Conception de systèmes
Compare la réflexion architecturale, l’analyse des compromis et la qualité de conception.
Dans ce genre, les capacites surtout observees sont Qualite de l architecture, Completude, Analyse des compromis.
Contrairement a coding, ce genre valorise davantage l architecture, l echelle, la fiabilite et les compromis que les details d implementation executable.
Un score eleve ici ne signifie pas que le modele ecrira le meilleur code fonctionnel ni l explication la plus simple.
Usages adaptes aux modeles forts dans ce genre
propositions d architecture, conception de services et discussions sur la scalabilite.
Ce que ce genre ne permet pas de juger a lui seul
la qualite d implementation bas niveau, la correction exacte ou l ecriture pour un public non technique.
Conception de systèmes : GPT-5 et Anthropic se regroupent en tête, Gemini décroche
OpenAI
Anthropic
OpenAI
Score moyen par modele
Notre ponderation
Sur 35 réponses de conception notées, le sommet est un groupe serré GPT-5 et Anthropic. GPT-5.5 (8,91) et Claude Opus 4.8 (8,69) occupent les places 1 et 2 avec un parcours parfait, mais chacun sur un seul échantillon : à lire comme prometteur plutôt qu'établi. Les meilleurs résultats étayés sont GPT-5.4 (8,67 sur 5 échantillons, 60 % de victoires) et GPT-5 mini (8,43 sur 4 échantillons, 75 % de victoires), qui pèsent le plus ici.
Moyenne et classement divergent : GPT-5.4 dépasse GPT-5 mini en moyenne (8,67 contre 8,43) mais se classe en dessous, car GPT-5 mini gagne une plus grande part de ses duels (75 % contre 60 %). Claude Sonnet 4.6 (8,53, 60 % sur 5) appartient à ce groupe, si bien que les six premiers se tiennent en moins d'un demi-point de qualité et se classent surtout aux victoires directes.
La gamme Gemini forme un palier inférieur net : 2.5 Pro (7,51), Flash (7,41) et Flash-Lite (7,12) ne gagnent aucun de leurs duels et accusent 1,2 à 1,8 point de retard sur les leaders. La Qualité d'architecture étant la mieux pondérée (30), devant le Raisonnement sur les compromis et la Scalabilité (20 chacun), l'écart traduit un raisonnement plus faible sur la structure et les arbitrages, non la présentation.
Les tailles d'échantillon vont de 1 à 6 par modèle, donc l'ordre fin au sein du groupe à 8 points est provisoire et quelques prompts peuvent déplacer n'importe quelle moyenne. L'écart de 1,79 point entre le premier et le dernier est réel, mais ce sont des mesures dépendantes des conditions pour des prompts de conception, non un verdict universel.
En bref
Pour la conception de systèmes, GPT-5 mini est le choix quotidien le plus défendable (75 % de victoires sur 4 échantillons), avec GPT-5.4 comme option haut de gamme la mieux étayée (8,67 sur 5). Claude Sonnet 4.6 est quasiment à égalité en qualité ; la gamme Gemini est nettement en retrait dans ce genre.
Cette analyse s appuie sur les scores de benchmark mesures par Orivel pour ce genre et est mise a jour periodiquement. Les scores sont des mesures dependantes des conditions, pas une verite absolue.
Classement des modeles forts dans ce genre
Ce classement est trie par score moyen uniquement dans ce genre.
Derniere mise a jour: 30 May 2026 09:41
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
Taux de victoire
Score moyen
| Modeles classes | Detail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.5 | OpenAI |
100%
|
89
|
1 | 1 | Voir l evaluation et le score de GPT-5.5 |
| #2 | Claude Opus 4.8 NOUVEAU | Anthropic |
100%
|
87
|
1 | 1 | Voir l evaluation et le score de Claude Opus 4.8 |
| #3 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Voir l evaluation et le score de GPT-5 mini |
| #4 | GPT-5.4 | OpenAI |
60%
|
87
|
3 | 5 | Voir l evaluation et le score de GPT-5.4 |
| #5 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Voir l evaluation et le score de Claude Sonnet 4.6 |
| #6 | Claude Haiku 4.5 | Anthropic |
40%
|
82
|
2 | 5 | Voir l evaluation et le score de Claude Haiku 4.5 |
| #7 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Voir l evaluation et le score de Gemini 2.5 Pro | |
| #8 | Gemini 2.5 Flash |
0%
|
74
|
0 | 6 | Voir l evaluation et le score de Gemini 2.5 Flash | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
71
|
0 | 4 | Voir l evaluation et le score de Gemini 2.5 Flash-Lite |
Ce qui est evalue dans Conception de systèmes
Criteres et poids utilises pour ce classement par genre.
Qualite de l architecture
30.0%
Ce critere est present pour verifier Qualite de l architecture dans la reponse. Il a plus de poids parce que cet aspect influence fortement le resultat global de ce genre.
Completude
20.0%
Ce critere est present pour verifier Completude dans la reponse. Il garde un poids important parce qu il change visiblement la qualite, meme si ce n est pas le seul element qui compte.
Analyse des compromis
20.0%
Ce critere est present pour verifier Analyse des compromis dans la reponse. Il garde un poids important parce qu il change visiblement la qualite, meme si ce n est pas le seul element qui compte.
Scalabilite et fiabilite
20.0%
Ce critere est present pour verifier Scalabilite et fiabilite dans la reponse. Il garde un poids important parce qu il change visiblement la qualite, meme si ce n est pas le seul element qui compte.
Clarte
10.0%
Ce critere est present pour verifier Clarte dans la reponse. Il est plus legerement pondere parce qu il soutient l objectif principal sans definir a lui seul le genre.
Taches recentes
Conception de systèmes
Concevoir un système de tableau blanc collaboratif en temps réel
Vous devez concevoir une architecture système de haut niveau pour une application de tableau blanc collaborative en temps réel. **Exigences principales :** 1. **Collaboration en temps réel :** Plusieurs utilisateurs (jusqu'à 100 par session) peuvent rejoindre un même tableau blanc et voir les actions des autres (dessin, ajout de texte, déplacement d'objets) en quasi-temps réel (latence inférieure à 200 ms). 2. **Persistance :** Les sessions de tableau blanc doivent être sauvegardées afin que les utilisateurs puissent fermer l'application et reprendre leur travail plus tard. 3. **Outils :** Les utilisateurs doivent disposer d'outils de base comme un stylo libre, des zones de texte et des post-it. **Contraintes d'échelle et de fiabilité :** * Supporter jusqu'à 10 000 sessions de tableau blanc actives simultanément. * Supporter jusqu'à 1 000 000 d'utilisateurs au total. * Le service doit être hautement disponible, avec 99,9 % de temps de fonctionnement. **Votre tâche :** Fournissez une conception système qui répond aux exigences ci-dessus. Votre réponse doit couvrir : 1. **Architecture de haut niveau :** Un diagramme ou une description des composants principaux (par ex., clients, équilibreurs de charge, serveurs d'application, bases de données, services en temps réel) et leur interaction. 2. **Communication en temps réel :** Expliquez la technologie et le protocole que vous utiliseriez pour diffuser les mises à jour à tous les utilisateurs d'une session. 3. **Modèle de données :** Décrivez comment vous structureriez les données pour un tableau blanc, son contenu (dessins, texte, etc.) et les sessions utilisateur. 4. **Stratégie de scalabilité et de fiabilité :** Comment concevriez-vous le système pour gérer la charge cible et assurer une haute disponibilité ? 5. **Compromis :** Discutez d'un compromis majeur que vous avez fait dans votre conception (par ex., cohérence vs latence, choix de la base de données, etc.).
Conception de systèmes
Concevoir un système évolutif de réservation de billets de concert
Concevez un système pour une plateforme de billetterie de concerts en ligne. Les utilisateurs peuvent parcourir les événements, voir la disponibilité des sièges, réserver des sièges spécifiques pendant 10 minutes, payer via un fournisseur de paiement externe et recevoir un billet numérique. La plateforme fonctionne dans une seule région cloud répartie sur plusieurs zones de disponibilité. Contraintes explicites : 3 millions d'utilisateurs enregistrés, 500 000 utilisateurs actifs quotidiens, les événements majeurs en mise en vente peuvent atteindre 150 000 utilisateurs simultanés, la charge de pointe est de 8 000 tentatives de réservation de sièges par seconde et 2 000 tentatives de paiement par seconde, chaque événement comporte jusqu'à 60 000 sièges, le système ne doit jamais vendre deux fois le même siège, les réservations de sièges expirent après 10 minutes si non payées, la latence p95 pour la navigation et les lectures de plans de salle doit être inférieure à 300 ms, la latence p95 pour la confirmation de réservation doit être inférieure à 800 ms hors temps du fournisseur de paiement, l'objectif de disponibilité pendant les fenêtres de mise en vente est de 99,95 %, l'objectif de point de récupération (RPO) est inférieur à 1 minute, l'objectif de temps de récupération (RTO) est inférieur à 15 minutes, et les callbacks du fournisseur de paiement sont au moins une fois, peuvent arriver dans le désordre et peuvent être retardés jusqu'à 5 minutes. Fournissez un plan de conception. Incluez les principaux services et magasins de données, les API principales, le modèle de données pour les sièges et les réservations, le flux des requêtes pour la navigation, la réservation, le paiement et l'expiration des réservations, la stratégie d'échelle pour les pics de trafic, l'approche de fiabilité et de reprise après sinistre, les choix de cohérence qui empêchent la survente, la surveillance et les alertes, ainsi que les principaux compromis ou alternatives que vous avez envisagés. Indiquez toutes les hypothèses raisonnables que vous faites.
Conception de systèmes
Concevoir un service de notifications évolutif
Vous êtes ingénieur logiciel senior dans une entreprise de réseaux sociaux en forte croissance. Votre tâche est de concevoir un service de notifications évolutif et fiable. Ce service sera responsable de l'envoi de notifications aux utilisateurs concernant divers événements, tels que de nouveaux abonnés, des « j'aime » sur leurs publications, des commentaires et des messages directs.
Conception de systèmes
Concevoir un service de notification en temps réel
Présentez une conception système de haut niveau pour un service de notification en temps réel destiné à une plateforme de médias sociaux. Le service doit répondre aux exigences suivantes : - **Échelle :** 10 millions d’utilisateurs actifs quotidiens (DAU). - **Volume :** Chaque utilisateur reçoit en moyenne 20 notifications par jour. - **Latence :** Les notifications doivent être livrées à l’appareil de l’utilisateur en moins de 2 secondes. - **Canaux :** Prise en charge des notifications push (mobile), des e-mails et des notifications intégrées à l’application. - **Fiabilité :** 99,9 % de disponibilité et aucune perte de données de notification. Votre conception doit couvrir les aspects suivants : 1. **Architecture principale :** Décrivez les composants clés (par ex., API Gateway, Notification Service, Message Queue, Workers) et leurs interactions. 2. **Schéma de base de données :** Proposez un schéma de base de données de base pour stocker les notifications utilisateur et les préférences. 3. **Stratégie de mise à l’échelle :** Expliquez comment vous mettriez le système à l’échelle pour gérer la charge spécifiée et la croissance future. 4. **Fiabilité et tolérance aux pannes :** Détaillez les mesures que vous prendriez pour garantir une haute disponibilité et éviter toute perte de données. 5. **Principaux compromis :** Discutez d’au moins deux compromis significatifs réalisés dans votre conception (par ex., cohérence vs disponibilité, choix de la base de données, modèle push vs pull).
Conception de systèmes
Concevoir un service de raccourcissement d'URL
Concevez un service de raccourcissement d'URL (similaire à bit.ly ou tinyurl.com) qui doit respecter les contraintes suivantes : 1. Le service doit supporter 100 millions de nouvelles URL raccourcies par mois. 2. Le ratio moyen lecture/écriture est de 100:1 (c.-à-d. que les URLs raccourcies sont beaucoup plus souvent consultées qu'elles ne sont créées). 3. Les URLs raccourcies doivent rester accessibles pendant au moins 5 ans après leur création. 4. Le système doit atteindre une disponibilité (uptime) de 99,9 %. 5. La latence de redirection (du moment où la requête pour une URL courte est reçue jusqu'à l'émission de la redirection HTTP) doit être inférieure à 50 ms au 95e centile. Dans votre conception, traitez tous les points suivants : A. Architecture haut niveau : Décrivez les composants majeurs (serveurs d'API, bases de données, caches, équilibreurs de charge, etc.) et comment ils interagissent. Incluez une description claire du flux de requêtes pour la création d'URL et pour la redirection d'URL. B. Stratégie de génération d'URL courtes : Expliquez comment vous généreriez des codes courts uniques. Discutez les compromis entre différentes approches (p. ex. hachage, compteur, pool de clés pré-générées) et justifiez votre choix. C. Stockage des données : Choisissez une technologie de base de données et un schéma. Estimez les besoins de stockage sur 5 ans en tenant compte des contraintes. Expliquez pourquoi la base de données choisie est appropriée. D. Stratégie de montée en charge : Expliquez comment le système monte en charge pour gérer le trafic fortement orienté lecture. Discutez de la stratégie de cache, de l'approche de partitionnement/sharding de la base de données, et de la façon de traiter les "clés chaudes" (URLs virales qui reçoivent un trafic disproportionné). E. Fiabilité et tolérance aux pannes : Décrivez comment le système maintient une disponibilité de 99,9 %. Traitez ce qui se passe quand des composants individuels tombent en panne, et comment vous gérez la réplication des données et le basculement (failover). F. Principaux compromis : Identifiez au moins deux compromis de conception significatifs que vous avez faits et expliquez pourquoi vous avez choisi un côté plutôt qu'un autre au regard des contraintes données.
Conception de systèmes
Concevoir un service de raccourcissement d'URL
Concevez un service de raccourcissement d'URL (similaire à bit.ly ou tinyurl.com) qui doit gérer les contraintes suivantes : 1. Le service doit prendre en charge 100 millions de nouveaux raccourcissements d'URL par mois. 2. Le ratio des requêtes de lecture (redirection) aux requêtes d'écriture (raccourcissement) est de 100:1. 3. Les URLs raccourcies doivent être aussi courtes que possible mais doivent supporter le volume attendu pendant au moins 10 ans. 4. Le système doit atteindre 99,9 % de disponibilité (uptime). 5. La latence de redirection doit être inférieure à 50 ms au 95e centile. 6. Le service doit gérer une dégradation maîtrisée si un centre de données devient indisponible. Dans votre conception, abordez chacun des domaines suivants : A) API Design : Définissez les principaux points de terminaison API et leurs contrats. B) Data Model and Storage : Choisissez une solution de stockage, justifiez votre choix, expliquez votre schéma et estimez le stockage total nécessaire sur 10 ans. C) Short URL Generation : Décrivez votre algorithme pour générer les codes courts. Expliquez comment vous évitez les collisions et quel jeu de caractères et quelle longueur vous avez choisis, avec une justification mathématique montrant pourquoi l'espace de clés est suffisant. D) Scaling and Performance : Expliquez comment vous feriez évoluer les lectures et les écritures indépendamment. Décrivez votre stratégie de mise en cache, y compris la politique d'éviction et le taux de cache attendu. Expliquez comment vous atteignez l'exigence de latence de 50 ms p95. E) Reliability and Fault Tolerance : Décrivez comment le système gère les pannes de centres de données, la stratégie de réplication des données et quels compromis vous faites entre cohérence et disponibilité (référencez le théorème CAP). F) Trade-off Discussion : Identifiez au moins deux compromis de conception significatifs que vous avez faits et expliquez pourquoi vous avez choisi une option plutôt qu'une autre, y compris ce que vous sacrifiez et ce que vous gagnez. Présentez votre réponse comme un plan structuré avec des sections claires correspondant à A à F.