OpsAgents : Dix agents LangGraph pour le cloud et les tâches DevOps.

Les ingénieurs continuent de poser la même question au sujet des agents DevOps, sous des mots différents : un tel outil existe-t-il vraiment, où se trouve son code et peut-il fonctionner dès aujourd’hui ? Les concepts ont leurs limites, donc la réponse pratique est OpsAgents, un ensemble de dix agents IA pour les opérations cloud et DevOps, développés avec LangGraph et Python. Il fonctionne à la fois en tant qu’outil en ligne de commande et en tant que serveur MCP.

Avertissement bêta : OpsAgents est encore en version bêta. Ne l’utilisez pas dans des environnements de production. Des changements majeurs peuvent apparaître sans préavis, et vous l’utilisez à vos propres risques.

Règles de conception

Un humain confirme chaque action destructrice. L’élargissement d’un déploiement, l’application de Terraform ou le déclenchement d’un runbook font tous en sorte que l’agent s’arrête et demande confirmation avant qu’un événement irréversible ne se produise. Il ne s’agit pas d’une fonctionnalité que l’on peut désactiver, car l’infrastructure de production ne le permettrait pas.

Machines à états, pas de chaînes de commandes fragiles. Chaque agent est un graphe dirigé dans lequel l’état se déplace d’un nœud à l’autre. Si une étape échoue en cours de route, l’état est conservé et l’agent peut se remettre en marche. Grâce au système de points de contrôle, l’agent survit à une redémarrage sans perdre ses progrès.

Intégrations réelles. Les agents fonctionnent avec AWS Cost Explorer, CloudWatch, CloudTrail, IAM, SSM et EC2, exécutent des opérations Kubernetes réelles via kubectl, utilisent Trivy pour un véritable balayage des CVE et génèrent des fichiers JSON pour des tableaux de bord Grafana que l’on peut intégrer dans une stack existante. Rien de tout cela n’est simulé ou fictif.

Plusieurs fournisseurs de modèles. Claude, GPT-4, Gemini, Mistral et Ollama fonctionnent tous, et Ollama permet des exécutions entièrement locales, sans connexion à Internet. Le framework ne dépend d’aucun fournisseur en particulier.

Deux manières de l’exécuter

Au mode CLI, vous lancez n’importe quel agent directement depuis la terminal, ce qui convient aux opérations ponctuelles, à l’écriture de scripts et aux tests.

Au mode serveur MCP, OpsAgents s’intègre à Claude Code, Cursor, Codex ou OpenCode, vous permettant ainsi de communiquer avec votre infrastructure comme avec un collègue. Une fois le serveur MCP configuré dans votre éditeur, chaque agent devient un outil que l’éditeur peut appeler. Vous pouvez lui demander de scanner le cluster à la recherche de pods défaillants ou de vous fournir un rapport sur la facture AWS du mois, et l’agent approprié gère la demande, en affichant une confirmation avant de modifier quoi que ce soit.

Les dix agents

Agents cloud (AWS)

Provisionneur d’infrastructure. Cet outil couvre l’ensemble du cycle de vie du Infrastructure-as-Code. Décrivez simplement ce que vous souhaitez, par exemple une VPC publique avec deux sous-réseaux répartis sur différentes zones de disponibilité, et il génère un fichier Terraform ou CloudFormation complet. Il vérifie ensuite la syntaxe et exécute terraform plan, vous permettant de voir exactement ce qui va changer avant même que les ressources ne soient créées, et n’applique les modifications qu’après confirmation interactive. Par la suite, il peut auditer le compte AWS en temps réel et signaler tout écart par rapport à la configuration enregistrée dans Git, ce qui permet de détecter les modifications manuelles qui contournent le flux de travail IaC.

• Traduction du langage naturel en fichiers Terraform ou CloudFormation complets, et non seulement en squelettes
• Vérification de la syntaxe et génération d’un plan de simulation avant exécution
• Application des modifications uniquement après confirmation humaine
• Détection des écarts entre l’état actuel d’AWS et la configuration enregistrée dans Git

