Remplacer Excel par un logiciel : ce qui reste, ce qui part, ce qu’il faut clarifier au préalable

L’indice figure souvent dans le nom du fichier : « Planning_final_nouveau_Version3 ». À côté se trouve « Planning_final_nouveau_Version3_Copie », et tout le monde au bureau sait qu’un seul des deux est juste. Celui qui les ouvre demande d’abord dans le couloir si quelqu’un est en train d’y travailler. Dans ce scénario, nous supposons une petite entreprise dont les commandes, les rendez-vous et les calculs convergent dans un seul classeur.

Le classeur n’est pas mal construit. Il s’est développé au fil des années, et chaque extension était raisonnable : une colonne pour le statut, une feuille pour le matériel, une macro qui transforme des lignes en devis. Ensemble, cela forme un système qui fonctionne tant qu’une personne précise le manipule. Si elle s’absente, on ne mesure qu’alors la quantité de savoir qui se cache dans les couleurs de cellules, les réglages de filtres et les colonnes masquées.

La question est donc rarement « Excel est-il mauvais ? ». Elle est : quand la feuille de calcul coûte-t-elle plus qu’elle n’apporte, et que perd-on si on la remplace ? Celui qui souhaite remplacer Excel par un logiciel devrait d’abord poser cette seconde question, car la réponse décide si le projet réussit ou s’il ne produit qu’un nouvel outil avec les mêmes vieilles erreurs.

S’y ajoute un moment que beaucoup d’entreprises connaissent : un nouveau collaborateur doit saisir des données et demande quelle colonne désigne la « date de livraison » et laquelle la « date souhaitée ». La réponse est : « Ça se voit à la couleur ». De telles phrases sont inoffensives tant que la personne qui peut les expliquer est là. Elles sont un signal d’alerte quand le savoir est concentré en un seul endroit.

Excel échoue rarement par manque de puissance de calcul, mais par simultanéité et par manque de caractère contraignant. Deux personnes saisissent des modifications le même matin, une version écrase l’autre, et on ne s’en aperçoit que quand une livraison manque. Même avec une édition partagée dans le cloud, le problème de fond demeure : chaque cellule peut contenir n’importe quoi, et personne ne vérifie si une date est vraiment une date.

S’y ajoute l’invisibilité des règles. Une formule renvoie à une feuille masquée, une macro convertit des valeurs à l’enregistrement, une mise en forme conditionnelle colore en rouge les lignes de plus de dix jours. Personne n’a jamais formulé ces règles comme une exigence, et pourtant on s’appuie dessus. Lors d’un remplacement, ce sont les points qui se perdent sans avertissement.

Enfin, la traçabilité fait défaut. Qui a modifié le prix à la ligne 214, et quand ? Excel peut suivre les modifications, mais au quotidien le journal est lacunaire ou désactivé. Pour les entreprises qui gèrent des devis, des procès-verbaux de contrôle ou des données clients, c’est plus qu’une question de confort, car cela touche à la responsabilité, aux réclamations et à la protection des données.

Un remplacement commence par un tri. Excel est excellent pour les analyses ponctuelles, les scénarios, les modèles de calcul rapides et les évaluations où quelqu’un explore des données. Il est faible pour les données que de nombreuses personnes tiennent à jour en même temps, qui doivent faire respecter des règles et qui exigent un historique. Celui qui mélange les deux dans un fichier a généralement trouvé la cause du problème.

Une distinction utile sépare saisir, traiter et analyser. La saisie et le traitement relèvent d’une application dotée de formulaires, de champs obligatoires, de droits et d’un journal. L’analyse peut rester dans Excel, alimentée par un export propre. Ainsi, les collaborateurs gardent l’outil familier là où il faut de la liberté, et les données gagnent en rigueur là où la liberté produit des erreurs.

Tous les tableurs ne méritent pas un logiciel. Une liste de quelques entrées qu’une personne met à jour une fois par mois est très bien dans Excel. Un remplacement se justifie là où de nombreuses personnes modifient les mêmes données, où les erreurs coûtent de l’argent ou de la confiance et où les processus se répètent régulièrement. Nous indiquerions honnêtement quels fichiers de l’entreprise peuvent volontairement rester.

