Faire passer un SaaS à l'échelle après le lancement sans casser le produit

Tout le monde célèbre le lancement. Presque personne ne vous prévient de ce qui vient après — cette année étrange, où l'on serre les dents, où le produit qui vous a apporté vos cent premiers clients commence à plier sous le poids des mille suivants. Rien de dramatique ne se produit. Les choses deviennent simplement plus lentes, plus instables, plus difficiles à modifier. Un mardi, vous réalisez qu'une fonctionnalité qui prenait un jour en prend désormais une semaine, et personne ne sait vraiment pourquoi. C'est là, et non au lancement, que la plupart des produits SaaS se gagnent ou se perdent en silence.

Nous nous sommes assis avec beaucoup de fondateurs précisément à ce moment. Ils n'échouent pas — c'est ce qui est déroutant. Le chiffre d'affaires monte, l'équipe grandit, les démos se passent bien. Mais en dessous, le produit gémit. Les tickets de support montent plus vite que les utilisateurs. Les déploiements qui étaient autrefois ennuyeux s'accompagnent désormais d'un souffle retenu. La base de code qui semblait astucieuse il y a un an ressemble maintenant à un champ de mines où chaque modification risque d'en déclencher une autre. Ils n'ont rien fait de mal. Ils ont simplement dépassé ce qu'ils avaient bâti, et personne ne leur avait dit que c'était censé arriver.

Voici donc le guide que nous aurions aimé que davantage de fondateurs aient avant l'apparition des fissures. Il ne s'agit pas d'hyperscale, de Kubernetes, ni de ce qu'une licorne a fait à cinquante millions d'utilisateurs. Il s'agit du milieu ennuyeux et décisif — passer de ça marche pour quelques-uns à ça marche pour beaucoup — sans tout réécrire, sans effrayer vos clients ni épuiser votre équipe. L'objectif n'est pas une architecture parfaite. C'est un produit qui continue de grandir au lieu de commencer à casser en silence.

Ce qui casse vraiment quand un SaaS grandit

Voici la partie qui surprend le plus les fondateurs : les problèmes de montée en charge n'arrivent presque jamais sous la forme de la panne dramatique que l'on redoute. Le serveur ne prend pas feu. Au lieu de cela, le produit développe une sorte de fièvre persistante de bas niveau. Des pages qui se chargeaient instantanément mettent soudain trois secondes. Un rapport qui tournait bien pour les premiers clients tombe en timeout pour le gros client qui vient de signer. Le même bug réapparaît sans cesse parce que deux parties du code dépendent secrètement l'une de l'autre d'une façon que personne n'a documentée.

Ce qui casse vraiment, ce sont rarement vos serveurs — ce sont vos hypothèses. Au début, vous avez bâti pour la forme de vos premiers utilisateurs : quelques comptes, peu de données, des flux simples, tout le monde à peu près identique. La croissance n'ajoute pas seulement plus de la même chose. Elle ajoute de la variété. Un client avec dix fois plus de données. Une équipe qui utilise une fonctionnalité d'une manière que vous n'aviez jamais imaginée. Un pic à neuf heures le lundi, quand tout le monde se connecte en même temps. Chacun viole en silence une hypothèse coulée dans votre code il y a un an, quand la violer était impensable.

Les quatre endroits où cela tend à se manifester d'abord sont prévisibles. La base de données est presque toujours le canari — des requêtes instantanées sur de petites tables se traînent à mesure que les données grossissent. Le point d'accès lent : une ou deux pages qui font trop de travail par requête, sans souci jusqu'à ce que le trafic s'accumule. Le déploiement fragile, où livrer quoi que ce soit est devenu effrayant parce que le code est trop emmêlé pour qu'on puisse le raisonner. Et la charge de support, qui n'est pas du tout de l'infrastructure mais qui est le signal précoce le plus fidèle que le produit ne correspond plus à la façon dont les gens l'utilisent réellement.

Le piège de résoudre des problèmes que vous n'avez pas encore

Avant de parler de corriger les choses, un avertissement qui a sauvé plus de produits que n'importe quelle optimisation. La plus grande menace pour un SaaS en croissance n'est pas d'ignorer l'échelle — c'est de la poursuivre trop tôt. Dès qu'un fondateur ressent le premier ralentissement, l'instinct est de saisir l'architecture lue sur un célèbre blog d'ingénierie. Microservices. Une file de messages. Une configuration multirégion. Sharder la base de données avant qu'elle n'ait un million de lignes.

C'est ainsi que l'on passe six mois et une fortune à bâtir une infrastructure pour une échelle que l'on n'a pas atteinte, pendant que le produit réel cesse d'avancer. Pire, vous avez désormais rendu chaque modification future plus difficile, car un système distribué est nettement plus complexe à bâtir et à déboguer que le système simple que vous aviez. Vous avez échangé un problème que vous n'aviez pas encore contre un problème garanti que vous avez aujourd'hui : plus rien ne sort.

