Comment surveiller votre bande passante pour empêcher Netflix de bloquer votre ERP ?

16h. Le pic d’activité. Les équipes de la comptabilité signalent que l’ERP rame et que les factures ne se chargent plus. Au même moment, le monitoring réseau affiche une saturation quasi totale du lien internet. Ce scénario est le quotidien de nombreux administrateurs réseau, pris en étau entre les exigences des applications métiers et un flot de trafic hétérogène et gourmand en ressources. L’accusé est souvent tout trouvé : le streaming vidéo, les mises à jour logicielles, la synchronisation de fichiers cloud personnels…

La première impulsion est souvent de blâmer nommément Netflix ou YouTube, ou d’appeler son fournisseur d’accès pour doubler un débit fibre qui semble déjà insuffisant. Ces approches, bien que compréhensibles, ne traitent que les symptômes. Elles s’apparentent à vouloir construire une autoroute toujours plus large en espérant fluidifier le trafic, sans jamais installer de panneaux de signalisation ni de voies prioritaires pour les services d’urgence. Le véritable enjeu n’est pas la quantité de bande passante, mais sa gestion.

Et si la solution n’était pas de construire, mais de réguler ? Si, au lieu de subir la congestion, vous pouviez l’orchestrer, en garantissant une voie express inviolable pour votre ERP et votre téléphonie, tout en allouant le reste des ressources de manière intelligente ? C’est tout l’objet de la régulation de flux et de la Qualité de Service (QoS). L’objectif n’est plus d’interdire, mais de comprendre, classer et prioriser chaque paquet pour que vos applications critiques ne soient plus jamais les otages du trafic non essentiel.

Cet article est votre feuille de route pour passer d’une gestion réactive à un pilotage proactif de votre bande passante. Nous allons détailler les outils de diagnostic, les stratégies de priorisation et les configurations techniques précises pour reprendre le contrôle de votre réseau et garantir la performance applicative, quelle que soit l’heure de la journée.

Qui consomme quoi ? Les outils indispensables pour auditer votre trafic en temps réel

Avant de pouvoir réguler, il faut comprendre. L’étape fondamentale pour reprendre le contrôle de sa bande passante est d’obtenir une visibilité parfaite sur les flux qui transitent par votre réseau. Tenter de mettre en place une QoS sans un diagnostic de flux préalable revient à piloter à l’aveugle. Les outils modernes ne se contentent plus de montrer un pourcentage global d’utilisation ; ils permettent une analyse granulaire : qui (quel utilisateur ou adresse IP), consomme quoi (quelle application), vers où (quelle destination) et combien.

Pour atteindre ce niveau de détail, les protocoles comme NetFlow (Cisco), sFlow (standard industriel) ou IPFIX sont incontournables. Ils transforment vos routeurs et commutateurs en sondes intelligentes, capables de collecter des métadonnées sur chaque conversation réseau sans en capturer le contenu. Ces données sont ensuite envoyées à un « collecteur » qui les analyse et les présente sous forme de tableaux de bord clairs. Vous pouvez ainsi identifier en quelques clics le poste de travail qui télécharge des ISO volumineuses ou les applications de streaming qui s’accaparent la connexion.

Ces plateformes de monitoring permettent de mettre en place des alertes proactives basées sur des seuils ou des comportements anormaux. Le déploiement d’une solution de surveillance permet non seulement de visualiser les flux de travail critiques, mais aussi d’identifier rapidement des comportements suspects. Par exemple, l’étude de cas du déploiement de PRTG chez Cherry Republic montre comment la surveillance NetFlow a permis de repérer des activités potentiellement malveillantes, offrant une visibilité indispensable à la sécurité et à la performance.

Un tableau de bord bien configuré met en évidence les principaux consommateurs de bande passante, les applications les plus utilisées et les conversations les plus actives. Cette cartographie est le point de départ de toute stratégie de QoS : elle vous fournit les données objectives pour justifier des actions de régulation et mesurer leur efficacité dans le temps.

Vidéoconférence vs YouTube : qui gagne la bataille de la bande passante dans vos bureaux ?

À première vue, un appel Teams en HD et une vidéo YouTube en 1080p semblent similaires : ce sont des flux vidéo qui consomment de la bande passante. Pourtant, d’un point de vue réseau, ils sont radicalement différents, et cette distinction est la clé de la priorisation. L’un est un service critique pour l’entreprise, l’autre un loisir. Il est d’ailleurs frappant de constater que des services comme Netflix captent 12,3% du trafic internet entrant en France, un volume colossal qui illustre bien le poids du streaming de divertissement sur les infrastructures.

