Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève


Fiche de lecture : Cyberattaque

Auteur(s) du livre : Angeline Vagabulle
Éditeur : Les funambulles
978-2-9555452-7-0
Publié en 2018
Première rédaction de cet article le 8 août 2019


Des livres parlant de « cyberattaques » ou de « cybersécurité », il y en a plein. C'est un thème à la mode et les historiens du futur, lorsqu'ils étudieront la littérature du passé, noteront sans doute que les années 2010 étaient marquées par l'importance de ce thème. Mais ce livre a un angle original : ni un roman, ni un « reportage » sensationnaliste, ni une pseudo-réflexion sur la « cyberguerre », c'est un récit vu de l'intérieur d'une grosse perturbation, le passage de NotPetya dans l'entreprise où travaille l'auteure. Derrière le passionnant récit « sur le terrain », c'est peut-être l'occasion de se poser quelques questions sur l'informatique et la sécurité.

J'avoue ne pas savoir dans quelle mesure ce récit est authentique. L'auteure raconte à la première personne ce qu'a vécu l'entreprise où elle travaillait. Angeline Vagabulle est un pseudonyme, soit parce que l'entreprise ne souhaitait pas que ses cafouillages internes soient associés à son nom, soit parce que l'auteure a fait preuve d'imagination et romancé la réalité. Mais le récit est très réaliste et, même si cette entreprise particulière n'existe pas, les évènements relatés dans ce livre ont tous bien eu lieu dans au moins une grande entreprise dans le monde.

Ceux et celles qui ont vécu un gros problème informatique dans une grande entreprise multinationale les reconnaitront : le DSI qui se vante dans des messages verbeux et mal écrits que l'entreprise est bien protégée et que cela ne pourrait pas arriver, les conseils absurdes (« ne cliquez pas sur un lien avant d'être certain de son authenticité »), l'absence de communication interne une fois que le problème commence (ou bien son caractère contradictoire « éteignez tout de suite vos ordinateurs » suivi de « surtout n'éteignez pas vos ordinateurs »), la langue de bois corporate (« nous travaillons très dur pour rétablir la situation »), la découverte de dépendances que personne n'avait sérieusement étudié avant (« ah, sans les serveurs informatiques, on ne peut plus téléphoner ? »), l'absence de moyens de communications alternatifs. Il faut dire que l'entreprise décrite ici a fait fort : non seulement les postes de travail sur le bureau mais tous les serveurs étaient sous Windows, évidemment pas tenus à jour, et donc vulnérables à la faille EternalBlue. Au passage de NotPetya, tous les fichiers sont détruits et plus rien ne marche, on ne peut plus envoyer de propositions commerciales aux clients, on ne peut plus organiser une réunion, on ne peut même plus regarder le site Web public de la boîte (qui, lui, a tenu, peut-être était-il sur Unix ?) Et cela pendant plusieurs semaines.

Le ton un peu trop « léger », et le fait que l'héroïne du livre surjoue la naïve qui ne comprend rien peuvent agacer mais ce livre n'est pas censé être un guide technique du logiciel malveillant, c'est un récit par une témoin qui ne comprend pas ce qui se passe, mais qui décrit de manière très vivante la crise. (En italique, des encarts donnent des informations plus concrètes sur la cybersécurité. Mais celles-ci sont parfois non vérifiés, comme les chiffres de cyberattaques, a fortiori comme leur évaluation financière.)

(Le titre est clairement sensationnaliste : il n'y a pas eu d'attaque, cyber ou pas, NotPetya se propageait automatiquement et ne visait pas spécialement cette entreprise.)

En revanche, j'ai particulièrement apprécié les solutions que mettent en place les employés, pour faire face à la défaillance de l'informatique officielle. Comme les ordiphones ont survécu, WhatsApp est largement adopté, et devient l'outil de communication de fait. (Ne me citez pas les inconvénients de WhatsApp, je les connais, et je connais l'entreprise qui est derrière. Mais, ici, il faut se rappeler que les différents sites de la boîte n'avaient plus aucune communication.) Il reste à reconstituer les carnets d'adresses, ce qui occupe du monde (« C'est John, du bureau de Dublin, qui demande si quelqu'un a le numéro de Kate, à Bruxelles, c'est pour pouvoir contacter Peter à Dubaï. ») Beaucoup de débrouillardise est déployée, pour pallier les conséquences du problème. Une nouvelle victoire du shadow IT, et la partie la plus passionnante du livre.

Ce livre peut aussi être lu comme une critique de l'entreprise. Avant même le problème informatique, l'auteure note que sa journée se passait en réunion « sans même le temps d'aller aux toilettes ». On peut se demander s'il est normal qu'une journée de travail se passe exclusivement en réunions et en fabrication de reportings, sans rien produire. Il est symptomatique, d'ailleurs, qu'on ne sait pas exactement quel travail fait l'héroïne dans son entreprise, ni dans quel service elle travaille, ni d'ailleurs ce que fait l'entreprise.

L'auteure s'aventure à supposer que le problème est partiellement de la faute des informaticiens. « Ils feraient mieux de se concentrer sur leur boulot, en l'occurrence le développement d'applications et de systèmes sans failles. » C'est non seulement très yakafokon (développer un système sans faille est vraiment difficile) mais surtout bien à côté de la plaque. On sait, sinon faire des applications sans faille, du moins faire des applications avec moins de failles. On sait sécuriser les systèmes informatiques, pas parfaitement, bien sûr, mais en tout cas bien mieux que ce qu'avait fait l'entreprise en question. On le sait. Il n'y a pas de problème d'ignorance. En revanche, savoir n'est pas tout. Encore faut-il appliquer et c'est là que le bât blesse. Les solutions connues ne sont pas appliquées, à la fois pour de bonnes et de mauvaises raisons. Elles coûtent trop cher, elles ne plaisent pas aux utilisateurs (« le système que tu nous dis d'utiliser, j'ai essayé, il est peut-être plus sécurisé, mais qu'est-ce qu'il est moche ») et/ou aux décideurs (« ce n'est pas enterprise-grade » ou bien « on n'a pas le temps, il faut d'abord finir le reporting du trimestre précédent »). D'ailleurs, après une panne d'une telle ampleur, est-ce que l'entreprise en question a changé ses pratiques ? Gageons qu'elle aura continué comme avant. Par exemple, au moment du passage de NotPetya, l'informatique était sous-traitée au Portugal et en Inde. Aucun informaticien compétent dans les bureaux. Est-ce que ça a changé ? Probablement pas. L'expérience ne sert à rien, surtout en matière de cybersécurité.

Déclaration de potentiel conflit d'intérêt : j'ai reçu un exemplaire gratuitement.


La fiche

Fiche de lecture : Programming Elixir

Auteur(s) du livre : Dave Thomas
Éditeur : The Pragmatic Programmers
978-1-68050-299-2
Publié en 2018
Première rédaction de cet article le 6 août 2019


Ce livre présente le langage de programmation Elixir, un langage, pour citer la couverture, « fonctionnel, parallèle, pragmatique et amusant ».

Elixir est surtout connu dans le monde des programmeurs Erlang, car il réutilise la machine virtuelle d'Erlang pour son exécution, et reprend certains concepts d'Erlang, notamment le parallélisme massif. Mais sa syntaxe est très différente et il s'agit bien d'un nouveau langage. Les principaux logiciels libres qui l'utilisent sont Pleroma (c'est via un travail sur ActivityPub que j'étais venu à Pleroma et donc à Elixir) et CertStream.

Comme tous les livres de cet éditeur, l'ouvrage est très concret, avec beaucoup d'exemples. Si vous voulez vous lancer, voici un exemple, avec l'interpréteur iex :

% iex
Erlang/OTP 22 [erts-10.4.4] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1] [hipe]

Interactive Elixir (1.8.2) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> "Hello"
"Hello"
iex(2)> 2 + 2
4
    

Mais on peut aussi bien sûr mettre du Elixir dans un fichier et l'exécuter :

% cat > test.exs 
IO.puts 2+2

% elixir test.exs
4
    

Elixir a évidemment un mode Emacs, elixir-mode (site de référence sur Github). On peut l'utiliser seul, ou bien intégré dans l'environnement général alchemist. J'ai utilisé MELPA pour installer elixir-mode. Une fois que c'est fait, on peut se lancer dans les exercices du livre.

Quelles sont les caractéristiques essentielles d'Elixir ? Comme indiqué sur la couverture du livre, Elixir est fonctionnel, parallèle, pragmatique et amusant. Voici quelques exemples, tirés du livre ou inspirés par lui, montrés pour la plupart en utilisant l'interpréteur iex (mais Elixir permet aussi de tout mettre dans un fichier et de compiler, chapitre 1 du livre).

Contrairement à un langage impératif classique, les variables ne sont pas modifiées (mais on peut lier une variable à une nouvelle valeur, donc l'effet est proche de celui d'un langage impératif) :

iex(1)> toto = 42
42
iex(2)> toto
42
iex(3)> toto = 1337
1337
iex(4)> ^toto = 1
** (MatchError) no match of right hand side value: 1
    (stdlib) erl_eval.erl:453: :erl_eval.expr/5
    (iex) lib/iex/evaluator.ex:249: IEx.Evaluator.handle_eval/5
    (iex) lib/iex/evaluator.ex:229: IEx.Evaluator.do_eval/3
    (iex) lib/iex/evaluator.ex:207: IEx.Evaluator.eval/3
    (iex) lib/iex/evaluator.ex:94: IEx.Evaluator.loop/1
    (iex) lib/iex/evaluator.ex:24: IEx.Evaluator.init/4
iex(4)> ^toto = 1337
1337
    

Dans les deux derniers tests, le caret avant le nom de la variable indique qu'on ne veut pas que la variable soit redéfinie (chapitre 2 du livre).

Elixir compte sur le pattern matching (chapitre 2 du livre) et sur les fonctions beaucoup plus que sur des structures de contrôle comme le test ou la boucle. Voici la fonction qui calcule la somme des n premiers nombres entiers. Elle fonctionne par récurrence et, dans un langage classique, on l'aurait programmée avec un test « si N vaut zéro, c'est zéro, sinon c'est N plus la somme des N-1 premiers entiers ». Ici, on utilise le pattern matching :

iex(1)> defmodule Test do
...(1)> def sum(0), do: 0
...(1)> def sum(n), do:  n + sum(n-1)
...(1)> end
iex(2)> Test.sum(3)
6
    

