J’ai longtemps hésité avant d’écrire ces mots. Parce que ce que j’observe dans vos organisations, jour après jour, me laisse un goût d’inachevé. Des ambitions sincères, des talents brillants… et pourtant.
“On veut innover, être agile, maximiser notre impact business.”
Je vous crois sur parole. Mais le même obstacle se dresse invariablement lorsque j’analyse vos structures décisionnelles :
Vous ambitionnez les résultats et les profits des licornes tout en pilotant obstinément votre équipe tech comme un simple centre de coût.
Ce n’est pas une subtilité sémantique. C’est une contradiction fondamentale qui sabote silencieusement vos initiatives de transformation avant même qu’elles ne prennent leur envol.
Une question de structure, pas de moyens
Régulièrement McKinsey se penche sur la question de performance des entreprises. Et meme si je suis tres éloignée de la philosophie de ce grand cabinet, forcee de contaster que leurs études et leur findings sont souvent suivies comme paroles dévangiles parles dirigeants que j’accompagne.
Leur étude “Developer Velocity” est formelle : les entreprises du premier quartile en matière de connaissent une croissance 4 à 5 fois plus rapide que celles du dernier quartile. Elles affichent des rendements pour les actionnaires supérieurs de 60% et des marges opérationnelles meilleures de 20%. Ce qui fait vraiment la différence ? Ni la taille, ni le budget, ni même la culture d’entreprise déclarée. C’est fondamentalement structurel.
Prenez Amazon et Spotify. On les cite en exemple, parfois jusqu’à l’indigestion. Mais ce qui fait leur force n’est pas un slogan inspirant sur un mur – c’est un choix fondamental d’organisation:
- AWS n’est pas né d’une illumination stratégique soudaine. Une simple règle organisationnelle – exiger que chaque service interne soit accessible par API – a façonné méthodiquement une architecture modulaire exploitable à l’échelle mondiale. Ce n’était pas un “moonshot” visionnaire. C’était une discipline quotidienne, ancrée dans les structures décisionnelles.
- Chez Spotify, quand une équipe prend en charge un domaine, elle en devient véritablement propriétaire. Sa mission n’est pas de livrer des fonctionnalités mais de créer de l’impact. L’expérimentation n’est pas une faveur qu’on lui accorde – c’est sa responsabilité fondamentale.
Ces entreprises n’ont pas simplement déclaré que “la tech est importante”. Elles ont construit leur organisation entière autour d’une conviction: la tech n’est pas là pour exécuter une stratégie, elle est la stratégie en action.
L’illusion du contrôle qui vous paralyse
Je l’ai vu trop souvent. Dans cette salle de réunion feutrée où l’on transmet à la tech “les besoins du business”. Comme si ces deux mondes devaient rester étrangers l’un à l’autre.
La tech hoche poliment la tête. On lui demande des délais, des estimations. On la jugera sur sa capacité à livrer… quelque chose qui a été pensé ailleurs, par d’autres.
Je me demande alors: livrer vite… quoi exactement? Et pour résoudre quel problème fondamental?
Dans une organisation centrée produit, la question est différente: quelles sont les souffrances, les attentes, les désirs inassouvis de nos clients? Quelles frictions essentielles devons-nous éliminer pour nos clients ? Et la tech devient alors co-auteure des solutions, pas simplement leur fabricante.
Cette nuance change tout: le niveau de responsabilité n’est plus le même.
Et ça, vous ne le transformerez pas avec un séminaire inspirant ou une formation éclair. Ça se construit dans les fondations mêmes: comment vous financez, comment vous décidez, comment vous mesurez le succès.
Ne blâmez pas la culture quand c’est le système qui étouffe
J’entends souvent: “c’est un problème de culture”. Mais la culture n’est que le reflet des structures que vous avez mises en place.
Si vous construisez un monde où:
- Les décisions importantes se prennent loin du terrain,
- L’argent est attribué projet par projet, sans flexibilité,
- Le succès se mesure à la conformité au planning initial,
…alors ne soyez pas surpris que vos équipes s’installent confortablement dans un rôle d’exécutant. Elles ne font que s’adapter intelligemment au système que vous avez créé pour elles.
L’étude McKinsey révèle que la sécurité psychologique constitue l’élément culturel fondamental pour catalyser l’innovation. Un environnement où l’expérimentation – et même l’échec – sont valorisés comme sources d’apprentissage. Pourtant, seuls 20% des dirigeants estiment avoir instauré ce type d’environnement.
Les organisations performantes ne se contentent pas d’encourager l’initiative – elles l’institutionnalisent par des systèmes qui absorbent et valorisent les échecs instructifs : déploiements progressifs, tests automatisés, rituels de rétrospective constructifs.
Je repense souvent à cette phrase de Deming, qui m’a fait comprendre tant de choses: “Un mauvais système battra toujours une bonne personne.“
Vous voulez changer votre culture tech? Commencez par changer les règles du jeu.
Le financement par projet : un héritage toxique de l’ère industrielle
Le financement par projet: cette prison dorée qui procure l’illusion réconfortante de la maîtrise. Cette approche, héritée de contextes stables et prévisibles, génère trois handicaps majeurs dans l’économie d’aujourdhui :
- Elle cristallise les décisions prématurément, quand la compréhension du problème est encore embryonnaire et vous empêche donc de pivoter quand le monde change (et il change toujours).
- Elle pénalise l’apprentissage en estimant que tout peut être planifié à l’avance
- Elle incite à livrer des solutions conformes aux spécifications initiales, même quand celles-ci ne répondent plus au besoin réel – livrer pour livrer, même quand il n’y a aucun rationnel économique le justifiant.
Mais son défaut le plus pernicieux est qu’elle institutionnalise la position subalterne de la tech. Les projets sont conceptualisés ailleurs, puis “commandés” aux équipes techniques. Ces dernières n’étant responsable ni du quoi, ni du pourquoi – uniquement du comment. Ce n’est pas un partenariat stratégique. C’est une relation client-fournisseur interne – une sous-traitance a peine déguisée.
Les données sont sans appel : l’étude “Developer Velocity Index” démontre que les entreprises finançant leurs équipes par capacité continue – plutôt que par projet – génèrent jusqu’à 5 fois plus d’innovation et de croissance.
Centre de cout vs Centre de profit
Un centre de coût, c’est comme un puits sans fond qu’il faut sans cesse combler. On cherche naturellement à: réduire ce qui sort, justifier chaque euro dépensé, et contrôler l’exécution dans les moindres détails.
Un centre de profit, c’est un jardin qu’on cultive pour qu’il fleurisse. On y investit pour créer de nouvelles formes de valeur, explorer des territoires inconnus, mesurer non pas l’effort, mais la récolte.
Cette distinction fondamentale transforme intégralement votre approche :
comparaison centre de cout vs centre de profitJ’observe constamment des organisations qui espèrent les bénéfices de la colonne de droite tout en s’enfermant résolument dans les pratiques de la colonne de gauche.
Cette incohérence n’est pas juste inefficace – elle est structurellement vouée à l’échec.
L’avantage concurrentiel négligé : l’habilitation des développeurs
Un résultat particulièrement éloquent de l’étude McKinsey concerne l’impact des outils et des pratiques mis à disposition des équipes techniques. Les entreprises du premier quartile en Developer Velocity sont 65% plus innovantes que leurs concurrentes, simplement grâce à des outils de qualité pour la planification, le développement et la collaboration.
Plus significatif encore : ces organisations affichent des taux de rétention des talents supérieurs de 47%. Elles accordent aux développeurs un degré d’autonomie dans le choix des outils – typiquement entre deux et cinq options pour répondre à différents besoins.
Traiter vos développeurs comme des artisans à qui l’on fournit les meilleurs instruments, plutôt que comme des ressources interchangeables, n’est pas un coût – c’est un investissement à rendement exponentiel.
Le mode Produit : votre avantage stratégique inexploité
McKinsey souligne que les entreprises performantes ont développé une fonction de gestion de produit complète et équilibrée. Cette capacité dépasse largement la livraison de projets dans les délais impartis.
Ce dont on parle ici est la mise en oeuvre d’un Product Operating Model – dans le sens Marty Cagan du terme : s’assurer que les bonnes solutions aux problèmes de nos clients sont construites pour leur offrir une expérience client supérieure. Les équipes les plus efficaces combinent une compréhension approfondie du marché avec des compétences techniques solides.
Les données montrent que les organisations maîtrisant les six dimensions clés du POM – expérience client, compétences stratégiques, acumen business, compétences techniques, leadership et facilitateurs organisationnels – obtiennent des scores 1,5 fois plus élevés que celles excellant dans seulement une ou deux dimensions.
La décision stratégique incontournable
“On n’a pas les moyens de Google ou d’Amazon” – j’entends cela presque chaque semaine.
Mais le véritable avantage de ces entreprises n’est pas leur trésor de guerre. C’est leur capacité à apprendre vite. À essayer. À se tromper. À recommencer, différemment.
Et cela, je vous le promets, n’est pas une question de budget. C’est une question de courage organisationnel:
- Financer des équipes pour leur impact, pas pour leurs tâches,
- Construire des équipes stables autour de missions durables, pas de projets éphémères,
- Mesurer les résultats qui comptent, pas l’activité qui rassure.
Tout cela est à votre portée. Mais cela demande de faire un choix fondamental : considérer réellement la tech comme un moteur de création de valeur, pas comme une ligne de dépense à optimiser.
Les transformations agiles / produit échouent massivement pour une raison fondamentale : on ne peut exiger d’une équipe qu’elle innove, soit agile et crée de la valeur lorsqu’on la structure comme un centre de coût, l’organise en silos et la juge comme un simple exécutant.
Si votre avenir stratégique dépend de votre capacité technologique – ce qui est désormais le cas dans tous presque tous les secteurs by the way – alors votre fonction Tech n’est pas “un département parmi d’autres”. Elle est le tissu même de votre entreprise, le coeur de votre succés business.
La question n’est donc pas de savoir si vous devez imiter les méthodes d’Amazon ou de Spotify. La vraie question stratégique est :
Êtes-vous prêt à transformer fondamentalement vos structures décisionnelles et financières pour considérer votre tech comme un véritable centre de profit ?
Cette décision semble simple en théorie. Sa mise en œuvre implique de reconsidérer intégralement vos mécanismes d’allocation des ressources, vos structures de gouvernance et vos critères d’évaluation de la performance.
Les données McKinsey sont formelles : les entreprises qui franchissent ce pas surpassent systématiquement leurs concurrents en termes de croissance, de rendement pour les actionnaires, de marges opérationnelles, d’innovation, de satisfaction client et d’attraction des talents.
La question n’est donc plus de savoir si vous pouvez vous permettre cette transformation. La question est : pouvez-vous vous permettre de l’éviter ?
