Résumé

  • La mise à jour d’août 2026 recense des milliers d’issues GitHub anciennes — environ 1 100 pour Datatracker à titre d’exemple — dont la plupart ne sont ni reliées à une structure de travail ni évaluées en effort ou en priorité.
  • Le plan prévoit de les ranger selon Goal -> Project -> Epic -> Task, d’estimer les tâches au niveau le plus bas, puis de fixer une première priorité au niveau des Goals et Projects avant une consultation dont le mécanisme restait à définir.
  • L’existence d’une issue publique atteste une demande enregistrée. Elle n’atteste ni validation, ni acceptation, ni financement, ni programmation, ni promesse de l’IETF.
  • Un reçu public reliant issue, classement, estimation, priorité, consultation et sort final peut rendre la décision contrôlable sans ouvrir les notes ZenHub, les vulnérabilités, les contrats ou l’évaluation individuelle des développeurs.

Une demande visible, une décision introuvable

L’issue Datatracker no 9204 paraît presque triviale. Elle demande que la fonction de Designated Expert apparaisse sur la page personnelle de la personne concernée. Ouverte en juillet 2025, elle était encore marquée open à la date d’observation. Sa page publique n’affichait ni assignee, ni project, ni milestone, ni relationship, ni branche, ni pull request.

Ces cases vides ne prouvent pas l’inaction. Elles prouvent une chose plus étroite : la vue publique GitHub ne permet pas de suivre le passage de la demande vers une décision institutionnelle. La mise à jour d’août montre ce que la fiche ne montre pas. Il faudrait fournir à l’IANA une spécification d’API, modéliser plusieurs formes de Designated Expert — personne, rôle d’Area Director, liste ou ensemble de chairs —, rapprocher les données IANA et Datatracker, puis organiser un import en continu.

La petite modification d’interface devient un Project composé d’epics, rattaché à un Goal sur l’exactitude et l’exhaustivité du registre du processus, des rôles et des contributions.

Voilà pourquoi « environ 1 100 issues » n’est pas « environ 1 100 unités de travail prêtes à être exécutées ». Une fiche peut être un doublon. Une autre peut avoir été absorbée par un projet plus large. Une troisième peut cacher un risque de sécurité. Une quatrième peut dépendre d’un contrat de données externe. Une cinquième peut être facile à coder mais coûteuse à exploiter pendant dix ans. Le nombre donne l’échelle du problème ; il ne fournit ni son dénominateur utile ni son ordre de traitement.

Les sept verbes d’un backlog gouverné

Enregistrer n’est pas valider. Valider n’est pas accepter. Accepter n’est pas estimer. Estimer n’est pas prioriser. Prioriser n’est pas autoriser une dépense. Autoriser n’est pas livrer. Livrer n’est pas nécessairement clore : une correction, une migration ou une substitution peut encore suivre.

L’interface open/closed écrase ces verbes. Pour l’auteur d’une demande, open peut ressembler à une promesse faible : l’institution connaît le besoin et finira peut-être par le traiter. Pour l’équipe, open peut signifier seulement que le point d’entrée n’a pas été fermé. Tant que la différence n’est pas publiée, chacun remplit le silence avec sa propre attente.

La mise à jour d’août est prudente. Elle parle de milliers d’issues, dont presque toutes restent individuelles, sans structuration et sans évaluation de l’effort ou de la priorité. Elle ne dit pas que chacune est valable, actuelle, indépendante ou soutenue par un large public. Elle ne dit pas non plus qu’une issue ancienne possède un droit d’antériorité.

Il serait tout aussi trompeur de conclure qu’aucune explication n’est due parce qu’une issue n’est pas une promesse. Le contributeur doit pouvoir distinguer une demande encore non examinée, une demande confirmée mais différée, un doublon, une demande hors périmètre et une demande reprise ailleurs. La transparence de l’entrée, sans transparence du sort, ne réduit pas l’opacité de l’allocation ; elle la rend plus visible.

Le premier défaut de la roadmap était déjà le raccord

