Résumé

  • Dans son rapport daté du 1er septembre, le directeur exécutif de l’IETF indique que le rapport 2025 sur le sponsoring a été publié et distribué aux sponsors.
  • Cette deuxième édition comporte des études de cas sur JMAP et L4S ; leurs informations constituent, selon le rapport, un élément central du « Living Case for Support » demandé par le conseil de l’IETF LLC.
  • La page publique des réussites de l’IETF avance notamment plus de dix millions d’utilisateurs raccordés à des réseaux d’accès capables de prendre en charge L4S fin 2025 et cite plusieurs mises en œuvre ou déploiements de JMAP.
  • Une spécification publiée, un logiciel compatible, une fonction livrée, une activation par défaut, un usage observé et un bénéfice mesuré sont six affirmations différentes.
  • RFC 8711 confie la collecte de fonds à l’IETF LLC tout en lui refusant toute autorité sur l’élaboration des normes. RFC 3935 rappelle qu’une norme IETF n’impose pas son adoption.
  • Chaque version du dossier de soutien devrait citer un registre public et cumulatif : version du protocole, classe d’affirmation, période, unité, dénominateur, méthode, relation de la source, incertitude et corrections.

Le passage discret du récit à l’infrastructure

Quelques lignes du rapport préparé pour la réunion du conseil de l’IETF LLC du 3 septembre méritent plus d’attention que ne le laisse penser leur place dans la rubrique « Fundraising ». Le directeur exécutif y annonce que le rapport 2025 sur le sponsoring a été publié et envoyé aux sponsors. Il précise que les cas JMAP et L4S représentent une amélioration de présentation par rapport à la première édition et que leur contenu forme une pièce centrale du dossier de soutien évolutif demandé par le conseil.

Le mot « évolutif » change la nature du document. Il ne s’agit plus seulement de raconter, une fois, pourquoi l’IETF compte. Le même matériau pourra alimenter une présentation à un donateur, une page publique, un prochain rapport ou une discussion budgétaire. Le récit devient un actif administratif réutilisable. À chaque reprise, la distance augmente entre l’observation initiale et le lecteur final.

Il serait absurde d’interdire à l’IETF de parler des protocoles effectivement utilisés. Le budget adopté pour 2026 prévoit 1,58 million de dollars de sponsoring et 140 000 dollars d’apports en nature sur environ 14,01 millions de recettes totales. Ce sont des prévisions, non des encaissements constatés. Elles suffisent néanmoins à montrer que le sponsoring est une ligne importante et que l’IETF LLC doit expliquer la valeur de l’institution qu’elle finance.

Une étude de cas est plus parlante qu’un tableau de coûts. Mais elle concentre aussi les risques d’interprétation. Le mot « succès » peut désigner la publication d’un RFC, l’existence d’un code, une offre commerciale, une fonction activée, un trafic réellement observé ou un résultat utile pour l’utilisateur. Si ces états ne sont pas conservés séparément, le dossier le mieux présenté finit par effacer l’origine de ce qu’il affirme.

La bonne question n’est donc pas de savoir si l’IETF doit lever des fonds. Elle est de savoir si la preuve reste lisible après avoir été mise au service de cette levée.

Dix millions de quoi, et à quelle date ?

La page publique « IETF success stories » donne une matière concrète. Elle affirme qu’à la fin de 2025, plus de dix millions d’internautes se trouvaient sur des réseaux d’accès compatibles avec L4S, avec une croissance attendue en 2026 et 2027. Pour JMAP, elle énumère plusieurs services et serveurs qui l’utilisent en production, puis distingue des déploiements en cours et des extensions envisagées.

Ces informations sont pertinentes. Leur diversité doit cependant être visible. Un réseau « capable » ne signifie pas que chaque terminal et chaque application négocie L4S. Un logiciel qui implémente JMAP ne prouve pas que tous les comptes hébergés l’emploient. Une fonction livrée n’est pas forcément activée. Une feuille de route n’est pas une observation. Un nombre d’abonnés éligibles, de lignes provisionnées, de terminaux actifs ou de flux mesurés ne partage pas le même dénominateur.

Sur la page examinée, le chiffre L4S et les affirmations nominatives sur JMAP ne renvoient pas chacun à une fiche indiquant méthode, période, unité et jeu de données. Cela ne permet pas de conclure que les sources n’existent pas. Un opérateur peut disposer de mesures sensibles, et le rapport envoyé aux sponsors peut contenir des références absentes de la page. Le constat est plus limité : le lecteur public ne peut pas reconstruire, depuis cette page, la catégorie probatoire de chaque proposition.

Les textes techniques de l’IETF eux-mêmes fournissent un antidote à la confusion. RFC 5218 sépare la finalité d’un protocole de l’échelle qu’il atteint ; son cadre de réussite inclut à la fois l’accomplissement des objectifs et un large déploiement. RFC 8170 recommande, pour une transition, de comprendre l’existant, d’expliquer les incitations, de distinguer les phases, de choisir une mesure et de préparer les échecs. Il reconnaît qu’un protocole observable par négociation ne se mesure pas comme une fonction interne ou une option silencieuse.

Ces RFC ne valident ni les chiffres actuels de L4S ni la liste actuelle de JMAP. Ils montrent plutôt pourquoi l’étiquette « adopté » doit toujours être suivie d’une phrase supplémentaire : adopté où, par quoi, dans quel état et selon quelle observation ?

