Que faut-il auditer dans WordPress avant une migration vers Next.js ?

Méthode et preuves

L’audit commence en lecture seule. Conservez la date, l’environnement, la version WordPress et le périmètre de chaque collecte. Évitez d’installer une extension d’audit sur la production avant d’avoir évalué son impact. Les sources peuvent combiner export, base de données, API REST, WP-CLI, fichiers, crawl HTTP, analytics, Search Console, journaux et entretiens.

Chaque ligne d’un registre doit contenir cinq éléments :

1. Observation : ce qui existe réellement, avec son identifiant ou son URL.
2. Preuve : réponse HTTP, export, capture de configuration, requête ou démonstration utilisateur.
3. Usage : personne, fréquence, dépendance et conséquence d’une panne.
4. Décision : conserver, transformer, fusionner, remplacer, archiver ou exclure.
5. Propriétaire : personne qui valide la reprise et accepte l’écart.

Ce cadre évite de recopier une fonction parce qu’elle est visible dans l’administration alors que personne ne l’utilise. Il évite aussi l’erreur inverse : supprimer un flux discret qui alimente un partenaire ou une opération critique.

1. Auditer les URL et les contenus

Construisez une table qui rapproche les URL découvertes par plusieurs voies : plans de site, crawl interne, analytics, Search Console, journaux serveur, liens externes connus et anciennes règles de redirection. Pour chaque URL, relevez le statut HTTP, la canonicale, le type de contenu, le titre, la date, la langue, la profondeur, les liens entrants internes et les signaux d’usage disponibles.

Ajoutez les contenus non publics : brouillons, contenus programmés, privés, révisions utiles, archives et pièces jointes. Une migration exécutée uniquement à partir des pages indexées peut perdre le travail éditorial en attente.

L’écran d’export WordPress permet de produire un fichier WXR contenant notamment articles, pages, types personnalisés, commentaires, champs personnalisés, catégories, étiquettes, taxonomies et utilisateurs. La documentation officielle de l’export décrit ce périmètre. Ce fichier est une source de contrôle ; il ne contient pas à lui seul les réglages du thème, toutes les options d’extensions, les fichiers ni les systèmes externes.

La décision par URL alimentera ensuite le runbook pour préserver le SEO pendant la migration. Ne décidez pas les redirections au dernier moment.

2. Auditer le modèle éditorial

Relevez les types de contenus, taxonomies, champs, relations, modèles Gutenberg, blocs réutilisables, shortcodes, menus, zones de widgets et options globales. Pour chaque champ, demandez s’il est obligatoire, qui le remplit, où il apparaît et quelles valeurs historiques sont réellement présentes.

Les écarts entre schéma déclaré et données réelles sont importants. Un champ marqué facultatif peut être indispensable sur un modèle public. Une relation peut être stockée sous forme d’identifiant, d’URL ou de texte libre selon l’époque. Les shortcodes peuvent cacher une requête, un formulaire ou un composant dont le contenu n’apparaît pas dans l’export nettoyé.

L’API REST WordPress expose les ressources standard et se décrit via son index ou des requêtes OPTIONS. Comparez ce que l’API rend accessible, ce que la base contient et ce que le site public affiche. Les types ou champs personnalisés ne sont pas nécessairement tous exposés sans configuration supplémentaire.

Livrable : un dictionnaire de contenu avec type, champ, format, cardinalité, exemple anonymisé, règle de validation, source et destination cible. Ce dictionnaire devient le contrat entre extraction, CMS cible et composants Next.js.

3. Auditer les médias

Inventoriez les pièces jointes WordPress et les fichiers réellement appelés par le HTML ou le CSS. Notez URL, chemin, type MIME, taille, dimensions, texte alternatif, légende, auteur, droits connus et contenus qui les utilisent. Détectez les références vers des fichiers absents, les doublons, les variantes générées et les médias servis depuis un CDN ou un stockage externe.

Ne copiez pas aveuglément toutes les miniatures produites par WordPress. La cible peut générer d’autres formats, mais elle doit conserver l’original nécessaire, les recadrages éditorialement significatifs et les informations d’accessibilité. Vérifiez aussi documents PDF, audio, vidéo, polices, images sociales et favicons : ils échappent souvent au périmètre « bibliothèque de médias ».

Livrable : un manifeste de fichiers avec empreinte, source, cible, décision de conservation et contrôle d’accessibilité. Un total de fichiers identique ne prouve pas que les bonnes images apparaissent aux bons endroits.

4. Auditer le rendu, le SEO et la mesure

Prélevez le HTML public de chaque modèle : page, article, archive, recherche, auteur, catégorie, pagination et erreur. Relevez titres, descriptions, canonicales, robots, langues, données structurées, Open Graph, fil d’Ariane, sommaire, dates, auteurs et liens.

Comparez la source HTML à ce qui apparaît après exécution JavaScript lorsqu’un script modifie le contenu. Repérez les éléments injectés par une extension SEO, un constructeur de pages, un gestionnaire de consentement ou un outil de test. La cible devra produire une sortie équivalente lorsque cette sortie est utile, pas réinstaller mécaniquement chaque outil.

Documentez analytics, gestionnaire de balises, pixels, consentement, événements, objectifs et exclusions internes. Conservez une période de référence et les définitions des conversions. Une nouvelle interface accompagnée d’un nouveau plan de mesure rend toute comparaison impossible si les deux changements ne sont pas raccordés.

5. Auditer les extensions, le thème et le code

Listez extensions actives, inactives, obligatoires, personnalisées et intégrées au thème. Pour chacune : version, éditeur, statut de maintenance, fonction observable, tables ou options créées, tâches planifiées, endpoints, shortcodes, blocs, permissions et dépendances.

