Moderniser un CMS sans interrompre la publication
Un CMS en production a été nettoyé pour une équipe éditoriale grandissante sans mettre le site hors ligne.
Détails du projet
Consultant systèmes / Responsable implémentation
L'organisation publiait en continu depuis des années. Le CMS avait accumulé les décisions de toutes les personnes qui l'avaient touché, y compris des gens partis dont la logique n'avait jamais été documentée. Des types de contenu précis à l'origine avaient été étirés. Des champs prévus pour un type de données servaient à autre chose. La médiathèque était remplie de fichiers nommés "final_v3_UTILISER-CELUI-CI.jpg." L'équipe de publication était composée de rédacteurs et d'éditeurs, pas d'administrateurs systèmes. Avec la croissance de l'équipe, les règles non écrites ne se transmettaient plus. Les erreurs de publication se multipliaient : mauvaises images, contenu dans les mauvaises catégories, corrections manuelles nécessaires.
Rendre le CMS utilisable pour une équipe grandissante sans interrompre la publication ni demander à l'équipe d'apprendre de nouveaux outils.
Le site ne pouvait pas être mis hors ligne. La publication ne pouvait pas s'arrêter. Il n'y avait pas de personnel technique. Tout ce que je construisais devait fonctionner pour les personnes réellement présentes.
Exécution
J'ai demandé à m'asseoir à côté de deux ou trois membres de l'équipe pendant qu'ils publiaient. Pas pour surveiller, mais pour voir la séquence réelle de décisions entre l'article terminé et le clic sur publier. Je cherchais les contournements. Chaque contournement est un signal sur l'endroit où le système échoue pour l'utilisateur.
Mes observations tombaient en trois groupes. D'abord : les sources d'erreurs actives, quelques types de contenu dont les champs obligatoires étaient régulièrement ignorés, et des schémas de catégories qui se chevauchaient. Ensuite : les choses désordonnées mais fonctionnelles, comme les noms de fichiers dans la médiathèque. J'ai documenté plutôt que nettoyé. Enfin : les choses qui gênaient esthétiquement sans conséquence opérationnelle. Je les ai laissées.
Pour la catégorisation, j'ai travaillé avec deux éditeurs seniors pour tracer des lignes claires entre les catégories qui se confondaient. Nous avons supprimé les sous-catégories ambiguës et les avons rattachées à des catégories parentes claires. J'ai d'abord fait ça en staging, validé, puis appliqué en production pendant des créneaux de faible trafic sur trois soirées en deux semaines.
La médiathèque était un problème différent. On ne peut pas renommer des milliers de fichiers sans risquer de casser des références. J'ai créé une convention de nommage pour tout le contenu futur et l'ai documentée dans un guide de publication d'une page. Une page exprès. Un guide qui nécessite de scroller ne sera pas consulté en plein deadline.
J'ai formé une personne en interne comme point de contact pour les questions. J'ai choisi la personne vers qui l'équipe se tournait déjà naturellement. On ne peut pas donner de l'autorité à quelqu'un par un titre ; il faut trouver la personne qui a déjà l'autorité informelle et rendre son savoir transmissible.
Résultats
Les erreurs de publication ont chuté nettement dès le premier mois. L'ambiguïté de catégorisation avait disparu. Quand il n'y a qu'un seul endroit correct pour quelque chose, c'est là que ça finit.
Le guide était utilisé. Les questions que la personne de référence recevait sont passées de "ça va où ?" à "le guide dit X mais dans ce cas Y." L'équipe avait intériorisé le flux et travaillait sur les cas limites, pas sur les fondamentaux.
Avec un système en production et une équipe non technique, le plus dangereux est d'aller vite. Le deuxième plus dangereux est d'imposer quelque chose que l'équipe n'a pas aidé à construire. Je sais ralentir et distinguer ce qui doit changer de ce qui en a juste l'air.