La fin du Sidecar : Implémentation des Ztunnels dans Istio Ambient Mesh

Vous trouvez que les proxy sidecars consomment trop de ressources dans votre Kubernetes ? Passez à l’avenir sans sidecar avec Ambient Mesh Ztunnels, qui utilisent le protocole HBONE pour un routage zéro confiance, haute performance, au niveau du nœud.

Dans l’écosystème en rapide évolution de l’infrastructure cloud-native, peu de technologies ont connu un changement aussi radical dans leur philosophie opérationnelle que le service mesh. Pendant des années, l’industrie s’est appuyée fortement sur le modèle “sidecar” — un proxy dédié injecté dans chaque pod Kubernetes. Ce paradigme apportait des capacités essentielles comme le mutual TLS (mTLS), l’observabilité et le contrôle granulaire du trafic. Cependant, à mesure que la taille des clusters augmentait et que l’adoption en entreprise s’accélérait, les défauts architecturaux du modèle sidecar sont devenus impossibles à ignorer : consommation massive de CPU et mémoire, complexité du cycle de vie des applications, et une relation de couplage étroit entre infrastructure et applications.

La réponse à ces problèmes est arrivée. Istio Ambient Mesh, qui a atteint la disponibilité générale dans Istio 1.24 en novembre 2024 avec ztunnel, waypoints, et toutes les API marquées comme stables par le Comité de supervision technique d’Istio, devient désormais la configuration par défaut pour les nouvelles déploiements de service mesh Kubernetes. Au cœur de cette transformation se trouve le Ztunnel (Zero Trust Tunnel) — un proxy au niveau du nœud qui change fondamentalement la sécurisation et le routage du trafic Kubernetes.

Dans ce guide, nous explorons le fonctionnement d’Istio Ambient Mesh et du Ztunnel, les spécificités du protocole HBONE, comment le CNI d’Istio gère la redirection du trafic, et la direction prise par le projet jusqu’en 2026.

---

L’ère du Sidecar : pourquoi il devait disparaître

Pour comprendre la conception d’Ambient Mesh, il faut d’abord saisir la douleur causée par le modèle qu’il remplace. La couche de données traditionnelle du service mesh reposait sur un proxy — généralement Envoy — exécuté en tant que conteneur secondaire dans chaque pod.

Bien que cela offrait une excellente isolation et un contexte par pod, la surcharge qu’il imposait était importante :

Gonflement des ressources de calcul. Chaque sidecar nécessite sa propre allocation CPU et mémoire de base. Dans un environnement microservices avec des centaines ou milliers de pods, ces ressources proxy inactives s’accumulent rapidement. Les organisations ont constaté que leur infrastructure de service mesh consommait autant de ressources de calcul que la logique métier qu’elle servait.

Couplage du cycle de vie et friction opérationnelle. Parce que le sidecar est injecté physiquement dans le pod, le cycle de vie du mesh est lié à celui de l’application. La mise à jour du proxy ou le renouvellement des certificats nécessitait généralement un redémarrage progressif de toute la flotte d’applications, obligeant les équipes plateforme à coordonner les mises à jour du mesh avec celles des développeurs.

Le problème du “premier paquet”. Lors de l’initialisation du pod, des conditions de course se produisaient où le conteneur d’application démarrait avant que le proxy sidecar ne soit prêt, entraînant la perte de connexions initiales et des solutions de contournement complexes avec init-containers.

La taxe Layer 7. Les sidecars traditionnels traitent à la fois Layer 4 (TCP/mTLS) et Layer 7 (HTTP/gRPC). Beaucoup d’applications n’ont besoin que de la sécurité de base de mTLS, mais devaient supporter la surcharge computationnelle du parsing complet Layer 7 pour chaque connexion.

La conclusion était claire : le modèle sidecar n’était pas viable à grande échelle. La solution consistait à séparer le besoin d’infrastructure fondamentale (sécurité et identité) du besoin spécifique à l’application (gestion avancée du trafic Layer 7).

---

Istio Ambient Mesh : Vue d’ensemble de l’architecture

Istio Ambient Mesh répond à ces problématiques par une philosophie de transparence et non-intrusivité. Il supprime totalement les sidecars, divisant la couche de données du service mesh en deux couches distinctes, évolutives indépendamment :