La discipline ici est la même que celle qui fait les bons produits au départ : résolvez le problème qui est devant vous, pas celui que vous êtes flatté d'imaginer. Un monolithe ennuyeux et bien compris que vous pouvez modifier vite passera mieux à l'échelle qu'un système distribué à la mode que vous avez peur de toucher. La complexité est un coût que vous payez chaque jour, pas un achat unique.

Mesurez avant de changer quoi que ce soit

Presque tous les fondateurs que nous rencontrons à ce stade sont convaincus de savoir où est le problème. Ils se trompent une fois sur deux — non par négligence, mais parce que l'intuition est un piètre profileur. La partie du code qui semble lente est souvent correcte ; le vrai coupable est une requête silencieuse qui s'exécute quarante fois sur une page à laquelle personne n'a pensé. On ne peut pas corriger ce qu'on n'a pas mesuré, et deviner ici, c'est ainsi que les équipes passent des semaines à optimiser la mauvaise chose.

Vous n'avez pas besoin d'une pile d'observabilité sophistiquée pour démarrer. Vous avez besoin de trois chiffres ennuyeux sous les yeux, en permanence. Quels points d'accès sont les plus lents, et à quel point sous trafic réel. Quelles requêtes de base de données consomment le plus de temps total — non pas la requête individuelle la plus lente, mais celle dont le temps s'additionne sur des milliers d'appels. Et où les erreurs surviennent réellement, avec assez de contexte pour les reproduire. Avec ces trois-là, le brouillard se dissipe généralement en une journée.

1. 1
   Activez la supervision de base

   Temps de réponse par point d'accès, taux d'erreur et journalisation des requêtes lentes sur la base de données. Les outils hébergés font cela en un après-midi. On ne peut pas améliorer un chiffre qu'on ne voit pas.
2. 2
   Trouvez le vrai trio de tête

   Triez par temps total consommé, pas au feeling. Trois coupables concentrent presque toujours l'essentiel de la douleur. Notez-les — c'est votre véritable feuille de route.
3. 3
   Corrigez-en un, remesurez

   Changez une seule chose, puis revérifiez les chiffres. Confirmez que cela a aidé avant de continuer. Deux changements à la fois et vous ne saurez jamais lequel comptait.
4. 4
   Arrêtez quand c'est assez bon

   Définissez 'assez rapide' avant de commencer — disons, chaque page sous une seconde à la charge actuelle. Au-delà, optimiser est un gouffre de temps, pas une victoire.

Cette dernière étape compte plus qu'il n'y paraît. Le travail de performance est véritablement addictif ; il y a toujours une milliseconde de plus à rogner. Mais vos clients ne sentent pas la différence entre 200 ms et 120 ms, et les heures passées à la poursuivre sont des heures non consacrées à la fonctionnalité qui ferait réellement croître l'entreprise. Mesurez, corrigez le trio de tête, déclarez la victoire, passez à autre chose.

La base de données est presque toujours le premier mur

Si nous devions parier de l'argent sur l'endroit où un SaaS en croissance heurte son premier vrai plafond, nous parierions à chaque fois sur la base de données. C'est la partie du système où les petites décisions précoces se cumulent le plus durement. Une requête sans index s'exécute en un clin d'œil sur mille lignes et s'enraye sur un million. Le code n'a pas changé. Les données, si — et les données ne font que croître.

La bonne nouvelle, c'est que la base de données est aussi là où vivent les corrections les moins chères et les plus impactantes. La classique est l'index manquant : une seule ligne qui transforme une requête de plusieurs secondes en une requête instantanée, parce que la base de données cesse de scanner chaque ligne pour trouver les quelques-unes dont elle a besoin. Juste derrière vient le problème de requêtes N+1 — une page qui, au lieu de poser une question, pose en silence la même petite question à la base de données des centaines de fois dans une boucle. Les deux sont courants, les deux sont invisibles tant qu'on ne regarde pas, et les deux se corrigent généralement en une journée une fois qu'on les a trouvés.

Il y a ici une séquence sur laquelle s'appuyer, et il vaut la peine de la suivre dans l'ordre plutôt que de sauter à la fin. Corrigez d'abord les requêtes — index, N+1, le rapport lent. Ajoutez ensuite du cache pour les données lues en permanence mais rarement modifiées. Ce n'est qu'après que cela a du sens de parler de répliques en lecture, d'instances plus grandes ou de séparer les données. La plupart des produits SaaS n'ont jamais besoin des étapes ultérieures. Il leur fallait juste que les premières soient faites correctement.

Faire évoluer le produit, c'est faire évoluer la façon dont vous le modifiez

Voici le basculement qui prend les fondateurs de court : passé un certain point, la montée en charge cesse de porter sur le produit qui encaisse plus d'utilisateurs et commence à porter sur votre équipe qui encaisse plus de changement. Quand c'était vous et un développeur, chacun avait le système entier en tête. Vous pouviez tout changer parce que vous saviez ce que cela toucherait. À cinq ou dix personnes, ce modèle mental vole en éclats — et le code qui supposait que tout le monde savait tout devient un fardeau.

