Migration de CMS : ce que les outils automatiques ne reprennent pas (et comment le vérifier)

Depuis que l'IA s'est invitée dans les projets web, les offres de migration de CMS rapide, automatique, parfois gratuite, se multiplient. La promesse est simple : on pointe l'outil vers votre site, et quelques jours plus tard, tout est dans le nouveau CMS.

Avant de comparer les délais et les prix, une question compte davantage : qu'est-ce qui arrive exactement de l'autre côté ? Un site d'entreprise est fait de plusieurs couches, et elles ne se migrent pas toutes de la même façon. Certaines se reprennent très bien de manière automatisée. D'autres demandent de comprendre comment le site a été construit, ce qu'aucun outil ne voit en lisant les pages publiées.

Les 4 points clés de l'article :

• Un site d'entreprise se compose de 5 couches : contenu, modèle de contenu, composants, templates, code et intégrations.
• Les outils de migration automatique reprennent bien le contenu, beaucoup moins le reste.
• Les templates et le code concentrent l'essentiel des écarts de budget et de calendrier.
• Une checklist permet de vérifier, couche par couche, ce que votre migration reprend vraiment.

Les 5 couches d'un site : ce qui passe d'un CMS à l'autre, et ce qui bloque

Pour savoir ce qu'une migration reprend vraiment, il faut d'abord savoir de quoi un site est fait. On peut le décrire en cinq couches, de la plus visible à la moins visible : les contenus que lit l'internaute, le modèle qui les structure, les composants qui servent à construire les pages, les templates qui les organisent, et enfin le code et les intégrations qui relient le site au reste de l'entreprise. L'ordre compte : plus une couche se voit dans les pages publiées, mieux elle se prête à une migration automatisée. À l'inverse, plus elle est cachée, plus il faut comprendre comment le site a été construit pour la reprendre.

1. Le contenu

Le contenu regroupe tout ce que l'internaute lit et regarde : les textes et les images, les documents et les vidéos, mais aussi les métadonnées SEO, les liens internes et la navigation. C'est la couche la plus visible et la plus facile à extraire, que ce soit par export depuis l'ancien CMS ou en lisant les pages publiées. C'est aussi celle que l'IA reprend le mieux : elle sait reconnaître un titre, un chapô, une image et sa légende, même dans un HTML peu structuré.

2. Le modèle de contenu

Sous le contenu se trouve le modèle qui l'organise : les types de contenu (actualité, fiche produit, offre d'emploi, page agence), leurs champs, leurs relations et les taxonomies qui les classent. Le modèle ne se voit pas dans une page : il se déduit. Un outil qui ne lit que le résultat affiché doit deviner la structure qui l'a produit. Le risque est un modèle appauvri, où chaque type de contenu se réduit à un titre, une image, une date et un grand champ de texte riche. Le contenu est bien là, mais il a perdu sa structure, et avec elle ce qui permettait de le réutiliser, de le traduire champ par champ, de le personnaliser ou de le diffuser en headless.

3. Les composants

Les composants sont les blocs réutilisables que les contributeurs assemblent pour construire leurs pages : bannière, carrousel, encart d'appel à l'action, formulaire, tableau comparatif. Bien migrés, ils arrivent sous forme de bibliothèque que les équipes réutilisent. Mal migrés, ils deviennent du HTML figé, que plus personne ne peut modifier sans un développeur.

4. Les templates

Les templates fixent la façon dont ces composants s'organisent sur la page. Ce sont les gabarits et les règles de mise en page, qui définissent quels composants sont autorisés à quel endroit, comment une page hérite de sa rubrique et quelles variantes existent selon le site ou la langue. Les templates encodent des décisions éditoriales et de design prises au fil des années. Ils se reconnaissent mal depuis l'extérieur, parce que deux pages qui se ressemblent peuvent venir de deux gabarits différents, et l'inverse.

5. Le code et les intégrations

Enfin, le code et les intégrations regroupent tout ce qui fait fonctionner le site au-delà de l'affichage. On y trouve les développements spécifiques, la logique métier, les droits d'accès, les workflows de validation et les connexions au CRM, à l'ERP, au SSO, au moteur de recherche ou à la plateforme e-commerce. C'est la couche la plus coûteuse d'un projet de migration, et celle qui ne se voit pas du tout dans les pages publiées.

Ce que les outils de migration automatique font bien

La plupart des outils de migration automatique partent de ce qui est accessible : les pages publiées ou un export de l'ancien CMS. Sur la première couche, le résultat peut être très bon. Les contenus sont extraits, nettoyés et réinjectés dans le nouveau CMS, avec leurs métadonnées.

Ce qu'ils laissent de côté

Plus on descend dans les couches, plus l'outil doit deviner. Le modèle de contenu cible est déduit des pages, et il est souvent plus simple que celui d'origine. Les templates sont regroupés par ressemblance visuelle, avec des erreurs. Le code et les intégrations, eux, ne sont en général pas migrés du tout : l'outil reprend le contenu et laisse la logique de côté.