(On ne peut définir des functions nommées que dans un module, d'où le defmodule.)

Naturellement, comme dans tout langage fonctionnel, on peut passer des fonctions en paramètres (chapitre 5 du livre). Ici, la traditionnelle fonction map (qui est dans le module standard Enum) prend en paramètre une fonction anonyme qui multiplie par deux :

iex(1)> my_array = [1, 2, 8, 11]   
[1, 2, 8, 11]
iex(2)> Enum.map my_array, fn x -> x*2 end
[2, 4, 16, 22]
    

Cela marche aussi si on met la fonction dans une variable :

iex(3)> my_func = fn x -> x*2 end
#Function<7.91303403/1 in :erl_eval.expr/5>
iex(4)> Enum.map my_array, my_func
[2, 4, 16, 22]
    

Notez qu'Elixir a une syntaxe courante mais moins claire pour les programmeurs et programmeuses venu·e·s d'autres langages, si on veut définir une courte fonction :

iex(5)> Enum.map my_array, &(&1*2)
[2, 4, 16, 22]
    

(Et notez aussi qu'on ne met pas forcément de parenthèses autour des appels de fonction.)

Évidemment, Elixir gère les types de données de base (chapitre 4) comme les entiers, les booléens, les chaînes de caractères… Ces chaînes sont en Unicode, ce qui fait que la longueur n'est en général pas le nombre d'octets :

iex(1)>  string = "Café"
"Café"
iex(2)> byte_size(string)
5
iex(3)> String.length(string)
4
    

Il existe également des structures de données, comme le dictionnaire (ici, le dictionnaire a deux élements, nom et ingrédients, le deuxième ayant pour valeur une liste) :

defmodule Creperie do
  def complète do
    %{nom: "Complète", ingrédients: ["Jambon", "Œufs", "Fromage"]}
  end

À propos de types, la particularité la plus exaspérante d'Elixir (apparemment héritée d'Erlang) est le fait que les listes de nombres sont imprimées comme s'il s'agissait de chaînes de caractères, si ces nombres sont des codes ASCII plus ou moins imprimables :

iex(2)> [78, 79, 78]
'NON'

iex(3)> [78, 79, 178]
[78, 79, 178]

iex(4)> [78, 79, 10]
'NO\n'

iex(5)> [78, 79, 7]
'NO\a'

iex(6)> [78, 79, 6] 
[78, 79, 6]
    

Les explications complètes sur cet agaçant problème figurent dans la documentation des charlists. Pour afficher les listes de nombres normalement, plusieurs solutions :

  • Pour l'interpréteur iex, mettre IEx.configure inspect: [charlists: false] dans ~/.iex.exs.
  • Pour la fonction IO.inspect, lui ajouter un second argument, charlists: :as_lists.
  • Un truc courant est d'ajouter un entier nul à la fin de la liste, [78, 79, 78] ++ [0] sera affiché [78, 79, 78, 0] et pas NON.

À part cette particularité pénible, tout cela est classique dans les langages fonctionnels. Ce livre va nous être plus utile pour aborder un concept central d'Elixir, le parallélisme massif (chapitre 15). Elixir, qui hérite en cela d'Erlang, encourage les programmeuses et les programmeurs à programmer en utilisant un grand nombre d'entités s'exécutant en parallèle, les processus (notons tout de suite qu'un processus Elixir, exécuté par la machine virtuelle sous-jacente, ne correspond pas forcément à un processus du système d'exploitation). Commençons par un exemple trivial, avec une machine à café et un client :

defmodule CoffeeMachine do

  def make(sugar) do
    IO.puts("Coffee done, sugar is #{sugar}")
  end

end

CoffeeMachine.make(true)
spawn(CoffeeMachine, :make, [false])
IO.puts("Main program done")
    

Le premier appel au sous-programme CoffeeMachine.make est classique, exécuté dans le processus principal. Le second appel lance par contre un nouveau processus, qui va exécuter CoffeeMachine.make avec la liste d'arguments [false].

Les deux processus (le programme principal et celui qui fait le café) sont ici séparés, aucun message n'est échangé. Dans un vrai programme, on demande en général un minimum de communication et de synchronisation. Ici, le processus parent envoie un message et le processus fils répond (il s'agit de deux messages séparés, il n'y a pas de canal bidirectionnel en Elixir, mais on peut toujours en bâtir, et c'est ce que font certaines bibliothèques) :

defmodule CoffeeMachine do

  def make(sugar) do
    pid = self() # PID pour Process IDentifier
    IO.puts("Coffee done by #{inspect pid}, sugar #{sugar}")
  end

  def order do
    pid = self()
    receive do
      {sender, msg} ->
     	send sender, {:ok, "Order #{msg} received by #{inspect pid}"}
    end
  end
  
end

pid = spawn(CoffeeMachine, :order, [])
IO.puts("Writing to #{inspect pid}")
send pid, {self(), "Milk"}

receive do
  {:ok, message} -> IO.puts("Received \"#{message}\"") 
  {_, message} -> IO.puts("ERROR #{message}")
after 1000 -> # Timeout after one second
  IO.puts("No response received in time")
end
    

On y notera :

  • Que l'identité de l'émetteur n'est pas automatiquement ajoutée, c'est à nous de le faire,
  • L'utilisation du pattern matching pour traiter les différentes types de message (avec clause after pour ne pas attendre éternellement),
  • Que contrairement à d'autres langages à parallélisme, il n'y a pas de canaux explicites, un processus écrit à un autre processus, il ne passe pas par un canal. Là encore, des bibliothèques de plus haut niveau permettent d'avoir de tels canaux. (C'est le cas avec Phoenix, présenté plus loin.)

spawn crée un processus complètement séparé du processus parent. Mais on peut aussi garder un lien avec le processus créé, avec spawn_link, qui lie le sort du parent à celui du fils (si une exception se produit dans le fils, elle tue aussi le parent) ou spawn_monitor, qui transforme les exceptions ou la terminaison du fils en un message envoyé au parent :

defmodule Multiple do
  
  def newp(p) do
    send p, {self(), "I'm here"}
    IO.puts("Child is over")
    # exit(:boom) # exit() would kill the parent
    # raise "Boom" # An exception would also kill it
  end

end

child = spawn_link(Multiple, :newp, [self()])
    

Et avec spawn_monitor :

defmodule Multiple do
  
  def newp(p) do
    pid = self()
    send p, {pid, "I'm here"}
    IO.puts("Child #{inspect pid} is over")
    # exit(:boom) # Parent receives termination message containing :boom
    # raise "Boom" # Parent receives termination message containing a
                   # tuple, and the runtime displays the exception
  end

end

{child, _} = spawn_monitor(Multiple, :newp, [self()]) 
    

Si on trouve les processus d'Elixir et leurs messages de trop bas niveau, on peut aussi utiliser le module Task, ici un exemple où la tâche et le programme principal ne font pas grand'chose à part dormir :

task = Task.async(fn -> Process.sleep Enum.random(0..2000); IO.puts("Task is over") end)  
Process.sleep Enum.random(0..1000)  
IO.puts("Main program is over")      
IO.inspect(Task.await(task))                                                                        
    

Vous pouvez trouver un exemple plus réaliste, utilisant le parallélisme pour lancer plusieurs requêtes réseau en évitant qu'une lente ne bloque une rapide qui suivrait, dans cet article.

Les processus peuvent également être lancés sur une autre machine du réseau, lorsqu'une machine virtuelle Erlang y tourne (chapitre 16 du livre). C'est souvent présenté par les zélateurs d'Erlang ou d'Elixir comme un bon moyen de programmer une application répartie sur l'Internet. Mais il y a deux sérieux bémols :

  • Ça ne marche que si les deux côtés de l'application (sur la machine locale et sur la distante) sont écrits en Elixir ou en Erlang,
  • Et, surtout, surtout, la sécurité est très limitée. La seule protection est une série d'octets qui doit être la même sur les deux machines. Comme elle est parfois fabriquée par l'utilisateur (on trouve sur le Web des exemples de programmes Erlang où cette série d'octets est une chaîne de caractères facile à deviner), elle n'est pas une protection bien solide, d'autant plus que la machine virtuelle la transmet en clair sur le réseau. (Chiffrer la communication semble difficile.)

Bref, cette technique de création de programmes répartis est à réserver aux cas où toutes les machines virtuelles tournent dans un environnement très fermé, complètement isolé de l'Internet public. Autrement, si on veut faire de la programmation répartie, il ne faut pas compter sur ce mécanisme.

Passons maintenant à des exemples où on utilise justement le réseau. D'abord, un serveur echo (je me suis inspiré de cet article). Echo est normalisé dans le RFC 862. Comme le programme est un peu plus compliqué que les Hello, world faits jusqu'à présent, on va commencer à utiliser l'outil de compilation d'Elixir, mix (chapitre 13 du livre, il existe un court tutoriel en français sur Mix).

Le plus simple, pour créer un projet qui sera géré avec mix, est :

%  mix new echo
    

Le nouveau projet est créé, on peut l'ajouter à son VCS favori, puis aller dans le répertoire du projet et le tester :

    
%  cd echo
%  mix test

Les tests ne sont pas très intéressants pour l'instant, puisqu'il n'y en a qu'un seul, ajouté automatiquement par Mix. Mais ça prouve que notre environnement de développement marche. Maintenant, on va écrire du vrai code, dans lib/echo.ex (vous pouvez voir le résultat complet).

Les points à noter :

  • Le livre de Dave Thomas ne parle pas du tout de programmation réseau, ou des prises réseau,
  • J'ai utilisé une bibliothèque Erlang.gen_tcp, puisqu'on peut appeler les bibliothèques Erlang depuis Elixir (rappelez-vous que les deux langages utilisent la même machine virtuelle, Beam.) Les bibliothèques Erlang importées dans Elixir ont leur nom précédé d'un deux-points donc, ici, :gen_tcp.
  • Une fois un client accepté avec :gen_tcp.accept, la fonction loop_acceptor lance un processus séparé puis s'appelle elle-même. Comme souvent dans les langages fonctionnels, on utilise la récursion là où, dans beaucoup de langages, on aurait utilisé une boucle. Cette appel récursif ne risque pas de faire déborder la pile, puisque c'est un appel terminal.
  • La fonction serve utilise l'opérateur |>, qui sert à emboiter deux fonctions, le résultat de l'une devenant l'argument de l'autre (comme le tube pour le shell Unix.) Et elle s'appelle elle-même, comme loop_acceptor, pour traiter tous les messages envoyés.
  • La fonction write_line est définie en utilisant le pattern matching (deux définitions possibles, une pour le cas normal, et une pour le cas où la connexion TCP est fermée.)
  • Le code peut sembler peu robuste, plusieurs cas ne sont pas traités (par exemple, que se passe-t-il si :gen_tcp.recv, et donc read_line, renvoie {:error, :reset} ? Aucune définition de write_line ne prévoit ce cas.) Mais cette négligence provient en partie du d'un style de développement courant en Elixir : on ne cherche pas à faire des serveurs qui résistent à tout, ce qui complique le code (la majorité du programme servant à gérer des cas rares). On préfère faire tourner le programme sous le contrôle d'un superviseur (et l'environnement OTP fournit tout ce qu'il faut pour cela, cf. chapitres 18 et 20 dans le livre), qui redémarrera le programme le cas échéant. Au premier atelier Elixir que j'avais suivi, au BreizhCamp, le formateur, Nicolas Savois, m'avait dit que mon code était trop robuste et que je vérifiait trop de choses. Avec Elixir, c'est Let it crash, et le superviseur se chargera du reste. (Dans mon serveur echo, je n'ai pas utilisé de superviseur, mais j'aurais dû.)

Et pour lancer le serveur ? Un programme start-server.exs contient simplement :

import Echo

Echo.accept(7)
    

(7 étant le port standard d'echo) Et on le démarre ainsi :

% sudo mix run start-server.exs
18:54:47.410 [info]  Accepting connections on port 7
...
18:55:10.807 [info]  Serving #Port<0.6>
    

La ligne « Serving #Port » est affichée lorsqu'un client apparait. Ici, on peut tester avec telnet :

% telnet thule echo
Trying 10.168.234.1...
Connected to thule.
Escape character is '^]'.
toto
toto
^]
telnet> quit
Connection closed.
    

Ou bien avec un client echo spécialisé, comme echoping :

% echoping  -v thule
...
Trying to send 256 bytes to internet address 10.168.234.1...
Connected...
TCP Latency: 0.000101 seconds
Sent (256 bytes)...
Application Latency: 0.000281 seconds
256 bytes read from server.
Estimated TCP RTT: 0.0001 seconds (std. deviation 0.000)
Checked
Elapsed time: 0.000516 seconds
   

Et si on veut faire un serveur HTTP, parce que c'est quand même plus utile ? On peut utiliser le même gen_tcp comme dans l'exemple qui figure au début de cet article. Si vous voulez tester, le code est en http-serve.exs, et ça se lance avec :

% elixir server.exs
15:56:29.721 [info]  Accepting connections on port 8080
...
    

On peut alors l'utiliser avec un client comme curl, ou bien un navigateur visitant http://localhost:8080/. Mais ce serveur réalisé en faisant presque tout soi-même est très limité (il ne lit pas le chemin de l'URL, il ne traite qu'une requête à la fois, etc) et, en pratique, la plupart des programmeurs vont s'appuyer sur des cadriciels existants comme Phoenix ou Plug. Par défaut, tous les deux utilisent le serveur HTTP Cowboy, écrit en Erlang (cf. le site Web de l'entreprise qui développe Cowboy, et la documentation.) Pour avoir des exemples concrets, regardez cet article ou bien, avec Plug, celui-ci.

Mix permet également de gérer les dépendances d'une application (les bibliothèques dont on a besoin), via Hex, le système de gestion de paquetages commun à Erlang et Elixir (chapitre 13 du livre). Voyons cela avec une bibliothèque DNS, Elixir DNS. On crée le projet :

 % mix new test_dns
* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/test_dns.ex
* creating test
* creating test/test_helper.exs
* creating test/test_dns_test.exs
...

% mix test
Compiling 1 file (.ex)
Generated test_dns app
..

Finished in 0.04 seconds
1 doctest, 1 test, 0 failures
  

On modifie le fichier mix.exs, créé par Mix, pour y ajouter la bibliothèque qu'on veut, avec son numéro de version minimal :

# Run "mix help deps" to learn about dependencies.
defp deps do
    [
      {:dns, "~> 2.1.2"},
    ]
end
  

Et on peut alors installer les dépendances. (Pour utiliser Hex, sur Debian, il faut installer le paquetage erlang-inets, sinon on obtient (UndefinedFunctionError) function :inets.stop/2 is undefined (module :inets is not available).)

% mix deps.get                       
Could not find Hex, which is needed to build dependency :dns
Shall I install Hex? (if running non-interactively, use "mix local.hex --force") [Yn] y
* creating /home/stephane/.mix/archives/hex-0.20.1
  

Le message Could not find Hex [...] Shall I install Hex n'apparaitra que la première fois. Après :

% mix deps.get
Resolving Hex dependencies...
Dependency resolution completed:
New:
  dns 2.1.2
  socket 0.3.13
* Getting dns (Hex package)
* Getting socket (Hex package)
  

Notez qu'Hex a également installé la dépendance de la dépendance (dns dépend de socket.) On peut maintenant exécuter nos programmes :

% cat example.exs
IO.inspect(DNS.resolve("github.com", :a))
    
% mix run ./example.exs
{:ok, [{140, 82, 118, 4}]}
  

En conclusion, je trouve le livre utile. Il est en effet très pratique, très orienté vers les programmeuses et programmeurs qui veulent avoir du code qui tourne dès les premiers chapitres. Concernant le langage, je réserve mon opinion tant que je n'ai pas écrit de vrais programmes avec.

Qui, d'ailleurs, écrit des vrais programmes avec Elixir ? Parmi les logiciels connus :

Si vous cherchez des ressources supplémentaires sur Elixir, voici quelques idées :


La fiche

Fiche de lecture : Qu'est-ce qu'une archive du Web ?

Auteur(s) du livre : Francesca Musiani, Camille Paloque-Bergès, Valérie Schafer, Benjamin Thierry
Éditeur : OpenEdition Press
979-10-365-0368-9
Publié en 2019
Première rédaction de cet article le 10 juin 2019


Ce très court livre décrit ce qu'est une archive du Web, et les diverses questions que soulève le problème « faut-il conserver tout ce qui a été un jour publié sur le Web et, si oui, comment, notamment compte-tenu de la taille de ces données et de leur rapidité de changement ? ».

Le Web a un peu plus de trente ans et déjà d'innombrables pages Web ont changé voire disparu. Bien des gens seraient intéressés à voir l'état passé du Web : historiens (cf. le précédent livre d'une des auteures, « En construction »), journalistes (qui voudraient par exemple vérifier le texte qu'un politicien a changé après son élection), simples curieux… Mais cela soulève des difficultés techniques et politiques.

Ces difficultés ne sont pas insurmontables : Internet Archive existe et est très utilisé. Ainsi, l'URL http://web.archive.org/web/19970606063341/http://www.nic.fr/ vous permettra de voir à quoi ressemblait le site Web de la future AFNIC en juin 1997 (notez comme l'URL est explicite). Et la BNF fait une récolte de tout le Web français (je sais, ce terme n'est pas facile à définir). Ces deux organisations (et plusieurs autres) gèrent un bot qui va ramasser automatiquement les pages, qui seront ensuite stockées. (C'est le même logiciel pour ces deux services, Heritrix.) Donc, l'archivage du Web existe mais ce n'est pas facile.

D'abord, voyons les difficultés techniques : le Web est gros et grossit en permanence. Il n'existe aucune estimation sérieuse du nombre de pages Web (d'autant plus qu'il n'y a pas de définition claire de ce qu'est une page) mais il ne fait pas de doute que c'est beaucoup. Vouloir stocker tous les états passés de toutes ces pages ne se fait pas avec trois disques durs dans son garage. Mais la principale difficulté technique réside dans la rapidité du changement de ces pages. Certaines pages changent en permanence (la page d'accueil d'un site d'informations, par exemple). Faut-il donc passer toutes les minutes voir cette page ?

