Mon blog

C'est une banalité que de choisir le conteneur comme symbole de la mondialisation. Mais comment en est-on arrivé là ? Qui a inventé le conteneur et pourquoi ? Comment s'est-il imposé ? Je trouve que Marc Levinson a fait un excellent travail d'histoire de la conteneurisation dans ce gros livre.

Donc, le conteneur, c'est la grosse boîte en acier qu'on voit déborder sur le pont des navires. Permettant d'abaisser le coût de transport international jusqu'au point qu'il devient souvent négligeable, le conteneur a permis aux baskets fabriquées au Viêt Nam, aux T-shirts du Bangladesh et aux téléphones montés en Chine d'arriver partout dans le monde. Plus besoin de mettre les usines près des futurs clients, on peut les installer là où les travaileurs ne sont pas syndiqués et donc pas chers. Mais malgré son rôle économique crucial, le conteneur ne fait pas rêver. On écrit plein de livres sur les avions, sur les bateaux, sur de nombreuses machines, mais pas sur cette grosse boîte disgracieuse, peinte de couleurs vulgaires, qu'est le conteneur. C'est là que Marc Levinson est intervenu pour écrire ce livre touffu et très détaillé. (L'original est en anglais mais j'ai lu la traduction en français.)

Levinson retrace l'histoire du conteneur, en insistant sur le rôle de Malcom McLean, qui n'est pas « l'inventeur » du conteneur (comme beaucoup d'inventions, le conteneur a de nombreux pères), mais celui qui l'a promu et développé depuis le début. L'histoire de l'homme seul luttant contre les conservatismes pour révolutionner le transport de marchandises aurait pu être fait en style « légende étatsunienne » classique, avec le courageux entrepreneur qui, parti de rien, devient riche par son travail personnel, mais, heureusement, Levinson ne donne pas dans ce travers. Il explique bien le rôle de McLean, mais aussi ses erreurs et ses défauts, et le rôle de nombreuses autres personnes.

C'est que le conteneur a eu une histoire difficile. Il n'y a que dans les légendes que l'inventeur conçoit un objet et qu'après de courtes difficultés initiales, l'objet conquiert le monde par la seule force de ses qualités intrinsèques. En fait, le conteneur ne s'est pas imposé tout de suite. Il a rencontré de nombreuses difficultés, du conservatisme des acteurs déjà installés aux problèmes politiques et légaux, en passant par la difficulté d'adapter toute la chaîne du transport. Sans oublier des problèmes techniques bien concrets, pour faire une boîte solide, mais pas chère et facile à manipuler.

Levinson ne cache pas que l'effondrement des coûts du transport international n'est pas uniquement dû au conteneur, objet magique. Il a fallu refaire toute la logistique, et cela a pris de nombreuses années. En cela, ce livre est un excellent modèle d'analyse d'un système socio-technique. Contrairement à beaucoup d'études sur un objet technique, celle-ci ne considère pas le conteneur comme isolé, mais bien comme un des maillons d'un système complexe. Avec le recul, on dit que c'est le conteneur, par la baisse des coûts qu'il a engendrée, qui a permis l'actuelle mondialisation. Mais pendant de nombreuses années, il fallait vraiment avoir la foi, le conteneur coûtait aussi cher, voire plus cher que les systèmes qu'il voulait remplacer. Et il fallait remplir cette grosse boîte, pour qu'elle ne voyage pas à moitié vide et cela au retour comme à l'aller. C'est seulement quand tout le système socio-technique du transport s'est adapté à ces exigences que les coûts ont réellement baissé. En attendant, il a fallu financer l'adaptation des bateaux et des ports à ce nouvel objet et, contrairement à la légende des entrepreneurs privés qui risquent leur argent et, si ça marche, en retirent des bénéfices bien mérités, ici, une bonne partie des ports et même des navires ont été financés pendant des années par l'argent public, McLean ayant réussi à convaincre beaucoup de monde que l'avenir était au conteneur. C'est d'ailleurs la guerre du Viêt Nam qui a marqué le vrai décollage du conteneur, vu les énormes besoins en matériel de l'armée étatsunienne et l'argent dont elle disposait.

