Résumé

  • F5 dit que Telenor AI Factory a sélectionné F5 BIG-IP Next for Kubernetes et présente le contrôle du trafic, l’isolation multi-locataire, les politiques d’entrée et de sortie ainsi que la télémétrie comme des capacités utilisables dans le service plane ; l’annonce ne fournit cependant aucun jalon prouvant une mise en production achevée chez Telenor.
  • La gouvernance fondée sur les jetons, les disjoncteurs, l’optimisation plus avancée tenant compte de l’inférence et l’appui aux workflows de droits, de reporting et de facturation sont explicitement présentés comme des étapes prévues pour Telenor. Certaines de ces fonctions existent déjà dans le produit F5 en général, ce qui ne prouve pas qu’elles soient activées dans Telenor AI Factory.

La preuve disponible : une sélection, des capacités et un projet distincts

Le verbe décisif dans l’annonce F5 du 21 octobre est selected. F5 affirme que Telenor AI Factory a sélectionné F5 BIG-IP Next for Kubernetes comme service plane intelligent pour son infrastructure souveraine. Le même texte indique que Telenor « can apply » des politiques, de la visibilité, de l’isolation des locataires et du contrôle du trafic directement sur le chemin des services IA. Il présente ensuite, sans les qualifier de futures, trois familles de fonctions : isolation réseau et multi-location sécurisée ; contrôle du trafic fondé sur des politiques couvrant ingress, egress, interactions API et télémétrie opérationnelle ; observabilité et télémétrie en temps réel pour les opérations, l’auditabilité et le reporting de conformité.

Cette formulation ne doit pas être gonflée en preuve de production. Le communiqué ne donne ni date de mise en service, ni état d’acceptation technique, ni périmètre de clusters effectivement équipé, ni version installée, ni volume de trafic passant par F5. Il ne publie pas davantage de nombre de clients concernés, de contrat commercial, de prix, de revenu, de taux d’utilisation ou de résultat de facturation. F5 ajoute d’ailleurs une clause explicite de déclarations prospectives couvrant les capacités prévues, leur disponibilité et leurs bénéfices attendus pour Telenor AI Factory.

La conclusion soutenable est donc qu’une décision technologique a été annoncée et qu’une architecture cible est décrite, non qu’un déploiement intégral et productif est attesté.

Les propres pages de Telenor donnent le contexte matériel sans fournir cette preuve supplémentaire. Telenor décrit déjà son premier cluster comme offrant des services cloud souverains et sécurisés, avec des NVIDIA H100 GPUs, du bare metal et une interface Kubernetes. Une annonce de juin 2025 indiquait en outre que la Sovereign AI Factory entrait dans une phase d’expansion et que Telenor intégrait NVIDIA AI Enterprise.

Ces éléments établissent qu’une infrastructure IA et un environnement Kubernetes préexistaient à l’annonce F5 ; ils ne documentent pas, dans les pages examinées, l’achèvement ultérieur d’un déploiement de BIG-IP Next for Kubernetes.

La distinction devient particulièrement importante pour les fonctions IA. Dans le communiqué du 21 octobre, F5 classe explicitement parmi les développements planned pour Telenor la gouvernance tenant compte des jetons, les mécanismes de circuit breaking et une optimisation plus avancée du trafic tenant compte de l’inférence. Le texte précise que ces fonctions sont destinées à renforcer le contrôle de la consommation et à soutenir ultérieurement des workflows de droits d’accès ou d’habilitation, de reporting et de facturation.

Cela ne signifie pas que F5 doive encore inventer toutes ces briques dans son produit. Sa documentation technique actuelle décrit déjà le comptage des jetons par utilisateur et par modèle, les limites de consommation, les plafonds de sessions simultanées et l’export de données d’usage vers des systèmes externes de comptage ou de facturation. Elle documente aussi l’identification d’un utilisateur par clé API, en-tête ou adresse IP et la possibilité de refuser une requête lorsque la limite configurée est dépassée.

