Les gens utilisent des agents de coding pour faire du rétro-ingénierie sur les appareils domestiques et en écrire l’automatisation en quelques heures. Des choses qui demandaient autrefois des jours d’analyse sur des protocoles non documentés, et que presque personne n’entreprenait parce que le jeu n’en valait pas la chandelle.

Simon Willison rassemble les anecdotes et en tire le vrai point : le coût d’écrire du code s’est effondré, et cela change l’équation.

Avant, comprendre comment parle un appareil sans documentation était réalisable mais non rentable. Le temps pour déchiffrer l’API dépassait la valeur de l’automatisation qu’on en tirait. Et il y avait un second problème : les API non documentées changent ou se cassent, et tout le travail devait être refait.

Avec les agents de coding le calcul change. Le coût d’une première tentative est bas, et le coût de réessayer en cas d’échec est tout aussi bas. Si l’API change dans six mois, jeter le code et le réécrire coûte une fraction du prix d’avant.

Pourquoi c’est pertinent pour vous. Si vous avez un appareil qui fait quelque chose d’utile mais l’app du fabricant est mauvaise ou restrictive, le seuil à partir duquel il vaut la peine de lui écrire votre propre automatisation s’est abaissé. Pas besoin d’être un rétro-ingénieur : il suffit de capturer le trafic réseau de l’appareil (des outils comme Wireshark ou un proxy HTTPS) et de décrire à l’agent ce que vous voulez obtenir.

La limite est honnête : ce sont des anecdotes, pas un benchmark. On ne sait pas combien d’appareils se prêtent à ce traitement ni comment le code se comporte dans le temps. Mais le signal est cohérent avec ce que nous racontions le 18 juillet : les agents de coding ont quitté la démo et changent ce qui vaut la peine de faire.

En détail

Comment c’était avant.

Faire du rétro-ingénierie sur un appareil domestique a toujours été possible. Vous allumez Wireshark, capturez le trafic entre l’app du fabricant et l’appareil, étudiez le modèle des messages, écrivez un script qui reproduit ces messages. Ça marche. Les gens le faisaient déjà il y a dix ans.

Le problème était le ROI. Déchiffrer un protocole non documenté demande des heures, parfois des jours. Et un programmeur expérimenté sait que les API non documentées sont instables : le fabricant peut les changer avec une mise à jour firmware, et alors tout votre travail doit être refait. Vous vous engagez dans un cycle de maintenance frustrant pour contrôler une ampoule.

Ce qui change.

Les agents de coding réduisent deux coûts simultanément. Le premier est le coût de la tentative : au lieu de passer un après-midi à lire des logs binaires, vous décrivez à l’agent ce que vous avez capturé et lui demandez d’écrire le code qui reproduit le comportement. Le second est le coût de l’échec : si le code ne fonctionne pas, vous le jetez et réessayez, parce que réécrire coûte peu.

Le point de Willison est psychologique autant qu’économique. Quand écrire du code coûte peu, l’idée de devoir le maintenir à l’avenir (ou le jeter et recommencer) cesse de peser. La friction mentale qui bloquait le bricolage se dissout.

Comment ça marche pour ceux qui ne développent pas.

Un appareil intelligent communique avec son app en envoyant des messages sur le réseau WiFi de la maison. Si vous interceptez ces messages, vous voyez un motif : envoyez ces octets, la lumière s’allume ; envoyez ceux-là, elle change de couleur. Un agent de coding peut lire le log de ce trafic et écrire un script qui fait la même chose, sans passer par l’app officielle. Le résultat est une automatisation à vous, que vous pouvez déclencher avec une commande vocale, une minuterie, ou un script système.

Les limites de ce que nous savons.

La source est un article de blog qui rassemble des anecdotes, pas une étude systématique. Trois questions concrètes restent ouvertes.

La première : combien d’appareils se prêtent à ce traitement ? Beaucoup de fabricants chiffrent maintenant le trafic entre app et appareil, et si le protocole est crypté l’interception devient beaucoup plus difficile.

La deuxième : comment le code se comporte-t-il dans le temps ? Une mise à jour firmware peut changer le protocole, et l’automatisation se casse. L’argument de Willison est que la réécrire coûte peu, mais il reste à voir à quelle fréquence cela se produit en pratique.

La troisième : personne n’a encore mesuré combien de temps cela prend vraiment. Les anecdotes parlent de « quelques heures », mais il n’y a pas d’échantillon suffisant pour savoir si c’est la norme ou le cas chanceux.

Ce qui est certain c’est la direction : le seuil de rentabilité s’est abaissé, et s’abaissera encore. Pour ceux qui ont un appareil qu’ils aimeraient mieux contrôler, cela vaut la peine d’essayer.