Pourquoi les projets IA échouent : les 7 erreurs que je retrouve en audit

Pourquoi un POC IA qui fonctionne ne passe pas en production

Le scénario est toujours le même. Une démonstration convaincante, un budget débloqué, une équipe motivée. Six mois plus tard, le système IA (AI system) répond correctement deux fois sur trois, les utilisateurs ont cessé de l'ouvrir, et chaque sprint propose un nouveau modèle ou un nouveau framework. Rien ne s'améliore de façon mesurable.

La raison est structurelle. L'IA en production est un métier jeune. La plupart des décisions d'architecture sont prises sans référentiel, par des ingénieurs qui n'ont jamais vu ce type de système fonctionner correctement. Personne dans l'équipe ne sait à quoi « bien » ressemble, donc personne ne sait ce qui manque.

Lisez ce guide avec votre propre système en tête. Chaque erreur est présentée avec son symptôme (la phrase que j'entends au premier appel), sa cause et sa correction. Les sept erreurs reprennent les constats du livre blanc que j'ai publié après une année d'audits ; elles s'appliquent aux assistants documentaires (RAG), aux agents IA, aux chaînes d'extraction et aux automatisations avec modèle de langage.

Erreur 1 : aucun jeu de test ni métrique, vous développez à l'aveugle

Le symptôme

« On a changé le modèle d'embeddings, les résultats ont l'air meilleurs. » L'air meilleurs, ou mesurés meilleurs ? Dans la majorité des systèmes que j'audite, il n'existe aucun cadre d'évaluation. L'équipe modifie un paramètre, teste à la main sur trois requêtes, déploie. Chaque sprint est un coup de dés.

La cause

Construire un jeu de test demande du temps métier : il faut collecter des questions réelles, écrire les réponses attendues, décider ce qu'est une bonne réponse. Ce travail est repoussé au profit de l'essai d'un nouveau modèle. Résultat : des régressions silencieuses, des semaines d'itérations perdues et des décisions prises à l'intuition.

La correction

• Un jeu de données représentatif : de l'ordre de 100 à 300 cas réels, couvrant les questions fréquentes, les cas limites et les cas où le système doit s'abstenir.
• Des métriques alignées sur le métier : taux de bonnes réponses, précision du retrieval, taux d'escalade, et non un score générique.
• Une évaluation automatisée qui tourne à chaque changement, comme des tests sur du code.

C'est la première brique, et c'est pour cette raison que l'Audit IA commence par la construction de ce jeu de test et vous le remet à la fin : chaque modification future pourra être mesurée avant et après.

Erreur 2 : changer de modèle au lieu de corriger les données

Le symptôme

Trois modèles essayés en trois mois, même plafond de qualité. L'équipe attend le prochain modèle comme une délivrance.

La cause

Le problème est en amont, dans ce que le modèle reçoit. Une extraction pauvre (OCR brut sans analyse de mise en page, tableaux écrasés en lignes illisibles, en-têtes et pieds de page mélangés au texte), des documents en double, des versions obsolètes jamais retirées, des métadonnées absentes. Tout ce bruit se propage dans le découpage, les embeddings et le retrieval. Le modèle hallucine à cause de l'entrée qu'il reçoit, et l'équipe passe des heures à déboguer le modèle alors que le défaut est dans l'ingestion.

La correction

• Une chaîne d'extraction adaptée à vos types de documents : segmentation de page, extraction de tableaux dédiée, nettoyage des artefacts, validation de la qualité avant indexation.
• Un inventaire des sources : ce qui entre, qui en est responsable, à quelle fréquence c'est mis à jour.
• Un contrôle qualité sur un échantillon de documents extraits, relu par un humain, avant toute discussion sur le modèle.

Le texte qui entre dans votre système doit être propre. Chez Lokimo, l'extraction de règles d'urbanisme depuis des PLU scannés (10 000 territoires par an) s'est jouée sur cette étape bien plus que sur le choix du modèle. Le guide OCR et IA documentaire détaille la chaîne d'extraction.

Erreur 3 : le retrieval négligé, le modèle répond à côté

Le symptôme

« Le retrieval ramène des résultats, mais rarement les bons. » Le modèle rédige une réponse fluide à partir de passages qui ne contiennent pas l'information demandée.

La cause

Le découpage par défaut : couper le texte tous les X jetons avec un recouvrement, sans tenir compte de la structure du document. Un fragment qui coupe une phrase en deux, qui mélange deux sections ou qui isole un tableau de son contexte produit un vecteur de mauvaise qualité. Ajoutez l'absence de métadonnées (source, date, section) qui empêche tout filtrage, et l'absence de mesure du retrieval indépendamment de la réponse finale. La qualité du retrieval est plafonnée par la qualité du découpage, jamais par le modèle d'embeddings.

La correction

• Un découpage sémantique : par section, par paragraphe, par unité de sens, adapté à la structure de vos documents.
• Des métadonnées sur chaque passage pour filtrer au retrieval (type de document, date, service émetteur).
• Une métrique de retrieval séparée (proportion de bons documents dans les 10 premiers résultats) mesurée sur le jeu de test.
• Une étape de reclassement (reranking) quand les volumes sont élevés.

Chez Delibia, sur 2,7 millions de délibérations, cette refonte a fait passer le retrieval de 53 % à 93 % de bons documents dans le Top 10, et les réponses jugées satisfaisantes de 26 % à 98 %. Le mécanisme complet est expliqué dans le guide RAG expliqué.

Erreur 4 : un prompt qui cumule trois responsabilités

Le symptôme

Mêmes entrées, sorties différentes. L'équipe empile des couches de post-traitement pour rattraper des résultats incohérents, et chaque correctif en casse un autre.

La cause

Un seul prompt qui classe la demande, extrait des informations et rédige la réponse, avec des instructions vagues, sans format de sortie imposé et sans exemples. Le modèle reçoit des consignes ambiguës et produit des résultats variables. Par réflexe, l'équipe confie aussi au modèle des tâches qu'un composant plus simple ferait mieux : détection de langue, classification, extraction d'un numéro de dossier.

La correction

• Une responsabilité par appel : classer, puis extraire, puis rédiger, chaque étape testable séparément.
• Des gabarits de prompt versionnés, avec des variables dynamiques et un format de sortie imposé (schéma JSON).
• Des exemples d'entrée et de sortie intégrés au prompt, sans instructions négatives.
• Le bon outil pour chaque tâche : un classifieur entraîné sur vos données, ou une expression régulière, coûte une fraction d'un appel au modèle et se trompe moins.
• Des tests automatisés sur les prompts, comme sur du code.

Cette décomposition est le premier pas vers un système multi-agents maîtrisé, où chaque agent a un périmètre étroit. C'est aussi ce que je mets en place dans les projets de développement IA sur mesure.

Erreur 5 : aucune supervision en production

Le symptôme

« On a douze étapes dans le système et quand ça casse, on ne sait pas où. » Les utilisateurs signalent un problème par e-mail trois jours après, et personne ne peut retrouver la requête concernée.

La cause

Le système a grandi par accumulation : une étape de reclassement ici, un mécanisme de secours là, une validation ailleurs. Après quelques mois, dix à quinze appels s'enchaînent, chacun pouvant échouer en silence. Rien n'est journalisé de façon structurée, aucune alerte n'existe, et l'équipe découvre les régressions par les plaintes. L'orchestration a été accumulée plutôt que pensée.

La correction

• Une journalisation structurée à chaque étape : entrée, sortie, durée, coût, identifiant de requête pour tracer de bout en bout.
• Des contrats d'interface clairs entre les étapes et des mécanismes de secours explicites, avec la complexité minimale nécessaire.
• Des alertes sur les indicateurs qui comptent : taux d'erreur, temps de réponse, part de réponses « je ne sais pas », coût journalier.
• Une revue hebdomadaire d'un échantillon de conversations réelles, qui alimente le jeu de test.

Chaque étape ajoutée est un point de défaillance potentiel qu'il faut justifier. La supervision est la partie du travail que je maintiens en accompagnement IA : un point hebdomadaire sur les métriques, et des corrections avant que les utilisateurs ne décrochent.

Erreur 6 : des coûts d'inférence non maîtrisés

Le symptôme

« On ne sait pas exactement combien coûte une requête. » La facture cloud grimpe de mois en mois sans corrélation avec l'usage.

La cause

Le système a été lancé avec les choix par défaut : le plus gros modèle disponible pour chaque tâche, embeddings via API, inférence cloud, base vectorielle managée, orchestration sur un cluster géré. Personne n'a calculé le coût unitaire. Des tâches simples (classification, détection de langue, extraction d'entités) passent par un modèle de langage alors qu'un modèle léger ferait mieux pour une fraction du prix.

