Entretien de System Design : méthode, arbitrages et pièges à éviter

Table des matières

TL;DR

Pour réussir un entretien de System Design :

Commencez par reformuler le besoin et rendre visibles les contraintes.
Posez des questions sur la charge, les données, la disponibilité, la sécurité, le coût et les compétences de l’équipe.
Dessinez d’abord une architecture globale, ou high-level design, avant de zoomer sur une brique.
Présentez des catégories de composants avant de citer des produits précis.
Justifiez chaque choix avec des critères mesurables plutôt qu’avec vos préférences techniques.
Considérez l’exercice comme une discussion, pas comme une soutenance figée de « votre » solution.
N’oubliez jamais l’observabilité, la sécurité, l’exploitation et la gestion du temps.

L’objectif n’est pas de produire l’unique architecture correcte. Il est de rendre votre raisonnement compréhensible, de montrer vos arbitrages et de faire évoluer votre proposition lorsque de nouvelles contraintes apparaissent.

La vidéo de référence

Cette synthèse s’appuie sur le retour d’expérience présenté par xavki dans la vidéo « REX : L'interview de System Design », publiée le 27 juillet 2026. L’épisode ne résout pas un exercice particulier de bout en bout. Il analyse plutôt la posture et la méthode attendues pendant ce type d’entretien.

Le message central est simple : connaître des outils ne suffit pas. Le candidat doit comprendre le problème de l’entreprise, obtenir les informations manquantes, expliciter son raisonnement et défendre des décisions adaptées au contexte.

Un entretien de System Design, c’est quoi exactement ?

Un entretien de System Design demande de concevoir, à partir d’un besoin souvent volontairement incomplet, un système capable de satisfaire des contraintes fonctionnelles et non fonctionnelles. L’exercice peut être orienté développement, infrastructure, plateforme ou mêler ces disciplines.

Le sujet initial tient parfois en une phrase :

Concevez un raccourcisseur d’URL, une plateforme vidéo, un système de messagerie, une boutique en ligne ou une architecture WordPress capable de monter en charge.

Cette phrase n’est pas un cahier des charges. Elle ouvre une enquête. Le candidat doit découvrir le volume de trafic, les données manipulées, les objectifs de disponibilité, les exigences de sécurité, les contraintes de coût et le contexte de l’équipe avant de proposer une architecture.

L’évaluation porte donc sur plusieurs dimensions :

Dimension	Ce que l’intervieweur peut observer
Compréhension	Capacité à reformuler le problème et à détecter les ambiguïtés
Investigation	Pertinence des questions posées pour obtenir les contraintes manquantes
Architecture	Capacité à décomposer le système en responsabilités cohérentes
Arbitrage	Comparaison des options et justification des décisions
Estimation	Ordres de grandeur sur le trafic, le stockage ou la capacité
Exploitation	Prise en compte des déploiements, incidents, métriques, logs et traces
Communication	Raisonnement à voix haute, écoute et interaction
Adaptation	Réaction face à une erreur ou à une nouvelle contrainte

Le vrai problème : ne pas confondre besoin et technologie

Le piège classique consiste à entendre « application à grande échelle » et à dessiner immédiatement un cluster Kubernetes. Or Kubernetes ne répond qu’à une partie du problème. Il peut contribuer au déploiement, à la résilience des workloads, à l’autoscaling ou à la portabilité de la couche d’exécution, mais il ne définit ni le modèle de données, ni la stratégie de cache, ni la sécurité de bout en bout, ni les objectifs métier.

Une architecture doit partir du besoin :

Quel service rend-on à l’utilisateur ?
Quel niveau de trafic doit-on absorber aujourd’hui et demain ?
Quelles données ne peuvent pas être perdues ?
Quelle indisponibilité est acceptable ?
Quelles compétences l’équipe possède-t-elle déjà ?
Quel budget et quel délai encadrent la solution ?

Le choix technologique vient ensuite. Dire « je choisis Kubernetes parce que j’aime Kubernetes » n’est pas une justification d’ingénierie. Dire « je choisis une plateforme d’orchestration parce que nous devons déployer fréquemment plusieurs services, automatiser leur redémarrage et adapter leur capacité, et parce que l’équipe sait déjà l’exploiter » rend la décision vérifiable.