C'est la vraie raison pour laquelle les déploiements deviennent effrayants. Ce n'est pas que le code a empiré du jour au lendemain ; c'est que plus personne ne peut prédire pleinement le rayon d'impact d'un changement. La solution n'est ni l'héroïsme ni un gel des livraisons. C'est d'investir dans l'échafaudage peu glamour qui permet à une équipe plus grande d'avancer sans se marcher dessus : une suite de tests automatisés qui attrape la casse évidente, des déploiements qui sont une routine plutôt qu'une cérémonie, et un moyen de désactiver une mauvaise version en quelques secondes au lieu de paniquer.

• Une suite de tests couvrant la poignée de flux dont la rupture serait catastrophique — connexion, paiement, action principale. Pas tout ; les rares critiques.
• Des déploiements qui tournent sur un bouton, pas un rituel, pour que livrer petit et souvent devienne sûr au lieu d'angoissant.
• Un moyen rapide de revenir en arrière, pour qu'une mauvaise version soit un événement de cinq minutes, pas un incident de toute la nuit.
• Des feature flags, pour pouvoir livrer du code à quelques clients d'abord et le désactiver instantanément s'il se comporte mal.
• Assez de documentation pour que les vacances d'une personne ne gèlent pas tout un pan du produit.

Rien de tout cela n'apparaît dans une démo. Rien de tout cela n'ajoute directement une fonctionnalité. Et c'est exactement le travail qui sépare un produit qui continue d'accélérer d'un produit qui ralentit à chaque nouvelle embauche. Les équipes qui passent bien à l'échelle sont celles qui traitent leur capacité à modifier le produit en toute sécurité comme une fonctionnalité à part entière — car à l'échelle, c'est précisément ce qu'elle est.

Une brève histoire depuis le point de rupture

Pour rendre cela concret, voici un composite tiré de travaux que nous avons menés — détails flous, forme fidèle à la réalité. Un petit SaaS de gestion d'équipes d'intervention sur le terrain avait bien démarré et grandi jusqu'à quelques centaines d'entreprises payantes. Les fondateurs étaient ravis et épuisés à parts égales. Puis leur plus gros client à ce jour a signé : une société avec plus d'utilisateurs et plus de données historiques que leurs dix clients précédents réunis.

En une semaine, le tableau de bord où tout le monde vivait s'était ralenti jusqu'à se traîner pour ce client — et, curieusement, pour tous les autres aussi. Les tickets de support ont bondi. Les fondateurs ont supposé qu'il leur fallait un serveur bien plus gros et se préparaient à une ré-architecture douloureuse et coûteuse. C'est à ce moment qu'on nous a fait intervenir, et l'instinct était compréhensible mais erroné.

Nous n'avons pas touché à l'architecture. Nous avons activé la journalisation des requêtes lentes et observé pendant un après-midi. Le coupable était presque gênant de petitesse : le tableau de bord principal chargeait la liste des missions de chaque utilisateur avec un schéma N+1 classique, en tirant une requête par mission. Pour un petit client, cela faisait quelques dizaines de requêtes inoffensives. Pour le nouveau géant, cela faisait des milliers par chargement de page — ce qui, sur une infrastructure partagée, tirait tout le système vers le bas pour tout le monde.

La leçon que les fondateurs en ont tirée n'était pas technique. C'était que l'effrayant problème de montée en charge qu'ils avaient imaginé — celui qui exigeait une reconstruction et une levée de fonds — était, une fois mesuré, une correction de deux jours cachée derrière un symptôme inquiétant. Ils s'apprêtaient à passer des mois à résoudre le mauvais problème. Cet écart, entre la crise imaginée et la crise mesurée, c'est là que l'essentiel de l'argent de la montée en charge se gaspille.

Quand il est vraiment temps de reconstruire un morceau

Toute cette prudence face à la montée en charge prématurée peut se lire comme ne jamais refactoriser, ne jamais reconstruire. Ce n'est pas cela. Parfois, une partie du produit a vraiment atteint la fin de sa vie, et la rapiécer encore est le choix coûteux. L'astuce est de distinguer une véritable limite structurelle des douleurs de croissance ordinaires qu'une correction mesurée réglerait.

Le signal honnête est celui-ci : reconstruisez un composant lorsque le coût de le modifier est devenu durablement supérieur au coût de le remplacer. Pas quand il est laid — du code laid qui est stable et rarement touché est très bien. Vous cherchez une partie du système où chaque changement est lent et risqué, où les mêmes bugs reviennent sans cesse, où les nouveaux développeurs ne peuvent pas travailler en sécurité, et où vous avez déjà essayé les corrections moins chères et heurté un mur. Quand plusieurs de ces conditions sont vraies en même temps, une réécriture ciblée de ce seul morceau est le bon choix.

Et quand vous reconstruisez, reconstruisez un morceau — pas le produit. La réécriture complète à partir de zéro est le chant des sirènes de la montée en charge, ce qui semble propre et finit par engloutir une année pendant que les concurrents livrent. Remplacez le seul composant pourri, derrière une frontière nette, pendant que le reste du produit continue de tourner et de rapporter. Chirurgical, pas héroïque.

Questions fréquentes