La méthode · Les sites

Une description, des outils,
et un script qui constate.

Nos sites ne se ressemblent pas, mais ils sortent tous de la même méthode. Tout ce qui varie d’un site à l’autre tient dans un fichier. Les outils posent ; un script vérifie ce qui tient, et il échoue tant qu’il reste un défaut.

La méthode est née du premier site, monté en deux jours en septembre 2026. Tout ce qui y a coûté du temps a été consigné ; tout ce qui se vérifie a été écrit dans un script. Depuis, chaque nouveau site la reprend telle quelle, et chaque défaut nouveau l’enrichit.

La méthode des sites : une description, neuf étapes outillées, puis la validation qui constate et le rapport de ce qu'aucun programme ne peut vérifier

Le principe

Rien n’est acquis tant qu’une mesure ne l’a pas dit. C’est la seule règle, et elle vient d’erreurs concrètes : un score DNS à 100/100 pendant que le courrier partait signé au nom d’un autre domaine ; un contrôle de santé vert sur une route qui ne répondait plus ; un échantillon de douze thèmes qui annonçait un défaut là où il y en avait cinquante et un.

D’où la forme : une méthode qu’on déroule, des outils qui posent, et un script qui constate. Le script ne répare rien : il nomme, et il sort en erreur s’il reste un échec. Aucun outil ne contient de nom de domaine, de raison sociale ni de libellé de menu : tout passe par la description du site.

Les neuf étapes

Décrire le site

Un fichier par site : le domaine, ce qui passe par le proxy et ce qui n’y passe pas, la marque, les couleurs, les menus, les pages. Le choix du proxy n’est pas une préférence : un dépôt proxifié plafonne à 100 Mo, et le courrier ne passe pas par un proxy web.

Poser le domaine et ses noms

La zone est déclarée à la plateforme, les certificats suivent. Un nom de portail est créé à part : sans lui, la connexion à l’administration renvoie vers la vitrine, qui répond « page introuvable ».

Monter le courrier

Les boîtes, puis SPF, DKIM et DMARC. La preuve n’est pas un score : c’est un message réel envoyé vers une boîte extérieure, dont on lit les en-têtes d’authentification.

Écrire les pages

En Markdown, avec des sections (bandeau, cartes, étapes, rangées alternées, chiffres, questions). Un outil les convertit en vrais blocs WordPress : chaque paragraphe reste modifiable dans l’éditeur.

Habiller

Logo, menus, pied de page et couleurs sont posés indépendamment du thème. L’habillage survit à un changement de thème, ce qui n’était pas le cas au premier essai.

Poser toute la bibliothèque de thèmes

Toute la bibliothèque, sur chaque nouveau site : le choix se fait en aperçu, et un aperçu suppose que le thème soit déjà là. Un module corrige à chaque bascule les trois défauts qui rendent un thème inutilisable.

Poser et vérifier les greffons

Les greffons du socle, posés et activés, puis vérifiés un par un : un greffon activé n’est pas un greffon qui marche. La pose se fait site par site, avec la mesure après chacun.

Référencer

Aucun site n’est livré sans son référencement : identité légale dans les données structurées, plan du site, soumission à IndexNow, ouverture aux moteurs vérifiée.

Valider

Le script de validation passe toutes ses vérifications, puis liste ce qu’aucun programme ne peut vérifier. Un échec bloque la livraison.

Une dixième étape vient ensuite, et ne s’arrête plus : nourrir le site. Un même corpus de fiches et de billets se publie sur un ou plusieurs sites, avec ses variantes par site, une adresse canonique croisée, et des captures floutées dans la page avant la prise, qu’un vérificateur refuse de publier sans rapport relu.

Ce que le script vérifie

Le nombre de vérifications dépend de la description du site : trente-quatre sur le premier, trente et une sur les trois sites de cabinets, plus de cinquante sur un site bilingue. Elles se rangent en six familles.

Les noms

Chaque nom résout, et passe ou non par le proxy, comme la description le dit.

Le certificat

Valide, sur chaque nom, avec la bonne échéance.

Les pages

Chaque page répond, aucun marqueur de gabarit n’est resté, aucune balise ne s’affiche en texte, l’adresse sans « www » renvoie vers la bonne.

La porte d’administration

Elle renvoie vers le portail de connexion de la plateforme, et le formulaire attendu s’y trouve.

Le courrier

Les enregistrements MX, SPF, DKIM et DMARC, et ce qu’on peut savoir à distance de leur alignement.

L’intérieur de WordPress

Les droits des dossiers de mise à jour, la version et le thème actif, la mémoire du conteneur, l’absence de blocs illisibles par l’éditeur, la présence du module d’habillage.

Et ce qu’il ne peut pas vérifier, il le dit

La propriété du domaine

Chez Google et chez Meta, elle passe par les comptes du commanditaire.

Les accès aux API restreintes

Ils supposent des dossiers signés par l’entité elle-même.

L’alignement réel du courrier

Il ne se lit que dans les en-têtes écrits par un serveur destinataire.

Le parcours de connexion

Deux portes successives, deux identifiants : il se joue dans un vrai navigateur.

Le rapport les liste au lieu de les taire. Le texte commercial, lui, se propose et se tranche par le commanditaire.

Les mesures enregistrées

  • 34
    vérifications passées par le premier site, sans échec
  • 30
    vérifications passées par le site de l’atelier TheSocle, sans échec
  • 53
    vérifications passées par la vitrine bilingue de Machinapolis, sans échec
  • 3
    sites de cabinets posés en une après-midi

Chaque fois, une seule alerte reste permanente : l’alignement de la signature du courrier, que seul un destinataire peut lire. Les trois sites de cabinets ont été décrits par un programme qui engendre leur description depuis la fiche de chaque cabinet ; le premier a passé ses trente et une vérifications, les deux autres ont buté sur un seul échec attendu, un nom d’application pas encore posé.

Vingt-trois pièges, payés une fois

Chaque défaut rencontré est consigné avec son symptôme, sa cause, son remède, et la façon de le détecter. Le suivant ne le repaie pas. Quelques-uns :

L’habillage disparaît

Le logo et le style étaient rangés sous le nom du thème actif : au premier changement de thème, le site se déshabillait.

L’administration mène à une page introuvable

Sans nom de portail, la plateforme renvoyait la connexion vers la vitrine, qui ne la connaît pas.

Le courrier signé par un autre

Le score affichait 100/100 ; les messages partaient signés au nom d’un autre domaine. Seul un envoi réel l’a montré.

Le contenu s’ouvre en HTML brut

Une page posée en HTML s’ouvrait dans l’éditeur comme un bloc illisible. D’où la conversion en vrais blocs.

Une sonde qui ment

Un contrôle de santé restait vert pendant que la route ne répondait plus.

Le blog, au premier article

Cinq défauts du gabarit d’article, que seule la lecture d’un vrai billet a révélés.

Les pages restent-elles modifiables à la main ?

Oui. La méthode écrit de vrais blocs WordPress, pas du HTML figé : chaque paragraphe, chaque carte, chaque bouton se modifie dans l’éditeur. Et le Markdown reste la source : on peut tout reposer d’une commande.

Un site peut-il changer de thème ?

Oui, en aperçu, à tout moment. L’habillage est posé à côté du thème, et les trois défauts courants des thèmes sont corrigés à chaque bascule.

Où vivent les greffons ?

Dans un dépôt qui est leur source de vérité, vérifié fichier par fichier contre ce qui tourne en production. Le détail est sur la page WordPress.

Un site à monter ou à reprendre ?

Gérer mes cookies