Les agents DevOps en 2026 : MCP, les frameworks et ce qui fonctionne réellement.
Comment fonctionnent les agents DevOps, pourquoi MCP est important, quels frameworks conviennent, où ils aident dans CI/CD, l’infrastructure, la surveillance et la sécurité, et ce qui reste encore une mode passagère.
Sources: The Complete 2026 Guide to DevOps Agents From CI/CD to Production Monitoring
Pendant longtemps, « l’IA dans DevOps » signifiait que Copilot complétait automatiquement votre code Terraform. Vous définissiez l’objectif, une suggestion apparaissait, vous l’acceptiez ou la rejetiez puis vous passiez à autre chose. Cet outil n’était qu’un complétion automatique plus sophistiqué, tandis que l’ingénieur effectuait toujours le travail lui-même. Cette organisation laisse place à quelque chose de différent.
Les agents effectuent désormais des tâches au lieu de proposer simplement du code. Ils examinent les demandes de fusion avant qu’un humain ne les ouvre, analysent les incidents tandis que vous lisez encore l’alerte, scannent le code d’infrastructure à la recherche de problèmes de sécurité avant le démarrage d’un pipeline, détectent des anomalies dans les métriques de production avant même que des seuils ne soient atteints, et rédigent des guides de procédure pour les incidents qu’ils viennent de résoudre. Les humains restent impliqués, mais le processus a changé. Vous n’êtes plus le premier à lire une demande de fusion ni le premier à traiter une alerte. Vous examinez ce que l’agent a trouvé, décidez des actions à entreprendre et gérez les situations qui nécessitent réellement un jugement.
L’adoption est inégale. Selon un chiffre souvent cité dans les enquêtes, seuls environ 11 % des organisations utilisent des agents en production à grande échelle, tandis que les autres se situent entre une démonstration spectaculaire et des problèmes réels en production. Ceux qui ont réussi à les mettre en œuvre fonctionnent de manière nettement différente, et cette différence se reflète dans la fréquence des déploiements, le temps de réponse aux incidents et la charge liée aux gardes de nuit. Ce qui suit explique ce qu’étaient réellement les agents DevOps, le protocole qui permet d’accéder à leurs outils, les frameworks utilisés pour les développer, les domaines où ils apportent déjà des avantages aujourd’hui, ainsi que ceux qui ne sont pas encore prêts à fonctionner sans surveillance.
Qu’est-ce qu’un agent DevOps ?
Ce n’est pas un script. Un script fait ce que son auteur a écrit et rien de plus. Il ne lit pas le contexte, ne raisonne pas sur une situation ni ne s’adapte à des circonstances que personne n’a prévues. Ce n’est pas non plus un chatbot, car un chatbot répond aux questions. Un agent est déclenché par des événements tels qu’une demande de fusion de code, l’envoi d’une alerte ou l’achèvement d’un pipeline. Il lit le contexte à partir de plusieurs sources, raisonne sur ce qu’il a trouvé, puis agit ou produit un résultat que l’ingénieur peut utiliser.
L’architecture se compose de trois parties :
- Le déclencheur est ce qui le met en marche : une demande de fusion de code, une alerte, un déploiement terminé, un planning ou une appel explicite.
- Les outils sont ceux auxquels il peut accéder : l’API GitHub, Prometheus, Kubernetes, Loki, AWS et bien d’autres. Les capacités d’un agent sont entièrement définies par ses outils.
Cette dernière étape distingue les agents des scripts, et l’accès aux outils devient praticable en pratique grâce au Model Context Protocol.
MCP et pourquoi il est important ici
MCP est mentionné partout au sein des communautés d’agents, et pour les DevOps il est utile de comprendre pourquoi, car il modifie les capacités des agents.
Qu’est-ce que c’est
Le Model Context Protocol est une norme ouverte publiée par Anthropic en novembre 2024. Selon la plupart des sources, elle a été transférée en décembre 2025 à une initiative de la Linux Foundation, l’Agentic AI Foundation, créée en collaboration avec Block et OpenAI, afin qu’aucune entreprise ne en soit propriétaire, tout comme HTTP et OAuth n’ont pas de propriétaire unique. ChatGPT, Gemini, Microsoft Copilot, Cursor et VS Code seraient compatibles avec ce protocole, bénéficiant du soutien en matière d’infrastructure des principaux fournisseurs de services cloud. On estime qu’il existe des milliers de serveurs publics, couvrant des bases de données, des infrastructures cloud, des outils de communication, des plateformes d’observabilité et des outils de développement. Les chiffres varient selon les sources, il convient donc de considérer chaque nombre avec prudence.
Le problème qu’il résout est la fragmentation. Auparavant, chaque client d’IA nécessitait une intégration distincte pour chaque outil. Le support GitHub dans un assistant de codage utilisait un code différent de celui utilisé dans un autre éditeur, et encore différent dans un troisième, ce qui obligeait à le réécrire trois fois. Avec MCP, on crée un seul serveur que tout client compatible peut appeler.
Un serveur peut exposer trois types de capacités :
- Ressources permettent au modèle de consulter des éléments sans les modifier, comme un fichier, une ligne de base de données, une réponse API ou le résultat d’une requête de métriques. Elles montrent à l’agent l’état actuel des choses.
- Outils sont des fonctions que le modèle peut appeler pour agir : déclencher un déploiement, commenter sur GitHub, ajuster l’échelle d’un déploiement Kubernetes.
- Promptes sont des modèles réutilisables pour des workflows prédéfinis : effectuer un scan de sécurité, résumer un incident, générer un guide d’opération.
Transport
Début 2026, le transport SSE plus ancien a été abandonné au profit d’HTTP pur, qui prend en charge l’authentification OAuth 2.1 et représente l’avenir de cet écosystème. Si vous choisissez ou développez des serveurs aujourd’hui, utilisez HTTP avec OAuth 2.1.
Quels serveurs existent pour DevOps
Le catalogue est passé de quelques dizaines de serveurs au début de 2025 à des centaines de serveurs publics un an plus tard, Google Colab en intégrant son propre serveur en avril 2026. Pour DevOps, les serveurs officiels et ceux fournis par les éditeurs couvrent déjà les principaux domaines : fournisseurs de cloud, plateformes d’observabilité, Kubernetes, systèmes CI et hébergeurs de sources. Un ensemble de plugins Anthropic regroupe les serveurs AWS, GCP, Datadog et Sentry ainsi que des commandes en forme de slash telles que /incident, /deploy et /rollback, ce qui offre un point de départ pour les workflows SRE.
Écrire votre propre solution est simple grâce aux SDK officiels Python et TypeScript. Un exemple typique est un serveur Kubernetes qui accorde aux agents un accès en lecture ainsi qu’un ensemble restreint d’opérations d’écriture sur le cluster.
Choix d’un framework
Plusieurs frameworks sont pertinents pour développer des agents DevOps, et la plus grande erreur des équipes consiste à choisir en fonction de la mode plutôt que de l’adéquation.
LangGraph modélise un agent sous forme de graphe orienté. Les nœuds représentent des fonctions telles que des agents, des outils ou des points de décision, les arêtes représentent les transitions, et l’état circule à travers le graphe. Cela correspond aux besoins des workflows de production :
- Décisions en fonction des résultats : une analyse de sécurité échouée envoie l’exécution en phase d’escalade, tandis qu’une analyse réussie passe à la phase de déploiement.
- Enregistrement de points de contrôle, afin qu’un redémarrage au milieu d’une enquête ne fasse pas perdre d’informations.
- Pauses avec intervention humaine aux nœuds choisis pour attendre l’approbation.
LangSmith ajoute des traces étape par étape avec un comptage des tokens par nœud et vous permet d’injecter des entrées modifiées en cours d’exécution, ce type de débogage que souhaite une équipe d’infrastructure lorsque un agent agit de manière étrange à 2 heures du matin. Choisissez LangGraph pour des flux de travail complexes à plusieurs étapes où l’état doit persister, où les pannes nécessitent une récupération structurée, où des approbations sont requises et où le journal d’audit est important, ce qui est toujours le cas en production.
The Claude Agent SDK est le framework d’agents d’Anthropic, basé sur l’architecture de Claude Code. Il convient aux agents en production qui souhaitent disposer de fonctions d’ancrage, de MCP, de compétences, de sous-agents ainsi que de l’utilisation d’outils natifs d’Anthropic. Le support MCP est intégré : il suffit de transmettre les configurations du serveur, et le SDK gère la découverte, le routage et l’exécution des outils, sans nécessiter de code d’enveloppe. Il fonctionne particulièrement bien avec les capacités de réflexion étendue, l’utilisation d’outils et la reconnaissance visuelle. Choisissez-le si vous déploiez des agents basés sur Claude, que vous souhaitez l’intégration MCP la plus simple, que vous avez besoin de réflexion étendue pour gérer des situations ambiguës, ou que vous souhaitez intégrer des agents dans les workflows de Claude Code.
The OpenAI Agents SDK est un framework Python léger qui fonctionne avec de nombreux fournisseurs et plus d’une centaine de modèles. Sa caractéristique principale pour les équipes DevOps réside dans les transferts explicites d’actions entre des agents spécialisés, ainsi que dans un routage clair. Choisissez-le pour un passage rapide du prototype à la production, pour la flexibilité de basculer entre Claude, GPT-4o ou Gemini, ou pour des workflows qui s’adaptent naturellement aux transferts d’actions.
Où les agents sont utilisés
CI/CD
C’est ici que l’adoption est la plus avancée. Les équipes indiquent que les pipelines sont 30 à 50 pour cent plus rapides et que le nombre de déploiements échoués diminue de 20 à 40 pour cent grâce aux agents CI/CD intelligents, des chiffres issus de rapports auto-remplis et dépendants du niveau de référence. Trois tâches sont aujourd’hui effectuées de manière fiable.
Revue des demandes de pull. Un agent examine la demande de pull avant qu’un humain ne le fasse. Prenons par exemple une modification apportée à une API de paiement qui ajoute une logique de tentative répétée pour les transactions échouées :
- L’agent lit la différence, au total 47 fichiers.
- Grâce à MCP, il identifie les modifications à risque : une nouvelle logique de tentative dans un service de paiement, un compteur de tentatives augmenté de 3 à 10 ainsi qu’une diminution du délai de coupure du circuit-breaker.
- Il consulte l’historique des déploiements via un serveur Argo CD et constate que deux des cinq derniers déploiements ont provoqué des incidents, un taux suffisamment élevé pour être signalé.
- Il vérifie les modèles de sécurité à l’aide de Semgrep et d’outils SAST, et identifie une boucle de tentatives sans recul exponentiel ni variation aléatoire, ce qui représente un risque majeur.
- Il publie un commentaire d’évaluation en indiquant les lignes spécifiques concernées.
Intelligence du pipeline. Les systèmes CI traditionnels exécutent chaque étape pour chaque modification. Un agent lit la différence et sélectionne les étapes à exécuter, de sorte qu’une modification de documents est finalisée en trois minutes, tandis qu’une modification dans un service de paiement fait l’objet de l’ensemble des tests, y compris ceux de performance.
Risque de déploiement. Avant chaque déploiement en production, un agent vérifie l’historique des déploiements, l’état actuel du service, les résultats des analyses de timing et de sécurité, puis fournit une recommandation notée accompagnée de ses raisons.
Infrastructure
Pour l’infrastructure en code, les agents effectuent une première analyse systématique : ils identifient les problèmes de sécurité en fonction de leur gravité, évaluent les coûts à partir des tarifs en temps réel via un serveur AWS Pricing, vérifient les conventions de nommage et rédigent un résumé du plan avant que quiconque ne consulte la proposition de modification. Lors de la génération de l’IaC, les agents utilisant un serveur Terraform Registry en temps réel ainsi que des données de tarification créent des configurations adaptées à votre environnement actuel, plutôt que des modèles basés sur des pratiques obsolètes datant de deux ans issues des données d’entraînement.
Surveillance
Les agents d’observabilité apprennent à quoi ressemble la normale pour chaque service, à chaque heure et sous différentes charges, et alertent en cas de déviation de comportement plutôt qu’en fonction de seuils statiques. Lorsqu’un phénomène anormal se produit à 3h47 du matin, l’agent vérifie les déploiements récents, les services associés ainsi que les événements d’infrastructure, puis envoie une notification qui attribue correctement la cause à un fournisseur externe, sans alerter les équipes de garde pour un problème sur lequel personne ne peut agir.
Réponse aux incidents
Un agent d’incident peut effectuer automatiquement les 15 premières minutes d’enquête. Plusieurs serveurs MCP sont consultés en même temps : Prometheus fournit des métriques, Loki gère les journaux, Argo CD fournit l’historique des déploiements et Tempo gère les traces. Il combine ensuite ces informations en une hypothèse sur la cause racine accompagnée d’une solution proposée. L’ingénieur de garde reçoit une analyse structurée à la place d’une simple alerte. Une entreprise SaaS aurait réduit le temps moyen de résolution de 35 %, car ses agents ont détecté des anomalies que les humains avaient manquées parmi le bruit des données.
Sécurité
Les agents de sécurité qui fonctionnent 24 heures sur 24 détectent des problèmes que les scans ponctuels négligent. Un agent de conformité planifié peut vérifier les signatures des images, comparer les images en production avec les derniers rapports CVE, tester l’état du cluster selon les politiques OPA et rassembler des preuves pour les auditeurs. Les agents de vérification des secrets scannent toute l’histoire git à la recherche de identifiants antérieurs à tout scan effectué.
Un ordre d’adoption judicieux
- Phase 1 : faible risque et retour rapide. Un agent d’examen des demandes de pull (un produit commercial comme CodeRabbit, ou un agent personnalisé basé sur le SDK Claude ainsi que sur un serveur GitHub) et un agent d’examen de l’IaC (LangGraph avec Terraform et des serveurs AWS IAM).
- Phase 2 : environ 30 jours plus tard. Un agent d’intelligence de pipeline sur le SDK OpenAI Agents, ainsi que la détection d’anomalies grâce à des fonctionnalités de plateforme comme celles de Datadog ou Dynatrace.
- Phase 3 : environ 60 jours plus tard. Un agent de réponse aux incidents (LangGraph avec Prometheus, Loki et des serveurs Kubernetes) ainsi qu’un évaluateur des risques de déploiement basé sur les données des phases précédentes.
- Phase 4 : état mature. Un mécanisme d’annulation automatique en cas de problème avec Argo Rollouts et un modèle d’analyse, ainsi qu’un agent de conformité planifié qui génère des dossiers de preuves.
Une évaluation honnête
Les avantages proviennent de choses peu spectaculaires : des processus CI/CD plus intelligents, des revues plus rapides, une correction proactive des problèmes et des économies de coûts. Le discours public met en avant l’autonomie totale et des pipelines à configurer une fois pour toutes, mais cela n’existe pas encore. Ce qui fonctionne aujourd’hui, ce sont les revues de propositions de modification, les revues d’IaC, la détection d’anomalies et l’enquête sur les incidents. Ce qui est surestimé, ce sont des pipelines de déploiement entièrement autonomes et de l’IA remplaçant le jugement humain face à de nouveaux types de pannes.
Les équipes qui comblent l’écart entre les projets pilotes et la production commencent petit, mesurent les résultats, construisent la confiance pas à pas et augmentent progressivement leur autonomie à mesure que la fiabilité est démontrée, et non parce qu’un fournisseur l’a promis. Le rôle de l’ingénieur évolue, passant du travail de configuration à la conception d’infrastructures, à la stratégie de coûts et à l’ingénierie de fiabilité. Ce rôle change sans disparaître, et ceux qui réussiront seront ceux qui développeront et géreront les systèmes d’agents.
Lectures complémentaires
- OpsAgents : Dix agents LangGraph pour le cloud et DevOps — Présentation de dix agents DevOps intégrant l’intervention humaine, développés sur LangGraph, allant de Terraform et Kubernetes aux analyses Trivy, avec une description des règles de conception et des leçons apprises.
- Notes pratiques : Systèmes RAG : Le guide complet de zéro à héros (édition 2026) — Guide pas à pas des Notes pratiques : Systèmes RAG : Le guide complet de zéro à héros (édition 2026) : contrats, vérifications et modules de code prêts à l’emploi pour les équipes utilisant ce modèle.