Agent IA pour le tri des échecs CI et la réponse aux incidents

Un déploiement qui échoue en pleine nuit ne devrait plus réveiller personne. Pourtant, dans beaucoup d'équipes, c'est encore un ingénieur d'astreinte qui ouvre les logs à froid, cherche le commit fautif et tape le message Slack qui prévient les autres. Un agent IA autonome peut prendre en charge cette première étape, sans jamais remplacer le jugement humain sur la cause racine ou le correctif.

Le problème

Les chiffres sur la fiabilité des pipelines CI/CD ne sont pas bons. Selon le rapport 2026 State of Software Delivery de CircleCI, le taux de réussite des builds sur la branche principale est tombé à 70,8 %, le plus bas niveau observé en cinq ans et largement sous le seuil de 90 % que l'éditeur recommande (CircleCI, 2026). Concrètement, environ trois tentatives de merge sur dix échouent avant même d'arriver en production.

Côté incidents, le rapport State of Incident Management de Runframe, publié début 2026, constate que la part du temps d'ingénierie absorbée par le travail opérationnel de routine (répondre aux alertes, trier les échecs, faire remonter l'information) est repassée à 30 %, en hausse pour la première fois en cinq ans malgré les investissements en IA (Runframe, 2026). Le même rapport avance qu'environ deux tiers des alertes générées chaque jour seraient ignorées faute de temps pour les trier correctement. C'est un ordre de grandeur à prendre avec prudence : le rapport agrège plusieurs études externes et des entretiens qualitatifs, ce n'est pas une mesure directe et unique.

Le rapport DORA 2025 sur le développement logiciel assisté par IA va dans le même sens sur un point de fond : l'IA amplifie ce qui existe déjà dans une organisation, elle ne corrige pas un processus de triage bancal, elle le rend simplement plus visible, plus vite (DORA, 2025). Un pipeline mal surveillé le reste, avec ou sans IA, tant que personne ne regarde les échecs en continu.

Ce dernier point compte particulièrement pour les équipes qui tournent avec une astreinte réduite, où une seule personne mobilisée surveille plusieurs services à la fois. Un échec de build qui arrive à 3h du matin n'attend généralement pas que quelqu'un se réveille pour être classé : soit il reste ignoré jusqu'au matin, soit il réveille quelqu'un pour un problème qui, une fois trié, s'avère mineur. Les deux issues coûtent cher, l'une en délai de résolution, l'autre en fatigue d'astreinte accumulée sur la durée.

Ce que fait l'agent, étape par étape

Sur Atako, cet agent ne se déclenche pas une fois puis ne s'arrête plus : il tourne en continu dans son propre environnement isolé. Deux mécaniques d'entrée le nourrissent, un webhook entrant que l'équipe configure pour recevoir les événements CI/CD, et une tâche cron que l'agent programme lui-même pour vérifier périodiquement l'état des workflows si le webhook venait à manquer un événement.

Une fois qu'un échec arrive, l'agent lit les logs et la stack trace du job pour classer le type de problème (compilation, test, dépendance, déploiement), puis il corrèle cet échec avec les commits et pull requests récents pour identifier l'auteur probable et le changement suspect. Il poste ensuite un résumé structuré sur Slack dans le canal d'astreinte, avec les liens directs vers le job et le commit en cause, et ouvre en parallèle un ticket Jira lié au build. Si la sévérité dépasse un seuil défini par l'équipe (déploiement bloqué, plusieurs services touchés), une escalade supplémentaire part vers les bonnes personnes. Enfin, il rédige une première version du rapport d'incident : chronologie, services affectés, logs pertinents, cause suspectée, laissée volontairement ouverte à la relecture humaine plutôt que présentée comme une conclusion définitive.

Les intégrations mobilisées

Chaque intégration est accordée via un grant précis, qui limite exactement ce que l'agent peut faire, jamais un accès générique à l'outil entier.

GitHub et GitLab fournissent la lecture des pipelines, des jobs et des commits, avec une écriture optionnelle pour créer ou commenter une issue si le grant couvre ce scope. Sur GitHub, les actions concrètes en jeu sont list_workflow_runs et get_job_logs_download_url côté lecture, create_issue et add_issue_comment côté écriture.

Slack reçoit les résumés de triage via post_message, dans le canal choisi par l'équipe, avec la possibilité de programmer un rappel via schedule_message si un incident reste ouvert trop longtemps.

Jira porte le ticket d'incident lui-même : create_issue à l'ouverture, update_issue et transition_issue au fil de la résolution, jusqu'à la clôture.

Datadog, quand l'équipe l'a connecté, permet à l'agent de croiser les métriques de performance et les traces applicatives avec l'échec CI pour affiner son hypothèse de cause racine. PagerDuty n'a pas de page intégration dédiée sur Atako pour le moment, mais reste utilisable comme destination d'alerte via un webhook sortant configuré côté Jira ou Slack.

Ce qui reste à l'humain

L'agent ne décide jamais seul de fusionner un correctif, et ce n'est pas un détail de conception, c'est la façon dont Atako structure l'autonomie. Chaque action que l'agent peut exécuter sur GitHub, GitLab, Jira ou Slack dépend d'un grant explicite : quelles actions précises sont autorisées, avec quelle portée (lecture seule ou lecture et écriture). Cette portée fait foi même si une action d'écriture se retrouvait par erreur dans une liste d'actions autorisées en lecture, et rien n'est jamais accordé par défaut à la simple connexion d'un outil.

Ça laisse trois choses clairement du côté humain. D'abord, l'investigation de la cause racine et la décision technique du correctif : l'agent fournit un point de départ (logs, commit suspect, historique), pas un diagnostic définitif. Ensuite, l'écriture et la fusion du code, une action humaine par nature, hors du périmètre de ce que l'agent peut faire. Enfin, le post-mortem : ajuster les seuils de criticité, revoir le runbook, améliorer les règles de triage, un travail d'équipe que l'agent ne remplace pas.

Ce partage relève de ce qu'on appelle le human-in-the-loop : l'agent absorbe la partie répétitive et chronophage du triage, l'humain garde la main sur les décisions qui comptent vraiment. Pour vérifier ce que l'agent a réellement fait, chaque appel d'intégration est journalisé, avec l'agent concerné, l'action, le statut (autorisé et exécuté, refusé par un contrôle de grant, ou échoué côté fournisseur) et la latence. Cette trace est visible dans la timeline d'activité de l'agent et, pour un administrateur, dans le journal d'intégration de toute l'entreprise, exportable en CSV.

Résultat mesurable

Le bénéfice le plus direct, c'est le temps entre l'échec du build et le moment où la bonne personne a l'information complète pour agir. Plus besoin d'attendre qu'un humain remarque l'alerte, ouvre les logs et recoupe manuellement avec les commits récents : l'agent le fait en continu, y compris à 3h du matin, sans jamais dormir ni changer d'humeur selon la charge de la semaine. Ça ne remplace pas les métriques DORA classiques comme la fréquence de déploiement ou le délai de restauration après échec, mais ça réduit la part de ces métriques qui dépend uniquement de la disponibilité humaine à un instant donné.

Le coût suit le plan Standard d'Atako : 20 euros par mois par emplacement d'agent (slot), avec 1000 crédits inclus chaque mois pour couvrir les appels au modèle utilisés par la réflexion, la classification et la rédaction. Pour chiffrer le retour avant de se lancer, le détail est sur la page tarifs.