Référentiel Établissements — Migration Dema1n / Inspire

Suivi de la migration de Dema1n et Inspire vers le référentiel établissements A1C (voir construction.md et api.md). Objectif fixé : bascule complète d'ici fin 2026.

État actuel

Dema1n

Champ historique : Jeune.bacSchool / Jeune.schoolName (texte libre, saisi via une liste statique SchoolListByDepartment.json). La migration a déjà commencé côté backend :

  • Jeune.etablissementId (varchar, nullable) a été ajouté — référence l'id A1C. null pour les jeunes créés avant la migration ou via le formulaire legacy (commits 8df9172e et ec2fca21, 2026-07/08).
  • EtablissementsService (dema1n/back/src/etablissements/) interroge le référentiel A1C en direct via A1ConnectClient (getEtablissements, getEtablissementById) — pas de copie locale synchronisée, contrairement à ce que décrit construction.md.
  • getMetadata(schoolName, etablissementId?) implémente déjà la double logique : lookup A1C exact si etablissementId présent, sinon fallback sur la liste statique par nom.
  • La liste statique legacy n'est pas retirée : elle reste l'unique source du flag partenaire (métier dema1n, absent d'A1C) et sert de fallback metadata (ips/zrr/qpv) pour les jeunes sans etablissementId.
  • Écriture non branchée : aucun DTO d'entrée (patch-inscription-draft.dto.ts, create-jeune.dto.ts) n'accepte etablissementId — en pratique le champ reste null pour tous les jeunes créés à ce jour. Schéma et lecture sont prêts, pas la saisie.

Inspire

Table locale complète etablissements (api/src/core/users/entities/etablissement.entity.ts), alimentée historiquement (champs old_id, idEtablissementOnisep). Aucun lien avec A1C aujourd'hui : pas d'équivalent d'A1ConnectClient pour les établissements côté Inspire (les intégrations A1Connect existantes concernent uniquement l'auth/JWT).

  • ParcoursLyceen.etablissement / ParcoursEclaireur.etablissement : relation etablissementId vers la table locale, pas vers l'id A1C.
  • etablissementNom : texte libre en fallback quand l'établissement n'est pas dans la table locale (cf. aussi le fallback équivalent documenté côté A1C dans construction.md#notes-et-limites).
  • Flags métier isPrioritaire / isPartenaire / isDenied stockés directement sur la table locale — cohérent avec la doc A1C (ce sont des flags métier, pas du référentiel).
  • Le webhook A1C → Inspire qui pousserait les mises à jour du référentiel (notifyPlatforms()) est écrit côté A1C mais désactivé.

Stratégie de migration

D'ici fin 2026, même principe sur les deux plateformes :

  1. Nouveaux jeunes/parcours (fin septembre) → renseigner l'etablissementId A1C dès la création.
  2. Période transitoire : cohabitation etablissementId (A1C) / nom libre (bacSchool / etablissementNom) pour compatibilité ascendante.
  3. Deuxième étape (fin octobre) : campagne de matching par nom pour rétro-remplir l'etablissementId des jeunes/parcours existants.

Points d'attention

Todo * [x] Brancher Dema1n pour les nouveaux user * [ ] Migrer les anciens user Dema1n * [ ] Brancher Inspire pour les nouveaux user * [ ] Migrer les anciens user

Points d'attention

  • Inspire : etablissementId existe déjà, mais pointe vers la table locale, pas A1C. On va donc créer un champ etablissementA1CId
  • Le matching par nom ne couvrira jamais 100% des cas. A1C ne référence que les établissements ONISEP (lycées + supérieur) ; les CFA hors contrat, établissements privés hors contrat et établissements à l'étranger seront à vérifier
  • Migration. Attention aux etablissmentName champ libre, on peut commencer déjà pour Dema1n à voir si certains sont déjà non trouvable entre le champ etablissmentName et la liste actuelle Dema1n
  • Fiabiliser le matching avant d'écrire en masse. Prévoir un dry-run avec taux de confiance / liste des cas ambigus avant un UPDATE en masse.