Corriger automatiquement les échecs de CI avec l’IA

Pouvoir corriger automatiquement les échecs de CI avec l’IA vous décharge d’une des corvées les plus répétitives. Vous poussez, et dix minutes plus tard GitHub Actions est rouge. Vous ouvrez le log, parcourez deux cents lignes, trouvez une erreur de type ou un snapshot périmé, corrigez et poussez à nouveau. Les commentaires de PR, c’est pareil : de petites remarques comme « renomme cette variable » ou « il manque un contrôle de null ici » s’accumulent, et chacune vous arrache à ce que vous faisiez.

Cet article explique comment confier ce travail à un agent IA : ce qui le déclenche, les garde-fous sous lesquels il tourne, comment il livre, et ce qu’il faut regarder avant que cela n’atteigne main.

Pourquoi corriger à la main coûte cher

Réparer un build rouge est rarement difficile. C’est le changement de contexte qui coûte :

• Vous êtes en plein autre travail. La notification de CI rouge vous en détourne.
• Lire les logs prend du temps. La vraie erreur est noyée dans des centaines de lignes, et la première ligne rouge n’est souvent pas la vraie erreur.
• Il faut reproduire en local. Trouver la commande de CI, l’exécuter et démêler les différences d’environnement, c’est un travail à part.
• Les commentaires arrivent en morceaux. Une revue de six commentaires oblige à lire les six et à répondre à chacun.

Ces tâches ont en commun un ensemble d’étapes connu. Un travail aux étapes connues, on peut le confier à un agent.

Déclencheurs : quand l’agent démarre-t-il ?

Dans AgentVera, les automatisations se trouvent sous Details → Automation → Automations. Une règle lance un travail toute seule quand un événement se produit. Deux déclencheurs comptent ici.

CI turned red

