Feuille de route

Où va avuru obs. Ceci est indicatif, pas un engagement — la portée et l'ordre évoluent au fil de nos apprentissages. Le détail technique de référence vit dans le ROADMAP.md du dépôt moteur ; cette page en est le résumé lisible. Pour ce qui fonctionne aujourd'hui, voir l'État des fonctionnalités ; pour ce qui a été livré, le Changelog.

Étoile polaire

:::tip Le coin Un cluster Kubernetes neuf → carte des services en direct en moins de cinq minutes, zéro changement applicatif. Chaque jalon est jugé à cette aune, et c'est vérifié par une porte d'intégration continue. :::

v0.1 — le coin (publiée le 15/07/2026)

Les niveaux de signaux livrés pour 0.1 :

Niveau	Signal	État
Complet	Carte des services + métriques RED ; explorateur de traces (waterfall, recherche)	Livré
Basique	Logs (collecte, recherche plein texte, corrélation trace_id)	Livré
Léger	Profilage continu (flame graphs CPU par service)	Livré
Support	Métriques d'infra (CPU/mémoire/réseau des nœuds/pods)	Livré

Plus la promesse forte : un remplaçant OTLP « drop-in » — les applications déjà instrumentées migrent en changeant seulement l'endpoint d'export, sans changement de SDK ni de code.

Jalons vers v0.1

M1

Stack locale & ingestion

Livré

• Stack make dev (ClickHouse + collecteur + app de démo)
• Ingestion OTLP de bout en bout ; premier test e2e « drop-in »
• Explorateur de traces, logs, carte des services & État du système en direct

M2

Backend OTLP déployable

Livré

• Installation Helm ; gateway → ClickHouse → hub dans le cluster — en direct
• DaemonSet sensor : traces + RED eBPF zéro-code (OBI), logs zéro-config — en direct
• UI d'inventaire des services (RED par service) — en direct

M3

Profondeur & corrélation des signaux

Livré

• Métriques d'infra & tableaux santé nœuds/pods — en direct
• Tableau de bord des métriques RED — en direct

M4

Profondeur de l'UI

Livré

• Waterfall + flamegraph, table des spans, statistiques, graphe — en direct
• Comparaison de traces (diff structurel) — en direct
• UI de profilage continu (flame graphs par service) — en direct

M5

Build gateway & porte TTV

Livré

• Distribution collecteur minimale construite via OCB — en direct
• Porte « time-to-value » sur kind imposant le coin des moins de 5 min — en direct

v0.2 — profondeur et contrôle (publiée le 28/07/2026)

Tout ce qui visait la v0.2 est livré dans la v0.2.0 : l'authentification sécurisée par défaut avec rôles par projet et SSO OIDC, le cadre de modules (choisissez vos signaux), le suivi des erreurs avec une voie d'ingestion navigateur, la santé des services par groupes avec niveaux de criticité, les webhooks d'alerte, la santé réseau sur les liaisons de la carte des services, le module énergie & carbone, et un capteur « qu'on peut laisser activé » prouvé par la CI. Le projet est sous licence AGPL-3.0 à partir de cette version. Le détail complet est sur la page état des fonctionnalités et dans le changelog.

v0.3 — une multi-tenance digne de confiance (publiée le 31/07/2026)

La v0.2 avait sécurisé la lecture ; la v0.3.0 verrouille l'écriture. Les projets deviennent quelque chose que vous administrez — création, renommage et suppression depuis l'interface — et les clés d'ingestion par projet font qu'un émetteur ne se contente plus de déclarer un tenant : en mode enforce, c'est la clé qui décide où atterrit sa télémétrie. Autour de cela : une démo en lecture seule en un clic, le module green sur les VM cloud dépourvues de RAPL, les fondations du plan de contrôle de la collecte à chaud, et le renommage de la couche de déploiement de avuruops vers avuruobs (rupture — voir le guide de mise à jour). Le détail complet est sur la page état des fonctionnalités et dans le changelog.

v0.4 — des comptes que vous administrez (publiée le 07/08/2026)

