Panne Closte : CDN perturbé et facturation inhabituelle, que se passe-t-il?
🚨 Sites cassés, mises à jour WordPress bloquées, puis factures inhabituelles : que s’est-il passé chez Closte ? Après 48 heures d’incident, j’ai migré les sites des clients qui avaient accepté mon devis et surveillé les autres. Je raconte les solutions que j’ai dû créer pour protéger leurs sites, et les questions qui restent sans réponse.

Pendant des années, j’ai longtemps apprécié Closte pour son hébergement WordPress, surtout leur système à la carte, paye ce que tu consommes, avec des prestas de haute qualité. Puis les signaux se sont accumulés : le domaine et le tableau de bord inaccessibles, des ressources distribuées par le CDN qui ne chargeaient plus correctement, des retours partiels suivis de nouvelles difficultés et, en septembre, des montants de facturation qui ont surpris plusieurs clients.
Pris séparément, chacun de ces problèmes appelle une explication. Mis bout à bout, ils changent la manière de gérer le risque.
Petit contexte, je gère des sites pour mes clients chez BL Digital, j’ai été donc victime collatérale de cette panne. Au bout de 48 heures d’incident, je n’ai pas attendu que la situation se résolve seule : j’ai transféré les sites des clients qui avaient validé mon devis de migration.
Pour les clients qui avaient refusé le transfert, j’ai gardé leurs sites à l’œil et surveillé l’évolution de l’incident. J’ai aussi dû résoudre des problèmes d’accès et de fonctionnement alors que les outils habituels de Closte ne répondaient plus. Certains de ces clients m’ont ensuite signalé des factures dépassant 200 €, indépendamment des deux captures en dollars que je partage plus bas. Cette surveillance fait aussi partie de la maintenance WordPress : repérer les erreurs, contrôler les sauvegardes et vérifier que les mises à jour restent possibles.
Je raconte ici ce que j’ai observé, ce que des utilisateurs ont publié et ce que je ne peux pas vérifier. Mon objectif est de comprendre l’enchaînement des événements et d’aider les propriétaires de sites à garder la maîtrise de leurs données. Les hypothèses sur l’origine de la panne ou de la facturation restent des hypothèses.
Juillet 2026 : le domaine Closte disparaît du DNS et l’accès se complique
À partir du 18 juillet, des clients signalent des difficultés d’accès à closte.com et au dashboard. Les vérifications publiées par LYVTech et Best Website relèvent des échecs de résolution DNS et un statut clientHold sur le domaine. Ce statut empêche sa publication dans le DNS ; il ne révèle pas, à lui seul, pourquoi la mesure a été appliquée.
Les conséquences n’étaient pas identiques pour tous les sites. Des domaines propres aux clients restaient parfois accessibles, tandis que le tableau de bord, des environnements de staging ou des ressources liées à Closte ne répondaient plus. La panne du domaine principal ne signifie donc pas automatiquement la perte des fichiers ou des bases de données, mais elle peut compliquer leur récupération.
Autre symptôme particulièrement visible : des utilisateurs rapportent que les images, les feuilles de style CSS ou les scripts ne chargeaient plus via le CDN. Dans certains cas décrits publiquement, le rendu est revenu après désactivation de cette distribution. Cela documente un problème sur ces configurations ; cela ne prouve pas que tout le CDN était indisponible partout ni que Google Cloud en était la cause.
À ce stade, ma question était simple : combien de temps pouvions-nous compter sur les accès encore disponibles pour sortir des copies fiables des sites ?
De mon côté, au bout de 48 heures d’incident, j’ai commencé les transferts pour les clients qui avaient accepté le devis. Je n’ai pas attendu la fin de la panne, pas de répons epublic de Closte, panique sur les reddit, action réaction on récupère e ton trransfert. Les sites dont les propriétaires avaient refusé la migration sont restés sous surveillance.
Fin juillet et août : un retour partiel, des accès instables et peu d’explications
Un retour temporaire de closte.com et du dashboard a été observé fin juillet, mais des problèmes de certificat étaient encore rapportés. Best Website a ensuite relevé de nouveaux échecs DNS le 19 août. De mon côté, je pouvais parfois accéder au tableau de bord, sans pouvoir considérer cet accès comme stable. Le site public, WordPress, le CDN et la console ne se comportaient pas toujours de la même façon.
Ce que j’ai dû faire pendant la panne : accès, DNS et mises à jour WordPress
Dès que le dashboard Closte était hors ligne, j’ai développé mon propre outil pour retrouver l’accès aux environnements de mes clients à partir des accès autorisés dont je disposais, sans dépendre du tableau de bord indisponible. Cela m’a permis de continuer à récupérer les données dont récent backup et les DNS entry et à travailler sur les sites pendant que l’interface habituelle ne fonctionnait pas.
Pour les sites dont les images, les feuilles de style ou les scripts dépendaient encore du CDN Closte, cette dépendance devait également être désactivée.
Le problème ne s’arrêtait pas à l’affichage. Closte empêchait alors la mise à jour de WordPress sur les sites concernés. Or, comme les problmèmes arrivent en rafale, une faille de sécurité importante exigeait une réaction, et je ne pouvais pas laisser mes clients exposés en attendant le déblocage de cette fonction. J’ai créé et appliqué, à mes frais, un correctif provisoire WordPress pour les protéger, le temps de pouvoir effectuer la mise à jour officielle. Ce travail supplémentaire a été rendu nécessaire par l’impossibilité de mettre WordPress à jour normalement.
Ces interventions n’étaient pas de simples vérifications de routine. Elles expliquent pourquoi j’ai jugé la situation trop risquée pour les clients qui avaient accepté de migrer, et pourquoi j’ai continué à surveiller attentivement les sites de ceux qui avaient choisi de rester.
Lorsqu’un accès se présente, récupérez les sauvegardes et exports par une méthode sûre. Une alerte de certificat ou de sécurité ne doit pas être ignorée aveuglément : faites vérifier l’authenticité de l’accès avant de saisir vos identifiants. Conservez aussi les fichiers et la base de données en dehors de Closte.
Aucun compte rendu public détaillé de Closte expliquant la cause et le calendrier de résolution de ces incidents, du jamais vu!
Septembre 2026 : après les pannes, la facturation soulève de nouvelles questions
Puis une autre anomalie est apparue, cette fois sur les coûts. Closte facture à l’usage : un montant peut varier avec le trafic et les ressources consommées. Mais quand plusieurs clients signalent des hausses soudaines après des semaines d’incidents, la question n’est plus seulement de comparer des reçus. Il faut expliquer d’où viennent ces consommations.
D’autres clients signalent des hausses au même moment
Dans le fil r/Wordpress consacré à Closte, plusieurs personnes décrivent des pics de trafic ou de consommation autour des 4, 5 et 6 septembre, y compris sur des sites peu visités. Un utilisateur dit avoir vu une tentative de débit de 300 $ pour les premiers jours de septembre alors qu’il payait habituellement 18 à 20 $ par mois. Un autre rapporte un débit de 400 € pour un site habituellement proche de 20 € par mois. Un troisième évoque une tentative de 1 400 $ pour les sept premiers jours du mois sur plusieurs sites à faible trafic.
Sur Trustpilot, un avis daté du 17 septembre indique environ 80 $ par mois auparavant, puis 691 $ en septembre. Ce sont des témoignages individuels et leur proximité dans le temps et la diversité des comptes concernés justifient néanmoins de demander à Closte une explication.