Le trafic de vidéoconférence (Teams, Zoom) est bidirectionnel, temps réel et extrêmement sensible à la latence et à la gigue (la variation de la latence). Il utilise principalement le protocole UDP, qui privilégie la vitesse à la fiabilité : un paquet perdu n’est pas retransmis, car il arriverait trop tard. La moindre congestion se traduit immédiatement par une image qui se fige, un son qui coupe, bref, une expérience dégradée qui impacte la productivité.

À l’inverse, le streaming vidéo (YouTube, Netflix) est unidirectionnel (download uniquement) et utilise majoritairement le protocole TCP. Il est conçu pour être résilient face aux aléas du réseau. Grâce à des mécanismes de mise en mémoire tampon (buffering), l’application peut pré-charger plusieurs secondes, voire minutes de vidéo. Un pic de latence ou une perte de paquet temporaire sera totalement invisible pour l’utilisateur, car le lecteur continuera de piocher dans son buffer. Ce trafic est donc gourmand en volume, mais tolérant aux délais.

Le tableau suivant synthétise ces différences fondamentales, qui justifient une gestion différenciée par la QoS.

Faut-il brider les mises à jour Windows pendant les heures de bureau ?

Autre grand consommateur silencieux de bande passante : les mises à jour Windows. Un « Patch Tuesday » peut rapidement saturer un lien internet si des centaines de machines se mettent à télécharger plusieurs gigaoctets simultanément, souvent en arrière-plan et aux heures les plus critiques. Brider ce trafic est non seulement recommandé, mais essentiel pour protéger les performances des applications interactives. Cependant, le « comment » est plus important que le « si ».

Une idée reçue tenace concerne la réservation de bande passante par Windows. Il est souvent dit que le système réserve 20% de la bande passante pour la QoS. En réalité, le planificateur de paquets QoS peut réserver jusqu’à 80% de la bande passante pour des applications prioritaires qui le demandent, laissant par défaut 20% pour le reste. Modifier ce paramètre n’aura donc que peu d’impact sur la consommation entrante des mises à jour. La bonne approche est d’utiliser des outils de gestion centralisée pour contrôler la distribution de ces mises à jour.

Plusieurs stratégies, chacune avec ses avantages et inconvénients, peuvent être mises en œuvre. L’introduction d’un serveur WSUS (Windows Server Update Services) local offre un contrôle total en ne téléchargeant les mises à jour qu’une seule fois depuis internet. L’optimisation de la distribution (Delivery Optimization) en mode P2P permet aux machines d’un même réseau local de se partager les fichiers téléchargés, réduisant drastiquement le trafic vers l’extérieur. Enfin, des GPO (Group Policy Objects) permettent de planifier les téléchargements et installations en dehors des heures de bureau ou de limiter le débit alloué à ce service.

Le tableau suivant compare ces différentes approches pour vous aider à choisir la plus adaptée à votre infrastructure.

Vidéo HD ou SD : comment régler Teams et Zoom pour économiser 30% de bande passante ?

Si le trafic de visioconférence doit être prioritaire, cela ne signifie pas qu’il ne peut pas être optimisé. Contrôler la consommation de bande passante de plateformes comme Microsoft Teams ou Zoom est une démarche proactive qui permet de préserver les ressources réseau, surtout dans les environnements à grande échelle. Contrairement aux idées reçues, la vidéo HD n’est pas toujours synonyme de consommation excessive. En effet, Teams est toujours prudent sur l’utilisation de la bande passante et peut fournir une qualité vidéo HD en moins de 1,5 Mbits/s grâce à des codecs très efficaces comme H.264 et une adaptation dynamique à la qualité du lien.

Cependant, il est possible d’aller plus loin et d’imposer des règles plus strictes via les consoles d’administration et les GPO. L’objectif est de trouver le juste équilibre entre qualité d’expérience et économie de bande passante. Forcer une résolution maximale à 720p (HD) au lieu de 1080p (Full HD) pour les réunions standards est souvent imperceptible pour les utilisateurs, mais peut générer des économies significatives. De même, la désactivation par défaut des fonctionnalités gourmandes comme les arrière-plans virtuels vidéo (qui demandent plus de calcul et donc plus de données à encoder) contribue à alléger la charge.

Pour une optimisation technique, plusieurs actions peuvent être menées de manière centralisée :

• Configurer la QoS via GPO : Prioriser les flux UDP sur les ports spécifiques (ex: 3478-3481 pour Teams) en leur appliquant un marquage DSCP élevé.
• Limiter la résolution vidéo : Utiliser les stratégies d’administration Teams ou Zoom pour plafonner la qualité vidéo par défaut à 720p.
• Activer le mode « économie de données » : Certaines plateformes proposent des modes qui réduisent la consommation globale, parfois jusqu’à 30%, en ajustant dynamiquement la qualité.
• Gérer les codecs : Dans des environnements plus complexes comme le VDI avec Citrix, l’optimisation pour Microsoft Teams permet une gestion fine des codecs audio et vidéo (Opus, H.264) pour s’adapter en temps réel à la bande passante disponible.

