Killing the Sidecar: Migration vers des maillages de services sans sidecar via Ambient Networking

Running an Envoy sidecar inside every single Kubernetes pod is a massive waste of cloud spend. Ambient networking splits Layer 4 and Layer 7 processing at the node level, eliminating sidecar overhead while preserving zero-trust encryption. Here is the full architectural picture, grounded in current benchmarks and the Istio release history through 1.30.

---

La taxe du Sidecar : pourquoi le modèle classique dépasse le budget cloud

L’évolution de l’architecture cloud-native a été définie par le découplage : applications des serveurs physiques via des machines virtuelles, dépendances d’exécution via des conteneurs, et logique réseau du code applicatif via le service mesh. Depuis des années, la norme industry pour ce dernier découplage est le modèle proxy sidecar—popularisé notamment par Istio.

Ce modèle injecte un conteneur proxy Envoy dans chaque pod d’application. Le proxy intercepte tout le trafic entrant et sortant, gère le chiffrement mutual TLS (mTLS), la télémétrie, le routage du trafic, et les politiques d’autorisation. L’abstraction est propre. Le coût, lui, ne l’est pas.

Avec la montée en échelle des déploiements Kubernetes, passant de dizaines à des milliers de microservices, un défaut croissant du modèle sidecar devient impossible à ignorer : vous faites tourner un processus Envoy complet pour chaque pod du cluster. Ce coût se répartit sur trois axes distincts.

1. Gonflement des ressources et dépenses cloud

Envoy est un proxy performant, mais il nécessite une allocation CPU et mémoire dédiée. Dans Kubernetes, chaque conteneur doit déclarer ses demandes et limites de ressources. À 1 000 pods, vous gérez 1 000 cycles de vie de proxy Envoy.

Parce que les pics de trafic sont imprévisibles, les équipes plateforme doivent provisionner des sidecars pour la charge maximale. Si un sidecar requiert 0.2 vCPU et 64 Mo de RAM pour gérer le trafic de pointe en toute sécurité, un cluster de 2 500 pods réserve 500 vCPU et 160 Go de RAM rien que pour la plomberie réseau. Dans de nombreux environnements d’entreprise, le plan de données du mesh consomme plus de ressources que la logique métier qu’il supporte.

2. Le cauchemar opérationnel de la gestion du cycle de vie

Puisque le sidecar est co-localisé dans le même pod que l’application, leurs cycles de vie sont liés. Patché une CVE dans Envoy ou mis à jour la version du mesh nécessite un redémarrage progressif de chaque pod d’application. Cela viole un principe fondamental de l’infrastructure : les changements réseau ne doivent pas provoquer de redémarrages d’application.

Ce couplage introduit aussi des conditions de course lors du démarrage du pod. Si le conteneur d’application s’initialise avant que le proxy sidecar ne soit prêt à router le trafic, les requêtes échouent, des boucles de crash se produisent, et les pipelines CI/CD se bloquent. Les jobs Kubernetes sont particulièrement problématiques : un sidecar injecté qui ne se termine jamais peut empêcher le Pod du Job de se compléter, le laissant orphelin indéfiniment.

3. La pénalité « tout ou rien » en calcul

Les sidecars traditionnels confondent la sécurité Layer 4 (L4) avec le routage Layer 7 (L7). Même si un microservice n’a besoin que du chiffrement mTLS et n’a aucune exigence pour les retries HTTP, la manipulation des en-têtes, ou le division du trafic, chaque paquet passant par le sidecar paie quand même le coût du parsing HTTP complet L7. Il n’y a pas d’option pour se désengager.

---

Introduction au plan de données Ambient Networking

La réponse architecturale à ces problèmes est le Mode Ambient d’Istio, annoncé en septembre 2022 et devenu disponible en Istio 1.24 le 7 novembre 2024. Lors de la sortie GA, l’image ztunnel, les waypoints, et toutes les API associées ont été marquées comme Stables par le Comité de supervision technique d’Istio, signalant leur maturité pour la production. La version ztunnel sur Docker Hub avait dépassé 1 million de téléchargements à cette date, avec environ 63 000 téléchargements la semaine précédant la sortie.