Ce déclencheur surveille les fournisseurs que vous avez ajoutés dans l’onglet CI/CD : GitHub Actions, GitLab CI et Jenkins. Laissez Branches vide pour surveiller toutes les branches, ou listez-les, comme main, release/*.

Certains runs sont ignorés volontairement. Les runs de pull requests issues de forks et les runs de merge requests GitLab ne déclenchent pas la règle. La branche et le log d’un fork appartiennent à quelqu’un d’extérieur à votre dépôt : la règle ne réagit donc qu’aux branches sur lesquelles vous pouvez pousser une correction.

PR got a comment

Les nouveaux commentaires de revue et de conversation sur les pull requests ouvertes sont lus toutes les 2 minutes, avec des filtres :

• Seuls comptent les commentaires du propriétaire, des membres ou des collaborateurs du dépôt. Un commentaire de passage ne lancera pas d’agent.
• Les commentaires de bots ne comptent pas. Les réponses d’AgentVera sont marquées et jamais reprises.
• Si un agent travaille déjà sur cette PR, les nouveaux commentaires lui sont transmis ; aucun second agent n’est ouvert.
• Si la limite quotidienne est atteinte, les commentaires ne sont pas perdus ; ils sont relus plus tard.

Les déclencheurs de commentaire de PR et d’issue demandent que l’origin du dépôt soit sur GitHub et une connexion GitHub sur votre ordinateur.

Les événements sont surveillés par l’app de bureau : AgentVera doit donc être ouvert sur votre ordinateur pour que les règles s’exécutent.

Préréglages

Quand un projet n’a pas encore de règles, AgentVera propose des préréglages. Deux d’entre eux font exactement ce travail :

Les deux autres traitent les issues étiquetées « ajan » et mettent à jour les dépendances chaque lundi.

Ce que fait l’agent

Quand une règle se déclenche, l’agent démarre dans un nouveau worktree sur une nouvelle branche dont le nom commence par ajan/. La branche part de la branche de l’événement : celle du run rouge ou celle de la PR. Votre dossier de travail n’est pas touché. Les fichiers .env ignorés par git sont copiés dans le worktree pour que les tests puissent tourner, mais ils ne sont jamais poussés.

L’agent suit les étapes du Playbook de la règle. Pour la CI, le playbook par défaut est « Fix a CI failure » :

1. Trouver la première vraie erreur dans le log.
2. Exécuter la commande de CI en local et reproduire l’erreur.
3. Corriger la cause racine ; si le problème vient de la config de CI (workflow, version, variable d’environnement), corriger cela.
4. Relancer les commandes de CI en local et les voir passer.

Pour les commentaires de PR, le défaut est « Address PR comments » : lire chaque commentaire et le code visé, appliquer ceux qui sont justes, expliquer son raisonnement quand on n’est pas d’accord, lancer les tests, et lister dans la réponse ce qui a été fait pour chaque commentaire.

Vous pouvez modifier les playbooks. Enregistrez les vôtres sur cet ordinateur ou dans le dépôt ; les playbooks du dépôt sont écrits sous .agentvera/playbooks/, partagés avec l’équipe via git, et remplacent le playbook intégré du même nom.

Utilisez Extra instructions pour restreindre la règle. Par exemple : « Corrige uniquement les tests et les erreurs de types ; ne change pas le contrat d’API. »

Dans le champ Agent, choisissez Claude Code ou Codex.

Garde-fous : qu’est-ce qui arrête l’agent ?

Un agent qui tourne seul doit être borné, pas seulement bon. Dans AgentVera, les limites sont :

• Une limite quotidienne. Chaque règle a une valeur Max per day de 1 à 50, 5 par défaut, comptée sur les dernières 24 heures. Les runs lancés à la main n’en font pas partie.
• Une limite par branche. Au plus 2 corrections de CI automatiques sont tentées par branche et par jour, et une seule correction par branche s’exécute ou attend à la fois. Si une correction recasse la CI, l’agent ne tourne pas indéfiniment.
• Le texte extérieur n’est pas une instruction. Les logs de CI, les commentaires de PR et le texte des issues sont remis à l’agent comme du texte extérieur non fiable qui ne fait que décrire le travail. On dit à l’agent de ne pas partager de secrets, de ne pas exécuter de commandes sans rapport et de ne pas envoyer de données ailleurs.
• L’agent ne pousse pas. Il ne fait que commiter. Pousser et ouvrir la PR est le travail d’AgentVera, après la remise de l’agent.
• Une analyse des fichiers de secrets. Avant de pousser, chaque commit et l’état final sont analysés à la recherche de fichiers de secrets : fichiers .env, clés comme .pem et .key, id_rsa, .npmrc, .netrc, credentials.json et similaires. Les fichiers d’exemple comme .env.example passent. Si un fichier est trouvé, rien n’est poussé et le run échoue.
• Un agent bloqué s’arrête. Si l’agent demande de l’aide, se tait ou se ferme, le run passe en « needs attention » et vous recevez une notification.

Livraison : où va le travail ?

Ce qui se passe quand l’agent a fini est défini par On delivery :

Une règle ne change jamais : AgentVera ne pousse jamais directement sur la branche par défaut. Si l’agent n’a fait aucune modification, le run se termine avec la note « no changes ».

Pour les commentaires de PR, le travail est poussé sur la branche de la PR et AgentVera poste sur la PR une réponse décrivant ce que l’agent a fait pour chaque commentaire.

Choisir la file de fusion signifie que la correction est testée une fois de plus au-dessus du dernier main. J’explique le fonctionnement de la file dans l’article sur la file de fusion.

Relire avant que cela n’atteigne main

Une correction automatique n’est pas une acceptation automatique. Il y a plusieurs façons de relire le travail de l’agent :

• La pull request elle-même. Les échecs sur main reviennent déjà sous forme de PR. Lisez le diff, regardez la CI passer au vert, fusionnez comme n’importe quelle PR.
• La validation dans la file de fusion. Land passing branches automatically est désactivé par défaut : un travail qui passe son contrôle vous attend donc.
• Leave on the branch. Pendant les premières semaines d’une nouvelle règle, choisir Leave on the branch et relire à la main est l’option la plus prudente.
• L’onglet Runs. Voyez l’état de chaque run, son agent et la PR qu’il a ouverte.

Pour vos propres agents, AgentVera propose aussi une revue de code automatique : quand le tour d’un agent se termine, un modèle Claude de votre choix relit le code et rapporte des constats avec gravité et fichier:ligne. Plus de détails dans l’article revue de code IA.

En relisant, regardez de près :

• A-t-on corrigé le test, ou le code ? Si l’agent a changé une valeur attendue pour faire passer un test, c’est un signal d’alerte. Vous pouvez l’interdire dans Extra instructions.
• La config de CI a-t-elle changé ? Une modification de workflow peut être légitime, ou être une étape sautée.
• Est-il resté dans le périmètre ? Une erreur de type ne doit pas revenir sous forme de refactoring de dix fichiers.

Corrections en un clic depuis le centre CI/CD

Vous ne voulez peut-être pas une règle pour chaque run rouge. L’onglet CI/CD liste les 25 derniers runs par fournisseur ; vous pouvez relancer un run, relancer uniquement les jobs en échec (pas sur Jenkins) ou l’annuler. Sur un run rouge, Have an agent fix it ouvre un agent avec les détails du run et la fin des logs de ses jobs en échec. Cette fois, vous êtes là, avec l’agent.

Erreurs courantes

• Surveiller main avec « Push to the same branch » et attendre un push direct. AgentVera ne pousse pas sur la branche par défaut ; la correction arrive quand même sous forme de PR.
• Pousser la limite quotidienne au maximum. La limite est un filet de sécurité. Gardez-la basse tant que la règle n’a pas gagné votre confiance.
• Laisser Extra instructions vide. Dire à l’agent ce qu’il ne doit pas toucher resserre nettement les résultats.
• Confier des tests instables à l’agent. Pour un test qui échoue de temps en temps, l’agent peut modifier des choses qui n’ont pas à l’être. Réglez d’abord vous-même les tests instables.
• Garder des secrets dans le dépôt. L’analyse bloque le push, mais la vraie solution est de ne jamais mettre de secrets dans le dépôt.

Un exemple de journée

Le matin

Le commit tardif de quelqu’un sur main a cassé la CI. La règle « Fix CI when it breaks » l’a attrapé : l’agent a trouvé l’erreur de type dans le log, l’a reproduite en local et l’a corrigée. Comme c’était la branche par défaut, le travail est revenu sous forme de PR. Vous lisez le diff devant un café et fusionnez.

À midi

Un collègue laisse quatre commentaires sur l’une de vos PR. En moins de deux minutes, la règle « Handle PR comments » se déclenche. L’agent en applique trois, n’est pas d’accord avec un et explique pourquoi. AgentVera pousse sur la branche de la PR et laisse une réponse sur la PR. Il ne vous reste qu’à lire celui qu’il a contesté et à trancher.

L’après-midi

La CI continue d’échouer sur une branche de fonctionnalité. L’agent essaie deux fois, et les tests restent rouges les deux fois. Il n’y a pas de troisième tentative ; vous voyez l’état dans l’onglet Runs. Le log montre que le problème est une variable d’environnement de test, et vous le corrigez vous-même.

Checklist

• Votre fournisseur de CI est-il ajouté dans l’onglet CI/CD ?
• Pour les dépôts GitHub, êtes-vous connecté à GitHub sur cet ordinateur ?
• Le champ Branches est-il bon ? Vide signifie toutes les branches.
• Les Extra instructions disent-elles ce que l’agent ne doit pas toucher ?
• Max per day est-il réglé prudemment ?
• On delivery correspond-il à votre façon de relire ?
• Vos secrets sont-ils hors du dépôt ?

Pour conclure

Confier les échecs de CI et les commentaires de PR à un agent IA vous rend la partie de la journée la plus interrompue. Ce qui compte, ce n’est pas que l’agent soit rapide, mais qu’il soit borné : dans AgentVera, il travaille dans son propre worktree, ne pousse pas de lui-même, n’écrit jamais directement sur la branche par défaut, ne pousse pas de travail contenant des fichiers de secrets et dispose d’un nombre limité d’essais par branche. La décision finale reste à vous, dans la PR ou la file de fusion.

Pour aller plus loin :

• Automatisations
• Centre CI/CD
• Revue de code
• Pipeline de workflow d’agents IA
• Agents de code en parallèle

Pour essayer AgentVera, commencez par la page d’accueil.