En décembre 2025, la Tools Team a expliqué pourquoi elle avait retiré la roadmap précédente. Les projets couvrant plusieurs trimestres avaient été découpés en phases sans décrire clairement le contenu de chaque phase. Des Goals organisationnels et des Projects très détaillés occupaient le même plan. Surtout, les projets de la roadmap n’étaient pas reliés aux issues des dépôts GitHub de chaque outil.

Le cadre de remplacement utilisait un projet GitHub en lecture seule, maintenu par la Tools Team. Il séparait les Goals des Projects et demandait au public si cette structure répondait à ses besoins, si le niveau de détail permettait de comprendre et d’influencer le plan, et si les bons objectifs pour 2026 avaient été retenus. La lecture seule n’annule pas la consultation : elle protège l’intégrité du plan officiel tout en laissant les commentaires passer par un canal identifié.

Le dispositif n’a pourtant pas encore fourni un état complet. En février 2026, le rapport public de l’Executive Director a relevé une participation relativement faible à l’appel consacré à la roadmap. Les participants présents soutenaient l’approche, mais le rapport jugeait nécessaire d’élargir l’engagement. Une faible participation ne constitue ni un rejet ni un mandat représentatif ; le nombre total de personnes exposées ou empêchées n’est pas connu.

En mars, un participant a demandé où voir si un élément annoncé pour le premier trimestre avançait comme prévu ou prenait du retard. Sa question ne vaut pas consensus communautaire. Elle révèle néanmoins une ambiguïté précise : un objectif temporel sans état courant peut être pris pour un engagement plus ferme qu’il ne l’est.

En avril, la roadmap a été mise de côté pendant le déploiement de la modernisation du RFC Production Center. En juin, elle n’avait toujours pas été actualisée ; la planification et l’engagement devaient être discutés lors de la retraite de mi-juin. Rien ne prouve ici un abandon. La séquence montre au contraire ce qu’une roadmap doit rendre explicite : un projet opérationnel pluriannuel peut légitimement absorber la capacité qui aurait servi à améliorer la roadmap elle-même.

Classer, estimer, prioriser : trois actes

La première phase annoncée en août est un travail de classement. Après l’IETF 126 à Vienne, l’équipe devait se concentrer pendant trois semaines sur la revue des issues et leur organisation selon Goal -> Project -> Epic -> Task. L’essentiel du travail se déroule dans l’instance ZenHub privée de la Tools Team, avec l’intention de relier le résultat aux dépôts publics. Les urgences peuvent être repérées dès ce stade, mais la plupart des fiches ne doivent pas encore recevoir d’estimation ou de priorité. Le rapport prévient en outre que trois semaines risquent de ne pas suffire.

La deuxième phase porte sur le niveau d’effort. Le développeur le plus susceptible de réaliser la Task la plus basse fournit l’estimation initiale. L’équipe vérifie la cohérence des échelles par estimation poker. Les efforts des niveaux supérieurs sont additionnés à partir des tâches, et une tâche trop grande est divisée. Une telle estimation n’est ni une note individuelle, ni une réservation de capacité, ni une date promise.

La troisième phase porte sur la priorité. Elle doit en général se fixer au niveau Goal et Project. La Tools Team réalise une première passe, qui sert de point de départ. La communauté peut ensuite réagir selon un mécanisme encore indéterminé au 6 août. La première passe n’est donc pas un verdict communautaire, et les réactions futures ne seront pas, par nature, un vote de budget.

Séparer ces actes empêche les glissements de sens. Classé ne veut pas dire accepté. Estimé ne veut pas dire programmé. Prioritaire au niveau d’un Project ne veut pas dire que chaque Task est prête. Une date de roadmap ne devient pas une norme. Une décision administrative de la Tools Team ne devient pas un rough consensus technique de l’IETF.

Consulter sans compter les applaudissements

Les utilisateurs ont des connaissances que l’équipe ne peut pas fabriquer seule. Datatracker soutient les documents, les Working Groups, les reviews, les ballots, les réunions et les rôles. Les autres services soutiennent le courrier, la production des textes et les archives RFC. Un mauvais choix d’outillage peut donc modifier le coût réel de la participation au processus de normalisation.