L’idée centrale derrière le plan de données ambient est une séparation claire des préoccupations : la sécurité de base (L4) est une propriété ubiquitaire et invisible de l’infrastructure, tandis que le réseau applicatif avancé (L7) est appliqué strictement sur une base volontaire. Pour atteindre cette séparation, il faut retirer complètement le proxy du pod d’application et le remplacer par deux nouveaux composants : le Ztunnel (pour L4) et le Waypoint Proxy (pour L7).

---

Ztunnel : Maîtriser la sécurité du transport au niveau du noyau Layer 4

Le Ztunnel (Zero Trust Tunnel) est la pierre angulaire du maillage de services sans sidecar. C’est un proxy dédié, écrit en Rust, conçu spécifiquement pour la sécurité mémoire, la rapidité, et une empreinte ressources ultra-faible.

Ztunnel est déployé en tant que DaemonSet Kubernetes. Une instance tourne sur chaque nœud, quel que soit le nombre de pods hébergés. Selon la documentation officielle de performance d’Istio, un seul proxy ztunnel à 1 000 requêtes par seconde consomme environ 0.06 vCPU et 12 Mo de mémoire en charge stable. Ce profil de faible consommation est une contrainte significative : en haute densité de pods, ztunnel bénéficie du multiplexage statistique entre tous les pods du nœud, et la consommation mémoire réelle en trafic mixte se situe généralement entre 30 et 50 Mo selon la configuration.

Ztunnel fonctionne strictement aux couches OSI 3 et 4. Il ne parse pas les requêtes HTTP, ne lit pas les payloads JSON, et ne réalise pas de division de trafic. Ses responsabilités se limitent à :

• Établir et terminer les connexions mTLS pour les pods.
• Appliquer les politiques d’autorisation réseau L4 (ex. “Service A peut atteindre Service B sur le port 8080”).
• Émettre des métriques de télémétrie TCP de base.

Comment le trafic atteint Ztunnel sans sidecar

Le mécanisme permettant une interception transparente a évolué au cours du cycle de release 1.x. Le mode par défaut dans les versions actuelles d’Istio utilise la redirection dans le pod : l’agent CNI d’Istio sur le nœud fournit l’espace de noms réseau du pod au ztunnel co-localisé, qui démarre alors ses sockets de redirection dans cet espace tout en fonctionnant en dehors du pod. La redirection du trafic entre ztunnel et le pod d’application est donc invisible pour tout CNI principal de Kubernetes opérant dans l’espace de noms réseau du nœud—Cilium, Calico, Flannel, et les implémentations CNI internes utilisées par OpenShift et Amazon EKS cohabitent sans conflit.

Une ancienne méthode utilisait des règles iptables combinées à des tunnels overlay GENEVE. Cela nécessitait de marquer et rediriger le trafic dans l’espace de noms réseau du nœud, ce qui entravait la compatibilité avec de nombreux CNIs tiers. La méthode actuelle, introduite pour assurer une compatibilité universelle avec CNI avant la version Beta, a résolu cette contrainte fondamentale de portabilité.

Une mode redirection eBPF optionnelle est aussi disponible via la valeur Helm redirectMode: "ebpf". La mise en marche nécessite un noyau version 4.20 ou supérieur et élimine la nécessité d’encapsulation GENEVE, offrant des améliorations mesurables en latence et débit par rapport à la voie iptables. La redirection eBPF est en option ; la configuration par défaut reste iptables + livraison dans l’espace de noms du pod. Les équipes plateforme avec des exigences de compatibilité CNI ou utilisant des noyaux plus anciens devraient rester sur la configuration par défaut.

Quel que soit le mécanisme de redirection, le chemin du trafic une fois ztunnel en possession du paquet est le suivant :

