Une alerte se déclenche peu après un déploiement. Les taux d’erreur augmentent, un service consomme plus de mémoire que d’habitude et les requêtes des clients commencent à échouer.
Un agent d’IA chargé de l’exploitation examine l’historique des déploiements, retrace les dépendances touchées et compare l’incident à des pannes antérieures. Il conclut qu’un service en particulier est probablement en cause et propose de le redémarrer.
La recommandation semble raisonnable. Attendre un ingénieur risque de prolonger la panne. Redémarrer immédiatement pourrait rétablir le service.
L’agent doit-il agir ?
Ce scénario est hypothétique, mais la décision devient déjà bien réelle pour les équipes d’exploitation. Il résume la question centrale de l’AgenticOps. Il ne s’agit pas simplement de savoir si un système d’IA peut enquêter sur un incident ou exécuter une commande. Il s’agit de savoir quelle autorité ce système devrait recevoir, et ce qui doit être vrai avant que cette autorité augmente.
Mon point de vue est que l’AgenticOps est déjà utile, mais que les éléments publics justifient une forme d’autonomie plus restreinte que ne le laissent entendre de nombreux gros titres. Les entreprises tirent de la valeur d’agents qui collectent des éléments de preuve, corrèlent des événements, enquêtent sur les causes probables et appliquent les politiques de mise en production. Les preuves d’un contrôle large et sans surveillance de l’infrastructure de production restent limitées.
Cela ne fait pas de l’AgenticOps une tendance technologique creuse. Cela signifie que nous devons l’évaluer comme un modèle d’autorité, et pas seulement comme un outil d’automatisation plus intelligent.
L’adoption est réelle, mais l’adoption ne décrit pas l’autorité
Le rapport AgenticOps publié par Cisco en septembre 2026 constitue un signal de marché important. L’étude d’Omdia sur laquelle il repose a interrogé plus de 1 000 responsables des opérations informatiques et réseau, issus d’organisations d’au moins 500 salariés en Amérique du Nord, en Europe de l’Ouest et en Asie-Pacifique.[1]
Cinquante et un pour cent ont déclaré disposer de systèmes agentiques qui agissent en production. Par ailleurs, 82 % se sont dits à l’aise à l’idée d’autoriser au moins certaines modifications du réseau de production sans approbation préalable.
Ces chiffres montrent que les agents d’exploitation dépassent le stade de l’expérimentation. Ils ne nous disent pas quelle autorité ces agents détiennent actuellement.
« Agir en production » peut désigner des dispositifs très différents. Un agent peut rassembler des journaux (logs), ouvrir un incident, recommander un retour arrière (rollback), bloquer une mise en production risquée ou exécuter une étape de reprise prédéfinie. Chacune de ces activités touche à l’exploitation en production, mais le risque n’est pas le même.
Les résultats sur la confiance font apparaître cette différence. Soixante-neuf pour cent des répondants exigeaient des explications détaillées pour les actions déclenchées par des agents. Quatre-vingt-dix-neuf pour cent voulaient au moins un garde-fou, comme des points de contrôle d’approbation, des limites fixées par des politiques, un contrôle d’accès basé sur les rôles, des pistes d’audit ou des mécanismes de reprise en main d’urgence.[2]
Le signal du marché est donc plus nuancé que « les entreprises confient l’exploitation à l’IA ». Les organisations semblent disposées à accroître l’automatisation tout en exigeant des contrôles plus stricts sur ce qu’un agent peut voir, décider et modifier.
Le périmètre compte aussi. Cette étude porte sur des responsables des opérations réseau. Elle apporte des éléments utiles sur les attitudes des équipes NetOps et sur les déploiements qu’elles déclarent. Ce n’est pas une mesure universelle de toutes les charges de travail des entreprises.
Un agent peut choisir une étape sans être maître de la décision
L’automatisation traditionnelle suit un chemin que les ingénieurs définissent à l’avance. Un script redémarre un service lorsqu’un seuil est franchi. Un pipeline de déploiement exécute une séquence fixe de tests. Un runbook exécute des commandes connues dans un ordre connu.
Un agent d’exploitation (en anglais) est différent, car il peut interpréter le contexte et choisir parmi plusieurs outils ou actions possibles. Il peut décider quels journaux interroger, quelle dépendance inspecter ou quel playbook de reprise correspond le mieux aux éléments recueillis.
Cette flexibilité est précieuse lorsque les incidents ne suivent pas une séquence prévisible. C’est aussi pourquoi l’autorité doit être traitée séparément de l’intelligence.
La confiance d’un modèle est une prédiction. Ce n’est pas une décision de contrôle d’accès.
Un agent peut être très confiant dans le fait que redémarrer un service résoudra un incident. Cette confiance n’établit ni que l’agent a le droit de le redémarrer, ni que l’action est sûre dans l’environnement actuel, ni que quelqu’un a accepté la responsabilité des conséquences.
L’AgenticOps combine donc deux systèmes différents :
- Un système de raisonnement propose ce qui devrait se produire.
- Un système d’autorité détermine ce qui est autorisé à se produire.
L’agent peut choisir parmi des outils et des étapes préautorisés, à l’intérieur d’un périmètre de tâche défini. Il ne devrait ni élargir ce périmètre ni décider du niveau d’autorité qu’il mérite.
Ce que démontrent les éléments actuels sur les produits
La documentation actuelle la plus solide va dans une direction cohérente. Les agents d’exploitation utiles fonctionnent à l’intérieur de limites explicites en matière de ressources, de permissions et d’approbation.
| Élément | Comportement documenté | Ce que cela étaye | Ce que cela ne prouve pas |
|---|---|---|---|
| Étude NetOps de Cisco et Omdia [1][2] | Fait état d’une adoption en production, d’une disposition à autoriser certaines modifications autonomes et d’une forte demande de garde-fous | L’AgenticOps est une tendance réelle du NetOps, et les contrôles de confiance restent importants | Une preuve indépendante qu’une autonomie étendue est sûre |
| Documentation de sécurité d’AWS DevOps Agent [3][4] | Utilise des Agent Spaces, des rôles IAM, des garde-fous de permissions, une lecture seule par défaut et des enregistrements d’audit | Une investigation utile dépend d’un périmètre d’accès défini | Qu’un accès en écriture sans restriction soit approprié |
| Documentation d’Azure SRE Agent [5] | Sépare les autorisations sur les ressources des modes d’exécution Review et Autonomous | Les droits d’accès et la politique d’approbation devraient être gouvernés indépendamment | Que le mode Autonomous convienne à toutes les tâches de production |
| Démonstration SRE de Google [6] | Récupère des éléments, choisit parmi des playbooks d’atténuation et vérifie le résultat | Un schéma d’action crédible comprend un ensemble fermé d’actions et une vérification | Un résultat mesuré en production à grande échelle |
Ces sources ne sont pas équivalentes. Le rapport de Cisco est une étude de marché financée par Cisco et réalisée par Omdia. AWS et Microsoft décrivent des contrôles intégrés à leurs produits. La démonstration de Google est un exemple d’architecture plutôt qu’un résultat client mesuré.
Même avec ces limites, la tendance est claire. Les éléments publics sont les plus solides pour l’investigation, la corrélation, la synthèse, le contrôle des mises en production et les actions soigneusement encadrées. Ils sont beaucoup plus faibles pour les modifications sans restriction des systèmes de production.
Ce constat m’a conduit à une manière plus utile d’aborder l’AgenticOps. Le choix ne se fait pas entre une exploitation manuelle et une autonomie totale. Il s’agit d’une échelle d’autorité opérationnelle.
L’échelle d’autorité de l’agent
Pour l’accessibilité, le cadre est également présenté ci-dessous.
- Observer : l’agent collecte et normalise la télémétrie. Des humains définissent les sources fiables et les limites d’accès.
- Enquêter : l’agent corrèle les éléments et teste des explications possibles. Des humains examinent l’incertitude et contestent les conclusions.
- Recommander : l’agent propose un runbook, une remédiation ou un verdict de mise en production. Des humains acceptent, rejettent ou modifient la recommandation.
- Action approuvée : l’agent exécute une modification clairement décrite après approbation. Un opérateur responsable en évalue l’impact et l’autorise.
- Autonomie encadrée : l’agent exécute une catégorie d’actions prédéfinie et réversible. Des humains fixent la politique, surveillent le comportement et conservent le pouvoir de reprendre la main.
Passer d’un niveau au suivant n’est pas une simple mise à niveau du modèle. C’est une décision organisationnelle qui porte sur les permissions, le risque et la responsabilité.
Une équipe peut faire confiance à un agent pour enquêter sur chaque incident de production tout en ne l’autorisant à exécuter qu’un petit ensemble d’actions. Une autre équipe peut permettre les redémarrages automatiques de services de développement sans état, mais exiger une approbation pour la même action dans un système de paiement.
Le modèle peut être identique dans les deux environnements. L’autorité appropriée, elle, ne l’est pas.
Retour à la décision de redémarrage
Avant que l’agent procède au redémarrage du service décrit dans le scénario d’ouverture, quatre questions appellent une réponse.
1. Dispose-t-il d’un contexte opérationnel suffisant ?
Une recommandation fondée sur un seul journal d’erreurs est très différente d’une recommandation étayée par l’historique des déploiements, la topologie des dépendances, les métriques de ressources, les modifications de configuration récentes et des incidents similaires.
Un agent ne peut pas compenser une télémétrie manquante en raisonnant avec plus d’assurance. La maturité de l’observabilité passe donc avant l’autonomie opérationnelle. Si la répartition des responsabilités, les dépendances et l’historique des incidents sont fragmentés, l’agent hérite de cette fragmentation.
2. L’action est-elle explicitement permise ?
L’agent devrait agir au moyen d’une identité restreinte, avec un accès selon le principe du moindre privilège. Ses outils, ses ressources cibles et ses actions permises devraient être définis en dehors du modèle. Un prompt demandant à l’agent d’« être prudent » n’est pas un contrôle de sécurité.
AWS documente cette séparation au moyen des Agent Spaces, des rôles IAM et des garde-fous de permissions. Microsoft offre un point de comparaison utile avec Azure SRE Agent, qui sépare les autorisations sur les ressources du mode d’exécution, lequel détermine si les actions sur l’infrastructure nécessitent une approbation.
Les produits diffèrent, mais le principe durable est le même. La capacité et la permission doivent être gouvernées indépendamment.
3. L’approbation éventuellement requise est-elle éclairée ?
Avant d’approuver le redémarrage, un opérateur devrait voir :
- Les éléments qui étayent le diagnostic.
- L’action exacte proposée.
- Les systèmes et les utilisateurs susceptibles d’être touchés.
- Le signal de rétablissement attendu.
- Le retour arrière ou la réponse de rechange.
- Les conditions qui déterminent la réussite ou l’échec.
Si l’opérateur ne peut pas comprendre ces points, l’approbation devient un rituel. Un bouton ne crée pas de contrôle humain réel lorsque la personne qui appuie dessus n’a pas les éléments, le temps ou l’autorité nécessaires pour juger l’action.
L’OWASP Top 10 for Agentic Applications 2026 formule un avertissement de sécurité plus large sur l’agentivité excessive (excessive agency).[7] La leçon pratique pour l’exploitation est simple. Les outils à fort impact nécessitent des limites de permissions plus strictes que les outils d’investigation à faible risque.
4. Le résultat peut-il être vérifié ?
L’exécution d’une commande ne marque pas la fin d’une action opérationnelle. Le système doit confirmer si les taux d’erreur ont baissé, si le trafic a repris, si les dépendances se sont stabilisées et si l’impact sur les clients a pris fin.
Si le rétablissement ne peut pas être établi, l’agent devrait revenir en arrière lorsque c’est possible ou escalader l’incident avec les éléments qu’il a recueillis. Sans cette boucle, un agent peut confondre l’exécution réussie d’une commande avec la résolution réussie de l’incident.
L’approbation humaine n’est pas toujours la réponse la plus sûre
Il est tentant de régler chaque risque de l’AgenticOps en exigeant qu’une personne approuve chaque action. Je ne pense pas que ce soit tenable.
Pendant une panne qui évolue rapidement, une demande d’approbation peut rester sans réponse. Un ingénieur épuisé peut l’approuver sans examiner les éléments. Exiger une confirmation humaine pour des centaines d’actions à faible risque peut créer une fatigue d’alerte et réduire la qualité de la supervision là où elle compte vraiment.
Dans certains environnements, l’autonomie encadrée peut être plus sûre qu’une intervention humaine tardive. Redémarrer un worker sans état, ajuster la capacité d’un niveau de service prédéfini ou suspendre un déploiement défaillant peut être approprié lorsque l’action est reproductible, observable et réversible.
L’objectif n’est pas d’insérer un humain dans chaque chemin d’exécution. Il est d’adapter l’autorité à l’action.
| Déléguer plus tôt lorsque l’action est | Garder une approbation explicite lorsque l’action touche |
|---|---|
| Reproductible et bien comprise | L’identité ou le contrôle d’accès |
| D’un rayon d’impact limité | Le pare-feu et la politique de sécurité réseau |
| Observable avant et après l’exécution | Les bases de données de production ou les données persistantes |
| Réversible par une procédure testée | Des opérations de stockage destructrices |
| Répétable sans aggraver les dommages | Une infrastructure partagée dont la responsabilité est floue |
| Couverte par une politique et des enregistrements d’audit complets | Des systèmes réglementés ou sensibles du point de vue de la conformité |
C’est un point de départ, pas une liste universelle de permissions. La même action peut comporter un risque différent selon les systèmes.
L’autorité de l’agent ne supprime pas l’autorité humaine
Un agent peut recevoir une permission. Il ne peut pas assumer la responsabilité organisationnelle.
Quelqu’un doit décider quelles sources d’éléments sont fiables, quels outils sont disponibles, quels environnements peuvent être modifiés et quelles défaillances exigent une escalade. Un responsable de service nommément désigné reste responsable de la politique, même lorsque l’agent opère correctement dans son cadre.
La répartition devrait être explicite. L’agent travaille à l’intérieur du périmètre de tâche qui lui est attribué : il collecte des éléments, explique son raisonnement, choisit parmi les actions permises et rend compte du résultat. L’autorité humaine crée ce périmètre, approuve les exceptions à fort impact, examine les échecs et décide si les permissions doivent être élargies, rester inchangées ou être réduites.
C’est pourquoi la notion d’« humain dans la boucle » (human in the loop) est trop vague pour servir de modèle de gouvernance. La question importante n’est pas de savoir si un humain apparaît quelque part dans le flux de travail. C’est de savoir quelles décisions restent des décisions humaines.
Une résolution plus rapide ne fait pas toute la grille d’évaluation
Réduire le délai moyen de résolution (MTTR) est utile, mais le MTTR n’est pas une mesure de la confiance.
Un système peut réduire le temps de résolution en agissant de manière agressive, en escaladant moins de cas ou en déclarant le rétablissement avant que le problème sous-jacent ait été éliminé. Un incident peut être clos rapidement et réapparaître une heure plus tard.
| Mesure | Ce qu’elle révèle |
|---|---|
| Délai d’obtention d’éléments utiles | Si l’agent accélère l’investigation |
| Taux d’acceptation des recommandations | Si les ingénieurs jugent ses conclusions utiles |
| Qualité de l’abstention | S’il reconnaît que les éléments sont insuffisants |
| Taux de reprise en main humaine | À quelle fréquence les opérateurs rejettent ou interrompent ses décisions |
| Taux de réussite des retours arrière | Si les actions qui ont échoué peuvent être rattrapées sans danger |
| Récurrence des incidents | Si l’action a corrigé la cause ou seulement le symptôme |
| Taux de violation des politiques | Si l’agent est resté dans les limites de son autorité |
| Exhaustivité de l’audit | Si les enquêteurs peuvent reconstituer ce qui s’est passé |
Un bon projet pilote devrait améliorer la vitesse sans dégrader ces mesures de sécurité et de qualité.
Par où les équipes devraient commencer
Le point de départ le plus sûr n’est pas la remédiation autonome. C’est la compréhension opérationnelle.
Laissez d’abord les agents observer. Donnez-leur accès à la télémétrie approuvée, aux registres de déploiement, à l’historique des incidents et à la documentation des services. Mesurez s’ils récupèrent les bons éléments et si leurs synthèses sont exactes.
Autorisez-les ensuite à enquêter et à recommander. Comparez leurs conclusions avec celles d’ingénieurs expérimentés. Notez quand l’agent a raison, quand il s’abstient et quand il produit une explication assurée mais incomplète.
L’action approuvée ne devrait venir que lorsque le processus de recommandation est devenu fiable. Même alors, commencez par des modifications limitées et réversibles, et exigez que le système annonce le résultat attendu avant l’exécution.
L’autonomie encadrée devrait se gagner catégorie d’actions par catégorie d’actions. Elle ne devrait pas être accordée largement parce qu’un modèle a donné de bons résultats sur une autre tâche.
Un agent qui redémarre de manière fiable des workers sans état n’a pas démontré qu’il peut modifier une politique de pare-feu. Un agent qui examine des déploiements n’a pas gagné le droit de modifier des schémas de base de données. L’autorité devrait s’étendre sur la base d’éléments précis, et non d’une confiance générale dans la technologie.
La confiance se gagne une décision encadrée à la fois
Revenons une dernière fois au redémarrage de service proposé.
L’agent peut être autorisé à l’exécuter sans attendre un ingénieur, mais seulement si l’organisation a déjà établi que cette catégorie de redémarrage est permise, réversible et vérifiable. L’agent ne devrait pas s’inventer cette autorité pendant l’incident.
Si les dépendances ne sont pas claires, si le rayon d’impact est incertain ou si le rétablissement ne peut pas être mesuré, la bonne action peut consister à recommander et à escalader. Ce n’est pas un échec de l’AgenticOps. Savoir quand ne pas agir fait partie de la compétence opérationnelle.
Le marché évolue vite, et les agents d’exploitation recevront davantage d’autorité à mesure que leurs capacités progresseront. Les organisations qui en tireront le plus de bénéfices ne seront pas celles qui suppriment le plus vite les points de contrôle d’approbation. Ce seront celles qui comprennent pourquoi chaque point de contrôle existe, quand il peut être supprimé sans danger et comment les contrôles restants détecteront une défaillance.
L’AgenticOps ne consiste pas à retirer les humains de l’exploitation. Il s’agit de décider avec soin et de manière explicite quelles décisions un agent peut prendre, lesquelles nécessitent une approbation et lesquelles devraient rester humaines.
Références et lectures complémentaires
Sources et documentation consultées le 28 septembre 2026. L’incident d’ouverture est un scénario illustratif, et non le compte rendu de la panne d’un client en particulier.
- The Impact of Agentic AI on Network Operations, Cisco et Omdia, 2026. Rapport de recherche fondé sur une enquête auprès de plus de 1 000 responsables NetOps en Amérique du Nord, en Europe de l’Ouest et en Asie-Pacifique, portant sur l’adoption, les actions autonomes et la demande de garde-fous. ↩
- NetOps Is Already Deploying Autonomy. Trust Will Decide How Far It Goes, Cisco, septembre 2026. Analyse opérationnelle, par Cisco, des résultats de l’enquête et des exigences de confiance qui entourent les actions réseau autonomes. ↩
- AWS DevOps Agent Security, AWS, consulté le 28 septembre 2026. Documentation officielle couvrant les Agent Spaces, l’isolation des identités, le traitement des données opérationnelles, les journaux (journals) et les pistes d’audit.
- Limiting Agent Access in an AWS Account, AWS, consulté le 28 septembre 2026. Guide technique sur les rôles IAM, les garde-fous de permissions et les contrôles d’accès effectifs.
- Run Modes in Azure SRE Agent, Microsoft, consulté le 28 septembre 2026. Documentation d’architecture montrant la séparation entre les autorisations sur les ressources et les modes d’exécution Review et Autonomous.
- How Google SREs Use Gemini CLI to Solve Real-World Outages, Google Cloud, janvier 2026. Démonstration pratique de la récupération d’éléments, de l’atténuation par un ensemble fermé de playbooks, de l’approbation humaine et de la vérification du résultat.
- OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, décembre 2025. Recommandations de sécurité détaillant l’agentivité excessive et la nécessité de limites strictes aux privilèges opérationnels. ↩
- AI Risk Management Framework (AI RMF 1.0), NIST, consulté le 28 septembre 2026. Norme fédérale de référence pour la gestion des risques des systèmes d’intelligence artificielle.