AI-DLC & test augmenté
Quatre-vingt-dix pour cent des professionnels du développement travaillent aujourd'hui avec l'IA, et le volume de code qui arrive en revue a augmenté d'autant. Ce qui décide si cette vitesse devient de la valeur livrée ou de l'instabilité n'est pas l'assistant : c'est ce qui vérifie sa production, et à quel moment.
L'IA ne répare pas une chaîne de livraison. Elle amplifie celle que vous avez.
L'adoption de l'IA accélère la production de code sans améliorer, à elle seule, ce qui la contrôle. Le volume qui arrive en revue augmente, et il arrive dans les barrières qui existaient déjà.
Notre intervention porte donc sur la chaîne plutôt que sur l'assistant : des exigences écrites pour s'exécuter, des tests dérivés du comportement attendu, un petit nombre de barrières qui tiennent, et un ingénieur nommé qui répond de ce qui est livré. C'est ce qui distingue une équipe qui produit davantage d'une équipe qui livre davantage.
Ce que nous faisons
Quatre chantiers, de l'exigence écrite pour s'exécuter jusqu'à l'incident vu avant l'utilisateur.
Écrire l'exigence pour qu'elle s'exécute
Des comportements attendus sous une forme qu'une machine peut vérifier, produits avec le métier plutôt qu'après lui. C'est ce qui permet de comparer le code généré à l'intention, et non à l'opinion de celui qui relit.
une exigence précisée à l'oral n'arbitre pas une revue de code générée
- Un comportement, une vérification exécutable
- Écrite avec le métier, avant la génération
- L'écart avec le code se voit tout seul
Dériver les tests de l'exigence
Des cas de test tirés de la spécification, pas du code qui vient d'être écrit. Un test dérivé du code confirme ce que le code fait, défauts compris, ce qui est exactement le piège quand le code a été produit en quelques secondes.
un test écrit après le code confirme le code, ses défauts inclus
- Des cas tirés du comportement, pas de l'implémentation
- L'ambiguïté de l'exigence révélée, pas lissée
- Une couverture mesurée sur les comportements
Tenir un petit nombre de barrières
Couverture des comportements, vulnérabilités des dépendances, accessibilité et budget de poids, vérifiés au commit. Assez peu nombreuses pour que personne ne les désactive au premier lot menacé, ce qui est précisément ce qui en fait des barrières.
quatre barrières qui tiennent valent mieux que vingt qui cèdent
- Des contrôles bloquants volontairement peu nombreux
- L'assistant propose, un ingénieur nommé répond
- La duplication surveillée, car c'est là que ça dérive
Vérifier ce que dit la production
Des objectifs de service posés sur les parcours réels, une détection qui voit l'incident métier avant que les clients ne le signalent, et chaque déploiement rattachable au changement qui l'a causé.
une chaîne qui livre vite sans observer pose ses défauts plus vite
- Des objectifs sur les parcours, pas sur l'infrastructure
- Une détection avant le premier appel client
- Chaque déploiement rattaché à son changement
La boucle que nous outillons
Le cycle de vie AI-DLC
Quatre phases, une boucle gouvernée : le cadrage transforme l'intention en specs, les agents génèrent, les garde-fous vérifient et la delivery livre en continu.
Les quatre phases
Ce que vous recevez
Un même projet traverse les quatre livrables ci-dessous : la reprise d'un parcours de souscription par la chaîne augmentée. Chaque étape dit ce qui est réellement remis, dans l'ordre où il l'est.
Le périmètre confié aux agents
Ce qu'ils ont le droit de produire, et les trois zones qu'ils ne touchent jamais : le calcul de prime, la migration des contrats en cours et tout ce qui écrit dans le référentiel client. Décidé avant, pas pendant.
parcours-souscription
- 01-perimetre-agents.yaml
- 02-tests-derives.feature
- 03-barrieres.yaml
- 04-mesure.yaml
Des tests dérivés de l'exigence
Des scénarios écrits depuis le comportement attendu plutôt que depuis le code généré, y compris l'ambiguïté que l'assistant avait tranchée seul et qui repart au métier.
parcours-souscription
- 01-perimetre-agents.yaml
- 02-tests-derives.feature
- 03-barrieres.yaml
- 04-mesure.yaml
Quatre barrières, pas quinze
Comportements couverts, vulnérabilités, accessibilité et plafond de duplication. La couverture de lignes et la complexité restent volontairement non bloquantes : elles se contournent sans rien prouver.
Une mesure de la chaîne, trois mois après
Le débit a doublé et toutes les barrières ont tenu. Le goulot s'est déplacé sur la revue humaine, à trente et une heures avant première relecture, c'est-à-dire au bon endroit.
Comment on travaille
Discover
selon le périmètre, le secteur et le niveau de conformité exigé
- Audit des cas d'usage et des irritants
- Matrice valeur / faisabilité
- Spécification exécutable (ASDD)
MVP
selon la complexité du système et les intégrations
- Un agent en environnement réel
- Tests générés et couverture mesurée
- Go / no-go avant l'industrialisation
Scale
selon le nombre d'agents et de systèmes raccordés
- Orchestration multi-agents sur socle mutualisé
- Intégration CI/CD et MLOps
- Montée en compétences des équipes
Run
engagement de service défini avec vous
- Observabilité LLMOps
- Optimisation FinOps des coûts IA
- Audit continu de conformité
Ce que montre vraiment la chaîne augmentée
Des chaînes qui tiennent à cette vitesse
Des barrières qui tiennent, sur dix-huit squads à la fois
couverture 41 % → 83 % · incidents post-release ÷4
Des produits d'assurance vie où un défaut arrivé en production est un contrat mal calculé, sur une chaîne de livraison qui devait accélérer à travers dix-huit squads produit sans que les contrôles redeviennent négociables à l'approche d'une date.
Des quality gates bloquants intégrés à la chaîne plutôt que posés à côté, une couverture de tests portée de quarante et un à quatre-vingt-trois pour cent, et la pratique transmise par une académie DevOps interne pour que les squads la tiennent elles-mêmes.
Voir l'incident avant que le client ne le voie
time-to-detect ÷5 · remédiation P1 ÷3
Des parcours de paiement, de connexion et de virement où un incident est vu par les clients avant la supervision, et où chaque minute de détection est une minute de transactions qui ne passent pas.
Quarante-huit indicateurs de service alignés sur les parcours réels plutôt que sur l'infrastructure, une détection d'incident métier ramenée de vingt-cinq minutes à moins de cinq, et une remédiation P1 passée de vingt-huit minutes à neuf.
Insights & Perspectives
Cas de tests générés par IA à partir de user stories
Une expérimentation contrôlée mesure ce que rend vraiment la génération de tests par IA : quatre-vingts pour cent de temps gagné, et vingt-sept pour cent d'ambiguïté restée dans l'exigence.
Comment l'IA peut simplifier et accélérer les tests d'acceptation
Automatiser la génération de scénarios, l'analyse des résultats et la détection d'anomalies en recette, et ce que cela change pour ceux qui la conduisent.
Fuzz-testing à l'ère de l'IA
Une technique vieille de quarante ans qui n'a jamais été largement adoptée, et ce qui change maintenant que générer et trier les cas ne coûte presque plus rien.
Vérifiez au rythme où vous produisez désormais
Des exigences exécutables, des tests dérivés du comportement, un petit nombre de barrières qui tiennent, et une production observée sur les parcours qui comptent.
Questions fréquentes
Non. L'étude DORA 2025 constate que l'adoption de l'IA augmente en même temps le débit de livraison et l'instabilité de livraison. L'IA amplifie la chaîne que vous avez déjà : là où les contrôles tiennent, le gain est réel ; là où ils étaient négociables, les dégâts arrivent simplement plus tôt et en plus grand nombre.
Parce qu'un test tiré du code confirme ce que le code fait, défauts compris. C'était déjà une habitude fragile ; elle devient un piège quand le code a été produit en quelques secondes et que personne ne l'a lu ligne à ligne. Dériver les cas du comportement écrit est ce qui rend la comparaison possible.
En déplaçant la lecture sur l'exigence plutôt que sur chaque ligne. Les comportements exécutables disent ce qui était attendu, les tests qui en dérivent échouent là où le code s'en écarte, et un ingénieur nommé signe le résultat. Tout lire a cessé d'être possible ; tout confronter à une intention écrite, non.
La duplication, et la part de code réellement refactorisé. GitClear mesure un code déplacé tombé à 3,8 % des lignes modifiées en 2026 contre 21 % en 2022, quand les blocs dupliqués progressent de 81 % par rapport à 2023. Un assistant rend l'insertion d'un bloc moins coûteuse que sa restructuration, et cela se paie en maintenance un an plus tard.
Peu. Une longue liste de contrôles bloquants est désactivée au premier lot menacé, et n'est jamais réactivée. Quatre qui tiennent toujours valent mieux que vingt qui cèdent à la première semaine difficile, et c'est cette fiabilité, pas leur nombre, qui en fait des barrières.
Il déplace l'effort plus tôt. Écrire un comportement pour qu'il s'exécute coûte des heures ; découvrir à la recette que le code généré répondait à une autre question coûte une refonte. La spécification sert deux fois, puisque c'est elle qui sert à relire le code produit.
Le cadrage prend 2 à 6 semaines selon le périmètre, le secteur et le niveau de conformité exigé, et produit les comportements exécutables, les barrières qui bloqueront et le périmètre confié aux agents. Un premier parcours livré par la chaîne augmentée, en production et non sur un démonstrateur, suit en 4 à 10 semaines.