1. Le pod source envoie un paquet TCP standard.
2. L’agent CNI d’Istio redirige le paquet dans ztunnel local.
3. Ztunnel identifie le pod source, récupère son SPIFFE X.509 SVID, et encapsule le trafic en utilisant HBONE (HTTP-Based Overlay Network Environment)—HTTP/2 CONNECT sur mTLS au port 15008.
4. Le paquet est tunnellisé vers ztunnel sur le nœud de destination.
5. Le ztunnel de destination déchiffre, valide les politiques, et livre le paquet au pod de destination.

Pour l’application, le réseau apparaît comme une connexion locale simple. En réalité, le trafic est entièrement chiffré et mutuellement authentifié au niveau du nœud.

2424 Note opérationnelle : Les objets NetworkPolicy existants dans les namespaces inscrits à l’ambient doivent autoriser le port 15008 en entrée pour le trafic HBONE afin que ztunnel de destination puisse recevoir le trafic. C’est une erreur courante lors de la migration.

Gestion cryptographique SPIFFE

Ztunnel gère les identités SPIFFE pour tous les pods sur son nœud. Lorsqu’un pod est inscrit dans le mesh ambient, ztunnel demande un SVID X.509 à Istiod pour le compte de ce pod. Ztunnel détient donc plusieurs identités distinctes simultanément—une par compte de service sur le nœud.

Les identités suivent le format SPIFFE standard d’Istio :

spiffe://<domaine-de-confiance>/ns/<namespace>/sa/<compte-de-service>

L’ID SPIFFE est intégré dans le champ Subject Alternative Name du certificat X.509, s’intégrant directement à l’authentification TLS mutuelle. La CA interne d’Istiod émet et renouvelle ces certificats automatiquement ; pour les entreprises nécessitant une gouvernance PKI centralisée, Istiod supporte la délégation à une déploiement SPIRE externe.

Lorsqu’un pod initie une connexion, la gestion de l’espace de noms réseau par CNI garantit que ztunnel connaît l’identité exacte du pod source—qui ne peut pas être usurpée. Le SVID sélectionné pour ce pod initie la poignée de main mTLS, et le ztunnel de destination vérifie l’identité avant de livrer le trafic. Il s’agit d’une authentification cryptographique par charge de travail au niveau du nœud ; la mobilité latérale d’un pod compromis reste cryptographiquement bloquée même si les deux pods résident sur le même hôte physique.

---

Waypoint Proxies : Découpler le traitement Layer 7

Pour la majorité du trafic interne east-west dans le cluster, la couverture mTLS L4 de ztunnel est suffisante. Certains services nécessitent une logique Layer 7 : routage basé sur les en-têtes HTTP, déploiements canary, circuit breaker, limitation de débit, ou extensions WebAssembly. Dans un mesh traditionnel, chaque pod supporte ce coût L7, peu importe. Dans le plan de données ambient, le L7 est géré exclusivement par des Waypoint Proxies.

Les waypoints sont des proxies Envoy standard déployés en dehors des pods d’application, généralement un par namespace ou par compte de service. Ils évoluent indépendamment de l’application et ne sont nécessaires que pour les services qui requièrent réellement des capacités L7.

Lorsqu’un service est configuré pour utiliser un waypoint, le chemin complet du trafic est :

1. Le pod source émet un paquet.
2. Le ztunnel du nœud source intercepte, attache l’identité SPIFFE source, et encapsule en HBONE.
3. Le trafic est routé vers le Waypoint Proxy assigné au service de destination.
4. Le waypoint termine le tunnel HBONE, inspecte les en-têtes HTTP, applique la politique L7 (ex. 10% du trafic vers un canary v2), ré-encrypte, et forwarde.
5. Le trafic arrive au ztunnel du nœud de destination.
6. Le ztunnel de destination livre le paquet au pod de destination.

En rendant le L7 explicite et en option, les équipes plateforme peuvent appliquer des waypoints uniquement aux services qui ont réellement besoin de logique HTTP et laisser le reste en surcoût L4 pur.

