En bref

  • Akvorado est un projet actif à code source ouvert d’analyse des flux, lancé à l’initiative de l’ingénieur réseau Vincent Bernat, soutenu dans l’environnement de Free et développé par une communauté publique plutôt que par une entreprise distincte.
  • L’architecture 2.x sépare la réception UDP, le transport par Kafka, l’enrichissement et le stockage dans ClickHouse, ce qui permet de faire évoluer chaque étape indépendamment sans éliminer les pertes antérieures à la réception ni les défauts des sources.
  • La plateforme apporte de la valeur lorsqu’elle transforme les adresses, les index d’interface et les compteurs en contexte de peering, de capacité et d’incident, mais ses conclusions dépendent des métadonnées, des classificateurs et de la chronologie.

Une version de maintenance révèle une refonte plus profonde

Le 14 juillet 2026, les responsables de la maintenance d’Akvorado ont publié la version 2.4.1. Cette version constituait en elle-même un signe ordinaire de maintenance active. Le fait le plus important se trouvait derrière elle: la génération actuelle ne confie plus à un collecteur étroitement intégré la réception de chaque export de flux, son décodage, son enrichissement et son écriture immédiate dans le stockage analytique.

Dans Akvorado 2.0, ce chemin est réparti entre des nœuds de travail distincts: inlet reçoit les datagrammes, Apache Kafka transporte une représentation compacte, les processus outlet ajoutent le contexte et ClickHouse conserve le résultat pour les recherches et les agrégations.

Cette architecture répond à un problème pratique bien connu des opérateurs. Un grand réseau produit bien plus de traces de trafic que les ingénieurs ne peuvent en examiner paquet par paquet. Les routeurs et les commutateurs peuvent résumer leurs observations dans des enregistrements NetFlow, IP Flow Information Export — IPFIX — et sFlow. L’export conserve suffisamment de données pour répondre à des questions sur le volume, la direction, les interfaces et les nœuds qui communiquent, sans stocker chaque charge utile.

Akvorado collecte ces traces, leur ajoute un sens réseau et met l’historique à disposition au moyen d’une interface web et d’un langage de filtrage.

Derrière l’apparente simplicité d’un graphique se trouve une chaîne de décisions. Le dispositif exportateur détermine quels paquets ou flux seront représentés. L’échantillonnage peut écarter les connexions brèves. Des datagrammes UDP peuvent être perdus avant que le collecteur les enregistre. Les modèles changent. Les identifiants d’interface sont réutilisés. Un flux d’informations de routage peut décrire un chemin modifié après le passage du trafic. Une base de données sur les systèmes autonomes ou la géolocalisation peut mal classer une adresse.

Une règle écrite par un humain peut étiqueter le trafic comme client, de peering ou de transit alors qu’aucun indicateur de ce type n’était présent dans le paquet lui-même.

Akvorado est important parce qu’il rend visible une grande partie de cette chaîne dans un code ouvert, au lieu de présenter le graphique comme le résultat opaque d’un équipement. Le projet donne aux opérateurs le contrôle de la collecte, de la durée de conservation, de l’enrichissement, des requêtes et des accès. Il leur laisse aussi la responsabilité des faiblesses de chaque composant choisi.

La question centrale est opérationnelle, non promotionnelle: jusqu’où un système auto-hébergé peut-il transformer des exports incomplets en mémoire fiable du fonctionnement du réseau, sans laisser un tableau de bord soigné promettre plus que ce que les données étayent?

La réponse dépend de l’usage. Pour la planification de capacité, une tendance issue d’un échantillonnage peut être utile même si elle ne fournit pas un nombre exact de paquets. Pour le peering, la direction générale du trafic et le contexte des systèmes autonomes peuvent montrer où la demande se déplace. Lors d’un incident, un historique peut réduire l’intervalle temporel, l’interface et le partenaire à examiner. Aucun de ces usages n’exige une omniscience au niveau des paquets. Chacun exige de comprendre ce que l’enregistrement représente, ce qu’il omet et comment l’enrichissement ultérieur en a modifié le sens.

Les enregistrements de flux existent parce que les paquets complets coûtent trop cher à conserver longtemps

Une capture complète de paquets peut conserver les en-têtes, l’ordre et parfois la charge utile avec un niveau de détail suffisant pour une reconstruction forensique minutieuse. Sur les liaisons très chargées, elle entraîne aussi des coûts considérables de stockage, de gestion des accès et de confidentialité. La télémétrie de flux propose un autre compromis. L’exportateur regroupe ou échantillonne le trafic et envoie des enregistrements comportant des champs distincts: adresses source et destination, ports, protocole, compteurs, horodatages, interfaces d’entrée et de sortie.

Le résultat est plus compact, plus facile à conserver et à agréger sur la durée, mais il ne constitue plus une reproduction littérale des paquets ayant traversé le réseau.

NetFlow et IPFIX décrivent généralement les connexions au moyen d’enregistrements créés à l’expiration d’une entrée de cache ou à la fin d’un flux. IPFIX formalise l’architecture des exportateurs, des collecteurs, des modèles et des enregistrements de données. Le collecteur a besoin d’un modèle pour interpréter les valeurs suivantes; la position d’un champ n’a pas de signification stable à elle seule. Les éléments propres aux fabricants et les différences de politique de mise en cache font que deux exportateurs peuvent décrire différemment un trafic similaire.

Les décodeurs d’Akvorado se trouvent à la frontière entre la famille de normes et le comportement réel des équipements.

sFlow aborde généralement le problème par l’échantillonnage des paquets et des compteurs. L’équipement sélectionne des paquets à une fréquence définie, exporte les informations relatives à l’échantillon et peut transmettre des statistiques d’interface. À volume suffisamment élevé, cette méthode révèle les tendances générales sans obliger l’équipement ou le collecteur à traiter chaque paquet comme un événement distinct.

La contrepartie apparaît aux marges: un flux bref peut ne jamais être sélectionné, une rafale soudaine peut être sous-estimée et aucune estimation ne peut être interprétée sérieusement sans le taux d’échantillonnage et le dénominateur.

Cette différence importe, car le terme « flux » ne désigne pas une forme unique de preuve. Un en-tête de paquet échantillonné, un enregistrement de connexion agrégé et un compteur d’interface répondent à des questions différentes. Ils peuvent se corroborer, mais ne peuvent pas être fusionnés en une seule affirmation de précision. Akvorado conserve et affiche les champs reçus; il ne peut contraindre l’exportateur à révéler des paquets qui n’ont pas été sélectionnés ni des champs qui n’ont pas été envoyés.

