Déterrer un TIPE de 17 ans : écrans tactiles SAW, différences finies, et une simulation à moitié perdue

Tue, 05 May 2026 00:00:00 +0000

Le montage expérimental du TIPE 2009, photographié pendant le projet. Un petit haut-parleur posé sur la plaque sert de source à fréquence unique. Les deux câbles noirs en bas sont les microphones utilisés pour écouter la plaque. La grille 3 par 3 dessinée sur une page de calendrier est le motif de test. Le titre manuscrit visible sur le papier est le titre de travail du TIPE.

La moitié que j’ai pu retrouver

Pendant des années j’ai eu un souvenir avec cette forme : mon TIPE de prépa avait été un projet CUDA. Écrans tactiles à ondes de surface, simulés sur GPU, parallélisés, un peu impressionnants. Le souvenir s’avère en partie juste, en partie cassé.

En avril 2026 je suis parti à la recherche du code. Le NAS OMV que je fais tourner à la maison contient encore une image du disque dur agonisant de mon vieux PC Dell XPS de l’époque prépa. Il y a un dossier sous XPS/Antoine/Desktop/ daté du 21 juin 2009, avec une simulation complète en C avec SDL et OpenMP. Il y a aussi, séparément, un unique fichier .cu daté du 19 juin 2009 : un hello-world de 1,2 Ko qui fait une addition vectorielle à 9 threads, posé à côté d’un papier téléchargé de Balacey, Chatelard, Faure et Gilles sur CUDA que j’avais clairement utilisé comme référence à l’époque.

La version CUDA de la vraie simulation TIPE, celle dont je me souviens avoir écrit et fait tourner sur le GPU du labo, n’est nulle part dans la sauvegarde. Elle a existé. J’en suis sûr. Elle a disparu : perdue entre des disques durs, perdue dans un dossier qui n’a pas survécu au cycle formatage-réinstallation d’un XPS qui montrait déjà son âge, perdue de la manière dont un projet de 17 ans sur une machine personnelle finit par perdre ses fichiers. Je n’arrive pas à la retrouver.

Ce que j’ai retrouvé, c’est le jumeau CPU : la même simulation, la même physique, la même grille d’entrée, écrite en C pur avec SDL pour le rendu et OpenMP pour la parallélisation. Le travail CUDA lui-même n’a jamais touché de machine de l’école : il tournait sur mon propre GPU à la maison, et sur la station de travail flambant neuve d’un ami (un PC sérieusement neuf à l’époque, assez généreux pour le prêter à un camarade qui bossait sur un TIPE). Que j’aie écrit la version CPU comme baseline avant le portage GPU, ou comme repli pour les moments où je n’avais accès à aucun des deux GPU, ou simplement parce que le cycle de développement était plus rapide sur CPU, les traces qui pourraient me le dire ont disparu avec le reste. Ce qui reste est une moitié du projet. C’est la moitié dont je parle ici, parce que c’est la moitié qui est revenue à la vie.

De quoi le TIPE traitait vraiment

Le titre complet est sur le calendrier dans la photo plus haut : Étude de la propagation d’ondes dans le contexte des écrans tactiles. L’objectif du projet était de comprendre et de reproduire en partie un écran tactile à ondes de surface (SAW).

Si vous avez utilisé une borne d’information publique, une machine à sous de casino, ou certains panneaux de contrôle industriels, vous avez probablement touché un écran SAW sans le savoir. Comparé aux écrans résistifs et capacitifs qu’on a partout aujourd’hui, le SAW a de vrais avantages :

La clarté optique n’est pas dégradée. Vous touchez une plaque de verre non modifiée. Il n’y a pas de couche d’ITO devant l’écran, donc la luminosité et le contraste de l’écran sous-jacent ne sont pas affectés.
Il résiste aux rayures. Une rayure sur un capteur capacitif change la carte de capacité. Une rayure à la surface d’une plaque de verre SAW n’affecte presque pas la propagation d’une onde sur la plaque.
Ça marche avec des gants. Le capacitif a besoin d’un conducteur. Le SAW a juste besoin d’un doigt (ou de n’importe quoi qui absorbe les vibrations), donc ça marche en hiver, dans la cuisine, en salle d’opération, et dans les usines.
Ça marche sur du verre blindé. La plaque peut être épaisse. C’est pour cela que le SAW domine historiquement les bornes publiques, les distributeurs automatiques et les machines de jeu.

