...SITE EN COURS DE REALISATION... commentaires bienvenus

Ce site est un recueil de quelques-unes de mes réalisations TECHNIQUES des 25 dernières années. Les réalisations sont classées soit par ordre de publication sur ce site, soit par ordre chronologique, soit par thème. Le passage d'un ordre à l'autre se fait par les onglets ci-dessus.

L'objectif de ce site est de partager quelques idées ainsi que de montrer l'étendue des sujets qui me passionnent.

Depuis 2003, je travaille en tant que "CTO freelance" au travers de ma société amberMind, le plus souvent pour des startups en démarrage, dont le produit repose sur une innovation technologique réelle. A ce stade de développement la startup n'a généralement pas l'attractivité ni les moyens qui lui permettraient de recruter des profils seniors. Or c'est à ce moment, lorsque la page est encore presque blanche, qu'elle a besoin d'une expertise élargie, d'une bonne expérience, d'une grande ouverture d'esprit, et d'une vision technologique qui s'inscrit dans le processus de commercialisation. J'accompagne ainsi le fondateur pour réaliser une première version du produit et passer progressivement le relais lorsque la startup est en mesure de recruter.

Le langage Scol que j'avais développé chez Cryo présentait à l'usage de nombreuses lacunes qu'il était difficile de corriger dans un cadre de "compatibilité ascendante". Aussi, après la liquidation du groupe, j'ai eu un peu de temps et j'ai pu repartir sur une base plus simple en intégrant notamment le Garbage collector incrémental, les types faibles, les types paramétriques, une unification de types nettement plus efficace dans le compilateur, syntaxe plus légère, ...

De fil en aiguille, ce projet initialement conçu pour "se libérer l'esprit" est devenu progressivement utile lorsque j'ai lancé mon activité de conseil. D'abord simple outil de prototypage ou d'aide à la création de logiciels, il s'est avéré très utile, et une version simplifiée a même été intégrée dans le Nabaztag-tag en 2006.

Pour concaténer deux listes quelconque, on définira la fonction conc comme ceci :

La machine virtuelle est pourvue de librairies graphiques, réseau, audio, ainsi que openGL.

La machine virtuelle existe sur Windows, Linux et MacOS.

Pacman est une référence incontournable, l'archétype du jeu vidéo, même si je n'ai jamais vraiment aimé la version arcade ; je préfère un labyrinthe plus complexe, avec des parties un peu plus longues, un peu comme sur VCS2600.

En 1991 j'ai développé une version un peu aboutie sur Atari ST, en monochrome ; je l'ai ensuite déclinée sur plusieurs environnements, en conservant à chaque fois le gameplay et les labyrinthes. On pourra télécharger ci-dessous toutes les versions.

La première version, en 1991 sur Atari ST monochrome, en assembleur 68000:

Toujours sur ST et en assembleur 68000, en 1992, mais en couleur:

En 1992, version Powerboook intégrée en 'cheatmode' dans le Projet info, un mix d'assembleur 68000 et de langage C.

En 1993, version unix X11 en langage C:

En 2003, version en langage Métal:

Dernière en date, en 2012, version unix en mode texte (librairie ncurses) en langage C:

En déambulant un peu au hasard avec Philippe Ulrich dans les allées du CES 2007 à Las Vegas, nous découvrons Koo Hyoung Lee sur son stand (Neurosky), en train de faire une démonstration d'un casque capable de lire les pensées. Nous travaillons alors sur un projet de musique interactive, et il nous semble évident que cette interface cérébrale revet un grand potentiel pour ce projet : la musique pourrait ainsi s'adapter automatiquement à l'état émotionnel de l'auditeur, voire l'influencer.

Contact pris avec la société Neurosky, je mènerai diverses expériences, qui aboutiront à la réalisation d'un prototype fonctionnel (casque + logiciel de musique pilotée par les ondes cérébrales) présenté au Midem 2008. Ces casques ont la particularité d'embarquer à la fois la technologie Brainwaves et des écouteurs audio, car par un heureux hasard, dixit Philippe, "les oreilles sont proches du cerveau, et ce n'est sans doute pas un hasard". J'ai confié le design des casques à l'agence InProcess (qui a designé Nabaztag et la lampe Dal). Ces casques obtiendront un prix de l'innovation marketing en 2008.

La technologie de Neurosky est intégrée dans un petit module électronique bluetooth ; elle utilise trois capteurs : deux sont au niveau des oreilles et prennent la tension de référence, le troisième capteur se situe sur le front et extrait le signal cérébral.

