La plupart des pilotes IA n’échouent pas parce que l’idée était mauvaise. Ils échouent parce que personne n’a construit le dispositif qui permet à un système probabiliste de tourner sans surveillance dans un workflow qui compte. Une démo prouve que le modèle sait faire la tâche une fois. La production prouve qu’il sait la faire dix mille fois sans qu’un humain rattrape chaque erreur.
Nous traitons l’écart entre les deux comme cinq jalons. Chacun répond à une question que quelqu’un finira par poser avant de laisser le système tourner seul, et chacun coûte peu à mettre en place tôt et cher à ajouter après coup. Sautez-en un seul et le pilote s’enlise, le plus souvent non pas côté ingénierie, mais dans la réunion de validation où personne ne sait répondre à la question que ce jalon devait régler.
Les cinq jalons
| Jalon | La question à laquelle il répond | Ce qui se passe quand il manque |
|---|---|---|
| Évaluations | Est-ce assez bon, et ce changement l’a-t-il amélioré ? | Chaque mise en production devient un débat d’impressions |
| Observabilité | Qu’a-t-il fait exactement sur ce cas ? | Vous l’apprenez par un client mécontent |
| Garde-fous | Quel est le pire qu’il puisse faire ? | Il ne passe jamais la revue de sécurité ni la revue juridique |
| Retour arrière | Que fait-on quand le modèle change sans prévenir ? | Une mise à jour du fournisseur le casse en silence |
| Responsable | À qui appartient ce chiffre ? | Un comité l’approuve et personne ne le met en production |
Jalon 1 : un jeu d’évaluations qui mesure ce qui compte pour vous
Un jeu d’évaluations (evals) est un ensemble fixe de cas réels dont le bon résultat est connu, noté automatiquement à chaque changement. Ce n’est ni un contrôle ponctuel ni un est-ce que ce résultat a l’air correct : c’est un chiffre que vous pouvez comparer à celui de la semaine dernière.
Sans lui, la qualité est affaire d’opinion. Chaque retouche de prompt tourne au débat, personne ne peut dire si le changement a aidé, et personne n’accepte de valider une mise en production qu’il ne peut pas mesurer. Ce n’est pas un problème de modèle, c’est l’absence d’instrument de mesure. Vous ne pouvez pas mettre en production ce que vous ne savez pas noter. C’est pourquoi nous plaçons ce jalon avant tous les autres, et pourquoi nous lui avons consacré un article entier (en anglais).
Vous avez franchi ce jalon quand vous pouvez changer de modèle ou réécrire un prompt et savoir en quelques minutes si la qualité a bougé, et dans quel sens.
Jalon 2 : une observabilité qui montre ce que le système a réellement fait
Pas un tableau de bord agrégé. Une analyse exécution par exécution : pour n’importe laquelle, l’entrée, le contexte récupéré, les outils appelés, le résultat renvoyé, le coût et la durée.
Les systèmes probabilistes échouent en silence. Un bug déterministe lève une erreur. Un modèle, lui, renvoie avec assurance quelque chose de légèrement faux, puis continue. Sans traces, ces défaillances restent invisibles jusqu’à ce qu’elles s’accumulent au point d’être remarquées par un humain. C’est ainsi que des équipes découvrent un mois de résultats erronés à l’occasion d’une seule escalade du support.
Vous avez franchi ce jalon quand quelqu’un peut répondre en moins de cinq minutes à la question pourquoi a-t-il fait cela, sur ce cas précis, mardi dernier.
Jalon 3 : des garde-fous qui bornent le pire scénario
Des contraintes explicites sur ce que l’agent peut toucher, ce qu’il peut dépenser, ce qu’il peut dire et le moment où il doit passer la main à une personne. Des limites de périmètre imposées dans le code, pas des consignes dans un prompt qui le lui demandent gentiment.
C’est à ce jalon que meurent la plupart des pilotes, et c’est rarement l’ingénierie qui les tue. C’est la revue de sécurité, la revue juridique, la discussion sur le risque qui n’aboutit jamais parce que personne ne sait énoncer en une phrase l’étendue des dégâts possibles. Un agent qui se comporte probablement bien ne peut pas recevoir un accès en écriture à un système de production, et il reste donc une démo pour toujours. La solution consiste à rendre le pire scénario petit et explicite, plutôt qu’à plaider qu’il est improbable.
Vous avez franchi ce jalon quand vous pouvez énoncer en une phrase le pire que le système puisse faire, et que la personne qui répond de ce risque l’accepte.
Jalon 4 : un retour arrière pour le jour où le terrain bouge
Des versions de modèle figées, des prompts et une configuration versionnés, et la possibilité de revenir à la demande à un état connu et fiable. Les modèles sur lesquels vous vous appuyez ne sont pas une infrastructure stable : les fournisseurs les retirent, les réajustent et en modifient le comportement selon leur calendrier, pas le vôtre.
Les équipes qui sautent ce jalon le découvrent toujours de la même façon : quelque chose qui marchait depuis des mois se dégrade en un week-end, et il n’existe aucune configuration précédente vers laquelle revenir, parce que la configuration courante a été modifiée sur place. Revenir en arrière oblige alors à tout reconstituer.
Vous avez franchi ce jalon quand un retour arrière est un déploiement, pas une reconstruction.
Jalon 5 : un responsable nommé qui répond de l’indicateur
Une personne. Un chiffre. Pas un sponsor, pas un groupe de travail, pas un prestataire : une personne nommée dont le poste est concerné par l’évolution de ce chiffre.
C’est le jalon le moins technique et le plus prédictif. Les comités savent approuver des projets IA et sont structurellement incapables de les mettre en production : une responsabilité répartie sur huit personnes est une responsabilité que personne ne ressent un jeudi à 18 heures, quand le projet a besoin d’un dernier effort. Nous appelons ce mode d’échec la taxe du comité de pilotage, et c’est le signal le plus fiable que nous connaissions d’un programme qui va s’enliser.
Vous avez franchi ce jalon quand vous pouvez citer la personne et le chiffre sans rien avoir à vérifier.
Pourquoi tout se joue dans les 90 premiers jours
L’échec est généralement décidé bien avant que quelqu’un le remarque : au cours du premier trimestre, en trois décisions qui paraissent toutes raisonnables sur le moment.
Premier mois : la stratégie est une liste de cas d’usage. Un atelier produit quinze workflows candidats classés selon l’enthousiasme qu’ils suscitent, et c’est le plus impressionnant qui est retenu, pas le plus réalisable. Personne ne demande lequel des quinze a aujourd’hui un coût mesurable, si bien qu’il n’y aura plus tard aucun chiffre dont répondre.
Deuxième mois : personne ne répond de l’indicateur. Le projet a un sponsor, un prestataire et un comité de pilotage, ce qui n’est pas la même chose qu’une personne nommée dont le poste dépend de l’évolution d’un chiffre. Un comité peut approuver un projet IA, il ne peut pas le faire fonctionner. C’est la taxe du comité de pilotage, et c’est le signe annonciateur le plus fiable d’un programme enlisé.
Troisième mois : la démo réussit et redéfinit discrètement le succès. Elle fonctionne sur le cas nominal, la salle est impressionnée, et l’objectif glisse sans bruit de déployé à démontré. À partir de là, le projet n’échoue pas vraiment : il ne se termine jamais. C’est pourquoi 95 % des pilotes d’IA générative en entreprise n’ont aucun effet mesurable sur le compte de résultat (MIT Project NANDA, 2025) et pourquoi Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027 (Gartner, 2025).
La parade n’a rien de spectaculaire : choisissez un workflow qui coûte déjà de l’argent à quelqu’un, mettez un nom sur l’indicateur et définissez terminé comme un fonctionnement sans surveillance en production, pas comme une démo qui a impressionné une salle. C’est toute la raison pour laquelle nos missions commencent par un Sprint de deux semaines à prix fixe, qui se termine par un système déployé et non par une présentation. Si vous n’en êtes pas encore là, l’évaluation de maturité IA (en anglais) est un premier examen moins coûteux.
À quel jalon êtes-vous bloqué ?
Vus de l’intérieur, les pilotes bloqués se ressemblent tous, mais le symptôme désigne en général un seul jalon manquant :
- Nous le retouchons sans cesse sans savoir s’il s’améliore. Jalon 1 : vous n’avez pas d’instrument de mesure.
- Il marche, sauf quand il ne marche pas, et nous n’arrivons pas à reproduire le problème. Jalon 2 : vous n’avez pas de traces.
- L’ingénierie a terminé il y a des mois, et il est toujours en revue. Jalon 3 : personne ne sait borner le pire scénario.
- Il marchait, puis quelque chose a changé. Jalon 4 : vous n’avez aucun état fiable vers lequel revenir.
- Tout le monde convient que c’est important et rien n’avance. Jalon 5 : personne ne répond seul du chiffre.
Ce diagnostic compte plus qu’il n’y paraît, car les jalons coûtent peu dans l’ordre ci-dessus et cher dans le désordre. Ajouter des évaluations à un système déjà en production oblige à reconstituer la vérité terrain à partir de cas que personne n’a enregistrés. Ajouter l’observabilité après une défaillance revient à enquêter sur un événement dont vous n’avez aucune trace. Presque tous les sauvetages coûteux de projets IA pour lesquels on nous appelle concernent une équipe qui paie le prix du rattrapage sur un jalon qui aurait coûté quelques jours au départ.
Rien de tout cela n’est exotique. C’est la discipline qui, il y a dix ans, a transformé des démos web en logiciels fiables, appliquée à une pile technique qui se trouve être non déterministe. Les entreprises coincées dans le purgatoire des pilotes ne manquent pas d’ambition. Il leur manque les jalons, et c’est exactement ce qu’un projet Gigabit Agents est conçu pour mettre en place. Si ce qui s’est enlisé est une application entière développée avec des outils d’IA, et non un seul agent, faire passer un prototype en production (en anglais) relève de la même discipline, appliquée au code.