Même décalage pour le routage d’inférence. Les notes de BIG-IP Next for Kubernetes 2.4.0 décrivent déjà des améliorations d’intelligent AI load balancing fondées notamment sur l’état du cache, la charge des endpoints, les files d’attente, la télémétrie GPU et la santé des endpoints. La version produit possède donc des mécanismes généraux d’optimisation tenant compte de l’inférence ; l’annonce de Telenor dit autre chose : l’usage plus avancé de ces mécanismes dans le service plane de Telenor reste une étape prévue. Capacité d’un produit, choix d’une architecture et fonction activée chez un client sont trois statuts différents.

Pour le circuit breaking, le statut publié concernant Telenor est encore plus simple : F5 le place explicitement dans la catégorie des capacités prévues. Il ne faut donc pas le présenter comme une fonction attestée en exploitation chez Telenor AI Factory sur la seule foi de cette annonce.

Le rôle des NVIDIA BlueField-3 demande la même discipline. La documentation générale de F5 distingue un modèle BNK on DPU dans lequel son Traffic Management Microkernel, ou TMM, s’exécute sur le DPU et prend en charge le traitement et l’application de politiques du trafic L4-L7. F5 décrit ce modèle comme destiné aux charges IA et cloud-native et associe le DPU à un traitement accéléré via NVIDIA DOCA. Le communiqué Telenor explique qu’en faisant fonctionner le data plane de gestion du trafic de F5 sur NVIDIA BlueField-3, certaines fonctions réseau et de sécurité peuvent être accélérées et isolées des charges de l’hôte. Mais aucune mesure Telenor publiée dans ces sources ne chiffre un déport CPU, un gain GPU, un débit, une latence ou une économie. Les bénéfices physiques décrits par le fournisseur ne sont donc pas des résultats économiques mesurés chez Telenor.

La frontière économique : appliquer, isoler et mesurer avant de facturer

L’intérêt économique observable se trouve d’abord dans l’endroit où le contrôle est placé. BIG-IP Next for Kubernetes insère un point d’application dans le chemin du trafic : le TMM traite les flux d’entrée et de sortie, tandis que les contrôleurs Kubernetes traduisent des ressources de configuration en politiques appliquées au data plane.

Dans son modèle Gateway API, F5 sépare en outre trois niveaux de décision : l’opérateur d’infrastructure définit le réseau sous-jacent ; l’opérateur de cluster ou administrateur réseau du locataire définit notamment les paramètres SNAT, ingress et egress propres au locataire ; le développeur ou administrateur du locataire instancie Gateways, EgressGateways et routes applicatives.

Cette hiérarchie donne une réponse concrète à la question « qui contrôle quoi ? ». Le modèle F5 réserve au niveau infrastructure les IPAM, VLAN, VXLAN, VRF, routes statiques et attachements réseau. GatewaySettings porte ensuite des réglages spécifiques aux locataires, et EgressGateway peut déterminer quels pods ou namespaces empruntent une sortie donnée. La documentation précise qu’une configuration distincte peut attribuer à chaque locataire son propre chemin de sortie, son pool SNAT et sa VRF. Ce sont des mécanismes généraux du produit : les sources ne disent pas lesquels Telenor a effectivement configurés ni avec quelle granularité commerciale.

C’est là que l’isolation devient plus qu’une propriété de sécurité. Lorsqu’un locataire possède une identité de namespace, un domaine de routage ou une identité de sortie distincte, le réseau peut conserver la provenance de son activité jusqu’au point de politique. La documentation F5 parle explicitement de per-tenant policy enforcement, logging et egress identity et indique que des identités de sortie propres aux namespaces donnent aux systèmes en amont une attribution auditable du trafic applicatif. Ce mécanisme peut produire une frontière d’attribution ; il ne produit pas encore une facture.

La télémétrie renforce cette frontière. Le dispositif TODA de F5 stocke les données métriques par namespace, pod et table ; les métriques conservent un label de namespace afin d’assurer leur traçabilité. Dans le modèle tenant-aware, chaque locataire ou namespace peut sélectionner les métriques qu’il collecte, leur fréquence, leurs labels et leur mode d’agrégation, tandis que l’administrateur de cluster définit les namespaces et métriques auxquels chaque locataire peut accéder. Les résultats passent ensuite vers OpenTelemetry.

