Protocoles, normes, infrastructures : la main invisible de Google

Plusieurs jour­na­listes ont raconté leurs périples pour se passer des géants améri­cains du numé­rique (chez Motherboard, chez Gizmodo). Conclusion : c’est compliqué, tant ils sont omni­pré­sents. Par exemple, Amazon (via AWS) c’est un tiers de l’in­fo­nua­gique.

Je vais décrire quelque chose d’à la fois simi­laire et diffé­rent :

  • D’abord, comment on peut passer la journée sans quitter l’uni­vers Google – avec des degrés de proba­bi­lité variable suivant les étapes : les produc­tions Youtube n’ont pas la même prégnance que Youtube lui-même.
  • Ensuite, comment cet univers n’est pas seule­ment constitué des offres qu’il propose et des filiales qu’il possède, mais aussi des langages, normes, et proto­coles invi­sibles sur lesquelles il a un large contrôle.
Chromebook

1. J’ouvre mon ordi­na­teur Google.

Logo OS Fuschia

2. Bientôt, j’allumerai un système d’exploitation inté­gra­le­ment créé par Google.

Logo language Dart

3. Je lance une appli­ca­tion de mail codée dans un langage créé par Google.

Logo AMP pour Email

4. J’ouvre un message affiché dans un sous‐langage contrôlé par Google.

Logo format d'image Webp

5. Je clique sur une image, qui est dans un format contrôlé par Google.

Logo protocole QUIC

6. Pour ouvrir la page, une requête est envoyée dans un proto­cole contrôlé par Google.

Logo Google DNS

7. L’URL de la page est traduite en IP avec un annuaire contrôlé par Google.

Carte du cable sous-marin FASTER

8. Les donnée sont trans­mises par un cable sous-marin en partie contrôlé par Google.

9. L’intégrité de la page est garantie par un certi­ficat de sécu­rité racine délivré par Google.

Logo Google Cloud Platform

10. La page est hébergée chez Google.

Logo Youtube Red

11. J’arrive sur une plate­forme de vidéo et regarde une série produite par Google.

Logo Widevine

12. Je ne peux pas télé­charger la vidéo à cause d’un DRM géré par Google.

galerie de matériel Google

13. Mon assis­tant Google Home m’en­voie une alerte d’une caméra Google connectée à une borne wifi Google.

Mascotte Android en cag

14. Pour en savoir plus, j’ouvre mon télé­phone Google et son système d’ex­ploi­ta­tion contrôlé par Google.

Et cetera et cetera. Je n’ai pas inclus l’offre d’accès à Internet Google Fiber puis­qu’elle est en pause.

Toute la complexité du monde se cache dans le champ Nom d’un formulaire

Une personne n’a pas forcé­ment un seul prénom suivi d’un seul nom de famille. Elle peut avoir un seul nom, ou trois prénoms et quatre noms de famille, en changer au cours de sa vie, son nom peut être très long ou très court… il y a telle­ment de variantes à travers les sociétés humaines que l’ex­cep­tion doit être consi­dérée comme la norme. Cette complexité existe aussi pour les numéros de télé­phone, les adresses, et pour tant d’autres méca­nismes qu’il existe toute une litté­ra­ture à ce sujet, avec un titre devenu coutu­mier : « Les erreurs que font les déve­lop­peurs avec [bidule] ».

S’il existe une longue liste de ces dispo­si­tifs, c’est qu’ils sont trop souvent mal pris en compte en infor­ma­tique. Cela peut avoir des consé­quences très gênantes, par exemple si votre nom de famille est aussi un mot réservé qui signifie le « rien » en program­ma­tion et que vous faites tout bugger.

C’est un problème clas­sique d’écart entre le terri­toire et la carte. Un concep­teur modé­lise la réalité comme il peut, en faisant des raccourcis : un être humain est iden­tifié par un prénom et un nom, dans cet ordre et sans rien d’autre. Il doit bien exister deux trois excep­tions mais on verra plus tard, se dit-il.

Les noms sont déjà complexes, alors imaginez une notion comme la famille. Par exemple le service Google Play Family impose des règles qui forment une défi­ni­tion impli­cite.

Admettons que ce sont surtout des limites commer­ciales pensées pour que les gens n’abusent pas du système en ajou­tant trois cent personnes du monde entier à leur « famille ». Mais quand même. Qui est Google pour dire qu’une famille ne peut être composée de nombreuses personnes vivant dans plusieurs pays ? Ensuite, ça influe forcé­ment sur la vie des gens : le service devient intriqué avec leur quoti­dien et définit quels films peut regarder un enfant, avec qui et sur quel appa­reil. Tout ça dans un contexte d’ob­jets toujours plus présents et connectés, où la famille peut avoir un appa­reil Google dans chaque pièce et plus d’ap­pa­reils que de membre.

Nom, prénom et design tragique

Bref, conce­voir un système peut avoir des consé­quences graves et inat­ten­dues, c’est un thème dont la profes­sion prend conscience, avec diffé­rents approches (design tragique, design systé­mique…) et spécia­lités (impact sur les mino­rités, biais et auto­ma­ti­sa­tion forcenée en intel­li­gence arti­fi­cielle…).

Mais ce que j’aime avec mes exemples, c’est qu’ils paraissent anodins. On ne parle pas de l’UI qui a causé l’envoi d’une fausse alerte d’at­taque de missiles à tout Hawaï ou de cock­pits d’avions mal conçus. La majo­rité des gens aujourd’hui saisissent leur nom en deux secondes et leur adresse par auto-complétion. Pourtant les noms sont une construc­tion à l’in­ter­sec­tion de bien des enjeux et des insti­tu­tions sociales :