La v0.4.0 termine le cycle de vie des comptes entamé en v0.2 : la gestion des utilisateurs depuis l'interface — modifier le nom et les rôles, réinitialiser un mot de passe, supprimer un compte selon la règle « désactiver d'abord » — et le changement de mot de passe en libre-service dans Paramètres → Compte, ces opérations restant refusées aux utilisateurs SSO dont l'identifiant appartient au fournisseur d'identité. La revue de cette surface a refermé trois portes d'entrée : un mot de passe local que l'on pouvait créer sur un compte purement SSO, un verrouillage des connexions que la rotation d'adresses IP contournait, et une connexion SSO capable de s'approprier l'e-mail d'un compte local. Côté exploitation : une installation dont la migration de schéma n'a jamais tourné se répare d'elle-même et publie l'état du schéma dans Paramètres → État ; green ne fait plus tomber la sonde sur les nœuds sans RAPL ; et la connexion fonctionne derrière un reverse proxy qui réécrit Host. Le détail complet est sur la page état des fonctionnalités et dans le changelog.

v0.5 — piloter depuis l'interface (publiée le 17/08/2026)

Presque tout ce que l'on administrait exigeait de modifier les valeurs puis de redéployer ; v0.5.0 le fait entrer dans l'application. La collecte pilotable à chaud est livrée au complet : chaque signal s'active ou se coupe depuis Paramètres → Collecte et le capteur suit en quelques secondes, toujours désactivée par défaut derrière un rôle étroitement délimité. Les groupes de services s'écrivent dans l'application, les groupes déclarés dans le chart restant en lecture seule et l'emportant en cas de collision de nom. Paramètres → Stockage et Accès montrent où vivent les données et qui peut toucher à quoi ; le mapping SSO groupe→rôle s'édite à côté des règles du chart ; et les jetons d'API personnels donnent aux scripts et aux futurs clients une accréditation qui suit les permissions vivantes de son propriétaire. Le Tableau de bord répond en un écran à « comment se porte le parc ? », la carte des services porte de vrais anneaux de santé, une latence par arête côté appelant et des filtres partageables, et l'écran Nœuds se trie et se filtre. OpAMP reste la destination pour le contrôle de la collecte : d'abord la remontée d'état, puis la configuration à distance quand l'amont fournira un client. Le détail complet est sur la page état des fonctionnalités et dans le changelog.

v0.6 — ouvert aux deux bouts (publiée le 22/08/2026)

Le produit observait bien un cluster et parlait un protocole ; les parcs sont plus grands que cela. v0.6.0 a ouvert les deux bouts du tuyau. Quatre protocoles de push de plus — Jaeger, Zipkin, Prometheus remote-write et Loki push — arrivent à côté d'OTLP, un flag de values chacun et tous désactivés par défaut, chacun passant par la même étape de tenant : les clés d'ingestion sont donc vérifiées quel que soit le protocole d'arrivée. Les exportateurs de transfert (OTLP/Kafka) dupliquent les écritures vers le backend que vous exploitez déjà, derrière une file bornée pour qu'une cible morte n'exerce aucune contre-pression sur le stockage. La promesse est un garde-fou de CI : de vraies charges par protocole à travers les récepteurs qu'une véritable installation Helm rend. Les projets membres font lire à un projet l'union de plusieurs clusters sur tous les écrans, et les interrupteurs de composants (hub.enabled, ui.enabled, gateway.enabled) permettent à un cluster secondaire de n'installer que la moitié « ingestion » face au stockage central. Les projets ont gagné ce qui leur manquait côté exploitation : une fenêtre de rétention propre et leur propre volume de stockage à côté de celui de l'installation. Côté énergie, /green nomme désormais les nœuds d'où viennent ses chiffres et les budgets carbone disent s'ils peuvent réellement joindre quelqu'un. Détail complet sur la page État des fonctionnalités et dans le changelog.

v0.7 — les clients et les étiquettes (publiée le 23/08/2026)

