Le fichier readme.html est souvent l’un des premiers fichiers visibles après l’installation d’un site WordPress. Pourtant, peu d’utilisateurs connaissent réellement son utilité, son contenu ou les implications de sa présence en matière de sécurité. Dans cet article, nous explorons son origine, son rôle, ses risques et les bonnes pratiques associées.

L’histoire et le rôle du fichier readme.html dans WordPress

Le fichier readme.html fait partie de l’ADN historique de WordPress. Présent depuis la version 1.0 (sortie officiellement en janvier 2004), il a été conçu à une époque où les CMS open source étaient encore très orientés développeurs, et où chaque installation se faisait manuellement via FTP. Il servait alors de repère rapide pour comprendre les premières étapes de configuration, connaître les auteurs du projet et accéder à la documentation en ligne. Situé à la racine de toute installation WordPress (au même niveau que index.php ou wp-config.php), readme.html est un fichier statique purement HTML, sans exécution de code PHP ni interaction avec la base de données. Il est consultable publiquement à l’adresse suivante :

https://votresite.com/readme.html

Historiquement, ce fichier était particulièrement utile dans les contextes suivants :

• Lors d’une installation manuelle : il donnait les grandes lignes pour configurer wp-config.php, créer une base de données et lancer le script d’installation ;
• Pour les webmasters débutants : il servait de point de départ accessible sans connaissance technique avancée ;
• Pour comprendre l’architecture de WordPress : il listait les exigences serveur et les principales fonctionnalités du CMS.

Le contenu typique du fichier comprend plusieurs sections didactiques :