En 2006, dans le cadre des mes recherches sur la musique interactive, je cherche à modéliser un système qui évolue de façon aléatoire, mais en respectant des contraintes pré-établies et des contraintes dynamiques, qui sont parfois contradictoires. C'est en fait un modèle théorique pour les oeuvres interactives : l'oeuvre évolue aléatoirement, dans les limites fixées par l'auteur, et en fonction des actions de l'utilisateur.

J'aboutis à un modèle qui s'avère être un calcul "Turing complet", et qui repose sur les notions d'états et d'observables. Le système calcule des probabilités pour chaque état, et effectue un tirage aléatoire pour sélectionner l'état observé (cf. réduction quantique). Les probablités sont déterminées par les contraintes pré-établies, sous formes de relations de contributions de probabilités. Comme il s'agit de "mixer des états", et que c'est un calcul, je l'appellerai "mix-calcul".

En 2003, j'assiste totalement par hasard à une performance de Michel Risse, "Instrument|Monument" dans la vieille gare de Longueville, lors des journées du patrimoine :

Cette vidéo montre les concepts, mais ne rend malheureusement pas du tout l'impression sonore du spectacle, qui était intense et prenante. Dans le jeu des musiciens/danseurs/acrobates, je perçois une dimension interactive (qui n'est peut-être qu'une impression), où la musique est le simple produit des interactions impromptues entre ces musiciens. Il semble y avoir trop d'aléas dans la durée des acrobaties pour que la musique soit prévisible, et pourtant tout s'accorde. La fin arrive comme un cheveu sur la soupe, frustrante : la musique aurait pu continuer indéfiniment, dans un renouvellement permanent.

Ce sont les bases de ce que j'entends par "musique interactive" : une musique qui se génère en fonction d'événements externes, et dont la durée se décide également de manière interactive. Cette interactivité n'empêche pas l'artiste de définir un cadre, des sons, une ligne mélodique, ... Tout ceci crée pour l'auditeur une expérience engageante et ludique.

On trouvera ci-dessous un prototype très simple de génération automatique et infinie de musique, réalisée par mixage dynamique de samples. L'interaction est alors réduite au minimum, l'auditeur pouvant juste arrêter la musique lorsqu'il le souhaite. Le mixage se fait sur le poste client, le serveur se contentant de fournir les samples comme un simple serveur http. Cette version utilise Flash. J'ai également une version Html5, mais seul Safari gère -avec un peu d'instabilité- le mixage de plusieurs sources audio.

Après quelques expérimentations en 2004-2005, le sujet intéressera Philippe Ulrich, mon complice de toujours, et nous créerons ensemble (avec Gilles Babinet) la société Mxp4 (aka. Musinaut) qui explorera ce sujet pendant deux ans avant de prendre une orientation sans rapport. Nous ferons diverses expérimentations autour de musiques connues, avec une interaction de l'auditeur pour choisir le style et la durée. Nous testerons également le pilotage de la musique par des capteurs de mouvement, des accéléromètres, et par les ondes cérébrales.

Techniquement, cette recherche aboutira à la création du format mxp4, qui permet de définir une musique interactive reposant sur un mixage dynamique de samples, le choix des samples étant le résultat de règles fournies par l'artiste et d'interactions externes. Le player mxp4 existera sous différentes formes : streaming avec player Flash, offline sur windows, mac, linux, windowsCE, symbian, iPhone.

La vidéo ci-dessus montre la version iPhone sur un cover du titre Oxygène4. L'interaction consiste à choisir des styles d'interprétation, chacun générant une musique infinie et différente à chaque écoute. Le bouton "lock" permet de stationner sur un style, alors qu'en mode normal, le style changera automatiquement au bout d'un certain temps. Bien qu'imprévisible, la musique est accompagnée de commentaires contextuels, sur l'instrumentation, le morceau original, ...

Au-delà de l'aspect technique, ce travail de recherche montrera la difficulté de donner du sens musical à cette interactivité ; si je bouge, la musique change : oui, mais comment pour que cela ait du sens ? C'est cette capacité à mettre en scène une interactivité musicale intéressante qui ouvre la porte à un nouvel espace de création musicale. Qui sont ces nouveaux artistes ? Le projet montrera que, de même qu'un bon photographe ne fera pas un bon cinéaste (pourtant on parle toujours de pellicule), de même un musicien traditionnel ne fera pas forcément un musicien interactif...

