Les systèmes d’IA agents, une forme d’intelligence artificielle qui peut planifier, invoquer des outils et compléter des parties d’un workflow avec une supervision humaine limitée, passent de l’expérimentation à l’utilisation de la production dans les entreprises, même lorsque les pratiques de gouvernance ont du mal à suivre le rythme.
L’écart entre ce que les agents peuvent faire et ce que les contrôles d’entreprise prennent en compte s’étend. Les agents qui faisaient autrefois apparaître des recommandations pour un examen humain initient désormais des workflows, modifient les configurations et transmettent le contexte à d’autres agents sans attendre l’approbation. Les équipes informatiques héritent de plus en plus de ces capacités en tant que fonctionnalités de plateforme par défaut, souvent avant que les politiques de gouvernance n’aient rattrapé.
Ce guide couvre les changements de capacité spécifiques, les modifications de cadre et les jalons réglementaires que les praticiens de l’informatique et de la sécurité peuvent évaluer par rapport à leur posture de gouvernance actuelle.
Pourquoi l’IA agentique évolue plus rapidement que la gouvernance d’entreprise ne peut suivre
L’IA agentique fait référence aux systèmes d’IA qui peuvent planifier, prendre des décisions et prendre des mesures de manière autonome pour atteindre les objectifs avec une intervention humaine minimale. Contrairement à l’IA traditionnelle qui répond aux invites, les systèmes agents décomposent les objectifs complexes, utilisent des outils externes et adaptent leur approche en fonction des résultats.
La plupart des déploiements de production aujourd’hui sont construits sur la base d’un grand modèle linguistique (LLM) comme base de raisonnement, avec des couches supplémentaires manipulant l’utilisation, la mémoire et l’orchestration des outils.
Comprendre cette architecture est important pour la gouvernance : la couche de raisonnement, la couche d’outils et la couche d’orchestration comportent chacune des profils de risque distincts.
Un facteur moins discuté, mais essentiel dans la gouvernance des agents, est la qualité et la rapidité des données sur lesquelles les agents s’appuient au moment de l’exécution.
À mesure que l’autonomie augmente, les décisions ne sont plus examinées étape par étape par les humains, ce qui signifie que des données inexactes ou obsolètes peuvent se traduire directement par des actions incorrectes. Ces cadres se concentrent généralement sur les permissions et l’auditabilité, mais la fraîcheur et l’exhaustivité des données sont des contrôles tout aussi importants.
L’écart entre ce que les systèmes agents peuvent faire et ce que la plupart des cadres de gouvernance d’entreprise prennent en compte augmente rapidement. L’adoption de l’IA d’entreprise s’accélère plus rapidement que de nombreux programmes de gouvernance conçus pour le gérer.
L’ novembre 2025 enquête de McKinsey a révélé que 62 % des personnes interrogées ont déclaré que leurs organisations expérimentaient au moins des agents d’IA, et 23 % ont déclaré qu’elles faisaient déjà évoluer un système d’IA agentique quelque part dans l’entreprise. La même enquête a révélé que la plupart des organisations en sont encore à la phase de pilotage, avec près des deux tiers ne mettant pas encore à l’échelle l’IA à l’échelle de l’entreprise, ce qui aide à expliquer pourquoi les programmes de gouvernance sont constamment en retard sur la courbe des capacités plutôt que de l’anticiper. Cela ne signifie pas que l’utilisation des agents est universelle, mais cela signifie que les équipes de supervision ne peuvent plus traiter l’IA agentique comme un problème uniquement futur.
Lorsque les agents peuvent initier des workflows d’approvisionnement, modifier des configurations ou faire remonter les demandes d’accès sans approbation humaine, la question de gouvernance change. Il ne s’agit plus seulement de savoir qui peut accéder à quelles données. Il s’agit de savoir quels processus autonomes peuvent déclencher quelles actions commerciales et dans quelles conditions.
Il s’agit d’un écart significatif par rapport aux générations antérieures d’assistants d’IA et même aux chatbots et interfaces conversationnelles qui les ont précédés, qui ont été conçus pour faire apparaître des recommandations et attendre une direction humaine. Les actes de la génération actuelle et les cadres de gouvernance doivent refléter cette distinction.
Les sections qui suivent couvrent les modifications de capacité spécifiques, les mises à jour du cadre et les jalons réglementaires que les équipes informatiques et de sécurité peuvent évaluer par rapport à leurs structures de gouvernance actuelles. Le fil commun à tous : les agents ne fonctionnent plus à la périphérie des processus métier. Ils sont intégrés dans les workflows de base qui stimulent l’approvisionnement, la gestion de la chaîne d’approvisionnement, les opérations de sécurité et la gestion de l’infrastructure.
Mises à jour des capacités du modèle et ce que l’autonomie étendue signifie pour le risque informatique
Plusieurs mises à jour de la plateforme au cours de l’année passée ont étendu ce que les agents peuvent faire sans intervention humaine. Les modèles d’IA sous-jacents qui alimentent ces agents sont également devenus plus capables de raisonner en plusieurs étapes, ce qui signifie que les mêmes limites de gouvernance qui étaient adéquates il y a douze mois peuvent ne plus contenir la gamme d’actions qu’un agent peut désormais prendre. Les versions modèles d’Anthropic, d’OpenAI et d’autres startups diverses ont spécifiquement mis en évidence des capacités étendues d’utilisation d’outils et de planification en plusieurs étapes comme objectifs de conception, des capacités qui se traduisent directement par une action autonome étendue dans les déploiements d’entreprise.
Du côté de la plateforme, les principaux fournisseurs réduisent la barrière au déploiement de la production. Microsoft positionne Copilot Studio comme une plateforme pour la création et la gestion d’agents, y compris des agents qui peuvent gérer des tâches ou des processus commerciaux de manière indépendante et participer à l’orchestration multi-agents. SAP décrit les agents Joule comme des agents sensibles aux processus métier qui automatisent les workflows à grande échelle et coordonnent les processus complexes entre les fonctions. L’implication de la gouvernance n’est pas que chaque workflow ERP est désormais entièrement autonome par défaut, mais que de plus en plus de plateformes d’entreprise rendent l’exécution des tâches axées sur les agents plus facile à configurer et à opérationnaliser.
Pour les équipes informatiques, les champs d’application des permissions des agents doivent désormais être définis au niveau du workflow, et pas uniquement au niveau d’accès aux données. La plupart des configurations IAM sont concernées par les permissions d’accès aux données par défaut, et les politiques régissant l’initiation du workflow ou l’exécution d’actions en chaîne sont rarement définies explicitement, même dans des environnements exécutant des plateformes d’identité modernes.
Une autre exigence émergente est la gouvernance de bout en bout tout au long du cycle de vie d’un workflow axé sur les agents. Le risque n’est pas introduit uniquement au moment de la décision, mais également dans la manière dont les informations sont générées, la manière dont les recommandations apparaissent et la manière dont les actions sont exécutées. Les systèmes qui séparent ces phases entre les outils peuvent rendre difficile la traçabilité de la manière dont une décision a entraîné un changement spécifique dans l’environnement.
La question de gouvernance pour toute capacité d’IA adjacente à une base de données est cohérente : dans quelle mesure les données derrière une décision autonome sont-elles à jour, quelles couches de mise en cache ou de réplication se trouvent sur le chemin, et cette latence est-elle acceptable pour le workflow automatisé ? Ces questions s’appliquent quel que soit le fournisseur.
Le modèle entre les mises à jour de la plateforme est cohérent. Les agents passent de rôles consultatifs (suggérant des actions que les humains doivent approuver) à des rôles d’exécution réels (prenant des actions dans les paramètres définis). Ce changement est en partie dû aux avancées dans l’ apprentissage automatique qui ont amélioré la capacité des agents à se généraliser à partir des modèles observés. La même capacité qui les rend plus utiles rend également leur comportement plus difficile à prédire à la périphérie de leur distribution de formation.
| Changement de capacité | Exemple | Écart de gouvernance créé |
|---|---|---|
| Initiation du workflow | Agents d’approvisionnement SAP | Les politiques IAM sont concernées par l’accès aux données, et non par les permissions de workflow |
| Requêtes de données en temps réel | Base de données Oracle AI | Décisions de l’agent basées sur des hypothèses de fraîcheur des données qui peuvent ne pas tenir |
| Actions chaînées | Agents de remédiation en plusieurs étapes | Des pistes d’audit qui capturent des actions individuelles mais manquent la chaîne de décision |
Implication pour l’entreprise : vérifiez si vos politiques IAM font la distinction entre les permissions d’accès aux données et les permissions d’initiation du workflow. Les agents opérant dans des périmètres d’accès « approuvés » peuvent toujours déclencher des actions commerciales en dehors des limites de gouvernance prévues. Il convient également de confirmer avec vos fournisseurs de plateforme, qu’ils soient des fournisseurs ERP, cloud ou d’endpoints, quelles capacités d’agent ont été activées par défaut dans les mises à jour récentes, car toutes les expansions de capacités ne sont pas communiquées via les canaux de notification de modification standard.
Avec l’expansion des capacités de modèle, la question suivante devient la manière dont les agents se coordonnent les uns avec les autres dans les environnements de production.
Changements de cadre et d’orchestration des agents affectant les déploiements d’entreprise
Les systèmes multi-agents, où les agents spécialisés se coordonnent pour gérer différents aspects des workflows complexes, passent des environnements de recherche aux environnements informatiques de production. Il ne s’agit pas de chaînes de tâches simples. Elles impliquent une logique décisionnelle de ramification, des escalades conditionnelles et un transfert de contexte inter-systèmes qui peuvent couvrir simultanément les opérations de sécurité, la gestion des services informatiques et les couches d’applications commerciales.
De nombreux déploiements d’entreprise précoces ont inséré des points de contrôle humains entre la détection, l’analyse et l’action. Ce qui change maintenant n’est pas l’existence de l’automatisation elle-même, mais la facilité avec laquelle les plateformes permettent aux équipes de coordonner plusieurs agents spécialisés au sein d’un seul workflow. Un agent qui détecte un problème peut désormais transmettre les résultats à un autre agent ou outil pour une analyse ou une action de suivi avec une orchestration moins personnalisée qu’auparavant.
Cela modifie le rayon d’explosion d’un agent mal configuré. Les erreurs ne s’arrêtent plus à une limite de tâche. Un agent de détection qui mal classifie un processus légitime peut déclencher un agent de remédiation qui met en quarantaine un système de production, le tout avant qu’un humain ne voie l’alerte.
De nombreuses plateformes cloud majeures rendent déjà les workflows coordonnés et multi-agents beaucoup plus accessibles. AWS a rendu la collaboration multi-agents généralement disponible pour Amazon Bedrock en mars 2025, puis Amazon Bedrock AgentCore, une plateforme modulaire de niveau entreprise pour déployer et gérer les agents de production, atteignant une disponibilité générale en octobre 2025.
Le modèle entre les fournisseurs est cohérent : les frais généraux d’infrastructure pour le déploiement multi-agents de production diminuent rapidement. À mesure que ces capacités deviennent plus faciles à déployer, les outils de gouvernance doivent suivre les chemins de délégation, la logique du superviseur, l’observabilité et la gestion des défaillances.
La supervision humaine dans les systèmes agents devient également de plus en plus granulaire. Plutôt qu’un simple modèle d’approbation ou de refus au début d’un workflow, les organisations définissent de plus en plus de points de contrôle au sein d’une séquence d’actions. Cela permet aux équipes d’examiner, de valider ou de remplacer des étapes spécifiques sans bloquer l’ensemble du workflow, en équilibrant vitesse et responsabilité.
Les cadres permettant ces transferts asynchrones, y compris les outils d’orchestration open source tels que LangGraph et AutoGen, réduisent également la barrière au déploiement de systèmes multi-agents, ce qui signifie que les équipes informatiques peuvent rencontrer des déploiements d’agents construits en dehors des plateformes d’entreprise sanctionnées. Les politiques de gouvernance doivent tenir compte des systèmes d’agent gérés par les fournisseurs et créés en interne.
La spécialisation verticale s’accélère également. Par exemple, Visa applique des modèles d’IA pour la détection des fraudes et la notation des risques dans les transactions de paiement, tandis que les plateformes de soins de santé spécialement conçues utilisent l’IA pour les workflows tels que la surveillance des substances contrôlées et la conformité clinique, des contextes où les exigences de précision spécifiques au domaine sont beaucoup plus strictes qu’un agent à usage général pourrait satisfaire de manière fiable.
Pour les décisions d’approvisionnement informatique, les agents à usage général peuvent offrir de la flexibilité, mais les systèmes spécialisés peuvent fournir une précision et une pertinence plus élevées dans des cas d’utilisation bien définis. Ce passage à l’optimisation spécifique au domaine affecte également la manière dont les équipes doivent évaluer l’efficacité des agents. La performance dans un périmètre de tâche défini est une référence plus significative que les scores de capacité généraux lors de l’évaluation de la préparation à la production.
Le même modèle émerge au-delà des logiciels. Les plateformes robotiques intègrent désormais des couches d’IA agentiques pour gérer le séquençage dynamique des tâches, allant au-delà des routines préprogrammées dans la prise de décision adaptative. Les fournisseurs d’infrastructure comme NVIDIA, dont les microservices NIM et la plateforme AI Enterprise sont de plus en plus utilisés pour déployer et exécuter des charges de travail d’agents à grande échelle, facilitent l’exécution de ces systèmes dans des environnements de production.
Pour les équipes de gouvernance, les deux tendances signifient que la portée de ce qui doit être pris en compte s’étend au-delà des agents hébergés dans le cloud aux déploiements accélérés par le matériel et physiquement intégrés également.
Implication pour l’entreprise : si vous exécutez ou évaluez des workflows multi-agents, vérifiez si vos outils de surveillance peuvent observer les transferts inter-agents. De nombreuses plateformes d’observabilité sont conçues pour les flux de demande initiés par l’utilisateur, et non pour le passage du signal d’agent à agent.
Les modifications d’orchestration affectent la manière dont les agents travaillent ensemble. La section suivante couvre spécifiquement ce qui change au niveau des endpoints et des opérations de sécurité.
Développements spécifiques aux endpoints et nouvelles surfaces d’attaque
Alors que l’automatisation alimentée par l’IA s’approfondit dans la gestion des endpoints et les opérations de sécurité, la surface d’attaque s’étend de manière que les outils de sécurité traditionnels n’ont pas été conçus pour surveiller. Au niveau de l’ endpoint et de la couche de réponse, les développements récents créent simultanément de nouvelles capacités et de nouveaux modèles de risque.
Dérive d’agent dans les environnements de production
La dérive de l’agent se produit lorsque les micro-décisions cumulées se cumulent dans les résultats que personne n’a prévus ou explicitement approuvés, distincte de l’hallucination du modèle, qui fait référence au modèle générant des sorties incorrectes. Le risque de dérive concerne souvent moins les sorties de modèle incorrectes que les workflows exécutés à l’intérieur des permissions qui étaient trop larges ou insuffisamment surveillés au fil du temps. Un modèle peut se comporter exactement comme prévu tout en déviant du périmètre prévu si les garde-fous autour du périmètre du workflow ne sont pas appliqués. Pour les praticiens, cela effectue des points d’approbation, une journalisation au niveau des étapes, des plans de restauration et un examen périodique des contrôles opérationnels de base des périmètres des agents.
L’écart de détection : examinez si votre journalisation et vos détections font la distinction entre les modifications initiées par l’homme, l’activité du compte de service et les actions déclenchées par l’agent. Si ce n’est pas le cas, l’activité de l’agent peut être plus difficile à suivre pendant un incident et plus facile à manquer pendant la surveillance de routine.
Étendue des informations d’identification à partir de l’accès persistant à l’agent
Ces systèmes nécessitent de plus en plus un accès persistant aux informations d’identification sur plusieurs systèmes pour exécuter leurs fonctions. Un agent de remédiation qui peut corriger les endpoints, mettre à jour les configurations et redémarrer les services nécessite des informations d’identification pour chaque action.
Les informations d’identification des agents ont souvent une portée plus large que n’importe quel utilisateur humain individuel, et elles sont actives en continu plutôt que pendant des heures de travail définies. En compensant cela, les agents s’authentifient fréquemment sur les API connectant les systèmes de gestion des endpoints, d’identité et d’applications métier, ce qui signifie qu’un seul compte de service compromis peut traverser plusieurs couches d’intégration simultanément. La plupart des cadres de gestion des accès privilégiés (PAM) n’étaient pas conçus pour gérer ce modèle.
Ces risques sont souvent amplifiés dans des environnements fragmentés. Lorsque les agents dépendent de sources de données, de plans de contrôle et de systèmes d’exécution différents, il devient difficile de maintenir une surveillance et une application cohérentes des politiques. Un modèle de données et d’exécution plus unifié peut réduire ces angles morts en s’assurant que les décisions, les actions et la surveillance fonctionnent toutes à partir de la même source de vérité.
Accès aux données au-delà des limites du système
Les agents qui interrogent des données provenant de plusieurs sources de données pour éclairer les décisions traversent les environnements de données de manière à créer des défis de visibilité. Une requête d’agent unique peut toucher la télémétrie des endpoints, les systèmes d’identité, les plateformes de business intelligence et les données d’applications commerciales.
Étant donné que les agents peuvent enchaîner les requêtes sur ces sources de manière autonome, la portée complète de ce qui a été accédé pour parvenir à une décision peut ne pas être visible dans le journal d’accès d’un seul système. La journalisation traditionnelle de l’accès aux données, conçue pour la visibilité application par application, peut ne pas capturer l’image complète de ce à quoi un agent a accédé pour prendre une décision.
La multiplication des outils d’IA sur l’endpoint
Un écart de gouvernance qui reçoit moins d’attention que la multiplication des informations d’identification ou l’accès aux données est plus simple et plus immédiat : la plupart des organisations ne disposent pas d’un inventaire précis des outils d’IA qui s’exécutent déjà dans leur environnement d’endpoint. Les modèles locaux en grandes langues, les serveurs MCP, les fichiers de modèle d’IA et les applications d’IA tierces peuvent être installés et exécutés sur les endpoints avant que les équipes informatiques ou de sécurité n’en aient une visibilité. Sans cet inventaire, les politiques de gouvernance n’ont aucune surface à appliquer.
Ce n’est pas un risque futur. Alors que les outils d’IA prolifèrent au niveau de la couche développeur et utilisateur de puissance, la surface d’attaque de l’IA sur l’endpoint s’étend indépendamment des déploiements sanctionnés. Les programmes de gouvernance qui se concentrent exclusivement sur les pipelines d’agents approuvés passeront à côté de l’exposition introduite par l’IA non autorisée qui s’exécute à leurs côtés.
Implication pour l’entreprise : la multiplication des outils d’IA et la multiplication des informations d’identification se mélangent. Vérifiez si vos règles de détection SIEM couvrent les comptes de service d’agent avec la même rigueur que les comptes d’utilisateur, et si votre inventaire d’endpoints capture désormais des artefacts spécifiques à l’IA parallèlement aux logiciels traditionnels. Si les modifications de configuration initiées par l’agent ne génèrent pas d’alertes, vous avez un écart de détection.
Mises à jour réglementaires et standard façonnant le déploiement de l’IA agentique
Les cadres réglementaires rattrapent les capacités d’IA agentique, et la phase d’application commence.
Étapes importantes de l’application de la loi européenne sur l’IA
Le régime basé sur les risques de la loi européenne sur l’IA peut s’appliquer aux systèmes d’IA utilisés dans des contextes couverts tels que l’infrastructure critique et l’emploi, mais le calendrier est important. La Loi est entrée en vigueur en 2024, et certaines dispositions ont commencé à s’appliquer en 2025. Pour les systèmes d’IA à haut risque, les obligations de déploiement et de journalisation les plus pertinentes pour la gouvernance d’entreprise sont actuellement planifiées pour s’appliquer sur 2 août 2026.
Le 7 mai 2026, les législateurs de l’UE ont conclu un accord politique sur l’Omnibus numérique, qui comprend un report de 16 mois pour les systèmes d’IA à haut risque nouveaux ou substantiellement modifiés répertoriés à l’Annexe III. L’adoption formelle est toujours en attente. Jusqu’à ce que la législation soit promulguée, les organisations doivent traiter août 2026 comme la date limite de planification opérationnelle et surveiller le processus Omnibus numérique pour les mises à jour.
Pour les équipes opérant dans des cas d’utilisation à haut risque couverts, le point à retenir à court terme le plus précis est le suivant :
- Journalisation et conservation : assurez-vous que le système peut générer des journaux et que les déployeurs peuvent conserver les journaux sous leur contrôle pendant la période requise
- Supervision humaine : affecter du personnel responsable et définir comment la supervision est exercée pendant l’utilisation
- Examen des cas d’utilisation et des risques : confirmez si le déploiement relève d’une catégorie à haut risque et si des obligations supplémentaires s’appliquent avant l’utilisation en production
Mises à jour du RMF du NIST AI pour les systèmes autonomes
Le cadre de gestion des risques liés à l’IA du National Institute of Standards and Technology (NIST) reste le cadre volontaire principal que de nombreuses organisations utilisent pour guider la gouvernance de l’IA. Le NIST a étendu ses conseils grâce à des ressources telles que le Guide RMF de l’IA et les profils d’IA génératifs, en se concentrant de plus en plus sur la manière dont les systèmes d’IA se comportent dans les environnements de production.
Pour les équipes déployant des systèmes agents, le changement pratique est vers une supervision continue. La gouvernance ne concerne pas uniquement les tests préalables au déploiement. Cela nécessite une surveillance continue du comportement des agents, des données sur lesquelles ils s’appuient et de la manière dont les décisions se traduisent en actions au fil du temps.
Cela inclut la documentation des sources de données et des pipelines qui éclairent les décisions des agents, en particulier dans les environnements où les agents interrogent les systèmes en temps réel plutôt que les jeux de données statiques.
Pour les organisations utilisant le NIST comme référence, l’accent passe de « tester avant le déploiement » à « surveiller et valider après le déploiement ».
Implication pour l’entreprise : si votre déploiement automatise les actions à fort impact, documentez les procédures de restauration, les points d’approbation et les chemins d’escalade dès maintenant. Même lorsque la réglementation n’exige pas explicitement des « anneaux de déploiement », le rollback contrôlé est une protection opérationnelle de base et une contribution importante à l’auditabilité.
Comment évaluer si votre cadre de gouvernance a suivi le rythme
Compte tenu des développements couverts ci-dessus, les équipes informatiques et de sécurité peuvent évaluer leur posture de gouvernance actuelle par rapport à des critères spécifiques.
| Critère d’évaluation | Question de diagnostic | Risque s’il n’est pas traité |
|---|---|---|
| Fraîcheur des données décisionnelles | Les données sont-elles suffisamment actuelles pour la tolérance du workflow en matière de retard ou de dérive ? | Les agents peuvent agir selon des conditions qui n’existent plus ou qui n’ont plus d’importance |
| Contrôles de gouvernance | Les limites d’approbation des agents sont-elles documentées et appliquées par des politiques ? | Action autonome non contrôlée en dehors du champ d’application prévu |
| Déploiement progressif | Votre déploiement prend-il en charge le déploiement par étapes, les procédures de déploiement et les critères de progression définis ? | Élargir les échecs des modifications non testées à grande échelle |
| Intégration | Les agents peuvent-ils échanger du contexte avec les outils SIEM, ITSM et endpoint existants ? | Automatisation cloisonnée qui crée des angles morts |
| Auditabilité et traçabilité | Pouvez-vous reconstruire ce que l’agent a fait, quels outils ou données il a utilisés et quelles approbations ou points de contrôle ont été impliqués ? | Écarts de conformité, faible reconstruction des incidents et faible confiance des opérateurs |
À mesure que les organisations évaluent ces critères, il devient clair que la gouvernance n’est plus limitée aux définitions de politiques statiques. Cela dépend de la manière dont les décisions sont informées lors de l’exécution, de la manière dont les actions sont exécutées sur les systèmes et de la manière dont les résultats sont surveillés et validés.
Avant de travailler sur chaque critère, établissez des mesures de base pour vos déploiements d’agent actuels : combien de comptes de service d’agent sont actifs, combien de permissions au niveau du workflow ont été accordées et combien de modifications de configuration initiées par l’agent se sont produites au cours des 30 derniers jours. Sans ces références, les critères d’évaluation ci-dessous sont difficiles à respecter :
- Fraîcheur des données de décision : la principale considération est de savoir si les décisions de l’agent d’alimentation des données sont suffisamment actuelles pour l’action prise. Dans les environnements en évolution rapide, même de courts délais entre la collecte de données et l’exécution des agents peuvent produire des mesures correctives incorrectes ou inutiles, en particulier lorsqu’aucun humain n’examine les décisions en temps réel. Valider la latence réelle entre la fraîcheur des données et l’action de l’agent est une étape concrète que la plupart des équipes n’ont pas prise.
- Contrôles de gouvernance et supervision humaine : la question pratique va au-delà de la question de savoir s’il existe des limites d’approbation, mais si elles sont appliquées de manière cohérente au point d’exécution. De nombreuses organisations ont des modèles d’approbation informels ou partiellement mis en œuvre qui ne limitent pas complètement ce qu’un agent peut faire une fois qu’il commence un workflow.
- Intégration : les défis d’intégration concernent souvent moins la connectivité que la cohérence. Lorsque plusieurs systèmes sont impliqués dans les workflows des agents, les différences dans les modèles de données, les contrôles d’accès et la journalisation peuvent introduire des lacunes dans la visibilité et rendre difficile la traçabilité de la manière dont les décisions se traduisent en actions.
- Déploiement progressif et déploiement par étapes : lorsque les agents commencent à exécuter des modifications directement, la stratégie de déploiement devient partie intégrante de la gouvernance. Les déploiements progressifs, l’exécution par étapes et les critères de progression documentés peuvent servir de contrôles de sécurité qui limitent le rayon d’explosion des décisions incorrectes. Dans ce modèle, la conception du déploiement n’est pas seulement une préoccupation opérationnelle, mais également un mécanisme de gouvernance.
Une distinction à évaluer dans n’importe quelle plateforme est de savoir si le rollback nécessite une initiation humaine ou si le système peut déclencher automatiquement le rollback lorsque l’exécution échoue à la validation. La restauration automatique en cas de défaillance est un contrôle de gouvernance qualitativement différent. Il ferme la fenêtre entre une action échouée et une réponse humaine, ce qui est le plus important dans les environnements où les agents exécutent des modifications à la vitesse et à l’échelle.
Certaines plateformes commencent également à introduire des signaux de confiance liés aux recommandations et aux actions automatisées. Ces signaux peuvent aider les équipes à déterminer quand autoriser une exécution entièrement automatisée et quand nécessiter un examen humain supplémentaire. Bien qu’ils ne soient pas encore standardisés, les contrôles basés sur la confiance apparaissent comme un moyen de rendre le comportement des agents plus prévisible et vérifiable.
Ce que les équipes informatiques et de sécurité peuvent prioriser dans les 90 prochains jours
Compte tenu des développements couverts dans ce guide, voici les mesures spécifiques que les équipes informatiques et de sécurité peuvent prendre à court terme. Ces sept actions sont tactiques, mais elles doivent également éclairer un examen plus large de la stratégie d’IA.
- Champs d’application des permissions de l’agent d’audit par rapport aux politiques IAM. Vérifiez les permissions au niveau du workflow désormais requises par les agents autonomes ERP et endpoint. La plupart des configurations IAM sont concernées par l’accès aux données, et non par l’initiation du workflow.
- Passez en revue les règles de détection SIEM pour les comptes de service d’agent. Si les règles de détection sont définies pour les comptes d’utilisateur, les modifications de configuration initiées par l’agent peuvent ne pas générer d’alertes.
- Documentez les procédures de restauration, les points d’approbation et les chemins d’escalade pour les workflows d’agent à fort impact. Le déploiement contrôlé et le déploiement sont des garanties opérationnelles essentielles, indépendamment des exigences réglementaires, et pour les déploiements qui relèvent des dispositions à haut risque de la loi de l’UE sur l’IA, ils soutiennent directement la documentation d’auditabilité requise par ces obligations.
- Évaluer la couverture de surveillance pour les transferts inter-agents. Si vous exécutez des workflows multi-agents, vérifiez si les outils d’observabilité peuvent suivre le contexte passant d’un agent à l’autre.
- Confirmez les hypothèses de fraîcheur des données pour les décisions des agents. Pour tout agent prenant des décisions autonomes en fonction de l’endpoint ou de l’état du système, vérifiez à quel point ces données sont réellement récentes.
- Identifiez où les workflows d’informations sur l’action franchissent les limites des outils. Si plusieurs systèmes sont impliqués dans la découverte, la décision et l’exécution, confirmez comment ces transitions sont régies, consignées et surveillées.
- Identités d’agent d’inventaire et comptes de service. Documentez les agents qui peuvent appeler quels outils, sous quelles informations d’identification et avec quelles limites d’approbation ou de RBAC. C’est souvent le moyen le plus rapide de faire apparaître un accès trop large avant qu’il ne se transforme en problème de gouvernance.
Si la documentation de gouvernance de l’IA de votre organisation a été écrite avant que les capacités d’agent ne soient entrées dans les niveaux de plateforme par défaut, elle ne tient probablement pas compte des permissions au niveau du workflow, des transferts multi-agents ou des exigences de documentation de l’UE. L’AI Act, qui sont toutes désormais des préoccupations opérationnelles, et non des considérations futures.
Pris ensemble, ces lacunes mettent en évidence un défi plus large : la gouvernance n’est plus seulement un exercice de politique. Cela dépend d’avoir des données précises et actuelles, de la capacité à agir sur ces données dans des workflows contrôlés et de la visibilité pour comprendre ce que les systèmes autonomes font en temps réel dans l’ensemble de l’environnement.
Comment Tanium soutient la gouvernance de l’IA agentique
La Tanium Autonomous IT Platform fournit des informations en temps réel sur les endpoints et une exécution régie pour les opérations informatiques et de sécurité, fournissant la couche de données et de contrôle dont dépendent les workflows assistés par IA et agents.
Cette base combine l’intelligence en temps réel des endpoints avec l’architecture de chaîne linéaire brevetée de Tanium, ainsi que la confiance et le score de risque, le déploiement progressif basé sur l’anneau et des intégrations approfondies. En plus de cette base, Tanium ajoute des requêtes en langage naturel, des workflows agents avec des contrôles humains dans la boucle et une supervision centralisée de l’activité autonome.
Tanium Atlas, le système d’exploitation autonome, réunit ces bases en une expérience unique et régie où l’intelligence, les conseils et l’action fonctionnent au sein du même workflow. Alors que l’écosystème de l’IA agentique continue d’évoluer, Tanium étend cette base afin que les organisations puissent maintenir la visibilité, appliquer la gouvernance et agir en toute confiance à mesure que les systèmes deviennent plus autonomes.
L’efficacité de l’IA agentique dans les opérations informatiques et de sécurité dépend moins de la sophistication du modèle et plus de la confiance qu’elle peut avoir pour passer d’une vision à une action dans des contraintes définies. Les systèmes qui connectent les données en temps réel, l’exécution régie et les résultats observables dans un workflow unique sont mieux positionnés pour prendre en charge une automatisation sûre et évolutive.
- Les informations en temps réel sur les endpoints aident les équipes à prendre des décisions assistées par IA dans l’état actuel des appareils. Tanium Ask utilise des interactions en langage naturel pour faire ressortir les informations et soutenir les enquêtes. De plus, l’ agent Tanium Ask étend cela à l’action en prenant en charge des workflows automatisés et humains dans la boucle pour la découverte de données, la gestion des logiciels, etc.
- Les contrôles humains dans la boucle sont intégrés dans des actions sensibles. L’agent Tanium Ask maintient la supervision humaine tout au long des workflows agents, nécessitant une confirmation avant les actions qui affectent directement les endpoints ou les configurations Tanium. Les administrateurs peuvent superviser, approuver et annuler les modifications, ce qui permet aux équipes de garder le contrôle sur ce que la plateforme fait en leur nom.
- Le score de confiance prend en charge le déploiement contrôlé des modifications automatisées. Un déploiement progressif avec des scores de confiance donne aux organisations un mécanisme pour mettre en place des changements et évaluer l’impact potentiel avant une exécution large.
- La supervision centralisée de l’activité autonome fournit une couche de gouvernance unifiée. Tanium Action Oversight fournit un reporting système continu et une visibilité sur l’état actuel de l’activité autonome sur la plateforme. Plutôt que de s’appuyer sur des journaux de module individuels ou une surveillance ad hoc, chaque système est lié à ce composant de gouvernance centralisée, offrant aux équipes informatiques et de sécurité une vue unifiée de ce que la plateforme fait de manière autonome, à quelle portée et dans quelles conditions.
- L’orchestration basée sur les playbooks prend en charge les workflows régis et reproductibles. Tanium Automate permet aux équipes de créer des playbooks qui relient les actions en séquences logiques et reproductibles avec peu ou pas de code pour automatiser les tâches courantes telles que l’application de correctifs, la remédiation des vulnérabilités et le déploiement d’applications. Grâce aux déploiements progressifs et à la supervision des utilisateurs intégrés au workflow, les équipes peuvent limiter l’impact des erreurs et contrôler la manière dont l’automatisation évolue dans les environnements de production.
- La gestion proactive des vulnérabilités aide à réduire les risques en aval dans les environnements automatisés. Tanium Guardian informe automatiquement les équipes des problèmes émergents, y compris les vulnérabilités zero-day, et fournit des actions recommandées aux opérateurs. Le contenu et les informations de Guardian sont préparés par l’équipe d’intervention d’urgence en cas de vulnérabilité (Vulnerability Emergency Response Team, VERT) de Tanium, une collaboration dirigée par Tanium entre les experts en sécurité, les partenaires du secteur et les clients de Tanium.
- Les opérations informatiques et de sécurité unifiées peuvent réduire les angles morts de la surveillance. Tanium Threat Response surveille l’activité des endpoints en temps réel, prend en charge la recherche des menaces et utilise Tanium Signals pour la détection et l’alerte continues. Étant donné que les enquêtes et les réponses s’exécutent sur la même plateforme, les équipes peuvent créer et ajuster des détections sans changer de contexte ou d’outils.
Cette approche reflète l’avantage opérationnel de traiter ensemble la gouvernance au niveau des données et de la couche d’exécution. Une approche de bout en bout couvrant la collecte de données en temps réel, l’exécution régie des workflows, la génération de pistes d’audit et la détection unifiée est ce qui sépare les cadres de gouvernance qui peuvent évoluer avec l’IA agentique de ceux qui créent de nouveaux angles morts à mesure que les capacités des agents se développent.
Lorsque les agents travaillent à partir de l’état actuel des endpoints, fonctionnent dans des workflows vérifiables et déclenchent des alertes via une couverture de détection unifiée, l’écart de supervision qui rend l’IA agentique risquée devient adressable plutôt que supposé.
À mesure que l’IA agentique s’étend dans les environnements d’endpoints, les défis de visibilité passent des listes d’applications au comportement d’exécution, aux modèles locaux et aux cadres d’agents intégrés. Cette vidéo fournit un aperçu pratique de la manière dont ces risques apparaissent et comment les équipes peuvent commencer à les catégoriser et à les surveiller à l’aide de Tanium.
Foire aux questions sur les progrès de l’IA agentique
Toujours trier ce que l’IA agentique signifie et comment elle affecte votre environnement ? Ces réponses rapides décomposent les questions les plus courantes que les équipes posent actuellement à mesure que les capacités évoluent et que les attentes en matière de gouvernance rattrapent le retard. Utilisez-les pour clarifier ce qui change, ce que cela signifie pour votre posture de risque et où vous concentrer ensuite.
Quelles sont les dernières innovations en matière d’IA agentique ?
L’IA agentique va au-delà de l’assistance de type chat vers des systèmes qui peuvent planifier, utiliser des outils et effectuer des workflows en plusieurs étapes. Les lancements récents de fournisseurs auprès d’entreprises telles que SAP, Microsoft, AWS et Oracle montrent que les entreprises disposent désormais d’un plus grand nombre d’options prêtes à l’emploi pour créer et coordonner des agents, mais la plupart des organisations en sont encore au stade précoce de leur mise à l’échelle.
Pourquoi tant d’initiatives d’IA agentique échouent-elles dans la production ?
De nombreuses défaillances découlent d’un écart de gouvernance : les équipes n’ont pas encore aligné les attentes en matière de fraîcheur des données, les limites d’approbation, les contrôles d’identité et l’observabilité sur ce que les workflows autonomes peuvent réellement faire en production. L’ novembre 2025 enquête de McKinsey a révélé que près des deux tiers des personnes interrogées ont déclaré que leurs organisations n’avaient pas encore commencé à faire évoluer l’IA dans l’ensemble de l’entreprise, ce qui aide à expliquer pourquoi l’enthousiasme autour des agents dépasse toujours la maturité opérationnelle.
Comment les mises à jour de l’IA agentique affectent-elles les processus de prise de décision ?
Les mises à jour récentes de la plateforme ont fait passer les agents des rôles de conseil aux rôles d’exécution, ce qui signifie qu’ils initient désormais des workflows et modifient les configurations sans attendre l’approbation humaine. Cela change la prise de décision de « l’agent suggère, l’humain approuve » à « l’agent agit dans les paramètres définis ». Pour les équipes informatiques, cela signifie que la gouvernance doit désormais tenir compte des permissions au niveau du workflow, et pas uniquement des contrôles d’accès aux données, et que les outils de surveillance doivent capturer les actions initiées par l’agent aussi rigoureusement que celles initiées par l’utilisateur.
L’IA agentique a-t-elle un avenir ?
L’adoption de l’IA agentique s’accélère, avec près de 70 % des entreprises dans l ’enquête Village 2025 CISO de Team8, une communauté de leaders de la sécurité dans les grandes entreprises, rapportant des agents d’IA déjà en production. Ce chiffre reflète probablement les adoptants de pointe plutôt que l’organisation médiane ; l’ novembre 2025 enquête de McKinsey a révélé que la plupart des entreprises en étaient encore aux premiers stades. Pris ensemble, les données suggèrent que l’adoption est inégale, mais évolue rapidement en haut du marché.
L’avenir de la technologie dépend de la capacité des cadres de gouvernance à rattraper les capacités des agents. Les organisations qui y parviennent seront celles qui traitent la gouvernance non pas comme un exercice de politique, mais comme une discipline opérationnelle, intégrée dans la manière dont les agents sont déployés, surveillés et limités dès le début.
Bien que les outils tels que ChatGPT aient introduit de nombreuses organisations dans les résultats générés par l’IA, les systèmes agents représentent une catégorie fondamentalement différente : ils ne répondent pas uniquement aux requêtes, ils initient des actions, et cette distinction est ce qui rend la gouvernance si critique.
Les équipes qui s’attaquent rapidement aux lacunes en matière de visibilité seront positionnées pour faire évoluer les déploiements d’IA agentique en toute confiance. Les organisations qui ne se retrouveront pas à gérer les incidents qui auraient pu être évités avec des limites plus claires et une meilleure intelligence des endpoints.
La gouvernance n’est plus un simple exercice de politique : elle dépend de données précises et actuelles, de la capacité à agir au sein de workflows contrôlés et de la visibilité pour comprendre ce que les systèmes autonomes font en temps réel.
Demandez une démo gratuite et personnalisée dès aujourd’hui pour voir comment Tanium prend en charge la gouvernance de l’IA agentique. Écoutez notre podcast et suivez Tanium sur LinkedIn et sur les réseaux sociaux pour obtenir des mises à jour continues sur la gouvernance de l’IA agentique, la sécurité des endpoints et les développements informatiques de l’entreprise.