Étape 1 : clarifier le besoin avant de dessiner

Le premier axe du schéma ssd.png est l’approche. Il recommande d’écrire les besoins, d’identifier les contraintes, de reformuler ce qui a été compris et d’avancer progressivement du high-level design vers les détails d’implémentation.

Écrire les mots-clés visibles par tous

Un tableau blanc partagé, physique ou numérique, sert de mémoire commune. Excalidraw est cité dans la vidéo, mais n’importe quel outil convient si l’intervieweur peut suivre le raisonnement.

Créez dès le départ des zones simples :

besoins fonctionnels ;
contraintes non fonctionnelles ;
hypothèses ;
questions ouvertes ;
architecture globale ;
décisions et alternatives.

Écrire les informations évite de perdre une contrainte annoncée au début de l’échange. Cela montre également que la conception suit une méthode et non une succession d’intuitions.

Reformuler explicitement

Après les premières informations, résumez le problème avec vos propres mots :

Si je reformule, nous devons accepter des créations et des lectures d’URL courtes. Les lectures sont beaucoup plus nombreuses que les écritures. Une redirection doit rester rapide et le service doit continuer à répondre malgré la perte d’une instance. Pour cette première version, la cohérence immédiate des statistiques n’est pas prioritaire. Est-ce correct ?

Cette reformulation donne à l’intervieweur l’occasion de corriger une interprétation avant qu’elle contamine toute l’architecture.

Questions fonctionnelles à poser

Quels parcours utilisateurs doivent être couverts ?
Quelles fonctions sont indispensables dans la première version ?
Quels acteurs ou systèmes externes utilisent le service ?
Quelles opérations modifient les données ?
Quelles opérations peuvent être asynchrones ?
Existe-t-il des règles métier ou réglementaires particulières ?

Questions non fonctionnelles à poser

Combien d’utilisateurs actifs sont attendus ?
Quel est le nombre moyen et maximal de requêtes par seconde ?
Quel est le ratio lecture/écriture ?
Quel volume de données une requête produit-elle ?
Quelle latence cible vise-t-on aux percentiles p50, p95 ou p99 ?
Quel objectif de disponibilité est attendu ?
Quelle durée de conservation s’applique aux données ?
Quelles régions géographiques faut-il servir ?
Quelles exigences de chiffrement, d’authentification ou d’audit s’appliquent ?
Quelles sont les contraintes de coût, de délai et de compétences ?

Découvrez RabbitMQ 000 - Sommaire & Tutoriels

Il n’est pas nécessaire d’obtenir une réponse parfaite à chaque question. Si une donnée manque, formulez une hypothèse, faites-la valider et notez-la.

Étape 2 : construire le high-level design

Une fois le périmètre clarifié, dessinez le trajet complet d’une requête, depuis l’utilisateur jusqu’au stockage ou au système destinataire. Le schéma doit d’abord rester homogène : chaque grande brique est représentée au même niveau de détail.

Pour un service web classique, le premier passage pourrait contenir :

clients web ou mobiles ;
DNS et point d’entrée public ;
CDN, WAF ou load balancer selon le besoin ;
couche applicative ;
cache éventuel ;
base de données ;
stockage d’objets pour les fichiers ;
file ou bus d’événements pour les traitements asynchrones ;
services d’observabilité et d’alerte.

Ce premier dessin doit couvrir l’ensemble du système. Il vaut mieux présenter toutes les responsabilités principales avec une profondeur raisonnable que détailler le partitionnement d’une base pendant vingt minutes en oubliant l’authentification, les fichiers et l’exploitation.

Du global vers le détail

La progression recommandée est la suivante :

présenter le flux de bout en bout ;
vérifier que les principales responsabilités sont couvertes ;
demander quelle zone mérite un approfondissement ;
créer un second schéma pour cette zone ;
détailler ses données, interfaces, pannes et mécanismes de capacité.

Cette séparation entre high-level design et zooms techniques garde le tableau lisible et protège le temps disponible.

Étape 3 : rendre les choix et les arbitrages visibles