Historique Receipts réel d’un de mes clients: un paiement de 110 $ daté du 7 septembre 2026, après plusieurs paiements antérieurs de 30 $. Les périodes et consommations correspondantes restent à examiner.
Que faire ?
Conservez dès maintenant les captures, reçus, factures et données de consommation disponibles. Notez les dates des pics et demandez les métriques et journaux qui expliquent chaque ligne facturée. Ces preuves serviront à discuter d’un éventuel ajustement ; elles ne doivent pas retarder la fuite vers un autre hébergeur.
Google Cloud, le CDN et le silence de Closte : les questions ouvertes
Closte présente Google Cloud CDN, Google Cloud DNS et Google Premium Network comme des composants de sa plateforme. Il est naturel de se demander si les difficultés de distribution et les montants de septembre ont un lien. Les témoignages et mes captures ne permettent pourtant pas d’établir une relation de cause à effet entre ces deux phénomènes.
Un pic de bots, un processus gourmand, un problème de mesure, une consommation comptabilisée avec retard ou un incident touchant l’acheminement des ressources sont autant de pistes techniques à vérifier.
Ce qui manque, c’est une explication officielle accessible : non plus pourquoi tous ces problèmes mais y-a-t-il quelqu’un dans l’avion ? Je n’ai trouvé aucun compte rendu public détaillé répondant à ces questions. Devant le silence, il faut migrer.
Les étapes pour transférer votre site sans aggraver la panne
1. Inventorier les accès encore utilisables
Vérifiez si vous disposez encore de WordPress, d’un accès aux fichiers, d’un export de base de données sur le dashboard Closte ou d’une sauvegarde extérieure (Cloudsnap). Repérez aussi qui contrôle le domaine et les DNS. Un site public accessible ne garantit pas l’accès à tous les autres services, et l’inverse est également possible.
2. Récupérer une copie indépendante
La priorité est une sauvegarde stockée hors de la plateforme concernée via cloudsnap : base de données, fichiers du site et éléments de configuration nécessaires. Conservez également les enregistrements DNS.
Une sauvegarde disponible uniquement dans le tableau de bord inaccessible de l’hébergeur ne suffit pas à vous protéger. C’est tout l’intérêt d’un plan de reprise d’activité : prévoir comment remettre le site en ligne lorsque l’hébergement habituel devient inaccessible.

