Six cycles de tests indépendants : renforcement du Sensbench AI Builder

Au cours de la semaine dernière, un tiers indépendant a mené six cycles de tests approfondis et adversariaux contre le Sensbench AI Builder et le serveur Sensbench MCP (Model Context Protocol). Leur mission était simple : essayer de le casser. Ils ont généré des projets, compilé des firmwares, relancé des invites identiques, sondé les caches, connecté de vrais courtiers MQTT et audité notre facturation. Voici ce qui s’est passé, ce que nous avons corrigé et à quoi ressemblent les chiffres maintenant.

Comment les tests ont été menés

Chaque affirmation ci-dessous a été vérifiée dans un environnement réel :

• Compilation réelle — chaque esquisse générée a été compilée sur notre chaîne d’outils arduino-esp32 réelle (build ESP-IDF), pas un linter ou un faux passage.
• MQTT réel — les esquisses Home Assistant générées ont été flashées dans le simulateur, connectées à un vrai courtier MQTT public, et pilotées de bout en bout : mosquitto_pub ON → callback de l’appareil → impulsion du relais → état publié en retour. Les messages de découverte ont été capturés sur homeassistant/switch/…/config.
• Sémantique du cache — des invites identiques, des invites sémantiquement différentes, des changements de carte et des changements de contraintes ont été rejoués pour vérifier que les réponses en cache ne correspondent jamais qu’à la requête exacte qui les a produites.
• Rapprochement de facturation — chaque génération et compilation a été rapprochée du registre de quota : succès facturés, hits de cache gratuits, compilations échouées gratuites.

Premier cycle : le chiffre honnête était de 20%

Le premier cycle a été humiliant. Sur cinq projets générés, quatre ont échoué à la compilation — y compris un ouvre-porte de garage, l’une des demandes réelles les plus courantes. Les échecs étaient des erreurs classiques de débutant en C++ : fonctions auxiliaires utilisées avant déclaration, piles de protocoles faites à la main, inclusion de bibliothèque manquante. Le verdict était juste : “le pipeline est réel, mais le générateur n’est pas fiable.”

Ce que nous avons changé

Plutôt que de discuter, nous avons intégré des garde-fous dans le pipeline lui-même :

• Injection automatique de prototypes — la chaîne de compilation n’exécute pas l’étape de prototype automatique d’Arduino, nous injectons donc automatiquement les prototypes de fonctions à la position correcte avant chaque compilation.
• Compilation d’auto-vérification interne — chaque projet généré est compilé en interne avant d’être montré à l’utilisateur. S’il échoue, l’erreur du compilateur est renvoyée et le modèle régénère, jusqu’à deux fois. Les utilisateurs ne voient que des résultats vérifiés.
• Bibliothèques matures plutôt que piles faites à la main — MQTT utilise désormais la bibliothèque éprouvée PubSubClient ; il est explicitement interdit au modèle de réimplémenter le protocole MQTT de zéro.
• Vérifications de complétude des exigences — compiler ne suffit pas. Si l’invite demande Home Assistant MQTT, le code doit réellement contenir un client MQTT fonctionnel avec logique d’abonnement/publication/callback — une démo locale déguisée en vraie chose est rejetée et régénérée.
• Cache uniquement vérifié — le cache de réponses ne stocke que les projets qui ont réussi à la fois la compilation et les vérifications des exigences. Répéter une invite populaire renvoie toujours la version vérifiée.
• Règles de réalité du simulateur — les esquisses générées utilisent désormais par défaut le vrai nom de point d’accès du simulateur, un courtier MQTT par défaut accessible, une gestion bidirectionnelle ON/OFF, un état initial conservé pour Home Assistant, et des types de capteurs exacts (un interrupteur à lames reste un interrupteur à lames).

Les chiffres maintenant

• Taux de réussite initial sur des demandes réelles : 1 sur 6.
• Taux de réussite après les correctifs, sur des cycles indépendants répétés : 6 compilations consécutives sur 6 + logique MQTT réelle — y compris les réponses en cache.
• Test sémantique du cache : 6 requêtes, aucune discordance. Les invites identiques renvoient un code octet pour octet identique ; les invites, cartes ou contraintes modifiées génèrent toujours du nouveau.
• MQTT de bout en bout : appareil → courtier → abonnement de type Home Assistant → commande → impulsion du relais → publication d’état, tout confirmé sur un vrai courtier, y compris les courtiers authentifiés.
• Serveur MCP : 8/8 outils exercés de bout en bout ; la facturation des quotas a été rapprochée exactement (succès facturés, hits de cache et échecs gratuits).

Ce dont nous parlons encore ouvertement

Limitations honnêtes que nous avons documentées lors des tests :

• L’intégration Home Assistant est manuelle MQTT par défaut (la configuration de découverte est publiée, mais la configuration de l’auto-découverte HA dépend de votre configuration MQTT HA).
• Le bac à sable du simulateur a une liste d’autorisation sortante — certains courtiers publics sont accessibles (par exemple broker.emqx.io), d’autres non. Consultez notre documentation pour savoir ce qui fonctionne.
• La sélection du matériel correspond sémantiquement à la demande, pas toujours à la lettre — le modèle peut choisir une classe de capteur équivalente ; nous le signalons dans les notes du plan généré.

Pourquoi publier cela

Tout le monde peut publier une vidéo de démonstration. Nous avons plutôt choisi de publier l’arc complet : les cycles d’échec, les correctifs et les nouveaux tests — avec une méthodologie reproductible. Si vous voulez essayer de le casser vous-même, l’AI Builder est gratuit pour une construction par jour, et le simulateur fonctionne entièrement dans votre navigateur. Le serveur MCP est disponible avec une véritable comptabilité des quotas. Apportez votre propre invite, votre propre courtier, votre propre scepticisme.

— L’équipe Sensbench