Remplacer un fichier Excel partagé par une application métier

Il s’appelle « Suivi_commandes_v14_DEF », ou « Planning_interventions_2026 », ou simplement « Clients ». Créé un jour pour dépanner, il est devenu le lieu où l’administration des ventes lit les commandes du jour, où le magasin vérifie ce qui part, où la direction prend ses chiffres du lundi. Personne ne l’a décidé : il était là, et tout le monde savait s’en servir.

La question n’est pas de savoir si Excel est un bon outil. Elle est de savoir ce que ce fichier-là est devenu, quelles règles il applique sans les écrire, et où sa donnée doit vivre pour rester juste quand l’activité grossit.

Quand remplacer un fichier Excel partagé

Le fichier que tout le monde ouvre, et que personne ne possède

Un fichier partagé a beaucoup d’utilisateurs et rarement un responsable. Chacun y ajoute la colonne dont il a besoin, colore les lignes qui l’inquiètent, crée un onglet pour son propre suivi.

Le basculement se produit sans bruit : le jour où une décision est prise sur la seule foi de ce fichier, il est devenu une base de données. Une livraison part parce que la ligne dit « OK ». Une relance n’est pas faite parce que la cellule est verte. Une erreur dans le fichier devient une erreur de l’entreprise.

Les signes qui ne trompent pas

Ils se reconnaissent vite, et ils arrivent rarement seuls :

• Des copies qui divergent. « Copie de Commandes », une version enregistrée sur un poste « pour être tranquille », une autre envoyée par e-mail à un sous-traitant.
• Des formules cassées. Un tri sur une seule colonne, une ligne insérée au mauvais endroit, et un #REF! apparaît dans un total que plus personne ne vérifie.
• Une seule personne qui sait. Elle connaît la signification du rouge, la colonne qu’il ne faut pas trier, l’onglet qu’il ne faut pas toucher. Le jour où elle est absente, le fichier devient fragile.
• Une saisie libre là où il faudrait un choix. « OK », « ok livré », « Livré ? » dans la même colonne : trois manières d’écrire un statut, et aucun filtre fiable.

Ce qu’Excel fait bien, et qu’il faut garder

Excel calcule vite, se prête à l’exploration d’une donnée, permet une saisie rapide et se passe de formation. Dans sa version Microsoft 365 et dans Excel pour le Web, quand le classeur est stocké sur OneDrive ou SharePoint, plusieurs personnes peuvent modifier le même classeur en même temps, et un historique des versions permet de revenir à un état antérieur du fichier.

Le problème n’est donc pas l’outil, c’est l’usage. Quand on demande à un tableur de tenir des commandes, des statuts et des responsabilités partagées entre plusieurs équipes, on lui demande d’être une application. Après la bascule, Excel garde d’ailleurs souvent sa place : celle de l’analyse, alimentée par une donnée qui vit ailleurs.

Ce que votre fichier fait sans le dire

Un fichier qui tient une activité depuis plusieurs années est une application qui s’ignore. Il applique des règles métier par convention, sans les écrire. Le remplacer, c’est d’abord rendre ces règles explicites.

La couleur qui vaut statut, l’onglet caché qui vaut référentiel

Dans le fichier de commandes d’ACME Négoce (exemple fictif), une cellule rouge veut dire « client bloqué pour impayé ». Personne ne l’a écrit, tout le monde le sait, sauf le nouvel arrivant. Un onglet masqué contient les tarifs par famille de produits, que les formules vont chercher : c’est, dans les faits, une table de référence.

Une application ne lit pas les couleurs. Ce que le rouge signifiait doit devenir un statut, nommé, avec une définition. Ce que l’onglet caché contenait doit devenir une table, avec quelqu’un qui a le droit de la modifier.

Le commentaire qui sert d’historique

« Rappelé le 12, attend validation du devis. » La colonne « Commentaire » est souvent la seule trace de ce qui s’est passé sur une ligne. L’historique des versions et l’affichage des modifications récentes disent ce qui a changé dans le fichier ; ils ne disent pas pourquoi une commande est passée de « en attente » à « livrée ». C’est ce journal métier, qui garde le motif de chaque changement de statut, qui manque quand un client conteste une livraison.

Celui qui a le fichier ouvert, c’est le verrou

Quand le classeur est stocké sur un partage réseau classique, le premier qui l’ouvre le bloque souvent pour les autres, qui passent en lecture seule. Et même en co-édition, rien n’écrit dans le fichier que le magasin peut changer la date d’expédition mais pas le prix, ni que seule la comptabilité peut lever un blocage client. Excel permet de protéger une feuille et d’autoriser certains utilisateurs à modifier certaines plages, mais ce réglage est rarement posé dans un fichier qui a grandi par ajouts successifs : en pratique, tout le monde peut tout modifier.

Écrire ces règles revient à constituer un dictionnaire de données : chaque champ, sa définition, ses valeurs possibles, son responsable. La méthode est détaillée dans notre article sur la mesure et le maintien de la qualité des données.

Décider ce que l’application doit tenir

Avant l’outil, quatre décisions : quels objets, quels statuts, qui modifie quoi, et qui fait foi.

Les objets et leurs liens

Une ligne Excel mélange souvent plusieurs choses. Dans le fichier d’ACME Négoce, une ligne porte à la fois le nom du client, son adresse, la commande, les articles, la date de livraison et le transporteur. Quand un client passe trois commandes, son adresse est saisie trois fois, et elle finit par être différente dans l’une d’elles.

Une application sépare ces objets : un client, des commandes rattachées à ce client, des livraisons rattachées à chaque commande. Ce découpage ne dépend d’aucun outil.

