ORIGINE
Pourquoi ce projet
Après Mate
(mon premier projet Product Builder, centré sur la donnée et l'automatisation), Skillo est le projet où j'ai voulu pousser plus loin deux choses que le CRM ne testait pas. Une vraie logique de rôles multiples (apprenant / formateur) avec des permissions distinctes, et plusieurs scénarios de notification automatisée (email de bienvenue, nouveau cours assigné, rappel d'inactivité) là où le Mini CRM n'en avait qu'un seul, la relance de facture.
Dès le cadrage, l'application a été pensée pour rester polyvalente sur plusieurs thématiques.
Le moteur applicatif (leçon, QCM, checklist, progression, gamification) est générique et réutilisable pour n'importe quel sujet technique. La climatisation a été choisie comme premier sujet pour l'incarner, un choix presque naturel puisque le projet a pris forme en plein été, au moment où on pense le plus à se rafraîchir.
Ce principe générique a guidé plusieurs décisions concrètes, du nommage des tables en base (cours, categorie, jamais de vocabulaire climatisation en dur) jusqu'à la direction artistique, volontairement détachée du métier.
Nom et identité visuelle
Skillo a été retenu pour un nom court, prononçable et générique, donc cohérent avec le principe de moteur réutilisable.
La direction visuelle ludique s'inspire du registre Duolingo/Babbel. Chaleureuse et motivante plutôt que technique, à l'opposé d'un premier jet de palette (bleu-pétrole, sobre) exploré puis écarté après une comparaison de plusieurs directions côte à côte.
Le logo traduit littéralement ce que l'app cherche à porter. Skill évoque la compétence à acquérir, et son "o" final pour l'Objectif. Ce o est représenté par un anneau circulaire pour représenter la progression. Que l'utilisateur soit apprenti, déjà en poste ou en reconversion, et que sa motivation soit de trouver un emploi dans le secteur, monter en compétences, préparer un examen ou par simple curiosité personnelle, ce même symbole porte visuellement son chemin vers cet objectif.
CONTEXTE
Constat de départ
Le point de départ du projet est l'observation qu'un apprenti technicien a rarement l'occasion de s'entraîner sur des cas concrets en dehors du terrain lui-même, même quand sa formation combine déjà théorie et pratique.
Skillo ne cherche pas à remplacer cette formation, mais à lui apporter un complément mobile, un entraînement accessible entre deux interventions, pas un substitut au terrain réel.
C'est aussi un bon terrain de test pour la partie du produit la plus spécifique, la checklist terrain, pensée comme un apprentissage procédural (l'ordre des gestes compte) plutôt que déclaratif (un QCM classique).
Problématique
Deux cibles aux besoins différents devaient cohabiter dans un seul produit sans que l'une n'alourdisse l'autre, un apprenant qui veut apprendre en autonomie, sans barrière à l'entrée, et un formateur qui veut à la fois créer son propre contenu et structurer un vrai suivi pour ses élèves.
Ce que Skillo résout :
- Inscription : libre pour l'apprenant, sans formateur requis, avec onboarding de profil différencié selon le rôle choisi
- Cours : Leçon rédigée en Markdown avec images et vidéos YouTube/Vimeo intégrées, aperçu en direct pour le formateur pendant la rédaction + QCM, avec checklist terrain optionnelle en complément, en mode case à cocher ou remise en ordre. Les questions de QCM et les étapes de checklist peuvent aussi contenir des images, agrandissables au clic pour l'apprenant
- Gamification : XP, progression par cours, badges à débloquer, quiz flash mélangeant plusieurs cours déjà suivis
- Espace formateur complet : création de cours privés (assignables à plusieurs groupes à la fois), gestion de groupes et d'élèves, suivi de progression par élève
- Emails automatisés via Make : bienvenue lors de l'inscription, nouveau cours disponible pour les élèves déjà présents dans un groupe, rattrapage des cours existants pour un élève qui rejoint un groupe en cours de route, rappel après 7 jours d'inactivité sur un cours commencé
STRATÉGIE PRODUIT
Modèle produit : hybride, pas un choix par défaut
Le vrai arbitrage de départ n'était pas technique mais business. L'app devait-elle être un pur produit grand public (accès libre, sans formateur, comme Duolingo), ou un outil institutionnel (accès uniquement via un formateur/organisme, comme un vrai LMS) ? Les deux modèles ont des implications de monétisation et de complexité de permissions radicalement différentes.
Le modèle retenu est hybride, inspiré d'outils comme Google Classroom ou Quizlet. Un contenu public en libre accès (sans barrière à l'entrée, sans formateur requis) coexiste avec un espace formateur privé (contenu réservé aux élèves qu'il rattache explicitement). Ce choix évite l'écueil des deux extrêmes. Un pur B2C n'aurait jamais justifié la complexité de rôles et de permissions construite. Un pur B2B institutionnel aurait fermé l'app à tout apprenant curieux sans structure derrière lui.
Segmentation des utilisateurs
Quatre profils sont capturés dès l'inscription (apprenti, déjà en poste, en reconversion, autre) avec leur motivation d'usage (trouver un emploi dans le secteur, monter en compétences, préparer un examen, curiosité personnelle). Cette donnée n'est pas décorative. Elle sert de base à toute réflexion produit future sur quel contenu prioriser, ou comment adapter le ton selon le profil dominant réellement observé une fois l'app utilisée.
Priorisation sous contrainte réelle
Un exemple concret d'arbitrage business est survenu en cours de route. Le plan gratuit de l'outil d'automatisation (Make) limite à deux scénarios actifs simultanément. Avec trois notifications prévues (bienvenue, nouveau cours, rappel d'inactivité), un choix de priorité s'imposait. L'email de bienvenue, plus accessoire, a été mis en pause au profit des deux notifications directement liées à l'usage du contenu, jugées plus utiles à la rétention. Une contrainte de ressource réelle, pas hypothétique, tranchée sur un critère produit plutôt que technique.
Monétisation (hypothèse, non validée)
Un modèle freemium côté formateur, gratuit à vie côté apprenant, semble le plus cohérent avec l'architecture construite. L'apprenant reste le canal d'acquisition et de traction, sans barrière. Le formateur, qui tire une valeur directe et mesurable de l'outil (gain de temps, suivi structuré), est le segment naturellement disposé à payer, avec une option de licence par organisme pour les structures qui équipent plusieurs formateurs à la fois. Ce raisonnement s'inspire directement du modèle Duolingo / Duolingo for Schools, déjà cité comme référence de direction artistique. Il n'a fait l'objet d'aucune validation utilisateur ni test de pricing, c'est une hypothèse de stratégie, pas un fait établi.
Ce qui resterait à faire
Skillo n'a pas fait l'objet d'une analyse concurrentielle formelle face aux LMS existants (Moodle, Teachable, ou des acteurs spécialisés formation professionnelle).
Un vrai point à combler avant de présenter ce projet comme une réflexion business complète.
RECHERCHE
Patterns UX d'apprentissage
La question initiale n'était pas esthétique mais structurelle. Comment un utilisateur apprend-il le mieux dans ce type d'app ? La réponse a orienté deux choix concrets.
D'abord, un parcours d'entrée en trois écrans distincts, une introduction en carrousel qui présente l'app avant tout choix, un écran de sélection du rôle (apprenant ou formateur), puis un onboarding de quelques questions de profil, plutôt qu'un unique écran surchargé qui mélangeait pitch marketing et formulaire de choix.
Ensuite, une checklist terrain pensée comme deux mécaniques d'apprentissage distinctes plutôt qu'une seule, case à cocher pour dérouler les étapes une à une, au fur et à mesure de leur réalisation, ou remise en ordre par glisser (flèches monter/descendre, plus fiable au tactile qu'un vrai drag-and-drop) pour tester la mémorisation d'un ordre de gestes.
Accessibilité
Palette validée WCAG AA sur l'ensemble des combinaisons texte/fond. Un statut de progression n'est jamais porté par la seule couleur (vert/bleu/gris), toujours doublé d'un libellé texte et d'une icône (✓ Terminé, ● En cours).
L'accent chaud (récompense, XP, badges) reste réservé aux fonds pleins ou aux éléments larges, jamais en texte fin, pour préserver le contraste.
Priorité mobile ou desktop, selon l'usage réel
L'espace apprenant est mobile-first, cohérent avec un usage nomade (consulter un cours dans les transports, en pause, ou n'importe où sans être devant un ordinateur).
L'espace formateur a d'abord été pensé desktop-first, cohérent avec un usage bureau plus fréquent pour ce rôle. La question s'est reposée en cours de route.
Un formateur doit-il aussi pouvoir créer un cours ou un groupe depuis son téléphone ? La réponse a été oui, et l'interface s'est révélée facilement accessible sur mobile, sans avoir à la repenser en profondeur pour ça.
MÉTHODE
Stack et rôle de l'IA
Claude Code + React/Vite + Supabase (Postgres, Auth, Storage, Row Level Security) + Vercel + Make (automatisations email). Contrairement au Mini CRM, pas de détour no-code sur ce projet. Le code a été la seule voie, du premier écran jusqu'au déploiement.
L'app tourne en production sur Vercel, avec déploiement continu à chaque envoi de code sur GitHub, pas une simple mise en ligne ponctuelle.
Le mode de travail a été systématiquement le même tout du long, cadrage et décision d'abord dans une conversation Claude.ai dédiée, traduction en instruction précise pour Claude Code ensuite, jamais l'inverse. Cette séparation des rôles (décider vs exécuter) a évité l'écueil classique du vibe coding. Le code avance vite, mais chaque instruction correspond à une décision déjà prise et documentée, pas à une improvisation demandée à l'IA à la volée.
Où l'itération a le plus servi
Deux exemples concrets où le simple fait de reformuler avant de construire a évité de refaire un travail :
- Le réglage qui détermine si une checklist se valide par case à cocher ou par remise en ordre avait d'abord été pensé étape par étape, comme si chaque étape pouvait avoir son propre mode. Une relecture a fait remarquer que ça n'avait pas de sens. Le mode de réorganisation ne peut s'appliquer qu'à la checklist entière, et non étape par étape. Corrigé avant la première ligne de code d'implémentation.
- La question "un formateur peut-il assigner un même cours à plusieurs classes ?" s'est posée après coup, une fois le produit déjà fonctionnel avec une relation un-cours-un-groupe. Plutôt que de la considérer hors scope, la migration vers une vraie relation plusieurs-à-plusieurs (nouvelle table de liaison cours_groupes) a été traitée comme un ajustement de schéma ciblé, pas une refonte.
DESIGN
Design System
Logo
Le "o" de Skillo comme anneau de progression, un seul élément qui sert à la fois de wordmark et de rappel visuel du système de progression de l'app.
L'anneau circulaire, plutôt qu'une barre de progression linéaire classique, constitue la signature visuelle de l'app. Il porte le pourcentage global de complétion et se retrouve à l'identique dans le logo, un même motif décliné du branding jusqu'au composant d'interface le plus consulté du Dashboard.
Gamification
XP à la complétion d'un quiz (20 XP) ou d'une checklist (15 XP), des badges avec condition de déblocage explicite (premier quiz, première checklist, trois cours terminés, score parfait, premier quiz flash réussi), et une animation de confettis dont l'intensité varie avec le score (30 à 65 particules selon le pourcentage obtenu) plutôt qu'un simple message de félicitations statique.
Parcours d'inscription
Le parcours d'entrée en trois écrans (Introduction, choix du rôle, Onboarding) se déroule différemment selon que l'utilisateur s'inscrit comme apprenant ou comme formateur, chacun avec ses propres questions de profil.
Introduction
Écran Connexion / Inscription
Parcours d'inscription pour l'apprenant et le formateur
Parcours de notification
Le diagramme ci-dessous montre la boucle complète, dans ses deux cas.
Un formateur crée un cours privé assigné à un groupe (l'app déclenche un appel direct vers Make, un email part vers chaque élève déjà membre), ou un nouvel élève rejoint un groupe qui a déjà des cours (un email de bienvenue lui liste directement ce qui l'attend). Dans les deux cas, l'élève clique et retrouve le cours sur son Dashboard.
Le dernier maillon de cette boucle, c'est ce que l'élève reçoit réellement. Deux autres cas s'ajoutent à cette boucle événementielle.
L'email de bienvenue suit le même principe, déclenché dès l'inscription, le cas le plus simple, sans groupe ni cours impliqué.
Le rappel d'inactivité, lui, repose sur une logique différente. Plutôt qu'un événement ponctuel, un scénario Make programmé interroge chaque jour la base pour repérer les cours abandonnés depuis 7 jours.
Pour chaque scénario construit, une paire de captures montre à la fois la mécanique (configuration Make) et le résultat (email reçu) :
Bienvenue à l'inscription
Scénario Make
Mail de bienvenue pour l'apprenant (à gauche) et mail de bienvenue pour le formateur (à droite)
Rattrapage pour un nouvel élève et Nouveau cours
Scénario Make
Mail d'ajout à un groupe (à gauche) et mail d'un nouveau cours (à droite)
Rappel d'inactivité après 7 jours
Scénario Make
Mail de relance
Ce que j'ai choisi de ne pas faire
- Streak et leaderboard : un streak (compteur de jours consécutifs d'activité, comme sur Duolingo) et un classement entre élèves, deux mécaniques de gamification courantes, écartées faute de cas d'usage validé. Un classement entre élèves n'a de sens que dans un contexte compétitif que ce produit ne cherche pas à créer.
- Rôle Super-admin : envisagé un temps pour une hypothèse multi-organismes, écarté parce qu'aucun cas d'usage réel n'existait à construire dessus. Le formateur reste "administrateur" de ses propres élèves, ce qui couvre le besoin réel sans complexifier le modèle de rôles pour un scénario hypothétique.
- Génération de contenu par IA intégrée à l'interface formateur : un bouton qui génère automatiquement des questions à partir d'une leçon existe comme idée, pas comme fonctionnalité construite (prévu en V2, voir plus bas). Les cours publics eux-mêmes ont été rédigés avec l'aide de l'IA en amont, mais comme un processus d'auteur mené à la main, pas comme un outil mis à disposition de n'importe quel formateur dans l'app.
- Confirmation d'email et réinitialisation de mot de passe :le lien "Mot de passe oublié" existe sur l'écran de connexion, mais sans le flux d'envoi d'email derrière. Volontairement laissé en l'état pour un usage portfolio, un vrai lancement public réactiverait ce point avant tout.
Dashboard apprenant
Section Cours
Mode terrain
Fiche de cours (Leçon/Quiz/Checklist)
Quiz Flash
Démonstration
Dashboard formateur
Cours
Gestion des groupes
Détail groupe avec suivi de progression
Création d'un cours
Démonstration
CONCLUSION
Où j'ai dû intervenir
- Deux tables qui se vérifient l'une l'autre : à deux reprises (élèves/groupes, puis cours/groupes), une règle de sécurité qui contrôle l'accès à une donnée en interrogeant une seconde donnée, elle-même contrôlée en retour par la première, crée une boucle sans fin que la base de données refuse d'exécuter. Corrigé en cassant la boucle par un point de passage intermédiaire, un piège à connaître avant de croiser deux règles d'accès entre elles.
- Un système d'envoi automatique tombait en panne sans prévenir : le mécanisme qui déclenchait les notifications par email fonctionnait un jour, plus le lendemain, sans message d'erreur exploitable. Plutôt que de continuer à chercher une cause invisible, la décision a été de changer de méthode : déclencher l'envoi directement depuis l'application plutôt que de dépendre d'un mécanisme externe peu fiable.
- Un outil de test qui capte mal les vrais événements : l'outil d'automatisation (Make) propose normalement les champs disponibles après avoir observé un exemple réel. Mais tant qu'un scénario tourne en direct, il traite chaque événement comme une vraie action, sans en garder un échantillon pour la configuration. Il faut le mettre en pause le temps de capturer cet exemple, une subtilité d'interface découverte à l'usage.
- Un choix disparaissait au rechargement de la page : le rôle choisi par un utilisateur (apprenant ou formateur) était gardé en mémoire temporaire, effacé au moindre rafraîchissement pendant l'inscription. Corrigé en le conservant dans les données de session, plus durables qu'une simple variable d'écran.
- Le contenu public n'avait aucun propriétaire : les cours accessibles à tous, sans formateur derrière, n'appartenaient à aucun compte, donc impossibles à modifier depuis l'interface une fois créés. Résolu en les rattachant à un compte dédié, avec les mêmes droits qu'un formateur classique.
Le correctif a été rapide précisément parce que le modèle de données ne distinguait déjà aucun rôle spécial pour posséder un cours, public ou privé, n'importe quel compte formateur pouvait en principe en gérer un. Une bonne décision d'architecture posée en amont, même si ce cas d'usage précis n'avait pas été anticipé.
Le correctif a été rapide précisément parce que le modèle de données ne distinguait déjà aucun rôle spécial pour posséder un cours, public ou privé, n'importe quel compte formateur pouvait en principe en gérer un. Une bonne décision d'architecture posée en amont, même si ce cas d'usage précis n'avait pas été anticipé.