Mon blog

Ce livre raconte les dix ans d'expérience de l'auteure, professeure des écoles, à enseigner l'histoire à des élèves du primaire, en essayant de ne pas se limiter à un récit venu d'en haut.

C'est tout à fait passionnant. L'auteure, partisane des méthodes Freinet (mais avec nuance et sans en faire un dogme), essaie de ne pas se contenter de parler d'histoire aux enfants mais de les faire pratiquer un peu, en partant de sources. Évidemment, vu leur âge, ielles ne feront pas de recherche vraiment originale (et ne travailleront pas forcément sur des sources primaires) mais le but est qu'ielles comprennent que l'histoire, ce ne sont pas juste des dates qu'on assène d'en haut.

Et que l'histoire ne concerne pas que des rois et des généraux. Par exemple, lorsque l'auteure enseigne dans le quartier de La Villette, elle fait travailler ses élèves sur les anciennes usines du quartier, usine à gaz ou sucrerie, avec recherche d'informations sur les conditions de travail des différentes époques.Elle les emmène même voir des archives et comprendre ainsi avec quel matériau les historiens travaillent.

La difficulté est bien sûr de laisser les élèves assez libres (principes de Freinet) tout en les cadrant pour qu'ils aient les connaissances de base. Elle note que les élèves manquent souvent de contexte et, par exemple, lors d'un travail sur les lettres entre les soldats et leurs femmes et fiancées pendant la première guerre mondiale, un élève a demandé pourquoi ils ne s'appelaient pas par téléphone. Il faut donc fixer les époques et leurs caractéristiques dans l'esprit des élèves.

Une autre question émouvante portait sur la guerre d'Algérie, un certain nombre de ses élèves étant issu·es de l'immigration algérienne. Faut-il parler de la torture, sachant que le grand-père d'une des élèvs l'a fait ? Comment concilier l'importance de la vérité avec le souci de ne pas traumatiser les élèves ? L'auteure ne se contente en effet pas de gentilles généralités « les élèves sont créatifs, il faut les laisser faire », elle détaille les difficultés, les nombreuses questions soulevées par cet objectif de liberté, et les solutions trouvées.

Bref, je recommande ce livre à celles et ceux qui s'intéressent à l'histoire et à l'éducation.

Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau avant qu'il ne tente de se connecter à un serveur. On peut envoyer ainsi des indications sur les versions des protocoles gérées, des clés cryptographiques ou des noms de serveurs supplémentaires.

Un client d'un service réseau a en effet plein de questions à se poser avant de tenter une connexion. Quelle adresse IP utiliser ? Quel port ? Chiffrement ou pas ? Les anciens mécanismes traitent la question de l'adresse IP (on la trouve par une requête DNS) et celle du port, si on se limite aux ports bien connus (comme 43 pour whois). Mais cela ne dit pas, par exemple, si le serveur HTTP distant accepte ou non HTTP/3 (RFC 9114). Par contre, cet enregistrement HTTPS de Cloudflare va bien nous dire que ce serveur accepte HTTP/2 et 3 :

% dig cloudflare.com HTTPS
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28399
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
cloudflare.com.		300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5
…
;; WHEN: Mon Apr 08 09:27:01 CEST 2024
;; MSG SIZE  rcvd: 226

  

Bon, en quoi consiste cet enregistrement SVCB ? Il a deux modes de fonctionnement, alias et service. Le premier mode sert à faire d'un nom une version canonique d'un autre, un peu comme le CNAME mais en étant utilisable à l'apex d'une zone. Le second mode sert à indiquer les paramètres techniques de la connexion. Un enregistrement SVCB (ou HTTPS) a trois champs dans ses données :

• SvcPriority : quand il vaut zéro, il indique le mode alias. Autrement (par exemple dans le cas ci-dessus), il indique la priorité de ces paramètres.
• TargetName : en mode alias, il indique le nom canonique, ou autrement un nom alternatif (pour un service accessible via plusieurs noms). Dans l'exemple Cloudflare ci-desssus, il valait la racine (un point) ce qui indique l'absence de nom alternatif (section 2.5).
• SvcParams : une liste de couples {clé,valeur} pour les paramètres de connexion (uniquement en mode service). Dans le cas avec Cloudflare, c'était alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5. (Si vous vous intéressez aux débats à l'IETF, la question de la syntaxe de ces paramètres avait suscité une longue discussion.)

Les enregistrements SVCB ont le type 64 (enregistré à l'IANA) et les HTTPS, qui ont la même syntaxe et le même contenu, mais sont spécifiques à HTTP, ont le 65 (SVCB est générique). Les enregistrements HTTPS (et de futurs enregistrements pour d'autres protocoles) sont dits « compatibles avec SVCB » car ils ont la même syntaxe et la même sémantique.

Notre RFC définit (section 7) une liste de paramètres possibles mais d'autres peuvent être ajoutés dans un registre IANA, via la procédure « Examen par un expert » (RFC 8126). Pour l'instant, il y a, entre autres :

• alpn : indique l'ALPN (RFC 7301).
• ech : il servira à indiquer la clé à utiliser pour chiffrer le SNI.
• port : comme son nom l'indique.
• ipv4hint et ipv6hint : les adresses IP du service.

L'enregistrement peut (cela dépend des protocoles qui l'utilisent, HTTP ne le fait pas) être placé sur un sous-domaine indiquant le service, par exemple _8765._baz.api.example.com (section 10.4.5).

Idéalement, un serveur faisant autorité devrait renvoyer les SVCB et les HTTPS, s'ils sont présents, dans la section additionnelle de la réponse, lorsque le type demandé était une adresse IP. Mais ceux de Cloudflare ne semblent pas le faire actuellement. (PowerDNS le fait.)

Si vous vous intéressez aux questions opérationnelles, et que vous voulez mettre des enregistrements SVCB/HTTPS dans votre zone, la section 10 du RFC est faite pour vous. J'ai des enregistrements HTTPS pour ce blog :

# Un alias à l'apex (la priorité 0 indique le mode alias)
% dig +short +nodnssec bortzmeyer.org HTTPS
0 www.bortzmeyer.org.

# J'ai HTTP/2 (mais pas encore HTTP/3)
% dig +short +nodnssec www.bortzmeyer.org HTTPS
1 . alpn="h2"

Pour cela, j'ai mis dans le fichier de zone :

; Enregistrements SVCB (HTTPS).     

; HTTP/2 (mais pas encore - au 2024-04-08 - de HTTP/3)               
www IN HTTPS 1 . alpn="h2"

; alias                               
@ IN HTTPS 0 www.bortzmeyer.org.

Les clients HTTP récents, qui gèrent SVCB/HTTPS vont alors se connecter directement en HTTP/2 à https://www.bortzmeyer.org/ même si l'utilisateur demandait originellement http://bortzmeyer.org/ (le type d'enregistrement HTTPS, comme son nom l'indique, sert aussi à annoncer qu'on accepte HTTPS, ce qui permettra d'abandonner HSTS). Les clients HTTP plus anciens, évidemment, ne connaissent pas le système SVCB/HTTPS et il faut donc garder une configuration pour eux (par exemple des adresses IP à l'apex). Il y a aussi les autres méthodes, comme le Alt-Svc: du RFC 7838. La section 9.3 du RFC décrit le comportement attendu lorsque les différentes méthodes coexistent.