Sécurité et conformité. Les comptes AWS en production accumulent silencieusement des risques. Les politiques IAM s’assouplissent avec le temps, les groupes de sécurité sont ouverts à des fins de débogage sans jamais être fermés, et les buckets S3 se retrouvent mal configurés. Cet agent effectue des audits en continu au lieu de se fier à des vérifications occasionnelles. Il recherche des permissions wildcard dans les politiques IAM ainsi que des identifiants ayant trop de privilèges, détecte les groupes de sécurité EC2 disposant d’une entrée publique (SSH ouvert sur 0.0.0.0/0 étant le cas le plus courant), et vérifie les buckets S3 pour détecter l’absence de chiffrement et l’accès de lecture public. Les résultats sont évalués selon le CIS AWS Foundations Benchmark, ce qui vous permet d’obtenir des niveaux de gravité plutôt qu’une simple liste.

• Analyse IAM couvrant les wildcards, les chemins d’escalade et les permissions inutilisées
• Audits des groupes de sécurité concernant les ports publics et les entrées excessivement ouvertes
• Audits S3 portant sur l’état du chiffrement et l’accès public

• Comparaison des référentiels CIS avec indication du niveau de gravité

Optimiseur des coûts. Les factures AWS contiennent des gaspillages que personne n’a le temps de rechercher manuellement : volumes EBS non attachés, instances EC2 inactives avec seulement 3 % d’utilisation du CPU pendant des mois, adresses IP élastiques allouées à rien, couverture des instances réservées qui évolue au fil des changements dans le parc informatique. L’agent interroge Cost Explorer pour obtenir des rapports de dépenses, identifie les ressources inutilisées par type et région, propose des ajustements de taille pour les ressources sous-utilisées et indique où les plans d’économie ou les instances réservées permettraient de réduire les dépenses. Chaque recommandation est accompagnée d’une estimation des économies mensuelles possibles.

• Interrogations de Cost Explorer par service, région et période
• Détection des volumes non attachés, des instances inactives et des adresses IP élastiques inutilisées
• Conseils d’ajustement de taille avec estimation des économies
• Analyse de la couverture des plans d’économie et des instances réservées

Réponse aux incidents. Lorsqu’une alarme en production se déclenche, les 15 premières minutes sont cruciales. Cet agent commence l’enquête en parallèle, avant même que l’opérateur ne se réveille complètement. Il collecte toutes les alarmes CloudWatch actuellement en état ALARM, interroge Log Insights pour identifier les erreurs récentes et liste les appels API CloudTrail effectués au moment de la panne ; cette combinaison permet généralement de déterminer ce qui a changé. Si un guide SSM standard convient, il peut le déclencher une fois que vous l’avez confirmé. Une fois le problème résolu, il génère un rapport post-mortem structuré en markdown, couvrant le déroulement des événements, la cause racine et les mesures correctives.

• Aggregation des alarmes indiquant ce qui est en état ALARM, depuis quand et quels ressources
• Analyse de la cause racine à partir de Log Insights ainsi que de l’historique CloudTrail
• Exécution du guide SSM avec validation
• Rapports post-mortem générés

Évaluation de l’architecture. La plupart des équipes vérifient leur conception selon le cadre AWS Well-Architected une seule fois au lancement et rarement par la suite. Cet agent permet de poursuivre ces évaluations. Il détecte les bases de données RDS, les instances EC2, les balanceurs de charge, les fonctions Lambda et les buckets S3 sans qu’on lui indique ce qui existe, puis crée des diagrammes de flux Mermaid montrant la manière dont ils sont connectés. Il évalue les paramètres en fonction des piliers du Well-Architected et met en évidence des lacunes telles qu’une absence de déploiement multi-AZ, des bases de données RDS sans sauvegardes automatiques, ou des architectures monorégionnelles alors qu’une architecture multi-régionnelle était prévue.

• Découverte automatique, donc pas de besoin d’inventaire manuel
• Diagrammes de topologie Mermaid générés à partir de données en temps réel
• Évaluation des piliers de fiabilité, de performance et de coûts
• Résultats spécifiques concernant les configurations multi-AZ, les sauvegardes et les goulots d’étranglement

Agents DevOps (opérations de plateforme)

Pipeline CI/CD. Tout le monde a des opinions sur les pipelines, et personne n’a le temps de les ajuster. Cet agent analyse la base de code et génère une configuration de pipeline sur mesure plutôt que de partir d’un modèle générique. Il détecte le langage, le gestionnaire de paquets et le système de compilation, puis crée des workflows GitHub Actions avec un cache des dépendances, des permissions minimales (OIDC au lieu de crédentielles à long terme) et une séparation logique des tâches. Lorsqu’un pipeline échoue, il lit les journaux et fournit un diagnostic précis, plutôt que simplement « la compilation a échoué », en indiquant par exemple une absence dans le cache due à une modification d’un fichier de verrouillage qui a rendu le hash de la clé du cache obsolète.

