FLORIAN BASTIN

Évaluation pratique

Projet

01 / Présentation du projet

Chaque élève construit, seul, un agent qui répond aux questions d'une population précise à partir d'un jeu de données ouvert. Vous travaillez comme une jeune entreprise : vous partez d'un besoin réel, pas d'une technologie.

Étape 1 : trouver un besoin

Partez d'une population et de sa question, pas des données. Votre README répond à quatre questions :

  1. Qui est la population visée ?
  2. Quelle question se pose-t-elle sans trouver de réponse simple aujourd'hui ?
  3. Quelles solutions existent déjà, et quelles sont leurs limites ?
  4. Pourquoi un agent répond-il mieux qu'un tableau de bord ou un moteur de recherche ?

Exemple du niveau attendu (à ne pas reprendre) :

  • Population : les cyclistes urbains, qui veulent savoir quels axes de leur trajet sont les plus accidentogènes.
  • Données : les bases annuelles des accidents corporels de la circulation, publiées sur data.gouv.fr.
  • Limite de l'existant : les cartes montrent des points, mais ne répondent pas à « mon trajet est-il dangereux le soir ? ».

Étape 2 : choisir et réserver son jeu de données

Chaque élève a son propre jeu de données : le premier qui le réserve sur le site le garde.

La source conseillée est data.gouv.fr, la plateforme ouverte des données publiques françaises. Vous y trouverez des données sur la santé, les transports, le logement, l'éducation, l'environnement, l'emploi, etc.

Le jeu de données doit :

  • permettre de répondre aux questions de votre population ;
  • être réutilisable : vérifiez la licence indiquée sur sa page ;
  • être lisible en Python (CSV, JSON, Excel…) ;
  • tenir dans le dépôt, sinon fournir un script qui le télécharge.

Pour le réserver :

  1. Choisissez votre jeu de données.
  2. Sur la page Réserver votre jeu de données, indiquez son nom et le lien de sa page.
  3. Une fois réservé, il n'est plus disponible pour les autres élèves. Premier arrivé, premier servi.

Étape 3 : construire l'agent

Votre agent répond en langage naturel en appelant des tools que vous écrivez vous-mêmes.

  • Tools : au moins trois fonctions Python qui interrogent vos données (filtrer, agréger, chercher). Le LLM lit leur docstring pour choisir lequel appeler : soignez-la autant que le code.
  • Prompts : le system prompt décrit la population, le ton attendu et la règle principale. L'agent n'affirme aucun chiffre qui ne vient pas d'un tool.
  • Hors des données : quand la réponse n'est pas dans vos données, l'agent le dit au lieu d'inventer.
  • Comprendre la trace : pour une question donnée, vous savez dire quels tools ont été appelés, dans quel ordre et pourquoi. Pour un Deep Agent, cela inclut son plan de tâches et les fichiers qu'il écrit.

Étape 4 : évaluer avec un LLM-as-a-judge

Vous mesurez la qualité de votre agent avec un LLM qui note ses réponses à 5 questions.

  1. Écrivez 5 questions que poserait votre population, chacune avec sa réponse de référence.
  2. Calculez les références sans l'agent, dans un notebook inclus dans le dépôt. Sinon, l'agent est évalué par rapport à lui-même.
  3. Lancez l'agent sur chaque question.
  4. Envoyez au juge la question, la référence et la réponse de l'agent. Il renvoie une note et sa justification dans un format structuré.
  5. Affichez un tableau des 5 notes et la moyenne.

Parmi vos 5 questions, il faut au moins :

  • une question qui demande plusieurs étapes ;
  • une question dont la réponse n'est pas dans les données.

Terminez par une courte analyse des échecs. Les causes possibles : un tool mal décrit, un prompt ambigu, une donnée manquante, ou un juge trop sévère ou trop indulgent.

Rendu

Vous rendez un dépôt Git que l'enseignant doit pouvoir lancer du premier coup.

projet/
├── README.md          # population, besoin, données, commandes de lancement
├── requirements.txt   # dépendances du projet
├── .env.example       # GOOGLE_API_KEY=
├── .gitignore         # contient .env et .venv/
├── data/              # données ou script de téléchargement
├── src/
│   ├── tools.py
│   ├── prompts.py
│   └── agent.py
└── eval/
    ├── questions.json     # 5 questions et leurs réponses de référence
    ├── references.ipynb   # calcul des références sans l'agent
    └── judge.py

L'enseignant clone le dépôt, puis :

  1. python -m venv .venv
  2. source .venv/bin/activate
  3. pip install -r requirements.txt
  4. copie .env.example en .env et y met sa clé ;
  5. python eval/judge.py

Si une de ces étapes échoue, la partie reproductibilité vaut 0.

Règles

  • Pas d'IA pour coder. Il est interdit de générer ou de compléter du code avec une IA (ChatGPT, Gemini, Copilot, Cursor, Claude…). La documentation officielle et les supports du cours sont autorisés. Gemini sert uniquement à faire tourner votre agent.
  • Une clé Gemini personnelle. Chaque élève reçoit sa propre clé, créditée de 50 € de tokens. Ne la partagez pas. Suivez votre consommation : une seule question peut déclencher plusieurs appels au LLM.
  • Ne publiez jamais la clé. Elle va dans .env, listé dans .gitignore. Seul .env.example, sans la clé, est dans le dépôt. Si votre clé fuite, prévenez l'enseignant.

Soutenance

La soutenance a lieu la semaine qui suit l'examen écrit de février. Vous présentez votre agent, puis vous le modifiez en direct sans IA : ajouter un tool, changer un comportement du prompt. Viennent ensuite des questions sur votre code.

Si vous ne savez pas expliquer votre code, la note des parties tools, agent et évaluation est plafonnée.

02 / Livrables
  1. 01Un dépôt Git avec des commits réguliers, pas un seul commit final.
  2. 02Un README : population, besoin, limites de l'existant, données utilisées et commandes de lancement.
  3. 03Un environnement virtuel reproductible : requirements.txt et .env.example, sans la clé.
  4. 04Au moins trois tools écrits à la main, et les prompts de l'agent.
  5. 05Un LLM-as-a-judge sur 5 questions-réponses, avec des références calculées sans l'agent et une courte analyse des échecs.