La conservation longue durée constitue le principal avantage opérationnel. Un compteur d’interface montrera qu’une liaison transportait davantage de trafic à un moment précis, mais il n’identifiera généralement pas les réseaux et les services concernés. Une capture de paquets répondra plus précisément, mais de nombreux opérateurs ne peuvent la conserver pendant des semaines ou des mois sur chaque liaison à haut débit. Les enregistrements de flux occupent une position intermédiaire. Ils préservent suffisamment de dimensions pour revenir ultérieurement sur un événement, à condition que la politique d’échantillonnage et d’export reste connue.

C’est pourquoi l’analyse des flux appartient à la pile d’infrastructure et non à l’habillage d’un tableau de bord. Le collecteur fait partie du système de production des preuves. Ses résultats peuvent orienter les achats, les changements de peering, la gestion du trafic et les enquêtes. Des décisions ayant de telles conséquences exigent un chemin documenté entre la configuration de l’équipement et le résultat d’une requête.

L’exportateur décide de ce qu’Akvorado pourra réellement savoir

La première dépendance d’Akvorado se trouve hors de son dépôt. Les routeurs et les commutateurs déterminent si l’export est activé, quelles interfaces participent, comment les clés des enregistrements sont constituées, à quel moment le cache expire, quel échantillonnage est appliqué et quels champs sont transmis. Les circuits matériels de transfert peuvent fournir des niveaux de détail différents. Même un collecteur irréprochable recevra un récit incomplet si les équipements sources sont configurés de manière incohérente ou ne savent pas produire les données nécessaires.

La gestion des modèles constitue l’un des points fragiles. IPFIX et plusieurs versions de NetFlow utilisent des modèles par lesquels l’exportateur définit la structure des enregistrements suivants. Si le collecteur manque un modèle, reçoit les données avant sa définition ou rencontre un champ propriétaire modifié, il peut ne pas décoder correctement l’enregistrement. Il est parfois possible de demander ou d’attendre un nouveau modèle, mais la télémétrie perdue dans l’intervalle ne revient pas automatiquement. Une exploitation sûre traite l’état des modèles comme une dépendance observable, non comme une conduite protocolaire invisible.

Les informations de séquence peuvent révéler une partie des ruptures. Les exportateurs numérotent les paquets ou les enregistrements, ce qui permet au collecteur de détecter une réinitialisation ou un saut. Il s’agit d’un signal de diagnostic, non de récupération. Un numéro manquant indique une lacune dans les preuves, mais ne recrée pas le trafic absent. Un redémarrage de l’exportateur, une perte en transit, la saturation d’un socket et l’ordonnancement de l’hôte peuvent se ressembler; le compteur de pertes ouvre donc une enquête sans en désigner la cause.

L’échantillonnage crée une autre forme d’incertitude. Un paquet sur plusieurs milliers peut fournir une estimation suffisamment bonne d’un grand flux stable pour certaines tâches de planification, mais ne presque rien dire sur des connexions rares. L’erreur n’est pas un pourcentage fixe applicable partout. Elle dépend de la distribution des flux, de la méthode d’échantillonnage, de la fenêtre temporelle et de la question posée. Une tendance du trafic de transit total et une conclusion de sécurité portant sur une seule connexion brève exigent des normes de preuve différentes.

La calibration maintient l’incertitude visible. Une équipe peut comparer le volume d’octets estimé à partir des flux avec les compteurs d’interface sur la même période. Un écart persistant peut signaler les paramètres d’échantillonnage, la couverture des exports, la perte de datagrammes ou une erreur de classification. Les sources reposent sur des mécanismes de mesure différents et ne sont pas tenues de coïncider parfaitement; la comparaison indique si le système est suffisamment stable pour l’usage prévu.

C’est là que se situe la première limite de l’autorité d’Akvorado. Le projet ne peut décoder, enrichir et interroger que les données effectivement arrivées. Il ne contrôle pas l’instrument au point d’observation. Si l’opérateur considère la configuration des exportateurs comme le problème de quelqu’un d’autre, toute l’analyse ultérieure repose sur un dénominateur inconnu.

Vincent Bernat a conçu Akvorado autour des questions réelles des opérateurs

Akvorado est né vers 2019 de besoins pratiques liés à l’analyse des flux. Les articles publics et l’historique du code présentent l’ingénieur réseau Vincent Bernat comme le principal initiateur et une figure majeure de sa maintenance. Le logiciel est aussi étroitement associé à l’environnement opérationnel du fournisseur d’accès à Internet français Free, qui lui a apporté un important contexte de production et un soutien. Les éléments disponibles ne permettent pas de présenter Akvorado comme un produit commercial de Free, une entreprise distincte ou un service exploité par Free pour l’ensemble des utilisateurs.

Cette distinction explique la nature du projet. Les documents publics se concentrent sur des tâches familières aux opérateurs: recevoir plusieurs formats de flux, résoudre les index d’interface, ajouter le contexte des systèmes autonomes et du routage, distinguer le peering du transit, conserver longtemps de grands volumes et permettre aux ingénieurs de poser des questions précises. L’interface est utile parce qu’elle s’appuie sur le modèle de données de l’opérateur lui-même, non parce qu’elle propose un ensemble universel de graphiques colorés.

La chronologie initiale est moins complète que la description de l’architecture actuelle. L’historique du dépôt montre que le développement s’est poursuivi au début des années 2020: la collecte, la classification et l’exploration web ont mûri avant la refonte 2.0. En 2023, Vincent Bernat a décrit publiquement le langage de filtrage proche de SQL et les Protocol Buffers dynamiques; des versions ont été publiées en 2024. Il n’existe pas de relevé public de la date exacte du premier déploiement en production, du lancement du projet ou de la croissance du nombre d’utilisateurs.

Le profil doit préserver ces lacunes plutôt que d’inventer une histoire de fondateur.

Le rôle le plus important de Free consiste à fournir un environnement opérationnel. Un fournisseur d’accès à Internet à fort trafic révèle des problèmes invisibles dans une démonstration de laboratoire: rafales d’exports UDP, très grand nombre d’interfaces, forte cardinalité des adresses, routage en évolution constante et nécessité de relier le volume de trafic aux relations commerciales. Ce contexte influence les priorités de développement, mais ne prouve pas que chaque fonction soit déployée de manière identique au sein de Free, que l’entreprise finance tous les contributeurs ou qu’elle contrôle l’avenir du projet.