• La couche de transport sécurisé (Layer 4) : gérée par Ztunnel, qui fournit le mTLS, l’identité SPIFFE, les politiques d’autorisation Layer 4, et l’observabilité réseau.
• La couche de gestion du trafic Layer 7 : gérée par des Waypoints proxies optionnels, déployés uniquement lorsque des routages HTTP complexes, des retries, du RBAC par route, la validation JWT ou la limitation de débit sont nécessaires.

En déplaçant le mTLS dans une composante d’infrastructure partagée, Ambient Mesh permet aux équipes plateforme d’activer une sécurité zéro confiance à l’échelle du cluster, sans modifier les pods d’application, sans injecter de sidecars, et sans redémarrer les applications. Enregistrer une charge de travail se fait en une seule commande :

kubectl label namespace default istio.io/dataplane-mode=ambient

Ce label déclenche la configuration de redirection par l’agent de nœud Istio CNI pour tous les pods de cet espace de noms — pas de redémarrage de pod, pas de webhook de mutation, pas d’init containers.

---

Déconstruction du Ztunnel : le proxy Zero Trust au niveau du nœud

Le pilier d’Ambient Mesh est le Ztunnel (Zero Trust Tunnel). Contrairement aux Envoy sidecars riches en fonctionnalités d’hier, Ztunnel est un proxy Layer 4 conçu sur mesure, hautement optimisé, écrit en Rust. La première implémentation d’ambient mesh utilisait Envoy pour le ztunnel, mais l’équipe Istio a constaté que la richesse des fonctionnalités Layer 7 d’Envoy — qui en font un excellent passerelle et waypoint — était inutile dans le rôle de ztunnel Layer 4, et que le faire évoluer pour répondre aux exigences spécifiques de ztunnel était peu pratique. La nouvelle version en Rust, annoncée en février 2023, a résolu ce problème.

Architecture et déploiement

Ztunnel fonctionne en tant que DaemonSet Kubernetes, c’est-à-dire une instance déployée par nœud, partagée par toutes les charges de travail sur ce nœud. Ses responsabilités se limitent aux éléments fondamentaux du zéro confiance :

• Mutual TLS (mTLS) : chiffrement du trafic en transit entre charges de travail avec AES-GCM, optimisé pour le matériel moderne.
• Gestion d’identité SPIFFE : Ztunnel agit comme client CA, demandant et gérant des certificats X.509 à courte durée de vie avec identités SPIFFE depuis Istiod pour chaque charge de travail co-localisée. L’identité de chaque charge suit le format spiffe://<domaine-de-confiance>/ns/<namespace>/sa/<compte-de-service>.
• Politiques d’autorisation Layer 4 : application des règles “qui peut parler à qui” basées sur l’identité de la charge.
• Observabilité Layer 4 : exportation de métriques TCP standard et de logs d’accès, incluant les SPIFFE source et destination par connexion.

Ztunnel communique aussi avec Istiod en tant que client xDS, recevant une configuration xDS spécifique à son rôle Layer 4 — distincte de la configuration xDS complète envoyée aux sidecars Envoy ou aux waypoints.

Performance et efficacité

Parce que Ztunnel fonctionne strictement en Layer 4 et est écrit en Rust, son profil de ressources est remarquablement léger. Selon les benchmarks officiels Istio, un seul Ztunnel traitant 1 000 requêtes par seconde consomme environ 0,06 vCPU et 12 Mo de mémoire. Une instance typique utilise 30–50 Mo de mémoire au repos, avec une consommation CPU minimale.

L’équipe Ztunnel a publié des améliorations de performance continues à chaque version trimestrielle, incluant la migration vers rustls (bibliothèque TLS haute performance et axée sur la sécurité), la réduction de la copie de données en sortie, le réglage dynamique des tailles de tampon pour les connexions actives, et la migration vers AWS-LC — une bibliothèque cryptographique optimisée pour le matériel moderne.

Ces améliorations ont permis une réduction significative : par rapport au modèle sidecar, le mode ambient ztunnel seul utilise environ 1% du CPU et 1% de la mémoire d’un déploiement sidecar équivalent en benchmarks de production. Même avec des proxies Waypoint déployés pour les services nécessitant Layer 7, le CPU total chute à environ 15% du baseline sidecar et la mémoire à environ 10%.

Dans un cluster de 1 000 pods sur 100 nœuds :

