![]() |
![]() HRM-BUDEEPBLUE 23 €
![]() Un milliard de personnes avait suivi de par le globe la bataille ultime, un match de boxe "poids lourds de la pensée" entre le champion du jeu d'échecs Garry Kasparov, symbole absolu de l'intelligence humaine, et une armoire remplie d'électronique, froide et sans âme, programmée par un étudiant chinois. L'issue du combat ne faisait guère de doutes: l'Homme allait gagner une fois de plus et renvoyer la machine Deep Blue au rayon "Quincaillerie", département qu'elle n'aurait jamais dû quitter, et humilier définitivement IBM. ![]() ![]() ![]() ![]() ![]() Les ordinateurs d'échecs comme Deep Blue remontent à bien longtemps. Le Turc mécanique, un «automate joueur d'échecs» construit par un ingénieur hongrois le baron Wolfgang von Kempelen, a fait sa première apparition à la cour d'Autriche en 1769. Sa victime la plus célèbre était Napoléon Bonaparte. En réalité, le Turc était une imposture: les coups étaient exécutés par un joueur d'échecs caché. Dans les années 1830, Charles Babbage rêvait de construire une machine d'échecs pour récolter suffisamment de fonds pour développer son Analytical Engine, le premier ordinateur mécanique programmable, jamais achevé. Mais au lieu de cela, il a construit une machine "tic-tac-toe". La création d'une véritable machine d'échecs était bien trop difficile, surtout s'il fallait la construire uniquement à partie de pièces mécaniques. Le premier ordinateur électronique programmable, ENIAC, a été achevé en 1946. Peu après, en 1949, Claude Shannon a tenu une conférence qui a jeté les bases des ordinateurs d'échecs modernes. À l'époque, de nombreux informaticiens de renom pensaient que le problème d'un programme d'échecs – la création d'un ordinateur capable de battre le champion du monde – serait résolu en quelques années, mais leurs prévisions se sont avérées trop optimistes. Au fil du temps – et sans solution à l'horizon –, la résolution du problème des échecs informatiques est devenue le Saint Graal des informaticiens. Au début des années 1980, plus de 30 ans après les travaux précurseurs de Shannon, les meilleurs ordinateurs d'échecs jouaient au même niveau que les maîtres nationaux américains, mais ils étaient encore loin de se mesurer au champion du monde. Mon engagement dans le domaine des échecs par ordinateur est le fruit du hasard. Au printemps 1985, le professeur H.T. Kung, mon conseiller pédagogique à Carnegie Mellon, m'a annoncé que ma survie dans les études supérieures était compromise. Quelques semaines plus tôt, j'avais, pour rendre service, examiné un problème technique pour le compte d'un éminent expert en échecs informatiques de notre département. Ce dernier n'a pas apprécié la solution que je lui ai proposée. Moi non plus d'ailleurs. Après mûre réflexion, je suis parvenu à la conclusion que le véritable problème résidait dans son approche. Une conception radicalement neuve, reposant en partie sur les idées de ses concurrents, serait de loin supérieure. Lorsqu'il a rejeté ma nouvelle proposition, je lui ai signifié sans détour que son approche était insuffisante et que j'avais perdu tout intérêt à creuser le sujet. J'aurais dû me montrer plus diplomate, selon le professeur Kung qui m'a alors exhorté à rédiger un rapport technique et à présenter un exposé étayant mon assertion. J'avais déjà eu assez d'ennuis à cause d'une incartade plus ancienne pour laquelle j'avais failli être renvoyé de l'école... C'est ainsi qu'a commencé le voyage étrange et inattendu vers la création de l'entité de jeu d'échecs la plus puissante au monde: Deep Blue. Au départ, j'avais prévu de retracer ce voyage en suivant le chemin emprunté par le Dr James D Watson, lauréat du prix Nobel de médecine, dans son ouvrage intitulé The Double Helix: A Personal Account of the Discovery of the Structure of DNA1, l'un de mes livres préférés. Cependant, au fur et à mesure que j'avançais dans mon travail d'écriture, je réalisais à quel point les deux livres seraient différents en portée et en nature; si le livre du Dr Watson relate l'une des plus grandes découvertes scientifiques du XXe siècle, l'ouvrage que vous tenez entre vos mains porte davantage sur une quête technique. Par définition, une quête technique couvre un champ plus vaste de la vie. Les idées techniques qui sous-tendent la quête doivent d'abord être découvertes, puis menées jusqu'à leur terme logique. La découverte peut être le fruit de la chance ou de l'inspiration, mais le reste de la quête est une histoire de sueur et de persévérance. La portée de ce livre est donc plus proche de celle, par exemple, de The Quest for Mach One2, le récit de Chuck Yeager sur le franchissement du mur du son. Mon livre décrit la quête visant à dépasser, ne serait-ce qu'un bref instant, la capacité de jeu du meilleur joueur d'échecs du monde. Comparé aux deux ouvrages pré-cités, son contenu est plus divertissant pour plusieurs raisons, non moins à cause de la frivolité apparente de cette idée de créer un ordinateur capable de battre le champion du monde d'échecs. Les informaticiens sont aussi des êtres humains, et ils aiment s'amuser. Une autre raison tient à la grande influence qu'a exercée, sur moi et sur mes écrits, un autre de mes livres préférés, Surely You're Joking, Mr Feynman: Adventures of a Curious Character3, écrit par le prix Nobel de physique Richard P. Feynman. J'y ai découvert son sens de l'humour particulier, sa passion irrépressible pour la vie et sa façon très pragmatique de voir les choses. Plus encore, j'ai appris la valeur de cette faculté de rire de soi-même. Les échecs par ordinateur étaient un domaine de recherche hautement compétitif – la rivalité scientifique était aussi forte et enflammée que dans le domaine de la recherche sur l'ADN. La compétition finale avec Garry Kasparov, le champion du monde d'échecs, était elle aussi une affaire extrêmement sérieuse. Savoir rire de moi-même, ne pas me prendre trop au sérieux, m'a permis de conserver ma lucidité dans des situations très tendues, découlant dans un premier temps de la rivalité scientifique puis des deux matchs face à Garry Kasparov. Si vous prenez du recul et replacez les événements dans leur contexte, les moments les plus sérieux de la vie peuvent aussi se révéler les plus drôles. De nombreux livres abordent les matchs entre le champion du monde d'échecs Garry Kasparov et Deep Blue. Cependant, la plupart d'entre eux s'attardent sur l'aspect «homme contre machine» et s'apparentent à des livres sur les échecs instantanés. Dans cette catégorie de livres, l'angle «homme contre machine» est apparemment très vendeur, mais il ne rend pas compte de la véritable essence du tournoi. Cette compétition opposait en réalité des hommes dans deux rôles différents: l'homme exécutant et l'homme fabricant d'outils. Kasparov et Deep Blue ont disputé deux matchs, qui ont débouché sur des résultats différents. Lors du match de 1996, l'homme exécutant a gagné, tandis que le match revanche de 1997 a été remporté par l'homme fabricant d'outils. Ce livre raconte les histoires des fabricants d'outils, ceux qui ont construit les machines, à l'exception du chapitre 2, la première partie du chapitre 3 et l'annexe A, lesquels portent sur ma vie précédant le lancement du projet. Les récits du chapitre 2 et de la première partie du chapitre 3 sont en rapport direct avec le projet. Si ce projet a existé, c'est bien parce que les événements rapportés dans ces textes ont eu lieu. L'annexe A réunit des souvenirs de mon enfance à Taïwan et peut être consultée comme un document de référence. Je l'ai insérée pour deux raisons: la première, pour répondre à la question «quel imbécile des échecs oserait défier le plus grand esprit échiquéen du monde?» Les témoignages contenus dans ce livre concernent deux organisations socialement et culturellement différentes, le département informatique de Carnegie Mellon et IBM Research. La première moitié du livre se concentre sur le projet de Carnegie Mellon. Au cours de cette période, les idées techniques de base ont pris forme, une nouvelle équipe d'échecs informatiques a été formée sur un coup de tête et une intense rivalité scientifique a éclaté. Le reste du livre documente l'évolution du projet chez IBM: adaptation aux nouveaux environnements, changements douloureux de personnel, développement de nouvelles machines d'échecs et – comme de juste – deux matchs intenses et controversés entre Kasparov et Deep Blue. L'épilogue du livre s'intéresse aux événements d'après-match, notamment la tentative manifeste de Kasparove d'esquiver un nouveau match, bien qu'il n'ait cessé de lancé des défis en ce sens pendant les deux années qui ont suivi sa défaite face à Deep Blue. En novembre 2000, Kasparov a perdu le championnat du monde contre Vladimir Kramnik. Un match contre Kramnik est-il pour autant envisageable? À l'heure où j'écris ces lignes, je n'en sais strictement rien. Une question revient au sujet de Deep Blue: «Est-il intelligent?» Les accusations de tricherie, formulées par Kasparov au cours du match de 1997 et même après, confirment que Deep Blue a réussi la version échiquéenne du test de Turing (un test à l'aveugle permettant de savoir si vous interagissez avec un humain ou un ordinateur). Mais Deep Blue n'est pas intelligent; ce n'est qu'un outil finement conçu et présentant un comportement intelligent dans un domaine bien circonscrit. Certes, Kasparov a perdu le match, mais c'est bien lui qui détenait la véritable intelligence. D'ailleurs, Deep Blue n'aurait jamais été capable de porter des accusations fantaisistes. Une dernière remarque: Deep Blue est le fruit d'un travail d'équipe. Écrire à la première personne le récit d'un effort d'équipe comporte le risque de minimiser le temps et l'énergie investis par les autres membres. Afin de pallier ce problème, j'ai sollicité les commentaires des membres de l'équipe sur les premières ébauches. Si, malgré ma vigilance, j'ai omis de citer dûment la contribution d'un participant, la responsabilité m'en incombe entièrement. Place au spectacle Fin avril 1997, des affiches pour un événement échiquéen inhabituel sont apparues dans les rues de New York. Elles montraient un homme sombre et pensif d'une trentaine d'années fixant les spectateurs par-dessus un échiquier. Sous son menton, une petite légende interrogeait: «Comment fait-on cligner des yeux un ordinateur?» L'homme sur l'affiche n'était autre que le champion du monde d'échecs Garry Kasparov, probablement le meilleur joueur d'échecs de tous les temps. Dans la rue, au sous-sol de l'Equitable Building, je fixais les écrans vierges d'un auditorium vide. Dans quelques jours, l'auditorium serait plein à craquer; les caméras de télévision seraient installées à des endroits stratégiques et les trois gigantesques écrans de projection disposés sur le devant prendraient vie. L'écran de gauche diffuserait une image en direct d'un studio de télévision situé au 35e étage du bâtiment, qui sert de salle de jeu. Le direct présente généralement les deux concurrents assis à une table spécialement conçue à cet effet. Le participant de gauche serait Garry Kasparov. En face de lui se tiendrait l'un de mes deux collègues, Murray Campbell et Joe Hoane, ou moi-même. Le véritable adversaire de Garry était l'ordinateur d'échecs Deep Blue, que nous avions tous les trois conçu et programmé. Pendant les parties, nous agissions comme de simples extensions de Deep Blue, effectuant pour lui les déplacements sur l'échiquier physique. Dans l'auditorium, trois commentateurs d'échecs, parfois accompagnés d'un ou deux invités, se servaient de l'écran central pour présenter leur analyse de la partie en cours. L'écran de droite affichait une vue d'ensemble de l'échiquier. Le public présent dans l'auditorium pouvait ainsi bénéficier d'une vision claire de la position actuelle du jeu. J'avais mis presque 12 ans à atteindre ce niveau. Lorsque j'ai entamé cette œuvre, Garry n'était pas encore champion du monde; il fallait encore attendre quelques mois avant de le voir remporter le titre. Au cours des 11 dernières années, soit depuis 1986, mes partenaires et moi avions construit des ordinateurs d'échecs toujours plus performants avec, pour objectif final, de battre le champion du monde d'échecs, qui qu'il ou elle soit. Avant nous, de nombreux pionniers – certains célèbres, d'autres moins – se sont emparés du «problème des échecs par ordinateur». En 1949, Claude Shannon a soumis sa proposition sur la façon de programmer un ordinateur pour jouer aux échecs. Dès lors, des milliers d'informaticiens, d'ingénieurs, d'amateurs, de joueurs d'échecs et même d'organisations commerciales se sont penchés sur ce problème. Certains entendaient utiliser les échecs comme un outil expérimental pour découvrir le fonctionnement de l'intelligence humaine: «Si l'on parvenait à concevoir une machine d'échecs performante, on pénétrerait au cœur de l'effort intellectuel humain», écrivaient Allen Newell, Cliff Shaw et Herbert Simon dans l'un des premiers articles sur les échecs informatiques. D'autres considéraient les échecs comme un exemple clair et bien défini d'un problème complexe. La «résolution» des échecs pourrait, en théorie, livrer de nouvelles techniques pour le dénouement d'autres problèmes complexes. Les entreprises commerciales l'ont évidemment fait pour le profit, tandis que certains individus, en particulier les amateurs, l'ont fait uniquement pour le plaisir. Nous avons abordé le problème sous un angle nouveau. Nous – ou tout au moins moi – l'avons considéré comme un problème purement technique. Depuis la fin des années 1970, il était établi que les ordinateurs d'échecs gagnaient en puissance proportionnellement à la vitesse du matériel (hardware). En 1985, lorsque j'ai démarré ce petit projet qui est devenu Deep Blue, l'extrapolation des données expérimentales indiquait qu'une augmentation de 1000 fois la vitesse du matériel suffirait à produire une machine d'échecs du même calibre qu'un champion du monde. Notre projet a donc été lancé avec un objectif simple, à savoir déterminer si une augmentation massive de la vitesse du matériel suffirait à «résoudre» le problème des échecs par ordinateur. La construction de cette «mère de toutes les machines d'échecs» était un problème intéressant en soi. Certes, si notre machine venait à battre le champion du monde, ce serait là un vrai plus. La version précédente de Deep Blue avait perdu une partie contre Garry Kasparov à Philadelphie en 1996. Cependant, aux deux tiers de ce match, nous étions ex aequo. Cette ancienne version de Deep Blue était déjà plus rapide que la machine que j'avais imaginée en 1985, mais ce n'était pas assez. Pour résoudre le problème des échecs par ordinateur, on ne pouvait se contenter d'augmenter la vitesse du matériel. Depuis ce match, nous avons reconstruit Deep Blue de zéro, en passant au crible chaque problème rencontré au cours du match et en sollicitant à foison la participation de plusieurs grands maîtres. Ces efforts ont amené le Grand Maître Joel Benjamin, notre conseiller en échecs et l'un des meilleurs joueurs d'échecs des États-Unis, à dire: «Vous savez, parfois Deep Blue joue aux échecs.» Joel ne pouvait désormais plus discerner avec certitude les coups de Deep Blue des coups joués par les meilleurs Grandmasters. Les médias attendaient ce nouveau match avec un vif intérêt. La victoire du nouveau Deep Blue marquerait un tournant dans la longue histoire de l'homme fabricant d'outils. Ce serait également l'accomplissement d'une étape longtemps recherchée par les informaticiens et les chercheurs en intelligence artificielle. Il était quasiment certain que ce match dépasserait en importance tous les championnats du monde d'échecs, à l'exception peut-être du match Fischer contre Spassky en 1972. Si nous gagnons, cette rencontre pourrait même supplanter celle entre Fischer et Spassky. Le nouveau Deep Blue était bien meilleur, mais serait-il à la hauteur? Le voyage entrepris par mes partenaires et moi-même il y a tant d'années touchait-il à sa fin? Un bureau de trublions «Votre bureau est un bureau de fauteurs de troubles !» s'est exclamé Kung, d'un air résigné. Kung n'était autre que le professeur H T Kung, mon conseiller pédagogique à l'université Carnegie Mellon de Pittsburgh, un homme grand et bien bâti d'une quarantaine d'années. J'étais un étudiant de 3e cycle au département d'informatique (Computer Science – CS). Nous venions de nous entretenir longuement en privé, dans son bureau. C'était l'automne 1987. Le professeur Kung avait été mon directeur de thèse pendant toute la durée de mon cursus à Carnegie Mellon. J'avais beaucoup de respect pour lui, non seulement parce qu'il avait été pour moi un bon directeur de thèse, mais aussi pour les actions qu'il avait menées à titre personnel. Le professeur Kung était un descendant direct de Confucius et mettait un point d'honneur à faire tout ce qui était en son pouvoir pour favoriser le développement technique et économique des sociétés chinoises dans le monde. Ce n'est pas avec le professeur Kung que je rencontrais des difficultés, mais avec un autre professeur du département. Au moment de cette conversation, il y avait deux équipes d'échecs informatiques à Carnegie Mellon; le Dr Hans Berliner dirigeait l'équipe Hitech, tandis que l'équipe concurrente, ChipTest, regroupait des étudiants de 3e cycle, pour la plupart non supervisés, dont je faisais partie. J'ai bénéficié d'une supervision minime de la part du professeur Kung, au moment où les membres de mon équipe travaillaient sur ChipTest par pur plaisir. La compétition entre les deux équipes, jusqu'alors amicale, était sur le point de se muer en une intense rivalité. En y repensant, je me dis que cette rivalité était inévitable. Il y avait eu quelques frictions entre les deux équipes. L'équipe ChipTest désapprouvait la façon dont on nous présentait, trop souvent et à tort, comme les étudiants du Dr Berliner ou travaillant sous sa houlette. Dans une large mesure, cette représentation découlait de la renommée du Dr Berliner dans le domaine des échecs informatiques, qui a conduit les journalistes à assumer automatiquement que lui seul dirigeait tous les projets d'échecs informatiques à Carleton4. Bien que vexante pour l'équipe de ChipTest, cette caractérisation ne pouvait, à elle seule, provoquer la montée en puissance immédiate du conflit. L'escalade a été déclenchée, entre autres, par une invitation de l'équipe ChipTest à participer à un tournoi d'échecs. Il se trouvait que l'équipe de Hitech se rendait au même tournoi et Berliner avait tenté de convaincre Kung qu'il était préférable pour l'équipe ChipTest de renoncer à cet événement5. Mon entretien avec le professeur Kung portait précisément sur la suite à donner à cette invitation. Kung soutenait l'équipe ChipTest et ne voyait aucune raison de décliner. Cependant, soucieux d'éviter tout problème futur, l'équipe ChipTest avait, avant cette discussion, décidé de satisfaire à la recommandation du Dr Berliner. Le professeur Kung était soulagé de voir le problème résolu, mais lorsqu'il a prononcé sa remarque sur les «fauteurs de troubles», il a dû éprouver une sensation de déjà-vu. Deux ans auparavant, en 1985, nous avions déjà eu une conversation se rapportant au Dr Berliner, conversation qui a constitué un maillon essentiel de la chaîne des événements qui ont débouché sur la création de ChipTest et, finalement, de Deep Blue. La véritable origine du projet Deep Blue remonte à encore plus loin. Tout a commencé avec les «fauteurs de trouble» du professeur Kung, étudiants en première année de 3e cycle. Les étudiants en première année d'études supérieures Le département des sciences informatiques (désormais cité CS) de Carnegie Mellon était le fleuron de l'université. Plusieurs départements figuraient parmi le top 10 de leur domaine, mais le CS était classé parmi les trois premiers, les numéros un et deux étant respectivement ceux du MIT et de Stanford. Selon les préférences de chacun, certains disaient même que le département CS de Carnegie Mellon était le meilleur. Le département était imprégné d'une ambiance particulière et, comparé à d'autres écoles, les étudiants de 3e cycle avaient davantage de contrôle et leur mot à dire sur leurs axes de recherche. Le fait que le département proposait seulement un cursus de doctorat (et pas de programme de licence ou de master) a sans doute donné à la Faculté la latitude nécessaire pour expérimenter et mettre au point ce système unique. Compte tenu de ce système atypique d'une part, et de la diversité des profils des nouveaux étudiants d'autre part, le premier mois de chaque semestre automnal était entièrement dédié au «cours d'intégration». Pour les nouveaux étudiants, c'était l'occasion de se familiariser avec les environnements, les outils, les projets et les personnes et, tout simplement, de s'amuser. Les étudiants plus âgés passaient du temps à faire la démonstration de leurs projets, à faciliter l'adaptation des nouveaux étudiants et, naturellement, à s'amuser aussi. Vers la fin de ce cours se tenait la «réception» annuelle du département, généralement dans un endroit chic de Pittsburgh. Je me rappelle avec émotion m'être gavé à la réception lorsque j'étais un jeune diplômé affamé. Le cours d'intégration marquait également le début des formalités de «mariage»: les nouveaux étudiants cherchaient à rencontrer les professeurs dont les travaux les intéressaient et choisissaient leurs directeurs de thèse. De leur côté, les professeurs observaient les nouveaux étudiants et décidaient de qui retenir. Comme dans la vie réelle, les mariages n'étaient pas définitifs, et des «divorces» entre les membres du corps enseignant et les étudiants se produisaient quelquefois, en partie parce que le financement des étudiants n'était pas nécessairement lié à un projet spécifique. Les membres du corps professoral dirigeaient leurs étudiants principalement grâce au respect que ces derniers leur témoignaient. En dehors des cours, les professeurs avaient très peu d'emprise sur les étudiants qu'ils n'encadraient pas. En 1982, l'année où j'ai «immigré» dans le département, le taux d'admission des étudiants était plus élevé que d'habitude et les places manquaient. Normalement, lors de l'attribution des bureaux, on considérait préférable de mêler anciens et nouveaux étudiants. En raison de cette pénurie, je me suis retrouvé dans un bureau vide avec trois nouveaux étudiants, Mike Browne, Andreas Nowatzyk et Tony Stentz. Au final, nous nous en sommes bien sortis tous les quatre mais, en cours de route, les professeurs ont probablement regretté leur décision. L'année suivante, Tony a déménagé dans un autre bureau et, pendant plusieurs années, seuls Mike, Andreas et moi occupions le bureau, nouant ainsi des liens d'amitié étroits. La remarque du professeur Kung sur les trublions excluait probablement Tony. Mike était sans doute le premier Américain avec qui j'ai engagé une véritable conversation, laquelle a eu lieu lors de mon premier jour sur le campus de Carnegie Mellon – et seulement mon 3e jour à l'université. En poussant la porte de mon nouveau bureau, je suis tombé sur un barbu; c'était Mike. Sa barbe m'empêchait de deviner son âge, mais il se révéla être l'un des plus jeunes étudiants de la nouvelle promotion. Né dans le New Jersey, mais ayant grandi à Allentown, en Pennsylvanie, Mike a obtenu son diplôme de premier cycle à l'université Lehigh en seulement trois ans. Pendant notre première conversation, Mike s'est présenté comme un «hacker», ce qui signifie, selon sa propre définition, un être capable de produire des programmes informatiques. Autrement dit, un créateur, quoique dans un domaine spécialisé. De nos jours, cette définition est encore d'usage, même si la caractérisation la plus courante, employée par les médias, désigne une personne qui endommage ou exploite des systèmes informatiques par des moyens virtuels. La définition la plus récente dépeint un destructeur. Mike était manifestement très intelligent mais incroyablement effacé Si Mike faisait partie des jeunes étudiants, Andreas et moi comptions parmi les plus âgés. Dans mon cas, c'était parce qu'à Taïwan, d'où je suis originaire, les garçons devaient servir deux ans dans l'armée après le lycée6. Quant à Andreas, il avait étudié un an de plus afin de décrocher deux diplômes de premier cycle difficiles: la physique et l'informatique. Il venait d'Allemagne, était diplômé de l'Université de Hambourg et avait effectué une année de doctorat dans son pays d'origine avant de rejoindre Carnegie Mellon. Mike était un très bon programmeur, et Andreas n'était pas en reste. En plus d'être un programmeur de premier ordre, Andreas a prouvé qu'il possédait de nombreuses compétences techniques. À Carnegie Mellon, il n'a eu de cesse de m'étonner: j'avais la ferme conviction que je pouvais être bon dans n'importe quel domaine technique si je m'y mettais. Pour sa part, Andreas semblait déjà maîtriser tous les sujets techniques. Pendant nos premières années à Carnegie Mellon, Mike et moi étions plutôt joueurs, alors qu'Andreas s'est montré très professionnel dès le premier jour. Ce n'est que bien plus tard, en découvrant que nous partagions de nombreux centres d'intérêt dans des domaines techniques, qu'Andreas et moi sommes devenus amis.Toutefois, cette amitié était loin d'être une relation symétrique. Je me souviens des multiples circonstances où Andreas m'a aidé dans des domaines où j'avais des lacunes. Mais il était tellement autonome que je ne me souviens pas avoir fait la moindre chose pour l'aider en aucune façon. Avant notre arrivée à Carnegie Mellon, Andreas, Mike et moi avions tous été familiarisés avec les échecs, ou les échecs par ordinateur. Au lycée, Mike était un joueur d'échecs de compétition. Sans y jouer sérieusement, Andreas s'intéressait aux échecs informatiques. À l'époque de ses études de premier cycle en Allemagne, il avait participé à l'arbitrage d'un championnat mondial d'échecs sur micro-ordinateur. Ma découverte des échecs par ordinateur a eu lieu principalement à travers la lecture de revues et livres techniques. Pendant notre période d'immersion, Andreas et moi avons examiné les recherches sur les échecs informatiques menées au sein du département. Nous étions tous deux intéressés par la conception de puces à très grande échelle (Very Large Scale Integration – VLSI). D'ailleurs, Carl Ebeling, un étudiant de 3e cycle du groupe VLSI, développait une machine d'échecs basée sur la VLSI. Ni Andreas ni moi n'étions assez intéressés pour nous lancer dans l'informatique échiquéenne. À l'époque, je pensais que le jeu d'échecs par ordinateur avait encore un long chemin à parcourir et je ne pouvais en prévoir l'issue. Qui plus est, j'avais envie de mener à bien un projet pratique. Le professeur Kung était le professeur principal du groupe VLSI et représentait pour Andreas et moi-même un choix évident. Mike a décidé de travailler avec un professeur en Intelligence Artificielle (IA). Andreas voyait d'un très mauvais œil la recherche en IA en général. Au début, Mike ne partageait pas le même avis mais, après s'être séparé de son premier directeur de recherche, Andreas et lui ont tous deux qualifié l'IA de «foutaise». Je ne suis pas allé jusqu'à cet extrême, même après ma lecture des soi-disant recherches en IA qui méritent vraiment ce qualificatif. Le groupe IA était de loin le plus important du département et comptait près de la moitié des étudiants. Au sein de notre bureau, l'opinion majoritaire sur l'IA était clairement minoritaire au sein du département. Malgré notre aversion partagée pour l'IA, Mike, Andreas et moi avions, au fil des années, évoqué à maintes reprises les échecs par ordinateur. L'une de nos discussions portait sur Belle, la meilleure machine d'échecs du début des années 1980. Lorsqu'il était encore à l'université de Hambourg, Andreas avait assisté à une conférence de Ken Thompson, l'un des concepteurs de Belle. Au cours de son exposé, Ken a présenté des expériences démontrant que le jeu de Belle était meilleur si on lui accordait plus de temps. J'ai demandé ce qui se passerait si une machine analogue à Belle était, disons, 1000 fois plus rapide. Aucun d'entre nous ne pensait qu'une telle machine ne serait assez puissante pour battre le champion du monde mais qu'elle ne passerait pas loin. En tout cas, au moment de cette conversation, aucun d'entre nous ne se doutait qu'à la suite de ma réponse à cette question, j'allais entraîner Andreas et Mike dans un projet d'échecs informatiques. La remarque du professeur Kung sur les fauteurs de troubles comprenait sans doute Andreas compte tenu de leur brouille survenue quelques années plus tard. Quant à la séparation de Mike et de son premier directeur de recherches, j'en ignore les impacts, mais cela devait être assez grave pour que le professeur Kung s'en aperçoive lors de la réunion des professeurs «Black Friday» qui se tient à la fin de chaque semestre. Andreas figurait en tête de la liste des «fauteurs de troubles» du professeur Kung, mais c'est probablement à moi que revenait la première place, car j'étais à l'origine de nombreux autres incidents. Certains découlaient de mes farces immatures. D'autres n'étaient pas entièrement de mon fait, comme vous le verrez dans les prochains chapitres. Les canulars que j'ai montés les premières années ont entraîné deux conséquences profondes; elles m'ont d'abord valu une réputation douteuse parmi les étudiants, réputation qui, paradoxalement, m'a aidé à recruter d'autres étudiants pour mon projet d'échecs. (À coup sûr, le recrutement ne constituait que la première étape. Il fallait que le projet soit intéressant en soi et que je traite mes amis convenablement). La seconde conséquence a été mon classement sur la liste des espèces en voie de disparition au département. Le premier mauvais tour, relaté dans la section ci-dessous, ne m'a pas attiré d'amis lors de la réunion «Black Friday», tandis que le second a bien failli provoquer mon renvoi de l'école et me conduire en prison s'il avait eu lieu quelques années plus tard. Les farces sont autorisées! À Taïwan, les étudiants devaient scrupuleusement respecter les règles de l'école. C'est pourquoi, lorsque je m'y trouvais encore, j'étais toujours fasciné par les histoires d'étudiants qui organisaient d'ingénieux poissons d'avril sur les campus universitaires américains. Pendant le cours d'adaptation, l'une des séances à laquelle tous les étudiants ont assisté était la séance de présentation: nous étions tous entassés dans une grande salle afin de nous présenter aux autres membres du département. Après s'être présentée aux nouveaux étudiants, Sharon Burks, l'assistante administrative du département à l'époque7, a mis en garde, sur le ton de la plaisanterie, la personne qui avait falsifié un courrier électronique de sa part le 1er avril. Surpris de constater une telle insubordination de la part des anciens étudiants, je me suis dit: «Chouette! Nous avons donc le droit de faire des bêtises.» Ma première année à Carnegie Mellon était très chargée; je voulais passer toutes les qualifications de base aussi vite que possible. J'avais perdu la main à cause de mes deux années de service militaire à Taïwan, aussi avais-je beaucoup de retard à rattraper. Après le premier semestre, j'étais en assez bonne posture sur le plan académique, et mon premier poisson d'avril à Carnegie Mellon pointait déjà le bout de son nez. Au début des années 1980, même dans une école supérieure de sciences informatiques comme Carnegie Mellon, les étudiants de 3e cycle ne disposaient que de terminaux en mode texte dans leurs bureaux. Certains d'entre nous bénéficiaient de postes de travail permettant d'afficher des graphiques en noir et blanc. Dans la salle des terminaux se trouvaient des postes de travail à usage public. La plupart de nos travaux étaient encore effectués sur des terminaux connectés à des mini-ordinateurs de dernière génération pour l'époque. Ces mini-ordinateurs étaient moins puissants que les micro-ordinateurs personnels que l'on peut aujourd'hui se procurer pour moins de 300 dollars (montant qui, soit dit en passant, ne suffisait pas à acquérir ne fût-ce qu'un seul des terminaux que nous utilisions). La plupart des mini-ordinateurs fonctionnaient avec le système d'exploitation UNIX8, qui est de nos jours largement utilisé dans des domaines où les pannes d'ordinateur causées par le système d'exploitation lui-même sont inadmissibles. UNIX vous permet de «parler» à un autre utilisateur sur le même ordinateur, à condition que ce dernier vous accorde ce privilège. La plupart des utilisateurs octroient ce droit par défaut. Lorsque vous «parlez» à un autre utilisateur, UNIX affiche les caractères que vous avez tapés directement sur le terminal de l'autre utilisateur. En principe, cette opération est inoffensive, si ce n'est qu'elle risque d'agacer l'autre utilisateur si vous en abusez. Il existe cependant un moyen de provoquer des ravages si le terminal de l'autre utilisateur est doté d'une certaine «intelligence». Les terminaux informatiques les plus intelligents acceptent généralement des chaînes de commande que l'ordinateur peut utiliser pour déplacer le curseur (l'indicateur à l'écran qui met en évidence l'endroit où le nouveau caractère doit apparaître) et pour lire l'emplacement (x, y) du curseur. Par la transmission de chaînes de commande adéquates, vous pouvez déplacer le curseur à un endroit particulier de l'écran, puis faire en sorte que le terminal renvoie l'emplacement du curseur à l'ordinateur de votre victime. Dans la mesure où l'ordinateur est probablement en attente d'une commande de l'utilisateur, le curseur apparaît le plus souvent comme si la victime avait saisi son emplacement sous forme de commande. Et hop, vous venez de faire exécuter à votre victime une commande de votre choix. Telle était l'idée de base de mon poisson d'avril de 1983. Le 31 mars, j'ai discuté avec un collègue qui a aussitôt décidé de se joindre à moi. Notre plan prévoyait que j'écrive deux programmes. Le premier sélectionnerait les victimes au hasard et enverrait des chaînes spécifiques à leurs terminaux. Le terminal de la victime transmettrait alors une commande chargée d'exécuter mon autre programme. Ce dernier publierait alors un message aléatoire, et sans doute déplacé, sur le tableau d'affichage électronique du département en provenance du compte de la victime. Mon collègue avait pour mission de trouver une collection de messages aléatoires à afficher, et il a accompli un travail exceptionnel. La plus grande difficulté technique consistait à faire en sorte que les victimes ne réalisent pas ce qui venait de se produire, même lorsqu'elles se trouvaient devant leur terminal. Le curseur devait d'abord se déplacer aux endroits appropriés afin de créer la commande informatique permettant d'exécuter le second programme, puis revenir à son emplacement initial. Au terme de ce processus, l'écran devait paraître identique à celui d'avant l'attaque. La tâche était compliquée, mais tout à fait réalisable. Même face à l'écran, la victime verrait, pendant environ une seconde, comme un papillotement accompagné d'un clignotement du curseur. Ce n'est qu'au soir du 1er avril que les programmes ont été finalisés. Nous les avons lancés dans les dernières heures de la journée. Le lendemain matin, plusieurs messages insolites sont apparus sur le tableau d'affichage électronique, la plupart des victimes étaient des membres du corps professoral9. Un message notable avait été envoyé par un professeur qui demandait à qui appartenait la paire de collants qu'il avait trouvée dans les toilettes pour dames. Un autre professeur a «posté» un message expliquant qu'il était parvenu à se connecter à l'ordinateur, mais qu'il ne savait pas comment fermer la session et avait besoin d'aide. Le professeur n'a pas apprécié la plaisanterie et, ne réalisant pas quel jour on était, il a posté – pour de vrai – un message exigeant les aveux de la personne qui avait diffusé le message relatif à la déconnexion. J'ai ressuscité mes programmes – cette fois avec une seule victime autorisée: moi-même –, et le fichier de messages a été modifié de manière à n'en contenir qu'un seul. Ce message relevait l'étourderie des professeurs et précisait que le 1er avril tombait la veille. Par ailleurs, des indices clairs trahissaient le caractère factice des messages. Tous les titres étaient encadrés par des guillemets et, techniquement, le message avait bel et bien été posté depuis le compte du professeur, tout comme le mien l'avait été depuis mon compte par le biais du même mécanisme. Je n'ai subi aucune conséquence directe de cet incident. Cependant, cette farce, comme sa suivante, bien plus grave, a probablement nui à ma réputation aux yeux de certains professeurs. Après cet épisode, mon collègue a définitivement désactivé le privilège d'écriture sur son terminal. Personne ne lui ferait jamais ce coup! Un autre ami s'est intéressé au contrôle du curseur et a finalement créé une «invite de commande psychédélique». Chaque fois qu'il tapait une commande, une figure ressemblant à un cow-boy s'affichait sur l'écran de son terminal, et une flèche jaillissant du côté gauche frappait le cow-boy qui se désintégrait aussitôt. Le voisinage de Mister Rogers UNIX est un système d'exploitation relativement sécurisé. L'un de ses créateurs, Ken Thompson, a évoqué plusieurs façons de le compromettre dans sa conférence du prix Turing. En général, un système UNIX bien entretenu est pratiquement imperméable aux attaques d'amateurs. Le problème, c'est que la plupart des systèmes UNIX ne sont pas forcément bien entretenus. Au début des années 1980, la quasi-totalité des ordinateurs de dernière générations dans les universités fonctionnaient sous UNIX. Beaucoup d'entre eux étaient connectés au réseau de la DARPA (Defense Advanced Research Project Agency), le précurseur de notre Internet actuel. Arpanet était le diminutif courant de ce réseau. Le département des sciences informatiques, qui menait de nombreux projets de recherche parrainés par la DARPA, était relié à l'Arpanet. Il disposait d'un personnel dévoué et compétent chargé d'entretenir les systèmes informatiques; d'ailleurs, je n'ai jamais trouvé le moyen de pirater les principales machines du département. Cependant, Arpanet abrite un grand nombre de machines moins sécurisées. Au département, il fallait saisir des mots de passe pour se connecter à tous les comptes informatiques accessibles depuis l'Arpanet ce qui n'était pas le cas de nombreux ordinateurs sur le Net. Je suis même tombé par hasard10 sur une machine de l'UC Berkeley disposant d'un compte invité qui ne nécessitait aucun mot de passe. Quelqu'un avait laissé la porte entrouverte. Certes, ce seul acte n'indique pas nécessairement la présence d'un problème. Le système d'exploitation UNIX vous permet de verrouiller votre propriété privée afin que les autres utilisateurs ne puissent pas accéder à vos lettres d'amour en ligne. (Même si je ne m'explique pas pourquoi vous laisseriez traîner ce genre de messages sur Internet.) Par définition, le compte invité possède des droits limités et, par conséquent, un invité ne peut pas faire sauter les verrous. Tout va bien alors, n'est-ce pas? Dans la réalité, les gestionnaires d'immeubles détiennent des clés passe-partout au moyen desquelles ils peuvent ouvrir toutes les portes du bâtiment. Dans un système UNIX, le gestionnaire du système peut se transformer en un «superutilisateur» habilité à faire tout ce que bon lui semble au cœur de ce système. Certains programmes de confiance, indispensables à la maintenance du système, se voient généralement accorder le privilège de «superutilisateur» pour garantir le bon fonctionnement des programmes. Il arrive, cependant, que la confiance placée dans ces programmes «superutilisateurs» soit infondée. Si les programmes eux-mêmes fonctionnent correctement, les fichiers dont ils dépendent ne ne sont pas toujours sécurisés. Tout gestionnaire de système compétent veillerait à ce que les programmes du superutilisateur eux-mêmes ne soient pas compromis, mais certains gestionnaires de système peu expérimentés négligent parfois les fichiers référencés par ces programmes. Pour une raison qui m'échappe, certains fichiers n'étaient pas suffisamment sécurisés sur la machine Berkeley. Il existait dès lors une porte dérobée par laquelle un invité pouvait entrer et s'emparer d'un passe-partout. C'est ainsi que je suis devenu le super-utilisateur, un dieu virtuel, de cette machine. Que faire de ce pouvoir? Naturellement, je ne voulais pas causer de préjudice. Un ami m'a proposé de créer un compte informatique pour Fred Rogers, le prédicateur et animateur de l'émission télévisée jeune «Mister Rogers' Neighborhood» sur la chaîne Public Broadcasting System. Fred Rogers vit à Pittsburgh, où l'émission est filmée, à quelques pas de Carnegie Mellon. La suggestion me paraissait opportune. Très vite et à son insu, Mister Rogers avait probablement son tout premier compte informatique sur la machine Berkeley. Une erreur s'est glissée dans le nom de son compte: mon ami pensait que l'initiale du second prénom de Fred était S, d'où l'attribution du nom «fsr» Au cours des deux semaines suivantes, Mister Rogers' Neighborhood étendait sa présence sur Arpanet pendant mon temps libre. La chanson de la série de Mister Rogers tournait en boucle dans ma tête: «It is a beautiful day in this neighborhood. A beautiful day for a neighbor. Would you be mine? Could you be mine?...»11 La création de nouveaux comptes pour Mister Rogers fut un processus fastidieux car chaque système présentait sa faiblesse propre. À l'approche des examens de fin d'année pour trois matières, je manquais de temps libre mais, au plus fort de l'activité, Mister Rogers détenait près de 10 comptes informatiques dans les meilleures universités américaines. Un jour, j'ai reçu une convocation de la part du chef de département, Nico Habermann. Le gestionnaire du système de l'université de Purdue avait repéré un compte créé pour Fred Rogers et avait remonté la piste jusqu'à Carnegie Mellon. C'est alors que le personnel de Carnegie Mellon m'a démasqué. Nico m'a sermonné et m'a ordonné de rédiger ce qui s'apparentait à une confession pour expliquer la manière dont j'avais procédé tout en manifestant mes remords. C'était une tape sur la main, sans grande conséquence; la sécurité des systèmes concernés s'en est peut-être trouvée renforcée. Mister Rogers, quant à lui, a perdu tous ses comptes. Cet épisode est intervenu avant que le Congrès n'adopte la loi sur la confidentialité des données informatiques. Si je venais à commettre ce méfait aujourd'hui, j'irais au devant de sérieux ennuis. Consulter des fichiers protégés sans autorisation constitue un manquement à l'éthique. Il en va de même pour les fichiers non protégés à caractère personnel. Je prenais les choses comme un jeu alors qu'il s'agissait en réalité d'une affaire sérieuse. Du reste, il ne faut jamais laisser traîner un fichier texte, protégé ou non, contenant des mots de passe et encore moins sur un système hébergeant des comptes invités qui ne requièrent pas la saisie d'un mot de passe. Le monde est vaste, et il regorge de malfaiteurs. Lors de la réunion «Black Friday» de cette année, je risquais fort d'être mis à la porte. En fait, j'étais probablement à un incident près d'être viré du département. Le grand saut L'éthique de travail des Japonais Je peux travailler dur quand je le veux, mais je suis fondamentalement un paresseux. Jusqu'à la seconde année à Carnegie Mellon, je n'avais bûché qu'une seule fois pendant une longue période; c'était pour préparer le concours d'entrée à l'université à Taïwan12. Seulement, réviser pour les examens ne peut être considéré comme un travail à part entière, ce qui voudrait dire que, jusqu'à ma deuxième année à Carnegie Mellon, je n'avais jamais travaillé dur de ma vie. Andreas Nowatzyk, mon collègue de bureau allemand, était un travailleur acharné, mais il travaillait surtout la nuit et ses habitudes de travail n'avaient pas déteint sur moi. Les choses ont changé lorsque j'ai entrepris une collaboration avec un visiteur japonais sur l'un projet du professeur Kung. Teiji Nishizawa était un visiteur de Matsushita Electric au Japon. (Matsushita est plus connue aux États-Unis comme étant la société à l'origine de la marque de produits électroniques grand public Panasonic). À l'époque, le département d'informatique avait conclu des accords avec de grandes entreprises japonaises afin d'envoyer, moyennant finances, des représentants travailler temporairement au sein du département sous la houlette des professeurs. Teiji comptait parmi ces émissaires. L'expérience m'a monté qu'il existe deux types de bosseurs. Le premier a tendance à travailler par à-coups. De nombreux programmeurs de logiciels appartiennent à cette catégorie –, bien que ce ne soit pas le cas de tous les bons programmeurs. Ce type de travailleur peut trimer, disons 48 heures d'affilée en laissant libre cours à sa créativité. Je ne pourrai jamais travailler de cette façon; je deviens grincheux au moindre manque de sommeil. Teiji était un bon spécimen de ce second type de bosseur; il était très motivé et auto-discipliné. Il ne travaillait pas forcément de longues heures, mais il accomplissait de solides journées de travail pendant de longues périodes. Ce type de travailleur acharné est plus adapté au travail de conception de puces, où il importe davantage de fournir un rendement soutenu et de haute qualité que des éclairs soudains de génie. C'est pourquoi le travail réalisé en étroite collaboration avec Teiji l'année suivante s'est avéré très instructif, surtout sous l'angle de l'éthique du travail. Teiji, Alan Sussman (un autre conseiller du professeur Kung) et moi-même avons fait équipe sur le projet conjoint du professeur Kung avec General Electric (GE). Alan et moi considérions ce projet comme une qualification dans ce champ d'étude, un critère indispensable à l'obtention de notre doctorat. Cette qualification était généralement une tâche confiée par le conseiller pédagogique aux étudiants afin qu'ils démontrent leur maîtrise du domaine de recherche. En réalité, il s'agissait également d'un moyen pour les professeurs de tirer un travail exploitable de la part des étudiants. C'est à l'occasion de ce projet que j'ai découvert l'éthique de travail japonaise. Notre projet consistait à (suite dans le livre) Ci-dessous -video 2- l'analyse de la partie fatale: (1. e4 c6 2. d4 d5 3. Nc3 dxe4 4. Nxe4 Nd7 5. Ng5 Ngf6 6. Bd3 e6 7. N1f3 h6 8. Nxe6 Qe7 9. O-O fxe6 10. Bg6+ Kd8 11. Bf4 b5 12. a4 Bb7 13. Re1 Nd5 14. Bg3 Kc8 15. axb5 cxb5 16. Qd3 Bc6 17. Bf5 exf5 18. Rxe7 Bxe7 19. c4) par Antonio Radic. Dans la video 1, vous entenderez Kasparov dire que Deep Blue ne joue pas des ''vrais échecs'' ce qui n'a pas de sens ! HRM-BUDEEPBLUE 23 €
HRM-BUDEEPBLUE 23 €
|
![]() |