Sprocket est un agente open source qui conçoit du matériel et écrit du logiciel. Présenté sur Hacker News (123 points, 12 commentaires au moment du signalement), il démarre avec npx @spikonado/sprocket et s’exécute dans le navigateur ou dans une application de bureau.

La particularité ne réside pas tant dans la qualité du code, difficile à évaluer sur un repository avec 12 étoiles, que dans le domaine. Sprocket dessine des schémas en React, génère la liste des composants (BOM, Bill of Materials), rédige les instructions d’assemblage et, selon le README, achète lui-même les composants sur les sites web quand on le lui demande. C’est un coding agent qui parle le langage du matériel.

Pourquoi cela te concerne. Les coding agents généralistes comme Cursor, Codex et Claude Code couvrent déjà bien le logiciel. Sprocket vise un domaine où un assistant générique n’arrive pas : les contraintes d’une fiche technique, la checklist d’un BOM, les règles d’un microcontrôleur. C’est le signal d’un mouvement vers des agentes verticaux, spécialisés dans un champ spécifique plutôt que de prétendre tout faire.

L’outil est rudimentaire. Les prétentions sont ambitieuses : acheter de manière autonome sur n’importe quel site est une opération qui porte tous les signes d’une démo, pas d’une fonctionnalité fiable. La communauté est minuscule. Mais le signal compte plus que l’outil : le matériel est un domaine où un agent spécialisé peut faire des choses qu’un assistant généraliste ne touche pas.

Si tu veux l’examiner de plus près, le repo est public sur GitHub avec une instruction pour démarrer sans installation.

En détail

Sprocket arrive à un moment où les coding agents généralistes se consolident. Claude Code, Cursor, OpenAI Codex : tous des outils qui écrivent du logiciel à partir d’une intention exprimée en langage naturel. Le saut que Sprocket essaie de faire est différent : porter l’approche agentic dans le monde physique, où le code se traduit en cartes électroniques, composants à commander et instructions de montage. Que les outils généralistes s’établissent sur un niveau de qualité fiable pour le logiciel rend c’est le bon moment pour regarder où l’approche n’est pas encore arrivée.

Le README décrit un agent qui récupère le contexte du web pour chaque décision qu’il prend. Sur le plan du matériel, cela signifie chercher des fiches techniques, comparer des composants alternatifs, vérifier la compatibilité des broches et des tensions. Sur le plan du logiciel, cela signifie écrire le firmware ou le code de contrôle pour les composants qu’il a choisis. Le flux est intéressant car il boucle le cercle entre conception et approvisionnement : le même agent qui dessine le schéma peut commander les pièces. Dans un travail réel, ces phases vivent souvent dans des mondes séparés, et c’est l’intégration qui peut faire émerger la valeur ou où peuvent naître les pires pannes.

La fonctionnalité d’achat autonome est la partie la plus délicate. Le README affirme que Sprocket peut acheter n’importe quoi sur n’importe quel site web quand on le lui demande. Aucun détail sur la façon de gérer l’authentification, les paiements, les confirmations ou la gestion des erreurs. Sur un repository avec 12 étoiles et 144 commits, il est prudent de la traiter comme une expérience, pas comme une fonction prête. Pour vraiment faire confiance, il faudrait au minimum un bac à sable de paiement et un journal lisible des actions entreprises avant la confirmation de la commande.

Le signal le plus intéressant est la direction. Jusqu’à présent, les agents IA ont ciblé des domaines numériques : code, documents, données. Le matériel est un domaine où les contraintes sont physiques et strictes, et où une erreur coûte plus cher (un composant incorrect signifie délais d’expédition, soudure, test). Le cycle d’itération est aussi plus lent : un bug dans le code se corrige en minutes, une erreur de brochage se découvre quand la carte arrive, des semaines plus tard. Un agent spécialisé qui connaît ces contraintes peut résoudre des problèmes qu’un assistant généraliste ne se pose même pas.

Il y a aussi un risque concret, et nous l’avons déjà vu ailleurs. Quand les agents opèrent sur des systèmes réels sans sandbox adéquats, les frontières entre « exécute une tâche » et « fait des dégâts » deviennent ténues. Un agent qui achète des composants en ligne avec accès à ta méthode de paiement est un cas évident où les permissions et les limites comptent plus que la capacité du modèle.

Pour l’instant, Sprocket est une expérience à surveiller, pas un outil à mettre en production. La valeur réside dans la démonstration que le modèle de l’agent vertical peut s’appliquer au matériel, pas dans le fait de l’avoir déjà résolu.