La v0.6 avait ouvert les deux bouts du tuyau ; ce qui arrivait ne valait que les mots sous lesquels on pouvait le ranger et les surfaces capables de le lire. La v0.7.0 a ajouté les deux. Les étiquettes métier associent une fois un label de pod Kubernetes et le portent sur chaque signal sous la forme avuru.tag.<clé>, appliqué à la collecte pour que les charges non instrumentées le portent aussi, puis proposé comme filtre sur les traces et les journaux — une trace correspondant dès qu'un service participant porte l'étiquette. Les métadonnées déclarées par le service permettent à un service d'annoncer son domaine, son environnement et sa criticité en attributs de ressource et d'être regroupé en conséquence à travers les namespaces Kubernetes, avec un avertissement quand une déclaration ne peut pas être honorée. Deux nouveaux clients lisent la même API publique : la CLI avuruobs, dont le prédicat --fail-on verrouille un déploiement avec trois codes de sortie, et une source de données Grafana — côté backend, donc le jeton d'API n'atteint jamais le navigateur. Chaque écran renvoie désormais à la page du manuel qui l'explique, et la comptabilité du trafic inter-zones rapporte les octets par paire de zones de disponibilité depuis les flux noyau. La carte a aussi cessé de mentir : les proxys de maillage sont reconnus comme du transport et ne sont plus dessinés comme des dépendances. Détail complet sur la page état des fonctionnalités et dans le journal des changements.

v0.8 — la carte grandit (publiée le 24/08/2026)

La carte est la page d'accueil du produit depuis la v0.1, et un graphe de cercles depuis tout aussi longtemps. v0.8.0 lui a appris à en dire plus, sans nouvelle collecte. Les cibles virtuelles placent sur la carte les bases de données, caches et brokers dont vos services dépendent, déduits des spans de sortie des services qui les appellent — un broker dessiné des deux côtés, pour qu'une file ne soit jamais une impasse. Les pairs non détectés récupèrent l'extrémité d'une connexion que personne n'a instrumentée, que le rendu jetait purement et simplement. Les frontières groupent le graphe par namespace Kubernetes ou par groupe de services, résolus exactement comme le tableau de santé les résout, et le volume des arêtes étiquette tous les chemins d'un coup quand la question est lequel porte le trafic. La barre latérale est devenue des couches — Topologie, Signaux, Exploitation, Infrastructure — au lieu d'une liste sans fin, le chemin des cinq premières minutes restant inchangé. Détail complet sur la carte des services, la page état des fonctionnalités et dans le changelog.

v0.9 — le maillage et le noyau (publiée le 25/08/2026)

La v0.8 a empêché la carte de mentir sur un cluster maillé. Elle n'en disait pas encore toute la vérité : les proxys masqués, les fausses dépendances avaient disparu et les vraies, derrière elles, manquaient toujours.

Le hub remonte désormais la parenté propre à chaque trace au travers des proxys et rapporte la dépendance en dessous, en nommant le proxy traversé — et la bascule du maillage échange les représentations au lieu de les empiler : une requête n'est jamais comptée deux fois. Le maillage a gagné son écran : charge, latence et taux de succès par proxy, avec les appels transportés en entrée et en sortie comptés séparément, plus la santé du plan de contrôle et la configuration que vos proxys ont refusée.

En dessous, la sonde eBPF passe à une version qui exporte les retransmissions TCP — la perte de paquets qu'un lien rapide peut masquer — et son attribution par arête est désormais vérifiée sur un noyau réel en intégration continue plutôt que supposée. Enfin, les sondes de point d'entrée répondent à la question que le trafic observé ne peut trancher : quelque chose sert-il encore quand personne n'appelle ? Détail complet sur la page état des fonctionnalités et dans le journal des modifications.

v0.10 — ce que ça coûte (publiée le 26/08/2026)

Toutes les versions précédentes répondaient à ce qui se passe. Celle-ci répond à une question posée par quelqu'un qui n'ouvrira jamais une carte des services : combien coûte ce cluster, et quelle part de cette somme n'achète rien du tout ?

La réponse vient de la capacité, pas d'une facture. Un cluster est dimensionné et facturé sur ce que ses charges de travail réservent : l'écart entre cette réservation et ce qu'elles consomment, c'est le gaspillage — et coût & gaspillage classe chaque charge de travail et chaque nœud selon cet écart. L'inutilisé se mesure par rapport au pic atteint, jamais à la moyenne : on ne peut pas descendre une requête sous son pic sans provoquer, la prochaine fois, l'éviction que ce pic déclencherait. Une charge de travail qui ne déclare aucune requête est signalée comme un état à part entière, et non affichée comme un zéro. Les tarifs sont des valeurs que vous fixez ; sans tarif, les écrans rapportent des cœurs et des octets et le disent — il n'y a pas d'API de tarification ici, et rien ne quitte votre cluster pour produire ce chiffre.