La première barrière est mentale et tient à l'exhaustivité de l'écoute. Autant un auteur de jeu vidéo revendique facilement la paternité de son jeu, alors qu'il n'a pas vu, et ne peut pas voir toutes les parties possibles, autant un musicien du début du 21e siècle veut pouvoir tout entendre avant de mettre son nom dessus.

La seconde barrière se trouve justement dans l'aptitude à créer un espace musical interactif qui ait du sens, et cette aptitude n'a pas de rapport avec les qualités d'un musicien ou d'un compositeur traditionnels. A contrario, un minimum de connaissance musicale semble indispensable.

En juillet 2011, le nouveau propriétaire du Nabaztag, Mindscape, dépose le bilan et annonce l'arrêt des serveurs Nabaztag. Il reste encore quelques milliers de lapins en vie, et il y a quelque chose de frustrant de voir que cet objet n'a pas connu l'exploitation qu'il méritait. Il présente globalement une ergonomie de répondeur téléphonique : il reçoit des messages, les lit, et comme il ne sait pas si quelqu'un les a écoutés, se met à clignoter. Lorsqu'on arrive chez soi et que le lapin clignote, on sait qu'un message est arrivé et on peut le relire en appuyant sur le bouton. Le choix des messages à recevoir se fait sur un site web, via des réglages complexes.

Pourtant ce lapin a été conçu pour avoir une véritable autonomie, et il dispose d'une puissance assez importante.

Ayant un peu de temps à ce moment là, je décidai de mettre en place un serveur alternatif, qui explorerait une toute autre voie. Ce sera "Nabizdead", néologisme issu d'un mélange de Nabaztag et Webisdead, en référence à une soirée à laquelle j'avais assisté début 2003.

Ce service propose une approche radicalement différente : il n'est pas nécessaire d'aller sur le site web, tout peut se faire depuis le lapin, en utilisant le bouton et les oreilles.

Le service fonctionne comme un twitter vocal : le lapin pioche dans des flux de messages courts, et les lit à voix haute. Il invite à noter les flux (en levant ou en baissant les oreilles à la fin du message) ce qui influencera le choix des messages suivants. De même il propose régulièrement de s'inscrire à de nouveaux flux. Les tags RFID peuvent être associés à un flux.

Le micro est en fait ouvert en permanence, et c'est la détection d'un bruit qui déclenche la lecture d'un nouveau message par le lapin.

Par ailleurs, le lapin donne l'heure, et retient ses heures de coucher et de réveil ; on le couche en baissant ses deux oreilles.

En allant sur le site, on peut créer soi-même des flux et poster des messages. On visualise alors l'audience de ces messages et les notations des lapins auditeurs. Une API permet de poster automatiquement des messages sur ces flux.

