Que signifie la scalabilité lors du développement d'une application ?

Parfois, ce moment arrive furtivement : l'application semble « un peu » plus lente, les tickets de support s'accumulent et les jours de sortie deviennent nerveux.

Et parfois, il arrive comme un coup. Une campagne décolle, une mention dans la presse provoque un pic, ou votre projet Purpose est partagé dans une newsletter. De 500 utilisateurs quotidiens, on passe à 50 000 - non pas en un an, mais en un week-end.

Dans nos projets, nous voyons que : La scalabilité n'est rarement importante par amour de la technologie, mais par amour de la confiance. Car si une application vacille sous la charge, ce n'est pas seulement « une erreur » qui se produit. Quelque chose se passe dans les esprits : les gens abandonnent, les évaluations basculent, les équipes tombent en mode crise.

L'attente est brutalement honnête. Même avec les expériences web mobiles, on voit à quel point la patience est faible : plus de 53 pour cent quittent une page si elle met plus de trois secondes à se charger. Marketing Dive (Google-étude, 2016)

Même si les applications ne sont pas exactement les mêmes que les sites web - la logique émotionnelle est la même : « Si cela ne fonctionne pas immédiatement, ce n'est pas fiable. »

Notre première nouvelle perspective : La scalabilité est aussi une sécurité d'impact. Si vous construisez une application éducative qui doit atteindre plus de personnes, ou une plateforme qui démarre des dons, alors la stabilité n'est pas seulement une question technique. C'est une partie de votre responsabilité : votre mission ne doit pas échouer à cause d'un point d'accès surchargé.

C'est pourquoi nous commençons tôt chez Pola avec une question simple mais cruciale : À quoi votre application doit-elle être préparée – à une croissance planifiable, à des pics imprévisibles ou aux deux ? Cette distinction détermine plus tard si vous priorisez la capacité, l'élasticité ou la robustesse.

Quand quelqu'un dit « Nous devons construire l'application scalabile », il ou elle veut souvent dire seulement : « Plus d'utilisateurs devraient pouvoir accéder simultanément. » C'est important – mais ce n'est que la moitié de l'histoire.

La scalabilité a deux axes de croissance :

Premièrement : Croissance de la charge. Plus de requêtes simultanées, plus de trafic de données, plus d'appareils, plus de tâches secondaires de votre système (Push, Sync, Uploads). Le marché des applications continue de croître et avec lui l'attente que tout fonctionne simplement. La simple densité montre la pression : en 2023, il y avait plus de 3,7 millions d'applications sur le Google Play Store et environ 1,8 million sur l'Apple App Store. Selleo

Deuxièmement : Croissance des fonctionnalités. Nouvelles fonctionnalités, nouveaux rôles, nouvelles intégrations, nouveaux marchés. Une application qui a commencé avec 5 écrans devient au fil du temps un produit avec des règles, des cas particuliers et des exceptions. Et c'est précisément là que tout bascule : pas parce que le CPU est faible, mais parce que chaque changement devient soudainement risqué.

Il est important de faire la distinction : La scalabilité n'est pas la même chose que la performance. La performance décrit la rapidité avec laquelle quelque chose se produit à une charge donnée. La scalabilité décrit comment l'application maintient sa performance lorsque la charge augmente.

Une image du quotidien que nous aimons utiliser : La performance, c'est la vitesse d'un train en voie libre. La scalabilité, c'est si le calendrier reste en place même si trois fois plus de personnes montent à bord – sans que les portes ne se bloquent, que les signaux ne tombent ou que l'ensemble de l'exploitation ne s'arrête.

Notre deuxième perspective nouvelle : La scalabilité est une architecture conviviale pour les équipes. En pratique, non seulement l'application grandit, mais aussi l'équipe qui y travaille. Si plusieurs développeurs doivent livrer en parallèle, vous avez besoin de structures qui découplent les changements. Une « application scalabile » signifie donc également : bien testable, modulaire, compréhensible.

Si vous nommez ces deux axes tôt, les décisions deviennent plus faciles : certains projets ont besoin d'abord de réserves de charge, d'autres d'une base propre pour la croissance des fonctionnalités. Et c'est souvent un mélange – mais avec un poids clair.

Quand les applications se cassent sous la charge, cela ressemble souvent à un seul problème : « Serveur surchargé ». En réalité, c'est presque toujours une chaîne de goulets d'étranglement.

La base de données est typique. Au début, elle est pratique : un endroit central, tout est cohérent, tout est traçable. Puis vient le moment où une recherche unique fonctionne soudainement mille fois plus souvent. Ou un verrou bloque l'accès en écriture. Ou un index mal choisi transforme une recherche en une exploration de texte intégral.

Tout aussi souvent, c'est le code. Pas « programmé trop lentement », mais trop étroitement couplé. Une fonction en appelle trois autres, attend une API externe et écrit des journaux synchrones au passage. Cela fonctionne avec 50 utilisateurs. Avec 5 000, cela devient un effet domino.

Et puis il y a le goulot d'étranglement sur lequel personne ne parle en premier : les processus et les livraisons. Si un correctif rapide ne peut être appliqué que la nuit, si les déploiements font peur, si personne ne sait exactement ce qu'il faut surveiller après le lancement - alors ce n'est pas le système qui évolue, mais le niveau de stress.