La correction

• Un coût par requête calculé et décomposé par étape, suivi dans le tableau de bord de supervision.
• Une analyse « construire ou acheter » pour chaque composant : à volume élevé, un serveur dédié avec un modèle ouvert servi en local divise la facture.
• Un modèle de la bonne taille pour chaque tâche, et un cache pour les requêtes répétées.
• Une revue à chaque nouveau modèle : les modèles récents sont souvent plus précis et moins chers que ceux choisis six mois plus tôt.

Le bon réflexe est de calculer avant de dépenser, ni tout cloud ni tout en propre. Le guide IA souveraine et hébergement en France compare les structures de coût des différentes options.

Erreur 7 : une équipe compétente sans expérience de production

Le symptôme

Tout a été essayé, rien ne s'améliore. La démonstration fonctionne, la production casse. Les développeurs sont bons, motivés, et ils tournent en rond.

La cause

Aucune des six erreurs précédentes n'est une erreur de compétence. Ce sont des erreurs de référentiel. Un ingénieur qui a déjà mis un assistant documentaire en production sait, avant d'écrire une ligne, qu'il faut un jeu de test, une chaîne d'extraction propre et une journalisation par étape. Un ingénieur qui le fait pour la première fois l'apprend en plusieurs mois, aux frais de l'entreprise. Recruter ce profil coûte de 13 000 à 15 000 € chargés par mois pour un senior, quand on le trouve.