Ces réglages, combinés, permettent de maintenir une excellente qualité de service pour la collaboration tout en libérant une part non négligeable de bande passante pour d’autres applications. C’est un exemple parfait de régulation granulaire où l’on n’interdit pas, mais on optimise.

L’attaque DDoS interne : comment repérer une machine infectée qui sature votre lien montant ?

La saturation de la bande passante n’est pas toujours causée par des usages légitimes mais gourmands. Une cause plus insidieuse et souvent négligée est la compromission d’un ou plusieurs postes de travail. Une machine infectée par un malware ou intégrée à un botnet peut se mettre à générer un volume colossal de trafic, souvent en émission (upload), dans le cadre d’une attaque par déni de service distribué (DDoS) visant une cible externe. Pour l’entreprise, le symptôme est une saturation du lien montant et un ralentissement général de l’accès à internet, y compris pour l’ERP.

Repérer une telle machine au milieu de centaines ou de milliers d’autres est impossible sans les bons outils de diagnostic de flux. C’est ici que les collecteurs NetFlow/sFlow prennent tout leur sens. Ils permettent d’identifier des schémas de trafic totalement anormaux qui trahissent une infection. Par exemple, une alerte peut être déclenchée lors de pics soudains de trafic ou si des flux sont acheminés vers le port 0, ce qui indique souvent du trafic malformé ou malveillant. Cette détection précoce est cruciale pour isoler la machine avant qu’elle ne cause plus de dégâts ou que votre adresse IP publique ne soit blacklistée.

Un protocole de détection et de réponse doit être en place pour réagir rapidement face à une suspicion de « DDoS interne ». Voici les étapes clés à surveiller :

• Surveiller les compteurs d’erreurs : Garder un œil sur les « output drops », « discards » et « overruns » sur les interfaces de vos routeurs et commutateurs. Une augmentation soudaine est un signe de congestion anormale.
• Définir des alertes comportementales : Configurer des alertes sur des usages de ports inhabituels (ex: ports IRC) ou un nombre anormalement élevé de connexions sortantes depuis un même poste.
• Analyser le trafic DNS : Un pic de requêtes DNS provenant d’une seule machine peut indiquer qu’un malware tente de contacter son serveur de commande et de contrôle (C&C).
• Identifier les destinations suspectes : Repérer un poste qui établit des milliers de connexions simultanées vers une multitude de destinations inconnues ou réputées malveillantes.
• Isoler et analyser : Une fois le poste suspect identifié, il doit être immédiatement isolé du réseau (par exemple, en le plaçant dans un VLAN de quarantaine) pour une analyse forensique approfondie.

Cette vigilance permet non seulement de protéger votre bande passante, mais aussi de constituer une ligne de défense essentielle pour la sécurité de votre système d’information.

Quand doubler votre débit fibre : la méthode de calcul basée sur l’usage réel

Demander une augmentation de débit est souvent la solution de facilité, mais c’est une décision coûteuse qui doit être justifiée par des données objectives, et non par un simple « ressenti » de lenteur. Comment savoir si vous avez réellement atteint les limites de votre connexion ou si le problème vient d’une mauvaise gestion du trafic ? La réponse se trouve, encore une fois, dans l’analyse de votre monitoring réseau sur une période significative.

La pire méthode consiste à se baser sur les pics d’utilisation. Un pic ponctuel, même s’il atteint 100% de votre capacité, peut être causé par un événement exceptionnel (un gros téléchargement, une sauvegarde cloud). Baser une décision d’investissement sur cet événement unique n’est pas pertinent. La méthode professionnelle pour mesurer l’utilisation soutenue de la bande passante est le calcul du 95ème centile. Comme le soulignent les bonnes pratiques d’analyse, les rapports du 95e centile sont largement utilisés pour mesurer l’utilisation régulière et soutenue, car ils éliminent les 5% de pics les plus élevés. Si la valeur de votre 95ème centile se rapproche dangereusement (à 80-90%) de votre débit souscrit, alors une augmentation est justifiée.

En parallèle, une approche de capacity planning est nécessaire. Il ne s’agit plus de regarder le passé, mais de projeter les besoins futurs. Combien de nouveaux collaborateurs prévoyez-vous ? Allez-vous déployer de nouvelles salles de visioconférence ? Pour chaque service, il existe des recommandations de consommation. Par exemple, Microsoft recommande d’allouer 10 Mbits/s pour chaque salle équipée d’un compte de ressource « Salles Teams ». En additionnant les besoins des applications critiques (VoIP, ERP, visioconférence) et en y ajoutant une marge pour le trafic de fond, vous obtiendrez une estimation fiable du débit dont vous aurez besoin à moyen terme.