Et, ensuite, comment s'assurer que les pages sauvegardées seront encore visibles dans vingt, trente, quarante ans ? Même si on a les données, un site Web en Flash sauvegardé en 2000 sera-t-il encore lisible en 2040 ? Faut-il sauvegarder les données (qu'on ne saura peut-être plus interpréter), ou bien juste une image de la page, rendue par les logiciels existants ?

Un autre problème est celui de la cohérence des pages. Une page Web est constituée de plusieurs élements, par exemple une ressource en HTML, deux en CSS, trois images, et un programme en JavaScript. Toutes ces ressources n'ont pas été récoltées au même moment et peuvent être incohérentes. Les aut·rice·eur·s citent ainsi le cas du site Web du CNRS dont la version « BNF » d'août 2015 montre un bandeau noir lié aux attentats djihadistes de novembre.

Ces difficultés techniques font que l'archivage du Web n'est pas du ressort du bricoleur dans son coin. Il faut de grosses organisations, bien financées, et assurées d'une certaine pérénnité (comme les bibliothèques nationales). Les questions techniques liées à la récolte sont peu mentionnées dans ce livre. Car il y a bien d'autres difficultés, notamment politiques.

D'abord, qui a le droit de récolter ainsi toutes ces pages ? On pourrait se dire qu'elles sont publiques, et qu'il n'y a donc pas de problème. Mais les lois sur la protection des données ne sont pas de cet avis : ce n'est pas parce que quelque chose est public qu'on a le droit de le récolter et de le traiter. Internet Archive considère qu'il est admissible de récolter ces pages publiques, en respectant simplement le robots.txt. La BNF s'appuie sur une obligation légale (le dépôt légal est créé par une loi) et ne suit donc pas ce robots.txt.

La question peut être sensible dans certains cas. Le livre cite l'exemple des sites Web en .ao, récoltés par une organisation portugaise. Bien sûr, ces sites étaient publiquement disponibles et tout le monde pouvait les récolter, mais cela peut être vu ici comme une manifestation de néo-colonialisme tout en sachant que, sans cette récolte de l'ancien colonisateur, rien ne serait récolté.

Ensuite, que peut-on publier de ce qui a été récolté ? Cela soulève des questions liées au droit d'auteur. Pour éviter de froisser les ayant-tous-les-droits, la BNF ne rend pas publique les pages archivées. Internet Archive, par contre, le fait. (Mais l'Internet Archive a déjà retiré des contenus, par exemple sur ordre de la toute-puissante Scientologie.) Le livre détaille pays par pays les solutions adoptées.

Outre les questions légales liées au droit d'auteur, il peut y avoir des questions éthiques. Par exemple, que penseraient les gens qui avaient contribué à GeoCities si leurs pages de l'époque (publiques, rappelons-le) étaient décortiquées aujourd'hui, alors qu'ils ne s'attendaient pas certainement à ce qu'elles fassent un jour l'objet de tant d'attention.

Et il y a de très nombreuses autres questions à étudier lorsqu'on archive le Web. Bref, un excellent livre, trop court pour tous les sujets à couvrir, mais qui vous fera réfléchir sur une question très riche, ayant plein de conséquences.


La fiche

Fiche de lecture : Manuel d'auto-défense contre le harcèlement en ligne (« Dompter les trolls »)

Auteur(s) du livre : Stéphanie de Vanssay
Éditeur : Dunod
978-2100-787944
Publié en 2019
Première rédaction de cet article le 17 février 2019
Dernière mise à jour le 11 mars 2019


La question du harcèlement en ligne est maintenant bien connue et, à juste titre, souvent mise sur le devant de la scène, mais cela ne veut pas dire que ceux et celles qui en parlent en parlent intelligemment. C'est donc une excellente chose que Stéphanie de Vanssay, qui connait très bien le monde du numérique, s'attaque à cette question, dans un très bon livre.

L'auteure sait hélas de quoi elle parle : comme la grande majorité des femmes qui s'expriment publiquement, avec des opinions affirmées, elle a été victime de plusieurs campagnes de harcèlement. (Un exemple est décrit ici.) Je dis bien de harcèlement, pas juste de critiques (qui seraient parfaitement légitimes) de son engagement ou de ses idées politiques, mais des insultes sur son physique, des menaces de viol ou de torture, etc. La publication de son livre ne va évidemment pas faire changer les harceleurs, qui critiquent déjà sur les réseaux sociaux sa « position victimaire » (les victimes qui dénoncent les agressions cherchent toutes à augmenter leur nombre de followers Twitter, c'est bien connu). On notera au passage que le livre sort en même temps que l'affaire de la ligue du LOL qui illustre très bien le fait que le harcèlement n'est pas uniquement le fait de déséquilibrés isolés, mais qu'il est commis en bandes organisées, ayant des objectifs précis (souvent de faire taire les femmes).

Ayant été témoin des déchainements contre Stéphanie de Vanssay, j'ai noté que le point de départ était souvent une question pédagogique. Car l'auteur est enseignante et parle souvent de questions d'éducation. Apparemment, cela ne plait pas à une horde vindicative qui dénonce les « pédagogistes » (et, à leurs yeux, est « pédagogiste » quiconque estime que l'enseignant n'a pas toujours raison et que les méthodes d'enseignement n'ont pas forcément à rester ce qu'elles étaient dans un lycée militaire au 19e siècle). Bref, cette horde est composée en partie d'enseignants et, en tant qu'ex-parent d'élève, je ne peux pas m'empêcher de trouver inquiétant le fait que certaines personnes chargées de l'éducation des enfants soient aussi agressifs en ligne (et, je le souhaite, seulement en ligne). En tout cas, il est sûr que le harcèlement en ligne n'est pas seulement pratiqué par des islamistes et des bas-du-front votant Trump, des bac+quelquechose le font aussi, hélas.

