Mon blog

Aujourd'hui, les questions d'identités numériques sont partout sur Internet. Est-il légal de donner un nom qui n'est pas celui de l'état civil lorsqu'on remplit un de ces milliers de formulaires qui existent sur le Web ? Est-ce grave que les contributeurs de Wikipédia soient identifiés par des « pseudos » comme ©éréales Kille® ou Anthere ? Est-ce normal de devoir se souvenir de dizaines de mots de passe différents ? Pourquoi ne pas utiliser son compte Google pour tout, de ma banque en ligne aux blogs où je mets des commentaires ? Si mon avatar dans Second Life tue quelqu'un, suis-je responsable ? Toutes ces questions sont relatives au concept d'identité numérique. La notion d'identité paraissait simple dans le monde physique où beaucoup de gens (à tort selon Olivier Iteanu) l'assimilaient à la seule identité délivrée par l'État. Comment faire désormais sur les réseaux ?

Le livre répond réellement à toutes ces questions et à bien d'autres. Olivier Iteanu est un avocat, expert reconnu des aspects juridiques des NTIC et défenseur des droits des citoyens face à des dangers comme l'utilisation abusive de leurs données personnelles ou comme leur traçage excessif.

Ce livre est court et n'épuise pas la question, qui est très vaste. Mais il éclaire bien des aspects de celle-ci. Mon chapitre préféré est le 4, sur le « pseudo », où Iteanu défend l'idée que le pseudo est une identité valable, reconnue mais soumise à certaines limites (ne pas choisir un pseudo dans le but de tromper, se méfier du droit des marques).

Mais il y a aussi l'intéressante introduction du livre, sur le manque d'un service d'identité générique sur Internet, manque probablement dû (c'est une des hypothèses évoquées) au choix de la simplicité. Des projets comme OpenID tentent d'apporter une partie de la solution de ce manque.

Parmi les autres chapitres utiles, le chapitre 2 est une explication et une défense de l'anonymat, dont Iteanu pense que, bien que légal actuellement, il pourrait être mieux reconnu par la loi. Le chapitre 9 est consacré aux menaces liées à l'usurpation d'identité comme le hameçonnage et le chapitre 10 à la redoutable efficacité du moteur de recherche Google, « plus fort que le casier judiciaire » car il n'oublie rien et n'est soumis à aucun contrôle.

La conclusion du livre est un appel à maîtriser nos identités numériques, plutôt que des les voir créées, copiées et volées par des forces peu sympathiques. Cela implique, dit Iteanu, un vrai droit à l'anonymat, une meilleure définition juridique de l'identité et le déploiement de techniques d'identité décentralisées permettant à chacun de créer et de contrôler ses identités sur le réseau.

Un peu de publicité personnelle pour finir : j'ai fait un article sur OpenID à JRES, article qui place cette technique au milieu des grandes manœuvres sur l'identité numérique. OpenID pourrait être une des briques permettant de construire le système d'identité distribué dont parle Iteanu.

