L’IA dans la CI

L’Étape précédente s’est arrêtée au sas : la production d’un agent entre dans le circuit de revue commun, jamais directement sur la branche principale. Sauf qu’un circuit de revue dimensionné pour des PR humaines ne survit pas à la cadence des agents.

C’est le renversement que j’ai vu arriver le plus vite en équipe : la production n’est plus le goulot d’étranglement, l’intégration l’est.

Et la réponse n’est pas de relire plus vite. C’est de déplacer dans le pipeline tout le jugement qui peut être rendu par une machine — et, surtout, de savoir lequel peut l’être.

---

Verdict ou avis : quelle différence ?

Un verdict est déterministe, un avis est probabiliste. Tout ce qu’une CI peut dire d’un diff appartient à l’une de ces deux familles, et les confondre est l’erreur structurante de l’IA dans le pipeline.

• Le verdict : compilation, types, tests, lint. Même entrée, même sortie, toujours. Un verdict peut bloquer un merge, parce qu’un verdict ne se discute pas — il se corrige.
• L’avis : une revue par un modèle, une analyse de cohérence, un score de risque. Même entrée, sortie variable. Un avis peut orienter l’attention humaine, jamais la remplacer, et encore moins tenir lieu de condition de merge.

Retenez-en une règle de placement, et elle suffit à trancher tous les cas douteux : dans le pipeline, le déterministe bloque, le probabiliste informe.

Une équipe qui fait bloquer ses merges par l’opinion d’un modèle découvre très vite les deux seules issues possibles : soit on apprend à contourner le juge, soit on apprend à lui plaire. Les deux sont mauvaises.

Pourquoi durcir la CI avant d’y brancher un modèle ?

Parce que votre CI déterministe change de rôle, et qu’elle doit mériter la confiance qu’on va lui demander de porter. Tant que les auteurs étaient humains, la CI était un filet. Quand l’auteur est un agent, elle devient le mécanisme de correction d’erreur lui-même : c’est contre elle que l’agent itère, c’est elle qui fait foi quand personne ne regarde.

Trois conséquences directes.

Tout ce que la revue corrigeait par habitude doit devenir une règle. Conventions de nommage, périmètres d’import, motifs interdits : un relecteur humain les faisait respecter à l’oral. Un agent satisfait ce qui est vérifié, et exactement ça. Une convention non encodée dans le lint ou les types n’existe tout simplement plus. L’Étape précédente l’a posé pour les garde-fous : une règle écrite dans le prompt est une probabilité, une règle appliquée par le système est une garantie.

Un test flaky est une dette qui s’aggrave. Un humain relance le job en soupirant. Un agent, lui, « résout » le flake — en relançant jusqu’à ce que ça passe, en assouplissant l’assertion, ou en supprimant carrément le test. J’ai vu passer ce diff-là, et il m’a fait froid dans le dos :

- expect(rows).toHaveLength(3)
+ expect(rows.length).toBeGreaterThan(0)

Le test est vert. Il ne vérifie plus rien. Un verdict qui se contredit perd son autorité, et un verdict sans autorité enseigne à l’agent que l’échec se négocie.

La sortie de la CI est désormais lue par des machines. Un échec doit être rapide, localisé et lisible : message d’erreur explicite, test en cause identifiable, log exploitable. Chaque minute de pipeline et chaque message cryptique se paient à chaque itération de chaque agent. Votre boucle de feedback est devenue un coût de production.

Que peut vraiment faire une revue automatisée ?

Trois choses, et elles sont réelles — à condition de ne jamais lui en demander une quatrième.

• La première passe. Repérer l’incohérence avec les conventions du projet, le cas limite non géré, l’écart entre le diff et ce que l’issue demandait.
• Le tri de l’attention. Signaler les zones du diff qui méritent la vigilance humaine, celles que Relire du code qu’on n’a pas écrit apprend à lire en premier.
• La constance. Le relecteur machine n’est jamais fatigué un vendredi soir. Et la fatigue de revue, c’est exactement ce que la cadence des agents épuise en premier.

Ce qu’elle ne fait pas, par construction : porter la responsabilité. Un avis de modèle reste une sortie de modèle — plausible avant d’être vraie, sensible à la formulation, et franchement complaisante envers le code qui a l’air propre.

La revue automatisée commente, suggère, alerte. L’approbation reste un acte humain, parce qu’approuver n’est pas constater : c’est engager.

LE CRAFTOMANCER

Méfiez-vous du circuit fermé : un agent qui produit, un modèle qui approuve, et personne entre les deux. L’agent producteur itérera jusqu’à satisfaire le relecteur machine. Il optimise alors la vraisemblance d’une bonne PR aux yeux d’un modèle, pas la qualité du code. Deux jugements probabilistes qui se valident l’un l’autre ne font pas une vérification : ils font un écho. La boucle ne se ferme que sur un verdict déterministe ou un humain.

Dans quel ordre placer les étages du pipeline ?

Du moins cher au plus cher, toujours. Format, lint, types en secondes ; tests unitaires en minutes ; intégration et avis du modèle ensuite ; l’attention humaine — la ressource la plus rare du système — en dernier, sur ce que rien d’autre n’a pu trancher.

J’aime bien voir le pipeline comme une série de tamis : les mailles les plus larges d’abord, pour que le tamis fin ne reçoive que ce qui vaut la peine d’être tamisé. Chaque étage existe pour protéger le suivant. Un avis de modèle sur un code qui ne compile pas, c’est un avis gaspillé. Une revue humaine sur un diff que le lint aurait rejeté, c’est une insulte au relecteur.

Ce classement a un corollaire que je trouve très utile en pratique : si une vérification importante n’existe qu’en revue humaine, votre priorité n’est pas d’ajouter de l’IA au pipeline. C’est de descendre cette vérification d’un étage — en faire un test, une règle de lint, un contrat de type.

L’IA dans la CI ne crée pas de la rigueur. Elle amplifie celle qui existe déjà.

En pratique

• Classez chaque contrôle du pipeline : verdict (déterministe) ou avis (probabiliste). Le verdict bloque, l’avis informe. Jamais l’inverse.
• Encodez en lint, types et tests ce que la revue corrigeait à l’oral : une convention non vérifiée mécaniquement n’existe pas pour un agent.
• Traquez le flake comme un incident : un verdict qui se contredit enseigne à l’agent que l’échec se négocie.
• Branchez la revue par modèle comme première passe et tri d’attention. L’approbation reste humaine, parce qu’elle engage.
• Jamais de circuit fermé agent-producteur / modèle-approbateur : la boucle se ferme sur un verdict déterministe ou un humain.
• Ordonnez par coût croissant et gardez l’attention humaine pour ce que rien d’autre ne tranche.

Un pipeline durci tient la cadence d’un agent ; reste à le faire tenir à l’échelle d’une équipe. Conventions partagées, responsabilité du code généré, transmission du savoir-faire : c’est l’objet de l’Étape suivante, sur les pratiques d’équipe.