Dans Kingdom, un bon officier commande cent hommes à la voix. Il les voit, il les connaît, il corrige en temps réel. Le même officier à la tête de dix mille hommes ne voit plus rien. Ce n'est pas qu'il est devenu mauvais : l'outil qui marchait — sa voix — ne porte plus assez loin.
Excel, c'est cette voix. Redoutable à petite échelle. Et il existe un moment précis où il cesse de porter.
J'ai construit une application qui remplace un tableur de pointage pour le calcul des heures de travail. Avant de l'écrire, j'ai passé du temps à comprendre pourquoi le tableur avait tenu si longtemps — et ce qui avait fini par casser.
D'abord, la défense du tableur
Le réflexe du développeur face à un fichier Excel de gestion est le mépris. C'est une erreur, et ça coûte des missions.
Un tableur qui fait tourner une activité depuis quatre ans, c'est quatre ans de règles métier découvertes et encodées. Chaque colonne bizarre correspond à un problème réel. Chaque formule à rallonge est une décision prise un jour où ça ne marchait pas.
C'est aussi, honnêtement, un outil remarquable : pas d'installation, pas de formation, modifiable par la personne qui en a besoin au moment où elle en a besoin. Aucun logiciel sur mesure n'offre ça.
La bonne question n'est donc pas « comment remplacer ce tableur ». C'est « ce tableur est-il encore le bon outil ? » — et la réponse est souvent oui.
Les six signaux
Voilà ce qui dit que tu as dépassé le point de bascule. Un seul ne suffit pas. Trois, c'est décidé.
1. Plusieurs personnes doivent l'ouvrir en même temps
Le symptôme se reconnaît : planning_v4_FINAL_corrigé_JP.xlsx. Ou la personne qui demande dans le groupe WhatsApp si elle peut ouvrir le fichier.
Un tableur est conçu pour un auteur. Dès que deux personnes écrivent, tu as inventé un système de gestion de conflits à base de politesse.
2. Tu passes plus de temps à corriger qu'à décider
Le calcul mensuel prend un après-midi. Pas parce que le calcul est long : parce qu'il faut d'abord retrouver les erreurs de saisie, les doublons, la ligne décalée d'un cran.
Si le temps de nettoyage dépasse le temps d'analyse, le tableur est devenu le travail au lieu de le servir.
3. Une erreur coûte de l'argent réel
Une cellule fausse dans un suivi de prospects, c'est agaçant. Une cellule fausse dans un calcul de salaire, c'est un employé sous-payé et une conversation pénible.
Dès que le tableur touche à la paie, à la facturation ou à un stock qui se vend, le niveau d'exigence change. Un logiciel valide à la saisie ; un tableur accepte tout.
4. Tu ne peux pas répondre à « pourquoi ce montant ? »
Trois mois après, quelqu'un conteste un chiffre. Tu ouvres le fichier. La formule a été modifiée depuis. Les données sources ont été écrasées.
Un tableur n'a pas d'historique exploitable. Tu ne peux ni reconstituer, ni prouver. C'est le signal le plus sérieux de la liste, et le plus souvent ignoré.
5. Une seule personne sait le faire tourner
Elle a construit le fichier, elle connaît les onglets cachés, elle sait qu'il faut rafraîchir dans cet ordre. Elle part en congé, et l'activité ralentit.
Ce n'est pas un problème de tableur, c'est un problème de risque. Mais c'est le tableur qui l'a rendu possible.
6. Tu recopies d'un fichier à un autre
Export de la pointeuse vers un fichier, copie vers un deuxième, résultat vers un troisième. Chaque copier-coller est une occasion de se tromper, et personne ne garde la trace de qui a copié quoi.
Ce qu'il ne faut PAS faire
Voici où la plupart des projets de ce type échouent : reproduire le tableur à l'identique dans un logiciel.
Le client demande ça — c'est rassurant, il connaît. Le développeur accepte — c'est spécifié, c'est facile à chiffrer. Et on livre une application qui fait exactement la même chose, en plus rigide, sans la souplesse qui rendait le tableur supportable.
Les utilisateurs retournent au tableur en trois semaines.
Ce qu'il faut faire à la place : ne reprendre que le nœud du problème. Sur le projet de pointage, la douleur n'était pas « avoir un tableau ». C'était le calcul des heures à partir d'un export brut de pointeuse, avec les cas tordus — pointage manquant, journée à cheval sur minuit. Le reste — consulter, filtrer, exporter — Excel le fait déjà très bien.
Alors l'application importe le fichier XLSX, calcule, et réexporte en Excel. On n'a pas chassé le tableur : on lui a retiré la seule chose qu'il faisait mal.
Le traitement mensuel est passé d'un après-midi à quelques minutes. Et personne n'a eu à désapprendre quoi que ce soit.
Le bon ordre, si tu décides d'y aller
- Garde le tableur en production pendant toute la migration. Il est ton filet.
- Automatise un seul calcul, le plus douloureux. Rien d'autre.
- Compare les deux résultats pendant un mois. Les écarts que tu trouveras sont des règles métier que personne ne t'avait dites — c'est la partie la plus précieuse du projet.
- Ajoute la saisie seulement une fois que le calcul est fiable et accepté.
- N'abandonne l'export Excel jamais. Tes utilisateurs en auront toujours besoin, et le leur retirer est le meilleur moyen de perdre leur confiance.
Cet ordre a un avantage décisif : la valeur arrive dès la deuxième semaine. Une refonte complète demande six mois avant le premier bénéfice, et échoue souvent avant.
Le problème de fond
Notre profession a un biais : on aime construire, on n'aime pas comprendre ce qui existe.
Alors on propose de remplacer là où il faudrait augmenter. On appelle « dette technique » un système qui marche depuis quatre ans et fait vivre une entreprise. On confond « je ne comprends pas ce fichier » et « ce fichier est mauvais ».
Or la majorité des PME, ici comme ailleurs, tourne sur des tableurs. Ce n'est pas un état arriéré à corriger, c'est une solution qui a fonctionné jusqu'à une certaine taille. Le travail utile consiste à trouver précisément où elle a cessé de fonctionner, et à n'intervenir que là.
Le reste, c'est de la vente.
L'application de traitement des pointages est décrite ici, et elle est en ligne. Si tu as un tableur devenu trop lourd et que tu veux savoir s'il faut vraiment en sortir, écris-moi — il m'arrive de répondre que non.