Je l'ai dit au début, la question du harcèlement en ligne est, heureusement, aujourd'hui reconnue comme une question politique importante. Mais cela ne veut pas dire que toutes les réponses suggérées soient bonnes. Ainsi, comme c'est souvent le cas pour les questions de sécurité, le harcèlement en ligne est souvent utilisé comme prétexte pour rogner les libertés. C'est par exemple le cas en France en ce moment avec le projet présidentiel d'interdire l'anonymat en ligne. Ce projet ne tient pas compte du fait qu'il existe déjà des tas de possibilités légales de lutter contre la « haine en ligne » mais qu'ils ne sont pas utilisés par manque de moyens matériels et manque de réelle volonté. On voit aussi des politiciens sans scrupules qui soutiennent la lutte anti-anonymat en s'appuyant sur les actions de la ligue du LOL… alors que les membres de la dite ligue agissaient souvent sous leur nom officiel. Sans compter les gens qui ne comprennent rien au monde de l'Internet et se contentent d'affirmations sommaires comme « il faudrait que Facebook demande une carte d'identité » (comme si Facebook n'avait pas déjà trop de données personnelles).

Mais assez parlé du contexte, parlons du livre de Stéphanie de Vanssay, plutôt. Elle connait très bien le sujet et ne propose donc pas de ces pseudo-solutions répressives et à l'emporte-pièce. D'abord, l'auteure est modeste : il s'agit d'aider les victimes de harcèlement à se défendre, sans prétendre régler tous les cas de harcèlement, notamment les plus graves (comme, par exemple, celui dont avait été victime la journaliste Nadia Daam). Dans ce cas, l'auteure note à juste titre qu'il faut envisager des recours, par exemple à la justice, et elle donne quelques indications pratiques à ce sujet. Mais même le harcèlement moins radical est dur pour les victimes, et peut mener la victime à ne plus s'exprimer publiquement (ce qui est souvent le but des harceleurs). L'auteure rejette l'idée (qui est aussi celle des trolls, et un des leurs arguments de défense favoris) « en ligne, c'est pas grave ».

L'essentiel du livre parle de ce que les victimes peuvent faire elles-mêmes et eux-mêmes. La force du troll ou du harceleur est que la victime se croit impuissante. Stéphanie de Vanssay montre que ce n'est pas complètement le cas, et qu'il existe diverses stratégies pour lutter contre les trolls.

La plus évidente est le fameux « ne nourrissez pas les trolls » (ne leur répondez pas, ignorez-les en espérant que le problème disparaitra de lui-même), conseil souvent donné mais avec lequel l'auteure n'est pas trop d'accord. D'abord, si le troll dit des choses vraiment inacceptables (des propos racistes, par exemple), cela ne doit pas être ignoré mais combattu. Et, dans certains cas, le troll peut être neutralisé par l'humour et la solidarité (des autres participants : l'auteure insiste que la victime doit être consciente qu'elle n'est pas seule). Mais dans certains cas, cette tactique d'ignorer le harceleur peut être préférable. Voir par exemple dans le livre le témoignage de Florence Porcel (le « petit groupe de potes » dont elle parle est la ligue du LOL, pas encore connue publiquement à l'époque de la rédaction du livre). Globalement, l'auteure est prudente : il n'y a pas de méthode magique anti-troll, pas de solution universelle au harcèlement.

Stéphanie de Vanssay tord le cou à pas mal d'idées reçues. Contrairement au discours médiatique dominant, elle fait remarquer que le harcèlement n'est pas apparu avec Facebook (elle cite Usenet, qui avait déjà permis d'observer pas mal de comportements scandaleux). Elle critique également une autre tarte à la crème du discours anti-numérique, la « bulle de filtres » qui ferait qu'en ligne, on ne serait exposé qu'à ce à quoi on croit déjà. L'auteur note au contraire qu'autrefois, quelqu'un qui ne partageait pas les opinions politiques du Figaro ne lisait jamais ce journal alors que, sur l'Internet, en un clic, on peut accéder à un de leurs articles, et on le fait bien plus souvent qu'hors-ligne.

Stéphanie de Vanssay explique aussi que pour protéger les enfants des dangers qui les menacent en ligne, les solutions simplistes souvent assénées ne sont pas idéales. Ne pas leur permettre un accès à l'Internet, solution souvent citée, revient à les boucler à la maison pour les protéger des dangers de la rue. Et cela les rendra encore plus vulnérables quand ils finiront par y accéder.

Peu de mentions des GAFA dans ce livre, à part pour noter que le signalement des trolls aux GAFA a peu d'effets, voire des effets négatifs (le troll chasse en bande, et eux aussi peuvent signaler, ce qui fait que la bureaucratie va fermer le compte de la victime plutôt que celui du harceleur).

Je vous laisse lire le livre pour voir les stratégies de défense que conseille l'auteur, toujours avec nuance et en sachant bien qu'aucune n'est parfaite. Personnellement, je ne suis pas tellement d'accord avec l'approche (revendiquée) « développement personnel », comme si la lutte contre les harceleurs consistait essentiellement à s'améliorer soi-même mais la question est délicate de toute façon : il faut à la fois aider les victimes à se défendre, sans pour autant les culpabiliser si elles n'y arrivent pas. Globalement, je trouve que ce livre se tire bien de cet exercice très difficile, et je souhaite qu'il serve à de nombreuses victimes à être plus fortes.

Et l'habituel instant « déclaration de conflit d'intérêt » : j'ai reçu un exemplaire de ce livre gratuitement, en tant que blogueur.


La fiche

Fiche de lecture : Habemus Piratam

Auteur(s) du livre : Pierre Raufast
Éditeur : Alma
978-2-36279-283-0
Publié en 2018
Première rédaction de cet article le 8 février 2019


Voici un roman policier que je recommande, dans le monde de la cybersécurité, « Habemus Piratam ».

C'est très bien écrit, drôle (enfin, pour le lecteur, pas pour les victimes), l'histoire est curieuse, pleine de rebondissements, et on est surpris jusqu'au bout.

Les livres à destination du grand public et parlant de sécurité informatique sont souvent remplis d'absurdités techniques. Ce n'est pas forcément grave lorsqu'il s'agit de romans, qui ne prétendent pas être une documentation correcte. L'auteur a heureusement le droit de ne pas laisser les faits se mettre sur le chemin de son imagination. Mais, ici, l'auteur s'est bien documenté et presque tout sonne vrai (à part la légende habituelle des tueurs à gage sur le darknet). Les « piratages » sont vraisemblables (sauf un, à mon avis, je vous laisse lire le livre). Il y a plein de clins d'œil (« CERT Baobab ») qui amuseront le lecteur qui connait un peu. La description de la conférence Botconf m'a beaucoup fait rire. Mais le polar est très agréable à lire même pour les personnes non expertes en sécurité informatique.

Il n'y a pas que la technique qui est réaliste, l'environnement humain l'est également ; « J'ai l'habitude de ces audits [de sécurité]. En général, la direction à qui je présente les résultats est horrifiée. Elle exige un plan de correction immédiat, fait tomber quelques têtes et ça s'arrête là. Quelques jours plus tard, les vicissitudes de la marche courante reprennent le dessus, le devis nécessaire à la correction des failles est annoncé. Au vu du montant astronomique, les travaux de colmatage sont repoussés au budget de l'année suivante. »


La fiche

Fiche de lecture : Sur les pas de Lucy

Auteur(s) du livre : Raymonde Bonnefille
Éditeur : Odile Jacob
978-2-7381-4164-4
Publié en 2018
Première rédaction de cet article le 8 février 2019


Depuis la découverte de Lucy en 1974, tous les protagonistes, quelle que soit l'importance de leur participation réelle, ont écrit sur les expéditions qui ont mené à cette découverte. Ici, Raymonde Bonnefille nous fait revivre ce qu'était le travail de terrain en Éthiopie, dans les années 1960 et 1970. Un récit très vivant, centré surtout sur les conditions pratiques de ce travail.

L'auteure était l'une des rares femmes présentes dans ces expéditions. Comme elle le note, ce n'est pas toujours facile d'être dans cette situation quand on est au milieu de dizaines de jeunes mâles bien testostéronés. D'autant que c'est à elle et à elle seule que le chef de l'expédition reproche d'affoler les chercheurs masculins, ou les soldats éthiopiens qui escortent l'expédition.

Les multiples expéditions auxquelles elle a participé se sont tenues dans deux régions, dans la vallée de l'Omo et dans les environs d'Hadar, où a été retrouvée Lucy. La situation géopolitique était bien différente de celle d'aujourd'hui, on était en pleine guerre froide, dans une Éthiopie fidèle alliée des États-Unis et toujours dirigée par un empereur. Plusieurs expéditions occidentales exploraient la région, connue pour sa richesse en fossiles depuis les années 1930. (Le livre contient des témoignages émouvants sur Camille Arenbourg, revenu à 83 ans sur le terrain qu'il avait exploré à l'époque.) Certaines de ces expéditions étaient françaises, d'autres états-uniennes et l'auteure a participé aux deux, ce qui lui permet de comparer des styles bien différents (les États-uniens ne comprenant pas que les Français s'arrêtent pour le déjeuner, et mettent une nappe sur la table).

Bonnefille est palynologue, un métier peu connu mais sur lequel on n'apprendra pas beaucoup de détails, à part que l'étude des pollens est cruciale pour reconstituer le paysage de l'époque de Lucy, et ses ressources alimentaires. C'est un métier moins spectaculaire que de chasser des fossiles humains (ou des dinosaures !) et l'exercer diminue sérieusement vos chances de devenir une vedette médiatique comme Yves Coppens. Plutôt que d'expliquer en détail la palynologie, l'auteure a donc choisi un angle plutôt « aventure ». Une expédition dans l'Omo ne s'improvise pas, on ne trouve pas de garage ou d'épicerie facilement, et les imprévus sont nombreux. On emporte donc beaucoup de matériel (bien davantage évidemment dans les expéditions états-uniennes) et on doit se débrouiller avec les moyens du bord quand le 4x4 est embourbé, quand on tombe malade, ou simplement quand il faut prendre une douche. (Ce qui n'est pas un luxe scandaleux : il fait très chaud en Éthiopie.)

Je recommande donc ce livre à tous les amateurs et toutes les amateures de voyages, d'expéditions, et d'interactions humaines (pas facile, le travail en équipe !)

À lire aussi, le récit de John Kalb sur les mêmes expéditions.


La fiche

Fiche de lecture : Bitcoin - métamorphoses

Auteur(s) du livre : Jacques Favier, Benoît Huguet, Adli Takkal Bataille
Éditeur : Dunod
9-782-100-784646
Publié en 2018
Première rédaction de cet article le 30 décembre 2018


Le Bitcoin suscite toujours autant de passions, et les informations à son sujet varient toujours de l'enthousiasme délirant aux enterrements prématurés. Il est amusant de noter que les uns comme les autres utilisent souvent les mêmes arguments qu'il y a dix ans, au moment du lancement de la cryptomonnaie. Au contraire, le livre de Favier, Huguet et Bataille se demande « où en est le Bitcoin aujourd'hui ? » Certainement pas au même point qu'en 2008.

J'avais déjà parlé du précédent livre de ces auteurs. Celui-ci est destiné à un public plus informé, qui connait déjà le Bitcoin et souhaite s'informer sur les derniers développements.

Comme dans leur livre antérieur, les auteurs n'hésitent pas à nager à contre-courant du discours dominant. Depuis deux ou trois ans, la mode est à dire « le Bitcoin, c'est pas bien mais la chaîne de blocs, c'est la solution à tous les problèmes de l'humanité ». Pour eux, au contraire, le Bitcoin reste la meilleure solution à bien des problèmes pour lesquels on crée de nouvelles chaînes de blocs, et ils sont très confiants dans sa capacité à évoluer pour répondre aux défis d'aujourd'hui. Les auteurs suggèrent que ce discours bruyant sur la chaîne de blocs sert à évacuer le caractère disrupteur du Bitcoin et à ramener le torrent des cryptomonnaies dans son lit, un lit bien contrôlé et bien régulé.

Les auteurs notent bien que la grande majorité des articles sur le Bitcoin sont très médiocres, juste une compilation de clichés (Law, les tulipes et Ponzi). Parfois, la malhonnêteté intellectuelle va plus loin, comme le reportage de France 2 sur le Bitcoin se terminant par… un envol de pigeons. Comme le notent Favier, Huguet et Bataille, « illustre-t-on un reportage sur une banque centrale par des photos de poulets en batterie ? »

Un autre exemple de la propagande contre les cryptomonnaies concerne les ICO, un mécanisme de financement où une entreprise débutante vend des jetons d'une cryptomonnaie… qui n'existe pas encore. Les ICO sont systématiquement diabolisés dans les médias, qui ne parlent que du risque de perdre son argent, si l'entreprise se casse la figure. Mais, comme le disent les auteurs « pourquoi est-il admis qu'on puisse perdre de l'argent avec la Française des Jeux et pas avec les ICO ? »

À juste titre, les auteurs sont hostiles au concept de « chaîne de blocs privée » (ou « chaîne de blocs à permission ») en notant qu'il s'agit soit de banales bases de données partagées, rebaptisées chaîne de blocs pour des raisons marketing, soit d'erreurs techniques où on utilise une chaîne de blocs pour un problème où elle n'est pas la meilleure solution. En effet, tout l'intérêt de Bitcoin est de fournir de la confiance dans un état alors même que les participants ne se connaissent pas. Si les participants se connaissent et ont déjà une structure en place ou, pire, si le seul participant est une entreprise spécifique, la chaîne de blocs n'a guère d'intérêt.

Et pendant ce temps, Bitcoin ne reste pas inactif : si le logiciel et le protocole n'évoluent qu'avec prudence, la communauté autour du Bitcoin, elle, a beaucoup changé et, au milieu de nombreuses crises, a prouvé sa faculté à s'adapter, dans un environnement impitoyable.

Le gros du livre tourne autour d'un enjeu technique essentiel pour toute chaîne de blocs : le passage à l'échelle. Vu que la taille de blocs de Bitcoin est limitée (notamment pour éviter certaines attaques par déni de service) et que l'écart de temps entre deux blocs est fixe, Bitcoin ne peut pas traiter un nombre illimité de transactions. Une chaîne de blocs qui ne mettrait pas de limite aurait d'autres problèmes, notamment la croissance illimitée de la chaîne, que tous les pairs doivent charger. Bref, on ne peut pas envisager, avec le Bitcoin classique, un monde où chacun paierait son café à la machine avec des bitcoins. Il faut donc améliorer le passage à l'échelle. Ce sujet est bouillonnant en ce moment dans le monde Bitcoin. (Le livre remarque que cela évoque l'époque où les experts auto-proclamés répétaient que l'Internet n'avait pas d'avenir, qu'il s'écroulerait dès qu'on essaierait de s'en servir vraiment, pendant que les vrais experts travaillaient à améliorer l'Internet, afin qu'il puisse assurer le service qu'en attendaient les utilisateurs.)

Les auteurs décrivent donc les solutions comme les « chaînes de côté » (sidechains, comme par exemple Blockstream ou RootStock) où une chaîne ayant moins de limites sert pour les transactions courantes, et son état final est mis de temps en temps sur une chaîne principale, par exemple celle de Bitcoin. Ainsi, la chaîne de côté croît vite mais on n'a pas besoin de la garder éternellement. Autre possibilité, les échanges hors-chaîne mais reportés sur la chaîne comme avec le Lightning Network. Cette partie du livre est plus difficile à lire, reflétant le caractère très mouvant de ces innovations.

Le livre couvre également en détail le cas des scissions, notamment la plus grosse qui a affecté Bitcoin depuis deux ans, et qui est toujours en cours, Bitcoin Cash (sans compter Bitcoin SV.)

Le cas des contrats automatiques est aussi traité, en exprimant un certain scepticisme quant à la possibilité d'en produire sans bogues. Mais, surtout, le livre note que la plupart des problèmes « intéressants » qu'on pourrait traiter avec des contrats automatiques nécessitent de l'information sur le monde extérieur à la chaîne. Si le déroulement d'un contrat automatique d'assurance dépend du temps, par exemple, il faudra bien accéder à des informations météorologiques, et cela ne sera plus pair-à-pair, cela ne pourra pas se faire entièrement sur la chaîne de blocs. (Il faudra utiliser ce qu'Ethereum appelle des oracles, qui ne sont pas pair-à-pair, donc posent un problème de confiance.)

Le monde Bitcoin, sans même parler des autres cryptomonnaies, est très actif en ce moment et des nouvelles propositions émergent tous les jours et d'innombrables essais sont lancés. Ce livre est donc un document utile pour avoir une vision relativement synthétique de l'état actuel de Bitcoin et de ses dernières évolutions. J'ai apprécié le côté ouvert de ce livre, qui présente des changements en cours, sans essayer d'imposer une vision unique.

Note : j'ai reçu (sans engagement) un exemplaire gratuit de ce livre par l'éditeur.


La fiche

Fiche de lecture : Cyberfatale

Auteur(s) du livre : Clément Oubrerie (Dessin), Cépanou (Scénario)
Éditeur : Rue de Sèvres
9-782369-815266
Publié en 2018
Première rédaction de cet article le 29 décembre 2018


Première (?) BD à parler de cybersécurité et de cyberguerre, « Cyberfatale » est une bonne introduction au monde de la lutte « cyber » entre États.

Il est significatif de l'état de la communication et de l'information en matière de « cyber » qu'une BD soit plus sérieuse et mieux informée que la plupart des livres supposés sérieux sur le sujet. Pas de sensationnalisme dans « Cyberfatale », juste une bonne description des attaques (de la plus triviale, un site Web de l'État défiguré, à la plus ennuyeuse, un engin de guerre piraté informatiquement) et des réactions (qui sont, on n'en sera pas surpris, surtout axées sur la communication : « si ça sort, on est morts »). L'un des personnages doit à un moment rédiger un texte officiel sur la cyberdéfense et, après avoir aligné les poncifs dans son texte, se dit « c'est incompréhensible, c'est parfait ».

Il est recommandé de connaitre un peu le sujet, pour comprendre les clins d'œil mais, sinon, l'auteur a pensé aux débutants avec un excellent glossaire, très drôle, et a inventé un personnage d'officière débutante dans le « cyber », excellent prétexte pour donner des explications au lecteur / à la lectrice.

J'ai particulièrement apprécié que le livre fasse une place importante à la question de l'attribution des attaques. Si l'exemple d'analyse d'un logiciel malveillant est ultra-simplifié (mais c'est une BD, pas un livre de rétro-ingénierie), en revanche, la difficulté à être sûr de l'identité de l'attaquant est bien rendue.

