Le pilot purgatory désigne la situation d'une entreprise qui accumule les preuves de concept en intelligence artificielle sans en faire passer aucune en production. Les démonstrations convainquent le comité de direction, puis rien ne suit, faute de sponsor nommé, de business case chiffré, de données prêtes ou de critères de décision fixés avant le lancement.
Plusieurs études mesurent le phénomène. Selon S&P Global (2025), 46 % des preuves de concept d'IA sont abandonnées avant d'atteindre la production, et le MIT (2025) observe de son côté que 95 % des pilotes d'IA générative n'ont aucun effet mesurable sur le compte de résultat. Faire d'un pilote un agent IA en production demande de trancher, dans le bon ordre, les questions de sponsor, de budget, de données et de risques.
D'où vient le chiffre de 87 % qui circule sur les projets IA
Un chiffre revient souvent pour illustrer l'échec des projets d'IA : 87 % d'entre eux n'atteindraient jamais la production. La plus ancienne trace écrite retrouvée est un article partenaire publié par VentureBeat le 19 juillet 2019, qui revenait sur un panel de la conférence Transform, tenue à San Francisco les 10 et 11 juillet, avec parmi les intervenants la CTO data science et IA d'IBM. L'article avance le chiffre sans le rattacher à aucune étude, et il portait sur les projets de data science, des années avant les agents et l'IA générative.
Les études récentes portent sur d'autres objets. D'après Deloitte (State of AI in the Enterprise, édition 2026), 21 % seulement des entreprises ont une gouvernance mature de leurs agents, et Gartner (2025) anticipe l'annulation de plus de 40 % des projets d'IA agentique d'ici fin 2027. Ces mesures concernent la gouvernance et l'abandon de projets agentiques, et aucune ne reprend ni ne valide le chiffre de 87 %.
Les modèles de fondation (Claude, GPT, Gemini) sont assez mûrs pour produire des résultats opérationnels, les frameworks agentiques existent et les API tiennent la charge : l'écart entre le POC et la production se joue donc sur l'organisation. Le passage du chatbot à l'agent rend cet écart plus visible, puisqu'un agent agit directement dans le système d'information et engage l'entreprise à chaque action.
Pourquoi les projets d'IA restent bloqués au stade pilote
Aucun cadre de gouvernance pour trancher
Sans cadre formel pour dire quels cas d'usage IA déployer, lesquels bloquer et quel niveau de risque accepter, chaque POC devient un débat isolé : la DSI freine par précaution, le métier pousse sans garde-fou, et le projet finit enterré en comité. Un cadre de gouvernance de l'IA écrit avant les premiers pilotes évite de rejouer ce débat à chaque projet.
Un sponsoring flou et des responsabilités diffuses
Qui porte le projet ? Qui décide du passage en production ? Qui répond d'une erreur de l'agent ? Tant que ces rôles restent implicites, le COMEX s'enthousiasme, la DSI expérimente, le métier observe, et personne ne porte la transition vers la production avec un mandat et un budget.
Un business case sans coût de départ mesuré
« On teste l'IA » exprime une intention, sans cible à atteindre. Un business case se construit à partir d'un coût opéré, mesuré et documentable : le temps qu'un analyste passe sur une tâche répétitive, le coût d'un ticket de support, le délai de traitement d'une facture. Sans cette base de départ, aucun ROI ne peut être calculé, et sans ROI démontré, personne ne signe l'investissement qu'exige la production.
Des données mal cadrées
Quand un POC tourne sur un échantillon propre, choisi pour la démonstration, la production expose ensuite l'agent à la réalité des données : sources hétérogènes, documents mal numérisés, règles métier jamais écrites. Un agent très fiable sur l'échantillon peut alors perdre nettement en précision face aux dossiers réels, d'où l'intérêt de prévoir cette mesure dès le départ.
Ce qu'il faut réunir avant le premier POC
Pour sortir du pilot purgatory, mieux vaut régler avant le premier POC les questions qui, sinon, surgissent à la fin. En plus des conditions détaillées plus bas, le cadre suivant se met en place dès le départ :
- Un cadre de gouvernance avec classification des cas d'usage par niveau de risque
- Un monitoring continu des agents déployés, sur des tableaux de bord qui suivent performance et coût
Le POC, un test contrôlé au service du passage en production
Un POC sert à valider une hypothèse dans un cadre contrôlé. S'il n'est rattaché à aucun plan de passage en production, avec un budget et un comité de décision, il restera une démonstration, aussi réussie soit-elle.
La méthode de passage en production : cadrage, gouvernance, déploiement, monitoring
La méthode que Koneetiv applique enchaîne ces étapes dans cet ordre, et chacune se termine par une décision écrite, prise par la personne qui en a le mandat.
Cadrer les cas d'usage et le business case
Le cadrage part des processus métier et des données disponibles, contraintes de sécurité comprises. Avec Claude Ignite, l'audit flash débouche sur une matrice qui note chaque cas d'usage sur sa valeur, sa faisabilité et son ROI estimé, puis retient les trois à cinq cas prioritaires, chacun avec son business case chiffré et une feuille de route jalonnée de décisions go/no-go.
Les meilleurs candidats sont des tâches à fort volume, aux règles connues et au coût mesurable. Le panorama des cas d'usage d'agents IA qui passent en production aide à les repérer, et le chiffrage de départ sert ensuite à juger le pilote.
Classer chaque action de l'agent dans les zones de confiance
Chaque action que l'agent pourra réaliser est rangée, avant le démarrage du POC, dans l'une des 4 zones de confiance LOOP™ : verte pour l'exécution autonome, orange quand un humain valide avant l'action, rouge quand l'escalade est obligatoire, noire pour ce qui reste hors périmètre. Faite à ce stade, la classification évite de découvrir en fin de parcours qu'une action clé relève de la zone rouge et ne peut pas être automatisée telle quelle.
La méthode Koneetiv profite de cette étape pour désigner le sponsor, fixer les engagements de service et ouvrir le registre de l'agent, où LOOP™ consigne les responsables, les actions autorisées et les règles d'escalade.
Déployer sur un périmètre contrôlé
L'agent est construit, testé sur des données réelles, intégré au système d'information, puis mis en production sur un périmètre restreint : un seul type de ticket, un seul fournisseur ou un seul canal. Pendant les premiers jours, un humain valide chaque décision, et l'écart entre ce que l'agent propose et ce que le métier aurait décidé se mesure dossier par dossier. L'extension se fait ensuite par paliers, avec une mesure à chaque palier et une décision du comité avant d'ouvrir le suivant.
Le jeu de test se prépare en même temps que l'agent. Il se constitue avec le métier, mélange les dossiers courants et les cas difficiles (pièces illisibles, demandes ambiguës, tentatives de contournement des règles) et sert ensuite de référence à chaque évolution du prompt ou du modèle. Le programme Claude Ops couvre ce déploiement de bout en bout, de l'audit technique jusqu'à la maintenance de l'agent en production.
Surveiller les décisions en continu
Une fois l'agent en production, la supervision suit ses décisions, ses exceptions et ses dérives, et le registre reste à jour. La classification évolue ensuite avec les résultats : les seuils LOOP™ sont versionnés au registre, les règles d'escalade sont validées par le RSSI, et les zones s'ajustent lors de la revue de gouvernance mensuelle, par exemple pour rendre de l'autonomie à une action restée fiable ou remettre une autre sous validation humaine après un incident, et chaque modification est tracée.
Comment Koneetiv accompagne la sortie du pilot purgatory
L'accompagnement repose sur une équipe et sur une méthode outillée, avec en face un sponsor métier engagé. Koneetiv, partenaire officiel Anthropic, s'appuie sur des modules d'agents standardisés et sur la gouvernance LOOP™ dès le cadrage, ce qui évite de reconstruire à chaque projet les briques d'intégration et de supervision.
La bibliothèque d'agents montre à quoi ressemble un périmètre resserré, à travers des démonstrations concrètes : automatisation des comptes fournisseurs et clients en finance, analyse de clauses en juridique, onboarding et questions des collaborateurs en RH, traitement des tickets et des incidents pour la DSI. Chaque démonstration part d'une tâche précise, ce qui en fait un bon point de départ pour discuter de votre propre premier cas d'usage.
Les autres analyses de la rubrique agents IA en production détaillent l'architecture des agents et le choix des cas d'usage.
Les conditions à vérifier avant de lancer un POC
Avant de lancer un POC, les conditions ci-dessous doivent être réunies ; toutes se contrôlent pendant le cadrage, avant la première ligne de code.
Un sponsor exécutif nommé
Le sponsor se désigne par un nom, avec un mandat daté. « La direction financière » décrit une fonction, alors que « la directrice financière, mandatée par le COMEX le 12 mars pour porter le projet » désigne une personne qui tranchera les arbitrages et en répondra devant le comité de direction.
Une baseline mesurée
Avant le déploiement, on doit connaître la durée de la tâche, le nombre d'erreurs qu'elle produit et son coût unitaire. Ces chiffres servent de point de comparaison au pilote et fondent la décision de passage en production. La baseline se construit sur un échantillon représentatif de dossiers, en mesurant le travail tel qu'il se fait réellement, exceptions comprises.
Un seuil de succès fixé avant le POC
Le niveau de performance qui déclenche la mise en production se décide au départ : un taux de précision minimal, un délai de traitement, une part maximale de dossiers escaladés ou un coût unitaire cible. Ce seuil s'écrit avant le POC, faute de quoi le débat devient subjectif au moment de conclure et la décision glisse de comité en comité.
Un comité de passage
Il faut une instance identifiée, qui se réunit à date fixe et qui tranche. Elle examine les résultats sur le jeu de test, le taux d'escalade, les incidents relevés et l'avis du RSSI, puis choisit entre le go, le no-go et un périmètre réduit. Sans ce comité, un POC risque de traîner d'une réunion à l'autre pendant des mois.
Un budget d'intégration engagé en amont
Le budget d'intégration est identifié et réservé avant le lancement du pilote, au même titre que celui du POC. Sans cette réserve, un pilote réussi risque de s'arrêter au moment de passer en production, faute de ligne budgétaire pour l'intégration au SI, la sécurité et le monitoring.
Les pièges à anticiper au moment du passage en production
Même avec un bon cadrage, le passage en production peut échouer au dernier moment, et ces pièges sont à anticiper dès le départ :
- Le piège des données de production : le POC tournait sur un échantillon propre, la réalité est plus sale. La parade consiste à tester sur des données réelles dès les premières semaines du POC.
- Le piège des exceptions : l'agent traite correctement la grande majorité des dossiers, mais la minorité restante devient ingérable faute de circuit prévu. La parade est une stratégie d'escalade humaine conçue dès le départ.
- Le piège de la sécurité : le RSSI découvre le projet en fin de parcours et le bloque. Il faut l'associer dès le cadrage, avec les obligations de l'AI Act qui s'appliquent au cas d'usage.
- Le piège de la résistance métier : les utilisateurs rejettent un agent sur lequel on ne les a jamais consultés. Ils doivent participer dès la première itération, en particulier à la constitution du jeu de test.
- Le piège du monitoring absent : l'agent tourne et personne ne suit ses décisions. La supervision et le registre doivent être en place avant la mise en production.
Koneetiv ajoute un dernier contrôle avant la mise en production : une équipe tente délibérément de faire dérailler l'agent avec des documents piégés, des demandes hors périmètre et des tentatives d'injection de prompt, et chaque faille trouvée devient une règle de blocage inscrite au registre avant l'ouverture aux utilisateurs.
Les principes de la méthode Koneetiv
Ces principes de conduite s'appliquent dès la première réunion.
Commencer par le coût de la tâche
La première réunion porte sur le chiffrage du coût actuel de la tâche, avant toute question d'architecture. Ce chiffre devient la référence sur laquelle tout le reste se construit, du choix du périmètre jusqu'au seuil de succès examiné par le comité.
Réduire le périmètre avant de l'élargir
Un premier agent prend en charge une seule tâche, bien délimitée. Mieux vaut viser « un agent qui préqualifie les tickets de niveau 1 de la catégorie facturation » qu'« un agent qui gère toute la relation client » : le premier se mesure, se corrige et se reproduit ensuite sur d'autres catégories, alors que le second n'offre aucun critère de succès vérifiable.
Pour situer votre organisation avant le prochain comité, le diagnostic de maturité IA donne en quelques minutes un score sur 100, un radar sur six axes et un plan d'action pour passer du POC à la production.