Ce qu'est vraiment la conception système : d'un serveur à des millions d'utilisateurs

Imagine une application de partage de photos : on s'inscrit, on publie des photos, on suit d'autres personnes, on défile un fil d'images. Tu écris le code, tu déploies tout sur un seul serveur et cela marche parfaitement ; une machine suffit pour les premiers milliers d'utilisateurs et tient toutes leurs données. Puis 10 millions de personnes ouvrent l'application chaque jour et, bien que le code de publication change à peine, les problèmes à résoudre deviennent tout autres : où ranger des centaines de téraoctets de photos, que se passe-t-il si le serveur plante, comment garder un fil rapide pour un utilisateur en Inde quand le serveur est aux États-Unis, et que se passe-t-il quand un compte populaire publie une photo qu'un million de personnes veulent voir en même temps. Ce ne sont plus des problèmes d'une seule fonction, mais de la conception d'ensemble et de la coopération de ses parties.

La conception système est le processus qui décide quels composants il faut, qui est responsable de quoi, comment ils communiquent et comment les données circulent entre eux, pour que le système remplisse ses exigences. Elle opère un niveau au-dessus du code : là où le code pense fonctions , classes , structures de données et algorithmes, la conception pense serveurs , bases de données , caches , files, stockage et réseau. Elle intègre aussi le ralentissement ou la panne d'un composant et l'évolution du comportement quand le trafic et les données grandissent.

Besoins : ce qu'il fait, et avec quelle qualité

Toute conception commence par les exigences, car on ne peut juger un dessin sans savoir ce que le système doit faire. Elles forment deux groupes : les exigences fonctionnelles disent ce que le système doit faire, comme publier des photos, suivre des utilisateurs, aimer des billets et voir son fil ; les exigences non fonctionnelles disent avec quelle qualité, comme un fil affiché en moins de 200 millisecondes, une application joignable même si un serveur tombe et des photos téléversées jamais perdues. Les premières décident des fonctionnalités, des API et des composants ; les secondes façonnent leur dessin, la capacité nécessaire et le traitement des pannes. Selon Educative, cette distinction est le plan de toutes les décisions d'architecture ultérieures : une application pour cent utilisateurs peut partager chaque fonctionnalité avec celle qui en sert cent millions tout en étant conçue tout autrement.

La plupart des grands systèmes naissent d'un petit ensemble de briques communes. Les clients comme les applis mobiles et les navigateurs envoient les requêtes, le DNS traduit le nom de domaine en adresse de serveur, le répartiteur de charge distribue le trafic entre serveurs applicatifs qui exécutent la logique métier. Les bases gardent les données structurées comme utilisateurs, abonnements et métadonnées des photos, tandis que le stockage objet garde les photos elles-mêmes ; le cache tient les lectures fréquentes en mémoire pour soulager la base, le CDN rapproche les copies du contenu statique des utilisateurs et les files de messages basculent le travail non urgent en arrière-plan pour ne jamais faire attendre. Une grande part du métier est de choisir les briques utiles et leur coopération. La carte des briques de Mehdi Akiki propose de lire chaque brique en quatre questions : ce qu'elle est, pourquoi elle existe, quand elle apparaît et ce qui casse en cas d'abus ; le cache existe parce que les lectures répétées coûtent cher, la file parce que tout ne doit pas passer par le chemin de requête, le CDN parce que les utilisateurs sont loin des serveurs.

De bout en bout : le voyage d'une photo

Regardons ces pièces assemblées dans l'application. Quand un utilisateur publie une photo, la requête traverse le répartiteur vers l'un des serveurs applicatifs ; le serveur écrit en base les métadonnées comme auteur, légende et horodatage, puis produit une adresse présignée qui autorise l'appli à téléverser l'image directement vers le stockage objet. Le téléversement terminé, le système dépose un travail dans une file pour le traitement complémentaire, et des tâches de fond s'en chargent, comme générer les miniatures ou mettre à jour les fils des abonnés. Le cours de CodeSnatch sur le stockage objet et les CDN confirme ce modèle : selon CodeSnatch, les bases sont le mauvais domicile des gros fichiers non structurés, les magasins de type S3 offrent un espace bon marché et sans limite avec onze neuf de durabilité, et les adresses présignées laissent le client écrire droit au stockage.