Le dépôt public offre aux opérateurs externes une autre source de confiance. Ils peuvent étudier le code, les problèmes signalés, les notes de version et les réglages; exécuter toute la pile chez eux; conserver les métadonnées sensibles sous contrôle interne; modifier le logiciel selon les termes de la GNU Affero General Public License version 3. La transparence ne remplace toutefois pas l’assistance. Les organisations ont toujours besoin de personnes qui comprennent les exportateurs, Kafka, ClickHouse, les données de routage et les conséquences des mises à niveau.

L’origine d’Akvorado crée ainsi une tension centrale au lieu de la supprimer. Un logiciel issu des problèmes des opérateurs peut exprimer plus précisément les questions nécessaires qu’un produit analytique généraliste. Il peut en même temps présenter un risque de concentration autour d’un petit groupe de responsables de maintenance et hériter d’hypothèses propres à l’environnement dans lequel il a été créé.

La version 2.0 a séparé la réception de l’interprétation

L’attrait d’un collecteur intégré unique est compréhensible. Un processus ou une pile étroitement liée reçoit les enregistrements, les décode, les enrichit et les écrit. Le déploiement est plus facile à expliquer et comporte moins de composants. La faiblesse apparaît lorsque l’entrée et l’analyse ne progressent plus à la même vitesse. Une rafale de datagrammes UDP n’attendra pas la fin d’une fusion dans la base ou l’accélération d’une requête externe de métadonnées. Si le chemin de réception se bloque, la partie la plus précoce et irremplaçable des preuves peut disparaître à l’entrée.

Akvorado 2.0 a séparé ces responsabilités. inlet se concentre sur la réception des datagrammes de flux et la publication dans Kafka d’une représentation codée compacte. Les processus outlet lisent le flux, décodent les enregistrements, ajoutent des métadonnées, appliquent les classificateurs et insèrent les données par lots dans ClickHouse. Les capacités de réception, d’enrichissement et de base de données peuvent évoluer comme des tâches liées mais autonomes.

Ce découplage modifie le comportement en cas de panne. Un ralentissement temporaire de ClickHouse ne doit plus nécessairement arrêter immédiatement le processus d’écoute UDP; Kafka peut conserver une file dans la limite de la durée de rétention et de l’espace disque disponible. Si l’enrichissement prend du retard, des processus outlet peuvent être ajoutés. Les partitions répartissent le travail, tandis qu’inlet reste suffisamment léger pour se consacrer aux sockets et à l’état des exportateurs.

Cette conception crée un vocabulaire opérationnel plus clair. Les ingénieurs peuvent demander séparément si les datagrammes ont atteint inlet, s’ils ont été publiés, si les consommateurs suivent le rythme, si l’enrichissement a réussi et si ClickHouse a accepté le lot. Un service monolithique peut masquer toutes ces étapes derrière un indicateur de santé unique. Des composants séparés rendent les transitions observables, à condition que le déploiement collecte et conserve réellement les bonnes métriques.

Davantage de composants signifie davantage de modes de panne. Les nœuds Kafka exigent une planification de capacité, un choix de réplication, une politique de conservation et une maintenance. Le retard des consommateurs peut croître discrètement. Les partitions influencent la répartition et l’ordre. Les processus outlet peuvent diverger s’ils utilisent des versions de structure ou des paramètres d’enrichissement différents. ClickHouse peut continuer à répondre à des requêtes historiques pendant que les données récentes attendent ailleurs.

L’architecture 2.0 renforce le contrôle en rendant la chaîne de traitement explicite; elle ne la rend pas auto-administrée.

La migration constitue une autre limite. Une refonte qui modifie la représentation des messages, le rôle des services et le comportement du stockage crée un travail de compatibilité et d’exploitation pour les anciens utilisateurs. L’historique public montre une maintenance active jusqu’à la version 2.4.1, mais aucun décompte indépendant n’indique combien d’opérateurs ont migré depuis les premières versions, combien de temps cela a pris ni quelles pannes sont apparues dans les déploiements les plus importants.

La modification 2.0 se comprend mieux comme une répartition des responsabilités. inlet protège le moment de l’arrivée. Kafka absorbe les différences de rythme après la publication. outlet transforme les enregistrements bruts selon le modèle de données d’Akvorado. ClickHouse conserve l’historique analytique. Chaque étape peut être améliorée et testée séparément; en cas de panne, chacune laisse son propre type de lacune.

Kafka absorbe les retards de traitement après l’arrivée des données

Kafka est la charnière de l’architecture actuelle d’Akvorado, car il transforme un chemin de réception sensible aux rafales en un flux que les processus ultérieurs peuvent traiter à un autre rythme. Les messages sont répartis entre des topics et des partitions, conservés pendant une durée définie et lus par les processus outlet. Ce tampon évite qu’un enrichissement coûteux ou un retard de stockage ne répercute immédiatement sa pression sur le socket qui reçoit les exports.

La limite temporelle est précise. Kafka ne peut protéger les données qu’après leur réception et leur publication par inlet. Un datagramme perdu dans le réseau, abandonné par l’exportateur, supprimé en raison d’un tampon de socket plein ou rejeté avant publication n’entre jamais dans le flux mis en mémoire par Kafka. Qualifier la chaîne de « sans pertes » au seul motif que Kafka est présent masquerait la partie la plus vulnérable du chemin.

Après la publication, la durabilité dépend encore des réglages. La réplication entre les nœuds, les accusés de réception, la capacité disque, la durée de conservation et la reprise après panne déterminent le niveau de protection. Une rétention courte peut transformer une panne prolongée de ClickHouse en perte de données. Un partitionnement qui concentre les exportateurs les plus lourds dans certaines partitions crée un retard inégal. La panne d’un nœud pendant une période de réplication insuffisante peut supprimer des enregistrements déjà reçus par inlet.

L’ordre exige également de l’attention. Kafka garantit la séquence au sein d’une partition, non entre toutes les partitions du groupe. L’analyse des flux a plus souvent besoin d’horodatages bornés et de fenêtres d’agrégation que d’un ordre absolu unique. L’état des modèles, la séquence d’un exportateur et les mises à jour de l’enrichissement peuvent néanmoins dépendre de la position relative des enregistrements. L’opérateur doit connaître les hypothèses d’outlet et comprendre comment un redémarrage ou un rééquilibrage les affecte.

