睦勝 Geek
Qui sait quand il faut combattre et quand il faut s'en abstenir sera victorieux.

[INSIGHT] Pourquoi la migration des contenus est (presque) toujours sous-estimée dans un projet CMS


Après quelques années passées dans la mise en place de sites web pilotés par des CMS, j'ai pu constater un certain nombres d'erreurs et de maladresses qui ressortent des échanges que j'ai pu avoir avec des clients potentiels ou actuels.
Dès lors, j'ai décidé de distiller quelques articles mettant en avant ces erreurs récurrentes. Je tâcherai, dans la mesure du possible, de fournir également quelques idées pour les éviter.

La première erreur commune concerne la migration de contenus. D'expérience, négliger la migration des contenus est le problème numéro 1 dans le palmarès des erreurs qui font totalement dérailler les budgets et les plannings dans les projets CMS. Et il y a plusieurs raisons à cela.

L'histoire commence généralement avant même que nous ne vendions notre technologie, quand les commerciaux et les coordinateurs de projets posent la question fatidique : "Et pour la migration des contenus, on peut automatiser ?"

La réponse rapide donnée par beaucoup de vendeurs est : "Bien sûr! Nous avons des scripts et des APIs qui rendent la migration de contenus facile". Et beaucoup, sinon tous, des clients pensent alors : "Super! Sujet suivant?"

J'entends beaucoup de chef de projets se voir offrir cette réponse mais la vérité, c'est que c'est trompeur. Le chef de projet technique s'attend à effectuer la migration complète du contenu. Il (ou elle) va alors faire une estimation du temps nécessaire pour réaliser cette tâche en se basant à la fois sur le volume du contenu à récupérer et sur le temps nécessaire pour implémenter les scripts de conversion. Il va alors en déduire une date de livraison. A mi-chemin de la migration, ou même plus loin, il va inévitablement rencontrer un certain nombre d'obstacles.

Par exemple :

  • Le contenu doit être ré-édité pour le web parce qu'il ne répond pas à certains standards ou parce qu'il a été directement copié depuis un média traditionnel.
  • Le contenu doit être réorganisé pour se conformer à une nouvelle architecture.
  • Le contenu est vieux, obsolète ou non-pertinent et il n'a pas été retouché depuis 5 ans ou plus.
  • La majorité du contenu ne fait plus d'audience et n'attire plus personne.
  • Il n'y a pas eu d'analyse de la qualité des contenus basée sur les usages et le taux de conversion depuis un certain temps.
  • Les chefs de projets sous-estiment l'effort nécessaire à la rédaction et la conversion manuelle des contenus.
  • Les contenus ne sont pas clairement séparés du design, rendant l'automatisation difficile voire impossible.
  • Les métadonnées relatives aux contenus doivent être régénérées parce que leurs classifications ou les systèmes afférents ont évolué. Le ré-étiquetage des contenus devient une source majeure de migraine.
  • La persistance des URLs après migration des contenus peuvent poser problème. Les URLs peuvent avoir changé et/ou suivi une autre nomenclature/arborescence, ce qui rend difficiles la définition et l'implémentation d'un système de redirection.

Et ce qui s'ensuit est précisément le point où les projets déraillent. Après avoir rencontré un ou plusieurs de ces problèmes, il s'avérera nécessaire de constituer un sous-projet afin de dégrossir, raffiner et polir la nouvelle architecture d'information. On se focalisera un peu plus sur le design et la qualité du contenu. Il est tout-à-fait normal, pour de nombreux sites, de se débarrasser de 70% du contenu existant, tandis que le reste devra être réorganisé et réédité.

En gardant bien en vue toutes ces contraintes, la question initiale concernant l'automatisation de la migration des contenus ne tient plus vraiment la route, si ?

Voilà donc quelques pistes pour vous aider à définir des objectifs et des plannings réalistes… et plus important encore, pour vous aider à les respecter.

Typiquement, vous ne voulez pas migrer tels quels des contenus marchands et marketing. Ils auront besoin d'un lifting aussi bien structurel qu'organisationnel. Bien sûr, il existe des situations où vous voudrez quand même automatiser cette migration… mais ces cas sont limités à une poignée de scénarios :

  • Les sites média : journaux, magazines, chaînes de télévision, radio… qui veulent migrer entièrement leur contenu et garder leurs archives en ligne pour une série de raisons liées aux SEO longue comme le bras.
  • Les pages d'informations produits : des sites qui veulent convertir leurs catalogues de produits. Cependant, la plus courante - et la plus rapide - des solutions est, dans ce cas, de passer par un système de GIP/PIM (Gestion de l'Information Produit / Product Information Management en Anglais) ou un PGI/ERP (Progiciel de Gestion Intégré / Enterprise Resource Planning) pour importer et synchroniser des données.
  • Du contenu statique : de communiqués de presse historiques, des blogs ou des contenus similaires qui doivent être conservés en l'état pour des raisons d'archivage (… et de SEO).

Et encore, dans le cas où vous avez décidé qu'il faut absolument automatiser la migration des contenus, vous avez de fortes chances de sous-estimer la tâche.
Et voici le Top 5 des causes :

  • Le contenu existant est mal formaté : automatiser du code HTML mal formaté est (très) loin d'être trivial.
  • Le nombre de styles (et de donc de designs) appliqués aux contenus à conserver vous est inconnu : cela complique l'automatisation en créant un nombre inconnu d'exceptions à prendre en charge.
  • Un formatage non-homogène : même si le contenu à conserver est stocké au format XML NTIF (News Industry Text Format), vous serez surpris de voir à quel point le formatage des contenus a évolué. A cause d'un défaut de validation des entrées et du stockage et de l'absence de contexte historique, la migration peut poser des problèmes (sérieux).
  • Les APIs et les outils de migrations sont inexistants ou ne répondent pas aux besoins : il est très important de faire cette vérification lors du choix d'un CMS.
  • L'absence de documentations relatives aux contenus historiques : cela induira un grand nombre d'exceptions et de cas particuliers dans le processus d'importation des contenus et mettra très certainement à mal toutes les estimations.

En conclusion, NE sous-estimez PAS la complexité d'une migration de contenus et surtout, NE vous posez PAS d'objectifs irréalistes concernant l'automatisation. Prévoir et prédire font partie de la planification et pour atteindre votre but, il est important que vos prédictions soient aussi précises que possible.

A propos de Young Sun TAN :

Young Sun TAN est un geek webophile, technophile, bidouilleur et gourmet.

Sur la toile depuis 1995 avec sa première page web (une biographie de Beaumarchais pour le compte du collège Beaumarchais de Paris), il revendique une identité de "digital native". Après une Terminale S au Lycée Louis-le-Grand à Paris et un Master en Informatique option Ingénierie Informatique - Systèmes d'Information, il a entamé une carrière d'analyste web et est désormais Project Leader pour le Groupe Lagardère. Il compte parmi ses réalisations les sites de Celebrity Cruises, Royal Caribbean ainsi que Gulli, Canal J, Tiji et Europe 1.

Menant un veille constante sur les évolutions du web et du développement, son expertise couvre le PHP-MySQL, le framework jQuery ainsi que le CMS eZPublish et Symfony pour lequel il a une affection toute particulière.

Côté détente, il affectionne tout particulièrement les bonnes tables et les bons plans foodista. Bien que la street food occupe une place de premier choix dans son cœur ventre, il n'est pas allergique à une excursion gastronomique ou bistronomique.

Retrouvez Young Sun TAN sur :