La lecture emploie les mêmes boîtes autrement. Quand un autre utilisateur ouvre son fil, le serveur applicatif consulte d'abord le cache pour la liste des billets ; si elle manque, il lit la base et garde le résultat en cache pour les requêtes suivantes. Les images elles-mêmes viennent par le CDN, depuis un serveur proche du lieu de l'utilisateur au lieu du dépôt d'origine à chaque fois. Chaque composant a sa raison : le CDN réduit la latence, la file écarte le lent du chemin de requête, le cache allège la base et le stockage objet offre une place qui grandit pour les gros fichiers.

Qualités et arbitrages

Pour juger un dessin, on regarde des qualités connues : l' extensibilité , absorber plus d'utilisateurs, de trafic et de données quand la demande croît ; la disponibilité , rester joignable quand il le faut même si des composants tombent ; la fiabilité , se comporter correctement sans perdre, dupliquer ni corrompre de données ; la performance , mesurée en latence, la durée d'une requête, et en débit, les requêtes traitées sur une période ; la cohérence , voir tous la même vue à jour des données ; la maintenabilité , exploiter, déboguer, mettre à jour et étendre sans peine ; et enfin le coût , car un bon dessin remplit ses exigences sans dépenser plus de serveurs, de stockage, de bande ni d'effort qu'il ne faut.

Améliorer l'une de ces qualités se paie souvent ailleurs. Ajouter un cache soulage la base et accélère nettement les lectures, mais les données en cache peuvent se périmer et rester dépassées jusqu'au rafraîchissement ou à l'expiration. Plus de répliques et de redondance peut lever performance et disponibilité, mais augmente le coût et complique l'exploitation. Il n'existe guère de dessin meilleur en tout ; une grande part du métier est de comprendre ces arbitrages , de décider quelles qualités comptent pour ses exigences et de savoir expliquer pourquoi telle approche l'emporte sur telle autre.

Petit départ, croissance aux goulets, récit en entretien

Les vrais systèmes naissent rarement dans leur forme finale. L'appli photo peut démarrer avec un seul serveur applicatif et une seule base, largement assez pour les premiers milliers d'utilisateurs. Quand l'usage croît, des goulets distincts apparaissent : la base sature, servir les images ralentit, le travail de fond retarde les requêtes ; c'est alors qu'on ajoute le composant qui résout le problème précis, cache, CDN, répliques de lecture ou file. Tout ajouter trop tôt crée surtout de la complexité, du débogage et du coût sans grande valeur. Un bon dessin remplit les exigences du jour tout en gardant la place pour l'échelle de demain.

Quiconque travaille sur le dorsal prend sans cesse des décisions de conception, même sur de petites fonctions. Prenons le bouton d'appréciation : faut-il mettre le compteur en cache, la mise à jour doit-elle passer en synchrone dans la requête ou partir en file pour un traitement de fond, et que se passe-t-il si le trafic explose parce qu'une célébrité attire des millions d'interactions. Connaître la conception aide à raisonner sur ces choix, à voir les arbitrages et à expliquer pourquoi une approche a plus de sens qu'une autre.

La conception pèse aussi lourd dans les entretiens d'embauche. Dans beaucoup d'entreprises technologiques, un tour de conception système est standard pour les ingénieurs confirmés et seniors, et certaines proposent une version simplifiée aux moins expérimentés. La performance peut influer sur le niveau d'embauche, donc directement sur la paie. Le format est en général ouvert : environ 45 minutes à une heure pour traiter un sujet comme un raccourcisseur d'adresses, une messagerie ou une appli photo comme celle de la vidéo ; il n'y a pas de réponse unique et on n'attend pas de code qui passe des tests. On suit plutôt un processus proche de la vidéo : clarifier les besoins, estimer l'échelle, esquisser un dessin de haut niveau, puis creuser quelques zones clés comme la base, la mise en cache, les flux de données et la gestion des pannes, en expliquant décisions et arbitrages au fil. Le guide 2026 de TryExponent note que le tour se gagne désormais sur le coût, les modes de panne et le jugement d'exploitation ; le cadre en sept étapes d'InterviewLoop recommande le même ordre : clarifier, estimer, dessiner, creuser, expliquer les arbitrages. La leçon commune : inutile de mémoriser les dessins courants, car qui comprend les briques de base, les problèmes qu'elles résolvent et les coûts qu'elles apportent peut raisonner sur des systèmes jamais vus.