Concevoir une plateforme éducative durable : retour d'expérience Product Engineering sur NablaSciences

Lorsqu'on lance un projet web éducatif, la tentation est souvent de commencer par les fonctionnalités visibles : pages, design, formulaires, contenus ou espace utilisateur.

Pour NablaSciences, la réflexion a été différente.

Le sujet n'était pas de développer une plateforme Symfony. Symfony n'était qu'un moyen. Le vrai sujet était de construire un socle durable, capable d'évoluer pendant plusieurs années sans devenir fragile à chaque nouvelle fonctionnalité.

Cette rétrospective revient sur les décisions de conception, les arbitrages techniques et les principes d'architecture qui ont guidé la plateforme.

Une plateforme éducative durable ne se juge pas seulement à sa première version. Elle se juge à sa capacité à absorber les évolutions sans perdre sa cohérence.

Contexte

NablaSciences devait permettre de publier, organiser et faire évoluer des contenus scientifiques dans un environnement web maîtrisé.

Dès le départ, plusieurs contraintes devaient coexister :

• garder une architecture lisible ;
• permettre une évolution progressive du produit ;
• éviter une complexité technique prématurée ;
• offrir une expérience utilisateur fluide ;
• rester compatible avec un hébergement PHP classique ;
• conserver un contrôle clair sur le modèle applicatif.

Individuellement, ces objectifs sont simples à formuler.

La difficulté apparaît lorsqu'ils doivent tenir ensemble dans un même produit. Une solution très flexible peut devenir difficile à maintenir. Une architecture trop simple peut devenir limitante. Une approche trop dynamique peut alourdir l'exploitation.

Le travail Product Engineering a donc consisté à trouver le bon niveau de structure.

Les limites d'une plateforme éducative classique

Un projet éducatif peut facilement dériver vers plusieurs formes :

• un blog ;
• une bibliothèque de ressources ;
• une plateforme de cours ;
• un portail pédagogique ;
• un service d'accompagnement ;
• un produit plus applicatif avec comptes, parcours ou tableaux de bord.

Le risque est de choisir trop tôt une architecture optimisée pour un seul de ces scénarios.

Une plateforme trop proche d'un simple blog peut devenir difficile à faire évoluer. Une plateforme trop proche d'une application complète peut introduire de la complexité avant que les usages soient stabilisés.

Il fallait donc concevoir NablaSciences comme une base progressive : suffisamment structurée pour durer, suffisamment sobre pour ne pas figer le produit.

Les objectifs de conception

Les objectifs n'étaient pas seulement techniques.

Ils portaient sur la manière dont le produit pourrait évoluer :

• accueillir différents types de contenus éducatifs ;
• structurer les pages et les ressources de manière cohérente ;
• faciliter les évolutions fonctionnelles ;
• garder une base de code lisible ;
• limiter la dépendance à des briques difficiles à maintenir ;
• permettre des ajustements sans réécrire toute la plateforme.

Cette logique a guidé les choix dès la conception.

L'enjeu n'était pas de construire la version la plus complète possible. L'enjeu était de poser une architecture capable de supporter les prochaines étapes.

Les décisions de Product Engineering

Plusieurs décisions ont structuré le projet.

Partir d'un socle serveur maîtrisé

Le rendu serveur permettait de conserver une architecture simple à déployer, facile à comprendre et compatible avec l'hébergement cible.

Ce choix limitait la complexité opérationnelle : moins de services à maintenir, moins de déploiements à coordonner, moins de dépendances runtime.

Garder le JavaScript ciblé

L'objectif n'était pas de transformer toute la plateforme en application frontend.

Turbo et Stimulus permettaient d'ajouter de la fluidité et des interactions là où elles apportaient une vraie valeur, sans basculer dans une Single Page Application complète.

Préserver la lisibilité du domaine

Une plateforme éducative doit rester compréhensible dans son code comme dans son usage.

