Septembre 2021 : un établissement d’enseignement à distance ouvre ses inscriptions pour l’année scolaire suivante via un site vitrine WordPress headless, pendant que la partie pédagogique — cours, devoirs, suivi des élèves — vit entièrement sur une plateforme de formation externe, hors de tout contrôle direct sur son schéma de données. Entre les deux systèmes, un même élève ne doit exister qu’une fois, avec un seul formulaire à remplir.
L’architecture qui répond à ce besoin ne demande pas de fusionner les deux systèmes ni de dupliquer leurs bases de données : elle repose sur un identifiant pivot, une synchronisation à sens unique côté écriture, et un webhook de confirmation pour fermer la boucle.
Le périmètre du problème
Le site vitrine gère le formulaire d’inscription, le paiement des frais de scolarité et la communication avec les familles. La plateforme de formation externe (LMS) gère les comptes élèves, les classes virtuelles et le suivi pédagogique. Sans synchronisation, une même famille devrait renseigner deux fois les informations de l’élève — une fois pour l’inscription administrative, une fois pour la création du compte pédagogique — avec le risque que les deux versions divergent au fil du temps.
Cet article ne traite pas de la pédagogie proposée par le LMS lui-même : il porte uniquement sur la mécanique de synchronisation qui évite la double saisie entre les deux systèmes.
L’architecture retenue
WordPress (formulaire d'inscription, CPT "inscription")
└── validation du paiement (webhook Stripe)
└── création du pivot : uuid genere via wp_generate_uuid4()
└── POST vers l'API du LMS
{ "pivot_id": "uuid...", "nom": ..., "classe": ... }
├── succes → LMS renvoie son propre identifiant interne
│ WordPress stocke lms_account_id en meta
└── echec → mise en file, nouvelle tentative differee
LMS (creation du compte eleve)
└── webhook de confirmation vers WordPress
{ "pivot_id": "uuid...", "status": "actif" }
└── WordPress met a jour le statut de l'inscription
L’identifiant pivot, un UUID généré côté WordPress au moment de la validation du paiement, sert de clé commune aux deux systèmes tout au long du processus, indépendamment des identifiants internes que chacun d’eux utilise par ailleurs.
Pourquoi la synchronisation part de WordPress
WordPress reste la source de vérité pour l’état administratif de l’inscription : c’est là que le paiement est confirmé, que les conditions générales sont acceptées, et que la famille peut suivre l’état de son dossier. Faire partir la synchronisation depuis WordPress garantit qu’un compte pédagogique n’est jamais créé côté LMS avant que l’inscription administrative ne soit réellement validée.
Le webhook de retour, envoyé par le LMS une fois le compte activé, referme la boucle sans que WordPress n’ait besoin d’interroger périodiquement l’API du LMS pour connaître l’état d’avancement — une approche par sondage qui aurait ajouté de la latence et une charge inutile sur les deux systèmes.
Gérer les cas d’échec
Trois situations d’échec doivent être anticipées dans ce type d’architecture :
- L’API du LMS est temporairement indisponible au moment de l’envoi initial : l’inscription reste en statut « en attente de synchronisation » côté WordPress, avec une tâche planifiée qui retente l’envoi à intervalle croissant.
- Le webhook de confirmation n’arrive jamais, par exemple si le LMS échoue à le déclencher : un contrôle quotidien interroge l’API du LMS pour les inscriptions restées en statut intermédiaire depuis plus de 24 heures, en filet de sécurité.
- Un même élève est inscrit deux fois par erreur, par exemple après un double clic sur le formulaire : une contrainte d’unicité sur la combinaison nom, date de naissance et année scolaire, côté WordPress, empêche la création d’un second pivot avant même l’appel au LMS.
Le rôle du statut d’inscription
Le CPT inscription porte un champ de statut à trois valeurs : en_attente_paiement, en_attente_synchronisation, active. Ce statut, visible dans l’espace famille du site, donne une transparence complète sur l’avancement du dossier sans exposer le moindre détail technique de l’intégration avec le LMS.
Un identifiant pivot bien choisi rend une intégration entre deux systèmes hétérogènes presque triviale à maintenir : il suffit de toujours pouvoir répondre à la question « à quelle inscription correspond cet enregistrement, côté LMS comme côté WordPress ? »
Pour aller plus loin
Cette architecture reste volontairement silencieuse sur la pédagogie du LMS — répartition des classes virtuelles, outils de suivi, contenu des cours — qui relève d’un choix indépendant de la mécanique de synchronisation décrite ici. Elle répond à une contrainte précise et souvent sous-estimée dans les projets headless multi-systèmes : garantir qu’une même personne, dans deux bases de données distinctes, ne soit jamais saisie deux fois par erreur humaine.