À côté, la carte des services ne dépend plus des noms que vous donnez : une passerelle appelée n'importe comment est reconnue à partir des étiquettes que votre maillage écrit sur son propre plan de données, et ces étiquettes ne font jamais que promouvoir une charge de travail au rang de transport, jamais l'inverse. Enfin, un plan de contrôle silencieux dit désormais lequel des trois silences il s'agit : rien ne le collecte, la cible ne répond pas, ou elle a répondu avec des métriques que ce produit ne sait pas lire. Détail complet sur la page état des fonctionnalités et dans le journal des modifications.

v0.11 — ce qui était déjà dans vos traces (publiée le 28/08/2026)

La v0.10 disait ce que coûte un cluster, et il lui a fallu une nouvelle collecte pour y parvenir. Cette version n'en ajoute aucune : chacune de ses fonctionnalités lit des spans que le coin stocke depuis les cinq premières minutes. Une installation qui se met à jour voit donc son historique, et pas seulement ce qui arrivera ensuite.

Le module IA lit les appels de modèles que vos applications envoyaient déjà. Par modèle : appels, jetons entrants et sortants, latence, échecs et troncatures ; par service appelant, la même chose avec un responsable. Quatre règles le gardent honnête — le modèle qui a répondu l'emporte sur celui qui était demandé, les deux orthographes des attributs de jetons sont acceptées, un appel sans usage rapporté est compté et nommé plutôt que moyenné comme un zéro, et une réponse tronquée n'est pas un échec. Les prix sont des valeurs que vous déclarez, absentes par défaut : il n'y a pas d'API de tarification ici. À côté, et délibérément non conditionné au module, la passerelle supprime par défaut le contenu des invites et des réponses — une décision sur ce que ce produit stocke, pas une option d'écran.

Les surfaces de traces ont grandi dans le même esprit. Un onglet Répartition regroupe les spans par service, opération ou attribut et les pondère par nombre ou par temps écoulé, avec un vrai compartiment de queue pour que les parties fassent bien le tout. Un service a gagné sa propre page, et une requête isolée une vue Chemin pondérée par le temps passé à l'intérieur de chaque service plutôt que par sa durée à l'écran. Enfin, refusé est devenu une troisième réponse à côté de « ok » et « erreur » — délibérément hors du taux d'erreur, car une requête rejetée n'est pas une requête cassée. Détail complet sur la page état des fonctionnalités et dans le journal des modifications.

v0.12 — la dépense sur laquelle agir (publiée le 01/09/2026)

Un rapport n'est pas une action. La v0.12 comble la distance entre les deux — et elle s'ouvre en corrigeant une lecture des spans qui s'est révélée fausse.

Le module IA décidait de ce qui comptait comme appel de modèle en vérifiant la présence de gen_ai.operation.name, sans jamais en lire la valeur. Or execute_tool, invoke_agent et create_agent sont des valeurs légitimes de ce même attribut : sur une charge de travail à base d'agents, chaque exécution d'outil était donc comptée comme un appel de modèle. Les compteurs gonflaient, les quantiles de latence mélangeaient une requête de base de données avec une complétion, le modèle ne se résolvait à rien, et le compartiment qui existe pour nommer honnêtement un manque d'instrumentation se remplissait de spans qui n'avaient jamais été des appels de modèle. Séparer la population par classe d'opération rétablit les quatre.

Une fois les outils distingués, le reste suit. Un tour d'agent est dessiné comme le petit graphe qu'il est — un outil appelé quatre fois est un nœud portant un compteur, parce que c'est la boucle qui mérite d'être vue. Les budgets de dépense se déclenchent via les alertes que vous utilisez déjà, en jetons ou en monnaie, par service appelant ou à l'échelle du parc ; un budget monétaire portant sur des modèles que vous n'avez pas tarifés est refusé à l'analyse de la configuration, plutôt que de passer sous tous les seuils en ignorant la moitié de la dépense. Enfin, une seule table de tarifs remplace deux formats qui pouvaient se contredire, modifiable dans les Réglages et appliquée sans redéploiement, les valeurs déclarées par le chart restant lisibles et marquées en lecture seule.

