Système de référence : pourquoi un résultat qui n'y figure pas n'existe pas pour l'entreprise
Lorsque nous avons conçu un générateur de propositions commerciales, la partie la plus sous-estimée n'a pas été l'assemblage du document, mais un geste technique précis : le document terminé s'attachait automatiquement à la fiche de l'affaire. Cela ne faisait pas gagner de temps au commercial. Cela déterminait si le document existait pour l'entreprise ou non.
Le système de référence (system of record — le système où vit, pour l'entreprise, la vérité sur une affaire, un document ou un client) n'est pas une notion d'architecture, mais de gouvernance. Tout fait, dans une entreprise, a un endroit où il est considéré comme vrai. Si le résultat d'un travail n'y arrive pas, il n'a tout simplement pas eu lieu pour l'organisation, quelle qu'ait été sa qualité.
Une automatisation n'a de valeur que si son résultat atteint le système de référence. Un résultat resté dans une conversation, un tableur ou un e-mail n'est hérité par personne, n'apparaît dans aucun rapport et ne survit pas aux congés de son auteur. Les données sur les erreurs dans les tableurs et sur la qualité des données d'entreprise montrent ce que coûte le fait de conserver la vérité hors du système : la part des enregistrements défectueux se compte en dizaines de pour cent.
Quatre signes qu'un fait de l'entreprise n'a pas de domicile
Le problème ne se voit pas dans l'architecture, mais dans les conversations. Chacun des quatre signes ci-dessous est le symptôme d'une même réalité : la vérité sur un fait vit là où personne ne la garantit.
« Je vous envoie le fichier. » La seule version à jour d'un document existe chez une seule personne et circule à la main. Un mois plus tard, plus personne ne sait quelle version est la dernière ; six mois plus tard, l'auteur lui-même l'ignore.
« Demandez-lui, c'est elle qui suivait ce client. » La vérité sur l'affaire vit dans la mémoire d'une collaboratrice. Cela fonctionne jusqu'aux congés, jusqu'au changement de service ou jusqu'au départ — et plus jamais après.
« Le rapport ne correspond pas à la réalité. » Les données du système décrivent une partie du travail, tandis que les décisions se prennent sur une autre partie, absente du système. Le dirigeant voit un rapport correctement construit sur des données incomplètes, sans pouvoir s'en rendre compte.
« Nous avons un tableur où tout est juste. » Le cas le plus dangereux, car il ressemble à une solution. Le tableur devient un tableur fantôme : on lui fait confiance, on s'y réfère, mais il n'a ni droits d'accès, ni historique des modifications, ni contrôles.
| Où vit la vérité | Que se passe-t-il quand l'auteur part | Est-ce visible dans un rapport |
|---|---|---|
| Système de référence | Rien, le fait reste accessible | Oui |
| Fichier chez un collaborateur | La version à jour se perd | Non |
| Mémoire d'un collaborateur | Le fait disparaît entièrement | Non |
| Tableur fantôme | Le fait reste, mais cesse d'être mis à jour | Non, et c'est le plus dangereux |
La troisième colonne explique pourquoi ce problème perdure pendant des années. Trois cas sur quatre sont invisibles dans le reporting, et on ne les découvre qu'au moment où quelque chose s'est déjà cassé.
Ce que coûte réellement un tableur fantôme
Le tableur comme dépositaire de la vérité est mieux documenté qu'on ne le croit : il existe à la fois des audits de terrain et des expériences contrôlées à son sujet.
Des audits de terrain sur des tableurs d'entreprise ont trouvé des erreurs dans 24 % des 367 fichiers examinés ; avec des méthodes d'audit plus rigoureuses, cette part est montée à au moins 86 %. Dans des expériences contrôlées, 51 % des participants ont commis une erreur en créant des tableurs de seulement 25 à 50 cellules.
Il s'agit d'une synthèse regroupant des études hétérogènes et partiellement anciennes, et la part des « tableurs comportant des erreurs » dépend fortement de la rigueur du critère retenu et de la taille du fichier. C'est une limite réelle. Mais l'écart de 24 % à 86 % est en soi instructif : plus on cherche attentivement, plus on trouve — exactement la propriété qui manque à un système doté de contrôles à la saisie.
La qualité des données à la saisie
L'autre moitié du problème, c'est ce qui entre réellement dans le système de référence lui-même. Il existe sur ce point une mesure obtenue par une méthode inhabituelle — et pour cette raison même convaincante.
Seules 3 % des organisations ont obtenu un score acceptable en matière de qualité des données, et 47 % des enregistrements nouvellement créés contenaient au moins une erreur critique.
L'échantillon est réduit — 75 organisations — et les données ont été collectées par les participants eux-mêmes, ce qui crée un vrai risque de biais ; il s'agit d'une chronique dans une revue économique, pas d'une publication évaluée par des pairs. Ce qui a de la valeur, c'est la méthode : vérifier à la main cent enregistrements consécutifs peut se répéter dans n'importe quelle entreprise en une journée et donne un chiffre exploitable immédiatement. Je recommande de commencer par là plutôt que par une discussion d'architecture.
Pourquoi une entreprise finit par avoir plusieurs systèmes de référence
L'idée d'un système unique se heurte à la réalité du paysage applicatif de l'entreprise, et cette réalité a été mesurée.
Le nombre moyen d'applications utilisées par une organisation a atteint 101 — dépassant pour la première fois la centaine.
Il s'agit de la télémétrie de la base de clients d'un seul fournisseur de gestion des accès, non d'un échantillon aléatoire d'entreprises, et l'indicateur est calculé au niveau de l'organisation, pas de l'individu. La conclusion pratique reste néanmoins directe : il n'y aura pas de système de référence unique. L'objectif réaliste n'est pas « un seul outil pour tout », mais une décision explicite sur le système qui fait foi pour chaque classe de faits, assortie d'une interdiction de dupliquer cette classe ailleurs.
Un effet secondaire de cette fragmentation est le changement de contexte entre applications. Il convient ici d'être précis : les données expérimentales sont moins tranchées qu'on ne le pense généralement.
Dans une expérience contrôlée, les interruptions n'ont pas ralenti l'exécution des tâches : les participants ont même terminé plus vite (20,3 à 20,6 minutes contre 22,8 dans la condition de référence). Mais cette rapidité s'est obtenue au prix d'un stress, d'une frustration et d'un sentiment d'urgence significativement plus élevés.
C'est un dispositif de laboratoire avec un échantillon d'étudiants et une tâche artificielle — on ne peut pas le transposer tel quel à des heures de travail en entreprise. Mais le résultat est précisément utile parce qu'il contredit l'intuition : le coût de la fragmentation ne s'exprime pas en minutes perdues visibles dans un rapport, mais dans une charge qui n'apparaît dans aucun rapport. C'est la même catégorie de défauts sans observateur que j'ai décrite par ailleurs.
Comment désigner le système de référence
La deuxième étape suscite en général un débat, et ce débat est utile : on découvre que deux systèmes revendiquent la même classe de faits et que personne n'avait encore tranché lequel fait autorité. La décision se prend une fois et coûte moins cher que n'importe quelle intégration.
La quatrième étape s'applique littéralement aux scénarios d'IA. Un assistant qui répond dans une fenêtre séparée et n'écrit son résultat nulle part augmente le nombre d'endroits où la vérité est stockée, il ne le réduit pas. La question « où atterrit le résultat » mérite d'être posée avant la question « la réponse est-elle bonne ».
Quatre vérifications réalisables en une journée
Prenez les cent derniers enregistrements
Vérifiez-les à la main pour repérer les erreurs manifestes : champs obligatoires vides, contradictions, doublons. La part de défauts constitue votre point de départ.
Repérez les tableurs fantômes
Demandez où se trouve la « bonne » version des données. Chaque tableur cité désigne une classe de faits sans système de référence.
Désignez un système qui fait foi pour chaque classe
Affaire, document, paiement, demande, tiers. Un seul endroit par classe, décision consignée par écrit.
Vérifiez que chaque processus arrive à destination
Repérez où le résultat finit par atterrir. Si la réponse est « dans les échanges d'e-mails » ou « chez la personne qui a fait le travail », le processus n'est pas terminé.
Si, à la question « où trouver la vraie version », on répond par le nom d'une personne plutôt que par le nom d'un système, l'automatisation de ce processus n'a pas encore commencé.
Questions fréquentes
Qu'est-ce qu'un système de référence, en termes simples ?
C'est le système où l'entreprise conserve la version qui fait foi d'un fait : une affaire, un document, un paiement, une demande. Le critère est simple : si deux sources divergent, celle désignée comme système de référence a raison, l'autre est considérée comme une copie. Sans cette désignation, l'écart se transforme en désaccord entre services, sans aucun moyen de le trancher.
Un tableur peut-il servir de système de référence ?
Pour un faible volume et un seul utilisateur, oui, à condition que ce soit une décision prise consciemment et consignée par écrit. Le problème survient quand le tableur devient un système de référence de facto : il n'a ni droits d'accès, ni historique des modifications, ni contrôles à la saisie, et les audits de terrain montrent une part de fichiers erronés qui se compte en dizaines de pour cent. Ce qui est dangereux, ce n'est pas le tableur, c'est son statut non défini.
Que faire s'il existe plusieurs systèmes et qu'ils sont tous nécessaires ?
Distinguez non pas les systèmes, mais les classes de faits. L'affaire peut avoir un système qui fait foi, le paiement un autre, le document un troisième — c'est normal. Ce qui ne l'est pas, c'est qu'une même classe vive à deux endroits mis à jour manuellement tous les deux : l'écart devient alors inévitable, et il se découvre au moment du rapprochement, c'est-à-dire le plus tard possible.
Où un assistant IA doit-il écrire son résultat ?
Dans le même système où vit déjà la classe de faits correspondante, et au moment même où le résultat est produit — pas selon la décision de l'utilisateur. Un assistant dont le résultat doit être recopié à la main ajoute un lieu de stockage de la vérité supplémentaire et un point de rupture de plus. Le critère pratique de maturité d'un scénario : le résultat est visible par un collègue qui n'a pas participé à la demande.
La mécanique consistant à attacher automatiquement le document terminé à la fiche de l'affaire, puis à l'envoyer depuis cette fiche, provient de la description du produit maison Alego.Digital, un générateur de propositions commerciales ; l'entreprise utilisait Megaplan comme système de référence. Les intégrations du module de vérification des tiers avec plusieurs CRM (Megaplan, Bitrix24, 1C, amoCRM) proviennent de la description d'un second produit maison de la même période. Il s'agit de documents internes à l'entreprise de l'auteur ; ils n'ont pas été vérifiés par un tiers indépendant et sont présentés ici pour illustrer la mécanique. La classification en quatre lieux de stockage de la vérité est une généralisation propre à l'auteur, issue de sa pratique.
- Panko R. R. What We Know About Spreadsheet Errors. EuSpRIG, 2000 ; arXiv:0802.3457, 2008. arxiv.org
- Nagle T., Redman T. C., Sammon D. Only 3% of Companies' Data Meets Basic Quality Standards. Harvard Business Review, septembre 2017. hbr.org
- Okta. Businesses at Work 2025, mars 2025. okta.com
- Mark G., Gudith D., Klocke U. The Cost of Interrupted Work: More Speed and Stress. CHI 2008. ics.uci.edu