ÉTUDE DE CAS · PRODUCT BUILDING · Sept. 2026

Skillo

Une app pour apprendre un métier technique entre deux journées de terrain : cours, quiz et checklists pour les apprentis, et un espace de suivi pour leurs formateurs.
Conçue et mise en production en 2,5 jours avec Claude Code.

Rôle :

Conception, design et build, en solo

Device :

Mobile pour l’apprenant, desktop et mobile pour le formateur

Stack :

React, Supabase, Vercel, Make

Durée :

2,5 jours

En bref

PROBLÈME :

un apprenti pratique rarement des cas concrets en dehors du terrain.

RÉPONSE :

cours, quiz et checklists terrain, avec XP et badges, gratuits pour l’apprenant.

Décision clé :

un modèle hybride, avec du contenu public ouvert à tous et un espace formateur privé.

Écarté :

streaks et classements, faute de cas d’usage compétitif chez la cible.

Sommaire

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 sur deux choses que le CRM ne testait pas. Une vraie logique de rôles multiples (apprenant et 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, catégorie, jamais de vocabulaire climatisation en dur) jusqu'à la direction artistique, volontairement détachée du métier.

Nom et identité visuelle

Skillo : un nom court, prononçable et générique, cohérent avec le moteur réutilisable. « Skill » pour la compétence, et un « o » final pour l'objectif, dessiné comme un anneau de progression. Ce même anneau porte le chemin de chaque utilisateur, qu'il soit apprenti, en poste ou en reconversion.

J'ai comparé trois directions côte à côte avant d'en retenir une. Un fond crème pour l'apprenant, un violet pour l'action, et un orange réservé aux récompenses. Le registre reste celui de Duolingo ou Babbel, sans les couleurs d'un métier en particulier.

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 devaient cohabiter sans que l'une alourdisse l'autre : un apprenant qui veut apprendre seul, sans barrière à l'entrée, et un formateur qui veut créer son contenu et suivre ses élèves.

Ce que Skillo résout

Inscription libre pour l'apprenant, sans formateur requis, avec un onboarding différent selon le rôle.

Cours : Cours : leçon en Markdown avec images et vidéos, QCM obligatoire, et checklist terrain optionnelle (case à cocher ou remise en ordre).

Gamification : XP, progression par cours, badges, quiz flash qui mélange plusieurs cours.

Espace formateur : Espace formateur : cours privés assignables à plusieurs groupes, gestion des groupes, suivi par élève, et un dashboard qui liste les élèves à relancer.

Emails automatiques : bienvenue, nouveau cours, rattrapage pour un élève qui rejoint un groupe, rappel après 7 jours d'inactivité.

Stratégie produit

Un modèle hybride, pas un choix par défaut

Le vrai arbitrage de départ était business, pas technique. Produit grand public en accès libre, comme Duolingo, ou outil institutionnel accessible seulement via un formateur, comme un LMS (Learning Management System) ?
Les deux impliquent une monétisation et des permissions très différentes.

J'ai retenu un modèle hybride, inspiré de Google Classroom et Quizlet. Du contenu public sans barrière et un espace formateur privé réservé à ses élèves. Un pur B2C n'aurait pas justifié la gestion des rôles. Un pur B2B aurait fermé l'app à tout apprenant curieux.

Segmentation

L'inscription capture quatre profils (apprenti, en poste, en reconversion, autre) et leur motivation (trouver un emploi, monter en compétences, préparer un examen, curiosité). Cette donnée servira à prioriser les contenus et adapter le ton selon le profil dominant observé.

Monétisation, hypothèse non validée

Gratuit à vie pour l'apprenant, qui est le canal d'acquisition. Freemium pour le formateur, qui tire une valeur mesurable de l'outil (temps gagné, suivi structuré), avec une licence possible par organisme.
Un raisonnement inspiré de Duolingo for Schools, sans test de prix ni validation utilisateur.

Ce qui reste à faire

Je n'ai pas mené d'analyse concurrentielle formelle face aux LMS existants (Moodle, Teachable, acteurs de la formation professionnelle).
Un vrai point à combler avant de présenter ce projet comme une réflexion business complète.

Recherche

Recherche documentaire : étude des patterns des applications d'apprentissage (Duolingo, Google Classroom, Quizlet), des mécaniques de mémorisation adaptées à un geste technique, et des principes d'accessibilité. Pas d'entretiens avec des apprentis ou des formateurs : les choix s'appuient sur ce benchmark et sur l'usage visé pour chaque rôle.

