Choisir entre Scaleway et OVHcloud pour héberger un cluster WordPress redondant destiné à un usage critique n’est pas qu’une question de tarif au gigaoctet. Les deux sont des fournisseurs cloud français, tous deux régulièrement cités dans les discussions autour de la souveraineté numérique, mais leurs offres divergent sur des points qui comptent précisément quand la tolérance à la panne devient une exigence contractuelle plutôt qu’un confort.
Cette comparaison ne traite pas de la configuration du répartiteur de charge devant le cluster, déjà largement documentée par ailleurs, mais du choix du fournisseur lui-même : ce que chacun propose en matière d’instances, de bases de données managées, de zones de disponibilité et d’accompagnement, dans le contexte précis d’un WordPress qui ne peut pas se permettre une interruption prolongée.
Zones de disponibilité et redondance réelle
Un cluster redondant n’a d’intérêt que si ses nœuds ne dépendent pas de la même infrastructure physique. OVHcloud structure historiquement son offre autour de plusieurs zones de disponibilité distinctes au sein d’une même région, permettant de répartir des instances sur des datacenters physiquement séparés tout en restant dans un même réseau privé à faible latence. Scaleway propose une logique comparable sur ses régions principales, avec une granularité qui varie selon la localisation choisie, certaines régions offrant une répartition en zones plus fine que d’autres.
Comparatif des offres pertinentes pour WordPress
| Critère | OVHcloud | Scaleway |
|---|---|---|
| Base de données managée MySQL | Disponible, avec réplicas en lecture | Disponible, avec réplicas en lecture |
| Object Storage compatible S3 | Oui, pour l’offload des médias | Oui, pour l’offload des médias |
| Load balancer managé | Oui | Oui |
| Historique et ancienneté de l’offre cloud public | Plus ancienne, écosystème plus large | Plus récente sur certains segments |
| Documentation technique WordPress spécifique | Générique, orientée infrastructure | Générique, orientée infrastructure |
Sur le papier, les deux couvrent les briques nécessaires à un cluster WordPress redondant : instances de calcul, base de données managée, stockage d’objets compatible S3 pour externaliser les médias, et répartiteur de charge. La différence ne se joue donc pas sur la présence de ces briques, mais sur des détails d’exécution.
La latence entre les nœuds, un critère sous-estimé
Pour un cluster WordPress avec réplication de session ou cache objet partagé entre plusieurs instances, la latence réseau entre les zones de disponibilité choisies compte davantage que la puissance brute de chaque instance. Un test simple avec ping et surtout avec un outil de mesure de latence applicative entre deux instances placées dans des zones distinctes permet d’objectiver ce paramètre avant de s’engager, plutôt que de se fier uniquement à la documentation commerciale.
mtr --report --report-cycles 100 10.0.1.5
Le support, souvent décisif en cas d’incident réel
Sur une infrastructure critique, la qualité du support technique en cas d’incident pèse autant que la fiche technique. Les deux fournisseurs proposent des niveaux de support différenciés selon le type de contrat souscrit, avec des délais d’intervention garantis qui varient fortement entre une offre d’entrée de gamme et une offre entreprise. Le choix du niveau de support doit être aligné sur l’exigence réelle de disponibilité du site, pas seulement sur son budget d’hébergement pur.
Ce qui a fait pencher la balance pour cette agence
Pour l’agence à l’origine de cette comparaison, chargée d’héberger un WordPress critique pour un client dont l’activité dépend directement de la disponibilité du site, le choix s’est porté sur OVHcloud, principalement pour deux raisons concrètes : une répartition en zones de disponibilité jugée plus lisible pour la région ciblée, et un historique d’incidents documenté publiquement qui a permis d’évaluer précisément la communication du fournisseur en situation de crise, un critère qu’aucune fiche technique ne renseigne.
Sur une infrastructure critique, la fiche technique départage rarement deux fournisseurs sérieux : c’est la façon dont chacun communique pendant un incident qui fait la différence.
Ce que ce choix n’implique pas
Choisir OVHcloud pour ce projet précis ne signifie pas que Scaleway serait un choix inadapté dans l’absolu. Pour une autre équipe, avec d’autres contraintes de région ou une préférence pour l’ergonomie de la console d’administration, la conclusion pourrait raisonnablement s’inverser. La méthode de comparaison, elle, reste transposable : mesurer la latence réelle entre zones, vérifier la granularité effective de la redondance proposée pour la région ciblée, et évaluer le support sur des incidents passés documentés plutôt que sur des promesses commerciales.
Notre verdict
Entre Scaleway et OVHcloud, aucun des deux ne constitue un choix par défaut évident pour un WordPress critique : les deux couvrent les briques techniques nécessaires à un cluster redondant. La décision doit se prendre région par région, sur la base de la latence mesurée entre zones de disponibilité et de la qualité de réponse du support en situation d’incident, deux critères que seule une évaluation concrète, pas une simple lecture de fiche produit, permet de trancher.