Faites attention toutefois, lorsque vous mettez ce type d'enregistrements dans votre zone, je ne connais pas encore d'outils de test permettant de vérifier la syntaxe des enregistrements, encore moins leur correspondance avec la réalité (par exemple, SSLLabs ne semble pas le faire). C'est un problème général de la signalisation sur l'Internet, quand on signale (notamment via le DNS) les capacités d'un serveur : le logiciel client doit de toute façon être prêt à tout, car il ne peut jamais être sûr que le signal est conforme aux faits.

En parlant d'anciens logiciels (clients et serveurs), vous pouvez trouver une liste de mises en œuvre de SVCB/HTTPS. Attention, elle est incomplète et pas à jour. Notez qu'il y a parfois des contraintes particulières, ainsi, il semble que Firefox ne demande des enregistrements HTTPS que s'il utilise DoH. iOS envoie des requêtes HTTPS depuis iOS 14, publié en septembre 2020, ce qui avait étonné, à l'époque.

En parlant de Firefox, s'il est assez récent, et s'il est configuré pour faire du DoH, vous pouvez tester le SVCB/HTTPS en allant dans about:networking#dnslookuptool. En entrant un nom de domaine, le champ « RR HTTP » doit renvoyer l'enregistrement HTTPS.

Avec un tcpdump récent, voici le trafic DNS utilisant le nouvel enregistrement DNS, qu'on peut observer sur un serveur faisant autorité pour bortzmeyer.org :

09:49:23.354974 IP6 2a04….31362 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 13024% [1au] HTTPS? www.bortzmeyer.org. (47)
09:52:06.094314 IP6 2a00….56551 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 40948% [1au] HTTPS? wWw.bOrTZmEyER.ORg. (62)
10:06:21.501437 IP6 2400….11624 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 59956 [1au] HTTPS? doh.bortzmeyer.fr. (46)
10:06:21.999608 IP6 2400….36887 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 17231 [1au] HTTPS? radia.bortzmeyer.org. (49)
10:25:53.947096 IP6 2001….54476 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 26123% [1au] HTTPS? www.bortzmeyer.org. (47)
  

Si votre tcpdump est plus ancien, vous verrez Type65 au lieu de HTTPS.

Sinon, si vous aimez les bricolages (et celui-ci sera de moins en moins utile avec le temps, au fur et à mesure que les serveurs géreront ce type), pour fabriquer les enregistrements, vous pouvez utiliser cet outil, qui va fabriquer la forme binaire, directement chargeable par les serveurs faisant autorité :

% perl type65_https.pl 'example.net HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.42" ipv6hint="2001:db8::42"'
example.net. TYPE65 ( \# 41 00010000010006026833026832000400
	04c000022a0006001020010db8000000 000000000000000042 )
  

(Il faut un Net::DNS récent sinon « unknown type "HTTPS" at /usr/share/perl5/Net/DNS/RR.pm line 671. in new Net::DNS::RR( www.bortzmeyer.org HTTPS 1 . alpn="h2" ) at type65_https.pl line 30. ».)

Quelques articles pas mal :

• Simple HTTPS Records par Kal Feher.
• Use of HTTPS Resource Records avec le résultat de mesures sur le déploiement effectif.
• Autres mesures dans le monde, l'article Deciphering the Digital Veil: Exploring the Ecosystem of DNS HTTPS Resource Records.

Voici un RFC assez futuriste qui explore à quoi pourrait ressembler un futur « Internet » quantique. Je divulgâche tout de suite : ce ne sera pas de si tôt.

Quelques avertissements s'imposent d'abord. Avant tout, rappelez-vous que la quantique produit des résultats qui sont parfaitement cohérents théoriquement et très bien vérifiés expérimentalement mais qui sont hautement non-intuitifs. Avant d'aborder le monde merveilleux de la quantique, n'oubliez pas d'oublier tout ce que vous croyez savoir sur le monde physique. Et ne comptez pas trop sur moi comme guide, on sort nettement ici de mon domaine de compétence. Ensuite, « quantique » est un terme à très forte charge marketing (moins que « IA » mais davantage que « métavers » ou même « blockchain », qui semblent bien passés de mode). Il faut donc être prudent chaque fois qu'un commercial ou un éditorialiste va dire que « c'est quantique » ou que « la quantique va bouleverser tel ou tel domaine ». Enfin, il y a loin de la coupe aux lèvres : de même qu'on n'a pas encore d'ordinateur quantique utile, on n'a pas encore de réseau quantique. Le RFC est à juste titre prudent, pointant les différents obstacles qui restent sur le chemin de l'Internet quantique.

