Situation réelle “On veut une culture d’excellence technique.” Cette ambition est louable, mais vague. Qu’est-ce que ça signifie concrètement ? Comment on la construit ? Et surtout, comment on la maintient quand l’équipe grandit ? Ce que j’ai observé : la culture technique ne se décrète pas dans un manifeste. Elle se construit jour après jour, par des choix concrets qui s’accumulent. Une culture forte survit au changement d’équipe et au turnover. ...
Article basé sur le livre “Être ou ne pas être CTO”. Situation réelle Premier jour comme CTO. L’équipe vous observe. Le CEO attend des résultats. Vous avez une vision de ce qui devrait changer, mais vous ne connaissez pas encore le contexte réel des décisions passées. La tentation est grande de montrer votre valeur en agissant rapidement. Ce que j’ai observé : les premiers 90 jours déterminent rarement le succès à long terme, mais ils façonnent la perception que l’équipe et l’organisation auront de vous. Cette période est moins une course contre la montre qu’un exercice d’écoute et de compréhension. ...
Situation réelle Réunion silencieuse. Tout le monde sait que cette décision est mauvaise, mais personne ne dit rien. Absence de sécurité psychologique : la peur de parler l’emporte sur le bénéfice de la vérité. Ce que j’ai observé : la sécurité psychologique (concept popularisé par Google via Project Aristotle) est le facteur #1 de performance d’équipe. Avant compétences, avant processus, avant outils. Le faux problème Le faux problème serait de croire que sécurité psychologique = tout le monde est gentil. En réalité, c’est un environnement où on peut être en désaccord sans peur de représailles. ...
Situation réelle Un bon développeur qui met 2 semaines à être productif = 2 semaines perdues + frustration. Cette situation n’est pas une fatalité. Un onboarding structuré peut réduire ce temps à 2 jours. Ce que j’ai observé : le coût d’un mauvais onboarding est réel. 2 semaines de salaire perdu (~$4k), frustration nouveau dev, temps équipe mobilisé. Impact long terme : mauvais onboarding → premier mois frustrant → doutes sur choix entreprise → 30% quittent dans 90 jours. Bon onboarding → productif rapidement → confiance boostée → rétention +50%. L’onboarding n’est pas un détail, c’est votre première impression. ...
Situation réelle “Tu as bien fait, mais…” Le feedback mal donné démotive plus qu’il n’aide. Cette situation n’est pas une fatalité. Le feedback efficace peut construire une culture de croissance plutôt qu’une culture de peur. Ce que j’ai observé : beaucoup de managers donnent du feedback uniquement négatif (“Ton code a des bugs”, “Ta PR n’est pas bonne”, “Tu es en retard”) ou vague (“C’est bien”, “Tu peux mieux faire”, “Continue comme ça”). Résultat: démotivation, peur de l’échec, pas d’action concrète possible. Le feedback efficace est régulier, spécifique, équilibré, actionnable. Règle d’or : le feedback doit faire grandir, pas seulement corriger. ...
Situation réelle Code review : rituel quotidien qui peut faire progresser l’équipe… ou créer de la frustration. Cette situation n’est pas une fatalité. Un code review efficace peut être un accelerator : knowledge sharing, quality improvement, team cohesion. Ce que j’ai observé : beaucoup de code reviews sont frustrantes. Pour l’auteur (09h00 crée PR, 16h30 pas review, lendemain 14h enfin review, 16h00 corrige commentaires, lendemain 11h 2ème review nouveaux comments, 5 jours merger 200 lignes). Pour le reviewer (PR à reviewer 1500 lignes “Où commencer ?” “Trop gros comprendre” “Approve en diagonale”). Résultat: vélocité ralentie, frustration deux côtés, quality compromise. Un code review efficace nécessite small PRs <400 lignes, fast feedback <24h, constructive comments, celebrate good code. ...
Situation réelle “Pourquoi je ne l’ai su qu’aujourd’hui ?” La communication managériale fait ou casse la confiance. Cette question révèle un problème de communication : sur-communication sans information, sous-communication sur décisions importantes, communication unidirectionnelle. Ce que j’ai observé : beaucoup de managers communiquent mal. Sur-communication sans information (réunion quotidienne “On continue comme hier” → aucune valeur ajoutée perte temps). Sous-communication sur décisions importantes (décision prise en haut équipe l’apprend par rumeur → perte confiance frustration). Communication unidirectionnelle (manager parle équipe écoute → pas échange pas feedback). La communication managériale efficace nécessite transparence avec discernement, fréquence adaptée au message, clarté avant tout, écoute plus que parole, action plutôt que simple information. ...
Situation réelle “Pourquoi changer ? Ça marche déjà.” La résistance au changement est normale. Cette réaction n’est pas de la mauvaise volonté, c’est une réaction humaine face à l’incertitude. Comprendre cette résistance permet de la gérer efficacement pour transformer l’équipe sans la casser. Ce que j’ai observé : beaucoup de changements échouent parce qu’ils sont imposés sans comprendre les résistances réelles. La résistance vient souvent de peur de l’inconnu, perte perçue, manque de confiance. Gérer le changement efficacement nécessite de comprendre ces résistances, communiquer la vision clairement, impliquer l’équipe, supporter la transition, mesurer l’impact. Règle d’or : le changement doit être un voyage qu’on fait ensemble, pas une destination imposée. ...
Dédramatisation “Lisez la doc.” Mais quelle doc ? Celle écrite il y a 2 ans et obsolète depuis 18 mois ? Cette situation n’est pas une fatalité. Voici comment créer une documentation que les développeurs vont réellement lire et maintenir. Ce que j’ai observé : le problème Doc obsolète inexistante. Symptômes classiques (README.md Last updated 2021 Run npm install Mais projet utilise pnpm depuis 2023 Ou pire Fichier user.service.ts 500 lignes Commentaire Aucun README “Le code se documente lui-même” Résultat Nouveaux devs perdus Bugs incompréhension Temps perdu reverse-engineer). Documentation n’est pas optionnelle. C’est multiplier : Onboarding 3x plus rapide Bugs -50% meilleure compréhension Contributions facilitées. Principes : Code self-documenting d’abord, Documenter “Pourquoi”, Rester proche code, Tester maintenir. Commencer petit : README Quick Start 1h, Guides essentiels 1 jour, CI check docs 2h, Iterate feedback. ...
Stratégies tirées de “Être ou ne pas être CTO”, chapitre “Construire l’équipe technique”. Situation réelle “On recrute quand ?” Cette question revient régulièrement dans les discussions stratégiques. Trop tôt, vous brûlez du cash sans nécessité réelle. Trop tard, vous brûlez votre équipe qui s’épuise. Le timing est critique, mais il n’y a pas de réponse universelle. Ce que j’ai observé : le recrutement n’est pas qu’une question de timing. C’est aussi une question de structure organisationnelle, de profils à recruter, de processus de recrutement, d’onboarding, et de rétention. Construire une équipe technique performante, c’est orchestrer tous ces éléments de manière cohérente. ...