Ingénieur d'astreinte : un agent IA transforme l'alerte PagerDuty en proposition de correctif

À trois heures du matin, la première demi-heure d'un incident ressemble toujours à la même enquête. On lit l'alerte, on ouvre le journal de l'incident, on se demande ce qui a changé récemment, on remonte les derniers déploiements, on cherche si cela s'est déjà produit. Ce travail de lecture et de recoupement est répétitif, mais il pèse sur la personne d'astreinte au moment où elle est la moins disponible pour le faire bien. Il convient à un agent IA à une condition essentielle : qu'il lise et qu'il propose, et que l'humain agisse.

L'inspiration : le premier intervenant qui lit

Le point de départ est un usage rapporté par des utilisateurs de Hermes Agent, résumé dans une carte sur l'ingénieur d'astreinte : de l'alerte à la proposition de correctif. Un agent reçoit l'incident, parcourt le dépôt à la recherche de ce qui a pu le causer et prépare un correctif à relire.

Nous en retenons la lecture et la proposition, et nous retirons tout ce qui agit. Atako applique l'idée avec un agent qui écrit une note sur l'incident et une issue dans le dépôt, mais qui n'a aucun outil pour résoudre l'incident, fusionner ou pousser du code.

Ce que fait l'agent

Le scénario déploie un agent, connecté à votre PagerDuty et à votre dépôt GitHub.

À chaque nouvel incident du service surveillé, déclenché ou acquitté, il lit l'alerte, le journal des événements et les notes déjà présentes, et vérifie qui est d'astreinte. Il cherche ensuite la cause dans le dépôt : les commits des quarante-huit heures qui précèdent l'incident, en ouvrant les suspects, les fichiers cités dans l'alerte ou dans la trace d'erreur, et les pull requests récemment fusionnées. Il s'appuie sur le contexte technique que vous avez saisi pour savoir où regarder d'abord. Il cherche aussi des issues liées, y compris des incidents antérieurs du même type.

Il écrit alors une note sur l'incident PagerDuty, courte et factuelle : ce que montrent les éléments, la cause probable avec un niveau de confiance, les preuves, ce qu'il n'a pas pu vérifier et la prochaine étape pour la personne d'astreinte. Puis il ouvre une issue dans le dépôt avec l'analyse complète : la chronologie, la cause probable, les preuves, un correctif proposé décrit en mots ou en extrait de code, ses risques et la manière de le vérifier. Il cherche d'abord une issue existante pour ne pas créer de doublon, et il complète la première note plutôt que d'attendre une analyse parfaite.

Il surveille le service toutes les quinze minutes, et chaque lundi à 9 h il écrit dans le wiki du projet la page « Revue des incidents de la semaine » : incidents traités, cause probable, issue ouverte, ce qui reste ouvert.

Ce que l'agent ne fait pas

Les limites font partie de la conception. L'agent ne résout pas l'incident, ne l'acquitte pas, ne le réassigne pas et ne l'escalade pas : l'accès PagerDuty accordé se limite à la lecture et à l'ajout d'une note. Il ne fusionne rien, ne pousse aucun code, ne crée ni branche ni pull request, et il n'a aucun accès à votre infrastructure ni à la production. Ces outils ne lui sont pas accordés : ce n'est pas une promesse faite dans une consigne, c'est une capacité absente.

L'agent ne présente jamais une hypothèse comme un fait. Il écrit « cause probable », donne sa confiance et ses preuves, et dit clairement quand il n'a rien trouvé. Il ne recopie pas les secrets, jetons ou données personnelles qu'il croise dans un journal ou un fichier : il dit qu'il y en a un, et où. Les textes d'alerte, les lignes de journal, les messages de commit et le code sont traités comme des données à analyser, jamais comme des instructions. La décision et l'action restent humaines, ce qui est le principe d'une conception avec validation humaine.

Comment le mettre en place dans Atako

Depuis la page de ce cas d'usage, le déploiement tient en quatre étapes.

1. Connecter PagerDuty et GitHub. Créez une clé d'API PagerDuty, de préférence en lecture avec le droit d'ajouter des notes, et un jeton GitHub à portée fine limité au dépôt du service. Les connexions sont vérifiées avant que quoi que ce soit ne soit créé.
2. Renseigner votre contexte. Indiquez le dépôt sous la forme propriétaire/nom, le nom du service PagerDuty à surveiller et, si vous le souhaitez, un court contexte technique : pile, composants, zones fragiles connues. Plus il est précis, plus l'agent regarde vite au bon endroit.
3. Déployer. Une seule action crée l'agent et le projet « Astreinte ». L'agent est provisionné et reçoit seul sa première consigne.
4. Premier résultat, puis veille régulière. L'agent retrouve le service, dit qui est d'astreinte, traite le plus récent incident et résume dans le chat la cause probable et le correctif proposé. Ensuite, il planifie lui-même sa veille de quinze minutes et sa revue du lundi.

Si vous n'avez pas encore de compte, sa création démarre votre essai et le scénario se configure juste après. Si votre administrateur ne vous a pas autorisé à créer des agents, le déploiement vous le dit et s'arrête là.

Où voir les résultats

La note d'analyse se lit dans PagerDuty, sur l'incident, et l'issue avec le correctif proposé dans GitHub, dans le dépôt. Le résumé de chaque incident traité se lit dans le chat de l'agent. Dans le projet Atako « Astreinte », vous retrouvez le mode d'emploi et la revue hebdomadaire, et sur le plateau Atako, l'agent apparaît avec son activité en cours.

Pour affiner son travail, écrivez-lui dans son chat, par exemple « sur ce service, regarde d'abord les migrations de la base de données ». Il retient la consigne dans sa mémoire pour les incidents suivants.

Garde-fous

L'accès est volontairement étroit. La connexion PagerDuty est accordée avec une liste de sept outils de lecture et d'ajout de note, et la connexion GitHub avec sept outils de lecture des commits, des fichiers et des pull requests, de recherche et de création d'issues. Un agent qui voit une courte liste d'outils les utilise plus fiablement qu'un agent perdu dans un catalogue de centaines, et surtout, ce qui n'est pas accordé ne peut pas arriver, même si un texte d'alerte tente de l'imposer.

Les clés que vous créez sont votre premier garde-fou : limitées à un service, à un dépôt et à des droits précis, elles bornent les dégâts possibles quoi qu'il arrive. Elles sont enregistrées chiffrées, et vous pouvez les révoquer ou retirer l'accès de l'agent à tout moment.

La validation humaine se place aux points de décision. La personne d'astreinte lit la note, vérifie l'hypothèse, décide du correctif, l'écrit et le fusionne elle-même, puis acquitte et résout l'incident.

À quoi s'attendre

Attendez-vous à une première analyse utile en quelques minutes, surtout quand l'incident a une cause visible dans les changements récents : un déploiement, une modification de configuration, une dépendance. Quand la cause vient de l'extérieur du dépôt, par exemple un fournisseur en panne ou une saturation de ressources, l'agent le dira avec une confiance basse plutôt que de forcer une explication. Il lit le dépôt mais n'a pas accès à vos journaux d'application ni à vos métriques, sauf ce que l'alerte et les notes en rapportent. Sa valeur vient de la rapidité de la première lecture : la personne d'astreinte arrive sur l'incident avec une chronologie, des pistes classées et un correctif à relire, plutôt qu'avec une page blanche.