Bon, ces précautions étant posées, qu'est-ce qu'un réseau quantique et pourquoi y consacrer un RFC ? La section 1 du RFC le résume : un réseau quantique est un réseau qui ferait communiquer des dispositifs quantiques pour faire des choses inimaginables avec un réseau classique. Il s'appuierait sur des propriétés spécifiques au monde quantique, notamment l'intrication, propriétés qui n'ont pas d'équivalent dans le monde classique. Attention, et le RFC insiste bien là-dessus, personne n'envisage de remplacer l'Internet classique par un Internet quantique (de la même façon que les futurs ordinateurs quantiques, étant loin d'être généralistes, ne remplaceront pas les ordinateurs classiques). Au contraire, le scénario envisagé est celui d'un réseau hybride, partiellement quantique. (Une lecture recommandée par le RFC est « The quantum internet ».)

Un exemple typique qui ne serait pas possible avec un réseau classique est celui de la distribution quantique de clés (parfois appelée du terme erroné de « cryptographie quantique »), dont l'utilité pratique est douteuse mais qui est assez spectaculaire et, contrairement à d'autres applications, est assez avancée techniquement. D'autres applications sont envisageables à plus long terme. C'est le cas par exemple du blind quantum computation, qui n'a pas encore d'article Wikipédia mais est expliqué dans cet article.

En laboratoire, beaucoup de résultats ont été obtenus. Les chercheurs et chercheuses ont déjà mis au point bien des dispositifs physiques étonnants. Mais à l'échelle du réseau, il n'y a pas encore eu beaucoup de travaux. Le RFC compare cette situation à celle d'un réseau classique où on aurait des fibres optiques et des lasers pour les illuminer mais aucun protocole de transport, aucun mécanisme de routage, encore moins de moyens de gérer le réseau. Développer une application pour un réseau quantique revient à toucher directement au matériel, comme, pour un réseau classique, s'il fallait que chaque application parle aux interfaces physiques, sans avoir d'interface de plus haut niveau comme les prises.

La section 2 du RFC est un rappel sur la quantique. Comme dit plus haut, c'est un domaine riche et complexe, où l'intuition ordinaire ne sert pas à grand'chose. Donc, lire ce rappel est une bonne idée mais n'espérez pas tout comprendre si vous n'êtes pas spécialiste de la question. Cette section est conçue pour des gens qui ne connaissent rien à la physique quantique, elle recommande, pour aller plus loin, le livre de Sutor Dancing with Qubits ou bien celui de Nielsen et Chuang, Quantum Computation and Quantum Information.

Le rappel commence avec la notion d'état quantique. Vous avez sans doute déjà entendu dire qu'un bit classique peut prendre deux valeurs, 0 ou 1, alors que son équivalent quantique, le qubit, a un état qui est une superposition de valeurs possibles, avec des probabilités. Lorsqu'on le mesure, on trouve un 0 ou un 1. (Oui, comme le célèbre chat qui est à la fois vivant et mort.) Attention, ces non-certitudes ne sont pas la conséquence d'un manque d'information mais sont une propriété fondamentale du monde quantique (Alain Aspect a eu un prix Nobel pour avoir prouvé cela). Notez que les versions HTML ou PDF du RFC sont recommandées ici, car il y a quelques équations. Comme un qubit est dans un état qui superpose les deux valeurs possibles, les opérations quantiques agissent sur tout l'état, par exemple l'équivalent quantique d'une porte NOT va inverser les probabilités du 0 et du 1 mais pas transformer un 0 en 1.

Le terme « qubit » (et cette distinction revient souvent dans le RFC) peut désigner aussi bien le concept abstrait que le truc physique qui va le mettre en œuvre (il existe plusieurs techniques pour fabriquer un engin qui gérera des qubits).

On peut ensuite assembler des qubits et, très vite, le nombre de possibilités croît. Mais l'intérêt de mettre des qubits ensemble est qu'on peut les intriquer et ce concept est au cœur de beaucoup de solutions quantiques, notamment du réseau quantique. Une fois intriqués, les deux qubits verront leur sort lié. Une mesure sur l'un affectera l'autre. (Rappel : la quantique n'est pas intuitive et l'intrication n'a pas d'équivalent dans le monde non-quantique, celui sur lequel a été bâtie notre intuition.) La mesure, comme toujours en quantique, est « destructive » au sens où elle ramène à un système classique (le qubit vaut 0 ou 1 quand on le mesure, pas un mélange des deux, et le chat est vivant ou mort quand on ouvre la boite).

Cette intrication est au cœur des réseaux quantiques (section 3 du RFC). Tous les projets de réseaux quantiques utilisent cette propriété (qui, rappelons-le, n'a pas d'équivalent non-quantique). L'intrication permet de corréler deux nœuds du réseau. Par exemple, pour se mettre d'accord sur une valeur, deux machines n'ont pas besoin de faire tourner des algorithmes de consensus, elles peuvent utiliser deux qubits intriqués, chacune en gardant un. Quand une machine lira la valeur de son qubit, elle sera certaine de la valeur lue par l'autre. Et l'intrication ne peut pas être partagée : un tiers ne peut pas s'intriquer avec une intrication existante, ce qui peut avoir des applications en sécurité.

Un réseau quantique est donc défini par notre RFC comme un ensemble de nœuds qui peuvent échanger des qubits intriqués.

Bon, tout ça, c'est très joli, mais comment on le réalise, ce réseau quantique ? La section 4 se penche sur les défis :

• Comme toute mesure détruit le caractère quantique du qubit et le transforme en un bit ordinaire, des opérations banales dans le monde classique, comme la copie d'un bit, deviennent non triviales.
• Et copier un qubit sans le mesurer ? On ne peut pas (c'est le théorème d'impossibilité du clonage).
• Tout cela rend très difficile la correction d'erreurs. Un réseau réel, reposant sur des objets physiques, va forcément voir des erreurs (un rayon cosmique passe et paf, un 0 est transformé en 1) et de nombreuses techniques existent pour gérer ce problème dans le monde classique. Mais elles ne peuvent en général pas s'appliquer dans le monde quantique, qui va donc avoir un problème de fidélité : la fidélité est la conformité à ce qu'on souhaitait (elle va de 0 à 1), et les applications doivent en tenir compte.

Distribuer sur le réseau des qubits quelconques n'est pas forcément facile, donc le RFC suggère de plutôt distribuer des paires de Bell. On peut alors plus facilement (tout est relatif) faire de la téléportation, c'est-à-dire « transporter » un qubit d'un point à un autre. Ce n'est pas une violation du théorème d'impossibilité du clonage puisque le qubit n'est pas copié (il disparait de son point de départ). Notez que le terme de « téléportation » est surtout marketing : vous ne pourrez pas déplacer votre chat ou vous-même de cette façon.

Dernier problème, amplifier le signal (sans le copier !) pour tenir compte de sa dégradation avec la distance. Il existe une astuce, l'échange d'intrication, que je ne vais pas essayer d'expliquer, mais qui permet des réseaux quantiques sur des distances importantes.

Revenons à la correction d'erreurs. Les réseaux quantiques ne sont pas complètement démunis, et ont des solutions possibles, comme les codes quantiques.

OK, on a vu que le monde quantique était très spécial. Donc, le réseau quantique va être bizarre aussi, aux yeux de quelqu'un qui a l'habitude des réseaux classiques (section 5 du RFC). Par exemple, il fera face à ces problèmes :

• C'est bien joli, les paires de Bell, mais ce n'est pas l'équivalent d'un paquet portant une charge utile. Il n'y a pas l'équivalent de l'en-tête du paquet, et le réseau quantique va donc devoir utiliser un réseau classique pour l'information de contrôle. On ne fera pas un réseau purement quantique.
• Toute action sur des qubits intriqués doit être coordonnée entre les nœuds puisque l'action sur un qubit va déterminer le résultat d'une action sur les autres (il faut donc que chaque nœud sache contacter les autres).

Répétons-le, chaque nœud du réseau quantique devra également être relié à un réseau classique. Le réseau sera donc complexe et son administration pas évidente.

Une fois qu'on a accepté cela, le réseau classique pourra s'occuper d'opérations comme la construction des tables de routage, pour laquelle les algorithmes et méthodes classiques semblent suffire. On n'aura donc peut-être qu'un seul plan de contrôle (le classique) mais deux plans de données, le classique et le quantique.

Que faut-il construire comme machines pour le plan de données quantique ? D'abord, des répéteurs quantiques qui vont pouvoir créer les intrications, les échanger et contrôler la fidélité. Ensuite :

• Des routeurs quantiques, qui, en plus des fonctions ci-dessus, participeront au routage.
• Les nœuds ordinaires, des répéteurs qui ne participent pas au routage.
• Les nœuds terminaux, qui pourront émettre et recevoir des qubits mais pas faire d'échange d'intrication. C'est là que tourneront les applications.

Facile, me direz-vous ? Non, construire ces machines va nécessiter de s'attaquer à quelques problèmes physiques :

• Stocker un qubit est un défi ! Le monde classique n'aime pas les objets quantiques et essaie régulièrement de les rappeler à ses lois. Les bruits divers de l'environnement font rapidement perdre aux qubits leurs propriétés quantiques. (C'est d'ailleurs pour cela que vous ne rencontrez pas de chats de Schrödinger dans la vraie vie.) Cela se nomme la décohérence et c'est l'un des principaux obstacles sur la route des réseaux quantiques (ou des calculateurs quantiques). Les durées de vie qu'on atteint étaient, lors de la rédaction du RFC, de l'ordre de la seconde (ou de la minute si on n'est pas connecté au réseau, source de perturbations).
• La capacité des liens quantiques est un autre problème. Générer des qubits intriqués prend du temps. Quand on en fabrique dix par seconde, on est contents. Bien sûr, la technique progresse sans cesse (pas mal des références du RFC sont un peu datées, car il a mis du temps à sortir) mais pas assez.
• On l'a dit, on peut réaliser des qubits intriqués par différentes méthodes physiques, avec des performances différentes selon la métrique utilisée. Mais ces méthodes ne communiquent pas entre elles, ce qui veut dire que tous les nœuds du réseau doivent utiliser la même.

Si vous n'êtes pas découragé·e (mais il ne faut pas l'être : même si les difficultés sont colossales, le chemin est rigolo), il faut maintenant, en supposant qu'on aura les composants de base d'un réseau, les assembler. (À moins que le choix décrit dans le RFC des paires de Bell et de l'échange d'intrication ne soit remis en cause par les futurs progrès…) La section 6 se penche sur la question. Elle démarre par un bel excès d'optimisme, en expliquant que, contrairement à ce qui s'est passé avec l'Internet classique, on a de l'expérience sur la construction de réseau, et qu'on pourra donc ne pas faire d'erreur comme la taille trop réduite des adresses IPv4.

Des services essentiels pour un réseau réel seront difficiles à assurer sur un réseau quantique. Par exemple, l'impossibilité du clonage interdira d'utiliser un logiciel équivalent à tcpdump (remarquez, pour la sécurité, c'est un plus). Le RFC liste les principes de base d'un réseau quantique :

• Le service de base sera l'intrication.
• La fidélité est aussi un service (contrairement au réseau classique où on peut espérer une fidélité parfaite).
• Le temps va être un facteur crucial, compte tenu de la décohérence. Pas question de faire patienter des qubits trop longtemps dans une file d'attente, par exemple.
• Il faudra être flexible, notamment parce que le matériel va continuer à évoluer.

Et le RFC se termine par une exploration d'une architecture de réseau quantique possible, inspirée de MPLS. Dans ce réseau (pour l'instant) imaginaire, tout fonctionne en mode connecté (comme MPLS) : on doit d'abord créer un circuit virtuel (car créer les paires de Bell et les utiliser va nécessiter de la coordination, donc il vaut mieux établir d'abord une connexion). Ce QVC (Quantum Virtual Circuit) a des caractéristiques comme une qualité de service choisie, qui se décline en, par exemple, une capacité mesurée en nombre de paires de Bell par seconde et bien sûr une fidélité (toutes les applications des réseaux quantiques n'ont pas les mêmes exigences en terme de fidélité). La signalisation peut être décentralisée (comme avec RSVP) ou centralisée (comme avec OpenFlow). Comme vous le verrez en lisant cette conclusion du RFC, les détails sont encore approximatifs.

Ce RFC a mis longtemps à être écrit, vous pouvez trouver une description ancienne du projet sur le blog de l'IETF. Notez que l'écriture de ce RFC a été en partie financée par la Quantum Internet Alliance européenne.

N'hésitez pas à vous plonger dans la bibliographie très détaillée de ce RFC, vous y trouverez beaucoup de lectures passionnantes. Il y a même déjà des livres entiers sur les réseaux quantiques comme celui de Van Meter.

Ce numéro de la revue d'histoire « Le temps des médias » est consacré à la place des animaux dans les médias et il y a beaucoup à dire !

Tous les articles sont passionnants mais, parmi ceux qui m'ont particulièrement instruit :

• L'histoire de l'« ours Martin » (qui n'était pas un ours unique, mais un nom générique) au Jardin des plantes, par Olivier Vayron. Si les médias de l'époque adoraient les récits (presque tous imaginaires) d'agressions commises par Martin sur les visiteurs, la réalité est plus glauque : ce sont les humains qui agressaient l'ours du zoo, souvent de manière lâche et ignoble.
• L'analyse de la place de l'animal sauvage dans les récits d'aventure bon marché du XIXe siècle, par Sophie Bros. Peu de souci de véracité ou même de vraisemblance dans ces récits conçus pour de la production et de la distribution de masse. Dans le train de l'époque, tiré par une locomotive à vapeur, on avait le temps de se délecter d'histoires toutes pareilles, où le courageux explorateur européen venait à bout de toute une ménagerie de bêtes féroces et exotiques.
• Plus actuel, un article de Félix Patiès détaille la polémique au sein de la Fédération Anarchiste sur une émission « antispéciste » de Radio Libertaire. Difficile équilibre entre un désir d'ouverture à d'autres courants (d'autant plus importante que l'ARCOM exige une production minimum de contenus originaux) et nécessité, pour une organisation politique, de ne pas accepter n'importe quoi sur son antenne, notamment lorsque cela s'oppose directement à sa ligne politique.
• Toujours dans une actualité plus récente, une étude détaillée de Michel Dupuy sur la construction de l'image de l'oiseau mazouté, comme symbole des destructions que la société industrielle inflige à l'environnement. Ce malheureux oiseau a également été utilisé pour de la propagande de guerre pendant la guerre du Golfe.
• Les fanas de géopolitique trouveront aussi de quoi les intéresser, avec l'article de Zhao Alexandre Huang, Mylène Hardy et Rui Wang sur l'utilisation des pandas par la propagande chinoise. Derrière la mignoncitude, Beijing tire les ficelles.
• Et bien sûr un article sur le rôle des chats sur l'Internet et un sur celui des chiens dans les films de Disney (article que j'ai trouvé extrêmement pro-Disney…)

On peut se procurer ce numéro sous forme papier chez l'éditeur et sous forme numérique (paradoxalement bien plus chère) sur cairn.info. PS : oui, le site Web officiel de la revue n'est pas à jour et est plein de mojibake.

L'idée de base de ces « zones catalogue » est d'automatiser la configuration d'une nouvelle zone DNS sur les serveurs secondaires, en publiant dans le DNS les caractéristiques des zones qu'ils devront servir. Cela concerne donc surtout les gros hébergeurs qui ont beaucoup de zones.

Petit rappel : une zone, dans le DNS, est une partie contigüe de l'arbre des noms de domaine, gérée comme un tout (mêmes serveurs faisant autorité). Ainsi, si vous venez de louer le nom machin.example, un hébergeur DNS va configurer ses serveurs pour faire autorité pour ce nom. Par exemple, avec le logiciel NSD, sur le primaire (serveur maitre) :

zone:
        name: "machin.example"
        zonefile: "primary/machin.example"
        # Les serveurs secondaires :
        notify: 2001:db8:1::53
        provide-xfr: 2001:db8:1::53
        …

Et, sur un serveur secondaire (serveur esclave), qui transférera la zone depuis le primaire (RFC 5936) :

zone:
   name: "machin.example"
   # Le primaire :
   allow-notify: 2001:db8:cafe::1 NOKEY
   request-xfr: AXFR 2001:db8:cafe::1 NOKEY

Si on gère beaucoup de zones, avec des ajouts et des retraits tout le temps, l'avitaillement manuel est long et risqué (et si on oublie un serveur ?). Éditer ces fichiers sur tous les serveurs secondaires devient vite pénible. Et si les logiciels sur les secondaires sont différents les uns des autres (ce qui est recommandé, pour la robustesse), il faut se souvenir des différentes syntaxes. Pourquoi faire manuellement ce qu'on peut automatiser ? C'est le principe des zones catalogue.

Le principe est simple : une zone catalogue est une zone comme une autre, produite par les mêmes mécanismes (par exemple emacs) et qui sera servie par un serveur primaire à tous les secondaires, qui changeront alors automatiquement leur configuration en fonction du contenu de la zone catalogue. Chaque zone à configurer est un enregistrement de type PTR, dont la partie gauche est une étiquette interne et la partie droite indique le nom de la zone. Ici, on configure la zone rutaba.ga, l'étiquette (qui doit être unique) label1 est à usage interne (section 4.1 du RFC) :

label1.zones.catalog.example. IN PTR rutaba.ga.

Le reste est listé sous forme de propriétés (section 4.2). Une propriété évidente est l'adresse IP du primaire. Pour l'instant, elle doit être indiquée via le composant ext qui désigne les propriétés pas encore normalisées :

primaries.ext.catalog.example.    IN AAAA 2001:db8:bad:dcaf::42

La liste des propriétés figure dans un registre IANA.

À l'heure actuelle, de nombreux logiciels gèrent ces zones catalogues. Le site Web du projet (pas mis à jour depuis très longtemps) en liste plusieurs.

Voici un exemple complet de zone catalogue :

; -*- zone -*-
catalog.example.    IN SOA ns4.bortzmeyer.org. stephane.bortzmeyer.org. 2023120902 900 600 86400 1
catalog.example.    IN NS invalid.   ; Le NS est inutile mais
                         ; obligatoire et "invalid" est la valeur
                         ; recommandée (section 4).
version.catalog.example.    IN TXT "2"  ; Obligatoire, section 4.2.1

label1.zones.catalog.example. IN PTR rutaba.ga.
primaries.ext.catalog.example.    IN AAAA 2001:db8:bad:dcaf::42

La configuration de BIND pour l'utiliser :

# La zone catalogue se charge comme n'importe quelle zone. Ceci dit,
# vu le caractère critique de la zone catalogue, la section 7 du RFC
# insiste sur l'importance de sécuriser ce transfert, par exemple avec
# TSIG (RFC 8945) :
zone "catalog.example" {
        type slave;
        file "catalog.example";
        masters {
              2001:db8:666::;
        };            

};

# Et, ici, on la désigne comme spéciale :
options {
   ...      
   catalog-zones {
     zone "catalog.example"
              in-memory no;
   };
};

Naturellement, comme toujours lorsque on automatise, on risque le syndrome de l'apprenti sorcier. Attention donc en générant la zone catalogue. Comme le note le RFC (section 6) : « Great power comes with great responsibility. Catalog zones simplify zone provisioning by orchestrating zones on secondary name servers from a single data source: the catalog. Hence, the catalog producer has great power and changes must be treated carefully. For example, if the catalog is generated by some script and this script generates an empty catalog, millions of member zones may get deleted from their secondaries within seconds, and all the affected domains may be offline in a blink of an eye. »

Michel Pastoureau continue son exploration de l'histoire culturelle des animaux avec la baleine.

D'abord, une précision, c'est un livre d'histoire des mentalités, pas un livre de zoologie. Le terme « baleine », dans le passé, pouvait désigner beaucoup d'animaux qu'on n'appelerait pas « baleine » aujourd'hui. L'idée est de faire le tour, de l'Antiquité à nos jours, sur la vision que les humains ont de la baleine. C'est un animal qui, par sa taille, par le milieu jugé hostile où il vit et par le fait qu'il était très mal connu jusqu'au XIXe siècle, est un parfait support de fantasmes. En gros, jusqu'au XXe siècle, la baleine est monstrueuse, inquiétante, incarnation du Mal, puis elle change tout à coup ou, plutôt, la vision qu'on en a change et on se met à la considérer comme gentille, menacée, et digne d'être protégée (elle est, avec le panda, un des animaux iconiques des campagnes de protection de la nature).

Ce retournement est récent. Le christianisme voyait plutôt la baleine négativement (cf. l'aventure de Jonas, même si la Bible ne dit pas clairement si c'était une baleine, ou un très gros poisson). Les marins aimaient décrire les dangers terribles, et imaginaires, qu'elle faisait courir aux bateaux. Et bien sûr, Moby-Dick n'est pas un modèle de gentillesse, même si son chasseur ne vaut pas mieux. On l'a dit, ce livre est une histoire culturelle d'humains, donc toutes les projections n'ont pas grand'chose à voir avec les baleines réelles.

Ah, et le livre est magnifiquement illustré, les dessins médiévaux sont très bien reproduits, en grand et avec de belles couleurs (vous trouverez celui-ci p. 59). Inutile de rappeler que le réalisme n'était pas le principal souci des auteurs de ces dessins…

(Tiens, j'ai terminé ce livre juste avant de commencer la série télé danoise Trom, où la chasse à la baleine aux iles Féroé et les polémiques que cela suscite sont la toile de fond de l'intrigue policière.)

Un passionnant livre détaillant l'histoire de l'ENIAC, l'un des premiers ordinateurs. Contrairement à beaucoup d'autres textes sur l'ENIAC, celui-ci est très détaillé techniquement et ne vous épargne pas les informations précises sur le fonctionnement de cette bête, notamment de ses débuts où la programmation se faisait en soudant et désoudant.

L'ENIAC a été largement traité dans de nombreux ouvrages et articles. De nombreux mythes et légendes ont été développés, malgré le fait qu'on dispose d'une quantité énorme d'informations de première main, accessible aux historiens (beaucoup plus que pour le Colossus, secret militaire et dont beaucoup de documents ont été détruits). Mais depuis ses débuts, l'ENIAC a été un objet médiatique, très publicisé (pendant la guerre, il n'était que confidentiel, pas secret, encore moins très secret, et il a été déclassifié tout de suite après la guerre). Résultat, tout le monde avait quelque chose à dire sur l'ENIAC.