Ah, et comme rien n'est parfait, un reproche : le texte utilise à tort le terme « crypter ».


La fiche

Fiche de lecture : En construction

Auteur(s) du livre : Valérie Schafer
Éditeur : INA
9-782869-382534
Publié en 2018
Première rédaction de cet article le 19 décembre 2018


Derrière un titre qui évoque les fameuses mentions « En construction » du début du Web, un ouvrage d'une historienne spécialisée dans l'histoire de l'Internet. Valérie Schafer décrit les débuts de l'Internet et du Web en France, au cours des années 1990.

On y trouve les débats franco-français « Minitel ou Internet », qui agitaient les gens d'en haut de 1994 à 1997 (les gens d'en bas avaient tranché depuis longtemps), les absurdités des intellectuels français face à un phénomène qu'ils ne comprennent pas, l'incompréhension des médias officiels (voir d'ailleurs l'excellente compilation de reportages télévisés faite par l'auteure), l'histoire de Fnet et d'autres acteurs, puis l'explosion de l'intérêt pour l'Internet, passant par les phases successives (on ignore, puis on ricane, puis on en fait des éloges démesurés), les problèmes concrets (kits de connexion, documentations incompréhensibles, compensées par le fait que les utilisateurs étaient des passionné·e·s, décidé·e·s à réussir), les débuts des sites Web (au HTML fait à la main), les relations avec les nouveaux utilisateurs qui arrivent en masse (le septembre sans fin), les premières censures, et les combats pour la liberté, par exemple le rôle de l'AUI, etc.

À propos de documentation, celle de l'accès au CNAM par modem, citée p. 55 et suivantes, est en ligne, en trois fichiers : acces-cnam-modems-1.pdf, acces-cnam-modems-2.pdf et acces-cnam-modems-3.pdf.

Question absurdités, le rapport Théry est évidemment mentionné, mais je pense que la prime revient à Philippe Val qui écrivait dans Charlie Hebdo en 2001 (p. 26 du livre) : « Qui est prêt à dépenser de l'argent à fonds perdus pour avoir son petit site personnel ? Des tarés, des maniaques, des fanatiques, des mégalomanes, des paranoïaques, des nazis, des délateurs [...] » Comme vous êtes en train de lire un « petit site personnel », je vous laisse chercher dans quelle(s) catégorie(s) est son auteur…

Les sources sont systématiquement citées, ce qui est normal pour une historienne, mais n'est pas toujours fait dans les livres parlant d'histoire de l'Internet. (Et qui répètent parfois en boucle des légendes, du genre c'est en France qu'on a inventé l'Internet. De telles légendes sont fréquentes dans les « histoires d'Internet », contrairement à ce livre, qui est très rigoureux.) Plus étonnant, des sources informelles sont très utilisées, notamment Usenet. C'est tout à fait justifié, vu le peu de sources formelles sur cette époque, mais c'est rare, Usenet est ignoré de la majorité des ouvrages et articles parlant d'Internet.

Pour ces citations tirées d'Usenet, Schafer n'a pas mis le nom de l'auteur·e de la citation. Le problème est complexe, car il faut arbitrer entre le droit d'auteur (citer l'auteur), la valeur historique du témoignage (qui dépend de qui parle) et le droit à la vie privée. Contrairement à un livre ou à un article dans un journal formel, l'auteur·e d'un message sur Usenet ne pensait pas forcément être retrouvé·e vingt ans après. Si vous voulez approfondir la question, l'auteure du livre recommande « Ethics and the Archived Web Presentation: “The Ethics of Studying GeoCities” » ou « Par-delà la dichotomie public/privé : la mise en visibilité des pratiques numériques et ses enjeux éthiques ».

Le fameux logo « En construction » orne logiquement la couverture du livre : couverture-en-construction-petite.jpg

Notez enfin que le site de l'Armada de la Liberté, mentionné p. 73, a été récemment remis en ligne à partir d'une sauvegarde personnelle dans le cadre d'une page d'histoire du CNAM à l'occasion d'une conférence. J'ai appris dans le livre de Valérie Schafer (p. 80) que le site Web du CNAM n'avait pas été le premier serveur Web en France, contrairement à ce que je répétais tout le temps. Heureusement que les historien·ne·s sont là pour vérifier.

Déclaration d'éventuel conflit d'intérêts : j'ai reçu (sans engagement) un exemplaire gratuit de ce livre par l'auteur.


La fiche

Fiche de lecture : Click here to kill everybody

Auteur(s) du livre : Bruce Schneier
Éditeur : Norton
978-0393-60888-5
Publié en 2018
Première rédaction de cet article le 6 octobre 2018


D'accord, le titre est vraiment putaclic mais il résume bien le livre. Bruce Schneier se pose la question de la sécurité de l'Internet des Objets, faisant notamment remarquer que le conséquences d'une panne ou d'une attaque changent. Contrairement à la sécurité informatique classique, avec l'Internet des Objets, il peut y avoir des conséquences dans le monde physique, y compris des conséquences mortelles.

Schneier est l'auteur de nombreux livres sur la sécurité (pas forcément uniquement la sécurité informatique). Il explique toujours bien et synthétise avec talent les questions de sécurité. C'est d'autant plus méritoire que la sécurité est un sujet hautement politisé, où il est difficile de parler sérieusement. Pensons par exemple aux mesures adoptées pour lutter contre l'ennemi djihadiste. Dès qu'on fait entendre un point de vue critique, ou simplement nuancé, on se fait accuser d'être « trop mou face au terrorisme » voire « complice des terroristes ». Schneier appelle au contraire à envisager la sécurité comme un sujet sérieux, et donc à s'abstenir de ce genre d'accusations tranchantes. Dans ses livres (comme « Beyond Fear ») et sur son blog, il remet sans cesse en cause les certitudes, critique le « show sécuritaire », demande qu'on évalue les mesures de sécurité, leur efficacité et leur coût, au lieu de simplement dire « il faut faire quelque chose, peu importe quoi ».

Le sujet de ce livre (plutôt un essai relativement court) est l'Internet des Objets. C'est un terme marketing, flou et mal défini. Schneier lui préfère celui d'« Internet+ », dont il reconnait qu'il n'est pas meilleur mais qu'il a l'avantage de forcer à reconsidérer de quoi on parle. En gros, il y a aujourd'hui énormément d'« objets » connectés à l'Internet. Ils ont en commun d'être des ordinateurs, mais de ne pas être perçus comme tels. Ce sont des ordinateurs, car ils en ont le matériel et surtout le logiciel, avec ses bogues et ses failles de sécurité. (Pour paraphraser l'auteur, « Un grille-pain moderne est un ordinateur avec des résistances chauffantes en plus ».) Mais ils ne sont pas perçus comme tels, donc le logiciel ne fait l'objet d'aucune analyse de sécurité, le problème de la mise à jour n'est pas envisagé, et les sociétés qui produisent ces objets n'ont aucune culture de sécurité, et refont en 2018 les erreurs que l'industrie informatique faisait il y a 20 ans (mots de passe par défaut, menaces judiciaires contre ceux qui signalent des failles de sécurité, tentative d'empêcher la rétro-ingénierie, affirmations grotesques du genre « notre système est parfaitement sécurisé »). La sécurité des objets connectés, de l'« Internet+ » est donc abyssalement basse. À chaque conférence de sécurité, on a de nombreux exposés montrant la facilité avec laquelle ces objets peuvent être piratés. Schneier cite une classe de politique du monde numérique où, au cours d'un travail pratique, la moitié des étudiants ont réussi à pirater une poupée connectée, alors même qu'ils et elles sont des juristes ou des étudiants en sciences politiques, pas des pentesteurs.

