Un responsable DevOps open-source nib : l'agent découpe un déploiement AWS en étapes, vérifications et retour arrière

« Déploie un nouveau service web sur AWS et crée les jobs de déploiement ». Une seule ligne dans le tracker. Derrière, il y a le réseau, les conteneurs, la base de données, les secrets, le CDN, deux workflows et des dizaines de petites actions que l'ingénieur garde en tête. Tant que personne ne vous interrompt, cela fonctionne. Mais après un appel, on ne sait plus si le port de la base a bien été fermé, et à la question « combien de temps ça prendra ? », la seule réponse honnête reste « un jour ou deux ».

L'auteur de cette analyse dirige une équipe DevOps dans un studio de jeux vidéo et compte 15 ans d'expérience. Il a formalisé sa façon de planifier et l'a confiée à un agent baptisé nib (Neuro Infrastructure Builder).

Comment planifie un ingénieur expérimenté

On commence par rassembler le contexte : de quel projet s'agit-il, comment l'infrastructure actuelle est organisée, ce que l'on sait des produits mentionnés dans la tâche. Ensuite, la tâche est découpée en grandes étapes : code d'infrastructure, workflows de build et de déploiement, création des ressources, déploiement, vérification. Plus que la liste elle-même, ce sont les dépendances entre les étapes qui comptent, car elles déterminent ce qui peut être fait en parallèle.

Chaque étape est ensuite décomposée en actions élémentaires : modifier un fichier, exécuter une commande, faire un appel d'API. Chaque action nécessite une vérification et un retour arrière. Par exemple, après terraform plan, le diff ne doit contenir aucun destroy, et après apply, RDS doit être au statut available. La colonne « Retour arrière » reste le plus souvent vide. L'auteur pose la question : quand avez-vous écrit pour la dernière fois un plan de retour arrière avant d'en avoir besoin ?

Le processus se brise à trois endroits. Des points s'oublient lors des changements de contexte : l'auteur a un jour migré des buckets d'assets entre deux clouds et oublié le CORS. Les vérifications sont sacrifiées face aux deadlines, car les sauter ne casse rien immédiatement. Enfin, il n'y a aucune estimation de la charge : tant que la tâche n'est pas décomposée, « un jour ou deux » n'est pas une estimation, mais une impression.

Ce que fait nib

L'outil fonctionne selon trois modes. Decompose pose des questions de clarification et dégage les étapes avec leurs dépendances. Plan lance un agent par étape ; ces agents détaillent en parallèle les actions et les vérifications, tandis qu'un agent distinct construit le retour arrière. Execute réalise l'action via les outils connectés, ou fournit à l'opérateur des instructions détaillées.

Le contexte de l'ingénieur est remplacé par une base de connaissances : description de l'entreprise, VCS, CI/CD, schéma des réseaux, conventions de nommage. Une fois le plan terminé, nib rédige un rapport et met à jour la base, de sorte que la tâche suivante démarre avec ce que l'agent a appris lors de la précédente.

L'installation est locale : git clone, make setup, Docker et la clé de n'importe quel fournisseur compatible OpenAI. Les outils se connectent via MCP en transport HTTP : GitHub, l'API AWS et SearXNG pour la recherche de documentation. Le serveur AWS n'expose que deux outils (appel de la CLI et assistant de commandes), tandis que GitHub en propose une vingtaine. Pour ne pas gonfler le contexte, nib sélectionne, à l'étape de décomposition, uniquement les catégories d'outils nécessaires.

Les pièges à éviter

Les paramètres de sécurité de l'exemple sont généreux. READ_OPERATIONS_ONLY: false autorise les modifications, et REQUIRE_MUTATION_CONSENT: false supprime la confirmation côté serveur MCP. La confirmation se résume alors au bouton Execute dans nib lui-même. AUTH_TYPE: no-auth n'est acceptable que parce que le port n'est pas exposé à l'extérieur et que le service n'est visible qu'au sein du réseau Docker.

Les secrets se trouvent à deux endroits. Les clés AWS sont nécessaires au conteneur aws-mcp, elles sont donc dans le .env. Le jeton GitHub est transmis par en-tête de nib au serveur MCP et stocké dans les secrets de nib avec une liste blanche d'hôtes. Pour GitHub, il faut un jeton classic avec les scopes repo et workflow ; sans le second, l'agent ne pourra pas committer de fichiers dans .github/workflows.

Enseignement pratique

La vraie valeur ne tient pas à la magie de l'agent, mais à la discipline elle-même : action, vérification, retour arrière à chaque étape. Même sans nib, ce tableau mérite d'être rédigé avant de commencer le travail, et une estimation fondée sur le nombre d'actions est plus honnête qu'un « jour ou deux ». Si vous testez l'outil, utilisez un compte AWS de bac à sable dédié et n'accordez à l'agent aucun droit supérieur au nécessaire. Cette partie ne couvre que la base de connaissances ; l'auteur promet de détailler les règles et les compétences dans un prochain article.