En contrepartie, on perd deux choses : le SAW est uniquement à détection au contact dans sa forme commerciale (pas de survol), et la précision spatiale est plus faible que le capacitif. Vous n’allez pas tracer des traits fins sur un écran SAW. En revanche, vous cliquerez sur de gros boutons de manière fiable pendant dix ans dans une salle d’arcade humide.

Le PDF de la soutenance pose tout ça dans les trois premières slides, et le reste pivote vers la question qui m’intéressait dans le projet : est-ce qu’on peut modéliser un écran SAW assez bien pour comprendre pourquoi ça marche, et est-ce qu’on peut en construire un dans un labo de physique en CPGE ?

Une remarque de contexte qui n’apparaît pas dans la soutenance. Un ami, Élie, travaillait sur sa propre simulation d’ondes en même temps, en parallèle et indépendamment. Son angle était visuel : les figures d’ondes stationnaires, l’esthétique des figures de Chladni, la même physique qui fait que si vous saupoudrez du sel sur une plaque qui vibre, il s’organise sur les nœuds. Mon angle était plus pratique : je voulais pousser l’idée d’écran tactile au-delà de ce que les écrans SAW commerciaux de l’époque pouvaient faire, et essayer de détecter le multi-touch et les gestes glissés. Deux doigts sur la plaque en même temps, chacun décalant le spectre stationnaire à sa façon ; ou un doigt qui se déplace sur la plaque, le spectre évoluant continûment au fur et à mesure. La démo en labo sur la soutenance s’arrête au mono-touch statique, parce que neuf sur neuf sur une grille 3 par 3 est ce que j’avais réussi à faire fonctionner robustement à temps pour l’oral. La simulation elle-même tournait toujours en excitation continue parce que c’est ce qu’il faut pour le multi-touch et le mouvement : une source sinusoïdale entretenue sur la plaque, les récepteurs en train d’écouter, et le spectre qui réagit en temps réel à ce que vous faites sur la surface.

La physique, en un peu moins qu’un cours

L’équation d’ondes sur une plaque est l’équation d’ondes linéaire 2D classique, avec la célérité c fixée par le matériau :

Δz = (1 / c²) · ∂²z / ∂t²

Pour un solide isotrope, c provient des propriétés élastiques : module d’Young E, coefficient de Poisson ν, masse volumique ρ. Le PDF traite l’exemple du plexiglas (PMMA : E = 2380 MPa, ν = 0,34, ρ = 1180 kg/m³), ce qui donne une célérité d’environ 1500 m/s. Assez lent pour qu’une simulation par différences finies tourne avec un pas de temps raisonnable, assez rapide pour qu’une petite plaque ait les modes qu’on attendrait d’un vrai écran tactile.

On discrétise l’équation de la manière évidente. On échantillonne l’espace au pas dx et le temps au pas dt, on remplace le laplacien par sa version discrète à 5 points, et on obtient la récurrence explicite :

z(i, j, k+1) = 2·z(i, j, k) − z(i, j, k−1)
             + (c·Δt / Δx)² · [ z(i−1, j, k) + z(i+1, j, k)
                              + z(i, j−1, k) + z(i, j+1, k)
                              − 4·z(i, j, k) ]

C’est tout le cœur de la simulation. Trois tranches de temps, deux indices, une constante. Chaque cellule n’a besoin que de ses quatre voisines et de ses propres valeurs précédentes. C’est massivement parallélisable. C’est aussi exactement le genre de problème où un CPU dual-core de 2009 avec OpenMP pouvait déjà faire de vrais progrès, et c’est précisément ce que fait la simulation.

Ce que fait la simulation CPU

Burst mono-source sur une plaque carrée à bords fixes, en plein vol. Le front d’onde principal est un cercle qui s’étend proprement depuis la source en haut au centre, et les fines stries verticales à l’intérieur du bol sont les premières réflexions sur les parois latérales qui reviennent. Voilà à quoi ressemble une plaque d’écran tactile SAW quand on tape une fois sur un émetteur piézo et qu’on regarde l’onde s’étaler.

