Vélocité doublée avec l'IA… et la recette ? Nos vrais chiffres
« Avec l’IA, on développe deux fois plus vite. » La phrase est partout. Nous avons voulu vérifier ce qu’elle recouvre chez nous, chiffres à l’appui, et surtout ce qu’elle ne dit pas.
C’est l’hypothèse de départ de PACE, notre méthodologie projet accélérée par l’IA : la vélocité augmente, mais la valeur réellement livrée et recettée ne suit pas forcément. Encore fallait-il le démontrer.
La méthode : aucun chiffre estimé à la main
Nous avons analysé deux produits que nous développons pour le même client, l’un depuis 2025, l’autre depuis le printemps 2026 :
- près de 2 000 tickets Jira, avec leurs historiques complets de changements de statut ;
- les rapports de sprint et graphiques de vélocité ;
- les merge requests GitLab.
Nous avons comparé les sprints avant et après l’arrivée de notre agent de développement dans l’équipe. Tous les chiffres sont recalculables depuis les API : aucun n’a été saisi à la main.
Produit A : la vélocité a bien doublé
Sur le produit le plus récent, une plateforme de prise de rendez-vous, l’effet est net :
| Indicateur | 6 sprints avant | Avec l’agent | Évolution |
|---|---|---|---|
| Vélocité (story points terminés / sprint) | 67,3 | 139,5 | × 2,1 |
| Bugs créés pour 10 SP livrés | 1,29 | 0,77 | – 40 % |
À première lecture, c’est le scénario rêvé : deux fois plus de livraisons, et une densité de bugs en baisse.
Mais la recette, elle, s’est effondrée
En regardant le passage en recette, l’étape où l’on vérifie que ce qui a été livré correspond au besoin, le tableau change :
| Indicateur | Avant | Avec l’agent |
|---|---|---|
| Durée médiane en recette | 7,8 jours | 1,0 jour |
| Sorties de recette faites par la personne qui avait livré | 20 % | 55 % |
| Réouvertures de tickets terminés / sprint | 0,5 | 2,5 |
| Part de la vélocité consacrée aux bugs | 12 % | 20 % |
Une recette qui passe de huit jours à un seul, ce n’est pas une recette plus efficace : c’est une recette qui ne filtre plus. Plus d’un ticket sur deux est désormais validé par la personne même qui l’a livré. Les réouvertures sont multipliées par cinq.
Et le stock de tickets « en recette » a atteint son record historique : 31 tickets, soit 97 story points en attente de validation. C’est plus qu’un sprint entier de vélocité d’avant l’IA.
La valeur est produite, mais elle attend. Le goulot d’étranglement s’est déplacé du développement vers la validation.
Produit B : pas de doublement
Sur le second produit, plus ancien et porté par une équipe plus large, la vélocité n’a progressé que de 13 %. La contribution directe de l’agent y est restée marginale, ce qui rend l’effet impossible à isoler. On y observe en revanche une légère hausse des livraisons sans aucun passage en recette (de 12 % à 19 %), sans qu’on puisse l’attribuer à l’IA.
Conclusion honnête : l’hypothèse est confirmée sur le produit A, non démontrée sur le produit B.
Les limites de l’exercice
Nous préférons les dire plutôt que de les taire :
- l’échantillon « avec l’agent » est court (2 sprints clos sur le produit A) : les tendances sont à confirmer ;
- l’équipe a changé en même temps (plus de contributeurs) ;
- plusieurs indicateurs utiles ne sont tout simplement pas mesurables avec nos données actuelles : le coût en tokens par fonctionnalité, les bugs causés par une livraison précédente, le temps passé à attendre une réponse du client, la phase où chaque défaut a été détecté.
Cette dernière limite est peut-être l’enseignement le plus important : on ne pilote pas ce qu’on ne mesure pas, et nos outils n’étaient pas instrumentés pour l’ère des agents.
Ce que nous changeons
De cette analyse sont sorties des actions très concrètes, peu coûteuses à mettre en place :
- Rendre la recette indépendante : interdire, dans le workflow Jira, que la personne qui a livré un ticket le valide elle-même.
- Limiter le stock en recette, avec une limite d’en-cours sur la colonne et un suivi hebdomadaire de son ancienneté.
- Tracer les reprises : tout bug lié à une livraison doit pointer vers le ticket d’origine.
- Ajouter un champ « détecté en » sur les bugs : revue de code, recette interne, recette client, production.
- Rendre visible l’attente client, avec un statut dédié pour mesurer les délais de réponse.
- Rattacher la consommation de tokens aux tickets, pour connaître enfin le coût réel d’une fonctionnalité recettée.
Et surtout, nous concevons un agent de recette indépendant, chargé de préparer le travail de validation sans jamais le remplacer. Nous y reviendrons dans un prochain article.
En résumé
L’IA double bien la vitesse de production du code. Mais un projet avance à la vitesse de son maillon le plus lent, et ce maillon, chez nous, s’est révélé être la recette. Accélérer le développement sans accélérer la validation, c’est remplir un entrepôt plus vite qu’on ne le vide.
La bonne question n’est donc pas « combien de code l’IA produit-elle ? », mais « combien de valeur recettée livrons-nous en production ? ».