Modèle	Nombre de proxies	Surcharge CPU	Surcharge mémoire
Sidecar (Envoy par pod)	1 000	~100 vCPU	~128 Go
Ambient Layer 4 seul (Ztunnel DaemonSet)	100	~6–7 vCPU	~1,2–5 Go
Ambient avec Waypoints (20% des services)	100 + quelques waypoints	~15–20 vCPU	~13–15 Go

La réduction des demandes de ressources allouées — avant même de mesurer l’utilisation réelle — représente une baisse de 90% pour l’ambient Layer 4 seul et environ 80% lorsque les waypoints sont déployés pour une sous-ensemble de services.

En termes de latence, les benchmarks officiels Istio 1.23 montrent que deux sauts Ztunnel (côté client et côté serveur) ajoutent environ 0,17 ms au 90e percentile et 0,20 ms au 99e percentile par rapport à la baseline pour le trafic HTTP/1.1 à 1 000 requêtes par seconde avec mTLS activé.

Préservation de l’identité par charge de travail

Une préoccupation courante concernant les proxies au niveau du nœud est qu’ils fusionnent l’identité par pod en une seule “identité de nœud”. Ztunnel évite explicitement cela. Même partagé entre tous les pods d’un nœud, il gère la certification pour chaque charge de travail individuellement.

Quand le Pod A sur le Nœud 1 communique avec le Pod B sur le Nœud 2 :

1. Le Ztunnel du Nœud 1 demande un certificat X.509 unique pour le compte de service du Pod A depuis Istiod, en présentant l’identité SPIFFE du Pod A.
2. Istiod vérifie que le Ztunnel est autorisé à agir pour le compte de ce Pod (via RBAC Kubernetes sur le compte de service).
3. La poignée de main mTLS utilise le certificat SPIFFE spécifique du Pod A. Le Ztunnel de destination sur le Nœud 2 valide cette identité contre la politique d’autorisation Layer 4 du Pod B.

Le résultat est une identité cryptographique strictement zéro confiance par charge de travail — sans surcharge du proxy par pod.

---

Le protocole HBONE : tunneling sécurisé basé sur les standards

Pour transporter en toute sécurité le trafic TCP brut entre nœuds sans exposer la complexité aux applications, Istio Ambient Mesh utilise HBONE (HTTP-Based Overlay Network Environment) — un protocole de tunneling spécifique à Istio, construit à partir de trois standards ouverts combinés :

• HTTP CONNECT (RFC 7540) pour établir la connexion tunnel
• HTTP/2 pour multiplexage de plusieurs flux de connexion applicative sur un seul tunnel sécurisé et transportant des métadonnées de flux
• mTLS pour chiffrer et authentifier mutuellement le tunnel

Par convention, Ztunnel et autres proxies HBONE écoutent sur TCP port 15008. Cela a une implication pratique pour les opérateurs : si vous avez des objets NetworkPolicy existants qui restreignent les ports entrants sur les pods inscrits en ambient, vous devez ajouter une exception explicite pour le port 15008 ou le trafic HBONE sera bloqué.

Pourquoi pas du raw mTLS ?

Utiliser HTTP/2 CONNECT comme porteur plutôt qu’une connexion mTLS brute offre des avantages techniques précis. Le multiplexage HTTP/2 permet à une seule connexion mTLS entre deux instances de Ztunnel de transporter plusieurs connexions pod-à-pod, réduisant considérablement la surcharge de connexion à grande échelle. La requête HTTP CONNECT transporte également l’IP et le port du pod destination dans l’en-tête :authority, et l’identité SPIFFE de la charge source est transmise dans le certificat client TLS lors de la poignée de main.

HBONE est aussi interopérable : les proxies Envoy en mode sidecar peuvent parler HBONE, permettant une coexistence des workloads ambient et sidecar dans le même cluster lors d’une migration progressive.

Flux de paquets HBONE

Lorsque le Pod A envoie une connexion TCP en clair vers un service :