Une pierre de touche est la question de savoir qui devrait reprendre le fichier demain. Si une nouvelle collègue peut l’utiliser en toute sécurité après une semaine, la structure est solide. Si elle a besoin de mois et de transmission orale, le fichier est déjà un risque opérationnel, quelle que soit la qualité de ses calculs.

La voie tentante est le grand soir : le classeur est reconstruit, basculé à une date butoir, et Excel est éteint. L’expérience montre que cela échoue sur deux points. Premièrement, l’étendue fonctionnelle de l’ancien classeur est plus grande qu’il n’y paraît. Deuxièmement, une date butoir met la pression au moment précis où apparaissent les premières erreurs. Nous ne choisirions cette voie que pour des fichiers très petits et faciles à embrasser.

Un remplacement par tranches convient mieux. On commence par basculer le domaine qui pose le plus de problèmes et dont les règles sont les plus claires, par exemple la saisie des commandes. Les analyses restent d’abord dans Excel et lisent la nouvelle source. Chaque tranche livre à elle seule un état fonctionnel, et l’équipe apprend sur un exemple maîtrisable au lieu de devoir tout absorber d’un coup.

Comme alternative, un logiciel standard entre en ligne de compte, par exemple une gestion de commandes prête à l’emploi ou une plateforme low-code. C’est souvent le bon choix si les processus de l’entreprise sont de toute façon courants. Un logiciel sur mesure se justifie quand les règles propres font l’avantage concurrentiel ou qu’aucun produit ne les reproduit. Nous comparerions les deux et laisserions la décision à l’entreprise, non au prestataire.

Une troisième possibilité consiste à garder Excel et à le construire avec plus de rigueur : feuilles de saisie et de calcul séparées, validation des données, formules protégées, un stockage central avec une responsabilité claire. C’est économique et rapide, mais atteint ses limites dès que de nombreuses personnes travaillent en même temps ou que des droits et un journal sont exigés. Comme étape intermédiaire, cela peut avoir du sens, car cela rend de toute façon visibles les règles dont un remplacement ultérieur aura besoin.

L’étape de travail la plus importante est discrète : nous lisons le classeur comme un expert. Chaque feuille est examinée pour savoir ce qu’elle stocke, ce qu’elle calcule et sur quoi elle s’appuie. Ce qui est masqué, protégé et lié est rendu visible, et les macros sont décrites ligne par ligne. Le résultat n’est pas un programme, mais une liste de règles en langage courant que l’entreprise peut relire.

Trois sortes de règles apparaissent. Il y a les règles explicites, par exemple « remise à partir de dix pièces ». Il y a les règles implicites, qui ne valent que par habitude, par exemple « les commandes à fond rouge sont traitées en premier ». Et il y a les compensations d’erreurs, où le classeur calcule quelque chose de faux et où les collaborateurs corrigent l’écart de tête. Ce troisième type ne doit pas être repris sans vérification.

À titre de contrôle, on réalise un entretien avec ceux qui travaillent chaque jour avec le fichier, et pas seulement avec la direction. Des questions comme « Que faites-vous quand le chiffre n’est pas bon ? » font ressortir ce qu’aucun document ne révèle. De ces deux sources naît une liste sur laquelle on décide ensemble : cette règle reste, celle-ci est simplifiée, celle-là disparaît parce qu’elle n’était qu’un expédient.

Il en découle au passage un bénéfice qui n’a encore rien à voir avec le logiciel. L’entreprise apprend comment elle travaille réellement et peut décider si c’est bien voulu. Certains remplacements deviennent ainsi plus modestes, parce qu’une règle superflue disparaît avant d’être coulée dans le code.

Lors du déménagement, on voit à quel point Excel est indulgent. La même colonne contient « 12.03.2024 », « mars 24 » et « 12/3 ». Les noms apparaissent avec ou sans titre, les montants avec virgule, point ou symbole monétaire dans un champ texte. Une base de données exige l’unicité, et c’est pourquoi le nettoyage détermine la qualité du nouveau système plus que n’importe quelle interface. Prévoyez-y une part considérable du temps de projet.

