IA agentique vs IA générative : ce qui change pour la gouvernance

L’essentiel

• L’IA générative produit un résultat que vous relisez. L’IA agentique produit un acte déjà accompli au moment où vous le découvrez. Tout le reste découle de ce décalage.
• Les agents ne constituent pas une catégorie juridique nouvelle : l’article 3, paragraphe 1 du règlement européen sur l’IA vise déjà les systèmes dotés de « différents niveaux d’autonomie ».
• La frontière entre IA agentique et IA générative est un dégradé, non un interrupteur. Gouvernez-la par degré d’agentivité : accès aux outils, mémoire, planification autonome, effet non relu, délégation entre agents.
• Votre cartographie des risques change de nature. L’injection de prompt cesse d’être un problème de texte pour devenir un problème de transaction non autorisée.
• Votre dossier de preuve change lui aussi : les journaux de prompts ne suffisent plus, l’auditeur réclamera les journaux d’actions, l’identité sous laquelle l’agent a agi et la preuve que le mécanisme d’arrêt fonctionne.

IA agentique vs IA générative : la différence qui déplace vos obligations

Demandez à un éditeur d’expliquer l’IA agentique et vous obtiendrez partout la même phrase : l’IA générative crée du contenu, l’IA agentique accomplit des actions. La formule est exacte. Elle ne sert à rien à qui doit valider une mise en production. La version utile est plus resserrée. L’IA générative dépose un brouillon devant une personne, et c’est cette personne qui décide s’il devient réel. L’IA agentique referme cet intervalle : elle planifie une séquence, appelle un outil, écrit dans un système de gestion, puis rend compte. Le résultat et l’effet arrivent ensemble. Or tout ce sur quoi reposait discrètement la gouvernance se logeait précisément dans cet intervalle : l’étape de relecture, la trace de validation, la possibilité de rattraper une réponse fausse avant qu’elle ne coûte quelque chose. Supprimez l’intervalle et les contrôles ne tombent pas bruyamment. Ils cessent simplement de se trouver là où se trouve le risque. Le législateur européen ne s’y est pas trompé. L’article 3, paragraphe 1 définit un système d’IA comme un système automatisé fonctionnant avec différents niveaux d’autonomie et déduisant des sorties qui influencent des environnements physiques ou virtuels. L’autonomie figure dans la définition elle-même. Un agent n’est pas un objet juridique inédit : c’est le même objet, curseur poussé plus loin. Les obligations ne changent donc pas d’identité, elles changent de poids.

La pile de capacités qui crée l’écart

L’Agentic Security Initiative de l’OWASP décrit un agent à travers quatre capacités : planification et raisonnement, mémoire et persistance d’état, usage d’outils, action. Chacune constitue autant une surface de gouvernance qu’une surface technique.

• La planification signifie que le système a choisi des étapes que vous n’aviez pas énumérées. Une analyse de risques bâtie sur une liste exhaustive de comportements attendus ne tient plus.
• La mémoire signifie que l’état persiste d’une exécution à l’autre. Une entrée corrompue peut donc modifier le comportement longtemps après la fermeture de la session qui l’a introduite.
• L’usage d’outils signifie que le rayon d’action correspond à ce que permettent les habilitations, non à ce que permet la zone de saisie.
• L’action signifie que l’effet est réel avant d’être relu.

Un modèle d’IA générative possède la première capacité sous une forme faible et aucune des trois autres. Voilà tout l’écart. Chacune des sections qui suivent n’en est qu’une conséquence.

Le test des cinq questions : votre déploiement a-t-il basculé ?

Rares sont les équipes qui décident de construire un agent. Elles ajoutent un appel d’outil à un assistant conversationnel, puis une boucle de reprise, puis un ordonnanceur, et un sprint plus tard la chose écrit en production. Le basculement relève rarement d’une décision, ce qui explique qu’il déclenche rarement une revue de gouvernance. Passez ces cinq questions sur chacun de vos déploiements.

