Workflow IA pour la création d'exercices

Contexte

Dans le cadre de mes missions sur Mathia chez Prof en Poche, j'ai eu l'occasion de créer 4 gabarits de jeux différents dans les domaines des fractions, de la géométrie et des grandeurs et mesures. Ces gabarits étaient conçus par des didacticiens à travers des documents de spécifications. Ces documents contenaient :

• une brève description du jeu et de chacun de ses modes ;
• toutes les variantes de l'exercice pour les niveaux CM1, CM2 et 6e (par exemple, pas de millièmes pour les CM1) ;
• les parcours qu'il fallait associer ;
• les feedbacks personnalisés à donner en fonction de l'erreur commise par l'élève.

Les exercices et parcours devaient se créer via le back-office WordPress. Pour un gabarit, il peut y avoir une cinquantaine d'exercices à créer, ce qui est très long à la main car il y a un certain temps de chargement à chaque action. Il y avait beaucoup d'exercices à produire dans un temps restreint : j'ai donc conçu un workflow avec Claude Code pour gagner du temps, de la lecture du document jusqu'à l'import dans WordPress.

Approche

Skills, agents et workflow

Le workflow repose sur trois niveaux, chacun avec son rôle :

• Les skills sont des connaissances réutilisables, chargées seulement par les agents qui en ont besoin : la syntaxe d'importation WordPress, ou le programme et les règles didactiques de chaque niveau.
• Les agents sont des rôles, chacun avec son propre contexte, son modèle et ses skills : spécification, importation, développement, revue de code et revue didactique.
• Le workflow orchestre l'ensemble : l'ordre des étapes, ce qui tourne en parallèle et les points où je valide moi-même avant de continuer.

• Agent
• Skill
• Validation humaine

Document des didacticiens

↓

Agent de spécificationOpus

↓

✓Validation de la spécification

Référence unique pour la suite du workflow

↓

Contenu

↓

Agent d'importation

• Import WordPress

↓

2 fichiers XML

Exercices et parcours

↓

✓Relecture et import manuel

Code

↓

Agents développeurs×N

En parallèle, puis tests des user stories

↓

Code reviewer

Règles Claude du projet

Reviewer didactique

• Didactique

La spécification comme contrat

Avant le développement du gabarit et de ses différentes variantes, un premier agent fournit une spécification complète (plan) : un résumé du jeu et les différentes marches à suivre, comme la création de toutes les variables didactiques d'un exercice (par exemple, la proportion de carrés ou de triangles dans un exercice de géométrie) avant leur importation dans WordPress.

Cette spécification me permet de faire une première validation de la compréhension du document et de sa réalisation. Elle permet également de lever toutes les incertitudes liées au document et de trancher en cas d'indications incompatibles. Une fois validée, c'est elle, et non plus le document d'origine, qui sert de référence à tous les agents suivants.

Pour cette phase, j'ai choisi un agent Opus : c'est sur cette spécification que tout le reste du workflow se base. Une petite coquille à ce moment peut impacter lourdement la suite et demander plusieurs itérations de correction.

L'importation dans WordPress

Plutôt que de créer les exercices à la main, j'ai opté pour l'outil d'importation natif de WordPress. Afin que Claude puisse comprendre la syntaxe d'importation des exercices et parcours, j'ai d'abord exporté ces entités pour fournir un exemple de chaque item (exercice et parcours), avec une explication des différents champs. C'est devenu le skill d'importation WordPress.

Lorsque la spécification est validée, un agent d'importation formate les exercices et parcours dans des fichiers XML reconnus par l'outil d'importation et me génère deux fichiers, que je vérifie avant l'importation. L'importation reste volontairement manuelle : cela force la relecture, là où un MCP WordPress aurait tout envoyé directement.

Le développement et les revues

Quelques agents développeurs tournent ensuite en parallèle sur les tâches indépendantes définies dans la spécification. Lorsqu'ils ont fini, ils testent que la fonctionnalité respecte bien les user stories de la spécification. Deux agents de revue prennent ensuite le relais :

• un code reviewer vérifie que le code fourni respecte bien les règles Claude du projet ;
• un reviewer didactique, équipé du skill de didactique, s'assure que les questions présentées à l'élève respectent bien le programme de son niveau et, dans la mesure du possible, corrige les contenus générés qui ne présenteraient pas d'intérêt didactique.

Résultat

Les résultats du workflow n'étaient pas très concluants à sa création, j'ai donc itéré sur son contenu (exemple : ajout du skill de didactique). Ces ajouts ont permis d'améliorer les résultats obtenus : moins de corrections après le lancement du workflow et des questions mieux adaptées au niveau de chaque élève. Ils ne sont pas encore parfaits, mais chaque problème récurrent observé donne une piste précise pour une itération suivante : un skill à compléter ou un contrôle à ajouter.

Ce que j'en retiens

• La spécification est l'étape où une erreur coûte le plus cher : c'est là que je mets le modèle le plus capable et ma première validation.
• Garder des validations humaines aux points clés, plutôt que tout automatiser, force une relecture qui rattrape ce que les agents laissent passer.