Pourquoi vos automatisations IA échouent sur les vraies données

Pourquoi une automatisation IA qui marche en démo échoue sur vos vraies données

Réponse directe : une automatisation IA échoue le plus souvent parce que les données réelles de l’entreprise (PDF scannés, tableurs bricolés, champs libres, doublons) ne ressemblent pas aux exemples propres utilisés pour la démonstration. Le modèle est rarement le problème ; la couche qui lui prépare l’information l’est presque toujours.

Le scénario est classique. Un flux d’extraction de factures fournisseurs ou de tri de demandes clients fonctionne sur vingt documents choisis à la main, puis se dégrade dès la première semaine d’usage réel. Cet article détaille les points de rupture, la manière de les diagnostiquer et les corrections qui comptent. Il complète notre article sur ce qui casse en premier quand un agent IA passe en production, qui traite l’orchestration ; ici, on s’arrête aux données.

Ce que disent les chiffres publiés

Deux données reviennent dans la littérature sur le sujet. Gartner estime que 57 % des organisations jugent leurs données inadaptées à l’IA, et prévoit que 60 % des projets d’IA qui ne reposent pas sur des données prêtes pour l’IA seront abandonnés d’ici 2026 (chiffres relayés par plusieurs éditeurs et consultants, voir les sources en fin d’article). Ce sont des projections de cabinet d’analyse, pas des mesures sur le terrain : prenez-les comme un ordre de grandeur, pas comme une loi.

Côté technique, les analyses de pipelines documentaires convergent sur un point : la majorité des défaillances naissent dans la couche d’extraction (reconnaissance de caractères, ordre de lecture, structure des tableaux), pas dans le modèle de langage. Une erreur d’extraction ne produit pas de message d’erreur : elle produit une réponse fausse, formulée avec aplomb.

Les six points de rupture au contact des vraies données

1. Les documents scannés et la reconnaissance de caractères

Un contrat ou une facture scannés de travers, tamponnés ou photographiés au téléphone dégradent la reconnaissance de caractères. Un « 1 » lu comme un « l », une virgule décimale perdue : le modèle reçoit un texte déjà faux et ne peut pas le deviner.

2. Les tableaux dont la structure se perd

Dans une facture, le sens d’un chiffre dépend de sa position : colonne, ligne, total partiel. Un modèle de langage lit du texte ; si l’extraction décale une colonne d’un cran, le résultat reste plausible et fausse pourtant tous les calculs en aval. C’est la défaillance silencieuse par excellence.

3. Les champs libres et les formats incohérents

Dates écrites de trois façons, montants avec ou sans séparateur de milliers, « CHF », « Fr. » ou rien. Dans une PME, le même fournisseur apparaît souvent sous trois noms différents dans le CRM, l’outil comptable et le tableur de suivi.

4. Les doublons et les sources qui se contredisent

Quand deux systèmes donnent deux adresses ou deux prix pour le même client, l’automatisation choisit sans le dire. Elle ne signale pas le conflit, elle l’absorbe.

5. Le contexte qui n’existe que dans la tête des collaborateurs

« Ce client paie toujours à 45 jours », « cette ligne se code en charges de période ». Ces règles ne figurent dans aucun document. L’automatisation ne les connaît pas et le jeu d’exemples de la démo ne les contenait pas.

6. Les cas rares qui arrivent quand même

Notes de crédit, factures en monnaie étrangère, documents multipages, pièces jointes dans le mauvais ordre. Sur vingt exemples, ils n’apparaissent pas ; sur deux mille, ils représentent un volume que quelqu’un devra traiter à la main.

Diagnostiquer : le modèle ou les données ?

Avant de changer de modèle, séparez les deux couches. La méthode tient en quatre gestes :

1. Prélevez cinquante cas réels sur le dernier mois, y compris les moches, sans les trier.
2. Relisez, pour chacun, ce que le modèle a reçu en entrée (le texte extrait), pas seulement ce qu’il a répondu.
3. Classez chaque erreur : entrée fausse, entrée correcte mais mal interprétée, règle métier manquante.
4. Comptez. Si la majorité des erreurs vient d’une entrée fausse, un meilleur modèle ne changera presque rien.

Ce tri rejoint la logique de l’évaluation avant la démo : le jeu de test doit contenir les documents que vous redoutez, pas ceux qui rassurent.

