Construire la culture d'ingénierie — The Manager's Path

Quand vous êtes un responsable senior de l'ingénierie, une partie de votre travail consiste à définir la culture de votre fonction. Une erreur fréquente des CTO débutants est de sous-estimer l'importance d'être clair et réfléchi sur la culture de l'équipe technique. Que vous montiez une équipe ou que vous en réformiez une, négliger sa culture est le moyen le plus sûr de vous compliquer la tâche. La culture n'est pas une affiche ou une charte : c'est une infrastructure dont vous dépendez, qu'il faut entretenir comme n'importe quel système critique. Et la vérité dérangeante est que vous façonnez cette culture que vous le vouliez ou non — autant le faire délibérément.

Camille Fournier a vécu cet exercice de l'intérieur chez Rent the Runway, où elle a installé une grande partie des structures et pratiques de l'équipe technique. Son conseil tient en une reformulation : ne parlez pas de « structure » et de « process » — des mots qui font fuir les esprits de startup — parlez d'apprentissage et de transparence. On ne met pas en place des systèmes parce que la structure a une valeur en soi. On le fait parce qu'on veut apprendre de ses succès et de ses erreurs, partager les premiers et encoder de façon transparente les leçons des secondes. C'est ainsi qu'une organisation devient plus stable et plus scalable avec le temps.

La structure : trop tôt nuit, trop tard aussi

Beaucoup de gens attirés par les startups voient la structure comme « lente » et « tueuse d'innovation ». Pourtant, l'absence revendiquée de structure est une illusion. Comme l'analyse Jo Freeman dans « The Tyranny of Structurelessness », prétendre fonctionner sans structure ne fait que créer des structures de pouvoir cachées (hidden power structures), issues de la nature même de la communication humaine. Une équipe sans structure apparente est en réalité soit moins autonome qu'elle ne le croit, soit gouvernée par des hiérarchies informelles — souvent les deux.

Freeman décrit les rares conditions sous lesquelles un groupe non structuré fonctionne vraiment : il est orienté tâche, petit et homogène, doté d'une forte communication et d'une faible spécialisation des compétences. C'est exactement le portrait de la jeune startup qui recrute des ingénieurs « full stack » via son réseau, les regroupe physiquement et les fait travailler comme simple bras d'exécution du produit. Cela marche — jusqu'à un certain point. La structure est précisément la façon dont on scale, dont on se diversifie et dont on prend en charge des tâches plus complexes sur le long terme. On le fait pour le code, pour les équipes et pour les process.

Le danger existe dans les deux sens. Rien n'est plus ridicule qu'une petite équipe dotée d'une hiérarchie rigide : cinq personnes empilées en cinq niveaux, ou qui passent leur temps en réunion à décider du papier toilette. La structure peut arriver trop tôt et freiner un groupe qui devrait se concentrer ailleurs. Mais dans les petites entreprises, le cas le plus courant est l'inverse : la structure arrive trop tard. Une personne s'habitue à tout décider et à changer d'avis sans cesse ; ce qui fonctionne à trois devient du chaos à 10, 20, 50. Le coût du changement d'avis explose.

Astuce

Une analogie que Fournier reprend de son ami On Freud sur la croissance : la startup débutante est une voiture de course — proche du sol, ultra-réactive, mais vous ne crashez que vous-même. En grandissant, vous passez au vol commercial : plus de vies dépendent de vous, vos mouvements doivent être plus réfléchis, mais vous tournez encore assez vite. Enfin vient le vaisseau spatial : impossible de virer brusquement, la trajectoire est fixée longtemps à l'avance, mais vous emmenez énormément de monde très loin. Reconnaissez la taille du vaisseau que vous pilotez.

Laissez l'échec guider l'évolution

Comment savoir quand ajouter ou retirer de la structure ? La réponse de Fournier est limpide : l'échec est le meilleur guide. La loi de Gall (citée dans Systemantics) le rappelle — un système complexe qui fonctionne a toujours évolué à partir d'un système simple qui fonctionnait ; un système complexe conçu d'un coup ne marche jamais. Inutile de sur-concevoir la structure d'une petite équipe qui tourne bien. Mais dès que des échecs apparaissent, examinez tout ce qui y contribue : les patterns que vous repérez sont autant d'occasions de faire évoluer la structure, en en ajoutant, en la modifiant ou en la supprimant.

