Au Joyeux Ragondin

Le dictionnaire Littré, édition 1863, en-ligne et téléchargeable pour utilisation locale, c'est trop d'la balle. Sa mère. Dans le même style, il y a Dictionnaires d'autrefois.

L'argument de la chambre chinoise est une expérience de pensée censée mettre à mal la thèse selon laquelle une machine de Turing serait capable de pensée. L'argument est très connu et discuté depuis sa formulation en 1980 mais, en bon inculte que je suis, je viens de le découvrir. Je le résume et vous renvoie vers le lien pour plus de détails.

L'objectif est reproduire une expérience dans laquelle on donne une histoire à un ordinateur et où, en manipulant des symboles, l'ordinateur est capable de répondre à des questions sur l'histoire. Dans l'expérience de la chambre chinoise, vous êtes enfermé dans une pièce et on vous donne trois blocs de données (en chinois) ainsi que des règles (algorithmes) de correspondance entre ces jeux de données, que vous devez utiliser pour envoyer des symboles à l'extérieur de la pièce. Les observateurs, dehors, considèrent que le premier bloc est un ensemble de données linguistiques vous permettant de faire des phrases, le deuxième bloc est l'histoire et le troisième bloc contient les questions. Si vous suivez scrupuleusement les règles, les symboles que vous envoyez sont des réponses (correctes) aux questions. Peut-on dire pour autant que vous avez compris l'histoire ? Il semble évident que non, et donc Searle, l'auteur de l'argument, conclut qu'il en est de même pour un ordinateur dans la même situation.

Une des critiques les plus pertinentes de l'argument est que si l'homme dans la pièce ne comprend pas l'histoire, il faut se rendre compte que le système étudié n'est pas composé uniquement de l'homme. L'équivalent du cerveau que l'on étudie serait le système constitué de l'homme, des blocs de données et des règles de calcul. Selon certains, ce système là comprend l'histoire, au même sens qu'un homme comprend une histoire dans sa langue. Si l'on nie que la compréhension du système, on nie aussi la compréhension humaine. Curieusement, Searle répond de travers à cet argument : il inclue les données et les algorithmes dans le cerveau de l'homme, pour essayer de faire de l'homme le système entier. Or, ce que fait l'homme, que les règles soient dans son esprit ou non, c'est simuler une machine de Turing. De la même manière qu'un ordinateur n'a aucune idée du sens d'un programme exécuté sur une machine virtuelle, l'homme n'a aucune idée du sens des règles qu'il applique, même si elles sont mémorisées. Searle raisonne au niveau matériel, un niveau trop bas pour pouvoir détecter une éventuelle conscience.

Finalement, la chambre chinoise n'est qu'une machine de Turing comme une autre. Le rôle de la tête de lecture est joué par un humain, mais ça n'a aucune importance dans l'argumentation, sauf au moment où Searle se trompe de cible et s'interroge sur la compréhension de l'humain. Lorsqu'une machine de Turing calcule quelque chose, s'interroge-t-on sur ce que la tête de lecture en a compris ? La question posée par l'expérience de pensée semble donc revenir à cette bonne vieille interrogation : une machine de Turing peut-elle penser ?

Je suppose que j'ai agité des évidences, il me reste maintenant à me plonger dans les abondantes discutions à ce sujet pour essayer de trouver une argumentation convainquante en faveur de la chambre chinoise. Il me semble néanmoins que si ses objections sont valides, ce ne sont pas des objections à la thèse de l'IA forte, mais des objections à notre définition de la conscience.

J'ai commencé ce blog après avoir découvert les agrégateurs de fil, attiré par la possibilité de pouvoir réunir en un même endroit de nombreuses sources. Après quelques années d'utilisation, j'ai pu remarquer quelques tendances. En particulier, dans certains des fils s'accumulent les billets non lus.