Modèle d’extension : WasmPlugin et TrafficExtension API

Une contrainte importante à connaître avant migration : l’API EnvoyFilter n’est pas supportée pour les proxies waypoint. EnvoyFilter reste en statut Alpha après des années d’usage en production en mode sidecar, principalement parce que sa forte dépendance à la structure interne xDS d’Envoy le rend fragile lors des mises à jour. Les mainteneurs n’ont pas déployé cette API en mode ambient.

Les extensions pour waypoints doivent utiliser des plugins WebAssembly (Wasm). En Wasm, la logique d’authentification personnalisée, la télémétrie spécialisée, ou la transformation des requêtes/réponses peuvent être chargées dynamiquement dans le waypoint à l’exécution, sans reconstruire le binaire du proxy. L’API WasmPlugin est le mécanisme actuel ; TrafficExtension—une API unifiée supportant à la fois Wasm et Lua pour sidecars, gateways, et waypoints—est en Alpha dans Istio 1.30 (mai 2026) et constitue la voie future.

Les équipes avec de lourds investissements dans EnvoyFilter doivent considérer la migration vers Wasm comme une priorité dans leur plan d’adoption ambient.

---

Optimisation du proxy au niveau du nœud : Impact économique

Le calcul de la migration du modèle sidecar par pod vers le ztunnel par nœud est simple, et les chiffres se vérifient en pratique. La documentation Istio et les premiers utilisateurs rapportent systématiquement des économies de 70% à 90% ou plus en surcharge de calcul du plan de données.

Considérons un cluster avec 50 nœuds de travail et 2 500 pods microservices.

Modèle Sidecar :

• 2 500 proxies Envoy, chacun provisionné pour la charge maximale.
• À 0.2 vCPU réservé par sidecar : 500 vCPU consommés par le plan de données du mesh.

Modèle Ambient :

• 50 instances de ztunnel (une par nœud) à environ 0.06–1 vCPU chacune selon la densité de trafic, bénéficiant du multiplexage statistique.
• Waypoints déployés pour 10–20% des services nécessitant du L7 ; à 10 instances, environ 1 vCPU chacune.
• Surcoût total du plan de données : environ 60–100 vCPU.

C’est une réduction de 80–88% du calcul dédié à la plomberie réseau. Dans les environnements cloud où les vCPU-heure se traduisent directement en coût, ces économies à l’échelle enterprise sont significatives.

L’histoire de la latence est tout aussi favorable. Les benchmarks de performance officiels d’Istio (mesurés sur le CNCF Community Infrastructure Lab à 1 000 RPS, 1 Ko de payload, HTTP/1.1, TLS mutuel activé) montrent que les deux sauts ztunnel d’un chemin L4 ambient ajoutent 0.17 ms à P90 et 0.20 ms à P99 par rapport à la latence de base du plan de données. Une étude peer-reviewed (arXiv:2411.02267) indique qu’Istio Ambient n’augmente la latence que de 8% à 3 200 RPS—le meilleur résultat parmi toutes les implémentations de mesh testées—alors que le mode sidecar traditionnel produisait une augmentation de 166% à la même charge, et ne pouvait pas atteindre 12 800 RPS.

L’utilisation de HTTP/2 pour le tunnel HBONE introduit environ 12% de latence supplémentaire par rapport à une connexion TLS brute en scénarios à connexion unique, une surcharge que le projet Istio suit activement pour réduire. Pour les charges multi-connexion à grande échelle, les gains de multiplexage statistique du proxy partagé au niveau du nœud dominent, et le profil de latence net est meilleur qu’en mode sidecar pour la majorité des trafics de production réalistes.

---

Redéfinir la sécurité : réponse à l’objection du proxy partagé