Le retard des consommateurs est le signal opérationnel le plus utile, car il traduit l’architecture en temps. Une file de dix millions d’enregistrements ne signifie pas grand-chose sans les vitesses d’arrivée et de traitement. Un retard exprimé en secondes ou en minutes indique de combien la représentation analytique est décalée par rapport au réseau. Lorsqu’une équipe chargée de la capacité ou de la réponse aux incidents pense observer le trafic actuel, ce délai fait partie de la preuve et doit entrer dans le modèle de santé du service lui-même.

Kafka modifie aussi les compétences nécessaires à Akvorado. Une petite équipe réseau qui gérait auparavant un collecteur et une base de données doit désormais exploiter un système distribué de messagerie. Cette charge supplémentaire peut être justifiée par l’échelle et la résilience. Elle reste un coût pour l’opérateur, non une propriété gratuite du code ouvert.

L’affirmation correcte est étroite et utile: Kafka réduit le couplage entre la réception et les travaux ultérieurs. Il offre une marge pour traverser un décalage temporaire de vitesse. Il ne restitue pas les enregistrements perdus avant inlet, ne garantit pas la durabilité de chaque déploiement et ne supprime pas la nécessité de surveiller la file comme une infrastructure de production.

ClickHouse rend interrogeable un long historique du trafic

La télémétrie de flux se prête bien à une base colonnaire, car de nombreuses questions ne parcourent que quelques champs parmi un très grand nombre de lignes. Un ingénieur peering peut regrouper les octets par système autonome de destination et par période. Un spécialiste de la capacité peut comparer des interfaces ou des sites sur plusieurs semaines. Un enquêteur peut filtrer un petit ensemble d’adresses et de ports dans un intervalle court. Le stockage colonnaire lit les colonnes nécessaires, compresse les valeurs répétitives et agrège sans reconstruire chaque enregistrement à chaque requête.

Akvorado insère les données dans ClickHouse par lots et les organise pour une analyse délimitée dans le temps. Des champs dérivés ou pré-calculés simplifient les dimensions fréquemment utilisées. La base apporte la persistance qui transforme un export éphémère en mémoire: un ingénieur peut revenir sur un déplacement de trafic après que les compteurs des équipements ont avancé et que l’état initial du routage a changé.

Cette mémoire a un coût physique. Les adresses, les ports, les métadonnées d’interface et les étiquettes à forte cardinalité occupent de l’espace et influencent la compression. Les partitions, les clés de tri et les fusions en arrière-plan déterminent la latence des requêtes et la stabilité des insertions. La politique de conservation décide si les données restent disponibles pendant des jours, des mois ou davantage. Un déploiement qui conserve indéfiniment chaque dimension peut épuiser ses disques ou dépenser davantage en stockage que ne le justifient les questions posées.

Les travaux d’arrière-plan de ClickHouse sont importants, car les données récentes et les requêtes historiques se disputent le même système. Les fusions, le compactage et la réplication consomment des entrées-sorties tandis qu’outlet insère de nouveaux lots. La base peut rester techniquement disponible tout en prenant du retard sur le plan opérationnel. La pression sur le disque se manifeste d’abord par un ralentissement des fusions, puis des insertions et, finalement, par l’absence de preuves récentes pour l’utilisateur.

La conception des requêtes crée une illusion similaire. Un graphique affiché rapidement peut reposer sur des champs pré-calculés ou dérivés dont le sens diffère de celui de l’enregistrement brut. Une requête large sur une dimension à forte cardinalité peut provoquer un parcours coûteux. L’opérateur a besoin de limites, d’une observabilité des requêtes et d’une distinction claire entre le détail complet et toute politique d’agrégation ou de conservation propre au déploiement.

Le langage de filtrage proche de SQL dispense les utilisateurs de manipuler directement la syntaxe de la base, mais n’en supprime pas le modèle. Les champs doivent exister, avoir un sens stable et être indexés ou organisés en fonction de la charge. L’évolution de la structure de données ajoute des dimensions tout en créant des besoins de migration et de compatibilité. Les Protocol Buffers dynamiques assouplissent la représentation de transport; ClickHouse exige malgré tout une structure analytique cohérente à l’autre extrémité.

ClickHouse est donc plus qu’une dépendance cachée sous l’interface web. Il fait partie du contrat opérationnel du produit. L’état du stockage, la vitesse des fusions, la latence des requêtes et la rétention déterminent si Akvorado répondra à une question au moment précis où la réponse est nécessaire.

L’enrichissement transforme les index d’interface en carte de l’activité réseau

Un enregistrement brut peut seulement indiquer que le trafic est entré par l’interface 287 et ressorti par l’interface 914. Ces nombres ont un sens pour l’équipement exportateur, mais ne disent pas à l’ingénieur si le chemin a emprunté un port client, une interconnexion privée, un fournisseur de transit, le cœur du réseau ou une interface de service. Akvorado enrichit les enregistrements afin que la requête soit formulée dans le langage du réseau plutôt que dans celui de l’exportateur.

L’interrogation au moyen de Simple Network Management Protocol — SNMP — fournit une partie de ce contexte. Akvorado peut mettre en cache les noms, descriptions, débits et adresses des interfaces, transformant des index numériques en liaisons reconnaissables. Le graphique devient exploitable pour vérifier la capacité ou examiner un incident. Un problème temporel apparaît cependant: les index sont réutilisés, les descriptions sont modifiées et les interrogations échouent. Un enregistrement créé le lundi peut être affiché avec des métadonnées obtenues plus tard si la mise en œuvre ne conserve pas l’association historique.

Les bases d’adresses et de systèmes autonomes ajoutent une autre couche. Elles relient un préfixe IP à une organisation, un ASN ou un emplacement et permettent aux équipes peering de regrouper le trafic par réseau et par zone géographique. Ce sont des référentiels utiles, non des registres de propriété infaillibles. Les sources de préfixes évoluent, les organisations fusionnent, l’anycast complexifie la géographie et les bases commerciales appliquent des méthodes divergentes. Une étiquette doit conserver suffisamment d’informations sur sa provenance pour que l’analyste puisse la contester.

Le contexte Border Gateway Protocol relie le trafic au plan de contrôle. L’architecture actuelle d’Akvorado prend en charge les informations de routage, notamment des données BGP Monitoring Protocol — BMP. Un préfixe, un pair et un prochain saut permettent d’expliquer quel itinéraire était visible et quelle relation pouvait transporter le trafic. La principale réserve concerne le temps: un instantané de routage recueilli après le flux peut ne pas décrire le chemin choisi lors du passage des paquets.