Par exemple, alors que les premières histoires sur l'ENIAC ne mentionnaient que des hommes, on a vu plus récemment des histoires affirmer en sens inverse que tout avait été fait par des femmes, les six de l'ENIAC. Le récit désormais classique est qu'elles faisaient la programmation de l'ENIAC, les « inventeurs » classiques, Eckert et Mauchly ne s'occupant « que » du matériel. Écoutant pour la Nième fois cette affirmation lors d'un exposé au FOSDEM, je me suis demandé « mais ça voulait dire quoi, au juste, programmer sur l'ENIAC » et j'ai lu ce livre.

Plusieurs facteurs rendent compliqué de répondre à cette question : d'abord, comme le notent bien les auteurs du livre, l'ENIAC, qui a eu une durée de vie très longue (de 1945 à 1955, bien plus qu'un smartphone d'aujourd'hui), a beaucoup évolué, cet ordinateur unique, qui ne faisait pas partie d'une fabrication en série, était modifié en permanence. Ainsi, la question de savoir si l'ENIAC était une machine à programme enregistré (plutôt qu'une « simple » calculatrice où le programme était à l'extérieur) a plusieurs réponses possibles (« plutôt non » au début de sa carrière, « plutôt oui » à la fin). Et la façon de « programmer » l'ENIAC a donc beaucoup changé.

Ensuite, bien que l'ENIAC ait laissé une énorme pile de documentation (comme les journaux d'exploitation, qui étaient bien sûr entièrement papier) pour les historiens, tout n'a pas été décrit. Des interactions informelles entre les membres de l'équipe n'ont pas forcément laissé de trace. Plusieurs couples mari-femme travaillaient sur l'ENIAC (comme Adele et Herman Goldstine) et il n'est pas facile de séparer leurs contributions (à chaque époque, on a mis en valeur les contributions de l'une ou de l'autre, selon la sensibilité de l'époque).

