En product management agile, on distingue traditionnellement deux grandes phases : la Discovery et la Delivery. La première correspond à l’exploration : comprendre les besoins, formuler des hypothèses, imaginer des solutions, tester des approches. La seconde représente l’exécution : concevoir, développer, déployer et maintenir les fonctionnalités en production, dans un cadre d’exploitation réel soumis à des engagements de service (SLA).

Autrement dit, le Discovery cherche à savoir si l’on doit construire, tandis que le Delivery s’assure que ce que l’on construit fonctionne et crée bien de la valeur.

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.

De la même façon, dans le modèle traditionnel, on distingue également le Build et le Run.

Le Build correspond à la phase de construction : concevoir, développer et livrer de nouvelles fonctionnalités, produits ou services.

Le Run, lui, concerne l’exploitation quotidienne du système : surveiller, maintenir, corriger, assurer la continuité de service et la satisfaction des utilisateurs. Autrement dit, le Build crée la valeur, tandis que le Run la préserve. Dans une usine à impact, cette séparation s’efface au profit d’une logique commune : 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.

ARTICLES CONNEXESPLUS DE L'AUTEUR