L’étape d’enrichissement crée de la valeur et de nouvelles formes de preuve. Les métadonnées des équipements décrivent les interfaces locales. Les données de routage décrivent l’état du plan de contrôle. Les bases IP et ASN fournissent des correspondances externes. Les données géographiques estiment un emplacement. Aucun de ces éléments n’est une propriété native du paquet. Akvorado combine les sources pour permettre à l’opérateur de poser de meilleures questions, mais le résultat hérite de l’horodatage et du modèle d’erreur de chacune.

La différence est particulièrement importante lorsque les mêmes informations servent à des activités techniques et commerciales. Une description d’interface obsolète peut être un désagrément lors d’un diagnostic. La même erreur peut faire passer le trafic dans une mauvaise catégorie client ou transit et influencer des calculs, des investissements ou des ventes. C’est au moment de l’enrichissement que le collecteur devient un système opérationnel et qu’une erreur apparemment anodine de métadonnées se transforme en fait organisationnel.

La classification transforme des enregistrements techniques en preuves commerciales

Les réseaux n’inscrivent pas dans chaque paquet un bit « pair », « client » ou « transit ». Ces catégories proviennent des contrats, des relations de routage, de la conception des interfaces et de la politique de l’opérateur. Les classificateurs d’Akvorado peuvent combiner des interfaces, des systèmes autonomes, des préfixes, des communautés BGP et d’autres métadonnées pour attribuer des étiquettes qui rendent le trafic compréhensible sur le plan commercial.

La valeur apparaît immédiatement. Un graphique de charge totale montre le remplissage d’une liaison, mais n’explique pas si la croissance provient de clients payants, de pairs sans règlement, d’un transit amont ou de mouvements internes au cœur du réseau. La classification sépare ces flux et permet de demander quelle relation est à l’origine du changement. L’équipe peering recherche des candidats dont le trafic augmente. Le planificateur décide si un nouveau port, un nouvel itinéraire ou une nouvelle liaison est justifié.

Le classificateur sert aussi de document de politique exprimé dans le code. Une règle qui associe une interface à la catégorie « client » consigne une hypothèse sur la conception du réseau. Une liste de préfixes peut représenter une frontière commerciale. Une communauté BGP peut servir d’indicateur d’une catégorie contractuelle. Lorsque les données d’entrée changent mais pas la règle, le tableau de bord conserve une apparence précise tandis que le sens dérive.

La rigueur de la validation doit correspondre aux conséquences. Les classificateurs destinés à l’exploration interne peuvent être testés de manière informelle. Ceux qui soutiennent des budgets de capacité, des négociations avec des partenaires ou des calculs exigent une gestion des changements, une revue par les pairs et une calibration à partir de données indépendantes. Une petite modification peut reclasser plusieurs mois d’historique ou transformer l’économie apparente d’un itinéraire.

La cohérence historique constitue un autre problème. Si un classificateur change aujourd’hui, les anciens enregistrements doivent-ils conserver l’étiquette appliquée lors de la collecte ou recevoir une nouvelle interprétation? Les deux modèles sont utiles. Le premier préserve la représentation que l’organisation avait à l’époque. Le second permet de comparer les rapports selon la définition actuelle. Le système et l’analyste doivent savoir quelle option est reflétée dans le graphique.

Akvorado rend ces décisions suffisamment visibles pour qu’elles puissent être gouvernées, puisque les règles et les données restent chez l’opérateur. Il ne choisit pas la bonne ontologie commerciale du réseau. La vérification la plus importante du tableau de bord a peut-être lieu hors de l’interface, lorsque les équipes d’ingénierie, de peering et de finance s’accordent sur le sens des catégories.

Le langage proche de SQL réduit la distance entre les données et l’opérateur

Une base de flux n’est utile que si les ingénieurs peuvent poser leurs questions assez rapidement pour influencer l’exploitation. Le SQL direct est puissant, mais il expose les détails du stockage et peut produire des requêtes risquées ou coûteuses. Le langage proche de SQL d’Akvorado propose des conditions, des ensembles et des opérateurs familiers, puis les traduit dans le modèle de requête propre au projet.

Ce langage est important parce que les questions opérationnelles sont itératives. Un ingénieur peut commencer par une interface, puis restreindre la sélection selon le système autonome, la famille d’adresses, le protocole, le port ou la direction. Un analyste peering peut comparer un réseau avant et après une modification de routage. Un intervenant sur incident peut passer d’une hausse générale à une courte liste de nœuds. Une interface proche du vocabulaire métier réduit le délai entre le soupçon et la preuve.

L’abstraction a une limite. Un champ ne peut être interrogé que s’il existe dans la structure de données et s’il est correctement renseigné. Un alias commode peut masquer si la valeur provient de l’exportateur ou d’une base d’enrichissement. Un test d’appartenance à un ensemble peut être rapide ou coûteux selon sa mise en œuvre. Le langage protège l’utilisateur d’une partie de la complexité de la base; il ne rend pas précis un champ mal défini.

L’évolution de la structure de données est l’une des raisons pour lesquelles Vincent Bernat a décrit en 2023 l’utilisation de Protocol Buffers dynamiques. Les formats de flux et l’enrichissement évoluent, tandis qu’une définition de message compilée de manière rigide peut obliger tous les producteurs et consommateurs à être mis à niveau simultanément. Une représentation dynamique transporte les nouveaux champs avec davantage de souplesse et maintient les messages d’inlet compacts.

Les règles de compatibilité, les numéros de champ et la sémantique exigent toujours de la discipline, en particulier tant que d’anciens consommateurs fonctionnent et que des enregistrements plus anciens sont conservés.

L’interface web achève le parcours en transformant les filtres en tableaux et en graphiques. La visualisation est utile, car les personnes remarquent plus vite les déplacements, la périodicité et les valeurs aberrantes qu’en lisant des lignes brutes. Elle crée aussi une fausse assurance. Une courbe régulière peut reposer sur un trafic échantillonné, une file retardée et un classificateur mis à jour. La fenêtre temporelle, l’agrégation et les limites des données doivent être accessibles dans la conception, non cachées derrière la présentation.

