Aller au contenu

Spécialité n°1

Migration WordPress vers
une architecture statique sécurisée

Nous reconstruisons votre site WordPress en pages pré-générées : mêmes contenus, même référencement, même autonomie éditoriale — mais plus aucune base de données ni back-office exposés sur Internet.

Le principe

On garde tout ce qui vous sert. On supprime tout ce qui vous expose.

Une migration réussie ne se voit pas depuis l’extérieur. Elle se mesure à ce qui a disparu du serveur.

Conservé

  • Vos URLs et votre arborescence
  • Vos contenus, images et médias
  • Votre identité graphique (ou une refonte, au choix)
  • Vos formulaires de contact
  • Votre suivi d’audience (Matomo ou GA4)
  • Votre capacité à publier en autonomie

Supprimé

  • La base de données exposée
  • Le back-office public /wp-admin
  • Les 20 à 40 extensions à surveiller
  • Les mises à jour de sécurité mensuelles
  • Le pare-feu applicatif et son abonnement
  • La peur du prochain piratage

Ce que vous y gagnez

Six bénéfices mesurables dès la mise en ligne

Surface d’attaque quasi nulle

Ni PHP, ni MySQL, ni extension exécutée en production. Il ne reste que des fichiers.

Chargement sous la seconde

HTML pré-généré, servi depuis le point de présence CDN le plus proche du visiteur.

SEO préservé, puis renforcé

URLs conservées, redirections 301 exhaustives, Core Web Vitals au vert.

Fin des mises à jour d’urgence

Les dépendances évoluent au build, testées. Le site en ligne, lui, ne bouge pas.

Hébergement quasi gratuit

Un site statique tient sur une offre CDN à quelques euros par mois, sans serveur à administrer.

Restauration en secondes

Chaque version est versionnée en Git : revenir à l’état d’hier est une commande.

Déroulé

La migration, étape par étape

Deux à trois semaines pour un site vitrine. Votre site actuel reste en ligne jusqu’à votre validation.

  1. 01

    Audit et cartographie

    Inventaire complet des URLs, des gabarits, des extensions actives, des formulaires et des intégrations tierces. Nous mesurons la surface d’attaque réelle et identifions ce qui doit rester dynamique.

  2. 02

    Extraction et normalisation du contenu

    Récupération du contenu depuis la base ou l’API REST, conversion en fichiers structurés versionnés, nettoyage du balisage hérité et normalisation des médias.

  3. 03

    Reconstruction en architecture statique

    Reconstruction des gabarits en Astro, images optimisées en AVIF/WebP, données structurées schema.org générées au build, budget de performance imposé.

  4. 04

    Continuité SEO

    Table de redirections 301 exhaustive, préservation des URLs canoniques, sitemap segmenté, comparaison avant/après sur les balises et le maillage interne.

  5. 05

    Reprise des fonctions dynamiques

    Formulaires, recherche, espace client, panier : chaque fonction est réimplantée sur un service isolé, avec quotas, journalisation et validation stricte des entrées.

  6. 06

    Durcissement et mise en ligne

    CSP, HSTS, en-têtes de sécurité, contrôle d’intégrité des dépendances, tests de non-régression, bascule DNS et surveillance post-migration.

Pour aller plus loin

Pourquoi le statique règle le problème à la racine

La sécurité d’un site WordPress est un travail sans fin. Non par défaut de conception du logiciel — son cœur est audité et corrigé rapidement — mais parce que son modèle repose sur l’exécution de code tiers à chaque requête. Un site WordPress moyen charge une vingtaine d’extensions écrites par autant d’auteurs, avec des exigences de qualité et des rythmes de maintenance très inégaux. Il suffit qu’une seule d’entre elles cesse d’être maintenue pour que votre site hérite d’une vulnérabilité que vous ne verrez pas passer.

Le raisonnement en trois temps

Premier temps : ce qui n’existe pas ne peut pas être attaqué. Un site statique ne comporte ni interpréteur PHP, ni base de données interrogeable, ni interface d’administration accessible publiquement. L’injection SQL, l’exécution de code à distance et le bourrage d’identifiants sur le back-office n’ont tout simplement plus de cible.

Deuxième temps : l’édition n’a pas besoin d’être publique. C’est le malentendu le plus fréquent. Un CMS headless offre la même expérience de rédaction, mais derrière une authentification, sur un domaine séparé, sans lien avec le site public. Vos équipes ne perdent rien ; les attaquants perdent leur porte d’entrée.

Troisième temps : le dynamique se déporte. Formulaires, recherche, commentaires, espace client : chacune de ces fonctions devient un service isolé, avec son propre périmètre, ses quotas et sa journalisation. Une compromission sur le formulaire de contact ne donne plus accès au contenu du site, et inversement.

Et le référencement dans tout ça ?

C’est la question qui bloque la plupart des projets, et c’est celle qui a la réponse la plus rassurante. Google indexe du HTML. Un site statique en produit du meilleur, plus vite, avec des données structurées générées au build plutôt que par une extension. Dans nos migrations, la continuité SEO repose sur quatre points non négociables :

  • Conservation à l’identique des URLs qui reçoivent du trafic ou des liens entrants.
  • Table de redirections 301 exhaustive pour tout ce qui change, testée URL par URL.
  • Comparaison avant/après des titres, méta-descriptions, balises canoniques et hreflang.
  • Sitemap segmenté et priorisé, soumis dès la bascule, avec suivi de l’indexation.

Le gain de vitesse — un site statique passe généralement sous la seconde d’affichage — agit ensuite comme un accélérateur sur les Core Web Vitals, qui sont un signal de classement réel.

Quand le statique n’est pas la bonne réponse

Nous le disons franchement : si votre site est en réalité une application, avec des données propres à chaque utilisateur recalculées à chaque requête, un tableau de bord temps réel ou des milliers d’écritures quotidiennes, le statique seul ne suffit pas. Dans ces cas-là, nous recommandons une architecture hybride — une vitrine statique devant une application isolée — plutôt que de forcer un modèle inadapté. L’audit sert précisément à trancher cette question avant de vous engager.

Questions fréquentes

Migration WordPress : vos questions

Oui. Nous installons un CMS headless (Directus, Strapi ou Decap) dont l’interface reste très proche de WordPress. La différence : ce back-office n’est plus hébergé sur le domaine public du site, il n’est donc plus une cible.

Nous les auditons une par une. La plupart (SEO, cache, sécurité, formulaires de contact, galeries) deviennent inutiles : leur fonction est native dans l’architecture statique. Les rares extensions réellement métier sont réimplantées en service isolé ou remplacées par une API dédiée.

Le prix dépend du nombre de gabarits à reconstruire, pas du nombre de pages. Un site vitrine de trente pages avec cinq gabarits se situe dans le bas de la fourchette ; un site éditorial avec espace membre et intégrations métier demande un chiffrage dédié. L’audit gratuit de 48 h fixe le montant exact.

Votre WordPress d’origine est conservé intact, hors ligne, pendant toute la période de stabilisation. La bascule DNS est réversible en quelques minutes. Dans les faits, personne ne revient en arrière.

Oui, via un service d’authentification dédié (Auth0, Clerk, Keycloak auto-hébergé) et des pages générées à la demande côté client. La zone protégée devient un périmètre restreint et auditable, au lieu d’être une fonction du CMS.

Prochaine étape

Combien d’extensions vulnérables tourne votre site en ce moment ?

L’audit gratuit de 48 h vous donne la réponse, la liste des risques classés par criticité, et le coût exact de la migration.

Réponse sous 24 h ouvrées · Aucune donnée stockée sur nos serveurs