La version porte aussi quelque chose qui n'était pas prévu pour elle : un serveur MCP, six outils en lecture seule sur les traces, journaux, problèmes d'erreur et l'état de santé qu'une installation stocke déjà — de quoi laisser un agent enquêter sur un incident au lieu qu'une personne retape un écran. Un seul gestionnaire sur le hub — aucune nouvelle collecte, aucun schéma, aucun conteneur — authentifié par les jetons d'API personnels qui existent depuis la v0.5 et résolvant les permissions vivantes de leur propriétaire, et documenté dans la référence d'API. Il est désactivé par défaut, car ce qu'un agent lit quitte votre cluster vers le fournisseur de modèle que vous avez choisi : c'est une décision à vous laisser, pas une décision à prendre à votre place. Détail complet sur la page état des fonctionnalités et dans le journal des modifications.

v0.13 — des dépendances que l'on voit (publiée le 04/09/2026)

Pas une version à thème. La v0.13, c'est ce qui était prêt, et les deux choses qui l'étaient n'ont rien en commun sinon d'achever un travail qu'une version antérieure avait laissé en suspens.

La page d'un service nomme ses appelants et ses dépendances depuis la v0.8, sous forme de deux tableaux triés par volume. Une liste ne peut pas montrer une forme — qu'un seul appelant porte tout le trafic, qu'une seule dépendance est celle qui vire au rouge, qu'un saut n'existe que parce que le hub a suivi une trace à travers un proxy de maillage. L'onglet Aperçu s'ouvre désormais sur un schéma de voisinage : les appelants à gauche, ce service au milieu, ce dont il dépend à droite, chaque flèche portant le débit et le p95 côté appelant de ce chemin précis. Cela ne coûte aucune requête supplémentaire — la page lisait déjà la réponse de la carte des services, et le schéma dessine ces mêmes arêtes. Tout ce que les tableaux refusaient d'affirmer, le schéma le refuse aussi : un saut reconstruit à travers un proxy affiche via <proxy>, une arête que personne n'a chronométrée ne porte aucune latence plutôt que 0 ms, et un pair qui n'a jamais émis de span est dessiné en contour plutôt qu'en plein.

L'autre moitié concerne l'installation même du produit. La v0.12 avait fermé les vulnérabilités critiques de la passerelle avec une distribution de collecteur propre ; l'agent de nœud ne pouvait pas suivre, car il lui faut des composants présents seulement dans contrib et l'avis concerné n'est corrigé dans aucune version de collecteur. Il reçoit donc lui aussi sa propre distribution, ne portant que ce que sa configuration rendue utilise réellement. Toutes les images que le chart télécharge par défaut sont désormais exemptes de vulnérabilité critique ou haute corrigeable, si bien qu'une politique de registre qui bloque les critiques n'a plus rien à excepter — et les exceptions qui subsistent sont nommées dans le fichier de valeurs plutôt que cachées dans un registre. Cela compte, car une telle politique se manifeste par un déploiement qui expire, pas par un rapport d'analyse. Détail complet sur la page état des fonctionnalités et dans le journal des modifications.

v0.14 — le parc qu'un agent peut atteindre (publiée le 06/09/2026)

La v0.12 affirmait qu'un agent peut lire le parc, et c'était vrai — au moyen d'un jeton qu'une personne devait créer et coller à la main, depuis un serveur que rien n'acheminait, et qui décrivait un cluster maillé autrement que les écrans ne le décrivent. Chacun de ces points est un écart entre ce que la version annonçait et ce qu'un opérateur obtenait.

Un assistant hébergé peut désormais s'authentifier. Le serveur MCP parle OAuth 2.1 : découverte, enregistrement dynamique, code d'autorisation avec PKCE, jetons de rafraîchissement à rotation. Les jetons d'accès sont opaques et liés au point d'entrée MCP : l'un d'eux ne peut jamais être rejoué contre le reste de l'API, et ce qu'il peut atteindre est relu à chaque requête plutôt que figé dans une revendication signée — c'est ce qui fait qu'une déconnexion prend effet dès l'appel suivant de l'application. L'écran de consentement indique qu'approuver fait sortir traces et corps de journaux de l'installation, signale que le nom déclaré par l'application n'est pas vérifié, et limite l'accès à un seul projet ; Réglages → Accès liste ce que vous avez connecté. Désactivé par défaut, derrière son propre interrupteur.