1. Peut-il appeler un outil, une API ou une base sans qu’un humain valide cet appel précis ? Si oui, votre point de contrôle s’est déplacé de la sortie vers l’habilitation.
2. Conserve-t-il un état entre les étapes ou les sessions, capable de modifier son comportement ultérieur ? Si oui, vous détenez un actif corruptible, qui appelle des contrôles d’intégrité et pas seulement des contrôles d’accès.
3. A-t-il décomposé l’objectif en étapes que vous n’aviez pas définies ? Si oui, votre analyse de risques ne peut plus procéder comportement par comportement, elle doit procéder frontière par frontière.
4. Sa sortie peut-elle produire effet sans relecture humaine préalable ? Si oui, la supervision devient un problème de conception et non plus un problème de processus.
5. Transmet-il du travail à un autre agent, ou en reçoit-il ? Si oui, vous gouvernez un système, et les défaillances intéressantes se logent dans l’interaction plutôt que dans un composant isolé.

Un « oui » ne constitue pas une alerte. Cinq « oui » décrivent un système différent de celui que documente votre dossier technique. Le cadrage le plus solide vient du Center for Long-Term Cybersecurity de l’université de Berkeley, dont l’Agentic AI Risk-Management Standards Profile soutient que la gouvernance doit croître avec le degré d’agentivité plutôt que traiter l’autonomie comme un attribut binaire. Notez le score des cinq réponses, inscrivez-le au registre, et laissez-le commander la lourdeur des contrôles. Une case « autonome : oui ou non » ne résistera pas à la réalité d’un portefeuille. C’est aussi là que le shadow AI cesse d’être un problème de découverte pour devenir un problème de classification. Une équipe ayant déclaré son outil comme « assistant de rédaction » il y a dix-huit mois ne redéposera pas spontanément sa fiche parce que quelqu’un a activé les appels de fonction.

Ce qui change dans la classification

C’est ici que la distinction produit sa première conséquence juridique concrète, et elle survient sur deux axes simultanés. L’analyse de The Future Society consacrée à la façon dont le règlement atteint les agents, Ahead of the Curve (Oueslati et Staes-Polet, 2025), expose les deux. Le chapitre V atteint le modèle d’usage général situé sous l’agent : les fournisseurs de modèles présentant un risque systémique doivent évaluer et atténuer les risques nés de l’intégration de ces modèles dans des systèmes agentiques. Le chapitre III atteint le système agentique lui-même, par la classification à haut risque. Trois conséquences en découlent, et chacune surprend quelqu’un. D’abord, la qualification d’un agent polyvalent en système à haut risque demeure réellement incertaine. L’annexe III a été rédigée avant que les risques agentiques ne soient bien compris, et un agent que l’on peut pointer vers de nombreuses tâches peut entrer dans le champ par défaut, sauf exclusion délibérée des usages à haut risque par le fournisseur. Exclusion délibérée signifie documentée et techniquement appliquée, non une ligne dans une charte d’usage. Si vous instruisez ce point, partez de la méthode de classification des systèmes à haut risque et appliquez-la à l’usage le plus large que l’agent peut atteindre, non à l’usage prévu. Ensuite, l’échafaudage que vous ajoutez peut changer votre qualité juridique. Envelopper un modèle d’IA à usage général dans une couche de récupération documentaire, un cadre d’orchestration et une boîte à outils peut constituer une modification substantielle, laquelle fait basculer des obligations de fournisseur sur une équipe qui avait budgété des obligations de déployeur. La facture de conformité diffère alors sensiblement, et elle atterrit d’ordinaire sur un groupe d’ingénierie qui n’a jamais ouvert le chapitre V. Enfin, la classification doit être refaite. Une capacité agentique ajoutée à un déploiement génératif existant n’est pas une montée de version : c’est un nouveau système au sens de la classification, et le travail de conformité repart de l’analyse de risques plutôt que de reprendre au dernier visa.

Ce qui change dans la supervision humaine