WP-CLI fournit une commande officielle wp plugin list capable de retourner un format structuré. Complétez cette liste par les extensions « must-use », les fichiers déposés hors du mécanisme standard et le code du thème enfant. Une extension inactive peut avoir laissé des tables, des médias ou des shortcodes encore présents dans les contenus.

Classez chaque capacité : fournie nativement par la cible, reconstruite, remplacée par un service, maintenue dans WordPress ou retirée. L’existence d’une fonction ne suffit pas à justifier sa reconstruction. Il faut un usage et une valeur, mais aussi une décision formelle pour l’abandonner.

6. Auditer les parcours fonctionnels

Exécutez les parcours avec les rôles réels : publier, prévisualiser, planifier, corriger, restaurer, rechercher, filtrer, remplir un formulaire, recevoir une confirmation, s’inscrire, se connecter, réinitialiser un mot de passe ou télécharger un document. Notez les étapes, états, notifications, erreurs et opérations de reprise.

Les formulaires méritent une fiche propre : champs et validations, destination, preuve de consentement, anti-spam, stockage, notification, pièce jointe, délai de conservation et comportement en échec. Un email reçu n’est pas la preuve que la donnée est correctement enregistrée ; une donnée enregistrée n’est pas la preuve que le destinataire a été notifié.

Pour les workflows importants, appliquez la méthode de documentation d’un workflow avant automatisation. Elle distingue déclencheur, états, décisions, exceptions et preuves.

7. Auditer les données et les intégrations

Cartographiez bases, tables personnalisées, options, fichiers, API, webhooks, flux, imports, exports et tâches planifiées. Pour chaque échange, indiquez source de vérité, authentification sans recopier le secret, format, fréquence, quotas, idempotence, délai, journalisation et méthode de reprise.

Testez les hypothèses avec des comptages et des échantillons : nombre d’objets par type et statut, valeurs nulles, identifiants orphelins, encodage, dates et relations. Une migration de schéma doit prévoir la transformation, la validation et le rapprochement. « Import terminé » ne signifie pas « données utilisables ».

Repérez enfin les écritures qui peuvent continuer pendant le chantier : nouveaux articles, formulaires, commandes, commentaires, comptes ou réglages. Elles déterminent le mécanisme de synchronisation finale et la durée acceptable d’un éventuel gel.

8. Auditer l’exploitation et la sécurité

Relevez versions de WordPress, PHP, base et serveur ; architecture d’hébergement ; DNS ; TLS ; cache ; CDN ; sauvegardes ; restaurations testées ; surveillance ; journaux ; alertes ; tâches cron ; environnements ; déploiements et accès administratifs.

L’écran Site Health vérifie plusieurs points de configuration et fournit des informations utiles sur l’installation. Utilisez-le comme une entrée, pas comme un certificat de migration. Il ne démontre ni la restauration, ni les procédures humaines, ni la capacité du système cible.

Établissez qui possède chaque compte, comment les accès sont révoqués et où sont stockés les secrets. Ne copiez aucun secret dans le rapport. Notez seulement son usage, son propriétaire, son emplacement géré et la nécessité de le renouveler au moment de la bascule.

Chiffrez aussi l’exploitation future. Une comparaison honnête reprend sauvegarde, surveillance, sécurité, support et obsolescence des deux architectures. Le guide sur le budget de maintenance fournit une structure d’enveloppes.

9. Auditer l’organisation et la conformité

Identifiez les personnes qui publient, valident, administrent, maintiennent et répondent aux demandes. Documentez les périodes critiques, niveaux de service attendus, dépendances à une personne et processus de support. Faites réaliser les tâches importantes par les utilisateurs : leur démonstration révèle souvent des contournements absents de la documentation.

Recensez les catégories de données personnelles, finalités, bases documentées, consentements, durées, destinataires, demandes d’exercice de droits et contrats de sous-traitance pertinents. La migration ne doit ni étendre silencieusement la collecte ni perdre la preuve existante. Les mentions, préférences et mécanismes de retrait doivent suivre le parcours réel.

Le propriétaire métier décide ce qui doit continuer ; l’équipe technique décrit ce qui est possible et prouve la reprise. Aucun des deux ne peut valider seul une suppression fonctionnelle sensible.

Le paquet de sortie qui autorise le cadrage

L’audit se conclut par six livrables reliés :

1. registre des URL et décisions de destination ;
2. dictionnaire des contenus et règles de transformation ;
3. manifeste des médias ;
4. matrice des fonctions, extensions et parcours ;
5. cartographie des données, intégrations et responsabilités ;
6. registre des risques, inconnues, exclusions et preuves attendues.

Ajoutez un lot pilote représentatif, un plan de validation et une estimation séparant construction, migration et exploitation. Le cadrage peut commencer si les inconnues restantes ont un moyen raisonnable d’être levées. Sinon, ouvrez une investigation ciblée au lieu de transformer une hypothèse en exigence.

Un inventaire anonymisé et ses zones d’incertitude peuvent être présentés à Forge Labs pour qualifier l’étape suivante. Il n’est pas nécessaire de transmettre contenus privés, accès ou secrets pour discuter de la structure du diagnostic.

L’audit est terminé quand chaque incertitude importante a un propriétaire, une méthode de vérification et une conséquence connue. C’est à cette condition que Next.js devient une cible conçue pour le système réel, plutôt qu’une nouvelle interface posée sur des dépendances oubliées.

Sources officielles

• WordPress.org — Tools Export screen, objets inclus dans l’export WXR.
• WordPress Developer Resources — REST API Reference, ressources et découverte de l’API.
• WordPress Developer Resources — Media endpoint, métadonnées des pièces jointes.
• WordPress Developer Resources — wp plugin list, inventaire structuré des extensions.
• WordPress.org — Site Health screen, contrôles et informations de configuration.