Pierre-Marie Baty — informaticien

Aussitôt après mon BTS électronique, je fus recruté par la société Digital-E créée par mon professeur William Cano, docteur Cnam, et on me donna pour mission de créer le prototype d'une enceinte acoustique numérique. Il s'agissait d'équiper une attraction du Grand Parc du Puy du Fou (le "Chemin Creux") d'un système de sonorisation haute-fidélité, résistant aux perturbations électriques, en minimisant la câblerie nécessaire - si possible en s'intégrant dans les réseaux existants. Il fut choisi de transporter le son numérique sur le réseau Ethernet : soit celui-ci était préexistant, soit il serait facile à étendre.

Afin de garantir que toutes les enceintes utiliseraient le même logiciel en même temps, il devit nécessaire de leur faire télécharger leur logiciel à chaque démarrage. Depuis quelques années Linux supportait le protocole BOOTP, qui permettait aux firmwares PXE des cartes Ethernet, lancés en tant qu'extension du BIOS, de télécharger par le réseau le noyau du système d'exploitation à démarrer. Il fallut pour cela recompiler un noyau Linux 2.4 sur mesure, c'est-à-dire monolithique, embarquant tous les pilotes nécessaires aux différentes variantes du prototype (carte mère, carte Ethernet, carte son), et le mettre à disposition des prototypes sur le réseau derrière un serveur TFTP.

Une fois ce noyau démarré, il fallait ensuite lui faire télécharger un disque initial (Initial Ramdisk ou "initrd") par TFTP (Trivial File Transfer Protocol) contenant un client de partage de fichiers et un lecteur MP3 qui allait chercher sa playlist sur un partage réseau, monté automatiquement par le script d'initialisation du système (init). Je ne me souviens plus s'il s'agissait d'un client Samba, NFS ou FTP (je pense qu'il s'agissait d'un client NFS).

Il se trouve que j'utilisais déjà Linux et OpenBSD quotidiennement - essentiellement par snobisme. On m'a pris au mot : j'ai relevé le défi, et j'ai réussi. Ce fut ma première expérience professionnelle dans l'informatique, et j'ai beaucoup appris.

Cette réalisation est à remettre dans le contexte l'époque : les années 1999-2000 furent l'émergence de Linux dans l'industrie. Les techniques décrites ici étaient relativement pionnières dans un contexte industriel.

J'exprime ici un regret. Durant mon passage dans cette entreprise, je ne fus pas à la hauteur de la mission suivante - qui n'avait rien à voir - et je regrette de n'avoir pas eu la maturité à l'époque pour m'affirmer et dire à M. Cano qu'elle ne m'inspirait pas : je lui ai fait perdre son temps, j'ai perdu le mien, et ce fut ma faute. La leçon est apprise.

Au début des années 2000, les connexions Internet étaient lentes et coûteuses, et les jeux vidéos de tir en vue subjective n'offraient pas de véritable défi aux joueurs hors ligne car les adversaires générés par ordinateur étaient gouvernés par des algorithmes simples.

Avec quelques amis passionnés, en nous réunissant sur des forums Internet hautement spécialisés, nous entreprîmes à titre bénévole d'améliorer l'intelligence artificielle de ces jeux en exploitant les APIs laissées par leurs créateurs. Le résultat de nos travaux fut des "bots" (robots adversaires).

S'appuyant sur le cadriciel open source laissé par Jeffrey "botman" Broome (créateur du HPB-Bot), mon ami Markus "Count Floyd" Klinge créa le fameux POD-Bot (qui domina le segment du jeu hors ligne de Counter-Strike, mais nécessitait des annotations très précises de la carte), Johannes "@$3.1415rin" Lampel créa ses JoeBot (qui utilisaient des réseaux neuronaux de 300 cellules pour le choix des armes), Stefan Hendriks créa le RealBot (qui annotait automatiquement les cartes par imitation), [mes excuses aux autres que je ne peux mentionner ici pour rester bref: Tobias "Killaruna" Heimann, William Van Der Sterren, Wei Mingzhi...] ; quant à moi-même, je créai le PMBot - renommé ensuite RACC, seul d'entre ces bots capable de naviguer et combattre de façon crédible dans un univers virtuel non annoté.

Entièrement programmé en langage C, supportant 5 jeux différents, ce bot fut un réel succès pour les joueurs hors ligne souhaitant un adversaire virtuel sur des cartes non annotées, et même sur certaines des cartes les plus populaires de Counter-Strike (ex: de_dust2). La navigation autonome par ray casting leur donnait un "feeling" très différent des autres bots, lesquels suivaient des points de passage prédéfinis. En revanche, mon utilisation des chaînes de Markov pour générer du contenu de discussion crédible (à la manière de ChatGPT 20 ans plus tard) ne fut pas un succès : le corpus d'entraînement étant les messages tapés par les joueurs humains eux-mêmes, celui-ci n'était pas d'une très grande qualité : il aurait fallu pré-entraîner ce modèle sur un vaste corpus filtré.

Je garde une grande nostalgie de cette époque où l'enthousiasme, l'émulation et un travail acharné nous transformèrent en quelques années en programmeurs affûtés et extrêmement compétents. J'en ai gardé une affinité certaine pour les solutions techniques innovantes et transgressives.

Le jeu massivement multijoueur en ligne (MMORPG) médiéval-fantastique "The 4th Coming" (T4C), dont l'exécution fut sous-traitée à Vircom Interactive, fut un produit d'appel gratuit lancé par la société GOA en Europe pour rassembler une communauté de joueurs à qui vendre ensuite des abonnements au jeu Dark Age of Camelot, qui était alors en développement. Leur idée fonctionna moins bien que prévu : une forte affinité se créa parmi les joueurs de GOA pour ce jeu objectivement fait à la va-vite, assez laid, mais où les possibilités non contraintes permettaient tous les styles de jeu, dont le jeu de rôle en ligne. Ainsi, quand GOA décida de fermer les serveurs T4C, toute une communauté de joueurs resta sans équivalent pour son besoin d'un support de jeu rôliste.

Après avoir fait le tour des possibilités existantes et constaté ce manque, je fondai alors le serveur Aegir à titre d'initiative bénévole pour fournir à cette communauté un moyen d'exprimer sa passion créative. Initialement hébergé derrière un modem ADSL, il apparut rapidement qu'il fallait une infrastructure sérieuse et Aegir fut bientôt hébergé sur un serveur dédié GNU/Linux hébergeant le site web, le forum, les outils d'administration, et faisant tourner une machine virtuelle Windows Server 2003 laquelle servait de plate-forme d'exécution au logiciel serveur du jeu.

Or, il se trouve que T4C était affecté par de nombreuses failles de sécurité exploitées par des tricheurs de tout acabit pour gagner indûment des avantages sur leurs concurrents. Après avoir constaté et subi le problème sur Aegir, j'ai forcé tous les joueurs se connectant au serveur à utiliser un double proxy : côté client, celui-ci vérifiait sa propre authenticité (l'exécutable était encrypté par une version privée de PESpin), vérifiait ensuite l'authenticité du logiciel de jeu, et encryptait tout le trafic réseau avec l'algorithme XTEA (chiffreur par blocs). Côté serveur, un second proxy, symétrique, réalisait l'opération inverse. Le serveur Aegir fut ainsi le seul serveur T4C protégé contre les nuisances ayant parasité ce jeu pendant de longues années.

