Pourquoi les tableurs craquent dans un atelier qui grandit

La plupart des articles sur ce sujet énumèrent des symptômes : des stocks qui ne correspondent plus, un rapport qui prend deux jours à assembler, une seule personne qui comprend encore la logique du fichier maître. Tout cela est exact, et ça n’explique pas vraiment pourquoi l’outil qui fonctionnait très bien il y a trois ans cesse soudain de suivre.

La vraie réponse est architecturale. Un tableur est conçu pour une personne qui modélise un problème à la fois. Un atelier qui grandit n’est ni mono-utilisateur ni plat : il devient multi-utilisateur et sa structure devient par nature hiérarchique. Une fois cette inadéquation comprise, le moment de la rupture cesse d’être un mystère.

L’hypothèse d’un seul utilisateur

Excel a été conçu pour la modélisation financière individuelle. Il n’existe pas de véritable accès simultané, pas de verrouillage, aucun moyen de savoir qu’un chiffre à l’écran vient d’être modifié par quelqu’un d’autre trois minutes plus tôt. Tant qu’une seule personne possède le fichier, ce n’est pas un problème. Ça le devient dès que les ventes, le magasin, l’atelier et la comptabilité doivent lire et modifier les mêmes données pendant la même journée.

La suite est prévisible. Le fichier se copie, puis se recopie sous un nom légèrement différent. En quelques mois, quatre versions circulent, chacune étant la vérité de quelqu’un, et la question de savoir quel chiffre est le bon consomme du vrai temps de réunion. Ce n’est pas une question de formation. C’est ce qui arrive quand un outil mono-utilisateur sert de système à plusieurs.

Pourquoi la structure ne tient pas un produit réel

Le format natif d’un tableur est une liste plate. Ça fonctionne pour un produit à dix pièces sans sous-ensemble. Ça cesse de fonctionner dès qu’un produit fini se compose de sous-ensembles, eux-mêmes composés de composants plus petits, ce qui pour une fabrication à plusieurs niveaux est la norme, pas l’exception.

Pour faire tenir un produit arborescent dans un outil plat, on empile des formules imbriquées, parfois des dizaines, pour calculer le besoin réel d’un lot en tenant compte des composants partagés entre plusieurs produits. Ça tient tant que la gamme reste stable. L’ajout d’un nouveau produit, ou un changement de fournisseur, casse la construction presque à coup sûr, le plus souvent sans message d’erreur : juste un chiffre plausible mais faux.

Le moment où le bureau d’études et l’atelier divergent

L’erreur la plus coûteuse n’est pas une formule cassée. C’est un décalage de version. Un concepteur remplace, sur le plan, un composant qui n’est plus fabriqué. Dans une organisation pilotée par tableur, ce changement vit dans un fichier, sur un poste, jusqu’à ce que quelqu’un le propage manuellement. Les achats continuent de commander l’ancienne pièce. L’atelier monte le produit d’après une impression vieille de deux semaines. Personne n’a commis d’erreur, il n’existait simplement aucun mécanisme forçant la mise à jour à circuler.

Le résultat se voit en rebut, en reprises et en délais manqués. La littérature du secteur attribue fréquemment à ce type d’erreurs de spécification et de process une part significative des coûts opérationnels totaux d’un fabricant, rarement par négligence, presque toujours parce que rien n’obligeait la nomenclature à rester à jour.

Une planification qui n’existe qu’à l’écran

Le calcul des besoins matières, MRP, consiste à synchroniser des dizaines de variables : stocks, planning de production, stock de sécurité, délais fournisseurs, recalculé à chaque fois que l’un de ces paramètres change. C’est un calcul réellement difficile dès qu’une poignée de composants alimente plus d’un produit fini, parce que la quantité requise d’une pièce partagée dépend de la demande combinée de tout ce qui la consomme.

Un tableur peut approcher cela avec suffisamment de formules imbriquées, jusqu’au jour où une nouvelle référence apparaît ou qu’un fournisseur change, moment où le modèle doit être reconstruit par celui qui l’a bâti à l’origine. Si cette personne est absente, la planification s’arrête.

Un chiffre de coût déjà obsolète au moment de le lire

Les prix des matières bougent chaque semaine. Le rendement de la main-d’œuvre varie selon le poste et l’opérateur. Les frais généraux doivent bien atterrir quelque part. Dans un atelier piloté par tableur, rien de tout cela ne se reflète en continu ; quelqu’un recalcule le coût standard une fois par trimestre, et le commercial chiffre ses devis sur cette base jusqu’au recalcul suivant.

L’échec est silencieux par nature. Le volume de commandes peut sembler sain pendant que la marge s’érode discrètement, parce que les devis partent sur une base de coût qui a cessé d’être exacte des semaines plus tôt. Personne ne s’en aperçoit avant la clôture, quand les commandes sont déjà expédiées et le prix figé.

Ce que ça change au moment de choisir un système

Rien de tout cela n’est un procès fait à Excel comme outil. C’est un constat sur Excel comme système de référence pour une entreprise qui a dépassé les hypothèses mono-utilisateur et fichier plat sur lesquelles il repose. Le test pratique n’est pas une liste de symptômes. Il est plus simple : les données de production vivent-elles encore dans un fichier qu’une seule personne comprend, ou dans un système conçu pour la taille réelle de l’entreprise aujourd’hui.

Dans notre propre travail sur les modules de production pour des fabricants en assemblage et en fabrication mixte chez Bimp, c’est exactement ce moment, celui où un dirigeant a besoin d’un chiffre qui traverse deux services et attend deux jours pour l’obtenir, qui explique le mieux pourquoi passer à un ERP vertical cesse d’être perçu comme une dépense et commence à être perçu comme une question de maîtrise de son entreprise.