Le cimetière des pilotes : six raisons pour lesquelles les projets agentiques sont annulés

Les démos s'améliorent chaque mois. N'importe qui peut monter en un après-midi quelque chose qui ressemble à un agent autonome, et l'enthousiasme en comité de direction est réel. En surface, l'adoption semble accélérer.

Sauf que les chiffres en dessous racontent une histoire plus dure. Environ 60 % des entreprises ne rapportent aucune valeur mesurable de l'IA (BCG), autour de 1 % se considèrent matures en IA (McKinsey QuantumBlack), et environ 40 % des projets d'IA agentique devraient être annulés d'ici 2027 (Thoughtworks). C'est un cimetière, et ce qui frappe, c'est le peu de variété dans les causes de décès. Les projets n'échouent pas de mille façons créatives. Ils échouent d'environ six façons, et chacune est évitable si vous concevez pour elle avant de commencer.

Voici les six, et quoi faire à la place.

Raison 1 : ils ont mis à l'échelle une automatisation de portable, pas une architecture

La cause de décès la plus courante est de prendre une démo qui marche pour un système de production. Un script écrit par un collaborateur passe la démo, quelqu'un crie victoire, et le plan devient « mettons ça à l'échelle ».

Mais une automatisation sur portable et un agent en production sont séparés par un gouffre que la mise à l'échelle ne franchit pas. L'automatisation n'a jamais eu à gérer l'identité, le moindre privilège, la dérive, l'audit ou l'entrée non fiable, parce que sur une seule machine rien de tout cela n'était dans le périmètre. Mettre le script à l'échelle ne fait qu'échelonner ses fondations manquantes.

Comment l'éviter. Traitez la démo comme la preuve que l'idée a du mérite, pas comme le système. Avant de mettre à l'échelle, demandez ce dont la chose a besoin et que le portable ne lui a jamais donné : une identité, une frontière autour de ce qu'elle lit, un enregistrement de ce qu'elle décide. Si cela manque, vous ne mettez pas un système à l'échelle, vous mettez un passif à l'échelle.

Raison 2 : l'agent ne pouvait pas atteindre le contexte dont il avait besoin

Le deuxième cimetière est plus silencieux, parce que l'agent fonctionne parfaitement, il ne voit simplement pas assez pour compter. Son contexte vit à travers le CRM, le système central, la GED, et la personne qui connaît l'exception. L'organisation n'a jamais construit la couche qui permet à un agent d'atteindre ce contexte en sécurité.

Le projet se scinde donc en deux mauvaises options. Soit l'agent reste trop isolé pour être utile, soit il est câblé avec des credentials larges et permanents que le comité de sécurité n'approuvera pas. Les deux routes mènent à l'annulation.

Comment l'éviter. Budgétez la couche de contexte comme du vrai travail, pas de la plomberie. L'agent devrait atteindre vos systèmes par des capacités typées et nommées, agir sous sa propre identité à moindre privilège, et être structurellement incapable de traiter une donnée non fiable comme une instruction. Si cette couche n'est pas au plan, le choix du modèle n'a aucune importance.

Raison 3 : il n'a pas pu passer le comité de sécurité

Beaucoup de pilotes meurent non pas en production mais à la revue d'homologation, et le constat est presque toujours le même : l'agent tourne sous le jeton personnel d'un développeur avec accès permanent à la production. C'est un passe-partout, et aucun comité de sécurité sérieux ne signe pour ça.

Le projet était techniquement impressionnant et structurellement inapprouvable. L'équipe a optimisé pour « est-ce que ça marche ? » et n'a jamais demandé « est-ce que ça peut passer la revue ? », qui est, dans une entreprise réglementée, la question qui commande réellement la mise en service.

Comment l'éviter. Concevez pour le comité de sécurité dès le premier jour, pas comme dernier obstacle. Chaque agent tourne sous sa propre identité non humaine, avec des credentials éphémères à moindre privilège et une allow-list de sortie explicite, de sorte qu'il n'y a pas de secret statique à voler et que l'identité ne peut faire que les quelques choses pour lesquelles elle a été cadrée. Rattachez chaque risque agentique à un contrôle nommé et testable, pour que le comité signe pour un contrôle, pas pour une assurance.

Raison 4 : la gouvernance IT ne pouvait pas gouverner un système qui dérive

Certains projets passent le comité de sécurité puis sont annulés quelques mois plus tard, quand la gouvernance découvre qu'elle n'a aucun moyen de tenir la chose. Le comité de changement a été construit pour du logiciel déterministe : même entrée, même sortie, releases sous contrôle. Il n'a aucun mécanisme pour un système qui a changé parce qu'un modèle a été mis à jour pendant la nuit et que personne n'a rien livré.