Constatant ensuite l'impossibilité de faire évoluer les fonctionnalités du jeu (du moins sans accès au code source, dont le prix étaint inabordable pour une activité bénévole), dans l'intérêt de la communauté rôliste, j'ai poussé plus avant le principe de ce double proxy en lui faisant décoder et réencoder les paquets d'information côté client et côté serveur. Ceci permit de modifier et d'étendre le protocole réseau, et par conséquent les fonctionnalités du jeu. Le serveur et le client officiels ne recevaient alors que les paquets qu'ils étaient capables d'interpréter ; tout le reste était géré par mes proxies côté client et côté serveur. Je pus rajouter, par exemple, des effets visuels au jeu par surimpression (nouvelles interfaces comme la possibilité d'écrire des livres ou des parchemins et les stocker dans des coffres), des nouveaux types de sorts, d'ennemis (comme des archers), d'effets visuels (intempéries), jusqu'à la modification périodique automatique des cartes du monde (4 saisons) : ainsi s'affichaient l'hiver de la neige et des arbres morts, l'été de la sécheresse, au printemps des arbres en feuilles, en automne de la pluie, etc. Les joueurs ne se privaient pas d'exploiter magnifiquement ces possibilités d'enrichir leur jeu de rôle.

Enfin, toujours dans le but d'épargner au maximum mon temps, je développai toute une suite d'outils à destination des maîtres de jeu pour leur permettre de gérer les besoins de la population du serveur (qui atteignait 100 connectés simultanément en période de pointe, ce qui était considérable pour l'époque). Certains dans l'équipe étant eux-même programmeurs, je leur fournis une API pour ajouter leurs propres fonctionnalités au serveur par des DLL optionnelles. Ainsi, l'un des animateurs d'Aegir fut l'auteur du module ajoutant des loup-garous à l'univers du serveur. J'ajoutai aussi un module IRC qui liait le canal de discussion principal du jeu à un salon IRC, ce qui permettait aux joueurs de communiquer depuis le jeu lui-même avec les visiteurs du site, où un client IRC en Java permettait cet échange.

L'administration d'Aegir pendant toutes ses années d'activité a nécessité de recruter, de sélectionner et d'entretenir une équipe de modérateurs, d'animateurs et de maîtres de jeu, et m'a beaucoup appris sur la psychologie humaine dans la gestion d'une équipe. Des anciens joueurs me recontactent encore aujourd'hui, 20 ans plus tard, pour m'exprimer leur nostalgie de cette époque, et on trouve encore la trace de cette nostalgie en 2025 sur certains forums Internet dédiés à T4C.

En 2002, un accident de voiture me priva de moyens de locomotion. Je me fis embaucher à la menuiserie voisine (Marquis) en tant que préparateur de programmes pour leur nouvelle machine à commande numérique italienne Masterwood MW310. Lorsque je suis arrivé dans l'entreprise, chaque programme qui devait alimenter cette machine était unique, et leur production prenait un temps considérable ; même si les programmes déjà créés étaient conservés dans un dossier, les possibilités de réutilisation restaient limitées.

Après quelques recherches me familiarisant avec le langage G-Code, je réalisai sur mon temps libre ce logiciel pour mon employeur. Il permettait de créer et de modifier des gabarits de programmes faisant appel à des sous-programmes bien définis (un sous-programme par tâche), et de leur adjoindre des possibilités paramétriques qui les rendaient réglables directement sur la machine.

Le langage G-Code employé par Masterwood possède une limitation extrêmement restrictive : l'imbrication des conditions n'est pas possible. Pour m'affranchir de cette limitation, et rendre mon logiciel possible, je me suis basé sur les propriétés des fonctions sinus et cosinus qui valent respectivement 0 et maximum à 0, et maximum et 0 à pi/2. Cette opposition leur permet d'être un facteur d'anéantissement sélectif quand on les emploie dans un calcul, rendant possible l'exécution sélective d'une action en G-Code selon la valeur binaire d'un paramètre multipliée par 0 ou pi/2.

Le logiciel Ouvertures a ainsi permis à mon employeur de gagner énormément de temps en réduisant la quantité de programmes paramétriques alimentant son centre d'usinage de plusieurs centaines à quelques dizaines, simplifiant considérablement ses processus de production. L'opérateur choisissait sur la machine le gabarit correspondant au type de pièce à produire, paramétrait les longueur, largeur et épaisseur de la pièce, et le programme s'adaptait automatiquement en usinant le nombre exact de modules à leurs positions requises pour ces dimensions.

Ce logiciel a été présenté au constructeur de la machine à Rimini en Italie ; ils se montrèrent intéressés mais demandèrent à ce que les usinages courbes (dont les cintres avec 3 arcs) soient eux aussi supportés de la même façon paramétrique. Malgré mes recherches pour y parvenir, je ne pus trouver une solution satisfaisante à ce cas de figure précis. Cette demande excédait les possibilités du langage.

Le prototypage du logiciel se fit dans le langage graphique LabVIEW. Il fut ensuite réécrit en C. J'estime que lors de mon départ de l'entreprise, entre la moitié et les 2/3 de la production se faisait en utilisant des programmes générés par mon logiciel.

Lorsque Windows Vista sortit en 2007, Microsoft inclut dans ce système d'exploitation le jeu "Chess Titans" en tant que démonstrateur pour leur technologie DirectX 10. Ce jeu d'échecs à l'interface polie, visuellement impeccable et très agréable à jouer, souffrait de certains défauts : il ne fonctionnait que sous Windows Vista, n'était pas un adversaire sérieux pour les amateurs d'échecs, et ne permettait pas de jouer en ligne sur Internet. Il semble que sa fonction principale de démonstrateur technologique empêcha Microsoft de pousser plus loin le concept et d'en faire un logiciel d'échecs "sérieux".

Or, le marché des logiciels d'échecs était un marché de niche, mal servi, et aucun des logiciels proposés à l'époque n'atteignait, même de loin, la qualité de l'expérience utilisateur fournie par Chess Titans. Constatant cette situation, j'ai entrepris de recréer ce logiciel sous DirectX 9, de façon à ce qu'il puisse fonctionner même sur des ordinateurs plus anciens (Windows XP restait majoritairement utilisé en 2009) - et ainsi naquit "Chess Giants". J'ai créé le moteur 3D entièrement en langage C, avec des effets de miroir, la gestion de matériaux, et du son spatialisé. Le résultat fut visuellement identique au démonstrateur technologique de Microsoft, tout en requérant moins de mémoire, moins de puissance, et en fournissant bien davantage de possibilités. Je mis le logiciel en ligne et il fut distribué sous le principe du "donationware" avec beaucoup de succès.

Constatant un fort intérêt de la part des utilisateurs, j'ai rajouté la possibilité de brancher d'autres moteurs d'échecs (Chess Giants employait initialement le moteur d'échecs Crafty du professeur Robert Hyatt), supportant les deux protocoles concurrents CECP et UCI - dont le célèbre moteur Stockfish, mais aussi les moteurs Fruit, Senpa, Texel et Toga II. J'ai donné aux utilisateurs la possibilité de personnaliser l'apparence du logiciel en créant eux-mêmes des thèmes visuels. Toutes les traductions (à l'exception de celles en anglais et en allemand) me furent fournies par les utilisateurs eux-mêmes. Enfin, je leur ai aussi permis d'utiliser Chess Giants comme interface pour se connecter au serveur d'échecs en ligne international FICS (Free Internet Chess Server), en implémentant son protocole de communication et en ajoutant à Chess Giants une interface de discussion instantanée inspirée de celle du défunt MSN. Les joueurs peuvent se connecter, rechercher leurs amis, discuter entre eux, lancer des invitations à jouer, y répondre, et jouer des parties tout en discutant.

Chess Giants a plus de quinze ans, et a plutôt bien vieilli. Si je devais le refaire aujourd'hui, j'emploierais un moteur 3D comme Unity ou Godot.

Quand j'ai commencé à exercer en tant qu'informaticien indépendant, il m'arrivait d'effectuer des dépannages pour des clients. Insatisfait de la lourdeur des solutions d'aide à distance existantes (TeamViewer...), j'ai créé en partant de la spécification du protocole VNC un petit exécutable léger, sans dépendance et auto-désinstallant. Mes clients le téléchargeaient en un clin d'oeil (sa taille était de 100 kilo-octets), le lançaient, et aussitôt une connexion s'établissait à mon ordinateur. La technique employée était un tunnel SSH inverse.

Avec l'arrivée de Windows 7 et la protection des comptes utilisateur (UAC) intégrée au système, cet utilitaire devint malheureusement assez rapidement obsolète. Mais il fit excellemment son travail pendant le temps où il m'a servi. Je l'ai utilisé jusqu'en 2011.

Lorsqu'une connaissance (Loïc "Black Lemming" Jean-Fulcrand, de T4C) me montra son iPhone, je compris rapidement tout l'intérêt d'avoir un véritable terminal informatique dans sa poche - et m'en offris un. Cependant, l'écosystème Apple était excessivement fermé et exigeait d'utiliser un Mac pour produire la moindre application, via leur environnement de développement "Xcode", dont l'interface était radicalement déroutante. Refusant de passer sous ces fourches caudines, je commençai par "jailbreaker" mon iPhone de façon à explorer le système du point de vue de la compatibilité POSIX. Je me rendis compte qu'il s'agissait simplement d'un port de l'écosystème Darwin de macOS sur une architecture ARM, avec quelques simplifications.

Il y avait un besoin énorme de pouvoir générer des applications pour iOS (et plus généralement, pour tout l'écosystème Apple), depuis le système d'exploitation majoritaire - à savoir Microsoft Windows. La concurrence entre Android, Windows Mobile et iOS rendait prohibitive pour un développeur l'acquisition de compétences spécialisées : chacun voulait pouvoir coder une fois, et déployer partout. Je me sentis en mesure de fournir un système de compilation croisée permettant de répondre à ce besoin (qui était, du reste, d'ailleurs à l'époque le mien).

Le passé technologique d'Apple est remarquable en ce qu'ils ont commencé sur des processeurs Motorola (gros-boutiens), pour basculer ensuite sur Intel (petit-boutiens) au tournant du XXIe siècle, puis se convertir à ARM pour leur efficacité énergétique inégalée - acquérant même leur propre licence pour développer Apple Silicon - et enfin, actuellement, explorer l'architecture libre de droits RISC-V. Cet éclectisme architectural confère au code source de leurs utilitaires de bas niveau une complexité significative, mais paradoxalement rend leur tronc commun plus clair et donc portable (du moins, vers toute architecture raisonnablement compatible POSIX).

Or, la compatibilité POSIX de Windows laissait largement à désirer ; bien que Windows soit pourtant le système d'exploitation majoritaire. Les implémentations des couches de compatibilité existantes (MinGW, Cygwin, MSYS2) amenant chacune quelques défauts rédhibitoires, j'entrepris d'écrire ma propre couche de compatibilité, rajoutant au runtime C de Microsoft les fonctions POSIX manquantes, et notamment une émulation des liens symboliques qui puisse interpréter les cibles brutes (telles que fournies dans un fichier zip généré sur macOS). Ceci me permit de compiler les binaires "cctools" d'Apple, l'assembleur "as" et l'éditeur de liens "ld". En y adjoignant le compilateur GCC paramétré pour la compilation croisée, il devenait possible de compiler du code C/C++ et générer des exécutables Mach-O pour Darwin sous Windows.

Il restait à résoudre le problème de la signature de code ; en étudiant l'état de l'art sur la question, en croisant les informations disponibles et par rétro-ingéniérie, je pus en déterminer le format et fus à même de réimplémenter un outil de signature utilisable avec les certificats fournis par Apple, et capable de signer des exécutables générés par ma chaîne d'outils de compilation. J'adjoignis alors à ma chaîne d'outils une vingtaine d'applications à valeur d'exemple, dont un port amélioré de la version "shareware" du jeu Wolfenstein 3D, supportant les modèles 3D et le guidage au gyroscope (qui éveilla la curiosité de John Carmack).

Quand Apple abandonna GCC et bascula vers LLVM/Clang, je fis évoluer parallèlement mes outils, en maintenant ma propre branche de LLVM où s'intégraient mes modifications POSIX. Quand ils introduisirent le langage Swift, je fis de même en maintenant ma propre branche de Swift - jusqu'en 2024 où ils commencèrent à distribuer des versions Windows suffisament stables (maintenues par l'ingénieur Saleem Abdulrasool). J'abandonnai alors mes branches distinctes pour utiliser les versions officielles, au prix d'un abandon du support de Windows 7 (et d'une réécriture de la couche POSIX).

Cet environnement est particulièrement utilisé par les développeurs qui utilisent le moteur 3D Unity - les ingénieurs d'Unity l'utilisent même en interne. Il suffit de lire les avis des utilisateurs.

Ce travail a rendu service à de nombreux studios de développement, dont Activision et Epic Games, et est toujours activement utilisé par un certain nombre d'acteurs majeurs de l'industrie. Je fus même contacté par un ingénieur d'Apple (Nat Brown), où il semble que l'existence de cette solution soit bien tolérée.

Au début des années 2010, aucun système domotique sur le marché n'offrait des prestations qualitativement satisfaisantes. L'enseigne haut de gamme Bticino, par exemple, n'actualisait pas les états de ses actionneurs sur différents terminaux : un interrupteur actionné sur le terminal tactile A puis éteint sur le terminal tactile B, restait affiché comme allumé sur le terminal tactile A. Cet "état de l'art" était tout simplement inacceptable.

J'ai donc développé, en collaboration avec mon cousin Damien Boissinot, un prototype de système domotique centralisé où ces défauts seraient corrigés. Pour minimiser le coût de déploiement, nous avons opté pour les choix les plus simples : le système devait pouvoir être installé par n'importe quel électricien sans formation préalable. Aucun câblage spécialisé, aucun bus de terrain n'était nécessaire. Il suffisait juste de faire converger les câbles vers un point central (typiquement la gaine principale).

Un petit serveur mini-ITX fanless sous FreeBSD, protégé par un onduleur, assurait la continuité du service. Celui-ci pilotait en lecture et en écriture des cartes relais à base de microcontrôleurs Atmel (Arduino), sur une liaison série. Les cartes pilotaient des relais de puissance (de 2A à 16A), des variateurs de tension continue, et recevaient des informations émanant de capteurs standard (tels que des sondes de température Delta Dore, bien connues des électriciens chauffagistes, ou des capteurs de présence et d'illumination standards).

Le système permettait en outre de récupérer des informations d'une caméra IP, d'un interphone, de diffuser de la musique (web radios ou playlist) sur les haut-parleurs de la maison, et il était possible de créer des scénarios, par exemple l'ouverture automatique de volets roulants ou le déclenchement d'ambiances d'éclairage.

On pouvait piloter la domotique depuis son ordinateur, son téléphone, son iPod ou sa tablette. Une application web à l'interface unifiée et au design moderne (effectué par le graphiste de NEOS Imagineering) permettait d'avoir le bâtiment dans sa poche.

Ce prototype fut installé dans une maison particulière de la région nantaise. Le feedback régulier des habitants devait nous permettre d'affiner le système. Malheureusement, il n'y eut pas suffisamment d'interaction spontanée entre eux et nous pour que cela fonctionne - les habitants de la maison en semblaient satisfaits, mais n'exprimaient pas de nouveaux besoins particuliers. Il aurait fallu installer le prototype dans d'autres domiciles pour obtenir d'autres retours, mais nous n'en avions pas l'opportunité et le projet fut abandonné, sur un prototype néanmoins totalement fonctionnel.

Je pense qu'un tel projet, si nous avions su le proposer à une entreprise d'envergure suffisante pour le mener à bien, aurait pu déboucher sur un produit qui aurait pu avoir du succès sur ce marché naissant, car il avait des avantages compétitifs sur tous les autres : simplicité d'installation, netteté de l'interface, et coût.

Je fus contacté en 2012 par la société Adaptive Digital Systems de Newport Beach qui avait découvert mon environnement de compilation croisée "iOS Build Environment". Ils me proposèrent la sous-traitance d'un développement très spécifique sur iOS, au carrefour de ce qui était techniquement possible et ce qui était, disons-le, moralement discutable. L'enjeu était, pour un client final états-unien que mon client nommait "l'agence à trois lettres", de pouvoir surveiller l'activité d'une personne infiltrée dans un gang de dealers de drogue, où à partir d'une camionnette ou d'un autre véhicule banalisé embarquant un point d'accès Wifi et 3G, des agents recevraient en temps réel des informations de positionnement GPS ainsi que toute l'activité audio (et plus tard, vidéo), collectées de façon invisible par un appareil sur lequel serait installé le logiciel que je leur fournirais. Il s'agissait bien d'un logiciel espion.

J'obtins l'assurance que le client final était une agence fédérale américaine, et fournis le logiciel à Adaptive Digital Systems. L'installation sur un téléphone iOS était rapide : il suffisait de brancher l'iPhone ou l'iPod sur un câble USB relié au terminal d'attaque ; celui-ci provoquait le redémarrage de l'appareil, son "jailbreaking", et l'installation du paquetage sous forme d'un démon UNIX.

La transmission des données audio était effectuée par UDP en temps réel vers une adresse IP prédéfinie, de façon à minimiser l'empreinte sur le système, et à bénéficier de la caractéristique "fire and forget" du protocole (UDP/IP étant un protocole sans état, à la différence de TCP/IP). La transmission de la position GPS se faisait en interrogeant périodiquement la puce GPS puis en transmettant la position par une API HTTP d'apparence bénigne vers un serveur distant ; l'emploi d'une requête HTTP permettait au niveau système d'employer la liaison Wifi quand celle-ci était disponible, et de basculer automatiquement sur la liaison 3G/EDGE quand celle-ci ne l'était plus. Quand aucune connection de données n'était disponible, la position GPS était envoyée par SMS en commandant directement la puce modem du téléphone (dans le cas, par exemple, d'un kidnapping de l'agent).

L'une des contraintes pour l'exploitation de la fonctionnalité d'envoi de la position GPS par SMS était que le téléphone soit au plus récent un iPhone 3GS: en effet, à partir de l'iPhone 4, Apple avait intégré la puce modem à leur propre SoC (System on a Chip), et de ce fait celle-ci ne pouvait plus être pilotée directement par des commandes AT. Dans leurs modèles précédents, Apple utilisait des puces Broadcom, pilotables par une liaison série /dev/dlci.XX comme de bêtes modems 56k sur RS232 (et ceci permettait, en outre, via une vulnérabilité de la puce Broadcom, d'infiltrer le système à distance par une chaîne de SMS, car les services chargés du dépaquetage de ces SMS en provenance du modem, fonctionnaient sur iOS avec les privilèges du super-utilisateur).

Un grand nombre de sociétés ont par la suite développé des solutions similaires, pour les vendre au "tout venant", comme par exemple à des parents anxieux de suivre l'activité de leurs adolescents. Ce n'est absolument pas le genre de cible pour lequel j'ai développé la solution que j'ai livrée à Adaptive Digital Systems.

Une entreprise industrielle (Micro-Contrôle, propriété du groupe Newport) spécialisée dans les positionneurs de précision, me missionna pour terminer l'implémentation du microgiciel d'un de leurs micropositionneurs monoaxes fonctionnant sur un DSP Texas Instruments 320f2808, le Smart-PP, qu'un de leurs collaborateurs ne parvenait pas à terminer. Il m'apparut assez rapidement qu'au vu de l'état de la base de code, il serait plus rapide de tout refaire - et c'est ce que je fis. Bien que je n'aie eu aucune connaissance ni de ce domaine industriel ni de la culture technique de cette entreprise, je réimplémentai l'intégralité du firmware en suivant les spécifications du protocole de communication et la documentation technique du produit, en langage C, documentant chaque choix technique ou logique dans le code source lui-même, de façon à ce qu'ils puissent le reprendre et le faire évoluer facilement.

Je fournis en temps requis à mon client le nouveau code source et une vidéo pour en valider le fonctionnement, ainsi que la documentation. Ils en furent favorablement impressionnés et devinrent un de mes clients réguliers.

La société israélienne Experitest vendait des outils d'automatisation des tests unitaires pour applications mobiles. Dans sa version iOS, ceci consistait à dépaqueter une application existante, y injecter une bibliothèque dynamique à chargement automatique (DYLD_INSERT_LIBRARIES, équivalent du LD_PRELOAD de GNU/Linux) réalisant diverses mesures, puis réempaqueter l'application - et évidemment la re-signer pour qu'elle passe la validation d'Apple. Or là était la faiblesse de leur modèle car, en plus de n'être documenté nulle part, d'être obligatoire pour l'exécution d'un quelconque code tierce partie sur iOS, le format de signature de code (relativement récent) utilisé par Apple pour ses écosystèmes mobiles subissait parfois à cette époque des changements structurels inopinés visant à corriger des vulnérabilités au fur et à mesure de leurs découvertes.

Experitest avait donc été la première à ajouter le support iOS à leur offre d'automation, en utilisant l'outil de signature de code que j'avais développé pour mon environnement de compilation croisée Windows vers iOS, avec un certain succès. Un changement soudain de format de signature de code par Apple dans iOS 8 les prit au dépourvu : leur processus d'automation pour iOS était cassé et leurs clients attendaient. Ils me contactèrent donc en urgence, un dimanche midi, pour me prier de travailler toutes affaires cessantes sur ce nouveau format. Je devais disséquer et réimplémenter le nouveau format de signature de code sous 48 heures, avant mardi.

Ce fut fait. Le rapport gain sur temps passé fut assez remarquable. Mais afin de se prémunir contre de futurs désagréments similaires, ils voulurent acheter mon code source : je le leur vendis. Malheureusement pour moi ils avaient de bons ingénieurs, et n'eurent effectivement par la suite plus besoin de mes services.

Cet épisode me renseigna mieux qu'aucun cours d'économie sur ce qu'est la valeur réelle d'un produit.

Une connaissance, Philippe Royer, fit un jour appel à mes services. Son activité était le négoce de bois abattus (sa société se nommait Little Bear). Je fus frappé de la vétusté des terminaux électroniques de mesure des grumes qui leur étaient imposés par le fournisseur unique de ce marché de niche, et par leur coût d'exploitation. J'affirmai à ma connaissance que je pouvais lui fournir le même service à l'aide d'une tablette chinoise Android renforcée et d'un logiciel ad hoc basé sur la technologie Apache Cordova, pour une fraction du prix.

J'acquis donc une tablette renforcée et un téléphone Android de marque Caterpillar et entrepris de coder cette application, qui n'était au fond qu'un simple tableur préfixé d'une interface de mesure aussi intuitive que possible, et suffixée d'un module de génération de devis et d'exportation de ceux-ci en différents formats (CSV, HTML, XLS, PDF...) Il fallait pouvoir enregistrer les billons mesurés dans un listing, leur assigner un prix par essence et par qualité, fournir la possibilité d'effectuer une remise commerciale, et sortir un document - lesuel devait ensuite pouvoir être modifié a posteriori, non nécessairement sur le terminal qui l'avait créé. J'utilisai donc naturellement le cadriciel Apache Cordova (ex-PhoneGap) afin de développer rapidement cette application en HTML5 et JavaScript.

Mon ami utilisait sur ses chantiers la tablette renforcée Android que je lui avais fournie, mais utilisait chez lui des téléphones et des tablettes Apple iOS. J'inclus donc dans la chaîne de génération du logiciel ma chaîne d'outils de compilation croisée de façon à générer en une seule itération à la fois l'application Android et l'application iOS. Mais il se trouva qu'il me demanda, par commodité, de pouvoir aussi afficher - et surtout modifier - les listings générés par l'application sur l'écran d'un ordinateur de bureau.

Je réalisai donc un rétroportage de Cordova vers Windows 7 et macOS 10 (ses ordinateurs au bureau étant sous Microsoft, et chez lui Apple), ce qui lui permit de disposer de la seule version de Cordova à même de générer en une fois des applications réactives pour Android, iOS, Windows 7 et macOS.

Tous les documents générés par l'application étaient envoyés vers mon serveur dédié (pmbaty.com), routés et protégés par l'identifiant du compte utilisateur, et synchronisés à chaque ouverture de l'application quel que soit le terminal utilisé. Ils étaient envoyables par courriel et par SMS.

L'application lui donna entière satisfaction, le seul défaut était l'insuffisance de contraste de l'écran de la tablette Android renforcée dans des conditions de forte luminosité (plein soleil). Un mode "noir et blanc" résolut ce problème.

Depuis l'invention du "cloud" je suis extrêmement circonspect sur l'opportunité de déléguer la gestion de mes données numériques à un prestataire privé dont les intérêts ne sont pas du tout alignés avec les miens, et je milite pour conserver celles-ci dans mon pré carré. Les fuites de données et failles de sécurité chez les prestataires de cloud qui défraient régulièrement la chronique (DropBox...) me donnent régulièrement raison. J'utilise donc mes compétences d'administrateur réseau pour maintenir en service, avec un effort minimal, et sur un serveur dédié, mon propre "nuage" à usage domestique et professionnel.

L'interface publique de celui-ci, à savoir le domaine pmbaty.com et ses nombreux sous-domaines, était initialement hébergé sur un serveur dédié chez OVH.com ; or j'étais de moins en moins satisfait de leur qualité de service. Je décidai de migrer vers une colocation où je pourrais faire héberger mon propre matériel. Mon expérience de l'administration des systèmes et des réseaux m'ayant appris que les principaux points de fragilité des matériels informatiques ont pour origine les pièces mécaniques, et tout particulièrement les vibrations causées par les ventilateurs, j'optai pour un matériel à dissipation entièrement passive, un "nettop" Gigabyte Brix grand public, que j'équipai d'un SSD Toshiba sur lequel j'installai le système d'exploitation UNIX FreeBSD. Aussi mon hébergeur vStoike fut assez intrigué de recevoir par la poste un boîtier grand comme la moitié d'un pack de lait à caler entre ses racks 1U et 2U, mais après quelques années de recul fut totalement convaincu de la justesse de mon choix technique (mon nettop affichait fièrement 99.7% de temps de service en ligne, loin devant ses propres HP ProLiant).

Le système d'exploitation est FreeBSD, réputé pour sa robustesse, son excellente pile réseau et ses performances - qui étaient précisément tout ce qui me permettait d'utiliser un matériel beaucoup moins puissant pour fournir le même service, et de rendre possible son fonctionnement en dissipation passive. La pile de courriel est Postfix pour SMTP et Dovecot pour POP3/IMAP. Ce dernier gère aussi les synchronisations CalDAV et CardDAV. Le SGBD initial était PostgreSQL ; celui-ci était surdimensionné pour mon usage, et je migrai ensuite mes bases vers MariaDB (une branche de MySQL), plus simple à administrer. Par la suite, une simplification des besoins et la tendance croissante des applications au SQL décentralisé (SQLite) voire au NoSQL me permit d'abandonner MariaDB au profit de Redis, un moteur minimal mais extrêmement rapide, qui dessert le tableur partagé EtherCalc. La discussion instantanée se fait par XMPP via le service Prosody ; une interface web a été rajoutée pour que quiconque puisse me contacter n'importe quand depuis ce point d'entrée sur mon site. Le service de visioconférence est Jitsi Meet, dans une instance Docker elle-même cloisonnée par sécurité dans une machine virtuelle Linux minimale. Le système de suivi de version et dépôt de mes codes sources est Subversion - un choix à contre-courant de la tendance, que j'assume car Git, bien qu'idéal pour des projets open source, possède des défauts rédhibitoires dans tous les autres cas. En comparaison SVN est léger, efficace, ne nécessite pas d'installer un sous-système POSIX complet pour fonctionner, et surtout garantit que le contrôle de l'arbre des sources reste centralisé, ce qui est un impératif pour tout projet logiciel qui ne soit pas open source.

Cette infrastructure a maintenant 10 ans et fonctionne de façon largement automatisée ; une réplication incrémentale complète est effectuée chaque jour vers un serveur de secours à mon domicile. Le nettop Gigabyte d'origine, qui a fonctionné sans discontinuer pendant 6 ans, a été remplacé en 2021 par un HP ProLiant car une mise à jour de FreeBSD avait retiré un pilote essentiel pour le support de ce type de matériel dans le noyau GENERIC, et il aurait été malcommode de devoir recompiler un noyau FreeBSD spécifique à chaque mise à jour du système.

Le "petit frère" de ce serveur FreeBSD se trouve à mon domicile ; en plus d'être prêt à prendre le relais en cas de défaillance du premier, il héberge le serveur domotique de mon habitation - que j'ai réalisé moi-même, sur l'inspiration de HouseMind, avec HomeAssistant.

Un client louait des machines à calibrer les muguets. Ces machines avaient été conçues vingt ans plus tôt et avaient besoin d'une sérieuse mise à jour : le vieillissement des composants nécessitait d'envisager le remplacement de toutes les cartes mères et des écrans tactiles monochromes à rayons cathodiques, qui tombaient en panne et ne se trouvaient plus nulle part. Quant au logiciel, programmé en Turbo C, il fonctionnait en mode réel sous MS-DOS, un système d'exploitation datant des années 80.

L'interface avec la machinerie se faisait sur un bus ISA 16-bit. Ce type de bus ayant disparu de la circulation depuis une bonne dizaine d'années (successivement remplacé par le bus PCI puis PCI-Express), il me fallut dénicher au fin fond de la Chine un constructeur de cartes mères capable de produire un clone de la dernière carte industrielle Advantech des années 2000 supportant ce type de bus et qu'Advantech eux-mêmes ne produisait plus. Après un grand nombre d'échanges en chinglish, je me suis acquitté avec succès de cette première étape de ma mission.

Le problème des cartes mères étant résolu, il fallut ensuite s'occuper des écrans tactiles. Ce fut beaucoup plus facile de trouver ce type de matériel, les fabricants chinois d'écrans tactiles sont innombrables. Seulement, l'ancienne interface tactile fonctionnait sur une liaison série RS232, et selon un protocole propriétaire dont mon client avait perdu la documentation : il fallut donc écrire un nouveau pilote. De plus, les nouveaux écrans tactiles n'offrant qu'une interface USB, je dus déployer dans MS-DOS une pile USB tierce-partie en TSR (Terminate and Stay Resident) pour pouvoir les exploiter. Il fallut ensuite implémenter le protocole proprement dit, car aucun des fabricants chinois de ces écrans tactiles ne fournissait plus de pilote pour MS-DOS ni ne savait en faire. Par rétro-ingéniérie des pilotes fournis, j'ai retrouvé l'organisation des paquets, et ai pu implémenter assez facilement un TSR qui fonctionnait de la manière suivante : chaque pression sur l'écran déclenchait l'émission d'un paquet d'information vers l'hôte USB, contenant les coordonnées absolues du contact. La pile USB routait ce paquet vers mon TSR, qui mettait alors à jour les coordonnées de la souris à l'emplacement mémoire réel exact où le pilote de souris standard du système (CuteMouse) écrivait les siennes. Le clic était simulé de la même manière, en inscrivant cette valeur à l'emplacement où CuteMouse le faisait lui-même. Cette compatibilité avec l'API d'un gestionnaire de souris classique permettait au logiciel métier de mon client de fonctionner avec cet écran tactile sans aucune modification - car le support de la souris était déjà inclus dans ce logiciel.

Cette technique me fit gagner beaucoup de temps dans la réalisation de cette mission et permit à mon client d'obtenir la mise à jour de son matériel, et ainsi de pouvoir continuer à exploiter ses machines pendant de longues années, pour un coût extrêmement modique.

Mon client Micro-Contrôle (groupe MKS Instruments / Newport) me missionna pour réaliser, de concert avec mon collègue Alix Leteur, un logiciel de simulation de positionneurs hexapodes aux fins de promouvoir leurs produits. Leurs concurrents sur le marché commençaient à fournir ce genre de logiciels et il s'agissait de relever le défi en proposant mieux, ce qui était, au vu de l'état de l'art, largement à notre portée.

Les équations mathématiques régissant le mouvement de ces curieux assemblages mécaniques que sont les positionneurs hexapodes nous furent fournies par les mathématiciens de l'entreprise : ceux-ci impliquaient du calcul matriciel 4x4 (transformations affines) et 6x6 (Jacobiens). Nous avions déjà réalisé, mon collègue et moi, des moteurs 3D par le passé - Chess Giants en ce qui me concerne - donc ce fut une tâche plutôt simple et très agréable d'en refaire un en C# supportant Direct3D 9.

Afin de rendre l'expérience utilisateur plus fluide, nous avons choisi d'implémenter la rotation autour de l'objet sous la forme d'un quaternion, afin de s'affranchir des problèmes d'extrema tangentiels de la représentation euclidienne. Un cube d'orientation similaire à celui des applications de CAO 3D bien connues permet de sélectionner le plan d'affichage. Il est possible d'afficher les hexapodes en 3D (perspective), et d'afficher leur espace de travail parcourable de façon dynamique sous forme d'un volume grillagé en 3D, et de courbes fermées en 2D.

Le simulateur calcule également les masses, forces et couples appliqués aux pièces mécaniques et est capable d'anticiper et mettre en évidence une surcharge capacitaire.

Notre expérience des moteurs 3D issue du jeu vidéo nous a permis d'amener facilement quelques avantages concurrentiels significatifs : ainsi, les modèles 3D des hexapodes présentés sont exactement ceux issus des documents techniques du bureau d'études, et un éclairage réaliste de la scène leur procure un aspect visuel très proche du produit réel. De plus, nous avons ajouté, sur notre suggestion, la possibilité pour l'utilisateur d'importer ses propres modèles 3D dans la scène représentée et la gestion des collisions, excédant assez largement le cahier des charges initial.

En totale confiance, mon client m'a laissé carte blanche pour revoir et améliorer l'interface utilisateur et je crois avoir réussi à rendre le tableau de commandes aussi intuitif que possible, en abstraction de la complexité du produit.

C'est moi qui supervisais cette réalisation commune et je suis fier du résultat que nous avons produit. Le logiciel HexaViz est désormais au catalogue des produits MKS/Newport et la présentation qu'en font mes clients laisse transparaître, à mon grand plaisir, une fierté partagée.

Un client voulut me voir reprendre le code source d'un logiciel de type ERP (planificateur de ressources d'entreprise) nommé "FARH", qu'il exploitait en tant que service web, en en louant l'accès à des PME. Je m'aperçus très rapidement que ce code source en PHP était inexploitable : de nombreux programmeurs aux compétences très diverses y étaient passés, et y avaient causé des dégâts irréparables. L'ensemble était l'illustration canonique de ce qu'on appelle dans le jargon du métier du "code spaghetti". Avant de songer à le faire évoluer, il fallait tout refaire pour repartir sur des bases saines, et je le lui dis.

Cependant, comme je ne souhaitais pas continuer la maintenance de ce logiciel après sa livraison (n'ayant que peu d'affinité avec le domaine de la gestion d'entreprise), j'ai souhaité donner à mon client, en plus du logiciel lui-même reprogrammé selon les règles de l'art, la possibilité de le faire évoluer ad libitum sans compétence technique particulière. Pour cela, je devais extraire la logique "codée en dur" gouvernant le comportement de chaque champ, chaque bouton, chaque contrôle et chaque indicateur du logiciel pour la stocker dans une base de données, que le nouveau logiciel interrogerait afin de déterminer le rôle, la position, la nature et le comportement entre eux de tous les éléments qu'il devait afficher, pour chaque page, à la manière d'un tableur programmable dont les cases n'auraient pas besoin d'être alignées sur une grille.

Je référencai donc tout le comportement du logiciel existant dans un wiki sous forme de formules de calcul, de formules d'affichage et de formules d'action. Je créai les règles de syntaxe gouvernant ces formules et les documentai. J'implémentai un résolveur hiérarchique où chaque opération arithmétique et logique se réduisait à un appel de fonction dont le résultat serait déterministe. Le nouveau logiciel se retrouvait donc gouverné par une métaprogrammation fonctionnelle qui faisait que le résolveur de formule ne "plante" pas.

Toutes les opérations sur la base de données SQLite se déroulaient de façon transactionnelle et atomique, respectant la règle du SPOT (Single Point Of Truth, interdisant la redondance de l'information).

Malgré cette complexité par-rapport à l'ancien logiciel dont la logique était "codé en dur", le nouveau logiciel donnait des performances dix fois supérieures (il n'était pas rare, par exemple, que l'affichage des pages de l'ancien logiciel soit interrompu car la limite de temps acceptable à l'exécution des scripts était atteinte, ce qui ne manquait pas de provoquer des dysfonctionnements ; mon implémentation affichait la même page en quelques secondes).

Afin de rendre le logiciel facile à faire évoluer et en maximiser la compatibilité, je me suis efforcé de le développer dans un PHP court et simple pour le côté serveur (1 seul fichier) et Javascript côté client, selon le patron Modèle/Vue/Contrôleur (le "modèle" étant les données, la "vue" l'interface dans laquelle les afficher, et le "contrôleur" la logique gouvernant le tout). J'ai fourni le tout sous forme d'un dépôt de code versionné qui intégrait son propre IDE (VSCodium) et son propre banc de test (NginX + PHP en local). Pour le mettre en ligne, il suffisait à mon client d'y téléverser les fichiers.

Dans l'intérêt de mon client, j'ai implémenté une gestion automatique des préconisations du RGPD (Règlement Général sur la Protection des Données) pour ses utilisateurs.

Ce projet fut un réel défi de complexité et je suis fier du résultat obtenu. Je suis convaincu que ce principe de rendre un logiciel modifiable par l'utilisateur lui-même recèle un immense intérêt technique et commercial.

Epic Games, les créateurs du célèbre jeu Fortnite et du moteur 3D Unreal Engine, ont une relation compliquée avec Apple. Les exigences protectionnistes d'Apple cadrent mal avec la hardiesse d'esprit des développeurs d'Epic. Apple est tenu (car ils utilisent des outils issus de l'écosystème open source) de publier les changements et le code source de certains de leurs outils de bas niveau, mais ils ne le font qu'avec un certain retard, ce qui irrite les développeurs des moteurs de jeu vidéo comme Epic Games (il y a également d'autres raisons, de nature commerciale, à leur mésentente).

En 2020 Je fus contacté par Jeff Roberts (fondateur de RAD Game Tools) et Jon Olick, qui utilisaient déjà mes outils de compilation croisée chez Epic. Après que j'ai résolu pour eux un bogue dans le code source de la dernière version de l'utilitaire "strip" fourni par Apple, Jeff m'a récompensé d'un pourboire de 1000 dollars. De fil en aiguille, Jeff finit par me proposer un emploi à distance chez eux, que je refusai par principe (Activision m'avait fait la même offre 1 an plus tôt, mais ceci impliquait de déclarer tous mes revenus fiscaux à l'administration américaine via la déclaration W8-BEN alors que je travaillerais en France, ce qui reviendrait à voler mon pays. Je ne suis pas opportuniste, c'est le moins que l'on puisse dire - en revanche, j'ai des principes.)

Souhaitant néanmoins me fournir les moyens de continuer à développer ce produit, Jeff Roberts me fit inscrire au programme Epic MegaGrants, qui distribue annuellement des dons aux projets qu'Epic Games juge prometteurs ou méritants. J'ai ainsi reçu de leur part une somme très significative, me permettant de prendre le temps de faire évoluer ce logiciel pendant une longue période.

Je suis infiniment reconnaissant à Jeff de sa grande générosité. Savoir que mon travail a été apprécié à ce point par une entreprise de premier plan, et que mes travaux leur ont rendu un réel service, me rend profondément heureux.

Conscient que sa ligne de produits embarquant des systèmes informatiques commençait à prendre de l'âge et risquait d'être vulnérable à certaines cyberattaques par des acteurs malintentionnés, mon client MKS Instruments voulut se faire une idée précise du risque. Il me commanda, sous accord de non divulgation, un rapport d'audit recensant les vulnérabilités informatiques que je pourrais découvrir dans ses principaux produits.

Je mis effectivement en évidence un certain nombre de vulnérabilités, et produisis un rapport de 80 pages illustrant leur découverte, leurs causes combinées, et les moyens d'y remédier, à tous les niveaux pertinents de la chaîne d'implémentation (design général, architecture de la solution, choix du matériel, choix du système d'exploitation, processus de démarrage automatique, configuration des services exposés, implémentation du logiciel métier, pratiques saines de programmation, sanitisation de code et renforcement de la chaîne de génération). J'y mettais l'accent sur les méthodes de protection modernes, en particulier la défiance systématique envers toute donnée entrante, les signatures numériques et la cryptographie asymétrique.

Ce rapport se terminait par un tableau synthétique résumant la quintessence de son contenu à l'attention des cadres décideurs de la hiérarchie.

Tout ce travail ayant été réalisé sous NDA (accord de non-divulgation), je ne peux pas rentrer davantage dans les détails.

Mon client MKS Instruments produit des micropositionneurs de précision à axes multiples. Ces produits fonctionnent généralement sous un système d'exploitation temps réel. Mon client a successivement exploité pour cela dans ses produits les systèmes VxWorks, QNX 6.5 et Linux/Xenomai Cobalt. La ligne de produits "XPS" était basée sur QNX 6.5 (dont je leur ai fourni l'interface web et les services UNIX en mode utilisateur en 2015) en 32-bit, et nécessitait une mise à jour afin d'exploiter un plus grand espace adressable en 64-bit dans leur logiciel métier. J'eus carte blanche pour faire évoluer ce système vers QNX 8.0.

Le système d'exploitation temps réel QNX, propriété de BlackBerry Inc., était livré jusqu'à la version 6.5 avec un compilateur natif. Ce ne fut plus le cas à partir de la version 7 et tout ce qui était produit pour cet écosystème devait nécessairement passer par leur système de compilation croisée, intégré dans leur environnement de développement "Momentics". Ceci posait un problème considérable, en ce qu'un grand nombre de logiciels de la logithèque UNIX, dont le serveur Samba (partage de fichiers avec les ordinateurs Microsoft) supportait très mal la compilation croisée ; en revanche, tous ces logiciels compilaient presque sans effort dans un système POSIX standardisé en compilation native. Il y avait donc deux options : pour porter l'ensemble de la logithèque disponible sur l'ancienne plate-forme QNX 6.5 vers QNX 8.0 et y ajouter les nouveaux services utiles, soit je passais sous les fourches caudines du système imposé par BlackBerry Inc. et je dévouais un temps considérable (et surtout imprédictible) à porter et déboguer les scripts de compilation pour qu'ils fonctionnent en compilation croisée, soit j'investissais du temps à fournir moi-même à QNX 8.0 le compilateur natif qui lui manquait. Ce second choix était le plus stimulant, le plus technique, mais paradoxalement le moins risqué : en effet, la trajectoire du travail à accomplir était lisible de bout en bout, à la différence de l'autre où essentiellement la chance tenait un rôle inacceptable.

J'ai donc commencé par rétro-analyse à identifier les particularités du format d'exécutable de ce système d'exploitation : c'était le format ELF, dans sa variante la plus simple. Je pus alors, modulo quelque configuration pour spécifier le bon chargeur d'exécutable propre à ce système et quelques paramètres de format, compiler en compilation croisée les outils binaires GNU, dont l'éditeur de liens qui permettrait de lier ensemble les fichiers objets compilés pour cette plate-forme dans un format exécutable par QNX. J'ai ensuite compilé, toujours en compilation croisée, une version du compilateur Clang/LLVM capable d'émettre des fichiers objet pour ce système. Y adjoignant un pilote de compilateur sur mesure qui reproduisait les arguments à passer à l'éditeur de liens, j'obtins alors la chaîne de génération complète.

Je pus alors compiler facilement sur la machine QNX 8.0 elle-même, l'ensemble de la logithèque à porter : GNU Autotools, interpréteur Bash, Midnight Commander, service Samba, service mDNS, serveur web NginX, interpréteur PHP, proxy WebSockets, client du logiciel métier, etc.

Afin de parfaire l'autonomie de cette plate-forme, j'ai réimplémenté l'empaqueteur de ramdisk de démarrage (IFS) afin d'en fournir une version native. Cette étude m'a permis d'imaginer une méthode pour extraire les valeurs des variables UEFI en mode utilisateur, sans passer par les services EFI, et donc avec un impact nul sur l'ordonnanceur temps réel du système, contrainte d'une importance critique sur ce type de produit. Cette découverte m'a permis d'implémenter la vérification du démarrage sécurisé par signature de code dans QNX 8.0, fonctionnalité que BlackBerry eux-mêmes n'avaient pas encore réalisé sur ce système.

Enfin, afin de rendre le nouveau système en tout point similaire à l'ancien auquel mon client était habitué, j'ai écrit un pilote d'affichage graphique permettant d'afficher des informations sur un écran plutôt que via une console série, méthode avec laquelle ils étaient moins familiers. J'y ai ajouté pour faire bonne mesure, et faciliter le débogage par mon client de leur application métier, le support des séquences d'échappement ANSI avec la couleur, les styles de fonte (gras/italique/souligné), et quelques extensions (couleur de fond transparente, et affichage arbitraire d'images aux coordonnées du curseur).

J'ai également fourni à mon client une méthode de détection automatique du matériel permettant de réutiliser le même IFS avec un grand nombre de cartes CPU, et une implémentation de GDB-GUI pour lui permettre de déboguer à distance ses programmes natifs sur QNX 8.0 via une interface web.

Ce fut jusqu'ici mon chantier le plus technique et l'un des plus stimulants, qui me tint occupé une bonne partie de l'année. Eu égard à l'état de l'art et à la rareté des compétences disponibles sur cet écosystème, je suis très fier du résultat.

Quand nous regardons la télévision, nous choisissons nos programmes, nous ne laissons pas les chaînes nous les imposer - de cette façon, avec le filtrage adéquat, nous évitons toute la publicité. Ceci implique qu'un petit ordinateur soit branché en permanence derrière la télévision, et que les programmes que nous regardions soient disponibles en "replay", sur un site d'hébergement vidéo quelconque. Cette situation implique aussi de taper des adresses Internet dans la barre d'un navigateur, et de diriger un pointeur de souris, sur un écran situé à trois ou quatre mètres et alors qu'on est assis dans un canapé.

Je n'ai trouvé aucune solution acceptable parmi les applications de contrôle à distance. Soit il fallait installer des applications obèses, soit il fallait subir de la publicité embarquée, soit l'implémentation du pavé tactile était extrêmement frustrante... En quelques jours, et pourrait-on dire de colère, j'ai écrit HeliMouse de façon portable en C/Objective-C, l'ai compilé pour macOS et Windows, et l'ai déposé sur l'App Store d'Apple et le Microsoft Store.

Cet utilitaire de taille ridicule remplit parfaitement son rôle, sans aucun des défauts présents dans les solutions concurrentes. Je m'assois dans mon canapé, je flashe le QR code qui s'affiche sur ma télé, le QR code disparaît et je me retrouve immédiatement en train de contrôler le pointeur de la souris du bout des doigts. Il n'y a vraiment rien de sorcier à faire les choses correctement...