Classyc : anatomie technique d'un SaaS EdTech à 600 utilisateurs

Le problème : un cahier journal qui dévore les soirées

Chaque enseignant du primaire en France doit tenir un cahier journal — le document de préparation pédagogique quotidien qui consigne les séances, objectifs et durées de la journée. En 2025, la majorité le fait encore sur papier, sur Word, ou avec des outils qui demandent autant de temps de saisie que la préparation elle-même.

Classyc automatise la partie la plus chronophage de ce travail. L'emploi du temps génère le squelette du cahier journal, les séances se dupliquent et se réorganisent, et le prof passe de plusieurs heures par semaine à une trentaine de minutes. Le reste du temps est rendu à ce qui compte : préparer le contenu pédagogique.

Aujourd'hui, plus de 600 enseignants utilisent la plateforme. Plus de 600 classes ont été créées, avec une moyenne de 20 événements par semaine dans chaque calendrier enseignant. Le tout avec zéro downtime constaté.

Voici comment on a construit l'infrastructure derrière, avec une équipe de 5 personnes.

Stack technique : des choix pragmatiques

Le socle applicatif

L'application repose sur TypeScript de bout en bout, avec Next.js comme framework full-stack. Ce choix n'est pas anodin pour une équipe de 5 : un seul langage, un seul framework, un seul déploiement. Pas de micro-services prématurés, pas de BFF séparé — le monolithe Next.js gère le rendu, l'API et l'authentification.

Prisma sert d'ORM. Le schema-first approach simplifie la collaboration : le fichier schema.prisma est la source de vérité partagée. Les migrations sont versionnées, les types sont générés automatiquement, et le typage end-to-end élimine une classe entière de bugs à l'intégration front/back.

TypeScript → Next.js (App Router) → Prisma → PostgreSQL (RDS)

La base de données : PostgreSQL sur RDS

PostgreSQL sur Amazon RDS en eu-west-3 (Paris) — le choix de la région n'est pas cosmétique. Quand on manipule des données liées à l'éducation et à des enseignants français, l'hébergement en Union européenne est un prérequis de conformité RGPD, pas une option marketing.

RDS apporte les fondamentaux sans overhead opérationnel : backups automatiques, failover multi-AZ disponible, mises à jour de sécurité gérées. Pour une équipe de 5 sans DBA dédié, c'est un compromis raisonnable entre contrôle et charge opérationnelle.

PgBouncer : le maillon souvent oublié

C'est le détail d'architecture qui a le plus d'impact au ratio effort/bénéfice. Prisma ouvre un pool de connexions par instance — et chaque connexion PostgreSQL coûte de la mémoire côté serveur. Sans pooler externe, on atteint rapidement la limite de connexions de RDS, surtout en serverless ou avec plusieurs instances Next.js.

PgBouncer en mode transaction s'intercale entre Prisma et RDS. Il mutualise les connexions réelles vers PostgreSQL et les répartit à la demande. Résultat concret : l'application supporte les pics de connexions des 600+ enseignants qui préparent leur semaine en même temps (typiquement le dimanche soir et le lundi matin) sans saturation du pool.

Next.js (Prisma Client) → PgBouncer (transaction mode) → RDS PostgreSQL

Cette couche est souvent négligée dans les architectures Next.js + Prisma. Si vous déployez en production avec Prisma et que vous n'avez pas de connection pooler, vous allez rencontrer des erreurs too many connections bien avant d'avoir un problème de performance applicative.

Hébergement et résilience : AWS eu-west-3

Pourquoi AWS Paris

Trois raisons ont guidé le choix :

Latence — les utilisateurs sont des enseignants en France. Un hébergement à Paris garantit des temps de réponse sous les 50 ms pour les requêtes API, ce qui est perceptible sur les interactions calendrier où les drag & drop doivent être fluides.

Conformité — les données restent dans l'UE. Le RGPD impose que le traitement des données personnelles soit encadré, et l'hébergement en France simplifie considérablement la conformité, en particulier dans le contexte éducatif où les exigences sont renforcées.