Des statuts en liste fermée, et qui peut les changer

Excel sait proposer une liste déroulante dans une cellule. Dans un fichier qui a grandi par ajouts successifs, elle est rarement posée partout, et la saisie libre reprend le dessus. Dans une application, chaque statut appartient à une liste fermée, avec un ordre (« reçue », « préparée », « expédiée », « livrée ») et, pour chaque passage, la personne ou le rôle qui a le droit de le faire.

Qui fait foi quand l’information existe déjà ailleurs

Le fichier recopie souvent un autre logiciel : les clients viennent du CRM, les références produits de l’ERP. Il faut alors décider quel outil fait foi sur chaque information, et cesser de la ressaisir. Notre article sur le choix entre un module intégré et un CRM central traite cette question pour les données clients.

Remplacer un fichier partagé, c’est d’abord écrire ce qu’il décidait en silence. L’outil vient après.

Module existant, no-code ou sur mesure

Trois destinations se présentent, et un seul critère les départage : à quel point votre processus vous est propre. Le diagnostic en haut de page vous situe.

Quand le CRM ou l’ERP en place peut reprendre le fichier

Si le fichier suit des clients, des affaires, des commandes ou des factures, il y a de fortes chances qu’un logiciel déjà en place sache le faire. Le fichier existe parce que ce logiciel n’a pas été configuré pour cet usage.

C’est la situation que connaissait Orhatek, cabinet de conseil en solutions RH. Ses processus commerciaux et de facturation reposaient sur une combinaison d’Excel et de Sellsy, avec des ressaisies et des erreurs entre des outils non connectés, et aucun pilotage de la marge faute d’indicateurs fiables. turnK a structuré ces processus dans HubSpot Sales Pro, relié à la comptabilité sous Pennylane. La donnée a trouvé sa place dans des outils reliés entre eux, plutôt que dans un fichier de plus.

Quand un outil no-code sur une base de données suffit

Certains fichiers tiennent un processus simple mais à part : un registre de prêts de matériel, un suivi de demandes internes, une liste de contrôles qualité. Aucun logiciel en place ne le couvre, et le processus ne justifie pas un développement. Un outil no-code bâti sur une vraie base de données apporte alors l’essentiel : des objets séparés, des listes fermées, des droits par rôle, des formulaires de saisie.

Attention toutefois : mal conçu, un outil no-code reproduit les défauts du tableur, avec une interface plus agréable. Notre article sur l’automatisation des processus métier décrit comment cartographier un processus avant de l’outiller.

Quand le processus est assez propre à votre métier

Prenons une entreprise de maintenance (exemple fictif) : ses techniciens saisissent les interventions depuis un téléphone, ses sous-traitants déclarent leurs passages, et chaque intervention déclenche une facturation selon des règles propres au contrat du client. Aucun module standard ne colle à ce processus, et un outil no-code atteindrait vite ses limites sur les accès extérieurs et les règles de calcul.

Une application sur mesure se justifie alors, à condition que le processus soit réellement différenciant et stable dans ses grandes lignes. Les raisons de ce choix sont détaillées dans notre article sur l’investissement dans des outils conçus pour son métier.

Reprendre la donnée sans la perdre

La reprise se prépare dans le fichier lui-même, avant toute migration.

Nettoyer dans le fichier avant de migrer

Uniformiser les statuts (« OK », « ok livré » et « Livré ? » deviennent une seule valeur), séparer les colonnes qui mélangent deux informations, corriger les formules cassées, repérer les lignes en double. Pour ce dernier point, notre article sur les doublons et leur correction sans les recréer donne la méthode. Une donnée migrée sale reste sale, avec en plus la caution d’un nouvel outil.

Avant son passage à HubSpot, Café Joyeux travaillait notamment sur des documents Excel, avec une gestion manuelle et chronophage des données.

Garder l’historique utile, pas tout l’historique

Les commandes en cours, les clients actifs et les tables de référence doivent être repris avec soin. Les lignes closes depuis longtemps restent dans une archive figée. Pour chaque bloc d’historique, une question suffit : quelqu’un aura-t-il besoin de le filtrer, de le modifier ou d’en tirer un indicateur dans l’application ?

Fixer une date de bascule et passer l’ancien fichier en lecture seule

Le risque principal d’un remplacement n’est pas technique : c’est la période où le fichier et l’application vivent en parallèle. Il faut une date, annoncée à l’avance, à laquelle l’ancien fichier passe en lecture seule et les copies locales sont retirées. Un responsable de la donnée, nommé, tranche les questions des premières semaines.

Le jour de la bascule, l’ancien fichier ne disparaît pas : il cesse simplement d’avoir raison.

Par où commencer

Recenser les fichiers qui font foi aujourd’hui

Commencez par une liste courte : pour chaque fichier partagé, l’activité qu’il tient, les personnes qui en dépendent, ce qui se passe quand une ligne est fausse, et le logiciel qu’il recopie éventuellement. C’est aussi le point de départ d’un projet de gestion, comme le rappelle notre article sur le déroulé d’un projet ERP.

Ce que turnK apporte

Nous partons du fichier tel qu’il est. Nous rendons explicites les règles qu’il applique sans les écrire, nous structurons la donnée en objets, en statuts et en droits, puis nous choisissons avec vous où elle doit vivre : dans un logiciel déjà en place, dans un outil no-code ou dans une application conçue pour votre métier. Nous préparons ensuite la reprise et la bascule, pour que la donnée reste sûre et exploitable le jour où le fichier cesse de faire foi.