Enfin, comme tout était nouveau dans cette machine, même les acteurs et les actrices du projet n'avaient pas toujours une vision claire. Même une distinction comme celle entre matériel et logiciel était loin d'être évidente à cette époque. Et la notion même de « programme » était floue. Les « six de l'ENIAC » avaient été embauchées comme « opératrices », plutôt à déboguer des programmes existants (la machine avait mauvais caractère et les bogues étaient souvent d'origine matérielle, un composant qui brûlait, et le déboguage nécessitait donc de fouiller dans les entrailles de la bête) avant que leur travail n'évolue vers quelque chose qui ressemblait beaucoup plus à la programmation actuelle (sans que leurs fiches de poste ne suivent cette évolution).

Et cette programmation, sur une machine qui était loin d'être bâtie sur un modèle en couches bien propre, nécessitait des compétences variées. Ainsi, à un moment, l'ENIAC a reçu des nouvelles mémoires, dites « lignes à retard », où une onde sonore était envoyée dans un tube de mercure. La lenteur des ondes sonores, comparée à la vitesse de l'électronique, faisait que cela permettait de mémoriser (mais pas pour toujours) une information. Comme la ligne à retard stockait plusieurs informations, et était strictement FIFO, l'optimisation du programme nécessitait de bien soigner l'ordre dans lequel on mettait les variables : il fallait qu'elles arrivent à la fin du tube pile au moment où le programme allait en avoir besoin. Le programmeur ou la programmeuse avait donc besoin d'une bonne connaissance du matériel et de la physique ! En lisant ce livre, on comprend mieux les exploits quotidiens que faisaient les « six de l'ENIAC » et leurs collègues.

