Retour sur l’attaque malveillante qu’a subi le site e-commerce d’un client, d’un vendredi qui part en vrille et de ce que signifie réellement accompagner un client quand on est un professionnel du web.
Quand on parle de sécurité d’un site Internet, on pense généralement aux mots de passe, aux mises à jour, aux sauvegardes et aux extensions utilisées pour tenir les indésirables à distance. Tout cela est indispensable, mais au-delà, bien des gens estiment que ça ne les concerne pas. Et pourtant, ce n’est qu’une (toute petite) partie du sujet.
Un site e-commerce, par exemple, n’est pas qu’une vitrine avec un bouton « Ajouter au panier ». C’est d’abord un outil de travail, relié à des services externes, à des moyens de paiement, à une gestion commerciale et, surtout, à une entreprise qui doit faire bouillir la marmite. Alors quand il tombe en carafe, ce n’est pas une simple page web qui disparaît du paysage.
C’est précisément ce qu’a vécu l’un de nos clients en septembre 2026. Son site a été la cible d’une cyber-attaque démesurée, suffisamment violente pour le rendre inaccessible, mettre son hébergement en difficulté et perturber plusieurs services dont dépendait son activité. Au menu : diagnostics, arbitrages techniques et surprises indépendantes de notre volonté dont on se serait volontiers passé.
J’ai alors choisi de revenir sur cet incident pour montrer ce qui se joue réellement derrière une prestation web professionnelle. Parce que créer un site Internet, c’est une chose. Être capable de comprendre ce qui lui arrive, de protéger son activité et d’accompagner son propriétaire lorsque tout part en vrille, c’en est une autre.
Tout commence par une erreur 429
Tout commence donc un Vendredi, avec un problème qui a l’air presque banal : le site du client ne répond plus. Non pas que ce soit courant, mais ce genre de chose peut arriver et se résout assez rapidement. Dans le cas présent, les visiteurs ont droit à une belle erreur 429, autrement dit un message indiquant que le serveur reçoit trop de demandes de connexions. Pourtant, rien n’explique ce comportement, de prime abord. Je commence donc par les vérifications habituelles : état de WordPress, configuration de l’hébergement et, surtout, journaux de connexion. Ces premières vérifications permettent généralement de savoir si on a affaire à un site capricieux ou à un serveur mal réveillé.
Seulement, les chiffres ne tardent pas à raconter une autre histoire. Les premières observations font apparaître un bon millier de connexions par minute, provenant d’un grand nombre d’adresses IP étrangères. Je tente alors de mettre en œuvre plusieurs mesures somme toute classiques : restrictions dans les fichiers de configuration du site, blocages ciblés, règles de sécurité supplémentaires, j’en passe et des meilleures.
Aucun résultat notable. Le problème se joue plus haut : le serveur déclenche ses propres limitations pour éviter au site d’être submergé. Il se protège, certes, mais au prix d’un site devenu inutilisable pour les vrais clients. Formidable paradoxe.
À ce stade, je commence à comprendre que mon client ne fait pas face à une simple attaque. Il est littéralement confronté à un déluge de requêtes que les protections habituelles du site ne peuvent pas contenir. Et à ce stade, j’ignore encore que ce que nous voyons là n’est qu’une (vraiment) toute petite partie de l’attaque.
Les mesures habituelles ne suffisent plus
Face à cette situation, une décision s’impose : il faut empêcher les requêtes malveillantes d’atteindre directement le serveur. Pour cela, je décide de déployer Cloudflare, un service qui va servir d’intermédiaire entre les visiteurs et le site Internet. Son rôle est relativement simple à comprendre : plutôt que d’envoyer directement toutes les connexions vers le site Internet du client, celles-ci transitent d’abord par les infrastructures de Cloudflare, capables d’identifier et de filtrer une grande partie du trafic suspect. En sommes, on installe un poste de garde chargé du contrôle à l’entrée, plutôt que de laisser les indésirables défoncer la porte.
Il faut donc modifier les paramètres DNS, autrement dit les réglages qui orientent les connexions Internet, tout en préservant le fonctionnement des e-mails, des accès FTP et des autres services associés. J’en profite également pour configurer une connexion chiffrée entre Cloudflare et le serveur d’origine, afin de ne pas sacrifier la sécurité des échanges au profit de la disponibilité. Le tout pendant que l’attaque continue et que les modifications DNS se propagent progressivement sur Internet. Et à présent, on prend un café, et on attend que le remède fasse effet.
Une fois Cloudflare en place, on observe que le filtrage fait son travail, mais ce n’est pas encore suffisant pour rendre le site accessible. J’active alors temporairement un mode de sécurité avancé du service, afin d’appliquer une protection renforcée qui soumet les visiteurs à une vérification avant de les laisser accéder au site. C’est un dispositif contraignant (on y reviendra), mais il s’agissait de répondre à l’urgence : absorber l’attaque en amont et rendre la boutique accessible. Et là, le miracle opère : le site est de retour ! Mais ce serait trop beau si l’histoire s’arrêtait là.
PlanetHoster sort le nucléaire
Alors que je venais de rétablir l’accès au site, PlanetHoster, l’hébergeur du client, décide de suspendre purement et simplement son compte d’hébergement. Pas uniquement le site attaqué, non, non. L’intégralité du compte ! Résultat : les autres sites Internet qui y sont hébergés deviennent inaccessibles, tout comme l’intégralité des services de messagerie associés. Nous étions partis d’une boutique en ligne indisponible et voilà maintenant plusieurs outils de travail mis hors service. Ou pour le dire autrement, les gonzes de chez PlanetHoster ont sorti le nucléaire pour détruire un nid de frelons.
Illustration générée.
Alors entendons-nous : qu’un hébergeur mutualisé intervienne lorsqu’un compte génère une charge serveur anormale n’a rien d’anormal en soi. Seulement, la mesure employée ici a des conséquences importantes pour l’entreprise, alors qu’ils auraient pu se contenter de bloquer le nom de domaine. D’autant que nous sommes précisément en train de déployer une solution pour endiguer l’attaque ! Et bien entendu, suspendre l’hébergement ne règle absolument pas le problème : si les requêtes malveillantes continuent d’affluer, elles seront toujours là lorsque le serveur sera remis en service. Mais PlanetHoster ne l’entend pas de cette oreille, et considère que bloquer le compte du client était la seule solution.
Il faut donc mener plusieurs opérations de front : maintenir et surveiller la mise en place de Cloudflare, échanger avec le support technique de PlanetHoster pour obtenir la réactivation du compte, et tenir le client informé de l’évolution de la situation. Car c’est aussi ça, la réalité d’une intervention professionnelle. On ne maîtrise pas nécessairement les décisions des prestataires, mais il faut savoir composer avec elles, défendre les intérêts du client et garder le cap. Car pendant que tout ce petit monde discute technique, l’entreprise, elle, aimerait simplement pouvoir continuer à travailler.
70 millions de requêtes, puis bien plus… et le site reste debout
Dès que Cloudflare fut opérationnel, ses outils statistiques ont commencé à révéler l’ampleur réelle du phénomène. Et autant dire que les chiffres ont de quoi laisser songeur. En quelques heures, le site dépasse les 70 millions de requêtes enregistrées. Pour rappel, nous parlons d’une petite boutique en ligne, pas du site d’Amazon ! Une grande partie de ce trafic est désormais interceptée ou soumise à vérification avant d’atteindre le serveur. Résultat : le site redevient accessible jusqu’à ce que PlanetHoster bloque le compte du client, puis ne le réactive. L’attaque, elle, ne s’arrête pas pour autant. Après une première accalmie, une nouvelle vague déferle, encore plus importante que la précédente. Le compteur dépasse les 200 millions de requêtes. Puis les assauts se succèdent, entre périodes de calme et reprises parfois spectaculaires.
Au terme d’une période de cinq jours, Cloudflare comptabilisera plus de 550 millions de requêtes, sans compter les premières heures de l’attaque, lorsque le trafic atteignait encore directement l’hébergeur.
Extrait du rapport Cloudflare du site client.
Mais le plus intéressant n’est finalement pas ce chiffre astronomique. C’est le résultat. Là où le serveur rendait les armes face à une fraction de ce volume, la boutique reste à présent accessible malgré des vagues autrement plus violentes. Cloudflare n’a pas fait disparaître l’attaque, il a permis d’en absorber les conséquences. Et pour notre client, c’est bien là l’essentiel : son commerce peut de nouveau fonctionner. Le cordon de sécurité tient bon, et les manifestants ne peuvent plus brûler le lycée.
Remettre un site en ligne ne signifie pas que le travail est terminé
Après toutes ces péripéties, on pourrait alors croire que l’affaire est pliée. Sauf que non ! En retournant sur le site la première fois, j’ai découvert que certaines fonctionnalités ne répondaient plus. Après quelques investigations, je constate que certains fichiers sont corrompus. Toujours est-il qu’il faut remettre les mains dans le cambouis, restaurer les fichiers concernés à partir de mes sauvegardes et vérifier que la boutique fonctionne correctement. J’en profite également pour passer au crible les comptes utilisateurs, les extensions, les fichiers sensibles et les différentes configurations de sécurité. Car après une attaque de cette ampleur, se contenter d’un site qui s’affiche serait quand même un peu léger.
Mais l’histoire ne s’arrête pas encore. Le Mardi suivant l’attaque (qui était toujours en cours, mais contenue), le client me signale des difficultés de transmission des commandes. Parallèlement, je constate que certaines tâches automatisées de WooCommerce s’accumulent sans être exécutées. Le coupable? Notre fameuse surprotection additionnelle de Cloudflare ! Efficace contre les robots malveillants, elle a aussi bloqué des communications parfaitement légitimes entre les applications. Une fois le trafic revenu à la normale, je désactive donc cette protection renforcée et, comme par enchantement, tout fonctionne de nouveau comme avant. En bref, un site Internet accessible n’est pas nécessairement un site fonctionnel.
La technique n’est qu’une partie du travail
Vous l’aurez compris, cette intervention a nécessité une bonne dose de connaissances techniques et de persévérance. Mais il serait réducteur de penser que le travail d’un professionnel du web consiste uniquement à taper du code et à tripatouiller des configurations serveur. Pendant que je jonglais entre les journaux de connexion, Cloudflare, WordPress et les échanges avec PlanetHoster, mon client, lui, avait une préoccupation plus terre à terre : voir sa boutique tourner mieux qu’un boulanger en période d’émeutes. Et on peut difficilement lui en vouloir !
Un client n’a pas besoin de connaître les subtilités des DNS, le fonctionnement d’un pare-feu applicatif ou de suivre mes investigations à travers cinquante captures d’écran. Ce n’est pas son métier, c’est le nôtre. En revanche, il doit comprendre ce qui arrive à son site, savoir ce qu’on entreprend pour résoudre le problème et être informé des conséquences éventuelles sur son activité. Cela implique de communiquer, de vulgariser le sujet pour le rendre accessible, et de procéder aux arbitrages qui relèvent de notre expertise. Le tout, sans lui vendre des certitudes qu’on n’a pas. Ça évite de raconter des salades et, accessoirement, de passer pour un guignol quelques heures plus tard.
Illustration générée.
C’est précisément là que se joue une bonne partie de notre valeur ajoutée. Un client ne fait pas appel à un professionnel pour hériter de ses problèmes techniques ou pour servir de cobaye à des expérimentations. Il attend un expert capable de prendre du recul, de piloter la situation et de défendre ses intérêts. L’accompagnement n’est pas une option facturée en supplément de la compétence : il en fait pleinement partie.
Ce que vous devez retenir de cet incident
Que faut-il retenir de cette histoire ? D’abord, qu’il n’est pas nécessaire de diriger une multinationale pour subir une attaque informatique d’envergure. Une petite boutique en ligne peut parfaitement se retrouver sous un déluge de centaines de millions de requêtes. Et ce n’est pas parce qu’un site est correctement entretenu qu’il devient invulnérable. Les mises à jour, les sauvegardes et les protections de WordPress restent indispensables, mais elles ne remplacent pas un professionnel capable de gérer la situation quand la situation l’exige.
Cet incident rappelle également que les sauvegardes doivent impérativement exister ailleurs que sur le serveur concerné. Croire qu’une sauvegarde conservée exclusivement chez son hébergeur constitue une garantie suffisante, c’est un peu comme conserver le double de ses clés à l’intérieur de sa maison.
Enfin, une protection n’est jamais une fin en soi. La sécurité additionnelle nous a permis de traverser la crise, mais son maintien perturbait l’activité du site. Il a donc fallu savoir quand revenir à une configuration moins restrictive lorsque la situation le permettait. Sécuriser un site ne consiste pas à le barricader au point d’empêcher ses propres clients d’entrer. Tout est affaire de discernement, de proportion et, surtout, de connaissance du fonctionnement réel de l’entreprise.
Qu’est-ce qui distingue réellement un professionnel du web ?
À une époque où n’importe qui peut prétendument assembler un WordPress en quelques clics ou demander à une intelligence artificielle de lui fabriquer un site Internet, on pourrait finir par se demander à quoi bon faire appel à un professionnel. Après tout, tant que les pages s’affichent et que les boutons fonctionnent, le résultat peut sembler convaincant. Du moins pour un œil non averti. La différence se joue déjà dans le design, la pertinence du message, l’ergonomie et la qualité de la conception. Mais elle devient autrement plus évidente lorsque quelque chose commence à sérieusement partir en sucette.
Attention, je ne prétends pas qu’un site réalisé par un professionnel ne rencontrera jamais de problème. Ce serait aussi crédible qu’un garagiste promettant que votre voiture ne tombera jamais en panne. En revanche, un professionnel doit être capable de comprendre ce qui se passe, d’identifier ses limites, de prendre les bonnes décisions et de mobiliser les bons interlocuteurs. Surtout, il doit savoir accompagner son client jusqu’à la résolution du problème, sans lui refiler la patate chaude à la première difficulté.
Cela ne signifie pas non plus qu’on puisse bricoler tranquillement son site pendant des années avant d’appeler un professionnel comme on appelle une ambulance. Reprendre en urgence un système mal conçu, jamais entretenu et dont personne ne maîtrise le fonctionnement est généralement plus coûteux que de repartir sur des bases solides.
Faire appel à un professionnel du web, ce n’est donc pas simplement acheter un site Internet. C’est s’entourer d’une expertise, d’une méthode et d’un interlocuteur responsable. Parce que derrière quelques pages affichées dans un navigateur, il y a un business qui compte dessus pour faire bouillir la marmite. Et ça, ça mérite mieux qu’un site bricolé avec deux prompts.
