OpsPilot

Le problème qui mérite d'être résolu

Une alerte se déclenche à trois heures du matin et annonce qu'un pod redémarre. Ce dont la personne d'astreinte a réellement besoin, c'est des vingt minutes de travail qui suivent, compressées : quel déploiement, ce qui a changé récemment, ce que disaient les journaux avant l'arrêt, si autre chose tombe en même temps, et laquelle des causes plausibles les preuves soutiennent.

Ce travail est mécanique pendant le premier quart d'heure, puis affaire de jugement. La partie mécanique est une bonne cible pour un agent : elle est bornée, les sources de données sont des API, et se tromper coûte peu tant qu'un humain décide de la suite.

Le périmètre, et ce que j'en ai retiré

La version qui mérite d'être construite est étroite. Une alerte arrive par webhook, l'agent rassemble les preuves en direct — état du déploiement et des pods, événements récents, journaux des conteneurs, la métrique déclenchante et ses voisines — et produit une analyse écrite de la cause racine avec une remédiation proposée. Il expose la même capacité comme serveur MCP, afin que l'investigation puisse aussi être menée par conversation depuis un terminal, et pas seulement par une alerte.

Deux éléments qui figureraient dans une description impressionnante sont volontairement hors de la première version. La recherche documentaire sur les incidents passés est le plus évident : c'est la partie la plus susceptible d'absorber tout le projet en produisant un corpus trop petit pour être utile — il lui faut une année d'incidents pour mériter sa place. L'autre est de laisser l'agent ouvrir une merge request avec un correctif. Écrire dans la chaîne de livraison relève d'une classe de risque entièrement différente, et cela ne doit pas être la deuxième fonctionnalité d'un outil dont la première n'est pas encore éprouvée.

• Des identifiants en lecture seule, imposés par le contrôle d'accès du cluster et non par les bonnes intentions de l'agent.
• Chaque remédiation est une proposition qu'un humain applique — l'agent n'agit jamais sur le cluster.
• Le résultat de l'investigation est adossé aux preuves : une conclusion fausse est auditable, et pas seulement fausse.

Pourquoi il est honnête de l'afficher non réalisé

Une version antérieure de ce site décrivait OpsPilot comme s'il existait, avec une pile technique et une liste de fonctionnalités. Ce n'était pas le cas — et présenter une conception comme un système livré est le genre de chose qui survit à un portfolio mais ne survit pas à un entretien.

Il reste donc, affiché pour ce qu'il est. Le cadrage ci-dessus est le véritable produit du travail : choisir la lecture seule plutôt que l'autonomie, différer la recherche documentaire jusqu'à ce qu'il y ait de la matière, et refuser que l'agent écrive dans la chaîne de livraison avant d'avoir mérité la confiance en lecture sur le cluster.