test(pronote): constituer un corpus anonymisé d’exports iCal et réponses API #29

New Issue

2026-09-12T10:36:33+02:00

Codex commented

2026-09-12 10:36:33 +02:00

Objectif

Construire un corpus de fixtures anonymisées et versionnées permettant de vérifier le parsing Pronote sans connexion réelle, et de détecter rapidement les régressions liées aux versions Pronote ou aux variantes d'établissement.

Constat

Les fixtures iCal actuelles couvrent les chemins nominaux et quelques annulations/devoirs, mais ne documentent pas suffisamment les variantes de schéma rencontrées dans les exports Pronote récents. Les tickets #20, #21, #27 et #28 montrent que les tests doivent distinguer :

la réponse brute de l'API Pronote et les objets exposés par pronotepy ;
le flux iCal, qui possède ses propres libellés, catégories, dates et règles de déduplication ;
les erreurs réelles d'authentification/session et les erreurs de parsing métier.

Sources et besoins identifiés

La documentation de protocole de pronotepy rappelle que les réponses Pronote sont des enveloppes JSON chiffrées/compressées et que les demandes d'emploi du temps utilisent des ressources parent/enfant et une semaine.

Des exports Pronote 2026 observés par pronote-digest ajoutent des cas importants pour l'iCal :

catégories Jours fériés ;
en-têtes Professeur(s), Salle(s), Partie(s) de classe ;
blocs « Pour le » et « Donné le » avec des dates distinctes ;
répétition du même devoir dans plusieurs cours ;
cours annulés ou déplacés ;
journées entières avec borne de fin exclusive.

Périmètre attendu

Corpus iCal

Ajouter des fixtures minimales et anonymisées couvrant au moins :

cours normal avec un ou plusieurs enseignants, salles et groupes ;
cours annulé ;
cours déplacé ;
changement de salle avec ancien et nouvel exemplaire ;
vacances ;
jour férié ;
cours sans UID, sans description, sans salle ou sans enseignant ;
descriptions avec retours à la ligne iCalendar, entités HTML et variations contrôlées de balises/espaces ;
plusieurs blocs « Pour le » et « Donné le », y compris plusieurs blocs à la même date ;
devoir identique recopié dans plusieurs cours et devoirs homonymes de matières/enseignants différents ;
dates/heures en UTC et avec zone Europe/Paris ;
flux vide, flux sans VEVENT et contenu non-iCalendar.

Réponses API

Ajouter, si le format peut être isolé sans secret :

enveloppes PageEmploiDuTemps parent avec ressource enfant ;
cours normaux, annulés, déplacés et changement de salle ;
PageCahierDeTexte avec plusieurs travaux, dates « Pour le »/« Donné le », matière et pièces jointes ;
réponse PageActualites code 20 pour vérifier le mode dégradé sans exécuter de login ;
champs optionnels absents ou null documentés.

Les payloads doivent être réduits aux champs nécessaires et ne jamais contenir de token, identifiant, nom, établissement ou contenu personnel réel.

Format et maintenance

Un manifeste associe chaque fixture à la version Pronote connue, au type de source et aux invariants attendus.
Les fixtures API sont séparées des fixtures iCal ; aucun test ne dépend du réseau.
Les tests vérifient les modèles métier finaux, pas seulement l'absence d'exception.
Les valeurs sensibles sont remplacées par des sentinelles génériques non réutilisables comme credentials.
Le corpus est réutilisable pour les évolutions de pronotepy et pour une éventuelle source alternative.
Une procédure de revue indique comment anonymiser un nouveau flux avant ajout.
Le contrôle de secrets est exécuté sur les fixtures et le diff.

Critères d'acceptation

Les scénarios listés disposent d'au moins un cas de test chacun, ou d'une justification documentée.
Les cas de statut, de timezone, de bornes de dates et de doublons sont explicitement assertés.
Un changement de version de pronotepy peut être rejoué sur le corpus sans authentification réelle.
Les tests garantissent qu'un champ inconnu ne provoque ni perte silencieuse non documentée ni fuite de données.
Les fixtures restent petites, lisibles et entièrement anonymisées.
La suite existante reste verte.

Conclusion opérationnelle

Prioriser ce ticket comme fondation de #27 et #28. Tant qu'un export réel anonymisé ne peut pas être rejoué localement, une correction de parsing Pronote reste difficile à prouver et risque de fonctionner uniquement sur les deux fixtures nominales actuelles.