La correction

• Apporter le référentiel de l'extérieur, le temps que l'équipe l'intègre : un audit qui dit ce qui manque, dans quel ordre le construire, et le prouve sur vos données.
• Faire travailler l'équipe avec quelqu'un qui a déjà déployé ce type de système, en sprint, jusqu'à la mise en production.
• Formaliser le transfert : code documenté, jeu de test, scripts d'évaluation, pour que rien ne dépende du prestataire ensuite.

Le comparatif consultant IA ou recrutement chiffre les deux options. Dans les deux cas, l'objectif est le même : que votre équipe sache à quoi « bien » ressemble.

Par où commencer : trois gestes rapides, puis l'audit

Avant tout chantier, trois vérifications tiennent en moins d'une heure et améliorent souvent un système en place :

1. Le modèle est-il à jour ? Les modèles récents sont en général plus précis et moins chers. Un changement de version, sans refonte, se teste en quelques minutes sur le jeu de test (si vous en avez un ; sinon, revenez à l'erreur 1).
2. Le prompt est-il calibré ? Relisez-le. Instructions précises, répartition entre consigne système et contexte, exemples d'entrée et de sortie, aucune instruction négative.
3. Les paramètres sont-ils explicites ? Température à zéro pour l'extraction et la classification, longueur maximale de réponse définie.

Si vous vous êtes reconnu dans trois erreurs ou plus, ces gestes ne suffiront pas : le problème est architectural. L'Audit IA est conçu pour ce cas. En 3 semaines, je lis votre code et vos données, je construis le jeu de test, je mesure chaque couche, je remets une feuille de route priorisée et une preuve de concept sur vos propres données. Les ordres de grandeur constatés en France pour ce type de diagnostic sont sur la page prix d'un audit IA, et un exemple de rapport sur la page Kolverr. Un appel de 20 minutes suffit pour savoir si votre système relève de l'audit ou d'une correction plus simple.