Résumé

  • La RFC 8890 demande de privilégier les utilisateurs finaux humains lorsque leurs intérêts s’opposent à ceux d’autres acteurs, mais elle n’accorde à l’IETF, aux gouvernements, aux défenseurs de la société civile ou aux participants consultés aucun droit automatique de les représenter tous.
  • Selon la RFC 9110, l’agent utilisateur est le programme client qui émet la requête HTTP. Il peut isoler un service, appliquer une préférence et restreindre une capacité sans prouver la présence, le consentement éclairé ou le mandat de la personne concernée.
  • Toute prétention à « représenter les utilisateurs » doit être remplacée par une chaîne vérifiable : groupes touchés, mécanisme de bénéfice ou de dommage, portée de la consultation, choix et défaut, pouvoirs du logiciel, solutions de remplacement, coût de sortie et résultat observé.

Une requête HTTP peut parfaitement voyager sans personne devant l’écran. Un rafraîchissement automatique se déclenche, un robot parcourt une page, une application synchronise un compte ou un appareil contacte un service. Dans tous ces cas, la RFC 9110 donne un nom au programme qui prend l’initiative : l’agent utilisateur.

Le mot « agent » invite à lui prêter une seconde fonction. Puisqu’il agit pour un usage, ne parlerait-il pas aussi au nom de l’utilisateur ? Et puisque ses règles sont élaborées par des ingénieurs, ceux-ci ne sauraient-ils pas ce que veulent les utilisateurs ? Mark Nottingham construit la RFC 8890 autour d’une réponse plus exigeante. L’Internet doit être conçu en priorité pour les utilisateurs finaux, mais nul n’obtient par cette phrase la procuration de tous.

Le texte ne résout pas la tension entre priorité et représentation. Il en fait une discipline : identifier les humains affectés, démontrer les mécanismes d’impact et garder visibles les limites de celui qui prétend les connaître.

Le rôle protocolaire s’arrête au programme client

La définition de la RFC 9110 porte sur une action observable : le client initie une requête. Le terme couvre le navigateur, la ligne de commande, le robot d’indexation, l’application mobile, l’équipement domestique et le script. Il ne garantit ni une personne présente, ni un utilisateur unique, ni une décision contemporaine.

Cette prudence interdit d’extraire une volonté humaine d’un simple message. Un appareil partagé applique parfois un réglage à plusieurs personnes. Un poste administré fait prévaloir la politique de l’employeur. Une tâche de fond réutilise une autorisation donnée dans un autre contexte. Un outil d’accessibilité transforme la page sans que le service comprenne l’intérêt qu’il protège.

Une trace réseau peut établir quel logiciel a parlé, quelle configuration était active et quelle préférence a été transmise. Pour remonter jusqu’à la personne, il faut d’autres reçus : qui a choisi le programme, qui pouvait modifier le réglage, qui subit l’effet et à quelle fin le pouvoir avait été confié.

L’agence protocolaire n’est donc pas une agence politique. Le logiciel reçoit une capacité technique circonscrite ; il ne devient pas le principal dont il sert l’activité.

L’utilisateur de la RFC 8890 peut ne jamais envoyer la requête

La RFC 8890 place au centre l’être humain dont l’activité est soutenue par l’Internet. Cet humain peut être indirectement touché : personne photographiée par une caméra connectée, visiteur d’un espace équipé de capteurs, destinataire d’une décision automatique. La maîtrise du protocole ou de l’appareil ne définit pas sa qualité d’utilisateur final.

Ces personnes ne forment pas un électorat homogène. Une même personne devient tour à tour lectrice, éditrice, acheteuse, vendeuse, consommatrice et petite fournisseuse de service. La confidentialité, la sécurité, l’accessibilité, le prix et la portée ne s’alignent pas toujours. Ce qui réduit le risque pour l’un peut transférer du travail ou de l’exclusion à l’autre.

La formule « les utilisateurs veulent » manque donc son premier objet tant que la population, le rôle et la situation ne sont pas nommés. La RFC va plus loin : l’IETF ne possède pas une intuition privilégiée du bien des utilisateurs et ne doit pas généraliser l’expérience de ses propres participants. Une personne financée par un gouvernement ne représente pas automatiquement les citoyens de sa juridiction. Un spécialiste de la société civile apporte une expertise sans nécessairement disposer d’un mandat collectif. Même une consultation ciblée ne garantit pas formellement la représentativité.

La priorité est une règle de décision lorsqu’un conflit est constaté. La représentation est une relation d’autorisation entre un principal et un agent, avec périmètre et responsabilité. Les deux notions doivent rester dans des colonnes séparées.