Enfin et plus large­ment, les noms de personnes sont en eux-même un phéno­mène social complexe, avec un champ d’étude dédié en sciences sociales : l’an­thro­po­nymie, dont on pourra lire une synthèse fasci­nante ici. Elle nous apprend qu’ils ne servent pas qu’à iden­ti­fier une personne, loin de là, mais aussi à classer et hiérar­chiser, à inscrire la personne dans une certaine orga­ni­sa­tion sociale et symbo­lique, ainsi qu’à s’adresser à elle d’une certaine manière, dans un certain contexte.

Bref, pour peu qu’on creuse un peu, toute la complexité de ce qu’on appelle un système socio-technique peut surgir d’un modeste champ de formu­laire.

L’offre crée sa propre demande

Cette formule de Keynes résume l’idée que la demande n’est pas statique et tend au contraire à augmenter lorsque l’offre croît elle aussi. La raison est simple : si un domaine est en situa­tion de pénurie, une partie de la demande va rester inex­primée. Par exemple, je ne vais même pas essayer d’emprunter une route si je sais qu’elle est en perma­nence bouchée. Cela ne veut pas dire que je n’en ai pas envie. Ce phéno­mène a été redé­cou­vert, avec des variantes, dans bien des domaines :

  • Mon exemple est un problème de plani­fi­ca­tion des réseaux de trans­port. On y trouve le concept de demande induite (ou latente), la conjec­ture de Lewis-Mogridge et le para­doxe de Braess.
  • L’effet de rebond en économie : augmenter l’ef­fi­ca­cité des méthodes de consom­ma­tions d’une ressource natu­relle tend à en augmenter la demande. Par exemple, l’in­ven­tion du moteur à vapeur de Watt, nette­ment plus effi­cace que ses prédé­ces­seurs, a large­ment augmenté la demande en charbon, alors que le volume néces­saire à l’in­dus­trie avait tech­ni­que­ment diminué.
  • Le prin­cipe de Blynn, en image de synthèse : la puis­sance crois­sante des ordi­na­teurs s’est réper­cutée dans une augmen­ta­tion de la qualité des images, pas dans une dimi­nu­tion des temps de rendu. Le prin­cipe de Wirth, plus général, peut aussi être inter­prété dans ce sens.
  • Le prin­cipe de Parkinson : dans une orga­ni­sa­tion, le temps néces­saire pour accom­plir une tâche augmente jusqu’à occuper toute la durée qu’on lui a attribué.

Je tiens à remer­cier la section « voir aussi » de Wikipédia, sans qui je n’au­rais pas décou­vert la moitié de ces idées.

Le Principe de robustesse

Dans le domaine des proto­coles de commu­ni­ca­tion, le Principe de robus­tesse veut qu’un nœud d’un réseau (par exemple un serveur sur Internet) soit tolé­rant quand il décide d’ac­cepter ou non un message plus ou moins bien formé, et qu’il soit plus rigou­reux sur la qualité des messages qu’il envoie. Le prin­cipe voit son origine dans les débats autour de l’im­por­tance qu’il faut donner à une norme de commu­ni­ca­tion : la stra­tégie opti­male pour la robus­tesse du réseau, ce serait de suivre la norme de près en output mais beau­coup moins en input.

Par la suite (RFC 1122, § 1.2.2), il été a inter­prété de manière plus large comme un prin­cipe de prévoyance :

Software should be written to deal with every concei­vable error.

C’est-à-dire : rendez votre programme robuste en le conce­vant de telle sorte à qu’il fonc­tionne avec les plus inputs les plus variés.

La rhéto­rique dispose d’un couple de règles très simi­laire : les prin­cipes d’hon­nê­teté intel­lec­tuelle et de charité. Le premier revient à dire qu’il faut faci­liter le travail de compré­hen­sion de l’in­ter­lo­cu­teur, le second qu’il faut inter­préter ses propos de la manière la plus avan­ta­geuse possible. (Note : c’est une vision à minima. L’honnêteté intel­lec­tuelle ne se limite pas à un souci de clarté. De manière plus dras­tique, ces prin­cipes rappellent qu’il faut veiller à avoir un langage et des valeurs de discus­sion communs.)

Il y a un troi­sième domaine où ce prin­cipe peut s’ap­pli­quer : les IHM. La mani­pu­la­tion d’un programme peut être vue comme un dialogue : l’uti­li­sa­teur demande quelque chose et le système répond qu’il a bien effectué (ou non) la tâche, tout ceci via le language de l’in­ter­face. La méta­phore a notam­ment été déve­loppée par Hutchins dès 1987 (article en lien ici – PDF pour­rave mais réflexion passion­nante), qui en note aussi les limites : elle suppose qu’il y a une média­tion de type symbo­lique entre l’homme et la machine, avec toute la complexité et l’ambiguïté que cela implique.

Pourtant, cette méta­phore de la conver­sion s’ap­plique encore à bien des cas, par exemple la complé­tion d’un formu­laire : j’entre une date et le programme me répond si elle a bien été comprise. Une bonne inter­face est tolé­rante dans les formats possibles qu’elle admet en entrée et rigou­reuse (cohé­rente) à chaque fois qu’elle doit affi­cher une date en sortie.

Le prin­cipe de robus­tesse sur Wikipedia