Ce que veut dire 'scalable' : les axes qui comptent (latence, débit, données, concurrence)
'Scalable' est utilisé comme un adjectif magique. En pratique, c'est une combinaison de quatre axes indépendants — et la plupart des produits n'ont besoin de travailler sérieusement que sur un ou deux d'entre eux.
"Scalable" n'est pas un interrupteur, c'est quatre axes distincts
"Il faut que ce soit scalable" est l'une des phrases les plus répétées et les moins définies de l'univers produit. En pratique, la scalabilité d'un système se décompose sur quatre axes qui n'évoluent pas ensemble : la latence (le temps de réponse par requête), le débit (le nombre de requêtes traitées simultanément), le volume de données (ce que la base doit stocker et interroger efficacement), et la concurrence (le nombre d'acteurs qui modifient le même état en même temps).
Un produit peut être solide sur trois axes et fragile sur le quatrième. Un outil de reporting qui traite un gros volume de données mais peu de concurrence n'a pas les mêmes contraintes qu'une plateforme de réservation où plusieurs utilisateurs se disputent la même ressource en temps réel.
L'erreur classique : optimiser l'axe qui ne sera jamais le problème
La sur-ingénierie de départ suit toujours le même schéma : construire une architecture pensée pour un débit massif sur un produit qui n'a encore aucun utilisateur. Le résultat est un budget de développement gonflé pour une contrainte hypothétique, pendant que l'axe qui posera réellement problème — souvent la concurrence sur une ressource partagée, ou la structure des données — n'a reçu aucune attention.
La plupart des produits n'ont jamais de problème de débit brut. Une architecture standard, bien construite, absorbe une croissance linéaire sans drame. Le vrai risque de scalabilité vient presque toujours d'un axe qu'on n'avait pas identifié comme prioritaire.
Ce qui rend un produit capable de grandir sans rupture
Une séparation claire des responsabilités. Un système où la logique métier, l'accès aux données et l'interface sont découplés permet de faire évoluer un axe (par exemple la structure de la base de données) sans casser les autres.
Un modèle de données pensé pour l'usage réel, pas pour la V1. La façon dont les données sont organisées dès le début a des conséquences qui se paient bien plus tard — c'est une des rares décisions qui coûte cher à revenir dessus après coup.
Des choix réversibles. Privilégier des standards largement adoptés plutôt que des architectures exotiques garantit qu'un autre développeur pourra reprendre et faire évoluer le produit si besoin. La réversibilité n'est pas un supplément de confort, c'est ce qui évite qu'un mauvais pari technique devienne définitif.
Le bon niveau d'ambition pour un lancement
Sur une V1, je ne construis jamais pour l'axe qu'on n'a pas encore identifié comme réel. Je construis une architecture propre, avec des technologies éprouvées, sans sur-ingénierie sur des contraintes hypothétiques — mais en gardant explicitement identifiés les points du système qui devront évoluer si un axe précis devient critique. Ce n'est pas du pragmatisme paresseux : c'est la reconnaissance que la scalabilité n'est jamais générique, elle est toujours spécifique à l'axe qui finira par poser problème.
Ne vous laissez pas impressionner par le mot lui-même. Ce qui compte, c'est de savoir lequel des quatre axes votre produit va réellement rencontrer en premier — et de garder la possibilité d'y répondre sans tout reconstruire.