Pour un opérateur d’AI Factory, ce placement ouvre trois catégories de comptabilité possibles sans qu’elles soient pour autant déjà réalisées chez Telenor. Le trafic réseau peut être attribué par namespace, identité de sortie, connexion, paquets ou octets exposés dans la télémétrie ; l’application des politiques de sécurité peut être reliée à des contextes de locataires distincts ; la collecte d’observabilité elle-même peut être différenciée par métriques sélectionnées, cadence de scrape et volume exporté.

La documentation F5 montre les identités et contrôles nécessaires à une telle séparation mais ne publie aucun modèle Telenor qui transforme ces mesures en coûts monétaires de réseau, de sécurité ou d’observabilité.

C’est la différence entre mesurabilité et costing. Savoir qu’un namespace a généré un certain trafic ou demandé une certaine fréquence de métriques ne dit pas quel montant comptable lui affecter. Il faut encore décider quels coûts sont fixes ou variables, quelles dépenses restent mutualisées, comment répartir les licences, l’exploitation, le stockage ou la collecte, et si l’on facture l’usage brut, le service fourni ou un droit d’accès. Aucun de ces paramètres n’est publié pour Telenor dans les sources examinées. Les documents permettent d’identifier des dimensions techniques d’attribution ; ils ne donnent ni structure des charges ni méthode d’allocation financière.

L’espoir de ne pas « créer une nouvelle couche de dépenses » doit être évalué avec la même rigueur. La documentation d’installation de F5 montre que BIG-IP Next for Kubernetes constitue bien une couche produit à gérer : le cluster doit être licencié au moyen d’un JWT associé à une souscription F5, et l’installation comporte notamment des opérateurs, des contrôleurs, le TMM, des composants de télémétrie et un OpenTelemetry Collector. Rien dans ces documents ne permet toutefois de connaître le prix payé par Telenor, son modèle contractuel ou le coût humain de l’exploitation.

L’intégration de plusieurs fonctions dans le même service plane pourrait éviter certaines duplications architecturales en principe : politique de trafic, isolation, sécurité et télémétrie utilisent le même contexte Kubernetes et la même frontière de data plane. Mais aucune source Telenor ou F5 citée ici ne montre que Telenor ait retiré d’autres systèmes, réduit des dépenses ou supprimé des équipes grâce à cette sélection. Affirmer une économie nette serait donc aller plus loin que les faits publiés.

Le cas du comptage des jetons illustre précisément la différence. F5 dispose dans le produit d’un mécanisme qui compte les jetons d’entrée et de sortie, associe l’usage à un utilisateur ou un modèle, maintient des compteurs et peut transmettre ces données par High Speed Logging à un outil externe de metering ou de facturation. C’est une brique techniquement adaptée à un futur ledger de consommation. Mais l’annonce Telenor classe encore la gouvernance token-aware et l’appui aux workflows de reporting et de billing dans les capacités prévues.

Aucun résultat public n’établit qu’une facture Telenor est aujourd’hui calculée depuis ces compteurs, ni que leur activation réduira le coût total de service.

Cette distinction modifie la lecture financière de la décision. F5 et Telenor ont choisi un endroit où les décisions futures pourront être rendues exécutables et observables : avant que la requête n’atteigne les ressources d’inférence, le service plane peut connaître l’identité technique, appliquer une route ou une politique, isoler un domaine et produire de la télémétrie. Dans une infrastructure partagée, c’est une condition utile pour transformer des ressources mutualisées en services différenciés. Mais la condition n’est pas le résultat. La publication du 21 octobre documente la création d’une frontière de contrôle ; elle ne démontre ni la marge qu’elle génère, ni les économies qu’elle produit, ni la volonté des clients de payer pour les catégories qu’elle permettrait de mesurer.