Ce livre est un recueil d'articles produits par différents acteurs de la gouvernance Internet un peu partout dans le monde. On n'y trouvera aucune unité, chacun a juste dévelopé un thème qui lui tenait à cœur (comme Latid Latif expliquant qu'IPv6 va sauver le monde). Il n'y a pas non plus grande originalité dans un livre où la plupart des auteurs avaient déjà eu de nombreuses occasions de faire connaitre leur point de vue.

Les articles sont courts et il y a peu de questions originales traitées. Le spectre des idées politiques est large, personne n'a été oublié, ce qui fait qu'un article d'Anriette Esterhuysen de l'APC, qui appelle à l'intervention publique pour s'assurer que tous les citoyens sont connectés, et qui met en garde contre les extensions des privilèges des titulaires de propriété intellectuelle est immédiatement suivi d'un article de George Sadowsky, de l'ISOC, qui explique que seul le Dieu Marché doit être autorisé à intervenir et qu'il est crucial de maintenir et d'étendre les droits déjà exorbitants dont jouissent les titulaires de propriété intellectuelle.

La plupart des articles n'apprendront rien à celui qui a déjà un peu étudié la gouvernance Internet, d'autant plus que la langue de bois est fort active (articles de Vint Cerf ou de Hamadoun Touré). Seuls quelques auteurs se sont aventurés hors de leur domaine habituel (comme Louis Pouzin qui écrit sur les identités numériques).

Depuis plusieurs ouvrages (dont le plus connu est « Dans les beaux quartiers »), Michel Pinçon et Monique Pinçon-Charlot étudient, en sociologues, la grande bourgeoisie. Des tas d'études sociologiques ont été faites sur les banlieues difficiles, sur les ouvriers, sur les chômeurs mais très peu sur la grande bourgeoisie, peut-être par acceptation aveugle du tabou comme quoi les classes sociales n'existeraient pas. Ce dernier ouvrage (car les auteurs prennent leur retraite) discute de l'occupation de l'espace et de sa défense.

Leurs sujets d'étude ne sont pas forcément faciles. Certes, les risques physiques sont plus faibles que lorsqu'on va étudier les délinquants de banlieue. Et on mange mieux lorsqu'on enquête au Jockey Club. Mais cela ne rend pas forcément l'enquête plus facile, face à des interlocuteurs qui, eux aussi, ont lu Bourdieu, et sont rompus à l'art difficile de se montrer sous son meilleur jour, tout le temps.

Dans ce livre, les deux auteurs s'attaquent plus particulièrement à la gestion de l'espace par la grande bourgeoisie. Si on reproche aux immigrés de vivre dans des ghettos, que dire de cette classe dont l'étude du Bottin mondain montre que ses membres ne vivent que dans trois arrondissements de Paris (7, 8 et 16), sans compter évidemment le vingt-et-unième ? À les fois très cosmopolites (le monde est leur terrain de jeu depuis toujours) et très attachés à leurs territoires, les sujets de l'étude mettent en œuvre tous les moyens à leur disposition pour rester entre eux et ne pas permettre de mélanges avec d'autres classes sociales. Leur dévouement militant, lorsque ce territoire est menacé, n'a rien à envier à la rage du caïd de banlieue s'opposant au passage dans « sa » cité d'autres exclus venus d'une cité différente...

Le seul jeu du marché, et les prix de l'immobilier qu'il entraine, sont déjà un bon moyen de limiter la mixité sociale. Encore faut-il veiller à ce que les politiques publiques ne contrarient pas trop ce marché. C'est alors que rentre en jeu le travail d'influence, rarement public, pour s'assurer qu'aucune loi n'aura de conséquences trop graves. C'est ainsi que la loi SRU a certes été votée (elle impose notamment un minimum de 20 % de logements sociaux par commune) mais est systématiquement violée, les sanctions étant bien trop faibles (Neuilly n'a ainsi que 2,6 % de logements sociaux).

Cette occupation de l'espace est particulièrement nette dans le cas du Bois de Boulogne, qui fait l'objet d'un article étonnant du livre. Une partie de cet espace public est en effet réservée depuis des dizaines d'années à un petit nombre de clubs ultra-fermés, où on n'entre que par cooptation, comme le Cercle du Bois de Boulogne ou le Polo de Paris.

Comment se pratique cette défense du territoire ? Pas de manifestations dans la rue, pas de voitures brûlées, même pas de complot international où de mystérieux financiers apatrides tireraient les ficelles. Non, c'est beaucoup plus simple, montrent nos deux sociologues. Ce monde est irrigué par un intense réseau de sociabilité. On dine ensemble à l'Interallié ou lors d'une réception chez l'un ou l'autre, on prend des vacances dans les mêmes palaces, à Gstaad ou à Marrakech et les problèmes sont réglés entre gens du même monde, discrètement. Il y a certes de nombreux conflits internes (l'associations de grands bourgeois qui s'oppose à une autoroute urbaine peut compter dans ses membres des actionnaires de Renault ou de Vinci...) mais la plupart se règlent « entre soi ».

Bref, un livre qui donne envie d'être riche, pour pouvoir profiter d'une telle entraide, et de territoires protégés, défendus avec une bonne conscience en béton : les quartiers où ils vivent étant souvent historiquement importants, ils ne défendent pas leurs intérêts, non, ils protègent le patrimoine national...

Le moindre téléphone portable, aujourd'hui, beaucoup de sites Web (réservations de train ou d'avion), de nombreux autres logiciels, disposent de fonctions de calendrier. Les nombreuses bogues constatées dans ces logiciels montrent que des questions aussi simples que « Le 1er mars 2000 est-il un mardi ou un mercredi ? » ne sont pas si triviales qu'elle en ont l'air. Ce livre est l'ouvrage de référence sur les calculs calendaires, pour de nombreux calendriers existants ou disparus, avec tous les détails nécessaires pour programmer soi-même ces calculs.

Les auteurs sont deux experts, Nachum Dershowitz a écrit de nombreux articles sur le sujet et Edward Reingold est le mainteneur du paquetage calendar d'Emacs. L'ampleur de l'érudition nécessaire pour couvrir, non seulement le traditionnel calendrier grégorien mais aussi les calendriers chinois, hindou, musulman, maya et bien d'autres, est impressionnante. Les amateurs d'anecdotes seront ravis. Par exemple, ils apprendront que les chinois incrémentent l'âge des enfants, non pas à leur anniversaire, mais au nouvel an. De plus, un enfant a un an à sa naissance. S'il nait la veille du nouvel an chinois, il aura deux ans au bout de quelques jours de vie. Autre exemple amusant, dans le calendrier maya Tzolkin, les numéros des jours et ceux des « mois » varient ensemble, mais sur des cycles de taille différentes. Ainsi, le 1 Imix est suivi du 2 Ik, lui-même suivi du 3 Akbal, etc jusqu'au 13 Ben (le cycle des jours a une longueur 13) qui est suivi du 1 Ix...

Mais la variété des calendriers permet aussi de philosopher sur le nombre de solutions possibles à un problème donné. Vivant sur la même Terre, avec les mêmes alternances de jour et de nuit et le même parcours du Soleil et de la Lune, les différentes civilisations ont développé des calendriers très différents. Il y en a deux grandes familles : les calendriers arithmétiques et les calendriers astronomiques. Les premiers obéissent à des règles arithmétiques simples (les seules opérations nécessaires pour les mettre en œuvre sont les quatre opérations de base, plus la fonction partie entière) et sont donc les plus simples à programmer. Mais, ignorant des cycles astronomiques et utilisant leurs propres cycles, incommensurables avec ceux des astres, il sont voués à un décalage grandissant avec le temps. C'est ainsi que notre calendrier grégorien, archétype des calendriers arithmétiques, a remplacé le calendrier julien, devenu trop décalé. Et il devra à son tour être réformé ou remplacé.

Les européens ne sont pas les seuls à avoir conçu un calendrier arithmétiques. Les Mayas ou les musulmans l'ont également fait. Mais d'autres peuples ont choisi une voie différente, notamment les chinois avec un calendrier astronomique, c'est-à-dire où le passage d'une période à une autre (par exemple d'un mois au suivant) dépend d'un événement astronomique (la nouvelle Lune dans le cas chinois). Ainsi, le calendrier est toujours synchronisé avec les astres. En revanche, si on veut calculer des dates futures, pour lesquelles il n'est pas encore possible de faire des observations astronomiques, les calculs sont nettement plus compliqués (rien n'est simple en astronomie, même la durée du jour diminue avec le temps). (Les hindous ont également un calendrier astronomique.)

Il existe aussi des calendriers qui ont emprunté aux deux systèmes. Par exemple, le calendrier civil musulman est arithmétique, mais les dates des événements importants comme le début du Ramadan dépendent de phénomènes astronomiques. Les chrétiens ont un système similaire pour déterminer Pâques (mais pas Noël, qui survient à date fixe). De même, le calendrier révolutionnaire français est astronomique : la méthode pour déterminer les années bissextiles ne dépend pas d'un algorithme mais d'observations. On ne peut donc pas prévoir facilement si une année future sera bissextile ou pas. Une réforme tardive de ce calendrier introduisait un mécanisme algorithmique et le transformait donc en calendrier arithmétique (mais elle n'a pas eu le temps d'être déployée avant le coup d'État de Bonaparte).

Comme tous les bons geeks, les auteurs ont inventé leur propre calendrier, le « date fixe » (Rata Die), qui compte le nombre de jours depuis le début de l'ère commune. La préface nous apprend ainsi que le livre a été terminé le 730 120 en « date fixe ».

Les auteurs ne perdent pas de vue les implémentations pratiques. Leurs algorithmes sont décrits en langage mathématique, sous une forme qui permet une programmation assez directe dans un langage de programmation fonctionnel. C'est ce que j'ai fait pour une partie des calendriers, en Haskell. (La composition du livre, elle, a dû exiger une bonne compétence en LaTeX.) On notera que le livre est accompagné d'un CD d'une implémentation complète en Common Lisp (attention, elle n'est pas du tout sous une licence libre).

On notera que les erreurs dans la seconde édition, publiée en 2000, sont nombreuses et l'erratum, publié sur leur site, est un impressionnant document. (Une troisième édition a été publiée fin 2007 mais je ne l'ai pas lue, merci à Damien Wyart pour son information.)

Cet article a été terminé le 6 février 2008 du calendrier grégorien, le 733 078 en « date fixe », le 18 pluviôse an 216 de la Révolution française, le 28 Muharram 1429 du calendrier musulman, le 12.19.15.1.0 du long compte maya et le 78-24-12-30 du calendrier chinois.

Ce livre est la référence absolue pour la programmation réseau en C sur Unix. Trés détaillé, très concret, avec énormément de code source, il a formé beaucoup de programmeurs réseaux. (Il s'agit du volume 1, le volume 2 étant consacré à la communication entre processus.)

Hélas, il n'y aura plus de livre écrit par W. Richard Stevens, il est décédé en 1999. Mais ses épais ouvrages ont formé des milliers de programmeurs et d'administrateurs réseaux. La seconde édition d'Unix network programming, volume 1, ajoutait notamment la description détaillée de la programmation IPv6, Stevens étant un des auteurs de l'API (RFC 3493). (Le livre a été repris par deux autres auteurs, qui ont publié une troisième édition, que je n'ai pas lue, merci à Damien Wyart pour l'information.)

Unix network programming couvre en près de mille pages l'interface des prises, l'écriture de clients et de serveurs, l'utilisation intelligente d'UDP et de TCP, et d'innombrables services plus avancés comme l'utilisation des options IP. Rien à voir avec le cours de réseau universitaire classique, avec son obligatoire modèle en couches. Ici, tous les programmes ont été testés et le code source est distribué (voir adresse plus haut).

En vrai geek, Stevens a écrit son livre en troff, un art aujourd'hui bien perdu.

Sans doute la plupart des programmeurs n'ont pas besoin d'autant d'informations, il est même peut-être préférable qu'ils programment à niveau plus élevé. Mais celui ou celle qui veut approfondir tous les mystères de la programmation réseau aura toujours intérêt à se plonger dans ce livre.

Un livre à grand succès, que tout le monde cite, pas forcément correctement. Collapse (Effondrement, dans l'édition française) raconte le sort de plusieurs civilisations qui ont disparues ou quasiment disparues, parce qu'elles n'ont pas su réagir et qu'elles ont tenu à continuer dans une mauvaise voie.

Jared Diamond est un biogéographe très connu, déjà auteur d'autres livres largement diffusés. Collapse est un gros livre mais raconté avec tellement de verve et d'érudition qu'on ne voit pas le temps passer en le lisant. Plusieurs civilisations disparues sont successivement étudiées, des Vikings du Groenland aux Mayas d'Amérique Centrale en passant par l'île de Pâques. Sans oublier des civilisations qui se sont sorties de crises écologiques graves, comme les papous de Nouvelle-Guinée ou qui s'en tireront peut-être comme les États-Unis d'ajourd'hui (Diamond étudie en détail le Montana et, de manière plus rapide, la région de Los Angeles).

À chaque fois, l'auteur nous décrit une civilisation brillante, sûre d'elle, et qui fonce avec obstination vers l'abîme, situé en général juste après le moment de plus grand rayonnement.

Un des points importants de Diamond est que ces civilisations disparues n'étaient pas forcément plus stupides ou plus ignorantes que la nôtre. Les erreurs qu'ils ont commises, l'aveuglément dont ils faisaient preuve, étaient dus à des facteurs qui existent aussi dans nos civilisations modernes. Si nous avons des avantages sur eux (nous savons d'avantage de choses), nous avons aussi des faiblesses plus graves (Diamond rappelle que les habitants de l'île de Pâques ont réussi à anéantir leur forêt avec seulement des haches de pierre et s'inquiète de ce que nous pourrions « réussir » à faire avec nos outils modernes).

Beaucoup de compte-rendus de Collapse ont insisté sur le côté pittoresque et ridicule de certaines décisions qu'avaient prises nos prédécesseurs (comme les Vikings du Groenland s'obstinant à construire d'immenses églises, dans un pays où le bois est plus rare que l'or, ou encore refusant de manger du poisson, alors que leurs bateaux naviguaient dans des eaux parmi les plus poissonneuses du monde). Mais Diamond s'oppose tout à fait à cette vision simpliste et rassurante, qui nous permettrait à nous, occidentaux d'aujourd'hui, de nous moquer des sauvages stupides des siècles passés. Il affirme que nos décisions ou non-décisions d'aujourd'hui, par exemple en ce qui concerne la lutte contre le réchauffement planétaire, apparaitront tout aussi ridicules dans le futur. Et qu'aucun effondrement ne peut être imputé à une cause unique. Le fanatisme religieux des Vikings du Groenland a certainement joué un rôle dans leur disparition (par exemple, en leur faisant refuser d'apprendre quoi que ce soit des Inuits, dont les compétences étaient ignorées car ils étaient païens). Mais leur civilisation, rappelle Diamond, a duré plus longtemps que le peuplement anglo-saxon en Amérique du Nord. Et c'est peut-être justement ce fanatisme religieux qui les a aidé à tenir si longtemps.

Diamond passe donc du temps à étudier les facteurs qui peuvent aider à comprendre la disparition ou le maintien de certaines civilisations. Son propos est nettement volontariste, comme le résume le sous-titre du livre : les civilisations choisissent leur sort. Là encore, Diamond voit beaucoup de solutions possibles, qu'il organise en deux catégories. Les méthodes de bas en haut, comme l'extrême démocratie pratiquée par les papous, exaspérante pour un occidental, mais qui leur a permis de prendre les décisions radicales exigées par la déforestation de leur île. Et les méthodes de haut en bas comme celles, très autoritaires, utilisées par le shogun au Japon pour sauver les derniers arbres de l'archipel, avec succès.

Diamond mentionne notamment, parmi les facteurs aggravant, l'inégalité. Chez les papous, les « grands hommes » (des sortes de sages respectés) cultivent un lopin de terre identique à celui des autres. Ils comprennent bien que leur sort est lié au sort commun. Au contraire, dans des sociétés ultra-hiérarchisées comme celle des Vikings ou des Mayas, les chefs pouvaient développer l'illusion qu'ils échapperaient à l'effondrement final et n'avaient donc aucune motivation pour tenter d'arrêter la catastrophe.

Un long article du Monde Diplomatique en décembre 2007, s'attaque à ce livre en le présentant comme l'inspirateur de la politique écologique de Sarkozy. C'est mettre les choses à l'envers. Sarkozy cite Diamond (qu'il n'a peut-être jamais lu) parce que c'est un auteur à la mode et parce que tout homme politique français se doit d'avoir une vision planétaire et d'avoir lu de gros livres. Mais rien n'indique que Sarkozy, l'ami des milliardaires, soit prêt à prendre les mesures radicales que réclame Diamond, surtout si elles s'attaquent aux intérêts du patronat.

(Le même article accuse aussi Diamond d'être un partisan caché d'un génocide, simplement parce qu'il fait remarquer les risques de la surpopulation.)

Voici le premier livre chez O'Reilly à propos d'Unicode. C'est un gros pavé de 700 pages et il ne couvre pourtant pas tout.

Le monde des écritures humaines est très riche et très compliqué et donc, logiquement, Unicode est compliqué. La norme est bien écrite, certes, mais rien ne peut rendre simple une réalité aussi complexe. N'attendons donc pas de ce livre des miracles, il explique déjà très bien beaucoup de choses.

L'orientation générale est plutôt vers l'auteur de documents. Le programmeur sera frustré, seul un chapitre lui est consacré, et une bonne partie est occupée par des langages de balisage comme HTML, qui ne sont pas de la programmation.

En revanche, Jukka Korpela explique avec beaucoup de détails (chapitres 4 à 6) la structure de la norme Unicode, les différents termes utilisés par celle-ci, les encodages et les innombrables informations qu'on peut trouver dans la base de données Unicode. Plus original, on trouve un excellent chapitre 2 consacré aux techniques permettant de saisir des caractères Unicode. Bien qu'il soit nettement trop orienté Windows à mon goût, ce chapitre réussit très bien à décrire les différentes méthodes.

Pour renforcer le côté « livre conçu pour les auteurs de textes, pas pour les programmeurs », je signale l'excellent chapitre 8, sur les usages des caractères, où on apprend plein de choses, même sur l'humble signe +. Beaucoup de caractères ont en effet plusieurs usages (la lettre grecque oméga - U+03A9 ou Ω - sert également à noter l'ohm, l'astérisque des énumérations en anglais sert également aux programmeurs à noter la multiplication, etc).

Le chapitre 11, consacré à la programmation est, on l'a dit, un peu limité, et il vaut sans doute mieux (re)lire Unicode demystified, de Richard Gillam.

Le chapitre 10 (sur les protocoles Internet) couvre également le problème intéressant d'écrire des textes en Unicode pour les publier sur Internet. L'auteur fait justement remarquer que, si on écrit en Unicode (par exemple en UTF-8), on sera tenté d'utiliser beaucoup plus de caractères, peut-être au détriment de la lisibilité du texte par les destinataires. Si on a donc relativement peu de caractères non-latins, il suggère de taper le texte en ASCII ou en ISO 8859 et d'utiliser les échappements comme ا (alif, ا). Curieusement, c'est justement ce que fait aujourd'hui l'auteur de ce blog, qui, en raison de problèmes avec UTF-8 rédige en Latin-1 et met les caractères non-latins avec des entités numériques XML.

Le style est très bon et les explications claires. La qualité générale de ce livre est celle des autres publications de cet éditeur et ce livre est donc à recommander aux non-programmeurs qui veulent comprendre les détails d'Unicode.

La question de savoir qui doit diriger l'Internet n'a pas cessé de poser depuis que ce réseau de réseaux a cessé d'être un jouet ultra-subventionné, pour devenir un espace public, soumis à toutes les règles de la politique et du droit. Ce livre nous donne un point de vue très états-unien sur la question.

En effet, dans des discussions comme à l'ICANN ou bien à l'IGF, on parle le langage diplomatique. On ne dit pas franchement ce que l'on veut, encore moins ce que l'on fait. Dans ce livre, par contre, son éditeur, l'Institut Cato, un centre de réflexion sur la politique, très marqué à droite, l'Institut Cato, donc, ne prend pas de gants.

Ainsi, l'article de Christopher Cox, « Establishing global Internet freedom » est un point de vue impérialiste classique, appelant à établir les mêmes règles qu'aux États-Unis, partout dans le monde, par la force si nécessaire.

Tous les auteurs ne sont pas forcément sur la même longueur d'onde pour tout. Ainsi, le livre contient une discussion lancée par Jack Goldsmith, qui s'oppose fortement à ce qu'il nomme la « cyber-anarchie », c'est-à-dire l'idée comme qui l'Internet serait un espace radicalement nouveau, où les lois et autres règles humaines traditionnelles ne pourraient ou ne devraient pas s'appliquer. Goldsmith s'oppose vigoureusement à ce point de vue et estime au contraire qu'il n'y a pas de changement de fond dans la politique et le droit, malgré Internet.

Dans le même livre, David Post s'oppose à cette théorie. Post est un tenant de la thèse « exceptionnaliste » qui dit que l'Internet est un espace radicalement nouveau et qu'on ne peut pas espérer y faire appliquer la loi de la même façon.

Il est amusant de constater que certains problèmes juridiques posés par le caractère international d'Internet étaient déjà connue par les états-uniens longtemps avant que le réseau ne sorte de leur pays. En effet, dans ce pays fédéral, les états ont souvent des législations divergentes et cette divergence nourrit une vaste jurisprudence depuis longtemps. Les articles de Michael Geist et de Dan Burk expliquent en détail ce problème, pendant que celui de Bruce Kobayashi et Larry Ribstein défend fermement un point de vue ultra-libéral en affirmant que les lois de protection du consommateur (comme celles qui existent en Californie) ne doivent pas s'appliquer sur le réseau, de façon à laisser les entreprises s'installer dans les « paradis légaux » comme le Delaware et en tirer tous les bénéfices souhaités.

Un remarquable livre sur la bonne façon de présenter des données et des informations avec des images.

Les images étant simples à lire, on pense qu'elles sont simples à écrire. Mais c'est le contraire, pense Edward Tufte, grand gourou de la présentation graphique d'informations, spécialiste de signalétique, enseignant à l'Université. Son livre Visual Explanations est un recueil de différents articles sur la visualisation, magnifiquement présentés et illustrés. Certes, son ton est parfois inutilement cassant mais son érudition est fascinante.

Deux articles ont particulièrement retenu mon attention. Le premier, Visual and statistical thinking, porte sur deux événements à caractère scientifico-technique, et qui furent fortement commentés à leur époque. D'abord, l'épidémie de choléra de Londres en 1854 et la façon dont le « héros » de l'épidémie, le docteur Snow, a su présenter les données disponibles pour emporter la conviction des décideurs quant aux mesures à adopter. Tufte montre bien comment, à partir des mêmes données, d'autres présentations auraient pu donner une vision complètement différente de l'épidémie.

Ensuite, dans le même article, Tufte parle des jours qui ont précédé le lancement raté de la navette spatiale Challenger. Toutes les données étaient là mais plusieurs présentations aggravaient la confusion et empêchaient de voir le danger posé par la glace, qui finira par détruire l'engin. Plusieurs diagrammes successifs des différents lancements, certains issus des rapports envoyés à la NASA avant l'accident et d'autres conçus par Tufte et ses collaborateurs, illustrent la différence.

Le deuxième article, Parallelism, discute de la présentation rapprochée, dans le temps ou dans l'espace, de plusieurs phénomènes et de la façon dont, là encore, on peut obscurcir ou au contraire révéler un phénomène. Une photo de trois personnes est ainsi légendée par un texte décrivant deux personnes seulement. Deux des trois personnes étant des anthropologues de la ville, ils ont droit à un nom, le troisième étant un Indien Yanomani, il peut disparaitre sans dommage de la légende.

À noter que Tufte pratique ce qu'il prêche et que le livre est très bien présenté. Par exemple, les illustrations sont toujours sur la même page que le texte qui les analyse, même si cela a parfois nécessité de reproduire l'illustration à plusieurs reprises.

La place qu'occupe désormais Google dans l'utilisation du Web a de quoi inquiéter. Un quasi-monopole de la recherche sur le Web et surtout une « part d'esprit » (comme il y a des parts de marché) qui éclipse non seulement les autres outils de recherche mais également toutes les méthodes d'accès à l'information.

Combien d'utilisateurs, par exemple, tapent "Wikipédia" dans Google pour aller sur l'encyclopédie en ligne, au lieu d'utiliser son adresse, http://fr.wikipedia.org/, seul moyen fiable d'arriver sur l'encyclopédie et pas, par exemple, sur un site qui en parlerait ?

Malgré cette place prise par Google, on voit encore peu de livres qui analysent sérieusement ce phénomène. Ceux publiés en anglais parlent de l'entreprise Google, mais pas tellement du rôle que joue son principal outil, le moteur de recherche. Le livre de Barbara Cassin, dont le quatrième de couverture annonce « un essai polémique », semble donc intéressant.

Mais il ne tient pas forcément ses promesses : emportée par la polémique, l'auteure fait feu de tout bois contre Google. Rien n'est acceptable dans cette entreprise, surtout pas le fait qu'elle parle anglais (comme si un monopole d'une entreprise francophone aurait été plus acceptable). La polémique s'étend d'ailleurs, sans qu'on voit bien le rapport, à des entités dont le seul point commun avec Google est de concerner l'Internet, comme Wikipédia, pourtant organisation ouverte et publiant sous licence libre, à l'opposé du géant de la recherche, très fermé et défendant fermement sa propriété intellectuelle. (Pour des raisons que j'ignore, Eurid a également droit aux foudres de l'auteure, mais pas Verisign.)

Cela mène souvent à des critiques très injustes, par exemple contre les « conditions générales d'utilisation » de Google, qui disent en substance que Google n'est responsable de rien et ne garantit rien... comme 100 % de ces textes, français ou états-uniens, que peu de gens lisent avant de cliquer « J'accepte ».

Il y a peu de réelle analyse et il y a confusion de beaucoup de niveaux dans ce livre. Le ton est très pédant (peut-être pour montrer que, contrairement à ces sauvages d'états-uniens, en France, on est cultivés), avec citations de Platon, Kant, Spinoza et Hannah Arendt à toutes les pages. Le fait d'écrire les mots en anglais dès qu'ils concernent Google, alors qu'ils sont écrits en français dans d'autres contextes, est prodigieusement exaspérant.

Plus agaçant encore, les erreurs sont nombreuses, de http://fr.wikipedia.org/ qualifié de « Wikipédia France » alors qu'il s'agit du Wikipédia francophone (mais beaucoup de français partagent ce point de vue étroitement hexagonal) au fondateur de l'informatique, Alan Turing gratifié sur son nom d'un tréma allemand alors qu'il était anglais ! Sans compter la confusion entre « standard ouvert » et open source (voilà ce qui arrive lorsqu'on utilise des mots anglais).

Le passage du temps est impitoyable pour les livres publiés sur papier et l'auteure consacre de nombreuses pages au projet Quaero, disparu avant la publication de l'ouvrage.

La critique de Google reste nécessaire, ainsi que les réflexions pour mettre au point des alternatives mais ce livre ne fera guère avancer ce travail.

La fin du livre, avec un long plaidoyer pour un assouplissement des règles de propriété intellectuelle, pose heureusement mieux le problème. Veut-on diffuser la culture ou bien permettre aux éditeurs de s'enrichir ?

Il existe dédormais une pléthore de livres sur XSLT. Celui-ci est un des premiers mais n'a pas pris une ride. C'est aussi un des rares livres de qualité sur XSLT écrits en français.

Je l'ai trouvé très concret, très bien expliqué et contenant tout ce qui était nécessaire au programmeur XSLT, notamment une bonne introduction à XPath, technologie sur laquelle repose une bonne partie de XSLT.

Il couvre également les aspects délicats de XSLT, ceux qui déroutent apparemment beaucoup de programmeurs, comme le mécanisme d'évaluation des règles ou bien comme la gestion des espaces.

Une section finale explique les outils XSLT et j'y ai découvert comment naviguer dans un document XML avec xmllint :

% xmllint --shell mesurer-temps-execution.entry_xml 

(On peut naviguer avec des commandes Unix-like.)

/ > ls
?-n        1 entry
-a-        7 entry
/ > cd entry
entry > ls
ta-        1  
---        1 date
ta-        1  
---        1 update_date
ta-        1  
---       25 content
ta-        1  

(On peut utiliser les expressions XPath.)

(Troisième paragraphe.)

content >  cat p[3]
<p>Sur un système <wikipedia>Unix</wikipedia>, la manière la plus
...

(L'élement <date>.)

content >  cat /entry/date
 -------
<date>2006-09-18</date>

Il ne semble pas qu'il y aie eu de seconde édition (l'édition originale date de 2002). Si XSLT 2 est évidemment absent, ce n'est pas très gênant, vu le peu de mises en œuvre et d'utilisation de XSLT 2.

À noter que les exemples du livre sont en ligne.

Annie Chéneau-Loquay avait déjà dirigé « Enjeux des technologies de la communication en Afrique » et continue à rassembler les contributions des meilleurs spécialistes du développement des NTIC en Afrique, via le programme de recherche Africanti (auquel succède le programme Net Suds).

Les contributions rassemblées dans ce livre couvrent de très nombreux aspects des NTIC. Elles sont très détaillées, parfois touffues : voici un livre dont on ne dira pas qu'il se lit « comme un roman ». Mais certaines contributions sont fascinantes comme celle Camille Lancri sur la région de Sikasso au Mali ou celle de Caroline Dulau et Annie Chéneau-Loquay sur les commerçants de Kayes au Mali ou, moins exotique pour un français (encore que...), celle de Claire Scopsi qui a étudié le monde étonnant des cyberboutiques du quartier du Chateau Rouge à Paris.

Loin des grands discours comme ceux tenus dans les réunions de l'IGF ou de NEPAD, un ouvrage qui permet de mesurer le dynamisme des africains, les difficultés recontrées et les progrès réalisés.

Le livre semble aujourd'hui être épuisé chez l'éditeur mais peut être commandé à la MSHA. Sinon, il sera sans doute bientôt en ligne.

Il existe de très nombreux livres de programmation. Et de très nombreux livres sur les détails pratiques de tel ou tel langage ou bien de tel ou tel environnement de programmation. Mais ce livre est original : il présente plutôt l'essence de la programmation sur Unix, pas les détails des outils mais plutôt comment faire des programmes qui soient bien conformes à l'esprit Unix.

Pas besoin de présenter Eric Raymond. L'un des meilleurs auteurs sur Unix et la programmation explique ici les principales caractéristiques d'Unix, pourquoi les programmes Unix sont comme ils sont et pourquoi il faut continuer. Par exemple, qu'il vaut mieux faire des petits programmes (Rule of Modularity), connectés par des interfaces simples (et pouvant donc être composés, comme on compose des fonctions), plutôt que des monstres comme OpenOffice, ininstallables et inutilisables sur un vieux PC et qui, surtout, ne permettent pas facilement de coopérer avec d'autres programmes.

Commme toujours avec Raymond, il présente toutes ses règles et aphorismes comme exprimant un consensus, alors que certaines sont plutôt personnelles. Des dix-sept règles qu'il présente, certaines (comme la Rule of Modularity donnée plus haut ou bien la Rule of Silence, qui dit qu'un programme doit se taire, sauf s'il a quelque chose d'utile à dire) seront en effet approuvées par tous les Unixiens mais ce n'est pas le cas de toutes.

Raymond, après avoir exposés les dix-sept règles, donne ensuite un bon cours de génie logiciel, qui est utilisable dans bien d'autres environnements qu'Unix. Il couvre un très grand nombre de sujets passionnants comme la conception de mini-langages. De nombreuses études de cas ponctuent son exposé.

Il passe ensuite à la mise en œuvre : quel langage de programmation choisir, quel système de contrôle de versions, la documentation, etc.

En résumé, un excellent livre, qui devrait être lu par tous les programmeurs et chefs de projet. Cela leur serait bien plus utile que de passer du temps à faire des diagrammes avec le dernier outil graphique à la mode.

Il existe de nombreux livres sur les outils et les techniques de production de logiciels. Il y a beaucoup d'ouvrages sur la gestion de projets logiciels. Mais il n'y avait guère de texte s'attaquant à la gestion de projets de logiciel libre, qui est pourtant assez spécifique (moins de camemberts et de diagrammes que dans les projets commerciaux, mais davantage de communication et de textes).

Karl Fogel a déjà écrit un livre sur CVS et a été un des développeurs de CVS et de Subversion. Mais son mérite ici est autre : il essaie d'expliquer comment fonctionne un projet de logiciel libre, du point de vue technique bien sûr, mais aussi et surtout dans les aspects humains.

Les textes précédents sur cette question étaient soient des proclamations très biaisées (tout est super, tout le monde est heureux, la liberté, c'est formidable) soit des productions très partielles, comme le célèbre article d'Eric Raymond, The cathedral and the bazaar, qui a l'avantage d'avoir été l'un des tout premiers à expliquer comment sont produits les logiciels libres, mais dont le principal inconvénient était de ne traiter qu'un seul type d'organisation (le bazar), en oubliant que la principale caractéristiques des logiciels libres est justement leur variété, technique bien sûr, mais aussi organisationnelle. Karl Fogel n'échappe d'ailleurs pas toujours à ce travers (pour des raisons évidentes, la plupart des exemples concernent Subversion) mais au moins il le reconnait.

Le livre couvre donc :

• L'infrastructure technique du projet. Si les logiciels libres n'utilisent pas MS project, ils dépendent néanmoins de beaucoup d'outils comme le système de gestion de versions.
• L'organisation du projet, analysée par notre Montesquieu du logiciel libre. Le projet peut être démocratique (au sens athénien du terme, donc une démocratie réduite à une petite élite) ou bien géré par un dictateur. (C'est le terme qui est utilisé, par exemple pour Python. Loin des hypocrisies de la gestion des ressources humaines, le monde du logiciel libre aime bien appeler un chat un chat. Les administrateurs de Wikipédia ont le titre officiel de "bureaucrates".)
• La question toujours délicate de l'argent et du financement.
• La communication entre les développeurs, avec tous ses pièges, s'agissant d'organisations internationales, et où l'ultima ratio de la hiérarchie n'est pas toujours possible.
• La gestion du personnel, celle dont le célèbre Andy Tanenbaum prédisait, dans un débat mémorable en 1993 avec Linus Torvalds, qu'elle serait l'écueil sur lequel se briserait tout projet de logiciel libre.
• Les questions juridiques, licences, brevets, etc.

Sur tous ces points, Karl Fogel est un grand connaisseur et sait toujours expliquer clairement les enjeux et les bonnes approches.

Un livre dont le but affiché est de servir aux auteurs de logiciel libre mais qui peut être lu par toute personne qui s'intéresse à ces projets qui semblaient utopiques il y a encore quinze ans. Ceux qui se demandent "Comment est-ce que cela peut marcher ?" trouveront sans doute des éléments de réponse dans ce livre.

Le livre est intégralement enligne, en http://producingoss.com/.

Les logiciels développés par Mozilla, dont le plus connu est le navigateur Web Firefox, sont très répandus mais beaucoup de leurs utilisateurs ignorent qu'ils sont aussi des environnements de développement, des plate-formes pour réaliser des programmes. Ce livre explique comment.

Un des charmes de Firefox est la disponibilité d'un grnd nombre d'extensions : non seulement on peut changer l'apparence du navigateur, mais on peut aussi ajouter des boutons, des menus, avec du code derrière. Par exemple, pour lire des flux de syndication, j'utilise en général Sage. Pour tester des pages Web, Web developer. Pour éditer des textes via des formulaires Web (comme pour Wikipedia), j'utilise ViewSourceWith.

De telles extensions (qui peuvent être développées pour n'importe quel logiciel Mozilla, pas seulement pour Firefox) sont écrites avec un mélange de nombreuses technologies : XUL pour décrire l'interface, CSS pour la présentation, JavaScript pour le code lui-même, XPCOM pour l'intergiciel, la communication entre les composants de Mozilla, RDF pour la description des composants, etc.

Ces technologies sont plus ou moins simples d'accès, plus ou moins documentées et évoluent parfois rapidement. Un livre de synthèse n'est donc pas inutile et c'est l'ambition de ce livre.

En 450 pages, il n'y réussit pas entièrement : il faut dire que le sujet n'est pas facile. On trouve peu de documentations synthétiques en ligne. L'API est particulièrement peu documentée. Et la technologie change rapidement (la version 1.5 de Firefox vient de sortir). Comme le livre est publié sous une licence libre, il est donc prudent de se fier à la version en ligne, la version papier datant de 2002, une éternité pour Mozilla.

Le livre couvre donc successivement toutes les techniques mentionnées plus haut. Vu le nombre d'auteurs, je suppose que chaque chapitre a été écrit très indépendamment car il y a peu de vision globale, juste une succession de techniques, qui semblent parfois redondantes (Javascript et les gabarits XUL, par exemple). Certains domaines qui me semblent importants, comme "chrome", le registre interne des ressources (code, images, etc) sont à peine traitées.

Tout est bien écrit et bien expliqué, certes, mais, en refremant le livre, on se sent un peu dépassé par l'ampleur de la tâche et le foisonnement d'information. Il existe heureusement des logiciels pour automatiser une partie des tâches de création d'une application Mozilla (ils sont décrits dans l'annexe B) et on peut toujours étudier les applications existantes pour voir comment elles marchent.

Je n'ai pas encore essayé de créer une vraie application avec ce livre comme guide, je vous tiendrai au courant.

Il existe désormais trois langages courants pour écrire des schémas XML c'est-à-dire pour décrire les éléments autorisés ou interdits dans un document XML. La norme du W3C, souvent appelée abusivement "schéma" tout court (une erreur que ce livre commet aussi) est la plus connue.

La norme "W3C Schema" est très complexe : mais ce livre réussit à l'exposer de manière simple, en commençant par un schéma minimum, puis en le compliquant au fur et à mesure que l'on souhaite décrire d'autres propriétés du langage qu'on développe. Il y a un seul fil conducteur dans le livre pour tous les exemples (une bibliothèque, avec description des livres) et cela facilite la plongée progressive dans les arcanes de XSD (autre nom des "W3C Schema").

L'auteur expose donc les schémas plats (où tous les éléments sont au même niveau) et les schémas en poupée russe, où les élément sont emboîtés. Il s'attaque ensuite au deuxième volet de XSD, après la structure du document : les types de données. Il expose en grand détail comment utiliser les types prédéfinis puis comment créer les siens.

À ce stade, on peut écrire son schéma (et c'est ce que j'ai fait avec succès). Mais les points plus subtils de l'écriture de schémas font ensuite l'objet d'un chapitre chacun (la documentation, la création de schémas qui pourront facilement être étendus, les espaces de noms...)

Personnellement, mes seuls manques ont été un chapitre de présentation de certaines normes utilisant les W3C Schemas (ce sont souvent de grosses normes très complexes et un tour d'introduction serait le bienvenu) et un autre chapitre sur les outils existants (validateurs, éditeurs).

En résumé, voici un excellent livre, par un auteur très compétent, qui est également l'auteur du livre "concurrent" chez O'Reilly, sur RelaxNG.

Les blogs et la syndication étant actuellement deux des occupations les plus populaires sur le Web, il fallait donc un livre chez O'Reilly sur les formats de syndication : c'est chose faite.

Ce livre couvre les différents formats RSS et une version assez préliminaire du format Atom (qui vient d'être normalisé dans le RFC 4287). Le chapitre historique qui retrace l'histoire de la syndication et des guerres entre formats nommés RSS est d'ailleurs passionnant et éclaire bien des questions.

Il continue par un chapitre sur l'utilisation de la syndication (il cite de nombreux outils mais pas un de mes favoris, rss2email, qui permet de convertir un flux de syndication en liste de diffusion par courrier). Puis il décrit en détail les principaux formats de syndication, s'attardant sur les innombrables modules qui ont fait le succès de la version 1.0 de RSS (celle qui utilise RDF).

Les chapitres suivants sont plus techniques : analyse de flux de syndication depuis un programme (presque tous les exemples sont en Perl), avec discussion pour savoir si l'analyseur doit être strict ou bien laxiste, des considérations sur les flux réels rencontrés dans la nature et surtout un chapitre passionnant sur des utilisations « inhabituelles » de la syndication, essentiellement pour des tâches d'administration système ou bien pour exploiter des sources d'information qui ne sont pas syndicatées (par exemple Google, avec un programme de conversion de recherches Google en flux RSS).

Bref, un livre assez court, très bien fait, peu à jour pour tout ce qui concerne Atom mais qui est quand même une bonne introduction au monde merveilleux de la syndication.

Il existe désormais trois langages courants pour écrire des schémas XML c'est-à-dire pour décrire les éléments autorisés ou interdits dans un document XML. RelaxNG, le plus récent, est le moins connu des trois et méritait donc bien un livre chez O'Reilly, avec un faisan sur la couverture, pour gagner d'avantage de popularité.

Autrefois, les schémas XML ne pouvaient s'écrire qu'avec une DTD et c'est la seule solution décrite dans la norme XML. Les limitations des DTD ont mené à l'invention de nouveaux langages, le plus connu étant W3C Schema, aussi dit XSD.

XSD est très complexe, souffre d'une syntaxe XML verbeuse, et est en même temps limité dans les schémas qu'il permet de décrire. Bien qu'il bénéficie d'une présence supérieure dans les médias, il n'a pas été choisi pour certains gros projets (Docbook, OpenDocument, Atom, etc) qui ont préféré RelaxNG.

C'est un signe de la simplicité de RelaxNG que le fait que ce livre soit à la fois relativement mince et très complet : il est rare qu'un sujet en soit absent. L'annotation d'un schéma (par exemple pour le documenter ou pour y mettre des méta-données) fait ainsi l'objet d'un chapitre entier.

L'auteur, Eric van der Vlist, est également l'auteur du O'Reilly sur XSD, il connait donc bien les deux "concurrents", même si sa préférence pour RelaxNG ne fait guère de doute. Francophone, il est également un des piliers de la liste xml-fr, où il répond en général très rapidement aux questions.

Ce livre couvre donc l'essentiel de RelaxNG : ses principes (ne valider que la structure, pas le contenu des éléments, ne pas changer les valeurs des éléments), puis sa syntaxe (RelaxNG a deux syntaxes, une XML et une dite compacte, bien plus lisible).

Il explique ensuite comment contraindre les valeurs des éléments grâce aux bibliothèques de types (extérieures à RelaxNG proprement dit), puis explique en détail comment réaliser des schémas qui, au lieu d'être des blocs monolithiques, soient extensibles ou restrictibles facilement, de façon à ce que leurs utilisateurs puissent n'utiliser que ce qu'ils veulent.

Le livre se termine sur un remarquable chapitre sur le déterminisme dans les schémas et pourquoi RelaxNG ne l'impose pas.

Notez que le schéma des fichiers XML de ce blog est écrit en RelaxNG.

Aujourd'hui, on entend et on lit très souvent, comme si cela allait de soi, que l'interface d'un logiciel doit être graphique et, de préférence, WYSIWYG. Toute mise en doute de ce dogme ne peut être, semble t-il, que l'œuvre de dinosaures obtus, attachés aux incompréhensibles commandes d'Unix. C'est ce dogme que Neal Stephenson, le célèbre auteur de la trilogie "Cryptonomicon" a décidé d'ébranler.

Dans ce petit livre, le raisonnement de Stephenson est simple : la ligne de commande, contrairement à l'interface graphique, est un langage. Comme tout langage, elle prend du temps à être maitrisée. Mais, une fois que c'est fait, elle permet bien plus d'expressivité qu'une interface graphique, qui ne permet que de choisir parmi des options pré-définies.

Stephenson compare l'utilisateur de l'interface graphique à un singe qui ne sait pas parler, seulement montrer du doigt (ou de la souris) la banane qu'il veut, peut-être en ajoutant quelques grognements.

Stephenson ne se limite pas au sujet évoqué dans le titre : il analyse toute l'évolution de l'informatique depuis vingt ans, l'influence des feuilletons télé et de Disneyland sur la mentalité états-unienne, les voitures, et les épopées antiques comme Gilgamesh. Qui a dit que les informaticiens étaient incultes et ne philosophaient pas ?

Un livre original qui est plutôt orienté vers l'apprentissage de la programmation fonctionnelle que vers celui du langage Haskell.

Il n'est probablement pas indispensable de savoir déjà programmer et ce livre pourrait être utilisé comme support de cours. L'auteur commence par les concepts de base de la programmation fonctionnelle, et, pour une fois, les exemples ne sont pas tous les sempiternels exemples mathématiques à base de factorielle et de Fibonacci mais des exemples graphiques avec des images que l'on transforme (pour faciliter la mise en œuvre, une intéressante implémentation entièrement en art ASCII est présentée par la suite).

Il explique ensuite l'environnement Hugs, utilisé pour la pratique, puis expose les différents concepts utilisés : listes, fonctions comme objets de première classe (pouvant être passées en argument), application partielle et curryfication, introduction à la preuve de programmes, le système des classes, la programmation paresseuse...

Comme le livre vise à enseigner la programmation fonctionnelle, plus que le langage Haskell, d'importants pans de celui-ci ne sont pas traités du tout : les monades sont très vite expédiées, les enregistrements nommés pas mentionnés, l'inférence de types est complètement absente (et l'auteur déclare donc systématiquement ses types). Les questions pratiques comme le contenu du Prélude, les bibliothèques existantes ou les entrées/sorties sont très peu traitées. Le lecteur ne doit donc pas s'imaginer qu'il pourra programmer en Haskell immédiatement, ni lire le code de darcs immédiatement.