Techniquement, la migration s’effectue par scripts, pas à la main. Les données sont lues, vérifiées, normalisées et écrites dans la structure cible. Les lignes qui enfreignent une règle atterrissent dans une liste d’erreurs que les spécialistes de l’entreprise traitent. Après chaque exécution, nous comparons les nombres, les totaux et des échantillons avec la source. Les doublons et les orphelins font l’objet d’une décision consciente, ils ne sont pas supprimés en silence, et l’original reste inchangé à titre d’archive.

L’application se compose de quelques briques. Une base de données stocke les commandes, les clients et les postes dans des tables distinctes, une couche applicative impose en un seul endroit les champs obligatoires, les changements d’état autorisés et les calculs, et une interface web reflète la manière de travailler de l’entreprise. Les droits se pensent en rôles : la planification modifie les rendez-vous, la comptabilité voit les chiffres mais pas la communication avec les clients. Celui qui n’a pas besoin de données ne les voit pas ; l’entreprise règle les détails avec son conseil en protection des données.

Un journal des modifications consigne l’utilisateur, l’horodatage, l’ancienne et la nouvelle valeur, y compris lors d’une suppression. La question « Qui a modifié cela ? » devient un simple coup d’œil à l’historique. L’export reste une fonction native : chaque liste peut être sortie en fichier CSV ou Excel, et les données sont dans un format ouvert. L’entreprise reste ainsi indépendante de l’éditeur, et les analyses peuvent se poursuivre dans Excel.

La transition est le moment où les projets basculent. Nous ferions fonctionner l’ancien et le nouveau en parallèle pendant une période limitée : les mêmes opérations sont saisies dans les deux systèmes, et un rapprochement régulier met en évidence les écarts. Cela prend du temps et n’est pas populaire, mais cela révèle des règles oubliées lors de l’état des lieux. Chaque écart est un constat sur le nouveau système ou sur l’ancien classeur.

La durée du fonctionnement en parallèle dépend du rythme de l’entreprise. Celui qui facture chaque mois devrait vivre au moins un cycle de facturation complet dans les deux systèmes. Il faut aussi une option de repli claire : tant que le rapprochement montre des zones d’ombre, Excel reste la source de référence ; ensuite, la référence change et l’ancien classeur passe en lecture seule, sans être supprimé.

On ne convainc pas les équipes avec des diapositives de formation. Il est utile d’associer tôt les personnes qui travaillent chaque jour avec le classeur et de prendre leurs contournements au sérieux. Un raccourci inventé par quelqu’un révèle en général un besoin réel. De brèves prises en main sur des cas concrets, un interlocuteur interne et un point de contact pour les questions durant les premières semaines sont plus efficaces que de volumineux manuels.

Il faut aussi parler honnêtement des résistances. Celui qui était efficace depuis des années avec un fichier perd d’abord en rapidité dans le nouveau système. Cet effet est normal et passager, mais il doit être anticipé, par exemple en allégeant la charge lors des pics d’activité. Le taire crée de la méfiance, qui nuit ensuite davantage au projet que la période d’apprentissage.

Un cas particulier concerne les macros qui font appel à des programmes externes ou génèrent des documents. Il ne suffit pas ici de lire le code : il faut connaître le résultat. À quoi ressemble le devis que reçoit le client, et qu’est-ce qui ne doit jamais y changer ? Ces sorties sont reconstruites sous forme de modèles et comparées phrase par phrase avec d’anciens documents avant que la première opération réelle ne passe par là.

Un logiciel ne promet pas de miracles, mais il élimine certaines catégories d’erreurs. Les conflits de versions disparaissent, car il n’existe qu’un seul état des données. Les saisies invalides sont bloquées au niveau du formulaire au lieu d’être découvertes dans l’analyse. Les modifications sont traçables, et les droits limitent les dégâts qu’une étourderie peut causer. Ce sont des améliorations structurelles qui ne dépendent pas de la forme du jour d’une personne.

Le bénéfice devient mesurable à l’aide d’indicateurs que l’entreprise définit elle-même avant le début du projet. Parmi eux : le nombre de corrections après la saisie, le temps consacré à la clôture mensuelle et aux rapports, le nombre de questions dues à des versions peu claires et le délai avant que les nouveaux collaborateurs travaillent de manière autonome. Une base de comparaison issue des semaines précédant la bascule est essentielle ; sinon, toute affirmation ultérieure reste une impression.