Une préoccupation courante lors de l’adoption d’un mesh sans sidecar est l’idée que le sidecar—isolé dans l’espace de noms réseau du pod—est plus sécurisé qu’un ztunnel partagé desservant plusieurs pods sur le même nœud. En pratique, le mode ambient maintient, et dans plusieurs cas améliore, la posture zero-trust du cluster.

L’isolation cryptographique est préservée. Ztunnel détient des SVID X.509 distincts pour chaque compte de service sur le nœud. La redirection dans le pod garantit que ztunnel connaît l’identité exacte du pod source avant de choisir le certificat correspondant pour la poignée de main mTLS. Il n’y a aucune situation où le pod A peut usurper l’identité du pod B, même si les deux résident sur le même hôte physique.

L’API d’administration Envoy est exempte de surface d’attaque. En mode sidecar, un conteneur d’application compromis a un accès localhost à l’API d’administration d’Envoy—un vecteur d’escalade bien connu. En mode ambient, le proxy n’est plus co-localisé dans le pod. Une application compromise n’a pas de proxy local à attaquer.

La sécurité mémoire de Rust élimine toute une classe de vulnérabilités. Ztunnel est écrit en Rust, ce qui élimine les débordements de tampon et les bugs use-after-free au niveau du langage. Le projet Istio a explicitement choisi Rust pour cette raison : le proxy contenant tout le matériel cryptographique sur le nœud doit être mémoire-safe.

L’intégration existante de NetworkPolicy reste inchangée. Ztunnel chiffre et authentifie le trafic au niveau du mesh. NetworkPolicy standard de Kubernetes continue de fonctionner au niveau du CNI, appliquant les contrôles de frontière réseau sans conflit. Calico, Cilium, et autres CNIs avec inspection approfondie des paquets continuent de fonctionner aux côtés de ztunnel plutôt que d’être remplacés.

---

Migration : à quoi ressemble réellement le changement opérationnel

Le chemin de migration en mode Ambient d’Istio est conçu pour être non disruptif. Inscrire un namespace dans le mesh ambient nécessite une seule étiquette :

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

L’agent CNI d’Istio détecte cette étiquette, configure la redirection dans le pod pour tous les nouveaux pods de ce namespace, et commence à router le trafic via le ztunnel du nœud. Les pods d’application ne redémarrent pas. Les connexions TCP ne sont pas interrompues. La mise à jour vers le mTLS strict est instantanée et transparente.

La mise à jour du mesh lui-même se découple totalement du cycle de vie des applications. Pour déployer une nouvelle version de ztunnel, les opérateurs mettent à jour le DaemonSet—nœud par nœud, avec une mise à jour progressive standard—sans toucher aux pods d’application. Les waypoints sont des Deployments Kubernetes classiques, mis à jour comme n’importe quel autre Deployment. L’infrastructure réseau n’est plus sous la responsabilité du développeur.

Migration depuis le mode Sidecar

La feuille de route 2025–2026 du projet Istio donne la priorité à la migration sidecar-vers-ambient : outils pour évaluer la préparation à la migration, interopérabilité sûre pour le rollback entre namespaces sidecar et ambient dans le même cluster, et documentation complète. Le mode sidecar n’est pas déprécié—les mainteneurs ont explicitement engagé un support continu—mais l’investissement opérationnel se concentre désormais clairement sur la voie ambient.

Les principales étapes pré-migration pour les équipes avec des déploiements sidecar existants :

• Auditer l’utilisation d’EnvoyFilter. Tous les filtres doivent être réécrits en plugins Wasm avant de désactiver l’injection sidecar. L’API TrafficExtension (Istio 1.30 Alpha) est la cible future.
• Valider la compatibilité CNI. La redirection dans le pod fonctionne avec tous les CNIs majeurs comme Cilium et Calico, mais vérifier avec votre version spécifique.
• Vérifier l’utilisation de VirtualService. VirtualService en mode ambient est Alpha et ne peut pas être combiné avec des ressources Gateway API. Les services utilisant VirtualService pour la gestion du trafic doivent migrer vers HTTPRoute (Gateway API) avant ou pendant la transition.
• Mettre à jour NetworkPolicy pour le port 15008. Le trafic HBONE doit être autorisé en entrée sur le port 15008 pour tous les pods inscrits à l’ambient.

