Un record d'affluence pour la fin du siècle Un historique approximatif des réunions de Paris.pm

Table des matières

• mercredi 1 novembre 2000 (précédent)
• mercredi 3 janvier 2001 (suivant)
• Tous les comptes-rendus

mercredi 29 novembre 2000

La voix du secrétaire (Jean)

• Yann, qui a mangé je ne sais plus quoi,
• Michael, le PHP-troyen, qui a mangé ??? et bu un Orangina,
• moi, avec du magret de canard et une Margarita (comme d'habitude),
• Erik (pas Eric Cholet, mais un autre Erik, ami de Kai, arrivé en avance par rapport à Kai), qui a mangé un Chicken Tavern,
• Artur, qui a bu une Grim,
• Stéphane, qui a mangé un pavé de rumsteack bleu,
• un américain originaire de San Diego,
• Kai, qui a demandé des moules marinières sans frites,
• Birgit (une amie de Kai), qui a mangé un hamburger,
• Claude (encore un ami de Kai), qui a mangé une salade de tomate et bu une blanche,
• Philippe, avec une andouillette, une Blanche, une Guinness et une Kilkenny (comme d'habitude),
• Emmanuel, qui a mangé un hamburger,
• Julien, qui a mangé des spaghetti carbonara et bu un Coca Cola,
• David, qui a mangé des moules au curry avec des frites, et bu de la Warsteiner,
• Guy Coslado, un lispien qui était trop loin pour que je reluque son assiette,
• Jacques Siboni, un autre lispien qui était encore plus loin,
• Jean-Louis, de Tangram, qui n'a rien mangé je crois,
• Briac, qui a mangé des moules marinières et bu une Guinness,
• Jean-Luc, encore un lispien.

Compte tenu du nombre de personnes, il y avait en moyenne trois fils de discussion à un instant donné. Comme le multithreading n'existait pas à l'époque de ma conception, cela veut dire que j'ai loupé les deux tiers de la réunion, et que le compte-rendu sera donc encore plus parcellaire que d'habitude. Nous avons parlé de Perl, d'Internet, et de sujets techniques ou pas, en nous étendant notamment sur les problèmes de statistiques.

Perl

• BooK signale qu'il programmait "proprement" [ si si, ça lui arrive en dehors de l'OPC ], c'est-à-dire en insérant une étiquette __END__ à la fin de ses programmes, puis en écrivant la doc au format POD, ce qui amène Kai à évoquer le module Pod::Usage. Ce module, appelé en complément de Getopt::Long, permet d'obtenir sans se fatiguer l'affichage du texte "usage" en utilisant l'option --help. Le seul défaut de ce module, c'est qu'il ne figure pas dans la distribution standard.
• Stéphane a lu le dernier numéro de The Perl Journal. Il évoque l'article sur le module Inline.pm. Ce module permet d'insérer du source C ou C++ dans un programme Perl. Auparavant, il y avait XS, qui était imbittable, et SWIG, qui était de la bidouille (à moins que ce soit l'inverse). À la lecture de l'article, le nouveau module Inline.pm semble très simple à mettre en oeuvre, et ne nécessite pas de connaissance particulière sur les internes de Perl. Cependant, Stéphane nous avertit qu'il n'a pas encore testé ce module, tout ce qu'il en connaît, c'est l'article de TPJ.
• Lorsque nous avons lu "Amelia", Stéphane et moi avons signalé à O'Reilly les erreurs que nous avons relevées. Vous allez peut-être me trouver excentrique, ou "spécial", mais quand je lis un livre, je le lis jusqu'au bout, y compris l'index alphabétique. C'est ainsi que j'ai découvert des trésors cachés dans l'index de The Art of Computer Programming (vol 1) et celui de Stanford Graphbase. Dans le cas d'Amelia, j'y ai découvert des erreurs. Les deux qui me reviennent à l'esprit sont :
  • à la lettre "G", il y a une entrée pour les modules traitant des fichiers GIF, et une autre pour les modules interfaçant Perl avec GIMP, mais ces deux entrées sont vides, elles n'indiquent aucun numéro de page,
  • il y a deux entrées pour $$, l'une étant accompagnée de l'alias $PID, l'autre de l'alias $PROCESS_ID ; le problème, c'est que la première donne la page 55, et la seconde, quelques lignes plus bas, indique la page 672.
  Stéphane, quant à lui, a détecté une incohérence dans cet index. Les variables spéciales de type scalaire, comme justement $PID, ou $a et $b (pour les tris) sont rassemblées au début de l'index, à cause du code ASCII du dollar. En revanche, les variables spéciales de type tableau, comme @ARGV ou @INC sont à l'emplacement indiqué par la lettre initiale ("A" ou "I" pour ces deux exemples).
  Cela dit, les erreurs que nous avons relevées ne doivent pas faire oublier qu'à côté de cela il y a de très nombreuses entrées utiles et appropriées, et qu'un tel index est, de loin, beaucoup mieux que pas d'index du tout. Stéphane me signale que la rédaction des index est un travail à temps plein chez O'Reilly.
• Philippe annonce un concours organisé par les Paris Perl Mongueurs. Le concours est ouvert (qu'il dit), mais le règlement, les modalités et les lots ne sont pas encore connus. Il y aura au moins un T-shirt Tangram à gagner (merci Jean-Louis). Je rappelle qu'il y a plusieurs mois, Philippe nous avait montré un dromadaire en latex, et qu'il voulait s'en débarasser. Donc, à mon avis, ce bibelot fera partie des récompenses. D'autre part, comme Philippe nous l'a raconté le mois dernier, son unité de bandes a rendu l'âme. J'émets donc la supposition [ ou la suggestion ] qu'il y aura également des bandes de sauvegarde à gagner !
• Jean-Louis est venu à la réunion, pas seulement pour donner un T-shirt Tangram, mais aussi pour donner des explications techniques sur Tangram. C'est un sujet trop vaste et trop technique pour que je puisse résumer ce qu'il a exposé, d'autant plus que j'ai écouté par intermittence, et que je discutais de tout autre chose avec les personnes à ma gauche (Claude, Emmanuel, Yann). Pour situer les idées, disons simplement que Tangram permet d'apporter de la persistence aux objets Perl. En d'autres termes, il s'agit d'une base de données orientée objet.
• Si Jean-Louis est venu nous rendre visite, c'est que, pendant la journée, il devait assurer des cours, et enseigner Perl, DBI et CGI en trois jours. Des mauvaises langues ont prétendu que l'exercice d'application de CGI consistait à afficher "404".
• Comme il y avait des nouveaux venus à la réunion, Emmanuel répête l'histoire de son prédécesseur, du message après sauvegarde qui contient la date sous la forme "19" . ([localtime]->[5]), et de la boîte aux lettres électronique redirigée vers la poubelle. Yann enchaîne sur le compte-rendu d'il y a un an. Dans ce compte-rendu, je prétendais avoir écrit un programme qui me calculait la date du premier mercredi du mois suivant, et je prétendais que le résultat pour décembre 1999 était "5 janvier 19100". J'avais pris soin d'ajouter "Farpaitement ! :-))", pour que le lecteur puisse comprendre que c'était ironique.

  Internet

• Une fois précédente, Emmanuel nous avait expliqué que là où il travaille, il y avait une webcam braquée en permanence sur son dos. Aujourd'hui, il ajoute que, la première fois qu'il est retourné chez ses parents après avoir commencé à travailler chez Acticiel, il avait trouvé plusieurs photos de lui en train de travailler. La situation a légèrement évolué. La webcam est toujours là, mais comme par hasard, "quelqu'un" l'a débranchée.
• Stéphane signale avoir lu dans Slashdot que l'auteur de ping venait de mourir dans un accident de la route. À propos de ping, Artur nous raconte qu'une fois, il avait lancé un ping vers une autre machine, et qu'il était passé à une autre tâche. Pendant ce temps-là, le ping a continué à émettre ses paquets de 58 octets. Quand Artur s'est aperçu que le ping tournait toujours, il avait envoyé 180 Mo !
• Philippe ayant évoqué When Wizards Stay Up Late, Artur et Stéphane viennent à discuter de l'historique d'Internet, et ils ne sont pas d'accord à ce sujet. Stéphane, se basant sur un article de The New Scientist, assure que le but initial d'Internet était de permettre des sessions à distance, par telnet, et que la messagerie électronique n'était pas du tout prévue à l'origine. Artur, quant à lui, estime que cela servait à faire communiquer des équipes éloignées géographiquement, ce qui implique entre autres un système de messagerie. Etant donné que Stéphane se base sur des documents disponibles sur le net, et qu'Artur s'appuie sur les Mil Std qu'il a utilisés il y a plusieurs années, mais qui ne sont vraisemblablement pas disponibles pour le commun des mortels (des fois qu'un bolchevique au couteau entre les dents s'en serve pour anéantir la civilisation occidentale), il est difficile de juger équitablement pour savoir qui a raison et qui a tort.
• Artur nous évoque les anciens temps de l'informatique et des réseaux. À cette époque, il travaillait en France sur une machine située en Amérique (via telnet, ou un logiciel semblable). Mais les débits n'avaient rien à voir avec ce que nous connaissons aujourd'hui, et il lui arrivait souvent de taper une commande en aveugle, et de voir s'afficher la commande après un délai de quelques secondes.
• Il raconte aussi son émerveillement lorsqu'il a découvert TCP/IP. Il avait ouvert une session (telnet, FTP ou autre) sur une machine, et il y avait une transmission en cours, lorsqu'il a tenté l'expérience suivante : il a débranché la prise réseau de sa machine, et il l'a rebranchée quelques secondes plus tard. Eh bien le traitement TCP/IP a continué comme si rien d'important ne s'était produit. Cela contraste beaucoup avec les protocoles auxquels Artur était habitué, qui s'écroulaient en cascade au moindre incident.

  Sujets techniques divers

• Philippe se pose la question suivante : imaginons que chaque ligne du métro parisien représente la vie d'un humain, de la naissance jusqu'à la mort (en traintant de façon particulière les lignes avec une boucle, comme la 10 et la 7b, ou une fourche, comme la 7 et la 13). Chaque correspondance représente la rencontre de deux personnes ou plus. Est-il possible de choisir un sens pour chaque ligne de manière que cela ne produise aucun paradoxe spatio-temporel ?
• En poursuivant notre réflexion sur les graphes, Stéphane signale le phénomène suivant. Si l'on prend un graphe aléatoire, il suffit de supprimer quelques arcs pour obtenir une propriété arbitraire fixée à l'avance. Toujours prêt à faire du mauvais esprit, je trouve immédiatement un contre-exemple, en choisissant la propriété "le graphe est complet" (c'est-à-dire entre deux noeuds, il existe toujours un arc).
• La discussion continue sur Stanford Graphbase, de Donald Knuth. Cet ouvrage est un exposé complet de la théorie des graphes avec des programmes basés sur des exemples concrets. Il y a ainsi le problème consistant à passer d'un mot à un autre en changeant une seule lettre à chaque étape (exemple flour floor flood blood brood broad bread). Ou bien, il reprend quelques classiques de la littérature (l'Iliade d'Homère ou Anna Karénine de Tolstoi entre autres), en extrait les personnages, et examine chapitre par chapitre qui rencontre qui. Cela rejoint un peu le problème de Philippe basé sur la carte du métro.
• Claude évoque l'utilisation possible de phénomènes quantiques pour l'électronique. Il extrapole en imaginant ce que pourrait donner à échelle macroscopique les phénomènes paradoxaux comme le principe d'incertitude d'Heisenberg. Je lui fais remarquer que Damian Conway a déjà appliqué le principe de superposition des états quantiques à la programmation, et qu'il a écrit un module Perl sur ce sujet. Par exemple, si l'on exécute :

  my $a = any(1 2 3);
  my $b = any(10 20);
  my $c = $a + $b;
  

  alors tous les tests suivants renverront "vrai" :

  $c == 11
  $c == 12
  $c == 13
  $c == 21
  $c == 22
  $c == 23
  

  D'autre part, l'exemple standard de déclaration d'une variable typée ne sera plus

  my Dog $spotty;
  

  ou bien

  $fido = new Camel "Amelia";
  

  mais

  my Cat $schroedinger;
  

• Quelqu'un parle de ses déboires lorsqu'il a voulu installer Linux sur un PC 486, sans lecteur de CD-ROM. La méthode envisagée à l'origine consistait à installer un serveur NFS sur une autre machine, et à y mettre une copie du CD-ROM d'installation. Mais d'après ce que j'ai compris, cela n'a pas très bien fonctionné. Une autre possibilité consiste à faire de la cross-compilation sur une machine Linux existante, mais encore faut-il que les compilateurs croisés soient installés sur cette machine.
• Suite à un rappel des résultats de l'OPC, Philippe évoque les algorithmes de compression. Outre les algorithmes bien connus de Hufmann et de LZW, il avait pensé à compresser un fichier de la manière suivante :
  1. le fichier compressé contient d'abord le nombre n0 de bits à zéro,
  2. puis il contient le nombre n1 de bits à 1,
  3. enfin il contient un numéro d'ordre, repérant la combinaison de n0 (ou n1) éléments pris parmi n0 + n1.
  Le problème avec cet algorithme, c'est que lorsque n1 et n2 sont voisins, le troisième nombre nécessite presque autant de bits que le fichier en entrée. En y ajoutant les deux premiers nombres, ce n'est pas sûr que l'on gagne de la place.
• Certains participants recherchent des filtres pour convertir du RTF en autre chose, ou inversement. La discussion enchaîne sur le fait qu'une personne ne connaissant pas très bien l'informatique peut être surprise, voire affolée, en recevant un message électronique contenant du RTF (ou du L^AT_EX, ce qui est très ressemblant pour un profane).
• BooK explique le principe de Python à ceux qui n'en avaient pas encore connaissance. Certains notent que la toute dernière version voit apparaître les opérateurs du style +=. En revanche, il n'y a pas, et il n'y aura jamais, d'opérateur ++ "car ce n'est pas bien" !
• Je fais part d'un problème que je rencontre de temps à autre lorsque je rédige les compte-rendus. Je souhaite établir un lien HTML vers un site comme celui qui traite des stupidités informatiques. Ce site comporte une vingtaine de fichiers HTML, chacun présentant en gros une cinquantaine d'anecdotes. Le problème, c'est que ces fichiers ne comportent aucune balise, ce qui fait que je ne peux pas spécifier le lien pour afficher directement telle ou telle anecdote située au fin fond du fichier. Pour l'instant je précise entre parenthèses

  ensuite cherchez la chaîne "interligne"

  mais je me demande s'il n'y aurait pas moyen d'écrire la balise sous la forme

  http://rinkworks.com/stupid/cs_drives.shtml?search=interligne
  

  pour automatiser l'affichage. Stéphane me répond que cela reviendrait à permettre à une page appelante d'exécuter du code Java ou Javascript sur la page appelée. D'où un problème de sécurité, le script de la page d'origine étant capable de dénaturer la page de destination. [ Si vous avez eu la curiosité de jeter un coup d'oeil sur le source HTML de ces comptes-rendus, vous aurez pu constater que depuis quelque temps j'associe une balise <a> à chaque élément de liste <li>, pour ne pas reproduire cette erreur. ]

  Sujets divers

• Jean-Louis parle du terme "open-source", et de l'idée que le grand public s'en fait. Une idée très répandue est que "Internet est open-source". C'est faux. De nombreux programmes sont diffusés sans le code source. La seule différence avec l'informatique traditionnelle, c'est que les spécifications, elles, sont visibles par tout un chacun.
• Dans un même ordre d'idée, les gens confondent les idées libérales de ESR avec les idées libertaires de RMS. Jean-Louis a assisté à une conférence en France (ou était-ce en Belgique ?) donnée par Eric Raymond, qui expliquait en Anglais comment la loi du marché s'applique à la programmation "open-source", comment il est possible de faire du profit dans ce domaine, et ainsi de suite. L'assistance francophone applaudissait béatement. Lorsque quelqu'un a pris la parole ensuite, c'était pour évoquer les notions de diffusion et de partage de l'information, de communauté, rien à voir avec les thèmes développés par ESR.
• Stéphane évoque l'attitude des utilisateurs de l'informatique, par exemple, les guichettiers de la Sécurité Sociale. Certains ont compris comment fonctionnent les divers écrans permettant l'utilisation de la carte Vitale. Les autres, plutôt que d'admettre qu'ils ne maîtrisent pas leur outil, préfèrent dire "votre carte Vitale ne marche pas". Philipe a constaté une attitude analogue, mais chez des collègues de travail, ce qu'il trouve pire. Ces personnes disent "c'est magique" pour signifier qu'ils ne savent pas ce qui se passe, et qu'ils ne veulent pas le savoir. Par contraste, lorsque nous autres Perl Mongueurs disont "c'est magique", cela signifie "je ne me suis pas encore penché sérieusement sur la question, mais si le besoin s'en fait sentir, et si j'ai du temps disponible, je vais fouiller pour essayer de comprendre, voire de corriger les problèmes."
• Je ne sais plus après quel enchaînement d'idées, Jean-Louis cite l'une des significations du sigle Emacs : "Eight megabytes and constantly swapping". J'ajoute que la distribution standard d'Emacs comporte un fichier etc/jokes, qui donne une liste impressionnante de significations différentes.
• BooK signale que, la dernière fois qu'il est allé au Monde en Tique, il y a trouvé The Perl Journal, mais pas 2600. Il ajoute que si vous demandez à un vendeur s'ils ont telle ou telle publication, il ne faut pas avoir une confiance aveugle dans la réponse, car il y a de temps à autre un décalage entre le stock et la base de données.
• À un moment de la soirée, le grand problème à l'ordre du jour est : parmi les nombres à quatre chiffres (en autorisant les zéros en première position), quelle est la proportion des nombres dont les quatres chiffres sont différents ? Après beaucoup de calculs dans tous les sens, nous en arrivons à la proportion d'environ un nombre sur deux. Le nombre de nombres dont tous les chiffres sont différents est 5040, le résultat du calcul 10 x 9 x 8 x 7. Une réflexion quelque temps plus tard dans la soirée me laisse supposer que la question concernait les codes secrets des cartes bancaires. En fait, en 1986, j'en discutais avec une collègue, qui m'a dit que la sécurité des cartes était très mauvaise. "Avec trois tentatives, un voleur a 3 chances sur 10 de trouver le bon code. Par exemple, le code de ma carte est 4444..." Cela dit, la règle a peut-être évolué depuis. Mais je ne vois pas pourquoi un nombre comme 1961, avec la répétition du 1, serait plus dangereux qu'un nombre comme 1234 (inutile de me voler ma carte, ce n'est pas le code).
• Stéphane expose le problème des messages d'erreur dans les programmes informatiques. Il arrive fréquemment que le message d'erreur soit "à côté de la plaque". Cela peut être dû à plusieurs raisons : mauvaise manip pour lier le code erreur au message, évolution des fonctions du programme, différence d'approche entre un esprit humain et un algorithme informatique, pour ne citer que quelques raisons. L'erreur à ne pas commettre, mais que nous commettons quand même, c'est de faire une confiance absolue dans le texte du message d'erreur, et de ne pas regarder d'un peu plus loin pour voir ce qui cloche.
• Je n'ai pas pu discuter avec les lispiens, mais Kai a eu l'occasion de le faire. Voici sa contribution : Jacques Siboni n'est pas que lispien, car il a un "Programming Republic of Perl" sur sa home page. Il est psychiatre et fait aussi de l'intelligence artificielle. Il nous raconte que son site, dédié à Jacques Lacan, avait été hacké récemment par quelqu'un venant de lucifer.org (ou .com, je sais plus...). Il cherche des conseils sécurité pour éviter que ça se reproduise. Son voisin à la réunion, Guy Coslado, habite à la campagne, et sa ferme, qui héberge des poulets, a été hackée récemment par un renard...

  Lies, Damn Lies and Statistics

• La discussion s'est engagée lorsque Philippe a parlé du livre qu'il est en train de lire, How to Lie With Statistics, et quand je suis intervenu pour évoquer les deux livres que j'ai lus il y a quelques années :
  1. 200% of Nothing, Dewdney, éd. Wiley
  2. La forme scientifique du mensonge ?, Jean-Louis Boursin, éd. Tchou
  Voici les quelques points évoqués, tirés de ces livres, de notre culture générale ou d'expériences vécues.
• Dans 200% of Nothing, il est question du cyclone Betsy [ et non pas d'un déraillement comme je l'ai dit à la réunion ] ayant touché la Nouvelle Orléans. Les autorités annonçaient 50 victimes. Mais un journaliste avait fait sa propre enquête, et il avait trouvé 93 morts. Les autorités nous cachent quelque chose ! Au fait, comment était-il arrivé à ce résultat ? Il avait posé la question aux Gardes-Côtes, à la police, aux pompiers et à la morgue, et il avait fait la somme des statistiques récoltées...
• Philippe évoque une autre anecdote, que j'ai d'ailleurs retrouvée dans La forme... : lorsque les femmes ont été admises à l'université John Hopkins, aux Etats-Unis, on a constaté que, au bout d'un an, 33% des étudiantes avaient épousé un professeur. En effet, la première année, il y a eu trois femmes inscrites dans cette université, et l'une d'elles, soit 33%, s'est mariée. [Je l'ai extraite de How to lie with statistics -- Philippe]
• Ceux qui consultent les statistiques (et parfois aussi ceux qui les établissent) ne font pas forcément attention à l'énoncé exact. Ainsi, sur un forum de discussion sur l'avortement, une première personne avait énoncé :

  Pour 100 naissances, il y a 30 avortements

  et quelqu'un avait répliqué :

  Je suis étonné que 30% des femmes enceintes se fassent avorter !

  L'erreur ne vient pas des jumeaux ni de la mortalité prénatale, dont l'influence est faible sur les statistiques. Elle vient du fait que la deuxième personne a confondu 100 naissances avec 100 grossesses. Dans la remarque de la première personne, il y avait implicitement 130 grossesses, et donc un pourcentage de 23% (= 30 / 130).
• Dans le même ordre d'idées, Philippe est en train de faire des statistiques sur les performances comparées de produits de filtrages d'URLs, à partir des sites web auxquels accèdent les personnes de l'entreprise dans laquelle il travaille. Il prend soin de faire la distinction entre le spectre (le nombre de sites différents) et le trafic (le nombre de requêtes). Un site très populaire aura une importance certaine sur le trafic, mais il sera sur un pied d'égalité avec les autres pour le spectre. Néanmoins, cela ne fait de doute pour personne, un de ces jours, un "décideur" prendra les statistiques de Philippe, les comprendra de travers, et utilisera le spectre comme s'il s'agissait des données de trafic, ou inversement.
• Et il y a la présentation des statistiques. L'étude de Philippe comporte une comparaison entre les établissements français, américain et singapourien de l'entreprise. Un de ses collègues lui a suggéré de présenter les trois nombres de sites (F, US et SING) sous la forme d'un camembert. Désolé pour ce collègue, mais c'est stupide ! Pour produire un camembert, il faudrait que l'addition de ces trois nombres ait une signification concrète. Sachant que l'on retrouvera les même sites populaires dans le spectre des trois établissements, il n'est pas question de les compter trois fois.
• Certaines représentations graphiques semblent même avoir pour but d'induire en erreur le lecteur. Ainsi, si l'on représente la population de divers pays par un bonhomme dessiné à l'échelle, ou la production industrielle par un tube de dentifrice dessiné lui aussi à l'échelle, qu'est-ce qui est à l'échelle réellement ? Est-ce la hauteur du dessin qui est proportionnelle à la population, est-ce la surface du dessin ? Ou est-ce le volume extrapolé à partir du dessin ? Ou bien alors, on prend un diagramme normal, camembert, bâtons, etc, et on le dessine en perspective, ce qui donne plus d'importance aux données représentées proches de l'oeil de l'observateur.
• Et il y a les mises à l'échelle, et les faux zéros. Notamment, les diagrammes d'évolution des cours de la bourse, qui prennent toute la place allouée, du bas jusqu'au sommet de la figure. Les cambistes savent interprêter ces diagrammes (tout au moins, espérons-le), mais qu'en est-il de l'homme de la rue qui découvre la bourse par les services en ligne d'Internet ?
• Et il y a l'interprétation de ces statistiques. On nous annonce : "La croissance ralentit !". Est-ce grave ? Faut-il se jeter par la fenêtre comme à Wall Street en octobre 1929 ? Pas du tout ! La croissance est peut-être moins forte, mais c'est toujours la croissance.
• Et il y a le cas de McNamara (Robert Strange McNamara pour les intimes, véridique !) et de la guerre du Viêt-nam. McNamara est un petit génie de la recherche opérationnelle, avec un QI de 160, et il travaillait chez Ford dans les années 50. Lorsque Kennedy a été élu président des Etats-Unis, ce dernier a nommé McNamara à la tête du Pentagone. En 1963, Lyndon B. Johnson succède à Kennedy, et un an plus tard fait passer la résolution du Golfe du Tonkin. McNamara se retrouve donc à mener la guerre du Viêt-nam. Comment procède-t-il ? Comme chez Ford, en appliquant consciencieusement les principes de la recherche opérationnelle. Il demande aux militaires de lui faire remonter des statistiques sur les opérations, kilomètres de voies ferrées détruits, hectares de forêt défoliés, et surtout le body count de sinistre mémoire. Il transmet ces données à la Rand Corp., qui triture les statistiques dans tous les sens, et renvoie au Pentagone des listings analysant ces statistiques (ce serait maintenant, Robert Strange ferait cela tout seul sur son portable, avec Excel ; et en plus, il aurait des camemberts en couleurs et en perspective). Cette démarche était vouée à l'échec pour de multiples raisons.
  • Les données étaient filtrées. Robert Strange avait à sa disposition les rapports de la CIA, et ceux de l'armée. Comme ces rapports étaient discordants, il utilisait uniquement ceux de l'armée, et il laissait tomber ceux des agents de terrain de la CIA, qui étaient trop pessimistes à son goût, et qui parlaient de choses inquantifiables, donc inutiles, comme l'état d'esprit du peuple vietnamien.
  • À propos, comment ces rapports étaient-ils établis ? Prenons l'exemple d'une opération Search and Destroy. Au cours de l'opération, une compagnie avait fait des pertes chez l'ennemi, et ils avaient répertorié 27 cadavres. Dans son rapport, le commandant de compagnie annonçait un body count de 30. Ce n'est pas un mensonge, c'est un arrondi. Lorsque le commandant de bataillon collationnait les rapports de ses compagnies, il arrondissait lui aussi. Et, bien entendu, dans le sens qui fait plaisir au tableau d'avancement. Ensuite, je n'ai pas besoin de vous faire un dessin, vous savez ce qu'est un processus itératif...
  • D'autre part, les 27 cadavres correspondent-ils tous à l'opération qui vient de s'effectuer ? Certains d'entre eux n'étaient-ils pas dû à l'opération qui a eu lieu trois jours plus tôt ? (Cf. l'anecdote sur l'ouragan).
  • Ensuite, la démarche adoptée par McNamara était foireuse à la base. Lisez Sun Tsu, (en version française et mise au goût du jour si vous préférez) et vous verrez que le but ultime d'une guerre est d'anéantir la volonté de ceux d'en face à continuer la guerre. Et cette volonté, elle n'apparaît pas sur un listing Rand ou sur un camembert Excel. Infliger des pertes à l'ennemi, c'est un moyen de réduire sa volonté, rien de plus. Il y a dans toute l'histoire de nombreux contre-exemples d'armées qui continuaient à combattre malgré un pourcentage de pertes énorme, ainsi que d'armées qui jetaient les armes sans avoir subi de pertes ou presque. On peut utiliser la recherche opérationnelle pour organiser la logistique d'une armée en campagne, ou bien pour conduire un programme d'armement, mais pas pour apprécier un concept aussi intangible que la volonté d'une nation à faire la guerre. Et cela, McNamara et son QI de 160 n'étaient pas capables de le comprendre.
• Pour reprendre sur une note un peu moins lugubre, je vous livre une anecdote tirée du livre de Jean-Louis Boursin [ je ne l'ai pas exposée à la réunion, mais je ne résiste pas à l'envie de vous en faire part ]

  La plupart des résultats chiffrés peuvent être interprétés dans deux sens opposés : comme le rappelait un jour l'hebdomadaire Newsweek, après cinquante ans de libération de la femme, il n'y a que 22 % de femmes qui ne votent pas comme leur mari ; mais dans le courrier des lecteurs, deux semaines plus tard, un lecteur facétieux faisait observer que 78 % des maris n'osaient pas voter autrement que leur femme !

• Et pour finir, voici ce que dit fortune(6) au sujet des statistiques :

  According to the latest official figures, 43% of all statistics are totally worthless.