Le service a rencontré un petit succès, tant sur le nombre de lapins inscrits (plus de 3000 début janvier 2012), que sur le nombre de flux créés par les internautes (plus de 150, dont la plupart générant automatiquement des messages via l'api, pour donner la météo, les titres des journaux, les résultats sportifs)

La liquidation rapide de Mindscape, et son rachat également rapide par Aldebaran, qui a rouvert les serveurs officiels, réduit la nécessité de serveurs alternatifs, mais l'expérience reste intéressante.

Techniquement, le service ouvre de nouvelles perspectives : l'hébergement jugé trop lourd par Mindscape est ici remplacé par un serveur mutualisé à 60 euros l'année, qui pourrait accueillir sans problème les quelques 10.000 lapins encore en service. Le lapin gère lui-même son TTS (synthèse vocale), en appelant de manière autonome des services TTS sur internet. Pour cela il a suffi de modifier le bytecode nominal.

Ergonomiquement, le service offre une vision communautaire, où selon le principe éprouvé de Twitter, tout le monde génère très facilement du contenu. L'interaction se fait directement avec le lapin en exploitant ses quelques entrées-sorties de manière très intuitive. Enfin le lapin possède une voix unique : il n'y a plus de schizophonie.

Fin 2005, je rencontre Fabien Vial et Pierre Varrod, qui lancent un projet de guide touristique sur pda/gps, à destination des grands hôtels parisiens. Il s'agit d'une carte interactive, tactile, avec beaucoup de contenu (culture, shopping, restaurants, ...) en 4 langues, sur un PDA équipé d'un GPS.

Plus forcément très original en 2012 à l'heure de l'iPhone, mais on est fin 2005, et le produit sera prêt en juin 2006.

Je réalise la totalité du soft, en C++ sur WindowsCE, sur un terminal cible Fujitsu N520.

J'ai découvert l'existence de 'Chocolate fix' en cherchant un cadeau pour une personne qui aime le chocolat. C'est un casse-tête édité par la société Thinkfun. Il s'agit de placer 9 "chocolats" sur une grille 3x3 en respectant une série de contraintes, qui forment un "problème". Chaque contrainte définit la position relative de chocolats, de couleurs ou de formes ; en effet les 9 chocolats sont le produits de trois couleurs (chocolat au lait, chocolat noir, fraise) et de trois formes (carré, rond, triangle). Un petit livre réunit une quarantaine de problèmes.

Le jeu est très amusant, mais on arrive vite à bout des problèmes proposés, et ceux-ci sont plutôt trop simples.

L'idée récréative est donc de parvenir à générer automatiquement des problèmes, et notamment des problèmes difficiles. Quel algorithme ? quelle complexité ? Il faut que le jeu de contraintes soit minimal, c'est-à-dire qu'il autorise une et une seule solution. J'ai trouvé une technique qui permet de générer trois niveaux différents, selon le type de contrainte produite. Sur un processeur Intel core i7-2620M à 2,7GHz, utilisé en mono-thread, la génération des problèmes prend entre 1 et 6 secondes selon la difficulté.

L'interface ci-dessous permet de visualiser ces problèmes et leur solution. Saurez-vous les résoudre ? Mais surtout, comment feriez vous le programme qui les génère ?

Après le succès rencontré par le Nabaztag, la société Violet développe un nouvelle version, plus puissante, avec la même équipe : Philippe Debadier pour l'électronique, et moi-même pour l'embarqué et le coeur du serveur.

Peu de choses le distinguent visuellement de son aîné : un nombril cache l'apparition d'un micro qui lui permet d'écouter et d'enregistrer du son. Il enferme aussi sous son nez un capteur RFID. Cependant, la puissance s'améliore avec un ARM à 6Mips, 128Ko de ROM pour le programme et 1Mo de RAM. Pour gagner en coût de fabrication, il n'y a pas de mémoire flash, et la carte wifi est de type SoftMac : contrairement au Nabaztag, le Nabaztag-tag doit donc implémenter dans son firmware l'intégralité du protocole wifi (connexion, encodage des trames, ...), la carte SoftMac traitant surtout la partie radio et le cryptage.

Le logiciel embarqué est écrit en C. Il gère les différents périphériques. Il gère également la carte wifi, via un driver écrit par un étudiant génial, Sébastien Bourdeauducq que j'ai découvert un peu par hasard sur le net dans les pages du projet opensource Prism54. Bien qu'il soit alors en maths spé, en train de préparer puis de passer les concours, il réalisa le driver parfait.

Une nouvelle fois, il a semblé naturel d'intégrer une machine virtuelle pour traiter le comportement fonctionnel de l'objet. D'abord tenté d'intégrer une VM java, il fallut partir sur une solution mieux maîtrisée en termes de délai, et j'intégrai donc en quelques semaines une version simplifiée de la VM Métal que j'avais développée début 2003.

Cette machine virtuelle utilise un langage de type "langage fonctionnel" statiquement typé, offrant une grande souplesse dans la création des calculs, et disposant d'un garbage collector. De fait, la couche réseau (arp, ip, udp, tcp, dns client, dhcp client et serveur, http client et serveur) est implémentée dans ce langage.

Au démarrage, le lapin possède un premier bytecode (appelé bytecode de boot), qui prend en charge la connexion au wifi. Une fois connecté, le lapin télécharge le bytecode nominal ; c'est ce bytecode qui détermine le fonctionnement du lapin. Ce fonctionnement est donc très libre, même si la société Violet ne l'a pas fait beaucoup évoluer par la suite. Le lapin est notamment capable de communiquer directement avec tout serveur, sans passer par le serveur "principal".

Le bytecode est généré par un compilateur, qui est lui-même intégré à un simulateur.

En 2004, la société Violet renonce à commercialiser la lampe DAL et se lance dans un projet d'objet communicant grand public. Après avoir hésité entre une fleur et une peluche, le projet s'arrête sur un lapin stylisé en plastique blanc. Il faudra un peu plus d'un an entre le début du projet et sa commercialisation en juin 2005.

L'électronique est réalisée par Philippe Debadier, ingénieur à l'école Sudria, sur la base d'un microcontrôleur 8 bits Microchip. Je m'occupe pour ma part du logiciel embarqué et de la partie serveur. Le système dispose de 3,5Ko de RAM et 48Ko de ROM pour stocker le programme, et 1Mo de flash utilisée comme mémoire de masse pour stocker la configuration et les données reçues du serveur ; on est donc face à une puissance comparable aux ordinateurs 8 bits du début des années 80, avec une RAM particulièrement faible.

Le logiciel embarqué est écrit en C. Il gère les différents périphériques ainsi que la carte wifi, au format pcmcia. La carte Wifi est de type 'Hardmac', ce qui signifie que l'essentiel du protocole wifi est traité dans la carte elle-même, notamment les mécanisme de connexion, le cryptage, l'encodage des trames réseaux. La RAM ne permettant pas le stockage complet des trames réseaux, celles-ci sont extraites (ou transmises) octet par octet de la carte pcmcia. Malgré tout, le firmware intègre une couche réseau relativement complète : arp, ip, udp, tcp, dns client, dhcp client et serveur, http client et serveur. En effet, comme pour la lampe DAL, la configuration se fait en mode wifi adhoc au travers d'un petit serveur http intégré ; ce mode s'active lorsqu'on appuie sur le bouton du lapin en le branchant.

Le firmware intègre également une machine virtuelle rudimentaire, qui lui permet de recevoir des bytecodes du serveur ; ceci permet d'une part de sécuriser le bon fonctionnement de l'objet, et d'autre part de faire évoluer le comportement interne de l'objet après le début de sa commercialisation. En effet, au début du développement du produit, nous n'avions pas les idées très claires sur les services qui seraient proposés.

Cette machine virtuelle utilise un langage de type assembleur 8 bits, auquel sont apportés quelques conforts rencontrés sur le processeur 16 bits motorola 68000 (Macintosh, atari ST, amiga) : il y a notamment 16 registres. Certaines fonctions de ce processeur permettent de piloter les leds, les moteurs, les capteurs optiques et le circuit audio. Le nom de code de ce langage est VASM.

Une fois connecté au wifi, le lapin télécharge un premier bytecode, puis régulièrement, interroge le serveur en http, et reçoit éventuellement un nouveau bytecode, qui remplacera le précédent

Le code source du logiciel embarqué n'a à ce jour pas été diffusé par ses nouveaux propriétaires, c'est pourquoi on ne le trouvera pas encore ici.

Le bytecode est généré par un serveur java qui s'appuie sur des templates de sources VASM, qui sont paramétrés à la volée, puis assemblés vers le bytecode.

En 2003, je suis mis en relation avec Olivier Mével, qui s'apprête à créer la société Violet sur le thème des objets pervasifs et de l'intelligence ambiante. Je vais l'aider pendant 3 ans, comme co-fondateur et CTO externe, en prenant en charge l'ensemble des sujets logiciels ; c'est le côté amusant de ce genre de startup : pendant plus d'un an, il faudra tout faire. Violet internalisera ensuite progressivement les aspects web et serveurs, mais touchera peu aux aspects embarqués.

Le premier objet est la Lampe DAL. Pourquoi une lampe ? parce que "la lumière, c'est la vie" me confiera le designer. Cette lampe sera développée en moins de 4 mois. En son coeur se trouve une électronique basée sur Linux. Elle communique avec un serveur Java. Pour garantir l'intégrité du fonctionnement, le logiciel embarqué prend la forme d'une machine virtuelle, qui télécharge des applis du serveur, et les fait fonctionner simultanément dans la lampe. Le langage utilisé est un langage Xml spécifique, qui permet de faire des calculs simples et d'accéder aux périphériques : 9 leds RGB et des capteurs de toucher.

L'objet est connecté à des sources de données (météo, mail, bourse, ...) qu'il reçoit du serveur ; les programmes s'appuient sur ces sources pour générer des animations lumineuses.

L'objet est connecté par wifi. La configuration se fait en mode wifi adhoc (avec un commutateur sous la lampe pour choisir le mode adhoc) au travers d'un petit serveur http intégré.

Le serveur permet de configurer ses services, mais aussi d'uploader ses propres programmes.

La lampe DAL sera présentée en 2003 à Beaubourg, au salon Batimat, puis à Apple Expo.

En 1996, alors que le développement du Deuxième Monde touche non sans mal à sa fin, la nécessité d'un "middleware" dédié aux mondes virtuels apparait de manière évidente pour pouvoir exploiter plus avant le filon. Nous lançons donc un projet de R&D en ce sens qui aboutira à la création de la technologie Scol, au sein de la filiale Cryonetworks.

La première présentation aura lieu début 1998, autour d'un univers baptisé Cryopolis, designé par Laurent Doubre.

La technologie comprend deux aspects très différents :

• une machine virtuelle dédiée à l'application d'applications réseau multimédia, reposant sur le langage Scol, et fonctionnant aussi bien côté serveur que côté client. Sous l'influence de mes stages au MIT et à l'Inria (voir plus bas), le langage Scol ressemble aux langages fonctionnels comme Id ou Caml, avec une syntaxe simplifiée à destination des développeurs traditionnels.
• une recherche autour des questions de distribution : chaque fonctionnalité est encapsulée dans un module qui regroupe à la fois un code serveur et un code client. Cette manière de découper l'application "verticalement" ouvre la voie à un outil d'intégration graphique (le SCS) dans lequel les modules de fonctionnalités sont connectés graphiquement par un utilisateur ignorant tout des questions pourtant délicates de distribution. Cette recherche aboutit au concept "user-flow", qui fera l'objet d'un papier au GT-RV99 de Laval.

Même la Fnac s'y est mis, en 2000, bien avant le buzz "second life" :

Cryopolis en 2000, une communauté avec 1.000 DAU, tous en liaison modem :

Cryonics, l'outil simplifié de création de monde virtuel. L'hébergement est local, sur le PC de l'utilisateur (qu'il ne faut donc pas éteindre); Scol, pionnier du P2P ?