L’article 14 impose que les systèmes à haut risque soient conçus de manière à pouvoir être effectivement supervisés par des personnes physiques, avec des mesures proportionnées aux risques, au degré d’autonomie et au contexte d’utilisation. Lisez cette disposition en pensant à un agent et la difficulté saute aux yeux : le texte accroît ses exigences à mesure que croît précisément la propriété qui rend ces exigences difficiles à satisfaire. La supervision d’un système génératif coûte peu parce qu’elle est synchrone : quelqu’un lit, puis agit. La supervision d’un système agentique coûte cher parce que l’action a déjà eu lieu. Elle doit donc être conçue dans le chemin d’exécution, et non posée par-dessus. Trois évolutions concrètes pour la supervision humaine au sens de l’article 14. Le point de contrôle remplace la relecture. La supervision passe de la lecture d’une sortie à l’autorisation préalable de catégories d’actions et à l’interruption d’actions précises en cours d’exécution. Il s’agit d’un modèle d’habilitations, qui mérite autant de soin de conception que le prompt lui-même. Le mode de supervision se déplace, mais pas partout. Passer du human-in-the-loop au human-on-the-loop constitue le bon arbitrage pour des traitements à fort volume et faible conséquence. C’est le mauvais arbitrage lorsqu’une décision produit des effets juridiques ou significatifs pour une personne, car l’article 22 du RGPD continue d’encadrer la décision entièrement automatisée, indépendamment de la qualification retenue au titre du règlement sur l’IA. La CNIL a d’ailleurs rappelé à plusieurs reprises que l’intervention humaine invoquée doit être réelle et pourvue d’un pouvoir de modification. La supervision doit survivre à son propre volume. L’OWASP range ce point en T10, Overwhelming Human-in-the-Loop, et c’est le plus sous-estimé de la liste. Une file de validation qu’un relecteur écoule au rythme de quatre cents éléments par heure n’est pas une supervision : c’est un tampon assorti d’une piste d’audit. Lorsqu’un contrôle repose sur une attention que la cadence rend impossible, le contrôle a déjà échoué, et vos preuves documenteront cet échec.

Ce qui change dans la cartographie des risques

C’est la section que la plupart des comparatifs sautent, et celle où la différence cesse d’être conceptuelle. Les modes de défaillance ne s’aggravent pas : ils changent de catégorie. Une cartographie générative porte surtout sur ce que le système dit : hallucination, fuite de confidentialité, sortie discriminatoire ou toxique, injection de prompt comme problème de contenu. Une cartographie agentique porte sur ce que le système fait. La taxonomie OWASP recense quinze menaces agentiques, parmi lesquelles l’empoisonnement de mémoire, le détournement d’outils, la compromission de privilèges, l’hallucination en cascade, la manipulation d’objectif, la répudiation et l’absence de traçabilité, ainsi que les agents devenus incontrôlables au sein d’un système multi-agents. La phrase à porter devant votre comité des risques tient en une ligne : l’injection de prompt cesse d’être un problème de mauvaise phrase pour devenir un problème de transaction non autorisée. Même attaque, autre classe de conséquence, autre propriétaire. <table header-row= »true »> <tr> <td>Mode de défaillance</td> <td>En IA générative</td> <td>En IA agentique</td> <td>Ce que devient le contrôle</td> </tr> <tr> <td>Injection de prompt</td> <td>Texte hors politique ou embarrassant</td> <td>Appel d’outil non autorisé, exfiltration, exécution de code</td> <td>Frontières de confiance en entrée et habilitations d’outils au moindre privilège</td> </tr> <tr> <td>Hallucination</td> <td>Une affirmation fausse qu’un relecteur intercepte</td> <td>Une action fausse déjà exécutée, puis prolongée par les étapes suivantes</td> <td>Validation des actions et réversibilité, pas seulement relecture</td> </tr> <tr> <td>Fuite de données</td> <td>Du texte sensible dans une réponse</td> <td>Des données déplacées entre systèmes par l’agent lui-même</td> <td>Contrôle des flux sortants au niveau de l’outil</td> </tr> <tr> <td>Corruption de mémoire</td> <td>Sans objet</td> <td>Un état empoisonné oriente le comportement sur plusieurs sessions</td> <td>Validation de la mémoire et cloisonnement des sessions</td> </tr> <tr> <td>Identité</td> <td>Un compte de service, un schéma d’appel</td> <td>Une identité non humaine agissant en continu sur plusieurs systèmes</td> <td>Identité d’agent, habilitations cantonnées, imputabilité complète</td> </tr> <tr> <td>Effet cumulatif</td> <td>Contenu à une réponse</td> <td>Défaillance en cascade entre étapes ou entre agents</td> <td>Évaluation au niveau système, coupe-circuits, confinement</td> </tr> </table> Le profil de Berkeley ajoute les risques de queue qui comptent aux degrés d’agentivité élevés : perte de contrôle, contournement de la supervision, désalignement trompeur, défaillances multi-agents en cascade. Il pose également un principe qui mérite d’entrer dans vos revues de conception : un système multi-agents doit être évalué agent par agent et collectivement, car les effets émergents d’interaction n’apparaissent pas aux tests unitaires. Sa recommandation la plus directe consiste à traiter un agent suffisamment capable comme non fiable et à le confiner en conséquence. Deux conséquences pratiques pour les dispositifs existants. Votre méthode de gestion des risques IA doit évaluer au niveau du système, faute de quoi l’évaluation agent par agent manquera les défaillances d’interaction. Et le red teaming IA doit viser la frontière des outils et le magasin de mémoire, pas seulement le prompt, puisque c’est par là qu’un agent se brise réellement.

