Une démonstration complète avec 1 686 enregistrements et 12 erreurs intentionnelles, de Google Sheets vers une base de données relationnelle fiable.

Un détaillant fictif de cafés spécialisés — « Roast & Ritual Coffee Co. » - parcourt tout son opération dans un classeur Google Sheets de 10 onglets : catalogue, variantes, inventaire, commandes, articles de commande, clients, fournisseurs, bons de commande, inventaires, journal d’activité. Le migration complète de ce classeur dans une base de données SQL normalisée, défauts inclus, est public et explorable sur demo.kamensky.dev.

TL;DR

Le problème	Les opérations de vente au détail dans Google Sheets pourrissent de manière prévisible : clients en double, inventaires à la dérive, prix historiques écrasés, aucune piste d’audit.
Qu’est-ce que la démo	Une migration déterministe et 100% reproductible : 10 onglets de feuille de calcul → 12 tableaux propres et liés, avec un rapport rendant compte de chaque décision de nettoyage.
Les chiffres clés	1 686 enregistrements sources → 1 634 importés · 16 doublons résolus · 18 valeurs normalisées · 3 lignes mises en quarantaine · 8 corrections de stock · 435 événements d’audit.
Les parties difficiles	Fusion du même client entré de deux manières (historique de 12 commandes réuni) ; conserver un prix promo de 54 $ alors que le catalogue indique 59 $ ; recalculer le stock à partir des mouvements lorsque la feuille indique 45 mais que le calcul indique 35.
Le modèle	Analyser → Carte → Nettoyer → Valider → Importer, exécuté comme une importation tout ou rien – soit il réussit complètement, soit il revient complètement en arrière.
À retenir	Une migration de feuille de calcul n’est pas un travail de copier-coller ; c’est un audit. Si votre rapport de migration ne peut pas prendre en compte chaque ligne, vous n’avez pas migré : vous avez déplacé le désordre.

Vous verrez ce qui se passe réellement lorsqu’une entreprise devient trop grande pour Sheets, comment chaque classe de défauts est détecté et résolu avec des décomptes exacts, et quelle est l’application des opérations qui en résulte on dirait. Si vous êtes plus tôt dans le voyage, commencez par Quand Google Sheets arrête de évoluer; si tu es planifiez une migration de base de données de production, associez-la au étude de cas : AppSheet vers SQL.

Le problème

Le classeur de démonstration est volontairement réaliste, car chaque entreprise utilisant une feuille de calcul converge vers les quatre mêmes modes de défaillance :

1. Fragmentation du client. Le même client est saisi sous différents orthographes dans les commandes – Marcus Vance dans un onglet, Marcus V. dans un autre. La valeur à vie et l’historique des commandes se divisent en deux identités, et aucune n’est correcte.
2. Dérive du recomptage des stocks. Un onglet statique « Inventaire » est une photographie, pas un grand livre. Les ventes et les réapprovisionnements atterrissent dans des onglets déconnectés ; quelqu’un oublie de mettre à jour le comte ; la feuille s’écarte de la réalité, une édition manquée à la fois.
3. Les faits historiques sont écrasés. Lorsqu’un prix catalogue change, un naïf la synchronisation « corrige » les anciennes lignes de commande pour qu’elles correspondent — réécrivant silencieusement votre comptabilité.
4. Visibilité d’audit nulle. Sheets ne peut pas répondre qui a modifié ce prix, quand le dernier recomptage a-t-il eu lieu et pourquoi.

La migration, étape par étape

Le pipeline comporte cinq étapes et, c’est important, l’importation s’exécute en une seule. étape tout ou rien. Il n’existe aucun état dans lequel la moitié du classeur est migré :

Scène	Ce qu’il fait
1. Analyser	Inspecte les formes des feuilles, la nullité et détecte les anomalies sales avant de toucher quoi que ce soit.
2. Carte	Applique des mappages explicites colonne-entité – rien n’est déduit par les vibrations.
3. Propre	Exécute les règles de nettoyage avec un suivi exact du décompte : chaque doublon, normalisation et quarantaine est compté.
4. Valider	Affirme des contrats record, l’intégrité des liens et six « faits héroïques » qui doivent survivre textuellement à la migration.
5. Importer	Chargement d’une seule transaction ; construit le grand livre des mouvements d’inventaire et le journal d’activité.

