Le chiffre qui range tout le monde
88 % des organisations utilisent l’IA dans au moins une fonction. Seules 23 % font passer un système agentique à l’échelle. Et 31 % ont au moins un agent réellement en production — 47 % dans la banque et l’assurance, 14 % dans le secteur public.
L’écart entre « on utilise de l’IA » et « un agent fait le travail en production » est immense. C’est dans cet écart que se joue tout le retour sur investissement.
Parce que le ROI, lui, est très clair : 171 % de médiane sur les déploiements agentiques à l’échelle, avec un retour sur investissement en 7 à 9 mois, et un premier quartile qui dépasse 540 % à 18 mois. En POC, ce chiffre est zéro. Un POC ne rapporte rien par construction — il informe, il ne produit pas.
Pourquoi 40 % des projets vont être abandonnés
Gartner anticipe l’abandon de plus de 40 % des projets d’IA agentique d’ici fin 2027. Ce n’est pas un problème de maturité technologique. Les modèles de 2026 sont largement suffisants pour la quasi-totalité des cas d’usage d’entreprise.
Ce qui tue ces projets tient en trois causes, dans cet ordre de fréquence.
Le cas d’usage n’a jamais été chiffré. On a démarré parce que « il faut faire de l’IA », pas parce qu’une tâche coûtait 400 000 € par an et qu’on pouvait en absorber 60 %. Sans dénominateur, impossible de dire si le projet réussit.
La démo a été confondue avec le produit. Une démo montre le chemin heureux. La production, c’est 80 % de cas tordus : la pièce jointe corrompue, le client qui répond en trois langues, l’API tierce qui renvoie un 503 pendant deux heures, l’utilisateur qui essaie de faire dire n’importe quoi à l’agent.
Personne n’a prévu la sortie. Pas de plan de bascule si le fournisseur change ses prix, pas de mesure du coût par tâche, pas de seuil au-delà duquel on arrête. Le projet meurt d’épuisement budgétaire, pas d’échec technique.
Ce qui sépare la démo du système
Un agent qui répond, c’est une démo. Un agent qui agit, c’est un système. Voici les six briques qui font la différence, et qui manquent presque toujours dans les projets qui échouent.
1. Des outils, pas des instructions
Un agent utile n’écrit pas du texte : il appelle des fonctions. Créer un avoir, réserver un créneau, mettre à jour une fiche produit, déclencher un remboursement. Chaque outil a un contrat d’entrée strict, une validation, et un comportement défini en cas d’échec.
Si votre « agent » ne fait que produire du texte que quelqu’un doit ensuite recopier ailleurs, vous avez automatisé la rédaction, pas la tâche.
2. Le moindre privilège, appliqué réellement
Un agent IA dispose des droits de celui qui l’a branché. C’est la faille la plus fréquente et la plus grave. Un agent support avec un accès en écriture sur toute la base clients est un incident qui attend son heure.
Chaque outil reçoit un périmètre minimal, borné par tenant, par type d’enregistrement et par action. Et les opérations irréversibles — remboursement, suppression, envoi externe — passent par une validation explicite.
3. Une défense contre l’injection de prompt
Tout contenu que l’agent lit est une entrée non fiable : un e-mail client, une page web, un PDF, un ticket. Si votre agent traite ces contenus comme des instructions, n’importe qui peut lui donner des ordres.
La règle est simple et non négociable : les instructions viennent du système, jamais des données lues. Et les actions sensibles ne se déclenchent pas sur la seule foi d’un contenu externe.
4. Une évaluation continue, pas un test de recette
Un système IA n’est pas déterministe. Le tester une fois avant la mise en production ne dit rien de son comportement trois semaines plus tard, après un changement de version du modèle côté fournisseur.
Il faut un jeu d’évaluation versionné, exécuté à chaque déploiement et périodiquement en production, avec des seuils qui bloquent la livraison. Exactement la même logique qu’une suite de tests, appliquée à un composant probabiliste.
5. Des traces exploitables
Quand un agent se trompe — et il se trompera — il faut pouvoir reconstituer la scène : quel prompt, quelle version de modèle, quels documents récupérés, quels outils appelés avec quels arguments, quelle réponse. Sans cela, le diagnostic est impossible et la correction devient du bricolage.
C’est aussi, accessoirement, ce que l’AI Act attend depuis le 2 août 2026.
6. Un coupe-circuit et un coût par tâche
Deux métriques doivent être visibles en permanence : le coût par tâche traitée et le taux de reprise humaine. La première dit si le système est rentable, la seconde s’il est utile.
Et il faut un interrupteur. Un vrai, actionnable par l’exploitation sans déploiement, qui bascule le flux vers le traitement humain. Un agent sans coupe-circuit n’est pas déployable.
La séquence qui fonctionne
L’ordre importe autant que le contenu.
On commence par choisir une tâche coûteuse, répétitive et mesurable, et on établit sa ligne de base : combien de fois par mois, combien de temps, combien d’erreurs aujourd’hui. Sans ce chiffre, rien de ce qui suit n’a de sens.
On construit ensuite le chemin le plus étroit possible : un seul cas d’usage, deux ou trois outils, un périmètre de données restreint. La tentation d’élargir arrive vite ; il faut y résister jusqu’à la mise en production.
On met en place l’évaluation avant l’interface. C’est contre-intuitif et c’est pourtant ce qui distingue les équipes qui livrent de celles qui itèrent indéfiniment sur des impressions.
On déploie enfin avec humain dans la boucle par défaut, puis on desserre progressivement à mesure que les métriques le justifient. On ne part jamais de l’autonomie complète.
Le vrai différenciateur
Le modèle que vous utilisez comptera de moins en moins. Les écarts entre les modèles de pointe se resserrent, les prix baissent, et changer de fournisseur devient une question de configuration.
Ce qui ne se remplace pas, c’est l’architecture autour : les outils bien bornés, la traçabilité, l’évaluation continue, la gouvernance des accès. C’est ce travail-là qui explique pourquoi 31 % sont en production et pourquoi les autres présentent encore des démos.
Vous avez un POC qui tourne depuis six mois sans passer en production ? C’est presque toujours l’une des six briques ci-dessus qui manque. On identifie laquelle, on chiffre le passage en production et on livre.