---

La feuille de route d’Istio Ambient : 2025 et au-delà

Le déploiement en mode ambient s’est considérablement étoffé depuis la sortie GA 1.24 :

Istio 1.27 (août 2025) : Multicluster ambient en Alpha. Connectivité sécurisée inter-cluster, découverte de services, et équilibrage de charge disponibles avec l’architecture ztunnel + waypoint, permettant des configurations actives-actives multi-cluster et multi-régions.

Istio 1.28 (novembre 2025) : Waypoints capables de router vers des réseaux distants en configuration multicluster. Politiques L7 incluant détection d’anomalies s’appliquant aux requêtes inter-réseaux. Support natif nftables ajouté comme alternative à iptables pour la gestion des règles réseau en mode ambient.

Istio 1.29 (février 2026) : Multicluster multi-réseaux en Beta, avec une télémétrie améliorée entre clusters distribués. HBONE enrichi avec des headers de baggage pour transporter la métadonnée peer à travers les gateways east-west, permettant des métriques L7 précises en topologies multi-clusters. La problématique de taille de fenêtre HTTP/2 affectant les workloads à haut débit a aussi été résolue.

Istio 1.30 (mai 2026) : Quatre CVEs corrigés, notamment une fuite de clé RSA de fallback JWKS (CVE-2026-31837) et une exposition non authentifiée de l’endpoint debug XDS (CVE-2026-31838). L’API TrafficExtension en Alpha, unifiant la configuration des extensions Wasm et Lua pour sidecars, gateways, et waypoints. Agentgateway—un nouveau composant de plan de données pour le routage des workloads d’inférence AI—a été introduit en expérimental. La nécessité d’authentification pour le débogage XDS est devenue obligatoire, et les permissions du fichier de configuration CNI ont été renforcées à 0600.

KubeCon EU 2026 (Amsterdam, mars 2026) : CNCF annonce la version Beta du multicluster Istio ambient, la Beta de l’extension Gateway API Inference (pour le routage intelligent de modèles AI), et l’intégration expérimentale d’agentgateway. La position est claire : Istio est désormais considéré comme une infrastructure pour les workloads Kubernetes de l’ère AI, avec 66% des organisations utilisant déjà l’IA générative sur Kubernetes selon CNCF.

---

Conclusion : L’avenir est ambient

Le proxy sidecar a été une étape nécessaire et réellement importante dans l’évolution du networking cloud-native. Il a prouvé que les architectures zero-trust étaient viables à grande échelle et a enseigné à l’industrie comment découpler l’intelligence réseau du code applicatif. Mais le coût en ressources, la friction opérationnelle, et le couplage du cycle de vie sont devenus des problèmes structurels que le modèle sidecar ne peut plus résoudre.

La transition vers un maillage de services sans sidecar via un plan de données ambient représente la maturité du concept de mesh de services. En déployant des ztunnels en Rust, mémoire-safe, en tant que proxies partagés par nœud Layer 4, et en isolant Envoy en waypoint pour la logique Layer 7 à la demande, les organisations obtiennent simultanément : une surface d’attaque plus petite et plus défendable, un cycle de vie du mesh réellement invisible pour les équipes applicatives, et une réduction concrète de 70 à 90% de la surcharge de calcul dédiée à l’infrastructure réseau.

La sortie GA du projet Istio en novembre 2024, la version multicluster en Beta début 2026, et la roadmap active jusqu’à 1.30 indiquent que ce n’est plus une infrastructure expérimentale. Pour les nouvelles déploiements, le mode ambient est la configuration par défaut. Pour les équipes avec des déploiements sidecar à grande échelle, les outils de migration et les garanties d’interopérabilité sont suffisamment matures pour commencer à planifier la transition dès maintenant.

