Comment Claude Code et moi avons « réussi » à endommager du matériel
Il se passe des choses intéressantes quand l'IA rencontre le matériel du monde réel !
Par Greg Chrystall
Note avant lecture : ce billet est écrit à la main par moi, pas par une IA, sauf la section de transcription, qui reprend les mots de Claude.
Barnluren veut être un produit simple et économique qui permet aux parents de faire revenir un téléphone fixe à la maison pour un coût très faible, afin que les enfants de 2026 découvrent ce qu'est une communication uniquement vocale, sans écran.
Pour tenir cette ambition, nous devons construire pas mal de composants, qui vont de l'expérience utilisateur de haut niveau — les boutons de l'application, les polices et les couleurs — jusqu'aux modules du noyau Linux qui font le vrai travail : convertir ces voix mignonnes en signaux électriques transmis au combiné téléphonique physique. Cette histoire parle du niveau le plus bas, et de la façon dont travailler avec du matériel peut devenir intéressant !
Les adaptateurs téléphoniques analogiques (ATA)
Un ATA est le pont entre le numérique et l'analogique. Les téléphones à l'ancienne sont tous analogiques : ils fonctionnent en envoyant un signal analogique, un peu comme un tourne-disque ou un lecteur de cassettes. Pour leur parler depuis un smartphone ordinaire, ou pour les faire communiquer entre eux via internet, qui est numérique, il faut convertir les uns et les zéros numériques en analogique, et inversement. Je me souviens qu'adolescent, nous avions cet appareil : une cassette audio avec un fil qui en sortait. On glissait la cassette dans l'autoradio et on branchait le fil sur son Discman qui lisait un CD numérique. C'est exactement ce que fait l'ATA — mais avec un téléphone.
Notre objectif est de fabriquer nos propres appareils. Nous voulons un appareil très simple : vous le branchez sur le secteur, vous le connectez à votre wifi, puis vous branchez un vrai téléphone analogique (récupéré, idéalement) sur son unique port téléphonique. Malheureusement, un tel appareil n'existe pas, mais nous en avons trouvé un suffisamment proche : il avait le port téléphonique, mais aussi beaucoup d'autres fonctions et ports. Nous nous en servons comme banc d'essai pour développer la couche la plus basse du logiciel qui fait tourner l'appareil : le firmware.
Notre firmware s'appuiera sur l'excellent projet open source OpenWRT. J'écrirai plus tard un autre billet sur la beauté du logiciel libre, car c'est absolument essentiel pour permettre à deux personnes de construire un produit comme Barnluren de A à Z. Faire fonctionner OpenWRT sur un nouvel appareil demande de tripatouiller le matériel, et c'est là que nous avons failli déclencher un incendie !
Claude Code
Si vous ne savez pas ce qu'est Claude Code, il faut le comprendre pour que cette histoire ait du sens. C'est un agent de programmation : il est très doué pour écrire du code dans presque n'importe quel langage et possède une connaissance encyclopédique de presque tout. Claude fait vraiment tout le gros du travail dans ce projet : tout le code, les déploiements, l'administration des serveurs, le débogage, etc. Donc, naturellement, pour faire de la rétro-ingénierie sur le matériel de l'ATA que nous utilisons et pouvoir construire notre propre version open source, Claude et moi avons fait équipe.
Mon rôle dans l'équipe ressemble à celui d'un coach ou d'un manager. Je fixe les buts et les objectifs, Claude m'aide à comprendre tous les détails, puis nous établissons ensemble un plan pour y arriver. Claude s'occupe ensuite de tout le code, des scripts et des tests sur les appareils. Dans ce cas précis, j'utilise en fait deux instances de Claude Code en parallèle : le Claude opérationnel, qui écrit tout le code et se connecte aux appareils, et le Claude coach, qui m'aide à apprendre, à travailler la stratégie et à superviser le Claude opérationnel.
Nous étions en train de faire fonctionner les circuits haute tension de l'ATA : c'est ce qui fait sonner la sonnerie du téléphone. Le procédé consiste à étudier soigneusement ce que fait l'appareil quand il tourne avec le firmware d'origine du fabricant, puis à écrire son propre code qui reproduit ce comportement, et à observer comment l'appareil réagit avec votre version. Cette rétro-ingénierie se fait au petit bonheur : on appuie sur tous les boutons et on regarde ce qui se passe, jusqu'à avoir la carte complète.
Nous n'avions pas tout à fait la carte complète la première fois que nous avons testé la mise sous tension de ce circuit DC-DC haute tension : quand nous l'avons démarré, l'appareil s'est mis à fumer ! Voici comment s'est déroulée la conversation avec Claude.
Le Claude opérationnel et le Claude coach ne peuvent pas se parler directement : je relaie les messages entre eux par copier-coller.
Le Claude opérationnel venait de compiler et d'envoyer du nouveau code sur l'appareil, puis de l'exécuter en SSH. Ce code tentait de démarrer pour la première fois le convertisseur DC-DC haute tension à l'intérieur de la puce téléphonique. Je regardais la sortie du terminal quand l'appareil a soudainement redémarré.
Conversation avec le Claude opérationnel :
Moi : L'appareil redémarre. On l'aurait grillé, d'une manière ou d'une autre ?
Claude : Non, il est quasi certain que nous ne l'avons pas grillé. L'appareil a un watchdog qui le redémarre automatiquement. Ce qui s'est le plus probablement passé : notre code fait basculer des broches GPIO du SPI matériel du noyau vers le mode GPIO, pour notre SPI en bit-bang vers la puce téléphonique. Pendant les temporisations de mise sous tension du DC-DC, le noyau a sans doute voulu lire la mémoire flash, a trouvé les broches du contrôleur SPI confisquées, et a paniqué. L'appareil va démarrer normalement — il dispose d'un double démarrage de secours.
Claude était sûr qu'il s'agissait simplement d'un redémarrage par le watchdog. Puis j'ai remarqué quelque chose.
Moi : Oui, ça sent le brûlé.
Le ton a changé immédiatement.
Claude : Débranchez l'appareil immédiatement.
C'est sérieux. Ce qui s'est probablement passé : la corruption des registres étant corrigée, le convertisseur DC-DC s'est vraiment mis à commuter cette fois, mais peut-être avec des paramètres inadaptés à la topologie d'alimentation propre à votre carte. Si la polarité du driver de commutation est inversée, cela peut provoquer un court-circuit traversant dans les FET — les transistors côté haut et côté bas conduisant en même temps — ce qui brûle des composants.
Moi : L'appareil est encore dans son boîtier. Je ne vois donc pas facilement les composants. Ça sent vraiment l'électronique qui brûle.
Claude : Nous avons en quelque sorte « réussi » jusqu'à endommager le matériel. Les essais précédents n'atteignaient jamais ce point — les registres corrompus faisaient échouer l'opération sans danger.
Je suis désolé. Avez-vous un deuxième appareil FTA1101 ?
Pendant ce temps, je suis passé à mon Claude coach et je lui ai raconté ce qui venait d'arriver :
Moi : Ça devient palpitant !!!! (transcription complète collée)
Claude coach : Voilà un moment effrayant. L'analyse de l'autre Claude est juste — les registres étant désormais corrects, le convertisseur DC-DC a réellement tenté de commuter pour la première fois, et si l'un des paramètres du convertisseur ne correspond pas à l'étage de puissance propre à votre carte, vous obtenez un courant destructeur.
Avant de retoucher quoi que ce soit à la mise sous tension du DC-DC, l'approche doit changer du tout au tout : Lisez, ne devinez pas. Démarrez le firmware d'origine et capturez les vraies valeurs en cours d'exécution pendant que le convertisseur tourne tranquillement. Pas depuis un désassemblage, pas depuis des fichiers de constantes — les vraies valeurs en direct du système qui fonctionne. Un seul bit erroné dans la polarité du driver de commutation, et c'est le court-circuit traversant.
J'ai copié le conseil du coach et je l'ai collé au Claude opérationnel :
Moi : Pas de souci ! C'est un progrès !! Nous avons celui qu'il faut débriquer avec un câble UART. Et puis il nous en est arrivé [quelques] autres. On dirait que nous en sommes au point où il faut prendre du recul et commencer à travailler avec une certitude absolue sur ce que nous faisons. Notre conseiller / coach Claude a ajouté ceci : (conseil « Lisez, ne devinez pas » collé)
Claude : Votre conseiller a tout à fait raison. C'est un vrai progrès — nous avons prouvé que la séquence d'initialisation fonctionne. Nous avons simplement brûlé les étapes sur la partie la plus dangereuse.
Moi : Oui, allons-y. Je vais laisser l'appareil refroidir et aller déjeuner.
On ne fait pas d'omelette sans casser des œufs
Cela peut sembler un peu dangereux, et l'idée de ce que des IA connectées à des objets connectés dans nos maisons pourraient provoquer fait un peu peur, mais c'était nécessaire pour avancer. Si j'avais mené tout ce processus seul, j'aurais sans doute grillé 10 appareils avant d'y arriver. Je me débrouille bien avec le logiciel en général, mais l'électronique bas niveau comme celle-ci est un vrai défi pour moi ! Ce que je trouve incroyable, c'est la vitesse à laquelle on peut itérer avec une connaissance de haut niveau, en laissant Claude s'occuper de tous les détails. Nous sommes passés de rien à notre propre firmware sur mesure tournant sur l'appareil en quelques jours. Au total, nous avons briqué 3 appareils ; le numéro 2 est celui qui a failli brûler. Le numéro 1, nous l'avions briqué tôt en y copiant un firmware incapable de se connecter au réseau : même s'il allait bien, nous n'avions plus aucun moyen de lui parler. Le numéro 3, c'était encore une mauvaise mise à jour de firmware. Mais avec l'aide de Claude...
Résurrection
Nous avons réussi à ouvrir les boîtiers des appareils 1 et 2 et, avec un connecteur spécial à 3 broches maintenu contre la carte électronique, nous avons pu nous connecter à la console série. C'est le dernier recours intégré pour communiquer avec l'appareil. Une fois connectés, nous avons pu leur donner d'autres instructions de démarrage. Les détails complets, ce sera pour une autre fois ! Aujourd'hui, les deux appareils sont revenus à la vie et nous fonçons vers l'étape suivante : faire réellement circuler l'audio à travers eux jusqu'à de vrais téléphones analogiques.