Ce qui change dans les preuves à produire

La conformité n’est pas ce que vous croyez de votre système : c’est ce que vous savez montrer. Sur ce terrain les deux paradigmes divergent nettement, et les équipes découvrent généralement l’écart pendant un audit plutôt qu’avant. Pour un déploiement génératif, le dossier est connu : documentation du modèle, résultats d’évaluation, journaux de prompts et de sorties, trace de la relecture humaine. Pour un déploiement agentique, la tenue de registres prévue à l’article 12 doit porter bien davantage. Un auditeur qui reconstitue une seule décision d’agent a besoin de l’objectif confié, du plan produit, de chaque appel d’outil avec ses paramètres et son résultat, de l’identité sous laquelle l’agent a agi, de l’habilitation qui autorisait l’appel, du caractère réversible de l’action et de sa réversion éventuelle, ainsi que de l’emplacement du point de contrôle humain. L’OWASP classe l’incapacité à produire cet ensemble en T8, répudiation et absence de traçabilité, et la traite comme une menace de sécurité. C’est tout autant une défaillance de gouvernance. Si vous ne pouvez rattacher une action à un agent, à une version et à une habilitation, vous ne pouvez répondre ni à un régulateur, ni à un auditeur, ni à un demandeur, et c’est l’absence de journal qui devient le constat. Trois artefacts à ajouter, dont un déploiement génératif n’avait jamais eu besoin :

• Une décision documentée de lancement ou d’abandon avant déploiement, que le profil de Berkeley situe en Manage 1.1. Écrite, avec les conditions qui la renverseraient.
• La preuve que le chemin de désengagement fonctionne, testée et non affirmée. Un bouton d’arrêt que personne n’a tiré lors d’un exercice reste une intention de conception, pas un contrôle.
• Un inventaire des identités non humaines, afin que chaque action d’agent se résolve en une habilitation, un périmètre et un propriétaire.

C’est également le moment où votre documentation technique et votre procédure de signalement d’incident demandent une réécriture plutôt qu’une extension, l’une comme l’autre ayant été conçues autour d’un système qui produit des sorties et non des effets.

Ce qui change dans la chaîne de responsabilité

