Jour 2 - C’est reparti !

Me voici dans le train du retour et je prend un peu de temps pour mettre en forme mes notes de la journée. C’est parti pour le récap du jour 2 de Touraine Tech 2026 !

Après une soirée speakers très sympa dans un bar à jeux, je me suis levé un poil trop tard et j’ai loupé la keynote… Dommage 😅.

Lorsqu’un simple bug réseau vous emmène dans les entrailles de Linux

Florian Forestier nous a raconté une histoire de debugging épique.

Le contexte : une équipe de 3 devs en mode “You build it, you run it”, avec une stack Golang/Svelte. Tout va bien, quand soudain arrive un manager qui dit “ça marche PAS”. La PKI est en panne, sur du hardware custom… provenant de matériel reconditionné tchèque (pour la modique somme de 200k€ tout de même).

Le matériel incriminé : des DL380 Gen 10 avec des cartes QLogic FastlinQ 45000. Il y en a 8, et aucune ne fonctionne.

L’enquête commence :

• Les cartes sont visibles dans le BIOS ✓
• lspci les détecte ✓
• Mais ip link ne les voit pas ✗
• dmesg affiche des erreurs sur les drivers qed/qede

Testé avec Ubuntu, CentOS, Alpine Linux -> KO partout. Impossible d’avoir des drivers pour des kernels récents compatibles avec Proxmox.

Après une semaine d’échecs collectifs, Florian a une “idée à la con” : installer une vieille Ubuntu 18.04. Moi ça me fait rire, parce que j’aurais commencé par là ! Quand on a du vieux matériel, on teste avec un OS contemporain du matériel.

Bingo ! Ça fonctionne.

À partir de là, investigation par dichotomie : Debian 12 avec le kernel 4.15 de Ubuntu -> OK. Bug présent en 4.17, absent en 4.16, puis rechercher le commit dans les modifications sur les pilotes qed/qede.

La solution : un code “non supporté” pas pris en compte dans une fonction ajoutée en 4.16. 3 lignes de fix.

Pour reverser le correctif dans le kernel Linux, il a fallu écrire sur la bonne mailing-list, avec ses 8 pages de règles. 3 semaines entre l’envoi du mail et le merge (habituellement 1-2 semaines).

Un beau REX de debugging bas niveau ! J’étais vraiment content de l’avoir vu :).

L’ampoule qui en savait trop : voyage au cœur de la sécurité des objets connectés

Paul Pinault nous a plongé dans le monde de la sécurité IoT.

Quelques chiffres pour poser le contexte : 300 millions d’ampoules connectées vendues chaque année, dont 60% en WiFi (vs Zigbee/ZWave). Et côté réglementation, ça bouge :

• RED (août 2025) : garantie sécurité cyber EN18031, mises à jour possibles et sécurisées, communications chiffrées, données personnelles nettoyées, plus de mots de passe par défaut
• Cyber Resilience Act (2026-2027) : SBOM obligatoire, MAJ pendant 10 ans minimum

Paul a donc disséqué (à la DREMMEL 🤣) une ampoule connectée équipée d’un ESP32-U4WD, avec ses 2 oscillateurs RTC/horloge et son eFuse, pour voir s’il pouvait la compromettre.

Les vecteurs d’attaque analysés :

• Port série et JTAG : désactivés post-usine
• Pairing WiFi : pas RED-compliant (HTTP car pas d’Internet au moment du pairing = pas de certificat, WiFi ouvert)
• BLE Pin : pas possible sur une ampoule
• BLE pairing : la voie privilégiée

Point rigolo : pour que les télécommandes soient CRA/RED compliant, l’ampoule doit aussi devenir une gateway BLE vers Internet (sinon, pas de mise à jour).

Au secours ! Mes images pourrissent mes perfs

Antoine Caron et Mathieu Mure nous ont parlé d’un sujet crucial pour les performances web : les images.

Un peu d’histoire… En 1992, la toute première image est affichée sur le web : les Cernettes (du CERN, évidemment).

Aujourd’hui, 99.9% des sites web ont au moins 1 image, et 68% des pages mobiles ont leur LCP (Largest Contentful Paint) lié à une image.

Le royaume des formats :

• Morts/vieillissants : BMP, GIF, JPEG, PNG
• Modernes : WebP, AVIF, SVG, JPEG XL

Après une chouette explication de comment ça fonctionne “en théorie”, Antoine et Mathieu nous on montré qu’à compression égale, les formats récents prennent moins de place, mais surtout, affichent des artefacts visuels bien moindres dans les hauts niveaux de compression (notamment AVIF).

Les bonnes pratiques présentées :

• Taille adaptative avec srcset pour laisser le navigateur choisir la meilleure taille
• Balises <picture> avec plusieurs <source> pour gérer différents formats
• fetchpriority="high" au-dessus de la ligne de flottaison
• loading="lazy" en dessous
• Sharp en JS pour le traitement côté serveur
• Git LFS pour éviter de commit des fichiers lourds
• Cache de build pour éviter de reconstruire chaque image à chaque CI