Et le même parc, décrit de la même façon. service_context rapporte désormais la dépendance située derrière un proxy de maillage plutôt que le proxy — la fusion que la carte des services opère depuis la v0.9, via le même code plutôt qu'une seconde implémentation. La vue Chemin des traces lit le temps propre par service calculé par le hub au lieu de le recalculer, ce qui a mis au jour un vrai défaut au passage : l'outil MCP ne comptait qu'un statut d'erreur brut, si bien qu'un service renvoyant des 5xx depuis un client auto-instrumenté était rapporté comme sain.

Un maillage que l'on peut vraiment lire. L'écran Maillage répondait à deux questions et, sur un cluster fonctionnant sans sidecars, affichait deux lignes. Il est devenu une console : chaque proxy gagne un rôle — plan de contrôle, passerelle, waypoint, ztunnel, sidecar — et un espace de noms, lus dans des labels que le stockage conservait déjà ; deux colonnes qui annonçaient des octets et affichaient des nombres d'appels sont renommées, et les vrais octets et la santé des liens ont leurs propres colonnes ; un proxy s'ouvre sur ce qu'il transporte, les dépendances fusionnées reconstituées à travers lui, lues depuis l'autre bout. Puis un second module, mesh-config, accordé séparément, lit en lecture seule les objets Istio et Gateway API du cluster lui-même : un espace de noms inscrit et silencieux a enfin une ligne, et six vérifications nomment les erreurs de configuration qui n'émettent aucune télémétrie. C'est un module à part, désactivé à la naissance, parce que l'écran du maillage n'a besoin d'aucune permission sur le cluster et qu'une lecture à l'échelle du cluster doit être une décision prise par un opérateur, pas par une mise à jour à sa place.

La version porte aussi trois réparations. /mcp n'était acheminé nulle part sur une installation Helm — le point d'entrée annoncé en v0.12 a répondu par la page 404 de l'interface pendant toute sa vie. Le schéma de voisinage de la v0.13 dessinait un proxy comme appelant sur un cluster maillé. Enfin, les images de publication sont compilées de façon croisée plutôt qu'émulées, ce qui était le seul obstacle entre un tag poussé et une version publiée. Détail complet sur la page état des fonctionnalités et dans le journal des modifications.

v0.15 — ce que le maillage a reçu comme consigne, et ce qu'il a fait (publiée le 07/09/2026)

La v0.14 a donné au maillage une console et un lecteur de sa configuration, et a laissé une question en suspens : la configuration du maillage dit qu'un espace de noms est strict, et un mode est une affirmation. Le trafic était-il vraiment chiffré, pourquoi un proxy a-t-il refusé une requête, quelles charges de travail sont réellement dans le maillage — ce sont les questions qu'un opérateur pose en premier, et chacune exige une source que le produit ne lisait pas : les proxys eux-mêmes, et les pods.

Déclaré contre observé est l'élément qui définit la version. La sonde lit ce que le plan de données rapporte sur lui-même — par requête et par connexion, TLS mutuel ou clair — depuis les proxys de chaque nœud, découverts grâce aux annotations que le maillage écrit déjà. Le hub le joint à la politique qui gouverne réellement chaque charge de travail, y compris celles à sélecteur que le lecteur de la v0.14 ignorait. Chaque espace de noms, charge de travail et arête de la carte reçoit un cadenas ; « permissif avec des appelants en clair » nomme les appelants ; et « déclaré strict, observé en clair » — une politique qui n'est pas appliquée — devient un constat au lieu d'un silence. Sous le module de maillage, activé par défaut : le module est le consentement.

