Pourquoi les projets d’IA agentique sont abandonnés et ce qu’un projet pilote de huit semaines permet de bien faire

Un client demande un remboursement. L’agent retrouve la commande dans le CRM, vérifie la politique de retour et rédige une réponse en moins d’une minute. Puis il cale, car l’approbation du remboursement se trouve dans un système financier auquel il n’a jamais été connecté et que l’adresse du client ne correspond pas dans deux bases de données. Ces lacunes apparaissent rarement lors d’une démonstration, mais elles déterminent le coût d’exploitation d’un agent et la confiance qu’on peut lui accorder. Le risque majeur lié à l’IA agentique se situe donc dans l’entreprise où l’agent est déployé, plutôt que dans le modèle.

Gartner estime que plus de 40 % des projets d’IA agentique seront abandonnés d’ici la fin de 2027, en raison de la hausse des coûts, d’une valeur commerciale incertaine et de contrôles des risques insuffisants. À y regarder de près, cette prévision concerne des projets approuvés sur la foi d’une démonstration, sans que l’on sache vraiment combien le travail coûte aujourd’hui ni qui est responsable des résultats.

La question que je poserais à toute équipe de direction est de savoir si l’entreprise peut faire en sorte que cet agent accomplisse son travail au quotidien, à un coût et avec un niveau de risque qu’elle peut accepter. Pour y répondre, il faut examiner attentivement ce que j’appelle le travail après l’automatisation, c’est-à-dire tout ce que les personnes doivent encore faire une fois que l’agent a terminé sa part. Un projet pilote de huit semaines est un moyen concret de mesurer ce travail avant de s’engager dans un déploiement à grande échelle.

Les problèmes que l’agent hérite de l’entreprise

Un agent travaille rarement de façon isolée : même une tâche qui paraît simple fait intervenir des dossiers clients, quelques applications métier et, généralement, une étape d’approbation. Chaque connexion limite ce que l’agent peut voir et faire. Lorsque les dossiers sont incohérents ou que personne ne sait vraiment qui doit donner son aval, l’agent hérite de cette confusion en même temps que de la tâche.

Les cas courants posent rarement problème ; ce sont les exceptions qui en posent, car c’est là que les coûts d’exploitation s’accumulent, et c’est précisément ce qu’une démonstration est conçue pour éviter. Les recherches menées par Deloitte en 2026 ont révélé que seulement 5 % des organisations jugent leurs processus métier très bien préparés à l’arrivée des agents d’IA. Ce chiffre est plus révélateur que n’importe quel résultat de référence d’un modèle, car il laisse entendre que l’IA est prête bien avant la plupart des processus.

Le calcul de rentabilité doit inclure le travail après l’automatisation

Mesurer la rapidité avec laquelle un agent produit un résultat est le moyen le plus simple d’exagérer sa valeur, car le chiffre important est le temps et les efforts nécessaires pour mener la tâche à bien. Supposons qu’un employé mette 20 minutes à traiter une demande et que l’agent réduise le premier traitement à deux minutes : le gain semble être de 18 minutes, jusqu’à ce qu’une personne passe 15 minutes à vérifier le résultat et à corriger les erreurs. Une fois le coût d’exploitation de l’agent pris en compte, un gain de trois minutes offre un rendement bien maigre.

L’analyse de McKinsey consacrée à un agent de service à la clientèle dans le secteur bancaire montre la même tendance à grande échelle : les jetons représentaient 20–25 % des coûts d’exploitation variables et la supervision humaine, 70–75 %. La majeure partie des dépenses se situait donc en dehors du modèle. Sans mesure de référence établie avant l’écriture du moindre code, un projet pilote peut afficher de nombreux progrès techniques sans pour autant éprouver la rentabilité de l’investissement. Au minimum, le responsable métier doit pouvoir répondre clairement à chacun des points suivants :

• Volume : fréquence d’exécution du processus et nombre de personnes qui y interviennent.
• Durée de traitement : temps nécessaire à l’exécution complète de la tâche, vérifications et corrections comprises.
• Précision : fréquence à laquelle le processus échoue ou doit être recommencé.
• Coût par tâche : coût actuel d’une tâche menée à bien.
• Impact commercial : ce qu’une amélioration réelle changerait pour les clients, le personnel ou l’entreprise.

Un agent doit trouver sa place dans le flux de travail

L’adoption est généralement abordée sous l’angle de la gestion du changement, mais, d’après mon expérience, elle se joue bien plus tôt, en fonction de la place de l’agent dans le flux de travail. Une entreprise mondiale de services professionnels avait créé des agents pour les équipes d’assistance et de conformité. Son agent d’assistance pouvait récupérer des informations dans plusieurs systèmes internes, mais les employés devaient ouvrir une application distincte pour l’utiliser et ne prenaient, pour la plupart, pas la peine de le faire. Lorsque le même flux de travail a été intégré à la plateforme d’assistance existante, l’agent est apparu directement dans le ticket sur lequel les collaborateurs travaillaient déjà. Un agent de contrôle de conformité a suivi la même voie : intégré à Salesforce, il se lançait à chaque création d’un dossier.