Le même montage mono-source, en mouvement. La source tire une courte rafale sinusoïdale depuis le haut au centre puis se tait ; ce qu'on voit se dérouler est la réponse impulsionnelle de la plaque. Le front d'onde principal s'étend en cercle propre, puis rebondit sur les bords et commence à interférer avec lui-même. Voilà tout le cœur physique de la simulation, bouclé sur un laplacien à 5 points, qui tournait à environ 20 fps dans le code original.

Le code tient dans cinq fichiers C (main.c, simulation.c, simulation.h, events.c, events.h) plus un tout petit utilitaire.h de macros, pour un total sous les 30 Ko de source. Les fonctionnalités qui m’intéressaient pour l’angle multi-touch étaient :

Une grille de 501 par 501 cellules, dessinée pixel par pixel sur une surface SDL, avec une plaque carrée comme bord (la simulation supporte aussi un bord libre et une plaque en disque, plus pertinents pour le côté figures d’ondes stationnaires du projet).
Deux sources oscillantes indépendantes, chacune avec une forme d’onde sélectionnable (sinus, carré, triangle, libre), une fréquence, une amplitude et une phase. On peut les déplacer sur la plaque à la souris. Deux points d’excitation sont utiles dès qu’on commence à penser à distinguer plus d’un toucher simultané.
Atténuation optionnelle, un petit facteur d’amortissement de la vitesse, pour éviter qu’une simulation rebondisse indéfiniment.
Un outil de perturbation : on clique quelque part sur la plaque et la simulation impose une condition de repos local à cet endroit, comme un doigt qui touche une vraie plaque. C’est tout l’enjeu d’un écran tactile SAW, et tout l’enjeu de la simulation pour moi. Cliquer pour placer un toucher, regarder le champ d’ondes changer, regarder ce que voient les récepteurs.
Sauvegarde et restauration d’état dans des fichiers texte, mappées sur les touches O et I avec le pavé numérique pour choisir le slot. Pratique pour comparer la même configuration avec et sans toucher, ce qui est l’expérience sous forme logicielle.
Pragmas OpenMP sur les boucles de mise à jour principales. Le matériel de 2009 était un CPU dual-core ; le portage 2026 tourne confortablement sur n’importe quoi de raisonnable.

Source unique en haut, doigt virtuel placé en bas à droite. Le front d’onde vient juste de balayer la position du doigt ; les anneaux concentriques secondaires qui se forment autour du cercle jaune sont la composante absorbée et ré-rayonnée de l’onde. C’est l’instant où un récepteur SAW commencerait à enregistrer un signal différent du baseline non touché.

Le même burst mono-source, mais avec un doigt virtuel posé sur la plaque en bas à droite (le cercle jaune). Regardez ce qui se passe quand le front d'onde principal le balaye : l'anneau se brise, des cercles de diffusion secondaires fleurissent depuis le point de contact, et la réponse de la plaque n'est plus symétrique par rapport à l'axe de la source. Voilà tout le principe de l'écran tactile SAW en une boucle. On appuie un doigt, les conditions aux limites du problème d'ondes changent, le champ aux récepteurs change, et la position où on a appuyé devient récupérable à partir de la façon dont l'onde a été perturbée sur son passage.

Une mise au point avant que la suite de cette section ne se lise bizarrement. Les deux clips ci-dessus sont la simulation en mode burst : une impulsion sinusoïdale finie, puis silence, enregistrée comme réponse impulsionnelle propre. Le mode burst est quelque chose que j’ai ajouté au programme en 2026, uniquement parce que ça donne une image fixe lisible et une boucle lisible. Le vrai travail de 2009 tournait en excitation continue : une source sinusoïdale entretenue, les récepteurs qui écoutent, le spectre qui s’installe en régime stationnaire, l’outil de perturbation qu’on déplace en direct. C’est le régime où le multi-touch et les gestes glissés ont du sens, parce que les deux sont définis par la façon dont le spectre stationnaire change au cours du temps, pas par une impulsion isolée. Un burst donne un beau GIF. Une source continue donne la vraie boucle d’interaction qui était le sujet du projet.