Une frontière logicielle ne devient pas une voix collective

La RFC 8890 décrit les agents utilisateurs comme des représentants imparfaits, mais structurellement utiles. Un site n’obtient généralement pas un accès arbitraire à la machine. Le navigateur lui présente un environnement contraint, met le code en bac à sable, arbitre certaines permissions et peut refuser une capacité. Il déplace une part du contrôle vers le bord.

Il faut résister à la tentation de faire de ce succès une garantie générale. Un bac à sable empêche une intrusion directe sans supprimer la surveillance. Une demande d’autorisation offre un refus, mais sa répétition peut fabriquer l’acceptation. Une extension protège un usage et ajoute parfois une surface d’attaque. Un éditeur peut défendre les personnes tout en renforçant sa propre position de distribution.

L’unité de preuve est chaque contrôle : quel intérêt protège-t-il, contre quel pouvoir du service, pour quelle origine, pendant combien de temps, avec quel état initial et quelle possibilité de révocation ? Sa mise en œuvre est-elle observable ? Une réponse favorable ne vaut que pour cette question.

La RFC 6973 distingue utilement participation, consentement, expression d’une préférence, minimisation des données et sécurité. Un signal de préférence n’établit pas la préférence entière. Le reçu doit dire qui l’a fixé, s’il était présélectionné, à qui il est envoyé, combien de temps il persiste et comment sa mise en œuvre est vérifiée.

Le logiciel peut transmettre fidèlement ce que l’interface permet d’exprimer. Il ne peut déduire une autorisation sur les intérêts que l’interface n’a jamais demandés, ni parler pour les personnes affectées en dehors de la requête.

Le préjudice est un problème à instruire, non une majorité à compter

La RFC 8890 ne définit pas automatiquement l’impact négatif sur les utilisateurs finaux. Le groupe compétent doit examiner la causalité avancée et parvenir à une conclusion. Affirmer sans preuve qu’une proposition nuit aux utilisateurs ne suffit pas. Refuser d’identifier un dommage parce que son porteur est isolé ou ne dispose pas d’un sondage ne suffit pas davantage.

La RFC 7282 explique que le consensus approximatif traite des problèmes plutôt que des personnes. Un hum indique l’état d’une salle et peut ouvrir une investigation ; ce n’est pas un scrutin qui efface une objection. Si son auteur part, le problème technique reste.

Le dossier d’impact doit nommer le groupe concerné, relier la conception à un bénéfice ou à un coût, exposer les éléments contraires, tester les conditions défavorables et indiquer la distribution des sacrifices. Lorsque deux catégories d’utilisateurs ont des intérêts réellement incompatibles, la décision doit conserver les alternatives et le motif du compromis.

Cette méthode fait aussi apparaître le problème d’agence. Ceux qui décident peuvent gagner en rapidité, en influence ou en revenu, tandis que des absents supportent la perte de confidentialité, d’accès ou de capacité de sortie. Le siège à la table ne transfère pas ce risque au décideur et ne lui remet pas le mandat du principal.

Une consultation prouve un effort, pas une délégation

La RFC 8890 demande d’aller vers les communautés affectées selon leurs usages, d’adapter les mécanismes de retour et d’éviter les surprises. Une liste de diffusion ou une réunion de travail sert les spécialistes du protocole ; elle peut exclure ceux qui n’utilisent pas cet outil, ne maîtrisent pas sa langue ou ne découvriront l’impact qu’après le déploiement.

L’atelier ESCAPE consigné par la RFC 8752 fournit un cas réel. Il rassemble des perspectives sur les éditeurs, l’agrégation de contenu et le Web ouvert. Il atteste les invitations, les discussions et les questions. Il n’atteste pas que les présents parlaient au nom de chaque éditeur, annonceur, lecteur ou personne décrite par ces systèmes.

Un journal de consultation utile mentionne l’organisateur, la communauté recherchée, le canal d’invitation, les langues et aménagements, les répondants, les groupes absents, les questions soulevées, les réponses, les modifications et les raisons des refus. Il conserve explicitement l’inconnu.

Séparer « entendu » d’« autorisé par » protège la valeur du témoignage sans imposer aux experts une procuration fictive. Le silence des personnes non atteintes ne se transforme pas non plus en consentement.

La sortie se mesure après l’installation

La RFC 8890 voit dans la pluralité des agents utilisateurs un moyen de réduire le coût de changement et d’aligner les éditeurs sur certains intérêts des personnes. La RFC 9518 approfondit cette mécanique : changer d’implémentation ou de déploiement peut limiter la centralisation, à condition que le substitut existe et que le coût soit supportable.

