Simon Willison a construit avec Claude un détecteur de bips et trouvé la source à environ 40 cm près

Un bip occasionnel est un casse-tête pour le diagnostic à domicile : le temps d'arriver dans la bonne pièce, l'appareil s'est déjà tu. Chez le développeur Simon Willison, le son provenait d'une pièce remplie de cartons non déballés. Plutôt que de fouiller tout leur contenu, il a chargé Claude Code de construire Beep Locator : une application qui compare les enregistrements de plusieurs microphones et affiche la source supposée sur une carte.

Selon Willison, le système a indiqué l'emplacement avec une précision d'environ 40 cm. Dans la bonne pile de cartons se trouvait un vieux détecteur de monoxyde de carbone dont les piles devaient être remplacées. Ce qui est intéressant ici pour un développeur, c'est la méthode de travail : l'agent avait accès aux mesures prises dans la pièce, pouvait vérifier le résultat de ses modifications et poursuivre la mise au point à partir des données observées.

Cinq appareils transformés en instrument de mesure

Willison a utilisé deux iPad, un téléphone, un MacBook Pro et un Surface Ultra. L'interface principale est servie par un serveur Python. Les autres appareils se connectent via un lien ou un QR code, autorisent le navigateur à accéder au microphone et échangent des données avec le serveur par WebSocket. Aucun microphone spécialisé n'a été nécessaire pour cette expérience.

Imaginez un téléphone près de la porte, une tablette sur une étagère et un ordinateur portable à côté des cartons. Un seul bip atteint leurs microphones à des moments différents. Si l'on connaît l'emplacement des appareils et que l'on aligne correctement les enregistrements, on peut estimer d'où vient le son. Mais les navigateurs et le réseau ajoutent des délais : il ne suffit pas de comparer simplement les heures de réception des messages par le serveur.

C'est pourquoi les écouteurs conservent les 60 dernières secondes d'audio. Un algorithme local recherche les bips possibles par analyse fréquentielle et filtrage. Lorsqu'un message d'événement arrive, le serveur demande à un appareil de jouer un court signal de contrôle. Il rassemble ensuite les fragments d'enregistrements contenant le son d'origine et ce signal. Le signal de contrôle aide à aligner les enregistrements pour le calcul ultérieur.

L'agent s'est appuyé sur l'article BeepBeep de 2007 consacré à la mesure acoustique de distances sur des appareils ordinaires. Toutefois, le résultat de l'expérience domestique ne peut pas être considéré automatiquement comme une reproduction de la précision du travail d'origine : l'implémentation et les conditions sont différentes.

La vérification par claquements comptait plus qu'une jolie carte

La détermination automatique de la position relative des appareils fonctionnait insuffisamment bien. Willison a ajouté un mode dans lequel il plaçait lui-même approximativement les icônes sur la carte, après quoi le système tentait d'affiner les coordonnées à partir des mesures sonores. C'est une limite importante : l'application a nécessité une configuration avec intervention humaine.

Pour vérifier la localisation, l'auteur a tapé dans ses mains à différents endroits de la pièce et comparé les positions réelles aux marqueurs. Ce test apportait une réponse claire à la question de savoir si le système sait vraiment localiser un son. Pour un développeur, c'est une astuce utile : avant de chercher une source inconnue, tester l'instrument de mesure sur un événement aux coordonnées connues.

L'étape suivante a été l'écoute des enregistrements de chaque appareil. L'utilisateur pouvait confirmer que le système avait capté le bon bip. Après confirmation, l'application suivait sa fréquence, les intervalles entre les événements et affinait la position supposée. L'interface a aussi gagné une suggestion indiquant où placer un microphone supplémentaire.

Les 40 cm annoncés concernent un seul cas décrit. Le document ne fournit pas de série de tests dans différentes pièces. Les réflexions du son, le bruit et les erreurs de coordonnées des appareils restent des raisons de vérifier le résultat sur place.

L'agent a besoin d'accéder au résultat

Un détail important de l'architecture : la possibilité d'envoyer aux écouteurs du nouveau JavaScript via WebSocket. L'agent pouvait ainsi modifier le traitement du son sans recharger chaque page. Sur certains appareils, le rechargement redemandait l'autorisation du microphone ; la mise à jour du code à la volée réduisait donc le travail manuel.

C'est précisément cette boucle qui rend l'histoire utile pour les équipes qui utilisent des agents dans le développement. L'agent écrit du code, reçoit des mesures, voit les erreurs et modifie l'implémentation. Une rétroaction similaire peut être organisée via les journaux de l'application, un banc de test ou des captures d'écran de l'appareil.

Conclusion pratique : en choisissant une tâche pour un agent, réfléchissez d'avance à la manière dont il vérifiera le résultat. Dans Beep Locator, il a fallu un tampon audio, la lecture des enregistrements, des claquements de test et la confirmation manuelle des événements. Ces outils ont permis de transformer du code fonctionnel en un système que l'auteur a pu utiliser pour une vraie recherche.