Replatforming CMS : stratégies, étapes et bénéfices

Au fil du temps, chaque organisation a tendance à multiplier les plateformes CMS qu'elle utilise en raison de nouvelles exigences fonctionnelles, d'avancées technologiques, de demandes commerciales urgentes ou simplement parce que, pour un projet particulier, il a été décidé de travailler avec une nouvelle agence qui a apporté ses propres préférences technologiques.

Après 8 à 10 ans, la plupart des grandes organisations se retrouvent à supporter les coûts de maintenance de 8 à 12 plateformes technologiques différentes, réparties sur plusieurs dizaines, voire centaines, de serveurs. Chez Jahia, nous avons vu des cas où le nombre de plateformes CMS utilisées dépassait les 30 au sein d'une même entreprise. Cela finit par créer un besoin urgent de nettoyer cette configuration kafkaïenne, de la rationaliser et de consolider "tout" sur une seule plateforme. Ce type de projet est souvent appelé "replatforming" ou, parfois, "consolidation IT".

Pour les grandes entreprises et les institutions, la replatformisation peut apporter des avantages significatifs mais nécessite une préparation méticuleuse et une méthodologie sans faille car il ne s'agit pas de migrer un seul système, mais plusieurs systèmes très différents, vers cette nouvelle base technologique. Chaque système source possède ses propres caractéristiques, notamment des structures de données propriétaires.

Cet article passe en revue les trois principales stratégies d'un projet de replatformisation de CMS, les étapes clés de sa mise en œuvre et les avantages que l'on peut en attendre. Mais d'abord, qu'est-ce que la replatformisation ?

Qu'est-ce que le replatforming ?

En résumé, le replatforming, ou la replatformisation, est le processus de migration d'une application ou d'un système d'une plateforme existante vers une nouvelle plateforme, généralement basée sur le cloud, avec un minimum de changements au niveau du code source. Cette approche vise à améliorer les performances, l'évolutivité et la sécurité, tout en conservant les fonctionnalités de base de l'application.

Objectifs et spécifications de base de la replatformisation d'applications

La replatformisation se justifie pour une organisation si elle vise des objectifs tels que :

• Amélioration de l'évolutivité et des performances: En migrant vers une plateforme plus moderne, les applications peuvent mieux gérer les charges de travail accrues et les demandes des utilisateurs, ce qui se traduit par une amélioration des performances et la possibilité d'adapter les ressources en fonction des besoins.
• Amélioration de la sécurité et de la conformité: La replatformisation permet aux applications de bénéficier des fonctions de sécurité avancées des plateformes modernes, ce qui garantit une meilleure protection des données et la conformité aux réglementations en vigueur.
• Rentabilité: La transition vers une nouvelle plateforme peut réduire les dépenses opérationnelles en optimisant l'utilisation des ressources et en diminuant les coûts de maintenance associés à une infrastructure obsolète.

Replatformer VS Refactorer

Le refactoring implique une révision complète de l'application, en réécrivant ou en restructurant son code, par exemple pour tirer pleinement parti des fonctionnalités cloud-natives. Cette stratégie vise à améliorer l'agilité, l'évolutivité et la maintenabilité de l'application, mais nécessite un investissement plus important en temps et en ressources.

En revanche, le replatforming consiste à migrer l'application  avec des ajustements mineurs pour optimiser son fonctionnement, de plus en plus dans un environnement cloud. Il peut s'agir de modifications visant à tirer parti de bases de données gérées ou de services d'infrastructure cloud spécifiques.

Le replatforming se situe donc entre le rehosting, trop léger pour de nombreux projets, et le refactoring, qui nécessite des ressources considérables.

Les différentes stratégies de replatforming de sites web

Stratégie 0 Migration

L'organisation met en œuvre la nouvelle plateforme mais ne migre pas les sites existants vers celle-ci. La plateforme est conçue exclusivement pour l'avenir, avec une approche avant/après claire. Chaque fois qu'un nouveau site est nécessaire au sein de l'organisation ou qu'un site existant doit être redéveloppé ou modernisé, il est construit sur la nouvelle plateforme, en veillant à ce que l'ancienne version soit progressivement supprimée ou en évitant que le champ d'application des plateformes prises en charge ne s'étende avec de nouvelles initiatives incontrôlées. Il s'agit de la stratégie la plus conservatrice et la plus lente, qui s'étend sur une longue période mais offre la plus grande sécurité. Une fois la plateforme bien établie, les organisations peuvent envisager de "forcer" les migrations, en particulier pour les sites simples et de petite taille, afin de rationaliser le paysage des solutions et de réaliser des économies.

