Votre feuille de calcul d'inventaire va casser à 10 000 SKU
À ~10 000 SKU avec variantes et emplacements, une feuille de calcul d'inventaire devient lente et source d'erreurs. Les quatre modes de défaillance — et la voie de migration vers une base de données.
Le problème
Votre inventaire vit dans une feuille de calcul. Pas parce que quelqu’un l’a choisie délibérément — elle était gratuite, familière, et tout le monde savait l’utiliser. Elle a fonctionné avec 500 SKU. Elle a fonctionné, lentement, avec 2 000. Puis la gamme de produits a grandi : variantes, couleurs, tailles, trois fournisseurs, deux entrepôts, une boutique Shopify en plus d’une liste de gros, et quelqu’un a ouvert un journal des mouvements dans un deuxième onglet « juste pour l’historique ».
Cette feuille de calcul est désormais l’outil le plus cher de vos opérations, et la facture apparaît à des endroits inattendus. Les commandes sont sur-vendues parce que deux personnes ont modifié le même stock en même temps. Des articles dorment dans un entrepôt pendant que la feuille dit qu’ils sont épuisés. L’équipe cesse de faire confiance aux chiffres et recommence à compter à la main. Plus personne ne met à jour la feuille, car la mise à jour prend trop de temps et personne ne croit au résultat.
Cet article porte sur le moment où un inventaire sur feuille de calcul casse : les quatre modes de défaillance, pourquoi cela arrive autour de 10 000 SKU (et non à la limite théorique de lignes), et à quoi ressemble « le vrai » quand la feuille est remplacée par une petite base de données dotée d’une interface fine et recherchable.
Les quatre modes de défaillance
1. La recherche et le filtrage s’effondrent
Trouver un SKU devient un rituel. Vous collez un code dans le champ de filtre, la feuille se fige plusieurs secondes, puis affiche trois lignes — et l’une d’elles est celle de la mauvaise variante, parce que la recherche a matché le code du fournisseur dans une colonne lointaine.
Avec 10 000 SKU et une moyenne de trois variantes chacun, les seules données maîtres représentent des dizaines de milliers de lignes et plus de 20 colonnes. Les filtres se recalculent sur chaque ligne, et les gens cessent silencieusement de les utiliser — ils mémorisent un chemin de contournement ou demandent à un collègue qui « sait où sont les choses ». Chaque question devient une réunion.
2. Les modifications simultanées corrompent les stocks en silence
Un stock dans une feuille de calcul n’est qu’une cellule. Deux personnes peuvent ouvrir la feuille, voir toutes deux stock = 40 et la modifier — l’une à 37 après une vente, l’autre à 52 après une livraison. Les feuilles de calcul résolvent le conflit par « le dernier écrit gagne », et personne ne voit le perdant. Survit la modification arrivée en dernier, pas celle qui était vraie.
En inventaire, c’est pire que dans toute autre fonction, car la boucle de correction est lente. Le mauvais stock vit dans la feuille pendant des jours, générant de mauvais seuils de réapprovisionnement, de fausses promesses de disponibilité aux clients et de mauvais chiffres côté achats. Quand quelqu’un s’en aperçoit, la feuille et l’entrepôt divergent d’une marge dont le rapprochement prend des heures.
3. Le recalcul des formules transforme chaque modification en attente
Les feuilles d’inventaire s’appuient sur des recherches sur colonnes entières — VLOOKUP, SUMIFS, QUERY, IMPORTRANGE — pour cumuler quantités et coûts entre onglets. Chaque modification déclenche un recalcul qui touche des dizaines de milliers de cellules. Vous ouvrez la feuille et fixez un spinner ; vous effectuez une modification et vous attendez encore.
Le contournement aggrave le problème : les équipes regroupent leurs modifications et les font tard dans la journée pour ne pas regarder la feuille peiner. Mais alors les chiffres ne sont à jour que quelques heures par jour, et toute décision prise hors de cette fenêtre s’appuie sur des données obsolètes.
4. Les intégrations transforment la feuille en instantané figé
La feuille de calcul contient rarement la vérité de l’inventaire à elle seule — elle importe depuis Shopify, depuis l’entrepôt, depuis la liste de gros. Chaque intégration est une étape manuelle : exporter un CSV, le transformer, l’importer, espérer que les formats correspondent. Chaque aller-retour vieillit immédiatement : la feuille est une photographie du stock, prise au moment où quelqu’un a cliqué sur « Importer » pour la dernière fois.
Dès que votre boutique dépend d’un inventaire quasi en temps réel (disponibilité publique, automatisation des réapprovisionnements, exécution multi-emplacements), la feuille cesse d’être un outil et devient un passif. Les marchands Shopify le ressentent en premier : l’inventaire de la plateforme est en temps réel, et la feuille qui l’accompagne est la seule source de vérité dont on est sûr qu’elle sera fausse.
Pourquoi ça casse vers 10 000 SKU, pas à la limite
Les limites publiées sont grandes : Google Sheets plafonne à 10 millions de cellules par classeur, et Excel plafonne à 1 048 576 lignes sur 16 384 colonnes. Une liste propre de 10 000 SKU tient confortablement dans les deux.
Le problème, c’est que l’inventaire n’est jamais une seule liste propre. Ce sont des données maîtres, multipliées :
| Élément | Lignes ou cellules |
|---|---|
| 10 000 SKU × 3 variantes chacun | 30 000 lignes de données maîtres |
| × plus de 20 colonnes (code-barres, fournisseur, coût, prix, quantité par emplacement, seuil de réapprovisionnement…) | Plus de 600 000 cellules |
| 2 entrepôts + Shopify + gros = 4 emplacements, chacun avec sa colonne de quantité | ×4 colonnes de stocks |
| Journal quotidien des mouvements, 10 000 SKU × 180 jours d’historique | 1,8 million de lignes |
| Formules, mise en forme conditionnelle, tables IMPORTRANGE par-dessus | Chaque recalcul traverse tout |
Un simple journal des mouvements — une ligne par SKU et par jour pendant six mois — représente 1,8 million de lignes, ce qui ne tient pas du tout dans Excel. Dans Sheets, cela s’étale entre les onglets, et chaque recherche inter-onglets multiplie le coût de recalcul. La modification multi-utilisateur et les intégrations s’empilent alors sur une feuille qui était déjà à la limite.
La lecture honnête du « 10k » dans le titre : pas le point où le fichier cesse de s’ouvrir, mais le point où la précision, la vitesse et la confiance de la feuille échouent toutes à la fois — et où chaque contournement aggrave le problème suivant.
À quoi ressemble « le vrai » : Postgres + une interface fine
Quand une feuille d’inventaire casse, le remplacement n’est pas une feuille plus grande. C’est une petite base de données relationnelle — PostgreSQL est le choix habituel — surmontée d’une interface volontairement fine. Le périmètre est petit, et c’est tout l’intérêt : quelques tables et une barre de recherche battent un classeur à 12 onglets.
Le modèle est un inventaire normalisé, ce qui est une façon polie de dire que les données sont stockées une fois et comptées partout ailleurs :
products (one row per product: name, barcode, supplier, cost, price, status)
variants (one row per variant: product_id, sku, option values)
locations (warehouse A, warehouse B, Shopify, wholesale)
stock_levels (one row per variant × location: quantity, updated_at)
movements (one row per stock change: variant_id, location_id, delta, reference, at)Quatre propriétés le distinguent de la feuille de calcul :
- Les requêtes prennent des millisecondes à n’importe quelle taille. Une recherche filtrée sur une table de 100 000 lignes est une recherche par index, pas un scan de colonne entière. Personne dans votre équipe n’attend plus jamais les chiffres.
- Les écritures sont atomiques. Une vente qui décrémente le stock sur deux emplacements est une transaction — elle réussit ou elle échoue. Pas d’édition partielle, pas de collision « le dernier écrit gagne » entre deux personnes.
- L’historique est intégré. Chaque mouvement est une ligne dans
movements. Vous pouvez répondre à « quel était le stock mardi, et pourquoi a-t-il changé ? » — la question à laquelle une feuille ne peut répondre sans une piste d’audit que personne n’a tenue. - L’interface est une barre de recherche, pas une grille. Scannez un code-barres, voyez la variante, ses emplacements, ses stocks et ses mouvements récents — sur un seul écran. Votre équipe lit moins de cellules, pas plus.
Ce n’est pas un projet de grande entreprise. Pour une opération de 10 000 SKU, la construction représente quelques jours de travail : les quatre tables ci-dessus, l’import depuis la feuille actuelle et l’écran fin. Les extensions — synchronisation Shopify, alertes de réapprovisionnement, bons de commande — s’ajoutent ensuite, une à une, sur le même modèle.
La voie de migration qui n’affole personne
Quitter une feuille de calcul n’exige pas un basculement brutal. Le schéma qui fonctionne avec une entreprise en activité est celui de toute migration de données :
- Le schéma d’abord. Définissez les quatre tables et chargez-y une copie des données maîtres — pas en production, juste dans une base de travail.
- Import avec point de contrôle. L’export depuis Sheets ou Excel est validé ligne par ligne : les SKU invalides, les coûts manquants et les produits sans emplacement sont signalés, pas écartés silencieusement. Vous corrigez les données une fois dans la feuille, réimportez et voyez zéro erreur.
- Exécution en parallèle. La base de données tourne à côté de la feuille pendant deux à quatre semaines. Tout le monde continue d’utiliser la feuille ; l’équipe contrôle la base par sondage. Quand la base est juste à chaque contrôle, la confiance a déjà déménagé.
- Basculement. La feuille devient une référence en lecture seule, puis un artefact d’export. La base de données devient l’outil que les gens ouvrent le matin.
Une note honnête : c’est le même voyage que le transfert de toute donnée métier hors des feuilles, et le schéma général (y compris l’astuce de l’exécution en parallèle) est couvert dans Quand Google Sheets cesse de passer à l’échelle. Cet article est la version spécifique à l’inventaire : les quatre tables ci-dessus et la barre de recherche sont tout l’enjeu.
Avant et après, en chiffres
Un profil concret : 10 000 SKU, deux entrepôts plus une boutique Shopify, 250 commandes par jour, cinq personnes qui touchent à l’inventaire.
| Feuille de calcul | Postgres + interface fine | |
|---|---|---|
| Répondre « combien de X dans l’entrepôt B ? » | 20–60 secondes de filtrage, puis le doute | ~1 seconde, fiable |
| Temps quotidien de rapprochement des stocks | 1–2 heures de recoupements | 10 minutes d’examen des exceptions |
| Deux personnes modifient le même stock | Corruption silencieuse « le dernier écrit gagne » | Une transaction atomique, la seconde écriture attend |
| Historique des mouvements | « On ne l’a pas vraiment » | Chaque changement, pour toujours |
| Exactitude de la disponibilité Shopify | Obsolète jusqu’au dernier import manuel | Temps réel à la même minute |
| Maintenance mensuelle de la feuille | Continue, non rémunérée, inévitable | Aucune |
Le but de la comparaison n’est pas la technologie — c’est que la version feuille de calcul de cette opération n’est plus un outil, mais un employé à temps partiel dont l’unique travail est de maintenir les chiffres approximativement corrects.
Résumé
| Préoccupation | Feuille de calcul | Postgres + interface fine |
|---|---|---|
| Vitesse à 10 000+ SKU | Secondes à minutes par recherche | Requêtes en millisecondes |
| Modifications simultanées | Corruption silencieuse « le dernier écrit gagne » | Transactions atomiques |
| Historique / piste d’audit | Aucun | Intégré dans movements |
| Intégrations (Shopify, entrepôt) | Manuelles, obsolètes à l’arrivée | Temps réel, pilotées par API |
| Effort mensuel | Maintenance infinie non rémunérée | Quasi nul |
Si votre équipe rapproche encore l’inventaire dans une feuille de calcul — ou pire, a cessé de lui faire confiance et a recommencé à compter à la main —, la solution est une petite base de données avec une barre de recherche, pas une feuille plus grande. Pour les marchands Shopify, le cas des bundles montre exactement comment la feuille échoue sous la charge des commandes : Corriger les SKU de bundles Shopify sans chaos de feuilles de calcul le parcourt avec un vrai schéma d’automatisation.
Cet article fait partie de ma série sur quand les feuilles de calcul cessent de passer à l’échelle et de la série sur l’automatisation Shopify. Si votre feuille d’inventaire est déjà lente, réservez une appel de cadrage de 20 min — je regarderai votre configuration et vous dirai exactement combien de jours, pas de mois, coûte la migration.