Patterns d'apprentissage

La question était structurelle avant d'être esthétique : comment apprend-on le mieux dans ce type d'app ? Deux choix en découlent.

Une entrée en trois écrans (présentation, choix du rôle, questions de profil) plutôt qu'un écran unique qui mélangeait pitch et formulaire.

Deux mécaniques de checklist : case à cocher pour dérouler les étapes, et remise en ordre pour tester la mémorisation. La remise en ordre utilise des flèches plutôt qu'un glisser-déposer, plus fiable au tactile.

Accessibilité

Palette validée WCAG AA sur toutes les combinaisons texte / fond. Un statut n'est jamais porté par la couleur seule : toujours un libellé et une icône (✓ Terminé, ● En cours). L'accent chaud des récompenses est réservé aux fonds pleins, jamais au texte fin.

Mobile ou desktop, selon l'usage

L'espace formateur est pensé d'abord pour l'ordinateur, où se crée un cours.
Sur téléphone, un formateur vient surtout voir qui avance et qui il doit relancer. L'interface y reste utilisable sans être optimisée pour la création, et aucune fonctionnalité n'est bloquée sur mobile.

Méthode

Stack et rôle de l'IA

Claude Code, React / Vite, Supabase (base, authentification, stockage, Row Level Security), Vercel et Make.

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.

Ma règle : décider d'abord dans une conversation Claude dédiée, puis traduire la décision en instruction précise pour Claude Code. Jamais l'inverse. Chaque instruction correspond à une décision déjà prise, pas à une improvisation demandée à l'IA.

Là où reformuler a évité de refaire

Le mode de la checklist avait d'abord été pensé étape par étape. Une relecture a montré qu'une remise en ordre n'a de sens que sur la checklist entière. Corrigé avant d'écrire la moindre ligne.

Un cours dans plusieurs groupes : la question est arrivée une fois le produit fonctionnel. Plutôt que de la repousser, j'ai migré vers une relation plusieurs-à-plusieurs (table cours_groupes), un ajustement ciblé plutôt qu'une refonte.

Le QCM obligatoire : la règle écrite autorisait un cours sans quiz, alors que le formulaire refusait déjà de l'enregistrer. J'ai aligné la règle sur l'app. C'est le quiz qui porte l'XP, les badges et le quiz flash. Un cours sans quiz n'aurait rien rapporté à l'apprenant.

Design

Design system

Logo et anneau de progression

Le « o » de Skillo est un anneau de progression.
Le même motif sert de logo et de composant principal des dashboards : la progression globale côté apprenant, le taux de complétion côté formateur.

Gamification

20 XP pour un quiz, 15 pour une checklist. Des badges aux conditions explicites (premier quiz, première checklist, trois cours terminés, score parfait, premier quiz flash). Des confettis dont l'intensité suit le score (de 30 à 65 particules), plutôt qu'un message de félicitations figé.

Écran de fin de quiz

Parcours d'inscription

L'entrée se fait en trois écrans (présentation, choix du rôle, questions de profil), et se déroule différemment pour l'apprenant et le formateur.

Notifications automatiques

Quatre emails partent sans intervention :

Bienvenue à l'inscription.

Nouveau cours : quand un formateur assigne un cours à un groupe, chaque élève est prévenu.

Rattrapage : quand un élève rejoint un groupe qui a déjà des cours, il reçoit la liste de ce qui l'attend.

Rappel : un scénario programmé repère chaque jour les cours abandonnés depuis 7 jours.

Les cinq emails, du mail de bienvenue au rappel.

Scénario Make du rappel : une requête quotidienne sur la base.

Ce que j'ai choisi de ne pas faire

Streaks et classements : 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, puis écarté faute de cas d'usage réel. Les cours publics appartiennent à un compte officiel, qui voit leurs statistiques et rien d'autre. Chaque formateur reste administrateur de ses propres élèves.

Génération de questions par IA dans l'app : 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

Réinitialisation du 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.

Taux de réussite par question : maquetté sur le détail d'un cours, avec la question la plus ratée mise en avant. Le formateur aurait vu où sa leçon manque de clarté, et pas seulement qui est en retard. Retiré parce que la base ne garde que le score global d'un quiz. Il faudrait enregistrer chaque réponse, par élève et par question.

Espace apprenant

L'anneau donne la progression globale d'un coup d'œil. XP et badges restent visibles sans voler la place des cours en cours.

