Le problème
Un système peut très bien marcher au début et devenir pénible quelques mois plus tard.
Pas forcément parce qu’il est mal codé.
Souvent parce que les vraies difficultés arrivent après :
- les premières pannes
- les premiers pics de charge
- les premiers incidents de production
- les premières évolutions produit qui touchent plusieurs briques en même temps
- les premiers moments où l’équipe n’ose plus modifier le système
À ce stade, la question n’est plus seulement est-ce que ça marche ?.
La vraie question devient :
- est-ce que le système reste correct quand quelque chose casse ?
- est-ce qu’il tient quand la charge augmente ?
- est-ce qu’on peut encore le faire évoluer sans se faire peur ?
C’est là que trois idées deviennent centrales :
- reliability
- scalability
- maintainability
L’idée simple
Un bon système de production n’est pas juste un système fonctionnel.
C’est un système qui tient sur trois axes :
- Reliable : il continue à faire le bon travail malgré les pannes, les bugs et les erreurs humaines.
- Scalable : il reste performant quand la charge monte.
- Maintainable : il reste compréhensible, exploitable et modifiable dans le temps.
Ces trois qualités se renforcent entre elles.
Un système pas maintenable finit souvent par devenir moins fiable.
Un système qui ne scale pas finit par devenir fragile sous charge.
Un système fiable mais impossible à faire évoluer devient vite un frein produit.
Comment ça fonctionne
Reliability
La fiabilité ne veut pas dire qu’il ne se passe jamais rien.
Elle veut dire que le système continue à fonctionner correctement même quand quelque chose tourne mal.
En pratique, les problèmes viennent souvent de trois familles :
-
pannes matérielles
disque qui meurt, machine qui disparaît, réseau qui coupe, instance cloud qui saute -
erreurs logicielles
bug corrélé, hypothèse cachée qui casse, dépendance qui ralentit, cascade d’erreurs -
erreurs humaines
mauvaise configuration, manipulation dangereuse, changement déployé trop vite
L’idée importante ici est simple : on ne construit pas un système sérieux en supposant que rien ne cassera.
On construit un système sérieux en supposant que ça cassera, puis en limitant l’impact.
Scalability
La scalabilité n’est pas une étiquette.
Dire ce système scale ne veut pas dire grand-chose si on ne précise pas :
- quelle charge augmente
- quelles performances doivent rester stables
- quels moyens on est prêt à ajouter
Il faut raisonner avec des paramètres concrets :
- trafic
- volume de données
- ratio lecture / écriture
- temps de réponse
- throughput
- percentiles de latence
Un système devient scalable quand on a une stratégie claire pour garder des performances correctes pendant que la charge augmente.
Ça peut vouloir dire :
- changer l’architecture
- répartir la charge
- déplacer le coût de la lecture vers l’écriture
- ajouter des machines
- revoir le modèle d’accès aux données
La scalabilité n’est jamais générique.
Elle dépend toujours du type de charge réel.
Maintainability
La maintenabilité est souvent sous-estimée au début, alors qu’elle finit par coûter le plus cher.
Un système maintenable est un système sur lequel les équipes peuvent travailler sans s’épuiser.
On peut le lire à travers trois idées :
Operability
Le système doit être exploitable en production.
Il faut pouvoir :
- voir ce qu’il fait
- diagnostiquer un problème
- revenir en arrière
- patcher sans drame
- faire de la maintenance avec un comportement prévisible
Simplicity
Le système doit limiter la complexité accidentelle.
La complexité ralentit :
- la compréhension
- le debug
- la livraison
- les changements
La simplicité ne veut pas dire moins de fonctionnalités.
Elle veut dire moins de couplage inutile, moins d’effets de bord, moins de zones où personne n’ose toucher.
Evolvability
Le système doit bien changer.
Les besoins changent toujours :
- nouvelles features
- nouveaux usages
- nouvelles contraintes
- nouvelles plateformes
- croissance du produit
Un bon système n’est donc pas juste bien conçu pour aujourd’hui.
Il est conçu pour encaisser les changements sans exiger une réécriture complète à chaque virage.
Quand ça devient ton problème
Tu as besoin de ce cadre dès que tu reconnais un ou plusieurs de ces signaux :
- ton système fonctionne, mais seulement tant qu’on n’y touche pas
- la moindre panne prend trop de temps à diagnostiquer
- la charge monte et les temps de réponse deviennent imprévisibles
- l’équipe ajoute des rustines au lieu de faire évoluer proprement
- certaines parties sont devenues intouchables
- les déploiements deviennent stressants
- l’exploitation compense en permanence les limites du logiciel
- vous commencez à confondre “ça tourne” avec “c’est sain”
Autrement dit :
tant que ton projet est petit, tu peux souvent survivre sans nommer ces problèmes.
Dès qu’il y a de la charge, des incidents, plusieurs personnes et des évolutions fréquentes, ces trois axes deviennent structurels.
Exemple concret
Prenons un service web qui démarre simplement :
- une base relationnelle
- une API
- un worker
- un peu de cache
Au début, tout va bien.
Puis arrivent :
- plus de trafic
- plus de données
- plus de jobs asynchrones
- plus de dépendances externes
- plus de personnes dans l’équipe
Le système continue de “marcher”, mais de nouveaux symptômes apparaissent :
- un incident sur une dépendance ralentit tout
- un changement de schéma devient risqué
- une hausse de trafic fait exploser la latence
- certains bugs n’apparaissent qu’en prod
- il faut des connaissances implicites pour redémarrer proprement
À ce moment-là :
- reliability te force à penser tolérance aux fautes
- scalability te force à décrire la charge et les limites
- maintainability te force à réduire la complexité et à rendre l’exploitation viable
Le système n’est plus juste un projet.
Il devient un système de production.
Points importants
- Reliability, scalability et maintainability sont des axes de décision, pas des slogans.
- La fiabilité commence quand on accepte que les pannes, bugs et erreurs humaines vont arriver.
- La scalabilité exige des métriques concrètes, pas des intuitions vagues.
- La maintenabilité est souvent ce qui décide si une architecture reste vivable après quelques mois.
- Un système simple à comprendre change généralement mieux qu’un système compliqué.
- Il n’existe pas d’architecture universellement scalable.
- Scaler trop tôt sur de mauvaises hypothèses peut coûter plus cher qu’attendre le bon signal.
Erreurs fréquentes
Confondre fiabilité et disponibilité
Un service “up” peut quand même renvoyer des résultats faux, incomplets ou incohérents.
Dire “ça scale” sans parler de charge
Sans préciser le trafic, le volume de données, les temps de réponse visés et les accès dominants, ça ne veut rien dire.
Optimiser trop tôt
Construire pour une charge hypothétique peut figer une architecture inutilement complexe.
Sacrifier la maintenabilité pour aller vite
Le gain initial se paie souvent plus tard en lenteur d’équipe, incidents, dette et peur du changement.
Réduire la simplicité à l’UI
La vraie simplicité ici concerne surtout la structure interne du système et sa lisibilité pour les ingénieurs.
Conclusion
Quand un système commence à compter, trois questions deviennent non négociables :
- est-ce qu’il reste correct quand ça casse ?
- est-ce qu’il tient quand la charge monte ?
- est-ce qu’on peut encore le faire évoluer proprement ?
C’est ça, le socle.
Reliable.
Scalable.
Maintainable.
Pas comme vocabulaire de présentation.
Comme critères de survie en production.
Under the Hood
À ouvrir ensuite :
hardware-software-human-faultsload-parameters-and-percentiles