• Détecte le langage, le gestionnaire de paquets et le système de compilation
• Génération de workflows avec cache, OIDC et contrôles de permissions
• Diagnostic des échecs de compilation avec la cause exacte et la solution correspondante

Opérations Kubernetes. Cet agent se comporte comme un administrateur de cluster doté de pouvoirs complets en matière de diagnostic et de correction, et c’est probablement le plus utile pour le travail en mode veille. Il résume l’état de santé des nœuds, des namespaces et des pods système dans un seul tableau. Pour les conteneurs défaillants, il suit des procédures de diagnostic spécifiques pour les cas CrashLoopBackOff, OOMKilled et ImagePullBackOff en examinant les événements et les conditions. Il génère du YAML pour les Deployments, Ingresses et Services, et il peut échaler les répliques ou effectuer un rollback directement, après confirmation.

• Résumé de l’état de santé du cluster dans un seul tableau
• Diagnostic structuré des pods pour les états de défaillance courants
• Génération de YAML pour les Deployments, Ingresses et Services
• Échelonnage et rollback avec confirmation

Surveillance et observabilité. Tout le monde reconnaît l’importance de la configuration de surveillance, mais la trouve fastidieuse. La syntaxe de PromQL est exigeante, le JSON des tableaux de bord Grafana est verbeux, et les arbres de routage d’Alertmanager sont sujets à des erreurs subtiles. Cet agent génère des règles d’alerte en PromQL pour des indicateurs courants tels que le taux d’erreurs, les percentiles de latence et le niveau de saturation, crée du JSON pour des tableaux de bord Grafana prêts à être importés, et élabore des plans de routage pour Alertmanager destinés à Slack ou PagerDuty. En fonction d’un niveau d’disponibilité cible de 99,9 % ou 99,95 %, il calcule également le budget d’erreurs mensuel et le temps d’arrêt maximal autorisé.

• Modèles PromQL pour les indicateurs d’infrastructure standard
• JSON de tableaux de bord Grafana importable
• Plan de routage d’Alertmanager pour Slack et PagerDuty
• Calculs liés aux SLO, y compris le budget d’erreurs et la durée d’arrêt autorisée

GitOps et déploiements. Cet agent gère toutes les tâches liées aux déploiements : fichiers de configuration, journaux des modifications, mises à jour de version et préparation des retraits. Il crée des manifestes d’application ArgoCD dotés de fonctionnalités d’auto-réparation et de suppression automatique, ainsi que des configurations Argo Rollouts pour des déploiements en mode canari ou bleu-vert, avec des AnalysisTemplates permettant de décider automatiquement de la promotion. Pour les déploiements, il met à jour les étiquettes Semver, génère des journaux des modifications à partir de l’historique des commits et peut créer des demandes de retrait lorsque un déploiement doit être annulé rapidement.

• Manifestes ArgoCD avec fonctionnalités d’auto-réparation, de suppression automatique et de synchronisation
• Deploiements en mode canari et bleu-vert avec AnalysisTemplates
• Mises à jour Semver et journaux des modifications à partir de l’historique Git
• Création de demandes de retrait

Sécurité des conteneurs et des images. La sécurité de la chaîne d’approvisionnement n’est plus optionnelle en 2026, et cet agent effectue les analyses et les mesures de renforcement qui doivent être appliquées avant que toute image ne soit mise en production. Il audite les couches des conteneurs à la recherche de vulnérabilités CVE à l’aide de Trivy et indique leur gravité ainsi que les paquets concernés. Il examine les Dockerfiles et les restructure grâce à des constructions en plusieurs étapes afin de réduire la taille de l’image, nettoie le cache pour éviter l’enflement des couches et utilise des utilisateurs non root. Il analyse les fichiers de verrouillage (poetry.lock, package-lock.json, Gemfile.lock) afin de détecter des dépendances obsolètes ou vulnérables, et génère des listes de matériel logiciel conformes aux normes CycloneDX ou SPDX.

• Analyses de vulnérabilités CVE avec évaluation de la gravité via Trivy
• Renforcement des Dockerfiles
• Analyses des fichiers de verrouillage pour identifier des paquets obsolètes ou vulnérables
• Génération de SBOM au format CycloneDX et SPDX

Pourquoi LangGraph en arrière-plan