Ce que l’on ne peut pas promettre : des gains de temps précis en heures ou en pourcentage avant de connaître les processus. Il serait également malhonnête d’affirmer que tous les intéressés adoreront le nouveau système. L’objectif réaliste est que le travail devienne plus fiable, que l’entreprise dépende moins de certaines personnes et que les données restent disponibles. La rentabilité se vérifie sur plusieurs mois, pas durant la première semaine.

En face, il y a des coûts récurrents qu’il convient d’aborder ouvertement. Une application nécessite hébergement, mises à jour, sauvegardes et, de temps à autre, des adaptations lorsque les processus évoluent. Excel semblait gratuit parce que les coûts induits étaient cachés dans le temps de travail et les erreurs. La comparaison n’est équitable que si les deux côtés sont présentés honnêtement.

La qualité des données elle-même devient aussi un critère. Après la bascule, on peut compter combien d’enregistrements contiennent toutes les informations obligatoires et combien d’entrées ont dû être corrigées après coup. Ces chiffres sont inconfortables, car ils montrent des faiblesses qu’Excel masquait en silence. Mais ils sont exactement ce dont une entreprise a besoin pour améliorer ses processus de façon ciblée au lieu de simplement subir les erreurs.

On peut tirer de la méthode quelques principes. Premièrement : la liste de règles est plus importante que le code. Celui qui la tient proprement peut étendre le système plus tard sans avoir à déterrer de nouveau le savoir. Deuxièmement : le nettoyage des données est un sous-projet à part entière, avec sa propre responsabilité dans l’entreprise, et non un sous-produit de la programmation.

Troisièmement : les petites tranches valent mieux que les grands coups. Un domaine qui fonctionne proprement en quelques semaines crée la confiance et apporte des enseignements pour le suivant. Quatrièmement : ne pas déclarer Excel ennemi. Laisser le fichier comme outil d’analyse enlève des résistances au projet et conserve une compétence éprouvée. Cinquièmement : l’export fait partie du système dès le départ, car il garantit l’indépendance.

Les cas où il vaut mieux déconseiller un remplacement sont tout aussi instructifs. Si les processus eux-mêmes sont encore flous, le logiciel ne fera que les figer. Si le fichier est tenu par une personne pour une personne, une feuille de calcul mieux construite, avec contrôle de saisie et courte documentation, suffit souvent. C’est aussi un résultat légitime d’un conseil.

Un autre principe concerne la responsabilité après le lancement. Une application n’est pas un objet que l’on réceptionne puis que l’on oublie. Il faut quelqu’un dans l’entreprise qui recueille les demandes, gère les droits et hiérarchise les retours ; sinon, une prolifération de solutions ponctuelles réapparaît vite dans le nouveau système, sous une autre forme. Ce rôle n’a pas besoin d’être important, mais il doit être désigné et doté d’un peu de temps.

Remplacer Excel par un logiciel est rarement une tâche technique, mais d’abord une tâche organisationnelle. Vous devez savoir ce que fait réellement votre classeur avant de pouvoir juger ce qu’un successeur doit accomplir. Le remplacement réussit lorsque les règles sont documentées, les données nettoyées, les transitions planifiées et les personnes associées. Il échoue lorsqu’on construit une interface en espérant que le reste suivra.

Un premier pas coûte peu. Ouvrez votre classeur le plus important et notez qui le modifie, quelles feuilles sont masquées et quelles macros s’exécutent. Demandez à deux collègues ce qu’ils font lorsqu’un chiffre ne tombe pas juste. Cette liste permet de décider calmement si un remplacement vaut la peine, si un meilleur fichier Excel suffit ou s’il faut d’abord clarifier les processus.

Nous examinons volontiers un tel classeur avec vous et vous donnons une appréciation claire de ce qui doit être remplacé, de ce qui peut rester et de l’effort à prévoir. Nous ne nous engageons sur aucune économie tant que les processus ne sont pas connus.

Planifiez avec réalisme : un remplacement dure plus longtemps que ne le laisse penser la première impression du classeur, car les règles cachées n’apparaissent qu’à la lecture. Une première étape clairement délimitée, avec un cadre fixe, est donc une meilleure entrée en matière qu’une offre globale pour l’ensemble.