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.
Le faux problème
Le faux problème serait de croire qu’écrire des valeurs sur un mur crée une culture. En réalité, la culture se manifeste dans les comportements réels, pas dans les déclarations.
Un autre faux problème : penser que culture forte signifie culture uniforme. En réalité, une culture saine tolère la diversité de pensée tout en maintenant des principes partagés.
Le vrai enjeu CTO
Le vrai enjeu est de définir et incarner les principes qui guideront l’équipe sur le long terme :
Les 6 piliers d’une culture technique durable :
Pilier 1 - Excellence sans perfectionnisme : Principe : viser la qualité sans bloquer la livraison. Manifestation : code reviews exigeantes mais constructives, standards clairs mais pragmatiques, refactoring continu vs big bang rewrite. Comportements observables : on livre régulièrement, la qualité s’améliore progressivement, pas de features bloquées 3 semaines pour “perfection”.
Pilier 2 - Apprentissage continu : Principe : erreur = opportunité d’apprentissage. Manifestation : post-mortems blameless, temps dédié formation (10-20%), partage connaissances ritualisé. Comportements : on parle ouvertement des erreurs, on documente apprentissages, pas de culture héroïque.
Pilier 3 - Autonomie responsable : Principe : confiance par défaut, accountability explicite. Manifestation : framework décision clair, délégation large, suivi transparent. Comportements : équipes décident sans attendre validation, assument résultats, escaladent quand nécessaire.
Pilier 4 - Collaboration > compétition : Principe : succès collectif > succès individuel. Manifestation : pair programming, code reviews collaboratives, partage credit. Comportements : on aide plutôt qu’on critique, succès célébrés collectivement, pas de héros solitaires.
Pilier 5 - Pragmatisme technique : Principe : résoudre problèmes business, pas faire de la tech pour la tech. Manifestation : choix techniques justifiés par valeur business, compromis assumés, pas de over-engineering. Comportements : on challenge “pourquoi cette techno ?”, on mesure impact, on assume dette intentionnelle.
Pilier 6 - Durabilité humaine : Principe : marathon, pas sprint. Manifestation : pas de crunch culture, équilibre pro-perso respecté, burn-out détecté et géré. Comportements : on finit à 18h, pas de héros surmenés, turnover faible.
Cadre de décision
Voici comment je construis et maintiens cette culture :
1. Définir 3-5 principes explicites Pas 20 valeurs vagues, mais 3-5 principes concrets avec exemples comportementaux. Document partagé, discuté, visible.
2. Incarner les principes Le CTO doit être le premier à les vivre. Si principe = “droit à l’erreur” mais CTO punit erreurs, culture morte. L’équipe suit ce qu’elle voit, pas ce qu’elle entend.
3. Ritualiser les comportements Principes → rituels concrets. “Apprentissage” → 20% time + post-mortems + tech talks mensuels. Ces rituels ancrent la culture.
4. Recruter pour culture fit Évaluer alignment principes pendant recrutement. Compétences s’apprennent, culture fit moins. Mais culture fit ≠ culture clone.
5. Mesurer et ajuster Survey trimestriel : “Culture vécue vs affichée ?”. Ces données révèlent écarts entre intention et réalité.
Retour terrain
Ce que j’ai observé dans différentes organisations :
La culture par accident : Pas de principes définis, culture émerge aléatoirement. Résultat : incohérence, frustration quand recrutement, impossible de scaler.
Les valeurs mur : 15 valeurs affichées, zéro incarnation. “Innovation” affiché mais erreur punie. Résultat : cynisme, perte de sens.
La culture qui dure : 5 principes clairs, ritualisés, incarnés par leadership. Exemple : “Droit à l’erreur” → post-mortems blameless systématiques, CTO partage ses erreurs publiquement. Résultat : culture forte qui survit turnover, nouvelles recrues s’alignent rapidement.
L’exemple concret : Principe “Autonomie responsable”. Rituels : framework décision Type 1/Type 2, ADR obligatoires décisions structurantes, review OKRs trimestriels. Incarnation : CTO délègue décisions Type 2, assume résultats décisions déléguées. Résultat : 85% décisions prises sans CTO, ownership fort, vélocité élevée.
Erreurs fréquentes
Multiplier les valeurs 15 valeurs vagues sur le mur. Résultat : personne ne s’en souvient, aucun impact comportemental.
Ne pas incarner Prôner excellence mais merger code sans tests. Résultat : cynisme, “faites ce que je dis, pas ce que je fais”.
Pas de rituels Principes affichés mais zéro traduction concrète. Résultat : culture reste théorique, jamais vécue.
Culture uniformité Chercher des clones culturels plutôt que culture fit. Résultat : perte de diversité, groupthink, stagnation.
Si c’était à refaire
Avec le recul, voici ce que je ferais différemment :
Co-créer les principes Pas imposer top-down, mais co-construire avec équipe. Cette participation crée ownership.
Commencer avec 3 principes Pas 10 dès le début. 3 principes bien incarnés > 10 principes théoriques. Ajouter progressivement.
Ritualiser immédiatement Pour chaque principe : quel rituel concret ? Implémenter ces rituels avant même que l’équipe grandisse.
Mesurer culture dès 10 personnes Survey trimestriel simple : culture vécue vs affichée. Ces données permettent ajustements précoces.
Pour approfondir
Le livre “Être ou ne pas être CTO” explore comment différents CTOs construisent et maintiennent leur culture technique.
Pour approfondir, tu peux aussi consulter les autres articles du pilier “Culture & management”.