• Si le fil ne contient pas l'intégralité des billets, j'ai tendance à ne suivre les liens que lorsque le titre est vraiment accrocheur.
• Si le fil contient un long texte argumenté, j'ai tendance à le laisser "pour plus tard" et à favoriser les billets courts parlant d'actualité.
• De la même manière, je délaisse des blogs qui pourraient pourtant m'intéresser, comme Drawn! ou Longevity Meme News parce qu'ils contiennent un résumé peu intéressant, mais des liens qu'il faut approfondir. Dans le cas de Drawn!, il faut aller voir les liens des artistes (avec des interfaces en Flash dans 90 % des cas) et dans le cas de LMN, il faut lire les articles pour espérer comprendre quelque chose.

Les blogs sont-ils destinés uniquement à contenir des informations superficielles sur des sujets d'actualité ? On pourrait penser que le problème principal consiste à faire le tri parmis la masse d'information pour extraire les billets intéressants, mais que se passe-t-il lorsque le nombre de billets intéressants est trop élevé ? J'ai tendance à stocker pour lire plus tard, « quand j'aurai le temps » mais le classement chronologique des blogs est peu adapté à ce genre de choses.

Alors, quel avenir pour le blog ? Des sites permettent déjà de centraliser les fils, de les étiquetter et de les partager. À quand des sites communautaires chargés, en plus, d'effectuer une synthèse de ce qu'on appelle la blogosphère ? Si ces sites existent déjà, n'hésitez pas à m'en faire part.

Dans un article sur Wired, Bruce Schneier propose de rendre les éditeurs de logiciels responsables (légalement) des bugs dans leurs logiciels pour, dit-il, créer un encouragement à améliorer leur qualité. Slashdot s'interroge naturellement sur les conséquences d'une telle responsabilité sur les logiciels libres, qui sont en grande partie développés par des bénévoles.

Un constat tout simple : actuellement il y a un encouragement financier à laisser des bugs dans son logiciel, à deux niveaux ; premièrement, il faut tenir les délais de livraison du produit, et donc plus on essaye de corriger les bugs plus on prend de retard ; deuxièmement, s'il reste des bugs génants on aura peut-être une mauvaise réputation, mais on pourra aussi vendre des mises à jour. Ce constat fait, on peut se dire qu'en rendant les éditeurs responsables, on crée un encouragement à corriger les bugs qui pourrait inverser la tendance et améliorer la qualité globale des logiciels qui, au moins pour les logiciels grand public, est catastrophique.

Qu'est-ce qu'un bug ? À priori, ce mot désigne n'importe quel comportement du logiciel qui n'était pas prévu par ses développeurs. Une observation importante : il est extrêmement difficile, et souvent impossible, de prouver qu'un logiciel fait ce que l'on veut, ni plus, ni moins. D'autant plus lorsque l'interaction avec l'extérieur (par exemple Internet) rend les choses imprévisibles. Il faut donc au minimum distinguer quelques catégories de bugs :

• Les bugs idiots, qui auraient pu être évités facilement par un étudiant en première année. Par exemple, un buffer overflow à cause de l'utilisation de strcpy au lieu de strncpy. Typiquement, ce sont des bugs qui peuvent être détectés par des logiciels, ou résolus en utilisant des langages de plus haut niveau.
• Les bugs de protocole, qui font trop confiance. Quelque part au niveau de la communication entre deux trucs, un développeur a supposé que la communication était fiable, qu'aucun des trucs n'était piégé, ou d'une manière ou d'une autre a permis que quelqu'un de mal intentionné abuse. Ces bugs sont plus difficiles à résoudre, il n'y a pas toujours de règles simples, mais avec de la discipline on peut s'en sortir.
• Les bugs compliqués, par exemple un système multithread où, dans certains cas très rares, une interaction entre deux bouts de code a des conséquences inattendues qui, si elles sont utilisées par quelqu'un de mal intentionné, peuvent être désastreuses. C'est compliqué parce qu'il y a deux niveaux de bug : d'abord il faut se rendre compte qu'un truc imprévu peut se produire bien que cela n'arrive jamais dans les tests, et ensuite il faut se rendre compte que cela peut être exploité (par exemple). On peut encore s'en sortir, mais cela prend énormément de temps, et donc coûte très cher.
• Les bugs impossibles à résoudre. Il y a des cas où on ne peut pas garantir que le programme fait bien toujours ce que l'on veut. Dans ce genre de cas, la solution de sécurité consiste à limiter les fonctionnalités pour reprendre un peu de contrôle. Par exemple, un navigateur équippé d'une machine virtuelle Java pose des limites à ce que peuvent faire des applets Java, de sorte que si les limites sont bien posées, les applets ne peuvent rien faire de catastrophique. Mais est-ce toujours une solution possible ? On ne peut pas faire de preuve formelle de tous les programmes, alors comment garantir que son programme fonctionne lorsqu'on n'a pas cette preuve ?

