Programmation
Explorez la performance des modeles IA en Programmation. Comparez classements, criteres de notation et benchmarks recents.
Vue d ensemble du genre
Compare la justesse, la qualité et l’utilité pratique du code généré.
Dans ce genre, les capacites surtout observees sont Exactitude, Completude, Qualite du code.
Contrairement a system design, ce genre regarde davantage si le code fonctionne reellement que les choix d architecture de haut niveau.
Un score eleve ici ne garantit ni meilleur jugement produit, ni meilleure architecture, ni meilleures explications pour debutants.
Usages adaptes aux modeles forts dans ce genre
implementation, debogage, refactorisation et aide pratique a la programmation.
Ce que ce genre ne permet pas de juger a lui seul
si le modele est meilleur pour l architecture, les documents pour parties prenantes ou l ideation ouverte.
Classement des modeles forts dans ce genre
Ce classement est trie par score moyen uniquement dans ce genre.
Derniere mise a jour: 12 May 2026 09:45
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
Taux de victoire
Score moyen
| Modeles classes | Detail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.2 Retire | OpenAI |
100%
|
89
|
6 | 6 | Voir l evaluation et le score de GPT-5.2 |
| #2 | GPT-5.5 NOUVEAU | OpenAI |
100%
|
89
|
1 | 1 | Voir l evaluation et le score de GPT-5.5 |
| #3 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Voir l evaluation et le score de GPT-5 mini |
| #4 | GPT-5.4 NOUVEAU | OpenAI |
75%
|
84
|
6 | 8 | Voir l evaluation et le score de GPT-5.4 |
| #5 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Voir l evaluation et le score de Claude Sonnet 4.6 |
| #6 | Claude Opus 4.6 Retire | Anthropic |
33%
|
84
|
1 | 3 | Voir l evaluation et le score de Claude Opus 4.6 |
| #7 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Voir l evaluation et le score de Gemini 2.5 Pro | |
| #8 | Gemini 2.5 Flash |
0%
|
73
|
0 | 4 | Voir l evaluation et le score de Gemini 2.5 Flash | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Voir l evaluation et le score de Gemini 2.5 Flash-Lite | |
| #10 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 4 | Voir l evaluation et le score de Claude Haiku 4.5 |
Ce qui est evalue dans Programmation
Criteres et poids utilises pour ce classement par genre.
Exactitude
35.0%
Ce critere est present pour verifier Exactitude 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.
Qualite du code
20.0%
Ce critere est present pour verifier Qualite du code 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.
Valeur pratique
15.0%
Ce critere est present pour verifier Valeur pratique dans la reponse. Il est plus legerement pondere parce qu il soutient l objectif principal sans definir a lui seul le genre.
Respect des consignes
10.0%
Ce critere est present pour verifier Respect des consignes dans la reponse. Il est plus legerement pondere parce qu il soutient l objectif principal sans definir a lui seul le genre.
Taches recentes
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 : 1. **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. 2. **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. 3. **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). 4. **Source de temps** : R rendez l’horloge injectable pour que les tests soient déterministes. Utilisez par défaut une horloge monotone. 5. **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. 6. **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. 7. **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.
Programmation
Convertisseur d'un sous-ensemble Markdown vers HTML
Écrivez une fonction Python `markdown_to_html(markdown_text: str) -> str` qui convertit une chaîne contenant un sous-ensemble spécifique de Markdown en sa représentation HTML correspondante. La fonction doit prendre en charge les fonctionnalités suivantes : **Éléments de bloc :** 1. **En-têtes :** Les lignes commençant par `# ` à `###### ` doivent être converties en balises `<h1>` à `<h6>`. 2. **Listes non ordonnées :** Les lignes commençant par `- ` doivent être converties en balises `<ul>` et `<li>`. Les listes imbriquées, indentées de deux espaces par niveau, doivent être prises en charge. Une liste se termine par une ligne vide ou un autre élément de bloc. 3. **Blocs de code :** Le contenu encadré entre des lignes de triple backticks (```) doit être converti en `<pre><code>...</code></pre>`. Le spécificateur de langage sur les backticks d'ouverture (par exemple, ```python) doit être ignoré. Aucune autre transformation Markdown ne doit se produire à l'intérieur d'un bloc de code. 4. **Paragraphes :** Tout autre texte doit être enveloppé dans des balises `<p>`. Les lignes consécutives de texte appartiennent au même paragraphe. Les paragraphes sont séparés par une ou plusieurs lignes vides. **Éléments en ligne :** 1. **Gras et italique :** `***text***` doit être converti en `<strong><em>text</em></strong>`. 2. **Gras :** `**text**` doit être converti en `<strong>text</strong>`. 3. **Italique :** `*text*` doit être converti en `<em>text</em>`. **Règles et contraintes :** - Les éléments en ligne peuvent être imbriqués dans les en-têtes et les éléments de liste. - Le parseur doit être robuste face à des entrées malformées ou délicates, telles que des balises en ligne non fermées. Par exemple, `*italic` doit être rendu comme `<p>*italic</p>`. - L'ordre de priorité pour les éléments en ligne est `***`, puis `**`, puis `*`. - Supposerez que l'entrée est une unique chaîne multilignes. - N'implémentez pas la prise en charge d'autres fonctionnalités Markdown comme les liens, images, blockquotes, ou les listes ordonnées. - Le HTML de sortie n'a pas besoin d'être un document complet (les balises `<html>` ou `<body>` ne sont pas requises). **Exemple d'entrée :** ```markdown # En-tête 1 Ceci est un paragraphe avec **gras** et *italique*. Ceci est le même paragraphe. - Élément de liste un - Élément de liste deux avec ***gras et italique*** - Élément de liste imbriquée - Retour au premier niveau ```python def hello(): print("Bonjour le monde !") ``` ```
Programmation
Implémenter un limiteur de débit Token Bucket thread-safe en Python
Écrivez une classe Python nommée `TokenBucketRateLimiter` qui implémente l'algorithme du token bucket pour la limitation de débit. L'implémentation doit être thread-safe et ne doit pas utiliser de bibliothèques externes pour la gestion d'état (comme Redis). La classe doit respecter les spécifications suivantes : 1. Une méthode `__init__(self, capacity, refill_rate)` : * `capacity` : Le nombre maximal de jetons que le seau peut contenir. * `refill_rate` : Le nombre de jetons qui sont ajoutés au seau par seconde. 2. Une méthode `consume(self, tokens)` : * Cette méthode tente de consommer un nombre donné de `tokens` depuis le seau. * Elle doit retourner `True` si les jetons peuvent être consommés avec succès, et `False` sinon. * Le seau doit être re-rempli avec des jetons en fonction du temps écoulé depuis le dernier appel avant d'essayer de consommer. 3. Sécurité des threads : * La classe doit être sûre à utiliser depuis plusieurs threads concurrents. Toutes les opérations qui modifient l'état du seau (comme le remplissage et la consommation de jetons) doivent être atomiques. Fournissez l'implémentation complète de la classe avec les imports nécessaires.
Programmation
Outil de synchronisation de fichiers en ligne de commande
Écrivez un script Python pour un outil de synchronisation de fichiers en ligne de commande. Le script doit accepter trois arguments en ligne de commande : 1. `source_path` : Le chemin vers le répertoire source. 2. `replica_path` : Le chemin vers le répertoire réplique qui sera synchronisé. 3. `log_file_path` : Le chemin vers un fichier où toutes les opérations seront consignées. Fonctionnalité principale : 1. **Synchronisation unidirectionnelle :** L’outil doit effectuer une synchronisation unidirectionnelle, faisant du répertoire `replica_path` une copie exacte du répertoire `source_path`. - Les fichiers et répertoires présents dans la source mais pas dans la réplique doivent être copiés dans la réplique. - Les fichiers et répertoires présents dans la réplique mais pas dans la source doivent être supprimés de la réplique. - Les fichiers présents aux deux emplacements mais dont le contenu diffère doivent être mis à jour dans la réplique (la version source écrase la version réplique). 2. **Détection des modifications :** Utilisez le hachage MD5 du contenu des fichiers pour déterminer si un fichier doit être mis à jour. Ne vous fiez pas aux horodatages de modification. 3. **Journalisation :** Consignez toutes les opérations sur les fichiers (par exemple, "COPIER file.txt", "SUPPRIMER old_dir", "METTRE À JOUR changed.log") à la fois sur la console et dans le fichier de journal spécifié. Chaque entrée du journal doit être horodatée. 4. **Exécution :** Le script doit effectuer l’opération de synchronisation exactement une fois puis se terminer. Il ne doit pas fonctionner en boucle. Exigences : - Utiliser Python 3. - Utiliser la bibliothèque `argparse` pour l’analyse des arguments en ligne de commande. - La solution doit gérer correctement les répertoires imbriqués, les répertoires vides et les fichiers de tailles variées. - Le script doit être un fichier unique et autonome.
Programmation
Implémenter un cache LRU concurrent sans verrou global
Implémentez un cache LRU (Least Recently Used) thread-safe en Python qui prend en charge des lectures et écritures concurrentes sans utiliser un verrou global pour chaque opération. Votre implémentation doit satisfaire aux exigences suivantes : 1. **Interface**: Le cache doit prendre en charge ces opérations : - `__init__(self, capacity: int)` — Initialiser le cache avec une capacité maximale donnée (entier positif). - `get(self, key: str) -> Optional[Any]` — Retourner la valeur associée à la clé si elle existe (et la marquer comme récemment utilisée), ou retourner `None` si la clé n'est pas dans le cache. - `put(self, key: str, value: Any) -> None` — Insérer ou mettre à jour la paire clé-valeur. Si le cache dépasse la capacité après l'insertion, évincer l'élément le moins récemment utilisé. - `delete(self, key: str) -> bool` — Supprimer la clé du cache. Retourner `True` si la clé était présente, `False` sinon. - `keys(self) -> List[str]` — Retourner une liste de toutes les clés actuellement dans le cache, ordonnées de la plus récemment utilisée à la moins récemment utilisée. 2. **Concurrence**: Le cache doit être sûr à utiliser depuis plusieurs threads simultanément. Visez une conception qui permet aux lectures concurrentes de progresser sans se bloquer mutuellement quand c'est possible (par exemple, en utilisant des verrous lecture-écriture, des verrous à granularité fine, ou des techniques lock-free). Un mutex global unique qui sérialise chaque opération est considéré comme une solution de base mais sous-optimale. 3. **Exactitude sous contention**: En cas d'accès concurrent, le cache ne doit jamais renvoyer de données obsolètes ou corrompues, ne doit jamais dépasser la capacité annoncée et doit maintenir un ordre LRU cohérent. 4. **Cas limites à gérer**: - Capacité de 1 - `put` avec une clé qui existe déjà (doit mettre à jour la valeur et déplacer en tant que plus récent) - `delete` d'une clé qui n'existe pas - `put` et `get` concurrents sur la même clé - Évictions séquentielles rapides lorsque de nombreux threads insèrent simultanément 5. **Tests**: Inclure une fonction de test `run_tests()` qui démontre la correction de toutes les opérations en scénarios mono-thread et multi-thread. Le test multi-thread doit utiliser au moins 8 threads effectuant un mélange d'opérations `get`, `put` et `delete` sur des clés qui se chevauchent, et doit vérifier (assert) que le cache ne dépasse jamais sa capacité et que `get` ne renvoie jamais une valeur pour une clé qui n'a jamais été insérée. Fournissez votre implémentation complète en Python. N'utilisez que la bibliothèque standard (aucun paquet tiers). Incluez des docstrings et des commentaires expliquant votre stratégie de concurrence et les compromis de conception que vous avez faits.
Programmation
Analyseur avancé de fichiers journaux pour un format personnalisé
Écrivez une fonction Python `parse_log(log_content: str) -> list` qui analyse un fichier journal avec un format personnalisé. La fonction doit prendre le contenu du journal sous forme d'une seule chaîne multilignes et retourner une liste de dictionnaires, où chaque dictionnaire représente une transaction correctement terminée. **Règles du format de journal :** 1. **`START <transaction_id> <timestamp>`** : Marque le début d'une transaction. `transaction_id` est une chaîne sans espaces. `timestamp` est une chaîne au format ISO 8601. 2. **`END <transaction_id> <status> <timestamp>`** : Marque la fin d'une transaction. Le `transaction_id` doit correspondre à une transaction ouverte. `status` est un mot unique (par ex., `SUCCESS`, `FAIL`). 3. **`EVENT <key1>=<value1> <key2>="<value with spaces>" ...`** : Représente un événement au sein de la transaction active en cours. Il se compose d'une ou plusieurs paires clé-valeur. Les valeurs contenant des espaces doivent être entourées de guillemets doubles. 4. **`COMMENT # <any text>`** : Une ligne de commentaire qui doit être ignorée. **Logique de traitement :** * La fonction doit traiter les lignes de manière séquentielle. * Une ligne `EVENT` est associée à la transaction démarrée la plus récente qui n'a pas encore été terminée. * Une transaction n'est considérée complète et valide que si elle a une ligne `START` et une ligne `END` correspondantes avec le même `transaction_id`. * La sortie doit être une liste de dictionnaires. Chaque dictionnaire représente une transaction terminée et doit avoir les clés suivantes : * `transaction_id` (chaîne) * `start_time` (chaîne) * `end_time` (chaîne) * `status` (chaîne) * `events` (une liste de dictionnaires, où chaque dictionnaire intérieur représente les paires clé-valeur d'une ligne `EVENT`). **Gestion des erreurs et cas limites :** * Ignorer toutes les lignes `COMMENT`, les lignes vides ou les lignes malformées qui ne correspondent pas aux formats spécifiés. * Ignorer tout `EVENT` qui survient en dehors d'une transaction active (c.-à-d. avant le premier `START` ou après la fermeture d'une transaction). * Si une nouvelle ligne `START` apparaît avant que la transaction précédente n'ait été fermée par un `END`, la transaction précédente est considérée comme « abandonnée » et doit être rejetée. La nouvelle ligne `START` commence une nouvelle transaction. * Toute transaction encore ouverte à la fin du fichier journal est également considérée comme « abandonnée » et ne doit pas être incluse dans la sortie finale.