Prompt Kimi K3 vs GLM5.2 vs Fable 5 vs GPT5.6 Sol
juillet 2026 · 26 min de lecture
01 — Générer l’environnement de l’épreuve de construction
Tu es chargé de créer un environnement de benchmark reproductible pour comparer plusieurs modèles d’IA capables de coder.
Ta mission n’est PAS de construire l’application attendue. Tu dois uniquement préparer le dossier de départ qui sera remis à chaque modèle candidat.
## Objectif de l’épreuve
Chaque modèle devra construire de zéro une application web de gestion de projets à partir du même brief, des mêmes données et des mêmes contraintes.
L’épreuve doit permettre de comparer :
- la compréhension du besoin ;
- la qualité fonctionnelle ;
- la qualité de l’interface ;
- la pertinence de l’architecture ;
- la persistance des données ;
- l’autonomie du modèle ;
- le temps et le coût nécessaires pour obtenir un résultat fonctionnel.
## Structure à générer
Crée le répertoire suivant :
benchmark-01-construction/
├── candidate-workspace/
│ ├── BRIEF.md
│ ├── RULES.md
│ ├── ACCEPTANCE-CRITERIA.md
│ ├── seed/
│ │ └── initial-data.json
│ ├── assets/
│ │ └── README.md
│ └── .gitignore
├── operator/
│ ├── README-OPERATOR.md
│ ├── SCORECARD.md
│ └── session-template.json
└── README.md
Le dossier `candidate-workspace` sera le seul dossier accessible au modèle testé.
Le dossier `operator` est réservé à l’organisateur du benchmark.
Ne crée aucune solution, aucun composant d’application et aucun exemple de code donnant directement l’architecture à utiliser.
## Contenu du brief candidat
Dans `BRIEF.md`, rédige le brief suivant de manière professionnelle et suffisamment précise :
Le candidat doit construire une application web de gestion de projets appelée provisoirement « FocusFlow ».
L’utilisateur doit pouvoir :
1. consulter la liste de ses projets ;
2. créer un nouveau projet ;
3. ouvrir un projet pour afficher ses tâches ;
4. créer, modifier et supprimer une tâche ;
5. faire passer une tâche entre les statuts « À faire », « En cours » et « Terminée » ;
6. visualiser la progression de chaque projet ;
7. retrouver ses données après une actualisation de la page ;
8. utiliser correctement l’application sur ordinateur et sur mobile.
Le tableau de bord doit permettre de voir rapidement :
- le nombre de projets actifs ;
- le nombre de tâches restantes ;
- les tâches à réaliser aujourd’hui ;
- les projets ou tâches en retard ;
- la progression globale.
Aucune authentification n’est demandée.
Aucune API externe payante ne doit être nécessaire.
Le candidat est libre de choisir sa stack technique.
Il doit cependant produire une application exécutable localement et documenter clairement les commandes nécessaires.
## Contraintes techniques communes
Dans `RULES.md`, indique les règles suivantes :
- L’application doit pouvoir fonctionner localement.
- La commande de lancement doit être documentée.
- L’application doit être accessible sur le port 3000.
- Si plusieurs services sont nécessaires, une commande unique doit permettre de les lancer.
- Les données doivent rester présentes après une actualisation du navigateur.
- Aucun service cloud propriétaire ne doit être obligatoire.
- Aucun compte utilisateur externe ne doit être nécessaire.
- Aucun contenu distant indispensable ne doit être chargé au moment de l’évaluation.
- Les erreurs doivent être visibles et compréhensibles.
- L’interface doit être utilisable à une largeur de 390 pixels.
- Le candidat peut installer les dépendances nécessaires.
- Le candidat ne doit pas modifier les fichiers du dossier `seed`.
- Le candidat doit créer un fichier `CANDIDATE-REPORT.md` à la fin de son travail.
## Rapport demandé au candidat
Dans les consignes, impose la création d’un fichier `CANDIDATE-REPORT.md` contenant :
- la stack technique choisie ;
- les commandes d’installation et de lancement ;
- les fonctionnalités implémentées ;
- les fonctionnalités éventuellement incomplètes ;
- les décisions d’architecture importantes ;
- les hypothèses faites ;
- les tests exécutés ;
- les limites connues.
## Données initiales
Crée un fichier `seed/initial-data.json` avec des données réalistes et déterministes.
Il doit contenir au minimum :
- 4 projets ;
- 18 tâches ;
- différents statuts ;
- plusieurs priorités ;
- certaines échéances passées ;
- certaines échéances correspondant à la date logique du benchmark ;
- plusieurs tâches terminées ;
- au moins un projet sans tâche.
Utilise une date de référence fixe dans les données, par exemple le 15 juillet 2026, afin que les résultats restent reproductibles.
Ne dépends jamais de la date réelle de la machine.
## Critères d’acceptation publics
Dans `ACCEPTANCE-CRITERIA.md`, indique uniquement les critères visibles par le candidat :
- l’application démarre correctement ;
- la liste des projets est visible ;
- un projet peut être créé ;
- une tâche peut être créée, modifiée et supprimée ;
- le statut d’une tâche peut être changé ;
- la progression est mise à jour correctement ;
- les données résistent à une actualisation ;
- les données initiales peuvent être chargées ;
- l’interface reste utilisable sur mobile ;
- aucune erreur bloquante n’apparaît dans la console pendant le parcours principal.
Ne révèle aucune information concernant les futurs tests automatisés.
## Grille opérateur
Dans `operator/SCORECARD.md`, prépare une grille sur 100 points :
- fonctionnalités principales : 30 points ;
- fiabilité et absence de bugs : 20 points ;
- expérience utilisateur : 15 points ;
- qualité et maintenabilité du code : 10 points ;
- autonomie du modèle : 10 points ;
- respect du brief : 5 points ;
- rapidité d’exécution : 5 points ;
- coût total : 5 points.
Ajoute pour chaque catégorie :
- les critères observables ;
- les éléments de preuve attendus ;
- les cas justifiant zéro point ;
- les critères permettant d’obtenir la totalité des points.
## Suivi de chaque session
Dans `operator/session-template.json`, prévois les champs suivants :
- model_name ;
- model_provider ;
- model_configuration ;
- harness_name ;
- start_time ;
- end_time ;
- total_duration_seconds ;
- input_tokens ;
- output_tokens ;
- cached_tokens ;
- total_api_cost ;
- number_of_human_interventions ;
- number_of_correction_prompts ;
- first_run_success ;
- features_passed ;
- features_failed ;
- notes.
## Documentation opérateur
Dans `operator/README-OPERATOR.md`, explique :
1. comment dupliquer un environnement propre pour chaque candidat ;
2. comment empêcher le candidat d’accéder au dossier opérateur ;
3. comment démarrer et arrêter le chronomètre ;
4. comment consigner chaque intervention humaine ;
5. comment nettoyer complètement l’environnement entre deux modèles ;
6. comment vérifier que les quatre candidats reçoivent exactement les mêmes fichiers ;
7. comment archiver le résultat de chaque session.
## Exigences finales
- Tous les documents doivent être rédigés en français.
- Le benchmark doit être utilisable sur Linux, macOS et Windows avec WSL.
- N’ajoute aucune solution cachée dans le dossier candidat.
- Ne choisis aucune stack à la place des modèles candidats.
- Vérifie que les fichiers JSON sont valides.
- Termine en affichant l’arborescence créée et un résumé des décisions prises.
02 — Générer la batterie de tests fonctionnels
Tu es chargé de créer la batterie d’évaluation automatisée d’un benchmark comparant plusieurs applications produites par des modèles d’IA.
Les applications candidates peuvent utiliser des technologies différentes. Les tests doivent donc être réalisés principalement en boîte noire depuis le navigateur.
L’application évaluée sera accessible sur :
http://localhost:3000
Ta mission est de créer un système de test reproductible, documenté et indépendant de la stack utilisée par le candidat.
## Structure à générer
Crée :
benchmark-02-functional-evaluator/
├── public/
│ ├── TESTING-CONTRACT.md
│ └── accessibility-recommendations.md
├── private/
│ ├── tests/
│ │ ├── startup.spec.ts
│ │ ├── projects.spec.ts
│ │ ├── tasks.spec.ts
│ │ ├── persistence.spec.ts
│ │ ├── progress.spec.ts
│ │ ├── responsive.spec.ts
│ │ └── stability.spec.ts
│ ├── fixtures/
│ │ └── benchmark-data.json
│ ├── scoring/
│ │ └── score-map.json
│ └── playwright.config.ts
├── scripts/
│ ├── run-evaluation.mjs
│ ├── wait-for-app.mjs
│ └── generate-report.mjs
├── reports/
│ └── .gitkeep
├── package.json
├── README.md
└── .gitignore
Utilise Playwright avec TypeScript.
Le dossier `private` ne devra jamais être remis au modèle candidat.
## Principes de test
Les tests doivent :
- fonctionner sans connaître React, Vue, Next.js ou une autre stack ;
- privilégier les rôles accessibles, labels, textes et noms de boutons ;
- éviter les sélecteurs CSS dépendant de l’implémentation ;
- tolérer de petites différences de formulation ;
- capturer une capture d’écran lorsqu’un test échoue ;
- produire une vidéo ou une trace Playwright pour les échecs ;
- enregistrer les erreurs de console ;
- enregistrer les requêtes réseau en échec ;
- ne pas modifier directement les fichiers du candidat ;
- pouvoir être relancés plusieurs fois avec le même résultat.
Lorsqu’un élément ne peut pas être trouvé par un rôle accessible, le test peut utiliser un sélecteur de secours, mais il doit le signaler dans le rapport.
## Tests à implémenter
### 1. Démarrage
Vérifier que :
- le serveur répond en moins de 60 secondes ;
- la page principale retourne un statut valide ;
- aucune page d’erreur générique n’est affichée ;
- le contenu principal est visible ;
- aucune erreur JavaScript bloquante n’apparaît.
### 2. Consultation des projets
Vérifier que :
- une liste de projets ou un tableau de bord est visible ;
- les données initiales peuvent être affichées ;
- au moins un projet peut être ouvert ;
- le nom, la progression ou les tâches du projet sont visibles.
### 3. Création d’un projet
Créer un projet avec un nom unique :
`Projet benchmark 2026`
Vérifier que :
- le projet apparaît dans l’interface ;
- aucune duplication n’est créée ;
- le projet peut être rouvert ;
- il reste présent après une actualisation.
### 4. Gestion des tâches
Dans le projet créé :
- créer une tâche ;
- modifier son titre ;
- lui attribuer une échéance ;
- changer son statut ;
- la supprimer.
Vérifier chaque état dans l’interface.
Utiliser des valeurs déterministes :
- titre initial : `Préparer la démonstration`
- titre modifié : `Préparer la démonstration finale`
- échéance : `2026-07-20`
### 5. Progression
Créer exactement quatre tâches :
- deux terminées ;
- une en cours ;
- une à faire.
Vérifier que la progression affichée correspond à 50 % si le calcul repose sur les tâches terminées.
Le test doit accepter les représentations suivantes :
- `50 %`
- `50%`
- une valeur de barre de progression accessible équivalente.
Il doit refuser une valeur manifestement incorrecte.
### 6. Persistance
Après avoir créé un projet et plusieurs tâches :
- actualiser la page ;
- fermer puis rouvrir une nouvelle page du navigateur ;
- vérifier que les données sont toujours présentes.
Ajoute un test séparé facultatif pour vérifier la persistance après redémarrage du serveur.
Ce test facultatif ne doit pas bloquer le score principal, mais il doit apparaître comme bonus.
### 7. Responsive
Tester au minimum :
- 1440 × 900 ;
- 768 × 1024 ;
- 390 × 844.
À 390 pixels de largeur, vérifier que :
- aucun défilement horizontal majeur n’est nécessaire ;
- les boutons essentiels restent visibles ;
- les formulaires peuvent être utilisés ;
- aucun élément principal ne se superpose ;
- le texte essentiel n’est pas coupé.
Prendre une capture d’écran pleine page pour chaque largeur.
### 8. Stabilité
Pendant le parcours principal, collecter :
- erreurs JavaScript ;
- promesses rejetées ;
- erreurs réseau 4xx et 5xx ;
- erreurs d’hydratation ;
- liens ou boutons principaux sans effet.
Les erreurs attendues ou sans conséquence doivent être séparées des erreurs bloquantes.
## Barème automatisé
Crée un score maximal de 40 points :
- démarrage : 4 points ;
- affichage des données : 4 points ;
- création de projet : 6 points ;
- gestion des tâches : 10 points ;
- calcul de progression : 5 points ;
- persistance après actualisation : 5 points ;
- responsive : 4 points ;
- stabilité : 2 points.
Le fichier `score-map.json` doit associer chaque test à un nombre précis de points.
Aucun résultat partiel ne doit être accordé sans règle explicite.
## Rapport généré
La commande principale doit produire :
reports/latest/
├── summary.md
├── results.json
├── results.csv
├── screenshots/
├── traces/
└── console-errors.json
Le fichier `summary.md` doit contenir :
- le score total ;
- les tests réussis ;
- les tests échoués ;
- les points obtenus par catégorie ;
- les erreurs observées ;
- les captures d’écran correspondantes ;
- le temps d’exécution ;
- la date de l’évaluation ;
- l’URL testée.
Le fichier `results.json` doit être facilement exploitable pour générer un tableau comparatif entre plusieurs modèles.
## Commandes attendues
Prévois au minimum :
- `npm install`
- `npm run install:browsers`
- `npm run test`
- `npm run test:headed`
- `npm run report`
La commande `npm run test` doit :
1. attendre que l’application réponde ;
2. lancer les tests ;
3. collecter les résultats ;
4. calculer le score ;
5. générer le rapport final.
## Contrôle qualité
Avant de terminer :
- vérifie que le TypeScript compile ;
- vérifie que la configuration Playwright est valide ;
- vérifie que les scripts ne nécessitent aucun service externe ;
- crée une petite application factice temporaire pour valider que le système de tests se lance ;
- supprime cette application factice avant la livraison ;
- documente toutes les hypothèses.
Tous les documents et rapports humains doivent être rédigés en français.
Termine en affichant l’arborescence générée, les commandes principales et les limites éventuelles des tests en boîte noire.
03 — Générer le dépôt volontairement buggé
Tu dois générer un dépôt de code volontairement buggé pour comparer la capacité de plusieurs modèles d’IA à comprendre et réparer une application existante.
Tous les modèles candidats recevront exactement le même dépôt.
Le projet doit être réaliste, simple à exécuter et suffisamment bien structuré pour que les bugs ne proviennent pas d’un code volontairement absurde.
## Objectif
Créer une application de gestion de projets comportant exactement cinq bugs fonctionnels connus.
Le modèle candidat devra :
- examiner le projet ;
- reproduire les problèmes ;
- identifier leurs causes ;
- corriger les cinq bugs ;
- éviter les régressions ;
- documenter son travail.
## Stack imposée pour cette épreuve
Utilise une stack volontairement commune et accessible :
- Node.js 22 ;
- TypeScript ;
- React ;
- Vite ;
- Express ;
- SQLite ;
- Vitest ;
- Playwright ;
- pnpm avec workspaces.
Aucun service cloud ne doit être requis.
## Structure du projet
Crée :
benchmark-03-debug/
├── candidate-workspace/
│ ├── apps/
│ │ ├── web/
│ │ └── api/
│ ├── packages/
│ │ ├── shared/
│ │ └── database/
│ ├── tests/
│ │ ├── public/
│ │ └── helpers/
│ ├── fixtures/
│ ├── CHALLENGE.md
│ ├── README.md
│ ├── package.json
│ ├── pnpm-workspace.yaml
│ ├── tsconfig.base.json
│ └── .gitignore
├── private-evaluator/
│ ├── tests/
│ ├── BUG-MAP.md
│ ├── SCORECARD.md
│ └── run-private-tests.mjs
└── operator/
└── README-OPERATOR.md
Le candidat n’aura accès qu’à `candidate-workspace`.
## Application attendue
L’application doit déjà fonctionner globalement et permettre :
- d’afficher plusieurs projets ;
- d’ouvrir un projet ;
- de créer des tâches ;
- de changer leur statut ;
- de supprimer des tâches ;
- de voir une progression ;
- de stocker les données dans SQLite ;
- de consulter l’application sur mobile.
L’interface doit être propre et crédible, sans être excessivement sophistiquée.
Ajoute des données initiales reproductibles.
## Les cinq bugs à intégrer
Intègre exactement les cinq problèmes suivants.
### Bug 1 — Suppression cassée
Symptôme visible :
Lorsqu’un utilisateur clique sur le bouton de suppression d’une tâche, l’action échoue ou supprime la mauvaise tâche.
Cause technique attendue :
Une incohérence réaliste entre le paramètre transmis par le front-end et le paramètre attendu par la route API.
La cause ne doit pas être signalée dans le code.
### Bug 2 — Création en double
Symptôme visible :
Une tâche peut être créée deux fois après une seule interaction dans certaines conditions reproductibles.
Cause technique attendue :
Une combinaison réaliste entre un double déclenchement côté interface et une absence de protection côté serveur.
Le bug doit être reproductible de manière déterministe dans les tests privés.
### Bug 3 — Mauvais calcul de progression
Symptôme visible :
Le pourcentage de progression d’un projet devient incorrect lorsque certaines tâches sont archivées ou supprimées.
Cause technique attendue :
Le calcul utilise le mauvais dénominateur ou inclut une catégorie qui devrait être exclue.
Le résultat incorrect doit être plausible, pas complètement aléatoire.
### Bug 4 — Perte de données après redémarrage
Symptôme visible :
Les données semblent persister après une actualisation du navigateur, mais disparaissent lorsque le serveur API redémarre.
Cause technique attendue :
Le processus réinitialise ou recrée incorrectement la base à chaque démarrage.
La base doit réellement utiliser SQLite, mais le cycle d’initialisation doit contenir l’erreur.
### Bug 5 — Interface mobile cassée
Symptôme visible :
À une largeur de 390 pixels, une partie importante de l’interface devient inaccessible ou provoque un débordement horizontal majeur.
Cause technique attendue :
Une contrainte CSS réaliste, par exemple une largeur minimale excessive, une grille rigide ou une barre latérale mal gérée.
Le problème ne doit pas être visible sur un écran large.
## Règles de qualité des bugs
- Chaque bug doit posséder une cause distincte.
- Aucun bug ne doit dépendre d’une connexion Internet.
- Aucun bug ne doit dépendre du hasard.
- Aucun bug ne doit empêcher totalement le lancement du projet.
- La correction d’un bug ne doit pas automatiquement corriger les quatre autres.
- Les bugs doivent ressembler à des erreurs de développement réelles.
- N’ajoute aucun commentaire contenant les mots « bug », « fix », « solution » ou équivalent près des causes.
- Ne laisse aucun nom de variable révélant directement le problème.
- Le code non concerné doit être raisonnablement propre.
- Les cinq problèmes doivent être vérifiables automatiquement.
## Consignes visibles par le candidat
Dans `CHALLENGE.md`, décris uniquement les cinq symptômes :
1. la suppression d’une tâche ne fonctionne pas correctement ;
2. certaines créations produisent des doublons ;
3. la progression peut afficher une mauvaise valeur ;
4. les données disparaissent après un redémarrage ;
5. l’interface est inutilisable sur certains écrans mobiles.
Ne donne aucune piste sur les causes techniques.
Demande au candidat :
- de reproduire chaque problème ;
- de corriger les cinq problèmes ;
- d’ajouter ou mettre à jour les tests ;
- de ne pas remplacer l’application par une nouvelle version ;
- de ne pas changer de stack ;
- de ne pas désactiver les fonctionnalités ;
- de ne pas contourner les tests ;
- de créer un fichier `DEBUG-REPORT.md`.
## Rapport candidat
Le fichier `DEBUG-REPORT.md` devra indiquer pour chaque problème :
- la cause identifiée ;
- les fichiers modifiés ;
- la correction appliquée ;
- le test permettant de vérifier la correction ;
- les risques de régression ;
- les éventuelles limites restantes.
## Tests publics
Ajoute quelques tests publics utiles, mais ne couvre pas directement les cinq causes.
Les tests publics doivent vérifier :
- que le projet démarre ;
- que l’API répond ;
- qu’un projet peut être consulté ;
- qu’une tâche simple peut être affichée ;
- que la base peut être initialisée.
Ils ne doivent pas permettre de déduire facilement tous les tests privés.
## Évaluateur privé
Dans `private-evaluator`, crée des tests couvrant exactement les cinq bugs.
Chaque bug vaut 4 points, pour un total de 20 points.
Pour chaque problème, les tests doivent vérifier :
- la disparition du symptôme ;
- la conservation du comportement normal ;
- l’absence de régression évidente.
Ajoute également une détection des contournements grossiers, par exemple :
- bouton supprimé ;
- fonctionnalité désactivée ;
- données codées en dur ;
- test ignoré ;
- route retournant toujours un succès fictif.
## Carte privée des bugs
Dans `private-evaluator/BUG-MAP.md`, documente pour l’opérateur :
- le symptôme ;
- les étapes de reproduction ;
- la cause exacte ;
- les fichiers impliqués ;
- la correction minimale raisonnable ;
- les variantes de correction acceptables ;
- les tests privés associés.
Ce fichier ne doit jamais être visible par les candidats.
## Commandes
Le projet candidat doit utiliser :
- `pnpm install`
- `pnpm dev`
- `pnpm test`
- `pnpm test:e2e`
- `pnpm db:reset`
La commande `pnpm dev` doit lancer le front-end et l’API avec une seule commande.
## Validation obligatoire
Avant de terminer :
1. installe les dépendances ;
2. initialise la base ;
3. lance le projet ;
4. vérifie que le parcours principal fonctionne ;
5. vérifie que les cinq bugs sont réellement présents ;
6. vérifie que chaque test privé échoue avant correction ;
7. crée temporairement une branche ou un patch contenant les cinq corrections ;
8. vérifie que tous les tests privés passent après correction ;
9. retire complètement les corrections de la version livrée ;
10. vérifie que la version finale contient bien les cinq bugs.
Ne livre jamais le patch corrigé dans le dossier candidat.
Tous les documents doivent être rédigés en français.
Termine en donnant :
- l’arborescence ;
- les commandes ;
- la liste des symptômes visibles ;
- la confirmation que les cinq tests privés échouent sur la version livrée ;
- la confirmation qu’une correction de référence a permis de les faire passer.
04 — Générer l’épreuve de compréhension d’une demande client
Tu dois créer une épreuve permettant de comparer la capacité de plusieurs modèles d’IA à comprendre une demande client volontairement floue et à transformer cette demande en amélioration produit pertinente.
Cette épreuve sera appliquée séparément à chaque application construite lors de l’épreuve initiale.
Tu ne dois pas modifier directement les applications candidates. Tu dois créer le paquet de consignes, les données nécessaires et la méthode d’évaluation.
## Objectif de l’épreuve
Évaluer si le modèle est capable de :
- comprendre l’intention réelle du client ;
- identifier les informations importantes ;
- faire des hypothèses raisonnables ;
- améliorer l’interface sans tout reconstruire ;
- privilégier l’utilité plutôt que la quantité de fonctionnalités ;
- préserver les fonctionnalités existantes ;
- expliquer ses décisions.
## Message client à utiliser
Le message remis à tous les modèles doit être exactement le suivant :
« L’application est bien, mais elle manque de clarté. Quand je l’ouvre le matin, je voudrais comprendre immédiatement quels projets sont en retard et sur quoi je dois travailler aujourd’hui. Je ne veux pas avoir à ouvrir chaque projet pour le savoir. »
Ne donne aucune autre précision au modèle candidat.
Le modèle doit pouvoir poser des questions, mais l’opérateur ne lui donnera aucune réponse supplémentaire.
S’il pose des questions, l’opérateur répondra uniquement :
« Fais les hypothèses qui te paraissent les plus raisonnables, documente-les et implémente la solution que tu recommanderais à un client réel. »
## Structure à générer
Crée :
benchmark-04-client-request/
├── candidate-package/
│ ├── CLIENT-REQUEST.md
│ ├── RULES.md
│ ├── DELIVERY-CHECKLIST.md
│ └── seed-overlay.json
├── private-evaluator/
│ ├── EVALUATION-RUBRIC.md
│ ├── expected-outcomes.json
│ ├── manual-review-form.md
│ └── tests/
│ ├── regressions.spec.ts
│ ├── overdue-visibility.spec.ts
│ ├── today-priorities.spec.ts
│ └── responsive.spec.ts
└── operator/
├── README-OPERATOR.md
└── session-template.json
Le dossier `private-evaluator` ne doit jamais être accessible aux candidats.
## Données de test
Dans `seed-overlay.json`, ajoute des données destinées à rendre la demande significative :
- 5 projets actifs ;
- 2 projets en retard ;
- 1 projet sans échéance ;
- 1 projet terminé ;
- 12 tâches non terminées ;
- 4 tâches prévues pour aujourd’hui ;
- 3 tâches en retard ;
- 2 tâches avec une priorité élevée ;
- plusieurs tâches terminées ;
- une tâche sans échéance.
Utilise comme date logique fixe :
15 juillet 2026
L’évaluation ne doit jamais dépendre de la date réelle de la machine.
## Règles visibles par le candidat
Dans `RULES.md`, indique :
- le modèle doit améliorer l’application existante ;
- il ne doit pas réécrire complètement le projet ;
- il doit conserver toutes les fonctionnalités précédentes ;
- il peut modifier l’interface, la logique et les données ;
- il ne doit pas ajouter d’authentification ;
- il ne doit pas ajouter de service externe ;
- il ne doit pas ajouter plus de fonctionnalités que nécessaire ;
- il doit utiliser la date logique fournie ;
- il doit rendre le résultat utilisable sur mobile ;
- il doit documenter ses hypothèses ;
- il doit créer un fichier `CLIENT-CHANGE-REPORT.md`.
## Livrable demandé
Le fichier `CLIENT-CHANGE-REPORT.md` doit contenir :
- la reformulation du besoin ;
- les hypothèses effectuées ;
- les changements réalisés ;
- les raisons de chaque changement ;
- les fonctionnalités volontairement non ajoutées ;
- les tests effectués ;
- les risques ou limites ;
- les éventuelles questions qui auraient été posées à un vrai client.
## Résultats attendus sans les révéler au candidat
L’évaluateur privé ne doit pas exiger un design précis.
Il doit cependant considérer comme particulièrement pertinentes les solutions qui permettent de voir rapidement :
- les projets en retard ;
- les tâches en retard ;
- les tâches à réaliser aujourd’hui ;
- le niveau de priorité ;
- la prochaine action utile ;
- une synthèse accessible depuis l’écran principal.
Plusieurs solutions doivent être acceptées, notamment :
- une section « Aujourd’hui » ;
- une section « En retard » ;
- un tableau de bord réorganisé ;
- un système de filtres directement visible ;
- une liste de priorités ;
- des indicateurs sur les cartes de projets ;
- une combinaison raisonnable de ces éléments.
L’évaluation ne doit jamais imposer une fonctionnalité exacte si une autre solution répond aussi bien au besoin.
## Signaux positifs
Le barème doit valoriser :
- une hiérarchie visuelle claire ;
- une compréhension immédiate de l’urgence ;
- une distinction claire entre « aujourd’hui » et « en retard » ;
- des informations actionnables ;
- un nombre limité d’éléments importants ;
- une bonne utilisation sur mobile ;
- la conservation des fonctions existantes ;
- des hypothèses explicitement documentées ;
- une implémentation cohérente avec l’architecture existante.
## Signaux négatifs
Le barème doit pénaliser :
- une simple modification cosmétique sans information nouvelle ;
- l’ajout de nombreuses fonctionnalités sans rapport ;
- une refonte complète injustifiée ;
- la suppression de fonctions existantes ;
- une liste surchargée et difficile à comprendre ;
- l’utilisation de la date réelle au lieu de la date logique ;
- des données codées en dur uniquement pour réussir la démonstration ;
- des régressions ;
- une solution uniquement fonctionnelle sur grand écran ;
- des éléments « urgents » sans critère compréhensible ;
- des choix non documentés.
## Barème sur 30 points
Crée une grille privée détaillée :
### Compréhension du besoin — 8 points
- identification correcte de la nécessité d’une vue synthétique ;
- distinction entre retard et travail du jour ;
- prise en compte de l’absence de navigation projet par projet ;
- hypothèses raisonnables.
### Utilité de la solution — 8 points
- informations immédiatement exploitables ;
- priorisation pertinente ;
- accès rapide aux tâches concernées ;
- clarté des états.
### Qualité de l’expérience — 5 points
- hiérarchie visuelle ;
- lisibilité ;
- responsive ;
- absence de surcharge.
### Qualité de l’implémentation — 4 points
- cohérence avec le projet ;
- données calculées correctement ;
- pas de valeurs codées en dur ;
- code raisonnablement maintenable.
### Absence de régressions — 3 points
- création, modification et suppression toujours fonctionnelles ;
- progression toujours correcte ;
- persistance toujours présente.
### Sobriété de la réponse — 2 points
- absence de fonctionnalités inutiles ;
- modification proportionnée à la demande.
## Tests privés
Crée des tests Playwright en boîte noire qui vérifient au minimum :
- qu’un projet en retard est identifiable depuis l’écran principal ;
- qu’une tâche du jour est identifiable depuis l’écran principal ;
- qu’une tâche en retard est identifiable ;
- que les informations changent si les données changent ;
- qu’aucune valeur n’est simplement codée en dur ;
- que les fonctionnalités principales précédentes fonctionnent toujours ;
- que l’interface reste utilisable à 390 pixels de largeur.
Les tests ne doivent pas dépendre d’un texte exact.
Ils doivent accepter plusieurs formulations françaises équivalentes et plusieurs structures visuelles possibles.
Lorsqu’un critère ne peut pas être évalué automatiquement, il doit être ajouté au formulaire de revue manuelle.
## Revue manuelle
Dans `manual-review-form.md`, crée une grille permettant à deux évaluateurs humains de noter indépendamment :
- la compréhension immédiate de l’écran ;
- la pertinence des priorités affichées ;
- la clarté des décisions ;
- la surcharge éventuelle ;
- la qualité mobile ;
- la cohérence avec le reste du produit.
Utilise une échelle définie et illustrée de 0 à 4.
Prévois une méthode de résolution lorsqu’il existe plus de deux points d’écart entre les évaluateurs.
## Procédure opérateur
Dans `README-OPERATOR.md`, explique :
1. comment copier le paquet candidat dans chaque projet ;
2. comment injecter les mêmes données ;
3. comment formuler la réponse standard aux questions ;
4. comment mesurer le temps ;
5. comment compter les interventions ;
6. comment exécuter les tests privés ;
7. comment organiser la revue manuelle ;
8. comment agréger le score ;
9. comment conserver des captures avant et après ;
10. comment éviter que l’ordre de passage influence la notation.
## Fichier de session
Le fichier `session-template.json` doit prévoir :
- model_name ;
- start_time ;
- end_time ;
- duration_seconds ;
- questions_asked ;
- human_interventions ;
- files_modified ;
- tests_run_by_candidate ;
- automated_score ;
- reviewer_1_score ;
- reviewer_2_score ;
- final_score ;
- regressions_detected ;
- summary_of_solution ;
- notes.
## Validation finale
Avant de terminer :
- vérifie la validité du JSON ;
- vérifie que les tests peuvent être adaptés à différentes stacks ;
- vérifie que le barème accepte plusieurs bonnes solutions ;
- vérifie qu’aucune solution précise n’est révélée dans le dossier candidat ;
- documente clairement les critères nécessitant une évaluation humaine.
Tous les documents doivent être rédigés en français.
Termine en affichant l’arborescence, le barème et un résumé des éléments publics et privés.