Un projet d’agent IA peut être techniquement fonctionnel et pourtant condamné avant son passage à l’échelle. Gartner prévoit que plus de 40 % des projets d’agents IA seront annulés d’ici fin 2027, notamment à cause de coûts élevés, d’une valeur métier mal définie et de contrôles insuffisants.
La pression augmente pourtant : selon Deloitte, 23 % des entreprises utilisent déjà des agents IA à un niveau au moins modéré, tandis que 74 % prévoient de le faire dans les deux prochaines années. En 2026, le sujet n’est donc plus de savoir si les agents vont entrer dans l’entreprise, mais dans quelles conditions ils pourront y rester.
Les cinq défis à anticiper concernent la valeur métier, les coûts, la gouvernance, les données et l’organisation. Le cas de Get Covered, qui supervise 16 agents pour 3 millions d’unités et attribue un responsable à chacun, montre une voie concrète : chaque agent doit avoir un périmètre, un propriétaire et des résultats mesurables.
1. Prouver une valeur métier avant d’élargir l’autonomie
Le premier défi consiste à éviter les agents sans objectif opérationnel précis. Un agent capable d’enchaîner plusieurs actions n’apporte pas automatiquement un bénéfice mesurable : l’entreprise doit relier son déploiement à un résultat métier vérifiable.
Un agent peut rechercher des informations, déclencher une procédure, mettre à jour un outil ou transmettre une décision à un collaborateur. Mais chaque capacité supplémentaire augmente aussi le périmètre à contrôler. Une démonstration convaincante ne suffit pas à justifier un déploiement en production.
Partir d’un processus délimité
Le périmètre initial doit être suffisamment étroit pour permettre une comparaison avant et après. Les indicateurs peuvent porter sur le temps de traitement, le taux d’erreur, le volume de tâches prises en charge ou le nombre d’escalades vers un humain.
Les cas d’usage les plus faciles à évaluer présentent généralement trois caractéristiques :
- un processus répétitif et documenté ;
- des entrées et sorties clairement identifiées ;
- un coût actuel mesurable, en temps, en ressources ou en erreurs.
L’objectif n’est pas de donner à l’agent le plus grand nombre de permissions, mais de vérifier qu’une autonomie limitée produit une amélioration nette. Une tâche qui demande déjà de nombreuses exceptions, des données contradictoires ou des arbitrages humains fréquents peut être un mauvais point de départ.
Gartner attribue une partie du risque d’annulation à la valeur métier mal définie. Le problème ne vient donc pas seulement du modèle utilisé : il concerne aussi la décision de lancer un agent sans hypothèse économique suffisamment précise.
Distinguer automatisation et agent autonome
Une automatisation classique suit un scénario défini à l’avance. Un agent peut interpréter un objectif, choisir des actions, utiliser plusieurs outils et ajuster son comportement en fonction du résultat. Cette souplesse peut réduire le travail manuel, mais elle rend l’évaluation plus exigeante.
Avant le lancement, l’entreprise doit répondre à des questions concrètes :
- Quelle décision l’agent peut-il prendre seul ?
- Quelles actions nécessitent une validation humaine ?
- Quel résultat déclenche une escalade ?
- Comment mesurer une erreur et son coût ?
- Dans quel délai le projet doit-il atteindre son seuil de rentabilité ?
À retenir : l’autonomie n’est pas un indicateur de valeur. Un agent utile est d’abord un agent qui améliore un processus défini, avec des critères de réussite mesurables.
2. Maîtriser les coûts d’un système qui agit en continu
Le deuxième défi concerne l’économie réelle du déploiement. Un agent ne consomme pas seulement des tokens : il mobilise des modèles, des outils, des systèmes d’intégration, de la supervision, des tests, du stockage et des équipes responsables de son fonctionnement.
Un prototype peut sembler peu coûteux parce qu’il traite un faible volume de tâches. Le coût change lorsque l’agent fonctionne en continu, répète des appels, consulte plusieurs sources ou doit reprendre une opération après une erreur.
Calculer le coût par tâche réussie
Le suivi du budget doit dépasser la facture du fournisseur de modèle. Une mesure plus utile consiste à calculer le coût total d’une tâche correctement terminée :
coût par tâche réussie = coûts d’infrastructure + modèles + intégrations + supervision + corrections / tâches terminées sans reprise
Cette approche fait apparaître des dépenses parfois invisibles dans une démonstration : intervention d’un opérateur, vérification d’une réponse, reprise manuelle, traitement d’un incident ou maintenance d’une connexion à un outil métier.
Les boucles d’exécution constituent un risque particulier. Un agent peut multiplier les appels lorsqu’il ne comprend pas une réponse, rencontre une donnée incohérente ou tente plusieurs chemins pour atteindre son objectif. Des limites de durée, de budget et de nombre d’actions doivent être intégrées dès le départ.
Prévoir le coût de la maintenance
Un agent dépend de son environnement. Une modification d’API, d’interface, de règle métier ou de structure de données peut dégrader son comportement sans modifier le modèle lui-même.
Les entreprises doivent donc prévoir :
- un budget de tests après chaque changement important ;
- une surveillance des coûts et du volume d’actions ;
- un mécanisme d’arrêt en cas de dérive ;
- une procédure de retour à une version précédente ;
- une équipe capable de corriger les intégrations.
Gartner prévoit également que 70 % des entreprises pourraient abandonner d’ici 2028 des systèmes d’agents construits avec l’aide de fournisseurs, lorsque les coûts de maintenance augmentent et que les équipes internes ne peuvent pas modifier ces systèmes de façon autonome. Cette projection renforce un point pratique : le transfert de compétences doit être prévu avant la fin de l’accompagnement du fournisseur.
Comparer les modèles de déploiement
| Modèle | Avantage principal | Risque à surveiller | Décision à formaliser |
|---|---|---|---|
| Agent interne | Contrôle direct du code et des données | Charge de maintenance plus élevée | Équipe responsable du cycle de vie |
| Agent construit avec un fournisseur | Accélération du démarrage | Dépendance technique et opérationnelle | Conditions de transfert et de sortie |
| Agent intégré à un logiciel existant | Adoption facilitée par les utilisateurs | Extension silencieuse des permissions | Réexamen après chaque nouvelle capacité |
Le choix ne doit pas être fondé uniquement sur la rapidité du prototype. La question déterminante est la capacité de l’entreprise à comprendre, auditer, modifier et arrêter le système dans la durée.
3. Définir qui répond de chaque décision
Le troisième défi est managérial. Un agent peut exécuter une action, mais il ne peut pas porter la responsabilité juridique, financière ou opérationnelle de cette action. Cette responsabilité doit être attribuée à des personnes et à des fonctions identifiées.
Le cas de Get Covered illustre une organisation explicite : l’entreprise gère 16 agents pour 3 millions d’unités et affecte un responsable à chacun. Cette logique évite qu’un agent soit considéré comme un simple outil sans propriétaire.
Donner un propriétaire à chaque agent
Le responsable d’un agent doit connaître son objectif, son périmètre d’action, ses indicateurs, ses dépendances et ses règles d’arrêt. Il doit aussi pouvoir déclencher une suspension lorsqu’un comportement devient anormal.
Une fiche de responsabilité devrait préciser :
- le processus couvert ;
- le propriétaire métier ;
- le responsable technique ;
- les systèmes accessibles ;
- les actions autorisées ;
- les validations humaines obligatoires ;
- les indicateurs suivis ;
- les conditions de suspension ou de retrait.
Cette répartition ne signifie pas que le responsable métier doit administrer seul l’infrastructure. La sécurité, l’IT, le juridique et la conformité doivent intervenir selon le niveau de risque du cas d’usage.
Séparer les décisions de gouvernance et l’exploitation
Des recommandations publiées en octobre 2026 distinguent les décisions de principe du fonctionnement technique. L’IT peut choisir un outil et organiser son intégration, tandis que la gouvernance définit les responsabilités, les droits de décision et les obligations de contrôle.
Cette séparation limite un risque fréquent : laisser l’équipe qui déploie l’agent décider seule de la latitude qu’elle lui accorde. Plus un agent peut accéder à des données sensibles ou agir sur des systèmes critiques, plus la validation doit associer des fonctions indépendantes de l’équipe de développement.
Gartner indique que 21 % seulement des responsables informatiques disposent déjà d’une gouvernance des agents IA, alors que 71 % prévoient de déployer ces systèmes dans les douze mois. L’écart entre la vitesse de déploiement et la maturité des contrôles constitue l’un des principaux points de tension pour 2026.
À retenir : un agent sans propriétaire identifié devient rapidement une zone grise. La responsabilité doit être attribuée avant la mise en production, et non après le premier incident.
4. Contrôler les accès, les actions et les changements de comportement
Le quatrième défi concerne la sécurité opérationnelle. Un agent ne se contente pas de produire du texte : il peut consulter des données, appeler des services, modifier un dossier ou déclencher une action au nom d’un utilisateur.
Une autorisation existante peut devenir beaucoup plus puissante lorsqu’un logiciel reçoit des capacités agentiques. Un outil approuvé peut alors accéder à davantage de données, invoquer d’autres systèmes ou agir à la vitesse d’une machine sans avoir été réévalué comme un nouveau risque.
Appliquer le principe du moindre privilège
Chaque agent doit disposer d’une identité technique distincte et de permissions limitées à son objectif. L’utilisation silencieuse du compte d’un salarié complique l’attribution des actions et rend les investigations plus difficiles.
Les contrôles doivent couvrir :
- l’identité propre de l’agent ;
- les systèmes qu’il peut appeler ;
- les données qu’il peut lire ;
- les actions qu’il peut exécuter ;
- les montants ou volumes maximaux ;
- les opérations qui exigent une validation humaine.
Une limite de lecture ne répond pas aux mêmes exigences qu’un droit d’écriture. De même, créer un brouillon, envoyer un message et modifier une donnée comptable sont trois niveaux d’impact différents.
Journaliser chaque action importante
Les journaux doivent permettre de reconstituer la chaîne complète d’une opération : l’initiateur, l’agent et sa version, l’objectif reçu, les systèmes consultés, l’éventuelle validation humaine et l’action finale.
Cette traçabilité sert à détecter les dérives, à analyser les erreurs et à répondre aux exigences de contrôle interne. Elle doit rester exploitable : un volume massif de traces inutilisables ne remplace pas une supervision conçue autour des événements à risque.
Les entreprises peuvent également définir des seuils d’arrêt automatique. Un nombre inhabituel d’actions, une répétition d’échecs, une sortie du périmètre prévu ou un accès à une donnée sensible doivent pouvoir suspendre l’exécution.
Réexaminer les agents après chaque évolution
Une nouvelle fonction peut transformer le profil de risque d’un produit déjà approuvé. Les changements à surveiller comprennent l’ajout d’une autonomie, l’élargissement de l’accès aux données, l’apparition de nouvelles intégrations ou la possibilité d’exécuter directement une décision.
Les clauses contractuelles avec les fournisseurs doivent prévoir une notification de ces changements, ainsi que des droits d’audit et des responsabilités clairement réparties. Les fonctionnalités à fort impact peuvent être désactivées par défaut jusqu’à leur validation spécifique.
5. Fiabiliser les données et organiser le passage à l’échelle
Le cinquième défi est souvent moins visible que le choix du modèle : la qualité des données et la complexité des systèmes existants. Gartner indique que 52 % des entreprises citent la qualité des données comme principal obstacle au déploiement d’agents.
Un agent ne corrige pas automatiquement des informations incomplètes, obsolètes ou contradictoires. Au contraire, son autonomie peut accélérer la propagation d’une erreur lorsqu’il utilise ces données pour prendre plusieurs décisions successives.
Traiter les données avant l’agent
Avant de connecter un agent à un système métier, l’entreprise doit identifier les sources de référence, les règles de mise à jour et les conflits possibles. Les doublons, les champs manquants et les informations périmées doivent être traités comme des problèmes opérationnels, pas comme de simples défauts de modèle.
Les contrôles utiles comprennent :
- la validation du format des entrées ;
- la vérification de la fraîcheur des données ;
- la détection des doublons ;
- la comparaison avec une source de référence ;
- le blocage des actions lorsque les données sont insuffisantes.
L’agent doit pouvoir signaler qu’il ne dispose pas des éléments nécessaires. Une stratégie qui force une réponse ou une action dans tous les cas transforme une incertitude en erreur potentiellement automatisée.
Tester les exceptions plutôt que les seuls cas nominaux
Un agent peut réussir une tâche standard et échouer dès qu’un client conteste une information, qu’un outil devient indisponible ou qu’une donnée ne respecte pas le format attendu. Les tests doivent donc représenter les situations qui déclenchent une intervention humaine.
Le passage à l’échelle devrait suivre des étapes contrôlées :
- environnement de test avec données représentatives ;
- période pilote sur un périmètre limité ;
- comparaison avec le processus existant ;
- extension progressive après validation des indicateurs ;
- revue régulière des incidents et des coûts.
Des recommandations publiées en octobre 2026 préconisent également des périodes d’essai, une documentation complète, des journaux d’activité et un cycle de vie formel pour chaque agent.
Relier l’agent aux équipes qui utilisent ses résultats
La qualité technique ne suffit pas si les collaborateurs ne savent pas quand faire confiance à l’agent, quand vérifier son travail ou quand reprendre la main. Les procédures doivent préciser les signaux d’alerte, les délais d’escalade et les personnes à contacter.
La formation doit porter sur le fonctionnement réel du système : limites, permissions, cas d’erreur, données utilisées et actions possibles. Elle ne doit pas se limiter à une présentation des fonctionnalités.
Les cinq contrôles à installer avant le premier déploiement
Un projet d’agent IA ne devrait pas entrer en production sans un socle de contrôle minimal. Les exigences suivantes couvrent les principaux risques identifiés pour 2026 :
- un objectif métier mesurable et un seuil de rentabilité défini ;
- un propriétaire métier et un responsable technique nommés ;
- une identité technique et des permissions limitées ;
- des journaux permettant de reconstituer chaque action sensible ;
- un bouton d’arrêt et une procédure de reprise manuelle ;
- un budget suivi par tâche réussie ;
- des tests couvrant les erreurs et les exceptions ;
- une revue après chaque évolution importante ;
- une procédure d’escalade vers un humain ;
- un plan de transfert de compétences si un fournisseur intervient.
Ces contrôles ne garantissent pas le succès du projet. Ils empêchent cependant de confondre une démonstration impressionnante avec un service exploitable, auditable et maintenable.
Notre avis : en 2026, les agents doivent d’abord gagner le droit d’agir
Les entreprises qui réussiront ne seront pas nécessairement celles qui déploieront le plus grand nombre d’agents. Ce seront celles qui relieront chaque agent à une valeur mesurable, à un propriétaire identifiable et à des limites techniques vérifiables.
Les chiffres disponibles dessinent une contradiction nette : 23 % des entreprises utilisent déjà des agents IA, 74 % veulent les adopter dans les deux prochaines années, mais seulement 21 % des responsables informatiques disposent aujourd’hui d’une gouvernance dédiée. La croissance de l’usage avance donc plus vite que l’organisation chargée de le contrôler.
Le cas de Get Covered fournit une règle simple et applicable : 16 agents, 16 responsables. Cette discipline doit s’étendre au suivi des coûts, aux données, aux permissions et aux conditions de retrait.
Dans les six prochains mois, la question décisive ne sera plus de savoir quel agent produit la réponse la plus convaincante, mais quelle entreprise saura démontrer qu’elle peut expliquer, limiter et interrompre chacune de ses actions. Les projets qui ne peuvent pas répondre à ces trois exigences devraient-ils encore être considérés comme prêts pour la production ?