Résumé

  • Le projet de SLA des outils IETF porte sur la performance et la disponibilité des systèmes. Il exclut explicitement la performance de la Tools Team ainsi que l’ordonnancement et la planification de son travail.
  • La consultation UX traite des interfaces, de l’accessibilité, des contrôles d’accès, des exigences côté client et des usages Web, CLI, plugin, API, MCP et hors ligne ; la performance des systèmes relève de la consultation parallèle.
  • Une fiche de décision versionnée peut relier les deux processus en indiquant, pour chaque retour, le service concerné, la mesure, les exclusions, l’autorité de décision, le responsable d’exécution, l’état temporel et le circuit de révision.

Deux textes ouverts ensemble, deux objets à gouverner

Le 17 septembre 2026, l’IETF LLC a sollicité des observations sur deux dimensions des outils de l’IETF, avec une échéance commune au 12 octobre. Les contributions peuvent être adressées en privé au Board et à l’Executive Director, ou publiquement sur la liste tools-discuss. Cette procédure commune ne doit pas masquer la différence de fond.

Le document SLA veut rendre observable un service. Il propose des objectifs de disponibilité, de temps de réponse Web, de délai du courrier et de traitement des incidents. Il classe les systèmes par niveau, pondère les dégradations partielles, définit des exclusions et prévoit des rapports mensuels ainsi qu’une révision annuelle. C’est une réponse à un historique de services fournis en « best efforts », pas une évaluation globale de l’organisation.

Le texte UX s’intéresse au parcours de l’utilisateur. Il examine le Web, la ligne de commande, les plugins, les API, le Model Context Protocol et le fonctionnement hors ligne. Il interroge l’accessibilité, l’authentification, les contraintes des clients, les URL partageables et le niveau de personnalisation attendu. Il place délibérément la performance des systèmes hors de son champ, puisqu’un autre texte la traite.

Cette séparation définit ce que chaque décision pourra prouver. Un chiffre de disponibilité décrit un système, un point de mesure et une période. Il ne prouve pas à lui seul que la Tools Team travaille bien ou mal et ne décide pas quelle fonctionnalité doit être planifiée en premier. Réciproquement, accepter un besoin UX ne démontre pas que le service qui le mettra en œuvre respecte déjà un objectif de disponibilité ou de latence.

La portée exacte de l’horloge de service

Le projet de SLA énonce lui-même sa limite : la performance de la Tools Team, la programmation des tâches et la planification ne font pas partie de l’accord proposé. Ces sujets peuvent mériter une discussion, mais les indicateurs du SLA ne leur donnent pas de réponse légitime.

À l’intérieur du périmètre, l’architecture de mesure est précise. La surveillance automatisée ferait foi pour la disponibilité. Une panne totale pèserait 1, une dégradation majeure 0,5, une dégradation mineure 0,25 et un défaut cosmétique zéro. Les niveaux de service distingueraient les infrastructures critiques des services moins sensibles ou fournis par des tiers. Pour les pages Web, la mesure s’arrêterait côté serveur : rendu du navigateur, réseau de l’utilisateur et certaines dépendances externes n’en feraient pas partie.

Il faut donc publier les exclusions avec le résultat. Maintenance programmée, panne d’un tiers, force majeure, équipement de l’utilisateur et mesure de sécurité délibérée seraient exclus. Une maintenance d’urgence ou une interruption due à un trafic abusif ne disparaîtrait pas automatiquement du calcul. Sans ce contexte, deux pourcentages identiques pourraient décrire des responsabilités très différentes.

Le mécanisme proposé n’est pas punitif. Un écart doit entraîner examen et amélioration, pas indemnité. Le texte rappelle aussi qu’une petite équipe distribuée travaille selon des horaires ordinaires, et non comme un centre d’exploitation permanent. La consultation demande donc de choisir entre niveau de service, coût et capacité opérationnelle ; elle ne crée pas une note de productivité.

Enfin, l’absence d’historique exploitable ne constitue pas un constat de panne. La surveillance existante ne conserve que sept jours de données et ne les exporte pas régulièrement. Cela justifie une discipline de mesure plus durable, pas une accusation sur l’état actuel des outils.

L’horloge UX décide d’autres choses

La consultation UX part d’un problème différent. Les outils ont évolué de façon organique et les choix d’interface ont souvent été faits par les développeurs. Le nouveau site rfc-editor.org a bénéficié de spécialistes, mais aucun processus transversal n’avait encore été formalisé pour recueillir et intégrer l’avis de la communauté sur l’ensemble du portefeuille.

Les réponses attendues sont des arbitrages : faut-il davantage de commandes ou de capacités hors ligne ? Quelle dépendance à JavaScript est acceptable ? Jusqu’où étendre l’authentification unique et la gestion autonome des accès ? Faut-il prévoir des usages directs par l’IA ou MCP ? Où l’intervention de spécialistes de l’accessibilité est-elle nécessaire ?

Chaque choix peut modifier les conditions d’exploitation. Un mode hors ligne peut exiger un jeu de données synchronisé ou une image conteneurisée. Une politique d’accès peut ajouter une dépendance d’identité. Une API ou MCP peut changer les volumes et justifier des clés ou des limites. Mais la conséquence mesurable ne remplace jamais le choix produit qui l’a créée.

Une piste commune sans fusion des états

La Community Engagement Policy de l’IETF LLC fixe déjà un socle : tout retour doit être suivi, incorporé ou accompagné d’un motif clair de non-incorporation ; la communauté doit ensuite être informée de la décision. Les deux consultations offrent l’occasion de rendre cette disposition vérifiable d’un processus à l’autre.

Une fiche publique et versionnée devrait contenir huit éléments : le retour reçu ; le service ou mode d’usage applicable ; l’indicateur et le point de mesure, s’ils existent ; les exclusions ; l’autorité qui tranche ; le responsable de la mise en œuvre ; l’état de priorité et de calendrier ; enfin le rapport ou la révision où le résultat sera contrôlé. Deux lignes liées peuvent partager une référence, mais jamais un statut.

Prenons une demande d’accès hors ligne fiable pendant une réunion. La ligne UX dira si le besoin est accepté, refusé ou reporté, par quelle autorité et avec quelle option de réalisation. Une ligne de service séparée identifiera le fichier, l’API de synchronisation ou l’image à mesurer, ainsi que ses dépendances exclues. « Besoin UX accepté » ne signifie pas « objectif de service atteint ». Un rapport de disponibilité au vert ne prouve pas davantage que le parcours hors ligne existe.

Le versionnage empêche aussi une décision tardive d’effacer la précédente. Un choix UX peut précéder le budget ou le calendrier d’exécution ; une nouvelle charge peut conduire à revoir le niveau de service. Chaque transition doit garder sa date, son auteur institutionnel et sa portée.

Ce registre n’est pas une file de travail universelle. C’est une carte des passages de responsabilité. La mesure reste attachée au système, l’UX à l’usage, et la planification à son propre processus. La transparence consiste à montrer où le retour a changé de voie — et où il n’en a jamais changé.

Sources