Comparatif des outils de test réseau : Clumsy, Toxiproxy et NetLimiter

01

Commencez par la limite du test

Un comparatif des outils de test réseau commence par le trajet que le test peut contrôler.

Pour comparer les outils de test réseau, demandez-vous où introduire le défaut. Pour modifier du trafic réel sélectionné sur un poste Windows, Clumsy peut appliquer un délai, une perte, une duplication ou un changement d’ordre aux flux qui correspondent au filtre. La limite comprend le poste, le filtre, la direction et la condition.

Si l’application peut se connecter par un proxy de test, Toxiproxy contrôle une connexion TCP qui le traverse. Cette méthode convient aux tests de services reproductibles, mais ne couvre ni le trafic qui contourne le proxy ni les chemins qui n’utilisent pas TCP.

Pour voir quelle application Windows utilise le réseau ou lui appliquer une règle de débit, NetLimiter correspond mieux au besoin. Ce n’est pas un outil de panne de paquets. Quel que soit l’outil, définissez une cible autorisée, un résultat observable et une vérification du retour à la normale avant de modifier le réseau.

02

Outils de test réseau : trois modèles de trafic

La couche où agit le test compte davantage que le nom du produit.

Clumsy agit sur les flux correspondant à un filtre dans un système Windows. Le testeur définit ce filtre, active une condition et observe l’application. L’approche convient lorsque l’application ne peut pas être configurée pour utiliser un proxy ou lorsque le chemin d’un vrai client Windows est important. Un filtre précis évite d’affecter d’autres activités et rend le résultat plus facile à interpréter.

Toxiproxy est un proxy TCP destiné à simuler des conditions réseau pendant le développement et les tests. L’application ou l’environnement doit envoyer la connexion concernée par ce proxy. Ce trajet explicite aide à répéter un scénario, à condition de vérifier la configuration et la couverture des protocoles.

NetLimiter vise l’observation et la gestion du trafic Internet par application sous Windows. Il peut aider à comprendre l’usage du réseau ou l’effet d’une limite de débit. Ne l’utilisez pas comme preuve d’un comportement de retransmission, de perte de paquets, de réordonnancement ou d’une panne de transport précise.

03

Choisissez selon le résultat à observer

Le choix doit s’appuyer sur des éléments que le test peut réellement recueillir.

Pour un client de bureau qui appelle directement une API distante, choisissez Clumsy si vous devez modifier le trafic correspondant sans changer les réglages de connexion du client. Consignez le filtre, la direction, la condition et sa valeur ; observez ensuite l’affichage d’attente, la retransmission d’une requête ou l’apparition d’une erreur récupérable. L’activation d’une condition ne prouve pas que les paquets visés ont été affectés.

Pour un test d’intégration dont le point de terminaison est configurable, faites passer la connexion par Toxiproxy et conservez les journaux du client et du service. Cette route explicite est reproductible dans la CI. Si le client ouvre des connexions secondaires, utilise un autre protocole ou contourne le point configuré, couvrez ces chemins séparément.

Utilisez NetLimiter pour une enquête Windows sur le processus qui transfère des données ou sur l’effet d’une règle de débit par application. Comparez le même transfert avant et après, en vérifiant que le serveur, le disque, le Wi-Fi ou un autre processus ne limite pas le résultat.

• Pour dégrader des paquets sur un client Windows, commencez avec Clumsy et un filtre étroitement défini.
• Pour une panne TCP reproductible en CI, routez le test par Toxiproxy et comparez le même résultat réseau entre les exécutions.
• Pour observer le trafic par application ou appliquer un débit, utilisez NetLimiter et comparez le transfert avant et après.
• Si l’outil n’expose pas le résultat attendu, ajoutez les journaux de l’application ou la télémétrie du service.

04

Rendez le comparatif reproductible

L’outil n’est qu’une partie d’un test réseau défendable.

Écrivez l’hypothèse avant de choisir les réglages. Par exemple : « Sous un délai contrôlé, le client doit laisser la requête en attente, appliquer sa politique de nouvelles tentatives après expiration du délai, puis récupérer lorsque la condition est retirée. » Cette phrase nomme l’application, le trajet modifié, le résultat attendu et la récupération.

Exécutez d’abord la même action sans défaut et conservez cette référence. Introduisez une seule condition avec l’outil choisi, gardez les autres variables fixes et relevez les horodatages, les journaux client et service ainsi que le résultat visible. Arrêtez la condition, répétez l’action et vérifiez le retour à la normale.

Pour Clumsy, conservez le filtre et la direction. Pour Toxiproxy, conservez la route et la configuration du proxy. Pour NetLimiter, notez l’application, la règle et le transfert mesuré. Dans tous les cas, ajoutez le système, la version de l’application, la cible, la période du test et l’activité simultanée.

Si le résultat varie, réduisez le périmètre avant d’augmenter la condition. Un test modéré et reproductible informe mieux qu’un réglage spectaculaire qui change plusieurs comportements.

1. Définir le périmètreNommez l’application, la cible de test autorisée, le protocole ou trajet et les personnes habilitées à lancer l’expérience.
2. Capturer une référenceLancez une action représentative sans condition et conservez les observations du client et du service.
3. Changer une variableUtilisez un seul outil et une seule condition. Consignez le filtre, la route proxy ou la règle d’application.
4. Observer et restaurerRelevez le résultat, arrêtez la condition, répétez l’action et confirmez la récupération.

05

Limites, autorisation et usage responsable

Puisque ces outils peuvent modifier ou limiter le trafic, un comparatif doit préciser son périmètre d’usage. Testez uniquement des systèmes et services qui vous appartiennent ou que vous êtes explicitement autorisé à évaluer. Préférez un laboratoire jetable, un service local ou un environnement de préproduction documenté ; ne perturbez ni une route de production partagée ni un service tiers.

Un outil ne garantit pas que la condition atteigne la requête visée. Un filtre peut sélectionner le mauvais flux, un proxy peut manquer une connexion qui le contourne et le débit peut être limité ailleurs. Validez le trajet avec des preuves de l’application et du service, et préparez une action d’arrêt ou de retour arrière.

Si le test affecte d’autres personnes, déclenche un comportement inattendu ou ne peut pas être arrêté proprement, arrêtez-le et rétablissez la référence avant de changer la configuration. Le but est d’obtenir des preuves de fiabilité contrôlées, pas de provoquer une perturbation.

06

Vérifiez les sources officielles et les versions

Avant d’installer ou de comparer un produit, consultez sa source première. La page des versions de Clumsy sur GitHub fait foi pour les tags, les fichiers et les notes. Vérifiée le 2026-11-05, elle indiquait toujours 0.3 comme dernière version officielle publiée. Une archive tierce ou un numéro plus élevé n’est pas automatiquement officiel.

Pour Toxiproxy, consultez le dépôt officiel du projet et sa documentation. Pour NetLimiter, vérifiez les informations actuelles sur les produits et plateformes sur le site de l’éditeur. Les fonctions et conditions peuvent évoluer.

Ce comparatif porte sur les rôles de test, pas sur les prix ni toutes les cases d’une fiche produit. Pour installer et utiliser Clumsy de façon contrôlée, consultez le guide de test Clumsy ou le guide des sources officielles. Pour distinguer émulation et simulation, lisez le guide des émulateurs réseau. Vérifiez la documentation avant d’ajouter un outil de test réseau à la CI.