Checklist qualité WordPress : que demander à votre agence

La qualité d'un site WordPress se lit avant même qu'on ouvre le code. Les signes se trouve dans le rendu de la page, dans le rapport de vitesse, dans la liste des extensions, et dans la manière dont l'agence parle de son propre travail. WordPress fait tourner aujourd'hui près de 42 % des sites web et 60 % de ceux qui s'appuient sur un CMS identifié, selon W3Techs. C'est précisément cette popularité qui explique des écarts de qualité aussi spectaculaires : la même plateforme abrite des sites menés avec une vraie rigueur d'ingénierie et des sites assemblés à coups de thème commercial, de page builder lourd et d'une trentaine d'extensions. Pour faire la différence, nul besoin d'être développeur. Un audit court et structuré suffit, mené à trois moments où vous avez encore voix au chapitre, et chaque étape se fait depuis un simple navigateur.

Ce guide est cet audit. Il s'articule autour des trois moments où un acheteur non-technique peut agir : examiner soi-même un site déjà en ligne, poser les bonnes questions avant la signature, exiger des preuves concrètes à la recette. La méthode vaut pour n'importe quelle agence WordPress, Keroberos comprise.

Pourquoi tant de sites WordPress déçoivent

Quand un site WordPress déçoit, WordPress n'y est presque jamais pour rien. La cause tient presque toujours à trois choix qui se sont superposés en cours de route, et chacun reste visible sur le site fini. D'abord, un thème acheté servant de socle, complété par un page builder lourd censé combler ses limites. Ensuite, un parc d'extensions qui a enflé chaque fois qu'un besoin sans solution évidente s'est présenté : on installe une extension de plus, et on passe au suivant. Enfin, une mise en ligne où le durcissement de sécurité, le travail de performance et l'audit d'accessibilité ont été remis à plus tard, autrement dit à jamais.

Aucun de ces choix n'est dramatique pris isolément. Cumulés, ils produisent un site lent, fragile et coûteux à maintenir. Le risque de sécurité, lui, est mesurable. Le livre blanc Patchstack 2026 sur l'état de la sécurité WordPress a recensé 11 334 nouvelles vulnérabilités dans l'écosystème WordPress en 2025, soit 42 % de plus qu'en 2024. 91 % de ces failles concernent les extensions, 9 % les thèmes, et 6 seulement le cœur de WordPress. Plus préoccupant encore : 46 % n'avaient pas de correctif au moment de leur publication, ce qui revient à dire que l'écart entre la divulgation et la correction n'avait pas de borne. Choisir ses extensions, sur un site WordPress, c'est prendre une décision de sécurité déguisée en décision fonctionnelle. Quand un site WordPress mal construit cède, ce n'est pas la plateforme qui est en cause, mais une surface d'attaque que personne n'a tenue à jour.

L'audit en trois temps

Sur un projet WordPress, vous disposez de trois moments distincts pour peser sur la qualité, et chacun demande un type de preuve différent. L'ordre compte : les questions posées à la signature ne portent que si vous savez d'abord quoi observer sur un site déjà livré, et les preuves exigées à la recette ne pèsent que si la conversation de cadrage a posé l'attente qu'elles seraient demandées.

Étape 1 : examiner le site en ligne par soi-même

Un acheteur non-technique peut mener cet audit sur n'importe quel site WordPress en ligne en une quinzaine de minutes, avec un navigateur, la vue du code source, et Google PageSpeed Insights. Il marche aussi bien sur le site d'un concurrent dont vous voulez comprendre les choix, sur un site présenté dans le portfolio d'une agence, sur un site hérité que vous découvrez, ou comme dernière vérification avant d'accepter la mise en ligne de votre propre projet.

