Migrer le WordPress d'une ONG sans sacrifier le moindre contenu

Ce projet concerne le site institutionnel d'une ONG internationale de défense des droits humains, basée au Luxembourg. La plateforme héberge les campagnes de mobilisation, les pétitions, la collecte de dons en ligne ainsi que toute la bibliothèque d'articles.

Au moment où j'ai pris le dossier en main, l'installation reposait encore sur WordPress 5.9 et PHP 7.4, avec une structure multisite et une série d'extensions abandonnées par leurs auteurs. La dette technique grossissait à vue d'œil et chaque correctif de sécurité devenait une opération délicate.

Le point de départ

Un WordPress 5.9 figé, un PHP 7.4 hors support, un découpage multisite qui ralentissait tout le monde. À cela s'ajoutaient 1 300 articles, 5 800 fichiers médias, un dispositif de dons reposant sur WooCommerce et des formulaires de pétition. Il fallait tout remettre à niveau sans égarer le moindre contenu et sans jamais fermer la porte aux visiteurs.

Les exigences à tenir :

• Abandonner le multisite au profit d'un single-site (refonte de l'architecture)
• Combler l'écart WordPress 5.9 → 6.8 (plusieurs paliers majeurs à franchir)
• Faire évoluer PHP de la 7.4 à la 8.3 (la 7.4 n'étant plus suivie)
• Porter WooCommerce de la 6.4 à la 10.3 (la collecte de dons tournant en production)
• Préserver l'affichage des blocs Gutenberg d'une version à l'autre
• Transférer 1 300 articles et 5 800 médias sans la moindre perte

Ma façon de procéder

Diagnostic de départ

Je n'ai touché à rien avant d'avoir dressé une carte complète de l'existant : extensions activées comme dormantes, thème, types de contenu personnalisés, taxonomies, organisation multisite, réglages WooCommerce et état du parc de médias. J'ai repéré les plugins dépassés ou dépourvus de version compatible avec PHP 8.3, puis recensé pour chacun les solutions de remplacement.

Du multisite au single-site

Le format multisite alourdissait le projet sans rien lui apporter. J'ai donc rapatrié l'intégralité du contenu dans une seule installation single-site. Une fois le transfert effectué, j'ai contrôlé chaque article, chaque fichier et chaque lien entre contenus. Bilan : 1 300 articles et 5 800 médias déplacés, aucune perte.

En détail - Fusion multisite vers single-site

Sur WordPress, démanteler un multisite revient à reprendre une à une les tables wp_X_posts, wp_X_postmeta et wp_X_options de chaque sous-site pour les verser dans les tables de l'installation principale. Comme les identifiants de médias sont réattribués, il faut réaligner tous les attachment_id présents dans les contenus. J'ai automatisé cette bascule par script, puis je l'ai contrôlée avec des sommes de contrôle comparant le décompte d'articles et de médias avant et après.

Survie des blocs Gutenberg

Entre WP 5.9 et 6.8, la définition de plusieurs blocs Gutenberg a évolué. Des blocs hérités de l'ancien éditeur s'affichaient de travers, voire renvoyaient des erreurs de validation. Plutôt que de reprendre chaque article à la main, j'ai conçu une conversion automatisée reliant l'ancien format au nouveau, pour que tous les contenus en place continuent de s'afficher correctement.

En détail - Conversion des blocs Gutenberg

Gutenberg enregistre ses blocs sous forme de HTML commenté à l'intérieur de post_content. D'une version à l'autre, certains attributs ont été renommés ou restructurés. J'ai écrit un script de transformation qui analyse ce contenu sérialisé, détecte les blocs devenus obsolètes et les réécrit au format courant. Le traitement a été lancé en lot sur les 1 300 articles, accompagné d'un comparatif avant/après pour inspecter visuellement un échantillon.

Bascule PHP et WooCommerce

PHP 7.4 n'était plus maintenu depuis novembre 2022. Passer en 8.3 met potentiellement en cause l'ensemble du code : thème, extensions, fonctions retirées. J'ai éprouvé chaque plugin sur un environnement de pré-production avant de toucher au site en ligne. J'ai appliqué la même prudence à WooCommerce : sauter de la 6.4 à la 10.3 condense plusieurs années d'évolutions, et la collecte de dons ne pouvait souffrir aucune coupure.

En détail - PHP 7.4 vers 8.3

La branche PHP 8.x apporte son lot de ruptures : typage plus strict, match qui remplace switch, arrivée de Fiber, retrait de fonctions devenues obsolètes (utf8_encode, ou encore str_contains qui prend le relais de strpos). J'ai analysé tout le code spécifique avec PHPStan en niveau 6 et levé les incompatibilités avant le basculement. Les extensions sans build compatible PHP 8.3 ont été soit remplacées, soit forkées.

CI/CD et autonomie côté client

J'ai monté un pipeline CI/CD pour fiabiliser les mises en ligne et écarter les fausses manipulations. J'ai ensuite formé les contributeurs internes de l'ONG aux apports de WordPress 6.x (éditeur de site complet, nouveaux blocs, compositions réutilisables), afin qu'ils gèrent leur quotidien éditorial sans dépendre de moi.

En parallèle - un groupe d'assurance et de santé

J'ai déployé la même exigence sur le site d'un groupe d'assurance et de santé international implanté au Luxembourg, sur son offre de couverture santé à l'étranger. Le projet incluait un changement d'identité de marque assorti d'une migration de domaine vers son nouvel espace dédié. Au programme : refonte du thème autour d'un design system fidèle à la nouvelle charte, création de blocs Gutenberg sur mesure, gestion d'un site en quatre langues (FR/EN/DE/ES) via Polylang Pro et maintenance régulière organisée en sprints.

Ce que ça a donné

• Aucune donnée égarée parmi les 1 300 articles et 5 800 médias
• Site resté accessible d'un bout à l'autre de la migration
• WordPress, PHP et WooCommerce désormais sur des versions suivies et protégées
• Architecture allégée par l'abandon du multisite au profit du single-site
• Blocs Gutenberg fonctionnels, sans avoir à reprendre les contenus un par un
• Chaîne de déploiement CI/CD en service
• Contributeurs internes formés et pleinement autonomes

La leçon que j'en tire

Remettre à flot un WordPress laissé de côté ne tient pas dans un clic sur « Mettre à jour ». Dès que plusieurs versions majeures séparent le point de départ de l'objectif, qu'il faut revoir l'architecture et sauvegarder des milliers de contenus, l'opération réclame une feuille de route, des scripts de migration éprouvés et une bonne dose de patience. C'est cette méthode que je mets en œuvre sur chacun de mes projets.