Une entreprise nous a récemment demandé de déployer un agent capable de relancer automatiquement les factures impayées. Sur le papier, un cas d'usage simple. En pratique, le premier test a envoyé trois relances à des clients qui avaient déjà réglé, et une mise en demeure à un compte fermé depuis huit mois. L'agent fonctionnait parfaitement. Ce sont les données qui mentaient.
C'est le point aveugle de la plupart des projets d'automatisation : on concentre l'attention sur l'agent, son modèle, ses capacités de raisonnement. Mais un agent IA ne fait qu'agir sur ce qu'on lui donne à lire. Si vos données sont fausses, il prendra des décisions fausses — plus vite, à plus grande échelle, et avec l'apparence de la fiabilité.
Ce qui était invisible devient soudain très visible
Tant qu'un humain traite les dossiers un par un, il compense en silence les défauts de vos données. Il devine qu'un client apparaît deux fois, il rappelle qu'un champ « date de résiliation » vide ne veut pas forcément dire « contrat actif », il sait qu'une adresse au format bizarre est en réalité correcte. Cette intelligence de rattrapage est partout, et elle est totalement invisible dans vos process.
Un agent, lui, ne rattrape rien. Il applique la règle. C'est précisément pour cela que l'automatisation agit comme un révélateur brutal de la qualité de vos données. Les défauts qui restaient dormants deviennent, du jour au lendemain, des erreurs de production.
Les coupables sont presque toujours les mêmes :
- Les doublons : un même client, fournisseur ou produit présent plusieurs fois, avec des variations d'orthographe ou d'identifiant.
- Les champs vides : une information manquante que l'agent interprète comme une absence de contrainte, alors qu'elle signifie « données inconnues ».
- Les formats incohérents : des dates en JJ/MM/AAAA et en AAAA-MM-JJ dans la même table, des montants avec ou sans devise, des références saisies à la main.
- Les données obsolètes : des statuts jamais mis à jour, des contacts qui ont changé de poste, des tarifs périmés.
Aucun de ces problèmes n'est spectaculaire pris isolément. Ensemble, ils suffisent à rendre un agent inexploitable.
On ne peut pas automatiser le chaos
Il faut le dire clairement : déployer un agent sur des données non maîtrisées, ce n'est pas gagner du temps, c'est industrialiser l'erreur. L'automatisation n'améliore pas la qualité de vos données, elle en amplifie les conséquences.
D'où une règle simple : l'audit de la qualité des données doit précéder tout déploiement. Pas comme une formalité, mais comme une étape de diagnostic à part entière. Concrètement, cet audit consiste à répondre à quelques questions précises pour chaque source de données concernée par le cas d'usage :
- Quel est le taux de champs vides sur les données critiques ?
- Combien de doublons, et selon quels critères de dédoublonnage ?
- Les formats sont-ils normalisés, ou faut-il prévoir une couche de nettoyage ?
- Quelle est la fraîcheur réelle des données : quand ont-elles été mises à jour pour la dernière fois ?
- Qui est responsable de leur mise à jour, et selon quel processus ?
Cette dernière question est décisive. Une donnée n'est jamais fiable dans l'absolu : elle est fiable parce qu'un processus la maintient à jour. C'est pourquoi l'audit des données et la cartographie des processus sont indissociables.
Pourquoi l'audit des données passe par la cartographie des processus
Une donnée obsolète est presque toujours le symptôme d'un processus défaillant. Si le champ « statut du contrat » n'est jamais fiable, ce n'est pas un problème technique : c'est que personne, à aucun moment du parcours, n'a la responsabilité claire de le mettre à jour.
Auditer les données sans cartographier les processus revient à traiter les symptômes sans comprendre la maladie. Vous nettoierez une base une fois, elle se dégradera à nouveau en quelques mois. À l'inverse, cartographier le processus permet de comprendre où la donnée est créée, par qui, quand elle devrait être mise à jour, et pourquoi elle ne l'est pas.
C'est ce travail qui transforme une organisation opaque en organisation requêtable : un système où chaque donnée a une origine identifiée, un responsable, une règle de mise à jour. C'est cette fondation, et non la sophistication de l'agent, qui détermine la réussite d'un projet.
Un exemple concret
Reprenons notre agent de relance de factures. L'audit préalable a révélé trois choses. D'abord, la base clients contenait 6 % de doublons, hérités de deux imports successifs jamais fusionnés. Ensuite, le statut « payé » n'était pas mis à jour en temps réel : il dépendait d'un rapprochement bancaire fait manuellement une fois par semaine. Enfin, aucun processus ne clôturait les comptes des clients partis.
La solution n'a pas été de brancher l'agent plus intelligemment. Elle a été de fusionner les doublons, d'automatiser le rapprochement bancaire quotidien, et d'ajouter une étape de clôture des comptes dans le processus de résiliation. Une fois ces fondations posées, l'agent a fonctionné sans erreur. Le vrai projet n'était pas l'agent : c'était de rendre les données fiables et le processus lisible.
Ce qu'il faut retenir
La qualité des données est le carburant invisible de vos agents. Invisible tant que tout va bien, mais responsable de la quasi-totalité des échecs quand ça dérape. Avant d'investir dans l'IA, investissez dans le diagnostic : auditez vos données, cartographiez les processus qui les produisent, et identifiez les responsables de leur mise à jour. C'est moins spectaculaire qu'un agent, mais c'est ce qui décide de tout.
Chez Lynakor, nous commençons toujours par un audit conjoint de vos données et de vos processus, avant toute mise en production d'agents. Vous voulez savoir si vos données sont prêtes à supporter l'automatisation ? Contactez-nous pour un diagnostic de fiabilité.