l’Etudiant, c’est le média référent d’informations et de services gratuits autour de l’éducation et de l’orientation pour les jeunes de 15 à 25 ans. Intégré au sein de l’équipe digitale, j’interviennais pour le travail de discovery, de conception, de production puis de maintenance évolutive. J’ai été recruté pour intervenir sur la pose des bases du nouveau CMS de l’Etudiant.
En bref
- Client : l’Etudiant, secteur de l’éducation
- Projet : CMS maison
- Période : Octobre 2018 à Novembre 2019
- Rôle : Product manager
- Périmètre : Initialisation du nouveau CMS maison destiné à gérer tous les contenus de l’Etudiant à terme.
- Équipe et méthode : équipe de 3 personnes travaillant en scrum
- Résultat clé : Tous les contenus ont été migrés, le CMS est toujours là 7 ans après sa mise en ligne : de nouvelles fonctionnalités ont été ajoutées et il a pu être maintenu à jour dans toutes les briques techniques.
Quel était le besoin ?
l’Etudiant disposait d’un CMS vieillissant. Il n’était plus possible de le maintenir à jour techniquement et les bases techniques ne permettaient pas simplement d’alimenter d’autres services. Il avait donc été décidé de développer en partant d’une feuille blanche un nouveau dispositif de gestion basé sur un système d’API permettant ensuite de se connecter à ce que l’on voulait. Par-dessus, une interface graphique a été complètement revue et les process de routing, de cache, de publication, d’édition même des contenus devaient être revus.
Quel a été mon rôle ?
Les principes avaient été posés par le directeur technique et validés par les consultants techniques de l’Etudiant. J’ai été choisi pour intégrer l’équipe technique de l’Etudiant afin de devenir le product owner de l’équipe en charge des développements.
Comment avons-nous travaillé ?
Un travail de discovery avait été réalisé avec les équipes métiers de l’Etudiant afin de comprendre comment proposer une nouvelle interface graphique pour les utilisateurs. J’ai décliné le bilan en US et nous avons démarré les développements. De plus, via des interviews avec les développeurs de l’ancien CMS, j’ai cadré tous les autres besoins (gestion des slugs, gestion du cache, gestion de la publication, gestion du SEO etc.)
En mode sprint, nous faisions les daily, sprint review, rétrospectives avec un delivery par incréments dès validation.
Quels ont été les résultats ?
En janvier 2019, les premières pages publiées par le nouveau CMS étaient en ligne, au fur et à mesure des besoins nous avons ajouté de nombreux composants. En 2026, l’intégralité des contenus a été migrée dessus, de nombreux nouveaux contenus ont été ajoutés, des interactions avec de nombreuses API ont été ajoutées : il est toujours utilisé et ne montre pas de signe de fatigue.
Ce que j’en retiens
S’être rendu compte qu’un produit n’allait plus répondre aux besoins futurs a permis de créer de nouvelles bases solides et de concevoir un nouvel outil allant servir longtemps.
Autres projets pour l’Etudiant
- Simulateur du bac : Développer un simulateur pratique et évolutif
- Tous les projets : l’Etudiant
Missions chez d’autres clients
- [McDonald’s] : Animation de l’univers digital
- Voir aussi : Valoriser plutôt que produire à tout va.
Questions fréquentes
Ne pas arrêter un produit parce qu’il existe peut-il coûter cher ?
Oui : savoir arrêter un produit à temps est un des choix les plus complexes. S’il fonctionne, pourquoi ne pas le continuer ? L’analyse des coûts futurs induits et des limitations qu’il contient by design va permettre de se rendre compte du fait que le produit soit adapté au futur, ou pas.
Il faut ensuite se rendre compte si c’est un arrêt, ou un remplacement. Dans le second cas il faut ensuite arbitrer comme une montée en puissance du nouveau qui remplace petit à petit l’ancien produit OU un remplacement direct.
L’UX/UI d’un CMS est-elle importante ?
Avant de démarrer un CMS, il faut prendre le temps d’échanger avec les personnes qui vont l’utiliser. Ils vont passer des heures dessus et donc ils doivent le comprendre. Il faut ensuite rédiger des guidelines fonctionnelles de manière à ce que tous les formulaires, potentiellement développés par des équipes distinctes aient la même philosophie.