Autour : chaque charge de travail, dedans ou dehors — le lecteur de configuration ajoute les pods, en lecture seule et plafonnés, pour qu'un onglet Charges de travail liste ce que le cluster exécute, trafic ou non, avec la présence d'un sidecar dans le pod, la capture par l'agent de nœud, le waypoint qui le lie et les politiques qui décident de son mode mTLS. Six vérifications deviennent dix-sept, dont les deux que la v0.14 avait retenues faute de pods et celles qu'exige une posture de sécurité, et chaque vérification dépendant des pods le dit quand la liste a été tronquée, pour qu'une colonne de problèmes vide ne soit jamais un quitus. Le proxy explique ses échecs — requêtes par indicateur de réponse et par version de destination, les compteurs qu'un maillage par défaut n'expose pas étant nommés comme non collectés plutôt qu'affichés à zéro. Et le graphe se lit par rôle, avec, au bout appelant de chaque arête mesurée, un marqueur tout-chiffré, mixte ou en clair, sur la carte comme sur le graphe du maillage.

Livrée dans la version 0.15.0 ; l'élément qui définit la version a son propre billet. Délibérément hors de cette ligne : la configuration effective par proxy, qui reste un travail de débogueur ; l'historique de posture et les alertes de posture, qui attendent que les verdicts aient été éprouvés sur de vrais clusters ; et un second plan de contrôle, qui attend toujours un opérateur qui en exploite un.

v0.16 — la page d'une charge de travail (publiée le 07/09/2026)

La v0.15 mettait sur une même ligne ce que le maillage avait reçu comme consigne et ce qu'il avait fait. Sur un vrai cluster ambiant, avec une console de maillage à côté, les questions suivantes du lecteur étaient celles auxquelles cette ligne ne répondait pas : qu'est-ce que cette charge, depuis quand, quels pods sur quel déploiement, quelle configuration la nomme — et qu'ont écrit les proxys à son sujet. La fiche se trouvait déjà dans des objets que le lecteur observait ; les lignes des proxys étaient déjà dans le magasin, classées sous les noms des proxys eux-mêmes. Rien de nouveau n'a été lu dans le cluster.

La fiche est l'élément qui définit la version. La page d'une charge porte la date de création du contrôleur (ou celle du pod le plus ancien, et elle le précise), son type, ses étiquettes app et version, chaque étiquette et les annotations du contrôleur dans des bornes explicites, chaque pod avec le déploiement auquel il appartient, et un verdict de santé avec la raison qui l'a décidé. À côté des politiques qui la sélectionnent par étiquette, les routes et règles qui l'atteignent par ses Services — HTTPRoute, GRPCRoute, VirtualService, DestinationRule — résolues par le même index d'hôtes que les vérifications, chacune avec ses propres constats. Une charge routée n'est plus dite sans configuration.

Trois sources, un seul flux. L'application journalise un côté de chaque requête ; ztunnel journalise la connexion et le waypoint l'échange HTTP, sous leurs propres noms de service. Une seule route lit les trois pour une charge comme un seul flux ordonné sous un seul curseur — composé dans le hub, qui connaît les pods derrière la charge et le waypoint auquel elle est liée. Quand les pods ne peuvent pas être connus, les lignes des proxys sont reconnues par nom et espace de noms ensemble, et la réponse dit à quel échelon elle est redescendue.

Livrée comme version v0.16.0. Délibérément hors de cette ligne : la disponibilité, les redémarrages et l'état des conteneurs des pods — le lecteur ne projette qu'une douzaine de champs par pod, à dessein ; et une ligne ztunnel dans l'onglet Proxys alimentée par la collecte plutôt que par les spans, qui attend la ligne suivante avec les compteurs d'octets TCP que la collecte conserve déjà.

v0.17 — l'espace de travail connecté (publiée le 15/09/2026)

La carte est le point d'entrée de l'application. Explorer garde les appelants et les dépendances du service sélectionné à côté du graphe, puis mène à ses traces, ses journaux et sa fiche. La sélection voyage dans l'URL et se fait au clavier. Un projet vide explique comment brancher eBPF et OTLP ; une lecture échouée propose de réessayer. L'interface commune adopte des surfaces sauge et forêt, avec une navigation mobile qui conserve les modules activés et les commandes de projet. L'écran Erreurs gagne un résumé de l'ensemble de problèmes filtré, l'onglet Journaux d'un service résout sa charge de travail, les tables de journaux se copient et se téléchargent, et le corps des journaux de conteneurs livre une sévérité.