Deux mandats qui ne doivent pas se fondre

La séparation institutionnelle existe déjà. RFC 8711 charge l’IETF LLC des opérations, du budget et de la collecte de fonds. Le même texte dit explicitement qu’elle n’a aucune autorité sur les activités de développement des normes de l’IETF. Le conseil et le personnel peuvent donc conclure des contrats, construire un argument de financement et rendre compte des recettes sans se transformer en organe technique.

RFC 3935 trace l’autre côté de la frontière. Une norme IETF explique comment faire quelque chose si un acteur veut se conformer à cette norme. Elle ne cherche ni à imposer l’usage ni à le contrôler. L’adoption est produite par des opérateurs, des développeurs, des fournisseurs et des utilisateurs ; l’expérience de ce code nourrit ensuite le jugement d’ingénierie.

Le cas de soutien peut donc employer l’adoption comme preuve de pertinence sans en revendiquer la propriété. De même, une entreprise qui fournit des données de déploiement ou finance l’IETF ne devient pas propriétaire du résultat normatif. Son intérêt doit être déclaré parce qu’il aide à lire la source, non parce qu’il prouverait à lui seul une capture.

Les documents de soutien publiés en 2023 insistaient déjà sur l’impossibilité d’acheter un siège, un contrôle ou un résultat technique. Un registre d’adoption renforcerait ce principe. Il montrerait, par la structure des données, que financement, implémentation, mesure et décision normative sont quatre actes distincts, même lorsqu’ils impliquent les mêmes noms.

Un registre mince, pas un nouveau certificateur

Le rapport destiné aux sponsors n’a pas besoin d’embarquer des téraoctets de télémétrie. Il lui faut un identifiant stable pour chaque affirmation importante et un lien vers l’instantané public utilisé lors de sa rédaction.

La fiche commencerait par la spécification exacte et sa version. Elle classerait l’affirmation : mise en œuvre, test d’interopérabilité, fonction livrée, fonction activée, usage actif, exposition d’utilisateurs ou bénéfice mesuré. Elle préciserait la date d’observation, la fenêtre de mesure, l’unité, le numérateur, le dénominateur, la portée géographique ou commerciale, la méthode et le détenteur des données.

Une rubrique distincte indiquerait si la mesure a été reproduite de manière indépendante. Une autre décrirait la relation de la source : implémenteur, sponsor, donateur, bénéficiaire, projet de mesure indépendant ou personnel de l’IETF. Les rôles peuvent se cumuler. L’objectif n’est pas d’écarter les sources intéressées ; les opérateurs connaissent souvent mieux que quiconque leur propre déploiement. Il s’agit de rendre l’intérêt visible et de ne pas obliger le lecteur à le deviner.

L’incertitude doit être un champ normal, non une note honteuse. Une estimation de portée peut être la meilleure information disponible. Elle doit simplement dire si elle compte des lignes capables, des comptes, des appareils ou des flux. Une annonce de produit peut rester une annonce jusqu’à ce qu’une observation la remplace. Une liste de mises en œuvre peut rester une preuve d’existence sans devenir artificiellement une part de marché.

Enfin, les corrections doivent s’ajouter au registre. Si un dénominateur est révisé ou si un fournisseur clarifie l’état d’activation, l’ancienne entrée doit rester visible avec un lien vers la nouvelle. Chaque édition du rapport conserve ainsi le jeu de faits qu’elle a réellement cité. Les données nouvelles n’améliorent pas rétroactivement la provenance d’une affirmation ancienne.

Ce mécanisme doit rester étroit. Il ne certifie pas les produits, ne classe pas les donateurs, ne décide pas du statut d’un RFC et ne publie pas de données commerciales confidentielles. Des agrégats peuvent protéger les clients tout en conservant méthode, unité et relation. Son seul pouvoir est de rendre une proposition vérifiable.

La distinction de Lu Heng s’applique ici sans détour : une preuve peut éclairer une décision sans devenir une autorité. Une publication ne crée pas le déploiement, un financement ne crée pas le mandat et un récit institutionnel ne crée pas la réalité technique. L’IETF LLC peut défendre la nécessité de son financement ; les systèmes en fonctionnement demeurent la source du fait d’adoption.

Un dossier vivant doit pouvoir changer. Mais il ne doit pas faire disparaître l’ascendance de ses chiffres. Le registre permettrait à l’IETF de raconter une histoire convaincante tout en laissant chaque lecteur revenir à la date, à la méthode et au propriétaire légitime de la preuve.

Sources

  1. IETF — Rapport du directeur exécutif pour la réunion du conseil du 3 septembre 2026
  2. IETF — Success stories
  3. IETF — Why we need your support
  4. IETF — Supporting the technical foundations of business
  5. IETF — Financial supporters
  6. IETF Administration LLC — Budget 2026
  7. RFC 8711 — Structure of the IETF Administrative Support Activity, Version 2.0
  8. RFC 3935 — A Mission Statement for the IETF
  9. RFC 5218 — What Makes for a Successful Protocol?
  10. RFC 8170 — Planning for Protocol Adoption and Subsequent Transitions
  11. IETF — Endowment Case for Support, novembre 2023
  12. IETF — Case for Support, septembre 2023
  13. Lu Heng — The Multi-Stakeholder Mirage