• Soupe de div d'un page builder dans le HTML. Clic droit sur la page, « Afficher le code source ». Cherchez les préfixes de classes elementor-, vc_ ou et_pb_. Une forte présence indique qu'un page builder gère la mise en page. Selon le chapitre CMS du Web Almanac 2025, Elementor reste le builder le plus répandu, à environ 43 % des sites WordPress équipés d'un builder, en recul par rapport aux 56 % de 2024. WPBakery est tombé à 13 %, Divi à 10 %, et l'éditeur de blocs natif de WordPress a grimpé à environ 18 %. La tendance est nette : les configurations « thème commercial plus page builder » cèdent du terrain face aux thèmes de blocs sur mesure. Un site bâti sur un thème de blocs propre n'affiche aucun de ces préfixes.
• Thème commercial reconnaissable. Toujours dans le code source, cherchez wp-content/themes/. Le dossier qui suit donne le nom du thème actif. Des noms comme Astra, OceanWP, Hello Elementor, GeneratePress ou Divi utilisé comme thème indiquent un thème acheté et utilisé tel quel. Ce n'est pas rédhibitoire en soi, mais cela signale que le site est un modèle configuré plutôt qu'un site sur mesure, et le prix doit en tenir compte.
• Trace des extensions dans l'onglet Réseau. Ouvrez les outils de développement du navigateur, allez sur l'onglet Réseau, rechargez la page, et filtrez par wp-content/plugins/. Chaque dossier d'extension visible correspond à une extension qui charge du code côté navigateur. Au-delà d'une vingtaine, la charge de maintenance et la surface d'attaque commencent à se cumuler dangereusement. Un projet sérieux garde ce nombre bas et n'embarque du JavaScript côté visiteur que là où c'est strictement utile.
• Données de terrain Core Web Vitals. Les trois métriques Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift) mesurent à quelle vitesse et avec quelle fluidité une page devient utilisable pour de vrais visiteurs. Passez l'URL publique dans PageSpeed Insights et regardez le badge CrUX : il s'agit du jeu de données de terrain de Google sur les utilisateurs Chrome réels, pas d'un test synthétique en laboratoire. Le Web Almanac 2025 indique que le site WordPress médian passe les Core Web Vitals sur mobile dans 45 % des cas, avec un score Lighthouse performance de 41 sur mobile. Autrement dit, le site WordPress typique se situe sous le seuil « Good ». Un projet professionnel doit afficher « Good » sur les trois indicateurs au 75e percentile des données CrUX dans les soixante jours qui suivent la mise en ligne.
• HTTPS, contenu mixte, HSTS. Ouvrez la console du navigateur sur la page d'accueil. Des avertissements de contenu mixte, des erreurs de certificat ou une page de connexion encore en HTTP simple sont autant de signaux d'alerte. Rater cette vérification en 2026 indique que le projet n'est jamais passé par une checklist de mise en ligne.
• Énumération de comptes sur /wp-admin/. Allez sur la page de connexion et entrez un faux nom d'utilisateur. Si le message d'erreur vous dit explicitement que le compte n'existe pas, le site laisse n'importe quel visiteur deviner les noms d'utilisateurs valides. Une installation durcie renvoie le même message générique quel que soit le compte saisi.
• Présence de balisage Schema. Dans le code source, cherchez application/ld+json. Des blocs JSON-LD signalent qu'un travail minimum de fondations SEO a été fait. Leur absence signale l'inverse, avec des conséquences à la fois sur le référencement classique et sur la capacité du site à être cité par les assistants IA.
• Scripts tiers déclenchés avant le consentement. Ouvrez l'onglet Réseau dans une fenêtre privée, puis chargez la page d'accueil sans toucher à la bannière de cookies. Si vous voyez déjà passer des requêtes vers Google Analytics, Meta Pixel ou un autre traceur, le site n'est pas conforme au régime européen de consentement, peu importe ce qu'affiche la bannière.

Un site qui valide six ou sept de ces huit points est en bonne santé. Un site qui en rate quatre ou plus accumule une dette de qualité qui ressortira sous forme d'incidents de sécurité, de plaintes sur les performances ou de coûts de reconstruction dans les deux premières années. L'exercice prend un quart d'heure et ne demande aucun accès privilégié. Faites-le avant même la première conversation avec l'agence qui a livré le site.

Étape 2 : les questions à poser avant de signer

L'étape 1 vous dit à quoi ressemble un site fini. L'étape 2 vous dit si l'agence en face de vous est capable d'en livrer un. Les sept questions ci-dessous sont celles auxquelles une agence sérieuse répond vite et précisément. Des réponses floues ou évasives ne relèvent pas du tempérament : elles décrivent une équipe qui n'a pas encore décidé comment elle va construire votre site.