Le deuxième axe de ssd.png concerne les choix. Une bonne proposition ne se limite pas à une suite de boîtes reliées par des flèches. Chaque composant représente une décision, et chaque décision doit répondre à un critère.

Présenter d’abord la catégorie, ensuite le produit

Évitez de commencer par :

Ici, je mets Kafka.

Préférez :

Ce traitement n’a pas besoin de bloquer la réponse utilisateur. Je propose donc un mécanisme de messagerie asynchrone afin de découpler les producteurs et les consommateurs, absorber les pointes et permettre les reprises. Kafka, NATS ou RabbitMQ seraient des options à comparer selon le débit, la rétention, le modèle de consommation et les compétences disponibles.

La catégorie décrit la fonction architecturale. Le produit est une implémentation possible.

Besoin	Catégorie de composant	Exemples à évaluer
Répartir les requêtes	Load balancer ou reverse proxy	HAProxy, NGINX, service managé cloud
Réduire la latence de lecture	Cache	Redis, Memcached, cache applicatif
Découpler des traitements	File ou bus d’événements	RabbitMQ, NATS, Kafka
Stocker des objets	Stockage objet	S3 ou implémentation compatible
Exécuter des conteneurs	Orchestrateur ou plateforme managée	Kubernetes, ECS, Cloud Run selon le contexte
Observer un flux distribué	Télémétrie et traçage	OpenTelemetry et backends compatibles

Cette manière de raisonner démontre que l’architecture ne dépend pas d’un logo choisi trop tôt.

Utiliser des critères explicites

Le support et la vidéo mettent notamment en avant :

la latence ;
le débit ;
la disponibilité et la fiabilité ;
la sécurité ;
la fréquence et le mode de déploiement ;
le coût ;
les compétences de l’équipe ;
le volume et la vitesse de croissance des données.

Pour chaque décision importante, une phrase peut suffire :

Je conserve une base relationnelle pour la V1, car les écritures nécessitent des transactions, le volume tient encore sur une instance correctement dimensionnée et l’équipe maîtrise déjà ce moteur. Si le débit d’écriture dépasse cette limite, nous réévaluerons le partitionnement ou un autre modèle de stockage.

Accepter qu’une décision évolue

Une erreur n’est pas nécessairement éliminatoire si le candidat sait reconnaître l’hypothèse incorrecte et propager la correction dans le système.

Une réponse saine ressemble à ceci :

J’avais supposé que les lectures dominaient. Avec ce nouveau ratio d’écritures, le cache apporte moins de bénéfices et le stockage devient le goulot principal. Je vais donc revoir la stratégie de partitionnement et le traitement des écritures.

Le but n’est pas de protéger le premier dessin à tout prix. Il est de démontrer une capacité d’adaptation.

Faire une estimation rapide sans transformer l’entretien en examen de maths

Le schéma conseille de montrer une évaluation rapide lorsque des chiffres sont disponibles. Une estimation « au dos de l’enveloppe » permet de détecter les ordres de grandeur incohérents.

Prenons un exemple hypothétique :

1 000 requêtes par seconde en moyenne ;
un pic trois fois supérieur ;
5 Ko reçus par requête ;
conservation des événements pendant une journée.

Le débit entrant moyen vaut environ :

1 000 requêtes/s × 5 Ko = 5 Mo/s

Le volume brut quotidien vaut environ :

5 Mo/s × 86 400 s = 432 000 Mo, soit environ 432 Go/jour

Avec trois copies, des index et des métadonnées, la capacité réelle nécessaire dépasse nettement le volume brut. Le but de ce calcul n’est pas d’obtenir le dernier mégaoctet. Il est de montrer que le choix du stockage, la bande passante, la rétention et le coût sont liés à des ordres de grandeur concrets.

Quelques calculs utiles :

requêtes/s = utilisateurs actifs × actions par utilisateur / durée
débit réseau = requêtes/s × taille moyenne d'une requête
stockage/jour = événements/s × taille moyenne × 86 400
capacité de service = instances × débit soutenable par instance

Annoncez toujours vos unités et vos hypothèses. Une estimation simple et lisible vaut mieux qu’un calcul long dont personne ne comprend la finalité.

