Mais dans la logique d’une usine à impact, cette séparation devient relative. Discovery et Delivery ne sont pas deux mondes étanches : ils partagent le même cycle d’apprentissage, composé des mêmes étapes – orienter, recenser, cadrer, planifier, délivrer, opérer, mesurer. La différence ne réside pas dans la méthode, mais dans la nature du test.

  • Si la livraison du test s’effectue dans un environnement de production, avec de vrais utilisateurs, des impacts mesurables et des contraintes d’exploitation, alors il s’agit de Delivery.

  • Si la livraison du test reste dans un cadre exploratoire — maquettes, prototypes, simulations, études ou expérimentations sans mise en production — alors nous sommes en Discovery.

Dans les deux cas, le principe est le même : on teste pour apprendre. La boucle est identique, seule la portée du test change. C’est pourquoi, dans le modèle de l’usine à impact, le verbe “Délivrer” ne se limite pas au “Delivery” au sens traditionnel. Il désigne la livraison du matériel de test, qu’il soit déployé en production ou non. Autrement dit, notre “Délivrer” s’applique aussi bien à une maquette de recherche qu’à une fonctionnalité en ligne : dans les deux cas, il s’agit d’apprendre, de mesurer l’écart, et d’ajuster la trajectoire pour maximiser l’impact.

Le Delivery, le « build », et le « run »

Pour illustrer la différence entre la valeur créée en discovery et celle générée ensuite en delivery, prenons un exemple concret : l’équipe qui développe CantinaFlow, un logiciel destiné à aider les cantines scolaires à réduire leur gaspillage alimentaire.

Dès les premières semaines, l’équipe mène des entretiens, observe le fonctionnement des cuisines et organise des focus groups. Ces initiatives ne produisent ni fonctionnalités ni engagements contractuels, mais elles créent une autre forme de valeur : les gestionnaires de cantine se sentent impliqués, compris, et commencent à se projeter dans le produit. C’est l’effet Ikea : lorsque les utilisateurs participent à la construction, ils s’attachent à la solution. La discovery construit donc un capital relationnel, une compréhension fine du problème et une communauté prête à accompagner la suite.

Cependant, cette valeur reste exploratoire. Tant que CantinaFlow n’a rien livré, aucune cantine ne bénéficie de garanties : pas de niveau de service, pas de support, pas d’obligation de corriger un comportement inattendu. C’est le passage en Delivery qui change la nature de la relation : lorsqu’un premier incrément du produit est livré, on sort du champ exploratoire pour entrer dans celui de l’engagement. Livrer une fonctionnalité — même en pilote — crée immédiatement des attentes, des droits d’usage, et donc des obligations pour l’équipe.

À l’intérieur de cette phase de Delivery, l’usine à impact distingue alors deux moments complémentaires et indissociables :
• le Build, où l’équipe conçoit et livre un nouvel incrément du produit,
• le Run, où cet incrément est utilisé, mesuré, et ajusté pour qu’il tienne ses promesses.

Dans notre exemple, le Build correspond à la livraison du module de prévision des quantités à cuisiner. Le Run commence dès que ce module est utilisé en conditions réelles : si les prévisions se révèlent moins fiables que prévu dans certaines écoles, l’équipe doit analyser le problème, corriger, ajuster les modèles ou l’expérience. Le Build crée la valeur ; le Run assure qu’elle se maintient et qu’elle n’érode pas la confiance créée.

Quoi qu’il en soit, dans une usine à impact, le build et le run sont également mesurés au regard du résultat attendu avec la logique de test propre à l’usine à impact : tout fait partie du même cycle d’amélioration continue. Les activités de Run ne sont plus vues comme un simple maintien en conditions opérationnelles, mais comme une source de données précieuse pour orienter les prochains apprentissages.

De la même manière, les activités de Build ne sont pas des phases ponctuelles de production, mais des expériences conçues pour être mesurées, évaluées et enrichies par ce que le Run révèle. Une anomalie en Run devient une hypothèse à tester en Build ; une innovation en Build devient un nouveau terrain d’observation en Run. En revanche, il est évident que le Build et le Run sont associés à du Delivery.

