Ce qu’est réellement le pharma hack

Il ne s’agit ni d’un défacement, ni d’un rançongiciel. L’attaquant ne veut pas casser le site : il veut l’emprunter. Votre domaine a une ancienneté, des liens entrants, une réputation auprès de Google — trois choses qui coûtent cher à fabriquer. Le pharma hack consiste à greffer sur ce capital des milliers de pages de spam pharmaceutique qui se positionnent dans les résultats de recherche et renvoient le visiteur vers des officines en ligne. Vous payez l’hébergement et la réputation, quelqu’un d’autre encaisse le trafic.

La conséquence n’est pas cosmétique. Google finit par signaler le site comme compromis dans la Search Console, affiche un avertissement aux internautes, puis désindexe. Les positions construites en plusieurs années s’effondrent en quelques jours, et la remise en confiance prend des semaines — bien plus longtemps que le nettoyage technique lui-même.

Pourquoi vous ne le voyez pas

Parce que le code sait qui le regarde. C’est ce qu’on appelle le cloaking : le site sert une version aux robots d’indexation et une autre aux humains. Concrètement, le code injecté examine l’en-tête User-Agent, parfois l’adresse IP ou le site d’où vient le visiteur, puis décide.

• Googlebot reçoit une page complète, bien structurée, bourrée de mots-clés pharmaceutiques et de liens sortants.
• Un visiteur ordinaire reçoit une erreur 404, une redirection vers le site marchand, ou la page normale du site — selon ce qui attire le moins l’attention.
• L’administrateur connecté ne voit jamais rien : beaucoup de charges utiles se désactivent dès qu’un cookie de session WordPress est présent.

D’où une règle simple : un site propre en apparence n’est pas un site propre. Tant que l’on n’a pas regardé le site avec les yeux de Google, on n’a rien vérifié du tout.

Les cinq contrôles qui révèlent l’infection

Aucun ne demande d’outil payant, et tous se font en dix minutes.

1. La recherche site: dans Google, tapez site:votredomaine.fr viagra, puis la même chose avec cialis, pharmacy, pills. Un seul résultat suffit à confirmer.
2. Le nombre de pages indexées : site:votredomaine.fr sans autre terme. Si un site de 40 pages en annonce 4 000, la question est réglée.
3. La Search Console : onglet Sécurité et actions manuelles, mais aussi la liste des pages indexées, le rapport de couverture — et surtout la liste des utilisateurs ayant accès à la propriété, où les attaquants s’ajoutent volontiers pour soumettre leurs propres sitemaps.
4. Les sitemaps : ouvrez le fichier d’index et déroulez-le. Un sitemap que personne n’a créé, ou une liste d’URL inconnues, ne laisse aucun doute.
5. La vue Googlebot : consultez une URL suspecte en changeant l’agent utilisateur du navigateur pour celui de Googlebot (outils de développement, onglet Réseau). La page de spam apparaît alors que la même URL renvoie 404 en navigation normale.

Où le code se cache

Le pharma hack est rarement un fichier unique. Il est modulaire, redondant, et prévu pour se réinstaller. Les emplacements qui reviennent le plus souvent :

• Les fichiers de tête : index.php, wp-config.php, wp-settings.php, avec quelques lignes ajoutées tout en haut ou tout en bas, souvent après des centaines d’espaces pour passer inaperçues.
• Plusieurs .htaccess, dont certains dans des sous-dossiers où il n’y en a jamais eu : ils pilotent les redirections conditionnelles.
• La base de données : contenus injectés directement dans wp_posts (pages publiées, souvent antidatées), et surtout wp_options, qui héberge des options d’apparence anodine contenant du code encodé.
• Les tâches planifiées : une entrée cron qui réécrit les fichiers nettoyés quelques heures après votre passage. C’est la raison numéro un des « réinfections » signalées deux jours plus tard.
• Le dossier uploads : aucun fichier .php n’a rien à y faire. Leur présence est un signal à elle seule.
• Les thèmes et extensions inactifs, jamais mis à jour puisque jamais utilisés, et donc parfaits pour héberger une porte dérobée.