Une bonne couche de requête remplit deux fonctions. Elle rend accessibles des données complexes et conserve suffisamment du modèle pour que l’opérateur puisse contester la réponse. La mise en œuvre ouverte d’Akvorado permet aux équipes de vérifier ce chemin. Le fait qu’elles utilisent ou non cette possibilité dépend de leur culture opérationnelle, non de la licence.

La classification donne un sens commercial au volume de trafic

L’analyse des flux prend place dans le réseau lorsqu’elle modifie une décision. La planification de capacité en offre l’un des exemples les plus clairs. Les compteurs d’interface montrent la charge, tandis que l’historique des flux répartit la demande par réseau de destination, région, protocole, catégorie de client et autres dimensions. Ces détails aident à décider s’il faut étendre une liaison existante, ajouter une session de peering, déplacer du trafic ou enquêter sur une variation soudaine.

La décision reste limitée par la chaîne des preuves. Les données échantillonnées peuvent bien représenter un grand flux stable tout en manquant de nombreuses connexions brèves. Un ensemble incomplet d’exportateurs rend une partie du réseau artificiellement silencieuse. Un classificateur peut attribuer la mauvaise relation. Une modification ultérieure du routage brouille l’interprétation si l’ancien état du plan de contrôle n’a pas été conservé. L’utilité pour la planification vient de mesures cohérentes dans le temps, non de la transformation d’un chiffre unique en vérité de facturation.

L’analyse du peering montre la différence entre la joignabilité technique et le sens commercial. Un système autonome qui apparaît souvent dans les données de destination peut être un candidat à une interconnexion directe, mais le volume de trafic ne suffit pas à établir l’avantage mutuel, le lieu, la disponibilité d’un port, la politique ou les conditions contractuelles. Akvorado signale une tendance qui mérite d’être étudiée. La décision appartient toujours aux opérateurs qui comprennent les chemins, les coûts, la résilience et la volonté du partenaire.

Les prévisions de capacité ont une limite similaire. La croissance historique aide à orienter les investissements, mais le lancement d’applications, le départ de clients, les changements de mise en cache et les événements de routage modifient la forme du trafic. Une longue conservation révèle la saisonnalité et les changements structurels, mais ne transforme pas l’avenir en prolongement du passé. L’usage responsable consiste à définir des scénarios et des seuils, non une prévision déterministe unique.

L’historique des flux permet aussi de vérifier si une intervention a fonctionné. Après une modification de politique de routage, les ingénieurs comparent la répartition avant et après l’événement. Si une liaison de transit diminue tandis qu’une liaison de peering augmente, le résultat concorde avec le transfert recherché. Les enregistrements BGP et les compteurs d’interface renforcent l’interprétation. Aucun signal ne prouve à lui seul que chaque paquet a suivi le bon chemin ou que l’expérience utilisateur s’est améliorée.

La valeur d’Akvorado est facile à exagérer comme à sous-estimer. Il n’automatise pas la décision commerciale. Il fournit au réseau un relevé durable et interrogeable des observations sur lesquelles cette décision peut s’appuyer. Dans les organisations où la connaissance du peering et de la capacité réside dans des feuilles de calcul, des scripts ponctuels et la mémoire de quelques personnes, un relevé commun devient lui-même une infrastructure.

L’historique des flux réduit le périmètre d’un incident sans en prouver la cause

Lors d’un incident, le premier avantage des flux conservés est le temps. Les ingénieurs demandent quand le profil a changé, quelles interfaces ont participé, quels nœuds ou systèmes autonomes ont dominé et si l’événement se poursuit. Ces questions réduisent un signalement général de panne ou de saturation à un ensemble plus restreint de systèmes et de relations.

La preuve est plus forte lorsqu’elle est combinée. Les compteurs d’interface confirment l’ampleur de la variation d’une liaison. Les enregistrements BGP ou BMP montrent un événement du plan de contrôle. Les journaux d’un équipement révèlent un redémarrage ou une mise à jour de politique. Une courte capture de paquets apporte des détails. La télémétrie des systèmes d’extrémité indique si l’application a échoué. L’historique d’Akvorado relie les sources par le temps et l’identité réseau, mais ne les remplace pas.

Une forte hausse du trafic ne signifie pas automatiquement une attaque. Elle peut provenir d’une publication populaire, d’une sauvegarde, d’un défaut de cache, d’une modification de routage ou d’une erreur de mesure. Les métadonnées de flux montrent les sources, les destinations, les ports et le volume; elles ne contiennent généralement ni la charge utile de l’application ni l’état du système d’extrémité. L’équipe de sécurité peut identifier des candidats à bloquer ou à examiner plus profondément. L’attribution et l’intention exigent des données supplémentaires.

Un graphique calme peut également induire en erreur. Si l’exportateur s’est arrêté, la disparition des enregistrements peut ressembler à un rétablissement. Si le retard dans Kafka augmente, l’interface affiche un état ancien. Si le classificateur change, le trafic se déplace entre les catégories sans changer sur le réseau. La procédure d’incident doit vérifier explicitement la fraîcheur, la santé des exportateurs, les ruptures de séquence et le retard de la chaîne de traitement avant d’interpréter le trafic.

La conservation reste utile après la fin de l’urgence. Les équipes peuvent reconstituer les minutes précédant le signal, comparer l’événement aux niveaux de référence antérieurs et tester des explications concurrentes. Cette possibilité est particulièrement utile lorsque l’état initial de l’équipement a déjà été écrasé. Le bilan révèle aussi les faiblesses du système de preuve lui-même: interfaces absentes, descriptions SNMP obsolètes, échantillonnage insuffisant ou fenêtre de conservation trop courte.

La formulation correcte pour Akvorado lors d’un incident est « soutient l’enquête ». Il rend la panne plus compréhensible et réduit le périmètre de recherche. Le graphique reste une observation passée par des exportateurs et des métadonnées, non un verdict causal.

Le cas d’un réseau centré sur IPv6 montre la portabilité — et les limites d’un exemple unique

Le 9 avril 2026, APNIC Blog a publié un retour pratique sur l’installation d’Akvorado dans un réseau centré sur IPv6. Ce cas est utile parce qu’il ne provient pas du discours principal du projet et place le logiciel dans un environnement concret. Il montre que la pile peut être adaptée à un réseau où IPv6 occupe une place centrale au lieu d’être ajouté tardivement.