Le Delivery n’est pas nécessairement technologique

À partir de quel moment un client commence-t-il réellement à bénéficier de la valeur de votre produit ? La réponse est souvent moins évidente qu’il n’y paraît. Prenons un exemple classique : au tout début, votre équipe envoyait une simple newsletter avec des astuces, du contenu exclusif et une relation directe avec votre audience. À l’époque, ce n’était pas encore la plateforme aux millions d’utilisateurs, aux murs infinis personnalisables et aux APIs REST. Pourtant, cette newsletter créait déjà de la valeur. Dans certains cas, elle aurait même pu être facturée : elle résolvait un problème, elle retenait une audience, elle déclenchait un comportement régulier.

Sous cet angle, cette newsletter n’était peut-être pas seulement un artefact de discovery. C’était potentiellement un premier Delivery minimal, un premier engagement sur quelque chose de concret que vous produisiez de manière continue.

La même logique s’applique aux actions marketing menées pour entretenir l’engagement ou générer de la croissance. Dès qu’une campagne promet un bénéfice — un accès rapide, une qualité de service, un niveau d’accompagnement, une fonctionnalité mise en avant — elle se confronte au terrain. Elle engage l’entreprise vis-à-vis du marché. Et cet engagement n’est pas purement théorique : il suppose qu’en interne, une organisation opérationnelle soit capable de livrer réellement ce qui est annoncé, de le maintenir et de le supporter. Dans ce sens, certaines actions marketing font déjà partie du Delivery, puisqu’elles déclenchent des attentes que l’entreprise doit satisfaire dans la durée.

C’est là que l’on découvre la frontière particulièrement fine entre Discovery et Delivery. La distinction que je propose est la suivante : la Discovery n’engage pas l’entreprise dans le temps. Elle permet d’apprendre, puis l’on passe à autre chose une fois le test terminé. À l’inverse, le Delivery crée des engagements, qu’ils soient explicites (clients, contrat, SLA) ou implicites (promesse marketing, régularité d’un service, continuité d’un contenu).

Cette distinction justifie l’existence d’une étape située après le Delivery : Operations. C’est en Operations que l’on maintient, supporte, ajuste, corrige et aligne ce qui a été livré avec la promesse initiale — qu’il s’agisse d’un logiciel, d’une fonctionnalité, d’une API… ou même d’une simple newsletter qui a commencé, bien avant la plateforme, à créer de la valeur tangible.

Pourquoi une confusion entre Delivrer et Delivery

Dans l’usine à impact, le cycle des tests utilise les étapes Délivrer et Opérer, un vocabulaire très proche de Delivery et Operations. Cette similarité peut sembler confusante, mais elle est volontaire : elle rappelle que, même dans un test, dès qu’un artefact est livré — qu’il s’agisse d’une fonctionnalité, d’un tunnel d’onboarding, d’une API ou même d’une simple newsletter — il crée un engagement minimal qu’il faut maintenir au delà du temps du test.

C’est précisément pour cette raison que, au-delà du Delivery, on distingue une étape Operations. L’enjeu d’Operations n’est pas seulement lié au produit final, mais aussi à la santé de chaque incrément livré au fil des tests : maintenir ce qui existe, soutenir les utilisateurs, corriger les écarts, ajuster l’expérience, s’assurer que la promesse annoncée, même temporairement, est bien tenue.

Autrement dit, les engagements durables créés par le Delivery — même lorsqu’il s’agit d’un test — se répercutent naturellement sur les activités d’Operations. Cette structure permet d’aligner l’organisation avec la réalité du terrain, tout en rendant explicite que ce qui est livré, même à petite échelle, doit être assumé, soutenu et opéré jusqu’à la fin de l’expérimentation.

ARTICLES CONNEXESPLUS DE L'AUTEUR