Des guardrails en CI : de la vitesse qu’on peut merger

Des guardrails en CI pour le code IA, ce sont des règles que ni un développeur pressé ni un agent ne peuvent contourner : des tests exigés sur ce qui change, une analyse statique bloquante, des scans de sécurité, des règles de revue appliquées au moment du merge. C’est le socle d’une équipe qui produit beaucoup de code assisté, et la réponse à la seule question qui compte quand le volume augmente : cette vitesse, peut-on la merger sans crainte ?

La plupart des équipes ont déjà une partie de ces briques. Ce qui change avec les agents, c’est que ces briques passent du statut de bonne pratique à celui d’infrastructure critique.

Pourquoi la CI et pas la charte

Beaucoup d’organisations répondent au code généré par un document : une charte d’usage de l’IA, des recommandations de relecture, des conventions. C’est utile pour aligner les humains. Mais un agent ne lit pas la charte, et un développeur qui relit son quinzième diff de la journée ne l’applique plus. Une règle qui repose sur la vigilance individuelle cesse de fonctionner exactement quand on en a besoin : sous le volume.

La CI est le seul endroit où une règle s’applique à cent pour cent des changements, humains ou générés, les bons jours comme les mauvais. C’est aussi un endroit que l’agent comprend : un pipeline qui échoue avec un message clair est un feedback qu’il exploite pour corriger seul. Un paragraphe de charte, non.

Le socle minimal de guardrails en CI

Voici ce que nous installons en priorité chez nos clients, au démarrage d’un programme d’ingénierie agentique, dans cet ordre :

1. Des tests qui passent, et une exigence de couverture sur les lignes modifiées (pas sur le total du repo, qui ne veut rien dire). Un agent à qui l’on demande du code testé en produit ; un agent à qui on ne demande rien n’en produit pas.
2. Une analyse statique et un linting bloquants, avec les règles de complexité et de duplication activées. C’est la parade la plus directe à la dette que le code généré accumule quand personne ne regarde.
3. Un scan de secrets sur chaque commit. Les agents manipulent des fichiers de configuration avec un aplomb total, et un jeton qui fuit dans un repo est un incident, pas un détail.
4. Un audit des dépendances. Le code généré tire volontiers avec lui des bibliothèques inutiles, obsolètes, ou pire. Chaque dépendance nouvelle doit se justifier.
5. Une CI rapide. Sous dix minutes si possible : un agent itère au rythme de votre pipeline, et une CI de quarante-cinq minutes transforme la délégation en attente.

Rien d’exotique. La différence se joue dans le caractère bloquant : un avertissement que l’on peut ignorer sera ignoré, par les humains comme par les machines.

Les règles de revue au moment du merge

Le deuxième étage s’applique aux pull requests. Des branches protégées, un relecteur humain requis sur les chemins sensibles, et un plafond de taille de diff : au-delà de quelques centaines de lignes, une revue honnête devient une signature. Plafonner la taille force le découpage en amont, et c’est le découpage qui rend la revue possible. Sans cela, la revue devient le goulot d’étranglement qui annule les gains d’écriture.

Une règle d’équipe complète le dispositif, et celle-là est humaine : la personne qui merge répond du code, qu’il ait été écrit à la main ou généré. Pas de catégorie "code de l’agent" dont personne ne serait responsable.

Des guardrails qui travaillent pour les agents

On présente souvent les guardrails comme une défense contre le code généré. C’est la moitié de l’histoire. Bien construits, ils sont aussi ce qui rend les agents réellement productifs : un agent face à une CI stricte et rapide converge vers du code conforme sans intervention, parce que chaque exigence explicite est une consigne qu’il sait satisfaire. Vos standards, une fois encodés, deviennent une spécification exécutable.

Ils sont enfin votre filet pour les sujets qui ne pardonnent pas, la sécurité du code généré en tête : les études convergent pour dire qu’une part importante du code produit par les modèles contient des vulnérabilités, et aucune relecture humaine ne tiendra ce front seule à l’échelle.

Monter ce socle prend typiquement deux à trois semaines, en parallèle d’un pilote plutôt qu’avant lui : la vitesse ne vaut que si vous pouvez la merger.