La difficulté la plus sérieuse n’est pas technique. The Future Society la nomme le problème des mains multiples : au moment où l’agent agit, tant de parties sont intervenues que la responsabilité se dilue, à moins que quelqu’un ne l’attribue délibérément. Trois acteurs, aux ressources, aux compétences et à l’information contextuelle asymétriques. Le fournisseur du modèle construit la capacité sous-jacente et les moyens techniques qui rendent la gouvernance possible. Le fournisseur du système agentique l’adapte à une finalité et fixe les bornes correspondantes. Le déployeur l’exécute sur des données réelles, des utilisateurs réels et des conséquences réelles. La surveillance en fournit l’illustration la plus nette. Le fournisseur du modèle doit construire une infrastructure de surveillance configurable. Le fournisseur du système doit régler des seuils d’alerte adaptés à l’usage. Le déployeur doit effectivement lire les alertes et y donner suite. L’un des trois agissant seul produit quelque chose qui ressemble à de la supervision sur un schéma et n’en est pas une en exploitation. Pour la plupart des organisations, la question pratique devient : qu’exiger d’un fournisseur qui vend un agent ? Quatre points relèvent du contrat : le schéma et la durée de conservation des journaux qui vous seront remis, la granularité à laquelle vous pouvez cantonner les habilitations de l’agent, le mécanisme de désengagement et sa latence mesurée, et l’obligation de notification lorsque le modèle ou l’échafaudage change sous vos pieds. Traitez ces éléments comme des points de due diligence fournisseurs au même titre que les questions de sécurité, car une évolution de capacité livrée silencieusement constitue un changement de classification que vous n’avez pas décidé. Ce qui ne se délègue pas, c’est l’obligation du déployeur. Le risque lié au contexte, la position au regard des droits fondamentaux et la conception de la supervision restent dans l’organisation qui exploite le système : c’est le fil conducteur de la responsabilité en matière d’IA dès que des agents entrent dans le parc.

La checklist de basculement

Dix actions lorsqu’un déploiement franchit la ligne. Chacune est vérifiable, ce qui importe davantage que son confort.

1. Refaire la classification sur l’usage le plus large atteignable, non sur l’usage prévu.
2. Inscrire un score de degré d’agentivité au registre et abandonner l’indicateur binaire d’autonomie.
3. Refaire l’analyse de risques au niveau du système, interactions entre agents comprises.
4. Déclarer chaque agent comme identité non humaine avec un propriétaire nommé.
5. Cantonner les habilitations d’outils au moindre privilège et fixer le rayon d’action délibérément plutôt qu’en héritage.
6. Instrumenter une journalisation par action portant objectif, plan, appel d’outil, identité et réversibilité.
7. Définir et tester le chemin de désengagement, et conserver la trace du test.
8. Reconcevoir le point de contrôle humain pour qu’il survive à la cadence de production.
9. Renégocier le contrat fournisseur sur les journaux, les habilitations, l’arrêt d’urgence et la notification de changement.
10. Étendre la procédure d’incident aux actions accomplies par l’agent, et pas seulement aux sorties produites.

Si votre organisation pilote cela dans des tableurs, l’étape agentique est généralement celle où le procédé cesse de fonctionner, la preuve devenant continue plutôt que périodique. C’est précisément le problème que résout une plateforme de gestion des risques IA.

Questions fréquentes