Ce n’est qu’en combinant l’analyse de l’existant (via le 95ème centile) et la projection des besoins futurs (via le capacity planning) que vous pourrez prendre une décision éclairée et financièrement justifiée. Le plus souvent, cette analyse révèle qu’une meilleure QoS est plus efficace et moins chère qu’une augmentation de débit.

L’erreur de policing qui jette des paquets valides lors de micro-bursts (pics de trafic)

Dans la mise en place d’une politique de QoS, une erreur commune peut avoir des conséquences désastreuses sur les applications, en particulier celles utilisant TCP comme un ERP. Il s’agit de la confusion entre deux mécanismes de limitation de débit : le policing et le shaping. Bien que leur objectif soit de contrôler le trafic, leur méthode diffère radicalement. Le policing est une méthode brutale : dès que le trafic dépasse la limite définie, les paquets excédentaires sont tout simplement jetés (« dropped »).

Le problème survient lors de micro-bursts. Il s’agit de pics de trafic extrêmement brefs (quelques millisecondes) qui sont inhérents au fonctionnement de protocoles comme TCP. Si une politique de policing stricte est en place, ces paquets légitimes seront jetés. Pour TCP, une perte de paquet est un signal de congestion sévère, ce qui le pousse à réduire drastiquement sa fenêtre d’envoi et à retransmettre les données perdues. Résultat : l’application (votre ERP) subit des ralentissements importants, alors même que le lien n’est pas saturé sur la durée. Vous avez créé une congestion artificielle.

Le traffic shaping, à l’inverse, est une méthode plus douce. Au lieu de jeter les paquets excédentaires, il les place dans une file d’attente (buffer) pour les envoyer dès que la bande passante se libère. Il lisse les pics de trafic au lieu de les couper. Pour des flux non temps réel comme ceux d’un ERP, c’est de loin la meilleure approche, car elle évite les retransmissions TCP coûteuses. Le policing doit être réservé aux situations où l’on veut explicitement pénaliser un trafic non désiré, mais jamais pour réguler un trafic légitime.

QoS : comment configurer votre réseau pour que la téléphonie ne coupe jamais, même en cas de surcharge ?

Nous arrivons au cœur de la régulation : la mise en place d’une politique de Qualité de Service (QoS) de bout en bout. L’objectif est de s’assurer que le trafic le plus sensible, comme la voix sur IP (VoIP), bénéficie d’un traitement prioritaire à chaque point du réseau, garantissant une qualité parfaite même si un utilisateur lance un téléchargement de 50 Go. Le mécanisme clé pour y parvenir est le marquage DSCP (Differentiated Services Code Point).

Le marquage consiste à insérer une petite valeur dans l’en-tête de chaque paquet réseau. Cette « étiquette » indique aux routeurs et commutateurs la classe de priorité du paquet. Pour que cela fonctionne, tous les équipements du réseau doivent être configurés pour interpréter ces valeurs et placer les paquets dans les bonnes files d’attente. L’implémentation de cette solution peut se faire de manière centralisée, par exemple via GPO dans un environnement Active Directory, pour s’assurer que tout le trafic généré par Skype ou Teams est correctement marqué à la source.

La configuration la plus courante et la plus efficace pour la voix est le LLQ (Low Latency Queuing). Elle consiste à créer une file d’attente prioritaire stricte, avec une bande passante garantie, exclusivement réservée au trafic le plus critique. Voici les valeurs DSCP standards à utiliser :

• Trafic Voix (RTP) : Doit être marqué en DSCP EF (Expedited Forwarding – valeur 46). C’est la plus haute priorité. Ce trafic sera placé dans la file d’attente LLQ.
• Trafic ERP : Peut être marqué en DSCP AF41 (Assured Forwarding – valeur 34). Il bénéficiera d’une bonne priorité et d’une bande passante garantie, juste en dessous de la voix.
• Signalisation (SIP, H.323) : Souvent marquée en DSCP CS3 (Class Selector – valeur 24). Elle est importante mais moins sensible à la latence que le flux audio lui-même.
• Trafic de fond (web, email) : Peut être laissé en DSCP 0 (Best Effort) ou marqué avec une priorité basse comme AF11.

Une fois cette hiérarchie mise en place, le trafic vocal passera toujours en premier, quoi qu’il arrive sur le reste du réseau. Votre téléphonie ne coupera plus jamais, et votre ERP restera réactif, même lorsque le lien internet est utilisé à 99% par des flux moins prioritaires.

Passez de la lutte contre la saturation à une maîtrise totale de votre réseau. Commencez dès aujourd’hui par déployer un outil de monitoring de flux pour obtenir la visibilité indispensable à toute stratégie de QoS efficace.