Georgi, de chez CloudLinux OS, a accepté de nous présenter leur impressionnant écosystème logiciel ! 🎙️
Plus qu’un OS : un univers complet pour l’hébergement sécurisé
Grâce au CloudFest, j’ai découvert que CloudLinux est bien plus qu’un simple système d’exploitation optimisé pour l’hébergement. C’est aussi l’éditeur de la célèbre suite de sécurité Imunify, que nous utilisons déjà sur les hébergements web LRob — et dont nous sommes pleinement satisfaits.
CloudLinux promet de simplifier la vie des hébergeurs avec notamment des outils de gestion de ressources améliorés.
En off, nous avons également parlé du partenariat avec KernelCare, une solution qui permet de mettre à jour le noyau Linux sans redémarrer le serveur. Un gain de sécurité et de stabilité énorme pour les infrastructures critiques !
Imunify, un outil de sécurité tout-en-un
Imunify, c’est une sécurité à tous les niveaux :
au niveau du serveur,
au niveau de PHP,
contre les malwares et attaques,
avec un pare-feu intégré et un système de réputation.
🎯 Pour les hébergeurs comme LRob, c’est une solution incontournable.
Une interview pleine de bonne humeur
Merci à Georgi pour sa disponibilité et sa bonne humeur lors de cette rencontre. C’était un plaisir de découvrir l’envers du décor et de mieux comprendre la puissance de leur écosystème.
▶️ [Activez les sous-titres pour profiter pleinement de l’interview !] (L’année prochaine, promis, je viendrai avec un micro dédié 😄)
Une suite à tester sans attendre
L’écosystème CloudLinux mérite clairement d’être exploré. Je compte bien demander un « free trial » pour tester plus en profondeur leurs outils.
Un refroidissement liquide pour votre station de travail professionnelle ? Alphacool dit oui ! Voici ma découverte des nouveautés de la marque allemande au CloudFest 2025.
Avec la montée en puissance des applications d’IA, de rendu 3D, de virtualisation ou encore de création audiovisuelle, les PC dits « lourds » nécessitent un système de refroidissement à la hauteur. Alphacool propose des solutions watercooling haut de gamme pour ceux qui cherchent à allier performances extrêmes, silence et durabilité des composants.
À partir de quand le watercooling devient-il pertinent ?
Certains pourraient se demander si une telle installation est nécessaire en dehors du minage ou du gaming intensif. Comme l’a très justement fait remarquer Olivier Marcu : « À partir de quel degré d’activité un tel boîtier serait utile ? Faut-il miner ou est-ce valable pour la simple utilisation d’un traitement de texte avec un doc de 10 pages ? » La réponse est claire : le watercooling prend tout son sens dès lors que l’on entre dans des charges de travail soutenues, avec des consommations qui dépassent les 300 watts (CPU + GPU). C’est dans ce contexte qu’il permet d’assurer un refroidissement efficace et un silence optimal — des critères souvent décisifs pour les professionnels de la création, de l’ingénierie ou de l’audio.
Silence et performances : le bon équilibre
Robin Labadie, hébergeur spécialisé dans la performance, partage son retour d’expérience : « Ma propre workstation est équipée en watercooling avec trois radiateurs de 360 mm, pour une conso en pointe de seulement 400 W sur la partie CPU+GPU, permettant un silence maximal. »
Malgré une maintenance légère annuelle (vidange annuelle du circuit), ce type de configuration garantit un environnement de travail très silencieux. Un atout non négligeable.
Des solutions modernes pour des contraintes anciennes
Heureusement, les solutions d’aujourd’hui permettent de s’affranchir de ce genre de bricolage. Avec des logiciels de contrôle comme FanControl ou une gestion fine via le BIOS, le silence devient un objectif atteignable — même dans un studio d’enregistrement. Pour aller encore plus loin, certains choisissent désormais de placer leur machine dans une pièce séparée, grâce à des rallonges USB ou HDMI en fibre optique. Résultat : un environnement totalement silencieux, sans compromis sur la puissance.
Hetzner : L’éco-responsabilité à prix ultra compétitif
Faire des économies d’énergie peut permettre d’être compétitif ? Hetzner répond : oui !
Le fournisseur de serveurs a montré un service exemplaire pour héberger les serveurs web ultra puissants de LRob depuis des années. Et je me devais d’en découvrir davantage sur leur recette magique… et de le partager avec vous !
Une stratégie maison, littéralement
Contrairement à de nombreux fournisseurs, Hetzner conçoit et fabrique une grande partie de ses équipements en interne. Par exemple ? Des conduits d’air imprimés en 3D par leurs soins — avec le logo Hetzner s’il vous plaît !
Résultat : non seulement c’est éco-responsable, mais c’est aussi plus économique. Un vrai double avantage, preuve que durabilité peut rimer avec rentabilité.
Merci pour l’interview
Merci infiniment à Lenz, qui a accepté de répondre à mes questions lors de cette interview improvisée au CloudFest. Grâce à lui, on a pu découvrir les coulisses d’Hetzner et certaines de leurs petites astuces bien gardées.
▶️ [Pour une meilleure expérience, activez les sous-titres !] (Promis, l’an prochain j’apporte un micro dédié 🎤)
Allez plus loin avec des hébergements performants et éco-responsables
Chez LRob, nous partageons pleinement cette vision : des infrastructures optimisées, des systèmes de défense intelligents contre les attaques, et une consommation CPU réduite jusqu’à 95%. Le tout hébergé exclusivement sur les serveurs Hetzner.
👉 Hébergez votre site chez LRob dès maintenant : Spécialiste WordPress, nous proposons également des offres revendeur (Web Agency), avec un support rapide et compétent !
Le CloudFest est autant un salon des acteurs du cloud qu’un festival. Il ne manque pas de marquer les mémoires chaque année. Cette année 2025 a une fois de plus été riche en rencontres professionnelles et en sensations fortes !
Entre jeux, montagnes russes, dîners, concerts, et rendez-vous pros avec des partenaires tous plus sympathiques les uns que les autres… Le monde du « cloud » devient un environnement de travail rêvé !
Mais le plus cette année : LRob a filmé quelques vidéos et quelques interviews pour que les absents de cette année puissent quand même profiter de l’atmosphère et de quelques nouveautés à ne pas manquer dans l’univers du Cloud.
Introduction CloudFest (teaser)
Cette vidéo montre un aperçu de l’ambiance générale : un rythme effréné riche en rencontres et en festival, sur 4 jours. Et nous n’avons pas filmé le quart de ce que nous avons fait ou vu !
Vidéo officielle
Interview Hetzner
Ne manquez pas l’interview chez Hetzner pour comprendre les secrets de l’éco-responsabilité ultra compétitive !
Interview CloudLinux OS
Voyez l’interview chez CloudLInux pour découvrir un OS qui peut simplifier la vie des hébergeurs et Imunify, la suite de sécurité tout compris.
Interview Realtime Register
LRob pourrait devenir registrar grâce à cette rencontre avec Realtime Register, et vous aussi !
Combien vous coûterait la perte de vos données d’entreprise ou perso ? Vous ne voulez pas le savoir. Et pourtant, c’est un risque bien réel – qui touche tous les jours des particuliers comme des professionnels, souvent par négligence, oubli ou fausse impression de sécurité.
À l’occasion de la Journée mondiale de la sauvegarde (World Backup Day), célébrée chaque année le 31 mars, LRob, votre hébergeur web spécialisé WordPress, vous aide à faire le point sur les bonnes pratiques, les solutions concrètes et les pièges à éviter pour ne plus jamais perdre une donnée précieuse.
L’idée est née sur Reddit, lorsqu’un utilisateur a raconté avoir perdu son disque dur… Et regretté de ne pas avoir été mieux informé sur les sauvegardes. Depuis 2011, cette journée incite les internautes à prendre un engagement simple : sauvegarder leurs données régulièrement.
Chaque 31 mars, entreprises et médias tech se mobilisent pour sensibiliser à l’importance des sauvegardes. Podcasts, articles, posts sur les réseaux sociaux. L’objectif est clair : éviter la catastrophe avant le 1er avril, et ce n’est pas une blague.
🏢 Pour les entreprises : le combo gagnant : NAS + Cloud
Si vous êtes une entreprise avec des données critiques (clients, projets, documents RH, compta…), il est indispensable d’organiser vos données et leurs sauvegardes.
💾 Méthode 1 : utiliser un NAS
Un NAS (Network Attached Storage) permet de stocker localement vos fichiers sensibles, avec des accès sécurisés pour vos équipes. Encore mieux : vous pouvez l’utiliser pour sauvegarder votre hébergement web LRob, à condition de disposer d’une IP fixe fournie par votre FAI. Nous en reparlons dans le chapitre suivant.
🛑 Mais attention : un NAS n’est pas une sauvegarde. Et non, même avec du RAID qui fournit une redondance en cas de panne des disques. Pourquoi ? Parce que le RAID protège contre la panne matérielle jusqu’à un certain niveau seulement, et pas contre la suppression accidentelle, un ransomware ou un incendie.
Il faut donc répliquer le NAS sur un service en ligne (Cloud) sécurisé. Par exemple :
Cloud S3 compatible ➜ Prix très variable en fonction des offres
Pulseheberg Storage Cloud ➜ À partir de 6€/mois pour 250 Go ➜ Compatible avec tous les NAS pros du marché… Et les hébergements Plesk ! ➜ LRob peut vous assister pour la mise en place.
☁️ Méthode 2 : Travail collaboratif via Nextcloud managé par LRob
Vous travaillez en équipe, vous gérez des projets partagés, vous voulez centraliser vos documents ? Vous souhaitez ne jamais être pris au dépourvu en déplacement, ne pas nécessiter de VPN ou autre configuration fastidieuse
Alors Nextcloud est sûrement fait pour vous !
Bien plus économique que les solutions Microsoft et Google pour les grandes équipes, la solution libre et open-source pourrait tout à fait vous convenir en plus de vous faire retrouver la souveraineté de vos données. Chez LRob on l’a adoptée depuis 2017 et on ne changerait pour rien au monde !
L’optique est intéressante : Les fichiers sont stockés sur chaque ordinateur connecté à Nextcloud et sur le serveur. Les smartphones (Android et iOS) peuvent sélectivement synchroniser n’importe quel fichier. Cela permet de facilement partager et synchroniser des fichiers au sein de l’équipe et ne vous empêche pas de travailler en cas de perte d’internet. Cela peut également créer de nouveaux workflows comme le partage de bases de données de mots de passe avec KeePass.
Nextcloud devient ainsi votre centre névralgique de la collaboration, tout en restant compatible avec les mêmes solutions de sauvegarde que nos hébergements WordPress.
Et grâce à LRob, vous pouvez également sauvegarder l’intégralité de vos données Nextcloud sur votre NAS ou hébergement externe par simple FTP.
💾 Les sauvegardes de vos hébergements web chez LRob : automatiques, externalisées, intelligentes
Plesk + LRob = tranquillité d’esprit
Bonne nouvelle : si votre hébergement web ou votre instance Nextcloud est chez LRob, vous êtes déjà bien protégé et vous avez des options additionnelles simples et abordables à mettre en place !
LRob effectue des sauvegardes hébergeur pour vous :
En clair : vous avez une première sécurité pour vos données, sans y penser.
Mais ce n’est pas tout : grâce à notre interface Plesk, vous pouvez planifier vos propres sauvegardes pour que toutes vos données soient sauvegardées automatiquement, de façon externalisée (c’est-à-dire en dehors et loin du serveur principal), incrémentale (on ne sauvegarde que ce qui a changé chaque jour) et ce vers un simple serveur FTP sécurisé. Le tout étant restaurable facilement depuis votre panneau de contrôle LRob ou vers un autre hébergement Plesk.
Vous respectez ainsi les premières préconisations de sécurité en matière de sauvegarde.
Le serveur FTP utilisé pour la sauvegarde peut être un NAS dans vos locaux ! Ainsi vous maximisez la souveraineté de vos données.
Pas de NAS ? Optez pour un VPS Storage Cloud chez Pulseheberg ➜ À partir de 6€/mois pour 250Go ➜ LRob peut configurer la sauvegarde en moins d’une heure de main d’œuvre
✅ En résumé : vos prochaines étapes
Voici la méthode qui fonctionne parfaitement pour nous depuis près de 10 ans :
Centralisez votre travail collaboratif avec Nextcloud managé
Mettez en place un NAS en local pour vos données d’entrepriseou un cloud externe (S3 ou Pulseheberg)
Sauvegardez automatiquement votre site web et votre Nextcloud gâce à Plesk
Nous espérons que celle-ci peut vous inspirer.
🛡️ Faites le bon choix maintenant, pas après une perte de données
Ne soyez pas la personne qui dit “j’aurais dû…”
Profitez de cette Journée mondiale de la sauvegarde pour faire le point et vous mettre à l’abri définitivement.
Chez LRob, nous sommes là pour vous accompagner — que vous soyez freelance, PME, ou grosse structure.Contactez-nous, on s’occupe du reste. 🙌
Le nom de domaine est requis pour la création de votre site internet et de vos emails personnalisés. Un bon choix de nom de domaine peut être la clé de votre succès et doit donc être pris très au sérieux.
LRob proposera prochainement l’enregistrement de noms de domaines. En attendant, nous vous aidons à bien les configurer et à faire les bons choix pour votre projet. L’occasion de faire le point pour bien choisir vos noms de domaine !
Avant de plonger dans le vif du sujet, si vous cherchez un hébergement web performant, sécurisé et avec un vrai support humain, découvrez nos offres d’hébergement chez LRob : https://portail.lrob.fr/hebergement-web/.
Alors : quel nom choisir, quelle extension choisir, avec ou sans tiret, quels sont les pièges à éviter et les bonnes pratiques à appliquer ?
Réponses.
Sommaire
Qu’est-ce qu’un nom de domaine ?
Un nom de domaine est l’adresse lisible par les humains pour accéder à un site internet. C’est ce que vous tapez dans votre navigateur, comme exemple.tld. Il se compose généralement de deux parties :
Le nom (par exemple : exemple)
L’extension, aussi appelée TLD (Top-Level Domain) comme .com, .fr, .net, etc.
Les TLD sont gérés par des entités appelées registres (ou registries en anglais), comme AFNIC pour le .fr ou Verisign pour le .com. Les registrars (bureaux d’enregistrement) sont les entreprises auprès desquelles vous pouvez acheter ces domaines (comme Gandi, OVH, etc.). Chez LRob, nous n’enregistrons pas de domaines, mais nous pouvons vous conseiller objectivement.
Dès que vous possédez votre nom de domaine, vous pouvez faire autant de sous-domaines que désiré. Le sous-domaine le plus courant est www, tel que www.exemple.tld est un sous-domaine de exemple.tld. Il faut ensuite simplement que votre hébergeur soit compatible pour héberger ces sous-domaines, ce qui est bien le cas des hébergements web LRob.
1. Vérifiez que le nom n’est pas déjà pris par un concurrent
Avant toute chose, faites des recherches. Si un concurrent majeur utilise déjà le nom ou quelque chose de très proche, cela peut semer la confusion, nuire à votre crédibilité, voire poser des problèmes juridiques. Un outil comme whois vous permet de vérifier la disponibilité. Cela doit être vérifié dès le choix de votre marque.
Astuce : faites aussi une recherche Google pour voir si le nom est déjà très présent ou associé à une autre marque.
2. Choisissez une extension adaptée à votre cible géographique
Si vous ciblez la France, privilégiez un .fr. Pour une audience européenne, le .eu est pertinent. Si votre activité est internationale, le .com reste une valeur sûre. Les extensions régionales (comme .bzh pour la Bretagne) peuvent aussi avoir du sens selon votre audience.
3. Utilisez une extension adaptée à votre secteur
Les extensions dites nouvelles ou sectorielles permettent d’afficher votre domaine d’activité dès l’URL :
.shop pour les boutiques en ligne
.org pour les associations
.tech pour les projets tech
.design, .art, .photo… selon votre univers
Elles peuvent être plus disponibles que les .com et ajouter un brin d’originalité, tout en restant professionnelles.
4. Optez pour un nom de domaine court
Un nom plus court est plus facile à retenir, plus rapide à taper, et réduit les risques d’erreur. Essayez de viser moins de 15 caractères si possible. Les tirets sont à éviter sauf cas particulier, car ils complexifient la communication orale (ex. : “mon-tres-joli-site.com”).
5. Assurez-vous qu’il soit facile à épeler
Un bon test : dites le nom à voix haute à quelqu’un. Si la personne ne sait pas comment l’écrire ou fait une faute, il est peut-être trop complexe. Évitez les jeux de mots trop subtils, les chiffres qui remplacent des lettres, ou les mots étrangers difficiles à orthographier.
6. Pensez stratégique : marque ou mot-clé ?
Si vous construisez une marque forte, le nom doit être original et unique. Exemple : lrob.fr. Si vous souhaitez vous positionner rapidement sur un secteur via le référencement naturel (SEO), intégrer un mot-clé pertinent dans le domaine peut être judicieux : garage-nantes.fr, photographe-lyon.com, etc.
7. Évitez les ambiguïtés et les caractères piégeux
Certaines lettres ou combinaisons peuvent prêter à confusion :
Le “i” majuscule et le “l” minuscule (nous savons de quoi nous parlons, LRob étant souvent pris pour iRob… Au point où nous avons aussi réservé les variantes avec un « i » !).
Le “0” et le “o”
Des doubles et triple lettres difficiles à lire (comme assso.com)
Vérifiez aussi que le nom ne forme pas un mot inapproprié quand lu en entier (le fameux “penisland.net” pour “Pen Island”…).
8. Sécurisez les variantes importantes du domaine
Même si vous n’utilisez que le .fr, il peut être stratégique d’enregistrer aussi le .com, .net ou .eu pour éviter que quelqu’un d’autre ne s’en empare. Vous pouvez les rediriger vers votre site principal.
Cela protège votre marque et limite les risques de phishing ou d’usurpation.
9. Inspirez confiance avec votre nom et votre extension
Un nom de domaine crédible, lisible et bien construit donne confiance. Une extension reconnue comme .fr, .com, .org ou .net rassure souvent davantage qu’un TLD obscur ou douteux.
Les noms trop farfelus, à rallonge ou sans lien avec l’activité peuvent rebuter les visiteurs et les moteurs de recherche.
10. Vérifiez la disponibilité sur les réseaux sociaux
Ce n’est pas une règle obligatoire, mais c’est un vrai plus : si le nom que vous choisissez est aussi libre sur les réseaux sociaux (Twitter, Instagram, Facebook, etc.), vous assurez une cohérence de marque sur tous les canaux. Des outils comme namecheckr.com permettent de vérifier cela en un clic.
Bonus : testez votre nom auprès de vraies personnes
Avant de valider définitivement votre choix, faites un test rapide autour de vous ou avec votre cible. Est-ce que les gens comprennent le nom ? Est-ce qu’ils s’en souviennent après 10 minutes ? Peuvent-ils le taper sans erreur ? Un petit sondage peut éviter de grosses erreurs.
En résumé
Bien choisir son nom de domaine, n’est donc pas simple, mais c’est absolument essentiel pour poser des bases solides pour votre présence en ligne. C’est un choix stratégique, à la fois technique, marketing et parfois émotionnel.
Choisir un hébergement web mutualisé et performant peut s’avérer complexe. Avec une multitude d’offres sur le marché, il est souvent difficile pour un webmaster ou une agence de démêler les diverses spécifications techniques et de savoir à l’avance quelles seront les performances réelles d’un hébergement web.
Temps de réponse, nombre de connexions simultanées supportées, vitesse de chargement… Ces informations manquent très souvent. Et pour cause : d’une part – et nous le verrons dans ce test – il est extrêmement difficile d’établir des normes de mesure en la matière, et d’autre part, il n’existe à notre connaissance aucune obligation légale à afficher ces éléments.
Chez LRob, nous accordons la plus grande importance à fournir les performances maximales possibles pour vos sites internet. Et pour s’assurer que nous offrons toujours l’excellence avec nos offres d’hébergement web, nous avons élaboré plusieurs techniques de test de performances, basés sur des outils très simples. Aujourd’hui, nous dévoilons ces techniques à tous et les employons pour tester plusieurs offres de confrères.
Nous avons ainsi décidé de nous mettre dans la peau d’un client à la recherche d’un hébergement performant. Nous avons mesuré le temps de réponse ponctuel et moyen des serveurs pour un site web donné, le nombre de pages par seconde servies, la gestion du cache et les performances sous forte charge.
Nous avons ainsi testé 10 offres chez 6 hébergeurs plébiscités en France, dont celles de LRob. Le tout en vous expliquant un maximum notre protocole de test et tous les détails techniques. Prenez bien le temps de consulter les réserves et explications pour une lecture éclairée des résultats.
Ce que l’on peut déjà vous dire : LRob s’en sort très bien dans la plupart des tests ; et si votre site web reçoit un fort trafic, l’activation d’un cache vous sera indispensable chez tous les hébergeurs !
Sommaire
Présentation des offres d’hébergement web testées
Nous avons testé au total 10 offres chez 6 hébergeurs.
Les offres testées couvrent une large gamme de prix, allant de 39,48 € HT/an à 480 € HT/an.
Les hébergeurs sont présentés par ordre alphabétique, les tarifs sont donnés annuellement et hors taxes.
HaiSoft
HaiSoft est un hébergeur français affichant près de 25 ans d’existence. Ses serveurs sont situés en France à Tours et Vélizy. HaiSoft propose des serveurs virtuels et dédiés infogérés, mais ce test porte sur deux de leurs offres mutualisées.
Pour HaiSoft, nous avons testé les offres :
HaiSoft Essentiel (47.88€ HT/an)
HaiSoft Pro + Support avancé WordPress (179.88€ HT/an) – Notée « HaiSoft Pro WP » durant ce test
Ionos
Ionos (anciennement 1&1) est un hébergeur allemand. Ionos exploite 31 datacenters à travers le monde, dont un à Paris et un second bientôt opérationnel.
Pour Ionos, nous avons testé une offre dédiée à WordPress :
Ionos Expand (12€ HT/an pendant 1 an puis 120€ HT/an)
LRob
LRob est un hébergeur indépendant basé en France. Les serveurs sont situés en Allemagne dans des datacenters Hetzner. Spécialiste WordPress, LRob propose des serveurs hautes performances optimisés.
Nous avons inclus nos 4 offres mutualisées single site :
LRob Starter Web (120€ HT/an) – Notée « LRob Starter » durant ce test
LRob Pro Web (190€ HT/an) – Notée « LRob Pro » durant ce test
LRob Super Web ( 300€ HT/an) – Notée « LRob Super » durant ce test
LRob Ultra Web (480€ HT/an) – Notée « LRob Ultra » durant ce test
Les tests ont été réalisés en conditions réelles sur les serveurs LRob utilisés pour les clients.
LWS
LWS est un hébergeur français présent sur le marché depuis plus de 20 ans, indiquant plus de 680 000 hébergements web. Ses datacenters sont situés en France et ses serveurs frontaux sont renouvelés tous les deux ans pour garantir une performance optimale.
Pour LWS, nous avons testé une offre cPanel :
LWS cPanel L (59.88€ HT/an pendant 1 an puis 83.88€ HT/an)
OVH
OVH est un hébergeurs français, affichant 1,6 millions de clients et 43 datacenters à travers le monde, dont plusieurs en France. OVH met en avant son rapport performance/prix.
Pour OVH, nous avons testé l’offre mutualisée second prix :
OVH PERSO (39.48€ HT/an)
o2switch
o2switch est un hébergeur français populaire avec plus de 700 000 sites hébergés. o2switch met en avant des « Ressources Monstrueuses » et des serveurs optimisés pour la sécurité et la rapidité.
Pour o2switch, nous avons choisi leur offre mise en avant la plus abordable la première année :
o2switch Cloud. (21.12€ HT/an puis 192€ HT/an ou 324€ HT/3 ans)
Tableaux récapitulatif des offres testées
Chaque hébergeur présentant ses informations de manière différente, nous avons sélectionné et agrégé des données comparables pour faciliter la distinction entre les hébergements web.
Concernant la version de PHP, les informations disponibles sur les fiches descriptives publiques n’étant pas toujours à jour, nous avons directement vérifié les versions disponibles dans les panels des hébergeurs. Nous avons utilisé la dernière version disponible de PHP pour chaque hébergeur, sauf pour Ionos qui recommande PHP 8.1 pour assurer la compatibilité avec son système WordPress.
Notez que ces valeurs relevées et mises en forme datent du 6 Mars 2025 et peuvent devenir obsolètes, ne pas inclure toutes les subtilités annoncées par les hébergeurs ou comporter des erreurs ou imprécisions involontaires. Pour une description plus à jour , plus complète et plus précise, nous vous invitons à consulter les pages produits de chaque hébergeur.
Domaine inclus la 1ère année, valable uniquement lors de la commande initiale et pour un engagement de 12 mois, au choix parmi les extensions suivantes : .fr, .eu, .be, .com, .net, .org, .info, .me, .biz, .online.
Bénéficiez de sauvegardes quotidiennes automatiques et restaurez vos données en 1 clic pour un site Web, gratuitement pendant 12 mois avec notre partenaire Jetpack. Vous obtiendrez un coupon que vous pourrez activer avec un compte WordPress et le plugin Jetpack.
120€
LRob Starter Web
Non
Sauvegarde hébergeur externalisée quotidienne, rétention 12 mois, restaurable à la demande.
120€
LRob Pro Web
Non
Sauvegarde hébergeur externalisée quotidienne, rétention 12 mois, restaurable à la demande.
190€
LRob Super Web
Non
Sauvegarde hébergeur externalisée quotidienne, rétention 12 mois, restaurable à la demande.
300€
LRob Ultra Web
Non
Sauvegarde hébergeur externalisée quotidienne, rétention 12 mois, restaurable à la demande.
Inclus jusqu’à 20Go, payant ensuite, Quotidien sur 7j, hebdomadaire sur 1 mois, puis mensuel sur 3 mois
58.88€
OVH Perso
Les extensions suivantes sont incluses pour une période d’un an pour tout achat d’un hébergement web OVHcloud, puis le renouvellement est facturé au prix annuel de l’extension sélectionnée dans la liste suivante : .fr, .com, .shop, .store, .tech, .me .live, .space, .xyz, .online, .site, .pro, .cloud, .blog, .name, .ovh, .boutique, .net, .org, .info, .eu, .re, .be, .it, .de, .co.uk, .pl. Non valide pour les extensions incluant le transfert gratuit.
Sauvegarde /restauration de vos fichiers J-1, J-2, J-3, J-7, J-14
39.48€
o2switch Cloud.
Un nom de domaine inclus à la commande et au renouvellement : .fr .com .net .org .eu .be .click .link .pm .re .tf .wf .xyz .yt
Sauvegardes Journalières 45 Jours
192€/an
Sélecteur de version PHP Ionos nous ayant conduits à utiliser PHP 8.1.
⚠️ Réserves (disclaimers)
Non responsabilité
Ces résultats sont publiés à titre informatif uniquement et ne constituent pas une recommandation commerciale. LRob ne saurait être tenu responsable des décisions prises sur la base de ces résultats. LRob décline toute responsabilité en cas de perte commerciale ou financière liée à l’interprétation ou à l’utilisation de ces résultats.
La démarche
Le but de cette démarche est d’apporter une méthodologie aux utilisateurs d’hébergement web mutualisés ou similaires quand à la mesure réelle des performances des hébergements, et d’apporter des clés de compréhension sur certains critères aidant à choisir un service d’hébergement web de manière informée. Pour cela, nous emploierons les techniques et méthodologies habituellement utilisée par LRob dans la mesure de ses propres performances, qui seront ici appliquée à la mesure d’offres d’hébergement diverses et variées.
Nous nous engageons à présenter les résultats de manière factuelle et objective, en nous basant uniquement sur les données recueillies lors des tests et à faire de notre mieux pour relever des différents biais de mesure ou biais méthodologiques.
Ce test n’a nulle vocation à dénigrer une quelconque entreprise et nous insistons sur le fait que les offres testées ne sont pas comparables directement, que ce soit sur le tarif, les garanties, l’architecture technique ou autre.
Limites techniques et méthodologiques
La mesure de performances est un sujet complexe impliquant de nombreux facteurs, et malgré nos efforts pour proposer une mesure la plus objective possible des performances, ce type de test ne peut pas prendre en compte tous les facteurs déterminants et ne doit pas être pris comme une source d’information représentative. Il s’agit d’un test indépendant réalisé de bonne foi, mettant en perspective plusieurs offres à des tarifs différents, avec des architectures et infrastructures différentes, des avantages et garanties différentes.
Les résultats obtenus peuvent varier en fonction de paramètres techniques spécifiques à chaque hébergeur, y compris des configurations internes non accessibles publiquement. Ces résultats ne constituent donc pas une comparaison exhaustive des performances réelles.
Certains réglages hébergeur en particulier comme le « rate-limiting » qui permet de protéger votre hébergement des attaques DoS et DDoS (Distributed Denial of Service) peuvent empêcher ou fausser certaines mesures de performances. Lorsque nous pensons qu’une telle protection est en place, nous partageons quand même les résultats mais émettons une réserve. Nous vous invitons à lire attentivement les explications présentés tout au long de ce test pour plus de précisions.
De plus, les performances peuvent varier au fil du temps en fonction du taux de remplissage des serveurs et d’autres variations passagères. Aussi, certains hébergeurs pourraient fournir de meilleures ou de moins bonnes performances à offre équivalente en fonction du hardware physique du serveur utilisé. Certains hébergeurs pourraient au final montrer de meilleurs ou de moins bons résultats que ce que montrent notre test.
En considérant le nombre de données important à analyser et à reporter manuellement dans un tableur et dans des graphiques, il est possible que des erreurs humaines soient présentes au sein du test. Ce test a en effet été réalisé par un seul humain, Robin LABADIE, et n’est pas infaillible ou exempt de potentielles erreurs et de potentiels bais de méthodologie, d’analyse ou d’appréciation. Si vous relevez une erreur, nous vous invitons à nous le signaler en commentaire de l’article ou via notre formulaire de contact et nous examinerons et corrigerons cela dans la mesure du possible.
Données non testées
Nous ne couvrirons pas les notions de support, d’expérience utilisateur et les divers problèmes de gestion et administration rencontrés lors de ce test de différents hébergeurs, car nous estimons que cela ne peut pas être traité objectivement, contrairement à des tests techniques qui resteront donc notre point d’attention principal.
Les éventuelles différences de réseau entre IPv4 et IPv6 ne sont pas prises en compte lors de ces tests et chaque test peut se dérouler en IPv4 ou IPv6 sans que cela ne soit vérifié.
Conflits d’intérêt
LRob étant lui-même hébergeur web, nous reconnaissons qu’un conflit d’intérêt potentiel peut exister. Nous nous engageons néanmoins à fournir une analyse factuelle et transparente, basée uniquement sur les résultats des tests.
Chacun est invité à conduire ses propres tests
LRob ne prétend pas offrir une analyse définitive ou exhaustive, mais simplement partager les résultats de ses tests en toute transparence.
Nous pensons qu’un seul test comme celui réalisé ce jour ne suffit pas à se faire une idée précise du paysage de l’hébergement web et que la multiplication des tests indépendants est clé.
Chacun est invité à souscrire aux divers hébergeurs existants et à conduire et partager ses propres tests afin de pouvoir tirer ses propres conclusions selon sa propre méthodologie et ses propres biais. Nos méthodologies sont explicitées dans cet article et nous acceptons que vous utilisiez tout ou partie de celle-ci pour comparer vos résultats aux nôtres.
LRob se tient disponible pour fournir des hébergements à des fins de tests de performances à titre gratuit. Pour nous solliciter, nous vous invitons à nous contacter.
Méthodologie des tests
Site web testé
Pour ce test, nous avons créé un site WordPress très simple et basé sur le contenu du site portail.lrob.fr/. Les articles ont été importés à l’aide des outils natifs de WordPress.
Version de WordPress : Dernière version disponible au moment du test — WordPress 6.7.2.
Indexation : Le site est configuré pour ne pas être indexé par les moteurs de recherche afin de limiter le trafic externe.
Confidentialité : Les URLs ne sont pas communiquées pour aider à obtenir un test isolé.
Plugins WordPress installés
Les 6 à 7 plugins installés et actifs sont les suivants :
Easy WP SMTP 2.10.0 – SMTP configuré
Go Live Update Urls 7.0.2 – Changement d’URLs dans les articles
RankMath SEO 1.0.239 – Configuration basique
W3 Total Cache 2.8.6 – Cache Redis si disponible, sinon « Disk Basic » (désactivé pour les tests sans cache)
WordPress Importer 0.8.3 – Importation des articles
WP Statistics 14.12.5 – Génération de charge supplémentaire
WPForms Lite 1.9.4.1 – Génération de charge supplémentaire (formulaire par défaut)
Note : Pour Ionos, nous avons désactivé les plugins pré-installés. Le plugin « Performance » n’a pas semblé avoir d’impact dans notre test et n’a donc pas été utilisé pour les tests avec cache.
Thème WordPress
Le thème utilisé est le thème natif Twenty Twenty-Five (1.1).
Le site comprend une seule page d’accueil contenant :
Header : Logo, titre du site, menu avec un élément, liste des catégories.
Corps de la page :
Grand logo
Titres
Liste de 30 articles avec images
Formulaire de contact WPForms (formulaire par défaut)
Footer : Logo, titre du site, tagline du site, éléments de menu par défaut (8 éléments), nom du thème et lien « Designed by WordPress. »
Migration et configuration technique
Le site a été compressé au format .zip et la base de données a été exportée pour migration vers les différents hébergements.
Les URLs dans les articles ont été corrigées via le plugin Go Live Update Urls afin de garantir le bon chargement des médias.
L’URL a été mise à jour directement dans la table _options de la base de données.
Type de tests réalisés
Nos tests ont été principalement axés sur les temps de réponse du site WordPress sur chaque hébergement. Nous avons réalisé trois séries de tests distinctes :
GTMetrix : Test de réponse GTMetrix depuis le serveur de Londres (UK), avec et sans cache. Ce test permet de mesurer plusieurs métriques clés de performance.
ApacheBench : Test de charge avec ApacheBench 2.3, réalisé depuis un VPS ARM Hetzner situé à Nuremberg (Allemagne). Ce test permet de mesurer le nombre de pages servies par seconde dans différentes conditions (cache activé ou non).
Uptime Kuma : Mesure du temps de réponse moyen toutes les 60 secondes sur une période de 24 heures, sans cache, depuis le même VPS ARM Hetzner, qui est un serveur de monitoring LRob faisant tourner Uptime Kuma 1.23.16.
Détails des tests
GTMetrix : Tests de vitesse de chargement
Les tests GTMetrix ont été effectués avec une offre GTMetrix Micro depuis le serveur de Londres, le plus proche de la France.
Les résultats peuvent être influencés par la qualité de l’interconnexion réseau entre l’hébergeur et le serveur de Londres.
Pour garantir des mesures représentatives, nous avons réalisé jusqu’à trois tests par hébergement et sélectionné le meilleur TTFB (Time to First Byte) des trois.
Cette procédure a été répétée deux fois : une fois sans cache et une fois avec cache.
Les temps supérieurs à 1000 ms sont arrondis au dixième de seconde près (exemple : 1,256 s ➔ 1,3 s).
ApacheBench : Test de charge
Nous avons initialement tenté de réaliser ces tests depuis une connexion Orange Pro FTTH, mais des limitations réseau nous ont conduits à utiliser un serveur Hetzner déjà à notre disposition.
Les tests ApacheBench ont été réalisés depuis un VPS ARM Hetzner [uptime.lrob.net] 2vCores situé à Nuremberg (Allemagne).
Nous avons vérifié que le VPS n’était pas saturé lors des tests.
Les tests ont été réalisés avec un nombre variable de connexions simultanées pour simuler différentes charges.
Certains hébergeurs (LWS, o2switch, et Ionos) ont semblé appliquer un rate limiting (limitation volontaire du nombre de requêtes depuis une IP unique), ce qui a pu influencer les résultats.
Uptime Kuma
Les mesures Uptime Kuma ont été réalisés depuis un VPS ARM Hetzner [uptime.lrob.net] 2vCores situé à Nuremberg (Allemagne), profitant ainsi d’une instance déjà opérationnelle. Ce serveur est parfois référencé comme « serveur de monitoring » dans l’article.
Les mesures Uptime Kuma ont été effectuées toutes les 60 secondes sur une période minimale de 24 heures dont Uptime Kuma fournit une moyenne.
Exception pour LWS : une mesure toutes les 60 secondes donnait un temps de réponse moyen de 2,9 s alors que le temps réel semblait être de 900 ms après un premier accès. Cette différence pourrait résulter d’une stratégie d’économie de ressources côté hébergeur. Nous avons donc utilisé un polling-rate de 20 secondes au lieu de 60.
Nous avons fourni une version pondérée des valeurs moyennes mesurées de 2x le ping entre [uptime.lrob.net] et les différents hébergements, afin d’éviter l’avantage géographique de certains serveurs par rapport au serveur de monitoring.
Les inaccessibilités sont également remontées avec les messages d’erreur retournés par Uptime Kuma. Celles-ci sont très variables au fil du temps et ne sont supposées non représentatives étant donné la courte période de mesure.
Configuration du cache
Pour les tests avec cache, nous avons configuré le plugin W3 Total Cache pour activer uniquement le cache de page :
Redis a été utilisé lorsque disponible.
Redis est une base de données en mémoire, offrant une vitesse de lecture rapide sans saturer le stockage disque.
LRob utilise Redis par défaut sur les sites de ses clients — nous avons donc choisi cette configuration comme référence.
Incompatibilité Redis :
Les offres OVH et Ionos ne semblaient pas supporter Redis dans notre configuration.
Nous avons donc utilisé le cache « Disk Basic » de W3 Total Cache à la place.
Cette différence peut avantager ou désavantager ces hébergeurs par rapport à ceux utilisant Redis. Il convient donc d’interpréter ces résultats avec prudence.
Biais techniques et facteurs externes
Le peering (interconnexion réseau) entre Hetzner et les différents hébergeurs peut impacter les résultats.
En particulier, LRob étant hébergé chez Hetzner, il pourrait bénéficier d’une latence plus faible lors des tests.
La latence réseau peut varier d’un ordre de 20 millisecondes entre certains hébergeurs et Hetzner, ce qui peut influencer les résultats.
Certaines micro-coupures réseau observées pourraient être attribuées à l’interconnexion entre Hetzner et les hébergeurs français.
Les dates et heures des tests ne sont pas particulièrement choisies. Elles correspondent simplement aux moments où nous étions disponibles pour réaliser ce test.
Considérations sur les domaines utilisés
Pour le test de Ionos, nous avons utilisé un sous-domaine en .live-website.com, fourni par Ionos.
Les autres tests ont été réalisés sur des sous-domaines en .bench.lrob.net pointant vers les adresses IPv4 et IPv6 des hébergements concernés.
Cette différence dans la configuration DNS pourrait entraîner de légères variations dans les temps de résolution DNS et par conséquent dans certains temps de réponse.
Tests GTMetrix
GTMetrix mesure la réactivité du serveur et le temps de chargement complet du site. Ce test tente de simuler l’expérience d’un visiteur unique visitant le site. L’objectif est d’obtenir les temps de réponse les plus bas possibles pour une meilleure expérience utilisateur.
Deux métriques principales sont analysées :
Fully Loaded Time – Temps total nécessaire pour que le navigateur charge l’ensemble des fichiers et ressources de la page.
TTFB (Time to First Byte) – Temps écoulé entre la requête initiale du navigateur et la réception du premier octet du serveur. Il est divisé en deux sous-mesures :
Connect time – Temps nécessaire pour établir la connexion au serveur, incluant le temps de ping et la négociation SSL/TLS (influencée par la force du chiffrement).
Backend time – Temps requis par le serveur pour générer la page demandée. Cette mesure reflète directement la performance du serveur.
Notes sur la fiabilité des mesures
Les résultats GTMetrix peuvent présenter une forte variabilité d’une mesure à l’autre, y-compris sur un même hébergement.
Le Backend time est toutefois relativement constant d’un test à l’autre, ce qui en fait une mesure plus fiable pour évaluer la performance du serveur.
Notes sur la compression des fichiers
Sur l’offre LWS cPanel L, le poids de la page était plus élevé (1,22 Mo contre 0,80 Mo). Après vérification, nous avons constaté que cet hébergement n’applique pas de compression des fichiers statiques, ce qui peut ralentir le chargement opéré par GTMetrix. Cela n’a cependant pas d’impact notable connu sur le TTFB mais peut impacter le « Fully Loaded » time.
Sur l’offre o2switch Cloud, le poids de la page était également légèrement plus élevé (0,84 Mo contre 0,80 Mo). Cette différence pourrait être liée à une méthode de compression différente. Nous n’avons pas examiné davantage ce point.
Tests GTMetrix sans cache
Les tests sans cache mesurent la performance brute du serveur dans le scénario le plus exigeant : la génération dynamique de la page à chaque requête, sans l’aide d’un cache du site.
Le principal indicateur de performance dans ce cas est le Backend time — il reflète directement la vitesse d’exécution du code PHP et les performances des requêtes MySQL.
Plus le site est complexe ou lourd (nombre de requêtes, taille des ressources), plus le Backend time sera élevé.
Plus un serveur est performant, plus le Backend time sera réduit.
Nous mesurons également le « Fully Loaded » time, soit le temps requis pour transférer tous les fichiers du site.
👉 L’objectif est d’obtenir les valeurs les plus faibles possibles pour garantir une réactivité maximale, même dans des conditions de charge dynamique.
Tableau récapitulatif de résultats GTMetrix – Tests réalisés le samedi 8 mars 2025 au matin – Sans cache – GTMetrix UK – Les scores les plus faibles sont préférables.
GTMetrix TTFB (Connect + Backend) – Sans Cache
Ce test mesure deux éléments distincts qui additionnés nous donnent le TTFB (Time To First Byte) :
Temps de connexion – Temps nécessaire pour établir la connexion entre le serveur GTMetrix à Londres et l’hébergeur, incluant probablement la négociation TLS (chiffrement sécurisé).
Backend time – Temps écoulé avant que le serveur commence à envoyer le contenu de la page.
Dans ce test sans cache, la puissance brute du serveur pour générer les pages HTML à partir de PHP et MySQL est plus déterminante que la latence réseau (Connect).
👉 Pour une performance optimale, l’objectif est d’obtenir la barre la plus basse possible.
TTFB (Connect + Backend) – Sans cache – GTMetrix UK – Le score le plus faible est préférable.
Les 5 premiers résultats se placent autour de 300ms sur ce test. Les résultats vont cependant du simple au triple (223 à 208 ms) sur le backend.
Le classement obtenu est le suivant :
LRob Ultra
o2switch Cloud.
LRob Super
LRob Starter
LRob Pro
HaiSoft Pro WP
Ionos Expand
HaiSoft Essentiel & OVH PERSO
LWS cPanel L
GTMetrix Fully Loaded time
Le graphique suivant indique le temps total mesuré par GTMetrix pour charger l’ensemble des fichiers du site. Il s’agit d’un indicateur clé, car il reflète directement la rapidité de chargement perçue par l’utilisateur final. Mais la marge d’erreur est élevée sur ce test, d’autant plus que nous avons priorisé le TTFB sur le « Fully Loaded » time pour ce test, ce qui signifie que les hébergeurs n’affichent pas forcément leur meilleur Fully Loaded time sur ce graphique.
👉 Pour une meilleure performance, l’objectif est d’obtenir la barre la plus basse possible.
« Fully Loaded Time » (chargement de tous les fichiers) – Sans cache – GTMetrix UK – Le score le plus faible est préférable.
Le classement obtenu est le suivant :
LRob Super & LRob Ultra
LRob Starter
HaiSoft Pro WP
o2switch Cloud.
HaiSoft Essentiel & Ionos Expand
LRob Pro
OVH Perso
LWS cPanel L
Tests GTMetrix avec Cache
Ce test mesure le temps de chargement optimal du site lorsque le cache est activé. Il reflète la capacité de l’hébergement à servir rapidement des pages pré-générées sans sollicitation excessive du backend (PHP/MySQL).
Le cache permet de stocker une version statique du site, réduisant ainsi la charge serveur et accélérant le temps de réponse.
Ce test met en évidence la qualité de l’optimisation du cache et la capacité de l’hébergement à gérer des requêtes rapides sous faible charge serveur.
👉 L’objectif est d’obtenir les valeurs les plus faibles possibles pour garantir une expérience utilisateur optimale.
Tableau récapitulatif de résultats GTMetrix – Tests réalisés le samedi 8 mars 2025 au matin – Avec cache – GTMetrix UK – Les scores les plus faibles sont préférables.
GTMetrix Connect + Backend – Avec Cache
Les résultats de ce test peuvent être influencés par plusieurs facteurs :
Une forte variabilité a été observée d’un test à l’autre, rendant cette mesure moins constante.
La latence réseau entre Londres et le serveur hébergeur devient significative en rapport au backend et peut donc entraîner des écarts d’autant plus significatifs.
Le type de cache utilisé diffère pour OVH et Ionos (cache fichier au lieu de Redis), ce qui altère les résultats.
Il convient donc d’interpréter ces résultats avec prudence, en tenant compte des différences de configuration entre hébergeurs.
Le graphique suivant reprend les deux éléments du tableau (connect et backend) qui additionnés nous donnent le TTFB, donc le temps de réponse total du serveur pour commencer à envoyer les fichiers.
👉 Pour une meilleure performance, l’objectif est d’obtenir la barre la plus basse possible.
TTFB (Connect + Backend) – Sans cache – GTMetrix UK – Le score le plus faible est préférable.
Le classement obtenu sur ce test est donc le suivant :
OVH PERSO (Cache Disk Basic)
HaiSoft Pro WP
HaiSoft Essentiel
LRob Starter & LRob Ultra
LRob Super
LRob Pro
o2switch Cloud.
LWS cPanel L
Ionos Expand (Cache Disk Basic)
De manière intéressante, les deux hébergements utilisant le cache Disk Basic occupent respectivement la première et la dernière place de ce test. Cela met en évidence le fait qu’une technologie de cache peut influencer de manière significative la performance d’un hébergement, à la hausse comme à la baisse.
👉 Nous recommandons d’expérimenter différents types de cache avec votre hébergeur afin de déterminer celui offrant les meilleurs résultats en fonction de votre configuration spécifique.
GTMetrix Fully Loaded – Avec cache
Le graphique suivant indique le temps total mesuré par GTMetrix pour charger l’ensemble des fichiers du site. Il s’agit d’un indicateur clé, car il reflète directement la rapidité de chargement perçue par l’utilisateur final.
La marge d’erreur est élevée sur ce test, d’autant plus que nous avons priorisé le TTFB sur le « Fully Loaded » time pour ce test et que le TTFB est sensiblement réduit par rapport au test sans cache, tandis que les marges d’erreur restent similaires.
👉 Pour une meilleure performance, l’objectif est d’obtenir la barre la plus basse possible.
« Fully Loaded Time » (chargement de tous les fichiers) – Avec cache – GTMetrix UK – Le score le plus faible est préférable.
Le classement obtenu est le suivant :
LRob Super
LRob Ultra
LRob Pro
LRob Starter
o2switch Cloud.
HaiSoft Pro WP
HaiSoft Essentiel
LWS cPanel L & OVH PERSO
Ionos Expand
Tests de charge avec ApacheBench
Ces tests évaluent la capacité maximale de chaque hébergement à gérer un volume élevé de requêtes simultanées à l’aide de l’outil ApacheBench (ab).
Explication des tests ApacheBench
Connexions simultanées et nombre de requêtes
ApacheBench permet de simuler plusieurs utilisateurs accédant simultanément au site.
Le nombre de connexions simultanées est défini par l’option -c :
Une connexion simultanée est notée « -c 1 » et correspond à un utilisateur simulé chargeant des pages en continu dès qu’une requête est terminée.
Deux connexions simultanées sont notées « -c 2« , et ainsi de suite.
👉 Le nombre total de pages chargées est défini par l’option -n :
-n 100 correspond à 100 pages chargées.
-n 1000 correspond à 1000 pages chargées.
Le test est fait sous la forme :
ab -l -c ${c} -n ${n} https://${url}/
L’argument « -l » nous permet de ne pas générer d’erreur lorsque le poids de la page varie d’une requête à l’autre. Et cela peut se produire pour de multiples raisons.
📈 Indicateur clé : requêtes par seconde
Le résultat clé fourni par ApacheBench est le nombre de requêtes par seconde que le serveur est capable de traiter. Ce chiffre sera mis en graphiques.
🚨 Vérification du rate limiting
Pour détecter un éventuel rate limiting (limitation volontaire des requêtes par l’hébergeur), nous avons réalisé un test complémentaire :
Pendant un test avec 40 connexions simultanées sans cache, nous avons surveillé le comportement du back-office pour vérifier la présence ou non d’éventuels ralentissements.
Cette observation reste subjective, mais permet de suggérer la présence d’un rate limiting si le test ApacheBench se voit ralenti mais qu’aucun ralentissement n’est visible à la visite du back-office.
La tableau des valeurs indique « Probable » dans le champ « Rate-Limiting » lorsque nous n’avons pas eu de lenteur à la visite du back-office durant le test.
👉 Le rate limiting n’est pas un défaut technique — il s’agit d’une mesure de protection visant à éviter une surcharge du serveur.
👉 Sur les tests sans cache, nous avons observé des signes potentiels de rate limiting à partir de 5 connexions simultanées sur les offres testées de Ionos, LWS et OVH. Les résultats avec 5 connexions simultanées ou plus sont donc potentiellement influencés par ces limitations.
👉 Sur les tests avec cache, les limites sont beaucoup moins claires et nous vous invitons à la plus grande parcimonie quand à l’interprétation des résultats.
Tests de charge ApacheBench – Sans cache
Ce test mesure la capacité du serveur à générer dynamiquement des pages sous forte charge, sans l’aide d’un cache.
Configuration du test
Nous avons simulé le chargement de 100 pages avec les configurations suivantes :
1, 2, 5, 10, 20 et 40 connexions simultanées
Le cache est désactivé afin de mesurer les performances brutes du serveur en termes de traitement PHP/MySQL.
Ce test permet de mettre en évidence les performances disponibles lorsque le serveur est soit peu sollicité, soit proche de la saturation.
Résultats agrégés – ApacheBench – Sans cache
Les valeurs brutes de ce benchmark sont rendues disponibles au téléchargement pour quiconque souhaite les ré-analyser.
Voici tout d’abord le graphique général suivi du tableau comportant ces valeurs.
👉 Pour une meilleure performance, l’objectif est d’obtenir les barres les plus hautes possible. Le but est de comparer chaque couleur entre elle. Nous détaillons ensuite les résultats obtenus pour chaque niveau de charge.
Tests de charge hébergeurs – Sans cache – ApacheBench – 100 pages, 1 à 40 connexions simultanées – Le score le plus élevé est préférable
Offer
-c 1 -n 100
-c 2 -n 100
-c 5 -n 100
– c 10 -n 100
-c 20 -n 100
-c 40 -n 100
Rate-Limiting
HaiSoft Essentiel
1.71
3.57
6.8
7.02
7.23
7.23
Haisoft Pro WP
2.12
4.07
9.82
13.58
13.69
13.37
Ionos Expand
2.35
4.47
4.95
4.9
4.9
ERROR
Probable
LRob Starter
4.25
8.15
9.51
9.53
9.54
9.52
LRob Pro
4.22
8.07
17.88
18.07
18
18.03
LRob Super
4.21
8.15
19.29
31.64
31.78
31.98
LRob Ultra
4.25
8.12
19.21
34.82
48.19
48.05
LWS cPanel L
1.1
2.23
1.75
1.07
0.95
1.15
Probable
OVH PERSO
1.84
3.666
5.98
5.86
5.83
5.72
Probable
o2switch Cloud
2.27
4.36
10.77
19.78
33.34
36.94
Probable
Tests de charge hébergeurs – Sans cache – ApacheBench – 100 pages, 1 à 40 connexions simultanées – Le score le plus élevé est préférable
Sur ce test, l’offre LRob Ultra obtient les meilleurs résultats dans toutes les configurations. Il est cependant important de rappeler qu’il s’agit de l’offre la plus coûteuse parmi celles testées.
1 connexion – ApacheBench – Sans cache
Sur une connexion unique, les serveurs offrant un TTFB inférieur (temps de réponse initial plus rapide) se distinguent par une vitesse de chargement plus élevée. Les quatre offres LRob occupent ainsi les premières places.
Tests de charge hébergeurs – Sans cache, 100 pages, 1 connexion simultanée – Le score le plus élevé est préférable
Les offres suivent dans l’ordre suivant :
LRob Starter, Pro, Super, Ultra – Entre 4,21 et 4,25 pages/seconde
Ionos Expand – 2,35 pages/seconde
o2switch Cloud – 2,27 pages/seconde
HaiSoft Pro WP – 2,12 pages/seconde
OVH PERSO – 1,84 pages/seconde
HaiSoft Essentiel – 1,71 pages/seconde
LWS cPanel L – 1,1 pages/seconde
👉 En connexion unique, LRob charge entre 1,8x et 3,86x plus de pages par seconde que les autres offres testées.
2 connexions – ApacheBench – Sans cache
Sur deux connexions simultanées, les performances sont environ doublées pour l’ensemble des hébergeurs, ce qui suggère qu’aucun rate-limiting n’est encore appliqué à ce stade.
Tests de charge hébergeurs – Sans cache, 100 pages, 2 connexions simultanées – Le score le plus élevé est préférable
👉 Les résultats observés sont les suivants :
Les offres LRob occupent la première place avec des performances comprises entre 8,07 et 8,15 pages/seconde.
Les offres de HaiSoft, Ionos, o2switch et OVH suivent avec des résultats compris entre 3,57 et 4,36 pages/seconde.
L’offre LWS cPanel L est légèrement en retrait avec 2,23 pages/seconde.
LRob conserve une avance similaire sur ce test avec une capacité avoisinant les 2x supérieures aux autres offres de ce test.
5 connexions – ApacheBench – Sans cache
À partir de 5 connexions simultanées, les écarts de performance entre les hébergements deviennent plus marqués. Les hébergements à 2 FPM ou appliquant du rate-limiting voient forcément leurs performances ou valeurs relevées en baisse.
Tests de charge hébergeurs – Sans cache, 100 pages, 5 connexions simultanées – Le score le plus élevé est préférable
👉 Les résultats observés sont les suivants :
Les offres LRob Pro, LRob Super et LRob Ultra conservent la tête avec des performances comprises entre 17,88 et 19,29 pages/seconde.
L’offre o2switch Cloud se classe quatrième avec 10,77 pages/seconde, suivie de près par HaiSoft Pro WP (9,82 pages/seconde) et LRob Starter (9,51 pages/seconde).
OVH PERSO atteint son maximum avec 5,98 pages/seconde, dépassant légèrement Ionos Expand, donnée pour 1vCPU qui plafonne à 4,95 pages/seconde.
L’offre LWS cPanel L régresse en tombant à 1,75 pages/seconde, indiquant le début du rate-limiting de notre serveur de test. Cette offre est annoncée avec 12 vCPU, ce qui suggère que cet hébergement pourrait offrir des performances supérieures dans un contexte différent. Nous supposons qu’un rate-limiting est en place, ne permettant pas à notre test de mesurer tout le potentiel de cet hébergement.
10 connexions – ApacheBench – Sans cache
Avec 10 connexions simultanées, les écarts se creusent encore :
Tests de charge hébergeurs – Sans cache, 100 pages, 10 connexions simultanées – Le score le plus élevé est préférable
👉 Les résultats observés sont les suivants :
LRob Ultra conserve la tête avec 34,82 pages/seconde, suivi de LRob Super avec 31,64 pages/seconde.
o2switch Cloud se positionne désormais en troisième place avec 19,78 pages/seconde, juste devant LRob Pro à 18,07 pages/seconde.
HaiSoft Pro WP suit avec 13,58 pages/seconde.
LRob Starter affiche une baisse de performance avec 9,53 pages/seconde, suivi de HaiSoft Essentiel à 7,02 pages/seconde.
Les hébergeurs atteignant leur limite ou appliquant un rate limiting apparaissent ensuite :
OVH PERSO
Ionos Expand
LWS cPanel L (rate limiting probable)
20 connexions – ApacheBench – Sans cache
Avec 20 connexions simultanées, les performances continuent de se démarquer.
Tests de charge hébergeurs – Sans cache, 100 pages, 20 connexions simultanées – Le score le plus élevé est préférable
👉 Les résultats observés sont les suivants :
LRob Ultra conserve la première place avec 48,19 pages/seconde.
o2switch Cloud progresse à la deuxième place avec 33,34 pages/seconde, dépassant LRob Super qui semble atteindre son plafond à 31,78 pages/seconde.
LRob Pro suit avec 18,00 pages/seconde.
Le reste du classement reste inchangé :
HaiSoft Pro WP avec 13,58 pages/seconde
LRob Starter avec 9.53 pages/seconde
HaiSoft Essentiel avec 7,02 pages/seconde
OVH PERSO avec 5,83 pages/seconde (rate limiting ou plafond de l’offre probables)
Ionos Expand avec 4,9 pages/seconde (rate limiting ou plafond de l’offre probables)
LWS cPanel L avec 0,95 pages/seconde (rate limiting probable)
40 connexions – ApacheBench – Sans cache
Avec 40 connexions simultanées, les offres capables d’exploiter une plus grande quantité de ressources se distinguent clairement.
Tests de charge hébergeurs – Sans cache, 100 pages, 40 connexions simultanées – Le score le plus élevé est préférable
👉 Les résultats observés sont les suivants :
LRob Ultra atteint son pic avec 48,19 pages/seconde servies sans cache.
o2switch Cloud suit avec 33,34 pages/seconde, devant LRob Super à 31,78 pages/seconde.
LRob Pro maintient une performance solide avec 18,00 pages/seconde.
HaiSoft Pro WP affiche 13,69 pages/seconde.
Le reste du classement reste stable avec :
LRob Starter
HaiSoft Essentiel
OVH PERSO (rate limiting ou plafond de l’offre probables)
Ionos Expand (rate limiting ou plafond de l’offre probables)
LWS cPanel L (rate limiting probable)
Ionos Expand (échec du test)
🚨 Rate limiting
L’offre LWS cPanel L semble appliquer un rate limiting à 1 page/seconde, limitant ainsi la capacité du serveur à gérer une charge élevée.
L’offre Ionos Expand a cessé de répondre au serveur de test, avec 79 % de réponses invalides (codes autres que 200).
Cette situation indique que le test a probablement dépassé la limite autorisée par l’hébergeur.
Par conséquent, la valeur invalide obtenue n’a pas été intégrée dans le graphique final.
Tests de charge ApacheBench – Avec cache – Des résultats imprévus
Le cache sur un site web permet de décupler ses performances. Les tests de charge avec cache visent à mesurer la capacité maximale des hébergements dans des conditions optimales.
Mais tout ne s’est pas passé comme prévu pour ce test.
Les résultats sont vraiment allés dans toutes les directions sur ce test, rendant toute analyse fortuite.
Nous noterons toutefois que le record obtenu est de 503 pages/s sur l’offre LRob Pro pour le premier de ces tests de charge. HaiSoft a atteint au maximum 176 pages/s et OVH 226 pages/s lors des meilleurs scores.
La conclusion est que l’on ne peut pas mesurer fiablement les performances en pic avec notre méthodologie en raison des rate-liming présents chez la plupart des hébergeur. Aussi, un cache semble indispensable pour les sites à fort trafic.
Nous rappelons que le type de cache diffère pour Ionos et OVH, pouvant influencer d’autant plus les résultats de ce test.
Voici cependant, pour transparence les résultats obtenus.
Test ApacheBench – Avec cache -c 1-200 -n 1000
Le test initial était prévu pour 1000 requêtes avec de 1 à 200 connexions simultanées. Problème : HaiSoft et LRob sont les deux seuls hébergeurs à accepter ce type de charge depuis l’IP unique de notre serveur de test. Pour tous les autres hébergements, cela a déclenché des requêtes en erreur (différentes de code de retour 200) chez Ionos, OVH et o2switch, avec un rate limiting fort chez Ionos, le blocage complet de notre serveur lançant le test sur l’offre o2switch, et un rate limiting à 1 requête/s sur l’offre LWS, rendant le test bien trop long, à tel point que nous l’avons stoppé.
Les valeurs brutes de ce benchmark sont rendues disponibles au téléchargement pour quiconque souhaite les ré-analyser.
Test ApacheBench – Avec cache -c 1-200 -n 1000 – Un score le plus élevé est préférable
Test ApacheBench – Avec cache -c 1-200 -n 1000 – Un score le plus élevé est préférable
Test ApacheBench – Avec cache -c 1-100 -n 100
Nous avons donc relancé le test avec 1 à 100 connexions simultanées pour 100 pages, ce qui a quand même déclenché le rate limiting. Nous avons cependant laissé ce test se terminer. Cette fois, seul notre hébergement Ionos a montré des erreurs « non 200 » à partir de 40 connexions, mais d’autres semblent clairement appliquer du rate-limiting.
Les valeurs brutes de ce benchmark sont rendues disponibles au téléchargement pour quiconque souhaite les ré-analyser.
Test ApacheBench – Avec cache -c 1-100 -n 100 – Un score plus élevé est préférable
Test ApacheBench – Avec cache -c 1-100 -n 100 – Un score plus élevé est préférable
Test ApacheBench – Avec cache -c 1-10 -n 10
Nous avons alors patienté un peu et sommes redescendus à un total de 10 requêtes de 1 à 10 connexions simultanées. Cela ne permet absolument pas de montrer le potentiel des hébergements et a quand même déclenché le rate-limiting de Ionos et LWS. o2switch semble indiquer de vraies valeurs sur ce test mais nous avons quand même un doute.
Les valeurs brutes de ce benchmark sont rendues disponibles au téléchargement pour quiconque souhaite les ré-analyser.
Test ApacheBench – Avec cache -c 1-10 -n 10 – Un score plus élevé est préférable
Test ApacheBench – Avec cache -c 1-10 -n 10 – Un score plus élevé est préférable
Mesures Uptime Kuma
Ces tests ont été réalisés sur les sites sans cache afin de mesurer le TTFB moyen (Time to First Byte) sur une période de 24 heures. Le TTFB correspond au temps écoulé entre l’envoi de la requête et le moment où le serveur commence à envoyer le contenu HTML de la page web. Cela permet notamment de vérifier la constance des performances serveur et la disponibilité de service.
Méthodologie de mesure
Les mesures sont effectuées toutes les 60 secondes, sauf pour LWS cPanel L (20 secondes), depuis notre serveur VPS ARM de monitoring situé chez Hetzner en Allemagne, via le logiciel Uptime Kuma.
Afin de limiter l’impact de la proximité géographique entre le serveur de test et les hébergeurs, nous avons appliqué une pondération en soustrayant 2 fois le ping moyen du serveur Uptime Kuma à la réponse moyenne.
Le ping a été mesuré manuellement depuis le serveur hébergeant notre instance Uptime Kuma, sur une moyenne de 10 occurrences à l’heure de la relève des mesures (le 10 Mars 2025 entre 12h20 et 12h25).
Cette correction vise à neutraliser l’avantage géographique potentiel.
En pratique, cela ne change pas le classement final qui est davantage impacté par d’autres facteurs.
Offer
Avg. Response 24h (ms)
Avg. Response 24h (ms) pondération 2x ping
Polling Rate (s)
Ping
Note
HaiSoft Essentiel
777
740.06
60
18.47
Haisoft Pro WP
786
749.06
60
18.47
Ionos Expand
480
461.54
60
9.23
LRob Starter
262
256.26
60
2.87
LRob Pro
261
255.26
60
2.87
LRob Super
260
254.26
60
2.87
LRob Ultra
262
256.26
60
2.87
LWS cPanel L
927
890.2
20
18.40
Polling réduit, sinon TTFB +3x supérieur
OVH PERSO
814
781.04
60
16.48
o2switch Cloud
431
397
60
17 (estimation)
Pas de réponse au ping, estimation
Relevés Uptime Kuma effectués le 10 Mars 2025 entre 12h20 et 12h25.
Réponse moyenne pondérée de 2x le ping – Uptime Kuma
Temps de réponse moyen sur 24h, pondéré – Un score plus faible est préférable
Le classement des réponses moyennes pondérées arrondies à 0.5ms obtenu est le suivant :
LRob Starter & LRob Pro & LRob Super & LRob Ultra – Avec 254 à 256ms
o2switch Cloud. – Avec 397ms
Ionos Expand – Avec 461ms
HaiSoft Essentiel & HaiSoft Pro – Avec 740 à 749ms
OVH Perso – Avec 781ms
LWS cPanel L – Avec 890ms
A noter que certaines perturbations serveur ou réseau ponctuels ont pu influencer ces résultats.
Voici ensuite le résultat obtenu pour chaque offre :
HaiSoft Essentiel & Pro WP
HaiSoft montre une réponse stable. Cela peut être aidé par la délégation des crons au serveur grâce à une case cochée sur l’hébergement. La moyenne baisse d’environ 140ms en raison d’un ralentissement ayant eu lieu la nuit causant le time-out de 20s à certains moments. Contactés à ce sujet, HaiSoft indique que cela provient d’une sauvegarde serveur quotidienne, que cela est déjà corrigé sur la majorité des serveurs et que le correctif arrive bientôt pour celui testé ici.
Erreurs rapportées par Uptime Kuma (sample) :
2025-03-10 00:12:35 timeout of 20000ms exceeded
Erreurs rapportées par Uptime Kuma (sample) :
2025-03-10 00:12:40 timeout of 20000ms exceeded
Ionos Expland
Ionos montre une réponse très stable sur ce test. On relève cependant deux pics à 18 et 8s de réponse, et deux requêtes en time-out.
Erreurs rapportées par Uptime Kuma (sample) :
2025-03-09 18:10:36 timeout of 20000ms exceeded
LRob Starter, Pro, Super, Ultra
Les offres LRob montrent une réponse stable. Cela est aidé par le serveur Uptime Kuma situé en Allemagne chez le même hébergeur que l’hébergement testé. Cela peut être également aidé par la délégation des crons au serveur grâce à une case cochée sur l’hébergement. Nous notons sur les 4 offres testées seulement 2 pics à 2.5 et 1.8 secondes et pas d’indisponibilité, avec globalement une fluctuation comprise sous les 100ms.
LWS cPanel L
La réponse de cette offre est stable mais avec de nombreux pics s’élevant jusqu’à près de 16 secondes. Cela ne nous semble pas attribuable uniquement à l’exécution périodique de WP-Cron et est couplé à de nombreuses requêtes indisponibles. Nous pensons que cela pourrait être dû à une saturation serveur ou à un problème réseau entre Hetzner et LWS. Aussi, ce test a dû être effectué avec un polling-rate de 20 secondes, offrant une granularité supérieure et évitant de monter à près de 3x le temps réponse. Nous avons inclus une capture plus large montrant le début du graphe avec un polling de 60s.
LWS cPanel L, polling rate 60s puis changement à polling rate 20s.
OVH PERSO
OVH montre ici des performances stables avec environ 200ms de fluctuation et aucune indisponibilité. Quelques pics sont à noter, entre 1 et 2s, qui pourraient être attribuées à l’exécution de WP-Cron.
O2switch Cloud
L’offre o2switch montre une excellente stabilité avec moins de 100ms de variations et un pic à moins de 750ms. On note toutefois deux micro indisponibilités retournant un certificat invalide. Par expérience, nous pensons que cela peut se produire lorsque le polling a lieu lors d’une mise à jour de configuration serveur, entre le moment où celle-ci est initiée et appliquée. Cela ne dure généralement que quelques secondes au maximum.
Erreurs rapportées par Uptime Kuma (sample) :
2025-03-10 04:02:18 Hostname/IP does not match certificate’s altnames: Host: o2switch-cloud.bench.lrob.net. is not in the cert’s altnames: DNS:jour.o2switch.net, DNS:mail.jour.o2switch.net, DNS:www.jour.o2switch.net
Conclusion
Pour ce test, nous avons tenté de nous mettre dans la peau d’un utilisateur cherchant à mesurer les performances de ses hébergements. Vous aurez certainement remarqué au gré des différents commentaires de cet article que la mesure des performances pose de nombreux défis techniques et ne peut pas être analysée et comprise sans une grande attention.
Des différences nettes sont apparues sur certains tests, mais il est globalement impossible de tirer des conclusions définitives en raison du nombre de biais et d’erreurs pouvant se glisser dans ces résultats.
Le choix d’un hébergeur n’est bien-sûr pas limité aux performances. D’autres critères peuvent entrer en jeu, comme la localisation géographique, l’espace disque, le support, les sauvegardes hébergeur, la popularité, ou encore vos habitudes – et la liste n’est pas complète -. Nous laissons ces critères à votre libre appréciation.
Sur le sujet des performances cependant, nous avons observé de beaux résultats chez les hébergeurs, en particulier en prenant en compte les prix contenus des différentes offres. Nous-nous réjouissons du large choix offert pour les clients hébergés. Et nous n’avons testé qu’une dizaine d’offres sur un très grand nombre existant.
Concernant nos hébergements LRob, nous-nous accordons notre propre auto-critique et estimons qu’ils ont été à la hauteur de leurs prétentions et ont pu montrer une belle puissance durant ces tests. Cela nous confirme que notre politique de choix et de gestion de serveurs permet bien des temps de réponse optimaux dans les tests que nous jugeons les plus importants. Et cela s’explique par nos choix stratégiques :
Des serveurs bare metal (dédiés) uniquement pour nos serveurs d’hébergement web mutualisés assurent qu’un maximum de ressources sont disponibles en tout temps. Ils sont tous équipés de disques SSD NVMe en RAID local.
Des choix de CPU (processeurs) optimaux pour le web : Le choix des CPU est pour nous l’une des clés de la performance. Par exemple, le serveur testé ici possède un AMD Ryzen 9 5950X (avec mémoire ECC), offrant selon nous l’un des meilleurs compromis actuels, entre performances single et multi-thread, consommation électrique, et coûts d’infrastructure. (Nous avons hâte de voir des serveurs basées sur des Ryzen 9 9950X !)
Des architectures logicielles et matérielle simples : MariaDB (MySQL), Redis, PHP et le serveur « front » sont tous sur la même machine, ce qui peut réduire les temps de latence par rapport à d’autres types d’architectures.
Un blocage efficace des attaques pour économiser jusqu’à 95% des ressources et éviter la saturation.
Des taux de remplissage faibles, pour éviter également la saturation.
Nous espérons en tout cas que ces tests, bien qu’imparfaits, vous auront donné des nouvelles pistes intéressantes pour effectuer vos propres tests et choisir votre hébergeur de manière éclairée.
N’hésitez pas à déposer un commentaire ou à nous contacter directement pour toute demande, remarque ou question relative à ce test.
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.
Sommaire
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.
La version majeure 31.0.0 de Nextcloud est sortie ce 25 février 2025. Si les notes de version officielles sont cette fois-ci très courtes, les améliorations sont ne sont pas en reste !
Chez LRob, nous proposons des instances Nextcloud managées avec mises à jour incluses, sauvegardées quotidiennement, avec stockage SSD NVMe pour des performances maximales et intégration de Collabora Online pour un travail collaboratif complet ! ➡️ Découvrez nos offres d’hébergement Nextcloud !
Et l’alternative open-source aux géants du cloud ne déçoit pas ! Comme tous les 5 à 6 mois, Nextcloud continue d’innover pour offrir une expérience toujours plus agréable, rapide, fiable et sécurisée à ses utilisateurs.
Pour résumer le changelog impressionnant des 1991 changements de cette mise à jour, nous avons passé tout cela à la moulinette de l’IA, pour que vous n’ayez pas à le faire… ! Voici ce qu’il faut retenir.
Sommaire
Des performances accrues et une meilleure gestion des bases de données
L’un des grands points forts de cette version est l’optimisation de la gestion des bases de données et des performances générales du système. Parmi les principales améliorations :
Optimisation de LDAP : La vérification des mots de passe LDAP a été revue pour réduire la charge CPU inutile ( server#35867).
Prise en charge des sockets UNIX pour occ db:convert-type : Une fonctionnalité très attendue pour faciliter les migrations de bases de données ( server#39242).
Corrections sur PostgreSQL : Amélioration de la gestion des permissions après la création d’une base de données ( server#38750).
Meilleure gestion du sharding : Transparence accrue sur la gestion des données réparties sur plusieurs serveurs ( server#46639).
LRob contribue à la résolution d’un bug
LRob est fier d’avoir contribué à la correction d’un bug critique affectant la commande occ db:convert-type, apparu avec l’ajout du support PrimaryReadReplicaConnection. Ce bug empêchait la conversion correcte des bases de données, un problème important pour les entreprises et administrateurs gérant des environnements Nextcloud divers et variés et ayant, comme LRob besoin de convertir des bases de données lors de migrations.
✅ Suite à l’intervention de LRob, le ticket a été relancé et la correction intégrée dans cette version. Voir le ticket GitHub #45257.
L’un de nos clients pourra ainsi passer de PostgreSQL à MariaDB en toute sécurité grâce à cette mise à jour.
Une amélioration de l’expérience utilisateur
Nextcloud 31 ne se contente pas d’améliorer les performances : cette version apporte aussi de nombreuses améliorations UX qui rendent l’utilisation plus intuitive et agréable.
1. Une interface modernisée
Migration progressive des pages vers Vue.js, pour un affichage plus fluide et réactif ( server#45652).
Correction des problèmes d’affichage des menus et du sélecteur de fichiers ( server#47203).
Alignement de l’interface avec le design Nextcloud 30 ( server#47248).
2. Une meilleure gestion du partage de fichiers
Possibilité de configurer la longueur des tokens de partage ( server#47265).
Amélioration des rappels pour les partages avec date d’expiration ( server#47412).
Une nouvelle commande pour mettre à jour les re-partages en cas de suppression d’un utilisateur ( server#43025).
3. Des optimisations pour les administrateurs
Ajout d’une commande occ user:welcome pour envoyer un email de bienvenue ( server#39611).
Prise en charge du stockage APCu sans échec si la configuration n’est pas disponible ( server#46151).
Options avancées pour la migration des fichiers chiffrés ( server#44555).
Une sécurité renforcée
Nextcloud 31 continue de renforcer la sécurité, un point crucial pour les entreprises et les utilisateurs soucieux de protéger leurs données.
WebAuthn : Ajout d’une vérification utilisateur pour les défis WebAuthn ( server#47253).
Gestion améliorée des tokens OAuth2 ( server#37761).
Vérifications et logs améliorés pour détecter les transactions SQL lentes et optimiser les performances ( server#47510).
Amélioration de la prise en charge des certificats SSL dans les environnements auto-hébergés ( server#48307).
Maintenez votre instance Nextcloud à jour en toute simplicité avec LRob
Nextcloud 31 apporte de nombreuses améliorations très utiles. Mais comme pour toute mise à jour, cela peut nécessiter des configurations et adaptations complexes. Chez LRob, nous prenons cela en charge pour vous ! Comme à chaque sortie majeure, nous prenons le temps de vérifier le bon fonctionnement de la version 31 avant de la déployer pour tous les clients dans les prochaines semaines. Sauf mention explicite, les mises à jour Nextcloud sont effectuées après 23h ou durant le week-end.
💡 Prêt à passer à Nextcloud 31 avec une instance sécurisée et optimisée ?Découvrez nos offres d’hébergement Nextcloud et bénéficiez d’un service fiable et performant avec un contrôle total sur vos données hébergées en Europe, et un support attentionné !
🔐 Pour renforcer la sécurité de vos accès Nextcloud, pensez à utiliser un gestionnaire de mots de passe open-source comme KeePass, que vous pouvez même héberger via Nextcloud.
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 !
A few cookies to keep the shop running 🍪
LRob respects your privacy. This site uses essential technical cookies (customer access, tickets, basket, payment). Stripe, our payment solution, may place additional security and marketing cookies.
YouTube forces its commercial cookies on videos integrated into the site.
Functional
Always active
Some cookies are required for the basic functions of this site.
Preferences
Technical access or storage is necessary for the legitimate purpose of storing preferences not requested by the subscriber or Internet user.
Statistics
Storage or technical access used exclusively for statistical purposes.Technical storage or access which is used exclusively for anonymous statistical purposes. In the absence of a subpoena, voluntary compliance by your internet service provider or additional records from a third party, information stored or retrieved for this sole purpose cannot generally be used to identify you.
Marketing
Technical access or storage is necessary to create user profiles in order to send advertisements, or to track the user on a website or on several websites with similar marketing purposes.
