I.
En production
Le parcours élève
Pas d'inscription libre : chaque compte est créé par l'équipe pédagogique. Un élève ne voit que les quêtes ouvertes à sa classe, rangées par catégories, avec leurs prérequis. Le catalogue s'ouvre progressivement, il n'arrive jamais d'un bloc.
- Quêtes et auto-validation
- Fiches d'exercice catégorisées, taguées, avec ressources et prérequis. Une quête peut aussi être un QCM qui se valide seul dès le seuil de réussite atteint, sans attendre de correction humaine.
- Parcours guidés
- Des chaînes de quêtes obligatoires ou optionnelles assignées à la classe. Chaque étape reste verrouillée tant que la précédente n'est pas validée, la progression se calcule à la volée.
- Badges et easter eggs
- Un catalogue de badges attribués par les formateurs, plus des badges cachés à débloquer par un code. Invisibles au catalogue tant qu'ils n'ont pas été trouvés.
- Discussion de rendu
- Chaque rendu a son fil de commentaires et un geste d'appréciation, visible par l'élève, ses formateurs, les admins et ses pairs.
- Favoris et ressources communautaires
- Mise en favori d'une quête, bibliothèque de liens par catégorie, et des ressources proposées et votées par les élèves eux-mêmes : classement pondéré, signalement des liens morts.
- Notifications en direct
- Neuf types d'événements (rendu corrigé, badge obtenu, sondage ouvert, message direct, diffusion de classe...) poussés en temps réel par flux
SSE, sans rechargement de page. - Carnet de compétences et sondages
- Un référentiel de compétences par classe, tenu à jour élève par élève par le formateur. Des sondages dont les résultats restent nommés côté formateur.
- Pensé mobile
- Tout le parcours élève (accueil, quêtes, détail, mes quêtes, profil, notifications) est adapté au mobile, avec un tiroir de navigation dédié plutôt qu'un simple rétrécissement du desktop.
II.
En production
L'outillage formateur
Un formateur pilote sa classe depuis un hub central. Plus besoin de jongler entre un tableur de notes, un agenda externe et une boîte mail pour faire tourner une promo.
- Hub de classe
- Roster complet, statistiques d'avancement par élève et par quête, taux de réussite des QCM : la vue d'ensemble avant d'aller au détail.
- Notation
- Projets et équipes, notes individuelles ou d'équipe, export CSV pour tout ce qui doit remonter ailleurs (jury, administratif).
- Agenda de classe
- Planning par type d'événement (cours, ateliers, démos live, jours non travaillés), consultable par les élèves en lecture seule.
- Émargement par QR code
- Une session s'ouvre en un clic ou automatiquement à l'heure programmée, un QR rotatif projeté en classe, l'élève signe du doigt sur son téléphone. Le formateur voit chaque signature apparaître en direct, peut en révoquer une, ou relancer par email un élève resté sans QR sous les yeux.
- Revue et publication de contenu
- Un workflow dédié pour faire évoluer une quête : brouillon, relecture, publication, en couche additive. La version publiée n'est jamais écrasée avant validation.
- Délégation fine
- Une permission ponctuelle (
QUEST_REVIEW) peut être accordée à un formateur de confiance sans lui donner tout le rôle admin. - Communication et masquerade
- Diffusion d'un message à toute une classe, et un mode « masquerade » pour prévisualiser l'application exactement comme la voit un élève donné.
III.
En production
Vulpy, l'assistant de correction
Vulpy s'appuie sur les modèles Claude d'Anthropic pour accélérer la correction, jamais pour la remplacer. Réservé au rôle le plus élevé de la plateforme, il propose, l'humain décide.
Ce que Vulpy renvoie sur un rendu élève : jamais une note, toujours une proposition
{
"decision": "REQUEST_CHANGES",
"feedback": "Le composant ne gère pas l'état de chargement...",
"rationale": "La consigne exige un indicateur visuel pendant l'appel API."
}
- Correction assistée
- Vulpy réunit le contexte complet d'un rendu (consigne, catégorie, ressources, commentaire de l'élève, et même le contenu des dépôts GitHub liés) pour proposer une décision structurée, jamais un simple avis en texte libre.
- Revue de contenu outillée
- Sur un signalement (lien mort, techno datée), Vulpy peut chercher sur le web une source de remplacement fiable, ou corriger en un clic l'ensemble des signalements d'une même quête.
- Maîtrise du coût
- Le modèle utilisé (rapide, équilibré, ou le plus capable) et le niveau d'effort de raisonnement se choisissent au cas par cas. Sans clé API configurée, le service se désactive proprement : jamais un point de blocage pour le reste de l'application.
- Garde-fous
- Consigne anti-injection systématique dans chaque prompt. Vulpy ne touche jamais la base de données lui-même : la publication reste un geste humain, à chaque fois.
IV.
En production
Gouvernance et sécurité
Le modèle de rôles n'a pas été pensé pour une seule classe pilote : il distingue déjà le pédagogique de l'administratif, ce qui compte dès qu'une structure grandit.
- Cinq rôles taillés sur mesure
- Élève, formateur, admin, super-admin, et
ADMISSION: un rôle à part pour l'équipe qui gère les comptes et la composition des classes, sans jamais toucher au contenu pédagogique (ni quêtes, ni notes, ni badges). - Permissions fines
- Des autorisations ponctuelles viennent s'ajouter à un rôle sans le changer : la granularité existe déjà là où le besoin s'est présenté.
- Authentification robuste
- Jetons JWT sans état, mots de passe hashés en Argon2id, jeton de renouvellement en cookie protégé. Les standards actuels, pas des raccourcis.
- RGPD par construction
- Purge automatique programmée des comptes élèves après le délai de rétention, avec e-mail d'avertissement préalable, et suppression de compte en libre-service.
V.
En production
Fiabilité et exploitation
Ce qui ne se voit pas à l'écran mais qui décide si l'application tient dans la durée : comment elle est testée, déployée, et surveillée une fois en ligne.
- Intégration continue
- Trois branches (développement, pré-production, production), tests obligatoires avant toute fusion, et un numéro de version calculé automatiquement à chaque commit.
- Déploiement automatisé
- Chaque nouvelle version publiée redéploie la production toute seule, par webhook. Pas d'étape manuelle à oublier un vendredi soir.
- Sous surveillance
- Métriques et tableaux de bord dédiés, logs structurés : de quoi repérer un problème avant qu'un élève n'ait besoin de le signaler.
- Un historique traçable
- 50 migrations de base de données, chacune versionnée et jamais modifiée après coup : l'évolution du produit se relit de bout en bout, sans zone d'ombre.
- Réellement testé
- 116 fichiers de tests automatisés, exécutés contre de vraies bases PostgreSQL en environnement de test. Pas de simulations qui masquent les vrais problèmes.
VI.
Vision, pas encore construit
La feuille de route
Ce qui suit n'existe pas encore dans le code. C'est la direction que le socle actuel (rôles déjà séparés, hub de classe déjà central, API déjà découpée par domaine) permet de prendre rapidement, sans tout reconstruire.
- Application mobile
- Retrouver ses quêtes, ses badges et ses notifications en mobilité, et scanner le QR d'émargement directement depuis l'appli plutôt qu'avec l'appareil photo natif. Le parcours élève déjà pensé mobile-first côté web, et la page de signature déjà conçue pour être réutilisée en vue embarquée, en posent la première pierre.
Vulpy, générateur de contenu
Étendre l'assistant au-delà de la correction : proposer un premier brouillon de quête à partir d'un thème, que le formateur affine ensuite.
Plusieurs organismes, une instance
Le rôle ADMISSION, déjà séparé du pédagogique, prépare le terrain pour accueillir plusieurs structures de formation distinctes.
Agenda synchronisé
Export et synchronisation du planning de classe vers un calendrier externe, pour ne plus tenir le rythme à deux endroits.