Files
open-school/PROGRAM_CONTENT_ARCHITECTURE.md
2026-05-12 23:44:30 +02:00

163 lines
5.0 KiB
Markdown

# Architecture du contenu pedagogique
## Objectif
Le programme doit devenir une arborescence complete, auditable et reproductible.
Pour les cycles cibles :
- cycle 3 : CM1, CM2, 6e ;
- cycle 4 : 5e, 4e, 3e.
Chaque niveau doit etre deduit des PDF officiels disponibles dans `Programme/` :
1. extraire les domaines et matieres ;
2. identifier les themes officiels ;
3. decouper chaque theme en lecons ;
4. decouper chaque lecon en fiches ;
5. decouper chaque fiche en cards consultables ;
6. produire les exercices et tests associes ;
7. conserver la source PDF et, quand possible, la page ou section d'origine.
## Traçabilite obligatoire
Tout fichier de contenu doit pouvoir indiquer d'ou vient l'information.
Chaque fichier Markdown de production contient un bloc `Sources` ou une section equivalente :
- document PDF officiel ;
- chemin local du PDF ou de son extraction texte ;
- cycle, niveau, matiere et theme ;
- page, chapitre ou section si l'information est connue ;
- date de generation ou de derniere validation.
Cette regle vaut pour :
- `lecon.md` ;
- chaque `fiche.md` ;
- chaque contexte de card ;
- chaque exercice ;
- chaque test ;
- chaque support SVG lorsqu'un Markdown de contexte l'accompagne.
L'objectif est de pouvoir repondre a un audit : "ce contenu s'appuie sur tel document officiel de l'Education nationale".
## Arborescence canonique
Une lecon doit suivre cette structure :
```text
cycle_X/
matiere/
niveau/
theme/
lecon/
README.md
lecon.md
fiches/
01_nom_de_fiche/
fiche.md
fiche.svg
02_nom_de_fiche/
fiche.md
fiche.svg
cards/
01_nom_de_fiche/
card_01.md
card_01.svg
card_02.md
card_02.svg
exercices/
01_nom_de_fiche/
exercices.md
exercices.svg
parcours_adaptes/
01_profil_ou_remediation.md
tests/
01_test_diagnostic.md
01_test_diagnostic.svg
```
`README.md` sert au statut editorial de la lecon : phases, validations, notes de reprise.
`lecon.md` est la lecon complete a charger comme contexte general dans le modele.
## Role des fichiers
`lecon.md` :
- contient la lecon ecrite en entier ;
- sert de contexte general pour le modele ;
- indique les objectifs, pre-requis, vocabulaire, erreurs frequentes et sources.
`fiches/*/fiche.md` :
- decrit une fiche de lecon ;
- precise ce que l'eleve doit comprendre dans cette fiche ;
- accompagne `fiche.svg`.
`cards/*/card_XX.md` :
- guide le modele pour une card precise ;
- decrit exactement ce qui est affiche ;
- donne une consigne orale courte ;
- indique le critere de passage a la card suivante ;
- accompagne `card_XX.svg`.
`exercices/*/exercices.md` :
- contient les exercices, corriges et explications ;
- accompagne `exercices.svg` quand un support visuel existe.
`tests/*` :
- contient les tests de diagnostic ou de validation ;
- permet de choisir les exercices adaptes a l'enfant ;
- remplace l'ancien dossier `kit_adaptatif`.
`exercices/parcours_adaptes/*` :
- contient les remediations ou parcours recommandes apres les tests ;
- n'est plus un type de contenu separe dans l'UI.
## Flux pedagogique
Une nouvelle lecon se deroule ainsi :
1. afficher les fiches et cards de lecon ;
2. charger `lecon.md` comme contexte general ;
3. charger le contexte de la card active depuis `cards/*/card_XX.md` ;
4. faire un test depuis `tests/` quand la lecon est assez avancee ou quand l'enseignant le lance ;
5. choisir les exercices les plus adaptes depuis `exercices/` et `exercices/parcours_adaptes/`.
Le modele ne doit pas improviser la structure du cours depuis le seul titre de card.
Il doit recevoir le contexte general de la lecon et le contexte specifique de l'objet affiche.
## Interface de validation
L'UI doit parcourir tous les types utiles :
- lecon ;
- fiche ;
- card ;
- exercice ;
- test ;
- support.
L'ancien type `kit` n'est plus un type editorial.
Les SVG d'exercices et de tests doivent etre visibles et validables comme les SVG de lecon.
## Regle de generation
Chaque nouvelle lecon doit etre produite dans cette arborescence des le depart.
Une generation qui place des contenus dans `kit_adaptatif`, `svg/`, `card_contexts/` ou `exercices_svg/` est consideree comme legacy et doit etre migree avant validation.
## Regles SVG fractions
Les fractions doivent utiliser une structure testable :
- groupe avec `data-math="fraction"` ;
- boite de controle `data-box="x y width height"` pour chaque fraction ;
- numerateur, barre et denominateur separes sans chevauchement ;
- l'ecart vertical doit etre controle sur la clairance visible estimee du glyphe, pas seulement sur les coordonnees `y` SVG.
Le controle strict est porte par `backend/tools/validate_svg_quality.py --warnings-as-errors`.
Un SVG de fraction qui chevauche visuellement la barre, ou qui laisse trop d'air autour d'elle, doit donc echouer avant validation editoriale.