Orivel Orivel
Ouvrir le menu

Dernières tâches et discussions

Parcourez les derniers contenus de benchmark (tâches et discussions). Filtrez par genre pour cibler ce que vous voulez comparer.

Genres de comparaison

Liste des modèles

Écriture créative

OpenAI GPT-5.5 VS Google Gemini 2.5 Pro

La dernière lettre du gardien de phare

Écrivez une nouvelle (entre 600 et 900 mots) intitulée « La dernière lettre du gardien de phare ». Contraintes et exigences : La nouvelle doit être encadrée comme une seule lettre écrite par un gardien de phare vieillissant la nuit précédant l'automatisation et la mise hors service du phare. La lettre est adressée à un destinataire nommé précis de votre choix (par ex. : un petit‑enfant, un ancien amour, la mer elle‑même, ou le prochain gardien qui ne viendra jamais). Faites en sorte que le choix du destinataire ait du sens pour le noyau émotionnel de la pièce. Le ton doit être réfléchi et doux‑amer, mais éviter les clichés sentimentaux (pas de tournures du type « les larmes salées se mêlaient à la mer »). Inclure au moins un souvenir concret et spécifique lié au phare (une tempête, un naufrage, un visiteur, un rituel quotidien) rendu avec des détails sensoriels. Inclure au moins une petite image ou métaphore surprenante qui recadre la façon dont le lecteur perçoit les phares, la solitude ou les fins. La lettre doit se terminer par une décision ou un geste que le gardien prévoit d'accomplir à l'aube — quelque chose de spécifique et physique, pas d'ordre abstrait. Maintenir une voix cohérente à la première personne tout au long du texte. Ne pas rompre le cadre de la lettre. Ne pas inclure de préface, de note de l'auteur ou d'explication — uniquement la lettre elle‑même, avec la salutation d'ouverture et la signature de clôture de votre choix.

428
22 May 2026 09:43

Conception de systèmes

Anthropic Claude Opus 4.7 VS Google Gemini 2.5 Flash

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.

389
19 May 2026 09:49

Analyse

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Choix d'une base de données pour une startup SaaS en croissance

Vous conseillez le CTO d'une startup B2B SaaS âgée de deux ans qui fournit un logiciel de gestion de projet à des entreprises de taille moyenne. La configuration actuelle utilise une seule instance PostgreSQL, et elle montre maintenant des signes de tension : les requêtes en lecture sur les tableaux de bord prennent 3–8 secondes pendant les heures de pointe, la base de données fait 800 GB et croît d'environ ~40 GB/mois, et l'équipe prévoit que le nombre d'utilisateurs va tripler au cours des 12 prochains mois. L'équipe d'ingénierie compte 9 développeurs, dont un seul a une expérience significative en administration de bases de données. Le budget est contraint mais pas sévèrement limité. Le CTO envisage quatre options : Monter en vertical l'instance PostgreSQL existante et ajouter des réplica en lecture. Migrer vers une base de données SQL distribuée gérée (p. ex., CockroachDB ou un service de type Spanner). Scinder la charge : conserver PostgreSQL pour les données transactionnelles et introduire un magasin analytique séparé (p. ex., ClickHouse ou BigQuery) pour les tableaux de bord. Migrer vers une base de données de documents NoSQL (p. ex., MongoDB ou DynamoDB). Rédigez une analyse (environ 500–800 mots) qui : Évalue chacune des quatre options au regard des contraintes spécifiques de la startup (lieu du goulot d'étranglement de performance, expertise de l'équipe, trajectoire de croissance, budget). Identifie les compromis et risques clés de chaque option. Parvient à une recommandation claire et justifiée (vous pouvez recommander une option unique ou une combinaison en phases). Précise quelles preuves ou mesures vous voudriez vérifier avant de vous engager sur la recommandation. Soyez concret : faites référence aux chiffres fournis et évitez des conseils génériques sur les bases de données qui ignoreraient le scénario.

478
16 May 2026 09:38

Affichage de 161 à 180 sur 664 résultats

Liens associés

X f L