Bref, j’ai du boulot sur ce blog (je le savais…).

Makers de Père en Fils

Matthias et Sylvain Gougouzian nous ont présenté un talk bonbon sur leurs projets makers en famille.

Un duo pétillant, pour ne pas dire explosif 😂 ! Matthias (le fils) est super cash (pour rester poli), c’était très rigolo à voir.

L’idée de Sylvain : initier ses enfants à l’électronique, comme nous à l’époque en cours de techno. Objectif : faire 1 à 2 projets par an ensemble.

Après découverte de Scratch (apprendre le code par blocs), Pyrates (approfondir avec Python), Micro:Bit (code visuel avec accéléromètres et boutons), TinkerCAD (conception 3D de projets physiques), Sylvain s’est dit que c’était le moment de passer à un vrai projet DE ZERO. Recréer un équivalent du Nabaztag !

Ils ont utilisé la méthode MoSCoW pour prioriser :

• Must have : Météo (LEDs), Moteurs
• Should have : Écran, GreenIT
• Could have : Micro, HP, Carte SD
• Won’t have : Bourse, Traffic

Choix techniques : ESP32/Raspberry Pico avec MicroPython.

Le moment touchant du talk : apprendre à se dire les choses. Matthias n’osait plus parler à son père quand une tâche était trop grosse, par peur de décevoir. C’est un point qu’en tant que parent, on peut trop facilement oublier…

Une fois les problèmes de communication réglé, ils ont pu découper en étapes : PoC d’abord (NeoLED, écran, servomoteur, bouton, carte microSD), puis passage au MVP avec la forme physique sur TinkerCAD.

Un bel exemple de transmission intergénérationnelle.

Another World, une belle leçon d’architecture logicielle

Olivier Poncet nous a fait découvrir les entrailles d’un jeu cultissime (bon, moi je le connaissais pas 🫣) : Another World.

Un talk que je voulais voir depuis longtemps, mais comme je savais que je le verrai à TNT26, j’avais décidé de ne pas regarder le replay !

Another World, c’est un jeu vidéo d’aventure/action cinématique sorti en 1991, fait par une seule personne (sauf la musique) : Eric Chahi, pionnier du jeu vidéo français des années 80-90.

Les specs impressionnantes :

• Exécutable de 24 Ko
• Assets de 1.2 Mo (images et sons)
• Un moteur graphique polygonal 2D (pour les animations fluides et séquences cinématiques)
• Un moteur sonore 4 pistes PCM
• Une machine virtuelle pour tout gérer !

Le matériel de l’époque : Amiga 500 avec 1 Mo de RAM et un HDD de 20 Mo, augmenté d’un Genlock (caméscope/magnétoscope) et d’un magnétophone. Eric Chahi a créé ses propres outils en GFA Basic. Il a utilisé la rotoscopie : capturer une image vidéo, détourer les assets pour créer les animations. Toutes les peintures et graphismes sont faits à la main.

Les données sont compressées avec l’algo ByteKiller, répandu sur Amiga, économe en RAM.

La VM est impressionnante agit comme une vrai machine : 64 threads, 256 registres, 29 instructions / 200+ opcodes. Olivier est rentré dans les détails de l’implémentation des opcodes et de leur conception.

Le moteur vidéo utilise des framebuffers avec 4 pages (2 backgrounds + 2 fenêtres principales, 2 actives et 2 inactives). Les polygones sont hiérarchisés dans des “bounding boxes” pour gérer l’affichage et les collisions. Les backgrounds, trop complexes pour être calculés en temps réel, sont pré-dessinés et mis en “cache”.

Difficile de tout retranscrire, Olivier nous a montré 1001 autres annecdotes sur les optimisations et autres astuces malines dans ce jeu. Olivier n’avait plus de temps pour nous montrer sa réimplémentation du jeu en C++ (qui fonctionne dans un navigateur avec WASM, si je ne dis pas de bêtises).

Une vraie leçon d’ingénierie avec les contraintes de l’époque !

Communauté et remerciements

Comme toujours, le meilleur d’une conférence reste les rencontres.

Je retiens surtout les longues (très longues) discussions avec Horacio et Yannick de Clever Cloud. J’ai aussi enfin pris le temps de papoter avec Estelle, Geoffrey, Julien (x3, décidément 🙃), Valentin, Stéphane (x2), Aurélie, Florian, Jérôme, et sûrement plein d’autres que j’ai oubliés dans le “blur” de la conférence.

Un grand merci à l’équipe d’organisation de Touraine Tech pour cette édition 2026 réussie. Le passage sur 2 jours et le changement de lieu ont été de bonnes décisions. À l’année prochaine !