Tant que l'object connecté est une brosse à dents, et que le piratage a pour seule conséquence d'empêcher cette brosse de fonctionner, ce n'est pas trop grave. Mais beaucoup d'objets ont des capacités bien plus étendues, et qui touchent le monde physique (d'où le titre sensationnaliste du livre). Si l'objet est une voiture, ou un dispositif de sécurité d'une usine, ou un appareil électrique potentiellement dangereux, les conséquences peuvent être bien plus graves. On est loin des problèmes de sécurité de WordPress, où la seule conséquence en cas de piratage est l'affichage d'un message moqueur sur la page d'accueil du site Web !

(Je rajoute, à titre personnel - ce n'est pas dans le livre, qu'il est scandaleux que, pour beaucoup d'objets, l'acheteur n'ait plus le choix. Aujourd'hui, acheter une télévision ou une voiture qui ne soit pas connectée, est devenu difficile, et demain, ce sera impossible. Un changement aussi crucial dans nos vies a été décidé sans que le citoyen ait eu son mot à dire.)

Schneier explique en détail les raisons techniques, pratiques et financières derrière l'insécurité informatique mais il note que cette insécurité ne déplait pas à tout le monde. Des services étatiques comme la NSA (dont la mission est justement de pirater des systèmes informatiques) aux entreprises qui gagnent de l'argent en exploitant des données personnelles, des tas d'organisations profitent de cette insécurité, ce qui est une des raisons pour laquelle elle ne se réduit guère. (Pour la NSA, Schneier préconise de la séparer en deux organisations radicalement distinctes, une chargée de l'attaque et une de la défense. Actuellement, la NSA est censée faire les deux, et, en pratique, l'attaque est toujours jugée plus importante. Cela amène la NSA, par exemple, à ne pas transmettre aux auteurs de logiciels les failles de sécurité détectées, de façon à pouvoir les exploiter. Le système français a aussi ses défauts mais, au moins, l'attaque - armée et DGSE - et la défense - ANSSI - sont clairement séparées, et la défense ne dépend pas de l'armée ou de la police, qui sont intéressées à conserver l'insécurité informatique.)

Notez que le livre est clairement écrit d'un point de vue états-unien et parle surtout de la situation dans ce pays.

Et les solutions ? Parce que ce n'est pas tout de faire peur aux gens, avec des scénarios qui semblent sortis tout droit des séries télé « Black Mirror » ou « Mr Robot ». Il faut chercher des solutions. L'auteur expose successivement le quoi, le comment et le qui. Le quoi, c'est le paysage que nous voudrions voir émerger, celui d'un « Internet+ » dont la sécurité ne soit pas risible, comme elle l'est actuellement. Les solutions ne vont pas de soi, car elles auront forcément un coût, et pas uniquement en argent, mais aussi en facilité d'usage et en générativité (pour reprendre le terme de Jonathan Zittrain, qui désigne ainsi la capacité d'une technique à faire des choses non prévues par ses concepteurs). Un exemple d'un choix difficile : le logiciel de l'objet doit-il être mis à jour automatiquement et à distance ? Du point de vue de la sécurité, c'est clairement oui, mais cela ouvre des tas de problèmes, comme la possibilité pour le vendeur de garder un contrôle sur l'objet vendu (cf. RFC 8240 pour les détails). Autre point qui sera difficile à avaler (et l'auteur n'en parle d'ailleurs que très peu) : il ne faudra pas tout connecter. Connecter des frigos et des télés à l'Internet est peut-être pratique et sexy mais c'est dangereusement irresponsable.

Le comment, ce sont les moyens d'y arriver. Et le qui, c'est la question brûlante de savoir quelle organisation va devoir agir.

Schneier ne croit pas au marché, qui a largement démontré son incapacité à résoudre les problèmes de sécurité. Cela semble une évidence mais il ne faut pas oublier que Schneier écrit pour un public états-unien, pour qui le marché est sacré, et toute suggestion comme quoi le marché n'est pas parfait est vite assimilée au communisme. Bruce Schneier suggère donc un rôle essentiel pour l'État, une position courageuse quand on écrit aux États-Unis. Il ne se fait pas d'illusions sur l'État (il décrit plusieurs cas où l'État, ses lois, ses règles et ses pratiques ont contribué à aggraver le problème, comme par exemple la loi DMCA) mais il ne voit pas d'autre option réaliste, en tout cas certainement pas l'« auto-régulation » (autrement dit le laisser-faire) chère à la Silicon Valley.

Bruce Schneier est bien conscient qu'il n'y a pas de solution idéale, et que la sécurisation de l'Internet+ sera douloureuse. Si vous lisez ce livre, ce que je vous recommande fortement, vous ne serez certainement pas d'accord avec tout, comme moi. (Par exemple, la proposition de faire du FAI le responsable de la sécurité des réseaux des utilisateurs à la maison m'inquiète. Et sa suggestion d'ajouter encore des règles et des processus, alors qu'au contraire cela sert en général à encourager l'irresponsabilité n'est pas idéale non plus.) Mais ne nous faisons pas d'illusion : on n'aura pas de solution parfaite. Et, si nous ne faisons rien, nous aurons peut-être des « solutions » catastrophiques, par exemple des règles ultra-liberticides imposées en mode panique par des politiciens affolés, après une grosse crise due à un objet connecté.

Vous serez peut-être également intéressé·e par cet exposé de l'auteur au sujet de ce livre.


La fiche

Fiche de lecture : Le livre-échange

Auteur(s) du livre : Mariannig Le Béchec, Dominique Boullier, Maxime Crépel
Éditeur : C & F Éditions
978-2-915825-76-3
Publié en 2018
Première rédaction de cet article le 30 août 2018


Le livre, sous ses deux formes, papier ou numérique, est un objet de passion depuis longtemps. Ce ne sont pas juste des lettres qu'on lit. Les lecteurices ont des usages, des pratiques, ils et elles se prêtent les livres, les annotent, les commentent, les échangent, en parlent sur leur blog…

Ce livre est une étude de ces pratiques. Que font les lecteurs de leur livre ? Pour chaque pratique, des lecteurices sont interrogé·e·s, des experts commentent parfois. On ne parle pas du texte, uniquement des usages que les lecteurices font du livre.

Les usages du livre sur papier forment l'essentiel de cet ouvrage, qui note que le livre numérique fait apparemment peu l'objet de ces diverses formes d'échange. On le lit, mais c'est tout.

Les usages du livre papier sont très variés (sans compter, dirait le cynique, celui de caler les meubles). Et les avis des lecteurices sont également divers. L'annotation, par exemple, est sans doute le chapitre où les avis sont les plus tranchés, entre celles et ceux qui considèrent le livre comme « sacré », et qui ne se permettraient pas d'y ajouter la moindre marque, et ceux et celles qui griffonnent, corrigent, et ajoutent des commentaires au stylo rouge. Le livre n'est clairement pas un objet comme les autres. À propos de l'achat de livres d'occasion, une lectrice explique qu'elle n'y recourt pas, car elle lit au lit et qu'elle ne veut pas faire rentrer dans son lit, espace intime, des livres déjà manipulés par un inconnu…

En résumé, un bel hommage à l'abondance de pratiques sociales autour du livre.

Déclaration de conflit d'intérêt : j'ai reçu un exemplaire de ce livre gratuitement.

Sur ce livre, on peut aussi lire :


La fiche

Fiche de lecture : Bitcoin, la monnaie acéphale

Auteur(s) du livre : Adli Takkal Bataille, Jacques Favier
Éditeur : CNRS Éditions
978-2-271-11554-6
Publié en 2017
Première rédaction de cet article le 11 mars 2018


Le succès du Bitcoin puis, plus récemment, celui du concept de chaîne de blocs, ont entrainé l'apparition de nombreux ouvrages sur le sujet. Ce dernier livre a un point de vue résolument « pieds dans le plat », en démolissant pas mal de vaches sacrées de la littérature économique.

Bitcoin dérange, c'est sûr, et les attaques contre lui n'ont pas manqué. Il a été accusé d'être une « monnaie virtuelle » (comme si l'euro ou le dollar avaient plus de réalité), d'être une monnaie de la délinquance (comme si la majorité des transactions illégales n'était pas en dollars), d'être une pyramide de Ponzi (sans doute l'accusation la plus ridicule)… Ce livre va donc tenter de redresser la barre, avec talent, et sans prendre de gants.

Dès la page 17, les discours des ignorants anti-Bitcoin se font étriller : « Ponzi, en matière d'argent, est un peu le point Godwin de l'invective » De nombreux autres clichés vont être remis en cause dans ce livre, qui aime les phrases-choc et, la plupart du temps, parfaitement justes.

Même quand une idée reçue est répétée en boucle par beaucoup de messieurs sérieux, les auteurs n'hésitent pas à lui tordre le cou. Ils exécutent ainsi les chaînes privées (« à permission ») p. 56, sans aucun respect pour tous les consultants qui vendent des rapports expliquant que c'est l'avenir.

Bon, la légende de la pyramide de Ponzi et les chaînes privées étaient des cibles faciles, aisées à réfuter. Mais ce livre ne recule pas non plus devant les critiques plus sérieuses, comme le problème écologique que posent les calculs (la « preuve de travail ») nécessaires pour protéger la chaîne Bitcoin. De même, les problèmes parfois « violents » agitant la « communauté » Bitcoin sont largement exposés et remis dans le contexte. On trouve par exemple une bonne analyse de la question du « pouvoir des mineurs ».

Les auteurs sont très à l'aise aussi bien avec l'informatique qu'avec l'économie, mais dérapent parfois sur des sujets « vendeurs » mais sur lesquels ils manquent de sens critique, comme l'Internet des Objets ou le vote électronique. De même, la présentation de Namecoin est très sommaire, et comprend d'ailleurs une erreur amusante lorsqu'ils disent que le TLD utilisé pour les noms de domaine Namecoin est .name (c'est en fait .bit).

Malgré ces défauts, c'est un livre que je recommande très fortement. Son titre à lui seul résume la bonne connaissance du Bitcoin par les auteurs : des tas d'adjectifs ont été utilisés pour le Bitcoin (« virtuel », « cryptographique », « décentralisé »…) mais je trouve qu'aucun ne résume aussi bien le Bitcoin que celui qu'ils ont choisi, « acéphale ».


La fiche

Fiche de lecture : Le médecin qui voulut être roi

Auteur(s) du livre : Guillaume Lachenal
Éditeur : Seuil
9-782021-142563
Publié en 2017
Première rédaction de cet article le 3 janvier 2018


Voici un excellent livre sur le colonialisme, à travers le cas d'un médecin français, Jean-Joseph David, qui, en poste à Wallis, puis au Cameroun, a obtenu les pleins pouvoirs, et s'est lancé dans une utopie, créer une société parfaite.

