Microlearning : concevoir une plateforme de A à Z (retour d expérience Andra)
24/11/2025
Le microlearning n'est pas du e-learning découpé en morceaux. C'est un modèle de formation qui repose sur des capsules courtes (5 à 10 minutes), délivrées au moment où l'apprenant en a besoin, dans son contexte de travail. La différence est structurante : elle conditionne l'architecture technique, le modèle de données, les intégrations et la façon de mesurer l'efficacité.
Cet article est un retour d'expérience. Pendant 2 ans et demi (janvier 2023 à septembre 2025), nous avons conçu et développé Andra Learning, une plateforme de microlearning contextuel pour les équipes commerciales. Ce qui suit couvre les choix d'architecture, les erreurs évitées et les patterns qui ont tenu dans la durée.
Ce qui distingue le microlearning d'un LMS classique
Un LMS organise des parcours de formation longs (30 minutes à plusieurs heures) que l'apprenant suit à son rythme. Le microlearning inverse la logique : c'est la plateforme qui pousse le contenu vers l'apprenant, au bon moment, dans un format qui se consomme en quelques minutes.
Trois différences techniques découlent de cette inversion.
Le déclenchement est contextuel. La plateforme ne se contente pas d'afficher un catalogue. Elle surveille des événements métier (rendez-vous dans le CRM, échéance proche, nouveau produit à maîtriser) et déclenche la capsule pertinente. Cela suppose un moteur de règles connecté aux outils de l'entreprise.
Le contenu est atomique. Chaque capsule traite un seul sujet, avec un objectif pédagogique unique. Le modèle de données doit permettre de taguer, de combiner et de séquencer ces capsules de façon granulaire.
La mesure porte sur le comportement. Le taux de complétion d'un module de 2 heures est un indicateur pauvre. Sur une capsule de 7 minutes délivrée avant un rendez-vous client, ce qui compte, c'est de savoir si le commercial l'a consultée et si son rendez-vous s'est mieux passé. La mesure d'impact est plus fine et plus proche du métier.
Architecture d'une plateforme de microlearning
L'architecture d'une plateforme de microlearning partage des composants avec un LMS classique (auth, gestion de contenus, tracking, analytics), mais ajoute deux couches spécifiques : le moteur de déclenchement contextuel et la couche d'intégration événementielle.
Le moteur de déclenchement contextuel
C'est le cœur technique de la plateforme. Il répond à la question : "quelle capsule envoyer à quel apprenant, à quel moment ?"
Le moteur fonctionne en trois étapes :
-
Collecte d'événements. La plateforme reçoit des événements en provenance de systèmes tiers (CRM, calendrier, et potentiellement SIRH ou outils de communication) via des webhooks ou des connecteurs API. Chaque événement est normalisé dans un format interne : type d'événement, utilisateur concerné, métadonnées contextuelles, horodatage.
-
Évaluation des règles. Chaque événement est évalué contre un ensemble de règles configurées par les administrateurs de formation. Une règle combine des conditions (type d'événement, profil apprenant, historique de formation, critères temporels) et une action (déclencher telle capsule, envoyer un rappel, proposer un parcours).
-
Délivrance. Si une règle matche, la plateforme envoie la capsule via le canal approprié : notification push, email, message dans l'outil de collaboration (Slack, Teams), ou affichage dans l'interface de la plateforme.
Sur Andra Learning, nous avons implémenté ce moteur comme un module NestJS dédié. Pour une plateforme à fort volume, l'ajout d'une file de traitement asynchrone (BullMQ par exemple) permet d'absorber les pics d'événements sans bloquer les requêtes utilisateur : chaque événement entrant est mis en file, évalué par un worker, et les actions résultantes sont exécutées de façon asynchrone.
La couche d'intégration événementielle
La valeur du microlearning contextuel dépend directement de la qualité des intégrations avec les outils métier. Si la plateforme ne reçoit pas les bons événements au bon moment, le déclenchement contextuel ne fonctionne pas.
Sur Andra, nous avons intégré deux sources d'événements qui couvraient l'essentiel des déclenchements :
CRM (Salesforce, HubSpot, Pipedrive). Événements exploitables : opportunité créée, rendez-vous planifié, deal passé à l'étape suivante, deal perdu. Sur Andra, l'intégration CRM alimentait 60 % des déclenchements de capsules.
Calendrier (Google Calendar, Outlook). Événements exploitables : rendez-vous avec un prospect dans les 48h, formation présentielle planifiée, onboarding d'un nouveau collaborateur. Le déclenchement "avant rendez-vous" était le cas d'usage le plus fréquent sur Andra.
D'autres intégrations peuvent enrichir le déclenchement contextuel selon le cas d'usage :
SIRH (Workday, Lucca, BambooHR). Événements exploitables : arrivée d'un nouveau collaborateur, changement de poste, fin de période d'essai. L'intégration SIRH automatise l'inscription aux parcours obligatoires.
Outils de communication (Slack, Teams). Canal de délivrance des capsules et des rappels. L'apprenant reçoit une notification dans l'outil qu'il utilise déjà, avec un lien direct vers la capsule.
Le piège principal : les API des outils métier sont inégales. Certains CRM exposent des webhooks fiables, d'autres nécessitent du polling. Certains fournissent des données contextuelles riches (secteur du prospect, montant du deal), d'autres uniquement l'identifiant de l'objet modifié. La couche d'abstraction que nous avons mise en place sur Andra normalise ces différences : un événement "rendez-vous dans 48h" a la même structure interne, qu'il provienne de Google Calendar ou d'Outlook.
Conception des capsules
Format et durée
Les études sur l'attention en formation convergent : la rétention chute après 6 à 8 minutes de contenu continu. Une capsule de microlearning doit tenir dans cette fenêtre.
En pratique, la durée optimale dépend du format :
| Format | Durée cible | Usage |
|---|---|---|
| Vidéo explicative | 3-5 min | Démonstration de process, présentation produit |
| Quiz interactif | 2-4 min | Validation de connaissances, révision |
| Texte + visuels | 5-7 min | Méthode, argumentaire, fiche technique |
| Scénario branché | 5-10 min | Mise en situation, simulation d'entretien |
| Audio (podcast) | 5-8 min | Formation en déplacement, équipes terrain |
Chaque capsule doit avoir un objectif pédagogique unique. "À la fin de cette capsule, le commercial sait reformuler l'argument prix pour le secteur pharma." Si l'objectif ne tient pas en une phrase, la capsule est trop large.
Modèle de données des capsules
Le modèle de données doit refléter la granularité du microlearning. Sur Andra, chaque capsule est définie par :
- Métadonnées : titre, durée estimée, difficulté, date de création, statut de publication
- Contenu : blocs ordonnés (texte riche, vidéo, image, quiz, interaction)
- Tags de contexte : secteur d'activité, étape du cycle de vente, type de produit, compétence ciblée
- Règles de déclenchement : conditions nécessaires pour que cette capsule soit proposée
- Dépendances : capsules prérequises, capsules de suivi
Les tags de contexte sont ce qui permet au moteur de règles de sélectionner la bonne capsule. Plus le système de tags est structuré, plus le déclenchement est pertinent. Nous utilisons une taxonomie à trois niveaux : domaine (vente, produit, process) → compétence (négociation, qualification, closing) → niveau (découverte, approfondissement, maîtrise).
Répétition espacée et rétention
Le microlearning résout le problème de la surcharge cognitive (capsules courtes, un sujet à la fois), mais pas celui de l'oubli. Sans révision, un apprenant oublie 70 % d'un contenu en 24 heures (courbe d'Ebbinghaus).
La répétition espacée complète le microlearning en automatisant les révisions. Le principe : proposer une révision juste avant que l'apprenant oublie, avec des intervalles croissants (J+1, J+3, J+7, J+14, J+30).
Implémentation sur une plateforme de microlearning
Chaque capsule terminée génère un enregistrement de révision avec un intervalle initial (1 jour) et un facteur de facilité (2.5 par défaut). À chaque révision réussie, l'intervalle est multiplié par le facteur de facilité. À chaque échec, retour à l'intervalle initial.
Le système de révision s'intègre au moteur de déclenchement : les rappels de révision sont traités comme des événements internes avec la même logique de file et de notification que les déclenchements contextuels.
La combinaison microlearning + répétition espacée est celle qui a le plus d'impact sur la rétention. Les études rapportent une amélioration de 50 % de la rétention à 30 jours par rapport à une formation classique sans révision. Sur Andra, les capsules révisées au moins une fois avaient un taux de rétention de score (aux quiz de rappel) supérieur de 40 % aux capsules consultées une seule fois.
L'intégration avec les mécaniques de gamification renforce l'adhésion : XP bonus pour les révisions effectuées dans le timing optimal, streaks alimentés par l'activité quotidienne de révision, badges de maîtrise pour les capsules révisées plusieurs fois avec succès.
Analytics et mesure d'impact
Métriques de la plateforme
Les métriques d'un outil de microlearning diffèrent de celles d'un LMS classique. Le taux de complétion d'un parcours de 4 heures n'a pas de sens quand les capsules font 5 minutes.
Les métriques pertinentes :
Engagement. Nombre de capsules consultées par utilisateur par semaine. Fréquence d'accès (quotidien vs hebdomadaire vs mensuel). Taux d'ouverture des notifications de déclenchement. Sur Andra, un utilisateur actif consultait en moyenne 4 à 5 capsules par semaine.
Pertinence du déclenchement. Taux de clic sur les capsules contextuelles (capsule déclenchée avant un rendez-vous → l'apprenant l'a-t-il ouverte ?). Délai entre notification et consultation. Taux de complétion des capsules déclenchées vs capsules consultées librement.
Rétention. Score aux quiz de rappel (répétition espacée). Évolution du facteur de facilité par capsule et par apprenant. Taux de rétention à 30 jours par sujet.
Impact métier. C'est la métrique la plus difficile à mesurer et la plus demandée par les clients. Sur une plateforme de formation commerciale, l'impact se mesure en corrélant les données de formation avec les données CRM : le commercial qui a suivi la capsule "Argumentaire secteur pharma" avant son rendez-vous a-t-il un meilleur taux de conversion que celui qui ne l'a pas suivie ?
Pipeline d'analytics
L'architecture du pipeline suit le pattern collecte → agrégation → stockage → visualisation :
- Chaque interaction apprenant génère un événement (capsule ouverte, quiz répondu, vidéo regardée à X %)
- Les événements sont stockés dans une table dédiée (PostgreSQL suffit pour les premiers milliers d'utilisateurs)
- Des jobs d'agrégation périodiques calculent les métriques (BullMQ, toutes les heures ou quotidien)
- Un tableau de bord expose les indicateurs aux responsables formation
Si votre plateforme supporte le standard xAPI, chaque événement est aussi stocké sous forme de statement xAPI dans un Learning Record Store (LRS). Cela permet de croiser les données de votre plateforme avec celles d'autres outils de formation dans un référentiel commun. Nous détaillons l'implémentation xAPI dans notre guide SCORM vs xAPI.
Les erreurs que nous avons évitées (et celles que nous avons faites)
Construire le moteur de règles trop tôt
La tentation est de commencer par le moteur de déclenchement contextuel, parce que c'est la fonctionnalité différenciante. Sur Andra, nous avons d'abord livré une plateforme de microlearning "classique" (catalogue de capsules, parcours manuels, tracking basique) avant d'ajouter le moteur de règles en phase 2.
Ce séquencement a permis de valider le produit avec de vrais utilisateurs avant d'investir dans la couche d'intégration. Les premiers retours ont aussi affiné les règles de déclenchement : certains cas d'usage imaginés en amont n'avaient pas de valeur terrain, d'autres sont apparus à l'usage.
Sous-estimer la complexité des intégrations
Les intégrations CRM et calendrier ont représenté environ 30 % de l'effort de développement total sur Andra. Les API des outils tiers ont des limites de débit, des formats de données incohérents, des webhooks peu fiables. Chaque nouvelle intégration nécessite de la découverte, de l'adaptation et des tests avec les données réelles du client.
Chiffrez les intégrations dès le cadrage. Si un client utilise un CRM maison ou un outil avec une API limitée, le coût d'intégration peut doubler.
Sur-investir dans les formats de contenu au départ
Les premiers mois, nous avons consacré du temps à développer des formats interactifs sophistiqués (scénarios branchés, simulations). Les utilisateurs consultaient principalement du texte structuré avec des quiz de validation. Les formats avancés sont venus progressivement, quand le volume d'utilisateurs et les retours terrain les justifiaient.
Stack et patterns techniques
Architecture recommandée
| Composant | Technologie | Rôle |
|---|---|---|
| Frontend | Next.js (React) | Interface apprenant + back-office admin |
| Backend | NestJS (Node.js) | API, moteur de règles, intégrations |
| Base de données | PostgreSQL + Prisma | Capsules, progressions, événements, règles |
| File d'attente (recommandé) | BullMQ (Redis) | Traitement asynchrone des événements et déclenchements |
| Cache (recommandé) | Redis | Sessions, métadonnées capsules, état des règles |
| Notifications | Push + email + Slack/Teams | Délivrance multi-canal des capsules |
Sur Andra, nous avons utilisé Next.js, NestJS, PostgreSQL et Prisma avec TypeScript de bout en bout. BullMQ et Redis sont des recommandations pour les plateformes qui atteignent un volume d'événements significatif : ils permettent de découpler le traitement des déclenchements de l'API principale. Sur un MVP ou une plateforme avec quelques centaines d'utilisateurs, le traitement synchrone dans NestJS suffit.
NestJS structure le code en modules métier (capsules, moteur de règles, intégrations, analytics) qui peuvent évoluer indépendamment.
Patterns à retenir
Event-driven pour le déclenchement. Chaque événement entrant (CRM, calendrier, et autres intégrations) est traité de façon découplée. À faible volume, un traitement synchrone suffit. Quand le volume augmente, la publication sur une file avec évaluation par un worker dédié permet d'absorber les pics sans impacter les temps de réponse de l'API.
Couche d'abstraction pour les intégrations. Un adaptateur par outil tiers, une interface commune pour les événements normalisés. Ajouter un nouveau CRM revient à écrire un nouvel adaptateur sans toucher au moteur de règles.
Feature flags pour les formats de contenu. Les nouveaux formats de capsule (vidéo interactive, scénario branché) sont activables par tenant. Cela permet de les tester avec un client pilote avant de les généraliser.
Par où commencer
Si vous envisagez de construire une plateforme de microlearning :
-
Validez le besoin avec un MVP simple. Catalogue de capsules, parcours manuels, tracking basique. Pas de moteur de règles, pas d'intégrations complexes. Testez avec un groupe pilote de 20-50 utilisateurs.
-
Ajoutez le déclenchement contextuel en phase 2. Commencez par une seule intégration (le CRM le plus utilisé par vos clients) et deux ou trois règles de déclenchement simples. Itérez sur les règles avec les retours terrain.
-
Investissez dans les analytics dès le départ. Le tracking des interactions apprenant est la base de tout : répétition espacée, personnalisation, mesure d'impact. Posez les fondations du pipeline analytics dès le MVP.
-
Prévoyez du budget pour les intégrations. Elles représentent 30-40 % de l'effort total. Chaque client aura un écosystème d'outils différent.
Pour cadrer votre projet de plateforme de microlearning, consultez notre estimation des coûts par type de projet EdTech ou notre page EdTech. Vous pouvez aussi réserver un appel de diagnostic pour discuter de votre cas spécifique.