Le 3 novembre 2025, un centre de formation continue en santé apprend que l’ordre professionnel qui encadre son activité impose, à partir de l’année suivante, l’utilisation d’un système de gestion de l’apprentissage (LMS) certifié pour le suivi des heures de formation de ses adhérents. Le site existant, un WordPress classique avec un thème sur mesure et un plugin de gestion de cours interne, ne pouvait tout simplement pas s’interfacer avec ce LMS externe : ce dernier imposait son propre protocole d’authentification et son propre système de suivi de progression, incompatibles avec l’architecture monolithique en place.
Ce cas documente l’architecture retenue pour répondre à cette contrainte, sans entrer dans le contenu des formations elles-mêmes, qui reste hors du périmètre technique traité ici.
La contrainte : un LMS externe non négociable
Le LMS imposé par l’ordre professionnel n’était pas un choix du centre de formation : il s’agissait d’une exigence réglementaire, avec un cahier des charges technique fourni par l’éditeur du LMS, incluant un protocole d’authentification unique (SSO) basé sur OpenID Connect et une API de synchronisation de progression pédagogique en JSON. WordPress devait rester la source de vérité pour le contenu marketing du centre (présentation des formations, actualités, page des formateurs), mais ne pouvait plus héberger directement le parcours de formation.
L’architecture retenue
Le choix s’est porté sur une architecture headless où WordPress conserve son rôle de gestion de contenu pour tout ce qui est public et éditorial, tandis qu’un front Next.js orchestre la navigation entre les pages vitrines issues de WordPress et le LMS externe, avec une session unique partagée entre les deux systèmes.
Visiteur
└── Front Next.js (pages vitrines + pont vers le LMS)
├── Contenu vitrine ─── API REST WordPress (headless)
│ formations, formateurs, actualités
└── Parcours de formation ─── LMS externe (OpenID Connect)
suivi de progression, attestations, heures validées
Le pont entre les deux systèmes repose sur un jeton d’identité OpenID Connect émis par le LMS lors de la connexion de l’adhérent, transmis ensuite à WordPress via un endpoint REST personnalisé qui associe cet identifiant externe à la fiche adhérent existante, sans dupliquer la gestion des mots de passe.
Le point le plus délicat : la synchronisation des inscriptions
Un adhérent s’inscrit à une formation depuis la page vitrine WordPress, mais son suivi pédagogique se déroule entièrement dans le LMS. Cette inscription doit donc être propagée automatiquement : un endpoint REST personnalisé, déclenché à la validation d’une commande WooCommerce (le centre facturait certaines formations via la boutique existante), notifie le LMS de la nouvelle inscription via son API :
add_action( 'woocommerce_order_status_completed', function ( $order_id ) {
$order = wc_get_order( $order_id );
foreach ( $order->get_items() as $item ) {
$formation_id = get_post_meta( $item->get_product_id(), 'lms_course_id', true );
if ( $formation_id ) {
wp_remote_post( 'https://lms-externe.exemple.fr/api/v1/enrollments', array(
'headers' => array( 'Authorization' => 'Bearer ' . getenv( 'LMS_API_KEY' ) ),
'body' => wp_json_encode( array(
'user_email' => $order->get_billing_email(),
'course_id' => $formation_id,
) ),
) );
}
}
} );Ce que la migration n’a pas résolu du premier coup
Deux difficultés ont retardé le chantier de plusieurs semaines. D’abord, la latence de synchronisation entre WooCommerce et le LMS, initialement traitée de façon synchrone dans le hook de commande, provoquait des délais de traitement de commande trop longs ; elle a été déplacée vers une tâche planifiée avec file d’attente, plus tolérante aux indisponibilités temporaires du LMS. Ensuite, la correspondance entre les comptes existants (créés avant la migration) et les nouveaux comptes LMS a nécessité un script de rapprochement manuel sur les emails, certains adhérents ayant changé d’adresse entre-temps sans mise à jour de leur fiche WordPress.
- File d’attente asynchrone pour toute synchronisation vers un système tiers non maîtrisé.
- Script de rapprochement des comptes existants avant bascule, plutôt qu’une migration automatique en masse.
- Page de secours affichant un message clair si le LMS est temporairement injoignable, plutôt qu’une erreur brute.
Une contrainte réglementaire imposée de l’extérieur laisse rarement le choix du calendrier ; elle laisse en revanche toute latitude sur l’architecture retenue pour s’y conformer sans reconstruire l’ensemble du système existant.
Bilan après quatre mois
Le chantier, cadré en juillet 2025 et mis en production fin novembre, a tenu son délai réglementaire de justesse. La séparation claire des responsabilités, WordPress pour l’éditorial et le LMS pour le pédagogique, a finalement simplifié la maintenance : chaque système reste spécialisé dans ce qu’il fait le mieux, et une future évolution réglementaire imposant un nouveau LMS n’obligerait à retoucher que le pont d’intégration, sans remettre en cause tout le site vitrine.