Le résultat est un projet qui avait l'air gouverné, parce qu'il est passé par le processus normal, et qui s'avère ingouvernable en pratique. Il a passé le mauvais gate.

Comment l'éviter. Ajoutez une couche de gouvernance conçue pour les agents à côté de votre gouvernance IT, pas au-dessus. Les agents gagnent leur autonomie sur une échelle graduée commandée par des evals, la surveillance de la dérive peut rétrograder un agent automatiquement dès qu'il sort de son seuil, et l'unité de gouvernance devient chaque décision, pas chaque release. La gouvernance déterministe continue de faire ce qu'elle fait bien. La nouvelle couche prend en charge la dérive.

Raison 5 : le comité des risques ne pouvait pas approuver une boîte noire

Le cinquième cimetière est un comité qui n'arrête pas de dire non. Le système marche peut-être, mais personne ne peut expliquer, après coup, pourquoi il a pris une décision précise. Sans cela, un comité des risques ne peut pas l'approuver, et un projet qui ne peut pas être approuvé ne peut pas passer à l'échelle.

C'est là que « le modèle est impressionnant » cesse de compter. Le comité n'évalue pas le modèle. Il évalue s'il peut défendre le système devant un régulateur, et il ne peut pas défendre ce qu'il ne peut pas inspecter.

Comment l'éviter. Rendez chaque décision inspectable avant qu'elle ne s'engage. Chacune laisse un enregistrement de preuves append-only chaîné par hachage, écrit avant que la décision ne prenne effet, de sorte que si la preuve ne peut pas être écrite, la décision n'a pas lieu. Les décisions à conséquence se résolvent vers une personne par politique, et les règles de conformité sont du code que votre équipe conformité possède et signe. Le comité signe alors pour un contrôle documenté et testable, ce qui est un oui qu'il peut réellement donner.

Raison 6 : ils ont parié gros, n'ont rien mesuré et n'avaient pas de sortie

La dernière cause de décès est un échec de forme du projet, et elle tue les bonnes architectures comme les mauvaises. L'organisation s'engage d'emblée sur un déploiement large, n'établit jamais de référence auditable, ne fixe jamais de gate go/no-go, et n'a donc aucun moyen honnête de dire si la chose fonctionne. Des mois de coûts s'accumulent sans moyen de prouver le retour, et finalement quelqu'un débranche un projet qui aurait peut-être été bon, parce que personne n'a pu montrer qu'il l'était.

Comment l'éviter. Ne pariez pas l'entreprise pour tester l'architecture. Engagez-vous plutôt sur une Fondation : un processus à forte conséquence, mené jusqu'à un agent gouverné en production en environ six à huit semaines, mesuré face à une référence auditable, avec un gate go/no-go explicite avant tout engagement à l'échelle.

Une séquence approximative rend cela concret. Dans les 30 premiers jours, prouvez la frontière : montez la couche de contexte et les identités pour ce seul processus, avec l'agent en Ombre, qui propose pendant que les personnes décident. Entre le 30e et le 60e jour, prouvez la gouvernance : allumez la piste de preuves et le point de décision de politique, passez l'agent en Supervisé, et laissez le comité des risques inspecter un vrai contrôle plutôt qu'une diapositive. Entre le 60e et le 90e jour, prouvez la valeur au gate : mesurez le coût par unité, la latence, le gain de qualité et la concordance avec la revue humaine face à la référence, et décidez de passer à l'échelle sur des preuves.

Si cela franchit la barre, vous passez à l'échelle sur preuve. Sinon, vous avez passé huit semaines et appris quelque chose de réel sans exposition en production, ce qui est un bien meilleur résultat que de le découvrir après un déploiement large.

Le recadrage

Remarquez ce que les six raisons ont en commun. Aucune n'est « le modèle n'était pas assez bon ». Chaque décès du cimetière est architectural ou procédural : une couche manquante, une identité inapprouvable, un modèle de gouvernance incapable de voir la dérive, une décision inauditable, ou un pari placé avant que quoi que ce soit ne soit prouvé.

La question n'est donc pas « sommes-nous en retard sur l'IA ? ». C'est : sur notre processus le plus lourd de conséquences, avons-nous une identité pour l'agent, une frontière autour de ce qu'il lit, un enregistrement de ce qu'il décide, une couche de gouvernance qui peut le voir dériver, et un gate fixé à l'avance ? Et sinon, quelle est la plus petite Fondation qui nous permettrait de le découvrir pour de vrai, avant de parier sur le deuxième processus ?

Si vous voulez une lecture honnête de l'endroit où l'un de vos processus atterrirait, prenez rendez-vous.