Remplacer un tableur par une application web : quand et comment

Un tableur ne meurt jamais d’un coup. Il commence à trois colonnes, rend service, grossit. Un jour il pilote les plannings, le suivi client et la facturation à lui seul, personne ne sait plus qui a écrit la macro du deuxième onglet, et la moitié de l’équipe a sa copie « version finale » sur son bureau.

La bonne nouvelle, quand on décide d’en sortir : contrairement au remplacement d’un logiciel métier, vous partez d’une base saine. Les données sont déjà en lignes et en colonnes, et les formules disent noir sur blanc comment le calcul se fait. Le travail est moins d’enquête, plus de traduction.

Un ou deux de ces symptômes, c’est gérable. Quatre, le tableur vous coûte déjà plus qu’une application.

• On se marche dessus. Deux personnes ouvrent le fichier, l’une écrase la saisie de l’autre, et la version partagée en ligne rame dès qu’on dépasse quelques milliers de lignes.
• Les copies se multiplient. « planning_v3 », « planning_v3_DEF », « planning_à_jour » : dès qu’il existe plus d’un fichier, plus personne ne sait lequel fait foi.
• Les erreurs sont silencieuses. Une ligne insérée au mauvais endroit, une plage de formule qui ne suit pas, une cellule en texte au lieu d’un nombre : le tableur n’alerte pas, il calcule faux sans rien dire.
• Rien n’empêche une saisie absurde. Une date au 30 février, un client qui n’existe pas, un montant négatif : aucun contrôle, et l’erreur se propage.
• On ne sait pas qui a changé quoi. Pas d’historique fiable, donc aucune façon de revenir en arrière ni de comprendre d’où vient une valeur.
• La consolidation prend une demi-journée. Chaque semaine, quelqu’un recolle des onglets, vérifie des totaux et produit un état pour la réunion. C’est un poste de travail à lui tout seul.

Il ne s’agit pas de refaire le tableur en plus joli. Une application change ce que l’outil garantit.

• Elle contrôle la saisie au moment où elle se fait. Champs obligatoires, formats vérifiés, listes de choix : l’erreur est refusée à l’entrée, pas découverte trois semaines plus tard.
• Elle donne des droits par personne. Chacun voit et modifie ce qui le concerne. Le commercial ne touche pas aux marges, l’atelier ne voit pas la paie.
• Elle garde l’historique. Qui a modifié quoi, quand, et quelle était la valeur avant. Une question de dix minutes au téléphone devient une vérification de dix secondes.
• Elle encaisse plusieurs utilisateurs sans conflit. Vingt personnes peuvent saisir en même temps sans que personne n’écrase personne.
• Elle produit les états toute seule. Le récapitulatif hebdomadaire, l’export comptable, le tableau de bord : calculés en direct, plus recollés à la main.

Le tableur enregistre ce qu’on tape. L’application décide ce qu’on a le droit de taper — et c’est toute la différence quand on est plus d’un à s’en servir.

C’est l’avantage de ce point de départ, et il faut s’en servir pleinement.

Les données

Elles sont déjà structurées : une ligne par enregistrement, une colonne par information. La reprise consiste à nettoyer les doublons, à trancher quelques colonnes ambiguës et à charger le tout. Sur un tableur bien tenu, c’est l’affaire de quelques jours — sans commune mesure avec la reprise d’un vieux logiciel.

La logique métier

Les formules sont votre spécification, écrite gratuitement au fil des années. Le calcul de la remise, les règles de relance, la façon dont un dossier passe d’un statut à l’autre : tout est là, lisible. On le transcrit, on questionne les cas bizarres, et le cahier des charges s’écrit presque tout seul.

Les habitudes

Les gens saisissent vite parce qu’ils connaissent l’ordre des colonnes par cœur. Une application qui reprend cet ordre, ces raccourcis, cette logique de navigation est adoptée en deux jours. Une application qui réinvente le parcours « parce que c’est mieux » se fait rejeter la première semaine.

Ce graphique est celui que je montre quand un devis paraît élevé au regard du nombre d’écrans. Les écrans, c’est la barre du milieu. Les trois autres postes existent que le projet soit chiffré ou non — la seule question est de savoir s’ils sont dans le budget ou dans la surprise.

Le poste le plus sous-estimé est le premier. Un tableur contient toujours des cas non écrits : le client qu’on facture différemment, la ligne qu’on saisit en rouge pour dire « à vérifier », l’onglet caché qui sert une fois par an à la clôture. Ces règles ne sont ni dans les formules ni dans une procédure — elles sont dans la tête de la personne qui s’en sert. Il faut s’asseoir à côté d’elle pour les voir.

• Un seul processus, le plus douloureux. Pas « toute la gestion » : la partie qui fait perdre le plus de temps ou qui génère le plus d’erreurs. On la sort du tableur, on la met en service, on apprend, on enchaîne.
• Le tableur reste en parallèle le temps que l’application couvre le périmètre. On ne débranche que quand plus personne n’a de raison de rouvrir le fichier.
• Une reprise des données à blanc, tôt. Dès que le modèle est stable, on charge une copie réelle du tableur. En deux jours, elle révèle les anomalies qu’aucune réunion ne trouve en trois semaines.
• Garder l’ancien fichier en lecture après la bascule. C’est gratuit, et cela transforme chaque doute en vérification de trente secondes.

Si vous avez au contraire un logiciel métier en place, avec ses propres écrans et ses règles enfouies dans le code, la démarche est différente — c’est le sujet de moderniser un logiciel métier sans casser l’existant. Et avant de vous lancer, ces questions à poser à un prestataire valent aussi pour un outil interne.

C’est le cœur de la prestation application web métier. La première étape n’est pas un devis de développement, c’est un état des lieux : ce que le tableur contient vraiment, qui s’en sert, et ce que vaut la reprise de ses données. Décrivez la situation en quelques lignes, je réponds sous 48 heures.