Mais une consultation ouverte ne crée pas automatiquement un électorat. Les personnes qui ont élaboré un contournement se plaignent parfois moins que les nouveaux arrivants. Une fonction visible recueille davantage de réactions qu’une migration de framework, une mise à niveau de sécurité ou un travail de cohérence des données. Les maintenances silencieuses peuvent être plus importantes que les nouveautés populaires.

Le mécanisme de feedback devrait demander des catégories de preuve : workflow touché, fréquence, gravité, rôle concerné, contournement disponible, conséquence pour la continuité, échéance externe et lien documentaire. Il devrait ensuite publier un sort : reclassé, accepté mais différé, couvert par un autre Project, hors périmètre, restreint pour raison de sécurité ou maintenu à son rang, avec une justification bornée.

Cette méthode reconnaît l’influence de la communauté sans transformer le nombre de commentaires, de réactions ou de participants à une réunion en pouvoir de programmation. Le feedback informe la décision ; il ne remplace pas l’autorité qui doit assumer les dépendances, les contrats et le fonctionnement du service.

Le reçu de disposition

Pour chaque issue publique, le reçu devrait rappeler l’issue source et sa date de création, puis indiquer la dernière date de triage et le rôle responsable. Son état de validité distinguerait : clarification nécessaire, confirmée, doublon, remplacée, hors périmètre, sensible pour la sécurité ou close.

Il relierait, quand la publication est sûre, les identifiants publics des Goal, Project, Epic et Task. Les dépendances et catégories de blocage seraient visibles. L’effort apparaîtrait sous forme de fourchette ou de classe, avec une date et un degré de confiance. « Pas encore estimé » est une information ; une cellule vide est une invitation à l’interprétation.

La priorité aurait elle aussi une classe, une date, un détenteur d’autorité et une raison courte, ou l’état explicite « pas encore priorisé ». Le volet communautaire préciserait la fenêtre, le canal, les preuves demandées, les limites du dénominateur et la manière dont les contributions ont ou non modifié la décision.

Un état de roadmap et une fourchette de cible ne seraient affichés qu’après autorisation réelle. Les liens vers l’implémentation, la release, la clôture, la substitution et la correction compléteraient la chaîne. Une correction ajouterait ou remplacerait un état sans effacer l’historique.

Ce reçu doit être une projection du système de planification, pas un troisième backlog édité à la main. Sinon GitHub, ZenHub et la roadmap publique divergeront, et la couche créée pour expliquer la décision deviendra une nouvelle source d’ambiguïté.

Ce que la transparence ne demande pas

Il n’est ni nécessaire ni prudent d’ouvrir l’intégralité de ZenHub. Les notes internes peuvent contenir des hypothèses, des vulnérabilités, des chemins d’exploitation, des données personnelles, des éléments contractuels ou des charges individuelles. Une estimation nominative publiée comme mesure de performance inciterait à gonfler les chiffres et détériorerait l’outil de planification.

Une issue sensible peut publier son état restreint, le rôle qui possède la prochaine étape et la date de la prochaine mise à jour sûre, sans révéler la faille. Une dépendance contractuelle peut être qualifiée de blocage d’achat ou de service externe sans reproduire les clauses. L’effort rendu public peut être la fourchette calibrée par l’équipe, non le jugement porté sur une personne.

Le reçu ne devient pas une autorité supplémentaire. La Tools Team conserve la première passe de priorité annoncée en août. L’Executive Director et l’IETF LLC conservent leurs responsabilités administratives, contractuelles et de ressources ; le Board conserve la supervision stratégique. La communauté apporte des preuves et conteste des raisons. L’autorité sur les standards techniques reste dans les procédures de l’IETF. Le registre montre ces frontières, il ne les redessine pas.

Sources

  1. August Tools Update
  2. Introducing a new roadmap framework
  3. Public Executive Director Report, 18 February 2026
  4. March tools update discussion
  5. IETF tools update 2026-04
  6. June tools update
  7. The Tools Team
  8. Tools Architecture and Strategy Team
  9. RFC 8711
  10. IETF Administrative Strategic Plan 2020
  11. Datatracker issue #9204