• Le thème sera-t-il fait sur mesure, un thème enfant, ou un thème commercial utilisé tel quel ? Une bonne réponse ressemble à « nous construirons un thème de blocs sur mesure adapté à votre design, sans page builder, et vous resterez propriétaire du code ». Une réponse faible ressemble à « nous partons d'Astra avec Elementor et nous adaptons à partir de là ». Aucune des deux n'est fausse en soi, mais elles décrivent des produits radicalement différents. Si vous entendez la deuxième, vous achetez un modèle configuré, pas un développement sur mesure, et le prix doit le refléter.
• Combien d'extensions le site embarquera-t-il à la mise en ligne, et pouvez-vous les nommer avec leurs éditeurs ? Une bonne réponse est un chiffre précis sous la barre des 15 ou 20, avec des éditeurs réputés et une ligne de justification par extension. Une réponse faible est « ce qu'il faudra » ou un nombre au-dessus de 30. Refuser de s'engager sur un chiffre avant la phase de cadrage est acceptable, mais ce chiffre doit être posé avant la mise en ligne, parce qu'il détermine votre exposition de sécurité, votre charge de mises à jour et votre budget annuel de licences pour les années à venir.
• Quelle est votre checklist de durcissement à la mise en ligne, et est-elle documentée ? Une bonne réponse fait référence au guide de durcissement WordPress.org comme socle minimum, et nomme les ajouts propres à l'agence : authentification à deux facteurs sur /wp-admin/, édition de fichiers désactivée dans le tableau de bord avec DISALLOW_FILE_EDIT, droits fichiers à 755 sur les répertoires et 644 sur les fichiers, utilisateur de base de données restreint, nom d'utilisateur admin jamais créé. Une réponse faible est « notre extension de sécurité s'en charge ». Une extension de sécurité peut compléter le socle, mais elle ne le remplace pas.
• Y a-t-il une URL de pré-production séparée, et y aurai-je accès tout au long du projet ? Une bonne réponse est une URL de pré-production dédiée, protégée par authentification basique, non indexée, avec votre accès en lecture dès la première semaine et un déploiement vers la production depuis la pré-production sur une cadence définie. Une réponse faible est « nous travaillons directement en production » ou « nous vous enverrons des captures d'écran ». Travailler en direct sur la production révèle qu'aucune méthode de travail formelle n'a été mise en place pour le projet.
• Quels scores Core Web Vitals le site embarquera-t-il à la mise en ligne, mesurés sur l'URL en production ? Une bonne réponse est un engagement écrit, par exemple « Good sur LCP, INP et CLS au 75e percentile des données CrUX dans les soixante jours suivant la mise en ligne », avec une clause de remédiation si l'engagement n'est pas tenu. Une réponse faible est « assez rapide » ou « nous optimiserons après la mise en ligne ». L'optimisation reportée à plus tard se retrouve presque toujours chiffrée comme une prestation séparée, et bien souvent elle ne se fait jamais.
• À quel standard d'accessibilité construisez-vous, et aurai-je un rapport d'audit avant la mise en ligne ? Une bonne réponse est « nous visons WCAG 2.2 niveau AA, nous menons une analyse automatisée et une passe manuelle au clavier et au lecteur d'écran, et vous recevez le rapport écrit à la recette ». WCAG 2.2 niveau AA est le standard international d'accessibilité que la plupart des sites du secteur public et des grandes entreprises appliquent comme socle de référence, et la cible pratique pour tout site sérieux en 2026. Une réponse faible est « WordPress est accessible par défaut », ce qui ne tient pas face à un audit réel. Selon le rapport WebAIM Million 2026, la page d'accueil moyenne d'un site WordPress comporte 52,8 erreurs WCAG détectables, ce qui place la plateforme en milieu de peloton, derrière Drupal (41,2) et Wix (33,3). Le travail d'accessibilité que WordPress fait sur la plateforme elle-même ne se transfère à votre site que si la construction a été pensée pour l'accessibilité dès le départ.
• Où iront les sauvegardes, et lancerez-vous un test de restauration avant la livraison ? Une bonne réponse est « des sauvegardes quotidiennes hors-site chez un hébergeur nommé, avec une rétention de 30 jours au minimum, et un test de restauration vers la pré-production dans la dernière semaine du projet, avec une capture d'écran que vous pourrez conserver ». Une réponse faible est « il y a une extension de sauvegarde ». Une sauvegarde qui n'a jamais été restaurée est une hypothèse, pas une sauvegarde, et le défaut se révèle presque toujours pendant un incident réel, au moment où il n'y a plus aucune marge pour le corriger.

