Arrêtez de tester sur des réseaux parfaits : implémentez des Chaos Tunnels pour des interfaces résilientes

Dans le flux de développement web moderne, “localhost” est une illusion. Nous construisons des applications sur des connexions fibre à très faible latence, fonctionnant sur des machines avec 32 Go de RAM, et testons contre des serveurs locaux qui répondent en moins de milliseconde. Ensuite, nous déployons ces applications aux utilisateurs dans un métro bondé avec un signal 5G fluctuant, ou à un navetteur rural confronté à une perte de paquets élevée.

Le résultat ? Des interfaces utilisateur fragiles qui se figent, clignotent ou plantent dès que le “chemin heureux” d’un réseau parfait disparaît.

Pour construire un logiciel vraiment résilient, il faut cesser de considérer le réseau comme une constante et commencer à le voir comme une variable. C’est ici qu’intervient l’ingénierie du chaos sur localhost. En implémentant des “Chaos Tunnels” — des proxies qui dégradent intentionnellement votre connexion locale — vous pouvez tester la gestion des erreurs et la gestion d’état de votre UI avant qu’une seule ligne de code n’atteigne la production.

---

La fausse sécurité de localhost

Lorsque vous développez en local, vos requêtes fetch() ne traversent pas Internet. Elles passent par une interface de boucle locale sans jitter, sans congestion et sans interférence de signal. Dans cet environnement stérile, les conditions de course restent cachées. Vos indicateurs de chargement semblent parfaits car ils n’apparaissent qu’une fraction de seconde.

Mais le monde réel est différent. Une étude comparant les réseaux publics 5G Standalone (SA) et Non-Standalone (NSA) publiée en février 2026 a révélé que la NSA 5G publique affichait une latence d’environ 54 ms en moyenne — avec un jitter presque dix fois supérieur à celui d’un réseau privé SA, et des pics occasionnels de plus de 50 ms au-dessus de la médiane. L’article Wikipedia sur la 5G indique que la latence augmente considérablement lors des handovers entre tours, allant de 50 à 150 ms selon les conditions du réseau.

C’est cette différence que votre environnement localhost vous cache.

Pourquoi les DevTools du navigateur ne suffisent pas

La plupart des développeurs utilisent l’onglet “Throttling” dans Chrome ou Firefox pour une vérification rapide. Bien utile, mais ces outils ont des limitations fondamentales :

Uniquement au niveau de l’application. Ils n’affectent que le thread principal du navigateur et les requêtes sortantes. Ils ne simulent pas les problèmes matériels ou les perturbations systémiques.

Lenteur prévisible. La limitation standard offre un débit fixe, comme “Fast 3G”. Elle ne simule pas le chaos d’une connexion rapide pendant deux secondes puis qui perd 20% des paquets pendant les cinq suivantes.

Aucune simulation TCP. Les DevTools ne peuvent pas simuler une panne DNS ou un timeout TCP en cours de transfert d’un gros payload.

---

Définir le Chaos Tunnel : un proxy de dégradation réseau

Un “Chaos Tunnel” est un intermédiaire — un proxy de dégradation réseau — placé entre votre application frontend et votre backend ou API externes. Contrairement au throttling du navigateur, un chaos tunnel opère au niveau du transport, vous permettant de manipuler le flux brut de données TCP.

En routant le trafic local via un outil comme Toxiproxy, vous pouvez injecter des “toxics” dans votre connexion :

• Latence : Ajouter un délai de base (ex. 500 ms) à chaque requête.
• Jitter : Ajouter une variance aléatoire à ce délai (ex. ±200 ms).
• Limitation de bande passante : Limiter le débit pour simuler une connexion edge 2G.
• Fermeture lente : Retarder la fermeture d’une connexion pour voir comment votre UI gère les sockets suspendus.
• Slicer : Découper les données en petits morceaux pour tester des cas limites en streaming ou en uploads chunkés.
• Reset peer : Terminer brutalement une connexion en vol pour simuler une signalisation perdue.

---

Mise en place de l’ingénierie du chaos sur localhost : un guide étape par étape

Nous utiliserons Toxiproxy, un framework proxy TCP créé à l’origine par Shopify pour simuler les conditions réseau. Actif depuis 2014, il est selon une étude de 2025 analysant l’adoption sur GitHub, l’un des trois outils d’ingénierie du chaos les plus utilisés, aux côtés de Chaos Mesh et Netflix’s Chaos Monkey — représentant plus de 64% des dépôts utilisant ces outils.

