Cinq neuf de disponibilité : pourquoi nous annonçons 99,99% (et pas 99,999%)

« 99,999% de disponibilité. » La formule rassure, elle tient dans un slogan, elle ferme un appel d'offres. Traduite en temps réel, elle devient pourtant une contrainte brutale : cinq minutes et quart d'indisponibilité tolérées sur une année entière. Pas par incident. Au total.

Beaucoup de prestataires affichent ce chiffre sans le mesurer. Nous avons fait l'inverse : nous avons regardé ce que nous tenons vraiment, sur le périmètre que nous opérons, et nous avons choisi d'annoncer ce que nous sommes capables de prouver. C'est 99,99%. Voici pourquoi.

Cinq neuf, ce que le chiffre veut dire

On parle de « neuf » pour le nombre de 9 dans le pourcentage de disponibilité. 99,9% (trois neuf), c'est près de neuf heures d'arrêt par an. 99,99% (quatre neuf), un peu moins d'une heure. 99,999% (cinq neuf), environ cinq minutes. Chaque neuf supplémentaire divise par dix le temps d'arrêt toléré, et multiplie l'exigence sur toute la chaîne.

Rapporté au volume, l'écart devient vertigineux. Sur une plateforme qui traite plus de cinq millions d'opérations par jour, trois neuf laissent passer près de cinq mille opérations échouées chaque jour à cause de la seule indisponibilité. Quatre neuf ramènent ce chiffre à cinq cents. Cinq neuf, à une cinquantaine. Ce ne sont pas des décimales sur un tableau de bord, ce sont des paiements qui aboutissent ou non, des clients qui reviennent ou non.

Cette progression n'est pas linéaire dans l'effort. Passer de trois à quatre neuf demande de la rigueur. Passer de quatre à cinq neuf demande de repenser l'architecture : il ne reste plus assez de marge pour qu'un humain diagnostique et répare à temps. La reprise doit devenir automatique, parce que cinq minutes ne suffisent pas à réveiller quelqu'un, comprendre, puis corriger.

Le périmètre maîtrisé et la chaîne complète

Avant d'aller plus loin, il faut distinguer deux périmètres que beaucoup confondent volontairement. Le premier, c'est ce que nous opérons : nos services, nos files, nos bases, nos déploiements, nos plans de reprise. C'est ce que nous maîtrisons et ce sur quoi nous nous engageons. Le second, c'est la chaîne complète vécue par l'utilisateur final : son réseau d'accès, l'opérateur mobile money qui débite, la passerelle interbancaire qui route. Autant de maillons indispensables, et opérés par des tiers.

Nous ne maîtrisons pas cette chaîne complète, et personne sur le continent ne la maîtrise. Annoncer cinq neuf bout-en-bout sur ce contexte, ce serait promettre ce qu'aucun acteur sérieux ne peut tenir. Annoncer cinq neuf sur notre seul périmètre, ce serait s'imposer une rigueur opérationnelle qui ne laisse plus aucune place à l'humain, à la maintenance, au moindre incident non anticipé. Sur un système qui évolue en production, c'est intenable.

Quatre neuf sur notre périmètre, c'est l'engagement honnête : moins d'une heure d'indisponibilité cumulée par an sur ce que nous opérons. Mesuré, vérifié, tenable. Le reste, ce qui se passe entre notre plateforme et l'utilisateur, dépend d'acteurs externes. Nous l'absorbons quand l'architecture le permet : réessais idempotents, files durables, modes dégradés locaux. Mais nous refusons de l'inclure dans un engagement contractuel sur lequel nous n'avons pas la main.

Les pannes ne viennent presque jamais d'où on les attend

L'image d'Épinal de la panne, c'est le serveur qui prend feu. Dans la réalité, le matériel tombe rarement, et quand il tombe, la redondance absorbe le choc. Les vraies indisponibilités viennent d'ailleurs : un déploiement qui passe mal, un certificat expiré, une montée de version d'une dépendance, une requête lente qui sature un pool de connexions, un pic non anticipé un soir de tirage.

Autrement dit, la majorité des arrêts évitables sont auto-infligés. C'est une bonne nouvelle : ce sont des causes sur lesquelles on a prise. Tenir quatre neuf commence par supprimer méthodiquement ces sources de sabotage interne, bien avant de parler de redondance matérielle.

Le déploiement mérite une mention à part, parce qu'il concentre le risque : c'est le moment où l'on modifie volontairement un système qui marchait. Un déploiement progressif, réversible en un geste et observé en continu, transforme cette prise de risque en non-événement. Le déploiement « big bang » du vendredi soir, lui, reste la cause d'incident la plus évitable qui soit.

Concevoir pour la panne, pas contre elle