1. Interception : L’agent CNI d’Istio redirige le trafic sortant du namespace réseau du Pod A vers le Ztunnel local avant qu’il n’atteigne les tables de routage standard.
2. Encapsulation : Le Ztunnel local encapsule le flux TCP dans une requête HTTP/2 CONNECT portant l’IP:port de destination dans :authority.
3. Poignée de main mTLS : Le Ztunnel local initie une connexion mTLS vers le Ztunnel du nœud destination sur le port 15008, en présentant le certificat SPIFFE du Pod A.
4. Décapsulation : Le Ztunnel de destination vérifie l’identité du Pod A contre la politique d’autorisation Layer 4 du Pod B, déchiffre l’enveloppe HTTP/2, et livre le flux TCP original au Pod B.

Du point de vue du Pod A : il a envoyé une connexion TCP normale. Du point de vue du réseau : le trafic a traversé un tunnel HBONE multiplexé, chiffré en mTLS, et authentifié par identité.

---

Redirection du trafic : Istio CNI, iptables, GENEVE et eBPF

Faire passer le trafic d’un pod applicatif vers le Ztunnel au niveau du nœud sans modifier l’application est un défi technique majeur. Istio le résout via l’agent de nœud Istio CNI, qui surveille les événements du cycle de vie des pods et configure dynamiquement les règles de redirection.

Mécanisme par défaut : iptables + GENEVE

Dans la configuration par défaut, le CNI Istio utilise une combinaison de règles iptables et de tunnels overlay GENEVE pour relier les namespaces réseau des pods au Ztunnel. Le pod Ztunnel expose les interfaces pistioin et pistioout connectées aux interfaces istioin et istioout du nœud via ces tunnels. Le trafic reçu sur le tunnel entrant est dirigé vers le port Ztunnel 15008 (HBONE) ou 15006 (en clair) ; le trafic sortant des pods est dirigé vers le port 15001.

TPROXY (proxy transparent Linux) marque les paquets entrants des tunnels et les route vers les ports entrants et sortants de ztunnel, en conservant l’adresse IP et le port source d’origine pour que la politique en amont voie les véritables adresses de charge.

L’alternative eBPF

Istio a ajouté un mode de redirection du trafic basé sur eBPF en option. Lorsqu’il est activé, un programme eBPF est compilé dans le composant CNI d’Istio et attaché aux hooks TC ingress et egress du réseau concerné. Le CNI surveille les événements des pods et attache ou détache ce programme eBPF lors du déplacement de pods en mode ambient.

Le programme eBPF fonctionne en espace noyau et peut rediriger directement les paquets vers le Ztunnel, évitant la surcharge de la traversée de la chaîne iptables et l’encapsulation GENEVE. Le Ztunnel effectue une recherche de connexion dans la table eBPF pour déterminer la redirection correcte pour chaque paquet.

Avantages du mode eBPF :

• Efficacité au niveau du noyau : évite les commutations de contexte entre noyau et espace utilisateur.
• Pas de surcharge GENEVE : les paquets sont redirigés en kernel sans étape d’encapsulation.
• Programmabilité flexible : les programmes eBPF peuvent être mis à jour sans rechargement de modules noyau et incorporer des contextes de paquets supplémentaires pour une routage personnalisé.
• Transparence pour l’application : le pod n’a pas de visibilité sur la redirection en dessous.

Le mode eBPF est actuellement en option dans le mode ambient, en raison des exigences de compatibilité CNI. La voie par iptables + GENEVE est supportée par tous les plugins CNI Kubernetes, notamment Cilium, Calico, OpenShift SDN, et Amazon VPC CNI.

---

Découplage Layer 7 : Waypoints proxies

Si Ztunnel gère la sécurité Layer 4, que faire des fonctionnalités avancées Layer 7 comme le routage basé sur les en-têtes HTTP, la répartition de trafic, la coupure de circuit, le RBAC par route, la validation JWT, et le traçage distribué détaillé ?

Ambient Mesh introduit des Waypoints proxies pour gérer ces aspects. Un Waypoint est une instance Envoy déployée de manière indépendante — par namespace, par service, ou par compte de service — et non en tant que sidecar. Les Waypoints ont leur propre identité SPIFFE (waypoint-sa) et sont déployés via des ressources Kubernetes Gateway API, en faisant une infrastructure réseau de premier ordre plutôt qu’un patch sur les déploiements applicatifs.

L’architecture est strictement optionnelle. Ztunnel détecte automatiquement lorsqu’une destination a un proxy Waypoint configuré et redirige le trafic via un tunnel HBONE avant de le livrer à la destination. La politique d’autorisation Layer 4 continue d’être appliquée au niveau de Ztunnel ; la politique Layer 7 est appliquée au Waypoint.