Étape 4 : traiter la solution comme une discussion

Le troisième axe de ssd.png contient une formule volontairement provocatrice : « ce n’est pas votre solution ». L’architecture sert une entreprise, ses utilisateurs et son équipe. Elle ne sert pas à exposer les technologies préférées du candidat.

Faire participer l’intervieweur

Un entretien de System Design est interactif. À chaque étape importante, vous pouvez vérifier la direction :

« Souhaitez-vous que je détaille le stockage ou le chemin réseau ? »
« L’entreprise utilise-t-elle déjà une plateforme de conteneurs ? »
« Cette hypothèse de cohérence éventuelle est-elle acceptable ? »
« Je peux comparer deux options ici ; laquelle voulez-vous approfondir ? »

Ces questions ne cherchent pas à soutirer la réponse. Elles synchronisent le niveau de détail et évitent de construire seul une solution hors sujet.

Argumenter sans entrer dans le conflit

Vous pouvez défendre une option, mais vous devez écouter les objections et accepter une contrainte nouvelle. L’entretien évalue aussi le comportement attendu dans une revue d’architecture réelle : capacité d’écoute, clarté, absence d’attachement excessif à une technologie et persévérance face à une zone inconnue.

Si l’on vous demande de ne pas utiliser Kubernetes, le bon réflexe n’est pas de bloquer. Il faut identifier les capacités réellement nécessaires, puis envisager une VM, un service de conteneurs managé, des fonctions ou une plateforme applicative selon le contexte.

Dire honnêtement ce que l’on ne sait pas

Une formulation crédible peut être :

Je n’ai pas exploité cette technologie directement. Je connais son rôle général et je vais raisonner à partir des contraintes. Je signalerai les hypothèses qui demanderaient une validation documentaire ou un prototype.

Cette posture est plus solide qu’une réponse inventée. Elle permet aussi de montrer que le raisonnement reste possible dans un domaine partiellement inconnu.

Les quatre sujets à ne jamais oublier

Le dernier axe de ssd.png rassemble quatre points qui disparaissent facilement lorsqu’on se concentre sur le chemin nominal : l’observabilité, la sécurité, le système d’infrastructure et le temps.

1. L’observabilité

Une architecture n’est pas exploitable si personne ne peut déterminer son état. Il faut au minimum préciser :

les métriques de trafic, d’erreur, de latence et de saturation ;
les logs utiles, structurés et corrélables ;
les traces distribuées lorsque plusieurs services participent à une requête ;
les tableaux de bord et alertes liés aux objectifs de service ;
le mécanisme permettant de suivre une requête avec un identifiant de corrélation.

Découvrez Agent Sandbox Kubernetes SIG : des sandboxes isolees et stateful pour vos agents AI

L’autoscaling illustre bien ce besoin. Dire « le service s’adapte automatiquement » ne suffit pas. Sur quel signal ? La CPU, la profondeur d’une file, le débit ou la latence ? Comment sait-on que le seuil est pertinent ? Que se passe-t-il si le stockage en aval ne peut pas suivre ?

2. La sécurité

Retracez le parcours de l’utilisateur jusqu’aux données :

exposition publique ou privée ;
authentification, SSO et autorisation ;
terminaison TLS et chiffrement des données ;
filtrage réseau, pare-feu applicatif ou WAF ;
gestion des secrets et rotation ;
isolation des environnements ;
dépendances tierces ;
audit, rétention et exigences réglementaires ;
protection contre les abus et limitation de débit.

La sécurité ne doit pas être une boîte ajoutée dans un coin à la fin. Elle traverse le système.

3. Le système d’infrastructure

Posez la question « Kubernetes ou pas Kubernetes ? » plutôt que de considérer son usage comme acquis. Les critères peuvent inclure :

nombre et nature des services ;
besoin d’orchestration et d’autoscaling ;
fréquence des déploiements ;
portabilité recherchée ;
plateforme déjà présente dans l’entreprise ;
coût opérationnel ;
maturité et taille de l’équipe.

