Pourquoi l'éducation a besoin d'un OS.

Le constat

Le secteur s'est équipé outil par outil, douleur par douleur. Un CRM quand le recrutement a fait mal. Un ERP de scolarité quand la gestion des apprenants a débordé. Un logiciel de planning, un outil d'émargement, un classeur Qualiopi, et — toujours — des tableurs pour ce que personne ne couvrait. Chaque achat était rationnel. Le résultat ne l'est pas : des organismes qui possèdent dix logiciels et zéro système. Les données de recrutement ignorent la scolarité, la scolarité ignore la facturation, et l'humain fait la navette entre les trois.

Tout le monde déborde, personne ne relie

Regardez les périmètres réels : le CRM d'admission fait aussi du matching entreprises, l'ERP de scolarité fait aussi de la prospection, la plateforme d'alternance fait aussi du CRM. Chaque éditeur, pour croître, déborde sur l'étape voisine. D'où un paradoxe : des chevauchements partout, une continuité nulle part. Le même candidat existe dans trois outils, avec trois orthographes et zéro synchronisation. Le référentiel unique de l'étudiant — colonne vertébrale de n'importe quelle industrie mature — n'existe nulle part sur ce marché.

La bataille n'est pas fonctionnelle, elle est référentielle. Les fonctionnalités sont chez les éditeurs ; l'identité de l'étudiant et la continuité de son parcours n'appartiennent à personne.

Pourquoi ça ne peut pas continuer

La charge réglementaire croît plus vite que les équipes. Qualiopi exige des preuves sur tout le parcours ; le BPF croise recrutement, scolarité et financement ; les enquêtes d'insertion imposent de relier la scolarité au placement, donc de savoir ce que devient l'étudiant après. Aucun outil ne détient seul ces chiffres, puisque chacun ne voit que son étape. Aujourd'hui, c'est un humain avec Excel qui fait la jointure. Pendant ce temps, les groupes consolident — multi-marques, multi-campus — et découvrent que leurs outils, eux, ne consolident pas. Les petites écoles, elles, n'ont simplement pas les bras.

Ce qu'on entend par OS

Un référentiel unique — apprenants, formations, campus, comptes, droits — et des apps qui s'y branchent. Le critère décisif tient en deux phrases : quand vous activez une nouvelle app, elle connaît déjà vos données ; quand vous la coupez, vous ne perdez rien. C'est exactement ce qui distingue un système d'exploitation d'une collection de logiciels — et c'est ce que nous construisons.

Notre méthode : connecter d'abord, construire basique ensuite

Nous ne serons jamais le meilleur éditeur de chaque brique. Nous serons le meilleur connecteur entre les meilleures. Les verticaux historiques portent vingt ans de complexité réglementaire française : on ne les déloge pas, on s'y branche — sur leurs API officielles. Nos apps natives sont le minimum utile pour les briques dont vous n'êtes pas équipé, jamais des concurrents premium. Ce n'est pas une limite qu'on cache : c'est une discipline de roadmap, et une promesse commerciale — pas de conflit avec votre existant, pas de migration forcée.

Nous construisons app par app, en production, avec de vrais réseaux d'écoles. Nous n'affichons que ce qui s'active réellement. Et nous ouvrons le socle — API publique, serveur MCP — plutôt que d'enfermer : vos données, vos outils, votre rythme.

Où on va

L'endgame : couvrir tout le cycle de vie de l'étudiant, du premier clic d'un candidat jusqu'à son premier contrat, sur un seul socle — les meilleurs outils du marché connectés entre eux, les briques manquantes fournies. Pour qu'un organisme de formation puisse être administré par une équipe minuscule, parce que le système fait le travail de fond.

Un étudiant, une identité, de son premier clic à son premier contrat. C'est tout le projet.