storagebits · #devlog

Test de la NUCLEO-F412ZG avec Hubris et Humility

2026-10-18T18:05:17-04:00

Le sujet : une NUCLEO-F412ZG, une carte de développement ST à Cortex-M4, et Hubris, l’OS embarqué d’Oxide Computer, qui ne la supporte pas de base. Le kernel n’a pas bougé d’une ligne. Il a fallu ajouter la carte, adapter trois drivers, mettre à jour le firmware de la sonde et corriger deux fois Humility, le debugger.

La NUCLEO-F412ZG, branchée par l'USB du ST-LINK, la sonde intégrée en bas de la carte. Au-dessus, les trois LEDs utilisateur que pilote la tâche pong.

# Hubris, Humility, c’est quoi ? C’est qui ?

Hubris est un petit OS en Rust qu’Oxide utilise dans ses serveurs pour le contrôleur de service. Chaque tâche vit dans ses propres régions mémoire, protégées par la MPU. Les tâches, leurs priorités et leurs droits sur les périphériques sont tous déclarés à la compilation, dans un app.toml. Humility lit la mémoire de la carte à travers la sonde et la traduit grâce aux infos de debug : état des tâches, piles, registres, dumps.

L’auteur principal, c’est Cliff Biffle. Sa présentation à l’Open Source Firmware Conference 2021 explique pourquoi Oxide a écrit son propre OS. Ce talk est vraiment incroyable, quelle belle pièce d’ingénierie !

« On Hubris and Humility: developing an OS for robustness in Rust », Cliff L. Biffle, Open Source Firmware Conference 2021, 43 min.

On peut aussi citer Bryan Cantrill, cofondateur et CTO d’Oxide, et Adam Leventhal, parmi les grands manitous derrière Hubris. Dans sa présentation sur le debug de Docker en production, à la DockerCon 2015, Cantrill défend une idée simple : un système planté ne se redémarre pas avant d’avoir été débogué, en direct ou d’après une image de sa mémoire, le core dump. Humility fait les deux : humility tasks lit la carte en marche, humility dump sauve son état complet dans un fichier qu’on examine ensuite carte débranchée.

« Running Aground: Debugging Docker in Production », Bryan Cantrill, DockerCon 2015. Docker a retiré la vidéo d'origine en 2018 ; c'est la copie republiée par Cantrill.

# Ce qu’il a fallu patcher

Je colle un prompt de mission à Claude : faire tourner Hubris sur cette carte, branchée en USB sur le Mac. Sa cible la plus proche dans le dépôt est une carte Discovery à STM32F407. Le soir même, Hubris tourne à 100 MHz sur la NUCLEO.

Ce qui a été patché, couche par couche :

Le kernel : rien, pas une ligne.
La carte et l’app : des ajouts purs. Un fichier de carte de 2 lignes (le nom de la puce pour probe-rs), une description de la puce (1 Mio de flash, 256 Kio de RAM, adresses des périphériques), et l’app elle-même, avec la configuration d’horloge à 100 MHz. La branche ajoute 621 lignes, documentation comprise.
Trois drivers partagés, environ 150 lignes : stm32fx-rcc choisit la variante F412 de la bibliothèque de registres, user-leds pilote les LEDs de la Nucleo sur PB0, PB7 et PB14, et stm32fx-usart passe sur USART3 (PD8/PD9), le port série virtuel du ST-LINK, cadencé à 50 MHz. Le point délicat : deux variantes de puce du crate stm32f4 ne peuvent pas cohabiter dans une même tâche, et deux de ces drivers forçaient la F407 dans leur Cargo.toml. Ce choix est passé dans une feature. La Discovery compile à l’identique, revérifié à chaque étape.
La sonde : le firmware du ST-LINK, trop ancien, a dû être mis à jour.
Humility, le debugger : deux correctifs, détaillés plus bas. Le premier répare Humility face au Hubris le plus récent, quelle que soit la carte. Le second corrige une mesure fausse qu’on voit sur cette carte.