Tableau : symptôme, cause probable, correction

Les corrections qui comptent, dans l’ordre

• Valider avant d’agir. Chaque sortie passe par des contrôles déterministes (totaux, formats, plages de valeurs) avant d’écrire dans un système.
• Prévoir une sortie « je ne sais pas ». Une automatisation qui ne peut jamais s’abstenir invente. Une file de revue humaine pour les cas incertains coûte moins cher qu’une erreur comptable découverte à la clôture.
• Normaliser en amont. Un référentiel unique des fournisseurs, clients et articles vaut plus que n’importe quelle invite bien rédigée.
• Journaliser l’entrée, pas seulement la sortie. Sans le texte extrait conservé, impossible de savoir a posteriori où l’erreur est née.
• Mesurer sur un échantillon mensuel. Les données dérivent : un nouveau fournisseur, un nouveau gabarit de facture, et la précision baisse sans bruit.

Exemple illustratif : le tri de factures fournisseurs

Prenons un cas fictif, mais représentatif : une fiduciaire reçoit environ deux mille factures par mois, dont une partie en PDF natifs et le reste en scans. L’automatisation lit chaque facture, propose le compte de charge et prépare l’écriture. Sur un échantillon de démonstration de vingt PDF natifs, tout passe.

En production, trois choses se produisent. Les scans de mauvaise qualité produisent des montants lus de travers. Les factures multipages perdent leur total, qui figure sur la dernière page. Les fournisseurs étrangers utilisent un autre format de date. Aucun de ces cas n’est exotique ; chacun est absent de l’échantillon de départ.

La correction ne passe pas par un modèle plus puissant. Elle passe par trois mécanismes simples : un contrôle « somme des lignes égale total » qui renvoie en revue toute facture incohérente, un format de date imposé avec rejet des cas ambigus, et un indicateur de qualité du scan qui dirige les documents illisibles vers un humain dès l’entrée. Le gain vient de la discipline du pipeline, pas de l’intelligence du modèle.

Construire la file de revue humaine sans la transformer en goulot

La revue humaine n’a de sens que si elle reste légère. Trois règles aident. Premièrement, n’envoyez en revue que les cas sous un seuil de confiance ou en échec de contrôle, jamais un échantillon au hasard à titre de précaution générale. Deuxièmement, montrez au relecteur le document source à côté de la proposition, avec les champs douteux surlignés : sans cela, la relecture prend plus de temps que la saisie manuelle. Troisièmement, utilisez chaque correction humaine comme donnée : une même correction répétée dix fois est une règle manquante qu’il faut écrire.

Quand ce n’est pas le bon chantier

Si le volume est de quelques dizaines de documents par mois, l’automatisation ne se rentabilisera probablement pas : le temps passé à préparer les données dépasse le temps économisé. Même verdict si le processus lui-même n’est pas stabilisé : automatiser une règle que personne n’a écrite fige un flou. Dans ces cas, mieux vaut d’abord clarifier le processus, éventuellement avec un simple tableur partagé, puis revenir à l’automatisation. Pour un autre angle sur les arbitrages de coûts, voir le coût réel d’une fonctionnalité IA en production.

Ce que cela change pour une PME romande

Les documents d’une fiduciaire, d’une agence immobilière ou d’une clinique privée cumulent souvent les facteurs ci-dessus : scans, formats multilingues français, allemand, italien, monnaies et conventions de nommage propres à chaque client. Le critère de choix d’un prestataire n’est donc pas le modèle annoncé, mais sa capacité à travailler sur un échantillon de vos documents réels avant tout engagement. C’est la logique du forward deployed engineer, présent dans vos données plutôt qu’en présentation. Pour savoir comment nous cadrons ce travail, consultez nos formules et nos prix.

À retenir

• La plupart des automatisations IA échouent en amont du modèle, sur l’extraction et la qualité des données.
• Une défaillance d’extraction est silencieuse : la réponse paraît plausible.
• Testez sur cinquante cas réels non triés, et relisez l’entrée autant que la sortie.
• Validez par des contrôles déterministes et prévoyez une revue humaine pour les cas incertains.
• Sous quelques dizaines de documents par mois, l’automatisation n’est pas forcément rentable.