WordPress 6.8 est en route et promet de raffiner l’expérience utilisateur, tout en optimisant la performance, le design et la sécurité. Prévue pour le 15 avril 2025, cette nouvelle version devrait ravir les utilisateurs.
Il est parfois complexe d’aller à la pêche aux informations et de comprendre ce qui nous attend… Alors on a démêlé tout cela pour vous. Voici donc ce qui vous attend avec WordPress 6.8.
Table of Contents
Calendrier de sortie de WordPress 6.8
WordPress nous fournit toujours une roadmap détaillée mais celle-ci peut être un peu complexe à appréhender.
Voici donc les principales étapes avant la sortie officielle de WordPress 6.8 :
Date
Événement
4 mars 2025
Beta 1 : Début des tests intensifs et corrections de bugs
25 mars 2025
Release Candidate 1 : Première version quasi finale
14 avril 2025
Dry run et gel du code
15 avril 2025
Sortie officielle de WordPress 6.8 🎉
Quelles nouveautés pour WordPress 6.8 ?
Les développeurs de WordPress ont annoncé ces fonctionnalités. Si la plupart devrait voir le jour dans la 6.8, il est possible que certaines ne soient pas prêtes à temps. Voici cependant un résumé de ce que WordPress prévoit pour nous.
🔎 Amélioration du mode “Zoom Out”
WordPress 6.8 permet désormais d’éditer les compositions (patterns) en mode “Zoom Out”. Cela enrichit le workflow et devrait plaire à ceux ayant déjà adopté ce mode et convertir les plus réfractaires ! #67140
✍️ Sélecteur de polices d’écriture amélioré
WordPress 6.8 ajoute un sélecteur de police avec aperçu en direct sur le menu déroulant dans l’éditeur Gutenberg, faisant gagner du temps lors du choix des typographies. #67118
🧓 Affichage des styles pour les thèmes non FSE
Les thèmes classiques ou hybrides ayant adopté l’utilisation d’un fichier theme.json pourront désormais afficher un aperçu du style via l’éditeur de site. #66851
🌈 Bouton de réinitialisation des couleurs
Il sera possible de réinitialiser une couleur personnalisée en un seul clic. Ce petit changement fera économiser de nombreux clics aux éditeurs ! C’est à se demander comment on a pu ne pas y penser avant ! #67116
WordPress 6.8 ajoute une fonctionnalité basée sur le plugin Speculative Loading qui intégrera désormais le core WordPress. Il s’agit donc du préchargement spéculatif, une API qui communique avec les navigateurs web. Elle accélère le chargement des pages en anticipant les interactions des visiteurs. Pour l’heure, elle n’est supportée que par les navigateurs basés sur Chromium (Chrome, Edge, Brave, Opera). Firefox teste cela expérimentalement. Core WP #62503
Cette nouvelle technologie attise la curiosité et chez LRob, on espère pouvoir mesurer l’impact sur l’utilisation serveur et autres métriques.
🔎 Affichage des boucles de requêtes plus efficaces
Désormais, il sera possible de filtrer les contenus par année, paginer plus efficacement et structurer les requêtes avec plus de flexibilité.
Les boucles de requêtes présentaient des soucis de logique sur l’affichage des articles mis en avant dans l’éditeur. Cela sera enfin corrigé dans WordPress 6.8. #68570 et #66126
Il sera possible d’ignorer les sticky posts pour tout simplement afficher tous les articles. Et non pas seulement les sticky, ou seulement les non sticky. De quoi simplifier le layout des boucles de requêtes. Enfin ! #66221
Il sera aussi possible de définir une limite de “profondeur” (depth limit) pour les pages enfants (sous-catégories). #68620
👉 Amélioration de l’API d’interactivité introduite dans 6.7
On retrouvera au moins le “lightbox” du bloc galerie, et une fonction de recherche instantanée. Et la navigation pleine page serait améliorée (pas de référence d’issue fournie par WP.org, difficile de savoir concrètement de quoi il s’agit) avec des améliorations régionales (en fonction de la langue).
D’autres fonctionnalités liées sont en préparation.
🖥️ Affichage des données améliorées dans le back-office
WordPress 6.8 unifie le comportement des listes et grilles affichant par exemple les templates dans l’éditeur de sites. La discussion est si énorme qu’elle prendrait des heures à résumer. Pour celle-ci, il faudra attendre la sortie ! #67477
Sur les propriétés d’une page ou d’un post, il sera possible d’éditer plusieurs champs en une fois, économisant un grand nombre de clics. #65399
Une confirmation a été ajoutée lors du vidage des éléments de la corbeille de pages dans l’éditeur FSE. #67824
Les marges autour des boutons d’action ont été légèrement réduites pour éviter le gaspillage d’espace. #67032
L’affichage par grilles permet de choisir la densité d’affichage. #67170
Un badge peut être ajouté dans les grilles de vues (par exemple pour la synchronisation des templates). #68062
Les espacements sur les filtres dans l’affichage des pages de l’éditeur ont été réduits pour éviter le clipping. #65835
Enfin, il sera possible pour les thèmes FSE de changer plus facilement le template des pages depuis l’éditeur de sites. #66591
🧱 Correctifs et améliorations de Gutenberg
Plusieurs blocs manquaient de la gestion des marges et autres contrôles. Cela a été ajouté. #68450, #64425, #68323
L’ajout d’images de fond (par exemple pour les groupes) se retrouve désormais sous un bouton “+” pour uniformiser ce choix optionnel avec les autres choix optionnels. #68085
Enfin, petit détail mais pas des moindres, des chevrons de sélection des polices et des ombres permettant de tout supprimer seront disponibles là où ils manquaient pour ré-uniformiser l’éditeur. #67253
🔐 Sécurité renforcée avec bcrypt pour le hachage des mots de passe
Grande avancée côté sécurité : WordPress 6.8 adopte bcrypt pour le hachage des mots de passe, rendant le stockage et la protection des accès beaucoup plus robustes. Ce changement renforce également la gestion des clés de sécurité et des mots de passe d’application.
🚀 Optimisations supplémentaires pour des sites plus rapides
WordPress 6.8 optimise encore les performances avec :
Lazy load des métadonnées des articles et utilisateurs,
Amélioration du cache des requêtes (notamment dans WP_Query),
Optimisation du chargement des images d’en-tête et du tri aléatoire ORDER BY RAND().
🏆 Accessibilité : WordPress devient fait des bonds en avant
La liste complète des correctifs et améliorations est longue :
Révision de l’utilisation de target=”_blank” dans l’administration
Suppression des attributs title inutiles
Ajout de boutons de soumission sur les champs de formulaire dans le panneau Ajouter un média
Utilisation d’éléments sémantiques pour les faux liens (non-link links)
Ajout d’un message d’erreur en cas de mot de passe incorrect sur les articles protégés
Éditeur de code : le linter (HTMLHint) doit afficher une erreur si une case à cocher n’a pas d’étiquette associée
L’uploader de médias ne restreint pas les types de fichiers acceptés en fonction du contexte actuel
Thème Twenty Twenty : le sous-menu d’un menu horizontal doit pouvoir être fermé
Ajout de préfixes aux notifications d’administration (Avertissement, Erreur, Succès, Info)
Amélioration de l’accessibilité des notifications d’administration
Correction et amélioration du réagencement des metaboxes
Ajout d’un mécanisme pour des info-bulles accessibles dans le cœur de WordPress
Thème Twenty Twenty : fermeture du menu et de la recherche peut entraîner un saut de défilement
Lecture excessive de texte avec erreurs dans la bibliothèque de médias
La réinitialisation du mot de passe doit pré-remplir le nom d’utilisateur pour répondre aux normes WCAG 2.2
Validation des liens personnalisés dans le menu d’administration non accessible
Simplification des libellés add_new_item pour les types de publication par défaut
Mise à jour de la classe CSS screen-reader-text et de ses implémentations locales
Absence de bouton submit – mauvais pour l’accessibilité
Ajout d’un arrière-plan plus clair pour l’administration
Ajout de padding et de changements de couleur aux boutons et aux champs de saisie
Modification du poids des polices pour les paramètres et autres libellés similaires
Ajustement du fond des lignes alternées dans les tableaux des articles et des pages
Le bloc core/site-title ajoute aria-current à la page du blog même si ce n’est pas la page d’accueil
get_custom_logo n’applique pas toujours l’attribut aria-current correctement
Amélioration de la sémantique HTML dans les tableaux des Informations sur la santé du site
Suppression des attributs title des scripts de l’éditeur classique
WordPress 6.8 : Une version axée sur la stabilité et l’optimisation
WordPress 6.8 va grandement améliorer l’expérience administrateur. Et continuer de convertir de plus en plus en plus de monde à Gutenberg et au Full Site Editing (FSE). Que vous soyez développeur, créateur de contenu, propriétaire de site, ou même visiteur, cette version garantit un écosystème encore plus agréable.
🚀 Préparez-vous dès maintenant à WordPress 6.8 avec LRob
Chez LRob, les hébergement sont optimisés pour WordPress.
Sécurité, performances, outils de gestion et support, tout y est.
Dès le le 4 juin 2025, Let’s Encrypt ne vous enverra plus d’emails pour vous avertir de l’expiration de vos certificats SSL/TLS. Ce changement, qui peut sembler surprenant, est en réalité une excellente nouvelle pour les administrateurs système, les hébergeurs web et les propriétaires de sites. Dans cet article, nous allons voir pourquoi cette décision simplifie la gestion des certificats et améliore la sécurité.
Chez LRob, nos offres d’hébergement web intègrent déjà Let’s Encrypt et automatisent la gestion des certificats SSL, garantissant un HTTPS toujours fonctionnel sans intervention manuelle.
Let’s Encrypt : un acteur clé du SSL/TLS gratuit et automatique
Let’s Encrypt est une autorité de certification qui fournit gratuitement des certificats SSL/TLS. Il permet à des millions de sites d’afficher le fameux cadenas de sécurité dans les navigateurs et d’assurer une connexion chiffrée en HTTPS.
Jusqu’à présent, si vous utilisiez Let’s Encrypt, vous receviez automatiquement des emails pour vous avertir de l’expiration imminente de vos certificats. Mais cette fonctionnalité va disparaître.
Pourquoi Let’s Encrypt supprime les notifications d’expiration
Let’s Encrypt a annoncé que les notifications d’expiration seront désactivées à partir du 4 juin 2025.
Article de blog Let’s Encrypt
Voici les raisons principales :
1. L’automatisation des certificats SSL est devenue la norme
Il y a 10 ans, renouveler un certificat était souvent un processus manuel. Aujourd’hui, tout bon hébergeur web et les outils d’administration système proposent un renouvellement automatique, ce qui rend les emails d’expiration inutiles.
Chez LRob, tous les certificats Let’s Encrypt sont renouvelés automatiquement pour éviter toute interruption de service. Pour nos clients qui utilisent un certificat wildcard, le renouvellement reste automatisé tant que le site utilise nos serveurs DNS.
2. Des notifications souvent inutiles ou trompeuses
Les emails d’expiration avaient plusieurs inconvénients :
Certificats remplacés mais toujours notifiés : Si vous régénériez un certificat pour une raison X ou Y, vous pouviez recevoir une alerte pour un certificat qui n’était plus en usage.
Emails ignorés ou mal interprétés : Les alertes pouvaient semer la confusion chez les propriétaires d’hébergements qui ne comprenaient pas toujours de quoi il s’agissait.
3. Amélioration de la protection des données personnelles
Let’s Encrypt stockait des millions d’adresses email uniquement pour envoyer ces alertes. En supprimant cette fonctionnalité, l’organisation renforce la protection de la vie privée des utilisateurs.
4. Réduction des coûts et de la complexité
Gérer ces notifications représentait des dizaines de milliers de dollars de frais par an pour Let’s Encrypt. Ces ressources seront maintenant allouées à l’amélioration de l’infrastructure et de la fiabilité du service.
Comment s’assurer que votre certificat SSL reste actif ?
Vous êtes client LRob ? Bonne nouvelle : vous n’avez rien à faire.
Nos hébergements web gèrent le renouvellement automatique de vos certificats Let’s Encrypt et vous alertent en cas d’anomalie. De plus nous monitorons les domaines hébergés afin d’être alertés avant l’expiration en cas de non renouvellement. Vous n’avez plus à vous soucier des expirations.
De plus, nous utilisons une clé de chiffrement RSA de 4096 bits au lieu de 2048 par défaut, pour une meilleure sécurité des données échangées entre les visiteurs et vos sites internet.
Utiliser un service de monitoring SSL
Si vous gérez vos certificats en dehors de LRob, nous vous conseillons de mettre en place un monitoring SSL, comme :
Red Sift Certificates Lite (anciennement Hardenize) : Gratuit pour surveiller jusqu’à 250 certificats.
Uptime Kuma ou Cert Spotter : Outils permettant de surveiller l’état de vos certificats et de recevoir des alertes en cas d’expiration.
Conclusion : Une simplification bénéfique pour l’hébergement web
La fin des notifications d’expiration de Let’s Encrypt est une évolution logique : les certificats sont maintenant automatisés et les solutions de surveillance permettent de pallier tout oubli.
Avec nos offres d’hébergement web, nous garantissons un HTTPS toujours actif, sans tracas. Vous cherchez un hébergeur qui intègre Let’s Encrypt et gère tout pour vous ? Rejoignez-nous !
Un hébergement WordPress ultra-performant et sécurisé, sans compromis
Chez LRob, notre mission est claire : offrir un hébergement WordPress rapide et sûr, en minimisant l’impact des attaques tout en optimisant les performances serveur. Contrairement à des solutions standard qui se contentent de répondre aux menaces, nous allons plus loin en prévenant activement les serveur charges inutiles.
Car si certains hébergeurs n’implémentent pas ou pas assez de blocage des attaques ou n’offrent aucune transparence, LRob peut afficher fièrement ses mesures en place et les résultats obtenus.
Dans cet article, nous vous expliquons notre stratégie qui repose sur trois couches de sécurité conçues pour bloquer efficacement les attaquants et vous offrir un maximum de sécurité et de performances pour vos site web.
Les attaques sur WordPress : un fléau qui consomme vos ressources
Les sites WordPress sont la cible de nombreuses attaques automatisées. Ces attaques prennent deux formes principales :
Les attaques réelles, qui consomment énormément de ressources. Par exemple, les tentatives de connexion massives ou les requêtes ciblant XML-RPC (xmlrpc.php) sollicitent fortement le CPU car elles atteignent directement PHP et ne peuvent pas être mises en cache. De même, certaines requêtes POST peuvent être interprétées par PHP et causer une charge excessive.
Les requêtes parasites, qui génèrent des réponses inutiles comme des erreurs 301, 403 (pare-feu applicatif ou règles serveur) ou 404. Bien qu’elles ne soient pas toujours malveillantes, elles alourdissent les logs et réduisent l’efficacité du serveur.
Sans les protections adéquates, cela peut saturer les serveurs et ralentir vos sites. C’est l’une des causes de lenteurs que l’on observe chez de nombreux hébergeurs.
C’est pourquoi LRob se bat activement contre ce type d’attaques. Et Notre approche fait la différence : nous ne nous contentons pas d’atténuer l’impact des requêtes malveillantes, nous les éliminons avant qu’elles ne deviennent un problème.
Notre stratégie de protection en trois niveaux
1. Des règles de sécurité spécifiques à WordPress
Nous implémentons des règles de sécurité strictes adaptées aux spécificités de WordPress, comme celles fournies par le WordPress Toolkit de Plesk, mais aussi des configurations personnalisées pour réduire la surface d’attaque.
Par exemple, nous interdisons certaines requêtes dans certains répertoires clé de WordPress, nous bloquons les requêtes sur XML-RPC lorsque inutilisé, et référençons les tentatives de connexion échouées à WordPress.
Cela permet de repérer ou bloquer directement les accès non autorisés et les comportements anormaux propres au CMS.
2. ModSecurity : un pare-feu applicatif puissant
ModSecurity agit comme un filtre intelligent en bloquant les requêtes malveillantes avant qu’elles n’atteignent WordPress. Cette solution permet d’arrêter les attaques les plus courantes comme les injections SQL, le XSS ou les scans de vulnérabilités, ajoutant ainsi une protection significative à votre site, même lorsque celui-ci contient des failles de sécurité connues.
Cependant, bloquer une requête ne suffit pas éviter l’utilisation inutile de ressources serveur. C’est là qu’intervient fail2ban.
3. Fail2ban : bloquer les attaquants de manière définitive
Fail2ban analyse les logs des attaques des deux sécurités précédentes et bloque automatiquement les IP malveillantes en les empêchant de faire d’autres requêtes.
En clair :
Fail2ban répertorie les attaquants via leur IP
Si un attaquant réitère son attaque, fail2ban bannit l’IP attaquante.
Résultat : cette IP ne pourra plus envoyer de requêtes à votre site.
Vous gagnez ainsi drastiquement sur deux plans : performance et sécurité. Votre site est plus rapide à charger et beaucoup moins sujet aux attaques.
Résultat : un site plus rapide, plus sûr, et des ressources libérées
Avec cette stratégie, nous constatons une baisse drastique de l’utilisation CPU sur nos serveurs, tout en améliorant la disponibilité et la réactivité des sites de nos clients.
Quelques chiffres :
Jusqu’à 95% de l’utilisation CPU économisée en bloquant directement les attaquants.
Un serveur autrefois saturé peut tomber à 5% d’utilisation après mise en place des protections.
Une réduction de 95% des logs parasites et une meilleure lisibilité des analyses de trafic.
J’aimerais pouvoir vous donner des chiffres sur le gain de sécurité. Mais il faudrait pour cela qu’un seul site hébergé par LRob aie été piraté. Cela n’est encore jamais arrivé. Il serait trop prétentieux de prétendre que cela réduit de 100% le risque de piratage d’un site. Néanmoins, on peut être confiant en le fait que cela mène la vie dure aux attaquants et rend le piratage de votre site extrêmement plus difficile.
Pourquoi choisir LRob pour votre hébergement WordPress ?
Nous ne nous contentons pas d’offrir un simple hébergement, nous optimisons en permanence notre infrastructure pour offrir une expérience fluide et sécurisée à nos clients.
Avec des règles de sécurité spécifiques, ModSecurity et fail2ban, nous assurons :
✅ Une protection proactive contre les attaques
✅ Des performances optimales pour vos visiteurs
✅ Un serveur déchargé des requêtes inutiles
Ne laissez pas des bots ralentir votre site.
Optez pour un hébergement web pensé pour la sécurité et la performance avec LRob ! 🚀
Une nouvelle menace d’ampleur inédite secoue le web : 2.8 millions de périphériques réseau compromis sont actuellement exploités pour inonder Internet de requêtes malveillantes.
Chez LRob, en tant qu’hébergeur web, nous avons observé une augmentation spectaculaire des attaques ces derniers jours. Nous vous expliquerons comment nous les bloquons efficacement.
Ces attaques ne sont pas seulement une nuisance : elles peuvent gravement impacter la performance et la sécurité de vos sites web. Quel est le fonctionnement de l’attaque ? Quel est son impact sur vos sites web ? Comment vous protéger ? Réponses.
Détails de l’attaque cyber
Découverte de l’attaque de cybersécurité
Comme nous l’indique notamment Cyber Security News dans son article, une vaste attaque par brute-force (essai de tous les mots de passe) a commencé par cibler les connexions VPN et pare-feu en utilisant 2,8 millions d’adresses IP. Une sorte de bruteforce croisé à du DDoS (Distributed Denial of Service) géant.
Détectée pour la première fois en janvier 2025 par la fondation Shadowserver, cette campagne vise les dispositifs de sécurité en périphérie, comme les VPN, pare-feu et routeurs de fournisseurs tels que Palo Alto Networks, Ivanti et SonicWall.
Les cybercriminels utilisent des réseaux de proxy résidentiels et des appareils compromis, notamment des routeurs MikroTik, Huawei et Cisco, pour mener ces attaques. Plus de 1,1 million d’adresses IP impliquées proviennent du Brésil. Suivi de la Turquie, la Russie, l’Argentine, le Maroc, le Mexique et d’autres pays comme l’Irlande selon certaines observations.
L’ensemble forme un botnet de plus en plus gros, pouvant mener diverses attaques. Et nous confirmons que cela commence à se voir côté hébergement web avec des attaques grandissantes depuis quelques jours. Il se pourrait donc que de nombreux nouveaux périphériques soient compromis.
Réaction des organismes officiels de cybersécurité
Face à cette menace croissante, les agences de cybersécurité internationales (CISA, NCSC, etc.) recommandent aux fabricants d’améliorer la sécurité par défaut de leurs dispositifs et aux entreprises de renforcer la protection de leurs accès réseau. L’utilisation de l’authentification multifactorielle (MFA), la mise à jour régulière des systèmes et la segmentation du réseau sont essentielles pour réduire les risques. Shadowserver avertit que ces attaques devraient se poursuivre, touchant d’autres fournisseurs et régions.
Propagation aux hébergements web – Observations LRob
Chez LRob, nous avons observé une augmentation des requêtes illégitimes depuis le début de l’année 2025, puis un bond drastique depuis le 8 février.
Ce 11 février, c’est le record avec +500% d’attaquants bloqués par rapport à la moyenne habituelle.
Un confrère confirme une augmentation simultanée des attaques reçues sur ses machines. Je me rapproche également d’autres confrères hébergeurs pour voir si eux aussi constatent une augmentation des attaques.
En chiffres bruts, nous avons dépassé 10.000 attaquants bloqués le mardi 11 Février 2025, soit 5x la valeur moyenne.
Concernant la charge serveur l’utilisation CPU moyenne des serveurs a augmenté d’environ 6%, passant de 14 à 20%. Si cela nous laisse 80% de marge de manœuvre, c’est déjà suffisant pour que nous réagissions (voir plus bas).
Provenance des attaques
De notre côté, les attaques proviennent de partout dans le monde et nous n’avons pas fait de statistiques précises sur la provenance, car cela demande une logistique importante pour peu de plus-value. La priorité est de bloquer un maximum d’attaques.
De plus, le type d’origine des attaques est très varié, cela vient d’IP domestiques comme d’IP en datacenter. Ce qui laisse à penser que nous avons affaire à un énorme botnet.
Concernant l’origine géographique, avec des pincettes, nous pouvons dire à vue d’œil que les attaques semblent provenir d’un peu partout dans le monde, avec la Chine potentiellement en tête (rien d’inhabituel, donc…).
Mais on observe également des attaques provenant de Singapour, du Brésil, d’Inde, du Vietnam, du Kazakhstan, Espagne, Finlande, Japon, Corée, Hong Kong, Thaïlande, Canada, USA, Géorgie, France, Italie, Royaume Uni, Bangladesh, Roumanie, Philippines…
Bref, rien ne se démarque à vue d’œil, les attaques viennent de partout, comme d’habitude.
Corrélation n’est pas causalité – Quelques réserves
Il faut concéder qu’il est impossible de faire un lien certain entre l’attaque mondiale en cours et cette augmentation d’attaques sur les serveurs web et les sites WordPress LRob. En effet, malgré la confirmation d’un confrère, l’échantillon n’est pas suffisant pour conclure avec certitude.
Cependant la corrélation reste frappante et il ne semble pas délirant de penser que les deux sont liés. Pour aller plus loin, la consultation d’autres confrères pourra nous permettre de vérifier si les attaques sont généralisées ou pas.
Les administrateurs, agences web et possesseurs de sites WordPress doivent s’interroger : “mon hébergement WordPress est-il prêt à encaisser cette vague d’attaques ?“
Que ce soit pour l’attaque actuelle ou les suivantes, si votre hébergeur web ne bloque pas ces attaques, vous pourriez rapidement en subir les conséquences :
Lenteurs : des requêtes parasites ralentissent votre site
Inaccessibilité : une saturation totale des serveurs peut empêcher toute réponse de votre site
Intrusions : une attaque réussie peut compromettre vos données et celles de vos clients
Dégradation du SEO : si un seul des points précédents se produit, cela peut dégrader fortement votre référencement
Comment protéger vos hébergements WordPress ? Méthode LRob.
LRob pratique déjà le blocage automatique des attaquants directement au niveau des serveurs. Cela réduit drastiquement la charge serveur, améliore les performances et réduit dratiquement le risque par rapport aux hébergeurs classiques. C’est selon nous la meilleure solution, testée et éprouvée depuis des années.
Un pare-feu applicatif (WAF), et de nombreuses règles de sécurité spécifiques à WordPress sont appliquées : cela permet de conserver vos sites web rapides et protégés.
Si ces sécurités sont déclenchées, alors l’attaquant est totalement bloqué du serveur. Ses attaques et requêtes n’ont alors plus aucun effet.
En bonus, on signale l’attaque sur AbuseIPDB pour aider les rares hébergeurs consciencieux à travers le monde.
Cependant, nous avons malgré cela observé une légère augmentation de 6% de l’utilisation CPU de nos serveurs, et en nombre d’attaques brutes, cela représente comme on l’a vu +500%.
En vérifiant la cause première de cette augmentation d’utilisation CPU, il s’agissait surtout de requêtes 404 (URLs inexistantes) pour environ 5%, et 1% d’autres requêtes plus complexes.
Nous avons donc pris des mesures supplémentaires pour retrouver un niveau de charge habituel. En s’ajustant ainsi, nous pouvons continuer d’assurer la performance maximale aux sites hébergés, même en cas d’accentuation de l’attaque. Nous ne sommes pas invincibles (personne ne l’est), mais nous n’avons pas à rougir face aux autres hébergeurs, bien au contraire. Et nous avons d’autres tours dans notre sac si besoin.
Nouvelles mesures de réduction du gaspillage de ressources
Certaines IP malveillantes génèrent un flot de requêtes inutiles (erreurs 404, scrapping abusif, etc.), gaspillant des cycles d’horloge processeur sans représenter une menace directe. Et le gaspillage est insupportable.
Nous avons donc mis en place une règle stricte : Les IP déclenchant trop de 404 sont désormais automatiquement bannies.
Les résultats sont immédiats :
Plus de 500 attaquants bannis grâce à cette règle en 24h
Réduction significative de l’utilisation CPU
Performance constante pour les visiteurs légitimes
Bien-sûr, nous ne pouvons pas détailler toutes les nouvelles règles publiquement, mais si vous êtes administrateur de serveur, un conseil : utilisez top/htop (en espérant que chaque site possède son propre user et FPM) et vérifiez vos logs avec de bons “grep”, et enfin, créez des jail custom sur fail2ban… Également, whitelistez les moteurs de recherche comme Google et Bing car ceux-ci déclenchent de nombreuses 404 et il serait dommage de déréférencer vos sites hébergés.
Pourquoi tous les hébergeurs n’appliquent-ils pas ces sécurités ?
La détection fine des attaques et le blocage automatique des attaquants est une solution très efficace. Pourtant, tous les hébergeurs n’appliquent pas ce genre de sécurités. Pourquoi ?
Si l’adresse IP d’un utilisateur légitime déclenche la sécurité par accident, il perd l’accès à son site. On appelle cela un “faux positif”. Et vers qui va-t-il se tourner pour diagnostiquer l’origine du blocage et se faire débloquer ? Vers son hébergeur.
A ma connaissance, à de rares exceptions près, la plupart des hébergeurs n’ont pas envie d’utiliser leur temps pour cela. Parfois ils sont même difficilement joignables. En pratique, extrêmement peu d’hébergeurs semblent appliquer ce type de sécurités.
Ne pas appliquer ces sécurités a deux effets principaux :
Pour l’hébergeur : cela réduit drastiquement le nombre d’appels et de tickets reçus… Donc les coûts. Cependant, cela augmente drastiquement la charge serveur (l’utilisation inutile de ressources). Chacun fait donc son calcul… Payer des humains, ou payer des machines… Pour beaucoup, le choix semble se tourner vers les machines. Que ceux-là n’osent pas me parler d’éco-responsabilité.
Pour les clients : cela réduit dangereusement le niveau de sécurité final de vos sites web, laissant champ libre aux attaquants et pouvant causer des lenteurs.
Chez LRob, notre but n’est pas de pratiquer des prix planchers et de vous laisser vous faire attaquer et sans support. Nous n’avons pas peur de recevoir vos tickets, emails et appels. Nous restons à votre disposition et ajustons les sécurités en fonction de vos besoins spécifiques. Ainsi, vous êtes bien protégés, conseillés, et débloqués rapidement si besoin. Choisissez votre hébergement WordPress maintenant !
Au final, quel impact pour LRob ?
Nous n’avons pour l’heure subi aucune lenteur causée par ces attaques 🚀 (car nous sommes encore très loin d’une saturation serveur grâce à un taux de remplissage raisonné et une optimisation permanente).
Aucune attaque réussie n’a été détectée. Et toujours aucun site piraté à déplorer. 🔒
Par ailleurs nous avons retrouvé nos 6% de CPU gaspillés et amélioré encore le niveau de sécurité final.
Nous restons attentifs, car la sécurité à 100% n’existe pas et personne n’est invulnérable. Nous surveillons donc en permanence les nouvelles menaces et adaptons les systèmes de défense en temps réel. Pour que votre site reste performant et sécurisé, quelles que soient les évolutions du paysage cyber. 🚀
Optez pour un hébergement WordPress sécurisé et performant
Un hébergement optimisé ne se limite pas à proposer un espace disque et une bande passante. Il doit anticiper les menaces, protéger activement votre site et garantir une rapidité d’exécution. Votre hébergeur doit aussi vous conseiller au quotidien et vous fournir un vrai support de qualité.
Avec LRob, vous bénéficiez d’un environnement conçu spécialement pour WordPress, capable de détecter, bloquer et s’adapter aux attaques. Au passage, profitez d’un des du plus hauts niveaux de performances, d’un panel simple et intuitif avec le WordPress Toolkit, et d’un support attentionné !
Les choix technologiques et matériels de votre hébergeur impactent directement les performances de votre site web. Pourtant, la plupart des hébergeurs restent vagues sur leurs infrastructures et leurs performances réelles. En tant que client, vous ne savez souvent pas ce pour quoi vous payez.
Chez LRob, nous essayons de faire mieux. Beaucoup mieux. Nous avons une approche transparente : nous mesurons, comparons et optimisons chaque paramètre, chaque choix matériel, pour garantir une vitesse de chargement jusqu’à 10x plus rapide que la concurrence. Nous tentons ainsi de vous proposer les hébergements web spécialisés WordPress les plus rapides. Et comme nous sommes fiers des résultats, nous n’avons aucun mal à vous les dévoiler.
Dans cet article, nous dévoilons donc nos benchmarks CPU et IOPS (SSD NVMe) pour vous expliquer comment nous choisissons nos serveurs. Nous vous montrerons ce qui fait vraiment la différence en matière de performances web.
Table of Contents
Quels sont les critères d’un hébergeur web performant ?
Une infrastructure web comporte plusieurs éléments. Entre logiciels, matériel, choix d’infrastructure et politique de remplissage, de suivi, de lutte anti-robots… Tout cela va impacter la vitesse finale de votre site.
Si en tant que webmaster, vous avez très certainement votre rôle à jouer dans l’optimisation de votre site web (et LRob peut vous y aider), l’hébergeur joue un rôle central et auquel vous ne pouvez pas couper.
Décortiquons ce qui compose un serveur web, et l’impact sur les performances de chaque élément. Et voyons ce qu’il en est chez LRob.
Les composants logiciels
Les logiciels d’un serveur web ne sont pas si nombreux. Leur impact peut cependant être drastique sur les performances finales.
Voici donc un résumé des différents composants logiciels et de leur impact.
Serveur front (Apache, nginx, LiteSpeed…)
Il s’agit du serveur HTTP(S) en lui-même. Il communique avec l’extérieur directement et son support de nouvelles technologies comme HTTP/3 ou la compression Brotli peuvent améliorer la vitesse de chargement des visiteurs. Les serveurs nginx et LiteSpeed sont considérés comme les plus performants, là où Apache est le plus compatible.
Chez LRob, nous combinons le meilleur des deux mondes, avec Apache en “back” et nginx en “front”, via une astuce technique assez courante appelée “reverse proxy”. Cela permet de maximiser les performances et la compatibilité en même temps, tout en ajoutant le support d’HTTP/3 et la compression Brotli et la mise en cache des fichiers, grâce à nginx.
Configuration serveur front : Au delà du support ou non des nouvelles normes HTTP comme HTTP/3, deux critères principaux se démarquent : le nombre maximal de clients connectés en simultané, durée de vie d’une connexion. Cela détermine directement le nombre de visiteurs maximal supportés. D’autres critères comme le cache de fichiers nginx peuvent rentrer en jeu.
LRob optimise intelligemment ces limites de sorte qu’elles aient la valeur maximale supportée par le matériel, sans saturer les ressources CPU ou RAM. La configuration permet également le cache de fichiers nginx en plus du cache système. Les valeurs peuvent être augmentées à la demande en fonction des cas spécifiques.
Serveur de base de données (MySQL, MariaDB)
La base de données est appelée à chaque visite de page sur le site. L’utilisation d’une version plus récente de MySQL ou MariaDB ainsi que de configurations optimisées amélioreront les performances. MariaDB est généralement considéré comme le plus libre et le plus performant. Les deux sont globalement inter-compatibles.
Actuellement, les serveurs LRob utilisent MariaDB 10.11 et MariaDB 11.4.
Configuration du serveur de base de données : MySQL et MariaDB comportent de nombreux réglages, comme la taille maximale d’une requête ou la taille du cache en RAM. Aucun hébergeur ne communique sur cela. Pourtant, de bons réglages généreux en RAM peuvent décupler les performances de la base de données.
Chez LRob, le buffer innodb est de 32Go minimum, ce qui permet d’inclure la quasi totalité des bases de données en RAM serveur pour des performances maximales.
Versions de PHP
Chaque nouvelle version de PHP est plus rapide que la précédente depuis quelques années. Si votre site et hébergeur sont compatibles, alors il faut toujours opter pour la version la plus récente pour des performances maximales.
Le handler ou “connecteur” PHP fait le lien entre le serveur front et PHP. Celui-ci peut avoir un impact drastique sur les performances. FPM et LSPHP sont les deux plus performants.
LRob utilise FPM avec une instance dédiée par site plutôt qu’une instance générale sur le serveur.
Configuration du handler PHP : Le handler PHP déterminera d’une part les limites de PHP en lui-même (par exemple la durée maximale d’exécution d’un script, ou la quantité de RAM maximale utilisable par un script), mais également le nombre de processus (threads) PHP simultanées qui peuvent tourner, qui détermine finalement le nombre de visiteurs maximal que vous pouvez servir en un temps donné – critère qui dépend aussi de la vitesse finale de votre site-.
Chez LRob, les limites PHP dépendent de votre offre d’hébergement. Elles sont indiquées en toute transparence et sont dimensionnées en cohérence avec le dimensionnement de votre offre. A noter qu’un thread PHP-FPM sur un serveur puissant pourra servir davantage de pages par seconde que sur un serveur peu performant. Ainsi, même avec l’offre initiale LRob (Starter) qui offre seulement 2 FPM, vous pouvez, avec un site bien optimisé, servir plusieurs milliers de pages par minute (plus de 7500 pages/minute).
Support de Cache RAM
Support de cache RAM (Redis, memcached) : Si votre site et votre hébergeur sont compatibles, cela peut décupler les performances de votre site en stockant vos pages et requêtes en RAM serveur.
LRob fournit un cache Redis en standard sur tous ses hébergements.
Composants hardware (matériels)
Le matériel derrière les serveurs web fait une différence majeure sur la vitesse de chargement finale. Plusieurs composants interagissent.
Le CPU
Le processeur des serveurs va directement déterminer la puissance de calcul disponible.
On peut résumer cela en 2 parties : La puissance “single thread”, la puissance “multi-thread”. Autrement dit, la quantité de travail réalisable sur une tâche seule qui s’exécute sur un seul cœur de processeur, et la quantité de travail totale réalisable sur tous les cœurs de processeur en même temps.
Grossièrement, la puissance “single thread” détermine la vitesse de votre site lorsqu’il n’y a qu’un seul visiteur, tandis que la puissance “multi-thread” détermine le nombre de visiteurs maximal que vous pouvez accueillir. A noter que lorsque vous utilisez toute la puissance “multi-thread”, vous réduisez plus ou moins la puissance “single-thread” en fonction du type de CPU utilisé, comme on le verra dans les benchmarks suivants.
En 2025, LRob choisit des processeurs 12 à 16 cores (24 et 32 threads) chez AMD qui propose les meilleures performances brutes selon nos diverses mesures.
La RAM
La RAM stocke les programmes serveur et les calculs du CPU. Plus le serveur dispose de RAM, plus il pourra contenir de cache (MySQL, Redis, nginx, fichiers) et plus il pourra faire tourner de processus PHP. Là encore, cela affecte le nombre de visiteurs simultanés maximum et les performances obtenues.
En 2025, LRob choisit des serveurs avec 128Go de RAM en standard, de quoi ne jamais être à court et profiter de mises en cache très généreuses pour éviter tout ralentissement.
L’IO du stockage
La capacité de stockage n’est pas un critère de rapidité sur un serveur web. On mesure plutôt les vitesses d’IO, c’est à dire d’input-output disque.
Toute lecture ou écriture de fichiers n’étant pas en RAM serveur utilisera de l’IO, que ce soit une requête MySQL ou la lecture des fichiers PHP et multimédia de votre site. Cela peut avoir un impact monumental sur la vitesse d’un site, surtout en ce qui concerne MySQL qui est généralement le plus sensible aux nombre d’opérations aléatoires chaque seconde (en particulier pour l’écriture, qui ne peut pas être mise en cache RAM).
Le disque dur classique est le plus lent, suivi des SSD en SATA, suivi des SSD NVMe qui sont les plus rapides. Dans le cas de serveurs virtualisés, les disques, quelle que soit leur forme, peuvent être déportés dans un SAN. Dans le cas d’un SAN, le stockage n’est alors plus local, pouvant entraîner une réduction des débits et une augmentation de la latence d’accès.
En 2025, LRob choisit exclusivement des serveurs avec SSD NVMe en RAID local (le plus rapide disponible) pour ne jamais attendre les accès disque !
Choix d’architecture informatique
Deux types de serveurs existent chez vos hébergeurs :
Les serveurs dédiés
LRob utilise uniquement des serveurs dédiés.
Les serveurs virtualisés
Un serveur dédié est une machine physique “normale” qui accueille des services.
Un serveur virtualisé, est un sous-serveur crée à partir d’une machine plus grosse. On parle de “VPS” (virtual private server) ou de “VM” (virtual machine), comportant chacun son propre système d’exploitation. Cela donne une versatilité supérieure à l’hébergeur, mais coûte plus cher en RAM, en espace disque, et une baisse de performances peut avoir lieu en raison de la virtualisation et du nombre de systèmes à faire tourner.
Ensuite, on peut déployer les serveurs de différentes manières :
Serveur LAMP (Linux Apache MySQL PHP) classique : Tout est sur la même machine (dédiée ou virtualisée)
LRob utilise uniquement des serveurs LAMP classiques et locaux sur serveurs dédiés.
Cluster : On sépare chaque applicatif sur une machine différente (dédiées ou virtualisées)
La seconde méthode est plus versatile et peut permettre de supporter de plus gros trafics totaux et peut permettre des économies d’échelle sur les gros volumes avec potentiellement une redondance de service. Mais en contrepartie, complexifie l’architecture et elle peut avoir un coût important en performances. Car comme chaque machine est séparée, cela crée une latence due au réseau et aux différents protocoles utilisés, à chaque accès fichier, à chaque requête MySQL, à chaque exécution de PHP. De plus, les matériels utilisés sont généralement des processeurs avec de nombreux cœurs (32 et plus) mais une faible performance par cœur.
Utilisés à outrance, les clusters n’ont selon LRob de réelle nécessite qu’à partir de dizaines de milliers de visites par minute, par exemple pour les réseaux sociaux ou les sites de services d’état. Pour le commun des mortels qui possède un ou plusieurs sites web, les clusters auront pour principal effet de bien souvent réduire les performance.
D’autant plus que comme vous le verrez en toute fin d’article avec un test de charge sur le site “Copines de bons plans”, on peut déjà faire plus de 12.000 visites par minute sur 2 process FPM chez LRob… Et bien plus sur les offres supérieures, pour peu que votre site soit très bien optimisé
Note : Bien que l’infrastructure LRob soit basée sur des serveurs dédiés, les offres que vous commandez sur le portail LRob sont bel et bien des offres mutualisées. Du mutualisé certes très performant, plus performant que ce que vous trouverez en VPS ou même sur serveur dédié à bas coût, mais techniquement ce sont bien des offres mutualisée, c’est à dire que plusieurs sites et utilisateurs sont sur la même machine physique.
Remplissage et blocage d’attaques : gestion de la charge serveur
La charge serveur, c’est l’utilisation moyenne de ressources des machines. Le but étant d’avoir une charge moyenne la plus faible possible, avec une réserve de ressources la plus haute possible. Cela permet que les serveurs supportent les pics de trafic, les pics de charge. Par exemple lorsque l’un de vos articles rencontre un fort succès sur les réseaux, ou qu’on parle de vous à la TV ou la radio, on cherche à tout prix à éviter la saturation serveur.
On devine bien souvent aux performances fluctuantes que les hébergeurs ont des serveurs plein à craquer, pour maximiser leur rentabilité. De plus, ils ne bloquent pas forcément efficacement les attaques de robots pirates, qui sur les sites à faible trafic peuvent représenter jusqu’à 95% de la charge. Imaginez, 95% des ressources de votre hébergement occupé par des robots… N’imaginez pas, c’est réellement ce qu’il peut se passer sans protection.
Et si la plupart des hébergeurs ne bloquent pas les robots, c’est à mon avis par choix stratégique : D’une part, cela incite les clients à passer sur serveur dédié ou offre supérieure (pour cause de lenteurs), et d’autre part, bloquer les attaques génère parfois des faux positifs, c’est à dire des clients qui se bloquent eux-même et feront donc une demande de support, que la plupart des hébergeurs n’ont pas envie de gérer.
En pratique, un serveur trop chargé comme on en voit souvent cause des lenteurs constantes ou occasionnelles sur votre site.
Chez LRob, on tente d’offrir les performances maximales à tout moment. Et pour cela, on applique une politique stricte :
On se fixe l’objectif de ne pas dépasser les 25% de charge moyenne et 50% en pic. Si cela se produit : On diminue la charge à la source (blocage d’attaques ? optimisation d’un site ?) ou on migre les sites les plus lourds et/ou populaires vers une nouvelle machine.
Blocage des attaques à différents niveaux, pour économiser jusqu’à 95% des ressources utiles, tout en protégeant vos sites web des attaques.
Limites intelligentes des process FPM, de sorte qu’aucun site ne sature les serveurs
Contact systématique des propriétaires de sites lents ou très populaires pour proposer des solutions d’optimisation des sites et ainsi réduire la charge serveur
Monitoring 24/7 des performances serveur et intervention directe en cas d’anomalie
Performances matérielles : Le gap technologique
On l’a vu, le choix du matériel peut joue un rôle drastique sur les performances. Aujourd’hui, nous allons nous focaliser sur les deux éléments essentiels pour traduire les performances d’un site web : La puissance de calcul CPU, et les performances en lecture/écriture disque (IO).
Puissance de calcul (CPU)
Nous avons mesuré un panel assez varié de serveurs afin d’avoir une idée représentative de ce que l’on peut obtenir en fonction du type de serveur choisi.
Le test du jour : Geekbench 6.4, permet de se faire une bonne idée de la puissance de calcul des machines.
Cliquez ici pour en savoir plus sur les “cores” et les “threads”.
Les “cœurs CPU” ou en anglais “CPU cores” permettent chacun d’obtenir une puissance de calcul unitaire pour un programme qui ne serait capable d’utiliser qu’un seul core. Les processeurs modernes ont plusieurs cores. Lorsque l’on utilise tous les cores en même temps, les performances par core baissent (en raison d’autres facteurs limitants, comme la consommation électrique et les températures, la vitesse de la RAM, ou la vitesse des caches internes des CPU).
Pour savoir si une application est capable d’utiliser un ou plusieurs cores, on parle d’application “monothread” ou “multithread”. Certaines applications sont entre les deux.
MySQL est multithread.
Apache et nginx sont un mix single-multithread : chaque thread correspond à un chargement de fichier ou une session HTTP.
PHP est aussi un mix single-multithread : chaque thread correspond à l’exécution d’une page PHP (si plusieurs scripts sont appelés, ils resteront enfermés dans un thread). Autrement dit, un visiteur seul ne peut utiliser qu’un core CPU à la fois.
On comprend que pour les performances maximales, il faut au minimum 2 cores, sinon tous ces programmes devront se partager un seul core de CPU. Et si vous attendez de la visite, vous avez intérêt à avoir bien plus, et à choisir des cores performants !
Voici donc les machines qui passent à la moulinette du Benchmark aujourd’hui :
VM 2 cores Intel Xeon chez PulseHeberg
VM 2 cores Intel Xeon chez Hetzner
VM 2 cores ARM chez Hetzner
VM 4 cores AMD Epyc chez Hetzner
Serveur dédié AMD Ryzen 9 3900 12 cores 24 threads chez Hetzner (serveur en production)
Les performances Single Thread, c’est à dire la puissance brute d’un seul core de processeur. Cela correspond aux performances lorsqu’une seule tâche a lieu (qui détermine la meilleure vitesse de chargement d’une seule page web lorsque le serveur est au repos).
Les performances Multi Thread, c’est à dire la puissance totale supportée. Cela impacte le nombre de visiteurs simultanés maximum.
Les performances par core en Multi Thread, c’est à dire les performances que vous pouvez espérer lorsque le serveur tourne à pleine charge. Cela est obtenu en divisant le résultat des performances Multi Thread par le nombre de cores CPU.
Les données brutes, avec en gras, les serveurs web mutualisés LRob :
Benchmark Geekbench 6.4 sur différents types de serveurs chez Hetzner et PulseHeberg
On peut tirer pas mal de conclusions.
Les performances single thread
Pour rappel, les performances en single thread vont directement affecter la vitesse perçue de votre site web. C’est le plus critique et souvent le plus négligé, car les hébergeurs classiques ont souvent tendance à choisir de très gros processeurs, avec de très nombreux cores, mais peu de performance single thread. Ainsi, ils peuvent accueillir de nombreux sites, mais individuellement, chaque site sera plus lent.
Et la différence peut être majeure, car nos mesures montrent que la vitesse va quasiment du simple au quadruple (x3.841) !
Benchmark serveurs single Thread GeekBench 6.4
Le moins performant étant le single thread sur VPS Intel chez Hetzner, le plus performant étant le single Thread sur VPS AMD R9 9900X chez PulseHeberg. Ce dernier est cependant un OVNI dans le monde des VPS, offrant des performances défiant l’entendement (et malheureusement victime de son succès depuis sa sortie, avec des stocks très limités). Nous n’en tiendrons donc pas spécialement compte pour le moment, mais cela nous donne simplement des perspectives pour l’avenir.
Petite mention pour Pulseheberg qui a le mérite d’indiquer clairement sur son site que les hôtes de virtualisation utilisent des Intel Xeon E5-2680v4 (14 cores 28 threads, 2.4-3.3Ghz).
Les VPS en processeur ARM ont de beaux restes et passent devant nos VM Intel. Ils ne battent cependant pas AMD et ses fameux Epyc, mais il faut se rappeler qu’ARM propose un gain significatif en termes de consommation, ce qui n’est pas anodin pour un datacenter.
On voit d’ailleurs que les CPU Epyc sont quasiment 2x plus performants que les CPU Intel chez Hetzner, avec à l’arrondi, x1.99 d’amélioration.
En comparant le VPS le plus lent et les serveurs dédiés LRob, on voit qu’on est à x2.33 et x3.03 de gain de performances single thread pour respectivement les Ryzen 3900 et 5950x.
En partant du meilleur CPU disponible en virtualisé (AMD Epyc chez Hetzner) et en arrivant sur les dédiés LRob, on fait encore respectivement x1.17 et x1.52 de performances. A noter que le serveur avec un Ryzen 3900 étant en production lors du benchmark, ses performances mesurées sont inférieures aux performances réelles.
Performances en multi thread
En multi, on a deux manières d’appréhender les résultats : d’une part, les performances brutes, et d’autre part voir à quel point le gain est proportionnel au nombre de cores. Avec cette dernière approche, on peut avoir une idée de la puissance et de la saturation de l’hôte des VM. Car nous ne sommes jamais seuls dessus.
Benchmark multi thread Geekbench 6.4
L’approche par “ratio”
Pour les VM 2 cores, où un score parfait serait un x2 en multi : chez PulseHeberg sur la VM 2 cores, on ne fait que x1.54 par rapport à son score single. Là où Hetzner nous fait du x1.8 sur sa VM 2 cores Intel. On peut imaginer que Hetzner a des CPU plus véloces sur ses hôtes ou un taux de remplissage moins important. De même que sur ARM avec x1.79, ce qui s’explique également par le nombre de cores importants des hôtes de virtualisation ARM.
En VM 4 cores, où un score parfait serait x4, Hetzner nous fait un respectable x3.36 sur la VM Epyc. Les CPU Epyc montant à 64 cores et plus tout en conservant une fréquence confortable, cela est très cohérent avec les attentes.
Côté dédié sur les Ryzen sélectionnés par LRob, on a du x5.3 les performances single, que ce soit sur le 3900 ou 5950x, où on s’attendrait à x12 ou x16.
Pour être exact, le 12 cores 24 threads Ryzen 3900 nous sort pile x5.3. Le 16 cores 32 threads Ryzen 5950x nous fait un x5.28. Alors pourquoi ça ne scale pas plus ? Car la fréquence CPU est fortement dynamique sur ces modèles. Ainsi, à faible charge, lorsque seulement quelques coeurs sont utilisés, on bénéficie d’une performance bien supérieure. Autrement dit, on obtient le meilleur résultat sur ces CPU en s’assurant de ne pas avoir une charge trop élevée.
En version desktop pour contrôle du 5950x (il s’avère que j’ai le même à la maison !), avec fréquence optimisée à la main, fixée à 4.4Ghz, on part d’un score single plus faible, mais en multi on fait finalement du x6.84. Résultat sensiblement supérieur au serveur, mais avec une consommation électrique également bien supérieure qui ne serait pas viable en datacenter.
Et pour la VM OVNI, la 8 cores sur Ryzen 9 9900X de PulseHeberg, celle-ci ne nous fait qu’un petit x3.89.. Mais à remettre en perspective, car les performances brutes restent exceptionnelles pour un 8 cores, dépassant le Ryzen 3900 (12 cores) et approchant les performances du Ryzen 5950x. De belles perspectives pour l’avenir.
Performances brutes
Voyons désormais la charge totale supportée par ces diverses machines.
Comparons la meilleure machine Intel dual core à nos dédiés : Le Ryzen 3900 en prod fait 6.89x le score. Le Ryzen 5950x, x8.86 le score.
Pour info, j’ai déjà vu des machines du type de ces 2 cores VM Intel héberger 50 sites sans trop de problème. Ce qui signifie qu’avec 7x les performances on pourrait héberger 350 sites. Cependant, on a fait le choix de s’arrêter autour de 200 à 250.
Face au plus véloce Epyc 4 cores : Le Ryzen 3900 en prod fait 1.86x le score. Le Ryzen 5950x fait 2.39x le score.
Performances par core
Sur les CPU de nos dédiés, les performances single core sont bien supérieures à la quasi totalité des serveurs, mais chutent en multi par rapport à ARM ou Epyc.
C’est un choix : En ne remplissant pas trop de tels serveurs, c’est ainsi que l’on obtient des performances drastiquement supérieures dans la vie de tous les jours, tout en ne s’écroulant pas totalement lors des forts pics de charges. Le but étant de faire en sorte que même les pics de charge soient sous les 50% d’utilisation totale.
Benchmark performances par core Geekbench 6.4
Donc oui, on chute en performances par core… Mais d’un autre côté, on a un bien plus grand nombre de cores ! Moralité : Pour conserver les performances maximales, il faut faire en sorte de ne jamais arriver dans ce “worst case scenario” (et c’est ce que l’on fait chez LRob !).
Performances IO (lecture/écriture)
La vitesse d’IO est la vitesse de lecture et écriture sur le disque de votre serveur. Cela a un impact pour de nombreux éléments, mais MySQL (et MariaDB) est l’élément qui bénéficie certainement le plus d’un excellent IO. Et qui dit de meilleures performances MySQL, dit un site plus rapide, un processeur qui n’attend pas pour que les opérations disque se complètent, et finalement, des performances optimales.
Pour cette partie on a simplifié les tests pour des raisons pratiques en réduisant le nombre de machines testées à celles qui sont les plus pertinentes.
On utilise le benchmark Linux “fio”. La commande de benchmark utilisée nous produit 75% de lecture et 25% d’écriture, le tout en fichiers aléatoires de 4K :
Comme beaucoup, PulseHeberg utilise probablement des SSD SATA classiques pour ses VM Intel, ce qui se traduit par le plus faible score ici. En revanche, sur les offres “Performance Cloud”, ils ont manifestement sélectionné de bons disques NVMe, prenant la tête de ce benchmark.
Côté ARM et Hetzner, on est probablement en SSD NVMe ou en SATA avec carte contrôleur RAID. Les débits sont corrects mais sans plus. De plus, si un SAN est utilisé, alors ce débit peut varier au fil de la journée.
Sur serveur dédié avec RAID de SSD NVMe local, on obtient de très solides performances. La différence entre nos deux machines est de l’ordre de la marge d’erreur, probablement due au fait que le serveur à base de Ryzen 3900 soit en prod.
En écriture (le plus critique pour MySQL), on est 8.1x plus rapides que la machine la plus lente, et 2.76x plus rapides que la VM ARM d’Hetzner (qui fait déjà un score respectable pour un VPS).
En comparaison avec la plupart des offres de VPS que vous observez, la moyenne doit se situer entre ces deux-ci, avec des serveurs LRob autour de 5x plus rapides que la norme trouvable sur les VPS.
En pratique, cela se traduit par un serveur MySQL qui exécute les tâches rapidement et n’est jamais saturé, et par conséquent, des sites toujours les plus réactifs possibles. Dans l’absolu, nous n’avons jamais observé de saturation de l’I/O disque sur une telle configuration en utilisation normale.
Comment LRob choisit-il ses serveurs ?
Bien-sûr, le critère N°1 est la performance.
Les serveurs virtuels ayant des performances trop aléatoires sont hors de question pour la production web.
Pour répondre à nos exigences, les serveurs dédiés avec SSD NVMe et 128Go de RAM sont un pré-requis indiscutable.
Concernant les CPU, on choisit ceux qui ont les meilleures performances single core, tout en offrant de solides performances en multi.
Le partenaire principal choisi pour les serveurs LRob à ce jour est l’indétrônable Hetzner qui brille par son éco-responsabilité et la qualité de son support avec une équipe dans le datacenter en 24/7.
Pourquoi ne pas choisir des processeurs Epyc ?
Cette question est légitime. Avec un Epyc 32 cores ou plus, on obtiendrait une capacité totale bien supérieure. Mais ce serait un mauvais choix stratégique pour 3 raisons :
D’une part, en charge modérée, nous obtenons de meilleures performances finales pour chacun des sites hébergés, en utilisant des Ryzen. En single core, notre 5950x est jusqu’à 1.52x plus performant qu’un Epyc.
D’autre part, il y a le coût : les machines Epyc valent bien très cher, prenant donc davantage de temps à être amorties.
Enfin, cela augmente le risque inutilement : rentabiliser une machine Epyc voudrait dire mettre énormément de sites dessus. Or, LRob pour la fiabilité et l’évolutivité, nous pensons qu’il vaut mieux avoir un peu plus de serveurs de taille moyenne que moins de gros serveurs. Au final on accueille déjà bien assez de sites sur Ryzen sans aucun ralentissement.
Pour le moment, ce n’est pas encore d’actualité, mais on garde bien-sûr un oeil sur les sorties de CPU et sur ce que les hébergeurs proposent.
Qu’en est-il du réseau ?
La consommation réseau est souvent surestimée, ou bien les lenteurs lui sont injustement attribuées. Un site lent ne signifie pas un réseau lent, les lenteurs proviennent plutôt d’un serveur lent, qui peine à générer les pages et/ou d’un site mal optimisé.
La moyenne d’utilisation réseau d’un serveur mutualisé dépasse rarement les 50Mbit/s, avec une moyenne autour de 10Mbit/s (merci aux webmasters de bien optimiser leurs sites !).
Or, tous les serveurs sont gigabit, donc 1000Mbit/s disponibles. On a de la marge… !
Au final, ce sont davantage les sauvegardes et les migrations, qui bénéficient de ces débits importants.
Quelles sont les performances chez LRob
En pratique, que donnent les performances de LRob par rapport aux autres hébergeurs ?
Sans pouvoir citer les hébergeurs source (légalement on peut être accusé de dénigrement), on peut cependant vous dire que LRob fait mieux que la quasi totalité des hébergeurs testés.
Nous avons migré des centaines de sites vers l’infrastructure LRob. Il est arrivé une seule fois que l’on observe pas de gain. Ce fut un événement historique et agaçant. Pour tous les autres cas, nous avons observé des sites qui chargent 2 à 10x plus rapidement, avec même des sites chargeant plus de 20x voire 30x plus vite après mise en place d’un cache ou réglage de celui-ci. Et le tout avec des vitesses stables au fil du temps.
Nous avons désormais une belle collection de graphiques avant/après migration dont voici un extrait :
Le site https://dreams-night.fr/ tournait à plus de 3.4s de chargement. Il s’agit d’un site SPIP. Après migration, il passe à 0.18s. Soit près de 20x plus rapide (18.88x). Le graphe n’arrive même pas à le montrer précisément, il faut alors lire “Response” en comparaison à “Avg. Response” (la réponse moyenne).
Le site https://raiddesdentelles.com/ subissait des pics de lenteurs dépassant les 5 secondes… Il est plus de 3x plus rapide après migration chez LRob, avant même l’activation d’un cache. La moyenne de temps de chargement passe à 1.2s.
A ce sjour, le site https://raiddesdentelles.com/ chez LRob a un cache Redis actif. La vitesse de chargement hors cache est toujours à 1s environ, avec un petit pic lors du renouvellement automatique du cache et un gros pic en cas de cron. En cas de fort trafic, cela reste sous les 0.1s désormais. La moyenne est à 0.2s. C’est 15 à 30x plus rapide qu’avant migration, en fonction de comment l’on compte…
Le site https://copinesdebonsplans.fr/ peinait à rester sous les 200ms de réponse moyenne. 200ms étant le seuil critique pour être favorisé par les moteurs de recherche. Après migration, il tombe à 200ms. Après la désactivation de plugins inutiles, il tombe sous les 150ms. Mais attendez de voir l’optimisation du cache…
Après optimisation du cache WP Rocket, le site https://copinesdebonsplans.fr/ descend à 76ms de moyenne. Un tel site peut, sur l’offre minimale d’entrée LRob (Starter), servir plus que les 7500 pages par minute annoncées par l’offre. Nous avons mesuré 12711 pages par minute via un test de charge.Voir le test de charge complet
root@srv01 ~ # ab -c 200 -n 10000 https://copinesdebonsplans.fr/ This is ApacheBench, Version 2.3 <$Revision: 1913912 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Server Software: nginx Server Hostname: copinesdebonsplans.fr Server Port: 443 SSL/TLS Protocol: TLSv1.3,TLS_AES_256_GCM_SHA384,4096,256 Server Temp Key: X25519 253 bits TLS Server Name: copinesdebonsplans.fr
Document Path: / Document Length: 114955 bytes
Concurrency Level: 200 Time taken for tests: 47.842 seconds Complete requests: 10000 Failed requests: 0 Total transferred: 1153600000 bytes HTML transferred: 1149550000 bytes Requests per second: 209.02 #/sec Time per request: 956.846 ms Time per request: 4.784 [ms] (mean, across all concurrent requests) Transfer rate: 23547.42 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 4 881 110.1 897 1005 Processing: 36 65 86.2 53 975 Waiting: 26 55 85.1 43 958 Total: 90 946 79.3 950 1183
Percentage of the requests served within a certain time (ms) 50% 950 66% 962 75% 970 80% 977 90% 1004 95% 1017 98% 1040 99% 1061 100% 1183 (longest request)
Au final, comment être sûr de choisir l’hébergeur le plus rapide ?
Un bon moyen est de choisir l’hébergeur capable de transparence, comme nous le faisons ici.
Nous conseillons de prendre du recul sur les idées pré-conçues, sur le marketing et de regarder les mesures, les données réelles (matériel, architecture), voire encore mieux, d’effectuer vos propres mesures.
Chez LRob, nous faisons tout ce que nous pouvons pour que chacun puisse profiter des ressources maximales pour son site, à tout moment.
Au delà des choix matériels, la politique interne joue un rôle élémentaire également :
Une bonne gestion du taux de remplissage et un blocage efficace des attaques font des miracles. Aussi, en cas de pic, nous vérifions son origine et corrigeons si nécessaire avec le propriétaire de chaque site. Oui, nous prenons la peine de les contacter un par un. Et vous savez quoi ? Ça marche ! Car chacun est toujours heureux d’accélérer son site.
Au final, nous faisons en sorte de tourner autour de 20% de charge moyenne sur les CPU et 50% en pic, ce qui laisse une marge importante pour absorber les pics d’activité sans ralentissement.
Au lieu de trop remplir chaque serveur, nous considérons que le serveur ci-dessous est presque plein, nécessitant le déploiement d’une nouvelle machine pour les futurs clients :
Charge serveur typique d’un serveur LRob en production
Si vous trouvez que cette politique transparente est idéale et souhaitez en bénéficier pour vos sites internet, réservez dès maintenant votre hébergement LRob ! Et soyez parmi les premiers à profiter d’un hébergement sur un Ryzen 9 5950X avec SSD NVMe local !
Découvrez WPMasterToolKit : le plugin indispensable pour vous simplifier la vie et alléger vos sites WordPress.
Ce plugin made-in France, développé par le talentueux Ludwig YOU de Webdeclic, regroupe une multitude de fonctionnalités essentielles de WordPress, que vous pouvez chacune activer en un clic. Le tout en une seule extension : de quoi simplifier votre gestion tout en accélérant votre site ! 🚀
Un plugin vraiment différent
WPMasterToolKit est simple et flexible. Avec déjà plus de 83 fonctionnalités gratuites activables, ce plugin vous permet de remplacer d’innombrables extensions par une seule.
Ce qui rend WPMasterToolKit unique, outre le fait d’être français, c’est sa capacité à activer uniquement les fonctionnalités dont vous avez besoin, sans alourdir inutilement votre site. Là où d’autres extensions sont monolithiques, chargeant des scripts inutiles même lorsque vous ne les utilisez pas, WPMasterToolKit est conçu pour être léger et efficace.
Si une fonctionnalité est désactivée, le programme associé ne se charge pas du tout. Ainsi, vous allégez l’utilisation de ressources de votre site et améliorez ses performances, en ne chargeant que les fonctionnalités dont vous avez réellement besoin.
D’autres fonctionnalités sont sur le feu, et quelques unes sont disponibles en premium pour pérenniser le projet.
Le développeur, Ludwig YOU, est très à l’écoute des suggestions et améliore activement son plugin. Avec notamment l’ajout récent d’un onglet permettant de voir d’un coup d’œil les fonctionnalités actives.
Fonctionnalités phares de WPMasterToolKit
WPMasterToolkit : Modules actifs sur le site LRob.fr
Voici quelques-unes de mes fonctionnalités préférées jusqu’à présent :
1. Cacher la version de WordPress
Cacher la version de WordPress affichée dans le code source est une excellente mesure de sécurité. Cela réduit les chances que votre site soit ciblé par des attaques automatisées visant des versions spécifiques de WordPress.
2. Limitation des révisions
La gestion des révisions de contenu est un point souvent négligé qui peut rapidement surcharger la base de données. WPMasterToolKit permet de limiter le nombre de révisions par article, ce qui aide à garder la base de données propre et performante.
3. Désactiver le support des emojis
Les emojis sont utiles pour certains sites, mais la plupart des navigateurs modernes supportent déjà nativement ces symboles. Désactiver leur prise en charge au niveau de WordPress permet d’alléger le chargement des pages.
4. Désactiver les balises Really Simple Discovery (RSD)
En désactivant le chargement des balises RSD (et des scripts comme Dashicons pour les visiteurs non connectés), vous pouvez réduire le temps de chargement de vos pages publiques, particulièrement si votre site n’utilise pas de services tiers qui nécessitent ces éléments.
5. Désactiver jQuery Migrate
Si votre site utilise des versions récentes de jQuery, le script jQuery Migrate devient inutile et peut être désactivé pour améliorer la vitesse de chargement des pages.
D’autres fonctionnalités intéressantes
Outre ces fonctionnalités favorites, WPMasterToolKit propose également une panoplie d’outils qui facilitent la gestion quotidienne de votre site. Parmi les plus populaires, vous trouverez :
Auto-publication des articles manqués : publie automatiquement les articles qui ont raté leur date de planification.
Gestion du SMTP : Se connecte à un serveur SMTP tiers pour relayer plus fiablement vos emails.
Désactivation des API REST pour les utilisateurs non authentifiés : améliore la sécurité en limitant l’accès aux données via l’API REST.
Ban d’emails : bloque la création de comptes utilisateurs avec des adresses email temporaires ou non autorisées.
Mode Maintenance : affiche une page de maintenance personnalisée pendant vos travaux sans gêner les administrateurs.
Redirection des 404 vers la page d’accueil : améliore l’expérience utilisateur en redirigeant les pages inexistantes vers la page d’accueil.
Et bien d’autres encore… L’idéal reste d’explorer et de tester par vous-même ! Qui sait, vous pourriez remplacer des dizaines de plugins !
Une boîte à outils WordPress essentielle qui gagnera à être connue
Avec ses multiples fonctionnalités personnalisables, vous avez tout sous la main pour mieux personnaliser et contrôler votre site, améliorer ses performances et renforcer sa sécurité.
Le plugin, encore récent compte à l’heure où j’écris ces lignes +500 installations active. Pour moi, ce plugin est un véritable game changer et je suis convaincu qu’il dépassera le millier bien avant la fin de l’année, et que sa popularité explosera ensuite.
Trouver le meilleur plugin de cache n’est pas évident. Il faut le tester, mesurer les performances, connaître son support à long terme…
Alors quel est le cache le plus rapide ? Quel est le meilleur plugin de cache ? Lesquels sont pratiques et complets, lesquels sont performants ? A-t-on besoin de payer pour un bon plugin de cache ?
Aujourd’hui, on tente de répondre à ces questions avec des mesures indépendantes et les plus objectives possibles. Le test est un peu “meta” car il porte sur essai sur lrob.fr, une vitrine/blog réalisée avec FSE (full site editing). Un site standard et léger.
Sommaire
Introduction
L’objectif d’un plugin de cache : tomber sous 200ms de temps de réponse ou “TTFB” (Time To First Byte, 200ms est le temps maximum préconisé par Google PageSpeed Insights).
Mais tous les cache ne se valent pas, comme le rappelle Yoan De Macedo dans son article de blog. Certains sont plus performants et d’autres dégradent même parfois les performances. Alors pour vraiment choisir le meilleur cache, il reste nécessaire d’en tester plusieurs sur son propre site et de mesurer précisément les résultats. En raison de la variabilité du temps de réponse, il est important de faire des tests sur une certaine durée et de moyenner les résultats. Cela peut cependant être fastidieux, alors vous pouvez choisir de vous baser sur ce test comparatif pour commencer à y voir plus clair.
On rappelle aussi que le cache ne fait pas tout. Le cache permet d’alléger les ressources serveur, mais votre site doit être optimisé à la base. Sinon cela s’appelle un “cache-misère”. Privilégiez donc les plugins et thèmes légers et bien optimisés pour éviter les mauvaises surprises. Le cache sera alors la cerise sur le gâteau.
Plugins testés
Je me suis basé sur un “top” des plugins de cache ainsi que sur mon expérience des plugins réellement rencontrés chez les différents clients hébergés pour établir cette liste des plugins à tester :
Ce test réalisé par LRob n’est aucunement sponsorisé par un quelconque plugin de cache. Il a vocation à être le plus objectif possible. Cependant, ce test n’est que le reflet de lui-même et de notre avis qui ne saurait être parfaitement objectif et n’a donc pas vocation à produire des vérités générales. LRob est un hébergeur web indépendant spécialiste de WordPress.
Détails du site web
Le test est réalisé sur https://www.lrob.fr/. La fonction WP-Cron est désactivée et est exécutée directement par le serveur toutes les 4 minutes. Le site tourne sous PHP 8.3.12 en FPM dédié derrière Apache 2, avec MariaDB 11.4. Redis server est également disponible sur le serveur hôte (version 5:6.0.16).
Thème
Le site est réalisé avec FSE et le thème Twenty Twenty-Four
Plugins
Le site comporte 17 plugins actifs au moment du test (sans compter le plugin de cache testé) :
Voir la liste des plugins
Comment Blacklist Updater
Complianz | GDPR/CCPA Cookie Consent
Connect Matomo
Easy WP SMTP
hCaptcha for WP
Insert PHP Code Snippet
Optimize Database after Deleting Revisions
Rank Math SEO
Regenerate Thumbnails
Simple Local Avatars
Site Reviews
Social Sharing Block
TranslatePress – Developer
TranslatePress – Multilingual
Update URLs
WPForms Lite
WPMasterToolKit
Mesures et détails
La mesure du temps de réponse est effectuée avec Uptime Kuma sur un serveur chez PulseHeberg en Suisse (Lausanne), qui fournit cette moyenne. Le serveur en production est situé en Allemagne chez Hetzner à Falkenstein.
Chaque plugin est testé successivement, avec une mesure toutes les 20 secondes pendant 5 minutes ou plus (parfois je suis allé me faire un café entre temps), soit minimum 15 mesures pour obtenir une moyenne cohérente.
Entre chaque test, les valeurs enregistrées d’Uptime Kuma sont effacées après une première mesure une fois que le cache est mis en place; le dossier de cache est supprimé et il a été vérifié que le .htaccess et wp-config.php sont bien exempts de toute trace du précédent plugin.
Limites du protocole
Le test est fait sur un serveur en production, générant une variabilité des résultats légèrement supérieure à celle observée sur un serveur sans activité. Cependant, l’utilisation serveur est très modérée au moment du test et la variabilité est compensée par une série de plus de 15 mesures à chaque fois qui permet de moyenner les résultats. Le but n’est pas d’avoir la valeur à la milliseconde près, mais d’obtenir un ordre de grandeur.
Par ailleurs, le test est fait sur un site spécifique et ne peut pas être extrapolé à l’ensemble des sites : chaque site est différent et régira différemment à certains plugins (en particulier les boutiques). Mais si votre site est fait avec le thème Twenty Twenty-Four ou un autre thème FSE (Full Site Editing), alors il y a fort à parier que vos résultats soient similaires.
Tests et Benchmarks
Baseline – Test contrôle : Réponse sans plugin de cache
Sans aucun plugin de cache, le site répond en moyenne en 379ms avec une faible variabilité. Cette valeur est relativement faible de base, puisque les sites faits avec des builders peuvent facilement prendre 2 à 4x ce temps de réponse.
Temps de réponse sans cache
Voyons comment s’en sortent les différents plugins de cache pour améliorer ce temps de réponse.
Autoptimize
Autoptimize Réglages 1Autoptimize Réglages 2Temps de réponse Autoptimize : 379ms
Réponse moyenne : 379ms
Le temps de réponse est identique au site sans cache. Et pour cause, la fonction de cache de Autoptimize n’est en fait disponible qu’avec le plugin payant. Autrement dit, vous n’accélérerez pas votre site en version gratuite avec ce plugin. Dommage.
Cependant, comme le précise le développeur Simon JANVIER, Autoptimize, en version gratuite, est davantage utile pour la concaténation et minification intelligente des scripts. Sur ce point, il peut alléger votre site, mais cela n’améliorera pas le TTFB (temps de réponse) de votre site.
Breeze
Contrairement à ce que je pensais initialement, Breeze n’est pas réservé à Cloudways ou à Varnish, il fonctionne également sur un système classique. Je l’ajoute donc à ce test et je remercie Michael GOUT d’avoir porté ce plugin à mon attention.
Réglages Breeze 1Réglages Breeze 2
Temps de réponse Breeze : 98ms
Réponse moyenne : 98ms
Le résultat est bluffant : on tombe sous les 100ms avec une très bonne stabilité des temps de réponse ! Je découvre ce plugin et j’en tombe de ma chaise !
J’émets une petite réserve sur la compatibilité du plugin avec tous les sites en raison des commentaires sur wordpress.org. A la lecture de ces commentaires, il semble que son utilisation pourrait poser quelques soucis avec les sites les plus dynamiques ou complexes, comme les e-commerce WooCommerce.
Pour le reste, il semble être un excellent choix à ne surtout pas manquer.
Cachify
Cachify propose par défaut une mise en cache en base de données et supporte également un cache par fichiers et par Redis. Nous avons testé le cache par défaut et Redis. En dehors de cela, très peu de réglages nous sont disponibles.
Réglages Cachify “Database”Temps de réponse Cachify “Database” : 257msRéglages Cachify “Redis”Temps de réponse Cachify “Redis” : 263ms
Réponse moyenne : 260ms
Les résultats sont similaires entre le cache “Database” et Redis, on est dans la marge d’erreur. Les résultats semblent cependant plus stables avec Redis. Le résultat dépasse dans tous les cas les 200ms escomptées, ce qui est donc décevant. Ce plugin ne peut pas vraiment être recommandé.
LiteSpeed Cache
LiteSpeed Cache a beaucoup fait parler de lui récemment pour ses failles de sécurité. Le plugin prétend correspondre également à un serveur Apache. Alors comment s’en sort-il en pratique ?
Un résultat décevant pour LiteSpeed cache sur notre configuration de test, puisque le site est dans la marge d’erreur du temps de réponse original du site, sans cache.
Et pour cause, comme le relève Louis Chance, LiteSpeed, comme son nom l’indique, n’apporte aucun cache sur un serveur Apache ! Il faut forcément un serveur LiteSpeed disponible. Impossible de recommander ce plugin si vous tournez sous Apache, étant donné les performances obtenues et les multiples failles de sécurité récentes.
W3 Total Cache
W3 Total Cache offre un assistant de configuration et de nombreux réglages. C’est le plugin gratuit le plus complet que je connaisse. Il supporte différents types de cache dont Redis. Ici, la minification a été activée, ce qui peut augmenter légèrement le temps de réponse mesuré mais offre de meilleures performances pour les visiteurs à la connexion plus lente (mobiles, ADSL, etc.).
Réglages W3 Total Cache 1Réglages W3 Total Cache 2Réglages W3 Total Cache 3Réglages W3 Total Cache 4Réglages Minifcation W3 Total CacheTemps de réponse W3 Total Cache : 159ms
Réponse moyenne : 159ms
Enfin un résultat sous les 200ms ! Avec Redis, donc en évitant des milliers de fichiers de cache. Et un grand contrôle sur les réglages et des options comme le Lazy Load des images, et la désactivation de certains scripts optionnels de WordPress. Sa configuration versatile permettra de s’adapter plus précisément à chaque site : vous pourrez mesurer les performances obtenues avec différents réglages et choisir les plus pertinents pour votre site spécifique.
Par ailleurs, les autres types de cache disponibles sont également performants, bien que non testés aujourd’hui, les résultats sont assez similaires quel que soit le type de cache choisi.
Ce plugin n’a jamais déçu selon notre expérience est donc tout à fait recommandable. (C’est même le choix de LRob.fr)
WP Fastest Cache
Ce plugin offre des options intéressantes en version gratuite. Certaines options offertes gratuitement avec W3 Total Cache manquent cependant à l’appel.
Mais le plus important aujourd’hui : ce plugin porte-t-il bien son nom, en étant réellement le plus rapide ?
Ce plugin porte assez bien son nom, c’est effectivement l’un des plus rapide testés ! Sur notre test, Breeze arrive cependant en tête.
Chez LRob, nous avons vu plusieurs blogs divers et variés obtenir de très bons résultats avec ce plugin. Il n’a jamais déçu, et nous le recommandons sans hésiter.
WP-Optimize
WP-Optimize n’offre que très peu de réglages de cache. Car en réalité, sa fonction première semble plutôt être le nettoyage de la base de données. Alors comment s’en sort-il en cache ?
Réglages WP-OptimizeTemps de réponse WP-Optimize : 152ms
La variabilité du temps de réponse est trop élevée à notre goût avec des réponses oscillant entre 132 et 180ms.
Néanmoins, la moyenne reste très bonne avec 152ms. Une bonne surprise.
Nous ne sommes pas du tout rassurés par cette variabilité et ne recommandons donc pas ce plugin en tant que cache. D’autant plus que nous avons déjà observé des sites plus lents avec ce plugin que sans… A utiliser donc avec précaution en tant que cache.
Solid Performance
En bonus, je vous propose de tester un nouveau plugin de cache, Solid Performance, qui semble prometteur. (merci à Julien ROUSSEL pour la recommandation).
Réglages Solid PerformanceTemps de réponse Solid Performance : 155ms
Réponse moyenne : 155ms
Si celui-ci ne fournit strictement aucun réglage, son temps de réponse mesuré figure parmi les meilleurs de ce test. De quoi potentiellement satisfaire ceux qui n’ont pas envie de faire le moindre réglage. Le plugin étant jeune, il n’a pas encore été éprouvé, néanmoins un plugin de cache se change facilement si besoin dans la plupart des cas, il n’y a donc pas trop de risque à l’essayer si le cœur vous en dit !
Résumé des résultats et conclusion
Plugin
Réponse moyenne (ms)
Pourcentage (lower is better)
Baseline (pas de cache)
379
100%
Autoptimize
379
100%
Breeze 🥇
98
25.8%
Cachify Database
257
67.8%
Cachify Redis
263
69.4%
LiteSpeed
376
99.2%
W3 Total Cache Redis 🥉
159
41.9%
WP Fastest Cache 🥈
123
32.4%
WP-Optimize
152
40.1%
Solid Performance
155
40.9%
Nous pouvons sans hésiter recommander Breeze, WP Fastest Cache et W3 Total Cache qui sont tous les trois excellents. Ils proposent de très bon temps de réponse avec suffisamment de réglages, même en version gratuite. A noter toutefois que Breeze pourrait poser quelques soucis sur certains sites. Aussi, W3 est toutefois un peu plus complet en gratuit que WP Fastest Cache, raison pour laquelle il a été choisi pour LRob.fr, mais Breeze pourrait potentiellement le remplacer à terme, car il fournit presque autant de fonctionnalités tout en étant plus simple d’utilisation.
En résumé, selon notre test :
Choisissez Breeze pour la performance max, plutôt pour les sites vitrine
Choisissez W3 Total Cache pour le plus haut niveau de personnalisation ou si votre hôte supporte Redis (c’est le cas des hébergements LRob)
Choisissez WP Fastest Cache pour d’excellentes performances sans configuration
Mention pour WP-Optimize qui malgré son manque de réglages et sa grande variabilité de temps de réponse montre un temps de réponse moyen tout à fait correct. Mention également pour Solid Performance qui, nouvel arrivant, porte bien son nom et semble prometteur sans pour autant révolutionner quoi que ce soit, en l’état, dû à son manque de réglages. Cachify montre des réglages et des performances inférieures aux autres plugins. Nous ne pouvons pas nous prononcer sur LiteSpeed dans notre configuration Apache (si ce n’est que son intérêt est donc très limité dans ce type de configuration). Autoptimize enfin, n’apporte aucune amélioration sur les temps de chargement et est donc totalement inutile à cet effet, selon nos mesures, mais pourrait être utilisé en conjonction avec un plugin de cache pour réduire le nombre de fichiers.
Vu les bons résultats obtenus avec ces plugins gratuits, il ne semble donc pas indispensable de payer pour un plugin de cache si vous n’avez pas besoin des fonctions additionnelles proposées. Nous pourrions cependant tester les versions payantes dans un futur article, si cela vous intéresse.
On rappelle bien-sûr qu’un hébergement performant est indispensable pour obtenir les meilleurs temps de réponse. Pour cela, les hébergements LRob sont là pour vous servir (dans tous les sens du terme) !
Il est temps de dénoncer une organisation – SPFBL.net – qui, bien qu’elle prétende lutter contre le spam, semble en réalité adopter des pratiques contraires à cet objectif. Au lieu de remplir son rôle, ce prestataire semble profiter de sa position pour mener des pratiques absolument scandaleuses et inacceptables.
Toutes les RBL ne sont pas gérées de manière éthique. L’exemple du jour est celui de SPFBL.net, une RBL brésilienne née en 2015(source MXToolbox), qui est de plus en plus mise en lumière pour ses pratiques largement contestables.
Info : Qu’est-ce qu’une RBL ?
Une RBL (Real-time Blackhole List) est une liste d’adresses IP suspectées d’envoyer du spam ou d’autres contenus malveillants. Les serveurs de messagerie s’appuient sur ces listes pour bloquer ou filtrer les e-mails potentiellement dangereux.
Dans cet article, nous allons décortiquer cette situation et expliquer pourquoi les pratiques de cette entreprise sont non seulement douteuses, mais potentiellement nuisibles à l’ensemble de l’écosystème internet si des administrateurs décident d’utiliser cette RBL. Nous verrons également comment combattre ces pratiques.
L’avis des utilisateurs et fournisseurs de services confrontés à la blacklist SPFBL
Commençons par montrer l’avis général ressortant de cette blacklist. Une rapide recherche sur les moteurs de recherche montre que les forums (en anglais) sont remplis de personnes criant au scandale et à l’arnaque au sujet de SPFBL.net.
Pour avoir contacté leur support (je vous détaille cela ensuite), je serais plutôt de leur avis… Jugez par vous-même.
“I contacted the operator of this spfbl.net and he threatened me with getting my IP’s blocked throughout the internet, how can something like this be allowed to happen.”
“We got flagged because we don’t have a contact email in our whois record (we have privacy turned on for it). Given that google.com also has that, I conclude that these guys are just a scam who want to be paid to have your domain unrestricted.”
Le cas LRob : une blacklist manifestement injustifiée
Le serveur d’infrastructure LRob est un exemple parfait d’un système configuré et géré avec soin depuis plusieurs années. En tant qu’administrateur système de ce serveur, je peux affirmer avec certitude qu’aucun spam n’a jamais été envoyé depuis cette machine. De plus, tous les paramètres essentiels sont correctement mis en place : Hostname, rDNS, MX, SPF, DKIM, et DMARC.
Malgré ces mesures exemplaires de conformité, l’IPv6 du serveur s’est retrouvée sur la liste noire de SPFBL.net.
A domain is considered non-compliant when the WHOIS search result for that domain does not contain the email address of the domain owner. Update the registration data and remove privacy protection for this domain in WHOIS and wait one hour for the cached result of this WHOIS query to expire.
This IP was flagged due to misconfiguration of the e-mail service or the suspicion that there is no MTA at it.
For the delist key can be sent, select the e-mail address responsible for this IP:
add a PayPal user’s email for 2.00 USD.
The rDNS must be registered under your own domain. We do not accept rDNS with third-party domains.
Résumé des échanges avec le support de SPFBL.net
J’ai bien-sûr contacté la RBL pour vérifier si j’avais bien compris leur politique et s’il était possible de discuter en bonne intelligence. Résultat : oui, j’avais bien compris, et non, il ne me semble pas possible de discuter en bonne intelligence avec eux en l’état.
Voici un résumé ChatGPT des échanges par mail :
Demande initiale (Robin) : Robin, administrateur système, a contacté SPFBL pour demander de l’aide concernant la suppression de son adresse IPv6 de leur liste noire DNS. Il souhaitait obtenir des précisions sur les raisons de l’inscription et des conseils pour corriger d’éventuelles mauvaises configurations, suspectant un lien avec la protection de la confidentialité WHOIS.
Réponse (Leandro) : Leandro, de SPFBL, a répondu en demandant à Robin de retirer temporairement la protection de la confidentialité WHOIS afin de pouvoir retirer l’IP via leur outil de suppression en ligne.
Préoccupations (Robin) : Robin a exprimé des inquiétudes quant à l’exigence de retirer la protection de la confidentialité WHOIS, invoquant les réglementations du RGPD. Il a remis en question la nécessité d’exposer des données personnelles, soulignant qu’aucun rapport d’abus n’avait été émis sur son domaine.
Explication (Leandro) : Leandro a expliqué que leur système utilisait les données du propriétaire du domaine pour prédire le spam et associer des domaines sous le même titulaire. Il n’a pas fourni d’autres justifications pour cette politique.
Objection (Robin) : Robin a contesté l’utilité des informations WHOIS pour évaluer le comportement d’une IP, qualifiant la politique de SPFBL de contre-productive. Il a réitéré que son IP ne présentait aucun risque et a demandé sa suppression de la liste noire.
Options (Leandro) : Leandro a proposé deux options pour la suppression : retirer temporairement la protection WHOIS ou payer des frais.
Réponse ferme (Robin) : Robin a fermement rejeté les deux options, qualifiant cette pratique de malhonnête et assimilable à une escroquerie. Il a souligné que son IP était conforme et a menacé de prendre des mesures légales si le problème n’était pas résolu.
Réponse finale (Leandro) : Leandro a rejeté les menaces légales de Robin, affirmant que SPFBL respecte les lois américaines et l’invitant à poursuivre toute action légale qu’il jugerait appropriée.
Dernier avertissement (Robin) : Robin a rappelé que l’internet est un système global et qu’aucune localisation ne justifie de nuire à des entreprises légitimes à travers des pratiques éthiques douteuses. Il a confirmé son intention de prendre les mesures nécessaires, en précisant que ses contacts identifieraient les autorités locales compétentes si nécessaire.
Ces échanges ont eu lieu entre le 8 et le 9 septembre 2024.
Par ailleurs, je dispose d’un log qui montre qu’ils ont tenté d’envoyer un mail à une adresse inexistante pour test, pouvant vérifier par eux-même la bonne configuration du serveur qui a donc rejeté ce mail :
Oct 9 14:55:13 ds postfix/smtpd[899530]: connect from matrix.spfbl.net[54.233.253.229]
Oct 9 14:55:14 ds postfix/smtpd[899530]: NOQUEUE: reject: RCPT from matrix.spfbl.net[54.233.253.229]: 550 5.1.1 <inexistent-feature-check-192715907d9@lrob.net>: Recipient address rejected: User unknown in virtual mailbox table; from=<admin@spfbl.net> to=<inexistent-feature-check-192715907d9@lrob.net> proto=ESMTP helo=<matrix.spfbl.net>
Oct 9 14:55:14 ds postfix/smtpd[899530]: disconnect from matrix.spfbl.net[54.233.253.229] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4
Oct 9 14:55:14 ds psa-pc-remote[2023328]: Message aborted.
Le cas SPFBL.net : une pratique abusive
Le cas de SPFBL.net met en lumière des pratiques alarmantes qui vont à l’encontre de la protection des données et des standards éthiques que de nombreuses autres RBL respectent.
En particulier, cette RBL blacklist des IP selon des critères abusifs, puis impose des conditions très problématiques pour le délistage d’adresses IP.
Décortiquons les “règles pour un délistage gratuit” selon la politique affichée sur leur site le 9 Septembre 2024, qui nous informe également sur les raisons possibles au blacklistage initial :
Only IP with rDNS pointing to the same mail server IP will be accepted, with FCrDNS validation;
❌ Ce critère est certes standard, mais cette vérification devrait être effectuée par le serveur destinataire de l’e-mail, pas par une RBL, qui ici n’apporte aucune valeur ajoutée.
The rDNS must be in the domain of the MTA administrator, so third-party domains such as the generic rDNS of the data-center or ISP will not be accepted, and its TLD cannot be free and must have a public and accessible WHOIS without privacy obfuscation;
❌ L’administrateur peut très bien infogérer les mails d’un tiers, comme dans mon cas où le MTA est “lrob.net” et l’administration est faite via “lrob.fr”. Cela ne devrait pas justifier un blocage. ❌ Bloquer les rDNS génériques peut être une bonne pratique, mais cela relève du serveur destinataire, pas d’une RBL. ❌ Exiger un WHOIS public contrevient au RGPD en Europe. Le droit d’envoyer des mails ne devrait pas dépendre de la visibilité des informations personnelles dans le WHOIS.
The postmaster account must be configured for the domain registered on the rDNS and the account must be active and responding;
❌ Les rDNS sont souvent des sous-domaines techniques, comme “ds.lrob.net”. Avoir une adresse e-mail du type “postmaster (at) ds.lrob.net” n’a aucun sens. Le postmaster peut être contacté via d’autres canaux plus appropriés, comme un formulaire de contact ou une adresse principale.
If you are using an IPv6 with SLAAC flag, you must keep port 25 opened to proof the existence of an active SMTP service and
❌ Bien que le serveur doive effectivement écouter sur le port 25 pour assurer le bon fonctionnement du SMTP, c’est encore une fois au serveur destinataire de vérifier cela, pas à une blacklist de le contrôler.
Reputation of IP should be below 25% of negative points per total send volume
✅ Ce critère est cohérent avec le principe même d’une RBL, qui évalue la réputation d’une adresse IP en fonction de son comportement réel.
Voyons aussi les conditions payantes :
Only static IPs with configured mail server reverse, even if FCrDNS is invalid;
❌ Sous prétexte de payer, on permettrait d’avoir un rDNS invalide, ce qui est contraire aux normes de configuration des e-mails. C’est un contournement des bonnes pratiques, qui pourrait permettre l’envoi de courriers mal configurés.
A PayPal account is required for the email address of this account to be assigned to the IP, as responsible for the abuse;
❌ Forcer l’utilisation de PayPal pour attribuer une adresse IP à un compte est une restriction injustifiée. Cela limite les options des utilisateurs et n’a aucune raison légitime dans un cadre technique.
The PayPal user must agree to have their email address shown publicly on this platform as responsible for the abuses of that IP and
❌ Exposer publiquement l’adresse email associée au compte PayPal est une atteinte à la vie privée et peut entraîner des risques de harcèlement ou d’abus. Cela va clairement à l’encontre des principes de confidentialité.
Reputation of IP should be below 25% of negative points per total send volume.
✅ Ce critère est acceptable et s’aligne avec le principe d’évaluation de la réputation d’une adresse IP sur la base de son comportement effectif, comme attendu d’une RBL.
En somme, cette blacklist me semble tenter de réinventer la roue avec des règles de blocage qui ne font strictement aucun sens d’un point de vue technique.
Quand aux conditions de délisting, même dans sa version payante, les conditions restent abusives. De mon point de vue, cela devrait déjà, à ce stade, avoir dissuadé tout sysadmin d’utiliser cette RBL.
Le but semble bien-sûr être de faire du profit sur le dos des utilisateurs tout en récupérant des données personnelles.
Résumé des problèmes de SPFBL.net
Plusieurs problèmes majeur remettent en question le bienfondé de leurs pratiques et leur impact négatif sur les entreprises légitimes.
Voici les principaux points à retenir :
Exposition des données privées WHOIS SPFBL.net exige que les administrateurs retirent la protection de leur WHOIS pour être retirés de leur liste noire. Cela signifie que des informations personnelles et sensibles, comme l’adresse email du propriétaire du domaine, doivent être publiquement accessibles pour que l’adresse IP ne soit plus blacklistée. En Europe, cette demande est en totale contradiction avec le RGPD (Règlement Général sur la Protection des Données), qui garantit la protection des données privées des utilisateurs. Les informations contenus dans le WHOIS sont privées par défaut depuis plusieurs années. Cette exigence exposerait les administrateurs système et les entreprises à des risques d’abus ou de spams ciblés, ce qui est contraire aux bonnes pratiques en matière de sécurité et de confidentialité.
Paiement pour la délistage En plus de la suppression de la protection WHOIS, SPFBL.net propose également une alternative : payer 2 dollars pour retirer une adresse IP de la liste noire. Cette pratique est perçue par beaucoup comme une forme de chantage. Exiger un paiement pour rétablir la légitimité d’une adresse IP, alors qu’il n’y a aucune preuve d’activité suspecte ou malveillante, remet en question la transparence de leurs opérations. Cette approche pousse probablement de nombreuses entreprises légitimes à payer simplement pour éviter les désagréments causés par le blacklistage.
Un modèle de détection inefficace Regrouper les domaines en fonction des informations WHOIS ignore les réalités du web moderne, où de nombreuses entreprises légitimes utilisent des infrastructures partagées, hébergées par des fournisseurs comme Google ou OVH. En conséquence, des adresses IP pourraient être injustement blacklisted simplement parce qu’elles partagent un propriétaire de domaine avec d’autres utilisateurs, sans considération pour leur comportement réel.
Un impact potentiel très grave
Les conséquences de ces pratiques sont nombreuses et graves pour l’écosystème internet :
Impact sur les entreprises : Lorsqu’une adresse IP est bloquée à tort, cela peut affecter la capacité d’une entreprise à communiquer par e-mail avec ses clients, partenaires ou prestataires. Les erreurs de détection ou les exigences abusives peuvent ainsi perturber le bon fonctionnement d’une entreprise.
Chantage et extorsion : Demander de l’argent pour supprimer une adresse IP d’une liste noire sans preuve d’activité malveillante s’apparente à de l’extorsion. Cette approche nuit gravement à la confiance entre les fournisseurs de services internet et leurs clients.
Violation de la confidentialité : En demandant la suppression de la protection WHOIS, SPFBL.net viole les principes fondamentaux de la protection des données personnelles, particulièrement en Europe, où le RGPD (Règlement Général sur la Protection des Données) protège les informations privées des utilisateurs. En exposant ces données, SPFBL.net expose les administrateurs système et les entreprises à des risques d’abus.
Que faire en tant que fournisseur de services sur internet ?
1. Cessez d’utiliser cette RBL immédiatement
Nous devons tous enjoindre nos relations chez les grands fournisseurs de services à ne surtout PAS utiliser cette RBL.
Il est absolument indispensable que les fournisseurs de services internet cessent d’utiliser SPFBL.net et d’autres RBL qui ne respectent pas les standards éthiques. Une autre RBL de ce type est également UCEPROTECT qui blacklist des blocks d’IP complets et demande ensuite de l’argent à chacun des usagers des IP pour les débloquer.
L’utilisation d’une RBL douteuse peut entraîner des conséquences néfastes pour les utilisateurs finaux, les entreprises et l’ensemble de l’écosystème numérique.
Il existe de nombreuses alternatives respectables qui se concentrent sur la détection des activités malveillantes en se basant sur des comportements réels, et non sur des informations privées ou des regroupements arbitraires de domaines. Les administrateurs système doivent rester vigilants et choisir des solutions qui respectent la vie privée et qui suivent des pratiques équitables et transparentes.
2. Ne cédez pas
Si comme moi vous êtes victime de cette RBL et estimez que ces pratiques sont abusives, ne cédez surtout pas aux prérequis scandaleux de cette RBL. Au contraire, battez-vous à mes côtés.
3. Dénoncez ces pratiques aux autorités compétentes
Faites jouer vos relations pour que cela remonte aux CSIRT français (Computer Security Incident Response Team), à l’ANSSI mais également à la CNIL pour non respect de la RGPD. Si vous avez des contacts au niveau européen, relayez l’info. Si vous êtes en dehors de France ou d’Europe, contactez les organismes à votre portée, et n’hésitez pas à vous appuyer sur cet article pour expliquer le problème.
Si vous n’avez pas de contact mais que vous comprenez l’enjeu, relayez également l’info à des personnes du domaine de l’hébergement et du sysadmin web.
Conclusion
L’affaire SPFBL.net est un exemple flagrant des dangers des pratiques douteuses de certaines RBL.
On comprend que celui qui se prétend combattre les “méchants” n’est pas toujours “gentil” lui-même.
Pour protéger l’intégrité de l’internet et le respect des utilisateurs, il est impératif que les fournisseurs de services internet cessent d’utiliser cette RBL et privilégient les solutions plus respectueuses disponibles.
Confrères sysadmin : ne cédez surtout pas aux prérequis grotesques de cette RBL.
LRob ne cèdera pas, cet article marque d’ailleurs le début d’une lutte qui ne s’arrêtra qu’une fois que la communauté aura eu gain de cause. Cela est possible, en contactant les bonnes personnes. Et vous pouvez aider à ce combat.
Si vous êtes confronté aux pratiques abusives de SPFBL.net, rejoignez-nous pour dénoncer ces actions et protéger l’intégrité de l’écosystème internet. Contactez les autorités compétentes, partagez cette information dans vos réseaux professionnels, et refusez de céder à ces pratiques déloyales.
Le monde de WordPress, qui alimente plus de 40 % des sites web dans le monde, est en pleine ébullition. Au centre du conflit se trouvent deux acteurs majeurs de l’écosystème : Matt Mullenweg, fondateur de WordPress et CEO d’Automattic, et WP Engine, une des principales entreprises d’hébergement pour WordPress.
Cet affrontement, qui a pris des proportions juridiques, soulève des questions cruciales sur le contrôle de la marque WordPress, l’open source, et la gouvernance de l’un des projets les plus influents du web. Voici une analyse détaillée de cette affaire et des enjeux qu’elle représente.
Contexte : WordPress et WP Engine
WordPress et Automattic : une relation complexe
WordPress, lancé en 2003 par Matt Mullenweg et Mike Little, est un logiciel open source permettant de créer et gérer des sites web. Il est gratuit et bénéficie du soutien d’une large communauté de développeurs qui contribuent à son amélioration continue. Cependant, la gouvernance du projet repose en grande partie sur Automattic, la société fondée par Mullenweg. Automattic gère notamment WordPress.com et d’autres produits populaires comme WooCommerce et Jetpack.
Bien que WordPress soit open source, Automattic détient une licence exclusive pour l’utilisation de la marque WordPress, ce qui donne à l’entreprise un rôle central dans l’écosystème. Cela inclut la protection de la marque contre des utilisations perçues comme abusives ou trompeuses.
WP Engine : un gros acteur de l’hébergement WordPress
De son côté, WP Engine est l’un des plus grands services d’hébergement spécialisés dans WordPress. L’entreprise propose des solutions d’hébergement optimisées pour WordPress, facilitant la gestion des sites web pour des millions d’utilisateurs. Elle a connu une croissance rapide, attirant des investisseurs de premier plan comme Silver Lake.
Cependant, WP Engine n’est pas directement affilié à Automattic ni à la WordPress Foundation, bien que son nom et son modèle économique soient étroitement liés à WordPress.
Le Début du Conflit : Mullenweg vs WP Engine
En septembre 2024, Matt Mullenweg a publié un billet de blog dans lequel il critiquait ouvertement WP Engine, qualifiant l’entreprise de “cancer pour WordPress”. Il reprochait à WP Engine de désactiver par défaut la fonctionnalité d’historique des révisions des articles, une pratique qui, selon lui, compromettait la protection des données des utilisateurs.
Mullenweg a également dénoncé l’utilisation par WP Engine de la marque “WP”, estimant que cela créait une confusion chez les utilisateurs, leur faisant croire que WP Engine faisait partie de WordPress ou avait un lien officiel avec la WordPress Foundation.
La Réaction de WP Engine
Face à ces accusations, WP Engine a répliqué en envoyant une lettre de cessation et de désistement à Mullenweg et à Automattic, exigeant qu’ils retirent leurs déclarations. WP Engine a défendu son utilisation de la marque “WP”, affirmant que cela relevait de l’usage loyal du nom, conformément à la loi sur les marques. La société a également accusé Mullenweg d’avoir menacé d’adopter une “approche nucléaire” contre WP Engine à moins qu’elle n’accepte de payer une redevance substantielle pour l’utilisation de la marque WordPress.
L’escalade juridique : cessez-le-feu et contre-attaques
En réponse à la lettre de WP Engine, Automattic a émis sa propre lettre de cessation et de désistement, affirmant que WP Engine violait les règles d’utilisation des marques WordPress et WooCommerce.
Le conflit a atteint un nouveau sommet lorsque Mullenweg a pris la décision radicale de bannir WP Engine des ressources de WordPress.org. Ce ban a bloqué les sites hébergés sur WP Engine de l’accès aux mises à jour des plugins et des thèmes, exposant de nombreux sites à des risques de sécurité. Cette mesure a été largement critiquée au sein de la communauté WordPress, car elle a laissé de petites entreprises et des sites indépendants sans solution viable.
WP Engine a dénoncé cette décision, accusant Mullenweg d’abus de pouvoir et de mettre en danger l’ensemble de l’écosystème WordPress.
Matt Mullenweg, CEO of Automattic, has misused his control of WordPress to interfere with WP Engine customers’ access to https://t.co/ZpKb9q4jPh, asserting that he did so because WP Engine filed litigation against https://t.co/erlNmkIol2. This simply is not true. Our Cease &…
L’interruption des services WP Engine a eu un impact majeur sur de nombreux utilisateurs. Bien que les plugins et thèmes WordPress soient sous licence open source, les hébergeurs comme WP Engine doivent gérer des infrastructures pour que leurs clients puissent les utiliser. Le ban temporaire a révélé la fragilité de certaines dépendances techniques et a mis en lumière l’importance d’une gestion équilibrée des ressources open source.
Mullenweg a toutefois affirmé que le conflit était strictement lié à des questions de marques et non à la gestion globale de WordPress. Le ban a été levé temporairement à la fin du mois de septembre, mais l’incident a semé des doutes dans la communauté.
Automattic trop dominant ?
De plus en plus de voix s’élèvent pour questionner la position dominante d’Automattic dans la gestion de WordPress. John O’Nolan, fondateur du CMS open source Ghost, a critiqué la centralisation excessive autour de Matt Mullenweg, affirmant que “40 % du web ne devrait pas être contrôlé par une seule personne”.
De son côté, David Heinemeier Hansson, créateur de Ruby on Rails, a accusé Automattic de trahir les principes de l’open source en demandant à WP Engine de reverser 8 % de ses revenus. Pour lui, cette pratique pourrait avoir des répercussions bien au-delà de WordPress, menaçant l’ensemble de la communauté open source.
Les implications juridiques et commerciales
Le 3 octobre 2024, WP Engine a décidé de passer à l’offensive en déposant une plainte contre Automattic et Mullenweg pour abus de pouvoir et pratiques anticoncurrentielles. WP Engine accuse Automattic de ne pas avoir respecté ses engagements envers l’open source et de nuire aux intérêts des développeurs et des utilisateurs.
Cette affaire est encore en cours, mais elle pourrait avoir des répercussions profondes sur la manière dont les marques et projets open source comme WordPress sont gérés à l’avenir.
Un message spécial à la connexion sur WordPress.org
Lors du login aux forums de WordPress.org, une nouvelle case à cocher est apparue :
✅ I am not affiliated with WP Engine in any way, financially or otherwise.
Message inhabituel qui m’a poussé à rechercher cela et à découvrir cette affaire.
Questions soulevées pour WordPress
Cela touche essentiellement deux grandes entreprises américaines qui font une exploitation commerciale de WordPress (dans des modèles à mon avis trop modifiés de la version originale de WordPress). Version originale de WP qui est vraiment libre et que vous pouvez héberger où vous le souhaitez (et on l’espère, vous choisirez un hébergement LRob).
Les hébergeurs indépendants tels que LRob, sommes pour l’heure totalement à l’abri de ce conflit. Pas de sonnette d’alarme pour nous, même si l’on reste vigilants.
Ce conflit souligne en tout cas les tensions possibles lors d’une gestion de projet open source à grande échelle. Alors que WordPress reste une technologie essentielle pour des millions de sites, ce débat autour de la propriété des marques, de la gouvernance et de l’éthique de l’open source, soulève des questions.
En particulier : Jusqu’où l’open source peut-il rester libre quand il est étroitement lié à des intérêts commerciaux massifs ?
Imaginez le drame : seulement 1 chance sur 10 que vos demandes vous parviennent !
Les formulaires de contact sont indispensables pour acquérir des clients. Pourtant, un certain nombre de ces formulaires sont mal configurés et échouent à faire parvenir les demandes des prospects…
De plus, les formulaires sont sensés être faits pour vous faire gagner du temps… Et quelques astuces peuvent vous y aider… Par exemple en ne recevant pas de spam ou en pouvant répondre plus rapidement.
Aujourd’hui, LRob vous fait gagner du temps et des prospects !
1. Ne mettez pas l’adresse email du client en expéditeur (From)
L’erreur la plus fréquente lors de la configuration des formulaires de contact est de considérer le client comme l’expéditeur du mail.
Il peut sembler logique de mettre son adresse email dans le champ “From”, mais cela provoque un problème majeur : le mail spoofing, ou usurpation d’identité.
En procédant ainsi, votre site web se fait passer pour l’adresse email de votre client (par exemple : john.doe@microsoft.com). Si le domaine de votre client est bien sécurisé (ce qui est souvent le cas), il refusera que votre serveur envoie un email en son nom. Le message sera donc bloqué silencieusement par votre fournisseur email, ou considéré comme du spam… 9 chances sur 10 que vous soyez considéré comme un spammeur.
La solution est très simple : l’expéditeur du mail doit toujours être une adresse liée à votre propre domaine. Par exemple, utilisez une adresse telle que : site@votredomaine.fr. Cela garantit que les emails envoyés à partir de votre formulaire ne seront pas rejetés ou classés comme spam.
2. Protégez vos formulaires avec un Captcha
N’oubliez pas d’ajouter un Captcha pour éviter les spams.
Le Captcha n’est pas là juste pour embêter le monde : c’est une solution simple et efficace pour filtrer les robots et préserver la qualité des messages reçus.
Sans cette protection, vous allez recevoir des dizaines voire des centaines de messages non sollicités par jour, ce qui vous fera perdre du temps à trier, en plus de manquer les vraies demandes.
Pour respecter la vie privée de vos usagers, je conseille hCaptcha.
3. Configurez SMTP sur votre site
Votre site web devrait avoir une adresse mail dédiée avec un vrai login SMTP pour vos envois. Pour rappel, SMTP est le protocole standard d’envoi email.
Si vos mails sont chez Gmail ou Microsoft, cela va être plus compliqué à appliquer car vous payez à chaque boîte mail et SMTP est désactivé par défaut… Mais s’ils sont chez votre hébergeur favori alors aucun souci !
Les envois par défaut via la fonction php mail() sont parfois désactivés pour éviter les envois involontaires de mails et ainsi préserver la réputation des serveurs (bloqué par défaut chez LRob, autorisé au cas par cas).
Cela assure que l’envoi se fasse depuis un vrai serveur email plutôt que depuis le serveur du site web, lorsque ces deux serveurs sont distincts.
SMTP va améliorer la délivrabilité des mails grâce à des “headers” email (des méta-informations) généralement plus propres que php mail().
En cas de problème avec le formulaire (envoi massif de spams par exemple), SMTP permettra de limiter les envois à un quota horaire.
En cas de souci de délivrabilité quelconque, si votre hébergeur fournit du support pour cela (c’est le cas de LRob), les envois SMTP sont bien plus facilement traçables dans les logs, ce qui simplifie le diagnostic.
En résumé, utiliser SMTP n’a que des chances d’améliorer votre délivrabilité et d’éviter les problèmes. Utilisez-le !
4. Vérifiez la délivrabilité de vos emails du formulaire
Assurez-vous que vos messages sont bien reçus en effectuant des tests avec des outils comme mail-tester.com.
Mail-Tester vous permet de mesurer la qualité de vos envois.
Mettez l’adresse mail s’affichant à la visite de mail-tester.com en destinataire du formulaire, faites votre test, puis vérifiez le score.
Un score supérieur ou égal à 9/10 est recommandé pour garantir la bonne réception des demandes. Ce score devrait également être atteint lors de vos envois email classiques. Si ce n’est pas le cas, contactez votre hébergeur email pour plus d’infos (ou venez vous héberger chez LRob !).
5. Faites vos tests en navigation privée
Lorsque vous testez vos formulaires de contact, faites-le en navigation privée.
Si vous êtes connecté à votre site, certaines fonctionnalités comme le Captcha peuvent être désactivées, pour ne citer que ça. Cela pourrait fausser vos tests et vous donner une impression erronée de la qualité de votre formulaire.
6. Utilisez une adresse destinataire liée à votre domaine
Assurez-vous que l’adresse de réception (destinataire du formulaire) appartient bien à votre domaine (vous@votredomaine.fr) et qu’elle n’est pas redirigée vers une autre adresse.
En cas de problème avec votre formulaire, par exemple si vous recevez du spam via le formulaire et que le destinataire est un grand fournisseur de messagerie (Gmail, Orange, Yahoo, etc.), vous pourriez être considéré comme spammeur.
Utiliser votre propre domaine en destinataire du formulaire vous permet donc de protéger votre e-réputation et de réduire les risques de blocage ou de mauvaise gestion des emails par les fournisseurs de messagerie.
7. Évitez les emails de confirmation
Envoyer un email de confirmation peut sembler être une bonne idée, mais il faut s’en méfier.
Si ce message contient le texte soumis par l’utilisateur, votre formulaire peut alors être exploité par des personnes malveillantes pour envoyer du spam à n’importe quelle adresse mail via votre site. Même si le texte n’est pas repris, cela peut quand même générer des mails non sollicités vers des tiers, ce qui n’est jamais bon.
Cela peut donc ternir la réputation de votre domaine et vous exposer à des sanctions. Préférez donc éviter cette pratique.
8. Utilisez le champ “Reply-To” pour faciliter vos réponses
Même si vous ne devez pas mettre l’adresse email du client dans le champ “From”, vous pouvez cependant l’ajouter dans le champ “Reply-To”.
Ainsi, vous pourrez directement répondre au mail du formulaire : l’adresse email de votre prospect sera automatiquement le destinataire de votre mail.
Une solution simple et efficace pour gagner du temps !
9. Sauvegardez les demandes sur le site
Envisagez de sauvegarder les demandes du formulaire en base de données du site.
Des plugins WordPress comme “Contact Form 7 Database Addon” permettent cela gratuitement. Vous pourrez alors vérifier de temps en temps que vous n’avez pas loupé une demande.
Pour aller plus loin…
Si vous avez des doutes sur la configuration de vos formulaires, ou si vous souhaitez un audit personnalisé, n’hésitez pas à me contacter.
Aussi, le conseil relatif à la délivrabilité email est inclus dans le support LRob pour tous les clients.
Je n’ai plus qu’à vous souhaiter une belle réussite avec des formulaires au top désormais ! 💪
Le mot “cloud” ne veut plus rien dire. Il est tellement utilisé à tort et à travers que j’ai créé une expression dédiée : “cloud bullshit”.
Le “cloud” est souvent synonyme de solution propriétaire qui vous enferme dans un écosystème tout-en-un dont il est extrêmement difficile de sortir.
Quand le prix de votre “solution cloud” augmente de 300%, ou qu’une nouvelle condition générale d’utilisation révoltante apparaît ou que le service est en panne : que faites-vous ? Vous subissez comme une victime, ou vous êtes convenablement préparé pour changer de fournisseur ?
Aujourd’hui, votre Administrateur Système Linux spécialisé en hébergement web WordPress vous livre tous les secrets pour ne pas vous faire piéger par le “cloud bullshit”.
Le “Cloud” n’existe pas ?
La cuillère n’existe pas.
Cloud : Définition
Le cloud computing (en français, « informatique dans les nuages ») fait référence à l’utilisation de la mémoire et des capacités de calcul des ordinateurs et des serveurs répartis dans le monde entier et liés par un réseau. Les applications et les données ne se trouvent plus sur un ordinateur déterminé mais dans un nuage (cloud) composé de nombreux serveurs distants interconnectés.
On ne sait pas où sont vos données. Elles sont éparpillées sur un système informatique obscure. Généralement chez un tiers dont vous ne savez rien de l’infrastructure et rien des accès et exploitations de données effectuées.
Est-ce vraiment ça l’avenir ? Ne plus savoir où sont ses données ?
Glissement sémantique du mot “cloud”
Le “cloud” n’existe plus vraiment car il a perdu son sens. D’une infrastructure web délocalisée et aux ressources éparpillées sur plusieurs machines, un glissement sémantique s’est opéré peu à peu.
Désormais cloud signifie davantage : Un ou plusieurs serveurs en datacenter hébergeant des services. En gros, tout service en ligne appartient au cloud.
Dans tous les cas, ça reste le ou les ordinateurs d’un autre…
Cloud = maraboutage
Avec le cloud, tout semble fonctionner comme par magie, sans que personne n’y comprenne rien. Du vrai maraboutage !
Ne pas comprendre, c’est vous mettre en danger.
Il faut simplifier les solutions pour les rendre intelligibles.
C’est en maîtrisant vos outils que vous pourrez vous protéger.
Lier applicatif et hébergement : danger d’emprisonnement
Un danger majeur du cloud : lorsque l’hébergement et le service fusionnent.
Vous êtes emprisonné dans cette solution. Vous êtes tributaire à 100% du bon vouloir d’une entreprise américaine qui possède vos données, vos outils de travail, sur lesquels vous n’avez pas la main.
Par exemple, si vous utilisez la suite Office 365, non-seulement vous hébergez vos données sur l’infrastructure cloud de Microsoft, mais les services (calendrier, éditeurs excel, etc.) que vous utilisez sont propriétaires et ne permettent pas facilement de sortir vos données vers un service alternatif.
Le cas de la panne informatique mondiale de ce mois de juillet montre bien le problème : tant que le prestataire n’a pas rétabli le service, vous êtes totalement bloqué. Votre business est tenu en otage.
Le problème est le même avec Google Cloud, mais aussi avec de nombreux prestataires vous fournissant des solutions propriétaires pour votre site ou vos mails et dont il est souvent difficile de se sortir.
Dès lors que vous avez des centaines d’employés sur un tel système, l’organisation et le coût pour en sortir refroidira plus d’un dirigeant, quand bien même cela ferait des économies à long terme.
Le “bon” et le “mauvais” cloud : les trois critères
Qu’est-ce qu’un “bon” cloud ?
De mon point de vue d’administrateur système, qui gère donc directement des infrastructures cloud, il y a trois critères majeurs qui caractérisent un bon cloud :
Il permet de savoir où sont stockées vos données.
Il n’exploite pas vos données.
Il est simple et standard, permettant d’en changer librement.
Les GAFAM (Google, Apple, Facebook, Amazon, Microsoft) sont donc exclus directement : Solutions propriétaires, impossibilité de localiser les données qui sortent généralement d’Europe, exploitation commerciale des données (statistiques, social engineering, etc) et en bonus : partenariats gouvernementaux donnant aux autorités US des passe-droits pour accéder à vos données.
Vous l’aurez compris : La solution choisie doit être simple, transportable, localisable, libre et indépendante.
On peut ajouter que la solution doit rester facilement joignable et prête à vous aider inconditionnellement, même si c’est dans l’objectif de sortir vos données de chez eux.
Enfin, un cloud idéal comporte des sécurités additionnelles comme des pare-feux applicatifs ou des solutions anti-bruteforce, des solutions de blocage anti-robots. Et aussi étonnant que cela puisse paraître, les plus grand prestataires de cloud omettent généralement ce type de sécurités car cela leur demanderait un support humain additionnel qu’ils ne semblent pas avoir envie de fournir.
Le cloud parfait existe
Grâce à mon expertise de l’hébergement libre, j’ai crée le cloud parfait !
Si parfait que j’y héberge tout mon business, toute ma vie. Preuve s’il en faut de la confiance totale que j’accorde à ce système et de sa viabilité totale.
De quoi se compose-t-il ?
Localisation transparente
Les serveurs web LRob sont parfaitement identifiables. Vous pouvez connaître l’emplacement précis de votre machine.
Les serveurs LRob sont situés exclusivement en Europe. De quoi simplifier votre gestion RGPD.
Solutions libres & transportables
Sites WordPress, emails POP/IMAP/SMTP, suite collaborative libre Nextcloud : Tout est standard et peut se transporter !
Rien ne vous retient, vous avez tous les accès requis pour migrer vos données si besoin.
Vous resterez donc chez LRob par plaisir !
Aucune exploitation des données
Aucune analyse statistique de votre utilisation n’est faite. Aucun accord gouvernemental n’est présent. Vos données sont au frais sur un serveur libre et open-source, dénué de tout outil d’analyse intrusif.
Une sécurité accrue
Bien que cela demande un support occasionnel en cas de faux positif, LRob n’a pas peur d’être en contact avec vous et met en place des sécurités additionnelles directement sur le serveur.
Une simplicité de gestion
Un panneau de contrôle simple et intuitif (Plesk) vous permet de gérer vos domaines et sous-domaines, vos emails, vos bases de données, vos accès FTP, vos sauvegardes très facilement. Cet accès vous permet de maîtriser efficacement toutes vos données.
Le WordPress Toolkit vous aide à gérer vos installations de WordPress sans être intrusif. Vous gagnez énormément de temps et de sécurité, sans perdre votre liberté.
Et vous savez quoi ? Avec LRob, vous êtes si libre que vous pouvez même mixer des solutions libres et non libres. Si vraiment vous tenez à utiliser Microsoft 365 ou Google Workspace, cela reste possible et je vous y aiderai même si besoin.
Et pour vous ? Le cloud parfait, c’est pour quand ?
En tant que possesseur d’un ou plusieurs sites WordPress, vous devriez savoir à quel point un hébergement web pratique, performant et fiable et sécurisé peut révolutionner votre approche.
Vous n’imaginez vraiment pas à quel point vous pouvez révolutionner votre gestion de WordPress.
Révolutionnez votre gestion avec le WordPress Toolkit
Que vous soyez expert ou non, gérer et maintenir un site WordPress peut être fastidieux et coûteux en temps. Si vous avez plusieurs sites, cela devient encore plus complexe.
Heureusement, avec le WordPress Toolkit inclus dans l’hébergement LRob, la maintenance devient un jeu d’enfant ! Vous allez gagner un temps fou ! Le WordPress Toolkit révolutionne totalement l’approche de la gestion WordPress en la rendant beaucoup plus efficace et scalable.
ℹ️ Contrairement à d’autres outils, le WordPress Toolkit est n’est pas intrusif : aucun plugin à installer, et votre installation de WordPress reste parfaitement standard !
✅ Installez WordPress en quelques clics, personnalisez l’installation si vous le souhaitez. Fini d’avoir à créer une base de données à la main. ✅ Vérifiez d’un coup d’œil si tout va bien et connectez-vous en un clic au back-office de vos sites. ✅ Changez votre mot de passe ou email administrateur en 3 clics ✅ En 1 clic : activez/désactivez l’indexation, le mode debug, l’exécution de wp-cron par le serveur !
✅ Mettez à jour automatiquement vos sites, thèmes et plugins et vérifiez les failles de sécurité en un coup d’œil (et soyez alertés par mail quand une nouvelle faille est détectée). 🔒 Appliquez une dizaine d’améliorations de sécurité en quelques clics seulement. 🔨 Votre site a planté suite l’installation d’un plugin ? Désactivez ce plugin en 2 clics avec le WP Toolkit ! 🔨 Clonez votre site simplement via l’assistant
ℹ️ Si vous avez plusieurs sites, alors ceux-ci sont bien isolés au niveau du système, mais vous pouvez tous les afficher sur le même écran, pour gérer efficacement toutes vos installations !
Les tâches complexes et fastidieuses sont ainsi rendues extrêmement simples. C’est une révolution qui vous permettra de gérer de nombreux sites très facilement.
Des performances maximales pour vos sites WordPress
La rapidité de votre site est critique pour l’expérience utilisateur et le référencement. Elle détermine aussi si vous allez gaspiller votre temps dans un back-office WordPress lent.
En tant que gestionnaire de site, vous avez certes un rôle à jouer en choisissant des plugins bien optimisés. Mais cela ne fait pas tout : la mesure des performances avant/après passage chez LRob montre une amélioration d’un facteur 2 à 15 sur les les performances par rapport aux hébergeurs traditionnels !
Voici les gains mesurés avant (à gauche) et après (à droite) migration vers LRob.
Chargements entre 3 et 15x plus rapides chez LRob et stabilisation des temps de chargementChargements 10x plus rapides chez LRob et stabilisation des temps de chargement
Comment est-ce possible ? Les hébergeurs classiques se moquent-ils de nous ?
Les hébergeurs classiques vous vendent souvent des “clusters” de serveurs vieux et saturés, qui rajoutent de la latence à chaque étape du traitement des pages et requêtes de votre site. Aussi, il n’y a pas souvent de solution de cache simple à utiliser et ultra performant directement sur le serveur.
Le secret LRob : des serveurs simples, performants et bien gérés !
Une infrastructure simple et au top niveau : des serveurs dédiés physiques parfaitement SUR-dimensionnés pour que chacun bénéficie des performances maximales à chaque fois qu’il en a besoin. Avec des SSD NVME locaux, pour des accès ultra rapides à vos fichiers et aux bases de données MySQL, des CPU de pointe pour un traitement rapide et une marge de performances énorme, avec bien plus de RAM qu’il n’en faut.
Une gestion intelligente et unique : une lutte anti-robots pirates exclusive, permettant d’éviter toute saturation inutile des serveurs, tout en protégeant vos sites. Et une configuration optimisée de chaque élément logiciel du serveur web.
Un cache Redis en RAM serveur : fini les milliers de fichiers de cache stockés dans votre site, Redis vous permet de stocker votre cache du site directement en RAM serveur !
La sécurité native pour vos sites WordPress
La sécurité de votre site est primordiale. Pourtant, sécuriser un site WordPress est souvent un casse-tête que personne ne comprend vraiment. Les plugins de sécurité ne sont pas très efficaces, vous font perdre du temps et nuisent aux performances de vos sites.
Un piratage de site web est toujours un drame. C’est pourquoi il faut mettre toutes les chances de votre côté. Et cela passe d’abord par une configuration native sécurisée du serveur qui héberge vos sites.
Un hébergeur spécialisé WordPress améliore drastiquement la sécurité de votre site par rapport à n’importe quel plugin grâce à une configuration serveur rigoureuse.
Voici tout ce qui est fourni “out of the box” par l’hébergeur WordPress spécialisé LRob :
Pare-feu applicatif personnalisable pour bloquer les tentatives de hack
Blocage automatique des robots pirates pour que leurs requêtes ne puissent atteindre vos sites
Améliorations de sécurité spécifiques à WordPress applicables en quelques clics seulement grâce au WordPress Toolkit.
Alertes en cas de faille de sécurité : si votre site comporte une vulnérabilité rendue publique, vous en êtes alertés directement par mail, vous permettant d’agir efficacement !
Certificats SSL Wildcard Let’s Encrypt inclus pour sécuriser les communications de votre site et services connexes comme les emails.
Sauvegarde quotidienne externalisée avec une rétention d’un an. Faite au plus haut niveau, c’est à dire directement par le serveur. Plus fiable qu’une sauvegarde effectuée par votre site, cette sauvegarde peut résister aux pires catastrophes ! Aussi, elle ne sort jamais chez un GAFAM et reste dans l’infrastructure privée LRob, assurant la confidentialité de vos données. Vous avez également la possibilité de configurer vos propres sauvegardes vers le FTP de votre choix.
Gestion simplifiée avec Plesk
Gérer votre hébergement WordPress n’a jamais été aussi simple qu’avec Plesk.
Ce panneau de contrôle intuitif vous permet de gérer tous les aspects de vos hébergements en quelques clics dans un panneau extrêmement bien présenté ! Le bon vieux cPanel n’a qu’à bien se tenir, il fait bien pâle figure à à côté de l’excellente présentation et praticité de Plesk !
Que vous souhaitiez créer des adresses email, gérer les accès FTP, configurer vos bases de données MySQL, ou modifier votre zone DNS : tout est à portée de main. Y-compris le WordPress Toolkit dont on reparle juste après.
Vous pouvez même accéder aux logs web pour diagnostiquer et résoudre rapidement les problèmes de votre site.
Une assistance et support passionné de WordPresss
En choisissant un hébergeur spécialisé WordPress, vous bénéficiez également d’un support expert et passionné qui fera tout pour vous aider, sans lire un script débile ou rejeter la faute sur le client.
Que ce soit pour des conseils de configuration, des problèmes d’accès ou des questions techniques, LRob sera toujours heureux de vous aider, de partager son savoir et son expérience pour vous faire atteindre vos objectifs.
Cette assistance de qualité change totalement la donne pour vous accompagner au quotidien.
Au fait : le monitoring de chacun des sites hébergés est fait en 24/7 toute l’année ! Concrètement, si votre site plante suite à une mise à jour, on vous prévient dès que possible, avant même que vous ne l’ayez remarqué ! Et on vous aide à comprendre le souci et à le remettre sur pieds !
Des options exceptionnelles pour les revendeurs
Vous avez plusieurs sites ? Gagnez encore plus de temps (et d’argent) !
Avec le panel revendeur Plesk, centralisez et simplifiez votre gestion, et devenez hébergeur !
Plus vous avez de sites, plus la solution devient économique. Par exemple, avec les tarifs LRob de 2024, si vous avez 8 sites, l’hébergement vous revient à 47.5€/an par site. Si vous avez 128 sites, cela vous revient à 15.5€/an par site.
Devenez interlocuteur unique pour vos client, créez-leur un accès si besoin, et offrez un service plus fiable et plus efficace.
Vous gagnez du temps, vous margez sur l’hébergement… Et vous offrez un meilleur service ! Avec un support d’expert pour vous accompagner au quotidien.
Offrez-vous la tranquillité avec un hébergement WordPress spécialisé
Opter pour un hébergement WordPress spécialisé, c’est choisir la sérénité et la performance pour votre site. Vous bénéficiez d’un service sécurisé, facile à gérer et optimisé pour WordPress et du meilleur support d’expert lorsque vous en avez le plus besoin.
Les offres LRob, ce sont des performances supérieures à ce que vous pourriez rêver même sur serveur dédié de la NASA, avec une gestion parfaite incluse, à un coût ultra raisonnable !
Alors n’attendez plus, faites confiance à un hébergeur expert WordPress comme LRob et offrez-vous la tranquillité d’esprit que vous méritez.
Tout le monde y va de son site éco-responsable. Si cela ne sauvera pas la planète, il reste utile qu’il y aie une prise de conscience. Cela ne peut qu’aller dans le bon sens.
Mais le but est de maximiser les efforts. Et si l’optimisation des sites du point de vue des visiteurs (côté “client”) est souvent mise en avant, l’optimisation et les choix côté serveurs sont bien trop souvent négligés.
Pourtant, l’hébergement est la clé de voûte d’un web réellement plus “vert”, représentant la majeure partie de l’économie de ressources que vous pouvez réaliser.
C’est le volet le plus connu et évident. Il s’agit de réduire le poids des ressources envoyées aux visiteurs, améliorant ainsi le temps de chargement et réduisant l’empreinte carbone du site.
Cela s’axe sur deux points principaux :
La conception : choisir des thèmes et plugins optimisés pour éviter l’envoi massif de polices et de codes JavaScript ou CSS inutiles.
L’optimisation des images : utiliser des formats d’image adaptés et compressés selon les standards modernes comme “webp”, pour minimiser la consommation de bande passante.
Mais ce n’est que la partie émergée de l’iceberg.
Passons à l’aspect vraiment déterminant ! 👇
2. L’hébergement et l’optimisation des ressources serveur
Ce point est souvent sous-estimé, pourtant il représente à mon sens 90% de l’impact !
Choix de l’hébergeur 🏭
Les hébergeurs ont une énorme marge de manœuvre pour être “green”.
Électricité verte, localisation géographique, récupération de chaleur, type de refroidissement, choix de machines durables et basse consommation.
Par exemple, mon prestataire fournisseur de serveurs Hetzner utilise 100% d’énergie verte et des serveurs sans boîtier, évolutifs et durables. 🌱
Lutte contre les robots 🤖
Supprimer jusqu’à 99% du trafic indésirable généré par les robots pirates permet de baisser la consommation électrique des machines de plus de 50%. Pourtant, quasiment aucun hébergeur n’applique ces filtres, car cela demande un support additionnel pour traiter les faux positifs (et concrètement, débloquer les clients qui se trompent de mot de passe en boucle, ou utilisent des plugins faisant des requêtes louches).
Cela a l’autre effet bénéfique de booster drastiquement les performances pour les utilisateurs réels.
J’accomplis cela grâce à des techniques de détection et de blocage d’attaques comme ModSecurity et Fail2ban qui sont de grands standards pour les plus familiers de l’administration système en hébergement web.
Optimisation CPU 🧮
Les développeurs doivent écrire un code léger et rapide, et utiliser des caches performants comme Redis (disponible sur mes hébergements), pour maximiser l’efficacité des serveurs.
On parle ici d’une division par un facteur 2 à 10 de l’utilisation CPU des serveurs grâce à un bon cache.
A noter que les caches traditionnels écrivant des fichiers temporaires sur les serveurs sont moins optimum que Redis qui garde tout en RAM et évite ainsi de consommer de l’espace et des ressources I/O (lecture/écriture disque) inutilement.
Mutualisation efficace 🫂
Une gestion optimisée des serveurs et des sites, selon les points précédents, évite le gaspillage de machines physiques (chaque serveur peut contenir davantage de sites) tout en assurant des performances maximales pour tous.
Cette approche repose aussi sur une vraie proximité avec les clients pour une gestion sur mesure. Par exemple, si un site consomme plus de ressources que ce qui est attendu, cela peut être dû à une attaque à bloquer, ou à un souci d’optimisation du site à remonter au client, avec des conseils personnalisés.
Espérant que vous aurez appris quelque-chose. En tout cas désormais, vous ne pourrez plus dire que vous ne saviez pas. 🌟👍
Vous perdez du temps à maintenir vos sites WordPress ? 🥵
Voici 10 points clés pour en gérer des centaines de manière hyper efficace ! 😎👇
1. Centralisez vos sites
Regroupez vos sites sur un ou quelques serveurs seulement, mais assurez-vous que chaque site reste isolé au niveau système pour rester sécurisé. Ce sera bien plus simple à gérer et plus économique qu’un hébergement individuel par site.
2. Gérez les DNS via le serveur hébergeur
Gérez les DNS de vos domaines directement via le serveur hébergeur. La création des sous-domaines sera simplifiée, vos emails seront pré-configurés pour une bonne délivrabilité, et vous pourrez bénéficier d’un certificat WildCard gratuit pour protéger tous vos domaines avec des connexions chiffrées SSL/TLS. Cela sera aussi l’occasion de centraliser votre gestion email pour là aussi gagner en efficacité.
3. Optez pour un hébergement ultra performant
Ne perdez pas votre temps avec un back-office lent. Choisissez un hébergement ultra performant comme ceux de LRob pour être certain que si votre site est lent, le problème ne vient pas du serveur mais de l’optimisation du site.
4. Utilisez le WordPress Toolkit
Choisissez un hébergement avec le WordPress Toolkit. Vous pourrez vous connecter en un clic à chaque site, recevoir des alertes de sécurité, ajouter des protections supplémentaires en quelques clics, bénéficier de mises à jour automatiques et désactiver un plugin problématique même si le site a un souci.
5. Assurez-vous d’un bon backup quotidien
Un bon backup doit être géré côté serveur, pas par le site lui-même. Ayez une copie chez vous en plus de celle de l’hébergeur pour être tranquille. Un souci sur un site ? Restaurez un backup. Et testez vos backups avant d’en avoir besoin pour ne pas être pris de court en cas de souci.
6. Accédez facilement aux logs serveur
En cas de bug sur votre site, ce qui arrivera forcément un jour, l’accès aux logs serveur est indispensable pour trouver et corriger l’erreur rapidement.
7. Choisissez un prestataire qui couvre vos arrières
Optez pour un prestataire fiable en matière de sauvegarde, de support et de monitoring. C’est dans les moments difficiles que vous verrez la différence entre un bon et un mauvais prestataire.
8. Activez les mises à jour automatiques des sites
Avec une bonne sauvegarde et un bon prestataire, activez les mises à jour automatiques de vos sites comme le permet le WordPress Toolkit. Vous n’avez plus besoin de faire les mises à jour manuellement, ce qui augmente la sécurité et vous fait gagner un temps fou. Vous seriez surpris de voir à quel point les problèmes deviennent rares lorsque les mises à jour sont faites régulièrement.
9. Utilisez des sécurités additionnelles au niveau serveur
Choisissez un serveur avec des sécurités supplémentaires comme un pare-feu applicatif, un anti-bruteforce, et le bannissement automatique des IP attaquantes. Cela, combiné aux mesures précédentes, réduit de 99 % le risque de piratage tout en réduisant drastiquement la charge inutile sur le serveur, pour des performances optimales.
10. Valorisez votre hébergement et maintenance
Communiquez sur vos mesures de sécurité et de maintenance. Facturez cette plus-value à vos clients pour pérenniser votre activité avec des abonnements à forte valeur ajoutée. Et soyez fiers du service que vous proposez pour mieux développer votre activité.
Vous avez entre 5 et 128 sites WordPress à héberger en respectant tous ces critères ? Mes offres Web Agency sont faites pour vous ! Contactez-moi pour plus d’infos.
Envie de partager votre propre méthode ? Des points à ajouter ? Commentez ci-dessous ! 👇
Avec ces conseils, vous optimiserez la gestion de vos sites WordPress, gagnerez du temps et améliorerez leur sécurité et performance. N’hésitez pas à me contacter pour découvrir comment nous pouvons travailler à atteindre vos objectifs.
Tout acteur du web doit absolument maîtriser ces points !
En maîtrisant les DNS, vous serez LIBRES avec vos sites web et noms de domaine ! 👇
Apprenez l’essentiel en 2 minutes intenses et efficaces au lieu d’un cours barbant de 3h. 🤯
Qu’est-ce que le système DNS ?
📄 Le Domain Name System est l’autoroute numérique qui permet à un nom de domaine (par exemple lrob.fr ou google.com) d’être accessible. En gros, on “pointe” le domaine vers une destination.
Exemples :
Si vous visitez un domaine comme lrob.fr, votre navigateur web fait en arrière-plan une requête nommée “résolution DNS” (DNS resolution) pour connaître l’adresse IP du serveur hébergeant le site.
Quand vous envoyez un mail, d’autres requêtes ont lieu pour trouver le serveur mail destinataire et authentifier l’expéditeur.
Comment fonctionne le système DNS ?
1 – Registrar 🏢
Les noms de domaine comme lrob.fr sont enregistrés chez un “bureau d’enregistrement” (registrar) comme HaiSoft, Gandi, NameCheap, OVH, etc.
Chaque registrar doit passer par un “registre” (registry) qui fait autorité pour l’extension de noms de domaine. Par exemple :
.fr : AFNIC
.com / .net Verisign
.org : Public Interest Registry (PIR)
2 – NS (Name Servers) 🌍
Pour rendre un domaine “résolvable” (accessible), il doit avoir des “serveurs de noms” ou NS (Name Servers).
Les NS contiennent les infos de pointage du domaine et sont dits “autoritaires”. Il faut toujours définir au moins deux NS pour la redondance. Le registrar transmet cette information au registry.
ℹ️ Le propriétaire du domaine (“registrant”) est libre d’utiliser les NS de son choix, voire de créer les siens à l’aide de valeurs appelées Glue Records.
Différents prestataires existent et vous pouvez créer les vôtres directement avec quelques connaissances. C’est par exemple le cas de lrob.net qui est mon domaine d’infrastructure avec un système DNS autonome complet fourni à tous les clients hébergés pour centraliser leur gestion DNS indépendamment du registrar utilisé. Pratique !
Les NS sont donc des serveurs contenant la zone DNS du domaine. C’est cette zone DNS qui contient les valeurs effectives de pointage.
Par exemple :
l’IP du serveur hébergeant le site
l’IP ou nom d’hôte du serveur de mails
Des méta-informations comme la liste des serveurs autorisés à envoyer des mails pour un domaine.
Cliquez ici pour découvrir toutes les valeurs DNS possibles et comment gérer votre zone DNS via LRob.
Que fait-on de tout ça ?
Vous êtes désormais libres d’enregistrer un nom de domaine chez n’importe quel registrar, de gérer vos NS (et donc votre zone DNS) où vous voulez. Et vos sites et mails peuvent être placés chez les prestataires différents que vous souhaitez en toute liberté grâce au paramétrage de la zone DNS !
Pour ne jamais vous tromper sur vos DNS, choisissez un Hébergement LRob ! 💪 Je vous accompagne au quotidien dans tous vos défis web ! 🤝
Savez-vous où sont physiquement vos données ? Dans quel datacenter ? Qui y a accès ?
Si une seule de ces réponses est “non”, c’est plus grave que vous ne pourriez le penser.
Reprenez le contrôle en 3 étapes.
1 – Prendre conscience du problème
Utiliser un service Google ou Microsoft peut procurer de la fierté voir de la joie, au début…
C’est là que l’on voit que le marketing fait bien son travail : avoir des clients heureux de payer premium, c’est à dire plusieurs centaines voir milliers d’euros par mois dans le cas de grandes équipes.
Mais dans l’absolu, qui veut vraiment donner ses données les plus chères aux géants américains ? Qui veut s’engouffrer dans un mécanisme de rétention dont il est difficile de sortir ? Qui veut ignorer où sont physiquement ses données, qui y a accès, et ce qui en est fait ? Et payer premium en plus…
Sans même avoir besoin de parler de “Big Brother” (qui est une réalité, ces entreprises vous connaissent mieux que vous ne vous connaissez, permettant une surveillance de masse et une subtile manipulation de vos résultats de recherche et autres que vous ne pouvez même pas remarquer), un tel fonctionnement ne peut être qu’inquiétant, que ce soit pour un particulier (même s’il n’a rien à cacher), ou pour une entreprise, dont le business dépend notamment de ses documents et emails.
Si vous êtes capable de dire “je n’ai pas le choix, tout le monde utilise ça”, sachez que c’est faux. D’autres solutions indépendantes font le même job, voir mieux, pour moins cher, tout en permettant de rester en pleine possession de ses données ! Leur développement est solide et ces outils sont utilisés par de plus en plus de personnes accordant de l’importance au contrôle de leur données.
2 – Contrôler ses emails
Les mails sont un service extrêmement standard et de nombreux prestataires en proposent.
Mais comment choisir ?
Une boîte mail n’est pas un calendrier, une suite d’éditions de documents, une machine à café, ou que sais-je encore. Si demain vous avez un souci avec l’un de ces service, tout ne doit pas être lié de sorte que le changement soit compliqué.
Choisissez un prestataire simple : une boîte mail, c’est une boîte mail et ne doit être rien de plus.
Aussi, choisissez un prestataire sécurisé : tout hébergeur ou fournisseur de services email doit respecter les normes d’envois de mails (rDNS/HELO/SPF/DKIM/DMARC) et avoir une lutte active contre l’envoi de spams depuis son réseau, ce qui est bien-sûr le cas de LRob qui vient avec ces sécurités sans configuration additionnelle de votre part.
Pour la connexion aux boîtes, le prestataire doit fournir un webmail standard comme Roundcube (libre et open-source, parfaitement optimisé, standard et simple), ainsi qu’une connexion POP/IMAP/SMTP. Pour la connexion, vous utiliserez donc soit le webmail fourni, soit le logiciel de votre choix (Thunderbird, Outlook, ou les apps email sur smartphone). Dois-je rappeler que LRob fournit également Roundcube et la connexion POP/IMAP/SMTP en standard sur tous les hébergements web avec email inclus ?
Un souci non résolu avec votre prestataire ? La migration peut se faire par simple copie des boîtes en IMAP et modifications DNS astucieuses pour éviter l’interruption de service. Si besoin de migrer, même depuis un cloud Microsoft, contactez-moi !
Pour travailler en équipe, beaucoup utilisent une suite collaborative comme celles intégrées avec les boîtes mail Microsoft Office 365 ou Gmail.
Mais comme on l’a vu, cela n’a à la base aucun rapport avec une boîte mail et devrait être un service distinct.
Pour cela, une solution libre et open-source existe : Elle s’appelle Nextcloud.
De plus en plus de professionnels sensibles au contrôle de leurs données l’utilisent. La raison est simple : Il s’agit d’un site web comme un autre, certes un peu plus lourd que la moyenne, mais hébergeable chez n’importe quel hébergeur puissant comme LRob !
Bien géré avec l’ajout d’une suite d’éditions de documents comme Collabora Online, Nextcloud permet l’édition collaborative, le partage de fichiers en équipe ou avec les clients, le partage de calendriers, la gestion des tâches, le tchat, et bien plus encore.
Compatible Windows, Mac, Linux, Android, et iOS, Nextcloud permet d’accéder à ses fichiers depuis n’importe où !
Pour la partie contacts et calendriers, Nextcloud utilise les standards CardDAV et CalDAV. Par exemple sur Android, vous pouvez ainsi à l’aide de l’appli DAVx5 vous passer totalement du calendrier et des contacts Google pour tout stocker sur Nextcloud. Idéal en environnement professionnel.
Dans le monde de l’hébergement web, les préoccupations écologiques et de confidentialité sont primordiales. Certaines idées reçues peuvent freiner le choix d’un hébergeur, notamment en Allemagne. Cet article vise à démonter ces préjugés, en mettant en lumière l’excellence de Hetzner, mon partenaire d’hébergement allemand, en matière d’écoresponsabilité, d’interconnexion et de confidentialité.
Écoresponsabilité : Au-delà du Greenwashing
🌿 Hetzner, un acteur clé de l’hébergement en Allemagne et en Europe, s’engage activement dans la préservation de l’environnement. Contrairement aux accusations de greenwashing souvent portées contre des entreprises de ce secteur, Hetzner prouve son engagement écoresponsable en utilisant exclusivement de l’énergie verte, fournie par Energiedienst AG, une entreprise spécialisée dans les énergies renouvelables telles que l’éolien et l’hydroélectrique. Mais pas seulement.
Architecture de Serveurs Innovante
📉 Hetzner révolutionne également l’architecture de ses serveurs. En optant pour une conception personnalisée sans châssis, l’entreprise réalise des économies de matières premières, améliore la ventilation (surpassant ainsi les serveurs traditionnels comme ceux de Dell), et réduit les coûts globaux. Cette innovation se traduit par une meilleure efficacité énergétique, la possibilité de fonctionner à des températures plus élevées (réduisant ainsi le besoin de climatisation) et la facilité d’upgrade et de réutilisation des composants.
En optimisant sa conception, Hetzner permet de meilleurs tarifs tout en préservant tant que possible notre chère planète.
Fiabilité et Performance en Pratique
⏩⏩ L’efficacité des serveurs custom de Hetzner ne se limite pas à leur conception. C’est dans les situations difficiles que l’on doit pouvoir compter su run hébergeur. Hetzner réussit cela aussi et peut par exemple remplacer un disque dur défectueux dans son datacenter en seulement 15 minutes – une rapidité inégalée comparée à d’autres fournisseurs.
Un Support Client Exemplaire
🤝 Le support client chez Hetzner est non seulement compétent mais aussi efficace, reflétant la fiabilité globale de leurs services. Cette excellence opérationnelle se traduit par une demande minimale d’intervention de support.
Interconnexion Optimale
🌍 Hetzner assure une interconnexion impeccable avec la France, grâce à un peering direct avec France-IX Paris qui gère des pics de 2.5TBit/s. Le peering d’Hetzner est de 100Gbit/s sur France-IX paris, qui a l’impressionnant taux de 99.9997% d’accessibilité sur l’année passée.
On note 5 à 10ms de latence toutefois dû à la distance. Dans la pratique avec HTTP/2 (et 3) l’impact est de l’ordre de la marge d’erreur et les performances supérieures des machines compensent largement cette micro perte avec des vitesses de chargement entre 2 et 4x plus rapides que de nombreux serveurs français.
Performances Réseau en Pratique
En pratique, les principaux fournisseurs d’accès français tels qu’Orange, SFR et OVH saturent un lien gigabit avec Hetzner sans souci. Free, le pire élève de l’interconnexion selon mon expérience générale avec eux, atteint quand même le Gigabit en burst puis oscille entre 100 et 250Mbit/s) à cause de ses règles QoS très conservatrices (pour ne pas dire radines). Pour Bouygues je sais qu’on sature un lien 5G sans problème, mais je n’ai pas encore eu l’occasion de tester le lien en fibre ; leur interconnexion étant généralement parmi les bons élèves, j’imagine que l’on sature donc un lien gigabit également.
Sécurité et Confidentialité au Niveau Européen
⚖️ L’Allemagne, tout comme la France, est soumise aux strictes réglementations européennes en matière de confidentialité. Hetzner respecte la norme DIN ISO/IEC 27001, garantissant un haut niveau de sécurité et de confidentialité des données. Avec le cloud Hetzner sur serveur dédié, les clients ont l’assurance de savoir où sont stockées leurs données.
Un Choix Avantageux et Fiable
✅ Hetzner se distingue non seulement par son engagement envers l’écoresponsabilité, la fiabilité et la sécurité, mais aussi par sa compétitivité tarifaire. Il représente un choix d’hébergement avantageux, surpassant de nombreuses offres françaises en termes de qualité et de performance.
Pour en profiter
Profitez d’un hébergement sur l’un de mes serveurs Hetzner infogéré et monitoré en 24/7.
Qui a envie de passer ses journées à trier des centaines de spams dans sa boîte mail ? De risquer de recevoir des virus ou du phishing, ou des intimidations ? Pas vous ? Alors voici 6 moyens de vous protéger de cette perte de temps. Cela fait 5 ans que j’ai mis toutes ces astuces en place et je ne reçois plus aucun spam.
1) N’affichez jamais votre adresse publiquement sur internet.
Il peut être tentant d’afficher votre adresse email sur votre site internet ou sur les réseaux pour faciliter le contact.
Mais les robots pirates sont à l’affût des adresses email affichées publiquement. Ils vont les récupérer pour les revendre sur le black market à des spammeurs et personnes mal intentionnées.
Pour info, une liste de 100.000 adresse se vend pour seulement $15. Il faut utiliser la solution en point 2) à la place.
2) Utilisez des formulaires de contact protégés.
Comme vous n’afficherez pas votre email sur votre site, vous allez mettre en place un formulaire de contact qui enverra les messages sur votre adresse mail. Mais un robot est tout à fait capable de remplir un formulaire de contact, vous envoyant là aussi du spam.
Tout formulaire de contact doit donc être protégé avec un système anti robots (Captcha). Certains robots arrivent à les contourner (et parfois des humains vont envoyer de la pub via votre formulaire), mais vous devriez en recevoir suffisamment peu pour pour vous focaliser sur les mails utiles.
3) N’ayez jamais confiance lorsque vous donnez votre adresse email : Utilisez des alias de messagerie.
Une sécurité à 100% n’existant pas, sur une durée suffisamment longue, tout site sur lequel vous êtes inscrit avec votre email sera théoriquement piraté. Que ce soit un site étatique, institutionnel, une grande entreprise : quasiment tous ont eu des fuites de données, même les plus grands. Aussi, vos contacts peuvent être piratés et leur carnet d’adresse récupéré. Donc la question n’est pas de savoir “si” mais “quand” votre adresse mail tombera entre de mauvaises mains.
Vous pouvez vérifier si votre adresse mail a fuité dans une brèche de données ici : https://haveibeenpwned.com/
Pour éviter de donner votre vraie adresse mail, seule l’utilisation d’alias peut vous sauver. Choisissez un prestataire qui (comme moi) permet de créer des alias de messagerie illimités. Et pas des alias dérivés de votre vraie adresse car ils permettraient de la retrouver, mais des alias indépendants. Ainsi, vous ferez un alias par prestataire sur lequel vous allez créer un compte. Un compte sur laposte.fr : donnez-leur l’email “laposte@mondomaine.tld”. Et les mails envoyés à cette adresse tomberont directement dans votre boîte. Ainsi si un jour vous notez un spam sur cette boîte, vous saurez automatiquement quel prestataire a laissé fuiter votre adresse. Vous n’avez plus qu’à créer un nouvel alias pour ce prestataire, changer l’adresse mail sur votre compte, et supprimer l’ancien alias. Et pensez-y également sur votre carte de visite, mettez un alias et répondez avec votre “vraie” adresse uniquement si vous avez confiance. Si le pire arrive, vous pourrez toujours renommer votre boîte et mettre l’ancienne en alias (voir point n°6).
4) Vérifiez les redirections vers votre boîte.
Avez le temps vous avez peut-être crée des redirections de boîtes mail vers la vôtre. Si cela peut être pratique pour une transition, ce n’est pas une solution viable à long terme. Notamment car tout spam reçu par la boîte originale sera alors transféré à son nom, faisant d’elle un spammeur…
Ne conservez donc pas une redirection ad vitam æternam mais considérez bien cela comme une solution transitoire.
5) Choisissez un prestataire email de confiance.
Certains spams incorrectement envoyés ne devraient voir la couleur d’une boîte de réception. Ils devraient être filtrés par le prestataire email avant même d’atteindre le filtre anti spam, juste car ils sont envoyés de manière insuffisamment authentifiée. Je ne vais pas citer de noms, mais certains prestataires, notamment gratuits et français, ne vérifient pas correctement l’authenticité des emails et laissent passer des aberrations.
Lorsque vous recevez des dizaines de spams par jour, votre adresse circule sûrement déjà sur des réseaux de spammeurs. Peut-être votre adresse a-t-elle fuité dans une brêche de données ou a-t-elle été affichée publiquement.
Il n’y a pas de retour en arrière, et les filtres anti spam ne feront pas de miracle ou alors ce sera au coût de procédures payantes, fastidieuses, ou de nombreux faux positifs (mails légitimes tombant en spam).
Il est sûrement temps de changer d’adresse mail. Mais vous avez certainement de nombreux comptes associés et souhaitez la conserver. Si votre prestataire supporte les alias (comme moi !), vous pourrez mettre votre ancienne adresse en alias de la nouvelle et continuer de recevoir vos emails le temps qu’il faut; et vous pourrez même automatiser leur déplacement dans un autre dossier pour ne pas polluer votre vue au quotidien. Une fois la transition terminée, appliquez bien toutes les règles de cet article et supprimez l’alias dans l’ancienne boîte. Et voilà, vous êtes “spam-free” !
Vous cherchez un hébergement email standard, open-source, sécurisé et flexible, avec alias illimités et contrôle du filtre anti spam ? Mes offres d’hébergement web incluent les adresses mail et alias illimités ! C’est par ici : https://www.lrob.fr/services/hebergement-web/
Depuis des années, les constructeurs de pages pour WordPress, appelés “builders” sont à la mode. Il s’agit d’éditeurs visuels ayant vocation à faciliter la mise en page des sites.
Elementor, Divi, WPBakery : Agences web, webmasters, chacun utilise son “builder” à tout-va. Révolution de WordPress, ou monumentale erreur, qu’en dit “l’expert WordPress” ?
La promesse des « Builders » WordPress
Les builders sont populaires car ils promettent de créer des pages riches et complexes sans toucher à la moindre ligne de code, grâce à des éditeurs visuels. Et sur ce point ils délivrent globalement leur promesse.
Mais alors Jamy, quels éléments viendraient remettre en question le bien-fondé de l’utilisation des builders dans le monde si parfait qu’est le nôtre ?
Les « Builders » WordPress vous emprisonnent
Les builders sont généralement payants, en abonnement annuel. Ayant payé votre builder, vous ne comptez donc pas faire marche arrière et ferez tout pour le faire fonctionner.
Mais un jour, la fatalité arrivera : vous aurez un souci vraiment bloquant avec votre builder et vous souhaiterez revenir en natif (sans builder). Ou choisir un autre builder.
Et là, c’est le drame.
Aucun standard, aucune interopérabilité entre les différents builders. Et surtout, aucun affichage si le plugin est désactivé.
Sans son builder, votre site est HS, vous devez le refaire totalement.
Alors, avez-vous vraiment gagné du temps et de l’argent en utilisant un builder pour façonner votre site ?
Les « Builders » vont à contre-courant de WordPress
Les builders modifient le fonctionnement natif du CMS WordPress.
Fonctionnement des builders
Un builder va occasionner des centaines de balises qui doivent être interprétées et converties dynamiquement en code HTML (le langage d’affichage final envoyé aux visiteurs) par le serveur avant d’être envoyés au visiteur.
Certains builders vont également générer des scripts (js) et feuilles de style (css) à la volée en fonction des pages.
Fonctionnement natif de WordPress
Auparavant, pour modifier l’apparence de WordPress à partir d’un thème donné, il fallait soit avoir choisi un thème très personnalisable, soit mettre les mains dans le code du site. Dans les deux cas, le contenu des pages restait natif et un changement de thème ne cassait donc pas l’intégralité du site.
Désormais, WordPress pousse Gutenberg, son système de blocs. Il permet nativement, sans aucune modification de WordPress, d’éditer visuellement tout le contenu de votre site : Pages, articles, mais également l’affichage global grâce au “full site editing”. Comme un builder en fait… ? Oui, sauf que le code généré est du HTML et n’a donc aucun coût en performances ou en temps de chargement.
L’impact sur les performances… Et l’écologie.
Lenteurs extrêmes
Durant mon expérience d’infogérant web-hosting, j’ai été sollicité par de nombreux clients WordPress se plaignant de lenteurs sur leur site. Les serveurs n’étaient pas saturés, mais leurs sites avaient un point commun récurrent : Ils utilisaient des builders WordPress.
Lors des tests avec/sans builder, j’ai observé un ralentissement de l’ordre de 10 à 40 avec leur builder activé. C’est à dire qu’un site mettant 0.3s à charger nativement passe à plus de 3s, voir plus de 10s dans les cas les plus extrêmes.
Mais le ralentissement a également lieu au niveau des visiteurs. Les nombreux et lourds scripts (js) et feuilles de style (css) générés par les builders prennent du temps à télécharger, puis doivent être interprétés. Ce faisant, ils prennent encore du temps.
Le temps, c’est de l’énergie
Les temps de chargements, ce sont des ressources de calcul et donc d’énergie consommées au niveau du serveur et de votre périphérique d’accès (smartphone, PC). Plus ça occupe les CPU (processeurs), plus de l’énergie est gaspillée.
Si la situation s’améliore avec des rustines d’optimisation du côté des builders, ou des plugins de mise en cache (qui évitent certaines consommation serveur), les performances ne sont généralement toujours pas au rendez-vous par rapport à un site natif.
Impact sur le succès du site
On le sait, la rétention des visiteurs sur un site dépend notamment de sa vitesse. Aussi, on a de bonnes raisons de penser que les moteurs de recherche favorisent les sites les mieux optimisés.
Impact écologique indéniable
WordPress propulse plus de 43% des sites web dans le monde. Nombre de ces sites comportent des builders, générant une surconsommation de ressources serveur de l’ordre de x10 (voir jusqu’à x40). Les builders ont donc une emprunte carbone considérable qu’il serait intéressant de mesurer objectivement. Je ne serais pas étonné que cela augmente la consommation d’énergie d’internet de 10% ou plus.
Fiabilité et sécurité
Une bonne partie des pannes observée sur les sites lors des mises à jour est due aux builder. Vous avez intérêt à avoir un bon backup. Tout ça, c’est de la maintenance additionnelle, perdue pour le webmaster et/ou pour le client.
De plus, les builders étant populaires, des failles de sécurité sont régulièrement découvertes. Donc si vous mettez à jour, vous risquez de casser le site, et si vous ne mettez pas à jour, vous risquez un hack. Vous choisissez quoi ?
Builders à outrance
Certains ont le réflexe systématique du builder. Même sur un site extrêmement simple. Mais est-ce vraiment nécessaire ?
Dans de nombreux cas, utiliser un builder revient à tuer une mouche au lance-flamme.
La règle n°1 de l’optimisation : n’utiliser que ce qui est nécessaire. Un peu de minimalisme ne fait de mal à personne.
A-t-on besoin de réfléchir 2000 ans à décaler une image d’un ou deux pixels ? Cela ne fait plaisir qu’aux web designers. Les utilisateurs et propriétaires des sites n’en ont rien à faire. Dans le monde réel, ce n’est pas ce qui importe pour le succès d’un site, c’est d’abord son contenu.
Ce qu’il faut, c’est avoir un site simple à maintenir, fiable, sécurisé, et rapide à afficher pour les visiteurs, et surtout, contenant les informations utiles recherchées par vos visiteurs, pour un bon référencement SEO (sur les moteurs de recherche Google et autres), et avec une emprunte carbone la plus faible possible.
Les alternatives
De nombreux thèmes natifs, souvent gratuits, sont capables d’offrir une expérience visuelle claire et plaisante et permettent déjà un excellent niveau de personnalisation.
De plus, avec Gutenberg, WordPress offre désormais la fonction “Full Site Editing” permettant, avec les thèmes compatibles, d’agencer chaque partie du site comme on le souhaite.
Cela devrait dans un futur proche marquer le début de la fin des builders.
Personnellement, j’ai toujours refusé d’aller à l’encontre du fonctionnement natif de WordPress, et j’ai adopté Gutenberg dès sa sortie malgré les bugs et limitations.