# La mission, en tranches

Le north star du prompt tient en une phrase : « humility tasks montre toutes les tâches Healthy sur la NUCLEO-F412ZG, les LEDs utilisateur clignotent sous le contrôle de pong, et ping écrit sur le port COM virtuel du ST-LINK. » Cinq tranches, chacune doit finir sur du matériel qui marche : préflight, build de référence, premier allumage sur l’oscillateur interne à 16 MHz, UART, puis 100 MHz.

Premier arrêt dès la tranche 0. Le firmware du ST-LINK de la carte est en V2J25 ; probe-rs, sur lequel s’appuie Humility, exige J26. Le prompt disait de s’arrêter et de demander. Claude propose de patcher automatiquement, je lui donne le zip téléchargé du site de ST et c’est fait.

Toutes les tâches sont Healthy. Claude ne voit pas les LEDs : il lit le registre de sortie de GPIOB plusieurs fois de suite et le voit alterner entre PB14, PB0 et rien, au rythme de pong. La carte tourne à 100 MHz. Sur 10 secondes, l’horloge de Hubris compte 10 235 ms pour 10,32 s au mur, l’écart étant la latence de connexion de Humility.

La tranche 4 : de 16 MHz sur la HSI à 100 MHz. Chaque constante est justifiée par une section du RM0402 dans le code, et relue dans les registres une fois flashée.

# Le moment où ça a cassé : SavedState

Juste avant le premier allumage, humility tasks échoue : « expected structure SavedState not found ».

Pour comprendre, il faut savoir comment Humility lit une tâche. Quand le kernel interrompt une tâche, il range ses registres (r4 à r11, le pointeur de pile, etc.) dans une structure, le champ save de l’entrée Task de cette tâche. Humility lit la table des tâches directement dans la RAM de la carte. Pour savoir à quel octet se trouve chaque registre, il a besoin du plan de cette structure, qu’il trouve dans les infos de debug (DWARF) du binaire du kernel. Et il la cherchait par son nom : SavedState.

Le 9 octobre, quatre jours plus tôt, la PR #2704 de Hubris a introduit un trait Arch pour que le kernel puisse viser plusieurs architectures. La structure de l’ARMv7-M y a pris le nom ArmMSavedState. Humility ne la trouve plus, et ni humility tasks ni la lecture des registres d’une tâche ne marchent, quelle que soit la carte.

Deux façons de s’en sortir. Claude fige d’abord la branche juste avant ce commit et continue, ce qui suffit pour cette carte. C’est dans DECISIONS.md, et ça débloque. Ensuite, le correctif, sur la branche savedstate-by-member de mon fork de Humility : au lieu de chercher le type par son nom, Humility prend le type du champ save de Task, que le DWARF donne directement. Le nom peut changer, le champ reste. Onze lignes ajoutées, quatre retirées, aux deux endroits qui lisaient cette structure : humility tasks et la lecture des registres. Le correctif marche avec l’ancien kernel et avec le nouveau, testé sur la carte dans les deux cas.

# Le second correctif : stackmargin affichait des zéros

humility stackmargin dit, pour chaque tâche, combien de pile elle n’a jamais utilisée. Le principe : au démarrage d’une tâche, le kernel remplit toute sa pile avec un motif, 0xbaddcafe. Humility lit la pile depuis le bas et compte les mots encore intacts : c’est la marge.

Sur la carte, il affiche une marge de 0 pour jefe, le superviseur, avec une pile de 152 octets alors que son app.toml en déclare 2200.

