Comment j'ai appliqué une démarche produit à un projet familial pour transformer la préparation d'un examen en système instrumenté, et ce que cette expérimentation m'apprend sur l'usage opérationnel de l'IA générative.
Chaque diagnostic produit un profil de compétences exploitable qui revient alimenter la pratique de Kaya. Le système est itératif par conception.
Le système, vu d'en haut
Plus Kaya passe de diagnostics, plus le pilotage gagne en finesse.
L'idée : tester en vrai, sur un sujet à enjeu réel, comment on conçoit un système IA-augmenté avec la même rigueur méthodologique qu'un produit numérique.
Les apprentissages que j'en tire alimentent directement mes interventions en formation, en Design Ops et en stratégie autour de l'IA.
Plus bas, je raconte la démarche, les arbitrages, le stack, les itérations. Et surtout : comment exactement le travail s'est réparti entre Claude et moi. Cette dichotomie est le cœur méthodologique du projet.
Ma fille Kaya prépare le bac général 2026 en candidate libre, via le CNED. Elle est en Première générale, avec trois spécialités : Maths, HGGSP et LLCER Anglais.
Le statut de candidate libre a une conséquence forte : toutes les évaluations passent par les examens terminaux. Pas de notes continues issues d'un établissement scolaire.
Concrètement : pas de retour institutionnel régulier, autonomie totale dans le pilotage, et un programme énorme sur deux ans.
Comment générer un signal objectif et continu sur un système d'apprentissage qui n'en produit pas par défaut ? Et utiliser ce signal pour piloter dynamiquement l'allocation du temps de révision sur deux ans ?
C'est un problème classique de système d'information : il manque une couche de mesure. Sans mesure, le pilotage devient affectif (« je crois que je suis bonne en ça »).
Avec un horizon de deux ans et une charge énorme, l'erreur de priorisation coûte cher.
Le temps de Kaya est prioritaire et non extensible. Le système doit la servir, pas l'occuper.
Programmes officiels uniquement (CNED, Eduscol, sujets zéro). Pas de curriculum générique.
Coût opérationnel maîtrisé. Éviter les architectures qui consomment des crédits SaaS pour rien.
Maintenabilité. Je suis seule sur le projet. Pas de stack fragile à entretenir.
L'hypothèse centrale, posée dès le début :
Si on produit pour chaque matière un profil de compétences objectif (chapitre par chapitre, domaine par domaine), basé sur un diagnostic adaptatif piloté par IA, alors on peut générer un retro-planning de révision qui priorise automatiquement les zones faibles. Et qui se met à jour à chaque nouveau diagnostic.
Trois sous-hypothèses se cachent dans cet énoncé :
Une IA bien orchestrée peut produire un diagnostic plus fin qu'un QCM statique.
La granularité chapitre par chapitre est nécessaire et suffisante. Ni plus fin, ni plus grossier.
Notion peut tenir le rôle de back-office et de surface de pilotage.
Les trois ont été validées au fil de la construction, avec quelques nuances que j'expose plus bas.
Sur ce type de projet, ce qui plombe les coûts et la maintenabilité, ce sont les choix par défaut. J'ai donc posé chaque arbitrage explicitement.
J'ai cherché des outils existants. Aucun ne couvrait le périmètre voulu. La plupart des plateformes de révision sont soit des bibliothèques de contenu (Annabac, Schoolmouv), soit des QCM standardisés.
Aucune ne produit un profil de compétences exploitable ni n'alimente un planning dynamique.
→ Construire, assuméUn questionnaire statique aurait été plus rapide à produire. Mais il aurait perdu l'essentiel : la capacité d'adaptation en temps réel.
Quand Kaya répond à une question, l'agent ajuste les questions suivantes, creuse les zones floues, valide les zones solides. C'est exactement ce que fait un humain enseignant — et ce que l'IA permet de mécaniser à coût marginal proche de zéro.
→ IA générativeJ'avais l'option de tout coder en sur mesure. J'ai écarté pour deux raisons : Notion est un outil que je maîtrise et que Kaya peut consulter sans formation. Et le coût de maintenance d'une interface sur mesure serait disproportionné.
Arbitrage important : les agents diagnostiques tournent en dehors de Notion, en HTML/JS autonomes hébergés sur GitHub Pages. Ils poussent leurs résultats vers Notion via webhook Make.
→ Notion comme back-office, agents en dehorsMake orchestre le pipeline webhook → Notion. Pour 3 raisons : visualisation claire des flux (utile en debug), gestion native des connexions Notion, pas de serveur à maintenir.
Pour l'agent côté navigateur, j'ai choisi un endpoint sans serveur (serverless) Vercel qui sert uniquement de pont CORS vers l'API Anthropic. La clé d'API reste côté Vercel, jamais exposée dans le HTML.
→ Make + endpoint Vercel (voir l'encadré)Choix retenu : 5 domaines par matière, chapitres rattachés.
Plus fin (sous-compétences) aurait alourdi sans gain. Plus grossier (matière entière) aurait fait perdre la capacité de prioriser.
→ 5 domaines par matièreChaque composant fait une chose, et une seule. Cette modularité m'a sauvée plusieurs fois en debug.
zalihata/bac-2026-agentsChaque agent suit la même structure standardisée en deux phases : d'abord une grille de couverture où Kaya déclare ce qu'elle a vu, puis un questionnement adaptatif de 12 à 18 questions générées dynamiquement. Le profil produit alimente la base Notion.
| Agent | Matière | Statut |
|---|---|---|
agent_maths_spe_v2.html |
Maths spécialité (T041) | Standardisé |
agent_francais_v2.html |
Français écrit + oral (T001 / T002) | Double payload |
agent_anglais_lva.html |
Anglais LVA (IP003) | Standardisé |
agent_llcer_anglais.html |
LLCER Anglais (IP020) | Standardisé |
agent_histgeo.html |
Histoire-Géographie (IP001) | Standardisé |
agent_emc.html |
EMC (IP002) | Standardisé |
agent_es_scientifique.html |
Enseignement Scientifique (IP005) | Standardisé |
J'ai tenu un rythme une matière à la fois. C'est un choix conscient : le coût d'une erreur cascadée sur 6 agents est bien supérieur au coût d'une itération séquentielle.
Pas en lisant la doc. C'est la partie la plus instructive de l'étude de cas — et celle qui prouve que le système a été construit avec les mains, pas en théorie.
Francais ecrit, pas Français écrit).
Les filtres Search Notion via Make échouaient silencieusement sur les versions accentuées.
{{substring(1.json_brut, 0, 1800)}} avec virgules
(et pas points-virgules — affaire de locale Make).
id:statut:urgence|...,
l'accès se fait avec {{get(split(3.value; ":"); 1/2/3)}}.
Promise.all, Make n'en traitait qu'un.
Solution : await séquentiel.
r"""...""") est obligatoire.
Sans ça, les apostrophes dans le contenu cassent les chaînes JS à apostrophes simples,
et les accents graves referment les template literals JS prématurément.
DRY_RUN = true
sur les scripts Apps Script de réorganisation Drive.
Toujours. Procéder matière par matière. Ne jamais traiter six matières en même temps.
Au-delà de mon journal de famille.
L'IA générative renforce l'exigence d'architecture. Plus elle est puissante, plus l'architecture autour doit être propre.
Dans ce projet, Claude fait un travail très qualitatif parce que la structure de données qui l'entoure est propre (programme officiel, granularité maîtrisée, format de sortie strict). Mal posé en amont, le même modèle aurait produit du bruit.
Les compétences les plus stratégiques autour de l'IA aujourd'hui sont des compétences classiques de design produit : cadrage, qualité des données, clarté du modèle de domaine, orchestration.
Faire ce projet avec une démarche produit (problème, hypothèses, produit minimum viable (MVP), itération, métriques, feuille de route) a deux effets : ça force la qualité, et ça produit un système qui peut évoluer.
Beaucoup de projets perso échouent parce qu'ils sont attaqués sans ce cadre. À l'inverse, beaucoup de projets pros sous-performent parce que le cadre est appliqué de manière performative et non opérationnelle.
Cette expérimentation me sert à creuser ce qu'est, concrètement, la rigueur produit minimale efficace.
Ce projet ne remplace pas Kaya dans son apprentissage. Il ne pense pas à sa place, ne révise pas à sa place, ne passe pas l'examen à sa place.
Il fait une seule chose : lui rendre visible ce qui ne l'était pas, pour qu'elle puisse décider en connaissance de cause.
C'est l'usage le plus solide qu'on puisse faire de l'IA en pédagogie aujourd'hui : un instrument qui rend le travail visible et pilotable. C'est aussi la position que je défends dans mes formations.
Dans ce qui suit, je distingue précisément ce qui relève de moi et ce qui relève de Claude. Cette répartition détermine la qualité de ce qui sort.
Claude n'a pas de mémoire persistante entre conversations. Une partie réelle de mon travail consiste donc à maintenir la cohérence du système dans le temps : recoller le contexte au début de chaque session, valider que les correctifs de la veille sont bien intégrés, éviter les régressions. C'est ce travail de continuité qui rend le système viable dans la durée.
La décision finale m'appartient toujours. Quand je pose une question d'arbitrage, il propose des options structurées avec leurs conséquences. La décision reste mienne, et elle s'appuie sur des contraintes qu'il ne voit pas (mon budget, le temps disponible de Kaya, la fragilité d'un outil que j'ai déjà galéré à maîtriser ailleurs).
Je conserve systématiquement le rôle de validation. Je lis le prompt système, vérifie la conformité avec le programme officiel, et fais passer un test à blanc avant chaque mise en production. Sur ce projet précisément, parce qu'il s'adresse à ma fille, le coût d'une erreur silencieuse (un domaine mal scoré, un chapitre absent) est très supérieur au gain de temps qu'apporterait le « je fais confiance et j'envoie ».
Un exemple authentique par catégorie, extrait de nos conversations réelles.
Je colle systématiquement un bloc de contexte exhaustif au démarrage de chaque conversation, parce que Claude n'a pas de mémoire transverse. Exemple-type, mot pour mot :
« Je te donne le contexte : Projet — Système de révision bac 2026 — candidate libre CNED. Stack : GitHub Pages [...], endpoint Vercel [...], Make webhooks [...], Notion : 3 bases — Matières, Diagnostics, Chapitres. Agents : 7 agents standardisés et opérationnels. Prochaine étape : construire le planning dynamique. »
J'ai demandé à Claude si on pouvait faire un diagnostic commun pour Anglais LVA et LLCER Anglais. Réponse : déconseillé.
Argumentaire structuré : les compétences évaluées sont distinctes (LVA = compréhension/expression sur thèmes de société ; LLCER = analyse de documents culturels d'aire anglophone). Un diagnostic commun donnerait un profil flou inutile pour la priorisation.
Décision retenue : deux diagnostics séparés, mais construits en parallèle.
Lors de la construction de l'agent Histoire-Géo, deux bugs JavaScript sont apparus en production : « Unexpected identifier 'Europe' » et « Unexpected identifier 'json' ».
Origine identifiée à deux : utilisation d'une chaîne triple-quoted Python """..."""
au lieu d'une chaîne brute r"""...""" lors de la génération du fichier.
Correctif chirurgical, ciblé.
Plutôt que de réécrire 5 agents un par un quand on a fait évoluer l'architecture pour passer à 5 domaines homogènes, on a co-conçu un bout de code unique copier-collable.
Le .filter(d => d.label) gère automatiquement les matières à 3 ou 4 domaines
en ignorant les emplacements vides. Un seul motif pour 5 contextes différents.
Coût total de la propagation : environ 30 minutes au lieu de plusieurs heures.
.filter(d => d.label)
~720×450
(à uploader : capture du bout de code propagé sur 5 agents)
— Pas un produit. Une démarche.
Le système est taillé pour Kaya, ses spécialités, son rythme et son contexte CNED. Reproduire la démarche demande des compétences techniques (HTML/JS, Make, Notion avancé, API) ou un accompagnement. Si vous voulez creuser une approche similaire pour un parcours spécifique, je peux échanger sur la méthode et le cadrage. Le projet, lui, dépend du contexte.
Réserver un appel