Agents IA : 40 % des entreprises pourraient les brider ou les retirer d'ici 2027

SECTION 1

Ce que dit la prévision

Le 26 mai 2026, Gartner a publié une prévision sans détour : d'ici 2027, 40 % des entreprises rétrograderont ou retireront des agents IA autonomes, à cause de lacunes de gouvernance découvertes seulement après des incidents en production. Elle ne se confond pas avec une autre prévision du cabinet, publiée en juin 2025, selon laquelle plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027.

L'explication du cabinet tient en une idée : les organisations traitent la gouvernance des agents comme un interrupteur. Soit l'agent est verrouillé, soit on lui fait entièrement confiance. Or les agents n'ont ni le même degré d'autonomie ni les mêmes accès. Appliquer partout les mêmes contrôles produit deux échecs symétriques.

Trop de contrôle sur les agents simples

Un agent qui se contente de lire et de résumer se retrouve soumis aux mêmes validations qu'un système critique. Les livraisons ralentissent, les équipes contournent les règles, et des agents apparaissent hors de tout cadre.

Pas assez sur les agents autonomes

À l'inverse, un agent capable d'agir dans les systèmes de l'entreprise reçoit la même revue légère qu'un assistant conversationnel. Le risque opérationnel, de sécurité et de conformité grandit sans que personne ne le voie, jusqu'au premier incident.

SECTION 2

Un agent n'est pas un chatbot

La différence ne tient pas à la qualité des réponses, mais à ce que l'agent a le droit de faire. Un assistant conversationnel produit du texte qu'un humain lit. Un agent appelle des outils, ouvre des tickets, modifie du code, déclenche des déploiements. Il agit dans le système d'information.

Des risques que le chatbot ne posait pas

Ce passage de la parole à l'action ouvre des risques nouveaux. Une instruction malveillante glissée dans un document que l'agent lit peut détourner son comportement. Des données peuvent sortir par un outil auquel il a accès. Une action mal bornée peut se répéter sans que personne ne l'arrête. En pratique, le risque d'un agent augmente avec ses capacités, son autonomie, ses accès et sa vitesse d'action, et diminue avec la qualité de la supervision.

Des questions qui demandent une réponse écrite

À quelles données l'agent accède-t-il ? Quelles actions peut-il lancer seul ? Qui peut l'arrêter, et en combien de temps ? Qui peut retracer sa décision six semaines plus tard ? Tant que ces questions n'ont pas de réponse écrite, l'agent reste un pilote, aussi impressionnant soit-il.

À lire aussi Les agents IA ne doivent pas être un cauchemar de sécurité

SECTION 3

Quatre niveaux d'autonomie, quatre niveaux de contrôle

La gouvernance commence par une classification. Chaque agent reçoit un niveau, et le niveau dit quels contrôles s'appliquent. Un agent change de niveau quand on élargit ses droits, jamais en silence.

Nous reprenons les quatre niveaux d'autonomie proposés par Gartner. Chaque niveau reprend les contrôles du précédent et en ajoute. Nous y ajoutons une règle valable à tous les niveaux : certaines actions, par nature sensibles, exigent toujours une validation humaine.

Figure interactive : à consulter dans la version en ligne de l'article

Niveau 1 : observer

L'agent lit, recherche, résume. Il ne modifie rien, et seul le demandeur voit le résultat. Les contrôles : lecture seule sur des sources définies ; l'agent ne voit que ce que l'utilisateur a le droit de voir ; sources citées ; échanges journalisés ; pas de lien ni d'image sortants non filtrés, une protection contre l'injection d'instructions.

Niveau 2 : proposer

L'agent rédige un ticket, une réponse, une modification de code. Un humain décide. S'y ajoutent l'évaluation de la qualité avant la mise en service puis en continu (exactitude, hallucinations), la revue de chaque proposition (chez Adservio, l'IA code et l'ingénieur valide) et la formation des utilisateurs.

Niveau 3 : agir avec validation

L'agent exécute lui-même l'action, mais seulement après l'accord explicite d'un humain, action par action. S'y ajoutent une identité technique propre à l'agent, des droits accordés action par action, une action présentée de façon lisible avant validation (différence, destinataires, volume) et le suivi de la fatigue de validation (taux de refus, délai de réponse, contrôles par échantillon).

Niveau 4 : agir en autonomie

L'agent agit seul dans des garde-fous ; l'humain revoit après coup les exceptions et les journaux. S'y ajoutent un périmètre et des interdits vérifiés par l'interface, pas par l'agent, des plafonds de coût et de volume, une exécution isolée, un retour arrière prévu, un arrêt d'urgence testé et des critères écrits pour monter ou descendre de niveau.