3. Restaurer et tester avant la bascule
Préparez le nouvel environnement, restaurez le site et contrôlez les pages, les images, les formulaires et, si nécessaire, les commandes et paiements. Ne changez les DNS qu’une fois les vérifications indispensables effectuées.
Évitez de supprimer trop tôt l’ancien environnement. Garder les éléments encore accessibles vous laisse une possibilité de récupérer ce qui aurait été oublié.
4. Supprimer les DNS et Cloudsnap
Il faut supprimer les DNS et la sauvegarde Cloudsnap, ces derniers sont payants et génèrerons à raison des frais sur votre prochaine facture Closte.
Si vou souhaitez ne pas continuer à payer les frais injustement générés, sachez qu’à l’heure actuelle ce n’est pas possible de détacher votre carte de crédit. Vous devez contacter votre banque et révoquer le mandat et les paiements Closte à venir.
5. Documenter les frais et contacter Closte
Conservez les reçus, factures, captures et dates d’incident. Ouvrez ensuite des tickets précis : quel compte, quel paiement, quelle période et quelle anomalie demandez-vous d’expliquer ? Gardez une copie des échanges.
Cette démarche reste utile même si la réponse tarde. Mais elle ne doit pas bloquer la mise en sécurité du site.
Pourquoi j’ai transféré mes clients vers IONOS
Pour les migrations réalisées après validation des devis par mes clients, j’ai choisi IONOS. C’était mon choix opérationnel dans cette urgence : il me fallait un environnement où restaurer et tester rapidement les sites. Ce retour d’expérience ne signifie pas que le même hébergement conviendrait automatiquement à tous les projets.
Quel que soit votre choix, préservez votre autonomie : un domaine que vous contrôlez, des sauvegardes indépendantes, des accès documentés et une procédure de sortie. Changer de prestataire sans corriger ces dépendances ne ferait que déplacer le problème.
Protéger son site d’abord, demander des comptes ensuite
Closte : quand les petits incidents deviennent une réaction en chaîne
En plongée sous-marine, un premier problème n’est jamais à prendre à la lègere: Le danger commence lorsqu’on le laisse entraîner le suivant, jusqu’à manquer de marge pour réagir. Avec Closte, j’ai vu cette mécanique à l’œuvre : un domaine inaccessible, un tableau de bord hors ligne, des sites cassés par leur dépendance au CDN, des mises à jour WordPress bloquées, puis des montants de facturation inattendus. Ce n’était plus une panne isolée ; c’était une réaction en chaîne.
Au début, certains patientes. On cherche à comprendre et on espère que l’hébergeur va rétablir le service. Mais il faut se donner une échéance. Un site qui s’affiche encore ne signifie pas qu’on en garde le contrôle : lorsque le dashboard devient inaccessible, l’administration de l’hébergement et la récupération des sauvegardes peuvent déjà être compromises. Pour moi, c’était une alerte majeure.
Je me suis donné 48 heures. Dès que mes clients ont validé le devis, j’ai transféré leurs sites. Ceux qui ont refusé la migration, je les ai gardés sous surveillance et j’ai déployé des solutions de secours. Mais surveiller un site ne remplace pas la maîtrise de son hébergement.
On peut se dire « le site est encore en ligne, tout va s’arranger » et repousser le transfert par fainéantise ou pour éviter la dépense. C’est un pari qui peut coûter cher, surtout chez un hébergeur facturé à l’usage : le jour où l’on doit agir, les accès peuvent manquer et des frais inattendus peuvent déjà s’être accumulés. N’attendez pas que votre site disparaisse pour fixer votre limite. Quand vous perdez les moyens d’intervenir normalement, il est temps de préparer la sortie.
Dans la même rubrique
- JetGEO, la nouveauté Crocoblock pour WordPress : contrôle des crawlers IA ou simple couche marketing ?
Thèmes communs : Numérique · Maintenance · WordPress
- Code Promo WordPress Plugins Black Friday 2022
Thèmes communs : Numérique · Maintenance · WordPress
- Comment Créer un Plan de Reprise d’Activité Après Sinistre Efficace – Disaster Recovery Plan
Thèmes communs : Cybersécurité · Maintenance · Plan de reprise d’activité
- Hack d’OpenAI avec Claude : ce que montre vraiment le récit de Hacktron
Thèmes communs : Cybersécurité · Numérique · Confidentialité