## Objectif Construire un corpus de fixtures anonymisées et versionnées permettant de vérifier le parsing Pronote sans connexion réelle, et de détecter rapidement les régressions liées aux versions Pronote ou aux variantes d'établissement. ## Constat Les fixtures iCal actuelles couvrent les chemins nominaux et quelques annulations/devoirs, mais ne documentent pas suffisamment les variantes de schéma rencontrées dans les exports Pronote récents. Les tickets #20, #21, #27 et #28 montrent que les tests doivent distinguer : - la réponse brute de l'API Pronote et les objets exposés par `pronotepy` ; - le flux iCal, qui possède ses propres libellés, catégories, dates et règles de déduplication ; - les erreurs réelles d'authentification/session et les erreurs de parsing métier. ## Sources et besoins identifiés La documentation de protocole de [pronotepy](https://github.com/bain3/pronotepy/blob/master/PRONOTE%20protocol.md) rappelle que les réponses Pronote sont des enveloppes JSON chiffrées/compressées et que les demandes d'emploi du temps utilisent des ressources parent/enfant et une semaine. Des exports Pronote 2026 observés par [pronote-digest](https://github.com/yoanbernabeu/pronote-digest/blob/main/docs/architecture.md) ajoutent des cas importants pour l'iCal : - catégories `Jours fériés` ; - en-têtes `Professeur(s)`, `Salle(s)`, `Partie(s) de classe` ; - blocs « Pour le » et « Donné le » avec des dates distinctes ; - répétition du même devoir dans plusieurs cours ; - cours annulés ou déplacés ; - journées entières avec borne de fin exclusive. ## Périmètre attendu ### Corpus iCal Ajouter des fixtures minimales et anonymisées couvrant au moins : 1. cours normal avec un ou plusieurs enseignants, salles et groupes ; 2. cours annulé ; 3. cours déplacé ; 4. changement de salle avec ancien et nouvel exemplaire ; 5. vacances ; 6. jour férié ; 7. cours sans UID, sans description, sans salle ou sans enseignant ; 8. descriptions avec retours à la ligne iCalendar, entités HTML et variations contrôlées de balises/espaces ; 9. plusieurs blocs « Pour le » et « Donné le », y compris plusieurs blocs à la même date ; 10. devoir identique recopié dans plusieurs cours et devoirs homonymes de matières/enseignants différents ; 11. dates/heures en UTC et avec zone Europe/Paris ; 12. flux vide, flux sans VEVENT et contenu non-iCalendar. ### Réponses API Ajouter, si le format peut être isolé sans secret : - enveloppes `PageEmploiDuTemps` parent avec ressource enfant ; - cours normaux, annulés, déplacés et changement de salle ; - `PageCahierDeTexte` avec plusieurs travaux, dates « Pour le »/« Donné le », matière et pièces jointes ; - réponse `PageActualites` code 20 pour vérifier le mode dégradé sans exécuter de login ; - champs optionnels absents ou `null` documentés. Les payloads doivent être réduits aux champs nécessaires et ne jamais contenir de token, identifiant, nom, établissement ou contenu personnel réel. ## Format et maintenance - [ ] Un manifeste associe chaque fixture à la version Pronote connue, au type de source et aux invariants attendus. - [ ] Les fixtures API sont séparées des fixtures iCal ; aucun test ne dépend du réseau. - [ ] Les tests vérifient les modèles métier finaux, pas seulement l'absence d'exception. - [ ] Les valeurs sensibles sont remplacées par des sentinelles génériques non réutilisables comme credentials. - [ ] Le corpus est réutilisable pour les évolutions de `pronotepy` et pour une éventuelle source alternative. - [ ] Une procédure de revue indique comment anonymiser un nouveau flux avant ajout. - [ ] Le contrôle de secrets est exécuté sur les fixtures et le diff. ## Critères d'acceptation - [ ] Les scénarios listés disposent d'au moins un cas de test chacun, ou d'une justification documentée. - [ ] Les cas de statut, de timezone, de bornes de dates et de doublons sont explicitement assertés. - [ ] Un changement de version de `pronotepy` peut être rejoué sur le corpus sans authentification réelle. - [ ] Les tests garantissent qu'un champ inconnu ne provoque ni perte silencieuse non documentée ni fuite de données. - [ ] Les fixtures restent petites, lisibles et entièrement anonymisées. - [ ] La suite existante reste verte. ## Conclusion opérationnelle Prioriser ce ticket comme fondation de #27 et #28. Tant qu'un export réel anonymisé ne peut pas être rejoué localement, une correction de parsing Pronote reste difficile à prouver et risque de fonctionner uniquement sur les deux fixtures nominales actuelles.

Codex added the investigation label 2026-09-12 10:36:33 +02:00

Codex self-assigned this 2026-09-12 10:36:33 +02:00

Codex added a new dependency 2026-09-12 13:03:51 +02:00

#27 fix(pronote): préserver les cours déplacés et les changements de salle

Codex added a new dependency 2026-09-12 13:03:52 +02:00

#28 fix(ical): fiabiliser l’extraction des devoirs et événements Pronote 2026