Comme tous les changements socio-techniques, le conteneur a fait des gagnants et des perdants. Levinson ne joue pas la partition de la « mondialisation heureuse » et analyse qui a gagné et qui a perdu. Parmi les perdants, les marins : la rapidité de chargement et de déchargement, un des buts de la conteneurisation, a réduit à quelques heures la durée des escales. On ne voit plus du pays quand on est marin, seulement les gigantesques terminaux à conteneurs, toujours situés, vu leur taille, très loin de la ville, contrairement au port traditionnel. Toujours parmi les perdants, les dockers, le but du conteneur étant entre autres de nécessiter moins de personnel pour charger et décharger les bateaux. Les pages consacrées aux questions sociales sont très intéressantes, mais le livre est évidemment très centré sur les États-Unis et ce pays présente quelques particularités, comme les liens de certains syndicats avec le crime organisé (même si l'auteur note que le film Sur les quais n'est pas toujours réaliste), ou comme la concurrence entre syndicats (celui des dockers et celui des camionnneurs qui s'allient chacun avec son patronat, contre l'autre syndicat…)

Mais les principaux perdants n'ont pas forcément été du côté des professionnels du transport maritime : ce sont tous les travailleurs qui se trouvent désormais en compétition avec des pays sans lois sociales, sans syndicats, sans droit du travail.

