51 stories, 4 sprints, 0 régression : comment j'ai livré une academy complète avec des agents IA autonomes

J'ai livré une application de formation complète en 4 sprints d'agents IA autonomes. 51 stories. 68 tests E2E. 5 parcours journey. Zéro bug de régression détecté en test manuel. Le tout en quelques heures de travail agent — pas de travail humain sauf la supervision et le test final.

Ce qui m'intéresse dans cette expérience, ce n'est pas la vitesse. C'est ce qui l'a rendue possible : exactement les mêmes pratiques de gestion de projet qu'on utilise depuis 20 ans — vision produit, découpage en stories, tests automatisés, gates de qualité. Sauf qu'au lieu de les appliquer à une équipe de développeurs, je les ai appliquées à des agents.

Le problème : les deux mauvaises options

Quand on utilise l'IA agentique pour développer un lot de fonctionnalités, on a en général deux options et aucune n'est satisfaisante.

La première, c'est le mode feature par feature. On lance l'agent sur une story, on teste manuellement, on corrige, on passe à la suivante. Le résultat est bon mais l'agent passe 80% de son temps à attendre que l'humain teste. La nuit, le week-end, quand on est sur un autre projet — il ne fait rien. C'est un gaspillage de temps d'horloge considérable.

La seconde, c'est le mode tout d'un coup. On lance toutes les features, on revient plus tard. Le problème c'est qu'on se retrouve avec une montagne de code à tester. Exactement comme un Product Owner qui revient de vacances et découvre 30 stories en "Product QA" dans son Kanban. L'équipe a super bien avancé, les tests unitaires passent, mais personne n'a jamais cliqué sur un bouton pour vérifier que le parcours utilisateur fonctionne de bout en bout.

Il fallait une troisième voie. Et après 4 sprints de production, je peux dire que cette troisième voie fonctionne vraiment.

La méthode : un harnais en 3 couches

L'idée est simple en théorie : donner à l'agent non seulement les stories à développer, mais aussi les critères pour vérifier lui-même que son travail est correct. Pas juste "le code compile" — "le parcours utilisateur fonctionne".

Concrètement, j'ai mis en place trois couches de sécurité empilées.

Couche 1 : l'analyse statique et les tests unitaires. C'est le minimum syndical — PHPStan, TypeScript strict, PHPUnit. L'agent les fait tourner après chaque story. Si c'est rouge, il corrige avant de passer à la suite. Rien de nouveau ici, c'est ce que toute équipe de dev devrait faire.

Couche 2 : un test E2E Playwright par story. Chaque story s'accompagne d'un vrai test navigateur qui vérifie ses critères d'acceptance. Pas un test unitaire frontend — un parcours complet : login, navigation, action, vérification. L'agent l'écrit ET le fait passer.

Couche 3 : les tests journey cross-stories. C'est là que ça devient intéressant. Avant de commencer à coder, j'ai écrit 3 scénarios end-to-end qui traversent tout le produit, de la création d'un devis jusqu'à l'envoi des attestations de formation. Ces tests sont initialement désactivés (test.fixme). Au fur et à mesure que l'agent progresse, il active les étapes que sa story débloque. Si un test journey casse à cause d'une story ultérieure, il le corrige immédiatement.

Le protocole de l'agent pour chaque story devient :

1. Lire la story et ses critères d'acceptance
2. Implémenter le backend + frontend
3. Écrire le test E2E de la story
4. Gate 1 : analyse statique + tests unitaires → vert
5. Gate 2 : test E2E de la story → vert
6. Gate 3 : tests journey (ceux déjà activés) → verts
7. Si rouge → fixer AVANT de passer à la suite

La règle d'or est brutale : ne jamais passer à la story suivante si un test est rouge.

Ce que ça donne en pratique : 4 sprints

Le scope final est une application de formation complète pour mon CRM — academie.alva.do. Au lieu de tout lancer en un seul bloc, j'ai découpé le travail en 4 sprints séquentiels, chacun confié à un agent autonome dans un container Docker.