Du premier jour à la bibliothèque terminée, la carte du haut propose toujours une seule chose à faire : commencer, reprendre, lancer le quiz flash. XP et badges suivent la progression en dessous.

Chaque cours affiche son statut en texte et en icône, jamais par la couleur seule.

Avec 31 cours sur 12 thèmes, une liste unique serait illisible.
Les cours se rangent par thème, avec une recherche globale, et les cours du formateur restent en premier. Les catégories sont contrôlées pour les cours publics, les formateurs gardent le texte libre sur leurs cours privés.

Le mode terrain : dérouler les étapes une à une, ou les remettre dans l'ordre pour tester la mémoire.

Leçon, quiz et checklist sur une même fiche. Les images s'agrandissent au clic.

Démonstration plateforme apprenant

Espace formateur

Vue d'ensemble des groupes et des cours du formateur.

Le dashboard formateur répond à une question : qui dois-je relancer aujourd'hui ?
Il ne compte que les cours assignés aux groupes. Une activité sur un cours public que le formateur n'a pas demandé n'apparaît ni dans le fil ni dans les relances.
Un cours n'est terminé que quand son quiz et sa checklist sont faits. Le taux de complétion a une seule définition, partout : les couples élève et cours assigné au statut « terminé », rapportés au total.

Tant qu’aucun cours n’est assigné, le formateur voit trois étapes au lieu d’un dashboard vide. Le suivi de ses élèves prend leur place dès qu’ils commencent.

Le compte officiel possède les cours publics et suit leur usage, avec les apprenants actifs, les cours terminés et le score moyen. Il ne voit rien des groupes des formateurs.

Un même cours peut être assigné à plusieurs groupes.

Gestion des groupes et des élèves.

Suivi par élève, avec seuils de performance en couleur et en texte.

Création d'un cours avec aperçu Markdown en direct

Démonstration plateforme formateur

Conclusion

Là où j'ai dû intervenir

Deux règles de sécurité qui se vérifiaient mutuellement (élèves / groupes, puis cours / groupes) créaient une boucle que la base refusait d'exécuter. Résolu avec une table intermédiaire.

Des emails qui partaient un jour, plus le lendemain, sans erreur exploitable. Plutôt que chercher une cause invisible, j'ai changé de méthode : l'envoi est déclenché directement depuis l'app.

Make ne capte pas d'exemple tant qu'un scénario tourne. Il faut le mettre en pause pour configurer les champs. Une subtilité découverte à l'usage.

Le rôle choisi disparaissait au rechargement pendant l'inscription. Conservé dans les données de session.

Les cours publics n'avaient pas de propriétaire, donc impossibles à modifier. Rattachés à un compte dédié. Correction rapide, parce que le modèle ne réservait la propriété d'un cours à aucun rôle spécial.

Un cours passait en « terminé » dès le quiz réussi, même si la checklist n'avait jamais été faite. Le suivi formateur comptait donc comme fini un élève qui n'avait pas fait le geste. La règle exige maintenant les deux

Ce que ce projet m'a appris

C'est le premier projet où j'ai géré de bout en bout plusieurs rôles aux permissions croisées, avec des règles de sécurité appliquées par la base elle-même.

Autant de compétences qui n'existaient pas dans ma pratique avant ce projet, acquises en résolvant de vrais blocages plutôt qu'en les lisant.

La bascule d'architecture sur les notifications (trigger Postgres vers appel direct depuis l'app) m'a aussi appris quelque chose sur ma propre méthode. Continuer à déboguer un système instable a un coût caché, celui du temps qu'on ne passe pas à avancer. Savoir arbitrer entre "je corrige" et "je change d'approche" est devenu un vrai réflexe de décision produit, pas seulement technique.

De la réflexion et du cadrage jusqu'à la livraison, ce projet a été mené en 2,5 jours, la preuve la plus concrète de ce que change une collaboration soutenue avec l'IA sur la vitesse d'exécution, sans sacrifier la rigueur des décisions prises en chemin.

Et ensuite

Afficher une vignette de couverture par cours (le champ existe déjà en base).

Activer la confirmation d'email avec un vrai fournisseur, avant tout usage public.

Générer des questions de quiz par IA dans l'interface formateur, à valider avant publication.

Ouvrir un second métier : le champ « domaine » existe déjà.

Brancher la relance du dashboard formateur sur un email automatique, avec un scénario Make.

Enregistrer les réponses par question, pour donner au formateur le taux de réussite de chaque question.

Une répartition des apprenants par âge dans le dashboard admin : la donnée est déjà collectée à l'inscription.