Il est temps de tuer le sidecar et de laisser le réseau devenir ambient.

---

Changelog

#	Section	Changement
1	Tout le document	Suppression de l’en-tête de métadonnées (sous-titre / bloc de description).
2	Introduction	Correction du framing GA : mode ambient en GA dans Istio 1.24 le 7 novembre 2024 avec ztunnel, waypoints, et toutes les API marquées comme Stables par le TOC d’Istio—pas “d’ici 2026” comme certains brouillons l’ont laissé entendre. Ajout du jalon de téléchargement Docker Hub (1M+ téléchargements, ~63k/semaine à GA).
3	Taxe du Sidecar §2	Ajout du problème des Jobs Kubernetes / pods orphelins comme mode de défaillance du cycle de vie, provenant de l’annonce officielle du mode ambient CNCF.
4	Ztunnel §resource	Correction de la référence mémoire : les docs de performance officiels d’Istio indiquent 12 Mo à 1 000 RPS et une utilisation typique de 30–50 Mo. Suppression du chiffre non attribué “moins de 15 Mo”. Ajout du chiffre précis de vCPU de 0.06 par instance ztunnel selon la documentation officielle de performance d’Istio.
5	Interception du trafic	Correction et expansion de la section mécanisme de redirection. Remplacement par une description précise : le mode par défaut est livraison dans l’espace de noms du pod via iptables ; eBPF est une alternative en option nécessitant un noyau ≥4.20 ; l’ancien mode overlay GENEVE n’est plus utilisé en configuration par défaut. Sources : blog Istio janvier 2024 et docs préliminaires 1.29.
6	HBONE	Ajout du port HBONE (15008) et de l’implication pratique pour NetworkPolicy : les pods en mode ambient doivent autoriser le port 15008 en entrée.
7	SPIFFE	Ajout du format explicite d’ID SPIFFE spiffe://<domaine-de-confiance>/ns/<namespace>/sa/<compte-de-service>, du mécanisme SVID X.509, et du modèle de certificat par compte de service d’Istiod. Sources : docs d’intégration Istio SPIRE et documentation du framework SPIFFE.
8	Limitations des Waypoints	Ajout de la limitation EnvoyFilter (non supporté pour les proxies waypoint), Wasm/TrafficExtension comme voie d’extension, avertissement sur l’Alpha VirtualService, et comportement de sécurité en cas de politique L7 (politiques L7 appliquées via workload selector deviennent des politiques DENY).
9	Benchmarks	Remplacement des chiffres de latence illustratifs par des données officielles Istio 1.22⁄1.23 : P90 = 0.17 ms, P99 = 0.20 ms pour deux sauts ztunnel à 1 000 RPS avec mTLS. Ajout d’une étude peer-reviewed (arXiv:2411.02267) montrant que Istio Ambient n’augmente la latence que de 8% à 3 200 RPS, contre 166% pour le mode sidecar traditionnel. Ajout de la surcharge HTTP/2 HBONE (~12%) issue du ticket GitHub #1476.
10	Économies de calcul	Ajustement de l’exemple vCPU à 0.2 par sidecar (correspondant à la guidance de performance d’Istio) plutôt que 0.5. La réduction estimée à 80–88% est cohérente avec les déclarations officielles d’Istio “peut dépasser 90%” et la revendication de Solo.io “90% ou plus”.
11	Ajout § : Feuille de route 2025–2026	Nouvelle section documentant Istio 1.27 (multicluster Alpha, août 2025), 1.28 (politiques L7, nftables, novembre 2025), 1.29 (multicluster Beta, HBONE avec headers, février 2026), 1.30 (quatre CVEs, TrafficExtension Alpha, agentgateway expérimental, mai 2026), et annonces KubeCon EU 2026. Sources : blogs officiels Istio et communiqués CNCF.
12	Checklist migration	Ajout d’une checklist concrète : audit EnvoyFilter, compatibilité CNI, migration VirtualService, port NetworkPolicy 15008.