Une présentation de Cryonetworks en 2000, qui est alors une société côtée de 180 personnes ; la vidéo montre les jeux online (Venise et Mankind) et Cryopolis :

Après la disparition du groupe Cryo, en 2002, j'ai récupéré les droits de la technologie Scol, et l'ai passée en opensource.

A l'occasion du salon Imagina 97, Philippe Ulrich et moi élaborons un papier prospectif sur les mutations que la numérisation va provoquer.

Il y est question d'information, de copie, d'ubiquité ; on pourra même y voir une introduction imagée au lambda calcul. La fin du papier annonce un projet encore en gestation, l'expérience Magma qui donnera naissance à la technologie Scol.

Le Menta, fusion de l'information et de son traitement, doué de mobilité et d'ubiquité, reste encore un sujet de prospection.

En 1995, la nouvelle société de Philippe Ulrich, Cryo Interactive, me demande de l'aider à réaliser un projet révolutionnaire, à l'intersection de deux sujets alors dans l'air du temps, la 3d et les réseaux. Il s'agit d'un des tous premiers mondes virtuels, le Deuxième Monde, qui reproduit un Paris virtuel dans lequel les utilisateurs se rencontrent au travers d'avatars.

J'interviendrai en réalisant deux des éléments de ce "jeu" : le moteur 3d et le serveur.