Les trois questions qui pèsent le plus sont la stratégie de thème, l'inventaire des extensions et la checklist de durcissement. Vous ne devriez pas signer un contrat de réalisation sans des réponses claires sur ces trois-là, parce qu'elles décrivent les fondations du site que vous paierez à maintenir pendant les cinq prochaines années. Les quatre autres se négocient plus tard si besoin.

Étape 3 : exiger les preuves à la recette

La recette est le moment où l'agence remet les clés au client et où le client accepte le travail. C'est aussi le moment où la plupart des compromis de qualité deviennent permanents, parce qu'ils sont absorbés dans « le site est en ligne, on passe à la suite ». La façon d'éviter cela est de baser la recette sur des preuves : chaque promesse faite au cadrage produit un artefact spécifique à la recette, et le site n'est pas accepté tant que ces artefacts ne sont pas remis.

• Un rapport d'audit d'accessibilité avant mise en ligne. Résultats de l'analyse automatisée et notes de revue manuelle, datés dans la dernière semaine du projet. Le rapport doit nommer le standard visé (WCAG 2.2 niveau AA par défaut), le périmètre des pages testées, l'outillage utilisé, et les problèmes identifiés avec leurs résolutions. Une analyse automatisée sans erreur est un plancher, pas un plafond : les outils automatisés ne détectent qu'une fraction des vrais défauts d'accessibilité, et un rapport propre sans passe manuelle attachée est un signal de travail incomplet.
• Une capture d'écran du test de restauration vers la pré-production. Preuve que la chaîne de sauvegarde a été testée de bout en bout, pas seulement configurée. La capture doit montrer la pré-production qui fait tourner le snapshot restauré, avec la date et l'horodatage de la sauvegarde source visibles. Sans cette capture, la sauvegarde reste théorique.
• Un inventaire complet des extensions. Un CSV ou un tableau markdown listant chaque extension embarquée à la mise en ligne, avec le nom de l'éditeur, l'URL de l'extension, le type de licence, le coût annuel de renouvellement et la date de renouvellement. Cela permet de planifier le budget annuel et permet à un futur mainteneur d'auditer la surface d'attaque sans avoir à redécouvrir ce qui est installé. C'est aussi ce qui rend visible l'abandon d'une extension : si la dernière mise à jour remonte à plus d'un an, l'extension est en chemin vers une vulnérabilité.
• Un accès propriétaire au dépôt de code. Le code du site doit vivre dans un dépôt Git sur GitHub, GitLab ou un équivalent, avec vous comme propriétaire du compte, pas comme simple collaborateur. Si le code reste « en interne » chez l'agence, vous êtes enfermé même si le contrat dit le contraire. Un statut de propriétaire reste à vous quoi qu'il advienne de la relation, alors qu'un statut de collaborateur peut être révoqué par le titulaire du compte à tout moment.
• La checklist de durcissement comme document livré. Pas « nous appliquons notre checklist de sécurité » dans l'abstrait, mais la liste précise des éléments appliqués à ce site, datée, avec les valeurs en place là où c'est pertinent (droits fichiers, privilèges de l'utilisateur de base de données, configuration de l'authentification à deux facteurs, paramètre DISALLOW_FILE_EDIT, et ainsi de suite). Cette checklist devient la base de tout audit futur, y compris ceux qu'une autre agence pourrait mener.
• Un document d'environnement et de procédure de déploiement. Où se trouvent la pré-production et la production, qui les héberge, à quoi ressemble la commande de déploiement, qui détient les clés SSH, où le DNS est géré, où sont stockées les sauvegardes, où sont accessibles les journaux. C'est ce document qui rend le site portable. Un site qui n'a pas ce document n'est portable que par l'agence qui l'a livré, ce qui est une autre forme d'enfermement.
• Une période de garantie inscrite au contrat. Typiquement 30 à 90 jours après la mise en ligne, qui couvre les corrections de bugs par rapport au cahier des charges convenu, sans facturation supplémentaire. Une garantie n'est pas la même chose qu'un contrat de maintenance : c'est une promesse que ce qui a été livré correspond bien à ce qui a été spécifié, et qu'il sera corrigé sans frais pendant la fenêtre de garantie. Une agence qui n'offre aucune garantie, ou qui veut facturer chaque modification dès le premier jour, vous indique à l'avance comment fonctionnera la relation sur la durée.