Les agents eux-mêmes n’ont pas changé ; c’est leur place dans le flux de travail qui a changé. Les collaborateurs avaient déjà une raison d’ouvrir un ticket ou de créer un dossier : les rejoindre à ce moment-là ne leur demandait donc aucun effort supplémentaire. Le choix de l’emplacement relève ainsi autant de l’architecture que de l’adoption, car l’agent doit disposer du contexte nécessaire là où le travail est effectué, et son résultat doit alimenter l’étape suivante sans que quelqu’un ait à le recopier manuellement.

L’autonomie modifie les enjeux de sécurité

Un agent qui peut uniquement lire des informations présente un type de risque ; un agent capable de modifier des dossiers ou d’envoyer des courriels aux clients en présente un tout autre. Les contrôles doivent donc être adaptés à ce qu’il est réellement autorisé à faire. Les autorisations excessives et les fuites de données sensibles sont des risques bien connus, mais l’injection de prompt mérite la plus grande attention : il s’agit d’instructions dissimulées dans un document ou un courriel que l’agent récupère alors qu’il accomplit une tâche parfaitement légitime.

Les recommandations de Gartner de mai 2026 sur la gouvernance des agents distinguent quatre niveaux d’autonomie, ce qui fournit un moyen concret de déterminer le degré de contrôle nécessaire :

1. Observer : l’agent récupère des informations et repère des tendances, avec un accès en lecture seule.
2. Conseiller : il recommande une action, et un employé prend la décision.
3. Agir avec approbation : il prépare ou lance une action qu’une personne doit autoriser avant son exécution.
4. Agir de manière autonome : il exécute de lui-même les actions approuvées dans les limites fixées, avec un suivi et une remontée des exceptions.

À chaque niveau, un agent doit disposer de sa propre identité, de permissions limitées à sa tâche et d’un historique de chacune de ses actions. Les organisations doivent également définir des règles de traitement et de conservation des données, préciser quelles informations sont transmises aux fournisseurs de modèles externes et désigner une personne habilitée à suspendre l’agent et à révoquer son accès dès qu’un problème semble survenir.

Chacun de ces contrôles entraîne un coût récurrent : des permissions plus étendues, une surveillance accrue et des approbations fréquentes finissent toutes par peser au fil du temps. Le niveau d’autonomie approprié relève donc autant d’une décision économique que d’un choix de sécurité ; il se situe là où l’agent apporte un bénéfice intéressant pour un niveau de risque acceptable pour l’entreprise.

Choisir un processus qui justifie le recours à un agent

De nombreuses équipes commencent par la technologie, puis cherchent un problème à résoudre. Il vaut mieux partir d’un processus dont le coût ou les retards sont déjà évidents pour les personnes qui l’exécutent.

Une entreprise mondiale de mise en relation avec des experts avec laquelle nous avons travaillé correspondait à cette description : son équipe mettait en relation des demandes de sondage et des experts à l’aide de trois systèmes qui ne communiquaient pas entre eux, et vérifiait manuellement les profils, la participation antérieure et la conformité pour chaque mise en relation. Nous avons créé un agent qui combinait la recherche sémantique, l’historique de participation et les règles de conformité. En production, les tickets liés à des mises en relation inadaptées ont diminué de 80 %, la précision de la mise en correspondance a augmenté de 40 % et l’équipe a récupéré 22 % de sa capacité de travail.

Le projet a fonctionné parce que le problème était bien défini : les informations étaient dispersées, leur rapprochement se faisait manuellement et la qualité des mises en relation pouvait être mesurée avant et après. Bien définir le problème aide aussi à déterminer si un processus nécessite réellement un agent. Les tâches régies par des règles fixes sont généralement moins coûteuses à traiter avec une automatisation classique. Celles qui consistent principalement à trouver et à résumer des informations se prêtent souvent bien à un assistant IA. En revanche, les agents justifient leur surcoût et les risques supplémentaires lorsque le travail exige d’interpréter le contexte, de choisir parmi des actions autorisées et d’enchaîner plusieurs étapes pour atteindre un résultat.

Un projet pilote de huit semaines, jalonné de décisions claires

Tout le projet pilote repose sur une question commerciale : cet agent peut-il améliorer suffisamment le processus pour justifier son déploiement à grande échelle ? Huit semaines donnent suffisamment de temps pour évaluer la rentabilité, la technologie et la capacité de l’organisation à gérer ce qu’elle construit.