Les notions de pages, contenus, catégories, ressources et parcours futurs devaient pouvoir évoluer sans devenir une accumulation de cas particuliers.

Ne pas surdimensionner la première version

Certaines fonctionnalités possibles ont été volontairement différées.

Ce choix évite de construire des abstractions trop tôt. Il permet de laisser les usages réels guider les prochaines évolutions.

Les options étudiées

Plusieurs directions étaient possibles.

WordPress

WordPress offrait une mise en place rapide, un écosystème éditorial mature et un coût d'entrée faible.

Mais le projet demandait aussi un contrôle plus fin de l'architecture applicative, du modèle de code et des évolutions futures. Le risque était de dépendre progressivement d'un assemblage de plugins et de conventions difficiles à reprendre sur le long terme.

Drupal

Drupal constituait une alternative crédible pour structurer des contenus complexes.

Sa puissance de modélisation, ses taxonomies et son architecture éditoriale auraient pu répondre à une partie du besoin. Mais pour une première version de NablaSciences, cette puissance aurait introduit une complexité supérieure à la valeur immédiate attendue.

Architecture headless

Une approche headless aurait séparé backend et frontend.

Elle aurait apporté de la flexibilité, mais aussi davantage de composants, de déploiements et de points de maintenance. À ce stade, cette sophistication ne créait pas suffisamment de valeur produit.

Single Page Application

Une SPA pouvait offrir une expérience très fluide.

Mais elle introduisait aussi plus de complexité de build, une dépendance plus forte à Node.js, un modèle d'exploitation plus lourd et des arbitrages supplémentaires autour du rendu initial.

Le gain d'expérience ne compensait pas le coût de maintenance pour cette phase du produit.

Pourquoi Symfony

Symfony a été retenu parce qu'il offrait un équilibre utile pour ce contexte.

Il permettait de conserver :

• un rendu HTML natif ;
• une architecture applicative explicite ;
• un contrôle complet du code ;
• une séparation claire des responsabilités ;
• un déploiement compatible avec un environnement PHP classique ;
• une base solide pour des évolutions futures.

Ce choix n'était pas un choix de préférence technologique.

C'était un choix d'architecture : utiliser un framework suffisamment structurant pour durer, sans ajouter une couche de complexité inutile à la première version.

Le rôle de Turbo et Stimulus

La question de l'expérience utilisateur restait importante.

Une navigation purement serveur peut être robuste, mais elle peut aussi donner une impression moins fluide si chaque interaction recharge toute la page.

Turbo a permis d'améliorer la navigation sans abandonner le rendu serveur. Stimulus a permis d'ajouter des comportements ciblés sans installer une architecture frontend complète.

Cette combinaison a permis de préserver trois objectifs :

• une expérience plus fluide ;
• une architecture sobre ;
• une maintenabilité raisonnable.

Le JavaScript reste ici un outil d'amélioration progressive, pas le centre de gravité du produit.

L'architecture retenue

L'architecture a été pensée comme un socle évolutif.

Elle devait organiser plusieurs dimensions :

• les pages structurantes ;
• les contenus éducatifs ;
• les catégories ou regroupements thématiques ;
• la navigation ;
• les médias ;
• les futurs points d'extension.

Chaque élément devait pouvoir évoluer sans imposer une refonte complète.

L'objectif n'était pas seulement de créer des pages. Il était de créer un modèle suffisamment clair pour que la plateforme puisse accueillir de nouveaux contenus, de nouvelles sections et de nouveaux usages.

Les principes de modularité

La modularité ne se limite pas à découper le code en fichiers.

Dans NablaSciences, elle repose sur plusieurs principes.

Des responsabilités séparées

Les pages, les contenus, les contrôleurs, les templates et les comportements frontend doivent conserver des responsabilités lisibles.

Quand une fonctionnalité évolue, il faut pouvoir identifier où intervenir sans suivre une chaîne de dépendances opaque.

Des templates réutilisables

Twig permet de composer des vues réutilisables et cohérentes.