Toxiproxy est indépendant du langage, fonctionne en tant que binaire unique, et expose une API de gestion HTTP simple, idéal pour le développement local et les pipelines CI.

Étape 1 : Installer Toxiproxy

Installer le serveur et le CLI via Homebrew sur macOS :

brew install toxiproxy

Ou récupérer l’image Docker (utile pour les environnements CI et Docker Compose) :

docker pull ghcr.io/shopify/toxiproxy:latest

Démarrer le serveur dans un terminal. Il écoute sur le port 8474 par défaut — c’est l’API du plan de contrôle :

toxiproxy-server

Étape 2 : Créer un tunnel proxy

Supposons que votre API backend fonctionne sur localhost:3000. Créez un tunnel sur localhost:4000 qui transfère le trafic vers le backend réel mais que vous pouvez corrompre à la demande :

toxiproxy-cli create api_proxy --listen localhost:4000 --upstream localhost:3000

Mettez à jour votre variable d’environnement frontend pour pointer vers le proxy :

# .env.local
API_URL=http://localhost:4000

À partir de ce moment, votre app communique avec Toxiproxy, qui transfère vers le vrai serveur. Vous contrôlez le chaos indépendamment, sans toucher au code de votre application.

Étape 3 : Injecter le chaos

Voici la partie utile. Simulez une connexion 5G “instable” — rapide sur le papier, mais sujette à des ombres de signal et des pics de handover.

Simulation de latence 5G avec jitter :

toxiproxy-cli toxic add api_proxy --type latency --attribute latency=100 --attribute jitter=500

Cela ajoute un délai de 100 ms avec une fenêtre de jitter de 500 ms, ce qui signifie que votre UI expérimentera des temps de réponse entre 100 ms et 600 ms de manière imprévisible — une simulation assez précise du 5G NSA public dans un environnement bondé.

Simulation de perte de paquets :

toxiproxy-cli toxic add api_proxy --type limit_data --attribute bytes=0

Ou utilisez le toxic reset_peer pour simuler des déconnexions abruptes.

Le fait de superposer plusieurs toxics est aussi possible. Vous pouvez empiler une limite de bande passante sur la latence pour recréer un scénario de réseau edge.

Étape 4 : Utiliser avec Docker Compose

Pour les équipes utilisant des stacks containerisés, Toxiproxy s’intègre parfaitement dans un fichier Docker Compose en tant que service sidecar. Vos services applicatifs pointent leurs chaînes de connexion vers les ports de Toxiproxy plutôt que directement vers leurs dépendances :

services:
  toxiproxy:
    image: ghcr.io/shopify/toxiproxy:latest
    ports:
      - "8474:8474"   # API du plan de contrôle
      - "4000:4000"   # Proxy pour votre API

  api:
    build: ./api
    environment:
      - BACKEND_URL=http://toxiproxy:4000
    depends_on:
      - toxiproxy

Cette approche ne nécessite aucune modification du code applicatif, au-delà de la mise à jour de la chaîne de connexion.

---

Scénarios spécifiques : Que testez-vous réellement ?

La connexion “Zombie” (Perte de paquets élevée)

Parfois, une connexion n’est pas coupée — elle est simplement tellement perdue qu’elle en devient inutilisable.

• Expérience : Configurez une perte de paquets de 15% sur votre chaos tunnel avec limit_data ou reset_peer toxics.
• Ce qu’il faut observer : Votre UI déclenche-t-elle un timeout, ou reste-t-elle en état de “chargement” indéfiniment ? Une UI résiliente devrait détecter qu’une requête est probablement morte après un certain seuil et proposer à l’utilisateur une option “Réessayer” plutôt qu’un spinner infini.

Le spike de handover 5G

Lorsque les utilisateurs passent d’une tour 5G à une autre ou changent de fréquences mmWave à mid-band, la latence peut sauter de moins de 20 ms à 150 ms ou plus durant le handover.

• Expérience : Script un toxic qui déclenche un spike de latence de 1 000 ms pendant 5 secondes toutes les 30 secondes.
• Ce qu’il faut observer : Votre UI gère-t-elle une requête en vol lors du spike ? Obtenez-vous des soumissions en double ? Les écrans de transition se font-ils en douceur vers un état “Toujours en cours…” ?

Le DNS Blackhole

Que se passe-t-il si votre API est opérationnelle, mais que le fournisseur DNS de l’utilisateur échoue ou qu’un script tiers non essentiel ne peut pas résoudre ?

