6 octobre 2026
·
17 min de lecture
Filtrage local : RTBH après env. 1 s, filtrage après 6–10 s, coût fixe ; le cloud absorbe les attaques plus grosses que l’uplink. Délais et coûts comparés.
Réponse courte : le filtrage dans votre propre réseau détecte et rejette le trafic d’attaque sur vos propres routeurs (RTBH après environ 1 s, filtrage sélectif après 6–10 s), à coût fixe et sans faire sortir le trafic du réseau. La protection DDoS cloud repose sur un scrubbing center : une installation d’un prestataire externe vers laquelle vous redirigez le trafic pour qu’il soit nettoyé puis renvoyé. Elle l’emporte si, et seulement si, l’attaque dépasse la capacité de votre uplink. Pour la plupart des opérateurs, la réponse honnête n’est pas « l’un ou l’autre », mais « l’un en première ligne, l’autre en escalade ».
Deux modèles, deux emplacements différents dans le réseau
Les deux approches résolvent le même problème, mais à un point différent de la topologie, et cette seule distinction explique pratiquement toutes les différences présentées ci-dessous.
Le filtrage dans votre propre réseau signifie que la détection et la riposte ont lieu sur une infrastructure que vous exploitez vous-même : le capteur observe le trafic qui transite de toute façon par chez vous, et la règle de filtrage s’applique sur votre routeur de bordure ou sur un serveur de filtrage. Le trafic ne change pas de chemin.
Le scrubbing center est un centre de données distant doté d’une très grande capacité de backbone. Au moment de l’attaque, vous annoncez vos préfixes via BGP (ou redirigez le trafic par DNS) ; le trafic y est acheminé, nettoyé, puis vous revient par un tunnel ou un lien dédié.
Le choix se résume à quatre leviers : le temps de réaction, le modèle de coût, la maîtrise du chemin du trafic et la capacité d’absorption. Aucune des options ne l’emporte sur les quatre.
Le contexte est par ailleurs de moins en moins confortable. Cloudflare indique qu’en 2025 le nombre d’attaques DDoS a augmenté de 121 % sur un an et que 5 376 attaques par heure ont été filtrées en moyenne ; les télécommunications, les fournisseurs de services et les opérateurs ont été le secteur le plus attaqué par les attaques de très gros volume (Cloudflare, Q4 2025 DDoS Threat Report, février 2026). NETSCOUT a recensé au second semestre 2025 plus de 8 millions d’attaques dans 203 pays, dont environ 42 % combinaient deux à cinq vecteurs simultanément (NETSCOUT DDoS Threat Intelligence Report, édition 16, mars 2026).
Comparatif : filtrage local ou protection DDoS cloud par scrubbing
Le tableau ci-dessous rassemble les critères qui déterminent réellement le choix chez un FAI, un hébergeur ou une entreprise qui gère son propre trafic.
| Critère | Dans votre réseau (p. ex. WanGuard) | Scrubbing center dans le cloud |
|---|---|---|
| Délai de détection | RTBH après environ 1 s, filtrage sélectif après 6–10 s avec port mirroring / DPDK | De quelques dizaines de secondes à plusieurs minutes (redirection + convergence BGP) |
| Lieu du filtrage | Vos routeurs de bordure | Centre de données du prestataire externe |
| Modèle de coût | Déploiement unique + licence + support | Facturation au Gbit/s ou au trafic nettoyé : augmente avec la taille de l’attaque |
| Chemin du trafic | Le trafic ne quitte pas votre réseau | Le trafic transite par un tiers |
| Souveraineté des données | Totale, dans le réseau (NIS2, réglementation des télécoms) | Le trafic et les métadonnées sortent du périmètre de votre infrastructure |
| Latence en régime établi | Aucune latence supplémentaire | Ajoutée en mode always-on ; nulle en mode on-demand |
| Plafond volumétrique | Capacité de vos uplinks | Échelle du térabit, backbone du prestataire |
| Contrôle et réglage | Vos seuils, exceptions et politiques | Logique du prestataire, plateforme mutualisée |
Le tableau est volontairement impitoyable dans les deux sens. Il n’y a aucune ligne où une colonne l’emporte « globalement » : il y a des lignes où l’une gagne, et des lignes où c’est l’autre.
En quoi consiste le filtrage d’une attaque dans votre propre réseau ?
Il s’agit d’un logiciel (plus rarement d’un matériel dédié) qui détecte et rejette le trafic d’attaque à l’intérieur de votre réseau, sur les serveurs et routeurs que vous administrez. Une plateforme comme WanGuard profile le trafic de production, apprend une ligne de base de la « normalité » par sous-réseau, par adresse et par décodeur, et, dès qu’un écart apparaît, lève une anomalie et recourt au mécanisme de filtrage disponible. Rien n’est redirigé nulle part.
La riposte s’effectue dans le plan de transfert existant :
- BGP FlowSpec : une règle chirurgicale sur le 5-tuple, exécutée sur le routeur au débit de la ligne. Nous l’avons décrit en détail dans l’article sur le filtrage des attaques par règles BGP FlowSpec.
- RTBH : le blackholing en dernier recours, lorsque l’attaque ne peut plus être isolée finement. Dans quels cas cela a du sens et dans quels cas cela revient à capituler, nous l’analysons dans l’article sur le RTBH.
- Serveur de filtrage DPDK, en ligne (inline) ou en dérivation, à 10/40/100 GE.
Comme la détection et la riposte résident toutes deux sur votre bordure, le temps de réponse se mesure en secondes, et non au temps nécessaire pour remanier l’acheminement du trafic sur Internet. C’est le modèle qu’ITORO déploie et maintient en tant que service anti-DDoS basé sur WanGuard.
Une réserve honnête : ce modèle exige que quelqu’un, chez vous, comprenne le réseau. Il faut régler les seuils, décrire les exceptions, et la redirection du trafic vers un serveur de filtrage peut s’avérer délicate sur le plan architectural dans un réseau à routeur unique. Ce n’est pas un boîtier que l’on allume avant de l’oublier.
Qu’est-ce qu’un scrubbing center et qu’apporte-t-il réellement ?
Un scrubbing center est une installation d’un prestataire externe, dotée d’une grande capacité de backbone, qui filtre (« nettoie ») votre trafic en dehors de votre réseau. Lorsqu’une attaque commence, le trafic y est redirigé, le plus souvent par l’annonce des préfixes en BGP, plus rarement par une redirection DNS. Le centre rejette le trafic d’attaque et renvoie un flux propre par un tunnel ou un lien dédié.
Le scrubbing center existe avant tout pour une raison : la capacité. Un prestataire disposant d’un backbone de plusieurs térabits absorbera un flood qui saturerait en quelques secondes l’uplink d’un opérateur isolé. C’est un avantage réel et important, et il n’y a aucune raison de le relativiser.
Le prix de cet avantage est architectural, et pas seulement financier :
- Le trafic transite par une infrastructure que vous ne contrôlez pas.
- Le filtrage attend la redirection et la convergence BGP.
- Le modèle commercial facture généralement au Gbit/s de trafic nettoyé : la facture augmente donc avec la taille de l’attaque contre laquelle vous vous défendez.
- Les politiques sont définies par le prestataire et partagées avec d’autres clients. Votre trafic atypique (p. ex. UDP de production, gaming, VoIP) est parfois rejeté à tort, et le réglage passe par un ticket, non par votre console.
Combien de temps perdez-vous à rediriger le trafic ?
Le délai de détection est un facteur que les opérateurs sous-estiment et que les attaquants exploitent.
La détection par port mirroring analyse une copie de chaque paquet au débit de la ligne (DPDK, PF_RING) ; elle reconnaît donc un flood volumétrique et déclenche le RTBH après environ 1 s, puis le filtrage sélectif après 6–10 s. La détection par NetFlow / sFlow / IPFIX est plus simple à déployer, mais vous la payez par le délai d’export des flux depuis le routeur : en pratique, 35–95 s.
Le scrubbing center ne peut rien faire tant que le trafic ne lui parvient pas. Annonce du préfixe, propagation, convergence BGP, établissement du chemin de retour : cela représente des dizaines de secondes, parfois des minutes, selon la conception du réseau et selon que le tunnel de retour est établi en permanence ou non.
Cet écart décide de l’issue. Lorsqu’un flood record culmine à 31,4 Tbit/s et dure 35 secondes (Cloudflare, février 2026), un chemin de défense qui a besoin d’une demi-minute pour se mettre en place peut manquer l’attaque entièrement, ou entrer en action précisément au moment où elle se termine. Le filtrage local est déjà sur le chemin du trafic : il n’y a pas d’étape « rediriger » à attendre.
Il existe deux variantes intermédiaires, et chacune a son prix :
- Le scrubbing always-on supprime le délai de redirection, mais ajoute une latence permanente à l’ensemble du trafic et un coût fixe, puisque tout le trafic est inspecté en permanence.
- Le scrubbing on-demand n’ajoute pas de latence en régime établi, mais réintroduit le délai de redirection précisément au pire moment.
Le filtrage dans votre propre réseau évite ces deux problèmes, mais uniquement pour une attaque qui tient dans votre uplink. C’est le cœur de toute la comparaison.
Coût : licence fixe ou facture au Gbit/s
Les structures de coûts diffèrent fondamentalement, et l’écart se creuse précisément aux moments où la protection est nécessaire.
Le modèle local correspond à un déploiement unique, auquel s’ajoutent la licence et le niveau de support. Le coût est fixe quelle que soit la taille de l’attaque, car vous disposez déjà de la capacité de filtrage. La budgétisation est prévisible : une attaque plus grosse ne signifie pas une facture plus élevée. S’y ajoute un effet secondaire dont on parle rarement : le capteur assure la rétention et des rapports détaillés sur le trafic, ce qui vous fournit au passage des données pour planifier vos achats de transit.
Le scrubbing est généralement facturé au Gbit/s de trafic nettoyé ou selon un seuil de capacité en burst. Le modèle est flexible, ce qui semble attrayant, mais signifie en pratique que le coût évolue avec la taille de l’attaque. Une campagne de plusieurs jours ou une série d’attaques répétées, comme nous en observons justement lors de tentatives d’extorsion avec demande de rançon, transforme une ligne budgétaire prévisible en variable qui culmine précisément quand vous êtes sous la plus forte pression.
Il faut toutefois présenter l’autre versant : le modèle local exige un investissement initial, avant que quoi que ce soit ne se produise, ainsi que des compétences pour l’exploiter. Pour une organisation qui n’a pas d’équipe réseau et ne souhaite pas en avoir, un abonnement auprès d’un prestataire peut être une décision rationnelle, même s’il revient plus cher sur un horizon de quelques années.
Nous n’indiquons pas de montants dans un article de blog, car la grille tarifaire évolue de son côté. Les tarifs actuels et le calculateur se trouvent sur la page Tarifs.
Pourquoi le chemin du trafic a-t-il une portée réglementaire ?
L’endroit où le trafic est nettoyé n’est pas seulement une question de performance. C’est aussi une question de conformité et de confiance.
Le filtrage local garde chaque paquet et ses métadonnées à l’intérieur de votre réseau. Pour les FAI, les opérateurs télécoms et les entités réglementées, cela compte : faire passer le trafic des clients par un scrubbing center signifie que les données des abonnés et les profils de trafic transitent par une infrastructure que vous ne contrôlez pas. Avec NIS2, sa transposition nationale et les réglementations sectorielles, cela soulève des questions auxquelles il faut pouvoir répondre dans la documentation, et non en réunion avec l’auditeur.
Il en va de même pour le contrôle. En local, vous disposez de vos propres seuils, exceptions et politiques, y compris pour ce trafic atypique et peu orthodoxe qui, chez un prestataire, tomberait sous une règle générale. Une plateforme cloud mutualisée applique à de nombreux clients à la fois une logique définie par le prestataire. C’est efficace, mais moins précis pour votre réseau en particulier.
D’après nos observations, les opérateurs qui posent le plus de questions sur le chemin du trafic sont ceux qui ont la plus forte exposition réglementaire. Pour eux, le filtrage dans le réseau n’est pas une préférence, mais une exigence.
Quand le scrubbing dans le cloud l’emporte-t-il vraiment ?
Il possède un avantage décisif : il absorbe les attaques plus grosses que votre uplink. C’est la limite honnête de toute solution locale, et aucun réglage ne permet de la contourner.
Vous ne pouvez pas filtrer plus de trafic que ce que vos liens transportent physiquement. Un flood qui sature le lien en amont de vos routeurs l’engorgera avant que votre filtre ne voie la moindre capacité libre. On ne triche pas avec la physique, et tout prestataire qui prétend le contraire vend autre chose que de l’ingénierie.
Le scrubbing (ou l’escalade auprès de l’opérateur de transit) est la bonne décision lorsque :
- le flood atteint l’échelle du térabit ou dépasse simplement la bande passante souscrite,
- l’attaque est multivectorielle et prolongée, et vous n’avez pas d’équipe pour la gérer 24/7,
- vous exploitez un service dont le profil attire régulièrement de gros volumes (gaming, DNS publics, grands sites médias).
Un prestataire crédible vous le dit avant la signature du contrat, et non pendant l’incident.
Il existe une troisième variante, que de nombreux opérateurs négligent : le filtrage chez l’opérateur de transit par règles BGP FlowSpec. Certains opérateurs de transit européens acceptent les règles FlowSpec de leurs clients et les appliquent sur leur propre bordure. La limite haute de ce que vous pouvez rejeter n’est alors plus fixée par votre uplink, sans redirection du trafic et sans facturation au Gbit/s.
Verdict : première ligne dans le réseau, escalade en amont
Pour la plupart des opérateurs, aucun des deux modèles ne l’emporte seul, et l’architecture la plus solide combine les deux.
Premier niveau : votre réseau. Détection et filtrage sur place (RTBH après environ 1 s, filtrage sélectif après 6–10 s), trafic qui ne sort pas, coût fixe. Il traite l’écrasante majorité des attaques, car la répartition des attaques par volume est fortement asymétrique : les petites et moyennes attaques, qui tiennent dans l’uplink, dominent.
Deuxième niveau : l’escalade. Blackholing chez l’opérateur, règle FlowSpec poussée en amont ou scrubbing center. Ce niveau est activé lorsque le volume dépasse ce que les liens peuvent transporter.
C’est l’automatisation qui fait fonctionner l’ensemble. WanGuard filtre d’abord finement par règle BGP FlowSpec, passe au RTBH lorsque les uplinks approchent de la saturation et signale le besoin d’escalade lorsque le volume dépasse la capacité du lien. Vous obtenez une riposte locale dans le cas typique (avec le port mirroring, RTBH après environ 1 s et filtrage sélectif après 6–10 s) et une protection à l’échelle du térabit dans le cas rare.
Ce que ce modèle n’offre pas : la garantie que chaque attaque sera filtrée sans laisser de trace. Personne ne l’offre. Il apporte en revanche deux choses : dans la plupart des incidents, le service reste disponible ; dans les cas rares et les plus massifs, vous suivez un chemin planifié au lieu d’improviser à trois heures du matin.
ITORO, Gold Partner d’Andrisoft, conçoit, déploie et maintient précisément ce type d’architecture pour les FAI, les hébergeurs et les entreprises. Les détails de l’architecture sont décrits sur la page consacrée à WanGuard.
Questions fréquentes
Que vaut-il mieux : le filtrage dans votre réseau ou le scrubbing dans le cloud ?
Cela dépend de la taille de l’attaque. Le filtrage local est plus rapide (avec le port mirroring, RTBH après environ 1 s et filtrage sélectif après 6–10 s), a un coût fixe et ne fait pas sortir le trafic du réseau ; il l’emporte donc pour tout ce qui tient dans l’uplink. Le scrubbing ne l’emporte que pour les floods qui dépassent la bande passante des liens. La plupart des opérateurs font fonctionner les deux dispositifs en parallèle.
Qu’est-ce qu’un scrubbing center ?
C’est une installation d’un prestataire externe, dotée d’une grande capacité de backbone, qui filtre votre trafic en dehors de votre réseau. Au moment de l’attaque, le trafic y est redirigé via BGP ou DNS, nettoyé puis renvoyé. Sa force : absorber des floods à l’échelle du térabit ; son prix : le délai de redirection, la facturation au Gbit/s et un trafic qui transite par un tiers.
De combien le filtrage dans mon réseau est-il plus rapide ?
La détection par port mirroring permet de déclencher le RTBH après environ 1 s et le filtrage sélectif après 6–10 s, car elle analyse le trafic qui transite déjà par chez vous. Le scrubbing center doit d’abord récupérer le trafic, et la redirection suivie de la convergence BGP prend généralement de quelques dizaines de secondes à plusieurs minutes. Face à des floods records d’une durée de 35 secondes (Cloudflare, février 2026), cet écart est décisif.
Le filtrage dans votre propre réseau arrêtera-t-il une attaque à l’échelle du térabit ?
Pas à lui seul. Il est limité par la capacité de vos uplinks ; un flood plus important que vos liens doit donc être arrêté en amont. C’est pourquoi une conception raisonnable prévoit deux niveaux : le filtrage local de tout ce qui tient dans le lien et, pour le reste, l’escalade vers le blackholing chez l’opérateur, des règles FlowSpec sur sa bordure ou un scrubbing center.
Une solution locale revient-elle plus cher qu’un abonnement cloud ?
Sur un horizon de quelques années, généralement non. La solution locale représente un déploiement unique, auquel s’ajoutent la licence et le support, pour un coût fixe quelle que soit la taille de l’attaque. Le scrubbing est facturé au Gbit/s de trafic nettoyé ; son coût augmente donc avec l’attaque et culmine lors des longues campagnes. En revanche, le modèle local exige un investissement initial et des compétences pour l’exploiter. Les tarifs actuels figurent sur la page Tarifs.
Pourquoi le chemin du trafic compte-t-il au regard de NIS2 ?
Parce que le filtrage local garde chaque paquet à l’intérieur de votre réseau, alors que le scrubbing fait passer votre trafic, y compris les données des abonnés et les profils de trafic, par un tiers. Pour les FAI, les opérateurs télécoms et les entités réglementées, maintenir le chemin du trafic dans le réseau relève parfois d’une exigence de conformité, et pas seulement d’une préférence architecturale.
