Programmation
Compare la justesse, la qualité et l’utilité pratique du code généré.
Dans ce genre, les capacités surtout observées sont Exactitude, Complétude, Qualité du code.
Contrairement à system design, ce genre regarde davantage si le code fonctionne réellement que les choix d’architecture de haut niveau.
Un score élevé ici ne garantit ni meilleur jugement produit, ni meilleure architecture, ni meilleures explications pour débutants.
Usages adaptés aux modèles forts dans ce genre
implémentation, débogage, refactorisation et aide pratique à la programmation.
Ce que ce genre ne permet pas de juger à lui seul
si le modèle est meilleur pour l’architecture, les documents pour parties prenantes ou l’idéation ouverte.
Programmation : Claude Fable 5 débute au sommet, GPT-5 mini reste le choix le plus défendable
Anthropic
OpenAI
OpenAI
Score moyen par modèle
Notre pondération
Claude Fable 5 est arrivé dans ce genre et a immédiatement pris la première place, remportant son duel inaugural avec la meilleure prestation du tableau. GPT-5.6 a lui aussi gagné tout ce qu’il a disputé jusqu’ici. Ces deux bilans sont à la fois impressionnants et minces : un début victorieux prouve qu’un modèle peut gagner ici, pas qu’il continuera. L’ordre exact tout en haut doit se lire comme un signal précoce.
Le bilan le plus défendable du genre appartient à GPT-5 mini : il a affronté plus de sujets de programmation que n’importe lequel des leaders et n’en a perdu aucun. Pour un modèle de gamme légère, une série sans défaite face à des adversaires de pointe est la meilleure histoire de rapport qualité-prix de ce tableau. GPT-5.5, à l’inverse, affiche l’une des meilleures moyennes du genre mais a partagé ses duels — du bon code qui n’a pas toujours battu le code d’en face. Claude Sonnet 5 a signé une moyenne solide pour sa première sortie et l’a pourtant perdue : son classement sous-estime pour l’instant la qualité de sa production.
La justesse domine l’évaluation, suivie de la complétude et de la qualité du code — le classement sanctionne les bugs discrets plus durement que le style. La famille Gemini n’a encore converti aucun duel dans ce genre et ferme aussi la marche en moyenne. Tout cela reflète les tâches et juges propres à Orivel : la programmation va des algorithmes au design d’API, et une poignée de sujets ne peut couvrir cet espace.
En bref
GPT-5 mini est le choix défendable aujourd’hui — invaincu sur le plus grand nombre de duels, au coût d’une gamme légère. Claude Fable 5 et GPT-5.6 semblent encore plus forts, mais sur des preuves précoces. À suivre : GPT-5.5 transformera-t-il ses réponses de qualité en victoires ?
Cette analyse s’appuie sur les scores de benchmark mesurés par Orivel pour ce genre et est mise à jour périodiquement. Les scores sont des mesures dépendantes des conditions, pas une vérité absolue.
Classement des modèles forts dans ce genre
Ce classement est trié par score moyen uniquement dans ce genre.
Dernière mise à jour: 25 Jul 2026 01:19
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
| Modèles classés | Détail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | Claude Fable 5 | Anthropic |
100%
|
91
|
1 | 1 | Voir l’évaluation et le score de Claude Fable 5 |
| #2 | GPT-5.6 | OpenAI |
100%
|
86
|
2 | 2 | Voir l’évaluation et le score de GPT-5.6 |
| #3 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Voir l’évaluation et le score de GPT-5 mini |
| #4 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | Voir l’évaluation et le score de GPT-5.5 |
| #5 | Claude Sonnet 5 NOUVEAU | Anthropic |
0%
|
83
|
0 | 1 | Voir l’évaluation et le score de Claude Sonnet 5 |
| #6 | Gemini 2.5 Pro |
0%
|
74
|
0 | 5 | Voir l’évaluation et le score de Gemini 2.5 Pro | |
| #7 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Voir l’évaluation et le score de Gemini 2.5 Flash-Lite | |
| #8 | Gemini 2.5 Flash |
0%
|
68
|
0 | 5 | Voir l’évaluation et le score de Gemini 2.5 Flash |
Ce qui est évalué dans Programmation
Critères et poids utilisés pour ce classement par genre.
Exactitude
35.0%
Ce critère est présent pour vérifier Exactitude dans la réponse. Il a plus de poids parce que cet aspect influence fortement le résultat global de ce genre.
Complétude
20.0%
Ce critère est présent pour vérifier Complétude dans la réponse. Il garde un poids important parce qu’il change visiblement la qualité, même si ce n’est pas le seul élément qui compte.
Qualité du code
20.0%
Ce critère est présent pour vérifier Qualité du code dans la réponse. Il garde un poids important parce qu’il change visiblement la qualité, même si ce n’est pas le seul élément qui compte.
Valeur pratique
15.0%
Ce critère est présent pour vérifier Valeur pratique dans la réponse. Il est plus légèrement pondéré parce qu’il soutient l’objectif principal sans définir à lui seul le genre.
Respect des consignes
10.0%
Ce critère est présent pour vérifier Respect des consignes dans la réponse. Il est plus légèrement pondéré parce qu’il soutient l’objectif principal sans définir à lui seul le genre.
Tâches récentes
Programmation
Analyseur de journaux de serveur Web
Écrivez une fonction Python analyze_logs(log_data) qui prend une chaîne multilignes contenant des entrées de journaux (logs) de serveur Web. La fonction doit analyser ces journaux, effectuer une analyse et renvoyer un dictionnaire résumant les résultats. Chaque ligne de journal valide suit ce format : [TIMESTAMP] LEVEL IP_ADDRESS "REQUEST_METHOD /path" RESPONSE_CODE BYTES_SENT Exemple d'une ligne valide : [2023-10-27T10:00:00Z] INFO 192.168.1.1 "GET /index.html" 200 1543 Votre fonction doit : Analyser uniquement les lignes de journal valides, en ignorant proprement toute ligne malformée ou vide. Calculer les métriques suivantes : total_requests : le nombre total d'entrées de journal valides. error_rate : le pourcentage de requêtes dont le LEVEL est ERROR, arrondi à deux décimales. top_3_ips : une liste de tuples, chaque tuple contenant une adresse IP et son nombre de requêtes, pour les 3 adresses IP les plus fréquentes. La liste doit être triée par ordre décroissant du nombre de requêtes. busiest_hour : l'heure de la journée (un entier de 0 à 23) qui a enregistré le plus de requêtes. Le timestamp est au format ISO 8601 (UTC). Renvoyer un dictionnaire avec les clés total_requests, error_rate, top_3_ips et busiest_hour contenant les valeurs calculées. Traitez les cas limites suivants : Si la chaîne d'entrée log_data est vide, renvoyer un dictionnaire avec des valeurs mises à zéro ou vides selon le cas (par ex., total_requests: 0, top_3_ips: []). S'il y a moins de 3 adresses IP uniques, la liste top_3_ips doit contenir toutes les IPs uniques, triées par nombre de requêtes. S'il y a égalité pour l'heure la plus chargée, il est acceptable de renvoyer n'importe laquelle des heures à égalité.
Programmation
Limiteur de débit avec fenêtre glissante et quotas multi‑locataires équitables
Implémentez une bibliothèque de limitation de débit réutilisable dans un langage de votre choix (Python, Go, TypeScript, Java ou Rust) qui applique des quotas de requêtes par client en utilisant un algorithme à fenêtre glissante, ainsi qu'une politique de partage équitable entre plusieurs locataires. Exigences fonctionnelles: Fournir une classe ou un module avec une méthode telle que allow(tenant_id, client_id, now_ms) qui retourne si une requête est autorisée et, lorsqu'elle est refusée, combien de millisecondes il reste avant que la prochaine requête soit autorisée (retry_after_ms). Chaque client est limité à un nombre maximal de requêtes dans une fenêtre temporelle roulante (par exemple, 100 requêtes par 60,000 ms). La configuration doit être ajustable par locataire. Implémenter une véritable fenêtre glissante (pondérée ou basée sur un log), pas une fenêtre par buckets calendaire fixe, de sorte que les rafales traversant les frontières de buckets soient traitées correctement. Ajouter un plafond global par locataire de sorte que tous les clients d'un locataire combinés ne puissent pas dépasser un plafond au niveau du locataire, et lorsque le locataire est saturé, la capacité restante soit partagée équitablement entre les clients actifs plutôt que monopolisée par un seul client. Le limiteur doit être sûr en cas d'accès concurrent depuis plusieurs threads ou tâches asynchrones. La mémoire ne doit pas croître de façon illimitée : l'état des clients obsolètes doit être évincé ou compacté au fil du temps. Livrables: L'implémentation complète avec une API publique claire et une documentation inline des décisions clés. Une brève explication (en commentaires ou une courte section en prose) de l'algorithme à fenêtre glissante que vous avez choisi et ses compromis précision/mémoire. Une suite de tests couvrant les principaux cas limites décrits ci-dessous. Cas limites à traiter explicitement dans le code et les tests: Requêtes exactement à la frontière de la fenêtre. Un client qui devient inactif puis revient après que la fenêtre ait entièrement expiré. Requêtes concurrentes qui se font concurrence sur le même compteur client. Horloge qui recule ou timestamps dupliqués. Saturation du locataire et redistribution équitable entre clients concurrents. Éviction de l'état client obsolète sans supprimer les clients actifs. Indiquez toutes les hypothèses que vous faites (processus unique vs distribué, disponibilité d'une horloge monotone, etc.). Si vous supposez un processus unique, décrivez brièvement comment le design s'étendrait à un déploiement distribué.
Programmation
Implémenter un simulateur déterministe de carnet d'ordres limite
Écrivez une solution Python 3.11 en un seul fichier implémentant la fonction process_events(events: list[dict]) -> dict. N'utilisez pas de paquets externes. La fonction doit simuler le carnet d'ordres limite d'une petite bourse pour un seul instrument. Elle reçoit une liste de dictionnaires d'événements dans l'ordre d'entrée et retourne un dictionnaire contenant exactement ces clés : trades, rejected, book. Types d'événements : Événement nouvel ordre : Champs requis : type="new", id, side, order_type, qty. side est "buy" ou "sell". order_type est "limit" ou "market". qty est un entier positif. Un ordre limite requiert également price, un nombre entier positif de cents. Champ optionnel tif est le time-in-force : "GTC", "IOC" ou "FOK". S'il est absent, utilisez "GTC" pour les ordres limit et "IOC" pour les ordres market. Les ordres market ne peuvent pas avoir tif="GTC" et ne peuvent pas rester sur le livre. Événement d'annulation : Champs requis : type="cancel", id. Il annule la quantité restante d'un ordre actuellement en attente sur le livre ayant cet id. Règles d'appariement : Le livre contient bids et asks. Les ordres buy limit en attente sont des bids ; les ordres sell limit en attente sont des asks. La priorité prix-temps est obligatoire : meilleur prix d'abord ; pour un même prix, l'ordre en attente accepté plus tôt passe en premier. Un ordre buy s'apparie aux asks en attente tant qu'il peut croiser : un market buy croise n'importe quel ask ; un limit buy croise les asks dont le prix ask <= prix limite buy. Un ordre sell s'apparie aux bids en attente tant qu'il peut croiser : un market sell croise n'importe quel bid ; un limit sell croise les bids dont le prix bid >= prix limite sell. La quantité de chaque trade est min(quantité restante de l'ordre entrant, quantité restante de l'ordre en attente). Le prix du trade est toujours le prix limite de l'ordre maker en attente, jamais le prix de l'ordre entrant. Un enregistrement de trade doit être ajouté immédiatement lorsqu'il se produit, avec exactement ces clés : buy_id, sell_id, price, qty, taker_id, maker_id. Les ordres en attente partiellement exécutés conservent leur priorité d'origine avec la quantité restante. Les ordres entièrement exécutés quittent le livre. Comportement du time-in-force : Les ordres limit GTC restent, pour tout reste non exécuté, sur le livre. Les ordres IOC s'exécutent autant que possible immédiatement, puis annulent tout reste. Les ordres FOK doivent être entièrement exécutables immédiatement selon le livre courant et les règles de croisement. Sinon, ils ne produisent aucun trade et ne changent pas le livre. S'ils sont entièrement exécutables, exécutez-les normalement. Les ordres FOK ne restent jamais sur le livre. Règles de validation et de rejet : Si un événement est mal formé, rejetez-le sans modifier le livre. Ajoutez un enregistrement de rejet à rejected avec les clés input_index, event, reason. La raison peut être une courte chaîne lisible par un humain. Rejetez un nouvel ordre si son id est déjà utilisé par un nouvel ordre précédemment accepté, même si cet ordre antérieur a depuis été exécuté ou annulé. Rejetez les événements cancel pour des ids inconnus ou des ids qui ne sont plus en attente. Rejetez les qty et price non entiers, nuls ou négatifs. En Python, bool ne doit pas être accepté comme entier pour ces champs. Ignorez les champs supplémentaires sur des événements autrement valides. Format de retour : trades : liste d'enregistrements de trade dans l'ordre d'exécution. rejected : liste d'enregistrements de rejet dans l'ordre d'entrée. book : un dictionnaire avec les clés bids et asks. book["bids"] doit lister tous les bids en attente triés par prix décroissant, puis par temps d'attente original, chacun sous la forme {"id": id, "price": price, "qty": remaining_qty}. book["asks"] doit lister tous les asks en attente triés par prix croissant, puis par temps d'attente original, chacun sous la forme {"id": id, "price": price, "qty": remaining_qty}. Votre réponse doit être un code Python exécutable complet définissant process_events. Vous pouvez inclure des classes/fonctions helper et une petite section d'auto-test protégée par if name == "main":, mais la fonction principale ne doit pas lire depuis stdin ni écrire sur stdout.
Programmation
Implémenter l'application atomique d'un JSON Patch en Python
Écrivez une implémentation Python 3.11 d'une fonction nommée apply_json_patch(document, patch) qui applique une séquence d'opérations de type JSON Patch à une valeur compatible JSON et retourne la valeur patchée. Le document d'entrée peut être n'importe quelle combinaison de dict, list, str, int, float, bool et None. Le patch est une liste de dictionnaires d'opérations. L'implémentation ne doit pas muter le document original ni aucun objet imbriqué accessible depuis celui-ci. Si une opération est invalide, la fonction doit lever une exception personnalisée nommée JsonPatchError et laisser le document original inchangé. Les opérations prises en charge sont add, remove, replace, move, copy et test. Utilisez des chemins JSON Pointer avec des jetons séparés par des slash, où la chaîne vide identifie l'ensemble du document, les jetons décodent ~1 en / et ~0 en ~, et toute autre utilisation de ~ est invalide. Pour les objets, un jeton de chemin est une clé. Pour les tableaux, un jeton de chemin doit être un entier non négatif sans zéros en tête sauf le jeton unique 0 ; pour add seulement, le jeton final peut être - pour ajouter à la fin. L'opération add insère dans les tableaux à un index de 0 à len(array), ajoute pour -, définit une clé d'objet, ou remplace l'ensemble du document pour le chemin vide. L'opération remove exige que la cible existe et la supprime. L'opération replace exige que la cible existe et la remplace. L'opération move exige from et path, supprime la valeur à from et l'ajoute à path, et doit rejeter le déplacement d'une valeur vers l'un de ses propres descendants. L'opération copy exige from et path et effectue une copie profonde (deep-copy) de la valeur source vers la cible. L'opération test exige value et ne réussit que si la cible courante est profondément égale (deeply equal) à value, y compris l'égalité Python normale pour les nombres et l'égalité exacte pour les chaînes, les booléens et None. Chaque dictionnaire d'opération doit contenir exactement les champs requis pour cette opération plus le champ op ; les champs inconnus ou manquants sont des erreurs. La fonction doit être déterministe, raisonnablement efficace et ne reposer que sur la bibliothèque standard Python. Incluez toutes les fonctions ou classes auxiliaires nécessaires. N'écrivez pas de programme en ligne de commande et n'utilisez pas de paquets externes.
Programmation
Implémenter un ordonnanceur de tâches basé sur les dépendances en Python
Écrivez une fonction ou une classe Python qui planifie une liste de tâches en fonction de leurs dépendances. L'ordonnanceur doit déterminer l'ordre dans lequel les tâches peuvent être exécutées, en regroupant les tâches qui peuvent s'exécuter en parallèle. L'entrée sera une liste de dictionnaires, où chaque dictionnaire représente une tâche avec les clés suivantes : id : un identifiant unique de type chaîne pour la tâche. name : un nom de la tâche sous forme de chaîne. dependencies : une liste d'identifiants (chaînes) des tâches qui doivent être terminées avant que cette tâche puisse commencer. Votre implémentation doit : Prendre la liste de dictionnaires de tâches en entrée. Retourner un plan d'exécution valide sous forme d'une liste de listes. Chaque liste interne représente un "lot" (batch) de tâches qui peuvent être exécutées simultanément. L'ordre des lots représente l'ordre d'exécution séquentiel. L'ordre des identifiants de tâches au sein d'un lot n'a pas d'importance. Détecter et gérer les dépendances circulaires. Si un cycle est détecté, la fonction doit lever une ValueError avec un message descriptif. Détecter et gérer les cas où un identifiant de dépendance ne correspond à aucune tâche existante. Cela doit également lever une ValueError.
Programmation
Limiteur de débit avec fenêtre glissante et tolérance de rafale
Concevez et implémentez un limiteur de débit sûr pour les threads dans un langage de votre choix (Python, Go, Java, TypeScript ou Rust) qui prend en charge les exigences suivantes : Surface de l'API : Exposez au moins ces opérations : allow(client_id: str, cost: int = 1) -> bool — retourne si la requête est autorisée immédiatement. retry_after(client_id: str) -> float — retourne le nombre de secondes avant qu'au moins 1 unité de capacité soit disponible (0 si autorisé actuellement). Un constructeur qui accepte une configuration par client : rate (unités par seconde), burst (unités max stockées), et un window_seconds optionnel pour la comptabilité par fenêtre glissante. Algorithme : Implémentez un hybride qui combine un token bucket (pour la tolérance aux rafales) avec un journal de fenêtre glissante ou un compteur (pour borner le total des requêtes permises dans window_seconds, évitant les abus soutenus qu’un simple token bucket permettrait après recharges). Une requête n’est autorisée que si les deux contrôles passent. Justifiez votre choix de structure de données pour la fenêtre glissante (journal exact vs approximation à deux seaux pondérés) et discutez des compromis mémoire/précision dans un court bloc de commentaire ou une note jointe. Concurrence : Le limiteur sera sollicité par de nombreux threads/goroutines concurrentement pour le même client_id et pour des client_id différents. Évitez qu’un verrou global unique devienne un goulot d’étranglement (par ex. verrous par client ou lock striping). Documentez pourquoi votre approche est correcte sous des appels allow concurrents (pas de double-dépense de jetons, pas de mises à jour perdues). Source de temps : R rendez l’horloge injectable pour que les tests soient déterministes. Utilisez par défaut une horloge monotone. Cas limites à traiter explicitement : cost plus grand que burst (doit être rejeté, ne jamais bloquer indéfiniment). Horloge reculant ou pauses longues (par ex. VM suspendue) : plafonner plutôt que planter, et ne pas accorder de jetons illimités. Première requête pour un client nouveau (initialisation paresseuse). Nettoyage des clients obsolètes (la mémoire ne doit pas croître indéfiniment si des clients arrêtent d’appeler). Jetons fractionnaires / timing sous-millisecondes. Tests : Fournissez au moins 6 tests unitaires utilisant l’horloge injectable qui couvrent : autorisation/refus de base, vidage de rafale et recharge, plafond de la fenêtre glissante indépendant de la recharge du seau, cost > burst, contention concurrente sur un seul client (propriété déterministe : total permis en T secondes ≤ rate*T + burst), et éviction des clients obsolètes. Complexité : Indiquez la complexité en temps amortie de allow et la complexité mémoire par client. Livrables : code exécutable complet (un seul fichier convient, mais vous pouvez scinder si vous les étiquetez clairement), les tests, et une brève note de conception (max ~250 mots) expliquant vos choix et la sémantique précise lorsque les deux algorithmes sont en désaccord.