• Expérience : Utilisez votre proxy pour bloquer tout le trafic vers une cible spécifique (par ex., un fournisseur d’analytique ou de test A/B).
• Ce qu’il faut observer : Votre app ne parvient-elle pas à démarrer parce qu’un script de suivi non essentiel bloque le thread principal ? C’est une erreur courante et facile à manquer — les chaos tunnels la révèlent instantanément.

La Slow-Close / Socket suspendu

Une connexion qui reste “ouverte” sans transmettre de données est l’un des scénarios réels les plus difficiles, surtout sur mobile où les machines d’état radio tentent de préserver la batterie en suspendant les connexions.

• Expérience : Appliquez le toxic slow_close avec un délai de plusieurs secondes.
• Ce qu’il faut observer : Votre UI définit-elle un timeout de requête significatif ? Ou se bloque-t-elle indéfiniment ?

---

Concevoir pour la résilience : modèles frontend à adopter

Une fois que votre UI s’effondre sous un chaos tunnel, vous pouvez mettre en œuvre des patterns défensifs avec confiance et les mesurer empiriquement.

1. UI optimiste avec rollback

N’attendez pas la confirmation du serveur pour un “Like” ou une soumission de formulaire. Mettez à jour l’UI immédiatement. Mais, l’ingénierie du chaos vous oblige à tester le chemin de rollback. Si le tunnel finit par couper la connexion, votre UI revient-elle gracieusement en arrière et affiche-t-elle un message d’erreur clair — ou laisse-t-elle silencieusement l’utilisateur dans un état cassé ?

2. Écrans squelette intelligents

Les spinners de chargement standard sont frustrants sur des réseaux à haute latence. Les écrans squelette offrent une amélioration perçue des performances. En utilisant un chaos tunnel avec une latence élevée, vous pouvez ajuster empiriquement le timing de ces écrans. Si une requête prend systématiquement plus de deux secondes, vous pouvez passer d’un squelette à un message “Toujours en cours…” pour donner à l’utilisateur une information actionable plutôt qu’incertaine.

3. Disjoncteurs (Circuit Breakers) côté frontend

Tout comme pour les microservices backend, les composants frontend devraient avoir des disjoncteurs. Le pattern — popularisé par la bibliothèque Hystrix de Netflix — fonctionne aussi en code client. Si un appel API échoue trois fois de suite via le chaos tunnel, le composant doit arrêter de réessayer et entrer en “Mode dégradé”, peut-être en affichant des données en cache plutôt qu’un état vide cassé.

Un disjoncteur côté client fonctionne comme une machine à états : Fermé (fonctionnement normal), Ouvert (échec rapide sans requêtes), et Semi-ouvert (permettant une requête de test pour voir si le service a récupéré). Des bibliothèques comme opossum apportent ce pattern à Node.js ; pour du code frontend pur, une implémentation légère est simple à écrire à la main.

4. Timeout explicite des requêtes

Le chaos tunnel exposera toute requête fetch() sans timeout configuré. Configurez toujours un AbortController avec un timeout raisonnable — généralement 5 à 10 secondes pour les requêtes utilisateur — pour éviter que des sockets suspendus bloquent indéfiniment votre UI.

const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 8000);

try {
  const response = await fetch('/api/data', { signal: controller.signal });
  // traiter la réponse
} catch (err) {
  if (err.name === 'AbortError') {
    // afficher une UI de réessai
  }
} finally {
  clearTimeout(timeoutId);
}

5. Scripts non essentiels ne doivent pas bloquer le thread principal

Votre fournisseur d’analytique, la bibliothèque A/B testing, et les scripts publicitaires sont non essentiels. Chargez-les avec defer ou async, et vérifiez toujours (via le scénario de blackhole DNS ci-dessus) que leur échec ne bloque pas le démarrage de votre application principale.

---

La boîte à outils frontend pour le chaos

Au-delà de Toxiproxy, l’écosystème s’est étoffé. Le dépôt GitHub awesome-chaos-engineering recense une communauté active d’outils, y compris un Chaos Frontend Toolkit dédié — un ensemble d’outils spécifiquement conçus pour appliquer l’ingénierie du chaos aux applications frontend. Pour la simulation au niveau du navigateur sans proxy, Mock Service Worker (MSW) peut simuler des réponses API avec des délais injectés et des codes d’erreur — utile pour tester des composants isolément.

Voici une comparaison mise à jour des principaux outils :

