Faut-il remplacer votre fichier Excel, ou le garder ?

Temps de lecture estimé : 4 minutes

En bref : Un fichier Excel qui déborde ne mérite pas toujours d’être remplacé. Trois issues existent : le garder, acheter un standard, développer sur mesure. Cet article donne les seuils qui font basculer d’une issue à l’autre, et les cas où garder le fichier reste la bonne décision.

Appy Makers est un acteur du low-code. Notre avis n’est pas neutre, mais honnête.

Votre fichier Excel n’était pas une erreur

Excel est partout : suivi de projets, budget, planning, base de contacts. Il est l’outil réflexe des équipes pour trois raisons concrètes. Il est déjà installé et déjà payé. Une idée devient une feuille de calcul en quelques minutes. Et on peut l’ajuster sans passer par la DSI.

Un fichier construit par le métier est un cahier des charges vivant. Chaque onglet dit quelles données sont suivies, chaque formule dit quels calculs comptent, chaque colonne restée vide dit ce qui manque. Le métier a formulé son besoin sans attendre l’informatique.

D’où une règle que nous appliquons en cadrage : ne jamais mépriser ce fichier. Quand un responsable d’atelier ouvre son classeur à macros, il ne montre pas un contournement du SI, il montre un besoin que le SI n’a pas couvert. Remplacer d’abord et comprendre ensuite, c’est perdre ce qui a déjà été appris.

À partir de quels seuils un fichier ne tient plus ?

Les limites d’Excel se mesurent. Quatre indicateurs suffisent à objectiver la discussion. Les ordres de grandeur ci-dessous viennent de ce que nous constatons en mission, pas d’une étude : prenez-les comme des repères à confronter à votre terrain.

• Utilisateurs qui écrivent en même temps. Au-delà de 3 à 5 personnes en écriture simultanée, les écrasements de saisie deviennent une routine.
• Versions en circulation. À partir de 3 copies vivantes du fichier, plus personne ne sait laquelle fait foi.
• Personnes capables de faire tourner les macros. Quand une seule personne sait les faire tourner et les corriger, le fichier est un risque de continuité d’activité avant d’être un outil.
• Délai de propagation d’une correction. Si corriger une règle de calcul met plus d’une semaine à atteindre tous les utilisateurs, des décisions se prennent entre-temps sur des chiffres faux.

Un seul seuil franchi ne justifie pas un projet. Deux ou trois en même temps, oui, parce qu’ils s’alimentent : les versions se multiplient parce que la collaboration ne tient pas, et la correction met d’autant plus de temps à se propager qu’il y a de versions.

Dans quels cas faut-il garder Excel ?

Personne dans notre métier n’écrit « gardez votre fichier ». C’est pourtant la bonne réponse dans quatre situations.

• Le métier saisit lui-même les règles. Grille tarifaire, coefficients, seuils de remise : tant que ces valeurs bougent souvent et relèvent d’une décision métier, la feuille de calcul reste la surface de saisie la plus rapide. Elle peut alimenter une application sans être remplacée par elle.
• L’usage est de la simulation. Tester une hypothèse, comparer trois scénarios, jeter le résultat. Un tableur fait cela mieux qu’une application, qui impose un modèle de données figé.
• La fréquence est faible. Un fichier ouvert deux fois par mois par deux personnes ne génère pas assez de temps perdu pour rentabiliser un développement, même low-code.
• Le fichier est tenu par son auteur, et il le restera. La dépendance à une personne clé n’est un risque que si cette personne peut partir à un horizon qui vous concerne. Sur un fichier tenu par un responsable en poste depuis dix ans et à trois ans de la retraite, le risque se pilote, il ne se traite pas par un projet.

Sur un projet de configurateur commercial, l’Excel du métier contenait toute la logique de prix. Nous ne l’avons pas écarté au cadrage, au contraire : c’est lui qui tranchait les désaccords sur les règles, il a servi de support d’autorité métier pendant toute la phase. Il a simplement cessé d’être le runtime le jour où l’application est passée en production. Le fichier existe toujours et sert encore à simuler.

Remplacer : standard ou sur mesure ?

Si les seuils sont franchis et qu’aucun cas de maintien ne s’applique, reste à choisir quoi mettre à la place. L’ordre des questions compte, et il commence par ce que vous payez déjà.

1. Le besoin existe-t-il déjà dans votre SI ? ERP, CRM, logiciel métier : la fonction est parfois présente et non déployée, ou couverte par un module de l’éditeur. Attention toutefois à ne pas tordre l’ERP pour y faire entrer tous les processus : si le besoin est standard, le standard suffit, s’il ne l’est pas, l’ERP paiera l’écart en paramétrage et en montées de version.
2. Un standard du marché le couvre-t-il ? Maintenance portée par l’éditeur, conformité réglementaire suivie, pérennité qui ne dépend pas de vous. Quand un logiciel existant couvre 80 % du besoin, la question devient celle des 20 % restants et de ce qu’ils coûtent en contournement.
3. Et seulement ensuite, le spécifique. Quand le besoin est propre à votre entreprise et qu’aucun standard ne le couvre, le développement sur mesure se justifie. C’est le rôle d’une Digital Factory : coconstruire avec les métiers, dans un cadre posé par la DSI, en no-code et low-code pour réduire le coût d’entrée. Le fichier Excel sert alors de spécification de départ.

Pour transposer à votre contexte, trois questions suffisent. Combien de personnes dépendent aujourd’hui de ce fichier pour décider ou produire ? Combien de temps l’entreprise perdrait-elle si son auteur partait demain ? Et le besoin qu’il couvre est-il propre à votre activité, ou commun à toutes les entreprises de votre secteur ? Les deux premières réponses disent s’il faut remplacer. La troisième dit par quoi.

Un cas complet est détaillé dans notre retour d’expérience Marrel / CTELM, où un fichier de suivi de carrossage à macros, devenu instable après le départ de son auteur, a été repris en application : ERP modulaire & Digital Factory.