Ah, mais c'est une excellente question,
ça. L'Internet est pour qui ? Qui sont les
« parties prenantes » et, parmi elles, quelles sont les plus
importantes ? Plus concrètement, la question pour l'IETF est « pour
qui bossons-nous ? » Quels sont les « clients » de notre activité ?
Ce RFC de
l'IAB met
les pieds dans le plat et affirme bien haut que ce sont les intérêts
des utilisateurs finaux qu'il faut considérer avant tout. Et
explique aussi comment prendre en compte ces intérêts, en
pratique. C'est donc un RFC 100 % politique.
Il y a encore quelques personnes à l'IETF qui ne veulent pas voir les
conséquences de leur travail (« la technique est neutre ») ou, pire,
qui ne veulent en retenir que les conséquences positives. Mais les
activités de l'IETF, comme la production des RFC, est en fait politique,
affirme ce document. Car l'Internet est aujourd'hui un outil crucial
pour toute la vie sociale, il a permis des changements importants,
il a enrichi certains et en a appauvri d'autres, il a permis l'accès
à un savoir colossal librement accessible, et il a facilité le
déploiement de mécanismes de surveillance dont Big Brother n'aurait jamais osé
rêver. Et toute décision apparemment « purement technique » va avoir
des conséquences en termes de ce qui est possible, impossible,
facile, ou difficile sur le réseau. Compte-tenu de leur impact, on
ne peut pas dire que ces décisions ne sont pas politiques (section 1
du RFC).
Une fois qu'on reconnait que ce qu'on fait est politique, se pose
la question : pour qui travaille-t-on ? Dresser la liste des
« parties prenantes », les intéressé·e·s, les organisations ou individus qui seront
affectés par les changements dans l'Internet est une tâche
impossible ; c'est quasiment tout le monde. Le RFC donne une liste
non limitative : les utilisateurs finaux, les opérateurs réseau, les
écoles, les vendeurs de matériel, les syndicats, les auteurs de
normes (c'est nous, à l'IETF), les
programmeurs qui vont mettre en œuvre les normes en question, les
ayant-droits, les États, les ONG, les
mouvements sociaux en ligne, les patrons, la police, les parents de
jeunes enfants… Tous et toutes sont affectés et tous et toutes
peuvent légitimement réclamer que leurs intérêts soient pris en
compte. Ce n'est pas forcément au détriment des autres : un
changement technique peut être bénéfique à tout le monde (ou, en
tout cas, être bénéfique à certains sans avoir d'inconvénients pour
les autres). Mais ce n'est pas toujours le cas. Pour prendre un
exemple classique (mais qui n'est pas cité dans ce RFC), voyons le
chiffrement : l'écriture du , qui normalisait la version 1.3 de TLS, a remué beaucoup de
monde à l'IETF car le gain en sécurité pour les utilisateurs finaux
se « payait » par de moindres possibilités de surveillance pour les
États et les patrons. Ici, pas question de s'en tirer en disant que
tout le monde serait heureux : il fallait accepter de faire des
mécontents.
Bon, là, c'étaient les grands principes, maintenant, il faut
devenir un peu concret. D'abord, qui sont ces « utilisateurs
finaux » ? Si on veut donner la priorité à leurs intérêts, il
faudrait les définir un peu plus précisément. La section 2
explique : ce sont les humains pour qui l'Internet rend un
service. Cela n'inclut donc pas les professionnels qui font marcher
le réseau : les utilisateurs finaux du protocole BGP ne sont pas les
administrateurs
réseau, qui configurent les routeurs BGP, mais les gens à qui le
réseau en question permet de communiquer.
Le RFC note que ces utilisateurs finaux ne forment donc pas un
groupe homogène. Ils ont des intérêts différents et des opinions
différentes. (Je suis personnellement très agacé par les gens qui,
dans les réunions de « gouvernance
Internet », plastronnent qu'ils représentent « les
utilisateurs ». Comme la mythique « société civile », les
utilisateurs ne sont pas d'accord entre eux.) Parfois, le désaccord
est au sein du même individu, lorsqu'il occupe plusieurs rôles. Même
dans un seul rôle, l'utilisateur final peut être le siège de
tensions, par exemple entre la protection de sa vie privée et la facilité d'utilisation du
réseau, deux objectifs honorables mais qui sont parfois difficiles à
concilier.
Le RFC note aussi que l'utilisateur final peut… ne pas être un
utilisateur, ou en tout cas pas directement. Si on prend une photo
de moi et qu'on la met sur le Web avec un commentaire, je suis
concerné, même si je n'utilise pas du tout l'Internet. Même chose si
j'entre dans un magasin truffé de capteurs qui détectent mes
mouvements et les signalent. Les utilisateurs finaux, au sens de ce
RFC, peuvent donc être des utilisateurs indirects.
Une fois qu'on sait qui sont les utilisateurs finaux, pourquoi
faudrait-il prioriser leurs intérêts ? La section 3 rappelle d'abord
que l'IETF a une longue histoire d'affirmation de cette
priorité. Le tout premier RFC, le , disait
déjà « One of our goals must be to stimulate the immediate
and easy use by a wide class of users. » (Bon, le parlait d'accessibilité et de facilité
d'usage plutôt que de politique, mais c'est une jolie référence.) La
charte de l'IETF, dans le , est plus
précise : « The IETF community wants the Internet to
succeed because we believe that the existence of the Internet, and
its influence on economics, communication, and education, will help
us to build a better human society. ». Et, encore plus
explicite, « We embrace technical concepts such as
decentralized control, edge-user empowerment and sharing of
resources, because those concepts resonate with the core values of
the IETF community. These concepts have little to do with the
technology that's possible, and much to do with the technology that
we choose to create. ». Bref, le but est le bonheur de
l'humanité, et celle-ci est composée des utilisateurs finaux.
(Pour ne fâcher personne, le RFC oublie de signaler l'existence
d'autres RFC qui au contraire donnent explicitement la priorité à
d'autres parties prenantes, par exemple les gérants du réseau dans
le .)
Le RFC note que le progrès quantitatif (davantage de machines
connectées, une capacité réseau plus
importante, une latence plus faible)
n'est pas un but en soi car l'Internet peut être utilisé pour des
mauvaises causes (surveiller les utilisateurs, exercer un pouvoir
sur eux). La technique pouvant être utilisée pour le bien comme pour
le mal, les améliorations techniques (comme présentées en couleur
rose par les techno-béats, par exemple les promoteurs de la 5G) ne doivent pas être considérées comme
forcément positives.
Après ces arguments humanistes, le RFC mentionne aussi des
arguments plus internes au réseau. D'abord, d'un point de vue
égoïste, l'IETF a tout intérêt à garder la confiance de ces
utilisateurs finaux, car l'IETF perdrait sa pertinence et son rôle
si elle se mettait, par exemple, uniquement à la remorque des
vendeurs de matériel ou de logiciel. (Ou même si elle était
simplement vue comme se mettant à cette remorque.)
On pourrait même voir les utilisateurs se détourner massivement,
non seulement du travail de l'IETF, mais aussi de l'Internet en
général, si leurs intérêts ne sont pas mis en premier. Prioriser les
utilisateurs finaux aide aussi à lutter contre certaine formes de
technophobie.
Maintenant, on a défini les utilisateurs finaux, affirmé qu'il
fallait penser à eux et elles en premier, et expliqué pourquoi. Il
reste le comment. C'est bien joli de dire, dans une grande envolée
« nous pensons avant tout à M. et Mme Toutlemonde » mais,
concrètement, cela veut dire quoi ? La section 4 du RFC décortique
les conséquences pratiques du choix politique.
D'abord, déterminer ce qui est bon pour les utilisateurs n'est
pas évident. Paradoxalement, le fait que les participants à l'IETF
connaissent et comprennent très bien le fonctionnement de l'Internet
n'aide pas, au contraire ; cela rend plus difficile de se mettre à
la place des utilisateurs finaux. Pourtant, on l'a vu, l'IETF se
réclame depuis longtemps d'une vague « Internet
community » mais sans trop savoir qui elle est. Une
solution évidente au problème « quels sont les intérêts des
utilisateurs finaux ? » serait de leur demander. C'est plus facile à
dire qu'à faire, mais c'est en effet la première chose à envisager :
se rapprocher des utilisateurs.
Cela ne va pas de soi. Déjà, le travail de l'IETF est très pointu
techniquement, et nécessite une forte expertise, sans compter la
nécessité de se familiariser avec la culture spécifique de
l'IETF. les utilisateurs finaux qu'on veut prioriser ne sont pas des
experts techniques. Pire, les connaissances qu'ils ont sur
l'Internet ne sont pas seulement insuffisantes, elles sont souvent
fausses. Bref, inviter M. ou Mme Toutlemonde sur les listes de diffusion de l'IETF
n'est pas la bonne approche.
Les États sont prompts à dire « pas de problème, les utilisateurs
ont une représentation, et c'est nous ». Il suffirait donc que les
envoyés de ces États participent à l'IETF et on aurait donc
automatiquement accès à « la voix des utilisateurs ». Il y a déjà de
ces envoyés qui participent à l'IETF. (À chaque réunion, il y a au
moins une personne avec un badge NSA, sans compter ceux qui n'ont pas le badge,
mais ont le même employeur.) La question de leur représentativité
(l'envoyé du gouvernement français est-il vraiment le porte-parole
des soixante millions d'utilisateurs français ?) a été une des
questions essentielles lors des discussions menant à ce RFC. Chaque
gouvernement prétend qu'il est représentatif. C'est clairement faux
pour les dictatures mais cela ne veut pas dire que les démocraties
sont parfaites, sans compter la difficulté de classer les pays dans
l'une ou l'autre catégorie. Bref, personne n'a envie de transformer
l'IETF en un organisme multi-gouvernemental paralytique, comme
l'ONU. (Les experts en
« gouvernance Internet » noteront que
l'ICANN a le même genre de problèmes, et son
GAC - Governmental Advisory Committee - ne satisfait personne.)
À ce sujet, bien que cela ne soit pas mentionné explicitement
dans le RFC, il faut aussi dire que les envoyés des États sont en
général contraints par un processus de décision interne très rigide,
et ne peuvent pas s'exprimer librement. Cela ne colle évidemment pas
avec le mécanisme de discussion très ouvert et très vif de
l'IETF. Je me souviens d'une réunion où deux personnes portant la
mention FBI sur leur badge étaient venus me
parler de problèmes avec un des documents sur lesquels je
travaillais. Lorsque je leur ai fait remarquer que leurs analyses,
assez pertinentes, devraient être faites dans la réunion officielle
du groupe de travail et pas juste dans les couloirs, ils m'avaient
répondu que leurs supérieurs ne les y autorisaient pas. Difficile
d'envisager une participation effective des États dans ces
conditions.
Bon, si on ne fait pas appel aux États, à qui ? Le RFC mentionne
la classique « société civile » dont personne ne sait trop en quoi
elle consiste, mais à qui tout le monde rend hommage. Selon
l'interlocuteur, « société civile » peut vouloir dire « tout le
monde sauf l'État » (incluant, par exemple, le
MEDEF), ou bien « tous les individus » ou
encore « tous les individus organisés (associations, syndicats,
etc) » sans compter ceux qui disent « société civile » pour « les
gens qui sont d'accord avec moi ». (Disons franchement les choses :
l'un des problèmes de fond de la « gouvernance de
l'Internet » est qu'il n'y a que peu ou pas de
représentation des utilisateurs. Tout le monde parle pour eux et
elles, mais ielles n'ont pas de voix propre. Ce syndrome « tout le
monde se réclame de l'utilisateur final » avait été très net, par
exemple, lors des débats sur
DoH, mais aussi dans d'autres questions de gouvernance.)
Mais le RFC note à juste titre qu'il existe des organisations qui
ont sérieusement travaillé les sujets politiques liés à l'Internet,
et qui connaissent donc bien les problèmes, et les conséquences des
choix techniques. (En France, ce serait par
exemple La Quadrature du Net,
Framasoft et certainement plusieurs autres.)
Bien que rien ne garantisse leur représentativité, note le RFC, ces
organisations sont sans doute le premier canal à utiliser pour
essayer de comprendre les intérêts des utilisateurs finaux. La
recommandation est donc d'essayer d'identifier ces groupes et de
travailler avec eux.
L'accent est mis sur la nécessité d'aller les voir, de ne pas
juste leur dire « venez participer à l'IETF » (ils n'ont pas
forcément le temps ou les moyens, et pas forcément envie de se
lancer dans ce processus). Outre ses réunions formelles et ses
listes de diffusion, l'IETF a quelques canaux de communication plus
adaptés mais certainement très peu connus (« venez à la Bar BoF, on
en parlera autour d'une bière »). Idéalement, c'est l'IETF qui
devrait prendre l'initiative, et essayer d'aller vers les groupes
organisés d'utilisateurs, par exemple en profitant des réunions
existantes. Le RFC recommande de faire davantage d'efforts de
sensibilisation, faire connaitre le travail de l'IETF, ses enjeux,
etc. (Mon expérience est qu'il est très difficile de faire
s'intéresser les gens à l'infrastructure de l'Internet, certes moins
sexy qu'une page d'accueil colorée d'un site Web. Après tout, on ne
peut pas faire boire un âne qui n'a pas soif.)
Le RFC donne un exemple d'un atelier ayant réuni des participants
à l'IETF, et des gens qui n'ont pas l'habitude d'aller à l'IETF, sur
un sujet assez chaud politiquement, la
réunion ESCAPE, documentée dans le .
On peut aussi penser que cette tâche de sensibilisation à
l'importance de la normalisation, et à ses
conséquences politiques, ne devrait pas revenir entièrement à
l'IETF, qui n'est pas forcément bien préparée à cela. Le RFC cite à
juste titre l'Internet
Society, qui fait en effet un important
travail dans ce domaine.
Le RFC continue avec une section sur le concept de systèmes
centrés sur l'utilisateur. Il part de l'exemple du Web, certainement un des plus gros
succès de l'Internet. Dans le Web, l'IETF normalise le protocole
HTTP (le
W3C faisant
le reste). La norme HTTP, le décrit
explicitement le rôle du client HTTP, appelé user
agent dans la norme (et c'est de là que vient l'en-tête
HTTP User-Agent:). À noter que le RFC mélange
client HTTP et navigateur Web : le client
d'un serveur HTTP n'est pas forcément un navigateur. Quoi qu'il en
soit, la discussion continue sur le navigateur : celui-ci sert
d'intermédiaire entre l'utilisateur et le serveur Web. Au lieu d'un
client spécifique d'un service, et qui a accès à toute la machine de
l'utilisateur pour faire sa tâche, le passage par cet intermédiaire
qu'est le navigateur permet de créer un bac à sable. Quelles que
soient les demandes faites par le serveur Web, il ne sera pas
possible de sortir du bac à sable et, par exemple, de lire et
d'écrire arbitrairement des fichiers sur la machine de
l'utilisateur.
Au contraire, les services sur le Web qui exigent l'installation
d'un client local demandent à l'utilisateur une confiance aveugle :
ces clients peuvent faire des choses que le navigateur bloquerait
normalement. Ce n'est pas par hasard que les sites des médias
demandent si souvent l'installation de leur
« app » quand on navigue depuis un
ordiphone : ces clients locaux ont bien plus
de possibilité, notamment de pistage et de surveillance que ce qui
est possible via le navigateur.
(Le RFC ne mentionne pas un autre moyen de créer la confiance :
le logiciel libre. La
totalité de ces « apps » sont du logiciel privateur. Si le logiciel
est sous une licence libre, il y a nettement moins de craintes à
avoir lorsqu'on l'installe.)
Le RFC estime que le fait d'avoir défini explicitement le
user agent et ses propriétés a facilité le succès
du Web, en permettant la création de cet intermédiaire de confiance
qu'est le navigateur Web, un exemple de système « centré sur
l'utilisateur ». Bien sûr, cette vision est très
contestable. Le RFC note par exemple que, à vouloir tout
faire passer par le Web, on aboutit à des navigateurs qui sont
devenus très complexes, ce qui se paie en sécurité et en
performances. En outre, cette complexité diminue la concurrence : il
n'y a que très peu de navigateurs et beaucoup de composants
cruciaux, comme WebKit sont communs à
plusieurs navigateurs, diminuant la diversité et le
choix. Aujourd'hui, créer un nouveau navigateur en partant de zéro
semble impossible, ce qui a de lourdes conséquences sur la
distribution du pouvoir dans le Web.
Mais le RFC estime que c'est quand même une meilleure approche
que celle, par exemple, de l'Internet des
objets, où il n'y a pas de norme d'interaction entre
l'utilisateur et le système, pas de « système centré sur
l'utilisateur », ce qui fait que l'utilisateur doit faire une
confiance aveugle à des systèmes opaques, dont la mauvaise qualité
(notamment en sécurité) et la mauvaise éthique ont déjà été
largement montrées.
On a dit plus haut que, dans le meilleur des cas, le travail de
l'IETF menait à des solutions qui étaient positives pour tout le
monde. L'IETF peut alors laisser les différentes parties prenantes
interagir (cf. l'article « Luttes
dans l'Internet », même si, aujourd'hui, je traduirais
tussle par un terme moins violent que
lutte). Mais ce cas idéal n'est pas systématique. Parfois, les
solutions techniques normalisées dans les RFC ne sont positives que pour certains,
et neutres pour d'autres (ne leur apportent aucun avantage). Et
parfois, c'est pire, les solutions sont négatives pour
certains. Dans le monde réel, fait de différences d'opinion et
d'intérêts (et de lutte des classes,
ajouterait un marxiste), il ne faut pas être
naïf : on ne va pas plaire à tout le monde. Conformément aux
principes établis plus haut, le RFC affirme que, si une solution
envisagée a forcément des conséquences négatives, il faut faire en
sorte que ces conséquences négatives ne soient pas supportées par
les utilisateurs finaux, mais par d'autres parties prenantes.
L'IETF a déjà été confrontée à de tels choix, et a documenté
cette décision, par exemple dans les
(sur le filtrage), et (sur la surveillance),
(sur les pare-feux des machines terminales)
et enfin (sur la vie privée).
Le RFC note aussi que certaines décisions politiques de l'IETF
peuvent être correctes mais insuffisantes. Ainsi, le insiste sur l'importance du modèle de bout en
bout. Mais cela ne suffit pas si c'est la machine avec qui on
communique qui trahit. Chiffrer grâce à HTTPS quand on parle avec un
GAFA n'est une protection que contre les
tiers, pas contre le GAFA.
Au sujet des GAFA, le RFC note que la concentration des services
dans les mains d'un petit groupe de sociétés est un problème pour
les utilisateurs. Il affirme aussi que cela peut être encouragé par
des propriétés du protocole IETF. (C'est nettement plus
contestable : quelles sont les caractéristiques de SMTP qui expliquent
la concentration du courrier chez Gmail et
Outlook.com ? Cet argument semble plutôt une
allusion maladroite aux débats
sur DoH.)
Comme indiqué au début, les utilisateurs finaux ne forment pas un
groupe homogène. Ils n'ont ni les mêmes intérêts, ni les mêmes
opinions. Cela peut entrainer des difficultés pour l'application du
principe « les utilisateurs d'abord ». Par exemple, dans un cas
hypothétique où une solution technique entrainerait des conséquences
positives pour les utilisateurs d'un pays et négatives dans un autre
pays, que faire ? Le RFC suggère de privilégier l'évitement des
conséquences négatives. Dans certains cas, il ne sera pas possible
de les éviter complètement, et il faudra vraiment faire des
compromis. Mais, au moins, il ne faudra pas cacher le problème sous
le tapis, et bien documenter ce compromis.
Le principe « les utilisateurs d'abord » s'applique aussi à
l'IETF elle-même. Le RFC se termine en affirmant qu'il ne faut pas
que l'IETF privilégie ses propres besoins. Ainsi, s'il faut
compliquer la tâche des auteurs de RFC pour mieux préserver les
intérêts de l'utilisateur, eh bien il faut le faire. De même, dit
le RFC, la beauté de l'architecture technique n'est pas un but en
soi, elle doit passer après les intérêts des utilisateurs
finaux.
En anglais, vous pouvez aussi lire la synthèse
qu'avait publié l'auteur du RFC, où il s'exprime plus
librement que dans le RFC, par exemple sur DoH. Un article de
synthèse, allant plus loin que le RFC a été écrit
par Vesna Manojlovic. D'autre part, la norme HTML (du W3C) a une mention qui
va dans le même esprit que ce RFC : « In
case of conflict, consider users over authors over implementors over
specifiers over theoretical purity. » (les
mauvaises langues pourront faire remarquer que ce mépris de la
« theoretical purity » explique le b...l
technique qu'est le Web). Ou, en sens opposé, un article qui s'était
vigoureusement
opposé à cet empouvoirement des utilisateurs.