Excel partagé : cinq signes qu'il est temps d'en faire un logiciel

Dans une part considérable des PME québécoises, un processus essentiel tourne sur un tableur partagé : les soumissions, les horaires, le suivi des commandes, la facturation des heures, l’inventaire. Ce n’est pas un signe d’amateurisme. Le tableur est l’outil le plus souple jamais inventé, il ne coûte rien, et il a permis à l’entreprise de fonctionner pendant des années sans attendre qu’un logiciel adapté existe. Le problème n’est jamais d’avoir commencé dans Excel. Il est de ne pas voir le moment où le fichier a cessé d’être un outil pour devenir un risque.

Cet essai propose cinq signes pour reconnaître ce moment, trois faux signes qui ne justifient rien, et une façon de passer au logiciel qui n’exige ni un projet de six mois ni un pari sur l’ensemble de l’entreprise.

Les cinq signes

1. Le fichier a un gardien. Une seule personne sait vraiment comment il fonctionne : quelles colonnes ne pas toucher, quelle macro relancer le lundi, pourquoi l’onglet caché existe. Quand elle part en vacances, le processus ralentit. Quand elle quitte l’entreprise, il s’arrête, ou continue en produisant des erreurs que personne ne sait expliquer. C’est le signe le plus grave, parce qu’il transforme une connaissance d’entreprise en dépendance à une personne.

2. Les versions divergent. Le fichier s’appelle Suivi_2026_final_v3_JM.xlsx, une copie circule par courriel, une autre vit sur un poste, et la réunion du mardi commence par dix minutes consacrées à établir quelle version fait foi. Dès qu’il faut se demander où est la vérité, elle n’est plus nulle part.

3. La même donnée est saisie deux fois. Une commande entre dans le tableur, puis dans le logiciel comptable, puis dans un courriel au fournisseur. Chaque recopie coûte du temps, et chacune introduit une chance d’erreur. Sur un processus de quelques dizaines de transactions par semaine, la double saisie représente vite plusieurs heures hebdomadaires qui ne produisent rien.

4. Les erreurs se découvrent chez le client. Une formule écrasée par une valeur, une ligne supprimée par mégarde, un filtre oublié au moment d’imprimer : le tableur ne proteste pas, et il ne garde qu’un historique rudimentaire de qui a changé quoi. L’erreur surgit donc en aval — une facture erronée, un stock annoncé qui n’existe pas, un employé mis à l’horaire deux fois. Quand le client est le premier à voir l’erreur, le coût n’est plus seulement interne.

5. On ne peut pas restreindre qui voit quoi. Le fichier contient les coordonnées des clients, parfois les salaires, parfois les marges. Tout le monde qui a besoin d’y saisir une ligne voit aussi tout le reste. Au-delà de la gêne, c’est une question de conformité : depuis la Loi 25, une entreprise doit pouvoir contrôler l’accès aux renseignements personnels qu’elle détient, et une copie envoyée au mauvais destinataire peut constituer un incident de confidentialité à consigner. J’ai détaillé ces obligations dans l’essai consacré à la Loi 25.

Deux signes suffisent à eux seuls : un gardien unique, et des erreurs découvertes par le client. Les trois autres s’additionnent.

Trois faux signes

Le fichier est gros. Un tableur de cinquante mille lignes qui fonctionne sans erreur et sans gardien n’a pas besoin d’être remplacé. Il a peut-être besoin d’être nettoyé.

Le fichier est lent. La lenteur vient presque toujours de formules recalculées sur des colonnes entières ou de mises en forme conditionnelles empilées. Une demi-journée de ménage règle souvent le problème pour une fraction du coût d’un logiciel.

Un concurrent a un logiciel. Ce n’est pas un argument. Un processus qui change chaque semaine, parce que l’entreprise cherche encore la bonne façon de faire, doit rester dans le tableur jusqu’à ce qu’il se stabilise. Figer dans un logiciel un processus qui n’est pas mûr, c’est payer pour construire ce qu’il faudra démolir.

Trois options, dans cet ordre

L’outil du marché, d’abord. Si un logiciel existant couvre le processus sans obliger l’entreprise à abandonner ce qui fait sa différence, c’est presque toujours la bonne réponse. Il sera maintenu par quelqu’un d’autre, et il coûtera moins cher au départ. La grille que j’utilise pour trancher est détaillée dans l’essai sur le choix entre construire et acheter.

Une base de données en ligne sans code, ensuite. Pour un processus simple, tenu par une petite équipe, ces outils apportent l’essentiel de ce qui manque au tableur : des champs typés, des droits d’accès, un historique. Leur limite apparaît quand le processus exige des règles métier complexes, des intégrations avec d’autres systèmes, ou quand le coût par utilisateur devient significatif.

Le sur-mesure, quand les deux premières options ont échoué. Il se justifie lorsque le processus est propre à l’entreprise, qu’aucun outil ne le couvre sans contorsion, ou que les abonnements cumulés pour y parvenir dépassent le coût d’un outil qu’elle posséderait.

Commencer petit, sur les vraies données

L’erreur la plus coûteuse, une fois la décision prise, est de vouloir remplacer tout le tableur d’un coup. Un fichier partagé porte généralement plusieurs processus imbriqués, construits en couches au fil des années. Un projet qui prétend tous les reproduire à l’identique dure des mois, et découvre en cours de route que la moitié des règles n’étaient écrites nulle part.

L’approche qui fonctionne est inverse. On isole le workflow le plus douloureux — celui qui a un gardien, ou celui où naissent les erreurs chez le client. On le remplace par un outil qui tourne en production, sur les vraies données de l’entreprise, utilisé par l’équipe qui s’en sert tous les jours. Le reste demeure dans le tableur tant qu’il ne pose pas de problème.

Ce premier outil sert de preuve. Soit il tient ses promesses, et la suite se décide sur des faits plutôt que sur une maquette. Soit il ne les tient pas, et l’entreprise l’apprend en quelques jours plutôt qu’au bout d’un projet de six mois.

C’est précisément le principe du Prototype en dix jours : un workflow, pas un système, construit sur vos données réelles et utilisé par votre équipe au bout de deux semaines. S’il ne tourne pas au dixième jour, vous ne payez rien.