Stratégie de migration partielle

Il s'agit de la stratégie la plus courante, qui consiste à migrer (reconstruire) certains sites existants sur la nouvelle plate-forme tout en excluant immédiatement les autres qui ne seront jamais migrés pour des raisons de coût ou de priorité et qui devraient disparaître progressivement au fil du temps. Dans le cadre de cette stratégie, l'accent doit être mis sur le retrait de plateformes spécifiques en migrant tous les sites qui en dépendent, retirant ainsi ces plateformes CMS de la stack prise en charge.

Le choix des plateformes à retirer peut être basé sur :

• des coûts de maintenance élevés,
• la difficulté de trouver des ressources qualifiées,
• des problèmes de sécurité (certaines plateformes étant notoirement plus vulnérables que d'autres),
• ou l'annonce de la fin de vie d'un CMS ou de la sortie d'une nouvelle version majeure. Par exemple, de nombreux projets de replatforming ont vu le jour lors de la transition de Drupal 7 à la version 8, car une réécriture complète ou quasi-complète était nécessaire.

L'acquisition d'un CMS par un autre fournisseur est un autre élément déclencheur de la replatformisation, que ce soit en raison de l'arrêt anticipé du produit ou de changements radicaux dans les conditions de licence ou d'assistance. Pour ceux qui se souviennent de cette époque, les acquisitions de RedDot puis de Vignette par OpenText ont entraîné des turbulences pour les clients. Vous pouvez trouver des exemples plus récents d'entreprises trompées par les premières initiatives Headless qui reviennent à un environnement plus stable, plus complet et plus contrôlé comme Jahia.

Découvrez dans cette vidéo comment Arkema a procédé à son replatforming

Stratégie de migration complète

Il s'agit de la stratégie maximaliste, qui vise à migrer tous les sites que l'organisation souhaite conserver sur la nouvelle plate-forme afin de maximiser les avantages de l'opération en éliminant résolument et systématiquement les autres plates-formes CMS. La migration ne se fait évidemment pas en une seule fois, mais si la phase de modélisation, le développement des composants et la création de modèles de sites prêts à l'emploi sont bien exécutés, les migrations peuvent se dérouler à un rythme régulier. Ce processus permet également de moderniser certains sites à moindre coût en exploitant des fonctionnalités partagées et en maîtrisant mieux les productions graphiques, notamment en utilisant un système de conception pour le développement de nouveaux composants.

Phases clés d'un projet de replatforming agile

Phase d'évaluation

La dure réalité est que la plupart des organisations ne peuvent pas déterminer avec précision le nombre de sites web et de projets digitaux qu'elles gèrent, le nombre de plateformes technologiques impliquées, ni même les coûts associés.

Certaines initiatives sont entreprises par des départements individuels pour répondre à des besoins non critiques (c'est souvent là que l'on trouve de nombreux petits sites construits avec Joomla, WordPress, ou d'anciennes versions de Drupal, voire des plateformes plus exotiques). D'autres projets sont gérés par des filiales ou des bureaux nationaux sans gouvernance web centralisée ni coordination avec le service informatique de l'entreprise. La société mère elle-même a généralement une technologie préférée, mais elle héberge rarement tous les sites qu'elle chapeaute. Les sites sont souvent créés au fil du temps, parfois à l'insu de la société mère ou au mépris de ses directives.

La réalisation d'un inventaire de tous les points de présence numérique (PPN ) - y compris les sites web, les sites intranet, les portails, les applications web et les applications mobiles desservies par un CMS - est une première étape essentielle d'un effort de replatformisation efficace. Cet inventaire doit couvrir à la fois les projets gérés et hébergés en interne et ceux qui sont externalisés. Bien qu'il s'agisse de l'étape la plus fastidieuse, c'est de loin la plus simple. Même si le projet de replatforming est interrompu par la suite, la réalisation de cette première phase peut révéler d'importantes possibilités d'économies.

Objectifs de l'inventaire :

• Évaluer les coûts existants.
• Identifier les plateformes présentant des risques de sécurité, au minimum sur la base du CMS et de sa version.
• Repérer les plateformes négligées ou rarement mises à jour pour évaluer leur pertinence.
• Éliminer les sites ou les plates-formes clairement obsolètes (on les trouve presque toujours par dizaines dans les grandes organisations).

Données à collecter pour chaque projet

Les données nécessaires pour chaque projet sont relativement limitées mais doivent être aussi précises que possible pour être utiles par la suite, notamment pour évaluer les véritables coûts de fonctionnement, qui ont tendance à être largement sous-estimés par les départements fonctionnels.

Voici un modèle pour collecter des informations sur tous vos projets et démarrer votre phase d'inventaire.

Phase de sélection

Une fois l'inventaire terminé et une liste complète de sites et de projets web établie, l'étape suivante consiste à sélectionner les projets qui migreront vers la nouvelle plateforme et à les classer par ordre de priorité. En fonction de la stratégie choisie, cette sélection peut varier considérablement.

Tout d'abord, il convient d'éliminer tous les sites web obsolètes, c'est-à-dire ceux qui n'ont plus de trafic ni de mises à jour depuis des mois, voire des années. Il s'agit souvent de blogs obsolètes, de sites de lancements de produits passés depuis longtemps, de pages consacrées à des événements ponctuels ou à des initiatives éphémères telles que les parrainages. La liste peut être étonnamment longue, en particulier pour les sites internes lancés avec enthousiasme mais abandonnés au bout de six mois.

Une entreprise comme Arkema a lancé plus de 2700 sites web au cours des 15 dernières années.

Pour les sites restants, les priorités de migration doivent tenir compte des facteurs suivants :

1. Sécurité

Les plateformes connues pour leurs vulnérabilités récurrentes en matière de sécurité doivent être la priorité absolue de la migration, en particulier si elles sont hébergées en interne ou si elles ont des connexions entrantes avec l'infrastructure informatique de l'organisation. Cette étape permet également de s'assurer que les sites ne stockent pas d'informations sensibles inutiles et que les données sensibles sont protégées de manière appropriée.

2. Coûts d'exploitation

Si les coûts de licence peuvent être constants, les frais d'hébergement et de maintenance peuvent varier de manière significative, parfois d'un facteur 10, selon le CMS. Les plateformes dont la maintenance est coûteuse, malgré des coûts de licence peu élevés, sont des candidats de choix pour la migration. De même, la gestion des sites externes présente souvent des disparités de coûts inexplicables, même pour un même CMS. L'identification et le traitement de ces écarts peuvent conduire à des gains rapides en matière de réduction des coûts.

3. Type de site et fréquence

De nombreuses organisations possèdent de nombreux sites simples, de type "blog", présentant des caractéristiques similaires - techniquement simples et partageant des modèles de contenu et des flux de travail uniformes, ce qui les rend faciles à migrer. Les mini-sites ou les pages de renvoi, bien que graphiquement diversifiés, peuvent également entrer dans cette catégorie.

4. Simplicité technique de la migration

Les sites à fort contenu (par exemple, les bases de connaissances, les pages de support, la documentation produit) sont généralement composés de pages simples avec un contenu structuré que n'importe quel CMS Enterprise comme Jahia peut facilement gérer. En cas de doute, consultez le fournisseur de solutions choisi, dont les experts peuvent évaluer la complexité de la migration et fournir des conseils sur mesure.

Chaque organisation doit peser ces facteurs en fonction de ses propres priorités et des risques identifiés.

Objectifs de la phase de sélection :

• Identifier les sites qui doivent migrer vers la nouvelle pile technologique.
• Estimer l'ampleur des efforts de migration à venir.
• Sélectionner des projets pilotes pour tester la nouvelle plate-forme.
• Déterminer l'ordre de migration des projets sélectionnés.

Phase de modélisation et de partage des composants

Une fois les candidats à la migration finalisés, l'étape la plus critique commence : la modélisation et la consolidation des composants logiciels nécessaires à la recréation et à la migration des sites. Cette phase vise à :

• Cartographier le contenu et ses types pour préparer les scripts d'importation et nettoyer les données si nécessaire. La réduction du nombre de types de contenu, même s'ils deviennent plus complets, simplifie le développement futur et la maintenance du code.
• Identifier les points communs entre les plateformes afin de ne développer qu'une seule fois les composants partagés. Recréer des fonctionnalités similaires (par exemple, gestion de blog, modules d'actualités, galeries d'images, formulaires de contact) pour chaque projet est un gaspillage. De même, les fonctionnalités avancées telles que les intégrations CRM ou DAM devraient être standardisées.
• Centraliser la gestion du contenu, y compris le texte, les images, les vidéos et les fichiers. La gestion de plusieurs technologies et instances empêche un partage efficace du contenu. Les plateformes CMS Enterprise telles que Jahia permettent un partage transparent du contenu entre les sites et prennent en charge des référentiels communs pour la création et la mise à jour du contenu, garantissant ainsi une cohérence entre tous les points d'utilisation. Grâce à des mécanismes de rendu avancés, le même contenu peut apparaître différemment selon le site ou le contexte.

Phase de mise en œuvre

La phase de mise en œuvre opérationnelle englobe un large éventail de défis, de risques et de méthodes. Les principales leçons et erreurs à éviter sont les suivantes :

• Éviter d'utiliser le site principal ou le plus critique de l'organisation comme premier candidat à la migration. Les sites complexes de l'entreprise, combinés aux complexités de la replatformisation, augmentent les risques et les retards. Commencez par des projets plus modestes pour acquérir de l'expérience et maîtriser la plateforme.
• Éviter l'automatisation excessive du transfert de contenu. Il existe rarement un "script magique" parfait pour migrer du contenu d'une plateforme CMS à l'autre. Il convient plutôt d'équilibrer les processus automatisés et les interventions manuelles afin de garantir le succès sans encourir de coûts ou de retards excessifs.
• Envisager l'hébergement cloud pour réduire les besoins en ressources internes pour la maintenance et les mises à jour. Des plateformes comme Jahia offrent des services gérés en nuage avec une fiabilité et une sécurité accrues.
• Donner la priorité à une formation complète pour les créateurs de contenu et les gestionnaires de sites qui doivent s'adapter à l'interface et aux flux de travail de la nouvelle plateforme. Un plan d'adoption bien préparé est essentiel, même s'il ralentit le déploiement.
• Utiliser un format pivot pour les exportations et les importations de données. Plutôt que de procéder à des migrations directes entre plusieurs systèmes, l'exportation vers un format commun (par exemple CSV) simplifie et rationalise la transformation des données tout en permettant leur nettoyage et leur enrichissement.

Avantages du replatforming et de l'unification technologique

Coûts de développement contrôlés

Avec une stack technologique unifiée, il est plus facile de trouver ou de former des ressources externes, d'optimiser les efforts de développement et d'éviter les fonctionnalités redondantes. Des frameworks comme React, supportés par Jahia, garantissent la flexibilité et l'accès à un vaste vivier de talents.

Des temps de réponse plus rapides pour les entreprises

Les composants et les modèles de sites préconstruits permettent d'assembler rapidement de nouveaux sites en quelques jours ou semaines au lieu de plusieurs mois. Par exemple, les capacités d'archivage et de modélisation de Jahia permettent le déploiement rapide de sites préconfigurés et prêts à l'emploi.

Sur ce point, nous vous proposons une comparaison objective (nous n'en sommes par à l'origine) entre les principaux CMS du marché (Wordpress, Drupal, Adobe Experience Manager, Contentful...). Vous trouverez sur ce comparatif de CMS des données issues de l'analyse des Core Web Vitals de sites web basés sur les différentes solutions. Bonne lecture !

Bibliothèque de composants centralisée

Un référentiel centralisé de modèles, de structures de contenu, de composants réutilisables et de fonctionnalités avancées réduit la redondance, garantit une qualité constante et simplifie la maintenance.

Coûts réduits

Un CMS comme Jahia peut gérer des dizaines ou des centaines de sites sans coûts d'hébergement et de maintenance supplémentaires, contrairement à des plateformes disparates avec des dépenses uniques.

Sécurité renforcée

La gestion d'une plateforme unique est nettement plus facile et plus sûre que la maintenance de plusieurs systèmes, ce qui réduit les vulnérabilités et les coûts associés.

Amélioration de la conformité légale

Une plateforme unifiée simplifie la conformité aux exigences légales et réduit les risques associés à des plateformes mal entretenues ou non gérées.

Meilleure gouvernance

La centralisation de plusieurs sites sur une seule plateforme améliore la gestion du cycle de vie, l'administration, l'audit et le reporting tout en réduisant les besoins en ressources.

Conclusion

La replatformisation est, en effet, un investissement substantiel, les licences logicielles ne représentant qu'une part mineure du coût total. Cependant, s'il est bien exécuté, elle permet de réaliser des économies importantes grâce à une sélection efficace des sites et à la normalisation des composants. Une collaboration étroite avec le fournisseur de la plateforme est essentielle pour garantir un processus de migration rationalisé et une utilisation efficace du nouveau système. Surtout, un tel projet est parfois le seul moyen de faire face au risque le plus critique de l'époque actuelle en matière de technologies de l'information : la cybersécurité.