Comment transformer mon fichier Excel en vrai système?
Déterminez ce que le fichier fait réellement — généralement un mélange de base de données, de processus et de rapports — et remplacez ces fonctions séparément. Le tableur est rarement le problème; le problème, c’est qu’il est le seul endroit où se trouve la vérité et qu’une seule personne le comprend.
Les signes qu’il est temps : deux personnes ne peuvent pas le modifier en même temps, quelqu’un tient une copie « maîtresse », les formules ne fonctionnent plus quand on déplace une ligne, ou l’entreprise s’arrêterait vraiment si ce fichier était perdu. Ajoutez-en un : quand le tableur a commencé à imposer un processus — des cellules qu’on sait ne pas toucher, des couleurs qui veulent dire quelque chose, un ordre d’onglets qui reflète le déroulement du travail — il est devenu un logiciel, mais un logiciel sans droits d’accès, sans historique et sans discipline de sauvegarde.
Décomposez les fonctions avant de remplacer quoi que ce soit. Les lignes sont une base de données : elles deviennent des tables avec des champs définis, des types et une fiche par élément du monde réel. Les formules et les copies manuelles entre onglets sont un processus : elles deviennent des déclencheurs et des règles qui s’exécutent sans que personne ait à s’en souvenir. Les onglets de synthèse sont des rapports : ils deviennent des vues sur des données en direct plutôt que des instantanés que quelqu’un refait chaque lundi. Vouloir remplacer les trois par une seule « application » monolithique, c’est ainsi que ces projets s’étirent; les remplacer comme des fonctions séparées garde chaque morceau petit.
La logique enfouie dans le fichier, c’est la partie que tout le monde sous-estime. Des années de cas particuliers vivent dans des formules imbriquées, dans la mise en forme conditionnelle et dans la tête de la personne qui entretient le fichier — le client facturé autrement, la colonne qui voulait dire autre chose avant 2024. Assoyez-vous avec la personne responsable du tableur et passez en revue les lignes bizarres avant de concevoir quoi que ce soit, parce que chacune de ces exceptions est une exigence, et celles que vous manquez refont surface sous forme de bogues après le lancement, au moment où la confiance est la plus fragile.
La migration que personne ne planifie, c’est l’historique. Décidez tôt quelles données passées doivent être transférées et sous quelle forme, parce que c’est généralement la moitié coûteuse du travail. Les vieilles lignes sont incohérentes — du texte libre là où le nouveau système attend une catégorie, trois orthographes du même client, des dates dans deux formats — et les nettoyer est un vrai travail. La décision pragmatique est souvent de migrer au complet l’historique récent, d’archiver le reste en lecture seule et de résister à l’envie de perfectionner des fiches vieilles de cinq ans que personne ne consultera.
Faites la bascule de façon délibérée : faites fonctionner le nouveau système en parallèle pendant une période courte et fixe, rapprochez les chiffres, puis figez le tableur en lecture seule plutôt que de le supprimer. Le gel compte — tant que l’ancien fichier reste modifiable, il reste le vrai système, et vous finissez par entretenir les deux. Un système comme celui-ci fait clairement partie du type de travail que le développement à l’ère de l’IA livre en quelques jours ou semaines, alors la période en parallèle peut être courte.
Dernière révision le 28 août 2026