Une VM correctement automatisée peut convenir à une petite V1. Une plateforme managée peut réduire l’exploitation. Kubernetes devient pertinent lorsque ses capacités répondent à des contraintes réelles et que l’organisation peut assumer sa complexité.

4. La gestion du temps

Trop d’explications sur une seule brique peuvent détruire le déroulé de l’entretien. Un découpage indicatif pour un exercice de 45 minutes serait :

Temps	Objectif
0 à 5 min	Clarifier le besoin, le périmètre et les contraintes
5 à 10 min	Estimer les ordres de grandeur et annoncer les hypothèses
10 à 22 min	Dessiner le high-level design de bout en bout
22 à 37 min	Approfondir les zones choisies avec l’intervieweur
37 à 42 min	Couvrir pannes, sécurité, observabilité et exploitation
42 à 45 min	Résumer les décisions, limites et évolutions possibles

Ce découpage n’est pas une règle universelle. Il sert de garde-fou. Si une discussion consomme plus de temps, dites explicitement ce que vous reportez : « Je note cette optimisation pour un second passage afin de terminer le flux principal. »

Exemple d’évolution : faire monter WordPress en charge

La vidéo propose un exercice simple : partir d’un WordPress et le faire évoluer par paliers. Cet exemple est intéressant parce qu’il oblige à séparer progressivement les responsabilités.

V1 : une seule machine

Pour un trafic limité, une instance peut héberger le serveur web, PHP, WordPress et la base de données. Cette architecture est facile à comprendre, mais la machine constitue un point unique de panne et ses ressources fixent une limite verticale.

V2 : séparer les responsabilités

Lorsque la charge augmente :

la base de données peut être déplacée vers un service distinct ;
les fichiers statiques et médias peuvent rejoindre un stockage objet ;
un CDN peut rapprocher les contenus des utilisateurs ;
plusieurs frontaux WordPress peuvent être placés derrière un load balancer ;
les sessions doivent devenir indépendantes d’une instance précise.

V3 : travailler les goulots d’étranglement

Une nouvelle hausse de trafic conduit à poser d’autres questions :

quelles pages peuvent être mises en cache ?
comment répartir les lectures de base de données ?
quelles écritures restent synchrones ?
comment sauvegarder et restaurer les données ?
comment déployer sans interruption ?
quelles métriques déclenchent une augmentation de capacité ?

L’exercice n’exige pas de reproduire l’infrastructure réelle d’un grand site. Il entraîne à faire apparaître les contraintes, à identifier le prochain goulot et à justifier chaque évolution.

Les erreurs fréquentes en entretien de System Design

Foncer directement sur une technologie

Le candidat dessine Kubernetes, Kafka et Redis avant d’avoir obtenu les besoins. La solution paraît sophistiquée, mais rien ne prouve qu’elle résout le problème posé.

Garder son raisonnement pour soi

Un bon schéma sans explication ne permet pas d’évaluer la démarche. Il faut verbaliser les hypothèses, les alternatives et les raisons des choix.

Aller trop tôt dans les détails

Décrire précisément des objets Kubernetes, un protocole de consensus ou le format d’un index peut consommer tout le temps. Commencez par une couverture homogène, puis approfondissez à la demande.

Défendre la première version comme une vérité

Une nouvelle contrainte doit faire évoluer l’architecture. Refuser le changement révèle davantage un attachement à la solution qu’une capacité d’ingénierie.

Oublier les réalités de l’entreprise

Une technologie peut être techniquement adaptée mais économiquement ou humainement irréaliste. Les compétences disponibles, la maintenance, le coût, le délai et les pratiques existantes font partie du problème.

Traiter uniquement le chemin heureux

Il faut aussi parler des pannes, reprises, sauvegardes, dépendances externes, limites de débit, déploiements, alertes et procédures d’exploitation.

Une trame réutilisable pendant l’entretien

Vous pouvez garder cette séquence comme aide-mémoire :

1. Reformuler le besoin.
2. Délimiter la V1 et les fonctions hors périmètre.
3. Demander charge, données, latence, disponibilité et sécurité.
4. Écrire les hypothèses et effectuer 1 ou 2 estimations utiles.
5. Dessiner le flux global de l'utilisateur jusqu'aux données.
6. Nommer les catégories de composants et leurs responsabilités.
7. Présenter les principales options et justifier les choix.
8. Vérifier les pannes, la sécurité et l'observabilité.
9. Approfondir une ou deux zones avec l'intervieweur.
10. Résumer les limites, les risques et la prochaine évolution.