Pesez la fréquence d'un échec et son coût. Une seule personne qui démissionne faute de perspective de carrière ne justifie peut-être pas de créer une grille de carrière ; plusieurs départs, oui. Et appliquez la structure au bon niveau : si l'échec ne touche qu'une équipe, corrigez la structure de cette équipe sans bouleverser l'ensemble. Méfiez-vous en revanche d'apprendre du succès : c'est un mauvais professeur. Nous attribuons volontiers nos échecs à la malchance et nos succès à notre talent — ce qui nous protège heureusement de sur-structurer à partir des échecs, mais nous expose au mirage de la « solution miracle » tirée d'un succès dont nous ne maîtrisons pas le contexte.

Symptôme observé	Cause	Structure à introduire
Chaque embauche ralentit l'équipe pendant des mois	Pas de processus d'intégration (onboarding)	Process d'onboarding documenté
Les gens partent faute de perspectives	Pas de grille de carrière (career ladder)	Échelle de niveaux et bandes salariales
Énième panne car quelqu'un a manipulé la base en direct	Pas de garde-fou opérationnel	Revue d'architecture, restrictions de rôles
Salaires fixés au hasard des négociations	Pas de structure salariale	Bandes de salaire adossées à la grille

Attention

Ne soyez pas attaché aux anciennes structures par pur réflexe. Beaucoup de gens refusent toute structure parce qu'ils ont subi une bureaucratie imposée sans explication. Mais l'inverse blesse aussi : une grille de carrière copiée chez un ami a échoué lamentablement chez Fournier, parce que son équipe — très diverse en parcours — avait besoin de beaucoup plus de détails que celle de son ami, soudée par une culture d'entreprise commune. Ce qui marche ailleurs ne se transpose pas mécaniquement, même entre entreprises très semblables.

Ce qu'est vraiment la culture

Culture is how things get done, without people having to think about it. — Frederick Laloux

La culture, ce sont les règles partagées, le plus souvent tacites, d'une communauté : ce qui guide les décisions quand personne ne regarde. Elle ne signifie pas que chacun partage exactement les mêmes valeurs, mais elle crée un large recouvrement et une foule de règles d'interaction qu'on n'a plus besoin de penser quand on y est profondément ancré. Dans les environnements complexes où les besoins du groupe doivent primer sur ceux de l'individu, les valeurs culturelles sont la colle qui permet de travailler en équipe et de décider face à l'incertitude.

Si vous montez une entreprise, ne comptez pas sur l'apparition spontanée d'une culture saine : la réalité est une course à la survie, et la culture vient souvent après coup. Les premiers employés forment la culture, pour le meilleur et pour le pire. Si vous arrivez dans une entreprise dotée de valeurs fondamentales (core values), elles ont été créées par les fondateurs et reflètent leur culture — et vous serez mesuré à leur aune, que vous le réalisiez ou non. Les employés qui incarnent naturellement toutes les valeurs s'épanouissent ; ceux qui en partagent moins rencontreront plus de friction. Cela vaut aussi pour vous : plus l'écart entre vos valeurs et celles de l'entreprise est grand, plus votre vie sera difficile.

À retenir

N'ayez pas peur d'avoir des valeurs par crainte de la discrimination — c'est l'inverse. « Les ingénieurs diplômés du MIT » n'est pas une culture. « Des gens qui valorisent l'innovation technologique, le travail, l'intelligence, la démarche scientifique et la donnée » en est une. La première ne laisse passer qu'une frange infime de l'humanité ; la seconde admet un éventail bien plus large de personnes tout en garantissant qu'elles partagent réellement les mêmes valeurs. Des valeurs authentiques et réfléchies réduisent la discrimination de surface plutôt que de l'alimenter.

Incarner les valeurs, pas les afficher