Le moteur 3d temps réel, à une époque où les cartes 3d n'existent pas encore, doit être capable de gérer des scènes étendues, contenant un nombre élevé de polygones, contrairement aux jeux de l'époque (cf. Descent ou Quake) qui gèrent un espace clos. Ecrit en assembleur, selon l'algorithme du scanline, il utilise une technique originale de gestion du mapping des textures : en effet, le mapping des textures nécessite théoriquement deux divisions par pixel, ce qui est trop coûteux en 1995 pour du temps réel. L'astuce consiste à passer en logarithme (via des tables de conversion) et à remplacer alors ces divisions par des soustractions.

Une première version sortira en 1997, suivi rapidement d'une V2.

Le serveur fonctionne sous Unix, et peut gérer quelques centaines de participants simultanés. En 1995, internet n'est pas encore un réseau grand public, et le jeu est alors initialement prévu pour fonctionner sur un réseau télématique dédié ; mais avant la fin du développement, les modems et les FAI se répandent, et le jeu utilisera finalement bien le réseau internet.

On peut revoir aujourd'hui les scènes 3D de l'époque grace à un prototype de monde virtuel s'appuyant sur la technologie Scol, et réalisé à la même époque.

En 1996, j'ai l'occasion d'effectuer mon stage de DEA à l'Inria, dans l'équipe PARA de Jean-Jacques Lévy, sur le sujet "Sécurité et processus mobiles". C'est l'occasion de découvrir le pi-calcul (un calcul théorique comme le lambda-calcul, dédié à la distribution), et le join-calcul, développé par l'équipe PARA et qui permet une mobilité des processus (en cours de fonctionnement). Le stage aborde les questions de cryptographie et de droit d'accès dans ce contexte théorique très particulier.