Évidemment, si l'on rend les éditeurs responsables des bugs, il faut tracer une limite quelque part. Quand on trouve un bug idiot dans un logiciel vendu très cher, c'est qu'il y a un problème. Quand l'utilisation d'un langage un peu strict aurait évité un bug, on peut s'en prendre à celui qui a décidé des outils à utiliser ou aux développeurs peu rigoureux. Mais pour les cas où une preuve est hors de portée, que faire ? Et pour le cas où le coût de détection des erreurs est trop élevé ?

Schneier parle d'un encouragement à corriger les bugs, pas d'une punition. Ça se comprend assez bien dans le domaine des logiciels pour le grand public, mais quand des vies sont en jeu, je suppose que les choses se compliquent. Un exemple intéressant, toujours dans les logiciels « communs » : Don Knuth, développeur de TeX, offre aux découvreurs de bugs un chèque dont la valeur augmente au fil du temps. Au début, la récompense était d'un cent, et elle a été doublée régulièrement depuis 1985. Évidemment, quand on a un chèque de Knuth, on ne l'encaisse pas : on l'encadre. Est-ce que Schneier pensait à ce genre de choses ? Il pensait plus probablement à rembourser les acheteurs de logiciels défectueux. Deux solutions différentes pour deux modes de développement différents ?

Francis Pisani s'interroge sur le futur du livre  liquide, en réseau ? Comme d'habitude, certains sont choqués par l'idée de désacraliser le livre en permettant, horreur, des modifications :

décidément tous ceux qui nous vantent les mérites des livres électroniques sont des gens qui... lisent peu, ou du moins lisent des livres qui ne sont pas des livres "compliqués". Ce sont des fondus d'informatique et de technologie, pas des universitaires, romanciers, poètes, et autres habitués des bibliothèques

Évidemment, je suis informaticien, et donc lecteur de livres simples. Néanmoins je m'interroge. Le problème des œuvres dérivées (et donc du remixage) est particulièrement présent dans les œuvres sous licences libres. Les auteurs permettront-ils que l'on modifie leurs œuvres ou qu'on en réutilise des morceaux (autrement qu'en tant que citation) ? Les lecteurs y verront-ils un intérêt ? Verrons nous une version dérivée de Crime et Châtiment où Rasklonikov ne tue pas la vieille ? Où il échappe à la justice grâce à sa finesse d'esprit et son self-control ? Ce problème n'est pas un problème technique mais un problème de copyright. On aurait tort de penser que sans numérisation massive le remixage est impossible. Le livre électronique facilite cela, mais les auteurs réticents ne sont pas contraints de s'y plier.

Une forme extrême du futur du livre (de fiction) nous est apportée par Star Trek avec son holodeck : les auteurs écrivent des décors et des personnalités, et les « lecteurs » sont actifs et forment l'histoire par leurs actions. Encore une vision technophile qui semble annoncer la mort du texte figé. Une version science-fictionnelle des Livres dont Vous Êtes le Héros. Nous avons là un autre problème : l'influence du lecteur sur le texte, poussée à l'extrême puisqu'il peut réellement agir sur l'histoire. L'avenir nous dira si ce genre de divertissement interactif a du succès (si on en croit le marché des jeux vidéos, la réponse est oui), mais il n'est pas nécessairement incompatible avec des histoires figées. Les deux ne peuvent-ils pas cohabiter ? Vouloir vivre une aventure au XIXième siècle n'est pas la même chose qu'apprécier une œuvre d'art.