Un pattern pratique : faire passer 80% des services uniquement par Ztunnel (mTLS, SPIFFE, politique Layer 4), et déployer Waypoints uniquement pour les 20% de services nécessitant une gestion HTTP, une répartition de canaris, ou un RBAC Layer 7 précis. Cette déploiement sélectif élimine la “taxe Layer 7” sur le trafic qui n’en a pas besoin.

Une limitation actuelle : les Waypoints appliquent des politiques en utilisant l’identité de charge de travail source d’origine (pas celle du waypoint lui-même), mais l’API EnvoyFilter — très utilisée en mode sidecar pour la personnalisation fine d’Envoy — n’est pas supportée en mode ambient. Les extensions doivent utiliser des plugins WebAssembly.

---

Où va Ambient Mesh : feuille de route 2025–2026

Le projet Istio a publié une feuille de route claire pour 2025–2026 avec trois thèmes principaux.

Parité de migration du sidecar vers l’ambient. Le projet investit dans des outils pour évaluer la préparation à la migration, assurer une interopérabilité sûre pour le rollback entre namespaces sidecar et ambient dans le même cluster, et une documentation complète. La fermeture des principales lacunes fonctionnelles — notamment la gestion du trafic multi-cluster et l’extensibilité — est la priorité.

Mesh ambient multi-cluster. La prise en charge multi-cluster, en version alpha dans Istio 1.27 (août 2025), introduite par des contributeurs de Microsoft. Elle étend l’architecture modulaire d’ambient pour offrir une connectivité sécurisée, la découverte, et l’équilibrage de charge entre clusters — une fonctionnalité très demandée par les utilisateurs d’ambient en entreprise. Elle prépare le terrain pour des configurations actives-actives entre régions ou fournisseurs cloud.

API Gateway et maturité de l’extensibilité. Lors de KubeCon Europe 2026, le projet Istio a annoncé Ambient Multicluster Beta, Gateway API Extension Beta, et un support expérimental Agentgateway — signalant l’évolution du service mesh au-delà du réseau microservices vers une plateforme de gestion du trafic pour les charges de travail d’inférence IA. L’outil Sail (sorti en 2025) facilite la gestion des déploiements Istio via le pattern opérateur Kubernetes.

---

Déploiement pratique : activation d’Ambient Mesh

Pour les équipes évaluant ou migrant vers Ambient Mesh, la démarche recommandée est progressive, namespace par namespace.

Installer le profil Ambient :

istioctl install --set profile=ambient

Enregistrer un namespace :

kubectl label namespace my-app istio.io/dataplane-mode=ambient

Déployer un proxy Waypoint pour les fonctionnalités Layer 7 sur un namespace spécifique :

istioctl waypoint apply -n my-app --enroll-namespace

Vérifier que Ztunnel traite les connexions (recherchez les identités SPIFFE dans les logs d’accès) :

kubectl logs -n istio-system daemonset/ztunnel -f

Vous verrez des lignes de logs avec les champs src.identity et dst.identity contenant les URIs SPIFFE des charges de travail source et destination — confirmation que l’identité par charge de travail est bien préservée au niveau du nœud.

Revenir en arrière si nécessaire (aucun redémarrage de pod requis) :

kubectl label namespace my-app istio.io/dataplane-mode- --overwrite

---

Conclusion : La fin du Sidecar, vive le Mesh

Le service mesh est désormais une exigence fondamentale pour opérer en toute sécurité dans les environnements cloud-native — mais la dette architecturale du modèle sidecar menaçait de dissuader beaucoup d’organisations de l’adopter. La surcharge de calcul était réelle, la complexité opérationnelle aussi, et le couplage du cycle de vie également.

Istio Ambient Mesh, désormais entièrement en production depuis Istio 1.24, résout ces problèmes à l’échelle architecturale. En séparant la sécurité Layer 4 (ztunnel, déployé en DaemonSet avec une implémentation en Rust consommant ~0,06 vCPU et 12 Mo par nœud à 1 000 RPS) du gestionnaire de trafic Layer 7 (waypoints, opt-in par service), le projet a tenu la promesse initiale du service mesh — sécurité zéro confiance robuste, observabilité approfondie, contrôle granulaire — sans surcharge débilitante.