Métrique	Comte
Enregistrements sources	1 686
Importé avec succès	1 634
Doublons résolus	16 (14 clients, 1 fournisseur, 1 article de commande)
Valeurs normalisées	18 (7 SKU, 6 variantes, 5 e-mails)
Mis en quarantaine pour examen	3 (ordres ambigus – jamais abandonnés en silence)
Corrections boursières	8 (fiche manuelle ≠ registre des mouvements)
Prix ​​historiques préservés	1
Événements d’activité importés	435

Les 12 défauts rencontrés par chaque migration

Le classeur est livré avec douze défauts implantés (E1 à E12), chacun tiré d’un modèle réel. les migrations. Un échantillon de ce que le pipeline doit capturer :

ID	État hérité	Règle appliquée	Résultat
E1	Marcus Vance (C-023) et Marcus V. (C-071), même courriel	Fusionner par email normalisé ; conserver le nom légal le plus long ; relier les commandes	Un client avec un historique de 12 commandes
E3	La ligne ORD-1042 indique 54 $, le catalogue indique 59 $	Préserver order_items.unit_price comme fait historique	Prix ​​promo maintenu ; catalogue intact — deux chiffres, tous deux vrais
E4	La feuille d’inventaire indique 45 unités du SKU phare	Recalculer le stock à partir des mouvements : +120 achetés, −85 vendus	Le cheptel est de 35 ; la feuille avait dérivé +10
E9	Fournisseur typé comme “Importateurs de café Horzion”	Alias/résolution floue vers le fournisseur canonique	Réapprovisionnement lié à la bonne entité
E12	Téléphones vides, cellules réservées vides	Les valeurs vides restent vraiment vides, jamais de zéros factices	Données honnêtes, pas de faux espaces réservés

Les sept autres couvrent les fautes de frappe du SKU (ETH-yir-wb-1000), les noms de produits retapés où une référence SKU devrait être, e-mails clients manquants, chaos dans le boîtier (WHOLE BEAN / 1KG vs ground / 250g), un élément de campagne double-collé et un SKU abandonné commandé des années plus tard - importé et signalé, car la suppression l’histoire est pire que de la garder.

Le boîtier E4 mérite une mention, car c’est celui qui surprend : le La feuille de calcul n’était pas fausse le jour où elle a été écrite. Cela a dérivé. Trois achats commandes entrées (+120 sacs) et quinze commandes sorties (−85), le stock réel est de 35 — le la feuille 45 est le résidu des mises à jour manuelles manquées. C’est pourquoi la structure cible stocke les mouvements, pas les comptes : le stock est toujours calculé, jamais saisi à la main.

Explorez la démo en direct

Tout ce qui précède est consultable sur demo.kamensky.dev — une application d’opérations complète s’exécutant sur la base de données migrée (non en lecture seule) :

• Tableau de bord et analyses — KPI calculés à partir de tableaux propres et liés, et non collés à partir d’une feuille.
• Saisie de données et autorisations — rôles d’utilisateurs authentifiés avec limites d’autorisations granulaires et saisie de données en direct.
• Inventory Ledger — stock calculé à partir du grand livre des mouvements, avec le mathématiques achetées/vendues/calculées visibles par SKU.
• Client 360 — Marcus Vance ouvert : 12 commandes sur les deux anciennes identités, fusionné en une seule chronologie.
• Commandes, produits, fournisseurs, achats — répertoires complets avec pages de détails par commande, SKU et fournisseur.
• Notifications et intégrations — alertes opérationnelles automatisées et prêtes pour les intégrations externes.
• Rapport de migration — le tableau d’audit exact ci-dessus, rendu à partir de l’exécution.

Les données sont fictives (c’est une démo), mais déterministes : chaque régénération commence à partir des mêmes données sources fixes — les mêmes 12 défauts, les mêmes 1 686 enregistrements, à chaque fois. C’est ce qui rend la migration prouvable plutôt que « probablement bien ».

Votre classeur est-il en danger ?

Les défauts de démonstration sont implantés ; le vôtre s’est accumulé organiquement. Cette calculatrice marque à quel point votre classeur est proche des modes de défaillance ci-dessus – branchez vos propres numéros :

GARDERXYZ10XYZGARDER

Vous gérez votre boutique sans feuille de calcul ?La démo utilise SQLite (une base de données intégrée) pour rester autonome — le même modèle de pipeline est la façon dont je

migrez les activités de production vers des bases de données relationnelles structurées, avec des exécutions parallèles et un temps d’arrêt nul basculement. Si votre classeur montre les signes, c’est la conversation à avoir.

Réserver un appel découverte →

Pour en savoir plus : consultez les articles Google Sheets associés et le Étude de cas sur la migration d’AppSheet vers SQL, et Quand Google Sheets arrête de évoluer.