Si votre fichier Excel sert à calculer un budget, une marge ou une simulation, gardez-le : aucun autre outil ne fera mieux. S'il sert de registre où plusieurs personnes ajoutent des lignes chaque semaine, c'est cette partie-là qui doit sortir, et un autre tableur n'y changerait rien.
Votre fichier fait deux métiers à la fois
Un tableur calcule, et c'est ce qu'il fait mieux que n'importe quel logiciel de gestion. Vous tapes une formule, vous vois le résultat, vous changes une hypothèse et tout se recalcule. Pour un budget prévisionnel ou une simulation de marge, personne n'a inventé mieux.
Le problème arrive quand le même fichier se met à tenir un registre : la liste des clients, l'état du stock, les devis en cours, le planning des interventions. Ce travail-là n'est plus du calcul. Le fichier enregistre de la donnée que plusieurs personnes lisent et modifient, or un tableur n'a pas été conçu pour arbitrer entre deux personnes qui écrivent au même endroit.
Sur une liste de prospects, une question de définition s'ajoute au reste : deux personnes ne mettent pas la même chose derrière « client à relancer ». C'est ce que règle un lead scoring écrit noir sur blanc.
Regardez vos onglets, vous y trouveras souvent les deux. Un onglet de calcul, propre, avec des formules que vous maîtrises, et trois onglets de saisie où l'équipe ajoute des lignes au fil de l'eau. Ce sont ces onglets de saisie qui posent problème, et c'est sur eux que porte la suite.
Le vrai plafond arrive bien avant la dernière ligne
Quand on cherche les limites d'Excel, on tombe d'abord sur des chiffres. Microsoft documente 1 048 576 lignes et 16 384 colonnes par feuille, et 32 767 caractères par cellule. Une PME de vingt personnes n'approche pas ces plafonds, donc ces chiffres ne vous apprennent rien sur votre risque réel.
Le cas le plus connu est justement un plafond que personne ne surveillait. Fin septembre 2020, Public Health England compilait ses résultats de tests Covid dans l'ancien format .xls, limité à 65 536 lignes. Résultat : 15 841 cas positifs non remontés entre le 25 septembre et le 2 octobre, et jusqu'à 48 000 contacts prévenus trop tard, comme l'a détaillé The Register. Le fichier n'affichait aucune erreur, il continuait simplement sans les lignes en trop.
Dans une PME, ce qui casse est plus banal, et ça ne ressemble pas à une panne. Deux personnes ouvrent le fichier le même matin et la deuxième écrase la saisie de la première. Quelqu'un envoie une copie par mail pour avancer depuis chez lui, et il existe deux vérités pendant trois jours. Un chiffre est faux, personne ne peut dire qui l'a changé ni quand, parce qu'un classeur ne garde pas cette trace.
| Ce que tu constates | Ce qui se passe | Ce qui le règle |
|---|---|---|
| Deux versions du même fichier circulent | Chacun travaille sur sa copie et personne n'arbitre | Une source unique, avec des droits d'écriture attribués par personne |
| Un chiffre est faux, personne ne sait depuis quand | Le classeur ne conserve pas l'historique des modifications | Un outil qui horodate chaque changement et son auteur |
| La même donnée est saisie dans deux outils | Les deux outils ne communiquent pas, quelqu'un recopie | Une liaison entre les deux, ou un outil unique |
| Une seule personne comprend les formules | La règle métier vit dans un fichier au lieu d'être écrite | Les règles écrites hors du fichier, et un deuxième référent |
Aucune de ces quatre lignes ne se règle en changeant de tableur.
Le test qui dit si votre fichier a basculé
Ouvre le fichier et compte combien de personnes y ont ajouté une ligne depuis une semaine. Si la réponse est zéro ou une, vous avez un fichier de travail et vous pouvez vous arrêter là.
Si la réponse est deux ou plus, posez-vous ces trois questions :
- Est-ce qu'une copie du fichier circule par mail, ou est-ce qu'un « v3 final » existe quelque part ?
- Est-ce que quelqu'un facture, commande ou planifie à partir d'une ligne saisie par un autre ?
- Est-ce que vous pourrais dire, aujourd'hui, qui a modifié le dernier chiffre du mois dernier ?
Une seule réponse gênante sur les trois suffit à sortir la partie registre du tableur. Reste à savoir vers quoi.
Trois sorties, et comment choisir entre elles
Garder le tableur, avec des règles. Si une seule personne saisit, le tableur reste le bon outil, et ce qui change, c'est la discipline : un propriétaire nommé, une seule porte d'entrée pour la saisie, les autres qui lisent une copie. Commencez par là, parce que ça coûte une conversation plutôt qu'un budget.
Prendre un logiciel du marché. Dès que votre processus ressemble à celui de tout le monde (facturer, relancer, suivre des tickets, gérer un stock standard), un outil existant fera mieux et moins cher que n'importe quel développement. Comparez son abonnement mensuel au temps que votre équipe passe à recopier, plutôt qu'au prix du tableur, qui est nul ou presque.
Faire développer un outil interne. Ça se justifie quand votre processus est stable, singulier, et qu'aucun logiciel du marché ne le prend sans que vous déformes votre façon de travailler. C'est le cas de figure sur lequel nous intervenons chez Numinam, et c'est aussi celui que nous écartons le plus souvent après l'audit : si le processus rentre dans un outil existant, faire développer revient à payer pour réécrire ce qui existe déjà.
Notre propre produit, Coddy, tourne dans neuf pays sans qu'un tableur partagé serve de registre de réservations. Les réservations, les paiements et l'envoi des instructions passent par des outils reliés entre eux, et une personne n'intervient que sur les cas qui sortent du cadre.
Ce qu'un nouvel outil ne réglera pas
Changer d'outil déplace la donnée, ça ne crée pas la discipline. Trois choses restent à votre charge, quel que soit votre choix.
La propriété de la donnée. Si personne n'est responsable de la liste des clients, le nouvel outil héritera des doublons du tableur, en plus joli. Mettez un nom sur chaque jeu de données avant la migration.
La double saisie. Elle ne disparaît que si le nouvel outil parle à ceux que vous gardez. Un outil de plus qui ne communique avec rien ajoute une saisie au lieu d'en retirer une, et c'est la première condition à vérifier avant d'automatiser quoi que ce soit.
Le point de départ. Note deux chiffres avant la bascule : le temps que prend chaque semaine la tâche que vous voulez supprimer, et le nombre d'erreurs que vous corriges par mois. Sans eux, vous ne pourras pas dire si le nouvel outil a servi à quelque chose, et c'est tout l'objet d'une mesure de référence prise avant le changement.
La migration oblige aussi à trancher : les colonnes que personne ne remplit depuis deux ans ne se reprennent pas. C'est pénible, et c'est le bon moment pour le faire.
À retenir
- Gardez le tableur pour ce qu'il calcule. Sortez du fichier la partie où plusieurs personnes saisissent des lignes chaque semaine.
- Le signal est le nombre de personnes qui écrivent dans le fichier la même semaine. À partir de deux, sors la partie registre.
- Avant de faire développer quoi que ce soit, vérifie qu'aucun logiciel existant ne couvre votre processus. S'il le couvre, développer revient à payer pour réécrire ce qui existe.
- Mettez un nom sur chaque jeu de données avant la migration, sinon le nouvel outil récupère les doublons du tableur.
- Notez le temps passé et le nombre d'erreurs corrigées avant la bascule : c'est le seul moyen de dire ensuite si le changement a servi.
Vous ne sais pas dans quelle sortie vous tombes ? On part du déroulé réel d'une commande, du premier contact à la facture, plutôt que de la liste de vos logiciels : voir comment nous construisons les outils internes.