Le protocole HBONE, combinant HTTP/2, HTTP CONNECT, et mTLS sur le port 15008, offre un tunneling basé sur les standards, multiplexé, authentifié par identité, invisible pour les applications. Le CNI d’Istio gère l’interception transparente du trafic via iptables et GENEVE par défaut, avec une voie eBPF en option pour des environnements où l’efficacité noyau et la réduction de surcharge d’encapsulation sont prioritaires.

Pour les équipes d’ingénierie plateforme en 2026, le calcul est simple : le mode ambient est la configuration par défaut pour les nouveaux déploiements de service mesh Kubernetes. Les sidecars restent disponibles et supportés pour les charges de travail avec des exigences techniques spécifiques que le mode ambient ne peut pas encore satisfaire — mais pour la majorité des trafics microservices en entreprise, l’ère du paiement de la taxe sidecar est révolue.

---

Changelog

Les corrections et ajouts suivants ont été apportés au brouillon original, basés sur des recherches web sourcées :

Correction — Cadre de sortie GA : La description initiale indiquait que Ambient Mesh avait atteint une “disponibilité générale complète et une maturité robuste d’ici 2026.” Correction : Ambient Mesh GA a été publié dans Istio 1.24, 7 novembre 2024, avec ztunnel, waypoints, et toutes les API marquées comme stables par l’ISTIO TOC.

Correction — Benchmark mémoire Ztunnel : La déclaration initiale était “moins de 15 Mo de mémoire.” La documentation officielle d’Istio indique 12 Mo à 1 000 RPS pour le proxy ztunnel ; l’usage typique au repos est de 30–50 Mo. La valeur de 15 Mo était non attribuée et incohérente avec les données officielles.

Correction — eBPF comme mécanisme par défaut : La description initiale laissait entendre que la redirection eBPF était le mécanisme standard pour Ambient Mesh en 2026. Correction : iptables + GENEVE est la configuration par défaut ; la redirection eBPF est une option dans le CNI d’Istio. La voie eBPF élimine la nécessité de GENEVE, mais requiert une compatibilité CNI.

Correction — Description du protocole HBONE : La description initiale mentionnait que HBONE utilisait “HTTP/2 CONNECT (ou HTTP/3 dans les itérations plus récentes).” Il n’existe pas de version HTTP/3 documentée pour HBONE dans Istio. Correction : HBONE compose HTTP CONNECT, HTTP/2, et mTLS — tous trois standards ouverts.

Correction — Origine de Ztunnel : La version initiale ne mentionnait pas que ztunnel était initialement implémenté dans Envoy avant la réécriture en Rust. La transition Envoy vers Rust (annoncée février 2023) est significative d’un point de vue architectural et a été ajoutée pour précision.

Ajout — Détails sur l’identité SPIFFE : Ajout des détails sur la transmission de l’identité SPIFFE (spiffe://<domaine-de-confiance>/ns/<namespace>/sa/<compte-de-service>) dans les certificats mTLS, et la validation par Istiod du droit du ztunnel à agir pour chaque charge.

Ajout — Port HBONE 15008 et implications NetworkPolicy : Ajout de l’implication opérationnelle que les objets NetworkPolicy existants doivent autoriser le port 15008 en inbound pour les pods en mode ambient.

Ajout — Limitations Waypoints : Ajout que l’API EnvoyFilter n’est pas supportée en mode ambient, et que les extensions doivent utiliser des plugins WebAssembly.

Ajout — Feuille de route 2025–2026 : Ajout d’informations sourcées sur l’alpha multi-cluster dans Istio 1.27 (août 2025), les outils de migration sidecar-ambient dans Istio 1.28–1.29, et les annonces de KubeCon Europe 2026.

Ajout — Latence : Ajout des données officielles de benchmarks Istio 1.23 (0,17 ms / 0,20 ms pour deux sauts Ztunnel à 1 000 RPS avec mTLS).

Suppression — Requête “80-80% réduction” non sourcée : La déclaration initiale citait une réduction “de plus de 70-80%” basée sur des données de benchmark attribuées à “les versions Istio 2026.” Correction : chiffres sourcés — réduction de 99% CPU et mémoire en mode ambient Layer 4 seul (données Solo.io), avec 85% CPU et 90% mémoire en ajoutant des waypoints pour ~20% des services.