FICHES PÉDAGOGIQUES

Une plateforme à bout de souffle

Fiches Pédagogiques, c'est une plateforme utilisée au quotidien par des enseignants du primaire pour trouver, filtrer et télécharger des fiches d'exercices classées par cycle, niveau et domaine. Le produit tournait depuis plusieurs années avec une base d'utilisateurs établie — mais la base technique avait vieilli au point où chaque évolution devenait coûteuse et risquée.

Quand Flippad a repris le projet en octobre 2024, les besoins du client étaient précis : moteur de recherche avec filtres combinés, back-office éditorial moderne, système de paiement multi-format, et une architecture capable de tenir dans la durée. Greffer tout ça sur l'existant aurait été plus long et plus fragile que de tout reconstruire. La décision a été rapide : on repart de zéro.

Trois devs, un produit

On était trois développeurs. Kylian assurait le lead backend et le pilotage du projet — architecture API, découpage en versions, relation client. Alexandre et moi portions le frontend, avec une répartition naturelle : je couvrais l'essentiel de l'application côté client (plus de 1 600 commits), Alexandre apportait son regard sur l'intégration et les parcours utilisateurs.

Le design venait de La Guilde, un studio externe. On recevait les maquettes au fil du projet et on les implémentait, avec une coordination constante pour identifier ce qui ne passait pas techniquement et ajuster.

Côté backend, Kylian a adopté une stratégie de releases progressives — plus de 40 versions avant la v1.0. Chaque stabilisation de l'API débloquait un nouveau chantier côté front. Ça donnait un rythme clair, mais ça demandait d'anticiper en permanence ce qui allait changer.

Ce qui résistait vraiment

Construire un frontend contre une API encore en construction, c'est un exercice d'équilibre constant. Il faut savoir ce qui est figé, ce qui est provisoire, et ne pas over-architecturer sur des contrats qui vont évoluer. Les pages publiques, le moteur de recherche, le tableau de bord utilisateur et les parcours de paiement ont chacun été construits en suivant la maturité du backend.

Le système de paiement a été le chantier le plus dense côté interface. Derrière un parcours d'achat en apparence simple se cachaient des cas bien distincts : abonnements individuels via Stripe, achats à l'unité, licences pour les établissements scolaires avec gestion de mandats administratifs et invitations de collaborateurs, abonnements manuels, codes promotionnels. Chaque flux avait ses propres règles et ses propres cas limites à couvrir.

La préservation du SEO était une contrainte non négociable dès le départ. La plateforme existante avait un capital organique significatif — une refonte mal gérée peut le détruire en quelques semaines. Structures d'URL préservées, redirections en place, chaque nouvelle page au moins aussi bien optimisée que l'ancienne.

La migration des données de l'ancienne plateforme a aussi représenté un volume conséquent : des années de contenu avec des relations entre entités parfois incohérentes, à nettoyer et réimporter sans rien perdre. En mars 2026, un audit de sécurité complet a couvert l'ensemble de la plateforme — authentification, validation des entrées, contrôle d'accès, flux de paiement.

17 mois plus tard

En mars 2026, la v1.0 frontend est sortie. 7 800 commits cumulés côté backend et frontend, 17 mois de développement, une plateforme entièrement reconstruite et en production.

Ce que cette mission m'a le plus appris : travailler contre une API vivante oblige à distinguer ce qui est architectural de ce qui est conjoncturel. On ne peut pas tout stabiliser en même temps — il faut choisir ses points d'appui et accepter que d'autres bougent encore.

Et puis la force d'une petite équipe avec des périmètres clairs. À trois, avec Kylian et Alexandre, on a livré quelque chose qui aurait pu mobiliser une équipe bien plus grande. La clarté des responsabilités évite la friction et maintient le rythme sur la durée.