Une règle valable à tous les niveaux : les actions sensibles

Une configuration de production, une donnée réglementée ou un envoi vers l'extérieur exigent une validation humaine, quel que soit le niveau. Plus l'action est critique, plus la validation monte : un manager pour un envoi externe, deux validations croisées pour une donnée de facturation. Une suppression est interdite par défaut ; une exception ponctuelle passe par la direction technique.

Une fiche par agent

Concrètement, chaque agent est décrit dans une fiche versionnée, au même titre que le code. Elle dit ce qu'il peut faire, ce qu'il ne fera jamais, et ce qui se passe quand une demande dépasse son mandat. Voici, à titre d'exemple, la fiche d'un agent de remédiation de niveau 4 : il ajuste seul le nombre d'instances de deux services, dans des bornes fixées, et escalade tout le reste.

# Tout ce qui n'est pas déclaré est interdit.
agent: remediation-incidents
version: 1.3.0
niveau: 4                          # agir en autonomie dans des garde-fous
responsable: prenom.nom            # personne nommée qui porte le mandat
equipe: sre
date_revue: 2026-12-15
identite: sa-agent-remediation     # compte de service dédié, jamais celui d'un humain
modele: nom-et-version-du-modele   # inscrit au registre

donnees:
  accessibles: [journaux-applicatifs, metriques]
  sensibilite_max: interne

outils:
  - id: lire_journaux
    acces: lecture
  - id: ajuster_instances
    acces: ecriture
    cibles: [api-commandes, worker-factures]
    environnements: [production]
    bornes: {min: 2, max: 6}
    reversible: true
    validation_humaine: false      # réversible, dans les bornes et sous les plafonds

garde_fous:                        # vérifiés par l'interface, pas par l'agent
  fenetre: "lun-ven 07:00-20:00 Europe/Paris"
  plafonds:
    actions_par_heure: 10
    cout_quotidien_eur: 50

hors_mandat:
  repli: escalade_humaine          # la décision remonte à l'astreinte
  canal: astreinte-sre

arret_urgence:
  qui: [astreinte-sre, responsable]
  delai_max: 5 min
  dernier_test: 2026-09-30

tracage:
  appels_outils: complet
  session: complete                # contexte, version du modèle, appels et réponses
  conservation: 90 jours
  donnees_personnelles: masquees

evolution:
  observation_min: 30 jours
  monter_si: [aucune action hors périmètre, taux de succès >= 99 %]
  descendre_si: [plafond atteint, action refusée par l'interface]

Les dernières sections comptent autant que les premières : un agent dont on sait qui l'arrête, en combien de temps, et ce qu'il fait d'une demande hors mandat est un agent que l'on peut laisser travailler.

L'autonomie se mérite

Le niveau d'un agent n'est pas figé. Il s'élargit quand l'agent a atteint, sur une période d'observation, des critères écrits à l'avance. Il se réduit dès qu'il franchit une limite : plafond atteint, action refusée par l'interface. C'est la traçabilité qui rend cette progression possible : sans traces, aucune preuve, donc aucune raison d'élargir.

SECTION 4

Comment nous gouvernons les agents

La grille ne suffit pas sans les mécanismes qui la font respecter. Voici les mécanismes que nous recommandons et que nous mettons en place sur nos projets d'agents.

Figure interactive : à consulter dans la version en ligne de l'article

Un registre : ce qui n'est pas déclaré ne s'exécute pas

Un plan de contrôle (control plane), par exemple une passerelle par laquelle passent tous les appels aux modèles et aux outils, tient le référentiel des modèles et outils autorisés, classe les données par sensibilité et suit les usages et les coûts, agent par agent. Un agent ou un outil absent du registre reste bloqué.

Une identité par agent

Chaque agent agit sous un compte de service qui lui est propre, avec ses seuls droits. Il n'emprunte jamais le compte d'un humain, et ses secrets sont gérés comme ceux d'une application.

Des interfaces révocables

L'agent n'interroge pas une base directement. Il passe par une interface, une API existante, un serveur MCP ou un connecteur dédié, qui porte les permissions, journalise les appels et peut être révoquée sans toucher à l'agent. Retirer un droit devient une opération de quelques secondes, pas un redéploiement. Retirer un droit n'interrompt pas une session déjà en cours : c'est le rôle de l'arrêt d'urgence, décrit plus bas.

Évaluer avant de promouvoir

Avant de monter de niveau, un agent passe une batterie de tests sur des cas réels et des cas pièges, dont des tentatives d'injection d'instructions.

Enregistrer pour pouvoir expliquer

Chaque session est enregistrée en entier : contexte, version du modèle, appels d'outils et leurs réponses. Une décision prise il y a six semaines se reconstitue à partir de ces traces, et peut être rejouée en environnement de test, au lieu d'être reconstituée de mémoire. Les traces peuvent contenir des données personnelles : elles sont minimisées, masquées quand c'est possible et conservées pour une durée définie.

Surveiller et réagir

Une alerte se déclenche quand un agent s'écarte de son comportement habituel (volume, coût, refus de l'interface). Un incident d'agent suit le même processus qu'un incident de production.