C'est une banalité de parler de pouvoir médical et de dire que le médecin se sent souvent placé au dessus des autres humains. Mais ici, dans les deux pays, David a en effet réussi à avoir la totalité des pouvoirs, médical, mais aussi économique, administratif, policier et judiciaire (il pouvait punir, et il ne s'en privait pas). Tout partait pourtant d'une idée sympathique, celle de la « médecine sociale », l'idée, en rupture avec la médecine pasteurienne, qu'on ne pouvait pas considérer la maladie comme le résultat de la seule action des microbes, mais qu'il fallait prendre en compte tout l'environnement. Mais cette idée a vite mené à un dérapage qu'on doit pouvoir qualifier de totalitaire. Le médecin s'est en effet senti en droit de réorganiser toute la société selon ses vues, évidemment sans jamais demander leur avis aux habitants.

Jean-Joseph David était-il gentil ou méchant ? Il traitait bien les indigènes, mais comme un éleveur traite bien son troupeau. Il ne les considérait pas comme des citoyens, même pas complètement comme des humains, quand il parlait d'« améliorer la race » ou bien d'amener beaucoup d'enfants à l'âge adulte pour que la France ait beaucoup de tirailleurs. Et ses utopies ont parfois eu des conséquences graves. Il était clairement mégalomane (« la mégalomanie est une maladie tropicale », note un ancien des interventions en Afrique à l'auteur) mais était aussi le produit de son époque (la culture du Pharo, où tous ces médecins coloniaux étaient formés par d'anciens coloniaux) et de l'éloignement (depuis Yaoundé, le gouverneur français le laissait faire ce qu'il voulait).

Le titre du livre fait évidemment référence à Kipling mais, ici, le héros ne cherche pas juste à être roi et à en avoir les avantages, il veut vraiment transformer la société.

Le livre est un peu décousu, d'abord parce qu'on a peu d'archives sur David (une grande partie a disparu dans les troubles qu'a connu le Cameroun par la suite), ensuite parce que ce n'est pas un roman, mais un travail plutôt universitaire, avec beaucoup de notions de sociologie et d'anthropologie qui nécessiteront que l·e·a lect·eur·rice s'accroche. Mais cela vaut la peine, il y a eu peu de descriptions de ce genre d'« utopies coloniales » où un mégalomane, profitant du pouvoir que lui donnait la force militaire de la France, se disait « je vais enfin pouvoir remodeler la société ». On est choqués de sa dictature et en même temps, c'est fascinant de se demander « et moi, si j'avais un tel pouvoir, j'en ferais quoi ? »


La fiche

Fiche de lecture : La mer des Cosmonautes

Auteur(s) du livre : Cédric Gras
Éditeur : Paulsen
Publié en 2017
Première rédaction de cet article le 1 janvier 2018


Il fait froid dehors, en ce début 2018 ? Voici un livre pour se réchauffer : partez en Antarctique avec les polyarniks russes.

Ce n'est pas un roman, mais un témoignage de l'auteur, qui est allé en Antarctique (en été, quand même…) à bord du Akademik Fedorov et en a rapporté plein d'histoires de travailleurs polaires. Et, oui, la mer des Cosmonautes du titre existe vraiment.

Le temps des explorateurs polaires avec trois types et quinze chiens qui se lançaient à l'assaut du continent blanc est passé : les bases sont maintenant bien plus grandes et peuplées, avec une débauche de matériel. Dans les bases russes, on trouve tous les fleurons de l'ex-industrie soviétique, devenues souvent épaves, de l'Iliouchine 14 au GAZ-69. On est maintenant dans l'exploitation plus que l'exploration. Mais les conditions de vie restent difficiles : le matériel casse, les humains s'épuisent, l'accident guette dès qu'on sort, il faut parfois allumer un feu sous le bulldozer pour qu'il démarre. Et les Russes prennent apparemment moins de précautions avec le matériel humain, alimentant le cimetière qui jouxte une des bases.

Mais pourquoi trouve-t-on des volontaires pour l'Antarctique ? À l'époque soviétique, une des raisons était le prestige attaché au métier de polyarnik. Leur prestige ne le cédait qu'aux cosmonautes, héros souvent cités par les polyarniks nostalgiques « à cette époque, on était quasiment aussi adulés que les cosmonautes », et les gamins dans les cours d'école jouaient en alternance au cosmonaute et au travailleur polaire. Tout ceci s'est effondré avec l'Union Soviétique, au point que, dans certaines bases, il a fallu vendre les breloques à étoile rouge aux touristes états-uniens de la base voisine, pour pouvoir se financer. Il n'y a plus qu'en Biélorussie, gelée dans les années Brejnev, que les polyarniks sont encore accueillis avec médailles et discours, à leur retour.

Aujourd'hui, la Russie continue l'exploitation antarctique, mais avec un nombre de bases réduit. Des nouveaux pays sont venus, et on s'échange les visites de courtoisie, dans ce territoire démilitarisé. Le travailleur polaire continue de bénéficier d'avantages matériels conséquents, et garde un peu de prestige, pas à cause de l'Antarctique, mais à cause des escales exotiques que fait le navire avant d'atteindre le continent blanc. Et puis, certains travailleurs le confient à l'auteur : après plusieurs rotations en Antarctique, ils ne se voient pas vraiment reprendre une vie « normale ».

En ligne, les photos de l'auteur.


La fiche

Fiche de lecture : Les dix millénaires oubliés qui ont fait l'histoire

Auteur(s) du livre : Jean-Paul Demoule
Éditeur : Fayard
978-2-213-67757-6
Publié en 2017
Première rédaction de cet article le 10 décembre 2017


Quand on parle de la préhistoire, tout le monde voit ce que c'est : des types vêtus de peaux de bêtes partant chercher du feu ou chassant le mammouth, ou encore inventant plein de choses. Idem pour l'histoire, on a plein de livres et de films sur tous les aspects de l'histoire, depuis qu'on a inventé l'écriture, jusqu'à Stéphane Bern et Franck Ferrand. Mais entre les deux ? Entre les deux, dit l'auteur, il y a « dix millénaires zappés ». La période qui va en gros de 13 000 à 3 000 AEC : qu'en savons-nous ?

Le livre fait le tour des innovations qui ont marqué cette période un peu oubliée : l'agriculture, bien sûr, les villages, les outils en métal, mais aussi la religion organisée. Il y avait bien sûr des croyances depuis longtemps mais, pendant ces dix millénaires, on commence à en voir des manifestations partout, y compris au prix d'efforts colossaux, inimaginables quand on était chasseur-cueilleur. Et cela ne s'arrête pas là. C'est aussi pendant cette période, dix mille ans avant Macron, qu'on invente les inégalités. Avant, il y avait sans doute des chefs. Mais l'examen des tombes ne permettait pas de voir des vraies inégalités. Pendant les dix millénaires, on voit au contraire apparaitre la distinction entre ceux qu'on enterre simplement, et ceux dont le tombeau recèle des richesses qui feront la joie des archéologues. L'auteur examine comment des gens qui vivaient à peu près libres ont pu accepter cet asservissement, et note que cela n'a pas été un processus linéaire, mais qu'il y a eu de nombreux retours à des enterrements égalitaires (suite à des révoltes contre les chefs ?)

Mais la civilisation ne s'est pas arrêtée à la religion et aux chefs. On a aussi inventé la guerre. Oui, bien sûr, il y avait de la violence avant. Mais des armées entières s'affrontant, alors que la plupart des soldats n'avaient aucune raison personnelle de se battre, ça date aussi de cette époque. (L'Europe en dehors de la Grèce était en retard sur la voie de la civilisation, et n'a donc connu sa première grande bataille que vers 1 200 AEC.) Effet amusant de la guerre, c'est aussi pendant cette période que le cannibalisme est devenu tabou…

Et la domination masculine ? A-t-elle toujours existé ? Et, si non, a-t-elle été inventée pendant cette période ? Contrairement aux batailles, cela ne laisse pas forcément beaucoup de traces analysables. Là, on est forcément davantage dans la spéculation, comme les théories de Bachofen, qui cherchait à tout prix à prouver que la domination masculine n'est pas universelle (alors qu'apparemment, elle l'est).

Et je vous laisse découvrir dans ce livre les autres étonnantes innovations de l'époque.


La fiche

Fiche de lecture : Artemis

Auteur(s) du livre : Andy Weir
Éditeur : Del Rey
9780091956943
Publié en 2017
Première rédaction de cet article le 21 novembre 2017


Le nouveau roman de l'auteur du Martien (oui, c'est nul de présenter un auteur par son bouquin précédent qui a eu du succès mais je n'avais pas d'autre idée). Il garde le côté « hard-tech », mais tend cette fois vers le polar.

Dans « Le Martien », le héros devait se débrouiller tout seul sur la planète Mars et l'un des principaux intérêts du roman était la description détaillée et correcte scientifiquement des différents problèmes qu'il affrontait, et de comment il les résolvait. Cette fois, ça se passe sur la Lune, et il s'agit de problèmes plus policiers, avec des méchants (très méchants), des complots et des sabotages (qui ont tout de suite un caractère plus dramatique quand il n'y a pas d'atmosphère dehors et qu'on ne peut donc pas sortir pour échapper au danger).

Comme le précédent, ce roman plaira aux geeks scientifiques. Ils y trouveront de la physique et de la chimie en quantité. Si vous le lisez en anglais, pensez à réviser la terminologie, notamment du monde de la soudure, qui joue un rôle essentiel dans le livre. « I wasn't sure what grade of steel [they] were made of, but most grades melt at or below 1450° C. So, just to be safe, my plate and stock rods were Grade 416 with a melting point of 1530° C. »

Mais les autres seront également ravis des personnages (surprenants), de la morale (curieuse), de l'intrigue (à rebondissements) et de l'(abondante) action. Mon fils, regardant par-dessus mon épaule, m'avait dit « c'est encore un livre où le héros affronte des épreuves, les surmonte puis pécho la jolie fille à la fin ? » Eh bien, non, ce n'est pas ça du tout, vous verrez en lisant.


La fiche

Fiche de lecture : Une toile large comme le monde

Auteur(s) du livre : Aude Seigne
Éditeur : Zoe
978-2-88927-458-1
Publié en 2017
Première rédaction de cet article le 5 novembre 2017


La cybercatastrophe (plus d'Internet, tout cassé, plus de vidéos de chat) est un thème fréquent dans les médias mais un peu moins dans les romans. Aude Seigne s'y est attelée dans son dernier roman, « Une toile large comme le monde ».

Le roman suit plusieurs personnages plutôt bien intégrés dans la société, plutôt mondialisés, n'ayant pas des boulots idiots (il n'y a jamais de caissière de supermarché, encore moins de vendeur des rues, dans les romans). Mais, pour des raisons diverses, ils décident d'arrêter Internet. Je ne vous en dis pas plus sur l'intrigue.

Disons-le tout de suite, je n'ai pas aimé le roman : l'auteure saute allègrement des pans entiers de son histoire, on ne comprend pas vraiment les motivations des personnages (qui passent pourtant tou·te·s beaucoup de temps à se regarder le nombril en en parlant), et les détails de la constitution et de la coordination de leur groupe sont à peine esquissés. Ça ne peut pourtant pas être aussi simple de monter un complot mondial !

Mais la partie de description de l'infrastructure d'Internet est bien faite, détaillant des aspects de son fonctionnement qui sont peu traités, que ce soit dans les cours d'informatique ou dans les romans. Elle a raison de pointer du doigt que tout le monde aujourd'hui dépend d'Internet, sans avoir la moindre idée de son fonctionnement (et je ne parle pas de la technique, juste des acteurs impliqués). J'ai bien aimé la citation « Ce n’est pas parce qu’on est YouTuber, joueur, programmeur, hacker ou community manager qu’on connaît l’existence des câbles », qui est quasiment celle par laquelle je commence mon cours au CELSA. Je vais réclamer des droits d'auteur 😃 Mais je préfère encore plus une autre phrase de l'auteure, « Internet n'est pas un esprit, il a besoin d'un corps » (et ce corps n'est pas uniquement composé de câbles et de machines).

Outre les câbles, largement décrits dans le roman (ainsi que les centres de données, à l'occasion d'une visite plus pédagogique que littéraire), l'auteure parle aussi des gens qui sont derrière le réseau, ce qui est utile, même si elle verse parfois dans le sensationnalisme (« Ils [les ingénieurs réseaux] sont seulement quelques centaines, à l'échelle mondiale, et ils se réunissent deux à trois fois par an [probablement une allusion aux réunions NANOG]. »).