Écosystème managé — RDS, les groupes de sécurité, le monitoring CloudWatch : tout est intégré. Pour une petite équipe, ne pas avoir à gérer un cluster Kubernetes ou des VMs nues libère du temps pour le produit.

Zéro downtime : pas de magie, de la discipline

Le zéro downtime n'est pas le fruit d'une architecture sur-dimensionnée. C'est le résultat de pratiques simples appliquées systématiquement :

• Migrations Prisma non-destructives (ajout de colonnes nullable avant suppression des anciennes)
• Déploiements progressifs sans interruption de service
• Health checks applicatifs qui retirent automatiquement les instances en erreur
• Backups RDS automatiques avec point-in-time recovery

Pas de blue-green deployment sophistiqué, pas de service mesh. Des fondamentaux bien exécutés.

Co-construction : le produit guidé par le terrain

Manon, l'enseignante qui a dessiné le produit

On aurait pu construire Classyc depuis notre IDE en devinant ce que veulent les profs. On a fait l'inverse. Manon, enseignante du primaire, a été intégrée dès le premier jour comme co-pilote produit.

Concrètement, ça veut dire :

• Chaque fonctionnalité a été challengée par l'usage réel avant d'être développée. Pas de user stories théoriques — des besoins observés en salle de classe.
• Chaque écran a été validé par quelqu'un qui prépare ses journées de cours, pas par un product manager qui projette ce que "l'utilisateur pourrait vouloir".
• La direction produit — quelles features construire, dans quel ordre — vient du terrain.

Itérations post-lancement

Au-delà de Manon, le feedback des 600+ enseignants en production a alimenté des améliorations continues. Le pattern est classique mais souvent mal exécuté : observer l'usage réel, identifier les frictions, corriger rapidement. La différence, c'est qu'avec une stack unifiée TypeScript/Next.js et une équipe réduite, le cycle entre le feedback terrain et le déploiement du correctif se compte en jours, pas en sprints.

Édu-Up : accélérer avec un financement institutionnel

KODY a déposé un dossier auprès du dispositif Édu-Up du ministère de l'Éducation nationale. Ce programme subventionne jusqu'à 50 % du coût global des projets de ressources numériques éducatives, avec un plafond de 70 000 €.

Édu-Up cible spécifiquement les innovations pédagogiques — outils collaboratifs, contenus utilisant l'IA, solutions favorisant l'école inclusive. Le projet doit respecter le RGPD, le RGAA (accessibilité), et être conforme aux référentiels de l'Éducation nationale.

Pour Classyc, cette subvention permettrait de financer les prochaines phases de développement : organisation avancée, fiches de préparation augmentées, et les fonctionnalités identifiées par la communauté enseignante.

Ce qu'on retient : une équipe de 5 peut livrer un produit complet

Le vrai enseignement de Classyc n'est pas technique — il est organisationnel. Une équipe de 5 tech peut concevoir, développer, déployer et commercialiser un SaaS complet, de l'architecture serveur à l'acquisition utilisateur, à condition de :

Choisir une stack unifiée. TypeScript partout, Next.js full-stack, Prisma comme couche d'abstraction. Moins de contexte switching, moins de surface de maintenance, plus de vélocité.

S'appuyer sur le managé. RDS plutôt qu'un PostgreSQL auto-hébergé. PgBouncer pour le pooling. CloudWatch pour le monitoring. Chaque service managé est un ingénieur que vous n'avez pas besoin d'embaucher.

Co-construire avec le terrain. Le meilleur product-market fit ne sort pas d'un lean canvas — il sort de l'observation directe de l'utilisateur qui va vivre avec votre produit au quotidien.

Ne pas sur-architecturer. Un monolithe Next.js, un PostgreSQL, un PgBouncer. Pas de micro-services, pas de message queue, pas de Kubernetes. Quand la complexité organisationnelle est faible, la complexité technique doit l'être aussi.

600 profs inscrits. Zéro downtime. Un dossier de subvention publique déposé. Et ce n'est que le début.

Classyc est développé par KODY, agence web & mobile à Lyon. Découvrez la plateforme sur classyc.fr.