Notre troisième perspective nouvelle : La scalabilité est amicale aux incidents. Nous construisons non seulement pour « plus », mais pour « si quelque chose se passe mal ». C'est une différence silencieuse : une application robuste a des limites claires, des délais d'attente clairs, des solutions de secours claires. Et elle aide l'équipe à comprendre rapidement ce qui se passe.

En pratique, nous aimons adopter pour cela un petit principe que vous pouvez immédiatement emporter : « Faites ce qui est critique court. » Tout ce qui est votre moment critique (inscription, paiement, don) devrait avoir le moins de dépendances possible. Si vous souhaitez envoyer des courriels, générer des PDF ou mettre à jour des statistiques par la suite, faites-le de manière asynchrone.

Cela montre également pourquoi tant de pannes sont coûteuses : le temps d'arrêt n'est pas seulement un état technique, c'est un dommage commercial. Atlassian cite des exemples où des pannes ont causé des dommages de plusieurs millions dans des grandes entreprises. Atlassian

Vous n'avez pas besoin d'être Facebook pour ressentir cet effet. Les produits plus petits n'ont juste moins de marge.

Quand nous parlons de scalabilité, nous arrivons rapidement à deux modèles de base : vertical et horizontal.

Vertical signifie : Vous donnez plus de puissance à un système. Plus de CPU, plus de RAM, une configuration de base de données plus grande. C'est souvent le premier pas, car il fonctionne rapidement et nécessite peu de réaménagement. Mais la scalabilité verticale a des limites : cela devient très coûteux à terme, et vous avez toujours un point central qui peut tomber en panne.

Horizontal signifie : Vous répartissez la charge sur plusieurs instances. Pas un serveur plus fort, mais plusieurs – idéalement de sorte que vous puissiez augmenter automatiquement lors de pics et diminuer lors des temps d'accalmie.

Pour que l'horizontale fonctionne, vous avez souvent besoin de deux choses : un équilibreur de charge (qui répartit le trafic) et des services qui sont stateless. Cela peut sembler technique, mais c'est facile à comprendre : si une connexion utilisateur ne fonctionne que sur le serveur A parce que la session s'y trouve, alors le serveur B n'est d'aucune aide. Si l'état est au contraire dans un stockage commun (par exemple dans une base de données ou un cache comme Redis), n'importe quelle instance peut intervenir.

En pratique, la scalabilité est souvent un mélange : un peu vertical pour souffler rapidement, et ciblé horizontal là où cela compte vraiment.

Ce que nous prenons toujours en compte : La fiabilité est une sœur de la scalabilité. Dès que vous travaillez horizontalement, vous intégrez souvent automatiquement la redondance. Si une instance tombe, d'autres prennent le relais. Ce n'est pas seulement « plus de performance », mais moins de risque.

Et c'est là qu'intervient notre perspective Pola : Nous n'aimons pas le « rendement maximal continu ». Cela devient durable quand votre système est élastique. Des ressources supplémentaires seulement lorsque nécessaires. Cela économise des coûts et évite une consommation énergétique inutile - le côté technique d'une attitude : ne pas gâcher.

Si vous êtes au début, la décision la plus importante n'est donc pas « Kubernetes ou non », mais : Votre application peut-elle fondamentalement supporter plusieurs instances ? Si vous préparez cela correctement, de nombreux chemins restent ouverts.

La question architecturale est souvent menée de manière inutilement idéologique : monolithe mauvais, microservices bons. Nous voyons cela différemment. Pour de nombreux produits, un monolithe bien construit est le bon choix au début : plus rapide à mettre en œuvre, plus facile à tester, plus facile à comprendre.

Le problème n'est pas souvent le monolithe en soi, mais un monolithe sans frontières. Si tout connaît tout, chaque changement devient coûteux.

C'est pourquoi nous aimons utiliser une deuxième méthode éprouvée : « Découpez selon la responsabilité, pas selon la technologie. » Cela signifie concrètement : nous structurons tôt selon les domaines fonctionnels, de sorte que vous puissiez plus tard extraire des parties sans déchirer l'ensemble du produit.

Un chemin typique ressemble à ceci :

• Démarrage en tant que monolithe modulaire avec des domaines clairs (par exemple, comptes, contenus, paiements).
• Quand un domaine croît fortement ou a des exigences particulières, il est externalisé en tant que service.
• Ce n'est que lorsque les équipes et l'exploitation en tirent réellement profit que plusieurs services autonomes émergent.

Pourquoi cet ordre ? Parce que les microservices vous permettent de fonctionner indépendamment, mais apportent de nouvelles tâches : communication réseau, débogage distribué, versionnement, observabilité. Cela en vaut la peine lorsqu'une certaine complexité est déjà présente – pas pour « acheter » de la complexité.

Cet avertissement est également valable dans le contexte des startups : il existe des indices selon lesquels une grande partie des échecs des startups est liée à une expansion prématurée – souvent organisationnelle et stratégique, mais cette idée peut être transposée. Publication LinkedIn (Chiffre Startup Genome, répandu)

Notre position à ce sujet : Planifiez la porte, ne construisez pas toute la maison tout de suite. Une application peut commencer comme un MVP. Mais elle doit être construite de sorte que vous n'ayez pas à tout recommencer à chaque étape de croissance.

Si vous souhaitez approfondir ces décisions : Nous avons accompagné des questions architecturales similaires dans des projets d'application, notamment là où de nouvelles fonctionnalités et groupes d'utilisateurs ont été ajoutés par la suite (par exemple, Ureka ou Aeri). Le contexte est chaque fois différent – le principe reste le même : la clarté avant la taille.