La qualité visuelle est franchement bonne. Devant la simulation qui tourne en 2026, avec le laplacien à 5 points qui fait son boulot à soixante images par seconde, on voit pourquoi ça marche. On touche la plaque, les nœuds bougent, les récepteurs voient un signal différent, la FFT voit un spectre différent, on lit la position dans le spectre. La simulation est l’explication.

Ce que j’ai bâti dans ma chambre

L’autre moitié du projet, celle qui justifiait la partie cas concret de la soutenance, était un vrai banc d’essai. C’est la photo en haut de ce billet.

La liste de matériel est courte et plaisante :

Une plaque plane. La page de calendrier 3 par 3 dans la photo est le motif de test ; la plaque elle-même, je n’arrive pas à la reconstruire de mémoire avec confiance.
Un haut-parleur (HP dans les schémas français), piloté par un générateur de signal à fréquence fixe. C’est la source SAW.
Deux microphones collés près de deux coins de la plaque. Avec seulement deux récepteurs, l’estimation de position doit venir de l’information spectrale, pas d’une triangulation par temps de vol.
Un ordinateur portable qui faisait tourner la bibliothèque Java de tracé de Michael T Flanagan, utilisée pour faire la FFT du signal enregistré et lire les pics dominants.
Une grille de test 3 par 3 dessinée sur la surface d’essai, numérotée de 1 à 9. La soutenance montre comment le spectre change d’une position à l’autre ; l’étape d’estimation de position utilise ces spectres pour classer un nouveau toucher.

La chaîne de traitement du signal de la soutenance. Source en haut à droite (haut-parleur), deux microphones en bas à droite de la plaque, ordinateur portable au milieu, FFT en bas à gauche, estimation de position en haut à gauche.

Le résultat, comme écrit sur la slide de conclusion, est :

9 sur 9 positions de test classées correctement.
Environ 1 cm de précision spatiale.
Quelques erreurs de classification que j’ai attribuées à l’algorithme plutôt qu’à la physique (« algorithme perfectible »).
Une observation surprenante : la détection sans contact semblait possible. Approcher un doigt près de la plaque, sans la toucher, modifiait déjà le spectre suffisamment pour être détectable. Je n’avais pas creusé ça à l’époque. En 2026, je relis cette ligne dans les slides et j’ai envie d’y retourner pour approfondir.

Densité spectrale de puissance d’un des signaux enregistrés, tracée dans le PlotGraph de Michael T Flanagan. L’information dépendante de la position est dans les amplitudes relatives des harmoniques, ce que l’étape FFT met en évidence.

Neuf sur neuf, isolément, n’a peut-être pas l’air spectaculaire. Remettons les contraintes : un labo de physique de CPGE, deux micros bon marché, une seule source à fréquence fixe, aucune calibration, et un tracé FFT en Java. Comme preuve de concept qu’on peut construire un système de détection de position fonctionnel avec du matériel d’épicerie, ça tient debout.

Le portage 2026 : SDL 1.2 vers SDL 2

Le code original cible SDL 1.2. SDL 1.2 a atteint sa fin de vie en 2012 et n’est plus packagé sur une distribution moderne sous une forme utilisable. Donc la simulation telle que retrouvée sur le NAS ne se compilait pas, ne se linkait pas, et ne tournait pas. La ramener à la vie a été un petit travail mais réel, fait en avril 2026 avec Claude comme partenaire de codage et tracé dans le README du dépôt récupéré. Le diff par rapport à la copie originale est court :

SDL_SetVideoMode a disparu, remplacé par SDL_CreateWindow plus SDL_GetWindowSurface.
SDL_Flip(ecran) a disparu, remplacé par SDL_UpdateWindowSurface(fenetre).
SDL_CreateThread a gagné un argument name en SDL 2 qui n’existait pas en 1.2, donc les appels ont dû être mis à jour.
L’API clavier est le changement le plus invasif. SDL 2 a séparé les touches en keycodes (quel caractère a été logiquement appuyé) et scancodes (quelle touche physique a été appuyée). Le code original indexait un tableau directement par SDLK_* et supposait que les valeurs étaient contiguës jusqu’à SDLK_LAST + 1. Elles ne le sont plus en SDL 2. Le correctif a été d’indexer par scancode à la place, dimensionné par SDL_NUM_SCANCODES, et de convertir entre les deux avec SDL_GetScancodeFromKey à la bonne frontière.
Une poignée de symboles du pavé numérique ont été renommés (SDLK_KP0 en SDLK_KP_0, avec le tiret bas).
inline void calcul(...) a dû devenir static inline pour que le linker soit content sous gcc moderne, parce que le C99 pur ne fournit pas de définition externe.

