3. Recherche utilisateur et phase de discovery

Avant de concevoir quoi que ce soit, il était essentiel de comprendre comment les équipes de Mediapart travaillaient concrètement avec le CMS existant — devenu rigide, difficile à maintenir, et souvent inadapté aux pratiques éditoriales actuelles.

Nous avons mené une phase d’immersion approfondie au sein de la rédaction :

• Entretiens avec des journalistes, éditeur·ices, correcteur·ices, responsables des podcasts…
• Sessions de shadowing pour observer les usages concrets sur le CMS existant
• Analyse des tickets internes et feedbacks terrain pour identifier les points de douleur récurrents

Un aperçu du CMS actuel dans Drupal…

Frictions identifiées :

• Rendu visuel trompeur : l’aperçu des articles dans le CMS était éloigné de celui en ligne, ce qui rendait difficile l'édition et la mise en forme d'un sujet
• Statuts flous : l'équipe nous avait remonté des difficultés dans le suivi du parcours d’un article entre les différents pôles (rédaction, édition, correction...)
• Interface datée, rigide, peu adaptée aux usages collaboratifs
• Contenus enrichis difficiles à insérer (médias, vidéos, documents…)

Cadrage du MVP :
Nous avons décidé, avec l’équipe CMS, de focaliser le MVP sur la page Article, centrale dans les usages quotidiens. Ce choix stratégique a permis de maximiser l’impact tout en gardant un périmètre maîtrisable.

4. Définition produit & priorisation fonctionnelle

Nom du projet :
Après votation en interne, ce nouveau CMS a été baptisé « Pinto », en hommage au lanceur d’alerte Rui Pinto (à l'origine des Football Leaks), clin d'œil assumé à la mission du journal.

Vision produit :

• Rendre l’outil plus ergonomique et accessible à toute la rédaction
• Fluidifier la collaboration entre pôles éditoriaux
• Assurer la souveraineté des contenus et des données
• Préparer l’avenir en intégrant les nouveaux formats éditoriaux (vidéo, podcast…)

Fonctionnalités prioritaires du MVP :

• Édition de texte en blocs
• Ajout de contenus enrichis (vidéos, images, audio...)
  
• Gestion des statuts éditoriaux (brouillon, en attente de validation, publié...)
• Historique des statuts 
• Commentaires internes entre pôles

Contraintes :

• Coexistence longue avec Drupal, le CMS historique
• Des milliers d’articles existants non migrés automatiquement
• Priorité donnée au desktop, mais volonté de garder une interface responsive minimale

5. Conception UX/UI

Pour concevoir l’interface de Pinto, j’ai cherché à créer un environnement à la fois flexible, clair et adapté aux usages métiers. L’inspiration m’est venue de Notion et WordPress, deux références solides dans l’édition de contenu, que j’ai adaptées aux besoins spécifiques de la rédaction.

Le nouveau système d'ajout de bloc

Une interface modulaire, pensée en blocs
La page Article repose sur un système de blocs éditoriaux : chaque élément (titre, image, citation, vidéo…) peut être ajouté, déplacé, modifié ou supprimé de manière intuitive. Cette approche permet aux journalistes de structurer leurs contenus avec plus de souplesse, tout en garantissant une mise en page cohérente.

Les options de formatage du texte apparaissent lors de la sélection

Tests utilisateurs et feedback en continu
En binôme avec la Product Manager, nous avons mis en place un rythme bimensuel de sessions de feedback avec un groupe pilote de la rédaction. Ces sessions de discovery nous ont permis :

• D’identifier les points de friction très tôt
• De tester les prototypes sur les parcours critiques
• D’itérer rapidement à partir des retours terrain

Un design system solide et évolutif
Pour soutenir l’interface, j’ai mis en place un design system basé sur MUI, une librairie robuste adaptée aux outils SaaS. Ce choix nous a permis :

• D’unifier l’expérience et les composants dès les premières pages
• De gagner du temps côté développement
  
• De préparer facilement l’extension future à d’autres vues du CMS

6. Recette & accompagnement au changement

La version beta n’est pas encore ouverte à la rédaction, mais nous avons mené une recette continue en parallèle du développement. Une phase d’accélération a été engagée en vue du lancement prévu à la rentrée 2025.

Communication en interne :

• Présentation des maquettes et prototypes à l’équipe produit
• Sessions de discovery et démos bimensuelles
• Démonstrations régulières à l’ensemble de l'équipe de Mediapart, lors des bilans produit semestriels
• Implication d’un groupe de testeurs dès l’ouverture de la beta

Premiers retours :
“Fluide et réactif”
“Facile à prendre en main”
“Trop bien de pouvoir déplacer un bloc”
“Ne pas avoir une barre de mise en forme classique peut demander de l’apprentissage”

Ces retours ont déjà donné lieu à des ajustements, notamment sur les statuts ou l’insertion de blocs.

Conclusion & apprentissages

Ce projet m’a permis de travailler sur un outil critique, dans un environnement exigeant, à la croisée du produit, de la tech et de l’éditorial. J’y ai appris à :

• Composer avec des contraintes métier fortes et un existant complexe
• Travailler de façon transversale avec les équipes web, mobile et produit
• Améliorer mes process de recherche UX et ma vision des outils SaaS B2B
• J’ai aussi dû faire preuve de pédagogie dans un environnement peu familier avec la culture produit, et poser les bases d’une démarche itérative adaptée au contexte de la presse écrite.

Mais ce qui m’a le plus motivé, c’est de contribuer à un projet collectif et porteur de sens, au service d’un journal que j’admire, et de concevoir un outil qui facilite le travail de celles et ceux qui font vivre l’information indépendante au quotidien !