Une icône concurrente ne constitue pas une sortie. Il faut déplacer données et préférences, conserver les identifiants, remplacer des extensions, retrouver l’accessibilité et les habitudes, franchir de nouveaux avertissements de sécurité et parfois convaincre une organisation. Le système d’exploitation peut compliquer le changement du choix par défaut. Le nouveau produit peut partager le même moteur ou le même gardien de distribution.

La spécification influe sur cette diversité. Trop de complexité écarte les implémentations indépendantes. Trop peu de précision pousse vers des extensions propriétaires et rend aussi le remplacement difficile. Compter des marques sans examiner moteurs, dépendances et politiques donne une illusion de choix.

Le test de sortie enregistre, pour des groupes réels, le temps, l’expertise, la coordination, les fonctions perdues, la portabilité des données et des identifiants, le statut par défaut, le résultat et la capacité de revenir. Un agent ne subit la discipline de l’utilisateur que si celui-ci peut réellement lui retirer le rôle.

Un intermédiaire doit montrer son entrée et sa limite

La RFC 9518 propose que l’intervention d’un tiers résulte d’un acte positif d’au moins une partie principale et que son observation ou son contrôle reste nécessaire à sa fonction. Ce document Informational du flux Independent exprime les vues de Nottingham ; il n’est ni le consensus de l’IETF ni une loi générale.

Le cadre permet néanmoins une inspection concrète. Qui a sélectionné l’agent utilisateur : la personne, la plate-forme ou l’employeur ? Quelles ressources peut-il lire, transformer, conserver ou bloquer ? Comment l’autorité est-elle retirée ? Quel substitut est accessible ? Un clic pour charger une page n’autorise pas toutes les utilisations secondaires.

Sur un appareil administré, l’agent peut fidèlement représenter une règle de l’organisation plutôt que la préférence de la personne affectée. Le qualifier de « choix utilisateur » masquerait alors deux réalités : le pouvoir de l’organisation et l’absence de choix individuel.

Trois documents ne portent pas la même autorité

Mark Nottingham est l’auteur nommé de la RFC 8890. Publiée comme RFC Informational dans le flux IAB, elle consigne le consensus de l’IAB au moment de sa publication. Elle n’est pas un Internet Standard et ne représente pas le consensus de l’IETF. Le billet de Nottingham en 2020 la présente comme une orientation persuasive, non contraignante.

La RFC 9110 relève, elle, du Standards Track de l’IETF. Roy Fielding, Mark Nottingham et Julian Reschke en sont les trois éditeurs. Sa définition de l’agent utilisateur appartient à un long travail collectif sur HTTP ; le nom d’un éditeur n’accorde aucun contrôle sur les logiciels.

La RFC 9518 est encore différente : RFC Informational du flux Independent, elle indique que les positions sont celles de l’auteur. Son analyse de la centralisation, du changement et des intermédiaires fournit des hypothèses vérifiables, pas un vote communautaire.

Le profil IETF Datatracker établit les contributions de Nottingham à HTTP, aux URL, à RSS/Atom et à QUIC, ainsi que des fonctions datées. Il ne prouve ni propriété du Web, ni maîtrise des politiques de navigateur, ni pouvoir sur les résultats de l’IETF, ni mandat des utilisateurs.

Remplacer un mot commode par une chaîne de reçus

La chaîne commence par les humains affectés, y compris ceux qui n’envoient aucune requête. Elle distingue leurs rôles, décrit le mécanisme du bénéfice ou du préjudice et conserve les limites de la consultation. Elle poursuit avec l’agent sélectionné, la source du défaut, la préférence active, le périmètre des capacités, l’exécution observée, les solutions indépendantes et le coût réel du départ. Elle finit par les résultats pour chaque groupe et la disposition des problèmes par le processus de normalisation.

Aucun reçu n’hérite de l’autorité du suivant. Un réglage actif n’établit pas un consentement informé. Une consultation n’établit pas un mandat. Un concurrent nominal n’établit pas la sortie. Un bénéfice mesuré pour un groupe n’établit pas le bien-être universel.

Mettre l’Internet au service des utilisateurs finaux ne revient donc pas à désigner quelqu’un pour parler à leur place. Cela revient à ne jamais les effacer derrière l’intermédiaire, à limiter le pouvoir de celui-ci et à rendre le choix, le retrait et les effets contestables. L’agent utilisateur mérite sa fonction lorsqu’il montre ce qu’il empêche et ce qu’il permet de quitter, non lorsqu’il revendique une voix collective.

Sources