Architecture technique d une plateforme e-learning : guide pour développeurs
09/02/2026
Vous construisez une plateforme de formation et vous devez poser les bases de l'architecture technique. Ce guide couvre les composants d'un LMS moderne, les choix de base de données, le streaming vidéo, le tracking apprenant, les intégrations et la scalabilité.
Cet article s'adresse aux développeurs et aux CTO qui pilotent un projet EdTech. Les patterns présentés sont ceux que nous utilisons sur nos projets, notamment le développement complet d'Andra Learning (microlearning contextuel, 2.5 ans de mission).
Les composants d'une plateforme e-learning
Une plateforme de formation moderne se décompose en services métier distincts. Chaque service gère un domaine fonctionnel et communique avec les autres via des API.
Authentification et gestion des utilisateurs
Le service d'authentification gère les identités, les rôles et les permissions. Dans un contexte EdTech, les rôles sont plus nuancés qu'un simple admin/utilisateur :
- Super administrateur : configuration de la plateforme, gestion des tenants (en multi-tenant)
- Administrateur formation : création des parcours, assignation des apprenants, accès aux rapports
- Formateur : création de contenu, suivi de ses groupes d'apprenants
- Apprenant : accès aux parcours assignés, suivi de sa progression
Le SSO (SAML, OpenID Connect) est indispensable dès que la plateforme est déployée en entreprise. Les apprenants ne créent pas de compte : ils se connectent avec leurs identifiants d'entreprise. L'intégration SSO conditionne l'adoption.
Gestion des contenus
Le service de gestion des contenus stocke et organise les ressources pédagogiques : vidéos, documents, quiz, contenus interactifs, packages SCORM. Deux approches architecturales :
CMS intégré : le back-office de la plateforme permet de créer et organiser les contenus directement. C'est l'approche la plus courante pour les LMS sur mesure. L'éditeur de contenu doit gérer le texte riche, l'upload de médias, l'ordonnancement des modules, et les prérequis entre les sections.
Headless CMS : le contenu est géré dans un CMS dédié (Strapi, Contentful) et consommé via API par la plateforme. Cette approche est pertinente si le contenu doit être diffusé sur plusieurs canaux (web, mobile, intégration dans des outils tiers).
Moteur de parcours et évaluations
Le moteur de parcours modélise la progression de l'apprenant à travers les contenus. C'est le cœur métier d'un LMS. Il gère :
- Les parcours linéaires (module 1, puis module 2, puis module 3)
- Les prérequis (le module 3 n'est accessible que si le module 2 est validé avec un score minimum)
- Les branchements conditionnels (si score < 70 %, proposer un module de rattrapage)
- Les évaluations à chaud (quiz post-module) et à froid (évaluation J+30)
- La génération d'attestations de complétion
La complexité du moteur de parcours est souvent sous-estimée dans les estimations initiales. Un parcours linéaire est simple à implémenter. Des parcours adaptatifs avec branchements, scoring par compétence et conditions de validation multiples nécessitent un modèle de données solide.
Tracking apprenant
Le service de tracking enregistre chaque interaction de l'apprenant avec la plateforme : temps passé par module, réponses aux quiz, taux de complétion, fréquence d'accès, progression dans le parcours.
Deux standards coexistent pour le tracking : SCORM et xAPI. SCORM pour la compatibilité avec les contenus tiers, xAPI pour le tracking natif enrichi (contexte, multi-source, mobile).
Le tracking alimente deux usages : le suivi individuel (l'apprenant voit sa progression) et le reporting agrégé (l'administrateur suit l'adoption par équipe, par formation, par période).
Analytics et reporting
Le service d'analytics transforme les données de tracking en indicateurs exploitables. Les métriques clés d'une plateforme de formation :
- Engagement : utilisateurs actifs, fréquence d'accès, temps moyen par session
- Performance pédagogique : taux de complétion, scores moyens, taux de réussite aux évaluations
- Impact métier : corrélation entre formation suivie et indicateurs de performance (pour les formations commerciales, par exemple)
L'architecture d'analytics suit un pipeline classique : collecte d'événements → file de messages (queue) → agrégation → stockage analytique → visualisation. Pour les premiers mois, une table d'événements PostgreSQL avec des requêtes SQL d'agrégation suffit. Un data warehouse dédié (BigQuery, Redshift) se justifie quand le volume de données ou la complexité des analyses augmente.
Base de données : modèle de données type
Le schéma de données d'un LMS s'articule autour de cinq entités principales :
Utilisateurs : identité, rôle, tenant (en multi-tenant), date de création. Lié aux inscriptions et aux progressions.
Formations (courses) : titre, description, formateur, dates, métadonnées (tags, difficulté, durée estimée). Une formation contient des modules ordonnés.
Modules : titre, ordre dans la formation, contenus associés, prérequis. Un module contient des ressources pédagogiques et des évaluations.
Inscriptions (enrollments) : la relation entre un utilisateur et une formation. Statut (en cours, terminé, abandonné), date d'inscription, pourcentage de complétion.
Progressions : la trace de l'avancement de chaque utilisateur dans chaque module. Pourcentage de complétion, temps passé, dernier accès, résultats d'évaluation.
Multi-tenancy
Si votre plateforme sert plusieurs organisations (chaque entreprise cliente a son propre espace), vous devez choisir une stratégie de multi-tenancy :
Base partagée avec filtrage par tenant : toutes les données dans la même base, chaque table a une colonne tenant_id. La Row-Level Security (RLS) de PostgreSQL garantit l'isolation au niveau de la base. C'est l'approche la plus économique et la plus simple à maintenir.
Base séparée par tenant : chaque organisation a sa propre base de données. Meilleure isolation, mais complexité accrue pour les migrations de schéma et le provisioning. Justifié pour des clients avec des exigences strictes de sécurité ou de souveraineté des données.
Pour la plupart des plateformes EdTech, la base partagée avec RLS est le bon choix au démarrage. Vous pourrez migrer les clients sensibles vers des bases dédiées ultérieurement si le besoin se présente.
Streaming vidéo
La vidéo est souvent le contenu le plus consommé sur une plateforme de formation. Son architecture impacte directement l'expérience utilisateur et les coûts d'infrastructure.
Protocoles
HLS (HTTP Live Streaming) est le standard le plus répandu. Le serveur découpe la vidéo en segments de 2 à 10 secondes et génère un manifeste .m3u8 qui liste les segments disponibles dans différentes qualités. Le lecteur client télécharge les segments au fur et à mesure et adapte la qualité au débit disponible (adaptive bitrate).
DASH (MPEG-DASH) est le standard ISO équivalent, avec un manifeste XML (MPD). Moins répandu que HLS dans les navigateurs, mais plus flexible sur les codecs (H.264, H.265, VP9, AV1).
Pour une plateforme de formation, HLS couvre la majorité des cas d'usage. Le support navigateur est universel (Safari natif, les autres via hls.js).
Architecture CDN
Le flux vidéo typique :
- Upload : le formateur uploade la vidéo source
- Transcoding : un job asynchrone encode la vidéo dans plusieurs résolutions (480p, 720p, 1080p) et formats (HLS segments)
- Stockage : les fichiers encodés sont stockés sur un object storage (S3, GCS)
- Distribution : un CDN (CloudFront, Cloudflare, Bunny) cache les segments au plus près des apprenants
- Lecture : le player client (hls.js, video.js) télécharge les segments depuis le edge server le plus proche
Le transcoding est la partie la plus coûteuse en calcul. Utilisez un service managé (AWS MediaConvert, Cloudflare Stream) plutôt que de gérer votre propre pipeline FFmpeg, sauf si vous avez des volumes très importants.
Coûts
Comptez 200 € à 1 000 € par mois d'infrastructure vidéo pour une plateforme de taille moyenne (quelques centaines d'apprenants, quelques dizaines d'heures de vidéo). Les coûts augmentent avec le nombre de vues simultanées et le volume de stockage.
Intégrations
Une plateforme de formation s'intègre dans l'écosystème IT de l'entreprise cliente. Les intégrations les plus fréquentes :
SIRH (Workday, SAP SuccessFactors, Lucca)
La synchronisation SIRH automatise la gestion des utilisateurs : création de comptes à l'embauche, mise à jour des équipes et des postes, désactivation au départ. Elle permet aussi d'inscrire automatiquement les collaborateurs aux formations obligatoires en fonction de leur poste.
L'intégration est bidirectionnelle : les données RH alimentent la plateforme, et les certifications obtenues remontent dans le dossier collaborateur.
SSO (SAML, OpenID Connect)
Le SSO est indispensable en contexte entreprise. L'apprenant se connecte avec ses identifiants d'entreprise (Active Directory, Google Workspace, Okta) sans créer de compte dédié. SAML 2.0 pour les entreprises traditionnelles, OpenID Connect pour les environnements cloud-native.
CRM (Salesforce, HubSpot)
Pour les plateformes de formation commerciale (comme Andra Learning), l'intégration CRM permet de déclencher des formations en fonction d'événements métier : prospect ajouté au pipeline, rendez-vous programmé, deal perdu. Le CRM est à la fois source de déclencheurs et destination des données de formation (le commercial a-t-il suivi la formation avant le rendez-vous ?).
Outils auteurs (Articulate, iSpring)
Les organismes de formation créent leurs contenus avec des outils auteurs spécialisés. Ces outils exportent des packages SCORM que votre plateforme doit savoir importer, stocker et exécuter. L'implémentation d'un player SCORM est un développement significatif (gestion de l'API JavaScript, stockage du suspend_data, reporting).
Temps réel et notifications
WebSocket
Les fonctionnalités temps réel (notifications push, mises à jour de progression en direct, sessions de formation live) nécessitent une connexion WebSocket persistante entre le client et le serveur.
L'architecture type : un registry de connexions (userId → socket) côté serveur, avec Redis Pub/Sub pour distribuer les messages entre les instances du serveur si vous avez plusieurs nœuds.
Notifications
Les notifications sont le levier d'engagement principal d'une plateforme de formation. Rappels de formation en cours, deadline d'évaluation, nouvelle capsule disponible, résultat d'examen. Le service de notifications doit gérer plusieurs canaux : in-app (WebSocket), email, push mobile.
Scalabilité
Les goulots d'étranglement classiques
La base de données est le premier goulot. Les requêtes de reporting qui agrègent les données de progression de milliers d'apprenants ralentissent les requêtes transactionnelles. La solution : séparer les requêtes de lecture analytique (read replicas) des requêtes d'écriture transactionnelles.
Le streaming vidéo est le second. Sans CDN, votre serveur d'origine encaisse toute la bande passante. Avec un CDN, seules les premières requêtes (cache miss) atteignent l'origine.
Les WebSockets consomment une connexion persistante par apprenant connecté. À 10 000 apprenants simultanés, c'est 10 000 connexions ouvertes. Le load balancing de WebSocket nécessite des sticky sessions ou un broker de messages centralisé.
Stratégie de cache
- Cache applicatif (Redis) : sessions utilisateur, métadonnées de cours, rôles et permissions. TTL : 5 à 15 minutes.
- Cache distribué (Redis cluster) : contenus de cours, blocs de texte, résultats d'évaluation. TTL : 30 à 60 minutes.
- Cache CDN : fichiers statiques, segments vidéo, images. TTL : 24 heures ou versionné.
Stack recommandée
| Composant | Technologie | Justification |
|---|---|---|
| Frontend web | Next.js (React) | SSR pour le SEO, SPA pour l'app, écosystème riche |
| Frontend mobile | React Native | Code partagé avec le web, offline-first possible |
| Backend API | NestJS (Node.js) | Architecture modulaire, TypeScript fullstack, performance |
| Base de données | PostgreSQL + Prisma | RLS pour multi-tenancy, JSON pour statements xAPI, Prisma pour la DX |
| Cache | Redis | Sessions, cache applicatif, pub/sub pour les notifications |
| Vidéo | Cloudflare Stream ou AWS MediaConvert + CloudFront | Transcoding managé, CDN intégré |
| Recherche | Elasticsearch ou Meilisearch | Recherche full-text dans les contenus de formation |
| Queue | BullMQ (Redis) | Jobs asynchrones (transcoding, emails, analytics) |
| Monitoring | Datadog ou Grafana + Prometheus | APM, logs, métriques infrastructure |
C'est la stack que nous utilisons sur nos projets EdTech. TypeScript de bout en bout (frontend, backend, scripts) élimine les incohérences de typage entre les couches et facilite les refactorings sur des projets qui durent plusieurs années, comme ce fut le cas avec Andra Learning.
Ce que vous devez retenir
- Découpez en services métier : auth, contenus, parcours, tracking, analytics, vidéo, notifications. Pas besoin de microservices dès le jour 1, mais structurez votre code en modules pour pouvoir les séparer quand le besoin se présentera.
- PostgreSQL avec RLS couvre le multi-tenancy pour la majorité des plateformes EdTech. Ne sur-architecturez pas le stockage au démarrage.
- Le streaming vidéo est un poste de coût et de complexité significatif. Utilisez un service managé plutôt que de gérer votre propre pipeline de transcoding.
- Les intégrations (SIRH, SSO, CRM, outils auteurs) représentent souvent 30 à 40 % de l'effort de développement total. Chiffrez-les dès le cadrage.
- Le tracking apprenant doit être pensé dès l'architecture initiale. Ajouter xAPI ou SCORM après coup est coûteux.
- Commencez simple, itérez. Un monolithe modulaire en NestJS, une base PostgreSQL et un CDN pour la vidéo vous portent loin. Vous éclaterez en services quand le volume le justifiera.
Si vous développez une plateforme de formation et souhaitez cadrer votre architecture technique, nous pouvons vous accompagner. Consultez notre page EdTech ou réservez un appel de diagnostic.