Les raisons de l'échec de 90 % des projets d'IA : la dette des invites, la dette de récupération, la dette d'évaluation entravent la mise en œuvre des entreprises

En 2025, 42 % des entreprises ont arrêté plusieurs projets d'IA, soit plus du double des 17 % de l'année précédente.
Le problème ne réside pas dans l'insuffisance de la puissance des modèles, mais dans une nouvelle forme de dette technologique qui s'accumule silencieusement dans l'infrastructure IA des entreprises, notamment la dette liée aux invites, la dette de récupération, la dette d'évaluation.
(Précédemment : Qu'est-ce que l'ingénierie Harness ? Décomposer les 7 modules principaux pour la mise en œuvre concrète d'un agent IA (Ingénierie de pilotage IA))
(Contexte supplémentaire : GPT-5.5 Instant est désormais accessible à tous les utilisateurs, OpenAI vous apprend à rédiger des prompts plus intelligents et efficaces)

Sommaire de cet article

Toggle

• Trois nouvelles formes de dette, plus difficiles à repérer que les bugs
• Les lacunes invisibles de la surveillance
• La solution ne réside pas dans le modèle, mais dans la conception du système

En 2025, 42 %, c'est la proportion d'entreprises ayant arrêté plusieurs projets d'IA, soit une augmentation d'une fois et demie par rapport à l'année précédente.
Les données de S&P Global Market Intelligence indiquent que l'échec de l'IA n'est pas un phénomène isolé, mais un problème systémique.
Une étude du MIT la même année souligne que 95 % des pilotes IA ne passent jamais en production ou ne génèrent pas de valeur commerciale quantifiable.

Ces échecs sont souvent imputés à un manque de capacité des modèles, à une mauvaise qualité des données ou à un ROI difficile à justifier.
Mais Vikram, responsable de Cota Capital, pense que la cause réelle est plus insidieuse : une nouvelle forme de dette technologique s'accumule discrètement dans les couches de prompts, de dépendance aux modèles et d'évaluation des systèmes, totalement différente de la dette de code traditionnel, mais tout aussi fatale.

Trois nouvelles formes de dette, plus difficiles à repérer que les bugs

La dette technologique traditionnelle réside dans le code, où les bugs peuvent être reproduits, testés et corrigés.
La dette IA, quant à elle, est fondamentalement différente : elle est distribuée, dispersée à travers les invites, les API de modèles, les pipelines de données et l'infrastructure.

Elle est intermittente, car la nature probabiliste des systèmes IA signifie que des entrées identiques ne garantissent pas des sorties identiques ;
Elle est aussi presque invisible, car le système semble fonctionner normalement jusqu'à ce qu'un moment critique provoque une panne totale.

Dette liée aux invites (Prompt Debt) est la plus évidente des trois.
Elle ne bénéficie pas d'enregistrements temporaires, ni de contrôle de version pour les invites modifiées, et la pratique du « bourrage d'invites » consiste à insérer de nombreuses informations non pertinentes pour faire comprendre davantage au modèle.

Le résultat : les invites deviennent une sorte de code informel, sans typage, sans tests, sans gestion de version.
Chaque ajustement est effectué sur un système opaque, et à force d'accumulation, la vulnérabilité du système croît exponentiellement.

Dette de dépendance au modèle (Model Dependency Debt) provient d'une forte dépendance des entreprises à des API de modèles externes.
Les applications s'appuient sur des appels à ces modèles, mais leur mise à jour n'est pas sous contrôle interne.

Lorsque le fournisseur de modèles met à jour silencieusement ses versions, les invites finement ajustées pour l'ancienne version peuvent devenir obsolètes ou produire des comportements imprévisibles.
La reproductibilité disparaît alors.

Dette de récupération (Retrieval Debt) apparaît dans la majorité des déploiements IA utilisant l'architecture RAG.
Le problème : ces bases de données sont souvent encombrées de données désorganisées, de fichiers en double, ou d'informations obsolètes.
Les réponses de l'IA, techniquement correctes à un moment donné, ne le sont plus aujourd'hui.
C'est plus difficile à détecter qu'une hallucination, car cela semble tout à fait raisonnable, même passable lors d'une revue par un testeur lambda.

Les lacunes invisibles de la surveillance

Dette d’évaluation (Evaluation Debt) est la plus sous-estimée des quatre nouvelles formes de dette IA.
Les benchmarks actuels se concentrent sur des évaluations ponctuelles et étroites, ne reflétant pas la performance réelle après déploiement.
La majorité des entreprises manquent de standards de test cohérents, de jeux de données de référence, ou de mécanismes de surveillance en temps réel des modèles déployés.

Comparé aux processus CI/CD (Intégration Continue / Livraison Continue) bien établis dans le développement logiciel, le domaine de l'IA ne dispose pas encore d'un mécanisme équivalent de « intégration continue des invites ».

En termes simples : un ingénieur peut fusionner du code avec des tests automatisés pour détecter les erreurs,
mais lorsqu'une invite est modifiée, aucun système ne peut alerter en temps réel.
Conséquence : les CIO et CTO manquent de visibilité sur la performance réelle du modèle, et ne peuvent pas suivre l'évolution de ses performances.

Ces quatre nouvelles formes de dette s'ajoutent à la dette technique de code, accélérant leur accumulation combinée.
Et pour aggraver la situation, la propriété des systèmes IA est dispersée : équipes d'ingénierie, produit, données et métier détiennent chacune une partie, rendant la responsabilité souvent floue en cas de problème.

La solution ne réside pas dans le modèle, mais dans la conception du système

Augmenter la puissance des modèles ne résoudra pas ce problème.
Vikram affirme directement : le taux d’échec élevé n’est pas lié à la précision des modèles, mais à la conception du système, à l’intégration et à la culture organisationnelle.

Plus concrètement, les invites doivent être traitées comme du code, avec gestion de version, documentation, et tests rigoureux avant et après déploiement pour toutes les configurations possibles.

Les mécanismes d’évaluation doivent être intégrés à toute la pile d’infrastructure IA, avec des pipelines d’évaluation continue, intégrant à la fois des indicateurs techniques et commerciaux, et en connectant la observabilité IA pour surveiller la qualité des sorties, le taux d’échec, le drift du modèle et des données.

De plus, tous les résultats IA doivent inclure une explication interprétable, avec une traçabilité claire des sources de données, des modèles utilisés, et des étapes d’exécution, pour assurer l’auditabilité et permettre une correction rapide en cas d’erreur systémique.

Cela nécessite, comme pour la sécurité ou la modernisation cloud, la mise en place d’un plan clair de réduction de la dette IA, avec un budget dédié, piloté personnellement par des dirigeants de niveau CXO.

Après tout ce discours, vous comprenez probablement : 95 % des échecs ne viennent pas d’un IA insuffisamment intelligente.
Mais de la manière dont on construit ces systèmes, qui reste encore trop souvent une boîte noire, plutôt qu’un système complexe à ingénierie rigoureuse.
La dette technologique ne disparaît jamais d’elle-même, elle ne fait que s’accumuler à un taux d’intérêt plus élevé, prête à être remboursée à un moment donné.