Comprendre et cultiver la culture est un pilier de votre travail de leader. Fournier propose une démarche concrète, et un principe surplombe tout : l'exemple du leader pèse infiniment plus que les chartes.

Définissez d'abord votre culture. Si l'entreprise a des valeurs, projetez-les sur votre équipe ; ajoutez-en éventuellement quelques-unes qui lui sont propres. Chez Rent the Runway, l'équipe technique valorisait explicitement la diversité (on s'intéressait davantage au potentiel qu'au respect de cases à cocher) et superposait une culture d'apprentissage aux valeurs de l'entreprise. Chaque sous-équipe aura sa propre coloration, et c'est sain.

Renforcez votre culture en récompensant ceux qui incarnent ses valeurs. Lors des réunions plénières (all-hands), laissez les gens se donner des « shoutouts ». Cet exercice peut mettre mal à l'aise — Fournier l'avoue — mais les histoires qu'une communauté se raconte la soudent. Faites-le sincèrement, jamais de façon forcée.

Servez-vous des valeurs dans les évaluations de performance. L'un des usages les plus importants de l'entretien d'évaluation est de mesurer l'alignement entre les valeurs de la personne et celles de l'entreprise. Nommez concrètement quand et comment chacun incarne une valeur : cela renforce positivement le comportement souhaité et vous éclaire sur qui est aligné et qui ne l'est pas. Repérez les conflits de valeurs : si « retroussez vos manches » est une valeur, celui qui refile sans cesse le travail aux autres ne la suit pas. Utiliser les valeurs pour coacher quelqu'un sur ses désalignements permet de mettre des mots sur une friction autrement floue.

Intégrez les valeurs au processus de recrutement. Rappelez leurs valeurs à vos intervieweurs et demandez-leur de repérer explicitement les correspondances et les collisions.

Piège courant

Évitez le piège du « cultural fit » version copain. Beaucoup d'entretiens jaugent l'adéquation par des marqueurs d'amitié — « aimeriez-vous être coincé dans un aéroport avec cette personne ? ». Or l'adéquation culturelle n'est pas une histoire d'amitié. On peut avoir d'excellentes relations de travail avec des gens qu'on ne fréquenterait pas hors du bureau, et l'inverse. Pire, le test de l'amitié est presque toujours discriminatoire : on se lie avec ceux qui partagent notre parcours — école, classe, race, genre. Préférez l'enrichissement culturel (cultural add) au clonage : soyez spécifique sur les valeurs de l'équipe, et notez où le candidat y correspond ou s'en écarte.

Process d'ingénierie : le process comme gestion du risque

Les process d'ingénierie sont l'endroit où la structure touche concrètement le terrain. Grilles de carrière, valeurs et structures d'équipe sont faciles à côté de l'angoisse que peut provoquer un mauvais process technique. Sans process, vos équipes peinent à scaler ; avec le mauvais process, elles ralentissent. La clé est de penser le process comme un proxy de la rareté ou de la difficulté souhaitée pour une action : un process compliqué ne doit exister que pour des activités rares, ou dont les risques ne sont pas évidents pour tout le monde.

Deux implications en découlent. D'abord, ne mettez jamais un process lourd sur une activité fréquente et à risque faible ou évident — sinon vous plombez la productivité de tout le groupe. Ensuite, traquez le risque caché et exposez-le au grand jour. Comme en politique, « une bonne idée est une idée qui marche même à moitié appliquée » : un bon process garde de la valeur même imparfaitement suivi, et cette valeur réside surtout dans le fait de socialiser le changement et le risque auprès de l'équipe. Fournier identifie trois process majeurs à envisager en grandissant — tous visent à dépersonnaliser la décision.