Le poids d’un seul cas reste limité. Il n’établit ni le nombre d’installations actives d’Akvorado, ni sa part de marché, ni un comportement universel avec IPv6, ni son adéquation à chaque opérateur. Les équipements, les exportateurs, le profil de trafic, l’expérience de l’équipe et les objectifs de conservation peuvent différer de ceux d’un grand opérateur, d’une entreprise ou d’un réseau de contenu. Un exemple pratique prouve l’utilisation, non la diffusion.

La portée plus large concerne la portabilité. Akvorado est distribué comme logiciel ouvert et non comme service centralisé. Une équipe externe peut l’installer, connecter ses propres exportateurs, définir ses classificateurs et conserver les données chez elle. Cela distingue le projet d’un outil interne à Free et permet au dépôt d’exister hors de l’environnement qui a contribué à le façonner.

La portabilité met aussi la documentation à l’épreuve. Le projet est plus facile à adopter lorsqu’un opérateur peut comprendre, sans instructions privées, les rôles d’inlet, de Kafka, d’outlet et de ClickHouse. Les documents d’installation ouverts et un environnement de démonstration réduisent le premier obstacle. Ils ne prévoient pas chaque modèle de fabricant, problème d’échelle ou politique de sécurité. Les cas externes montrent où le modèle documenté résiste au contact avec un autre réseau.

Des rapports indépendants supplémentaires renforceraient considérablement les preuves. Les publications utiles préciseraient les types d’exportateurs, la fréquence d’échantillonnage, le volume d’enregistrements, la durée de conservation, les coûts d’infrastructure, les pertes mesurées, l’expérience de migration et la relation entre les estimations de flux et les compteurs d’interface. Elles décriraient aussi les pannes, car une capture d’écran réussie dit très peu sur le fonctionnement sous charge.

Le tableau public de l’adoption d’Akvorado est plausible mais incomplet. L’activité du dépôt, les versions et le cas APNIC montrent un projet vivant, utilisé au-delà d’un seul responsable de maintenance. Ils ne confirment pas le nombre exact d’installations et ne font pas de la pile un choix standard pour l’analyse des flux.

L’auto-hébergement maintient les métadonnées sensibles à proximité

Les enregistrements de flux ne contiennent généralement pas la charge utile des applications, mais ils révèlent beaucoup sur les relations. Les adresses, les ports, les horaires, les volumes et les interfaces montrent quels systèmes ont communiqué, à quelle fréquence et par quelle partie du réseau. Une conservation prolongée transforme ces observations en historique des comportements. Pour un opérateur, une entreprise ou une administration, cet ensemble est à la fois utile et sensible.

Le modèle d’Akvorado permet de conserver la collecte, Kafka, ClickHouse et l’interface web dans une infrastructure maîtrisée. L’opérateur décide où les données résident, combien de temps elles sont conservées, qui peut les interroger et quelles sources d’enrichissement sont utilisées. Il s’agit d’un avantage important pour les équipes qui ne peuvent pas envoyer une télémétrie réseau détaillée à un service externe.

Le contrôle local ne vaut que par les pratiques locales. L’interface web, l’API, les identifiants de la base, l’accès à Kafka et les hôtes sous-jacents appartiennent tous au périmètre de sécurité. Un rôle d’analyste trop large révèle davantage de relations que nécessaire. Les sauvegardes et les répliques conservent les données au-delà de la durée officielle. L’export des résultats déplace les informations sensibles vers des systèmes moins contrôlés.

La conservation doit avoir un objectif. Une histoire agrégée peut suffire à la planification de capacité, tandis que la réponse aux incidents exige des enregistrements plus détaillés pendant une période courte. Une politique unique et illimitée maximise à la fois les possibilités d’enquête et les conséquences d’une fuite. Les niveaux d’accès, l’agrégation, la suppression et l’audit doivent découler des questions auxquelles l’organisation estime légitime et nécessaire de pouvoir répondre.

L’enrichissement ajoute un risque de confidentialité en même temps qu’une valeur opérationnelle. Associer une adresse à une organisation ou à un lieu rend l’enregistrement plus compréhensible et plus facile à détourner. Une correspondance erronée peut orienter les soupçons vers une autre partie. Les analystes doivent voir quels champs proviennent de l’exportateur, des métadonnées internes ou de bases externes.

La licence AGPLv3 donne accès au code selon ses propres conditions, mais elle ne conçoit pas la gouvernance des données de l’organisation. L’auto-hébergement retire un prestataire de la chaîne de stockage. Il ne supprime ni le principe du moindre privilège, ni la maintenance sécurisée, ni les limites de conservation, ni la nécessité de savoir clairement qui peut transformer les métadonnées de trafic en décisions.

La licence ouverte laisse aux opérateurs le coût d’exploitation de la pile

Akvorado ne demande pas de redevance logicielle habituelle lorsqu’il est utilisé selon les conditions de l’AGPLv3. Cette situation attire les opérateurs qui veulent contrôler les coûts, les données et la personnalisation. Elle ne rend pas l’exploitation gratuite. Un déploiement en production consomme des serveurs ou des machines virtuelles, du stockage, de la capacité réseau, du temps de personnel et des astreintes.

Kafka et ClickHouse sont eux-mêmes des systèmes complexes. Leur capacité doit être planifiée, leurs mises à niveau testées et leurs pannes résolues. La couverture des exportateurs exige une maintenance continue à mesure que les équipements et les micrologiciels changent. Les identifiants SNMP et les métadonnées doivent être protégés. Les classificateurs doivent être vérifiés. Les correctifs de sécurité doivent être appliqués. Le coût le plus important peut être le temps d’ingénierie consacré à préserver la fiabilité des preuves.

Des plateformes commerciales comme Kentik répartissent ces coûts différemment. Un service géré regroupe l’hébergement, l’assistance, les intégrations et une surface produit plus large dans un contrat. ElastiFlow et d’autres piles ouvertes ou commerciales choisissent d’autres modèles de stockage, de licence et d’assistance. pmacct, ntopng, FastNetMon, les outils généraux d’observabilité et les systèmes fondés sur les paquets couvrent des parties voisines du problème. La comparaison doit porter sur les modèles d’exploitation et les exigences de preuve, non sur le nombre de fonctions du tableau de bord.

L’opérateur de sa propre installation contrôle mieux les enregistrements bruts, la structure des données, la conservation et la logique des requêtes. Il assume aussi le risque du départ d’un spécialiste, d’une modification de dépendance ou d’une mise à niveau ratée. Le client d’un service géré délègue une partie de l’infrastructure et de l’assistance, en acceptant une dépendance envers le contrat, le lieu de stockage, le prix et la feuille de route du produit. Aucun modèle ne supprime la dépendance; ils la placent différemment.

