PACE : notre méthodologie projet accélérée par l'IA

L’IA a changé la donne du développement logiciel. Avec Claude et nos agents de développement, la production de code s’est fortement accélérée. Mais cette accélération révèle une vérité inconfortable : le code n’est plus le goulot d’étranglement. C’est le constat qui a donné naissance à PACE — Prototyper · Aligner · Construire · Éprouver — notre cycle projet agile, accéléré par l’IA, pensé pour livrer vite en production sans renoncer à la qualité.

Le constat : le code n’est plus le goulot d’étranglement

Quand l’écriture du code s’accélère, le délai global d’un projet n’est plus dominé par le développement, mais par l’attente des décisions fonctionnelles. Accélérer ce qui n’est pas la contrainte ne raccourcit pas le délai : le goulot s’est simplement déplacé vers l’arbitrage.

Les symptômes sont reconnaissables :

• Un fonctionnel instable : le besoin évolue pendant le développement et impose des reprises.
• Un client peu disponible : les arbitrages arrivent tard, les questions restent ouvertes, la vitesse gagnée se perd en temps morts.
• Un client absent en conception et en recette : les oppositions surgissent tard, en démo — « je ne pensais pas que ça marchait comme ça ».
• Une recette sautée, sous l’effet d’un biais cognitif tenace : « c’est l’IA qui a codé, donc c’est bon ». Les défauts partent en production.

La conclusion est simple : toute la chaîne doit monter en vitesse, pas seulement le développement. La vitesse d’un projet est celle de son maillon le plus lent — conception, décision, recette. Et il faut le rappeler : un bug en production coûte toujours plus cher qu’un bug détecté en conception ou en recette, que le code soit écrit par un humain ou par une IA. Le code généré coûte moins cher, mais il coûte quand même : tokens, relecture, reprises.

Le principe : séparer l’incertain de l’industrialisé

L’IA rend le code jetable et bon marché. PACE en tire parti avec un principe directeur : on explore vite et salement, puis on reconstruit proprement. Seul ce qui est mûr entre dans la chaîne qualité.

L’approche s’inspire du dual-track agile (découverte et livraison en parallèle) et du spec-driven development. Sa spécificité : combiner les deux avec des agents de développement et un niveau de maturité par fonctionnalité. Le principe reste agile — se tromper est permis, c’est même le but de la phase d’exploration.

La règle de l’écrit : la spec, seule entrée des agents

Nos agents ne travaillent qu’à partir d’un écrit formalisé : spec, critères d’acceptation, glossaire métier, décisions tracées. Pas de prompt lancé en direct dans un outil de génération sans trace de la demande initiale, de la manière de la tester et de la manière de la valider.

La distinction est essentielle :

• Ce qui n’est pas la source de vérité : le code généré, l’outil de génération et son historique de prompts, ce qui a été dit en atelier sans être écrit.
• Ce qui l’est : la documentation (spec, règles de gestion, critères d’acceptation), le registre de décisions, le glossaire métier, un écrit accessible à tous — agents, PO, client, utilisateurs.

Sans cette règle, on perd les données, la documentation et l’historique : plus personne ne sait pourquoi l’application se comporte ainsi, ni comment la tester. Le prototypage rapide reste permis en phase Prototyper, mais ce qui en sort doit être écrit en phase Aligner avant d’alimenter les agents.

Le cycle : un socle unique, puis une boucle par module

PACE repose sur une phase 0 jouée une fois par projet, puis une boucle de quatre étapes répétée pour chaque module. Plusieurs modules peuvent être à des étapes différentes en même temps.

Phase 0 · Socle (une fois par projet, 1 à 2 semaines). On pose les fondations qui rendent la vitesse sûre : architecture cible déployée, CI/CD et environnements de preview par branche, agents de développement configurés, conventions et templates de specs et de tests. Règle d’or : aucun module n’est forgé avant que le socle ne tourne jusqu’en production.

Étape 1 · Prototyper — valider vite ce qui bouge. On teste les éléments les plus fluctuants du besoin avant d’y investir, via un prototype cliquable construit en atelier avec le client. Règle d’or : le prototype ne part jamais en production. Se tromper est permis, c’est même le but.

Étape 2 · Aligner — transformer le validé en source de vérité. On formalise ce que le prototype a permis de trancher : règles de gestion et cas limites, critères d’acceptation, glossaire métier, décisions inscrites au registre, spec lisible par les agents. Règle d’or : pas de spec figée, pas d’industrialisation. C’est le vrai point de contrôle qualité.

Étape 3 · Construire — reconstruire proprement, au niveau de qualité habituel. Les agents produisent le module définitif sur le socle, à partir de la spec ; le code est relu par les développeurs, les tests d’acceptation générés depuis la spec, la revue de code et les contrôles qualité réalisés. Règle d’or : on reconstruit, on ne recycle pas le prototype.

Étape 4 · Éprouver — valider et livrer sans friction. Le client valide sur un vrai environnement de preview, pas sur une démo ; la mise en production se fait derrière un feature flag ; les retours qualité remontent vers les agents. Règle d’or : le client valide sur du réel. Non recetté = non Done.

La jauge de maturité : l’attente ne bloque plus le sprint

Chaque fonctionnalité porte un niveau de maturité :

• Exploratoire : le besoin est encore flou, il mûrit en atelier sur prototype.
• Stabilisé : les grandes décisions sont prises, la spec est en cours d’écriture.
• Figé : la spec est validée, le sujet peut entrer en Construire.

Les développeurs travaillent toujours sur du figé ou sur le socle. Ainsi, l’attente du client ne bloque plus le sprint : elle se déplace là où elle ne coûte rien.

La proximité client : des engagements réciproques

PACE ne fonctionne que si le client s’engage autant que l’équipe. Comme un service informatique s’engage sur un SLA de résolution, le client s’engage sur un SLA de réponse aux questions fonctionnelles. Et une règle structurante : toute question est posée avec une proposition. On ne demande jamais « comment faire ? » mais « nous proposons ceci, validez-vous ? ».

Côté client, nous demandons un décideur désigné par module, une présence régulière, une réponse sous délai convenu et une recette dans les temps. En retour, nous nous engageons à arriver avec des propositions plutôt que des questions, à montrer des prototypes plutôt que faire lire des specs, à rendre visible le temps « bloqué client » et à livrer en production fréquemment.

Quand déclencher PACE

PACE n’est pas adapté à tous les périmètres. Il brille sur les modules applicatifs à fonctionnel maîtrisé, portés par un décideur identifié et disponible, avec une équipe réduite et peu d’interactions avec d’autres applicatifs. À l’inverse, un fonctionnel réparti entre de multiples interlocuteurs sans arbitre, ou des intégrations ERP et SI tiers lourdes, demandent un cycle plus classique et structuré. Les deux cycles peuvent d’ailleurs coexister dans un même projet.

En résumé

PACE est notre réponse à une question nouvelle : que fait-on de la vitesse que l’IA nous donne ? Nous choisissons de ne pas la gaspiller en temps morts ni de la payer en dette. Explorer vite et salement, aligner par l’écrit, reconstruire proprement, éprouver sur du réel — pour livrer vite en production, sous contrôle humain, sans jamais renoncer à la qualité.