Protocoles, normes, infrastructures : la main invisible de Google

Plusieurs journalistes ont raconté leurs périples pour se passer des géants américains du numérique (chez Motherboard, chez Gizmodo). Conclusion : c’est compliqué, tant ils sont omniprésents. Par exemple, Amazon (via AWS) c’est un tiers de l’infonuagique.

Je vais décrire quelque chose d’à la fois similaire et différent :

  • D’abord, comment on peut passer la journée sans quitter l’univers Google – avec des degrés de probabilité variable suivant les étapes : les productions Youtube n’ont pas la même prégnance que Youtube lui‐même.
  • Ensuite, comment cet univers n’est pas seulement constitué des offres qu’il propose et des filiales qu’il possède, mais aussi des langages, normes, et protocoles invisibles sur lesquelles il a un large contrôle.
Chromebook

1. J’ouvre mon ordinateur Google.

Logo OS Fuschia

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

Logo language Dart

3. Je lance une application 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 protocole 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 transmises par un cable sous‐marin en partie contrôlé par Google.

9. L’intégrité de la page est garantie par un certificat de sécurité 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 plateforme 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 assistant Google Home m’envoie 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’exploitation contrôlé par Google.

Langage Kotlin

15. J’ouvre l’application couplée à la caméra, créée dans un langage (encore un) contrôlé par Google.

Et cetera et cetera. Je n’ai pas inclus l’offre d’accès à Internet Google Fiber puisqu’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 tellement de variantes à travers les sociétés humaines que l’exception doit être considé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écanismes qu’il existe toute une littérature à ce sujet, avec un titre devenu coutumier : « Les erreurs que font les développeurs avec [bidule]».

S’il existe une longue liste de ces dispositifs, c’est qu’ils sont trop souvent mal pris en compte en informatique. 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 programmation et que vous faites tout bugger.

C’est un problème classique d’écart entre le territoire et la carte. Un concepteur modélise la réalité comme il peut, en faisant des raccourcis : un être humain est identifié par un prénom et un nom, dans cet ordre et sans rien d’autre. Il doit bien exister deux trois exceptions 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éfinition implicite.

Admettons que ce sont surtout des limites commerciales pensées pour que les gens n’abusent pas du système en ajoutant 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 quotidien et définit quels films peut regarder un enfant, avec qui et sur quel appareil. Tout ça dans un contexte d’objets toujours plus présents et connectés, où la famille peut avoir un appareil Google dans chaque pièce et plus d’appareils que de membre.

Nom, prénom et design tragique

Bref, concevoir un système peut avoir des conséquences graves et inattendues, c’est un thème dont la profession prend conscience, avec différents approches (design tragique, design systémique…) et spécialités (impact sur les minorités, biais et automatisation forcenée en intelligence artificielle…).

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’attaque de missiles à tout Hawaï ou de cockpits d’avions mal conçus. La majorité des gens aujourd’hui saisissent leur nom en deux secondes et leur adresse par auto‐complétion. Pourtant les noms sont une construction à l’intersection de bien des enjeux et des institutions sociales :

Enfin et plus largement, les noms de personnes sont en eux‐même un phénomène social complexe, avec un champ d’étude dédié en sciences sociales : l’anthroponymie, dont on pourra lire une synthèse fascinante ici. Elle nous apprend qu’ils ne servent pas qu’à identifier une personne, loin de là, mais aussi à classer et hiérarchiser, à inscrire la personne dans une certaine organisation sociale et symbolique, 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 formulaire.

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 situation de pénurie, une partie de la demande va rester inexprimée. Par exemple, je ne vais même pas essayer d’emprunter une route si je sais qu’elle est en permanence bouchée. Cela ne veut pas dire que je n’en ai pas envie. Ce phénomène a été redécouvert, avec des variantes, dans bien des domaines :

  • Mon exemple est un problème de planification des réseaux de transport. On y trouve le concept de demande induite (ou latente), la conjecture de Lewis‐Mogridge et le paradoxe de Braess.
  • L’effet de rebond en économie : augmenter l’efficacité des méthodes de consommations d’une ressource naturelle tend à en augmenter la demande. Par exemple, l’invention du moteur à vapeur de Watt, nettement plus efficace que ses prédécesseurs, a largement augmenté la demande en charbon, alors que le volume nécessaire à l’industrie avait techniquement diminué.
  • Le principe de Blynn, en image de synthèse : la puissance croissante des ordinateurs s’est répercutée dans une augmentation de la qualité des images, pas dans une diminution des temps de rendu. Le principe de Wirth, plus général, peut aussi être interprété dans ce sens.
  • Le principe de Parkinson : dans une organisation, le temps nécessaire pour accomplir une tâche augmente jusqu’à occuper toute la durée qu’on lui a attribué.

Je tiens à remercier la section « voir aussi » de Wikipédia, sans qui je n’aurais pas découvert la moitié de ces idées.

Le Principe de robustesse

Dans le domaine des protocoles de communication, le Principe de robustesse veut qu’un nœud d’un réseau (par exemple un serveur sur Internet) soit tolérant quand il décide d’accepter ou non un message plus ou moins bien formé, et qu’il soit plus rigoureux sur la qualité des messages qu’il envoie. Le principe voit son origine dans les débats autour de l’importance qu’il faut donner à une norme de communication : la stratégie optimale pour la robustesse du réseau, ce serait de suivre la norme de près en output mais beaucoup moins en input.

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

Software should be written to deal with every conceivable error.

C’est-à-dire : rendez votre programme robuste en le concevant de telle sorte à qu’il fonctionne avec les plus inputs les plus variés.

La rhétorique dispose d’un couple de règles très similaire : les principes d’honnêteté intellectuelle et de charité. Le premier revient à dire qu’il faut faciliter le travail de compréhension de l’interlocuteur, le second qu’il faut interpréter ses propos de la manière la plus avantageuse possible. (Note : c’est une vision à minima. L’honnêteté intellectuelle ne se limite pas à un souci de clarté. De manière plus drastique, ces principes rappellent qu’il faut veiller à avoir un langage et des valeurs de discussion communs.)

Il y a un troisième domaine où ce principe peut s’appliquer : les IHM. La manipulation d’un programme peut être vue comme un dialogue : l’utilisateur 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’interface. La métaphore a notamment été développée par Hutchins dès 1987 (article en lien ici – PDF pourrave mais réflexion passionnante), qui en note aussi les limites : elle suppose qu’il y a une médiation de type symbolique entre l’homme et la machine, avec toute la complexité et l’ambiguïté que cela implique.

Pourtant, cette métaphore de la conversion s’applique encore à bien des cas, par exemple la complétion d’un formulaire : j’entre une date et le programme me répond si elle a bien été comprise. Une bonne interface est tolérante dans les formats possibles qu’elle admet en entrée et rigoureuse (cohérente) à chaque fois qu’elle doit afficher une date en sortie.

Le principe de robustesse sur Wikipedia