L’absence d’une entreprise commerciale unique chargée de l’assistance d’Akvorado a son importance. Des consultants peuvent aider certains déploiements, mais les documents étudiés ne montrent aucun acteur garantissant la migration, la réponse aux vulnérabilités ou un niveau de service pour l’ensemble du projet. Une organisation doit décider si elle peut fonctionner seule, conclure un contrat d’expertise ou contribuer suffisamment au projet amont pour réduire son risque.

Le coût total dépend aussi de la valeur de l’historique conservé. Un petit réseau au volume de flux modeste peut fonctionner économiquement sur une infrastructure ordinaire. Un grand opérateur qui conserve des enregistrements détaillés à forte cardinalité devra supporter des coûts importants de disque et de base de données. Le dénominateur utile n’est pas le coût d’un serveur, mais celui de la production de preuves assez fiables pour modifier une décision opérationnelle.

La limite économique est facile à manquer, car les projets à code ouvert ne publient ni chiffre d’affaires ni valorisation. La durabilité d’Akvorado repose sur le travail des responsables de maintenance, le soutien opérationnel de Free, les contributions externes et la volonté de chaque utilisateur d’entretenir les dépendances. Le projet peut créer une valeur considérable en aval sans disposer d’un bilan qui la mesure.

Un projet ouvert peut rester dépendant de quelques responsables de maintenance

Vincent Bernat est le principal initiateur public et responsable de maintenance associé à Akvorado. Le dépôt consigne les contributions d’autres personnes, tandis que les versions, les problèmes et les demandes de fusion rendent le développement visible. Les documents examinés ne font apparaître ni fondation distincte, ni conseil élu, ni organe formel de membres, ni vue complète du financement.

La gouvernance centrée sur le dépôt présente de réels atouts. Les décisions laissent une trace publique. Les utilisateurs proposent des modifications, lisent les discussions et peuvent dériver le code s’ils contestent l’orientation. La licence et le code source offrent une voie de sortie technique qui n’existe pas avec un service fermé. Le projet peut réagir rapidement lorsque les responsables de maintenance partagent un modèle opérationnel clair.

La même structure concentre l’autorité pratique. Les responsables de maintenance décident quelles modifications entrent dans les versions officielles, comment la compatibilité est préservée et quelles erreurs reçoivent de l’attention. La connaissance d’inlet, de la structure dynamique, des classificateurs et des migrations peut résider chez peu de personnes. Une dérivation est juridiquement possible, mais coûteuse sur le plan opérationnel si la communauté qui part ne possède pas ces connaissances.

Le soutien de Free réduit une partie du risque de continuité en reliant le projet à un environnement de production. Il crée en même temps une dépendance envers des priorités qui ne sont pas entièrement publiques. Si les besoins de l’entreprise changent, si les responsables de maintenance changent de rôle ou si le soutien diminue, les utilisateurs externes doivent savoir si la communauté élargie pourra maintenir les versions, la sécurité et les mises à jour des dépendances.

Les projets amont ajoutent une autre couche de contrôle distribué. Kafka et ClickHouse définissent leurs propres trajectoires. Les fabricants modifient le comportement des exportateurs. Les organismes de normalisation font évoluer les travaux sur IPFIX et BMP. Les bases externes changent de structure et de licence. Akvorado peut s’adapter, figer des versions ou remplacer des composants, mais ne peut empêcher ces décisions.

Une gouvernance mature n’exige pas qu’Akvorado devienne une grande fondation. Elle doit rendre la continuité compréhensible. Une politique de publication documentée, un cercle élargi de responsables de maintenance, un processus de sécurité, des engagements de compatibilité et un plan de succession montreraient ce qui arriverait si les relations informelles actuelles étaient mises sous tension. À la date de l’étude, aucun mécanisme public complet de ce type n’existait.

L’ouverture du projet doit être décrite avec précision. Le code et une part importante des décisions sont publics. Le financement, la répartition du temps et la succession sont moins visibles. La transparence réduit la dépendance à la confiance, mais ne supprime pas la dépendance envers les personnes.

Le meilleur tableau de bord montre son dénominateur

La contribution d’Akvorado n’est pas la promesse de voir tout le réseau. C’est un moyen de conserver et d’explorer des observations sélectionnées longtemps après que les équipements qui les ont produites ont changé d’état. Le projet relie les exports des routeurs, les files, l’enrichissement, le stockage et les requêtes sous une forme qu’un opérateur peut vérifier et exécuter lui-même.

Les usages les plus solides acceptent l’incertitude au lieu de la masquer. Les équipes chargées de la capacité suivent des tendances stables et comparent les totaux de flux aux compteurs. Les équipes peering recherchent des relations et vérifient les règles de classification. La réponse aux incidents réduit la période et le périmètre tout en recherchant les données de routage, les journaux, les paquets et les informations des systèmes d’extrémité. Les équipes chargées de la confidentialité conservent les informations localement et limitent les accès et la durée.

Le principal mode de défaillance est d’abord épistémique, puis technique: un graphique propre donne à un dénominateur inconnu une apparence de précision. Des exportateurs absents, l’échantillonnage des paquets, la perte UDP, des consommateurs retardés, d’anciennes informations d’interface et des étiquettes rétrospectives peuvent produire une courbe plausible. Le système est plus sûr lorsque ces conditions sont mesurées à côté du trafic au lieu d’être cachées comme détails de mise en œuvre.

Il s’agit aussi du meilleur test pour la prochaine étape d’Akvorado. La fréquence des versions après la 2.4.1 montrera si l’architecture 2.x reste maintenue. Des déploiements indépendants révéleront le coût des migrations, les pertes de données, la vitesse des requêtes et la charge opérationnelle globale. Un suivi temporel plus précis du routage et des métadonnées renforcera l’analyse historique. Un processus de sécurité et de gouvernance plus large réduira le risque de continuité.

La réussite n’exige pas de remplacer chaque plateforme gérée ni de devenir une norme universelle. Le projet doit rester performant dans une tâche plus étroite: transformer des exports de flux incomplets en mémoire honnête et durable du fonctionnement du réseau. La preuve décisive est de savoir si les opérateurs peuvent remonter d’une ligne à l’écran jusqu’aux équipements, à l’échantillonnage, aux files, aux métadonnées et aux règles, puis expliquer ce qu’elle prouve et ce qu’elle ne prouve pas.