Un système fiable n'est pas un système qui ne tombe jamais. C'est un système qui continue de rendre le service quand une partie de lui tombe. Cela suppose trois réflexes. La redondance active : aucun composant unique dont la perte arrête tout. La bascule automatique : quand un nœud lâche, le trafic part ailleurs sans intervention humaine. La dégradation maîtrisée : plutôt que de s'arrêter net, le système renonce d'abord au superflu pour préserver l'essentiel, la transaction.

À cela s'ajoutent les garde-fous qui empêchent un incident local de se propager : limites de débit, disjoncteurs qui isolent une dépendance défaillante, files durables qui amortissent les pics, et idempotence pour que rien ne soit perdu ni compté deux fois pendant la bascule. Chacun de ces mécanismes est modeste. Ensemble, ils séparent l'incident invisible de la panne générale.

Le plus difficile, c'est l'état, pas le calcul

Rendre un service de calcul résilient est presque facile : on duplique des instances sans état, on répartit la charge, on remplace une instance morte par une autre. La difficulté commence avec la donnée. Un solde, un journal de transactions, un statut de paiement : ces états ne se répliquent pas sans coût. Il faut arbitrer entre cohérence forte et disponibilité quand le réseau se coupe, dimensionner la réplication, et garantir qu'aucune écriture validée ne se perde en route.

C'est là que se nichent les pannes les plus dangereuses, celles qui ne font pas tomber le service mais corrompent les chiffres. Une bascule mal pensée peut accepter deux fois la même opération, ou en perdre une. La disponibilité ne vaut rien si elle s'achète au prix de l'exactitude. Sur un système transactionnel, l'un ne va jamais sans l'autre.

La moyenne ment, c'est la pointe qui compte

Une disponibilité annuelle se calcule en moyenne, et la moyenne est trompeuse. Un système peut afficher 99,99% sur l'année et avoir laissé tomber tout le monde pendant l'heure la plus importante, un soir de paie ou de gros tirage. Pour l'utilisateur, cette heure-là est la seule qui compte.

C'est pourquoi nous ne raisonnons pas en moyenne mais en pire centile, vécu au pire moment. La bonne question n'est pas « quelle est la disponibilité moyenne ? » mais « que vit l'utilisateur quand le système est le plus sollicité ? ». Concevoir pour la pointe, c'est surdimensionner là où ça compte et tester précisément ces moments-là.

Ce qui ne se prouve pas ne tient pas

Une bascule qui n'a jamais été jouée n'est pas une bascule, c'est une hypothèse. Beaucoup d'architectures réputées « hautement disponibles » s'effondrent au premier vrai incident, parce que le plan de reprise n'avait été validé que sur le papier. La seule garantie sérieuse, c'est de provoquer la panne en conditions contrôlées et de vérifier que le système se rétablit, encore et encore.

Cela demande des exercices réguliers : couper un nœud en production maîtrisée, simuler la perte d'une dépendance, rejouer un pic de charge. Cela demande aussi de l'observabilité, sans laquelle on ignore qu'on s'approche du précipice avant d'y tomber. Mesurer, répéter, prouver : la disponibilité n'est pas un état qu'on atteint, c'est une propriété qu'on entretient.

Ce que nous engageons, ce que nous ne promettons pas

Sur notre périmètre, nous tenons aujourd'hui quatre neuf, soit moins d'une heure d'indisponibilité cumulée par an sur les plateformes que nous opérons. Ce chiffre est mesuré en production, pas estimé en plaquette. Il inclut nos déploiements, nos maintenances, nos incidents internes. Il n'inclut pas ce que nous ne contrôlons pas : une coupure côté opérateur mobile money, un changement de protocole imposé par un partenaire, une défaillance d'infrastructure tiers en amont de notre plateforme.

Cette distinction n'est pas une clause d'évitement, c'est une condition d'honnêteté. Sur ces incidents externes, nous documentons et nous communiquons. Ce que nous refusons, c'est d'imputer à notre engagement de disponibilité ce qui appartient à des acteurs sur lesquels nous n'avons pas la main. Personne ne gagne à des chiffres maquillés.

Pourquoi nous tenons ce niveau

Tenir quatre neuf sur notre périmètre n'est pas un argument de plaquette, c'est le produit d'un modèle. Chez UBIQ, ceux qui conçoivent le système sont ceux qui l'opèrent et qui répondent des incidents. On code différemment quand on sait qu'on sera réveillé si ça casse. Cette responsabilité produit des architectures plus simples, des plans de reprise réellement testés, et une disponibilité qui se vérifie au pire moment, pas seulement en moyenne.

Le jour où nous annoncerons cinq neuf, ce sera parce que nous les aurons tenus, mesurés, deux années de suite, sur un périmètre clairement délimité. D'ici là, nous préférons un chiffre vrai à un chiffre qui ferme un appel d'offres et se paye en confiance perdue à la première panne.