Éclair CMS ou WordPress ? Ce que montre un benchmark public, avec ses limites

Sommaire
- Comment le benchmark a-t-il été mené ?
- Pourquoi les pages Éclair sont-elles si légères ?
- Que se passe-t-il quand le cache ne sert pas ?
- Dans quels cas WordPress fait-il mieux qu'Éclair ?
- WordPress est-il moins sûr qu'Éclair ?
- Quelle maintenance et quel SEO dès l'installation ?
- Mon analyse : quand choisir WordPress, quand choisir Éclair ?
- Que faire concrètement avant de choisir ?
- Questions fréquentes
- Sources
Éclair CMS vs WordPress : sur le même serveur, dans le benchmark public publié le 8 novembre 2026, Éclair 2.0.0 répond 1,6 fois plus vite que WordPress 7.1.4 équipé d'une extension de cache, sert 1,9 fois plus de requêtes par seconde et fait télécharger 9 fois moins de données au navigateur[1]. WordPress garde l'avantage derrière un cache FastCGI de Nginx, sur les gros sites et dès qu'il faut un écosystème d'extensions. Voici les chiffres, la méthode et les limites.
Je dois d'abord signaler un conflit d'intérêts : j'ai créé Éclair CMS, et j'ai aussi écrit ce benchmark. C'est justement pour cela que tout est public : scripts, réglages, résultats bruts, et une seule commande (« sudo ./run.sh ») pour refaire les mesures sur votre propre machine. À ma connaissance, aucune réplication indépendante n'a encore été publiée : je vous invite à en faire une.
Pourquoi se mesurer à WordPress ? Parce que c'est la référence : selon W3Techs, il fait tourner 39,4 % de tous les sites web et 58,1 % des sites dont le CMS est connu (données du 9 novembre 2026)[2]. Pour une PME, le choix du CMS engage pour plusieurs années la vitesse du site, le temps passé en maintenance et la surface d'attaque.
Comment le benchmark a-t-il été mené ?
Les mesures datent du 8 novembre 2026. Elles opposent Éclair 2.0.0, WordPress 7.1.4 avec son thème par défaut Twenty Twenty-Five (avec et sans l'extension Cache Enabler 1.8.16) et Kirby 5.6.3 avec son cache de pages[1]. Précision importante : la version courante d'Éclair est la 2.1.0, publiée le 9 novembre ; les chiffres ci-dessous concernent bien la 2.0.0.
La machine est volontairement modeste : 2 vCPU Intel Xeon à 2,10 GHz, 7 Go de RAM, Ubuntu 24.04, Apache 2.4 (ou Nginx 1.24 pour une seconde série), PHP 8.3 avec OPcache, MariaDB 10.11 pour WordPress, gzip partout. Chaque site contient les mêmes 20 articles générés. Le temps de premier octet est la médiane de 300 requêtes en local, réseau exclu ; la charge est simulée avec wrk (20 connexions pendant 20 secondes) ; Lighthouse 12.8.2 tourne avec les réglages mobiles de PageSpeed Insights (4G lente, processeur ralenti 4 fois), médiane de 5 passages.
| CMS | Premier octet (médiane) | Page construite sans cache | Débit (20 connexions) | Téléchargé (Lighthouse) | Fichiers | LCP mobile |
|---|---|---|---|---|---|---|
| Éclair 2.0.0 | 1,11 ms | 3,37 ms | 1 997 req/s | 10,8 Ko | 3 | 0,95 s |
| WordPress 7.1.4 + Cache Enabler | 1,80 ms | 75,72 ms | 1 060 req/s | 97,6 Ko | 10 | 1,50 s |
| WordPress 7.1.4 sans extension | 75,64 ms | 75,91 ms | 31 req/s | 97,8 Ko | 10 | 1,50 s |
| Kirby 5.6.3 (cache de pages) | 1,89 ms | 3,89 ms | 1 106 req/s | 23,0 Ko | 9 | 1,14 s |

Pourquoi les pages Éclair sont-elles si légères ?
Lighthouse donne 100 sur 100 à Éclair dans les quatre catégories. WordPress obtient 100 en performance, accessibilité et bonnes pratiques, mais 92 en SEO avec son thème par défaut ; Kirby obtient 100, 94, 100 et 90. Sur une page de texte aussi simple, tout le monde reste rapide : le LCP mobile simulé est de 0,95 s pour Éclair contre 1,50 s pour WordPress, avec 3 fichiers et 10,8 Ko à télécharger d'un côté, 10 fichiers et 97,6 Ko de l'autre[1].
Il faut lire ce chiffre avec prudence : les thèmes par défaut ne sont pas identiques, on compare donc deux installations neuves, pas deux pages strictement équivalentes. Mais la réalité du terrain va plutôt dans le sens d'un écart plus grand. Selon le Web Almanac 2025 du HTTP Archive, la page WordPress médiane pèse 2 894 Ko sur mobile, et seuls 45 % des sites WordPress passent les trois Core Web Vitals sur mobile[7].

Que se passe-t-il quand le cache ne sert pas ?
Le cache masque beaucoup de différences. Mais une partie des pages est toujours construite à la volée : la première visite après une modification, les aperçus, les visiteurs connectés, ou tout le site quand aucune extension de cache n'est installée. Là, Éclair construit la page article en 3,37 ms contre 75,72 ms pour WordPress, soit 22,5 fois plus vite ; sur la page liste, l'écart atteint 30 fois[1].
L'explication est architecturale. Une page Éclair en cache est servie par un seul fichier PHP, contre 27 pour WordPress avec Cache Enabler. Sans cache, WordPress charge 496 fichiers PHP et exécute 32 requêtes SQL pour afficher une page article, avec un pic de mémoire PHP de 6,3 Mo ; Éclair n'a pas de base de données du tout. Résultat : sans extension de cache, WordPress plafonne à 31 requêtes par seconde sur cette machine.

Même logique pour l'installation : 2,5 Mo et 155 fichiers PHP pour Éclair, sans base de données ; 150,2 Mo, environ 1 900 fichiers PHP et un serveur MariaDB ou MySQL pour WordPress ; 20,1 Mo pour Kirby. L'archive à télécharger d'Éclair 2.1.0 pèse 875 Ko (896 401 octets)[6].

Dans quels cas WordPress fait-il mieux qu'Éclair ?
Sur Nginx, avec le cache FastCGI du serveur, WordPress sert 4 136 requêtes par seconde contre 3 262 pour Éclair, soit 1,3 fois plus : les pages en cache sont livrées sans passer par PHP. Les temps de premier octet sont alors identiques (0,57 ms contre 0,56 ms). Il faut toutefois un accès root au serveur pour régler ce cache, ce qu'un hébergement mutualisé ne donne pas[1].
Sur les gros sites, la construction hors cache d'Éclair ralentit : 9,61 ms à 1 000 articles, 31,03 ms à 2 900, alors que WordPress reste stable entre 60 et 76 ms. Depuis le cache, Éclair reste autour de 1 ms et de 2 000 requêtes par seconde quelle que soit la taille. Surtout, Éclair 2.x est plafonné à 3 000 contenus, articles et pages confondus : au-delà, ce n'est pas le bon outil.
Sous forte charge sur Apache (100 connexions simultanées), le 99e centile d'Éclair monte à 195 ms contre 120 ms pour WordPress avec cache ; c'est l'inverse sur Nginx. Ce sont des mesures de laboratoire, sur une petite machine qui héberge aussi l'injecteur de charge. WP Rocket, LiteSpeed Cache, Ghost, Grav, Drupal et Statamic n'ont pas été testés : je ne peux rien en dire.
WordPress est-il moins sûr qu'Éclair ?
Le cœur de WordPress est solide. Dans son rapport sur l'année 2025, Patchstack ne recense que 6 vulnérabilités dans le cœur, sur 11 334 nouvelles vulnérabilités dans tout l'écosystème WordPress, en hausse de 42 % par rapport à 2024. 91 % concernaient des extensions et 9 % des thèmes ; 17 % avaient un score de gravité élevé, et 46 % n'avaient pas de correctif au moment de leur divulgation[3].
Le risque d'un site WordPress dépend donc surtout du nombre et de la qualité de ses extensions. Éclair prend le problème autrement : cache, SEO, double authentification et sauvegardes sont dans le cœur, il n'y a pas de base de données, et les mises à jour sont signées (Ed25519) avec retour automatique à la version précédente en cas d'échec. Le projet a corrigé 21 failles confirmées lors de deux audits, aucune classée critique, dans les versions 1.10.3 et 1.10.4[4].
La contrepartie est réelle : Éclair est un projet jeune, dont la version 1.0.0 date du 29 octobre 2026, avec 24 versions publiées depuis. Sa base d'utilisateurs n'a aucune commune mesure avec celle de WordPress. Moins de code tiers, c'est moins de surface d'attaque, mais aussi moins d'yeux pour relire le code.
Quelle maintenance et quel SEO dès l'installation ?
WordPress demande PHP 8.3 ou plus, MySQL 8.0 ou MariaDB 10.11[5], puis une pile d'extensions à tenir à jour : cache, SEO, sécurité, sauvegardes. Éclair fonctionne avec PHP 8.1 ou plus sur Apache ou LiteSpeed (Nginx est possible), sans base de données à créer, exporter ou restaurer : les contenus sont stockés dans des fichiers protégés[6].
Côté référencement, Éclair génère selon sa documentation le sitemap, les données structurées JSON-LD et les redirections, et pour les moteurs IA un fichier llms.txt, une version Markdown de chaque page (il suffit d'ajouter .md à l'adresse) et des règles pour une trentaine de robots d'IA[6]. Sur WordPress, on obtient l'essentiel avec Yoast SEO ou Rank Math, au prix d'une brique de plus à maintenir. J'explique dans mon guide du GEO pourquoi ces éléments comptent pour être cité par les IA.
Mon analyse : quand choisir WordPress, quand choisir Éclair ?
Je conseille WordPress à un client qui dépasse ou dépassera 3 000 contenus, qui a besoin d'une fonction précise disponible en extension (adhésions, réservations, boutique avec panier et comptes clients : la boutique d'Éclair se limite à un lien de paiement par produit), ou dont le prestataire maîtrise déjà WordPress et un serveur Nginx bien réglé. Dans ces cas, migrer serait une erreur.
Je conseille Éclair pour un site vitrine, un blog ou un site de contenu d'indépendant ou de PME, sur hébergement mutualisé, quand on veut la vitesse et le SEO technique sans empiler d'extensions. Ce n'est pas un WordPress en mieux : c'est un outil plus étroit, qui fait moins de choses et les fait vite. L'impact énergétique de cet écart, plus modeste qu'on pourrait le croire, est chiffré dans mon article sur la consommation électrique d'un site web.

