Critique de Livre : «Good Strategy / Bad Strategy» de Richard Rumelt
J'ai lu «Good Strategy / Bad Strategy» de Richard Rumelt pour la première fois en 2019. Je l'ai relu deux fois depuis. C'est le genre de livre qui devient plus précis à chaque lecture parce que vous continuez à reconnaître ses schémas dans vos propres décisions — surtout les mauvaises.
L'argument central de Rumelt est d'une simplicité trompeuse : la plupart de ce qui passe pour de la stratégie n'en est pas. Ce sont des objectifs habillés en langage aspirationnel. Ce sont des déclarations de vision sur un diaporama. Ce sont des listes de priorités si longues que rien n'est réellement priorisé. Et dans le monde des startups, où la « stratégie » est évoquée à chaque réunion du conseil et à chaque all-hands, ce problème est endémique.
Si vous dirigez une équipe d'ingénierie, gérez un produit ou pilotez une startup, ce livre changera votre façon de penser les décisions. Voici pourquoi.
Le Noyau de la Bonne Stratégie
Rumelt définit la bonne stratégie comme composée de trois éléments — ce qu'il appelle le noyau (kernel) :
1. Diagnostic : Quel est le vrai défi ?
Le diagnostic est une évaluation honnête de la situation. Pas ce que vous souhaiteriez être vrai. Le problème réel.
J'ai participé à des réunions stratégiques où le diagnostic était « nous devons croître plus vite ». Ce n'est pas un diagnostic — c'est un désir. Un vrai diagnostic : « Notre conversion essai-vers-payant est de 4%, la moitié du benchmark sectoriel, parce que l'onboarding perd 60% des utilisateurs avant qu'ils voient la valeur centrale. »
En termes d'ingénierie, un bon diagnostic : « Notre cycle de déploiement prend 3 semaines parce que nous n'avons pas de tests automatisés, un processus QA manuel et une stratégie de branche unique. » Spécifique. Actionnable. Nomme la vraie contrainte.
Un mauvais diagnostic : « Nous devons livrer plus vite. » Tout le monde hoche la tête. Personne ne sait quoi faire.
2. Politique Directrice : L'approche
La politique directrice est l'approche globale face au défi diagnostiqué. Pas une action spécifique — la direction qui contraint vos actions.
L'analogie de Rumelt : une politique directrice est comme une glissière de sécurité sur une route de montagne. Elle ne vous dit pas où orienter le volant, mais elle vous empêche de tomber dans le précipice.
Pour l'exemple de déploiement : « Nous investirons dans l'automatisation pour rendre les déploiements en libre-service et éliminer la coordination manuelle. » Cela ne précise pas quel outil CI/CD utiliser ni comment gérer les migrations. Cela fixe la direction.
La caractéristique clé d'une bonne politique directrice est qu'elle fait des choix. Elle dit « nous ferons ceci, pas cela ». Si votre « stratégie » n'exclut rien, ce n'est pas une stratégie.
3. Actions Cohérentes : Des étapes coordonnées
Le troisième élément est un ensemble d'actions coordonnées qui mettent en œuvre la politique directrice. Pas une liste de souhaits. Pas 47 initiatives. Un ensemble focalisé de mouvements qui se renforcent mutuellement.
Pour notre problème de déploiement : (1) introduire des feature flags pour découpler le déploiement de la mise en production, (2) configurer une CI avec des suites de tests automatisés pour les deux services les plus fréquentés, (3) passer au développement trunk-based. Ces trois mouvements sont cohérents — chacun soutient les autres, et ensemble ils répondent au problème diagnostiqué.
La cohérence est ce qui sépare la stratégie d'une liste de tâches. Une liste de projets d'amélioration sans lien n'est pas une stratégie. Un ensemble d'actions mutuellement renforçantes visant un défi spécifique en est une.
La Mauvaise Stratégie Est Partout
La taxonomie de la mauvaise stratégie de Rumelt m'a frappé comme un train de marchandises parce que j'ai reconnu chaque schéma dans des entreprises avec lesquelles j'avais travaillé :
La boursouflure. Un langage enflé qui ne dit rien. « Nous leveragerons nos capacités de plateforme synergiques pour débloquer de la valeur à travers l'écosystème. » Enlevez le jargon et il ne reste rien en dessous.
Confondre les objectifs avec la stratégie. « Notre stratégie est d'être le leader du marché des outils pour développeurs. » C'est un objectif, pas une stratégie. Où est le diagnostic ? Où est la politique directrice ?
Ne pas faire de choix. Le schéma le plus dommageable. Une entreprise qui liste 12 « priorités stratégiques » n'en a aucune. La stratégie, c'est décider ce qu'on ne fera PAS. Si votre équipe d'ingénierie réécrit simultanément le backend, construit trois fonctionnalités, migre vers un nouveau cloud et réduit la dette technique de 40%, vous avez une fantaisie, pas une stratégie.
Ignorer le défi. Sauter directement aux objectifs et aux actions sans identifier ce qui est vraiment difficile. Le résultat est des playbooks génériques qui n'adressent pas les contraintes spécifiques.
Pourquoi la Plupart des OKRs Ne Sont Pas une Stratégie
C'est là où le framework de Rumelt pique vraiment dans le monde tech. Les OKRs — Objectifs et Résultats Clés — sont d'excellents outils d'exécution. Mais ils ne sont pas une stratégie, et les traiter comme tels est l'une des erreurs les plus fréquentes que je vois.
Un OKR comme « Augmenter la fiabilité de la plateforme à 99,95% de disponibilité » est un objectif avec un résultat mesurable. Il vous dit à quoi ressemble le succès. Il ne vous dit pas :
- Pourquoi la fiabilité est le défi le plus important maintenant (diagnostic)
- Quelle approche vous adopterez pour l'améliorer (politique directrice)
- Quelles actions spécifiques et coordonnées vous exécuterez (actions cohérentes)
Les OKRs se situent en aval de la stratégie. Ils l'opérationnalisent. Mais si vous définissez des OKRs sans stratégie, vous vous retrouvez avec une collection d'objectifs mesurables qui ne se connectent pas et n'adressent pas votre défi central. Chaque équipe atteint ses OKRs et l'entreprise n'avance toujours pas, parce que personne n'a posé la question difficile : « Quel est le problème le plus important que nous devons résoudre, et que allons-nous faire à ce sujet ? »
Appliquer Rumelt aux Décisions d'Ingénierie
C'est là où le livre devient intensément pratique pour quiconque dirige de l'ingénierie :
Décisions d'architecture. Faut-il réécrire ou refactoriser ? Le framework de Rumelt vous force à commencer par le diagnostic. Quel est le vrai problème ? Si c'est « le monolithe est lent à déployer », la politique directrice pourrait être d'extraire les modules à plus forte rotation en services — pas une réécriture complète. Les actions cohérentes suivent : identifier les 3 modules principaux par fréquence de changement, définir les frontières de service, implémenter une extraction en preuve de concept.
Build vs. buy. « Nous construisons tout en interne » n'est pas une stratégie — c'est un défaut. Un bon diagnostic : « Nous dépensons 30% du temps d'ingénierie à maintenir de l'infrastructure banalisée. » Politique directrice : « Acheter des services gérés pour les non-différenciateurs ; construire uniquement là où nous avons un avantage unique. » Maintenant chaque décision future a un filtre.
Scaling de l'équipe. « Recruter 20 ingénieurs » est un objectif. La version stratégique : « La vitesse de livraison a diminué de moitié parce que deux équipes se marchent dessus dans une base de code partagée. » Politique directrice : « Établir la propriété de domaine avant d'augmenter les effectifs. » Actions cohérentes : définir des contextes bornés, diviser la base de code, créer des APIs d'équipe, puis recruter dans la nouvelle structure.
La Partie Difficile : Faire des Choix
La vérité la plus inconfortable de ce livre est que la bonne stratégie exige de dire non. Pas « pas pour l'instant ». Non.
Si vous êtes une startup avec 8 ingénieurs et que vous essayez simultanément de construire une application mobile, une application web, une plateforme API et une fonctionnalité IA, vous n'avez pas de stratégie. Vous avez du FOMO. Rumelt vous dirait de diagnostiquer votre avantage concurrentiel réel, de choisir la seule chose qui compte le plus, et de l'exécuter avec cohérence.
Cela signifie dire à quelqu'un — un cofondateur, un membre du conseil, un client — que vous n'allez pas faire ce qu'il veut. C'est pourquoi la mauvaise stratégie est beaucoup plus courante que la bonne. La mauvaise stratégie vous permet d'éviter le conflit. La bonne stratégie l'exige.
Chez Conectia, nous voyons ce schéma constamment avec les startups avec lesquelles nous travaillons. Les fondateurs viennent nous voir avec un besoin d'ingénieurs, mais la vraie conversation commence souvent par « que devrions-nous construire en premier ? » Quand nous intégrons des ingénieurs seniors dans une équipe, ils n'écrivent pas que du code — ils posent les questions de diagnostic qui affûtent la stratégie. Quel est le vrai goulot d'étranglement ? Que devrions-nous arrêter de faire ? Où ajouter de la capacité résout vraiment le problème plutôt que de simplement rendre le chaos plus rapide ?
C'est ce qu'apportent les ingénieurs expérimentés : pas seulement de l'exécution, mais du jugement sur ce qu'il faut exécuter.
Vous constituez votre équipe d'ingénierie et vous voulez des personnes qui pensent stratégiquement, pas seulement qui écrivent du code ? Parlez à un CTO — nous intégrons des ingénieurs senior LATAM qui posent les bonnes questions avant d'écrire la première ligne.