Quelques bizarreries du code original ont survécu au portage. m_attenuation est déclaré int et utilisé à deux endroits qui ne sont pas d’accord sur si c’est un booléen ou un multiplicateur flottant. La touche SDLK_b est mappée à deux actions différentes dans la même map de touches et la première de la liste chaînée gagne. Aucune des deux n’a d’incidence sur l’expérience. Les deux m’ont fait sourire.

Le résultat compile avec MSYS2 mingw64 gcc 11.2.0 contre SDL 2.30.10, tourne sur Windows sans installeur, et produit la même sortie visuelle que le code original en 2009. Le dépôt récupéré, y compris le binaire et les DLLs, vit sur le NAS de la maison. Je ne l’ai pas encore mis sur un host Git public, parce que ce n’est pas vraiment mon code à publier.

Une coda de 2013

Quelques années plus tard, vers 2013, j’ai rencontré Charles Hudin et j’ai appris qu’il avait travaillé sur l’inverse exact de ce dont parlait mon TIPE. Le papier qui en est sorti, avec mon futur directeur de thèse Vincent Hayward comme co-auteur, est Hudin, Lozada et Hayward, Localized Tactile Feedback on a Transparent Surface Through Time-Reversal Wave Focusing, IEEE Transactions on Haptics 8(2):188 à 198, 2015.

Même plaque, même équation d’ondes 2D, même laplacien à 5 points. Les flèches qui pointent dans l’autre sens. Là où mon TIPE utilisait les ondes arrivant à des capteurs sur le bord pour deviner où un doigt avait été placé, Charles utilisait des signaux retournés temporellement et ré-émis depuis des transducteurs sur le bord pour focaliser un front d’onde sur un point choisi de la plaque, assez brièvement et assez intensément pour créer une sensation tactile localisée juste sous le doigt. Détection d’un côté, génération de l’autre. La même simulation, jouée à l’envers dans le temps.

C’est le genre de connexion qu’on ne voit pas venir. Une fois qu’on la voit, un TIPE de 2009 cesse de ressembler à un fichier fermé et commence à ressembler à la première moitié d’un fil plus long.

Ce qui m’est resté

Il y a un motif que je remarque souvent dans ma propre histoire technique. Ce dont je me souviens d’un projet n’est presque jamais le résultat. C’est la technique, ou parfois juste une seule image. De ce TIPE, ce que j’ai retenu c’est la forme du problème (un laplacien à 5 points sur une grille régulière reste l’introduction canonique à la simulation d’ondes), l’idée visuelle des lignes nodales qui bougent quand on touche la plaque, et la satisfaction de voir neuf sur neuf sur une matrice de confusion. Le travail CUDA, dont je suis sûr de l’avoir fait et dont je ne retrouve pas la source, vit dans ma tête comme une ambition plutôt que comme du code. Et c’est très bien aussi. L’ambition dont on se souvient assez bien pour la décrire est, avec le recul, plus durable que du code dont on se souvient juste comme d’un nom de fichier.

Récupérer la moitié survivante, fichier par fichier en relisant le code source de 2009, a été son propre petit plaisir archéologique : chaque nom de variable dans le bon style français, chaque appel d’API manifestement écrit par un étudiant de CPGE pressé.

Il y a une petite ironie dans la moitié qui a survécu. La version CUDA était l’impressionnante de 2009, celle que j’aurais voulu montrer, celle qui aurait fait dresser l’oreille du jury. Le jumeau CPU était, par comparaison, le sûr et l’évident. Dix-sept ans plus tard, le sûr et l’évident est celui qui tourne encore. Un build CUDA de 2009 ne tournerait pas sur un GPU de 2026 sans son propre portage substantiel : les compute capabilities ont bougé, la toolkit s’est réécrite deux fois, la liste de dépréciations est longue. Du code portable avec une API propre survit à du code spécifique à une plateforme avec une API excitante. Voilà, je pense, la vraie leçon de la fouille.

C | Antoine Weill--Duflos