Il y avait plein d'autres différences entre la programmation de l'époque et celle d'aujourd'hui. Par exemple, l'ENIAC manipulait des nombres décimaux (son successeur, l'EDVAC passera au binaire). Les débats étaient très vivants au sein de l'équipe sur la meilleure façon de dompter ces nouvelles machines. Ainsi, une discussion récurrente était de savoir s'il valait mieux une machine complexe sachant faire beaucoup de choses ou bien une machine simple, ne faisant que des choses triviales, mais optimisée et plus générale. La deuxième possibilité nécessitait évidemment que la complexité soit prise en charge par les programmes. Bref, un débat qui évoque beaucoup celui CISC contre RISC. Au milieu de tous ces débats, il peut être difficile de distinguer la contribution de chacun ou de chacune. Ainsi, on présente souvent von Neumann comme l'inventeur de l'ordinateur moderne à programme enregistré (et où le code est donc traité comme une donnée), dans son fameux first draft. mais d'autres témoins relativisent son rôle en estimant que le first draft ne faisait que documenter par écrit les idées qui circulaient dans l'équipe. Les auteurs du livre se gardent de trancher (la vérité peut aussi être quelque part entre les deux). Les éventuels désaccords de personnes compliquent aussi les choses, par exemple Adele Goldstine et les six de l'ENIAC n'ont pas vraiment les mêmes souvenirs sur la création de cette équipe et son rôle. (Contrairement à ce qui est parfois raconté, les six de l'ENIAC n'étaient pas des victimes passives du sexisme, et ont largement fait connaitre leurs souvenirs et leurs opinions, contrairement à ceux et celles de Bletchley Park, tenu·es à un secret militaire rigoureux, même longtemps après la guerre.)

Point amusant, l'ENIAC est entré en service à une époque où les concepts de la cybernétique étaient à la mode et cela a influencé le vocabulaire de l'informatique. Si le terme de « cerveau électronique », par lequel était souvent désigné l'ENIAC, n'est pas resté, c'est avec l'ENIAC qu'on a commencé à utiliser une autre métaphore humaine, « mémoire » pour parle des dispositifs de stockage de l'information et, là, ce terme a perduré.

Outre les passions humaines, l'histoire de l'ENIAC a aussi été brouillée par des conflits motivés par l'argent. Eckert et Mauchly avaient tenté d'obtenir un brevet sur les concepts de base de l'ENIAC et le long conflit juridique sur ce brevet (finalement refusé) a été marqué par de nombreux témoignages officiels devant les tribunaux, témoignages qui ont pu figer certains souvenirs en fonction d'intérêts financiers.

En tout cas, le débat sur le rôle des six de l'ENIAC a occulté le rôle d'une autre catégorie, bien oubliée (on ne connait même pas leurs noms), les Rosie qui ont bâti le monstre, un engin qui occupait une immense pièce et avait nécessité beaucoup de travail manuel, peu reconnu.

Les auteurs notent d'ailleurs que bien des débats en histoire ne peuvent pas avoir de réponse simple. Ainsi, la recherche effrénée du « premier » (l'ENIAC était-il le premier ordinateur ?) n'a pas forcément, notent-ils, de sens. Déjà, cela dépend de la définition qu'on donne d'« ordinateur », ensuite, certains concepts émergent petit à petit, sans qu'il y ait un « moment Eurêka » où tout se révèle d'un coup. (Pour prendre l'exemple d'une autre polémique classique dans l'histoire de l'informatique, se demander qui a inventé le datagramme n'a pas plus de sens. Le concept est apparu progressivement, sans qu'on puisse citer, par exemple, l'article ou la conférence qui l'aurait exposé en premier.)