Avant de lancer le premier agent, j'ai passé environ 2 heures à préparer le terrain. Un PRD de 3 pages qui décrit la vision. 18 stories détaillées avec critères d'acceptance. 3 tests journey en mode fixme. Un Dockerfile avec tout l'outillage (PHP, Node, Playwright, Chromium). Une commande de seed qui crée les données de test. Et un prompt de 200 lignes qui décrit le protocole gate par gate.

Sprint 1 — L'EPIC fondateur : 18 stories pour le socle (rapports hebdomadaires, sessions de formation, convention, émargement digital, app stagiaire, documents partagés). 1h20 d'agent. Résultat : une nouvelle app web complète, 25 endpoints API, 275 tests unitaires.

Sprint 2 — Les présentations : 11 présentations MDX pour le programme de formation (45 min à 15 slides chacune). L'agent a créé le contenu pédagogique — pas juste du code. 33 tests E2E qui vérifient que chaque présentation compile et s'affiche.

Sprint 3 — L'infrastructure quiz : modèle de données (Quiz, QuizAnswer), API (18 endpoints), scoring côté serveur avec classement en temps réel, export CSV, interface d'administration pour le formateur. 14 tests E2E + 11 tests unitaires.

Sprint 4 — L'expérience interactive : page quiz plein écran avec timer animé, classement live avec médailles, résultats détaillés par question, ROTI anonyme, export PDF pour le RH. 21 tests E2E + 1 journey complet.

Le bilan après les 4 sprints :

Un point important : je ne lis plus le code. Je ne l'ai pas lu pendant les 4 sprints et je ne le lirai pas après. Ce n'est pas de la négligence — c'est que les 3 couches de tests font le travail de vérification à ma place. Si les 5 tests journey passent, ça signifie qu'un utilisateur peut se connecter, participer à un quiz avec timer et classement live, signer son émargement, voir ses résultats. C'est plus fiable que n'importe quelle revue de code manuelle.

Ce qui a cassé (et ce que ça nous apprend)

Tout n'a pas marché du premier coup sur le sprint 1. L'agent a livré les 18 stories avec un backend solide, mais il a jugé que les tests journey étaient "hors scope". Il a eu tort, et je l'ai relancé. Au deuxième run, le seed avait des bugs : l'agent avait deviné les noms de champs de l'API au lieu de lire les controllers. L'équivalent d'un développeur qui code contre une API sans lire la documentation. Un troisième prompt a été nécessaire pour corriger un raccourci architectural (iframe au lieu de rendu natif des slides).

Ce qui est remarquable, c'est la suite. Les sprints 2, 3 et 4 se sont chacun déroulés en un seul run, sans intervention humaine pendant l'exécution. Toutes les gates (PHPStan, PHPUnit, TypeScript, Playwright) sont passées du premier coup. La raison est simple : chaque sprint a bénéficié des leçons du précédent. Le prompt s'est affiné. Les garde-fous se sont précisés ("N'utilise PAS de caractères Unicode échappés", "Fais un git commit après chaque story"). Le harnais de tests s'est enrichi.

L'infrastructure des workers a aussi évolué en cours de route. Le premier sprint utilisait un script naïf qui supprimait le clone à chaque lancement — 10 minutes perdues en réinstallation de dépendances. En m'inspirant d'un projet précédent, j'ai réécrit le système avec des clones persistants et un store pnpm partagé entre les workers. Résultat : le deuxième lancement d'un worker prend 15 secondes au lieu de 10 minutes.

Au total sur les 4 sprints : quelques heures de travail agent, environ une demi-journée de temps humain (setup, supervision, tests manuels, corrections UX). La bonne nouvelle c'est que chaque correction a rendu le système plus robuste pour la suite. L'agent a créé de lui-même un service "bouchon" pour remplacer Google Drive en environnement de test, un pattern qui permet à tous les tests de tourner sans configuration externe.

Le vrai enseignement : les sprints séquentiels

