# Corriger automatiquement les échecs de CI avec l’IA

URL: https://agentvera.dev/fr/blog/auto-fix-ci-failures-with-ai/ · Publié: 2026-10-18

Laissez un agent IA corriger les CI rouges et traiter les commentaires de PR : déclencheurs, garde-fous, livraison, et ce qu’il faut vérifier avant main.

**En bref:**

- Dans AgentVera, une règle peut lancer Claude Code ou Codex quand GitHub Actions, GitLab CI ou Jenkins passe au rouge, ou quand un membre du dépôt commente une PR ouverte ; les commentaires sont lus toutes les 2 minutes.
- L’agent travaille dans son propre worktree et ne fait que commiter ; AgentVera pousse après avoir cherché des fichiers de secrets, et ne pousse jamais directement sur la branche par défaut.
- Chaque règle a une limite quotidienne (5 par défaut, jusqu’à 50), et au plus 2 corrections de CI automatiques sont tentées par branche et par jour : une correction qui échoue ne boucle pas indéfiniment.

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 :

| Préréglage | Ce qu’il fait |
| --- | --- |
| Fix CI when it breaks | Lit le log du run rouge et le corrige ; pousse sur les branches de fonctionnalité et ouvre une PR pour la branche principale |
| Handle PR comments | Applique les commentaires de revue sur les PR ouvertes, pousse sur la branche de la PR et répond |

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** :

| Option | Ce qui se passe |
| --- | --- |
| Automatic (push to the CI branch, PR to the main branch) | Push si l’échec était sur une branche de fonctionnalité, PR s’il était sur la branche par défaut |
| Open a PR | Toujours une PR |
| Push to the same branch | Push sur la branche de l’événement ; sur la branche par défaut, c’est quand même une PR |
| Add to the merge queue | La branche rejoint la file et son résultat fusionné est testé |
| Leave on the branch | Rien n’est poussé ; la branche reste chez vous |

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](/fr/blog/merge-queue-for-ai-agents/).

## 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](/fr/blog/ai-code-review/).

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](/fr/features/automations/)
- [Centre CI/CD](/fr/features/ci-cd-center/)
- [Revue de code](/fr/features/code-review/)
- [Pipeline de workflow d’agents IA](/fr/blog/ai-agent-workflow-pipeline/)
- [Agents de code en parallèle](/fr/blog/parallel-coding-agents/)

Pour essayer AgentVera, commencez par la [page d’accueil](/fr/).

## Questions fréquentes

**L’IA peut-elle vraiment corriger les échecs de CI ?** Souvent, pour des tests cassés, des erreurs de types, des échecs de lint et des problèmes de config CI comme une version ou une variable d’environnement. L’agent trouve la première vraie erreur dans le log, la reproduit en local et la corrige. Vous relisez quand même le résultat.

**L’agent pousse-t-il directement sur main ?** Non. AgentVera ne pousse jamais directement sur la branche par défaut. Un échec sur main revient sous forme de pull request ; un échec sur une branche de fonctionnalité est poussé sur cette branche avec la livraison par défaut.

**L’agent peut-il se retrouver dans une boucle de corrections ?** Non. Au plus 2 corrections automatiques sont tentées par branche et par jour, et une seule correction par branche s’exécute ou attend à la fois. Chaque règle a aussi sa propre limite quotidienne.

**Avec quels agents cela fonctionne-t-il ?** Les règles d’automatisation exécutent Claude Code ou Codex. Vous en choisissez un dans le champ Agent de la règle.

**Quels systèmes de CI sont pris en charge ?** Le déclencheur « CI turned red » surveille les fournisseurs GitHub Actions, GitLab CI et Jenkins que vous ajoutez dans l’onglet CI/CD. Les déclencheurs de commentaire de PR et d’issue demandent que le dépôt soit sur GitHub et une connexion GitHub sur votre ordinateur.

**Quelle offre inclut cette fonction ?** Les automatisations sont dans les offres Pro et Team. Dans l’app de bureau, elles se trouvent sous Details → Automation → Automations.

---

**À propos d’AgentVera.** AgentVera est une app de bureau pour macOS, Windows et Linux, développée par Solviera Teknoloji. Elle exécute 18 agents de code IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) côte à côte, par projet, dans de vrais terminaux avec les installations et connexions CLI de l’utilisateur. L’offre gratuite inclut des agents illimités. Télécharger: https://agentvera.dev/fr/download/ · Tarifs: https://agentvera.dev/fr/pricing/