Le super-pouvoir de votre équipe tech : être un nain sur la bonne épaule de géant
Si vous cherchez à mesurer la valeur de votre équipe technique, il y a de fortes chances que votre regard se porte sur « ce qui a été produit ». Le nombre de nouvelles fonctionnalités, la vélocité, la quantité de code.
Je vais vous le dire sans filtre : vous regardez le mauvais indicateur.
Il y a une de mes phrases fétiches, que j’aime bien balancer quand je discute avec des devs, une idée piquée à Bernard de Chartres et popularisée par Newton : on est des nains sur des épaules de géants.
En clair, ça veut dire que chaque ligne de code qu’on écrit aujourd’hui repose sur des décennies d’inventions conçues par d’autres. Le protocole HTTP, le noyau Linux, les bases de données, les frameworks comme React… On a rien inventé de tout ça. Notre métier, c’est d’être des assembleurs. Des intégrateurs de génie.
Mais le véritable enjeu (et c’est tout l’objet de cet article) est de savoir quand l’épaule du géant que tout le monde emprunte est en réalité une impasse. Un piège qui bride votre business.
« These aren’t the droids you’re looking for. »
Avant de parler de l’exception qui confirme la règle, parlons du mode par défaut. De ces 99% du temps où le job de votre équipe n’est PAS d’inventer, mais d’exécuter avec intelligence et pragmatisme. Pour ça, il faut une culture basée sur trois piliers.
1. Le seul KPI qui compte : l’Impact Client
Votre meilleur développeur n’est pas celui qui est capable de recoder une librairie de gestion de dates en trois jours. C’est celui qui, en 15 minutes, trouve la bonne librairie sur GitHub, la teste, la valide et passe le reste de sa journée à résoudre le VRAI problème de votre utilisateur. On ne vous paie pas pour la beauté de votre code, mais pour la valeur que vous créez. Point.
2. La Curiosité est une compétence, pas un hobby
La veille technologique n’est pas un passe-temps pour geeks qui se la racontent à la machine à café. C’est une assurance-vie pour votre produit. C’est une discipline de gestion des risques. Choisir un « géant » en fin de vie, ou une librairie sans communauté, c’est comme construire sa maison sur des fondations en sable. La facture arrive toujours, et elle est salée. Une équipe qui ne fait pas de veille est une équipe qui navigue à vue, avec une dette technique qui gonfle à chaque sprint.
3. L’Ego : le passif le plus cher de votre bilan technique
Une culture d’équipe qui applaudit quand un développeur passe trois semaines à réinventer un système d’authentification standard est une culture qui brûle du cash. L’ego du « bâtisseur de cathédrales », celui qui veut tout refaire lui-même pour prouver sa valeur, est un passif. Il crée de la complexité inutile, des solutions que personne d’autre ne saura maintenir, et une dette technique que vous paierez pendant des années. L’humilité n’est pas une option, c’est une exigence économique.
« Roads? Where we’re going, we don’t need roads. »
Accepter d’être un nain est la base. Mais parfois, ça ne suffit pas. Parfois, l’étagère des solutions standards est vide, ou pire, la solution la plus populaire est une impasse pour votre ambition. Que faire quand votre vision business dépasse les outils du marché ?
La réponse est simple : vous devez créer la route.
Un cas d’école que je trouve particulièrement parlant est celui de Netflix. Au début des années 2010, ils ont pris une décision radicale : migrer toute leur infrastructure sur le cloud d’Amazon, AWS. Le problème ? Ils avaient une ambition démesurée : offrir une expérience de streaming parfaite, 24/7, à l’échelle mondiale, sur une infrastructure partagée qu’ils ne contrôlaient pas.
Les outils de l’époque, les « géants » du monitoring et de la gestion de pannes, n’étaient absolument pas conçus pour ce niveau de résilience. Ils étaient faits pour un monde de serveurs stables dans un datacenter, pas pour le chaos inhérent du cloud.
Face à ce vide, Netflix a fait un choix non pas technique, mais stratégique. Ils ont compris que leur avantage concurrentiel le plus critique, la disponibilité sans faille de leur service, ne pouvait pas s’acheter sur étagère. Ils devaient le construire.
De cette nécessité sont nés de nouveaux géants. On pense souvent à :
- Hystrix : Le fameux « disjoncteur » (circuit breaker) qui isole une panne pour éviter qu’elle ne contamine tout le système.
- Chaos Monkey : L’outil qui sème le chaos en créant volontairement des pannes en production pour forcer les systèmes à être anti-fragiles.
Mais ce ne sont que les exemples les plus célèbres. En réalité, ils ont développé et mis en open-source un écosystème entier d’outils, visible sur leur portail netflix.github.io, qui a redéfini les standards du secteur.
La leçon est magistrale. Netflix n’a pas fait du from scratch par plaisir d’ingénieur. Ils l’ont fait parce que leur stratégie business l’exigeait. En résolvant leur propre problème, ils sont devenus les épaules sur lesquelles une bonne partie de la tech s’appuie aujourd’hui.
« With great power comes great responsibility. »
Alors, concrètement, on fait quoi ? Votre rôle, en tant que décideur, n’est pas de devenir un expert technique de chaque solution. C’est de devenir un expert dans l’art de poser les bonnes questions. C’est de challenger vos équipes pour qu’elles prennent les décisions les plus intelligentes.
La prochaine fois qu’on vous présente un projet, voici trois questions à graver dans le marbre :
- « Quelle est la solution standard du marché pour ce problème ? » Cette question force l’équipe à prouver qu’elle a fait une veille minimale et qu’elle ne part pas tête baissée dans une solution maison par simple ignorance.
- « En quoi notre besoin est-il si unique qu’il justifie qu’on s’écarte du standard ? » La réponse doit être un argument business, pas technique. Si la réponse est « parce que c’est plus élégant comme ça », c’est un drapeau rouge. Si c’est « parce que ça nous permettra de diviser le coût d’opération par trois », on peut commencer à discuter.
- « Si nous construisons, est-ce un véritable avantage concurrentiel ou une dette de maintenance déguisée ? » Chaque ligne de code « maison » est une ligne qu’il faudra maintenir, débugger et faire évoluer pendant des années. Assurez-vous que le jeu en vaut la chandelle.
Instaurer cette culture, c’est aussi allouer du temps pour la veille, célébrer les arbitrages intelligents (même s’ils ne mènent à aucune ligne de code) et récompenser la curiosité autant que la productivité.
« There is no spoon. »
L’excellence technique d’une équipe, ce n’est pas de savoir tout construire. C’est de savoir, avec sagesse, ce qu’il ne faut pas construire.
C’est une culture de l’humilité qui pousse à monter sur les épaules des géants pour aller plus vite et plus loin. Mais c’est aussi une culture de la vigilance, qui permet de savoir quand il faut sauter de ces épaules pour tracer sa propre voie et, peut-être, devenir un géant à son tour.
Alors, la prochaine fois que vous ferez un point projet, oubliez un instant le classique « Où en est le développement ? ».
Demandez plutôt : « Quelle est la décision d’assemblage la plus intelligente que nous ayons prise cette semaine ? »
Leave a Reply