ChatGPT relève-t-il de l’IA générative ou de l’IA agentique ? Des deux, selon la configuration retenue. Utilisé comme interface conversationnelle renvoyant du texte à lire, il est génératif. Doté d’outils, de navigation, d’exécution de code ou de connecteurs, et autorisé à enchaîner des étapes vers un objectif, le même produit se comporte de façon agentique. C’est pourquoi la question ne se tranche pas au niveau d’un nom de produit, mais au niveau de votre paramétrage, de vos outils activés et de vos habilitations. Deux entreprises abonnées au même service peuvent ainsi supporter des obligations très différentes. Quelle différence entre un agent IA et l’IA agentique ? Le profil de Berkeley trace une ligne utile. Un agent IA désigne un modèle unique doté d’outils pour mener à bien une tâche circonscrite de bout en bout. L’IA agentique désigne un système de plusieurs agents coordonnés vers des objectifs plus larges. La distinction commande l’évaluation : un agent isolé s’évalue pour l’essentiel seul, alors qu’un système multi-agents doit s’évaluer agent par agent et collectivement, puisque les défaillances les plus lourdes émergent de l’interaction plutôt que d’un composant fautif. Pouvez-vous donner un exemple d’IA agentique ? Un assistant achats qui lit une facture entrante, la rapproche du bon de commande, interroge la fiche fournisseur, signale un écart et dépose une instruction de paiement approuvée dans le système financier. Chaque étape est banale. La combinaison est agentique parce que le système a planifié la séquence, mobilisé plusieurs outils et produit un effet financier sans qu’une personne ait validé ce paiement précis. La version générative du même assistant aurait rédigé une synthèse à l’attention d’un comptable. L’IA agentique est-elle à haut risque au sens du règlement européen ? Pas automatiquement, et pas du fait d’être agentique. La qualification dépend de la finalité, du rôle de composant de sécurité ou de l’appartenance à un domaine de l’annexe III. La complication tient à ce qu’un agent polyvalent peut atteindre de nombreuses finalités, et les analyses publiées soulignent qu’un tel système pourrait entrer dans le champ par défaut, sauf exclusion délibérée et démontrable des usages à haut risque. Classifiez au regard de ce que l’agent peut atteindre, et traitez l’exclusion comme un contrôle technique probant plutôt que comme une déclaration de politique. Faut-il une analyse de risques différente de celle d’une IA générative ? Oui, et pas seulement plus longue. Une analyse générative est essentiellement centrée sur la sortie : ce que le système pourrait dire et qui pourrait en souffrir. Une analyse agentique doit être centrée sur l’action et menée au niveau du système : ce que l’agent peut atteindre, ce qu’il peut modifier, ce qui se produit lorsqu’une étape échoue en cours de route, et comment les défaillances se cumulent entre étapes ou entre agents. Le profil de Berkeley rattache cette démarche aux fonctions du NIST AI RMF, ce qui permet à la plupart des organisations d’étendre une méthode existante plutôt que d’en adopter une nouvelle. Faut-il une charte IA distincte pour les agents ? Rarement un document séparé, mais la charte existante appelle de nouvelles clauses : qui peut accorder à un agent l’accès à un outil et sous quelle validation, quelles classes d’actions imposent toujours un point de contrôle humain, quelles exigences de journalisation et d’identité s’appliquent, et quel événement déclenche une reclassification lorsqu’une capacité agentique est activée. Intégrer ces clauses à votre charte IA préserve un document unique et opposable plutôt que deux textes concurrents.

Conclusion

Le comparatif que tout le monde publie est exact et s’arrête une marche trop tôt. L’IA générative crée, l’IA agentique agit, et la question intéressante porte sur ce que cela vous coûte. Cela coûte une reclassification, puisque l’ensemble des usages atteignables s’est élargi. Cela coûte une refonte de la supervision, puisque l’article 14 exige davantage à mesure que l’autonomie rend cette exigence plus difficile à satisfaire. Cela coûte une nouvelle cartographie des risques, puisque les modes de défaillance ont changé de catégorie. Cela coûte un dossier de preuve plus lourd, puisque l’auditeur demande désormais ce que le système a fait et sous quelle autorité. Cela coûte enfin une relation fournisseur renégociée, puisque la partie qui modifie la capacité est rarement celle qui en supporte la conséquence. Rien de tout cela ne plaide contre les agents. Tout cela plaide pour savoir précisément à quel moment vous en avez acquis un. Passez les cinq questions sur votre portefeuille ce trimestre, et mesurez la part qui a déjà franchi la ligne. Pour tenir la classification, la conception de la supervision, la cartographie des risques et la piste de preuve au même endroit plutôt que dans cinq tableurs, c’est la vocation d’AI Sigil.