Livrée avec la version v0.17.0.

v0.18 — regarder à l'intérieur du cluster (publiée le 16/09/2026)

L'infrastructure gagne Cluster X-Ray : une vue isométrique interactive des Nodes, des Pods translucides et d'une couche d'infrastructure logique à côté de l'inventaire. Orbiter, zoomer, séparer ou masquer les couches, filtrer les namespaces, inspecter le CPU, la mémoire et le placement d'un Pod, et suivre les connexions que les traces ont enregistrées — uniquement entre identités de Pods enregistrées, les adresses non résolues restant explicitement non localisées. Le moteur de rendu se charge à la demande, la scène annonce ses limites, et l'inventaire reste disponible au clavier et sans WebGL.

Livrée avec la version v0.18.0.

v0.19 — les logs de plusieurs services en un seul flux (publiée le 18/09/2026)

Un seul explorateur de logs pour Signaux → Logs et Service Mesh → Logs : choisissez services et workloads, sélectionnez les sources à lire, et suivez-les fusionnés du plus récent au plus ancien ou en un panneau par service. Sélection, sources et affichage vivent dans l'URL ; GET /api/v1/logs compose les sujets en une seule requête paginée sous un jeton de pagination signé. Le thème sombre passe à l'ardoise avec un texte secondaire lisible. La v0.19.1 a restreint les écrans du maillage aux namespaces que les projets de l'appelant atteignent.

Livrée avec la version v0.19.0.

v0.20 — les décisions typées, sur le papier (publiée le 23/09/2026)

Aucune modification du produit. Une note de conception classe les endroits où un classifieur qui répond par une probabilité calibrée plutôt que par du texte aurait sa place — la sévérité qu'une règle n'a pas su lire, des erreurs qu'une empreinte a séparées, des alertes à trier — et ce que chacun coûterait à la promesse que rien ne quitte le cluster : au plus un module optionnel, par lots, n'envoyant que des charges structurées ou déjà nettoyées, désactivé à la naissance, jamais sur le chemin d'ingestion. Un banc d'essai hors ligne mesure le premier cas, le rattrapage de sévérité des logs, depuis un poste de travail contre une copie de la table des logs. La note reste un brouillon tant que cette mesure n'a pas eu lieu.

Livrée avec la version v0.20.0.

Au-delà de la v0.20 (indicatif)

• Les proxys depuis la collecte, non depuis les spans. Sur un cluster ambiant, ztunnel n'émet aucun span, si bien que l'onglet Proxys n'a pas de ligne pour lui alors même que ses métriques sont lues ; le up et les jauges de la collecte devraient alimenter la ligne, et les compteurs d'octets TCP déjà collectés devraient être lus.

• Lire un deuxième plan de contrôle, dès que quelqu'un qui en exploite un pourra dire lesquels de ses signaux répondent aux questions auxquelles répond la carte Istio — et lesquels n'y ont tout simplement pas de réponse.

• Le coût joint au module « green » : la même capacité réservée-et-inutilisée en Wh et gCO2e, sur une installation qui exécute les deux. Un seul récit sur le gaspillage, en deux unités.

• L'incident : des synthèses de cause racine, avec tout commutateur de fournisseur désactivé par défaut — ce serait le premier appel réseau sortant d'un produit dont la promesse est que rien ne quitte le cluster. La note de conception de la v0.20 porte la moitié décision — quelle urgence, et est-ce le symptôme d'une alerte amont déjà déclenchée — sur le papier, comme décision typée sur des métadonnées structurées, sans rien générer ; la moitié synthèse reste écartée.

• Des parcours de vérification scriptés en plusieurs étapes, si la demande se manifeste — la v0.9 livre délibérément des vérifications à requête unique.

• Un profilage plus profond : profils hors-CPU et mémoire, à mesure que le profileur eBPF amont les développe.

• Réévaluation du stockage : ClickHouse reste derrière l'interface storage.Store ; GreptimeDB sera réévalué mi-2027 sans changer le code du hub.

Comment cette feuille de route change

Ouvrez une issue ou une discussion pour proposer un changement de cap ; les éléments plus importants passent par une Avuru Enhancement Proposal avant implémentation. Les modifications passent par une pull request classique.