En 1994, j'ai l'occasion de passer quelques mois au MIT, dans le laboratoire Computation Structures Group du professeur Arvind. Cette équipe a mis au point Monsoon, un ordinateur Dataflow, en partenariat électronique avec Motorola. Le Dataflow est un modèle de programmation parallèle particulièrement efficace : "Imagine a computer program that can run on thousands of processors with no modifications and even greater performance. Scalability and programmability would be virtually unlimited".

Mon travail a consisté à ajouter de l'interactivité à cette machine qui en était totalement dépourvue. En ajoutant une interface X11, il a été possible d'explorer de nouvelles fonctionnalités, comme la parallélisation d'une feuille excel, mais aussi ce qui fut sans doute le premier et le dernier casse-brique parallèle de l'Histoire.

La machine se programmait dans un langage fonctionnel, appelé "Id", très élégant, très efficace, et parfaitement adapté au parallélisme.

En 1994, à une époque où les cartes 3d n'existent pas, je cherche des techniques pour optimiser le calcul d'objet en 3d. J'imagine une technique de précalcul de l'ordre d'affichage des polygones, qui débouche sur une étude théorique qui me semble intéressante.

Quand un objet est convexe le tri des polygones est simple : on affiche d'abord les polygones dont on voit la face intérieure, puis les polygones dont on voit la face extérieure.

Quand un plan sépare un objet en deux, on affiche d'abord les polygones qui ne sont pas du même côté de ce plan que l'observateur, puis les polygones qui sont du même côté du plan que l'observateur

Fort de ces ceux observations, on démontre qu'on peut toujours décomposer un objet comme une arborescence de ces deux cas, et que de manière inattendue, des objets apparemment complexes se réduisent à une succession du premier cas.

Sur la lancée du programme Reverse, en 1987, j'imagine une technique de résolution de coup très simple, qui s'avérera différente et meilleure que le minimax. J'en ferai une première implémentation sur Atari ST en 1990, mais ce n'est qu'en 1994 que j'aurai le bagage mathématique pour analyser cette solution.

Dans ce type de problème, on utilise une fonction d'évaluation qui attribue un score à une position de jeu. Pour une recherche à 5 demi-coups par exemple, on cherche le coup qui garantit la meilleure valeur de la fonction d'évaluation 5 demi-coups plus tard, quels que soient les coups de l'adversaire. La technique de résolution classique s'appelle Minimax et s'accompagne d'une variante optimisée appelée "alpha-bêta".

Dans la méthode ici décrite, on procède par dichotomie : on choisit une valeur de la fonction d'évaluation, par exemple V, et on se demande s'il existe un coup qui permet de garantir cette valeur. Pour n demi-coups, on joue le premier demi-coup au hasard, puis le second demi-coup au hasard, jusqu'au n-ième demi-coup. On regarde alors la position obtenue. Si son score est supérieur à la valeur V, on modifie le dernier coup de l'adversaire ; si on les a tous essayés, on remonte de deux demi-coups et on modifie donc l'avant dernier coup de l'adversaire. Puis on rejoue la partie au hasard jusqu'au n-ième demi-coup. Si le score est inférieur à la valeur V, on modifie le dernier coup du joueur, etc. En remontant de deux demi-coups pour modifier un coup de l'adversaire, il arrive finalement qu'on revienne avant la position actuelle. Cela signifie que la valeur V est garantie, et que le premier demi-coup du joueur actuellement tenté est le bon. Si c'est en modifiant un coup du joueur qu'on revient avant la position actuelle, cela signifie que le valeur V ne peut être garantie. En appliquant une dichotomie sur les valeurs V, on détermine précisément le meilleur coup possible et la meilleure valeur V garantie.

Tout ceci est expliqué en détail dans le papier ci-dessous.

A l'arrivée à l'X en 1992, nous sommes contraints d'acquérir un portable apple (powerbook 145), sur lequel nous devons réaliser un projet informatique sur un sujet éventuellement libre. Intéressé par les problématiques de Système d'exploitation, de multi-tâche préemptif, et par l'évolution des interfaces graphiques, je réalise un tel système sur Mac. A l'époque, les systèmes courants (Mac, Windows 3.1) n'étaient pas préemptifs, ce qui signifie que seule la fenêtre qui avait le focus travaillait réellement ; les autres étaient gelées. De même, les applications devaient rendre elles-même la main au système lorsqu'elles avaient fini chaque traitement, sans quoi le système lui-même était gelé. Dans un système préemptif, le système reprend la main d'office, avant de la redonner plus tard.

