Pourquoi 100% de disponibilité est votre pire ennemi

Je vais vous dire quelque chose que votre CTO n’aime pas entendre : vous ne devriez pas viser 100% de disponibilité.

J’ai passé 15 ans en infrastructure. J’ai vu les plus grands acteurs tech du monde construire des systèmes aussi massifs qu’instables. Et j’ai aussi vu des scale-ups avec un tiers des ressources rester stables. La différence ? Pas la taille. C’est la matrice de décision.

1. La loi des rendements décroissants (et son coût exponentiel)

En mathématiques, on l’appelle la “loi des rendements décroissants”. En ingénierie, on l’appelle “cause du burnout”.

Passer de 99% à 99,9% de disponibilité ? Faisable. Ça demande une bonne architecture, de la redondance intelligente, du monitoring.

Passer de 99,9% à 99,99% ? Ça demande les meilleures talents, des architectures complexes, de la géo-redondance, une obsession du détail.

Passer à 99,999% (cinq nines) ? Vous devez construire des trucs que personne n’a construits avant. Vous devez inventer. Votre coût opérationnel explose. Votre cycle d’innovation ralentit parce que chaque changement est un risque existentiel.

Et viser les 100%? C’est mathématiquement impossible. C’est comme viser l’infini.

Ce 0,01% final vous coûte plus cher que tous les 99,99% précédents réunis.

2. Le paradoxe de l’innovation : La peur du changement

Voici ce qui arrive dans une org obsédée par “zéro panne” :

L’équipe commence à avoir peur. Peur de déployer. Peur d’expérimenter. Peur d’optimiser le code parce que “et si ça break ?”.

Vos déploiements qui prenaient 10 minutes prennent maintenant 2 jours : tests de régression, validations manuelles, approbations de comités. Chaque changement est un risque.

Résultat ? Vous accumulez de la dette technique. Votre code vieillit. Vos frameworks ne sont plus à jour. Vos dépendances deviennent des bombes à retardement.

Et là arrive un concurrent plus agile qui accepte une marge d’erreur saine, déploie 10x plus vite, et innove 10x plus. Maintenant, vous n’êtes plus juste lent. Vous êtes obsolète.

3. Le problème du “Last Mile”

Imaginez ça : vous avez construit la plus belle infrastructure du monde. 100% de disponibilité garantie. Zero downtime. Les serveurs sont immortels.

Mais votre client ? Il est sur un café avec du Wi-Fi gratuit. Ou il utilise la 4G d’un FAI grand public qui ne promet que 95% de connectivité.

Quand sa connexion tombe, il ne sait pas que vos serveurs, eux, tournent parfaitement. Tout ce qu’il sait, c’est qu’il ne peut pas accéder à votre service.

La fiabilité perçue est toujours limitée par le maillon le plus faible de la chaîne. Et ce maillon, 90% du temps, ce n’est pas vous.

Pourquoi investir des ressources infinies dans ce que vos utilisateurs ne ressentent jamais ?

4. La solution : Les SLO et l’Error Budget

Le modèle SRE a trouvé la réponse. C’est pas révolutionnaire, mais c’est pragmatique.

Au lieu de viser 100%, vous définissez un SLO (Service Level Objective) : “Je vise 99,9% de disponibilité”.

De ce 99,9%, vous dégagez un Budget d’Erreur : 0,1% de downtime accepté. Pour une année, ça représente ~8.7 heures de downtime acceptable.

Ici, ça devient psychologique mais crucial : vous avez maintenant une ressource. C’est du capital risque que vous pouvez “dépenser” pour :

Lancer des features audacieuses : Vous avez dépensé 2h de votre budget ? Ça signifie vous pouvez expérimenter davantage le mois prochain
Faire du Chaos Engineering : Cassez intentionnellement votre système pour le rendre plus fort
Accélérer votre déploiement : Moins de validations manuelles, plus de confiance

Vos équipes Dev et Ops parlent enfin le même langage : celui du budget d’erreur. Un dev qui code une feature comprend qu’il “dépense” du budget si elle est inefficace.

5. La question pour votre CTO

C’est pas “Comment je garantis 100% d’uptime ?”

C’est : “Quel est le niveau de fiabilité que mon métier exige réellement ? Et à quel coût ?”

Vous vendez des billets de train ? Peut-être 99,95% (quelques minutes par mois acceptable)
Vous gérez une app bancaire ? Peut-être 99,99%
Vous avez un blog ? 99% est largement suffisant

Une fois que vous avez cette réponse, vous arrêtez de brûler de l’argent sur la perfection et vous commencez à construire intelligemment.

Conclusion : Piloter par la valeur, pas par la peur

Le rôle d’un leader technique moderne n’est pas de garantir que votre système ne tombera jamais.

C’est de s’assurer qu’il tombe rarement, de manière contrôlée, et qu’il se répare vite.

Chez Leanovia, on ne vous vend pas une perfection stérile. On vous construit des systèmes résilients qui absorbent les erreurs sans interrompre le business.

Et on vous donne les outils (SLO, budget d’erreur, incident reviews) pour piloter ça intelligemment.

Et vous, comment dépensez-vous votre budget d’erreur cette année ?