• Présentation du projet : historique, fondateurs (Matt Mullenweg et Mike Little), philosophie open source, lien vers la licence GPL.
• Instructions d’installation : prérequis serveur, étapes FTP, création de la base, et lancement de l’assistant d’installation (install.php).
• Procédures de mise à jour : comment passer à une version plus récente sans perte de contenu.
• Importation de contenu : informations sur l’outil d’import/export, utile pour migrer depuis d’autres plateformes (Blogger, MovableType, etc.).
• Ressources communautaires : liens vers les forums d’entraide, la documentation, les salons IRC de l’époque (comme #wordpress sur Freenode).
• Informations système : versions minimales recommandées de PHP et MySQL, et conseils de configuration serveur (mod_rewrite, Apache, etc.).

À l’époque, ce fichier constituait une sorte de mini guide utilisateur, un « manuel d’accueil » local qui complétait l’expérience de téléchargement de WordPress depuis wordpress.org. Aujourd’hui encore, bien qu’il ne soit plus vraiment consulté par la majorité des utilisateurs (en raison des installateurs en un clic proposés par les hébergeurs), readme.html est toujours inclus par défaut. Il conserve donc une valeur symbolique et informative pour ceux qui veulent comprendre les racines du CMS… mais aussi un potentiel vecteur d’information sensible, comme nous le verrons dans les sections suivantes.

La structure technique du fichier readme.html de WordPress

Le fichier readme.html est un document statique entièrement rédigé en HTML, sans aucun traitement côté serveur. Il ne fait appel à aucune ressource dynamique (pas de PHP, pas de base de données) et peut être consulté même si l’installation WordPress est incomplète ou endommagée. Son objectif est de fournir une documentation embarquée accessible à tous depuis le navigateur. Son contenu suit une structure relativement stable d’une version à l’autre, structurée autour de sections informatives. Voici une description détaillée des blocs que l’on retrouve généralement dans ce fichier :

Section	Description
Préambule	Introduction par Matt Mullenweg, co-fondateur de WordPress, souvent accompagnée d’un message d’accueil et d’un rappel sur la mission open source du projet.
Installation	Instructions détaillées pour installer WordPress manuellement via FTP : téléversement des fichiers, création de la base de données, modification de wp-config.php, puis lancement de install.php.
Mise à jour	Présentation des deux méthodes disponibles pour mettre à jour WordPress : depuis l’interface d’administration (méthode automatique recommandée) ou manuellement via FTP.
Migration	Informations utiles pour importer du contenu depuis d’autres systèmes comme Blogger, Movable Type ou LiveJournal, à l’aide de l’outil natif « Import » de WordPress.
Prérequis techniques	Liste des versions minimales de PHP (souvent ≥ 7.0) et de MySQL/MariaDB, ainsi que des recommandations serveur comme Apache avec mod_rewrite ou Nginx.
Ressources utiles	Liens vers la documentation officielle, les forums communautaires, les actualités du projet et parfois les anciens canaux IRC (#wordpress sur Freenode).
Licence	Rappel que WordPress est distribué sous la licence GPLv2 ou supérieure. Cette section peut aussi comporter des informations légales sur les droits d’auteur du code source et des bibliothèques incluses.

Le HTML du fichier est volontairement très basique, sans CSS complexe ni script embarqué, afin d’être lisible sur tous les navigateurs, même anciens. Cela en fait un point de référence fiable pour les utilisateurs dans un environnement technique minimal (ligne de commande, navigateurs allégés, intranet, etc.). Bien que readme.html ne soit plus consulté activement par la plupart des utilisateurs finaux, sa structure reste pensée pour servir de documentation embarquée rapide, toujours accessible, même en cas de site partiellement défaillant.

Les problèmes de sécurité WordPress liés à readme.html

Le fichier readme.html, bien qu’apparemment inoffensif, peut constituer une faille indirecte de sécurité sur votre site WordPress. Sa seule présence publique suffit parfois à alerter des scripts automatisés ou des attaquants humains sur la version exacte de WordPress que vous utilisez, ce qui facilite fortement les tentatives d’exploitation. Ce fichier est généré automatiquement à chaque installation ou mise à jour de WordPress, et est accessible librement depuis une URL standard :

https://votresite.com/readme.html

Voici les principaux risques associés à sa présence :

• Divulgation de version : la version exacte de WordPress est affichée en clair dans le titre de la page et parfois dans les métadonnées HTML. Cela permet à un attaquant de savoir immédiatement si vous utilisez une version obsolète, vulnérable à des failles connues (XSS, injection SQL, escalade de privilèges, etc.) ;
• Scan massif et automatisé : les robots malveillants ou outils de scan (comme WPScan ou Nikto) ciblent directement ce fichier pour identifier et classer les sites à attaquer. Il sert souvent de « premier test » dans une attaque par reconnaissance ;
• Indexation par les moteurs de recherche : si votre fichier n’est pas bloqué dans le fichier robots.txt, il peut être indexé par Google, Bing ou d’autres moteurs. Un simple opérateur de recherche tel que inurl:"readme.html" "WordPress 6.0" permet alors à un attaquant de repérer tous les sites avec une version donnée ;
• Non protégé par défaut : contrairement à wp-config.php ou .htaccess, le fichier readme.html n’est protégé ni par une règle serveur ni par une directive WordPress native, ce qui le rend accessible à tout moment tant qu’il est présent.

Ce que cela signifie en pratique

Un pirate informatique qui découvre que votre site fonctionne avec une version spécifique de WordPress peut alors rechercher :

• des exploits publiquement connus pour cette version (via CVE ou exploit-db),
• des failles non corrigées si vous avez désactivé les mises à jour automatiques,
• des plugins ou thèmes vulnérables souvent associés à la même version WordPress (puisque de nombreuses installations restent figées dans le temps).

Les bonnes pratiques autour du fichier readme.html de WordPress

Le fichier readme.html n’est pas nécessaire au fonctionnement de WordPress. Pourtant, il est souvent laissé accessible par défaut après l’installation du CMS. Pour renforcer la sécurité de votre site et éviter les tentatives d’exploitation basées sur la version de WordPress, voici les recommandations à suivre :

• Supprimez ce fichier après installation : c’est l’action la plus simple et la plus efficace. Une fois WordPress installé et configuré, readme.html n’a plus aucune utilité fonctionnelle. Sa suppression n’affectera ni le cœur du CMS, ni le tableau de bord, ni les mises à jour.
• Si vous ne souhaitez pas le supprimer, bloquez son accès côté serveur :
  • Sur un serveur Apache, ajoutez cette directive dans votre fichier .htaccess à la racine du site :

  <Files "readme.html">
    Order allow,deny
    Deny from all
  </Files>
  

  • Sur un serveur Nginx, utilisez ce bloc dans votre configuration :

  location = /readme.html {
    deny all;
    access_log off;
    log_not_found off;
  }
  

  Ces règles empêchent toute tentative d’accès à /readme.html, même si le fichier est toujours présent physiquement sur le serveur.

• Désindexez le fichier pour les moteurs de recherche : ajoutez une directive dans votre fichier robots.txt pour éviter que Google ou Bing n’indexent le fichier (et donc n’exposent la version WordPress dans les résultats publics).

Exemple de règle à insérer dans robots.txt :

User-agent: *
Disallow: /readme.html

Ce blocage est purement indicatif : il repose sur le respect du protocole d’exclusion volontaire des bots. Il n’empêche pas les attaquants malveillants de consulter readme.html s’il est accessible. C’est pourquoi il est préférable de combiner cette mesure avec un blocage serveur ou la suppression directe du fichier.

Conseil pour les développeurs d’agence ou de thèmes :

Si vous développez des sites pour des clients, pensez à inclure la suppression de readme.html dans vos scripts post-installation ou dans vos playbooks Ansible/Docker. Cela garantit que vous n’exposez pas involontairement vos sites en production.

Enfin, notez que ce fichier est souvent recréé lors de la mise à jour de WordPress. Pensez à surveiller sa présence à chaque déploiement ou à utiliser une tâche automatisée pour le supprimer après chaque mise à jour du cœur.

Conclusion sur le fichier readme.html : Supprimer, cacher ou garder ?

Le fichier readme.html n’est pas dangereux en soi. Il ne contient pas de code exécutable ni de faille directe, mais il constitue une faille d’information qui peut faciliter le travail des attaquants. En exposant ouvertement la version exacte de WordPress installée, il fournit un indice précieux pour ceux qui scannent automatiquement le web à la recherche de versions vulnérables. À l’heure actuelle, ce fichier n’est plus indispensable. Son rôle initial (fournir un guide d’installation manuelle) a été largement supplanté par les installateurs en un clic proposés par les hébergeurs, les interfaces graphiques, et les gestionnaires de mise à jour intégrés. Il reste donc comme un vestige de l’histoire de WordPress, un clin d’œil à ses origines techniques, mais inutile en production.

Alors, que faire ?

• Supprimez-le si vous ne l’utilisez pas. Cela ne brisera aucune fonctionnalité du CMS.
• Bloquez son accès si vous préférez le conserver pour archive ou documentation interne (via .htaccess ou Nginx).
• Ajoutez une règle robots.txt pour éviter qu’il ne soit indexé par Google ou d’autres moteurs de recherche.

Si vous gérez plusieurs sites WordPress ou travaillez en agence, pensez à intégrer cette mesure dans vos routines de sécurité et dans vos scripts d’automatisation de déploiement. C’est une action simple, rapide, et qui contribue à réduire votre surface d’exposition. En somme, le fichier readme.html n’a plus sa place sur un site WordPress professionnel ou en production. À moins que vous ne le conserviez pour des raisons pédagogiques ou historiques, il est fortement recommandé de le supprimer ou d’en restreindre l’accès.