Ce projet reconstruit from scratch (juste en récupérant l'adresse de la mémoire vidéo) un environnement graphique monochrome avec fenêtre et souris, au-dessus d'un gestionnaire de processus (avec scheduler et multi-threading).

Plusieurs démonstrations sont intégrées : un calcul de l'ensemble de Mandelbrot (qui démontre visuellement que plusieurs fenêtres travaillent simultanément), un othello, un moniteur de processus et de mémoire, quelques démonstrations de concurrence (le classique "parking", avec une seule entrée, une seule sortie, et plusieurs voitures), ... et un cheatmode, accessible sur quintuple click (un pacman développé initialement sur Atari ST).

Les copies d'écrans ci-après ont été réalisées sur l'émulateur Mess en mode Mac SE/30 (car il faut un 68030 avec un écran monochrome). L'écran du Powerbook 145 était sensiblement plus large, et un peu plus haut (640x400 au lieu de 512x384), ce qui explique que certaines images sont tronquées.

Début 1994, je découvre les "émulateurs", ces programmes qui transforment les ordinateurs du moment en ordinateurs des années 80. Apple ][, Commodore 64, Zx Spectrum, la plupart des machines sont déjà traitées. Toutes ? non car l'ordinateur français de référence, le To7, résiste, et n'a pas encore suscité de vocation, sans doute car inconnu hors de France. Je m'attèle à la tâche et fais ainsi revivre ma première machine. C'est aussi ma première machine virtuelle ; je ne sais pas encore qu'il y en aura beaucoup d'autres.

La première version est réalisée sur Unix/X11 (Linux, mais pas seulement). Il faudra attendre 1995 pour une version Ms-Dos, environ 2000 pour une version Windows puis PocketPC.

Un compagnon indispensable de tout émulateur est l'outil de récupération des logiciels ; en l'occurrence, l'outil qui récupère les logiciels stockés sur cassettes audio. On numérise une cassette (par exemple au format 44.100Hz, 8 bits, mono), puis un programme s'efforce de repérer les sons qui correspondent à des 1, et ceux qui correspondent aux 0. A partir de là, en connaissant le format d'encodage des données du To7, on reconstitue l'information complète. C'est en théorie assez simple, mais les bandes ne sont pas toujours bien conservées, et l'outil va alors se tromper sur certains bits. Comment retrouver lesquels ? La meilleure technique que j'ai trouvée consiste à développer deux outils de récupération utilisant deux techniques distinctes (par exemple l'un sur l'analyse fréquentielle, l'autre sur l'analyse temporelle) : en cas d'erreur à un endroit de la bande, les deux techniques donnent généralement deux résultats différents pour cette partie de la bande, ce qui permet de localiser très précisément l'erreur.

Une version particulière de l'émulateur a été développée pour la Bibliothèque Nationale de France, dans le cadre de son activité de conservation du patrimoine logiciel, et notamment du fonds très volumineux des logiciels éducatifs du plan Informatique Pour Tous. Ce fonds est ainsi accessible aux chercheurs désireux de consulter ce glorieux patrimoine.

En 1988, Ere Informatique me demande de porter un de ses jeux à succès, Macadam Bumper (de Rémi Herbulot) sur les ordinateurs Thomson du moment. Disposant de très peu de documentation sur l'original, c'est ici une adaptation très libre. Il s'agit d'un flipper constructible.

C'est un mélange de Basic et d'assembleur, avec très peu de Basic ; il est assez difficile d'extraire le code source en basic, autrement qu'en le chargeant sur un émulateur. Il était distribué sous forme de disquette 3 pouces 1/2

Ce premier programme est réalisé en 1986, à l'age de 14 ans, et repéré par Philippe Ulrich, qui est alors directeur de la création de Ere Informatique, un éditeur français qui s'appuie sur un réseau d'auteurs indépendants. Il est publié sous le label 'Gasoline Software'.

Ce programme est écrit pour les ordinateurs Thomson (To7, Mo5), dont j'ai plus tard écrit des émulateurs. C'est un mélange de Basic et d'assembleur. Il était distribué sous forme de cassette audio.