Situation réelle

“On veut innover mais on ne peut pas se permettre d’instabilité.” Cette tension, tout CTO la ressent. Le business veut de la nouveauté, mais aussi que rien ne casse.

Ce que j’ai observé : innovation et stabilité ne sont pas opposés. C’est une fausse dichotomie. L’enjeu est de créer les conditions pour innover sans mettre en danger la stabilité.

Le faux problème

Le faux problème serait de croire qu’il faut choisir entre les deux. En réalité, les organisations qui durent savent faire les deux simultanément, sur des timeboxes et scopes différents.

Un autre faux problème : penser que stabilité signifie immobilisme. En réalité, la stabilité bien comprise inclut l’évolution contrôlée.

Le vrai enjeu CTO

Le vrai enjeu est de structurer l’organisation pour permettre les deux :

Les 3 horizons temporels (McKinsey) :

Horizon 1 - Maintenir (70% ressources) : Focus : optimize existing, stabilité, run the business. Exemples : features produit core, maintenance, support. Innovation : incrémentale, faible risque. Stabilité : critique, zéro tolérance incident.

Horizon 2 - Étendre (20% ressources) : Focus : nouvelles offerings adjacentes, croissance. Exemples : nouvelles features majeures, nouveaux marchés. Innovation : modérée, risque calculé. Stabilité : importante, incidents tolérés si isolés.

Horizon 3 - Explorer (10% ressources) : Focus : disruption, exploration, long terme. Exemples : POC IA, nouvelle techno, R&D. Innovation : haute, échec acceptable. Stabilité : non critique, sandbox séparé.

Les patterns d’organisation :

Pattern 1 - Séparation équipes : Équipe A (H1) : stabilité,production, SLA strict. Équipe B (H2+H3) : innovation, expérimentation, fail fast. Communication forte entre les deux.

Pattern 2 - Time-boxing : 80% temps sur H1, 20% temps sur H2+H3. Exemple : “20% time” Google, “hack days” mensuels.

Pattern 3 - Feature flags : Innovation déployée mais désactivée, activation progressive. Rollback immédiat si problème. Stabilité préservée.

Cadre de décision

Voici comment je gère cette tension :

1. Allouer explicitement selon horizons 70% H1, 20% H2, 10% H3. Cette allocation claire évite “on fait tout en même temps”.

2. Standards différenciés par horizon H1 : test coverage 90%, review multiple, monitoring strict. H3 : POC, pas de tests, sandbox isolé. Cette différenciation permet vitesse H3 sans compromettre H1.

3. Feature flags systématiques Toute innovation déployée avec flags. Activation 1% puis 10% puis 100%. Rollback en 1 clic. Stabilité préservée.

4. Blameless postmortems Incident sur innovation : apprendre, pas punir. Cette culture permet innovation sans peur.

5. Mesurer les deux dimensions Métriques stabilité : uptime, MTTR, incident rate. Métriques innovation : features livrées, POCs, adoption nouvelles technos. Dashboard équilibré.

Retour terrain

Ce que j’ai observé dans différentes organisations :

100% stabilité : “On ne change rien, trop risqué.” Résultat : stagnation, concurrence qui innove, perte de parts de marché, talents qui partent.

100% innovation : “Move fast and break things” sans garde-fous. Résultat : instabilité chronique, clients frustrés, réputation ternie, churn élevé.

L’équilibre H1/H2/H3 : 70% maintain, 20% extend, 10% explore. H1 ultra-stable (99.9% uptime), H3 en sandbox. Résultat : clients satisfaits ET pipeline innovation.

Feature flags qui sauvent : Feature IA lancée avec flag, bugs détectés à 5% adoption, rollback immédiat. Fix en 2 jours, relance progressive. Stabilité préservée, innovation livrée.

Erreurs fréquentes

Tout mélanger Pas de séparation H1/H2/H3. Résultat : instabilité H1, innovation ralentie, pire des deux mondes.

Innover sur la prod Tester en production sans feature flags ni sandbox. Résultat : incidents, clients impactés, perte de confiance.

Punir les échecs d’innovation Blâmer une équipe quand POC échoue. Résultat : peur d’innover, stagnation.

Ne pas mesurer les deux Tracker uniquement uptime ou uniquement features. Résultat : déséquilibre, sur-optimisation d’un côté.

Si c’était à refaire

Avec le recul, voici ce que je ferais différemment :

Séparer clairement H1/H2/H3 dès 20 personnes Équipes ou timeboxing explicites. Cette séparation permet vitesse H3 sans compromettre H1.

Feature flags dès le début Toute feature significative derrière flag. Cette pratique permet innovation rapide sans risque stabilité.

Célébrer les échecs H3 “POC X a échoué, on a appris Y.” Cette culture encourage innovation.

Dashboard équilibré Métriques stabilité ET innovation affichées au comex. Cette visibilité maintient l’équilibre.

Pour approfondir

Le livre “Être ou ne pas être CTO” explore comment différents CTOs gèrent cette tension selon leur contexte.

Pour approfondir, tu peux aussi consulter les autres contenus du pilier “Gouvernance & décision”.