Process	But réel	Bonnes pratiques	Piège à éviter
Revue de code (code review)	Socialiser le code (plusieurs personnes l'ont vu), pas attraper les bugs — ce sont les tests qui attrapent les bugs	Process simple et rapide ; un linter tranche le style automatiquement ; surveiller le backlog de revues	Plateforme de critique ou de nitpicking sur le style
Post-mortem (learning review)	Apprendre de l'incident, pas trouver un coupable	Comprendre le contexte et les facteurs contributifs ; ne retenir qu'un ou deux axes vraiment à risque	Pointer du doigt ; une liste de courses qu'on ne traitera jamais
Revue d'architecture	Socialiser les gros changements (langage, framework, stockage, outillage) et exposer leurs risques	Le board inclut ceux qui seront impactés ; la valeur est dans la préparation de la revue	Process lourd sur le design de feature courant ; un veto venu d'un domaine sans rapport

Astuce

Pour la revue de code, sortez le style du débat. Les ingénieurs gaspillent un temps absurde sur le formatage. Décidez d'un style, mettez-le dans un linter qui formate automatiquement, et le sujet disparaît. Laisser le style ouvert à la discussion en revue mène au nitpicking au mieux, au harcèlement au pire.

Apprendre de l'échec : des post-mortems sans blâme

Le post-mortem est l'élément le plus révélateur d'une culture d'ingénierie saine. Beaucoup le renomment désormais « learning review » pour signaler que son objet n'est pas d'établir une cause de décès, mais d'apprendre de l'incident. Trois principes sont critiques, surtout pour les petites équipes.

Résistez à l'envie de pointer du doigt. Après une panne stressante, il est terriblement tentant de reprocher à la personne de ne pas avoir anticipé les conséquences : pourquoi a-t-elle lancé cette commande, n'a-t-elle pas testé, a-t-elle ignoré cette alerte. Mais ce blâme n'aboutit qu'à une chose : les gens prennent peur de faire des erreurs — et cessent donc de les remonter. C'est l'inverse de ce qu'il faut. Évitez donc le blâme pour qu'au contraire les erreurs deviennent des apprentissages.

Examinez les circonstances et le contexte. Cherchez les facteurs qui ont contribué à l'incident : un test qui l'aurait détecté, un outil qui aurait fluidifié la gestion. Cette liste de contributeurs circonstanciels révèle des patterns et des axes d'amélioration — c'est tout le « learning » de la learning review.

Soyez réaliste sur les enseignements à retenir. Ne donnez pas l'impression qu'il faut résoudre chaque problème identifié. Ces revues finissent souvent en liste de courses interminable ; si vous tentez de tout faire, vous ne ferez rien. Choisissez le ou les deux points réellement à haut risque, et assumez ouvertement ceux que vous laissez de côté pour l'instant.

Structurer les équipes : transverse plutôt que cloisonné

À mesure qu'une entreprise grandit, il faut répondre à des questions devenues floues : avec qui travaillez-vous, à qui rapportez-vous, avec qui collaborez-vous ? Chez Rent the Runway, Fournier a fait évoluer l'organisation vers des équipes transverses (cross-functional teams) — appelez-les « pods », « squads » ou « pillars ». L'idée : réunir dans un même groupe tous ceux nécessaires au succès d'un projet — ingénieurs frontend et backend, product manager, designers, analyste, voire un représentant du service client.

Le premier essai — une fonctionnalité autour des photos clientes — fut un franc succès : la livraison fut rapide, et chacun comprenait les objectifs. Surtout, ces unités firent passer l'organisation du « nous contre eux » (chaque fonction se vivant comme « nous » face au reste) à un grand « nous » partagé. C'est la loi de Conway à l'œuvre : les organisations produisent des designs qui copient leurs structures de communication. En montant des équipes transverses, vous privilégiez la communication qui mène à un développement produit efficace.

Note

Cette structure a un coût assumé : elle ne produira pas forcément la meilleure technologie. Une organisation centrée produit générera sans doute des systèmes un peu moins efficients qu'une organisation centrée ingénierie. Vous devez décider où vous acceptez des compromis de design système pour livrer du produit plus efficacement. Côté management, on ne change pas les lignes hiérarchiques : les ingénieurs restent managés par des managers d'ingénierie ; c'est le pod qui décide du quotidien. Et réservez environ 20 % du temps d'ingénierie pour l'astreinte (on-call), les entretiens et la dette technique.

La structure transverse change aussi les valeurs des gens. Entre ingénieurs du même type, le modèle est celui qui conçoit les systèmes les plus complexes. Dans une structure produit, ce sont ceux qui ont le meilleur sens produit, qui livrent vite et qui communiquent le mieux avec les autres fonctions qui émergent comme leaders. Aucun jugement de valeur ici : demandez-vous ce qui est vraiment important pour le succès de votre entreprise, et orientez vos recrutements en conséquence.

Adapter la culture à la taille

Le fil rouge du chapitre est qu'il n'existe pas de recette universelle : ce qui fonctionne à 10 personnes échoue à 100. Reconnaître la taille du vaisseau que vous pilotez dépend de plusieurs facteurs combinés.

Facteur	Effet sur le besoin de structure
Nombre de personnes	Plus on est nombreux, plus il faut de structure réfléchie pour aligner tout le monde — surtout autour de la fixation d'objectifs
Âge de l'entreprise	Plus elle est ancienne, plus les habitudes sont ancrées — mais plus elle a de chances de durer
Taille de l'infrastructure	Plus il y a de règles métier, de code et d'infra existants, plus il faut de clarté pour les gérer
Tolérance au risque	Secteur régulé ou beaucoup à perdre ? Plus de structure. Peu en jeu ? Moins de structure

La grille de carrière illustre parfaitement cette adaptation : impliquez l'équipe dans sa rédaction, cherchez des exemples ailleurs, soyez détaillé mais à l'échelle de votre entreprise, séparez les voies management et technique, et n'ayez pas peur de la faire évoluer — c'est un document vivant. La même prudence vaut pour tout : une structure rigide et figée n'est jamais justifiée, même dans une grande entreprise stable, car les évolutions technologiques rendent souvent sûrs des mouvements autrefois risqués.

Le leadership est un parcours, jamais terminé

C'est le message final du livre. Vous avez parcouru le chemin du mentor au manager puis au leader senior. La leçon la plus importante de Fournier : pour bien manager les autres, il faut savoir se manager soi-même. Plus vous comprenez vos réactions, ce qui vous inspire et ce qui vous exaspère, mieux vous vous porterez.

Les grands managers sont des maîtres de la résolution de conflits, ce qui suppose de sortir son ego de la conversation : voir au-delà de ses interprétations et des histoires qu'on se raconte. L'outil que Fournier retient, après des années d'erreurs et de leçons difficiles, tient en deux mots, qu'elle se répète chaque matin comme un mantra : « Get curious. » Cherchez l'autre version de l'histoire. Demandez-vous ce que l'autre essaie de faire, ce qu'il valorise, ce dont il a besoin. Appliquez cette curiosité aux gens, au process, à la technologie, à la stratégie. Posez des questions, et acceptez d'avoir tort. Le parcours ne se termine jamais — et c'est précisément ce qui le rend passionnant.

À retenir

Vous façonnez la culture que vous le vouliez ou non : autant le faire délibérément. Parlez d'apprentissage et de transparence plutôt que de « structure » et de « process » — c'est ce dont il s'agit vraiment.
La structure doit arriver au bon moment : trop tôt, elle étouffe une petite équipe ; trop tard (le cas le plus courant), elle laisse le chaos s'installer. Laissez l'échec, jugé à sa fréquence et son coût, guider son évolution.
Des valeurs authentiques s'incarnent, elles ne s'affichent pas : l'exemple du leader pèse plus que toute charte. Récompensez ceux qui les vivent, coachez les désalignements, et recrutez pour l'enrichissement culturel (cultural add), pas pour le clone.
Pensez chaque process comme une gestion du risque : lourd seulement sur le rare ou le risque caché, léger sur le fréquent. Code review, post-mortem et revue d'architecture servent avant tout à socialiser le changement et à dépersonnaliser la décision.
Cultivez l'apprentissage de l'échec : refuser de pointer du doigt évite que les gens aient peur de faire des erreurs et cessent de les remonter — c'est ainsi qu'elles deviennent des apprentissages.
Ce qui marche à 10 échoue à 100 : adaptez structure, équipes transverses et grille de carrière à la taille, à l'âge et au risque. Et souvenez-vous que le leadership est un parcours d'apprentissage continu : restez curieux.