Outil	Idéal pour	Fonctionnalité clé
Toxiproxy	Localhost / CI	Proxy TCP hautement scriptable ; idéal pour tests automatisés et Docker
Pumba	Environnements Docker	Tuer et limiter la bande passante des containers Docker et leurs liens réseau
Chaos Mesh	Kubernetes	Injection de fautes à l’échelle du cluster ; reconnu par la CNCF en tant que projet incubé
MSW (Mock Service Worker)	Tests unitaires / composants	Worker de service navigateur interceptant fetch ; pas besoin de proxy
Network Link Conditioner	macOS	Limitation système ; utile pour tester applications natives et tout trafic navigateur
Chaos Frontend Toolkit	Frontend	Spécifiquement conçu pour expérimenter la résilience UI

---

Mesurer le succès : métriques de résilience essentielles

Réaliser des expériences de chaos n’a d’intérêt que si vous suivez ce qui change. Définissez un “Profil de Résilience” pour chaque grande fonctionnalité et mesurez ces métriques avant et après :

Temps jusqu’à l’interactivité sous stress (TTI-S) : Quel est votre TTI quand il y a 200 ms de jitter ? Comparez avec votre baseline.

Taux de récupération d’erreur : Quel pourcentage des requêtes échouées aboutissent à une nouvelle tentative réussie par l’utilisateur ? Une UI de réessai bien conçue peut récupérer une part importante d’utilisateurs sinon perdus.

Durée d’état “Zombie” : Combien de temps un utilisateur reste-t-il sur un écran sans feedback lorsque le réseau est coupé ? Cela doit être limité par votre timeout de requête et la mise à jour UI suivante.

Isolement des échecs de scripts non essentiels : Bloquer votre fournisseur d’analytique affecte-t-il le TTI ? Cela ne devrait pas.

---

Intégrer le chaos dans la CI

Un chaos tunnel est d’autant plus précieux qu’il s’exécute automatiquement. Avec l’API HTTP de Toxiproxy et ses bibliothèques clientes disponibles pour la plupart des langages, vous pouvez écrire des suites de tests qui :

1. Démarrent une instance de Toxiproxy dans votre pile Docker Compose.
2. Configurent un proxy pointant vers votre API.
3. Injectent un toxic (ex. latence de 500 ms) avant d’exécuter votre suite de tests end-to-end.
4. Vérifient que votre UI affiche le squelette, le message de timeout, et le bouton de réessai dans les délais.
5. Suppriment le toxic et vérifient que l’opération normale reprend.

Cela transforme la résilience d’un exercice manuel en une étape de régression automatique à chaque pull request.

---

Conclusion : Faites du chaos une partie intégrante de la définition de terminé

L’ingénierie du chaos n’a pas pour but de casser pour le plaisir. Elle vise à construire une confiance justifiée. Quand vous savez que votre UI gère un spike de handover 5G simulé, un blackhole DNS, et 15% de perte de paquets sur localhost, vous pouvez déployer en production avec moins de surprises.

L’écart entre un environnement localhost stérile et le vrai monde du 5G public — où le jitter peut être presque dix fois supérieur à celui d’un réseau privé — n’est pas un écart que vous devriez découvrir après un déploiement. C’est un écart contre lequel vous devriez vous préparer dès le départ.

Arrêtez de tester sur des réseaux parfaits. Mettez en place un proxy, injectez quelques toxics, et commencez à traiter l’instabilité réseau comme une priorité dans votre processus de développement.

---

Liste de vérification résumé

• [ ] Installer Toxiproxy (binaire ou image Docker) et exposer le plan de contrôle sur le port 8474.
• [ ] Créer un tunnel proxy d’un port local vers votre API backend.
• [ ] Mettre à jour vos variables d’environnement frontend pour pointer vers le tunnel.
• [ ] Injecter jitter (±500 ms) pour révéler des conditions de course et des soumissions en double.
• [ ] Simuler un spike de handover 5G (1 000 ms pendant 5 secondes toutes les 30 secondes) pour tester la gestion des requêtes en vol.
• [ ] Appliquer un toxic de perte de paquets / reset pour vérifier le timeout et la gestion de réessai.
• [ ] Exécuter le scénario de blackhole DNS — bloquer votre fournisseur d’analytique et confirmer que l’app démarre toujours.
• [ ] Implémenter des timeouts avec AbortController sur toutes les requêtes fetch() utilisateur.
• [ ] Ajouter un disjoncteur pour les composants appelant des endpoints fréquemment échoués.
• [ ] Charger tous les scripts non essentiels (analytics, A/B testing) avec defer ou async.
• [ ] Intégrer vos scénarios de chaos dans la CI pour détecter automatiquement les régressions de résilience.