Un tableur né pour dépanner — suivre quelques commandes, centraliser des contacts — grossit sans qu’on décide jamais consciemment de le faire grandir. Il finit par porter une activité entière, jusqu’au jour où il devient plus fragile que l’outil de fortune qu’il était censé rester. Le seuil auquel ce basculement se produit varie selon les usages, mais il se reconnaît à des symptômes précis avant même de compter les lignes.
Les symptômes qui précèdent le chiffre
Une formule recopiée à la main sur des centaines de lignes, plutôt que construite pour s’appliquer automatiquement à toute nouvelle donnée, indique déjà qu’un tableur a dépassé son usage confortable. Des onglets qui dupliquent la même information sous des formes légèrement différentes — une liste de clients ici, une autre là, jamais synchronisées — créent un risque d’incohérence qui grandit avec chaque mise à jour oubliée d’un des deux onglets. Un recalcul qui devient perceptiblement lent à l’ouverture ou à chaque modification signale que le fichier manipule plus de données que le logiciel n’est structurellement pensé pour en gérer confortablement. Et surtout, une seule personne dans l’organisation capable de comprendre et de modifier le fichier sans le casser est le symptôme le plus révélateur : ce n’est plus un outil partagé, c’est une dépendance envers une personne.
Trois questions avant de migrer
La première question porte sur la fréquence de mise à jour : un fichier modifié plusieurs fois par jour par plusieurs personnes justifie un outil pensé pour la concurrence d’accès, ce qu’un tableur gère mal au-delà d’un petit nombre d’utilisateurs simultanés. La deuxième porte sur la criticité : si une erreur dans ce fichier peut coûter cher — une commande mal facturée, un stock mal compté — la fiabilité prime sur la simplicité, et un outil structuré limite mécaniquement certaines erreurs qu’un tableur laisse passer. La troisième porte sur la croissance attendue : un volume qui va continuer à grossir dans les mois qui viennent justifie d’anticiper la migration avant que le fichier ne devienne trop central pour qu’on ose y toucher.
Le cas où le tableur reste le bon outil
Un usage ponctuel, une donnée peu volumineuse, une seule personne concernée et pas d’enjeu critique en cas d’erreur : dans cette configuration, migrer vers un outil plus structuré ajoute une charge de gestion sans bénéfice proportionné. La dette technique n’est un problème que lorsqu’elle finit par coûter plus cher à porter qu’à rembourser — un tableur simple, qui reste simple, n’en est jamais une. Cette question de seuil rejoint celle du pilotage de la trésorerie, où le même repère s’applique : au-delà d’un certain volume de lignes, l’outil artisanal cesse d’être une économie et devient un risque qu’on porte sans le mesurer.
