Construire et mettre en production ce que la discovery a décidé. Les quatre temps, la différence avec la discovery, et ce qui change quand ce sont des agents qui exécutent.
La phase de delivery, c'est le temps où l'on construit et met en production ce que la discovery a décidé. Elle commence avec un périmètre et des critères de succès, elle se termine quand de vrais utilisateurs utilisent le système et que les critères sont mesurés. Entre les deux : concevoir, construire, tester, livrer, par petits incréments.
Dans le Double Diamond, c'est le second losange. La discovery ouvre puis referme le problème. La delivery ouvre puis referme la solution.
Ce qui a changé. J'ai écrit la première version de cet article quand la delivery mobilisait un designer, un PM et deux à quatre développeurs pendant des mois. En 2026, je livre seul ce que cette équipe livrait, parce que les agents produisent le code, les tests et les contenus, et que je garde le cadrage, la vérification et la décision. Cet article décrit la delivery telle qu'elle se pratique maintenant.
| En entrée, venu de la discovery | En sortie |
|---|---|
| Un problème formulé et prouvé | Un système en production qui le traite |
| Un périmètre minimal, avec ce qui n'entre pas | Ce périmètre, livré, et rien de plus |
| Trois critères de réussite avec leur valeur actuelle | Les mêmes critères, mesurés sur de vrais usages |
| Des hypothèses testées | Des hypothèses confirmées ou abandonnées en production |
Si la colonne de gauche est vide, la delivery ne peut pas commencer. Elle commence quand même, souvent. C'est la première cause des projets qui durent le double du prévu : on construit en découvrant.
Parcours, écrans clés, règles métier, modèle de données. Pas une maquette de chaque état. Le niveau de détail dépend de ce qui est risqué : un écran de paiement se dessine au pixel, un écran de réglages se décrit en une phrase. Ce que les agents changent : les maquettes des écrans secondaires et les variantes se génèrent à partir du design system, je dessine les écrans qui décident.
Un incrément, c'est une tranche fine qui traverse tout le système et que quelqu'un peut utiliser. Pas une couche technique. « L'utilisateur peut créer un devis et l'envoyer » est un incrément. « La base de données est prête » n'en est pas un. Ce que les agents changent : je découpe et je brief, ils écrivent le code et les tests, je relis et je décide de ce qui part. Le temps d'un incrément passe de deux semaines à deux jours.
Chaque incrément va devant de vrais utilisateurs, pas devant l'équipe. Cinq personnes suffisent pour voir ce qui casse. On mesure les critères de la discovery à chaque fois, pas à la fin. Un critère qui ne bouge pas après trois incréments, c'est un signal de retourner en discovery, pas de construire plus.
La delivery ne finit pas à la mise en ligne. Elle finit quand le système tient tout seul : supervision, gestion des erreurs, et pour un produit IA, ce qui se passe quand l'agent se trompe. Un agent en production sans point de contrôle humain n'est pas livré, il est lâché.
Trois différences avec une delivery logicielle classique.
Le comportement n'est pas déterministe. On ne teste pas un agent avec dix cas, on le teste avec deux cents, et on mesure un taux d'erreur, pas un pass ou fail. Le jeu de test se construit pendant la discovery, à partir de vrais cas.
Les données sont le produit. Un agent RAG qui cite la loi vaut ce que valent ses sources et leur mise à jour. La delivery inclut le pipeline de données, pas seulement le modèle. Sur tondroit.fr, la moitié du temps de build est passée sur l'ingestion et la vérification des sources, pas sur l'agent.
Le point de contrôle humain fait partie du périmètre. Où l'agent s'arrête et demande, qui vérifie, qui peut corriger. Ça se conçoit avant la première ligne de code. Ça se rajoute très mal après.
Livrer tout à la fin. Six mois de build, une recette, cent problèmes. Chaque incrément non livré est un risque qui s'accumule.
Respecter le planning plutôt que les critères. On livre à l'heure quelque chose qui ne change rien aux mesures fixées en discovery. C'est un échec propre.
Laisser la discovery à la porte. Pendant la delivery, on apprend. Si personne ne ramène ce qu'on apprend dans le périmètre, on construit la version d'il y a trois mois du besoin.
Confondre démo et production. Un agent qui marche en démo devant le comité n'est pas en production. En production, il y a les cas limites, les données sales et les utilisateurs pressés. C'est la différence entre un POC et un produit, et c'est celle que je vends.
Le format que j'utilise pour démarrer une delivery : le sprint IA de 72 heures. Trois jours pour transformer le périmètre de la discovery en un premier agent en production, testé sur vos vraies données, avec une recommandation chiffrée pour la suite. Dès 3 500 € HT, au forfait. Ce n'est pas le produit fini. C'est la preuve que la delivery peut tenir ce que la discovery a promis.
La delivery est la phase où l'on construit et met en production ce que la discovery a décidé. Elle transforme un périmètre et des critères de succès en un système qui tourne chez de vrais utilisateurs. Elle se mesure à une seule chose : ce qui est en production et utilisé, pas ce qui est en cours.
Ça dépend du périmètre, et c'est justement pour ça que la discovery doit le réduire. Un premier périmètre bien cadré se livre en deux à six semaines. Avec des agents qui produisent le code, les tests et les contenus, je livre un premier agent fonctionnel en 72 heures et un produit complet en quelques semaines, là où une équipe de quatre mettait six mois.
La discovery décide, la delivery construit. La discovery produit un périmètre et des critères ; la delivery produit du logiciel en production. Elles ne sont pas séquentielles pour toujours : sur un produit vivant, les deux tournent en parallèle, la discovery alimente la delivery suivante.
Une delivery qui livre en production par petits incréments, chacun testé sur de vrais utilisateurs, avec les critères de la discovery mesurés à chaque incrément. Une mauvaise delivery livre tout à la fin, découvre les problèmes en recette, et redécouvre le besoin en construisant.
Ils remplacent une grande partie de l'exécution : code, tests, intégrations, contenus, documentation. Ils ne remplacent ni le cadrage, ni la vérification, ni la responsabilité de ce qui part en production. C'est le métier de Product Builder IA : une personne qui brief, vérifie et décide, des agents qui exécutent.
Par les critères fixés en discovery, mesurés en production. Pas par le respect du planning. Un produit livré à l'heure que personne n'utilise est un échec de delivery, même s'il est propre.
45 minutes pour regarder ce qui bloque et voir si 72 heures suffisent pour un premier incrément qui tourne.
Réserver un appel de 45 minutes →
Ou par email : e.loui@uxdesignparis.fr · Téléphone : +33 6 35 31 50 35