Un seul artefact manquant à la recette se rattrape généralement avec un email de relance. Trois ou plus signifient que le site est inachevé et que l'agence vous demande de le réceptionner quand même. La façon d'éviter cette conversation le jour de la livraison est de nommer ces artefacts dès le cadrage et de les inscrire au contrat.

Préparation IA et agents

Une couche de qualité s'est imposée en 2026 et reste presque totalement absente des checklists WordPress qui circulent : la capacité du site à être lu, compris et cité par les assistants IA. Une part croissante du trafic visiteurs passe désormais par des systèmes IA qui résument le contenu avant même que le visiteur ne le voie, et les sites cités par ces assistants gagnent une visibilité dont ceux qu'ils ignorent ne profitent pas. Nous traitons le sujet en profondeur dans notre guide sur les sites prêts pour les agents IA. Le minimum qu'un projet WordPress sérieux doit embarquer tient en six points.

• HTML sémantique et hiérarchie de titres propre. Un seul H1 par page, des H2 pour les sections de premier niveau, pas de niveau sauté. Les systèmes IA analysent la structure du document avant le contenu. Un site qui s'ouvre sur trois H1 et qui saute du H2 au H4 est lu comme trois documents cousus ensemble.
• Schémas FAQPage et Article comme socle. Ces deux types de schéma concentrent la majorité des extraits de contenu cités par les IA dans le suivi actuel. Ils sont peu coûteux à ajouter et leur effet sur la fréquence de citation est mesurable.
• Canonical et hreflang corrects sur les sites multilingues. Une canonique erronée fait citer la mauvaise page par les systèmes IA. Un hreflang manquant fait choisir à l'assistant la mauvaise version linguistique quand on lui pose une question dans l'une ou l'autre langue. Les deux défauts sont courants sur les sites WordPress multilingues et tous deux se vérifient dans le code source.
• Une entité Organization publique avec sameAs. Du JSON-LD sur la page d'accueil qui décrit l'organisation et relie vers ses profils faisant autorité : LinkedIn, GitHub, Crunchbase, le registre des entreprises local quand c'est pertinent. C'est ainsi que les assistants IA résolvent la question « qui est ce site » avec assez de fiabilité pour citer la source.
• Contenu principal qui n'est pas rendu uniquement en JavaScript. Beaucoup de crawlers IA n'exécutent pas le JavaScript du tout, ou appliquent un rendu différé qui ajoute un délai non négligeable, comme Google le documente lui-même pour le comportement de rendu de son propre crawler. Du contenu qui n'apparaît qu'après l'exécution d'un script est du contenu qui peut ne pas figurer du tout dans les données d'entraînement des IA.
• Un fichier /llms.txt optionnel. La convention pour les résumés de site lisibles par agent émerge encore, mais le coût d'ajout est négligeable et le signal envoyé aux opérateurs IA est que le propriétaire du site fait attention à ce canal.

Questions fréquentes

Que comprend un projet WordPress mené dans les règles ?

Un projet WordPress mené dans les règles embarque un thème de blocs sur mesure ou choisi avec soin, un parc d'extensions resserré chez des éditeurs réputés, le guide de durcissement WordPress.org appliqué comme socle, des Core Web Vitals au niveau « Good » sur l'URL en production à la mise en ligne, un audit d'accessibilité contre WCAG 2.2 niveau AA avant la livraison, des sauvegardes quotidiennes hors-site avec restauration testée, une pré-production séparée, le code du site dans un dépôt de versions dont vous êtes propriétaire, une documentation de livraison complète comprenant un inventaire des extensions et une procédure de déploiement, et une période de garantie inscrite au contrat.

Comment savoir si une agence WordPress fait du travail de qualité ?