Un arrêt prévu dès la conception

Un agent doit pouvoir être arrêté rapidement, et sa fiche comme ses configurations sont versionnées pour revenir à l'état précédent. Ces mécanismes ne valent que s'ils sont exercés : nous les testons comme on teste un plan de reprise.

SECTION 5

Et la réglementation ?

Un agent n'est pas un système « à haut risque » par nature au sens de l'AI Act : tout dépend de l'usage. Un agent qui trie des candidatures ou qui intervient dans l'octroi d'un crédit relève de règles renforcées ; ce n'est pas le cas d'un agent qui résume la documentation interne. Dès qu'un agent échange avec des personnes, l'AI Act impose de leur indiquer qu'elles interagissent avec une IA (article 50). Si l'agent prend seul une décision qui produit des effets juridiques pour une personne ou l'affecte de manière significative, l'article 22 du RGPD s'applique : une telle décision n'est permise que dans des cas précis, et la personne peut obtenir une intervention humaine. Un auditeur, un client ou une autorité attendront pourtant toujours la même chose : savoir ce que fait l'agent, avec quels droits et sur quelles données. Les traces tenues dès le premier jour y répondent.

À lire aussi NIS2, DORA, AI Act : pourquoi la conformité cyber devient un enjeu business en 2026-2027

SECTION 6

Six erreurs à éviter

• Une gouvernance uniforme : les mêmes contrôles pour tous les agents, trop lourds pour les uns, trop légers pour les autres.
• Des agents fantômes : construits par les équipes en dehors de tout programme, absents du registre, donc invisibles.
• Des droits empruntés à un humain : un agent qui agit avec le compte d'un administrateur hérite de tous ses droits.
• Élargir les droits en silence : un outil ajouté sans revoir ni le niveau de l'agent, ni ses contrôles.
• Des sessions non enregistrées : sans traces exploitables, une erreur ne s'explique pas et ne se corrige pas.
• Un arrêt d'urgence jamais testé : le jour où il faut arrêter l'agent, personne ne sait comment.

SECTION 7

Par où commencer

Trois gestes permettent de savoir où en est votre organisation, avant d'investir davantage dans les agents :

1. Inventorier les agents existants, y compris ceux construits par les équipes en dehors de tout programme.

2. Classer chacun selon son niveau d'autonomie, en partant de ce qu'il a réellement le droit de faire, pas de ce qu'il fait d'habitude.

3. Aligner les contrôles sur le niveau, en allégeant ceux des agents simples autant qu'en renforçant ceux des agents autonomes.

SECTION 8

Comment Adservio vous accompagne

C'est la démarche de notre offre Agents IA : des agents qui spécifient, codent, testent et documentent sur tout le cycle de livraison, encadrés par des garde-fous à plusieurs niveaux. Nous les construisons avec l'Agentic Spec-Driven Development, en quatre temps : spécifier, planifier, découper, implémenter. L'IA propose la trajectoire, l'ingénieur arbitre ; l'IA code, l'ingénieur valide.

Concrètement, nous intervenons à trois moments : l'inventaire et la classification de vos agents existants, la mise en place du registre, des interfaces et de l'enregistrement des sessions, puis l'accompagnement des équipes à mesure que les agents gagnent des niveaux.

SECTION 9

En résumé

Les agents IA échouent rarement à cause du modèle. Ils échouent le plus souvent quand leurs contrôles ne correspondent pas à ce qu'ils ont le droit de faire. Classer chaque agent selon son niveau d'autonomie, déclarer ses droits dans une fiche, tracer chacune de ses actions et pouvoir l'arrêter à tout moment : c'est ce qui sépare un agent qui passe en production de celui que l'on débranche.

FAQ

Questions fréquentes

SOURCES