Que faire concrètement avant de choisir ?
- Mesurez votre site actuel dans PageSpeed Insights en mode mobile : poids téléchargé, nombre de requêtes, LCP.
- Comptez vos contenus et listez les extensions dont vous ne pouvez pas vous passer. Au-delà de 3 000 contenus, ou avec un vrai panier, restez sur WordPress.
- Lisez la méthodologie du benchmark, ou relancez-le sur une machine de test.
- Si vous envisagez de migrer, lancez l'extension gratuite Eclair Export en mode simulation : elle produit un rapport avant toute bascule[8].
- Vérifiez votre hébergement : PHP 8.1 suffit pour Éclair, WordPress demande PHP 8.3.
Dans les deux cas, gardez la même exigence : des adresses qui ne changent pas, des données structurées complètes et un site lisible sans JavaScript. Le CMS n'est qu'un moyen ; c'est ce que les moteurs et les IA trouvent sur vos pages qui fait la différence.
Questions fréquentes
Éclair CMS est-il vraiment plus rapide que WordPress ?
Dans le benchmark public du 8 novembre 2026, oui sur Apache : 1 997 requêtes par seconde contre 1 060 pour WordPress avec Cache Enabler, et une page construite sans cache en 3,37 ms contre 75,72 ms. Derrière un cache FastCGI de Nginx, WordPress sert en revanche 1,3 fois plus de requêtes qu'Éclair.
Qui a réalisé ce benchmark ?
Je l'ai écrit moi-même, en tant que créateur d'Éclair CMS, et je le signale dans le dépôt. Pour compenser ce conflit d'intérêts, scripts, réglages et résultats bruts sont publics et la mesure se relance avec une seule commande. Aucune réplication indépendante n'a encore été publiée à ma connaissance.
Éclair CMS convient-il à un gros site ?
Non au-delà de 3 000 contenus : Éclair 2.x est plafonné à ce nombre d'articles et de pages. Sur 2 900 articles, la construction d'une page hors cache passe déjà à 31 ms, alors que les pages en cache restent autour de 1 ms. Pour un catalogue ou un média plus important, WordPress reste le choix raisonnable.
Peut-on passer de WordPress à Éclair sans perdre son référencement ?
C'est l'objectif de l'extension gratuite Eclair Export, qui reprend contenus, médias, SEO de Yoast, Rank Math ou AIOSEO, menus et redirections, avec un mode simulation. Selon le projet, un test sur un WordPress de 500 articles a vérifié 635 anciennes adresses sans erreur 404. Contrôlez quand même le rapport avant de basculer.
Sources
- Eclair Benchmarks, dépôt public : README, méthodologie et résultats du 8 novembre 2026 (GitHub)
- W3Techs, Usage statistics and market share of WordPress (données du 9 novembre 2026)
- Patchstack, State of WordPress Security in 2026
- Éclair CMS, journal des modifications (versions 1.0.0 à 2.1.0)
- WordPress.org, Requirements
- Éclair CMS, dépôt officiel et README (GitHub)
- HTTP Archive, Web Almanac 2025, chapitre CMS (données de juillet 2025)
- Eclair Export, extension WordPress de diagnostic et d'export (GitHub)