Regardez trois éléments ensemble. D'abord, un site déjà en ligne livré par cette agence qui passe l'audit de l'étape 1 de ce guide : code source propre, Core Web Vitals au niveau « Good », pas de fuite de chemins d'extensions, pas d'énumération sur la page de connexion. Ensuite, des réponses écrites claires aux questions de l'étape 2, en particulier sur la stratégie de thème, l'inventaire des extensions et la checklist de durcissement. Enfin, les artefacts de recette de l'étape 3 nommés noir sur blanc dans la proposition, pas vaguement promis quelque part vers la fin. Une agence qui fait du travail de qualité décrit ce travail dans des termes concrets, avec des références à des sites déjà livrés, à des processus nommés et à des livrables nommés.

Quelle est la différence entre un site WordPress bas de gamme et un site professionnel ?

Les différences structurelles sont visibles à chaque étape. Un site WordPress bas de gamme s'appuie typiquement sur un thème commercial empilé avec un page builder lourd et trente extensions ou plus, déployé sans durcissement, sans travail d'accessibilité, sans pré-production séparée, et sans documentation. Un site WordPress professionnel s'appuie sur un thème de blocs sur mesure ou choisi avec soin, sur une liste d'extensions resserrée et justifiée, sur une mise en ligne durcie, sur des performances et une accessibilité mesurables, et sur une recette propre que vous pourrez transmettre à n'importe quel futur mainteneur. Le coût d'hébergement est similaire entre les deux. C'est le coût de réalisation qui fait la différence.

Combien coûte un site WordPress bien construit ?

Le prix affiché est rarement là où se loge la variation qui compte. Deux sites avec le même cahier des charges et la même liste de fonctionnalités peuvent différer d'un ordre de grandeur en coût total selon la façon dont le thème est construit, la rigueur de la sélection des extensions, et le nombre d'heures d'ingénierie investies dans la sécurité, les performances et l'accessibilité avant la mise en ligne. Un site bas de gamme réutilise typiquement un thème commercial empilé avec un page builder lourd et s'arrête à la configuration, alors qu'un site professionnel passe des heures d'ingénierie sur les dimensions décrites dans cet article. Ce qui sépare les deux est rarement la liste des fonctionnalités, et presque toujours le soin apporté à chaque couche du projet.

Comment vérifier la qualité d'un site WordPress avant d'engager l'agence qui l'a livré ?

Faites l'audit de l'étape 1 sur un site issu du portfolio de l'agence. Cherchez dans le code source les préfixes de classes de page builder et le nom du thème actif. Lancez PageSpeed Insights et regardez le badge des données de terrain CrUX. Cherchez le balisage Schema JSON-LD dans le code source. Comptez les chemins d'extensions dans l'onglet Réseau des outils de développement. Vérifiez que la page de connexion ne fuit pas l'énumération des noms d'utilisateurs. Quinze minutes de travail sur une URL en production vous en disent plus sur la façon de construire de l'agence que n'importe quel appel commercial.

Où ce guide s'inscrit dans votre décision

Ce guide suppose que vous avez déjà choisi WordPress. Si vous êtes encore en train de comparer les plateformes, notre cadre d'audit de plateforme couvre les cinq vérifications qui déterminent si WordPress est bien la bonne plateforme pour votre projet. Si vous êtes en amont du choix d'agence et en train de monter un cahier des charges, notre guide pour préparer un projet web avec une agence couvre ce qu'il faut apporter à la table. Une fois le site en ligne, les règles opérationnelles changent : notre guide des contrats de maintenance WordPress couvre ce que l'agence doit faire pour vous à partir de la mise en ligne.

Si vous voulez un regard indépendant sur un site WordPress que vous êtes sur le point de commander, ou sur un site dont vous venez d'hériter et que vous devez évaluer, notre service de conseil et avis est conçu pour cela. Si vous voulez une équipe pour livrer un projet aux standards décrits ici, notre service de développement web part de la même checklist.

Keroberos est un cabinet de conseil en technologies web qui accompagne les entreprises dans le choix de leur plateforme, livre des projets WordPress et Drupal, et fournit des prestations en régie pour les équipes de développement. Pour échanger sur votre projet WordPress, contactez-nous.