Outils internes
Comment remplacer Excel par un logiciel métier
Le fichier s'appelle « suivi_2024_v7_FINAL.xlsx ». Six personnes l'ouvrent chaque matin, deux savent à quoi servent les colonnes grisées, une seule comprend la formule de la colonne M. Il tourne depuis trois ans, et il fonctionne.
Par Wake Systems··9 min de lecture
Ce fichier est votre meilleur cahier des charges
Avant de parler de le remplacer, il faut comprendre pourquoi il a gagné. Un tableur est disponible immédiatement, tout le monde sait s'en servir, et il épouse exactement la façon de travailler de l'équipe, parce que c'est l'équipe qui l'a construit.
C'est un avantage considérable, et il explique pourquoi tant de logiciels sérieux finissent remplacés par un fichier partagé. Le logiciel imposait un processus, le fichier a suivi le vôtre.
Un tableur qui pilote une activité depuis trois ans n'est donc pas un défaut d'organisation : c'est une spécification fonctionnelle écrite par les utilisateurs et validée par l'usage. Aucun cahier des charges rédigé en réunion n'atteint ce niveau de précision.
Une régularité se vérifie sur presque tous ces fichiers : une petite partie des colonnes porte l'essentiel de l'usage quotidien, le reste étant de l'historique, des calculs intermédiaires et des colonnes que plus personne ne remplit. Distinguer les unes des autres est la première valeur d'un projet de remplacement.
Les signes qui justifient un diagnostic
Le moment du basculement se repère à des symptômes opérationnels, pas techniques.
- Plusieurs personnes doivent écrire en même temps, et quelqu'un arbitre les versions.
- Une colonne sert à savoir qui a fait quoi, parce que le fichier ne le sait pas.
- Des règles importantes vivent dans des formules que deux personnes seulement comprennent.
- Le fichier alimente autre chose, facturation ou planning, par copier-coller.
- Il existe plusieurs copies et personne ne sait laquelle fait foi.
- Une erreur de saisie a déjà eu une conséquence visible pour un client.
- Quelqu'un consacre régulièrement du temps à consolider les versions et à corriger les écarts.
Trois de ces signes réunis ne décident de rien à eux seuls, mais ils indiquent qu'un diagnostic mérite d'être fait. Le critère qui tranche ensuite n'est pas la taille du fichier : c'est le nombre de personnes qui en dépendent sans pouvoir le vérifier.
Ce qu'un outil apporte qu'un fichier ne peut pas
Un logiciel métier n'est pas un tableur plus joli. Il apporte quatre choses qu'un fichier ne peut structurellement pas fournir.
- Les droits : chacun voit et modifie ce qui le concerne, et seulement cela.
- L'historique : qui a changé quoi, quand, et quelle était la valeur précédente. Souvent le bénéfice le plus apprécié, et le moins anticipé.
- Les règles au moment de la saisie : une date de fin antérieure à la date de début est refusée à l'entrée, pas découverte trois semaines plus tard.
- Les raccordements : l'outil parle à la gestion, à la facturation, au site, sans copier-coller.
Le gain de temps vient ensuite, et il est réel, mais il arrive en second. Le premier bénéfice est la fiabilité : une information dont personne n'a plus besoin de vérifier qu'elle est à jour.
Le vrai risque : être moins souple que le fichier
Les projets de remplacement qui échouent ne tombent presque jamais en panne. Ils sont abandonnés, et toujours pour la même raison : l'outil est moins souple que le fichier qu'il remplace.
Dans un tableur, ajouter une colonne prend quinze secondes et ne demande l'autorisation de personne. Si la même opération demande trois semaines et un devis, l'équipe rouvrira un fichier à côté pour la nouvelle information. Et elle aura raison : son travail n'attend pas le prochain sprint.
À partir de là, le scénario est écrit. Deux sources coexistent, l'outil se vide de sa substance, et six mois plus tard quelqu'un constate que tout le monde est revenu au tableur. Le projet n'a pas échoué techniquement, il a échoué en souplesse.
La parade se décide à la conception, pas après. Il faut lister dès le départ ce que l'équipe pourra modifier seule : les listes de choix, les libellés, les modèles de documents, les seuils, les règles simples. Tout ce qui se modifie sans développeur ne se facture pas et ne frustre personne.
C'est le critère que nous regardons en premier sur ce type de projet, avant même les fonctions : qu'est-ce que l'équipe pourra changer lundi matin sans nous appeler ?
La transition, dans l'ordre qui fonctionne
La méthode efficace est l'inverse de celle qu'on imagine : on ne reproduit pas le tableur, on reprend d'abord son usage quotidien et rien d'autre.
- Observer. Une demi-journée à regarder l'équipe utiliser le fichier apprend davantage que trois réunions de cadrage.
- Isoler les colonnes qui portent l'usage réel, et laisser le reste de côté.
- Reprendre les données actives, celles qui ont bougé dans l'année, pas dix ans d'historique. Un projet de migration devient alors un import de quelques heures.
- Livrer une première version en service au bout de quelques jours, utilisée en parallèle du fichier.
- Étendre à partir de l'usage. Les manques réels se signalent d'eux-mêmes en quinze jours, et ce ne sont jamais ceux qu'on avait listés.
- Fermer le fichier. L'étape qui compte : tant que le tableur reste modifiable, l'outil ne devient pas la référence.
Une précaution utile : conservez le tableur en lecture seule pendant quelques mois. Personne n'y revient, mais savoir qu'il est là lève la moitié des réticences.
Délais et budget
Un outil interne qui reprend un tableur partagé, avec quelques rôles et une source de données, se met en production en une à deux semaines et se situe en moyenne entre 3 000 et 10 000 euros, sans limite haute.
Trois éléments font monter ce chiffre : le nombre de raccordements à d'autres systèmes, la reprise de l'historique complet, et le nombre d'exceptions aux règles. Les exceptions pèsent plus lourd qu'on ne le croit.
Trois éléments le font baisser : accepter des écrans conventionnels, repousser les statistiques à une deuxième étape, commencer par un seul service plutôt que par tous à la fois.
Le calcul de rentabilité est souvent immédiat, et il se fait sur le temps que l'équipe consacre aujourd'hui au fichier, sans compter les erreurs évitées, plus difficiles à chiffrer mais rarement négligeables.
Par où commencer
Prenez le fichier le plus partagé de l'entreprise, celui dont plusieurs personnes dépendent chaque jour. Regardez qui l'ouvre, à quelle fréquence, et ce que chacun y fait réellement.
Cette observation suffit à définir un périmètre de départ et à estimer un budget. Elle évite surtout l'erreur la plus courante, qui consiste à vouloir tout reprendre d'un coup alors que la moitié des colonnes d'un tableur ancien ne sert plus à personne.
Et posez la question de la souplesse avant celle des fonctions. Un outil un peu moins complet que prévu, mais que l'équipe peut ajuster elle-même, s'installe pour des années. L'inverse ne tient pas six mois.