La MPU d’un Cortex-M4 ne connaît que des régions dont la taille est une puissance de 2. Depuis avril (PR #2458), Hubris découpe la RAM d’une tâche en plusieurs régions contiguës pour moins gaspiller : les 2560 octets de jefe font 1 Kio + 1 Kio + 512 octets au lieu d’une région de 4 Kio. Une pile peut donc s’étaler sur plusieurs régions. Le kernel a été corrigé en mai (PR #2492) pour la peindre en entier. Humility, lui, ne lisait que la région qui contient le sommet de pile : ici la dernière, où ne tiennent que 152 octets de pile, tous utilisés. D’où la marge de 0.

Relevé sur la carte (humility map, readmem). Humility ne regardait que la région qui contient le sommet de pile. Le kernel, lui, peint toute la pile en 0xbaddcafe sur les trois régions.

           STACKBASE  STACKSIZE  MAXDEPTH  MARGIN
avant  jefe 0x20001c00       152       152       0
après  jefe 0x20001400      2200       272    1928

Le correctif, sur la branche stackmargin-multi-region, descend les régions contiguës qui appartiennent à la même tâche, comme le fait le kernel, avant de mesurer. Le test de non-régression de Humility l’a aussi validé : sur un dump de Sidecar, un vrai switch d’Oxide, l’instantané attendu contenait trois faux « MARGIN 0 ». Après correction, chaque taille de pile égale à l’octet près celle déclarée dans l’app.toml de ce Sidecar.

# Où j’en suis

La branche nucleo-f412zg compte cinq commits, avec un DECISIONS.md et un README. Elle est figée avant la PR #2704 ; avec le premier correctif, Humility suit aussi le kernel récent. Les deux correctifs sont sur mon fork de Humility. La suite de tests du kernel sur la F412, la tranche 5 optionnelle, n’est pas faite. Et « tout Healthy » n’est vrai qu’à moitié : ping fait exprès une faute toutes les 100 réponses de pong, comme dans les démos d’Oxide.

Une piste pour la suite, pas encore faite : un capteur I2C ou SPI derrière une tâche driver. Dans Hubris, un driver est une tâche comme une autre : elle seule a accès aux registres du périphérique, déclarés dans l’app.toml, et les autres tâches lui parlent par messages. Le driver I2C du dépôt vise les STM32H7 et G0 (plus un driver à part pour le LPC55), le SPI seulement les STM32H7 et le LPC55 : rien pour la famille F4, il faudrait l’écrire pour cette carte.

À suivre…

Une montre de 2020, un firmware complet, trois jours

2026-10-16T00:00:00+00:00

J’ai acheté une LilyGO T-Watch 2020 il y a six ans, parce qu’elle était bon marché et idéale pour tester et bricoler. Développer dessus demandait en revanche un vrai investissement : du C/C++, un framework à apprendre, des notions d’embarqué. Elle a fini dans un coin, avec d’autres side projects inachevés.

Avec l’IA, tous ces freins sautent : en quelques minutes, j’avais un firmware complet, écrit de zéro. Sans l’IA, je ne l’aurais pas ressortie du tiroir : y créer quelque chose demandait trop d’efforts.

Quels appareils dorment chez vous ? Imaginez ce que vous pourriez en faire, en un temps record.

Le billet sur les quatre jours a déjà raconté le premier flash. Ici, je reste sur la montre.

# Ce que je voulais

Un cadran de chronographe d’aviation et des afficheurs 7 segments façon « circuits temporels ». Puis la météo, les bus et les notifications de l’iPhone. La liste complète des applications est dans le README du dépôt.

Ma méthode tient en deux gestes. J’expose simplement les fonctions que je veux. Puis je demande tout de suite de concevoir une première version de bout en bout, pour avoir une boucle de retour courte. Le résultat devient convaincant très vite.

J’ai piloté le développement en langage naturel, en exprimant des intentions. En lisant le code généré, j’ai aussi beaucoup appris, tant sur le langage que sur les frameworks et les concepts d’embarqué. La portée pédagogique est immense !

# Le commencement

Premier commit à 3 h 22. Le prompt de mission imposait deux règles : sauvegarder les 16 Mo de flash d’origine avant toute écriture, et ne jamais toucher aux eFuses ni à la tension du cœur.

La sauvegarde a failli échouer. À 921 600 bauds, le port USB a disparu en pleine lecture. L’agent a recommencé à 230 400 bauds, par blocs de 1 Mo vérifiés un par un, parce qu’au-delà le câble introduisait des erreurs. À 3 h 46, la sauvegarde complète était vérifiée et son empreinte SHA-256 consignée. À 3 h 48, premier flash vérifié sur la montre.

J’ai eu un peu peur de bricker la montre. Je ne savais pas d’où venait la panne ; probablement du câble. L’agent a tout pris en charge, jusqu’à essayer un flash lent et fractionné pour composer avec ce câble défectueux (!). Ses questions et ses méthodes étaient pertinentes et précises, et c’est ce qui me donnait confiance.

À 4 h 09, le cadran d’aviateur s’affichait, avec une trotteuse à 8 Hz.

Le cadran d’aviateur, capturé sur la vraie montre par le port série. Capture déjà publiée dans le billet précédent.

# Le moment où ça a cassé

Branchée en USB, la montre tenait. Sur batterie, elle plantait systématiquement au bout de quelques secondes. Dans la matinée, je craignais qu’elle soit brickée, et je pressais l’agent d’aller vite avant le plantage suivant. J’ai dû l’éteindre et la rallumer trois fois.

Il y avait deux causes, trouvées l’une après l’autre. D’abord, le chien de garde du processeur restait armé pendant le sommeil léger. Il est maintenant suspendu avant la mise en veille et réarmé au réveil. Ensuite, un appui sur le bouton figeait la montre. La ligne d’interruption de la puce d’alimentation reste à l’état bas tant qu’on ne la lit pas, et l’interruption se redéclenchait sans fin. Les interruptions GPIO sont désormais désactivées pendant le sommeil, et j’ai constaté que la montre tenait très bien.

# Une décision : ne plus dépendre du câble

Les coupures USB revenaient pendant les flashs. Il y avait deux options : attendre que le port revienne, ou rendre le câble accessoire. L’agent a proposé le « mode atelier » : quand la montre est alimentée par USB et que le Wi-Fi est configuré, elle reste connectée, accepte les mises à jour par Wi-Fi (OTA) et expose une console TCP. Un Wi-Fi allumé en permanence est normalement un anti-pattern. Sur secteur, la batterie n’est pas en jeu, et l’option se désactive.

Comme le câble lâchait, l’agent est passé de lui-même aux mises à jour par Wi-Fi (OTA). Magique ! Plus tard, les coupures sont aussi apparues pendant que le processeur était dans son chargeur de démarrage en ROM : le problème est donc matériel, pas logiciel. Un mode sans échec a suivi : après trois plantages d’affilée dans la première minute, le Bluetooth ne démarre pas, pour qu’on puisse toujours réparer la montre à distance.

La vraie montre sur l’écran de diagnostic, le premier écran flashé. Photo déjà publiée dans le billet précédent.

# Où j’en suis

Le problème de câble (B2 dans BLOCKERS.md) reste ouvert : la connexion micro-USB est toujours fragile. Le double tapotement qui réveille l’écran reste un peu aléatoire, mais il fonctionne. Le geste du poignet pour réveiller la montre est encore à régler. L’autonomie sur une journée n’est pas encore mesurée.

Ce qui m’a le plus impressionné, c’est la rapidité avec laquelle l’agent a flashé la montre en autonomie et m’a montré des résultats concrets. J’ai hâte de l’essayer sur d’autres appareils. Je vais d’ailleurs bientôt ressortir mes micro:bits : j’ai une idée de projet !

Douze minutes entre l'idée et la télé

2026-10-12T00:00:00+00:00

Jeudi 8 octobre, 20 h 34, j’envoie un prompt de mission à un agent. 20 h 46, l’heure s’affiche en grand sur ma télé, dans une typo choisie par l’agent.

Quatre jours plus tard : six projets, 159 commits, quelque 240 messages de ma part, dont une bonne partie font moins de cinq mots. « go T8 ». « vas-y présente la tranche 3 ». « c’est fait, reteste ».

Le délai entre l’intention et le concret est devenu ridicule. Douze minutes pour l’application Almanak. Seize pour Lukarne. Le goulot d’étranglement, maintenant, c’est moi : mon sommeil, mes câbles, mes quotas.

Une ligne par projet, du jeudi 19 h au lundi 19 h. Le chiffre à droite compte les commits. Survole les cercles pour les heures exactes.

Chaque ligne est un projet, chaque trait un commit. Le cercle vide, c’est mon premier message à l’agent. Le plein, relevé au-dessus de la ligne, c’est le premier truc concret : l’app qui tourne sur la télé, le firmware sur la montre, la double authentification active sur la passerelle du homelab. Les bandes grises, ce sont les nuits. Il y a des commits dedans. Pas toujours parce que j’étais debout.

# Jeudi soir : trois agents en 45 minutes

Le 8 au soir, en 45 minutes :

20 h 34 : la mission Almanak part.
20 h 36 : je relance shot2cart, un projet commencé en septembre avec un autre outil. « inspect project, it comes from an other AI conversation, inspect and we pursue ».
21 h 07 : je télécharge depuis claude.ai le CLAUDE.md de mon homelab, que je redesign par LLM, et que je venais d’écrire avec une autre instance pendant que la première construisait Almanak.
21 h 19 : « je viens de créer CLAUDE.md pour toi, c’est parti ! »

Personne n’attend personne. Pendant qu’un agent compile, j’écris la mission du suivant avec un troisième.

# Almanak, l’étincelle

Le north star tenait en une phrase :

Un écran qu’on a envie de laisser allumé. Quand je passe devant ma télé, je sais en 2 secondes : l’heure, la date, le temps qu’il fait et va faire, et dans combien de minutes passe mon prochain bus. C’est beau comme un objet de design, pas comme un dashboard d’admin.

Et une règle que j’ai gardée pour tous les projets suivants : aucune tranche n’est finie tant que l’agent ne l’a pas vue tourner sur la Shield. Il fait une capture par adb, il la lit, il la critique. Lisibilité à 3 m, overscan, débordements. Et pour chaque tranche visuelle, deux variantes, on garde la meilleure.

Almanak sur la Shield le premier soir : le thème sombre à 22 h 17, le thème papier à 21 h 38.

Sept tranches entre 20 h 46 et 22 h 32. Pour l’horloge, l’agent a comparé une police serif éditoriale et une sans-serif suisse, et il a gardé Fraunces parce qu’à 3 m, Inter en graisse 200 « commence à ressembler à un fil de fer ». Il a raison.

Le meilleur bug : la synchro des horaires de bus renvoyait HTTP 441 sur la Shield et marchait depuis le Mac. L’agent a fouillé dumpsys connectivity et trouvé le VPN qui tourne sur la Shield : le site de la STM (le réseau de transport de Montréal) refuse les IP de sortie des VPN. Il a basculé sur un miroir du même flux, octet pour octet, et documenté le split tunneling dans le README. Le prompt ne parlait pas de VPN.

Pour être honnête : ma définition de « fini » demandait 24 h d’écran de veille sans fuite mémoire. La mesure réelle couvre à peu près une heure. Fini, donc. Avec des guillemets.

# Lukarne, mon préféré

Le lendemain, 17 h 58, deuxième mission. Une fenêtre sur le monde : faire tourner un globe à la télécommande, plonger sur une région, voir une mosaïque de webcams en direct, zapper d’une caméra à l’autre. La phrase qui compte dans le prompt :

Si une interaction n’est pas fluide à la télécommande, elle est ratée, même si elle est techniquement correcte.

Et une autre, plus discrète, qui explique pourquoi tout est allé si vite : « J’ai déjà développé une autre app Google TV avec toi sur cette même Shield. Avant toute chose, retrouve dans mon environnement […] comment on s’y connecte […]. Réutilise ce qui marche. » Chaque projet laisse derrière lui une adresse adb, un script de déploiement, un format de DECISIONS.md. Le suivant part de là.

18 h 14 : premier direct en plein écran sur la télé, HLS et YouTube, gauche/droite pour passer de l’un à l’autre. 16 minutes. À 20 h 54, la V1 était là : un globe jour/nuit en OpenGL à 60 images par seconde (3 ms par image), 1 640 caméras dans 34 régions (19 de plus depuis lundi), une mosaïque 3×3 dont la tuile sélectionnée passe en direct en deux secondes, et un bouton « surprends-moi » qui t’envoie là où il fait jour. Deux tests d’endurance de 22 minutes, zéro crash.

Lukarne : l’Europe de nuit, Venise sélectionnée, 16 webcams en direct, le bassin de Saint-Marc en coin d’écran.

Le plus simple, c’est de la regarder tourner :

78 secondes sur la Shield, sans le son : le globe jusqu'à la Californie, la plongée sur Pollock Pines, la mosaïque de caméras d'autoroute en direct, le plein écran, la caméra suivante, on remonte, puis « surprise me ».

Cette vidéo, c’est l’agent qui l’a tournée, lundi soir, pour ce billet. Il pilotait la Shield à la télécommande virtuelle (adb shell input keyevent) et enregistrait l’écran avec screenrecord. Il a fait une première prise en français, en Europe, où il était 1 h du matin : tout était noir. Il a refait la prise en anglais, en Californie, de jour.

La mosaïque d’un lieu, puis le plein écran. Gauche/droite passe à la caméra voisine sans repasser par la mosaïque.

« surprise me » est tombé là-dessus, en plein tournage. La caméra aurore d’explore.org à Fairbanks, 15 h 09 heure locale : sans doute une rediffusion de la nuit entre deux plans en direct.

Puis je l’ai utilisée, et je me suis plaint. Samedi, 23 h 20 : « je suis assez surpris du peu de flux video , bcp d’images fixes qui apportent peu ». 23 h 34, commit : le direct d’abord, les images fixes en option. Quatorze minutes.

Dans la nuit de dimanche à lundi, minuit huit : « parfait , je vais dormir là ». Et deux demandes : « les vignettes pixelisée : on peut trouver un moyen de charger ne serait ce qu 1 frame propre plutôt que la vignette degeueu ? », et pour le dernier niveau de zoom, un « effet plongeant genre zoom google earth ». À 0 h 26, les vignettes sont des vraies images capturées sur l’appareil pendant la lecture. À 0 h 48, on plonge sur un lieu avec un zoom ×30, les lumières s’allument, et on remonte. À 0 h 59, test d’endurance de 10 minutes après tout ça. Je dormais.

Lundi après-midi, j’ai demandé un mode démo, pour que la télé voyage toute seule. 41 minutes plus tard :

Le mode démo : des caméras au hasard, là où il fait jour, jamais deux fois la même région, avec un fondu sur un carton-titre entre deux.

Les réglages, au bout de la télécommande : langue (anglais, français, espagnol), unités, images fixes ou direct seulement, lecteur en coin, durée par caméra du mode démo, et les crédits de chaque source.

Ce qui manque encore : la couverture en direct hors Amérique du Nord reste mince. Le premier jour, l’agent a brûlé tout le quota de recherche YouTube pendant que deux bugs cachaient les résultats. Aujourd’hui, un dépôt public republie chaque jour le catalogue des directs, et l’app le télécharge derrière son logo. Et il y a un bug que je ne sais pas toujours reproduire : une webcam YouTube qui reste figée quand on en enchaîne deux. Je l’ai signalé à 15 h 46, il y a eu un correctif à 16 h 31. Reste à le vérifier sur la télé.

# DropboksTV, un dimanche après-midi

Un client Dropbox pour la télé, pensé pour le canapé : photos et vidéos d’abord, lecture seule, pas de backend. Dimanche, 15 h 18 : « read prompt-dropbokstv-claude-code.md and go ». 16 h 02 : l’appairage par téléphone marche sur la télé. 18 h 28 : huitième et dernière tranche, avec la recherche, le mode hors ligne, l’écran de veille et 128 textes traduits par langue.

Le morceau le plus tordu, c’est l’appairage. Se connecter à Dropbox depuis une télé, sans clavier, ça devrait être un code à taper sur le téléphone. Sauf que l’API de Dropbox ne propose pas ce flux. L’agent l’a vérifié dans le SDK et l’a consigné dans son journal de décisions. Il a donc monté autre chose :

la télé affiche un QR code qui pointe vers une page servie par la télé elle-même, sur le Wi-Fi de la maison ;
le téléphone ouvre cette page, qui l’envoie autoriser DropboksTV chez Dropbox ;
Dropbox affiche un code, on le colle sur le téléphone, et la télé l’échange contre un jeton (PKCE : le secret ne quitte jamais la télé, pas de backend) ;
la session expire au bout de 10 minutes et la télé renouvelle le QR toute seule. Une faute de frappe ne grille pas la session. Et si le téléphone ne voit pas la télé, un bouton bascule sur le lien Dropbox direct.

Le petit serveur HTTP de la télé (150 lignes), il l’a repris d’Almanak.

L’appairage

Et puis il y a le lecteur. En trois tranches, entre 16 h 25 et 18 h 07, l’agent a écrit une visionneuse qui ouvre à peu près tout :

les photos, avec un zoom ×2 et ×3 qu’on déplace aux flèches, et un diaporama en fondu ou en Ken Burns ;
les vidéos : H.264, HEVC jusqu’en 4K, reprise là où on s’était arrêté, sous-titres .srt ;
les PDF, page par page, avec zoom ;
Word et PowerPoint, que Dropbox convertit en PDF, et les tableurs, mis à l’échelle à 170 % pour être lisibles depuis le canapé ;
le Markdown mis en forme, le code avec numéros de ligne et coloration ;
la musique, MP3 et FLAC, avec la pochette ;
et pour tout le reste, un QR code qui envoie le fichier sur le téléphone.

Le lecteur vidéo a pris 16 minutes. Les documents, la musique et l’envoi vers le téléphone, 27. La folie.

Dans l’ordre : photo zoomée, vidéo, PDF, tableur, Markdown, code, musique, envoi vers le téléphone (QR flouté). Les fichiers de test, c’est l’agent qui les a fabriqués et déposés dans un dossier Dropbox dédié. Captures prises pendant le développement.

# Kronograf, ou le retour du matériel

Lundi, 3 h 19 du matin, une montre LilyGO T-Watch de 2020 branchée en USB, et une mission : un cadran de chronographe d’aviation, et des afficheurs 7 segments « circuits temporels ». À 3 h 48, premier flash vérifié sur la montre, après une sauvegarde complète de la flash d’origine. C’était la règle n° 2 du prompt : on n’écrit rien sur la montre sans filet. Le câble a lâché pendant la première sauvegarde, et l’agent a refusé de flasher tant qu’il n’en avait pas une complète.

La vraie montre, lundi à 18 h 11 : l’écran de diagnostic, le premier écran flashé. En vert, les puces détectées ; en gris, ce que la V1 n’a pas.

À gauche, capture de la vraie montre par le port série. À droite, le cadran « circuits temporels » dans le simulateur, qui compile exactement la même interface.

Là, le délai remonte, et ce n’est pas la faute de l’agent. Ce n’est plus du code contre un émulateur, c’est un connecteur micro-USB fatigué. Mes messages de la matinée : « elle plante systematiquement au bout de quelque secondes », « va vite sinon elle plante », « j’espère qu’elle n’est pas brikée ». Le problème venait du sommeil léger, avec une tempête d’interruptions au réveil par le bouton. À 11 h 17 : « ce semble tres bien tenir maintenant ». À 11 h 18 : « go pour la météo ». À 11 h 31, la montre affiche la météo et le prochain bus en temps réel.

Ce soir, elle a 33 commits, des alarmes, un chrono, un podomètre, des mises à jour par Wi-Fi et les notifications de l’iPhone en Bluetooth, qui accrochent encore mal. Le double tapotement est « un peu alétoire , comme le mouvement du poignet … mais ca passe ».

# Le homelab, et l’app shot2cart

Le chantier le plus long ne se voit pas. Soixante commits et 276 messages pour remettre à plat le serveur de la maison : état des lieux, sauvegardes avec de vrais tests de restauration, accès à distance par passkeys pour la famille, alertes, une page d’accueil avec un schéma animé de l’infra et un autre du réseau local.

Mon message préféré de toute la série, le premier soir : « ignore cet audit ; je ne compte que sur toi maintenant ». Le plus honnête, dimanche : « Nest dans Home Assistant c’est payant ??!! ». Et ouais, 5 $, merci Google.

shot2cart, c’est le contre-exemple. Le pitch de l’app, c’est une photo d’une liste de courses, et le panier s’ouvre chez le marchand en moins de 15 secondes, sans rien taper. Première tentative en septembre, avec un autre outil et un workflow de spécifications : trois jours, deux commits. Jeudi soir, je l’ai relancée sur cette base. Dimanche, 20 h 13, j’ai tout archivé : « forget about previous session, I archived the previous project and to start a new one with better prompt ». 23 h 01 : photo, analyse par un modèle de vision, liens marchands article par article. Minuit quatre : « I’m going to sleep […] please go as far as you can in full autonomy ». Le matin, il y avait la détection en streaming, des fiches de relecture et des parcours de test automatisés.

Même idée, même développeur. La différence entre septembre et ce dimanche, c’est la qualité des modèles, et notamment Opus 5.5. Une bête !!!

# Le délai, mesuré

Type	Ce que j’ai demandé	Délai jusqu’au commit
FEAT	« ajoute la langue espagnole à l’application » (Lukarne)	5 min
BUG	Les voisins à 2 500 km : « je suis sur Londres mais la Patagonie est listée »	5 min
BUG	Le logo qui n’apparaît qu’une demi-seconde au lancement	2 min
FEAT	Plus de direct, moins d’images fixes	14 min
FEAT	Le zoom plongeant « genre Google Earth », demandé avant d’aller dormir	40 min
FEAT	Un mode démo qui enchaîne les webcams au hasard	41 min
BUG	La vidéo récente qui ouvre toujours une vidéo de 2012 (DropboksTV)	2 min
FEAT	« go pour la météo » sur la montre	13 min

Ce qui ne va pas plus vite : un câble micro-USB qui se débranche, un quota YouTube qui se remet à zéro à 3 h du matin, une clé d’API que le portail du fournisseur refuse, mon abonnement. Dimanche, 16 h 46 : « il me reste que 10% pour notre session en cours ». Et mon sommeil, que j’ai fini par intégrer au plan : « je vais dormir la , avance au maximum de ton autonomie ».

Ce que je ne sais pas encore : combien de ces six projets j’utiliserai encore dans un mois. Faut aller au bout maintenant, publier ce qui est publiable, alimenter d’autres agents.

Ce billet a été fait pareil. Un message de ma part lundi en fin d’après-midi, en vrac, avec mes fautes de frappe : « génère moi un article complet […] mettre en avant le délai ridicule que c’est devenu entre l’intention et le concret ». Reprends tout en transparence et honnêteté. Le blog lui-même était en ligne 45 minutes après mon premier message, lundi à 4 h du matin.

En bref, une bonne fin de semaine !