Cette approche réduit la duplication et facilite l'évolution progressive de l'interface.

Une interaction frontend ciblée

Stimulus permet de rattacher des comportements à des zones précises de l'interface.

Cela évite de transformer chaque besoin d'interaction en architecture frontend globale.

Un modèle prêt à évoluer

La plateforme devait pouvoir accueillir de nouvelles familles de contenus ou de parcours sans réécrire ses fondations.

Cette capacité d'évolution a plus de valeur qu'une sophistication immédiate.

Préparer les évolutions futures

Une plateforme éducative durable doit accepter l'incertitude.

Au démarrage, tous les usages ne sont pas connus. Certains besoins émergent avec les contenus, les retours utilisateurs ou l'évolution du projet.

L'architecture devait donc permettre plusieurs trajectoires :

• enrichir les formats de contenus ;
• créer de nouvelles pages structurantes ;
• ajouter des fonctionnalités interactives ciblées ;
• améliorer les parcours utilisateurs ;
• renforcer progressivement les outils d'administration ;
• faire évoluer le modèle sans rupture majeure.

Préparer l'avenir ne signifie pas tout développer dès le départ.

Cela signifie éviter les décisions qui bloqueraient les évolutions raisonnablement prévisibles.

Les difficultés rencontrées

La première difficulté a été de clarifier le niveau d'ambition de la plateforme.

Un produit éducatif peut prendre plusieurs directions. Il fallait donc éviter de figer trop tôt une vision trop étroite ou trop large.

La deuxième difficulté concernait le bon niveau de complexité.

Chaque technologie supplémentaire apporte des possibilités, mais aussi un coût durable. Le projet a donc privilégié une architecture volontairement sobre.

La troisième difficulté était liée à la projection long terme.

Il fallait construire une première version concrète tout en gardant en tête les évolutions futures. Cet équilibre est délicat : trop prévoir ralentit, trop peu prévoir fragilise.

Ce que je ferais différemment aujourd'hui

Avec le recul, je formaliserais encore plus tôt certains invariants produit.

Par exemple :

• les types de contenus appelés à durer ;
• les règles de structuration des pages ;
• les limites entre contenu, interaction et future logique applicative ;
• les conventions de templates ;
• les scénarios d'évolution probables.

J'introduirais aussi plus tôt quelques contenus réels dans les premières itérations.

Les contenus réels révèlent rapidement les limites d'une structure : longueurs de titres, densité des pages, besoins de navigation, variations de mise en page.

Ces ajustements ne remettent pas en cause les arbitrages principaux. Ils auraient surtout permis de valider plus tôt certaines décisions de structure.

Enseignements Product Engineering

Le principal enseignement de NablaSciences est qu'une plateforme éducative doit être pensée comme un système évolutif.

La technologie ne suffit pas à rendre un produit durable.

La durabilité vient de la cohérence entre :

• le modèle de contenu ;
• l'architecture applicative ;
• les contraintes d'exploitation ;
• l'expérience utilisateur ;
• la capacité à faire évoluer le produit sans rupture.

Symfony, Turbo et Stimulus ont été utiles parce qu'ils servaient cette cohérence.

Plus qu'un choix de stack, il s'agissait d'un choix de trajectoire : construire une base suffisamment solide pour évoluer, sans surcharger la première version.

Ce que je retiens aujourd'hui

NablaSciences m'a rappelé qu'un bon produit web se construit souvent par retenue.

Il ne s'agit pas d'utiliser l'architecture la plus moderne ou la plus complète. Il s'agit de choisir une structure qui respecte les contraintes réelles du projet et laisse de la place aux évolutions.

Le rôle du Product Engineer est précisément là : comprendre la trajectoire probable du produit, identifier les décisions qui comptent tôt, et éviter celles qui rendraient la suite plus coûteuse.

Dans NablaSciences, Symfony était un moyen. Le sujet principal était la conception d'une plateforme éducative durable.