DDoS
Une attaque DDoS (Distributed Denial of Service), ou attaque distribuée par déni de service, consiste à rendre un site web, une application, une API ou un service en ligne indisponible en le submergeant de trafic ou de requêtes.
Contrairement à une intrusion classique, l’objectif premier n’est donc pas nécessairement de pénétrer dans le système ou de voler des données. Il s’agit avant tout de saturer une ressource jusqu’à empêcher les utilisateurs légitimes d’y accéder.
Pour une entreprise dont le site web, l’e-commerce, les applications ou les services marketing reposent largement sur le cloud, le DDoS touche ainsi directement à l’un des fondamentaux de la cybersécurité : la disponibilité.
Que signifie DDoS ?
DDoS est l’acronyme de Distributed Denial of Service, littéralement « déni de service distribué ».
La nuance entre DoS et DDoS tient au mot Distributed. Dans une attaque DoS classique, l’attaque peut provenir d’une seule source. Une attaque DDoS mobilise au contraire un grand nombre de machines ou d’équipements connectés qui envoient simultanément du trafic vers la même cible.
Ces équipements peuvent notamment appartenir à un botnet, c’est-à-dire un réseau de machines compromises et contrôlées à distance. Ordinateurs, serveurs, routeurs, caméras IP et autres objets connectés peuvent ainsi participer à une attaque sans que leurs propriétaires en aient conscience.
Vu depuis le serveur attaqué, le phénomène ressemble à une soudaine et gigantesque affluence.
La comparaison avec un magasin fonctionne assez bien : si quelques milliers de personnes se présentent simultanément devant une boutique uniquement pour en bloquer les portes, les vrais clients ne peuvent plus entrer. Sur Internet, les portes sont remplacées par de la bande passante, des connexions réseau, des serveurs web, des ressources CPU ou des traitements applicatifs.
Comment fonctionne une attaque DDoS ?
Une infrastructure numérique possède toujours une capacité limitée. Elle peut accepter un certain débit réseau, maintenir un certain nombre de connexions et traiter un certain volume de requêtes simultanément.
L’attaquant cherche donc à épuiser une ou plusieurs de ces ressources.
Mais toutes les attaques DDoS ne fonctionnent pas de la même manière. Certaines cherchent à envoyer une quantité gigantesque de données. D’autres multiplient les connexions. Les plus applicatives peuvent au contraire envoyer un volume relativement modéré de requêtes soigneusement choisies parce qu’elles sont coûteuses à traiter.
C’est pourquoi une attaque DDoS ne se mesure pas uniquement en Gbit/s. Selon le type d’attaque, on surveillera également le nombre de paquets par seconde, de connexions ou de requêtes HTTP par seconde.
DDoS volumétrique, protocolaire et applicatif
On distingue généralement plusieurs grandes familles d’attaques.
- Les attaques volumétriques cherchent essentiellement à saturer la capacité réseau disponible. Le principe est simple : faire arriver davantage de trafic que l’infrastructure ne peut en absorber.
- Les attaques visant les protocoles et les ressources réseau, telles que certains SYN floods, cherchent plutôt à épuiser les capacités de traitement ou de gestion des connexions des serveurs, firewalls ou load balancers.
- Enfin, les attaques applicatives, souvent associées à la couche 7 du modèle OSI, ciblent directement le fonctionnement d’un site ou d’une application. Un HTTP flood peut, par exemple, multiplier les demandes de pages ou les appels à une API jusqu’à épuiser les ressources nécessaires à leur traitement. AWS distingue notamment les attaques d’infrastructure des couches 3 et 4 et les attaques applicatives de couche 7. (AWS Documentation)
Cette dernière catégorie est particulièrement importante pour les environnements MarTech : une requête apparemment normale peut être beaucoup plus coûteuse qu’elle n’en a l’air.
Une requête vers une image déjà présente dans un CDN coûte très peu. Une requête déclenchant PHP, plusieurs plugins, une recherche, une personnalisation et différentes requêtes SQL peut solliciter une chaîne entière de composants.
Pourquoi les attaques DDoS concernent-elles directement la MarTech ?
À première vue, le DDoS semble être une problématique réservée aux équipes réseau et cybersécurité. En réalité, la dépendance croissante du marketing aux infrastructures numériques en fait aussi un sujet MarTech.
Un site e-commerce indisponible signifie des ventes perdues. Une landing page inaccessible peut compromettre une campagne média. Une API indisponible peut interrompre des échanges entre plusieurs briques de la stack marketing. Un espace client inaccessible affecte directement l’expérience de marque.
Le problème devient encore plus sensible lors des pics de trafic légitimes : lancement de produit, campagne publicitaire, événement, opération promotionnelle, Black Friday, diffusion TV ou campagne d’influence.
Pour l’infrastructure, la frontière entre succès marketing et incident technique peut parfois être assez mince : dans les deux cas, beaucoup de monde arrive en même temps. Les outils de protection doivent donc être capables de distinguer autant que possible le trafic légitime du trafic hostile, plutôt que simplement limiter les visiteurs.
Les différentes couches de protection contre un DDoS
Il n’existe pas un unique « logiciel anti-DDoS ». Une protection robuste repose plutôt sur une défense en profondeur, avec plusieurs mécanismes placés entre Internet et l’application.
On peut simplifier cette architecture de la manière suivante :
ARCHITECTURE DE PROTECTION DDOS
Une défense en profondeur, couche après couche
Une protection efficace contre les attaques DDoS repose sur plusieurs couches complémentaires. L’objectif est de filtrer et absorber le trafic malveillant le plus tôt possible, avant qu’il n’atteigne l’application et ses ressources critiques.
01
Internet
Trafic légitime, bots, scans automatisés et flux d’attaque arrivent
depuis de multiples sources.
02
Protection réseau
Absorbe les attaques volumétriques et protège la bande passante
et les infrastructures réseau.
03
CDN / Edge
Distribue le trafic, sert les contenus en cache et réduit les
sollicitations du serveur d’origine.
04
WAF / Bot protection
Analyse les requêtes HTTP et bloque les comportements suspects,
les bots malveillants et certains abus.
05
Serveur / Reverse proxy
Applique le rate limiting, les règles d’accès et le contrôle
des connexions avant l’application.
06
Application / CMS
WordPress, e-commerce, API et logique applicative ne traitent
idéalement que le trafic restant.
07
Données & services
Bases de données, caches, services internes et intégrations constituent
les ressources les plus profondes à préserver.
Trafic entrant
Couches de filtrage et de protection
Ressources applicatives à préserver
Une attaque qui atteint l’application a donc traversé les protections précédentes. Cela ne signifie pas nécessairement qu’elles ont échoué : une couche peut avoir éliminé l’essentiel du trafic malveillant tandis qu’une autre traite ce qui reste.
La première protection se situe au niveau de l’opérateur réseau ou du fournisseur cloud. Elle est essentielle face aux attaques volumétriques. Si la connexion d’un serveur est saturée avant même que les paquets n’arrivent jusqu’à lui, installer un plugin de sécurité sur le site ne changera évidemment pas grand-chose.
Viennent ensuite les infrastructures CDN et Edge, capables de distribuer et d’absorber une grande partie du trafic en amont du serveur d’origine.
Des services de protection DDoS et des WAF (Web Application Firewall) peuvent ensuite analyser le trafic HTTP, appliquer des règles, détecter certains comportements anormaux, limiter le débit ou déclencher des challenges.
Plus près de l’application, les reverse proxies et serveurs web tels que Nginx peuvent également limiter le nombre de connexions ou de requêtes et protéger certaines ressources.
Enfin arrive la protection applicative : CMS, authentification, plugins de sécurité, limitation des appels API, contrôle des endpoints sensibles, etc.
Le principe général reste simple : plus une requête malveillante est arrêtée tôt, moins elle coûte à l’infrastructure.
CDN, WAF et anti-DDoS : quelle différence ?
Ces termes sont proches mais ne désignent pas exactement la même chose.
Un CDN (Content Delivery Network) distribue notamment les contenus sur un réseau de serveurs géographiquement répartis et réduit les sollicitations du serveur d’origine grâce au cache. Cette architecture apporte naturellement une capacité d’absorption importante.
Une solution anti-DDoS est spécifiquement conçue pour identifier et atténuer les attaques visant la disponibilité des services.
Le WAF, lui, travaille au niveau des requêtes web et applique des règles destinées à protéger l’application. Les fonctions peuvent cependant se chevaucher : les grandes plateformes cloud et Edge réunissent aujourd’hui plusieurs de ces mécanismes.
Cloudflare, par exemple, documente des protections DDoS aux couches 3, 4 et 7, tandis qu’AWS combine notamment Shield, CloudFront et AWS WAF selon les architectures et le niveau de protection recherché. (Cloudflare Docs).
DDoS et cloud : le paradoxe de l’élasticité
Le cloud a considérablement amélioré la capacité des infrastructures à absorber les variations de trafic. Load balancing, CDN, ressources distribuées et autoscaling permettent de faire face à des pics qui auraient autrefois suffi à mettre un serveur hors ligne.
Mais cette élasticité introduit un paradoxe : absorber une attaque ne signifie pas nécessairement qu’elle est sans conséquence.
Une infrastructure configurée pour augmenter automatiquement ses ressources peut continuer à fonctionner sous forte charge, tout en consommant davantage de ressources cloud. La résilience doit donc être pensée conjointement avec le filtrage, la limitation du trafic et le contrôle des coûts.
L’objectif n’est pas simplement de disposer d’un serveur « plus puissant » que l’attaquant. Pour les attaques d’infrastructure importantes, les architectures de mitigation reposent justement sur des réseaux capables de filtrer ou absorber le trafic en amont de la ressource ciblée. (AWS Documentation).
DDoS, bots et trafic légitime : une frontière de plus en plus complexe
La difficulté des attaques applicatives modernes tient moins à la quantité brute de trafic qu’à la capacité à distinguer un vrai utilisateur, un bon bot, un mauvais bot et un comportement automatisé cherchant à reproduire celui d’un humain.
Cette problématique dépasse d’ailleurs le DDoS. Les mêmes mécanismes de bot management peuvent servir à combattre le scraping massif, le credential stuffing, certains abus d’API ou l’automatisation frauduleuse.
Pour les responsables MarTech, cette évolution pose une question supplémentaire : il ne faut pas bloquer les machines que l’on souhaite justement accueillir.
Moteurs de recherche, outils de monitoring, partenaires, services marketing et désormais crawlers liés aux systèmes d’IA peuvent eux aussi générer du trafic automatisé. Une politique excessivement agressive peut donc améliorer la sécurité tout en dégradant le référencement, les intégrations ou la visibilité numérique.
La protection devient ainsi autant un exercice de gestion du trafic que de simple blocage.
Quels sont les impacts d’une attaque DDoS ?
Le premier effet est évidemment l’indisponibilité ou le ralentissement du service. Mais pour une entreprise numérique, les conséquences peuvent aller beaucoup plus loin.
Une interruption d’un site marchand entraîne potentiellement une perte immédiate de chiffre d’affaires. Une campagne payante peut continuer à envoyer des visiteurs vers une destination indisponible. Les équipes techniques et marketing sont mobilisées en urgence, le support reçoit davantage de sollicitations et l’image de marque peut être affectée.
La CISA souligne ainsi que les attaques DDoS peuvent entraîner des coûts en temps et en argent ainsi que des conséquences réputationnelles pendant l’indisponibilité des ressources et services. (CISA)
Le DDoS est donc moins un problème de « site qui rame » qu’un véritable risque de continuité numérique.
Comment réduire le risque DDoS ?
Il est impossible de garantir qu’un service accessible depuis Internet ne sera jamais ciblé. L’objectif consiste donc à réduire sa surface d’attaque, absorber les volumes importants, filtrer le trafic malveillant et préserver suffisamment de ressources pour les utilisateurs légitimes.
Une architecture moderne combine généralement une protection réseau opérée par l’hébergeur ou le fournisseur cloud, une infrastructure Edge/CDN, une protection DDoS, un WAF, du rate limiting et une application correctement dimensionnée et mise en cache.
Il est également important de protéger l’adresse IP du serveur d’origine lorsque celui-ci est placé derrière un proxy ou un CDN. Si l’origine reste directement accessible et que son adresse est connue, un attaquant peut tenter de contourner les protections placées en amont.
Enfin, les équipes doivent disposer de monitoring, de métriques et idéalement d’un plan de réaction. Une hausse brutale du trafic n’est pas automatiquement une attaque : pour une équipe marketing, cela peut aussi être la très bonne nouvelle que tout le monde attendait.
À retenir
Une attaque DDoS cherche à rendre une ressource numérique indisponible en épuisant sa capacité à accepter ou traiter du trafic légitime. Le caractère « distribué » vient de l’utilisation de multiples sources pour produire l’attaque.
Les attaques peuvent cibler différentes couches, depuis le réseau jusqu’à l’application. C’est pourquoi la réponse efficace ne consiste pas à installer un unique outil anti-DDoS, mais à construire plusieurs couches complémentaires de protection.
Pour les organisations très dépendantes du digital, du cloud et de la MarTech, cette résilience devient une composante de l’expérience client : un service numérique performant est utile, un service disponible l’est encore davantage.
Quelques références
- « Understanding and Responding to Distributed Denial-of-Service Attacks » — CISA, FBI & MS-ISAC — 2026
- « What is a DDoS attack? » — Cloudflare Learning Center — consulté en septembre 2026
- « How AWS Shield and Shield Advanced work » — Amazon Web Services — consulté en septembre 2026
- « AWS Best Practices for DDoS Resiliency » — AWS Documentation — consulté en septembre 2026
Lire ensuite
Synonymes :
Distributed Denial of Service
