Moderniser WordPress pour une ONG sans perdre une donnée

amnesty.lu est le site institutionnel d'Amnesty International au Luxembourg. Il porte les campagnes de l'organisation, les pétitions, les dons en ligne et l'ensemble des publications.

Quand AdevWeb a repris le projet, le site tournait sur WordPress 5.9 avec PHP 7.4, une architecture multisite et des plugins qui n'étaient plus maintenus. La dette technique s'accumulait et les mises à jour de sécurité devenaient risquées.

Le contexte

WordPress 5.9, PHP 7.4 en fin de vie, une architecture multisite devenue un frein. 1 300 publications, 5 800 médias, un système de dons via WooCommerce, des formulaires de pétitions. Tout devait être modernisé sans perdre un seul contenu et sans couper l'accès au site.

Les contraintes :

• Passage de multisite vers single-site (changement d'architecture)
• Migration WordPress 5.9 → 6.8 (plusieurs versions majeures d'écart)
• Montée PHP 7.4 → 8.3 (fin de support PHP 7.4 dépassée)
• Mise à jour WooCommerce 6.4 → 10.3 (système de dons en production)
• Compatibilité des blocs Gutenberg entre les anciennes et nouvelles versions
• 1 300 publications et 5 800 médias à migrer sans perte

Comment on a travaillé

Audit initial

Avant toute intervention, on a cartographié le site : plugins actifs et inactifs, thème, custom post types, taxonomies, structure multisite, configuration WooCommerce, état des médias. On a identifié les plugins obsolètes ou sans version compatible PHP 8.3, et listé les alternatives.

Passage multisite vers single-site

L'architecture multisite ajoutait de la complexité sans apporter de valeur. On a consolidé tout le contenu dans une installation single-site. Chaque publication, chaque média, chaque relation entre contenus a été vérifiée après migration. Résultat : 1 300 publications et 5 800 médias transférés, zéro perte.

Côté technique - Multisite vers single-site

Le passage multisite → single-site sur WordPress impose de retravailler les tables wp_X_posts, wp_X_postmeta, wp_X_options de chaque sous-site pour les fusionner dans les tables principales. Les IDs de médias changent, les attachment_id dans les contenus doivent être remappés. On a scripté l'ensemble et validé avec des checksums sur le nombre de publications et médias avant/après.

Compatibilité des blocs Gutenberg

En passant de WP 5.9 à 6.8, le format de certains blocs Gutenberg a changé. Des blocs créés sous l'ancien éditeur ne s'affichaient plus correctement ou déclenchaient des erreurs de validation. On a développé un système de mapping automatique entre les anciens et les nouveaux formats de blocs pour que les contenus existants restent fonctionnels sans intervention manuelle sur chaque publication.

Côté technique - Mapping des blocs Gutenberg

Les blocs Gutenberg sont stockés en HTML commenté dans post_content. Entre WP 5.9 et 6.8, certains attributs ont changé de nom ou de structure. On a écrit un script de transformation qui parse le contenu sérialisé, identifie les blocs dépréciés, et les convertit au nouveau format. Le tout exécuté en batch sur les 1 300 publications, avec un diff avant/après pour vérifier visuellement un échantillon.

Montée PHP et WooCommerce

PHP 7.4 était en fin de vie depuis novembre 2022. Le passage à 8.3 touche potentiellement tout le code : thème, plugins, fonctions dépréciées. On a testé chaque plugin en environnement de staging avant de basculer la production. Même approche pour WooCommerce : la montée de 6.4 à 10.3 représente plusieurs années de changements, et le système de dons devait continuer à fonctionner sans interruption.

Côté technique - PHP 7.4 → 8.3

PHP 8.x introduit des breaking changes : typage strict, match au lieu de switch, Fiber, suppression de fonctions dépréciées (utf8_encode, str_contains en remplacement de strpos). On a passé tout le code custom avec PHPStan niveau 6 et corrigé les incompatibilités avant la bascule. Les plugins sans version PHP 8.3 compatible ont été remplacés ou forkés.

CI/CD et autonomie des équipes

On a mis en place un pipeline CI/CD pour automatiser les déploiements et réduire le risque d'erreur humaine. Les équipes internes d'Amnesty ont été formées aux nouvelles fonctionnalités de WordPress 6.x (éditeur de site, nouveaux blocs, patterns) pour qu'elles soient autonomes dans la gestion quotidienne.

En parallèle - Global Health by Foyer Group

On applique la même rigueur sur le site de Global Health by Foyer Group, l'assureur santé international du groupe Foyer au Luxembourg. Le site a fait l'objet d'un rebranding complet - passage de foyerglobalhealth.com vers globalhealth.insurance. Refonte du thème avec un design system aligné sur la nouvelle charte, développement de blocs Gutenberg sur mesure, gestion multilingue en 4 langues (FR/EN/DE/ES) via Polylang Pro, maintenance continue en sprints.

Les résultats

• Zéro perte de données sur 1 300 publications et 5 800 médias
• Zéro interruption de service pendant toute la migration
• WordPress, PHP et WooCommerce sur versions supportées et sécurisées
• Architecture simplifiée (multisite → single-site)
• Blocs Gutenberg compatibles sans reprise manuelle des contenus
• Pipeline CI/CD opérationnel
• Équipes internes formées et autonomes

Ce qu'on en retient

Moderniser un WordPress qui a pris du retard, ça ne se résume pas à cliquer sur "Mettre à jour". Quand il y a plusieurs versions majeures d'écart, un changement d'architecture et des milliers de contenus à préserver, ça demande un plan, des scripts de migration testés, et de la patience. On applique la même approche sur tous nos projets.