Techniquement, n'attendez pas de détails sur les techniques utilisées pour arrêter l'Internet. Le livre est globalement bien documenté mais comprend plusieurs exagérations. C'est le cas, par exemple, de l'apparition dans une liste de pannes partielles de l'Internet, de « 2014 ― Panne importante à l'échelle mondiale, suscitée par le dépassement de la limite des 512 000 routes, que d'anciens modèles de routeurs ne peuvent prendre en charge » (alors qu'il ne s'était en fait pas passé grand'chose). Si vous voulez approfondir cette question de la résilience d'Internet, vous pouvez aussi lire mon article au SSTIC.

Il y a eu un article d'Usbek & Rica sur ce livre. Comme souvent dans les médias, l'article ne tient pas les promesses du titre. Le titre parle de couper Internet, et ensuite c'est juste « en 2016, une cyberattaque [celle contre Dyn] prive des millions d’Américains d’accès aux plus grands sites pendant une dizaine d’heures… ». C'est une erreur courante des analyses de la robustesse de l'Internet que de confondre les pannes locales et limitées dans le temps (relativement fréquentes et difficiles à empêcher) avec une vraie cybercastrophe stoppant presque tout l'Internet pendant des semaines.

On trouve aussi dans cet article des grosses bêtises du genre « avoir une boîte mail remplie à ras-bord et pleine de spams est désormais aussi condamnable que de ne pas trier ses déchets ».

Voici la page officielle du livre. Mais, comme vous vous en doutez, je préfère recommander, pour le lecteur intéressé par le « corps d'Internet », le livre Tubes d'Andrew Blum.


La fiche

Fiche de lecture : 1177 b.c. the year the civilization collapsed

Auteur(s) du livre : Eric H. Cline
Éditeur : Princeton University Press
978-0-691-16838-8
Publié en 2014
Première rédaction de cet article le 29 octobre 2017


Vous savez pourquoi tant de civilisations de la Méditerranée orientale ont disparu assez rapidement, autour de 1 177 AEC ? Moi non, mais Eric Cline s'est penché sur le problème, sur lequel je ne connaissais rien. Les grandes catastrophes sont toujours fascinantes. Que savons-nous sur celle-ci ?

Posons donc le décor. Vers 1 200 AEC, dans l'âge du bronze tardif, la Méditerranée orientale abrite une concentration de civilisations avancées. On connait l'Égypte des pharaons, bien sûr, mais il y a aussi les Hittites, les Mycéniens, les Minoens et plein d'autres, ainsi que beaucoup de cités-États riches du commerce, comme Ougarit ou Troie. Tout cela se passait longtemps avant la Grèce antique et a fortiori longtemps avant Rome. Tout ce monde échangeait, s'écrivait (bénédiction pour les archéologues du futur), se visitait et se faisait la guerre.

Mais, quelques dizaines d'années après, tout a disparu. Si l'Égypte a continué, ce ne sera que sous forme d'un royaume très diminué (privé de ses possessions asiatiques). Les malheurs de Troie seront écrits sous forme d'un poème épique, bien plus tard. D'autres disparaitront en laissant peu de traces, comme le royaume hittite, pourtant la deuxième superpuissance de l'époque, après l'Égypte.

Est-ce qu'on connait la cause ? Pas vraiment (oui, désolé, j'anticipe sur la fin du livre). Des tas d'explications ont été proposées, des tremblements de terre, des sécheresses, des invasions par les peu connus peuples de la mer… Aucune ne semble pouvoir tout expliquer, il y a peut-être eu simplement combinaison de facteurs au mauvais moment. On ne sait même pas si les « peuples de la mer » étaient vraiment une armée d'invasion, ou simplement des réfugiés fuyant d'autres lieux touchés par la crise.

C'est que les traces archéologiques sont incomplètes et difficiles à interpréter. Quand on trouve une cité en ruines, était-ce le résultat d'un tremblement de terre ou d'une invasion, ou simplement du temps qui s'est écoulé depuis son abandon ? Eric Cline explique très bien comment l'archéologue d'aujourd'hui doit travailler, déchiffrant des tablettes d'argile, et regardant si on trouve des pointes de flèche (bon indice d'une attaque militaire). Tout est indice de nos jours, et l'auteur déplore le comportement des archéologues d'autrefois, comme Schliemann, qui y allait à la brutale, sans même noter ce qu'ils détruisaient au passage.

Cline fait revivre tout ce monde peu connu des profanes. On a tous entendu parler des pharaons égyptiens et de leurs pyramides, mais beaucoup moins des autres peuples de l'époque. J'ai beaucoup aimé la description du navire d'Uluburun, chargé d'innombrables richesses provenant de toute la région, et qui symbolise l'importance des échanges commerciaux pendant cette « première mondialisation ». Comme le note l'auteur, un pharaon égyptien de l'époque était sans doute autant préoccupé de l'approvisionnement de son pays en étain (indispensable pour le bronze, donc pour les armes), qu'un président états-unien aujourd'hui avec le remplissage des 4x4 en essence.

Bon, et après cette description d'une époque dynamique et d'une civilisation avancée, pourquoi cette disparition relativement rapide ? Bien sûr, le titre du livre est un peu exagéré. L'effondrement des civilisations méditerranéennes n'a pas duré qu'une seule année, le processus a pris plus de temps. Et tout n'a pas été perdu : si les échanges commerciaux se sont effondrés, si les grands royaumes ont disparu, si de nombreuses riches cités sont devenues des ruines, les gens n'ont pas oublié l'écriture, ni l'art, ni leurs techniques et, quelques siècles plus tard, c'est reparti comme avant.

Néanmoins, il y a bien eu une redistribution des cartes spectaculaires, dont les causes ne sont pas bien connues. Cline passe en revue toutes les hypothèses (comme il le note dans la postface, il ne manque que l'épidémie…) mais on reste à la merci de nouvelles découvertes archéologiques, qui changeront notre opinion sur cette crise. Cline note que, contrairement aux cas étudiés par Diamond dans son livre « Effondrement », qui ne couvre que des civilisations isolées, ici, c'est peut-être la forte interconnexion des civilisations méditerranéennes qui a causé leur chute en dominos.

En attendant, si vous voulez aider les scientifiques, je vous rappelle que le linéaire A est toujours à déchiffrer… (Il a cessé d'être utilisé avant l'effondrement, mais il pourrait permettre de mieux comprendre la civiisation minoenne.)


La fiche

Fiche de lecture : La face cachée d'Internet

Auteur(s) du livre : Rayna Stamboliyska
Éditeur : Larousse
978-2-03-593641-7
Publié en 2017
Première rédaction de cet article le 28 juin 2017


Vous allez peut-être vous dire, en prenant connaissance du sous-titre (« hackers, darkweb, Tor, Anonymous, WikiLeaks, bitcoins… ») et surtout en voyant la couverture un peu tape-à-l'œil, que c'est juste le Nième livre sur les gros méchants cyberaffreux des bas-fonds du réseau, ceux qui font sauter une centrale nucléaire en tapotant sur un smartphone, ceux que le gentil ministre va heureusement bientôt civiliser. Des livres de ce genre, sensationnalistes, bourrés d'erreurs qui amusent les geeks et égarent les lecteurs innocents, il y en a plein. Mais celui-ci est différent :

  • Il est écrit par une auteure qui connait son (ou plutôt ses) sujets,
  • Il ne contient pas d'erreurs (ou alors je ne les ai pas trouvées),
  • Il essaie de tout expliquer sans simplifier et sans prendre le lecteur pour un ahuri.

Le cahier des charges était donc difficile. Les éditions Larousse font des livres à destination du grand public (le célèbre M. Michu). Souvent, « mais c'est pour le grand public » sert d'excuse pour bâcler le travail. Or, cela devrait être le contraire : comme M. Michu n'a pas les connaissances nécessaires pour corriger de lui-même les erreurs, il faut être plus rigoureux et plus précis quand on écrit pour le grand public. L'auteure n'a pas écrit pour toi, lecteur typique de mon blog ou, plutôt, pas que pour toi.

On trouve très peu de livres ayant un cahier des charges analogue. Soit on fait du purement technique, pour informaticiens, soit on fait du Paris Match. C'est ce que j'apprécie le plus dans le travail de Rayna Stamboliyska, l'effort pour être claire et pédagogue, sans être approximative et baratineuse.

Est-ce réussi ? Je vais laisser l·a·e lect·rice·eur en juger. Personnellement, je trouve que le livre est riche, plein d'informations, et que M. Michu va devoir faire un effort pour suivre ces nombreux personnages et ces rebondissements multiples (notamment dans le chapitre sur WikiLeaks). D'autant plus qu'on trouve dans ce livre des choses qu'on s'attend plus à voir dans un ouvrage universitaire (ma préférée est le double espace de numérotation des références, un en romain pour des notes de bas de page, un autre en italique pour la bibliographie à la fin) Mais, justement, je ne pense pas que M. Michu soit un imbécile et demander un travail au lecteur ne me choque pas.

Ah, et puisque j'ai parlé de la bibliographie : recopier à la main des URL est évidemment pénible et provoque souvent des erreurs. Donc, pour accéder aux nombreux textes cités, et pour d'autres raisons, je recommande que vous visitiez le site Web officiel attaché au livre. Quelques autres références :

Avertissement : je suis l'auteur de la préface, et j'ai reçu un exemplaire gratuit. Je ne suis donc pas neutre.

Un dernier mot, pour les programmeurs : il y a deux fautes dans le code en C sur la couverture. Cherchez.


La fiche

Fiche de lecture : For all the tea in China

Auteur(s) du livre : Sarah Rose
Éditeur : Arrow Books
9780099493426
Publié en 2009
Première rédaction de cet article le 14 février 2017


Robert Fortune n'exerçait pas vraiment un métier qu'on associe aux aventures, à l'espionnage et à la mondialisation économique. Il était botaniste. S'il a désormais sa place comme héros de roman, c'est parce que ce Britannique a joué un rôle crucial dans le grand jeu qui a permis de prélever en Chine les plants de thé et le savoir nécessaire pour les faire pousser, avant de transplanter le tout en Inde, permettant à l'Empire de se passer d'un partenaire chinois difficile et de produire son propre thé, révolutionnant ainsi le breakfast.

C'est qu'il ne suffisait pas d'être bon botaniste pour, en 1848, faire pousser du thé en Inde. La Chine avait un monopole historique, et le défendait. Exporter les plants de thé, ou les méthodes permettant de transformer les feuilles, était strictement interdit. La Chine était certes à l'époque dominée militairement par l'Europe mais restait indépendante. Et très peu d'Européens avaient osé pénétrer à l'intérieur du pays. La plupart restait dans les ports protégés par les canonnières impérialistes.

Fortune, employé de l'East India Company, fut donc chargé de cette mission. Sarah Rose fait revivre de façon très vivante les aventures assez extraordinaires d'un homme qu'on imaginerait plutôt s'occuper d'un tranquille jardin anglais. Il part en Chine sans guide Lonely Planet, loin des zones où les armes européennes garantissent la sécurité des étrangers, dans des parties de la Chine où même le pouvoir de l'Empereur est assez théorique. Curieux, Fortune observe non seulement le thé, mais aussi plein d'autres plantes, ainsi que les Chinois et leur civilisation. (Il est moins curieux en politique, ne voyant pas venir la révolte des Taiping.) Et il réussit non seulement à survivre mais à mener à bien sa mission d'espionnage industriel (les ayant-droits d'aujourd'hui parleraient probablement de « piratage »). Le thé arrive à Calcutta, puis à Darjeeling et finira, après un ou deux faux départs, par s'épanouir en Inde.

Bref, voyages, thé, et aventures, tout ce qu'on attend d'un roman.


La fiche

Fiches de lecture des différentes années : 2019  2018  2017  2016  2015  2014  2013