Flux de développement avec IA: critères d’acceptation, tests automatisés et CI

Le risque central du code assisté par IA n’est pas la vitesse du modèle. C’est la lenteur du contrôle qui suit: un développeur fatigué lit un grand diff ligne par ligne et confond cette lecture avec une garantie. Le rituel paraît sérieux, mais il protège moins qu’un contrat d’acceptation écrit avant la génération.

La revue humaine reste indispensable. Elle doit simplement porter sur ce que l’humain fait mieux: définir le comportement attendu, les interdits, les limites de données, les risques de migration et les conditions d’arrêt. Lire visuellement un patch propre ne permet pas de simuler toutes les branches, permissions et erreurs d’état.

Un bon flux commence donc par un ordre de travail. Objectif, périmètre, non-objectifs, critères d’acceptation, cas négatifs, commandes de test, règles de sécurité et moment où l’assistant doit demander de l’aide. “Ajoute l’authentification” est trop vague. “Garde le service de hashage, refuse les comptes désactivés, limite les tentatives, journalise les événements et teste le replay de refresh token” devient vérifiable.

Les documents d’Anthropic sur Claude Code, ceux de GitHub sur Copilot coding agent et les guides d’OpenAI sur Codex vont dans ce sens: contexte de projet, instructions explicites, exécution contrôlée, journaux, pull requests, tests et approbation humaine. Le modèle n’est pas le processus; il travaille à l’intérieur du processus.

La résistance vient aussi de la culture métier. Taper du code et commenter une PR sont visibles. Écrire des critères ressemble à de l’administration. Avec l’IA, c’est pourtant là que se trouve souvent la compétence rare: formuler les invariants, les permissions minimales, les cas de refus et la définition de terminé.

Les tests automatisés deviennent la mémoire de la décision. Une instruction dans un chat peut se perdre; une intégration qui échoue reste un signal. Typage, lint, tests unitaires, tests d’API, scans de dépendances et checklist produit donnent au reviewer une base plus solide que la simple impression de propreté.

Il faut aussi traiter la confidentialité, le coût et le verrouillage fournisseur. Les assistants voient parfois du contexte de dépôt, des logs ou des exemples proches de la production. Le contrat doit interdire les secrets, limiter les données, nommer les permissions et garder les vérifications reproductibles hors du chat.

Ce mode convient aux équipes qui utilisent déjà des agents pour du code réel: backend, facturation, authentification, automatisation interne, migration. Les équipes sans tests, sans staging ou sans rollback devraient d’abord construire ces garde-fous.

Le développeur n’est alors plus le linter humain de la machine. Il devient l’auteur des contraintes qui permettent au système de prouver le changement. C’est moins romantique que “j’ai écrit chaque ligne”, mais beaucoup plus proche de l’ingénierie.

Une bonne habitude consiste à demander à l’assistant de prouver d’abord l’hypothèse la plus risquée. Si le changement dépend d’un droit d’accès, il faut le test qui échoue avant l’implémentation. S’il dépend des performances, il faut une commande de mesure et un budget. S’il dépend d’une API externe, il faut simuler l’échec, la reprise et le mode dégradé.

Le reviewer lit toujours les parties importantes: architecture, maintenance, produit, sécurité. Mais il ne joue plus à la fois le compilateur, le testeur et l’auditeur. La revue devient une décision informée, pas un exercice d’endurance visuelle.

Le modèle minimal tient dans une issue: objectif, périmètre, interdits, critères, cas négatifs, commandes de vérification, propriétaire de la revue et rollback. Après quelques semaines, il devient une habitude partagée. Les nouveaux comprennent plus vite ce qui peut être délégué à l’agent et ce qui exige une décision d’architecture. Les seniors dépensent moins d’énergie sur la cosmétique et davantage sur les vraies limites du système.

Le coût de mise en place reste raisonnable. On peut commencer par deux commandes obligatoires dans chaque ticket, un exemple de test négatif et une phrase sur les données interdites. Ensuite l’équipe enrichit la liste quand un incident, un bug ou une revue révèle un angle mort. Le gate n’est pas une cérémonie lourde; c’est une mémoire opérationnelle qui empêche de refaire les mêmes erreurs avec un modèle plus rapide.