Le livre se termine d'ailleurs par une « histoire de l'histoire » de l'ENIAC, qui montre les nombreuses évolutions qu'il y a eu, et qu'il continuera à y avoir, sur cette machine. Comme souvent l'histoire suit le présent (les motivations de son époque) plutôt que le passé.

Merci à Valérie Schafer pour le conseil de lire ce livre, tout à fait ce qu'il faut pour comprendre ce que voulait dire « programmer l'ENIAC ».

Le court livre « The Bomber Mafia » est l'histoire de la controverse technico-politique au sein de l'armée de l'air des USA, juste avant la Deuxième Guerre mondiale et pendant celle-ci : comment utiliser le mieux possible les bombardiers, peut-on forcer un ennemi à capituler en le bombardant et comment ?

Ce n'est pas une étude historique, plutôt un récit journalistique, centré sur deux personnes, Haywood Hansell et Curtis LeMay. Pour simplifier, le premier était un représentant d'un groupe surnommé The Bomber Mafia, qui avait une confiance illimitée dans les capacités des bombardiers à atteindre leur objectif, à le toucher avec précision, et ainsi à contraindre l'ennemi à capituler. Avant la deuxième guerre mondiale, leurs idées n'avaient pas vraiment été testées, et les adversaires de la Bomber Mafia lui reprochaient justement sa tendance à aborder les problèmes sous un angle trop théorique. LeMay, d'un autre côté, tout aussi convaincu de la puissance des bombardiers, et qui allait faire une belle carrière après la guerre, était plus pragmatique. Tous les deux s'opposaient sur la question de l'utilisation des B-17 et des B-29 mais, à ce conflit, se superposait aussi celui de tous les aviateurs (dont Hansell et LeMay) contre les autres branches de l'armée qui estimaient que ces jouets très chers ne gagneraient pas la guerre à eux seuls (« aucun soldat ne s'est jamais rendu à un avion »).

Au débat entre les « théoriciens » de la Bomber Mafia et les « praticiens », qui voyaient bien que les bombardements ne se passaient pas aussi bien que dans les théories d'avant-guerre, se superposait un débat moral, la Bomber Mafia estimant que le progrès technique permettait au bombardier de frapper avec une précision absolue, ce qui limitait les dégâts collatéraux, alors que ses adversaires, voyant bien la difficulté à mettre les bombes en plein sur l'objectif, dans un monde réel plein de nuages, d'appareils déréglés, et de vents puissants en altitude, voulaient plutôt bombarder largement, sans se soucier des conséquences, notamment sur les civils, voire en les ciblant délibérement.

Le livre détaille (c'est sa meilleure partie) le cas d'un appareil présenté comme magique, le viseur Norden, une incroyable merveille d'ingéniosité et de précision, contenant un calculateur analogique et qui devait permettre à l'homme chargé de déclencher le largage des bombes de mettre en plein dans le mille. Malgré les promesses boursouflées de l'inventeur (un classique de l'innovation technologique), malgré la fascination de beaucoup d'aviateurs pour cette très haute technologie, coûteuse et très secrète (l'équipage avait ordre de tout faire pour détruire le viseur si le bombardier tombait), le viseur Norden n'a jamais tenu ses promesses. Spectaculaire en laboratoire, il marchait nettement moins bien à plusieurs milliers de mètres d'altitude, dans le froid et la condensation, à bord d'un avion en mouvement. Son échec a beaucoup contribué à décrédibiliser la Bomber mafia et à donner raison à LeMay et à sa pratique d'un bombardement très étendu, d'autant plus que LeMay ne s'encombrait pas d'arguments moraux. Mais la Bomber Mafia n'a apparemment jamais admis que les faits étaient plus forts que sa théorie, trouvant toujours des moyens de dire que, cette fois, ça allait marcher comme ils le disaient.

L'auteur, qui a nettement tendance à présenter Hansell comme le bon et LeMay comme le méchant, alors que tous les deux étaient dans la même armée et poursuivaient le même but, estime que le temps a donné raison à la Bomber Mafia, puisque, le numérique ayant remplacé l'analogique, le drone moderne peut frapper avec une précision parfaite. Est-ce que les militaires d'aujourd'hui peuvent vraiment, en plein dans le brouillard de la guerre, frapper pile où ils veulent, sans dégâts collatéraux ?

Ce court livre en anglais rassemble plusieurs textes sur les questions politiques liées à l'Internet comme la défense de la vie privée, le chiffrement, la normalisation, etc.

Le livre est disponible gratuitement en ligne mais vous pouvez préférer l'édition papier, qui a une curieuse mise en page, avec une couverture qui se tourne dans un sens inhabituel et les appels des notes de bas de page joliment décorés.