Semaines 1 à 2 : déterminer ce qui doit être amélioré

Commencez par documenter le fonctionnement actuel du processus : volume, délai d’exécution, taux d’erreur, reprises et coûts. Notez les systèmes concernés, les responsables de chaque étape et les exceptions qui nécessitent une intervention humaine, puis demandez au responsable métier et à l’équipe technique de s’entendre sur le résultat unique que l’agent doit améliorer. Point de décision : poursuivez lorsque le problème, la situation de référence, le responsable et les critères de réussite sont clairement définis.

Semaine 3 : définir les limites de l’agent

C’est à cette étape que sont fixées les limites de l’agent : son identité, ses permissions, son accès aux données, les outils autorisés et son degré d’autonomie. Mettez-le à l’épreuve face aux injections de prompt, aux accès non autorisés, à l’exposition de données sensibles et au mauvais usage des outils ; mettez également en place la journalisation et une procédure de réponse aux incidents, ainsi qu’un moyen de suspendre l’agent ou de révoquer son accès. Point de décision : poursuivez lorsque les contrôles et les mesures d’intervention ont réellement été testés et que chacun sait ce que l’agent est autorisé à faire.

Semaines 4 à 6 : tester les situations qui font échouer la démonstration

Soumettez-le maintenant à des tâches réalistes, avec notamment des dossiers incomplets, des informations contradictoires, des demandes inhabituelles et des pannes occasionnelles du système. Suivez le nombre de tâches qu’il accomplit, sa précision et l’ampleur des corrections que les employés doivent apporter, puis calculez le coût réel d’une tâche menée à bien en tenant compte de l’utilisation des modèles, des intégrations, de la surveillance et de la vérification. Point de décision : passez aux essais en conditions réelles lorsque l’agent atteint les seuils convenus et que l’équipe comprend à la fois son coût de fonctionnement et ses modes de défaillance.

Semaines 7 à 8 : le mettre à la disposition de vrais utilisateurs

Mettez-le à la disposition d’un petit groupe d’employés pour une partie limitée et contrôlée du travail réel, tout en maintenant l’ancien processus pour les tâches que l’agent ne peut pas traiter. Observez si les employés l’utilisent réellement, s’il leur épargne des efforts et s’ils font confiance à ses résultats.

À la fin, comparez les résultats à la situation de référence établie lors de la première semaine et examinez la productivité, la précision, l’adoption, la fréquence des interventions humaines, le coût total de fonctionnement et les risques de sécurité encore présents. Il faut alors décider de passer à l’échelle, de corriger des lacunes précises puis de refaire les tests, ou d’arrêter. Un projet pilote qui démontre que l’agent est trop coûteux ou trop peu fiable pour la tâche a tout de même rempli son rôle : il a évité un investissement bien plus important fondé sur des suppositions.

Mesurer les résultats, puis décider du degré d’autonomie à accorder

Compter le nombre de tâches traitées par un agent ne nous apprend pas grand-chose : un système peut traiter des milliers de demandes tout en laissant aux employés le soin d’en vérifier, d’en corriger ou d’en terminer la plupart. Le coût par tâche menée à bien, considéré conjointement avec les taux d’exactitude et d’exceptions, donne une bien meilleure idée de l’amélioration réelle du processus de bout en bout.

Ces mêmes mesures permettent de déterminer si l’on peut accorder davantage de latitude à un agent. On peut faire confiance à un agent qui traite de manière fiable les demandes courantes dans les limites convenues pour qu’il les gère seul. En revanche, si un agent rencontre régulièrement des cas ambigus, un humain continue d’approuver ses décisions, tandis que les autorisations sont réexaminées à mesure que les données s’accumulent.

Passer à l’échelle lorsque l’entreprise peut prendre en charge l’agent

Tôt ou tard, un agent qui fonctionne bien pour une équipe devra aussi interagir avec d’autres services, applications et circuits d’approbation. Pour le déployer à plus grande échelle, il faut définir clairement les responsabilités, appliquer des contrôles d’accès cohérents et prévoir un moyen de gérer les exceptions, ainsi que réserver un budget pour maintenir l’agent à jour à mesure que les processus qui l’entourent évoluent.

La décision fondamentale consiste à déterminer quelle part de responsabilité l’organisation est prête à déléguer, en s’appuyant sur des éléments issus du travail réel plutôt que sur une démonstration convaincante. Au terme des huit semaines, la direction devrait savoir ce que l’agent peut prendre en charge, dans quelles situations les équipes doivent encore intervenir et combien son fonctionnement coûtera. Les entreprises qui prendront de l’avance grâce à l’IA agentique seront celles qui, dès la première semaine, anticiperont le travail qui restera à accomplir après l’automatisation et financeront les agents pour les tâches qu’ils réalisent effectivement.