Le comité de pilotage a vu la démonstration, elle marchait. Six mois plus tard, rien n'est en service. Le réflexe consiste à incriminer le modèle ou la conduite du changement. Les causes réelles sont ailleurs, et elles sont documentées.
Premier mur : votre démonstration n'est pas reproductible
C'est le fait le plus dérangeant du dossier, et il se vérifie en une heure. En septembre 2025, l'équipe de Thinking Machines Lab a lancé mille appels rigoureusement identiques, avec le même prompt et une température à zéro, sur un modèle ouvert. Résultat : quatre-vingts complétions différentes, la plus fréquente n'apparaissant que soixante-dix-huit fois.
Le détail rend la chose plus troublante encore. Les mille sorties sont identiques jusqu'au cent-deuxième mot-jeton, puis divergent au cent-troisième. Neuf cent quatre-vingt-douze écrivent « Queens, New York », huit écrivent « New York City ».
La cause ne se trouve pas dans le code appelant. Elle tient à la façon dont les calculs sont regroupés côté serveur : la taille des lots varie selon la charge, et les noyaux de calcul ne donnent pas exactement le même résultat selon cette taille. Avec des noyaux conçus pour être insensibles au lot, les mille sorties redeviennent identiques.
Deuxième mur : la régularité, pas la moyenne
Un pilote se juge presque toujours sur un taux de réussite moyen. C'est la mauvaise grandeur.
Le banc d'essai τ-bench, publié en juin 2024, évalue des agents sur des tâches de service client. Son résumé est explicite : même les meilleurs agents de l'époque réussissaient moins de la moitié des tâches, et surtout se montraient irréguliers, avec un taux de réussite sur huit tentatives consécutives inférieur à 25 % dans le domaine du commerce de détail.
L'écart entre ces deux nombres est tout le sujet. Un agent qui réussit une fois sur deux en moyenne, mais rarement huit fois d'affilée, produit une expérience client inacceptable alors que son tableau de bord paraît honorable.
Une publication de Princeton parue en juin 2026, portant sur quinze modèles et douze métriques de fiabilité, apporte la conclusion qui ferme le débat : les gains récents de capacité n'ont produit que de faibles améliorations de fiabilité. Attendre le prochain modèle ne fera pas passer votre pilote en production.
Un travail publié en mai 2026 ajoute une mise en garde sur la mesure elle-même : les scores de fin de tâche menacent la crédibilité de l'évaluation, et l'analyse des journaux d'exécution est nécessaire. Les auteurs relèvent que sur un domaine de τ-bench, la performance réelle était sous-estimée de près de moitié faute d'examiner ce que l'agent avait fait.
Troisième mur : l'intégration est un chantier d'identités
Un POC tourne avec une clé d'API dans une variable d'environnement. Un système en production doit savoir qui demande quoi, au nom de qui, avec quels droits.
L'exemple du protocole MCP, qui sert à connecter un modèle aux outils de l'entreprise, montre l'ampleur de la marche. Dans sa spécification, un serveur exposé en HTTP qui implémente l'autorisation doit s'appuyer sur OAuth 2.1, publier ses métadonnées de ressource protégée, recevoir du client un paramètre identifiant la ressource visée, et vérifier que le jeton présenté a bien été émis pour lui. La spécification écrit qu'un serveur ne doit accepter ni transmettre aucun autre jeton.
C'est un chantier de gestion des identités et des accès, mené par des équipes qui n'étaient pas dans la salle pendant la démonstration. Il ne s'improvise pas en fin de projet.
Cette disproportion entre le modèle et son environnement est un classique de l'ingénierie logicielle. Un article de recherche publié en 2015 par des ingénieurs de Google, devenu une référence sur la dette technique des systèmes d'apprentissage, avance qu'un système arrivé à maturité peut n'être composé que d'une faible part de code d'apprentissage, l'essentiel étant du code de liaison. Les auteurs y formulent aussi un principe utile à retenir avant de toucher à un système en service : changer quoi que ce soit change tout.
Quatrième mur : le coût d'exploitation bouge sans vous
Un pilote consomme peu, donc personne ne regarde la facture. En production, trois mécanismes la déplacent sans qu'une ligne de code ne change.
- Le tarif du fournisseur. Le modèle Claude Sonnet 5 est facturé 2 et 10 dollars par million de tokens jusqu'au 31 août 2026 inclus, et passe à 3 et 15 dollars le 1er septembre. Une hausse de moitié, à volume identique.
- Le découpage du texte. Le tokeniseur introduit avec les modèles récents d'Anthropic découpe le même texte en davantage d'unités facturables, avec environ 30 % de plus documenté pour Sonnet 5 par rapport à la génération précédente. Le même prompt coûte plus cher.
- La mise en cache. Le seuil minimal pour qu'un contexte soit mis en cache diffère selon le modèle, de 512 à 4 096 tokens, et il n'évolue pas dans le même sens d'une génération à l'autre. L'échec est silencieux : aucune erreur, seulement un compteur qui reste à zéro et une facture qui ne baisse pas.
S'ajoute le cycle de vie des modèles. Anthropic s'engage sur un préavis d'au moins soixante jours avant le retrait d'un modèle, et cinq modèles ont été retirés entre février et juin 2026. Les requêtes vers un modèle retiré échouent. Un système en production doit donc prévoir son changement de modèle comme une opération de maintenance ordinaire, avec la campagne d'évaluation qui va avec.
Cinquième mur : l'outil est livré et personne ne s'en sert
Le chiffre le plus parlant vient d'une source publique et représentative. Un document de travail du bureau du recensement américain, publié en avril 2026 sur des données collectées entre novembre 2025 et janvier 2026, relève que 19 % des entreprises déclarant un usage formel de l'IA ne montrent aucune trace d'usage par leurs salariés dans leurs tâches. Les auteurs parlent d'une approche descendante confrontée à des délais de mise en œuvre.
Côté français, l'Insee a publié le 21 juillet 2026 des données qui désignent précisément le blocage. Chez les entreprises qui utilisent déjà l'IA, le premier frein à l'extension de l'usage est le manque d'expertise, cité par 53 % d'entre elles, devant les données à 43 % et le cadre juridique à 42 %. Chez les entreprises de 250 salariés et plus qui n'utilisent pas encore l'IA, le manque d'expertise monte à 73 %.
Le point de blocage n'est donc pas la décision d'adopter. C'est la capacité à exploiter ce qui a été livré. Un pilote qui ne prévoit ni propriétaire métier, ni montée en compétence, ni budget de maintien en condition opérationnelle prépare son propre abandon.
Les critères de sortie existent depuis 2017
Une équipe de Google a publié en 2017 un barème de préparation à la production pour les systèmes d'apprentissage automatique. Il comporte vingt-huit tests répartis en quatre sections : données, modèle, infrastructure, surveillance.
Sa mécanique de notation est ce qui le rend utile. Un test vaut un demi-point s'il est exécuté manuellement avec des résultats documentés et diffusés, un point entier s'il existe un dispositif pour l'exécuter automatiquement de façon répétée. Le score final est le minimum des quatre sections, et non leur moyenne, les auteurs jugeant les quatre également importantes.
L'interprétation du score zéro est écrite noir sur blanc : il s'agit davantage d'un projet de recherche que d'un système industrialisé. C'est exactement la note qu'obtient un POC, et c'est le diagnostic dont un comité de pilotage a besoin.
| À écrire avant de lancer le pilote | Ce que ça évite |
|---|---|
| La distribution de résultats attendue, pas un exemple réussi | Valider un tirage plutôt qu'un système |
| Le taux de réussite sur N tentatives consécutives, pas la moyenne | Livrer un agent irrégulier au client final |
| Le mode d'authentification et les droits, validés par l'équipe sécurité | Découvrir le chantier des identités en fin de projet |
| Le coût par transaction à volume cible, et qui le surveille | Une facture qui dérive sans alerte |
| Le propriétaire métier nommé et son temps alloué | Un outil livré que personne ne fait vivre |
| La procédure de changement de modèle et son budget d'évaluation | Une panne au retrait d'un modèle |
Reprendre un pilote qui n'aboutit pas
Une reprise commence par une mesure, pas par un choix d'outil. Rejouer le cas d'usage sur une centaine d'exécutions donne la distribution réelle et le taux de réussite consécutive. Cette seule mesure réoriente la plupart des projets, parce qu'elle remplace une impression par un chiffre.
Vient ensuite l'inventaire de ce qui manque autour du modèle : authentification, journalisation, évaluation continue, propriétaire, budget de fonctionnement. C'est là que se trouve le travail restant, et il est rarement là où le comité de pilotage l'attend.
Un pilote qui échoue n'a pas prouvé que l'IA ne marche pas chez vous. Il a prouvé qu'un système d'IA se juge sur sa régularité, son exploitation et son adoption, et qu'aucun des trois ne se démontre en réunion.
- 01Premier mur : votre démonstration n'est pas reproductible
- 02Deuxième mur : la régularité, pas la moyenne
- 03Troisième mur : l'intégration est un chantier d'identités
- 04Quatrième mur : le coût d'exploitation bouge sans vous
- 05Cinquième mur : l'outil est livré et personne ne s'en sert
- 06Les critères de sortie existent depuis 2017
- 07Reprendre un pilote qui n'aboutit pas
Questions fréquentes