C'est une limite de l'approche, et elle ne pose pas de problème tant que l'offre l'annonce. Le problème vient quand elle ne le dit pas. Une migration présentée comme « complète » qui ne reprend que le contenu repousse le travail le plus difficile après la signature, au moment où le budget et le calendrier sont déjà fixés.

Quelques signaux doivent alerter :

• l'offre parle de « pages migrées » sans jamais mentionner le modèle de contenu, les templates ou les intégrations ;
• personne ne demande à voir votre code, vos workflows ou la liste de vos connecteurs avant de chiffrer ;
• le modèle de contenu cible vous est livré après la reprise, au lieu d'être validé avant ;
• le délai annoncé est le même pour un site vitrine et pour un portail avec espace client.

Pourquoi les templates et le code sont la partie la plus difficile

Le contenu est une donnée : on peut l'extraire, le transformer et le recharger. Le code et les templates sont des décisions. Ils traduisent la façon dont votre organisation publie, valide, traduit et personnalise ses contenus, et la façon dont le site parle au reste de votre système d'information.

Ces décisions ne se recopient pas d'un CMS à l'autre, parce que les deux plateformes ne fonctionnent pas de la même façon. Une règle de gestion codée en dur dans l'ancien CMS peut devenir une simple configuration dans le nouveau, ou demander un développement. Un connecteur CRM peut exister nativement ou être à écrire. C'est là que se concentrent les écarts de budget et de calendrier dans un projet de migration, et c'est là qu'il faut une expertise humaine sur les deux plateformes.

Une bonne migration ne cherche donc pas à tout automatiser. Elle automatise ce qui peut l'être (le contenu, une grande partie des composants), et elle identifie et chiffre dès le départ ce qui demande des experts.

Les questions à poser avant de signer

Quel que soit le prestataire ou l'outil, ces questions permettent de savoir ce que couvre réellement une offre de migration :

• Que reprenez-vous, couche par couche : contenu, modèle de contenu, composants, templates, code, intégrations ?
• Le modèle de contenu cible est-il conçu avec nous et validé avant la reprise, ou déduit automatiquement ?
• Les composants arrivent-ils sous forme de bibliothèque réutilisable par nos contributeurs ?
• Qui reprend les développements spécifiques, la logique métier et les intégrations, et sont-ils chiffrés avant le démarrage ?
• Notre site actuel reste-t-il en production pendant toute la migration ?
• Pouvons-nous comparer l'ancien site et le nouveau, côte à côte, avant la mise en ligne ?
• Comment sont gérés les redirections, les métadonnées et le suivi SEO après la bascule ?

Checklist de migration de CMS : vérifier chaque couche

Cette checklist se lit en deux temps : ce qu'il faut inventorier avant la migration, et ce qu'il faut contrôler une fois les contenus repris dans le nouveau CMS.

La ligne SEO, en particulier, se prépare bien avant la bascule. C'est elle qui décide si une migration de site web se fait sans perte de trafic. Lors d'une refonte, le trafic organique dépend de la façon dont les signaux accumulés par l'ancien site sont transmis au nouveau : les URL indexées, les pages qui génèrent des visites et des conversions, les backlinks qui pointent vers elles, les balises title et meta description, le maillage interne. Une URL qui change sans redirection 301 renvoie une erreur 404, et Google finit par retirer la page de son index, avec le trafic qu'elle apportait. Une page dont le contenu est appauvri ou qui perd ses liens internes peut aussi reculer dans les résultats, même si elle reste accessible.

Le travail SEO se fait donc en trois temps. Avant la migration, on relève l'état de référence : URL indexées, pages qui apportent du trafic, positions sur les requêtes principales. Au moment de la bascule, chaque ancienne URL est redirigée vers son équivalent le plus proche, et le plan de redirections est testé avant la mise en ligne, pas après. Dans les semaines qui suivent, on surveille dans la Search Console les erreurs d'exploration, l'indexation et le trafic des pages principales, pour corriger rapidement ce qui a échappé au plan. Un outil qui reprend les contenus sans traiter ces points peut livrer un site complet et lui faire perdre une partie de son trafic.

Et si l'inventaire fait apparaître beaucoup de code et d'intégrations, le projet relève moins d'une simple reprise de contenus que d'un replatforming CMS, à organiser phase par phase.

Comment Jahia aborde la migration

La migration CMS gratuite par IA de Jahia reconstruit vos contenus, composants et métadonnées dans Jahia. Les contenus sont repris dans des modèles de contenu soumis à votre validation, et les composants sont regroupés en bibliothèque réutilisable.

Avant le démarrage, un diagnostic inventorie votre site : contenus, composants, métadonnées, intégrations et développements propres. Il sépare ce que l'IA reconstruit de ce que les experts Jahia traitent avec vous, c'est-à-dire les développements spécifiques, la logique métier et les intégrations, et chiffre ces éléments avant le début du projet. Votre site source reste en production pendant toute la migration, et vos équipes valident à chaque étape.

Pour le détail de l'offre, voir notre article sur la migration gratuite de CMS par IA, ou l'exemple d'une migration d'Adobe AEM vers Jahia.