Claude Code a localisé un détecteur qui bipait grâce au son de cinq appareils, à 40 cm près

Une situation domestique bien connue : dans une pièce remplie de cartons pas encore déballés après un déménagement, quelque chose bipe de temps à autre. Le son est rare, impossible à localiser à l'oreille, et fouiller partout n'a rien d'attrayant. L'auteur de la note d'origine a réglé le problème comme on règle aujourd'hui beaucoup de petits tracas : il l'a confié à Claude Code. Le résultat s'appelle Beep Locator, et il est intéressant moins pour le bip lui-même que pour la façon dont le travail se répartit entre l'humain et l'agent.

Comment fonctionne Beep Locator

Un serveur web Python tourne sur l'ordinateur portable. Les autres appareils ouvrent la page via un QR code ou un lien et deviennent des écouteurs. Le test a mobilisé deux iPad, un téléphone, un MacBook Pro et un Surface. Chaque appareil accède au micro via WebAudio et conserve en mémoire les 60 dernières secondes d'enregistrement. Un détecteur simple, basé sur une transformée de Fourier rapide avec un filtre passe-haut, repère les bips suspects et les signale au serveur.

C'est là que tout se joue. Le serveur demande à l'un des appareils de jouer un court chirp, puis réclame à chaque écouteur un fragment d'enregistrement allant d'environ 0,6 seconde avant le bip jusqu'à 0,8 seconde après le chirp. Le chirp sert de point de référence commun : il permet d'aligner les enregistrements des différents appareils et de voir de combien le bip est arrivé plus tôt à un micro qu'à un autre. C'est à partir de cet écart de temps que la position est calculée sur la carte.

Claude a trouvé l'idée tout seul : il s'agit d'un article de 2007, BeepBeep, sur la mesure de distances par le son avec de simples téléphones et PDA. Il ne requiert qu'un haut-parleur, un micro et un canal de communication. Pour le réglage, les appareils se sont d'abord joué des sons pour déterminer leurs positions relatives, mais le résultat était médiocre. On a alors ajouté un « mode grossier » : les icônes se déplacent sur la carte à peu près là où se trouvent les appareils, puis le système affine les coordonnées.

Remplacement à chaud du code et itérations avec l'agent

La solution la plus pratique ici n'a rien à voir avec l'acoustique. Dès la première étape, une méthode installModule() a été intégrée aux écouteurs : via WebSocket, le serveur peut envoyer du nouveau JavaScript à n'importe quel appareil, qui l'exécute aussitôt. La raison est prosaïque : sur certains appareils, le navigateur redemande l'accès au micro après chaque rechargement de page, et faire le tour de tous les gadgets à la main après chaque modification aurait été un calvaire.

Grâce à cela, l'agent pouvait modifier le comportement des « oreilles » à la volée, lire les journaux de sons et reconfigurer le détecteur sans intervention humaine. L'auteur, lui, restait surtout à côté et formulait les tâches en langage courant. Il a demandé d'ajouter un mode claquements de mains pour tester le système, des horodatages sur les icônes, un journal avec un bouton de lecture de l'enregistrement de chaque appareil, et un bouton « C'est le bip mystérieux ».

Ce marquage aide le système à reconnaître la fréquence recherchée et à la suivre spécifiquement. Sont ensuite apparus la fonction « Déplacer les appareils » sans redémarrer les écouteurs, et une suggestion de l'endroit où placer un micro supplémentaire pour affiner la position d'environ 12 %.

Le projet a été lancé sur iPhone dans Claude Code avec le modèle Opus 5.5, puis peaufiné sur ordinateur portable avec le nouveau Fable 5.2. C'est un bon exemple de répartition du travail : la première session a rédigé problem.md et la base, la seconde a débogué le système en conditions réelles.

Ce qu'il faut en retenir

L'idée centrale de l'auteur : on peut doter un agent de codage d'organes sensoriels, même si le modèle n'en a pas. Claude n'a pas d'entrée audio propre, mais il sait écrire et exécuter du code qui analyse le son des micros d'autres appareils, et ajuster lui-même ce code. Une astuce similaire a été présentée à GitHub Universe : une webcam braquée sur l'écran d'un appareil pour que l'agent vérifie si la mise à jour avait fonctionné.

Pour un développeur, la conclusion est simple : si l'agent est « aveugle », réfléchissez à un canal de retour peu coûteux à lui offrir (caméra, micro, journaux, captures d'écran), et il se mettra à boucler lui-même le cycle « modifier — vérifier ».

Il y a aussi des réserves. C'est une expérience domestique, pas un instrument de précision : environ 40 cm de précision dans une seule pièce avec cinq appareils, et sans ce résultat il aurait quand même fallu fouiller les cartons. L'étalonnage automatique par les sons a mal fonctionné, d'où la nécessité d'un placement manuel. En outre, le mécanisme d'exécution de code arbitraire sur les clients via WebSocket est pratique pour le débogage, mais sur un réseau tiers, c'est une faille toute prête. Il ne faut l'utiliser que dans un environnement de confiance et le temps d'une expérience.