open-school/PROGRAM_CONTENT_ARCHITECTURE.md

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 :

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 entre le chiffre et la barre ne doit pas depasser environ la moitie de la taille du chiffre.

Le controle strict est porte par backend/tools/validate_svg_quality.py --warnings-as-errors. Un SVG de fraction qui laisse trop d'air entre numerateur/denominateur et barre doit donc echouer avant validation editoriale.