Le découpage en sprints séquentiels n'était pas prévu au départ. J'avais initialement voulu tout faire en un seul prompt. Mais après le sprint 1, le pattern est devenu évident : chaque sprint doit construire sur le précédent, pas essayer de tout faire d'un coup.

Sprint 1 (backend + app) → Sprint 2 (contenu) → Sprint 3 (infra quiz) → Sprint 4 (UX interactive). Chaque sprint hérite du code, des tests et du contexte du précédent. L'agent du sprint 3 peut lire les documents créés par l'agent du sprint 2. L'agent du sprint 4 peut réutiliser les endpoints créés par l'agent du sprint 3.

C'est le même principe que dans une équipe humaine : on ne demande pas au même développeur de faire l'architecture, le contenu, l'infra et le frontend en même temps. On découpe, on séquence, on valide à chaque étape. La différence c'est que là, chaque "développeur" est un agent qui travaille en 30 minutes ce qui prendrait 2-3 semaines.

Pourquoi les bonnes pratiques comptent plus, pas moins

Ce retour d'expérience confirme une conviction forte : l'IA agentique n'élimine pas le besoin de bonnes pratiques de gestion de projet. Elle les rend encore plus importantes.

Sans PRD, l'agent code dans le vide. Sans stories découpées, il fait des choix architecturaux incohérents. Sans tests automatisés, il produit du code qui compile mais qui ne fonctionne pas de bout en bout. Sans gates de qualité, les régressions s'empilent silencieusement. Et sans découpage en sprints, un agent qui déraille au milieu vous coûte tout le travail au lieu d'un seul sprint.

La métaphore que j'utilise en formation est celle du chef d'orchestre. Le chef ne joue pas d'instrument, mais sans lui, l'orchestre joue faux. Le PRD est la partition. Les stories sont les mesures. Les tests sont les répétitions. L'agent est l'orchestre. Et vous êtes le chef.

Ce qui change avec l'IA, c'est que l'orchestre joue 100 fois plus vite. Ce qui ne change pas, c'est qu'il a besoin d'une partition pour jouer juste.

Ce que l'humain fait mieux (et doit continuer à faire)

Les 68 tests E2E sont verts. Les 5 parcours journey passent. La mécanique fonctionne. Mais il reste des choses que l'agent ne peut pas valider, et c'est important de les nommer.

Le feeling UX d'abord. Après les 4 sprints, j'ai passé une heure à naviguer dans l'application en me mettant à la place d'un formateur, puis d'un stagiaire. Le timer du quiz était en décompte (15 → 0) alors que ce n'est pas une course de vitesse — je l'ai fait passer en compteur croissant. Les stagiaires voyaient un badge "Piège !" sur certaines questions, ce qui n'a aucune valeur pédagogique — je l'ai retiré. Le temps de réponse était affiché dans le classement, ce qui créait une pression inutile — masqué. Six corrections de ce type, toutes trouvées en test manuel, aucune détectable par un test automatisé.

Le design d'information ensuite. L'agent avait créé deux blocs séparés "Présentations" et "Quiz" dans l'interface du formateur. En pratique, un formateur pense en "programme" : il sait qu'il fait la présentation "Mémoire du projet" le matin du jour 1, puis le quiz correspondant juste après. J'ai fusionné les deux en un bloc "Programme" unique, groupé par jour et demi-journée. Cette décision structurante ne pouvait pas venir de l'agent — elle vient de la compréhension du métier.

En comptant honnêtement, c'est une demi-journée de travail humain sur l'ensemble des 4 sprints — et pas une demi-journée de concentration intense : j'ai fait autre chose en parallèle pendant que les agents travaillaient. Le résultat aurait pris 3-4 mois à une équipe de 2-3 développeurs avec un PO. Pas parce que l'IA est magique, mais parce que les bonnes pratiques, appliquées rigoureusement, créent un effet multiplicateur que les méthodes traditionnelles ne permettent pas d'atteindre.