Vous y trouverez de nombreux articles, tous écrits par des spécialistes de l'Internet (et j'ai bien dit l'Internet, pas les GAFA, vous n'aurez pas le Nième article sur les turpitudes de Facebook, encore moins sur les derniers exploits de l'IA). C'est très intéressant et couvre beaucoup de sujets, dont certains sont rarement traités (comme l'article de Shivan Kaul Sahib sur les conséquences politiques des CDN). Mais, vu la taille du livre et le nombre de contributions, cela reste peu approfondi, donc ce livre vise plutôt un public de débutant·es. (Si vous suivez ces questions depuis quelques années, vous avez certainement déjà rencontré ces auteur·es et leurs textes.)

En France en 2024, le discours politique sur le monde arabo-musulman est souvent fondé sur une assignation identitaire, qui suppose que toute personne élevée dans un milieu musulman est forcément croyante, voire bigote, ou même islamiste. La réalité est différente et le monde arabo-musulman a lui aussi ses libres penseurs qui n'acceptent pas aveuglément les dogmes religieux, et encore moins les humains qui les utilisent pour assoir leur pouvoir. Cet ouvrage rassemble un certain nombre de contributions, très diverses, sur des libres penseurs dans l'histoire du monde arabo-musulman.

Tout le monde a entendu parler d'Omar Khayyam, bien sûr. Mais la plupart des autres libres penseurs décrits dans l'ouvrage sont nettement moins connus en Occident. Ils ne forment pas un groupe homogène : certains sont athées, d'autres simplement méfiants vis-à-vis de la religion organisée. Il faut aussi noter que le livre couvre treize siècles d'histoire et une aire géographique très étendue ; il n'est pas étonnant que la diversité de ces libres penseurs soit grande. Le livre contient aussi des textes qui remettent en perspective ces penseurs, par exemple en détaillant le mouvement de la Nahda ou bien en critiquant le mythe de la tolérance religieuse qui aurait régné en al-Andalus.

Le livre est assez décousu, vu la variété des contributeurs. On va de textes plutôt universitaires à des articles davantage militants (et certains sont assez mal écrits, je trouve, et auraient bénéficié d'une meilleure relecture). Mais tous ont le même mérite : tirer de l'oubli des libres penseurs souvent invisibilisés comme Tahar Haddad ou Ibn al-Rawandi. Et vous apprendrez de toute façon plein de choses (je ne connaissais pas le mutazilisme).

Cet atlas illustre (au sens propre) un certain nombre d'aspects du monde numérique (plutôt axé sur l'Internet). Beaucoup de données et d'infographies sous les angles économiques, sociaux et politiques.

L'ouvrage est très graphique, et riche. Tout le monde y trouvera des choses qui l'intéressent comme le spectaculaire tableau des systèmes d'exploitation p. 18 ou bien la représentation astucieuse de l'alternance des modes en IA p. 33 ou encore la visualisation de la censure en Russie p. 104 (tirée des travaux de Resistic). Les résultats ne sont pas forcément surprenants (p. 61, les youtubeurs les plus populaires sur les sujets de la voiture ou de la science sont des hommes, sur les sujet animaux, style et vie quotidienne, ce sont des femmes). Mais plusieurs articles mettent aussi en cause certaines analyses traditionnelles comme p. 82 celui qui dégonfle le mythe « fake news » (ou plus exactement leur instrumentalisation par les détenteurs de la parole officielle).

Les utilisations de l'Internet (en pratique, surtout les réseaux sociaux centralisés) sont très détaillées, par contre l'infrastructure logicielle est absente (la matérielle est présente via des cartes de câbles sous-marins et des articles sur l'empreinte environnementale).

Les infographies sont magnifiques mais souvent difficiles à lire, en raison de leur petite taille (sur la version papier de l'ouvrage) et du fait que chacune est le résultat de choix de présentation différents. D'autre part, les couleurs sont parfois difficiles à distinguer (p. 31 par exemple). Et l'axe des X ou celui des Y manque parfois, comme dans l'article sur la viralité p. 56 qui n'a pas d'ordonnées. Il faut dire que certaines réalités sont très difficiles à capturer comme la gouvernance de l'Internet p. 101, sujet tellement complexe qu'il n'est pas sûr qu'il aurait été possible de faire mieux.

Plus gênantes sont les bogues comme p. 31 la Quadrature du Net et FFDN classées dans « Secteur économique et start-ups ». Ou bien p. 37 LREM considéré comme plus à gauche que le PS…

Si vous aimez les histoires de bateau à voile, avec naufrages, mutineries, iles désertes et tout ça, ce roman vous emballera. Sauf que ce n'est pas un roman, le navire « The Wager » a vraiment existé et vraiment fait vivre toutes ces aventures à son équipage.

Le livre a été écrit par David Grann, connu comme l'auteur de « Killers of the flower moon ». En attendant que Scorsese en fasse un film, comme il l'a fait de « Killers of the flower moon », je recommande fortement la lecture du livre. « The Wager », navire de guerre anglais, n'a eu que des malheurs pendant la guerre de l’oreille de Jenkins. Départ retardé, épidémies à bord alors même qu'il était encore à quai, problèmes divers en route, une bonne partie de l'équipage mort alors même que le Wager n'a pas échangé un seul coup de canon avec les Espagnols. Le bateau finit par faire naufrage en Patagonie. À cette époque, sans radio, sans GPS, sans même de mesure de longitude correcte, de tels naufrages n'étaient pas rares. (Le livre parle aussi d'une escadre espagnole qui a tenté d'intercepter celle où se trouvait le Wager, et n'a pas été plus heureuse.)

Ce qui est plus original dans le cas du Wager est que des survivants sont rentrés séparement en Angleterre et qu'ils ont raconté des histoires très différentes sur le naufrage et la mutinerie qui a suivi. Chacun (en tout cas ceux qui savaient écrire ou bien trouvaient quelqu'un pour le faire pour eux) a publié sa version et l'auteur de ce livre essaie de rendre compte des différents points de vue.

Donc, pas un roman mais autant de rebondissements que dans un roman. Vous feriez comment, vous, pour rentrer en Angleterre si vous étiez coincé sur une des iles les plus inhospitalières d'une des régions les plus inhospitalières du monde ? Le plus extraordinaire est que plusieurs groupes de survivants y sont arrivés, par des moyens différents.

Sinon, les informaticien·nes noteront que l'arrière-grand-père d'Ada Lovelace était à bord (il fait partie de ceux qui ont écrit un livre sur le voyage du Wager). Les fans de Patricio Guzmán verront que cela se passe au même endroit que son film « Le bouton de nacre » (et on croise dans le livre les mêmes Kawésqars).

Comme les lecteurices de ce blog le savent sûrement, je pense que la place prise par le numérique dans nos vies justifie qu'on réfléchisse sérieusement à cette transition que nous vivons. Donc, ce livre est une bonne idée. Mais, comme beaucoup d'ouvrages collectifs, il souffre d'un manque évident de coordination entre les auteurices, dont les différentes contributions sont de niveaux très inégaux.

On y croise ainsi des baratineurs classiques comme Luc Ferry, personnage qu'on aurait pu penser définitivement démonétisé. Sans surprise, il parle d'un sujet cliché, le transhumanisme (le mannequin de paille classique de beaucoup d'« intellectuels » français). Sans aller aussi loin dans la vacuité, on trouve aussi dans ce livre des articles par des auteurs dont on peut se demander s'ils maitrisent leur sujet. Ainsi une auteure présentée comme spécialiste des questions bancaires déplore que l'IA a des biais quand elle décide d'accorder un prêt ou pas (un exemple, typique de la sur-utilisation de la notion de biais ; évidemment qu'un outil d'aide à la décision en matière de prêts va être mal disposé envers les gens ayant des revenus faibles et irréguliers). Le texte de présentation de chaque contribution a aussi sa part de responsabilité, comme celui de l'article sur la chaine de blocs qui dit que les données sont cryptées (et, non, le problème n'est pas l'utilisation de cet terme, « chiffrées » n'aurait pas été mieux). Enfin lisant un livre qui se veut de réflexion sur le numérique, je vois la phrase « les technologies digitales sont des technologies qui sont faciles à prendre en main », et je me demande si l'auteur l'a fait exprès.

Bon, assez critiqué, il y a aussi des analyses intéressantes (j'ai dit intéressantes, pas forcément que j'étais 100 % d'accord) : Pauline Türk réfléchit sur l'utilisation du numérique pour améliorer le processus démocratique, Ophélie Coelho traite de géopolitique et détaille les risques liés à la dépendance vis-à-vis d'entreprises ou d'États, Lionel Maurel plaide pour l'ouverture des résultats des recherches scientifiques, mais aussi (avec nuances) pour l'ouverture des données de recherche, Philippe Bihouix explique concrètement comment réduire l'empreinte environnementale, Jessica Eynard questionne l'identité numérique (même si je la trouve bien trop optimiste sur le projet d'identité numérique étatique au niveau de l'UE), Amine Smihi décrit la vidéosurveillance vue de son rôle d'élu local, etc.

Bref, un tour d'horizon de beaucoup de questions que pose la place du numérique dans notre société.