Divers frameworks auraient pu être utilisés ici, parmi lesquels LangGraph, le Claude SDK, l’OpenAI Agents SDK, CrewAI et AutoGen. LangGraph a été choisi car ses forces correspondent aux exigences des processus DevOps.

Les workflows de production ne sont pas linéaires. Un scan de sécurité qui révèle un problème critique lié aux IAM doit être traité différemment d’un scan qui ne trouve rien, et une enquête sur un incident incapable de déterminer la cause racine dans les journaux doit être transmise à CloudTrail. Le routage conditionnel de LangGraph gère cela de manière efficace.

La persistance de l’état signifie qu’un agent qui traite un incident complexe survit à une redémarrage sans perdre ses résultats. Les points de contrôle vous permettent de rejouer un flux de travail à partir de n’importe quel nœud avec des entrées modifiées, ce qui est essentiel lors de la débogage d’un agent ayant pris une décision surprenante. De plus, le soutien humain fait partie intégrante du modèle de graphe et n’est pas ajouté ultérieurement. Vous décidez quels nœuds nécessitent une confirmation et le graphe s’arrête à cet endroit.

Leçons tirées de sa conception

Trois choses n’étaient pas évidentes avant l’existence des agents :

• L’étape de confirmation est cruciale. Une question bien placée avant des actions destructrices permet de distinguer un agent utile d’un agent dangereux. Le faire correctement signifie considérer l’approbation humaine comme une contrainte architecturale, et non simplement comme une case à cocher, ce qui vous oblige à déterminer quels nœuds dans chaque graphe ont réellement des effets secondaires.
• La conception de l’état est la partie la plus difficile. Faire fonctionner la logique de l’agent est aisé. Déterminer ce qui doit persister, ce qui reste temporaire et comment les erreurs se propagent nécessite des itérations ; l’agent Kubernetes a subi trois redessins de son état avant que le flux de diagnostic ne paraisse naturel.
• Les outils sont plus importants que le choix du modèle. Un agent n’est aussi performant que ses outils. Faire en sorte que les fonctions des outils AWS retournent des résultats structurés et cohérents a donné de meilleurs résultats que de simplement ajuster les prompts, car un modèle raisonne mieux lorsque les données qu’il reçoit sont propres.

Que vient ensuite

Ce n’est qu’un point de départ et non un produit final. Les agents couvrent les workflows cloud et DevOps les plus courants, mais il reste encore beaucoup à faire. Parmi les orientations envisagées figurent le support multi-cloud avec des agents pour GCP et Azure, la détection des anomalies de coûts basée sur des modèles historiques plutôt que sur des seuils statiques, la correction automatique des écarts où l’agent génère et applique la solution avec approbation, ainsi qu’une intégration plus étroite avec les flux Claude Code et Cursor MCP.

Comment contribuer

Vous n’avez pas besoin d’être un expert, seulement curieux. L’aide la plus utile dépend de qui vous êtes :

• Ingénieur DevOps ou cloud : exécutez un agent sur une infrastructure réelle et rapportez ce qui a mal fonctionné, quels résultats vous ont déroutés et quel workflow vous attendiez qu’il gère. Les retours du monde réel constituent les informations les plus précieuses à ce stade.
• Développeur : choisissez n’importe quel agent, lisez sa définition graphique et améliorez-y quelque chose, que ce soit une meilleure gestion des erreurs, un outil manquant ou un champ d’état qui devrait être suivi. La base de code est suffisamment petite pour comprendre un agent entier en environ 30 minutes.
• Nouveaux venus dans le domaine des agents DevOps : le répertoire sert également d’environnement d’apprentissage. Créez une branche, exécutez-le localement avec Ollama afin d’éviter les coûts liés aux API, et lisez le code en même temps qu’un guide général sur les agents DevOps. Ouvrir un ticket pour poser une question compte comme une contribution.
• Tout le monde ayant une idée pour un nouvel agent : ouvrez un ticket décrivant le flux de travail. Si quelque chose que vous faites manuellement aujourd’hui devrait être automatisé, mentionnez-le. Un agent d’audit pour Secrets Manager, des agents multi-cloud et un agent de détection des anomalies de coûts font tous partie du plan de développement et sont ouverts à qui souhaite les créer.

Marquez ce dépôt comme favori, ouvrez un problème ou envoyez une demande de fusion. L’objectif est des agents fiables en production, développés de manière ouverte.