La normalisation est un sujet peu abordé dans les analyses des systèmes socio-techniques mais, ici, elle a la place qu'elle mérite. Le conteneur n'est en effet intéressant que si n'importe quel navire, train ou camion peut l'embarquer. Cela nécessite une normalisation de la taille, des caractéristiques physiques (résistance à l'écrasement) et du système de verrouillage des conteneurs. C'est un des meilleurs chapitres du livre, introduisant le lecteur à ce monde feutré des négociations autour de la normalisation, sachant que des détails apparemment sans importance, comme la largeur exacte du conteneur, peuvent faire perdre beaucoup d'argent aux premiers investisseurs, qui risquent de devoir refaire leurs ports et leurs navires, si la taille initialement retenue n'est pas celle choisie par ces premiers arrivés. Et les décisions de normalisation ne sont pas purement arbitraires, la technique a son mot à dire, par exemple sur le système de verrouillage (sinon, on perd des conteneurs en mer.)

Pour résumer, c'est un très bon exemple d'analyse socio-technique, à lire même si vous ne travaillez pas dans le domaine du transport de marchandises. On voudrait que tous les systèmes socio-techniques complexes fassent l'objet d'aussi bonnes synthèses.

Et de jolies photos de conteneurs, prises à l'exposition Playmobil à Calais : (Version en taille originale.) (Version en taille originale.)

Les discours sur les pratiques numériques des « jeunes » ne manquent pas, allant de « ielles sont digital natives, ielles sont complètement à l'aise dans l'environnement numérique, les adultes n'ont rien à leur apprendre » à « ielles sont bêtes, ielles ont la capacité d'attention d'un poisson rouge, ielles gobent toutes les fake news, ielles ne lisent plus rien, c'était mieux avant [surtout qu'il n'y avait pas d'écriture inclusive] ». Les deux positions ont en commun d'être énoncées sans avoir sérieusement étudié les pratiques effectives de jeunes réels… Au contraire, dans ce livre, Anne Cordier regarde des vrais jeunes et, sans juger a priori, analyse ce qu'ielles font sur l'Internet.

Le livre date de 2015 (et le travail de recherche semble avoir été fait un certain temps avant), mais les choses n'ont pas forcément énormément changé depuis. Il y a sans doute moins de Facebook et davantage d'Instagram chez les jeunes, et MSN, cité dans le livre, a probablement disparu. Mais les fondamentaux demeurent, à savoir une grande… déconnexion entre l'existence connectée quasiment en permanence, et la difficulté à comprendre ce qui se passe derrière l'écran. (Et comme le note l'auteure, cette déconnexion n'est pas spécifique aux jeunes. Bien des adultes, même en milieu professionnel, ne comprennent pas non plus les dessous du numérique.)

La méthodologie suivie par l'auteure était d'observer, dans un CDI, collègiens et lycéens dans leurs aventures connectées, et de les interroger, de façon aussi neutre que possible, sur ce qu'ielles en pensaient, sur leurs analyses de l'Internet. Il est important de ne pas juger. Par exemple, ceux et celles qui ont des difficultés avec les outils de l'Internet ont souvent du mal à en parler aux enseignant·e·s ou aux parents. Et d'autant plus que le discours sur les mythiques digital natives, ces jeunes qui sauraient absolument tout sur le numérique et n'auraient rien à apprendre à ce sujet, est très présent, y compris dans leurs têtes. Si une personne de 70 ans peut avouer « moi, ces machines modernes, je n'y comprends rien », un tel aveu est bien plus difficile à 11 ans, quand on est censé tout maitriser de l'Internet. Les expressions du genre « si j'avouais que je ne sais pas faire une recherche Google, ce serait la honte » reviennent souvent.

Alors, que font et disent ces jeunes ? D'abord, ielles sont divers, et il faut se méfier des généralisations. D'autant plus que l'auteure a travaillé avec des classes différentes, dans des établissements scolaires différents. La première chose qui m'a frappé a été le manque de littératie numérique (et je ne pense pas que ce se soit beaucoup amélioré depuis 2015). Oui, ils et elles savent se servir avec rapidité des équipements électroniques, et de certains logiciels (comme, aujourd'hui, WhatsApp). Mais cela n'implique pas de compréhension de ce qui se passe derrière, et cela conduit à des comportements stéréotypés, par exemple d'utiliser toujours le même moteur de recherche. Le livre contient beaucoup de déclarations des jeunes participant à l'étude, et, p. 215, l'auteure leur demande pourquoi avoir choisi le moteur de recherche de Google : « on n'a que ça à la maison ». Sans compter celles et ceux qui affirment bien fort que « Google, c'est le meilleur », avant d'admettre qu'ielles n'en connaissent pas d'autres. Là encore, ne rions pas d'eux et elles : bien des adultes ne sont pas plus avancés, même s'ielles sont à des postes importants dans le monde professionnel.

En parlant de Google, il est frappant, en lisant le livre, à quel point Google occupe une « part d'esprit », en sus de sa part de marché. Et, là, ça n'a certainement pas changé depuis la sortie du livre. Les services de Google/Alphabet sont la référence pour tout, et plus d'un collègien ou lycéen lui attribue des pouvoirs quasi-magiques. À l'inverse, les échecs ne sont que rarement correctement analysés (p. 115). Cela va de l'auto-culpabilisation « j'ai fait une erreur, je suis nulle », au déni « je suis super-fort en Internet, ce n'est pas moi qui ai fait une erreur, je suis un boss » en passant par la personnalisation « il n'a pas compris ce que je lui demandais ». Notez quand même qu'à part quelques vantards, beaucoup des jeunes interrogés sont assez lucides sur leur manque de littératie numérique « on ne nous a jamais appris, les profs disent qu'on est censés tout savoir, mais en fait, on ne sait pas ».

Le plus grave, je trouve, c'est l'absence de compréhension de ce qu'ielles font (p. 244), qui se manifeste notamment par l'absence de terminologie. Beaucoup des jeunes interrogés ne savent pas raconter ce qu'ielles font sur l'Internet, à part en décrivant des gestes (« je clique sur le E bleu »). Une telle absence de modélisation, de conceptualisation, ne permet certainement pas de comprendre ce qui se passe, et d'avoir une attitude active et critique.

Les jeunes sont souvent en compétition les uns avec les autres, et cela se manifeste aussi dans les usages numériques. Lors d'un travail scolaire impliquant le montage d'un film, les utilisateurices de Movie Maker se sont ainsi fait vertement reprendre, comme quoi il ne s'agissait que d'un outil pour bricoleurs, pas pour vrais pros.

Par contre, ielles parlent beaucoup d'entraide, surtout de la part des grandes sœurs (les grands frères sont plus rarement mentionnés) et même des parents (les mères, surtout, les pères semblent moins souvent cités par les jeunes.)

Bref, un livre que je recommande beaucoup, pour avoir une bonne idée de l'état de la « culture numérique » chez les jeunes. Normalement, vous en sortez avec moins de certitudes et de généralisations qu'au départ.

Comme l'auteure a été professeur documentaliste, j'en profite pour signaler l'existence des APDEN, les associations de professeurs documentalistes, qui font d'excellentes réunions. Et puisqu'on a parlé d'éducation au numérique, je vous suggère la lecture du programme de SNT, qui commence en 2019. Mon avis est que ce programme est ambitieux, peut-être trop, vu les moyens concrets alloués, mais qu'il va dans la bonne direction : c'est justement ce niveau d'exigence qu'il faudrait pour le numérique.

Je vous recommande également cet excellent interview de l'auteure à l'émission 56Kast.

Le sujet du harcèlement dans l'enseignement est douloureux mais il est quand même nécessaire de l'étudier. Il ne se réduit pas au cyberharcèlement, et il n'est même pas sûr que le cyberharcèlement soit si différent que cela du harcèlement classique, comme l'indique le titre de ce livre, qui met « cyber » entre parenthèses. En outre, ce sujet se prête au sensationnalisme, et les articles sur quelques cas spectaculaires masquent souvent la réalité du phénomène. On peut donc féliciter l'auteure d'avoir abordé le sujet sous un angle plus scientifique, en s'appuyant sur des faits, et en étudiant le phénomène sous tous ses aspects, afin de mieux pouvoir le combattre.

C'est d'autant plus important que les exagérations et les approximations qui sont fréquentes lorsqu'on parle du cyberharcèlement ont souvent des but cachés. Par exemple, les politiciens français dénoncent souvent l'anonymat sur l'Internet comme étant lié au harcèlement, et réclament son abolition, alors que Bérengère Stassin fait remarquer que, dans la plupart des affaires de harcèlement scolaire, la victime sait parfaitement qui sont ses harceleurs. Mais la vérité ne compte pas quand on veut faire passer une nouvelle loi.

Et, si les médias et les autorités parlent si souvent du cyberharcèlement (et très peu du harcèlement tout court), c'est que cela sert aussi à diaboliser les outils de communication modernes, qui les concurrencent. On voit ainsi des campagnes de sensibilisation anxiogènes, qui ne présentent l'Internet que comme un outil de harcèlement.

Revenons au livre. L'auteure commence par recadrer le problème dans l'ensemble des phénomènes de harcèlement à l'école, malheureusement fréquents. (Elle fait aussi remarquer que les cas les plus dramatiques, se terminant parfois par un suicide de la victime, font parfois oublier qu'il existe un harcèlement de masse, pas aussi grave mais beaucoup plus fréquent.) Le harcèlement scolaire a été étudié depuis longtemps par les spécialistes, même s'il n'existe évidemment pas de solution miracle. Le harcèlement massif est difficile à mesurer car il consiste en beaucoup de micro-agressions. Chaque agresseur a l'impression de ne pas avoir fait grand'chose, alors que c'est leur nombre qui fait la gravité du phénomène. Et le harcèlement est inégalement réparti entre les genres, les filles en étant plus souvent victimes.

Comme toutes les activités humaines, le harcèlement s'est ensuite adapté à l'Internet et diverses formes de cyberharcèlement sont apparues, que l'auteure passe en revue en détail avec, pour chacune, ce que dit la loi. Mais la presse et les politiciens, toujours prêts à diaboliser le nouveau système de communication, ont rapidement entonné le discours « c'est la faute d'Internet et des écrans, les jeunes étaient mieux avant », quitte à inventer les faits, comme dans l'affaire du soi-disant Momo challenge. La réalité est pourtant bien assez grave comme cela, et plusieurs personnalités ont dénoncé publiquement le cyberharcèlement dirigé contre elles, par exemple Marion Seclin ou Nadia Daam. Ces trois premiers chapitres du livre sont difficiles à lire, car parlant de choses extrêmement douloureuses (même si les agresseurs les considèrent toujours avec légèreté) mais indispensables, pour avoir une idée claire du phénomène. Le livre détaille notamment les nombreuses études qui ont été faites, analysant les motivations des harceleurs (inutile de rappeler que comprendre, ce n'est pas excuser, n'est-ce pas ?)

Une fois qu'on a étudié le harcèlement, reste à lutter contre lui. C'est l'objet du dernier chapitre. Au moins, maintenant, le problème est nommé et reconnu (ce n'était pas le cas il y a cent ans.) L'État s'en empare, le ministère fait des campagnes, et sensibilise, plusieurs associations sont actives (comme l'APHEE, Marion, la main tendue ou e-Enfance, cette dernière étant spécialisée dans la lutte contre le cyberharcèlement et, au passage, le livre contient énormément d'URL de ressources utiles pour lutter contre le harcèlement).

Le livre ne fournit bien sûr pas de solution simple et magiquement efficace. Il liste de nombreuses initiatives, de nombreux endroit où trouver des informations et des idées. Les personnes impliquées dans la lutte contre le harcèlement, les enseignant·e·s par exemple, y trouveront des armes contre ces affreuses pratiques. Ne manquez pas également de visiter le blog de l'auteure.

Autre compte-rendu de ce livre : celui de Didier Epsztajn.

Beaucoup de textes ont été écrits sur le rôle de l'Internet, et des réseaux sociaux centralisés, comme Facebook ou Twitter, dans des évènements politiques. Ce fut le cas, par exemple, du printemps arabe. L'auteure explore, dans ce livre très riche et très rigoureux, tous les aspects de cette relation entre les militants et les techniques d'information et de communication. Twitter peut-il battre les gaz lacrymogènes ?

(Le livre a été écrit en anglais, Zeynep Tufekci étant étatsunienne - d'origine turque. Il a été publié dans sa langue originale en 2017. Je l'ai lu dans la traduction française, tout à fait correcte, à part une certaine tendance à utiliser le mot anglais en français, comme traduire activist par activiste ou devastated par dévasté.)

Une grande partie des articles et messages écrits au sujet de l'utilisation de l'Internet par les militants des quatre coins du globe sont assez excessifs dans un sens ou dans l'autre. Soit on estime que l'Internet change tellement de choses qu'il ouvre une façon toute nouvelle de faire de la politique, et rend donc dépassées les méthodes traditionnelles, soit on se moque des « révolutions Twitter » et on affirme que le pouvoir se prend dans la rue, comme avant. La vérité est évidemment plus complexe : l'arrivée de l'Internet n'a pas supprimé les lois de la politique, les questions posées aux militants et aux révolutionnaires restent les mêmes, ainsi que les problèmes auxquels ils et elles font face. Mais l'Internet n'est pas non plus un épiphénomène : comme d'autres techniques avant lui (l'imprimerie est l'exemple canonique, d'ailleurs analysé de façon originale par l'auteure), l'Internet a changé les moyens dont les gens disposent, a créé de nouvelles affordances (là, je ne critiquerai pas la traduction : il n'y a pas de bon terme en français), c'est-à-dire de nouvelles potentialités, des encouragements à aller dans de nouvelles directions. Sur la question récurrente de la neutralité de la technique, Zeynep Tufekci cite à juste titre la citation classique de Melvin Kranzberg : « La technologie n'est ni bonne, ni mauvaise ; et n'est pas neutre non plus. »

Une des raisons pour lesquelles bien des discours sur les mouvements politiques utilisant l'Internet sont très unilatéraux est que beaucoup de leurs auteurs sont des férus de technique qui ne connaissent pas grand'chose à la politique, et qui découvrent comme s'ils étaient les premiers à militer, ou bien ils sont des connaisseurs de la politique, mais complètement ignorants de la technique, dont ils font un tout, animé d'une volonté propre (les fameux « algorithmes »), et pas des outils que les gens vont utiliser. L'auteure, au contraire, informaticienne, puis chercheuse en sciences politiques, connait bien les deux aspects. Elle a étudié en profondeur de nombreux mouvements, les zapatistes au Mexique, Occupy Wall Street, l'occupation du parc Gezi, Black Lives Matter, les révolutions tunisienne et égyptienne, en étant souvent sur le terrain, à respirer les gaz lacrymogènes. (Les gilets jaunes n'y sont pas, bien que ce mouvement mériterait certainement d'être étudié dans son rapport à Facebook, mais le livre a été publié avant.) Et elle analyse le rôle de l'Internet, en chercheuse qui le connait bien, en voit les forces et les limites.

En contraste, elle étudie également le mouvement des droits civiques aux États-Unis. Voici un mouvement de très grande importance, qui a tout fait sans disposer de l'Internet. Alors qu'aujourd'hui, deux ou trois messages sur Facebook peuvent être le point de départ d'une manifestation très importante, et très rapidement prête, le mouvement des droits civiques a dû ramer pendant de nombreux mois pour, par exemple, organiser sa grande manifestation à Washington. L'auteure ne dit pas que c'était mieux à l'époque ou mieux aujourd'hui : elle insiste plutôt sur les permanences de l'action politique. Mais elle note aussi les différences : si l'organisation était bien plus laborieuse à l'époque (pas question de coordonner les aspects matériels avec une feuille de calcul mise en ligne et partagée), cela avait également des avantages. Les militants apprenaient à se connaitre, à se faire confiance, même des activités a priori sans intérêt politique, comme l'organisation pratique des voyages pour aller sur le lieu de la manifestation, avaient l'avantage de créer des liens, qui allaient permettre au mouvement de rester solide dans les tempêtes, face à la répression, et surtout face aux choix tactiques et stratégiques nécessaires lorsque la situation évolue.

Au contraire, l'Internet permet de se passer de cette organisation, au moins au début. Un individu seul peut se créer son blog et s'exprimer là où, auparavant, il aurait dû mendier un espace d'expression aux médias officiels, ou bien rejoindre un parti ou un mouvement critique, pour pouvoir faire relayer ses idées. C'est un énorme avantage et un des grands succès de l'Internet. Mais cela entraine de nouveaux risques, comme le fait qu'on n'a plus besoin de supporter les difficultés du travail collectif, ce qui peut rendre plus compliquée la traduction des idées en actions qui changent les choses.

Parmi les affordances de l'Internet, il y a le fait que beaucoup de choses sont possibles sans organisation formelle. Des mouvements très forts (comme celui du parc Gezi) ont été possibles sans qu'un parti traditionnel ne les structure et ne les dirige. Mais, bien sûr, cet avantage a aussi une face négative : puisque la nécessité d'une organisation n'est pas évidente, on peut se dire qu'on peut s'en passer. Au début, ça se passe effectivement bien, sans les lourdeurs bureaucratiques exaspérantes. Mais, ensuite, les problèmes surgissent : le pouvoir en place fait des ouvertures. Comment y répondre ? Ou bien il change de tactique, et le mouvement doit s'adapter. Et, là, l'absence d'un mécanisme de prise de décision commun se fait sentir, et beaucoup de mouvements s'affaiblissent alors, permettant à la répression de disperser ce qui reste. J'avais été frappé, sur les ronds-points, par la fréquence du discours « ah non, surtout pas de partis, surtout pas de syndicats, surtout pas d'organisations et de porte-paroles », chez des gilets jaunes qui n'avaient sans doute pas étudié les théoriciens de l'anarchisme. Mais c'est que le débat est aussi ancien que la politique. L'Internet le met en évidence, en rendant possible des fonctionnements moins centralisés, mais il ne l'a pas créé.

Léger reproche à l'auteure : elle ne discute pas ce qui pourrait arriver avec d'autres outils que les gros réseaux centralisés étatsuniens comme Facebook ou Twitter. Il est vrai qu'on manque encore d'exemples détaillés à utiliser, il n'y a pas encore eu de révolution déclenchée sur le fédivers ou via Matrix.

Je n'ai donné qu'une idée très limitée de ce livre. Il est très riche, très nuancé, l'auteure a vraiment tenu à étudier tout en détail, et aucun résumé ne peut donc suffire. En conclusion, un livre que je recommande à toutes celles et tous ceux qui veulent changer le monde et se demandent comment faire. Il n'est ni optimiste, ni pessimiste sur le rôle de l'Internet dans les révolutions : « ni rire, ni pleurer, mais comprendre » (Spinoza, il semble).

Autre(s) article(s) en français sur ce livre :

• Celui de Matthieu Demory.

Petit avertissement : j'ai reçu un exemplaire gratuit de ce livre.

Excellent (vraiment excellent) livre d'histoire de la France, vu sous un angle différent de l'habituel : moins de rois et de princes, et d'avantage de gens du peuple.

Le titre fait référence à un livre très connu d'histoire des États-Unis. L'idée de départ est la même : les livres d'histoire traditionnels privilégient les gens importants, les « premiers de cordée », comme dirait Macron, et oublient les « 99 % ». On voit ainsi des historiens écrire sans sourciller que « Louis XIV a construit le château de Versailles », sans tenir compte des ouvriers.

Si les historiens tendent à privilégier ces « gens d'en haut », ça n'est pas forcément par conviction politique aristocratique, ou par mépris du peuple. C'est aussi parce que c'est plus facile. On dispose de tas de textes sur Louis XIV, de sa main, de celle de ses courtisans, de celle de ses ennemis, tout est bien documenté. Les nobles et les bourgeois de l'époque ont aussi parlé de leur classe sociale respective. Mais que sait-on des travailleurs de base ? Ils ne savaient en général pas écrire et, même quand c'était le cas, leurs textes ont rarement été gardés. On a des traces matérielles, mais peu de choses sur ce qu'ils ressentaient, leurs opinions, la vie quotidienne.

Et l'auteur ne résout pas complètement ce problème : il reconnait dès le début que l'historien manque de matériaux sur lesquels s'appuyer pour une histoire des classes populaires. Son livre est donc plutôt une histoire de France, en gardant sans cesse comme perspective que la France ne se limitait pas au roi et à la cour.

Le plan est classique, chronologique, de la guerre de Cent Ans à nos jours, soit 800 pages bien tassées. La question des débuts de la France est étudiée en détail ; à partir de quand les gens se disaient-ils français ? L'histoire traditionnelle est souvent anachronique, en qualifiant par exemple Jeanne d'Arc de patriote française, notion qui lui était bien étrangère. Les questions religieuses occupent ensuite beaucoup de place : au Moyen-Âge, tout conflit interne était présenté comme religieux, même quand ses causes profondes étaient politiques. L'auteur explique d'ailleurs que les guerres de religion ne méritaient que partiellement leur nom, et qu'elles avaient des racines qui n'étaient pas toujours religieuses.

L'esclavage et le colonialisme sont largement traités. Ils sont parfois absents des « histoires de la France », soit parce que ce n'était pas très glorieux, soit parce que les pays qui en furent victimes n'étaient pas la France. Ici, au contraire, ces questions sont vues en détail. Ces peuples n'avaient pas voulu faire partie de l'histoire de France, mais ils en sont devenus une composante importante. Comme l'accent du livre est mis sur le peuple, pas seulement comme sujet mais aussi comme acteur, les révoltes d'esclaves et les luttes anti-colonialistes jouent un rôle important.

Comme le peuple s'obstine à ne pas comprendre que les dirigeants veulent son bien, et qu'il se révolte de temps en temps, et de diverses manières, l'État développe ses moyens de contrôle. Noiriel explique ainsi le développement successif de la notion d'identité (comme dans « carte d'identité »), et le contrôle qu'elle permet.

La révolution industrielle fait franchir une nouvelle étape à ces processus, avec la création du prolétariat de masse, et la prise de conscience qui a suivi, permettant les nombreuses révoltes du 19e siècle. Mais l'articulation entre l'appartenance de classe et les opinions politiques est restée compliquée. Le parti communiste, par exemple, n'a jamais hésité à jouer la carte de la culpabilisation, écartant toutes les critiques de sa politique d'un « nous sommes un parti ouvrier, donc nous avons forcément raison ». Lorsque l'opposant était en effet né dans une famille bourgeoise, l'argument avait du poids. Comme le note Noiriel, « la culpabilité est mauvaise conseillère ». (Et elle continue à l'être.)

Par la suite, les changements dans l'organisation de la société, et une offensive idéologique importante, ont remis en cause cette conscience de classe. Aujourd'hui, l'idéologie dominante est identitaire et racialiste, faisant croire au prolétaire que sa nationalité, sa couleur de peau ou sa religion sont les choses importantes, niant les classes sociales. Cette méthode est efficace pour limiter le risque de révolte contre les dominants. Mais l'histoire n'est jamais terminée et les choses vont continuer à changer, peut-être en mieux, peut-être pas.

Je recommande fortement la lecture de ce livre, si vous voulez une histoire de France très complète, très documentée, et qui ne cherche pas à faire des raccourcis au milieu des chemins souvent complexes que cette histoire a empruntés.

Tout le monde connait bien sûr Edward Snowden, le héros grâce à qui les citoyens ordinaires ont des informations précises et étayées sur la surveillance de masse qu'exercent les États sur les citoyens. S'il a fait plusieurs interventions à distance, depuis son exil, il n'avait pas encore raconté de manière détaillée son parcours. C'est ce qu'il fait dans ce livre.

(J'ai lu ce livre en anglais car le titre de la traduction française m'avait semblé bizarre. Permanent record, c'est « Dossier qui vous suivra toute la vie » ou « Fiché pour toujours », certainement pas « Mémoires vives ».)

Je n'étais pas sûr de l'intérêt de ce livre : on peut être un héros sans savoir écrire, un informaticien compétent sans capacités pédagogiques, un lanceur d'alerte sans avoir guère de connaissances politiques. Mais j'ai été agréablement surpris : le livre est très bien écrit (Snowden remercie à la fin ceux qui ont lui ont appris à faire un livre intéressant), souvent drôle, malgré la gravité des faits, et Snowden explique très bien les questions informatiques comme le fonctionnement des services de surveillance étatiques.

Une partie du livre, surtout au début, est plutôt personnelle : enfance, jeunesse, débuts dans l'informatique. L'auteur décrit très bien la passion qu'est l'informatique, comment le hacker veut savoir comment ça marche, comment les erreurs aident à progresser. Tout informaticien se reconnaitra sans peine. (Si vous croisez quelqu'un qui dit « je ne comprends pas comment on peut être passionné par l'informatique », faites-lui lire ce livre.) Après commence la vie professionnelle, et Snowden démonte très bien le mécanisme pervers de recrutement des agences gouvernementales étatsuniennes : plutôt que d'avoir des fonctionnaires, on fait appel à des sous-traitants, qui facturent cher et font vivre un certain nombre de boites parasites, qui se contentent de mettre en rapport les informaticiens et l'État. Toute personne qui a travaillé dans une SSII reconnaitra ce monde, où on n'est jamais dans l'entreprise qui vous a embauché, et où on est parfois sous-traitant du sous-traitant. La majorité des gens qui conçoivent et font fonctionner le système de surveillance de masse sont des employés du privé…

Les amateurs de récits d'espionnage, même s'il n'y a évidemment aucun secret militaire dans ce livre, seront ravis des explications sur le fonctionnement interne des services de sécurité étatsuniens, monde très opaque et très complexe, qui est ici bien décortiqué.

La divergence entre Snowden et ses collègues a lieu après : la plupart des passionnés d'informatique accepteront sans problème de travailler pour Palantir, pour Facebook, pour Criteo ou pour la NSA. Ils ne se poseront pas de questions, se disant « de toute façon, c'est comme ça, on ne peut rien y faire » ou bien « la technique est neutre, je ne suis pas responsable de ce que les chefs font de mes programmes ». C'est là que Snowden suit une autre voie : il s'interroge, il se pose des questions, il lit, au grand étonnement de ses collègues de la CIA ou de la NSA, le texte de la constitution, et il finit par décider d'alerter le public sur le système d'espionnage qui avait été mis en place de manière complètement illégale (et qui l'est toujours).

Les amateurs de sécurité informatique pratique liront avec intérêt les réflexions d'Edward Snowden qui, sans pouvoir en parler avec personne, a dû concevoir un mécanisme pour sortir des locaux de la NSA, les innombrables documents qui ont fait les « révélations Snowden ». Je vous divulgue tout de suite un truc : les cartes SD (surtout microSD) sont bien plus discrètes que les clés USB, ne font pas sonner les détecteurs de métaux, et peuvent être avalées plus rapidement en cas d'urgence. Pendant qu'on en est aux conseils techniques, Snowden insiste sur l'importance du chiffrement, la principale protection technique sérieuse (mais pas à 100 %) contre la surveillance. Un des intérêts de ce livre est de revenir sur des points sur lesquels les discussions suite aux révélations de Snowden avaient parfois été brouillées par du FUD, où des gens plus ou moins bien intentionnés avaient essayé de brouiller le message en disant « mais, le chiffrement, ça ne protège pas vraiment », ou bien « mais non, PRISM, ce n'est pas une récolte directement auprès des GAFA ». Snowden explique clairement les programmes de la NSA, aux noms pittoresques, et les mécanismes de protection existants, au lieu de pinailler pour le plaisir de pinailler comme cela se fait parfois en matière de sécurité informatique.

Puis, une fois les documents sortis, c'est le départ pour Hong Kong et l'attente dans la chambre d'hôtel avant la rencontre avec Glen Greenwald et Laura Poitras, qui a filmé ces journées pour son remarquable documentaire « Citizenfour » (si vous ne l'avez pas vu, arrêtez de lire ce blog et allez voir ce documentaire).

Le livre n'a pas vraiment de conclusion : c'est à nous désormais de l'écrire.

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.

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 :

• Une mise en œuvre du fédivers, Pleroma.
• L'excellent serveur de suivi des journaux Certificate Transparency (RFC 6962) CertStream (journaux qu'il est indispensable de surveiller automatiquement pour détecter des faux certificats utilisant votre nom).
• Le système Nerves de développement de code embarqué.
• Toujours pour l'IoT, il y a Astarte.
• Le système de communication audio/vidéo Discord (non libre, contrairement aux trois précédents) l'utilise. Ils publient d'intéressants articles sur les questions de passage à l'échelle, comme celui-ci ou bien cet autre, qui mentionne les limites d'Elixir.
• Le système de curation de contenu éducatif Moodle.
• Et le futur système de coordination d'actions Mobilizon sera en Elixir.

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

• La bibliothèques standard est documentée en https://hexdocs.pm/elixir/, une adresse à retenir.
• Sur la notion de superviseur, cruciale en Elixir pour écrire des serveurs non-expérimentaux, voir la documentation officielle. (Mais on les utilise typiquement via l'orchestrateur OTP.)
• Pour créer un serveur HTTP supervisé, et avec l'aide de Mix, Cowboy et Plug, voir cet article.
• Une bonne introduction à Plug.
• Pour essayer en pratique un langage de programmation, on utilise souvent l'API CRUD TODO Backend, qui permet de gérer une liste de choses à faire (ajouter une chose à faire, la voir, la modifier, avoir la liste, la détruire). Parmi les innombrables réalisations de cette API qu'on trouve sur leur site, il y en a trois en Elixir, une avec Phoenix, une avec Plug, et une avec un autre cadriciel, Maru.
• Une bonne ressource pour les débutants, le site Elixir School.
• J'avais mentionné l'atelier de Nicolas Savois au BreizhCamp, les documents de cet atelier sont en ligne.

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.

Ah, et le livre est disponible gratuitement en EPUB et PDF.

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). Et le harcèlement n'est pas uniquement le fait de déséquilibrés isolés, mais il est fréquemment 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.

Quelques lectures en plus :

• Le site Web d'accompagnement du livre,
• Le moment Twitter des gens qui parlent du livre,
• Sur le site de l'éditeur,
• L'avis de Marie Rachedi,
• Le récit par l'auteure du processus d'écriture.

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.

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. »

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.