Comment s’entraîner efficacement

La recommandation finale de la vidéo est de pratiquer face à une page blanche. Choisissez un système connu, sans chercher à reproduire son architecture réelle, puis construisez votre proposition.

Quelques sujets progressifs :

un WordPress qui passe de quelques visiteurs à un trafic international ;
un raccourcisseur d’URL ;
un service de dépôt et de partage de fichiers ;
une file de traitement d’images ;
une plateforme de notifications ;
un moteur de recherche documentaire avec RAG ;
un système de diffusion vidéo.

Pour chaque exercice :

limitez-vous à 45 ou 60 minutes ;
enregistrez votre explication à voix haute ;
vérifiez que le high-level design est terminé avant les zooms ;
listez les décisions insuffisamment justifiées ;
ajoutez une contrainte en cours d’exercice, par exemple un milliard de requêtes par jour, une nouvelle région ou une exigence forte de confidentialité ;
redessinez uniquement les parties affectées.

La page blanche révèle rapidement ce que l’on sait réciter et ce que l’on sait réellement relier.

FAQ sur l’entretien de System Design

Faut-il connaître Kubernetes pour réussir un entretien de System Design ?

Non. Il faut comprendre les capacités nécessaires au système et savoir quand un orchestrateur apporte une réponse adaptée. Kubernetes peut être une option, mais une VM, une plateforme de conteneurs managée ou un service serverless peuvent être plus cohérents selon l’échelle, l’équipe et le coût.

Existe-t-il une seule bonne architecture ?

Non. Plusieurs architectures peuvent satisfaire le même besoin avec des compromis différents. L’évaluation porte largement sur la cohérence entre les contraintes, les décisions et les explications.

Peut-on poser beaucoup de questions à l’intervieweur ?

Oui, si elles servent à réduire une ambiguïté ou à obtenir une contrainte utile. Regroupez-les et expliquez pourquoi une réponse influence la conception. L’entretien doit rester une discussion orientée vers une architecture.

Que faire si l’intervieweur ne répond pas ?

Annoncez une hypothèse raisonnable, demandez sa validation, puis continuez. Notez-la pour pouvoir modifier la solution si elle change.

Faut-il citer des technologies précises ?

Oui, mais après avoir décrit la catégorie et la responsabilité du composant. Citer quelques options montre votre culture technique ; justifier pourquoi l’une convient au contexte montre votre capacité d’architecture.

Comment réagir lorsqu’un choix est contesté ?

Demandez quelle contrainte motive l’objection, réévaluez vos critères et adaptez la proposition. Vous pouvez argumenter, mais sans transformer l’échange en confrontation.

Jusqu’où faut-il détailler les calculs de capacité ?

Quelques ordres de grandeur suffisent généralement : requêtes par seconde, débit réseau, volume quotidien, ratio lecture/écriture et capacité approximative par instance. Le calcul doit éclairer une décision, pas devenir une fin en soi.

Quels éléments sont le plus souvent oubliés ?

L’observabilité, la sécurité de bout en bout, les dépendances externes, les sauvegardes, les scénarios de panne, les coûts et la gestion du temps sont fréquemment absents d’un premier dessin.

Liens utiles

Conclusion

Un entretien de System Design ne récompense pas celui qui place le plus de technologies sur un tableau. Il cherche à observer une démarche d’ingénierie : comprendre un besoin imparfait, obtenir les contraintes essentielles, construire une vision globale, estimer les ordres de grandeur, comparer des options et faire évoluer la proposition sans perdre le fil.

La méthode peut se résumer ainsi : besoin, hypothèses, high-level design, arbitrages, approfondissement, exploitation. Si votre dessin rend visibles ces étapes et si votre dialogue permet à l’intervieweur de suivre chaque décision, vous démontrez bien plus qu’une connaissance d’outils : vous montrez votre capacité à concevoir un système pour une organisation réelle.