School of Product 2025 - L’approche produit n'existe pas, seules comptent les organisations produit.

Romain Delassus commence son talk par un constat honnête : pendant plus de dix ans, j’ai assisté — parfois en spectateur, souvent en acteur — à des transformations numériques profondes. Et pourtant, malgré les compétences et la motivation du top management… beaucoup échouent encore à produire des services numériques réellement utiles, robustes et durables.

Ce constat, il l’a longtemps traîné comme un sentiment d’échec personnel mais avec le recul, il révèle surtout un mal systémique, ancré dans la structure même des organisations.

Romain a travaillé dans plusieurs ministères. Il a été chef de projet, responsable produit, directeur du numérique au ministère de la Culture puis à la tête d’une DSI d’une centaine de personnes. Il travaille aujourd’hui dans une startup deep tech en tant que Directeur Produits et Systèmes d’Information.

3 constantes qui expliquent les échecs des organisations

Durant sa conférence, Romain nous partage son expérience au Ministère de la Culture en tant que DSI et nous relate 3 symptômes qui caractérisent selon lui les échecs des organisations établies :

1. L’archipel des monolithes

Les organisations empilent les refontes successives ou le shadow IT avec des systèmes qui ne sont pas reliés entre eux. Chaque direction a son applicatif et son objectif ce qui implique nécessairement de la complexité, une duplication fréquente du patrimoine IT et une réelle fragilité du SI.

2. L’externalisation massive

Années après années, les DSI ont remplacé leur maîtrise du code par une externalisation des compétences avec des achats de prestations. Les équipes internes sont alors devenues des chefs de projet, plus orchestrateurs que constructeurs. Ainsi, la capacité à décider et comprendre s’est quelque peu diluée au sein de l’organisation laissant clairement un manque d’autorité sur l’écosystème IT.

3. La multiplication des infrastructures

Le dernier facteur impactant est la multiplication des infrastructures portées par les hébergements et les technologies. Avec une forte dette technique et organisationnelle, l’organisation perd ainsi la main sur la tech, la finance et les opérations.

Un premier réflexe : la méthode “Start-up d’État”

Romain nous explique que son premier réflexe est d’introduire une logique start-up d’état en se focalisant sur les besoins réels des usagers, la mesure de l’impact et des équipes “produit” dédiées. Pour rappel, le programme “bêta-gouv” aussi appelé “start-ups d’état” est un programme destiné à aider les administrations publiques à construire des services numériques utiles, simples et répondant vraiment aux besoins des gens.

Cette première action est une réussite apportant clairement un appel d’air pour les équipes et surtout des premières preuves par l’usage. Cependant, il se heurte très vite à deux effets rebonds :

• Une équipe intégrée coûte cher et la question se pose sur la pérennité d’un tel modèle
• L’obsession usager peut devenir rapidement un piège si elle se fait au détriment de la vision long terme et de l’architecture technique
• On crée des îlots d’agilité dans un océan de dette
• Le passage est l’échelle est quasi impossible car ces îlots se heurtent rapidement à la complexité du système existant

Les limites de l’organisation : la loi de Conway, encore et toujours

Une organisation pyramidale, pilotée par le haut, produira toujours des systèmes monolithiques, silotés et redondants. Ce n’est donc pas un problème de technologie ou de compétences.
C’est un principe sociologique connu depuis des décennies par le loi de Conway.

> “Toute organisation qui conçoit un système produira un système qui est le reflet de sa structure de communication.”

Romain nous expose alors que son problème n’était pas le produit mais bien la gouvernance et l’organigramme.

Une transformation en 3 actes

Pour agir concrètement et opérer une vraie transformation, Romain nous présente la démarche en 3 actes :

Acte 1 : Construire un nouveau squelette

Avant de lancer un nouveau produit, nous avons conçu une architecture cible complète du système d’information avec une infrastructure de données, une couche DevOps, une infrastructure cloud mutualisée et une chaîne CI/CD prête.

Comme le dit Romain, “rien de révolutionnaire techniquement” mais une base commune avec un objectif de pérennité.

Acte 2 : Redessiner l’organisation

Une fois la première base construite et livrée, l’équipe initiale a été dissoute et l’organigramme a été complètement redessiné afin de mieux servir l’architecture mise en place.

Ensuite, des nouvelles équipes ont été créées ; des équipes orientées usagers, des équipes dites “plateforme” au service des équipes internes avec une forte pluridisciplinarité et autonomie.

Romain nous partage à ce moment un certaine difficulté dans cette étape de transformation à savoir opérer et maintenir cette organisation. En effet, recruter, convaincre, protéger les équipes et maintenir le cap donné deviennent des défis quotidiens pour lesquels Romain nous rappelle d’être le plus vigilant.

Le leitmotiv devient alors : une équipe, une mission, un produit.

Acte 3 – Sortir du mode projet

Enfin, après l’architecture et les équipes, le dernier acte consiste à abandonner les projets d’un an avec des budgets fixés et des plannings pluriannuels.

À la place de ces assets très “projet”, Romain met en place des feuilles de route à 6 mois, une priorisation par la valeur, des indicateurs de mesure et surtout une gouvernance impliquant les utilisateurs finaux.

En focalisant les équipes sur la valeur et le produit, la DSI passe alors d’un centre de coût à un partenaire stratégique des métiers. Et, Romain le résume assez bien par cette “mini” proposition de valeur “Voici nos compétences. Que construisons-nous ensemble ?

Les premiers résultats

Avec un an de recul, les effets sont déjà visibles :

• Attractivité RH : des compétences techniques à nouveau désirables, des candidatures spontanées et une réinternalisation possible.
  
• Image positive : une DSI sollicitée pour résoudre les problèmes importants, moins de comités stériles, plus de pilotage par les résultats.
  
• Vélocité : des projets et de la valeur livrés en quelques mois, voire quelques semaines après des phases de cadrage et d’investigation.
  

Ainsi, avec une certaine humilité, Romain nous confie tout de même que ce n’est pas parfait, que des compromis sont toujours nécessaires. Le produit à l’état de l’art n’existe pas vraiment mais la démarche mise en place fonctionne.

Conclusion

Romain nous laisse un message assez clair : Faire du mode produit sans toucher à l’architecture du système et à l’organisation, c’est comme vouloir faire de l’eau chaude sans toucher à la plomberie. Au mieux, vous aurez une très bonne bouilloire dans un coin.

Il termine par : “Votreprochain grand produit n’est pas une feature. C’est une nouvelle version de votre organisation qui accepte de lâcher le contrôle et de ne pas tout savoir à l’avance.”

On aura toujours le système d’information que notre organisation mérite.