Le code lui-même est obscurci : eval, base64_decode, gzinflate, concaténations de variables, et de plus en plus souvent des caractères Unicode qui ressemblent à des caractères latins pour tromper une recherche textuelle. Chercher eval( ne suffit plus ; il faut comparer les fichiers à leur version officielle.

Le nettoyage, dans l’ordre

L’ordre compte autant que les gestes. Nettoyer les fichiers avant d’avoir coupé les accès revient à repeindre pendant que la fenêtre est ouverte.

1. Figer la situation

Sauvegarder l’état infecté — fichiers et base — avant toute intervention. C’est la seule pièce qui permettra de comprendre par où l’attaquant est entré, et de vérifier plus tard qu’on n’a rien oublié. Ensuite seulement, couper : mots de passe de tous les comptes, accès FTP/SFTP, base de données, panneau d’hébergement, et régénération des clés de sécurité de wp-config.php pour invalider les sessions ouvertes.

2. Remplacer plutôt que réparer

Le cœur de WordPress se remplace intégralement par une archive officielle de la même version : wp-admin et wp-includes écrasés, fichiers racine remplacés à l’exception de wp-config.php et du dossier wp-content. Pour les extensions et les thèmes, on réinstalle depuis la source officielle au lieu de corriger ligne à ligne. Seul le thème sur-mesure demande une comparaison manuelle avec le dépôt de code.

3. Traiter la base et les relances

Supprimer les contenus injectés dans wp_posts, inspecter wp_options, vider les tâches planifiées illégitimes, supprimer les comptes administrateur non identifiés — et vérifier les adresses de messagerie des comptes restants, souvent modifiées en douce pour récupérer les liens de réinitialisation.

4. Vérifier comme un robot, pas comme un humain

On refait les cinq contrôles du début, en agent utilisateur Googlebot, et on les refait encore trois jours plus tard. Un pharma hack déclaré propre au bout d’une heure est un pharma hack qu’on n’a pas fini de nettoyer.

Le volet SEO, celui qu’on oublie toujours

Le site peut être parfaitement assaini et continuer à afficher des résultats pharmaceutiques pendant des semaines : l’index de Google, lui, n’a pas été nettoyé. Quatre gestes s’imposent une fois le site sain :

• Faire retourner un code 410 (ou 404) sur les URL de spam, plutôt que de les rediriger vers l’accueil.
• Régénérer et resoumettre le sitemap légitime, supprimer tout sitemap étranger déclaré dans la Search Console.
• Demander un examen de sécurité dans la Search Console, en décrivant ce qui a été fait — un dossier précis est traité plus vite.
• Surveiller le nombre de pages indexées pendant un mois : c’est l’indicateur qui confirme la guérison, pas le scanner.

Par où ça entre

Trois portes, presque toujours les mêmes : une extension ou un thème non mis à jour comportant une faille connue ; une extension ou un thème « nulled », téléchargée gratuitement alors qu’elle est payante, et livrée avec sa porte dérobée intégrée ; ou, de plus en plus, un identifiant d’administration volé ailleurs et rejoué sur le site, sans la moindre tentative échouée dans les journaux.

Les deux premières se règlent par de la discipline de maintenance. La troisième ne se règle que par la double authentification et l’hygiène des accès.

Comment nous intervenons

Nous traitons ces situations comme des reprises de site, pas comme des dépannages. L’ordre de nos interventions est toujours le même : constater avec les bons outils, figer l’état, couper les accès, remplacer le code par des sources officielles, nettoyer la base, puis rouvrir — et enfin travailler l’index côté moteur de recherche, qui est la partie visible pour le client.

Sur les sites que nous maintenons, l’essentiel du travail est fait en amont : inventaire des extensions et suppression de celles que plus personne n’utilise, aucune source non officielle, comptes nominatifs et rôles minimaux, second facteur sur les accès à privilèges, durcissement de l’installation, mises à jour suivies, et sauvegardes assez anciennes pour couvrir une infection qui daterait de plusieurs semaines. Ce sont les mêmes réflexes que ceux décrits dans nos missions de développement et de maintenance WordPress, de reprise de site et de référencement.

À faire aujourd’hui, même si tout va bien

Tapez site:votredomaine.fr dans Google et comparez le nombre de résultats au nombre de pages que vous pensez avoir. Ouvrez la liste des utilisateurs de votre Search Console. Ouvrez celle des extensions installées. Trois minutes, et vous saurez si le sujet vous concerne.

Si quelque chose cloche, ou si vous préférez faire regarder par quelqu’un dont c’est le métier : écrivez-nous. Nous commençons toujours par un état des lieux, avant de toucher à quoi que ce soit.

Les intrusions par identifiants valides — volés ailleurs, puis rejoués sur le site — sont en forte progression depuis le début de l’année. Elles ne ressemblent pas à un piratage : elles ressemblent à une journée de travail normale.

Une connexion réussie, du premier coup

Le scénario type, rapporté ces derniers mois sur des dizaines de sites, tient en quelques lignes. Une agence découvre sur un site client une extension qu’elle n’a jamais installée, au nom rassurant : « Admin Security Tools ». Elle remonte les journaux de connexion en s’attendant à trouver des centaines d’échecs. Il n’y en a aucun. Une adresse IP située à Francfort s’est connectée une fois, avec les bons identifiants, et rien d’autre. L’extension n’était pas l’attaque : c’était la porte de service posée par l’attaquant pour revenir même après un changement de mot de passe.

Tous les sites de cette agence étaient touchés par le même intrus. L’origine exacte des identifiants n’a pas pu être établie — poste infecté par un logiciel voleur de mots de passe, session de navigateur récupérée, hameçonnage réussi, ou fuite chez un tiers ayant eu accès aux accès. C’est précisément le point : on ne sait pas toujours où la fuite a eu lieu, et le site piraté n’en garde aucune trace.

Pourquoi la force brute n’est plus le sujet

Un mot de passe valide s’obtient aujourd’hui bien plus facilement qu’il ne se devine. Quatre circuits alimentent le marché :

• Les logiciels voleurs d’identifiants (infostealers), installés sur le poste de travail par un faux installeur ou une pièce jointe, qui exfiltrent en une passe tous les mots de passe enregistrés dans le navigateur — y compris celui de l’administration WordPress, et les identifiants du client FTP.
• Le vol de session : inutile de connaître le mot de passe si l’on récupère le cookie de connexion, qui reste valide jusqu’à son expiration.
• L’hameçonnage ciblé, devenu propre : une fausse notification de mise à jour, un faux message de l’hébergeur, une page de connexion copiée au pixel près.
• La réutilisation : le même mot de passe sur le site et sur un service tiers qui, lui, a fuité. L’attaquant n’a rien à casser, juste à essayer ailleurs.

Dans les quatre cas, le site reçoit une connexion parfaitement légitime. Aucune règle de limitation de tentatives ne se déclenche, aucun pare-feu ne bronche : du point de vue de WordPress, c’est vous qui vous connectez.

Ce que WordPress ne voit pas

Une installation WordPress nue n’a aucun moyen de repérer ce scénario. Elle ne journalise pas les connexions réussies, ne prévient pas qu’un compte administrateur s’est connecté depuis un pays inhabituel, ne propose pas de second facteur, et n’expire pas les sessions ouvertes. Ajoutez à cela que beaucoup de sites publient la liste de leurs comptes : l’API REST (/wp-json/wp/v2/users), les archives d’auteur et les données oEmbed livrent volontiers les identifiants de connexion. L’attaquant n’a donc à trouver qu’une moitié du couple.

Le corollaire est désagréable : l’absence d’alerte ne prouve rien. Un tableau de bord vert, un scanner silencieux et zéro tentative bloquée, c’est exactement ce qu’on observe sur un site où quelqu’un est entré par la porte.

Le signal à surveiller : les connexions qui réussissent

Le renversement de méthode tient en une phrase : arrêter de compter les échecs, commencer à regarder les succès. Trois questions suffisent à ouvrir le dossier.

• Qui s’est connecté ces trente derniers jours, depuis quelle adresse et à quelle heure ? Une connexion administrateur à 3 h du matin depuis un pays où personne ne travaille est un événement, même si tout va bien par ailleurs.
• La liste des comptes correspond-elle à la liste des personnes ? Les comptes de stagiaires partis, de prestataires d’il y a trois ans et d’extensions désinstallées survivent presque toujours, souvent avec le rôle administrateur.
• La liste des extensions installées correspond-elle à la liste des extensions choisies ? C’est ce test, et lui seul, qui fait tomber le scénario décrit plus haut.

La double authentification n’est plus une option de confort

Un mot de passe long et unique reste indispensable, mais il ne protège de rien une fois volé : sa force n’a aucune influence sur sa capacité à être recopiée. Le seul mécanisme qui casse la chaîne, c’est le second facteur. Un identifiant dérobé devient alors une information sans valeur.

Commencer par le plus simple plutôt que par le plus élégant

L’objection habituelle est humaine : les clients ne veulent pas installer une application d’authentification. Le second facteur par courriel — un code envoyé à l’adresse du compte — se met en place sans rien installer et ferme déjà l’essentiel du problème. Une application TOTP est plus robuste, une clé physique encore plus, mais un second facteur imparfait activé vaut infiniment mieux qu’un second facteur idéal repoussé de trimestre en trimestre.

L’activer là où ça compte

Sur tous les comptes administrateur et éditeur, et sur tous les sites — pas seulement sur celui qui a été touché. Un attaquant qui tient un accès s’en sert sur tout le portefeuille : les identifiants d’une agence ouvrent les sites de ses clients, et un poste infecté suffit à exposer l’ensemble.

Changer le mot de passe ne suffit jamais

C’est le réflexe le plus courant, et le plus insuffisant. Un attaquant qui a eu un accès administrateur pendant quelques minutes a eu le temps de se ménager plusieurs retours. Une remise au propre digne de ce nom suit cet ordre :

1. Déconnecter toutes les sessions en régénérant les clés de sécurité de wp-config.php — sinon le cookie volé reste valide malgré le nouveau mot de passe.
2. Réinitialiser tous les comptes, pas seulement le sien, et supprimer ceux qui ne correspondent à personne.
3. Inventorier les extensions et les thèmes, y compris les mu-plugins, qui s’activent sans apparaître dans la liste classique.
4. Vérifier les tâches planifiées : une tâche cron est un point de relance discret pour un code qui se réinstalle tout seul.
5. Changer aussi les accès périphériques : FTP/SFTP, base de données, panneau d’hébergement, comptes de messagerie associés. Ils sont souvent enregistrés dans le même navigateur que celui qui a fuité.
6. Restaurer depuis une sauvegarde antérieure à l’intrusion quand le doute persiste — ce qui suppose d’avoir des sauvegardes assez anciennes, et testées.

Comment nous intervenons

Nous ne vendons pas de logiciel de sécurité et nous ne promettons l’inviolabilité de rien. Notre travail consiste à réduire la surface d’attaque, à rendre l’anomalie visible, et à garantir qu’un retour en arrière reste possible. Concrètement, sur les sites que nous construisons et que nous maintenons :

• Comptes nominatifs et rôles minimaux. Pas de compte « admin » partagé entre l’agence, le client et le prestataire de passage : chacun le sien, au rôle le plus bas qui permette de travailler, et on ferme les accès quand la mission s’arrête.
• Second facteur sur les comptes à privilèges, et mots de passe gérés dans un gestionnaire dédié — jamais dans le navigateur, qui est justement la cible des logiciels voleurs.
• Durcissement de l’installation : édition de fichiers désactivée depuis l’administration, énumération des comptes fermée côté API REST et oEmbed, en-têtes de sécurité posés au niveau du serveur, fichiers d’installation et numéros de version inutiles retirés.
• Audit d’entrée systématique sur les reprises de site. Quand nous récupérons un WordPress dont personne ne connaît l’historique, nous commençons par l’inventaire : comptes réels, extensions abandonnées ou piratées, code laissé par d’anciens prestataires, tables orphelines, tâches planifiées en échec. C’est là que se trouvent les mauvaises surprises, pas dans le thème.
• Mises à jour suivies et sauvegardes restaurables. Une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde, c’est une hypothèse.

C’est la méthode que nous appliquons dans nos missions de développement et de maintenance WordPress comme dans les refontes et reprises de site — un sujet que nous abordons sous un autre angle dans notre article sur la façon de reprendre un site WordPress laissé à l’abandon.

Trois gestes à faire cette semaine

Si vous ne deviez retenir que trois actions, dans cet ordre :

1. Activer la double authentification sur tous les comptes administrateur, en commençant par le second facteur par courriel si c’est le plus rapide à déployer.
2. Ouvrir la liste des comptes et celle des extensions, et supprimer tout ce que personne ne revendique.
3. Sortir les mots de passe du navigateur et les confier à un gestionnaire dédié — c’est le geste qui coupe la voie d’entrée la plus fréquente.

Un doute sur l’état d’un site, une reprise à documenter, un portefeuille de sites à remettre au carré : écrivez-nous. Nous commençons toujours par regarder avant de proposer quoi que ce soit.

Le DSFR en une minute

Le Système de Design de l’État est l’outil destiné à produire les interfaces officielles des sites en .gouv.fr. Il est porté par le Service d’Information du Gouvernement (SIG) et regroupe un ensemble de règles et de composants réutilisables, avec un objectif affiché : fournir à la population des services numériques simples, accessibles et reconnaissables.

Concrètement, il contient :

• les fondamentaux — identité de marque, typographie, couleurs, grille, règles d’accessibilité ;
• une bibliothèque de plus de 50 composants d’interface prêts à l’emploi ;
• des modèles de page officiels et des formulaires types ;
• l’outillage qui va avec : librairies Figma et Sketch, Storybook, et même des extensions pour LimeSurvey et Penpot.

La version courante est la 1.15.2, disponible depuis le 11 août 2026 — la 1.15.0 étant sortie le 17 juillet et la 1.15.1 le 20 juillet. Le rythme est celui d’un vrai produit : des versions mineures régulières, des correctifs documentés, et parfois des changements qui cassent l’existant. C’est une ligne de maintenance à budgéter, pas une intégration qu’on livre et qu’on oublie.

Autour du code, il y a aussi des interlocuteurs : chaque ministère dispose d’un Responsable du design, la communauté échange sur Tchap, et les demandes de correctifs passent par un portail JIRA. Le SIG publie par ailleurs des notes de doctrine qui vont au-delà du design : la plus récente recommande un marquage explicite des contenus produits avec l’aide d’une intelligence artificielle.

Ce que dit la circulaire 6411-SG

Le texte de référence est la circulaire n°6411/SG du 7 juillet 2023, relative à l’amélioration de la lisibilité des sites Internet de l’État et de la qualité des démarches numériques. Une note d’application produite par le SIG le 13 juillet 2023 en précise les modalités. Les deux documents sont téléchargeables depuis la documentation officielle.

DSFR et .gouv.fr sont indissociables

C’est le point qui surprend le plus, et il mérite d’être cité tel quel : depuis le 7 juillet 2023, la mise en œuvre du DSFR sur un site ne peut se faire sans recourir à un nom de domaine en .gouv.fr. Et inversement, un site en .gouv.fr ne peut pas être mis en ligne sans se conformer au DSFR. Les deux composantes sont indissociables et doivent être utilisées simultanément. L’extension .gouv.fr, elle, est gérée par délégation à l’AFNIC.

Autrement dit, on ne « prend » pas le DSFR pour son ergonomie ou pour ses composants accessibles. On l’adopte parce qu’on est dans son périmètre, avec le nom de domaine qui va avec.

Pourquoi une telle obligation

La raison est écrite noir sur blanc dans la documentation, et elle n’a rien de cosmétique : dans un contexte croissant de désinformation, le DSFR et le .gouv.fr sont des repères qui assurent au citoyen qu’il est bien sur un site officiel. C’est une logique de marque de confiance, avec tout ce qu’elle implique — y compris le fait que l’État défende cette marque.

Trois régimes, pas un seul

La question « est-ce que le DSFR s’applique à moi ? » n’a pas une réponse mais trois, selon la nature de l’entité.

L’État central et déconcentré : obligatoire

Sont soumises à l’obligation toutes les entités constitutives de l’État central :

• les administrations centrales et leurs directions ;
• les délégations et missions interministérielles ;
• les préfectures, les ambassades et l’ensemble des services déconcentrés.

L’obligation porte sur tout nouveau site Internet ou application mobile mis à disposition du public. Et elle ne s’arrête pas au fait de « piocher » dans la bibliothèque : elle implique le bon usage des composants, le strict respect des fondamentaux, et le respect de la procédure des agréments du SIG.

Les opérateurs de l’État : facultatif, avec un socle obligatoire

Les opérateurs de l’État — au sens de l’annexe « opérateurs de l’État » du projet de loi de finances — bénéficient d’un régime plus souple, souvent mal compris. Le détail compte :

• le DSFR n’est pas obligatoire pour eux ;
• en revanche, les éléments de marque de l’État le sont : le bloc marque doit figurer en haut de page ainsi que dans le pied de page ;
• ils sont fortement encouragés à recourir au DSFR et au .gouv.fr, mais pas l’un sans l’autre ;
• s’ils le souhaitent, la demande doit faire l’objet d’un agrément auprès du SIG, en passant par le Responsable de design du ministère de tutelle ;
• cette possibilité d’utilisation ne vaut que dans le cadre de la mission de service public de l’opérateur.

Tout le reste : interdit

La formulation officielle ne laisse aucune marge d’interprétation : il est formellement interdit à tout autre acteur d’utiliser le Système de Design de l’État — les administrations territoriales comme les acteurs privés. Le DSFR représente l’identité numérique de l’État ; ces entités ne sont donc pas concernées par son déploiement. En cas d’usage à des fins trompeuses ou frauduleuses, l’État se réserve le droit d’entreprendre les actions nécessaires pour y mettre un terme.

C’est la principale surprise que nous avons à annoncer, en avant-vente comme en cours de projet : non, une commune, une intercommunalité, un département ou une région ne peut pas « passer son site au DSFR ». Nous y revenons plus bas, parce qu’il existe une réponse utile à ce besoin.

« Se conformer », concrètement

Pas d’usage partiel, pas d’adaptation

Choisir d’utiliser le DSFR, c’est le faire de façon complète et exhaustive : les adaptations et les utilisations partielles des composants ne sont pas autorisées. En pratique, cela ferme deux portes qu’on voit souvent s’ouvrir dans les cahiers des charges : reprendre la charte en changeant la palette « pour rester dans nos couleurs », et n’intégrer que quelques composants dans une maquette maison. Ni l’un ni l’autre n’est conforme.

Les trois agréments du SIG

Les créations et refontes de sites grand public de l’État et des applications mobiles sont soumises à l’agrément du SIG, quel que soit le nom de domaine, la demande passant par le Responsable de design du ministère de tutelle. Il existe trois démarches distinctes :

• l’agrément préalable, à demander avant le lancement du projet, pour valider son principe en amont de la construction ;
• l’agrément définitif, à demander avant la mise en production, pour valider la conformité aux différents référentiels — DSFR, RGAA, mesure d’audience ;
• l’obtention d’une URL de communication, pour acquérir un .gouv.fr sur un site existant ou poser une redirection dans le cadre d’une campagne.

Ces deux jalons ne sont pas des formalités de fin de projet : ils se placent au rétroplanning dès le cadrage. Un agrément définitif demandé trois jours avant la date de mise en ligne prévue, c’est une mise en ligne qui glisse.

DSFR et WordPress : ce qui marche, ce qui coince

Ce que la version 1.15 change pour un projet

Un changement de distribution est passé assez discrètement, et il a des conséquences très concrètes sur un chiffrage : le code compilé du DSFR n’est plus disponible en téléchargement direct via les releases GitHub. Il faut désormais importer le paquet via NPM, ou cloner le dépôt et compiler les sources. La mesure vise à s’assurer que tout utilisateur accepte les modalités d’utilisation avant de se servir du DSFR.

Traduction pour un projet WordPress : un thème conforme suppose une chaîne de compilation (Node et NPM) dans le projet, et une procédure de mise à jour qui passe par elle. Le « je dépose un zip dans wp-content et je mets à jour à la main dans deux ans » n’est plus une option. À la même période, la licence du projet est passée en Etalab 2.0 et les conditions générales d’utilisation ont été intégrées au build.

Un portage WordPress existe

Le thème WP-DSFR, développé par l’agence Be API, est un portage open source du DSFR sous forme de thème WordPress, compatible avec l’éditeur Gutenberg. C’est un point de départ crédible, à condition de savoir ce qu’il fait et ce qu’il ne fait pas : il fait gagner du temps sur l’intégration des composants ; il ne délivre pas l’agrément du SIG, et il ne rend pas un site conforme au RGAA. La conformité d’accessibilité se constate sur le site fini, pas sur la bibliothèque utilisée.

Les pièges de montée de version

Trois exemples pris dans la seule version 1.15, qui donnent le ton du travail de maintenance :

• la classe utilitaire red-marianne a été retirée des classes de couleur, de fond et de bordure, son usage n’étant pas autorisé : un site qui s’en servait casse à la mise à jour ;
• le chargement des pictogrammes SVG a été sécurisé — SVG assainis avant insertion dans le DOM et chargement restreint à la même origine ; l’impact documenté concerne IE11, où des pictogrammes servis depuis un CDN tiers ne se chargent plus. Le réflexe à prendre : rapatrier ses assets sur la même origine que l’application ;
• dans le pied de page, les titres de catégories passent en h2 par défaut, ce qui modifie la hiérarchie de titres d’un site existant — et donc son audit d’accessibilité.

Au passage, la même version ajoute le bouton ProConnect, l’état indéterminé sur les cases à cocher, et une prise en compte des modes de contraste élevé. Ce sont de bonnes nouvelles, mais elles arrivent au même rythme que les changements cassants.

Et les page builders ?

Ils sont hors sujet ici, et pour une fois ce n’est pas une question de performance : le DSFR impose un balisage précis et n’autorise aucune adaptation. Construire une page de l’État à la souris dans un constructeur visuel produit du HTML qui n’est pas celui du système de design. C’est une raison de plus, dans ce contexte, de travailler avec un thème et des blocs maîtrisés.

Vous êtes une collectivité : ce qui est interdit, ce qui reste légitime

C’est le cas de figure le plus fréquent, et il mérite une réponse qui ne s’arrête pas à « non ».

Ce qui est interdit, c’est le DSFR en tant qu’identité de l’État : la Marianne, le bloc marque, la typographie institutionnelle, les composants tels quels, et le tout sur un .gouv.fr auquel vous n’avez pas droit.

Ce qui est parfaitement légitime, en revanche, c’est d’en reprendre la méthode, qui est la vraie valeur du DSFR : un système de design documenté, une bibliothèque de composants accessibles, des modèles de page réutilisables, et une charte partagée entre tous les sites de la collectivité. Rien n’empêche une ville ou un département de se doter de son propre système de design — c’est même le meilleur investissement quand on gère un site principal, des sites d’équipements et deux ou trois sites de campagne.

Et surtout, ce qui reste obligatoire pour tout le monde, DSFR ou pas : le RGAA. L’obligation d’accessibilité des sites publics ne dépend pas du système de design employé. C’est là que se joue la conformité réelle d’un site public, et c’est un chantier que nous menons indépendamment du DSFR — voir notre page Accessibilité.

Comment nous abordons ces projets

Notre méthode sur un projet qui touche à ce périmètre tient en cinq points :

1. Qualifier le régime applicable avant toute maquette : obligation pleine, socle marque pour un opérateur, ou hors périmètre. Cette seule réponse change le budget et le calendrier.
2. Placer les agréments au rétroplanning, agrément préalable au cadrage et agrément définitif avant la mise en production.
3. Intégrer proprement : thème WordPress avec chaîne de build, respect des fondamentaux, aucun composant adapté.
4. Auditer le RGAA sur le site fini, et produire la déclaration d’accessibilité qui va avec.
5. Tenir la conformité dans le temps, parce que le DSFR bouge — nous suivons les versions dans le cadre de la maintenance WordPress.

Si vous êtes en amont d’une création ou d’une refonte, le bon moment pour trancher ces questions, c’est maintenant : elles conditionnent le choix du nom de domaine.

Questions fréquentes

Une mairie peut-elle utiliser le DSFR ?

Non. L’usage est formellement interdit aux administrations territoriales, comme à tout acteur privé. Le DSFR est réservé aux services de l’État.

Un opérateur de l’État est-il obligé de l’utiliser ?

Non, le DSFR n’est pas obligatoire pour les opérateurs. En revanche, les éléments de marque de l’État sont attendus — bloc marque en haut de page et en pied de page — et l’usage du DSFR comme du .gouv.fr ne peut se faire que sur agrément du SIG, l’un n’allant pas sans l’autre.

Le DSFR rend-il un site conforme au RGAA ?

Non. Ses composants sont conçus pour favoriser l’accessibilité, ce qui aide beaucoup, mais la conformité s’apprécie sur le site livré : contenus, images, formulaires, parcours. L’audit reste dû, et l’agrément définitif vérifie d’ailleurs le RGAA en plus du DSFR.

Peut-on n’en utiliser que quelques composants ?

Non. Les adaptations et les usages partiels ne sont pas autorisés : c’est le système entier, ou rien.

Pour aller plus loin

• La page Périmètre d’application (nouvel onglet) de la documentation officielle, qui héberge la circulaire et la note du SIG.
• La note aux opérateurs (nouvel onglet), pour le régime des opérateurs et le détail des agréments.
• La note de version 1.15 (nouvel onglet), à lire avant toute montée de version.
• Le thème WP-DSFR (nouvel onglet), pour les projets WordPress dans le périmètre.

Un projet public à cadrer, ou un doute sur votre périmètre ?
Parlons-en. On vous répond sous 48 h, sans jargon, avec un premier avis clair sur le régime qui s’applique à vous.

Louer ou posséder : la vraie ligne de partage

Une plateforme fermée vous donne un espace de vente clés en main, hébergé, maintenu, sécurisé par l’éditeur. En échange, la boutique reste chez lui. Vous administrez un compte, pas une infrastructure.

WooCommerce fonctionne à l’inverse : c’est une extension WordPress installée sur un hébergement que vous choisissez. Personne ne peut modifier vos conditions d’utilisation, changer votre grille tarifaire ou suspendre votre accès, parce qu’il n’y a pas de compte à suspendre.

Les deux modèles sont défendables. Ce qui ne l’est pas, c’est de choisir le premier en croyant choisir le second — et de s’en apercevoir le jour où l’on veut partir.

Le coût réel, ligne par ligne

C’est l’argument commercial le plus courant en faveur des plateformes : « à partir de 29 € par mois ». Le chiffre est exact, il est simplement incomplet.

L’abonnement

Il monte par paliers, et le palier suivant se déclenche souvent sur des besoins banals : plusieurs comptes utilisateurs, une gestion multi-boutiques, des rapports détaillés. Le prix d’appel n’est presque jamais le prix d’exploitation.

La commission sur les ventes

C’est le poste qui change tout, parce qu’il grandit avec vous. Une commission de quelques dixièmes de pourcent est indolore sur 30 000 € de ventes annuelles ; sur 600 000 €, elle finance à elle seule une bonne partie d’un développement sur-mesure. Certaines plateformes la suppriment si vous utilisez leur propre solution de paiement — ce qui déplace le coût plutôt que de l’annuler.

Les applications

Le catalogue d’applications est présenté comme un avantage, et c’en est un. Mais chacune se facture au mois, indépendamment des autres. Une boutique un peu spécifique en cumule facilement cinq ou six : la note mensuelle dépasse alors largement l’abonnement de base.

Le thème et les développements

Un thème payant, quelques ajustements par un intégrateur : ce poste-là existe des deux côtés. La différence n’est pas son montant, c’est que sur une plateforme fermée, rien de ce que vous avez payé n’est réutilisable ailleurs.

Aucune de ces lignes n’est scandaleuse prise isolément. Faites simplement l’addition sur trois ans, avec votre chiffre d’affaires prévisionnel, et refaites l’exercice côté WooCommerce. Les deux courbes se croisent — la seule question utile est de savoir où.

Ce que la plateforme fermée ne vous laissera pas faire

Tant que votre besoin ressemble à celui de tout le monde, une plateforme le couvre très bien. Les frictions commencent aux cas particuliers, et les cas particuliers sont précisément ce qui distingue votre activité :

• un tunnel de commande modifié — une étape en moins, un champ obligatoire, une règle de validation propre à votre métier ;
• une tarification qui ne rentre pas dans la grille : adhérents, tarifs négociés, quantités dégressives, devis en ligne ;
• une connexion à votre outil de gestion quand il n’existe pas de connecteur officiel ;
• un niveau d’accessibilité contraint, quand le RGAA s’impose à vous et que le code du thème ne vous appartient pas ;
• une logique de don ou de reversement greffée sur la vente.

Sur WooCommerce, chacun de ces points est un développement : cela coûte du temps et de l’argent, mais c’est faisable. Sur une plateforme fermée, la réponse peut être simplement non — et aucun budget ne la change.

Les données clients, le point aveugle

C’est le sujet le moins discuté au moment du choix, et le plus douloureux au moment du départ. Vos fiches clients, vos commandes, vos historiques d’achat sont exportables : tous les éditeurs sérieux le permettent, et le RGPD l’impose.

Ce qui ne s’exporte pas, c’est le reste : les numéros de commande sur lesquels s’appuie votre comptabilité, le lien entre un abonnement et son historique de facturation, les avis rattachés à des références internes, les adresses de vos fiches produit. Vous récupérez des tableaux, pas une boutique. La reconstitution est un projet à part entière.

Sous WooCommerce, la base de données est la vôtre : la question de l’export ne se pose pas, seulement celle de la sauvegarde.

Ce que WooCommerce exige en retour

Il serait malhonnête de présenter l’autonomie comme gratuite. Elle a un prix, et il est réel.

L’hébergement est votre responsabilité. Une boutique demande davantage qu’un site vitrine : base de données très sollicitée, pics de trafic, paniers simultanés. Un hébergement mutualisé d’entrée de gamme ne tiendra pas.

Les mises à jour ne se font pas seules. Cœur WordPress, WooCommerce, extensions, passerelle de paiement : c’est un contrat de maintenance, pas une case à cocher.

La sécurité vous incombe. Une boutique manipule des données personnelles et des transactions ; elle mérite une surveillance, des sauvegardes testées, et quelqu’un qui décroche quand ça casse.

Sur une plateforme fermée, ces trois postes sont compris dans l’abonnement. C’est précisément ce que vous payez — et c’est un vrai service, qu’il faut porter au crédit de la plateforme au lieu de le passer sous silence.

Quand la plateforme fermée est le bon choix

Nous ne recommandons pas WooCommerce par principe. Un abonnement est le choix raisonnable si vous êtes dans l’un de ces cas :

• vous testez une idée et vous voulez vendre dans la semaine ;
• votre catalogue est simple et standard, sans règle métier particulière ;
• vous n’avez personne en interne, ni budget pour un prestataire de maintenance ;
• votre volume de ventes reste modeste, donc la commission aussi.

Le basculement se produit généralement quand la boutique devient un revenu principal plutôt qu’un complément : à ce moment-là, la commission devient un poste de charges, et la contrainte fonctionnelle un frein commercial.

Trois questions pour trancher

Si vous hésitez encore, ces trois-là suffisent le plus souvent.

1. Quel sera mon chiffre d’affaires dans trois ans ? Multipliez-le par le taux de commission. Si le résultat vous fait tiquer, vous avez votre réponse.
2. Y a-t-il une règle propre à mon métier ? Tarif adhérent, don, abonnement, devis : si oui, vérifiez qu’elle est réalisable avant de signer, pas après.
3. Qui s’occupera du site dans deux ans ? Si la réponse est « personne », l’abonnement est plus honnête qu’une installation laissée à l’abandon.

Changer de camp, ça se prépare

Passer d’une plateforme à WooCommerce n’a rien d’insurmontable, à une condition : traiter l’opération comme un projet, avec une reprise de données vérifiée et un plan d’adresses arrêté avant la bascule, jamais dans l’urgence du lendemain. C’est le sens du travail décrit sur notre page agence WooCommerce et e-commerce éthique, avec la méthode et les projets déjà menés.

Et si votre situation ne rentre dans aucune des cases ci-dessus, décrivez-nous votre projet : nous vous dirons franchement si WooCommerce est la bonne réponse — y compris quand ce n’est pas le cas.

Le problème du milieu

Presque toutes les organisations qu’on accompagne ont le même angle mort. D’un côté, un site web propre, tenu, à jour. De l’autre, la vraie vie du métier : un tableur partagé qui recense les adhérents, un second qui suit les demandes de subvention, un troisième que seule Marie sait mettre à jour, et une boîte mail qui sert de système de relance.

Ça tient. Jusqu’au jour où trois personnes ouvrent le fichier en même temps, où plus personne ne sait quelle version fait foi, où une ligne effacée par erreur ne revient pas. Là, deux devis arrivent sur le bureau.

Le premier propose un abonnement à un outil SaaS : opérationnel en deux semaines, facturé par utilisateur et par mois, données hébergées ailleurs, et un modèle de fonctionnement qu’il faudra adopter tel quel. Le second propose une application sur-mesure : quelques dizaines de milliers d’euros, six mois, et à l’arrivée un logiciel de plus à maintenir, à faire évoluer et à héberger.

Les deux réponses sont légitimes. Aucune n’est adaptée à une association de quinze personnes qui veut simplement arrêter de se relancer par e-mail.

C’est précisément ce trou-là que Teable vient occuper.

Teable en une minute

Teable est une plateforme open source de base de données collaborative. En clair : l’interface d’un tableur, la solidité d’une vraie base de données, et par-dessus, deux couches que le tableur n’a jamais eues — un moteur d’automatisations et un constructeur d’applications internes.

Les faits qui situent le projet :

• Licence AGPL-3.0 pour l’édition communautaire, avec des paquets techniques en MIT. Le dépôt teableio/teable affiche plus de 21 000 étoiles sur GitHub, ce qui en fait l’un des projets les plus suivis de sa catégorie.
• Auto-hébergeable via Docker, en déploiement autonome ou complet. Une offre cloud existe en parallèle, ainsi qu’un déploiement privé pour les organisations qui veulent garder la main sur le stockage et les accès.
• Vues multiples sur les mêmes données : grille, formulaire, kanban, galerie, calendrier. Formules, filtres, regroupements, tris, agrégations.
• Collaboration en temps réel, commentaires, historique des enregistrements, annuler/rétablir.
• API complète et documentée, avec gestion de jetons d’accès. C’est le point qui nous intéressera le plus loin dans cet article.
• Automatisations déclenchées par une modification d’enregistrement, une date ou un webhook.
• Requête SQL directe sur vos tables : les données restent dans une base SQL standard, lisible par n’importe quel outil du marché. Ce n’est pas un format propriétaire dont il faudrait un jour s’échapper.
• Certifications ISO 9001 et ISO 27001 annoncées côté éditeur.

Sur l’offre cloud, la grille tarifaire au moment où nous écrivons : gratuit jusqu’à 1 000 lignes et 1 Go de pièces jointes ; Pro à 10 $ par siège et par mois en annuel, avec 250 000 lignes ; Business à 20 $ par siège en annuel, avec un million de lignes, l’authentification unique et une matrice de permissions détaillée. En auto-hébergé, la question du plafond de lignes ne se pose plus de la même façon : c’est votre serveur qui décide.

Le premier contact

En mode découverte, la première demi-heure est révélatrice. On a importé un fichier de suivi réel — 1 800 lignes, une quinzaine de colonnes, le genre de tableur qui a vécu, avec ses colonnes fantômes et ses dates saisies dans trois formats différents.

Trois observations.

On est chez soi immédiatement. Quiconque a déjà utilisé Airtable ne sera pas dépaysé une seconde : mêmes concepts, même vocabulaire, même geste pour créer une vue ou relier deux tables. C’est un compliment ambigu — Teable ne cherche visiblement pas à réinventer l’ergonomie du genre — mais pour une équipe qui doit adopter l’outil sans formation lourde, c’est exactement ce qu’il faut.

Le passage du tableur à la base se fait dans la douleur, et c’est normal. L’import prend trente secondes, mais le vrai travail commence après : décider ce qui est une table et ce qui est une colonne, transformer une colonne de texte libre en liste fermée, extraire les relations que le tableur écrasait. Aucun outil ne fera cette réflexion à votre place, et il faut se méfier de ceux qui le promettent. Comptez une demi-journée d’atelier pour un processus de taille moyenne — c’est du temps très bien investi, parce que c’est là que les incohérences du fichier d’origine remontent à la surface.

Les formulaires changent la donne plus vite qu’on ne le croit. Une vue formulaire se crée en deux clics et s’envoie par lien. La saisie arrive directement dans la base, avec les bons types de champs et les bonnes validations. Rien que ce geste — arrêter de recevoir des informations par e-mail pour les recopier ensuite — supprime une catégorie entière d’erreurs.

Un mot sur les automatisations, puisque c’est la couche qui justifie l’outil. Le principe est classique — un déclencheur, une suite d’actions — mais la mise en œuvre est nettement plus accessible que les moteurs de workflow d’entreprise. On décrit ce qu’on veut, on teste, on ajuste. Le premier scénario utile (quand un dossier passe au statut « validé », prévenir la personne concernée et poser la date) prend une dizaine de minutes.

Ce qui le distingue d’Airtable

Poser la comparaison honnêtement suppose de reconnaître d’abord ce qu’Airtable a pour lui : dix ans d’avance, un écosystème d’intégrations considérable, une communauté immense, des modèles tout prêts pour à peu près tous les métiers, et une fiabilité éprouvée à grande échelle. Sur ces terrains, Teable est un challenger, pas un remplaçant évident.

Cela posé, quatre différences comptent vraiment.

Le code est ouvert, et l’outil s’auto-héberge. C’est la différence structurante, pas un argument idéologique. Pour une collectivité, une association traitant des données sensibles ou un établissement soumis à des exigences de souveraineté, pouvoir installer l’outil sur un serveur en France, chez le même hébergeur que le site, règle en une phrase une conversation qui dure sinon des mois.

Le coût ne suit pas la même courbe. Un tarif par siège devient douloureux dès qu’on veut donner accès à des personnes qui consultent plus qu’elles ne saisissent : bénévoles, partenaires, élus, terrain. En auto-hébergé, cette contrainte disparaît. C’est souvent ce point, plus que le prix affiché, qui fait basculer une décision.

Les données restent interrogeables. Une base SQL standard, une API documentée, un export à tout moment : la réversibilité n’est pas une promesse commerciale, c’est une propriété technique. On peut brancher un outil de reporting, alimenter le site web, écrire un script de synchronisation. On y revient tout de suite.

Le produit est jeune. Il faut le dire dans l’autre sens aussi. Un projet de trois ans, aussi bien suivi soit-il, n’a pas la maturité d’un service qui tourne depuis dix ans. Sur un processus critique, cela justifie de vérifier la trajectoire du projet et de prévoir un plan de sortie — ce que la licence ouverte rend justement possible.

Et Claude Code là-dedans ?

C’est là que la comparaison devient intéressante, parce qu’elle ne se joue plus entre deux outils no-code.

Claude Code est un agent de développement qui travaille dans le terminal : il lit un dépôt, écrit du code, exécute des commandes, corrige. Avec un outil pareil, la tentation est grande de tout construire sur mesure — le coût d’écriture d’une application interne a chuté d’un ordre de grandeur en deux ans. Sauf qu’écrire le code n’a jamais été le vrai coût. Le vrai coût, c’est le logiciel qu’on possède ensuite : l’authentification à tenir, les droits à gérer, les migrations de base, les sauvegardes, les dépendances qui vieillissent, l’interface d’administration que personne n’a envie de dessiner.

Teable et Claude Code ne sont donc pas deux réponses concurrentes à la même question. Ils occupent deux moitiés complémentaires du travail.

Ce que Teable apporte, et qu’on aurait tort de réécrire : le stockage, les comptes et les droits par rôle, les vues, les formulaires, l’historique, la collaboration en temps réel, le moteur d’automatisations, l’interface d’administration. Tout ce qui est générique, éprouvé, ennuyeux à refaire et coûteux à maintenir.

Ce que l’agent apporte, et que l’outil ne fera jamais : le spécifique. L’import biscornu du fichier historique que personne n’a jamais réussi à nettoyer. Le calcul métier qui n’entre dans aucune formule standard. Le pont avec votre site WordPress. L’interface de pilotage taillée pour un comité de direction, avec les trois indicateurs qui comptent et rien d’autre.

Le lien entre les deux, c’est l’API. Teable expose une API complète avec gestion de jetons : créer des tables, écrire et lire des enregistrements, déclencher des traitements. Concrètement, dans notre pratique, cela veut dire décrire le modèle de données à l’agent en langage courant et le laisser poser la structure, écrire le script d’import, brancher le formulaire du site et générer la synchronisation — pendant que la partie visible reste dans Teable, où le client la modifie lui-même sans nous appeler.

Un mot sur MCP, puisque la question revient. Le Model Context Protocol est le standard ouvert qui permet à un agent comme Claude Code de dialoguer avec un outil externe sans intégration codée en dur. Des serveurs MCP communautaires pour Teable circulent déjà ; à notre connaissance il n’existe pas encore de serveur officiel maintenu par l’éditeur. En attendant, l’API REST documentée fait parfaitement le travail — et c’est de toute façon elle qui se trouve sous n’importe quel serveur MCP.

Ce qu’on ne lui demanderait pas

Un article de découverte qui ne liste que des qualités est une publicité. Quatre réserves, sincères.

Ce n’est pas un ERP, ni un CRM clé en main. Teable donne les briques ; l’assemblage reste à faire, et il demande de savoir ce qu’on veut. Une organisation qui cherche un logiciel de comptabilité ou de gestion commerciale prêt à l’emploi doit acheter ce logiciel, pas le reconstruire.

Ce n’est pas non plus une base de données publique. L’outil sert au travail interne. Pour publier des contenus sur le web — un catalogue, un annuaire, des actualités —, c’est votre site qui reste la vitrine ; Teable l’alimente en coulisses.

Les fonctions d’IA méritent une lecture attentive. Elles s’appuient sur des modèles hébergés par des tiers. Sur des données personnelles ou sensibles, la question de ce qui sort de votre infrastructure doit être tranchée avant d’activer la fonctionnalité, pas après. En auto-hébergé, la possibilité de brancher d’autres modèles ouvre des options, mais elle ne dispense pas de l’analyse.

La licence AGPL a des conséquences. Pour un usage interne, aucune. Si vous envisagez de redistribuer un service construit dessus, le sujet mérite un avis éclairé.

Ce qu’on en fait concrètement

Nous avons ajouté cette approche à nos applications métier sur-mesure : cartographier un processus réel, le modéliser, automatiser ce qui fait perdre le plus de temps, et développer sur demande les interfaces de tableau de bord et de pilotage qui vont avec. Le tout connecté au site WordPress quand ça a du sens, et hébergé en France quand c’est nécessaire.

La bonne nouvelle de cette découverte n’est pas qu’un outil de plus existe. C’est qu’entre « on prend l’abonnement et on s’adapte » et « on développe tout », une troisième voie est devenue praticable — plus rapide que la seconde, plus libre que la première, et surtout réversible.

Pour aller plus loin

• Le site officiel : teable.ai (nouvel onglet) — présentation, offres et documentation.
• Le dépôt public : github.com/teableio/teable (nouvel onglet) — licence, code et rythme des versions.
• La documentation de l’API et des jetons d’accès, pour évaluer l’intégration à vos outils existants.
• Notre page Applications métier sur-mesure, si vous voulez voir à quoi ressemble la démarche côté projet.

Un processus qui vous coûte des heures chaque semaine ?

Parlons-en. On regarde ensemble ce qui s’automatise vraiment, et ce qui ne vaut pas la peine de l’être. Réponse sous 48 h.

Le référentiel n’est pourtant ni long ni obscur : 78 critères, 9 familles, un livrable public. Et une question de départ qui vaut pour n’importe quel site : est-ce qu’il a besoin de peser ce qu’il pèse ? Voici ce qu’il demande, ce qu’il ne demande pas, et la manière dont nous nous y prenons.

Le RGESN en une minute

Le Référentiel général d’écoconception de services numériques a été publié le 17 mai 2024 par l’Arcep et l’Arcom, avec l’ADEME et la DINUM (la CNIL et l’Inria ont contribué aux travaux). Il découle de l’article 25 de la loi REEN du 15 novembre 2021, qui prévoyait la création d’un référentiel de conception durable des services numériques.

Ce n’est pas un texte parti de zéro : une première version issue de la mission interministérielle Numérique écoresponsable circulait déjà, et le référentiel 2024 en est la refonte élargie. Il ne parle plus seulement de sites web, mais de services numériques au sens large : applications, API, logiciels métier, services intégrant de l’intelligence artificielle.

• Version — 2024, publiée le 17 mai 2024.
• Auteurs — l’Arcep et l’Arcom, avec l’ADEME et la DINUM.
• Base légale — article 25 de la loi REEN n° 2021-1485 du 15 novembre 2021.
• Volume — 78 critères répartis en 9 familles.
• Chaque critère porte un niveau de priorité, une difficulté de mise en œuvre, et des moyens de test : le référentiel est auditable, pas seulement déclaratif.
• Souplesse — un critère peut être déclaré non applicable, à condition de le justifier.
• Livrable attendu — une déclaration d’écoconception publique, mise à jour à chaque changement significatif du service.

L’esprit du référentiel tient dans son point de départ. La première famille, Stratégie, ne parle pas de code : elle demande si le service est utile, quelles fonctionnalités sont réellement employées, et ce qui est prévu pour sa fin de vie. L’écoconception commence par retirer, pas par optimiser.

Qui est concerné, et à quel titre

Trois situations à distinguer, parce qu’on les confond souvent.

Le secteur public

La loi REEN structure une obligation d’ensemble : depuis 2025, les communes et intercommunalités de plus de 50 000 habitants doivent élaborer une stratégie numérique responsable, et l’État comme ses opérateurs sont engagés dans la même trajectoire. Le RGESN est l’outil de référence pour la matérialiser côté services numériques, et la déclaration d’écoconception en est la preuve publique. En pratique, collectivités et établissements publics publient désormais ces déclarations sur leurs sites, exactement comme leur déclaration d’accessibilité RGAA.

Un point d’honnêteté. À ce jour, le RGESN n’est pas assorti d’un régime de sanctions comme peut l’être le RGAA. Personne ne viendra vous mettre une amende parce qu’un critère est non conforme. Ce qui est en jeu est différent, et souvent plus contraignant : la cohérence avec les engagements affichés, les exigences des acheteurs publics, et la crédibilité d’une politique RSE.

Les entreprises privées

Aucune obligation directe, mais deux forces convergentes : les rapports extra-financiers (CSRD et ses standards ESRS) réclament des indicateurs sur l’empreinte numérique, et les grands comptes répercutent la demande sur leurs prestataires. Un référentiel public, gratuit, auditable et reconnu est le moyen le plus simple de documenter le sujet sans inventer sa propre méthode.

Les agences et les prestataires

Le RGESN est un cahier des charges tout prêt. Une bonne moitié des critères recouvre ce qu’un projet bien mené fait déjà : ne pas charger 400 ko de JavaScript pour une page de contact, servir des images à leur dimension d’affichage, ne pas empiler des extensions qui font trois fois le même travail. Le référentiel donne à ces choix un cadre nommé et opposable.

Les 9 familles de critères, traduites en langage de projet

L’ordre des familles n’est pas décoratif : il suit le déroulé d’un projet, de la décision de faire jusqu’à la machine qui héberge.

• Stratégie — pertinence du service, référent écoconception identifié, revue des fonctionnalités, fin de vie. La famille la plus inconfortable : elle interroge le périmètre, pas la technique.
• Spécifications — ce qui est écrit avant de produire : contraintes environnementales au cahier des charges, compatibilité avec des terminaux anciens, budget de performance, exigences transmises aux prestataires.
• Architecture — nombre de domaines et de services tiers appelés, pertinence des composants, mutualisation, protocoles. Chaque brique tierce est un coût réseau et une dépendance.
• UX / UI — longueur des parcours, absence de dark patterns, respect du choix de l’utilisateur (pas de lecture automatique, pas de défilement infini), interface utilisable sans matériel récent.
• Contenus — poids et format des médias, pertinence de la vidéo, alternatives textuelles, durée de vie et archivage. Les gains les plus immédiats, et la famille la plus dépendante des équipes éditoriales.
• Frontend — volume de HTML, CSS et JavaScript réellement utilisé, taille du DOM, chargement différé, polices, cache navigateur. Le terrain de jeu habituel des outils de mesure.
• Backend — requêtes en base, cache serveur, journaux, traitements planifiés, données conservées sans usage. Un site lent côté serveur consomme deux fois : sur la machine, et dans l’attente de l’utilisateur.
• Hébergement — localisation, efficacité énergétique du centre de données, taux d’utilisation des ressources, engagements de l’hébergeur, durée de vie du matériel. Souvent hors de portée directe d’une agence : d’où l’importance de savoir quoi demander.
• Algorithmie — complexité des traitements, sobriété des modèles, entraînement et inférence. La famille qui a le plus de raisons de grossir dans les prochaines versions.

La déclaration d’écoconception, seul livrable qui engage

C’est le point que la plupart des projets découvrent en dernier, alors que c’est lui qui compte.

Se prévaloir du RGESN suppose de publier une déclaration d’écoconception : un document public qui atteste que le service a fait l’objet d’une évaluation, et qui en expose les résultats. Le référentiel demande aussi une auto-évaluation régulière, mise à jour au moins à chaque changement significatif du service. Un score d’avancement peut être calculé, mais il n’a de valeur qu’accompagné d’une déclaration détaillée : un pourcentage seul ne dit rien.

Concrètement, une déclaration exploitable contient :

• le nom du service et son périmètre exact : quels sites, quels sous-domaines, quelles applications ;
• la version du référentiel utilisée et la date de l’évaluation ;
• le résultat critère par critère — conforme, non conforme, non applicable — avec la justification des non-applicables ;
• les indicateurs mesurés et la méthode employée ;
• le plan d’amélioration, daté ;
• un contact pour signaler un manquement.

C’est exactement la logique de la déclaration d’accessibilité RGAA, et c’est une bonne nouvelle : les organisations qui ont déjà fait cet exercice savent à quoi s’attendre.

Un point de vigilance : une déclaration est un document public. Elle sera lue, y compris par des gens qui vérifient. Mieux vaut annoncer 34 critères conformes et un plan crédible que 70 critères conformes indéfendables.

Ce que le RGESN n’est pas

• Ce n’est pas un label. Aucune certification, aucun organisme qui tamponne. On s’auto-évalue et on publie.
• Ce n’est pas un score. L’EcoIndex donne une note de A à G, le RGESN non. Les deux outils sont complémentaires : l’un mesure une page, l’autre évalue une démarche.
• Ce n’est pas le RGAA. Les deux référentiels se croisent beaucoup — structure du HTML, sobriété des interfaces, contenus alternatifs — mais l’accessibilité a ses obligations et son régime propres.
• Ce n’est pas un argument marketing. Le référentiel est public et testable. Une conformité annoncée sans déclaration ni mesure se démonte en dix minutes avec un navigateur.

Comment nous intervenons

Notre approche est la même que sur l’accessibilité : nous ne vendons pas une conformité, nous installons une méthode. Voici comment se déroule un accompagnement.

1. Cadrage : regarder le périmètre avant le code

Un atelier avec les personnes qui décident et celles qui alimentent le site. On y traite les critères de la famille Stratégie, les moins techniques et les plus structurants :

• quelle est l’unité fonctionnelle du service — ce qu’il sert vraiment à faire ;
• quelles fonctionnalités sont utilisées, et lesquelles ne le sont plus (les statistiques d’usage tranchent mieux que les opinions) ;
• qui est le référent écoconception côté client, parce qu’un référentiel sans porteur interne meurt à la livraison ;
• ce qui est prévu pour les contenus obsolètes et pour la fin de vie du service.

C’est la séance où l’on décide de supprimer des pages, pas d’en optimiser.

2. Auto-évaluation des 78 critères

Nous passons le référentiel intégralement : l’extension NumEcoDiag de l’ADEME pour les critères automatisables, une revue manuelle pour le reste — l’outil ne juge ni la stratégie, ni les contenus, ni l’hébergement. Le livrable est une grille par critère : statut, priorité, difficulté, action proposée, responsable. Les non-applicables sont justifiés dès cette étape, pas au moment de rédiger la déclaration.

3. Mesure de l’état initial

Avant de toucher à quoi que ce soit, on fixe un point de départ mesurable : EcoIndex sur un échantillon représentatif de pages (accueil, page de contenu, formulaire, résultats de recherche), poids et nombre de requêtes, taille du DOM, Core Web Vitals sur données réelles. Sans cette photo, aucune amélioration n’est démontrable — et une déclaration sans chiffres avant/après ne vaut pas grand-chose.

4. Chantiers techniques

Le gros du travail, priorisé par le rapport gain/effort issu de l’étape 2. Sur un site WordPress, cela tourne presque toujours autour de :

• les médias — conversion en WebP ou AVIF, dimensions réelles d’affichage, attributs de largeur et de hauteur posés, chargement différé maîtrisé, vidéos jamais en lecture automatique ;
• le thème — un thème sur mesure plutôt qu’un empilement de page builder : nous livrons du HTML que nous maîtrisons, sans les kilo-octets de CSS et de JavaScript qu’un constructeur visuel embarque pour des blocs que le site n’utilise pas ;
• les scripts tiers — inventaire des domaines appelés, suppression des traceurs redondants, polices auto-hébergées ;
• le cache et la diffusion — cache de pages, cache navigateur cohérent, minification, compression ;
• le backend — extensions désinstallées dont les tables et les tâches planifiées traînent encore, révisions et journaux qui gonflent la base, requêtes lentes ;
• l’hébergement — ce qu’on peut demander à l’hébergeur : localisation, engagements énergétiques, versions de PHP à jour, ressources correctement dimensionnées.

Nous intervenons aussi bien sur un site existant que dans le cadre d’une refonte. Sur l’existant, la première passe consiste souvent à retirer des choses installées par d’autres.

5. Design, contenus et accessibilité

Les critères UX/UI et Contenus ne se règlent pas en production : ils se règlent en maquette et dans la ligne éditoriale. Parcours raccourcis, pas de carrousel décoratif, interfaces qui restent utilisables sur un terminal de cinq ans, contrastes et navigation clavier traités en même temps que la sobriété. Les critères RGESN et RGAA se renforcent ici plutôt qu’ils ne s’opposent : voir notre article RGAA : par où commencer pour un site conforme.

Et parce que le poids d’un site dépend surtout de ce qu’on y publie ensuite, nous formons l’équipe éditoriale, avec des règles simples et vérifiables : poids maximum d’une image, quand une vidéo se justifie, quand une page doit être archivée.

6. Déclaration d’écoconception et gouvernance

Nous rédigeons la déclaration, nous la publions, nous la datons. Puis nous installons ce qui la maintient vivante : un budget de performance à ne pas dépasser, les indicateurs à surveiller, une revue à chaque évolution significative, une révision annuelle. Le référentiel demande une démarche continue, pas un audit ponctuel — c’est tout le sens de notre accompagnement dans la durée.

Ce que nous ne promettons pas

Nous ne promettons pas un score EcoIndex A sur toutes les pages : un site avec une cartographie interactive ou un catalogue en images ne l’atteindra pas, et prétendre le contraire nous ferait mentir. Nous ne promettons pas non plus « 78 critères conformes » : plusieurs dépendent de l’hébergeur et de choix internes au client. Ce que nous garantissons, c’est une évaluation honnête, une trajectoire chiffrée, et une déclaration qui tient debout si quelqu’un la vérifie. C’est la même exigence que celle décrite sur notre page RSE et numérique responsable.

Les chantiers qui paient le plus vite sur un site WordPress

Si vous voulez avancer avant même de lancer une démarche complète, voici l’ordre de rentabilité que nous constatons projet après projet.

• Les images. C’est presque toujours le premier poste de poids. Une seule image non redimensionnée peut peser plus lourd que tout le reste de la page.
• Les extensions fantômes. Désactivées ou supprimées, elles laissent des tables, des tâches planifiées et parfois des règles de réécriture actives. Le nettoyage est invisible pour le visiteur, très net côté serveur.
• Les scripts tiers. Chaque outil de mesure, chat, widget social ou pixel publicitaire ajoute des connexions et du JavaScript. La question n’est pas technique, elle est politique : qui a besoin de cette donnée ?
• Le cache. Un cache de pages mal configuré — ou neutralisé par un reliquat de configuration — fait travailler PHP et la base à chaque visite pour rien.
• Les contenus morts. Des centaines d’URL indexées qui ne servent plus, c’est du crawl, du stockage et de la dette. Les archiver est un geste d’écoconception autant que de référencement.

Aucun de ces cinq chantiers ne demande une refonte. Tous sont vérifiables avant/après.

RGESN et marchés publics

Nous répondons régulièrement à des consultations publiques, et la tendance est nette : l’écoconception passe du vœu pieux au critère noté. On voit apparaître, dans les CCTP et les règlements de consultation, des exigences de conformité RGESN, des demandes de déclaration d’écoconception, des scores EcoIndex plafonds, des budgets de performance contractuels.

Deux conséquences pratiques. Pour un acheteur : formuler l’exigence en s’appuyant sur les critères du référentiel et sur des indicateurs mesurables, plutôt que sur une clause générale d’« engagement environnemental » que tout le monde peut cocher. Pour un candidat : pouvoir présenter une méthode, des outils et des déclarations existantes, parce qu’une promesse d’écoconception sans livrable ne rapporte pas de points.

Par où commencer, concrètement

Trois gestes, faisables cette semaine. Ouvrez votre page d’accueil et regardez son poids et son nombre de requêtes dans les outils de développement de votre navigateur. Listez les extensions actives et demandez-vous, pour chacune, qui s’en sert. Cherchez si une déclaration d’écoconception existe quelque part sur votre site. Ces trois réponses vous diront à peu près où vous en êtes.

Pour la suite — l’auto-évaluation des 78 critères, la mesure d’impact, le plan de correction priorisé et la déclaration publique —, c’est notre métier : écrivez-nous pour en parler. On répond sous 48 h, sans jargon, avec un premier regard concret sur votre site.

Studio Cassette répond régulièrement à des consultations publiques : CROUS, Bpifrance, APF France handicap, France Assos Santé, UDAF 74, Saison Brésil-France 2025. Voici notre méthode, étape par étape — utile aux acheteurs publics qui veulent savoir ce qu’une agence fait réellement de leur DCE, comme aux confrères qui démarrent sur les marchés.

Étape zéro : décider de ne pas répondre

La première décision n’est pas « comment répondre » mais « faut-il répondre ». On lit le règlement de la consultation avant le reste : date limite, pièces exigées, critères de jugement et leur pondération. Puis le CCTP, en cherchant d’abord les lignes qui nous disqualifient.

On renonce quand le délai ne laisse pas la place à une recette d’accessibilité sérieuse, quand le périmètre sort de notre métier (application native, refonte d’un ERP, marché à dominante infogérance), ou quand l’estimation budgétaire rend le résultat intenable. Une réponse bâclée coûte plus cher qu’un renoncement assumé : elle occupe une semaine de travail et laisse une trace médiocre chez un acheteur qu’on retrouvera à la consultation suivante.

Lire le DCE dans le bon ordre

Le dossier de consultation des entreprises n’est pas un bloc : chaque pièce répond à une question différente, et il y a un ordre de lecture qui fait gagner du temps.

On surligne d’abord les critères de jugement. Ils disent noir sur blanc sur quoi l’offre sera notée — et donnent donc le plan du mémoire technique. Un mémoire organisé autrement oblige la commission à chercher les réponses : c’est toujours du point perdu.

Poser des questions pendant la consultation

Peu de candidats le font, alors que le règlement de la consultation prévoit presque toujours une fenêtre de questions sur le profil acheteur. Les réponses sont diffusées à tous les candidats : c’est le prix à payer, mais une hypothèse fausse coûte plus cher qu’une question partagée.

On pose celles qui changent le chiffrage : qui fournit et reprend les contenus, quelle est la volumétrie réelle à migrer, l’audit d’accessibilité est-il dans le périmètre ou à la charge de l’acheteur, l’hébergement est-il imposé, la maintenance est-elle incluse et sur quelle durée. Le reste, on l’assume comme hypothèse — écrite comme telle dans le mémoire.

Le mémoire technique : répondre au CCTP, pas dérouler sa plaquette

C’est la pièce qui fait la différence, et celle qu’on voit le plus souvent ratée. Notre trame :

• Un plan calé sur les critères pondérés, dans leur ordre, avec les mêmes intitulés que le règlement de la consultation.
• Un tableau de conformité au CCTP, exigence par exigence : conforme, conforme avec réserve, hors périmètre. Les réserves assumées rassurent plus qu’un « conforme » systématique.
• Des preuves plutôt que des adjectifs : références comparables, extraits de livrables réels, noms des intervenants et leur rôle effectif sur le projet — pas un organigramme d’agence.
• Un planning tenable, avec les jalons de validation, la phase de recette et le temps de relecture côté client, qui est toujours sous-estimé.
• Ce qu’on n’écrit pas : un score parfait, un « site 100 % accessible », une conformité définitive. Ce sont des affirmations invérifiables — et elles deviennent contractuelles.

Un mémoire technique n’est pas un document commercial : c’est la démonstration qu’on a lu le CCTP.

Un mot sur le copier-coller : il se voit. Un mémoire recyclé garde toujours quelque part le nom de l’ancien client, un périmètre qui ne correspond pas, une technologie qui n’est pas celle demandée. On réutilise nos briques méthodologiques, mais l’architecture du document est refaite à chaque consultation.

Accessibilité : le sujet qui départage vraiment

Pour un site public, l’accessibilité n’est pas une option de confort : c’est une obligation légale, issue de l’article 47 de la loi de 2005, déclinée par le RGAA. Beaucoup d’offres la traitent en une ligne. C’est dommage, parce que c’est souvent là que la commission cherche à trancher entre deux candidats à prix comparable.

Ce que nous engageons : l’accessibilité traitée dès la conception (contrastes, structure de titres, parcours clavier, focus visible) plutôt qu’en rattrapage, une recette dédiée avant mise en ligne, la déclaration d’accessibilité et le schéma pluriannuel, et surtout la formation des contributeurs. Ce dernier point est le plus négligé : un site conforme se dégrade dès le premier PDF non balisé ou la première image sans alternative textuelle publiée par une équipe qu’on n’a pas outillée. La conformité est un état, à une date, sur un périmètre — pas un label acquis une fois pour toutes.

Nous détaillons cette partie sur notre page audit d’accessibilité RGAA.

RGPD, hébergement, réversibilité

Trois exigences qui reviennent dans presque tous les CCTP, et trois réponses concrètes attendues :

• Données personnelles : gestion du consentement, minimisation des données collectées par les formulaires, liste des sous-traitants et de leur rôle, mentions légales et politique de confidentialité livrées avec le site.
• Hébergement : localisation en France, sauvegardes quotidiennes, restauration testée, supervision et pare-feu applicatif. Un plan de reprise qu’on a réellement déclenché au moins une fois vaut mieux qu’un paragraphe théorique.
• Réversibilité : c’est la clause qu’on lit le plus vite et qui engage le plus. Nous livrons une base de données exportable, les médias, un thème documenté et du code standard WordPress. Concrètement : pas de site prisonnier d’une extension propriétaire ou d’un constructeur de pages — ce qui rejoint le parti pris expliqué dans pourquoi nous évitons les page builders lourds.

S’ajoute depuis peu le référentiel général d’écoconception des services numériques (RGESN), de plus en plus souvent cité dans les CCTP. Nous y répondons par des engagements mesurables sur le projet — sobriété du code, poids des pages et des médias suivis, pas de dépendance inutile — et non par une note globale promise à l’avance. Notre démarche de numérique responsable détaille ce cadre.

Le chiffrage : cohérent avec le mémoire, sur toute la durée du marché

Règle de base : on remplit la DPGF telle qu’elle est fournie. En modifier la structure, fusionner des lignes ou ajouter une prestation non prévue expose l’offre à être jugée irrégulière — perdre un marché sur un tableur mal rempli est une façon absurde de perdre.

Ensuite, on sépare clairement les postes : cadrage et conception, maquettes, développement, accessibilité et recette, reprise des contenus, formation, puis maintenance. Le critère prix porte presque toujours sur le coût global du marché, reconductions comprises : une maintenance sous-évaluée gonfle le score initial et se paie ensuite en avenants ou en qualité de service. Nous chiffrons donc la durée entière, années optionnelles incluses, et nous l’écrivons.

Le dépôt : là où l’on perd des marchés bêtement

La remise est dématérialisée, sur le profil acheteur indiqué par le règlement de la consultation. Quelques précautions qui n’ont rien d’intellectuel, mais qui sauvent des dossiers :

• Créer le compte sur la plateforme dès le début de la consultation, pas la veille du dépôt.
• Préparer les pièces de candidature en avance : DUME ou DC1/DC2, attestations fiscales et sociales, attestation d’assurance, RIB, références.
• Vérifier si la signature électronique est exigée, et sur quel document exactement.
• Déposer 24 à 48 heures avant l’échéance. L’horodatage de la plateforme fait foi : une offre arrivée après l’heure limite est écartée, quel qu’en soit le contenu et quelle qu’en soit la raison.
• Contrôler les formats et le poids des fichiers, puis relire le dossier tel qu’il apparaît sur la plateforme — pas celui qui est resté sur le disque dur.

Après le dépôt : audition, attribution, ou refus utile

En procédure adaptée, une phase de négociation ou d’audition est fréquente. On s’y prépare comme à une soutenance : les intervenants annoncés dans le mémoire sont ceux qui viennent, et les questions portent presque toujours sur les points où nous avons posé une réserve. C’est une bonne nouvelle : elles se préparent.

En cas de rejet, l’acheteur doit notifier les motifs, et communiquer sur demande les caractéristiques et avantages de l’offre retenue ainsi que les notes obtenues. Nous le demandons systématiquement : c’est le retour d’expérience le plus précis, le plus honnête et le moins cher qui existe sur notre façon de répondre.

En cas d’attribution, le mémoire technique devient une pièce contractuelle. Tout ce qui y est écrit doit être tenu, avec les moyens annoncés et dans les délais annoncés. C’est la raison de fond pour laquelle nous n’y écrivons rien que nous ne sachions faire.

Nos trois règles

• Ne répondre que si nous pouvons tenir — sur le délai, le périmètre et le prix.
• N’écrire que ce qui est vérifiable — une réserve assumée pèse plus lourd qu’une promesse ronde.
• Chiffrer la durée entière du marché, pas seulement la mise en ligne.

Une consultation en cours ?

Nous accompagnons institutions, collectivités et établissements publics de la réponse à l’appel d’offres jusqu’à la maintenance du site. Si vous préparez une candidature, notre page marchés publics résume nos livrables et nos références ; si vous êtes acheteur et que la rédaction du CCTP est encore ouverte, nous intervenons aussi en amont, en assistance à maîtrise d’ouvrage.

Dans tous les cas, transmettez-nous votre cahier des charges via notre page contact : vous aurez une réponse sous 48 heures, avec un premier avis concret sur la faisabilité — et, le cas échéant, un « non » argumenté.

C’est une situation que nous reprenons régulièrement. Voici notre méthode, dans l’ordre où nous l’appliquons. Précision utile : plusieurs des exemples qui suivent viennent de notre propre migration d’hébergeur, en août 2026. On ne se prétend pas au-dessus du problème.

Jour 1 : ne rien mettre à jour

Le premier réflexe, face à un site en retard, consiste à cliquer sur « Tout mettre à jour ». C’est aussi la façon la plus rapide de casser un site qu’on ne connaît pas encore, et de le casser sans pouvoir revenir en arrière.

L’ordre est donc : récupérer les accès (hébergement, base de données, DNS, registrar, comptes administrateurs), faire une sauvegarde complète — fichiers et base — stockée ailleurs que sur le serveur, puis tester la restauration. Une sauvegarde qu’on n’a jamais restaurée est une hypothèse, pas une sauvegarde. Ensuite seulement, on monte une copie de travail pour y faire les essais.

Inventaire : de quoi ce site est-il fait ?

On relève les versions (WordPress, PHP, base de données), le thème et surtout la façon dont il a été modifié : thème enfant propre, ou fichiers du thème parent édités directement — auquel cas la prochaine mise à jour effacera le travail. Puis les extensions actives, les extensions désactivées mais toujours présentes, et les tâches planifiées.

Le point aveugle, ce sont les mu-plugins : ces fichiers déposés dans wp-content/mu-plugins/ se chargent d’office et n’apparaissent pas dans la liste habituelle des extensions. Sur notre propre site, la reprise a mis au jour deux mu-plugins laissés par l’ancien hébergeur, dont l’un désactivait les mises à jour automatiques et redirigeait les appels à wordpress.org vers son propre miroir. Vu du tableau de bord, tout semblait normal.

Même chose pour le code mort qui traîne à côté de WordPress : règles de réécriture dans le .htaccess laissées par une extension supprimée, fichiers drop-in orphelins, constantes inutiles dans wp-config.php. Ce n’est pas de la poussière décorative : chez nous, une règle de réécriture abandonnée par un ancien plugin de cache empêchait purement et simplement le cache en place de fonctionner.

Sécurité : avant tout le reste

Un site abandonné a presque toujours un problème de comptes. On liste les utilisateurs, on cherche les comptes administrateurs dormants — anciens prestataires, stagiaires, « admin » créé à l’installation et jamais retiré — et on vérifie si le site publie lui-même la liste de ses auteurs, ce que WordPress fait par défaut via son API.

• Réinitialiser les accès : mots de passe des comptes conservés, identifiants FTP et base de données, clés de salage de wp-config.php (ce qui déconnecte toutes les sessions actives, y compris celles qu’on ne connaît pas).
• Supprimer, pas désactiver, les comptes qui n’ont plus de raison d’être — et rétrograder ceux qui n’ont pas besoin du rôle administrateur.
• Chercher les traces d’injection dans les répertoires qui ne devraient contenir que des médias, et vérifier les droits sur les fichiers.
• Activer la double authentification sur les comptes restants.

Si le site est déjà compromis, le raisonnement change : on ne nettoie pas une infection à la main sur la production. On isole, on repart d’une base saine, et on remonte les contenus.

Les extensions : moins, pas plus

Une extension désactivée n’est pas neutralisée : son code reste sur le disque, et certaines vulnérabilités connues sont exploitables sans que l’extension soit active. Un gestionnaire de fichiers laissé « au cas où » dans un coin du site est une porte, pas un outil.

À l’inverse, désinstaller ne suffit pas toujours à faire le ménage : la plupart des extensions ne nettoient rien en partant. Dans notre base, nous avons retrouvé six tables appartenant à des extensions disparues, une file de tâches planifiées contenant plus de huit cents actions en échec pour un plugin qui n’existait plus, et un journal de tâches de près de 281 000 lignes. Rien de dramatique, mais ce sont des requêtes, de la sauvegarde et du temps de migration pour rien.

Notre règle de tri : chaque extension doit avoir une raison d’être identifiable, un éditeur qui la maintient encore, et une alternative connue si elle s’arrête. Les autres partent.

Mettre à jour : dans l’ordre, avec un point de retour

Sur la copie de travail, on avance par étapes séparées, en vérifiant le site entre chacune : le cœur de WordPress, puis les extensions une par une pour celles qui touchent au contenu ou aux formulaires, puis le thème, puis la version de PHP. Grouper les mises à jour fait gagner dix minutes et coûte une demi-journée de diagnostic quand quelque chose casse.

Une mise à jour qu’on ne peut pas annuler n’est pas une mise à jour : c’est un pari.

Si une extension bloque la montée de version de PHP, la vraie question n’est pas « comment la garder » mais « par quoi la remplacer ». Un site qui reste sur une version de PHP obsolète n’est pas seulement lent : il est privé des correctifs de sécurité du langage lui-même.

Le SEO : ce qui casse sans qu’on le voie

Une reprise est aussi le bon moment pour vérifier ce que le site raconte aux moteurs, parce que c’est le genre de dégât silencieux : pages de test restées publiques et indexées, balises title et méta descriptions manquantes, redirections en chaîne qui font deux ou trois sauts, sitemap qui annonce des URL redirigées, robots.txt qui interdit ou expose ce qu’il ne faut pas.

On croise le sitemap avec les URL réellement servies, on regarde les erreurs remontées par la Search Console, et on corrige avant de toucher au contenu. C’est la partie détaillée dans notre page référencement naturel.

Performance : chercher la cause, pas le plugin

Le réflexe habituel — installer une extension d’optimisation de plus — arrive presque toujours trop tôt. L’ordre utile est : temps de réponse du serveur, cache de page, poids des médias, puis CSS et JavaScript.

Deux exemples pris chez nous. Une fois la règle de réécriture morte retirée du .htaccess, le cache de page a recommencé à servir : le temps de réponse est passé d’environ 0,55 s à 0,1 s, sans installer quoi que ce soit. Et à l’inverse, un lazy-load mal réglé imposait une largeur de remplacement de 500 px à chaque logo d’une bande d’images : la mise en page sautait au chargement. Une extension d’optimisation mal configurée dégrade l’expérience qu’elle prétend améliorer.

Documenter, puis rendre les clés

La reprise se termine par un document court et à jour : où est hébergé le site, qui gère le nom de domaine, quels sont les accès et qui les détient, à quoi sert chaque extension conservée, où sont les sauvegardes et à quelle fréquence, comment se déroule une mise à jour, qui appeler en cas d’incident. Plus une formation de la personne qui édite le site au quotidien.

Un site repris mais non documenté est un site qui sera abandonné une deuxième fois. C’est la seule partie du travail qui empêche le problème de revenir.

Ce que nous refusons de faire

• Mettre à jour sans sauvegarde restaurable et testée.
• Désinfecter un site compromis directement en production.
• Conserver une extension abandonnée par son éditeur parce qu’elle « marche encore ».
• Proposer une refonte quand une remise à niveau suffit — et l’inverse : rafistoler un site dont la dette technique coûte désormais plus cher que sa reconstruction.

Un site à reprendre ?

Nous commençons toujours par un audit : inventaire, sécurité, performance, SEO, et un plan chiffré qui distingue ce qui est urgent de ce qui peut attendre. Ce que couvre ensuite la maintenance WordPress : mises à jour surveillées, sauvegardes, supervision de sécurité et un interlocuteur qui connaît le site.

Si vous avez hérité d’un site dont personne ne sait plus quoi faire, écrivez-nous via la page contact : réponse sous 48 heures, avec un premier avis honnête — y compris quand la bonne réponse est de ne pas tout refaire.

Sauf que l’espace blanc n’est pas de l’espace inoccupé : c’est de l’espace qui travaille. Il porte la hiérarchie, il rend le texte lisible, il évite les erreurs de clic. Voici ce qu’il fait exactement, et comment nous en décidons — parce que ce n’est pas une affaire de goût.

L’espace est la première chose qu’on lit

Avant de lire un mot, l’œil regroupe : ce qui est proche est perçu comme lié, ce qui est éloigné comme distinct. Ce mécanisme est plus rapide que la lecture, et il est plus fort que les mots eux-mêmes. Un intertitre collé au paragraphe qui le précède plutôt qu’à celui qu’il annonce est donc une erreur d’information, pas un détail esthétique : la page dit le contraire de ce que le texte raconte.

C’est pour cette raison que l’espacement est notre premier outil de hiérarchie, avant la taille des caractères et bien avant la couleur. Augmenter un titre de deux points est un pansement ; l’isoler correctement change la compréhension de la page.

Macro et micro : deux échelles, deux effets

Le macro-espacement — marges, gouttières, distance entre les sections — donne le rythme et dit où commence et où finit une idée. C’est lui qui permet de parcourir une page sans la lire, ce que fait tout visiteur pendant les premières secondes.

Le micro-espacement — interlignage, espace entre une étiquette et son champ, marge intérieure d’un bouton, espace avant un signe de ponctuation — décide du confort. Il ne se voit pas. Il se ressent sous forme de fatigue, ou d’absence de fatigue, au bout de trois paragraphes.

Le réglage le plus rentable : la longueur de ligne

Un texte courant se lit confortablement entre 45 et 75 caractères par ligne, espaces comprises. Au-delà, l’œil perd son point de retour à la fin de la ligne et doit chercher la suivante ; en dessous, la lecture est hachée. C’est la raison pour laquelle un article n’occupe jamais toute la largeur d’un grand écran : ce n’est pas de la place perdue, c’est une colonne de lecture.

Le corollaire vaut pour l’interlignage : environ une fois et demie la taille du texte pour un paragraphe, nettement moins pour un grand titre, dont les lignes seraient sinon perçues comme des blocs séparés. Ces deux réglages n’ajoutent aucun contenu et améliorent la lisibilité plus sûrement que n’importe quel choix de police.

« Ça fait vide » : deux façons de regarder la même page

Il y a une asymétrie intéressante dans la manière dont une maquette est vue. Le commanditaire la découvre en grand, quelques secondes, souvent à côté d’une autre proposition, avec la question « en ai-je pour mon argent ? » en tête. Le visiteur, lui, verra une page à la fois, souvent sur un téléphone, avec une intention précise et deux minutes d’attention.

Ces deux regards ne récompensent pas les mêmes choses. Le premier valorise la densité, parce qu’elle donne l’impression de valeur. Le second ne demande qu’une chose : comprendre où il est arrivé et quoi faire ensuite. Six messages entassés dans le premier écran, c’est zéro message transmis.

Cela dit, l’objection est parfois juste, et il faut savoir l’entendre. Une zone calme qui ne sépare rien, un bloc qui flotte sans ancrage, une page qui respire parce qu’elle n’a rien à dire : ce n’est pas de l’espace blanc, c’est un défaut. Dans le dernier cas, le problème à traiter est le contenu manquant, pas la mise en page.

L’espace ne se remplit pas : il se justifie. S’il ne sert ni la hiérarchie ni la lisibilité, alors oui, il est perdu — c’est le seul cas.

La densité juste dépend de la tâche

Il n’existe pas de bonne densité universelle, et c’est ce qui rend le sujet intéressant. Une interface de comparaison — tableau de bord, liste de résultats, grille tarifaire — doit être dense : le visiteur balaye, compare, revient en arrière, et chaque espace superflu l’oblige à scroller pour tenir deux informations ensemble dans son champ de vision.

Une page qui doit faire comprendre une idée, à l’inverse, gagne à n’en présenter qu’une par écran. La bonne question n’est donc jamais « est-ce trop vide ? » mais « que fait le visiteur ici : il compare, ou il comprend ? ».

L’accessibilité s’invite dans la conversation

• L’espace doit être extensible. Les règles d’accessibilité prévoient qu’un visiteur puisse augmenter l’interlignage et l’espacement des mots sans que le contenu soit tronqué ou chevauché. Une mise en page calculée au pixel près, où chaque bloc touche le suivant, casse dès qu’on augmente l’espacement — donc elle exclut.
• Les zones cliquables ont besoin d’air. Deux liens collés l’un à l’autre, c’est une erreur de clic garantie pour qui a un tremblement, un doigt gourd ou un téléphone dans une main dans le métro. L’espace, ici, n’est pas du confort : c’est de la fiabilité.
• Les groupes visuels aident la navigation non visuelle. Une page dont les sections sont clairement séparées est en général une page correctement structurée dans le code — et donc parcourable au clavier et au lecteur d’écran.

Nous détaillons ce volet dans notre page audit d’accessibilité RGAA.

Une échelle, pas des valeurs improvisées

La différence entre un site qui paraît soigné et un site qui « sent le bricolage » sans qu’on sache dire pourquoi tient rarement au graphisme : elle tient à la cohérence des espacements. Vingt-deux pixels ici, dix-huit là, trente ailleurs, et le rythme disparaît.

Nous travaillons donc avec une échelle d’espacement — une suite de valeurs limitée, dérivée d’une unité de base — déclarée une fois dans le système de design et réutilisée partout. Le site que vous lisez fonctionne ainsi : les espacements viennent de variables, pas de décisions au cas par cas. Deux bénéfices concrets : le rythme est reproductible d’une page à l’autre, et un ajustement global se fait en une ligne au lieu de cent.

Sur mobile, l’espace ne disparaît pas : il se redistribue

Le réflexe, sur petit écran, consiste à tout resserrer. C’est à moitié vrai : les marges latérales se réduisent, la colonne de texte se rétrécit, la grille passe sur une colonne. Mais la séparation verticale entre les blocs, elle, doit être maintenue — voire renforcée. C’est le seul repère qui reste quand on ne voit plus qu’un tiers de la page à la fois.

Le défilement n’a jamais fait fuir personne : c’est le geste le plus naturel du web. Ce qui fait fuir, c’est de ne pas savoir où l’on en est.

Nos arbitrages, en pratique

• Une idée dominante par section, un seul appel à l’action principal.
• Toujours plus d’espace entre deux sections qu’à l’intérieur d’une section — sinon la page perd son plan.
• Jamais un titre à égale distance du paragraphe qu’il annonce et de celui qui le précède.
• Une colonne de lecture bornée, quelle que soit la taille de l’écran.
• Le test des yeux plissés : si la hiérarchie de la page reste lisible en flou, elle est bonne. Si tout se vaut, il manque de l’espace, pas du contenu.
• Une vérification systématique à 375 px et à 1 440 px, parce que la plupart des problèmes d’espacement n’existent qu’à l’une des deux extrémités.

Un projet où le contenu doit respirer ?

C’est le cœur de notre travail de design et de direction artistique, et cela se joue dès la conception du site : la hiérarchie se décide avant la première maquette. Nos réalisations donnent une idée du résultat.

Vous hésitez entre deux versions d’une page, l’une dense, l’autre aérée ? Envoyez-les-nous via la page contact : nous vous dirons ce que chacune fait comprendre en trois secondes — c’est le seul arbitrage qui compte.

Voici ce que ces indicateurs mesurent, ce que Google en fait, et l’ordre dans lequel nous les traitons sur un site WordPress. Sans promesse de score parfait : nous allons justement expliquer pourquoi c’est une mauvaise cible.

Trois métriques, trois seuils

L’INP a remplacé le FID en mars 2024, et c’est un durcissement : le FID ne mesurait que le délai avant la première réaction, l’INP regarde l’ensemble des interactions de la visite. Un site qui passait de justesse avec l’ancien indicateur peut échouer avec le nouveau, sans que rien n’ait changé dans le code.

Le chiffre qui compte n’est pas celui de votre rapport PageSpeed

C’est le malentendu principal. Le score sur 100 que renvoie Lighthouse est une mesure de laboratoire : une seule visite, simulée, sur une machine et une connexion théoriques. Il est utile pour diagnostiquer, il varie d’un test à l’autre, et ce n’est pas lui que Google utilise.

Les Core Web Vitals sont évalués sur des données de terrain : les visites réelles des utilisateurs de Chrome, agrégées sur 28 jours, et lues au 75^e centile. Autrement dit : trois visiteurs sur quatre doivent être sous le seuil. C’est une exigence différente d’un test unitaire réussi — un site rapide pour vous, en fibre sur un ordinateur récent, peut échouer parce que son public réel est en 4G sur un téléphone de trois ans.

Conséquence pratique : on diagnostique dans Lighthouse, mais on juge le résultat dans le rapport « Signaux web essentiels » de la Search Console, et avec quatre semaines de décalage. Une correction déployée aujourd’hui ne se lit pas demain.

LCP : une histoire de serveur, puis d’image

Dans la grande majorité des cas, un mauvais LCP se décompose en deux causes, dans cet ordre.

Le temps de réponse du serveur. Une page WordPress non mise en cache est reconstruite à chaque visite : PHP interroge la base, assemble, renvoie. Un cache de page bien réglé sert un fichier déjà prêt. Sur ce site, le simple fait de rendre le cache de page fonctionnel — il était neutralisé par une règle de réécriture laissée par une ancienne extension — a fait passer le temps de réponse d’environ 0,55 s à 0,1 s. Aucun plugin ajouté, une ligne retirée.

L’image de haut de page. C’est presque toujours l’élément LCP. Elle doit être dimensionnée pour son affichage réel, servie dans un format moderne, et surtout ne pas être différée : mettre en lazy-load l’image principale, c’est retarder volontairement la métrique qu’on essaie d’améliorer. Nous en avons fait l’expérience à nos dépens : un seul PNG exporté à 1,2 Mo suffit à faire dérailler le LCP d’une page par ailleurs bien construite.

INP : ce que fait votre JavaScript pendant qu’on vous clique

L’INP sanctionne le JavaScript qui monopolise le fil principal du navigateur. Le visiteur clique, le navigateur est occupé, l’interface répond en retard. Les responsables habituels sont connus : les constructeurs de pages et leur couche de scripts chargée sur chaque page, l’accumulation d’extensions qui ajoutent chacune leur bibliothèque, les carrousels, les scripts de suivi et les widgets tiers.

La bonne nouvelle : c’est la métrique où retirer du code paie le plus. La mauvaise : on ne retire pas facilement du code dont le site dépend, ce qui rejoint notre parti pris expliqué dans pourquoi nous évitons les page builders lourds. Un site construit léger n’a pas besoin d’être optimisé après coup.

CLS : le plus facile à corriger, le plus souvent négligé

Le CLS mesure les sauts de mise en page : ce moment où l’on s’apprête à cliquer et où le bouton se déplace. Les causes sont peu nombreuses et toutes réparables.

• Images et iframes sans dimensions : sans width et height, le navigateur ne réserve pas la place et tout se décale à l’arrivée du fichier.
• Polices web : un basculement de la police de secours vers la police finale change les hauteurs de texte. Cela se maîtrise avec le préchargement et une police de repli de métriques proches.
• Contenus injectés après coup : bandeau de cookies, alerte, publicité, bloc chargé en JavaScript — tout ce qui s’insère au-dessus du contenu déjà lu.
• Un lazy-load mal réglé, cas vécu ici : l’extension imposait une largeur de remplacement de 500 px à chaque logo d’une bande d’images. La bande occupait quatre fois sa largeur réelle, puis se repliait d’un coup. Le correctif n’était pas « plus d’optimisation », c’était d’exclure ces images du lazy-load et de déclarer leurs dimensions.

Ce que ça change vraiment pour le référencement

Soyons précis, parce que c’est là que le marketing déraille. L’expérience de la page est un signal parmi des centaines, et un signal faible : il ne fera pas remonter une page dont le contenu ne répond pas à la requête. Aucune optimisation technique ne compense un contenu qui n’a rien à dire.

Passer les seuils suffit. Courir après un score de 100 sur 100 coûte cher et ne rapporte rien.

En revanche, l’effet sur le comportement des visiteurs est direct, et il est mesurable dans vos propres statistiques : moins d’abandons au chargement, plus de pages vues, plus de formulaires terminés. C’est le vrai argument. Le référencement en bénéficie indirectement, parce que Google observe aussi ce que font les gens.

Notre ordre d’intervention

1. Mesurer sur le terrain, pas seulement en laboratoire : quelles URL échouent, sur mobile ou sur ordinateur, et pour quelle métrique.
2. Retirer avant d’ajouter : extensions inutiles, scripts tiers oubliés, règles mortes qui bloquent le cache.
3. Régler le temps de réponse : hébergement, cache de page, version de PHP.
4. Traiter les médias : dimensions réelles, formats modernes, dimensions déclarées, pas de lazy-load sur le premier écran.
5. Réduire et différer le JavaScript non essentiel, en vérifiant à chaque étape que rien n’est cassé.
6. Attendre. Les données de terrain se rafraîchissent sur 28 jours : juger trop vite conduit à empiler des correctifs inutiles.

Les faux amis

• Empiler les extensions d’optimisation. Deux caches qui se contredisent, c’est un site plus lent et un diagnostic impossible.
• Le score comme objectif. Un rapport vert obtenu en désactivant des fonctionnalités utiles n’est pas une amélioration, c’est un appauvrissement.
• Le « tout minifier, tout combiner » sans vérification : cela casse régulièrement des fonctionnalités, souvent sur une seule page qu’on ne teste pas.
• Optimiser une page à la fois alors que la cause est commune à tout le site : l’en-tête, les polices et les scripts globaux se corrigent une fois.

Un site à remettre dans le vert ?

Nous traitons la performance comme un sujet de construction, pas de rattrapage : c’est plus efficace et bien moins coûteux. Voir nos pages référencement naturel et maintenance WordPress, ou notre démarche de numérique responsable — la sobriété technique et la vitesse sont le même travail.

Un rapport rouge dans la Search Console et pas de piste claire ? Écrivez-nous via la page contact : nous regardons vos URL réelles et vous disons quelles causes traiter en premier — et lesquelles ne valent pas l’effort.

La bonne nouvelle, c’est qu’une petite partie du référentiel explique la grande majorité des blocages réels rencontrés par les internautes. Voici l’ordre dans lequel nous attaquons le sujet, et ce qu’il faut savoir avant de commencer.

D’abord : qui est concerné, et par quoi

En France, l’obligation d’accessibilité des sites vient de l’article 47 de la loi du 11 février 2005, précisé par le décret de 2019. Elle s’applique aux services de l’État, aux collectivités, aux établissements publics et aux organismes chargés d’une mission de service public — ainsi qu’aux entreprises privées dont le chiffre d’affaires dépasse un seuil élevé. Le non-respect des obligations de publication expose à une sanction administrative renouvelable, dont le plafond a été relevé en 2023.

À cela s’ajoute, depuis le 28 juin 2025, l’application de la directive européenne sur l’accessibilité (souvent appelée European Accessibility Act) à de nombreux services destinés aux consommateurs : commerce en ligne, banque, transport, livres numériques. Autrement dit : le sujet a cessé d’être une affaire de secteur public.

Le référentiel technique, lui, est le RGAA, qui est la déclinaison française des règles internationales WCAG 2.1 niveau AA. Travailler pour le RGAA, c’est travailler pour les WCAG : il n’y a pas deux chantiers.

Trois obligations documentaires, souvent oubliées

Beaucoup d’organisations travaillent leur site sans produire les documents attendus — alors que ce sont eux qui sont contrôlés en premier, parce qu’ils sont publics et immédiatement vérifiables :

• Une déclaration d’accessibilité, accessible depuis le site, qui annonce l’état réel : non conforme, partiellement conforme ou totalement conforme, avec le taux obtenu et la liste des contenus non conformes.
• Un schéma pluriannuel de mise en accessibilité, décliné en plans d’action annuels.
• La mention du niveau d’accessibilité sur la page d’accueil, avec un lien vers la déclaration.

Un point qui rassure souvent nos interlocuteurs : « partiellement conforme » est un état déclarable et parfaitement assumable. Annoncer honnêtement un taux et un plan d’action vaut infiniment mieux que se taire — ou que revendiquer une conformité totale invérifiable. Notre propre déclaration d’accessibilité suit cette logique.

Les cinq chantiers qui règlent le plus de problèmes

Si vous ne faites que cinq choses, faites celles-là. Elles couvrent l’essentiel des obstacles concrets, et elles sont à la portée d’une équipe qui n’est pas spécialiste.

1. Les contrastes. Texte courant contre son fond : rapport minimal de 4,5 pour 1, et 3 pour 1 pour les grands titres. C’est le critère le plus fréquemment en échec, et le seul qui se corrige entièrement dans la charte graphique — avant la première ligne de code. Attention aux gris clairs sur fond blanc, aux textes posés sur des photos et aux boutons dont l’état survolé perd du contraste.
2. Les alternatives textuelles. Chaque image porteuse d’information a besoin d’une alternative qui transmet cette information ; chaque image décorative a besoin d’une alternative vide, pour être ignorée. « Photo », « image1.jpg » ou le nom du fichier ne sont pas des alternatives.
3. La structure de titres. Un seul H1, puis une hiérarchie H2/H3 continue, sans niveau sauté et sans titre choisi pour sa taille. C’est le plan du document : c’est ainsi qu’un lecteur d’écran permet de parcourir une page, comme vous parcourez un sommaire.
4. Le clavier. Tout ce qui est cliquable doit être atteignable et actionnable à la touche Tab, dans un ordre logique, avec un focus visible. Le contour de focus supprimé en CSS parce qu’il « fait sale » est l’une des régressions les plus courantes — et l’une des plus handicapantes.
5. Les formulaires. Chaque champ a une étiquette visible et associée, les champs obligatoires sont annoncés autrement que par une couleur, et les messages d’erreur disent quoi corriger, à côté du champ concerné.

Le test de cinq minutes

Avant tout audit, il existe un test que n’importe qui peut faire : posez la souris et parcourez votre page d’accueil uniquement au clavier. Tab pour avancer, Entrée pour activer. Trois questions suffisent : est-ce que je vois toujours où je suis ? ; est-ce que je peux atteindre le menu, la recherche et le formulaire ? ; est-ce que je me retrouve piégé quelque part, typiquement dans une fenêtre modale ou un carrousel ?

Si la réponse est non à l’une des trois, vous connaissez déjà votre premier chantier — et il pèse plus lourd que la moitié du référentiel.

Les outils : utiles, mais partiels

Les extensions de navigateur d’analyse automatique et les rapports d’audit intégrés aux navigateurs font gagner du temps : ils repèrent les contrastes insuffisants, les alternatives manquantes, les erreurs de structure. Utilisez-les, ils sont gratuits.

Mais ils ne détectent qu’une partie des critères du RGAA. Tout ce qui relève du sens échappe à l’automatisation : une alternative textuelle peut être présente et inutile, un ordre de tabulation peut être valide et incompréhensible, un composant peut être techniquement correct et impraticable. Le reste se vérifie à la main, au clavier, et avec un lecteur d’écran.

Ce qu’il ne faut pas faire : installer une surcouche

On vous proposera un script à ajouter à votre site, avec un petit bouton flottant promettant la conformité en une ligne de code. Notre position est nette : ces surcouches ne rendent pas un site conforme. Elles n’ont aucun effet sur les critères du référentiel, qui portent sur le code de vos pages ; un audit RGAA les traverse sans les voir. Dans le meilleur des cas, elles ajoutent une préférence de contraste que le système d’exploitation du visiteur gère déjà mieux qu’elles.

L’accessibilité n’est pas une case à cocher en fin de projet : c’est une contrainte de conception, au même titre que le mobile.

Les angles morts : PDF, vidéos, composants riches

• Les documents PDF. Ils font partie du périmètre. Un rapport annuel exporté sans structure de titres ni ordre de lecture est un contenu inaccessible, même sur un site irréprochable. La question à trancher est souvent : ce document doit-il rester un PDF, ou devenir une page web ?
• Les vidéos. Sous-titres pour l’audio, et transcription pour ce qui est purement visuel. Les sous-titres automatiques sont un point de départ à relire, jamais un livrable.
• Les composants riches — carrousels, accordéons, onglets, fenêtres modales, menus déroulants. C’est là que se concentrent les échecs, et souvent à cause d’attributs ARIA ajoutés au hasard. Un composant sans ARIA mais utilisable au clavier vaut mieux qu’un composant couvert d’attributs qui mentent au lecteur d’écran.

La partie qu’on oublie toujours : les contributeurs

Un site livré conforme se dégrade au fil des publications. Le premier PDF non balisé, la première image sans alternative, le premier « cliquez ici », le premier titre choisi parce qu’il était à la bonne taille : la conformité s’érode par le contenu, pas par le code.

C’est pourquoi nous considérons la formation des personnes qui éditent le site comme une partie du chantier d’accessibilité, et pas comme une option de fin de projet. Une demi-journée et une fiche de rappel de dix lignes suffisent à changer durablement la trajectoire.

Par où commencer, concrètement

1. Faire le test au clavier sur trois pages clés : accueil, page de contenu, formulaire.
2. Corriger les contrastes dans la charte, une fois pour tout le site.
3. Reprendre la structure de titres et les alternatives des gabarits, puis des pages les plus consultées.
4. Rendre le focus visible et vérifier les composants interactifs.
5. Faire auditer un échantillon de pages représentatif, puis publier la déclaration d’accessibilité avec le taux réel.
6. Écrire le schéma pluriannuel : ce qui est corrigé, ce qui est planifié, quand.
7. Former les contributeurs, et intégrer la vérification d’accessibilité à la recette de chaque évolution.

Cet ordre a une logique : il commence par ce qui coûte le moins et bénéficie au plus grand nombre, et il évite le piège classique du projet d’accessibilité — vouloir tout traiter d’un coup, et ne rien livrer.

Besoin d’un point de départ ?

Nous réalisons des audits d’accessibilité RGAA avec un rapport priorisé, la déclaration à publier, et l’accompagnement des équipes. Pour les organisations publiques, l’accessibilité est traitée dès la réponse à la consultation : voir nos pages marchés publics et notre article sur notre méthode de réponse aux appels d’offres.

Un doute sur l’état de votre site ? Écrivez-nous via la page contact : nous regardons quelques pages et vous disons où vous en êtes, sans vendre un audit complet à qui n’en a pas encore besoin.

Chez Studio Cassette, on a fait un choix clair : construire propre, avec l’éditeur natif de WordPress. Voici le raisonnement, sans jargon.

Le poids, ennemi de la performance

Un page builder charge sa propre couche de CSS et de JavaScript sur chaque page — souvent plusieurs centaines de kilo-octets. Résultat : des temps de chargement allongés, des Core Web Vitals dans le rouge, et une expérience dégradée sur mobile.

Un site rapide n’est pas un luxe : c’est la première condition pour être lu, et pour être référencé.

Mises à jour et dette technique

Un site monté sur un builder dépend entièrement de cette extension. Le jour où le builder casse la compatibilité avec une mise à jour de WordPress, c’est tout votre site qui vacille.

Notre alternative : Gutenberg, proprement

L’éditeur de blocs natif de WordPress a énormément mûri. Couplé à un thème léger et à quelques blocs sur-mesure, il permet de tout faire — sans la surcharge d’un builder tiers.

Ce qu’on en retient

Un page builder peut dépanner, mais il a un coût caché : performance, autonomie et longévité. Pour un site professionnel, on préfère investir un peu plus de soin au départ pour livrer une base saine.