Gadget IA : créer un Tamagotchi connecté soi-même

Pourquoi fabriquer un Tamagotchi IA plutôt que l'acheter ?

Un gadget IA compact attire vite : on a l'impression d'avoir une interaction plus directe qu'avec un téléphone. Un bouton, un écran, une voix, et c'est censé suffire. Le Muse Charm, présenté par Meta, suit cette logique avec un objet portable et des avatars expressifs. Le prototype dont il est question ici suit une autre voie : partir d'une carte-écran programmable, puis ajouter ce qui manque.

Le matériel utilisé est un Waveshare ESP32-S3 1.75C : un petit écran tactile avec microcontrôleur, vendu environ 50 dollars dans le retour d'expérience d'origine. Visuellement, on est plus proche d'une montre de poche métallique que d'un jouet. Pour démarrer, rien de très compliqué : connecter l'appareil à un ordinateur, installer le logiciel fourni pour les Muse Gadgets, puis l'associer à l'application Muse sur téléphone. Cette base permet déjà de communiquer avec l'assistant distant, mais ce n'est pas suffisant pour en faire un objet agréable au quotidien.

Au départ, les limites sont très concrètes. L'appareil interprète mal les commandes vocales, restitue assez mal les réponses et, dans le prototype initial, il ne prononce même pas la voix. L'écran ne montre que quelques mots. L'avatar reste surtout décoratif, et l'appareil ne repère pas automatiquement des équipements domotiques dans la maison. Il peut aussi afficher une vidéo envoyée depuis le téléphone, mais sans bouton de déclenchement à distance, l'usage photo reste bancal.

Et c'est là que la démarche du prototype devient intéressante. Plutôt que d'attendre un correctif du fabricant, son créateur demande à Claude Code de modifier le logiciel. On n'est pas dans un produit "fin prêt pour l'industrie", ni dans une preuve de robustesse généralisée. C'est surtout un test de ce qui arrive quand la distance entre "utilisateur" et "développeur" se réduit : quelqu'un sans expérience de programmation peut exprimer un besoin, obtenir une modification fonctionnelle, puis l'essayer sur le matériel.

L'idée n'est pas "l'IA rend le matériel inutile". Elle réduit surtout le coût et le temps des essais : personnaliser, corriger une interaction, tester plus vite. Mais elle ne supprime pas l'ergonomie perfectible, ni les bogues, ni la nécessité de vérifier le code. Donc, pour l'acheteur, la question change : ce n'est plus seulement "est-ce qu'il y a une IA ?", mais plutôt "est-ce que je peux lui donner une fonction utile que mon téléphone ne fait pas aussi bien ?".

Que peut réellement faire un gadget IA relié à un LLM ?

Dans sa version modifiée, l'appareil ne se contente plus d'envoyer l'audio au service Muse. Il devient une interface physique autour de plusieurs fonctions : dialogue vocal, historique des échanges, contrôle photo depuis le téléphone, et mini-jeu façon Tamagotchi. Les usages restent simples, mais ils montrent comment un modèle de langage peut s'intégrer à un objet déjà "existons" à condition qu'on construise l'interface et les règles qui l'entourent.

Une première modification ajoute une page d'historique accessible en faisant glisser l'écran. C'est une correction d'interface assez logique : si l'appareil n'affiche que quelques mots, l'utilisateur perd facilement le fil de la réponse. Une voix générée par ElevenLabs permet aussi d'entendre les réponses. Là encore, tout dépend des choix de voix et du service utilisé : dans le prototype, la voix retenue ne correspond pas vraiment à l'ambiance douce annoncée par les avatars.

Le contrôle photo illustre une autre catégorie d'usage. Le pendentif peut demander au téléphone de prendre une photo à distance, avec un aperçu en direct en meilleure qualité via le Wi‑Fi domestique. Une prévisualisation plus faible peut aussi être transmise en Bluetooth, ce qui aide pour cadrer sans dépendre du Wi‑Fi. Dans ce cas, le gadget n'ajoute pas "une intelligence" magique : il apporte surtout une commande physique et déportée.

Le mini-jeu, lui, transforme l'avatar en animal virtuel. Il faut lui donner à manger, jouer avec lui, le laisser dormir et le laver. Des jauges de faim, d'ennui et de saleté rendent les conséquences visibles : les friandises salissent l'avatar, et trop jouer le fatigue. Ce n'est pas une logique compliquée, mais ça donne une continuité à l'objet. L'avatar n'est plus seulement "mignon" : il réagit à des actions répétées.

Enfin, le prototype ajoute aussi un cadran de montre avec trois aiguilles. Cette partie a été faite rapidement, mais elle ne doit pas être confondue avec une "capacité IA" : le cadran affiche l'heure selon une logique programmée. L'IA a surtout servi à écrire le code ; elle n'a pas rendu le temps "plus intelligent". C'est important, parce que les objets présentés comme "IA" mélangent souvent plusieurs couches : capteurs, interface, logique applicative, services en ligne et modèle génératif.

Comment transformer un prototype en objet utile ?

La méthode suivie est assez directe : repérer une friction, la décrire précisément, demander une modification, puis tester l'appareil. Par exemple, quand le bouton vocal était relâché trop tôt, l'appareil envoyait des échantillons audio très courts, que l'assistant traitait mal. Une modification a consisté à ignorer les enregistrements de moins d'une seconde. Ce correctif, simple et vérifiable, a rendu l'interaction plus robuste.

Le même principe s'applique à l'historique des réponses et au déclenchement photo. En pratique, c'est souvent plus efficace de demander une fonction clairement délimitée que de lancer une consigne vague du type "améliore l'appareil". La demande doit préciser le comportement attendu, les contraintes matérielles et la façon de vérifier que ça marche. Exemple : "quand l'utilisateur relâche le bouton, ne transmettre l'audio que s'il dépasse une seconde et afficher un message explicite sinon".

Cette approche permet d'ajouter des fonctions au fil des besoins. Mais elle ne remplace pas une revue technique. Le créateur du prototype précise qu'il n'a pas d'expérience de programmation, et qu'il ne sait pas si le code produit est de bonne qualité. C'est un point clé : un changement peut sembler fonctionner dans un cas précis, tout en introduisant une faille ou un défaut ailleurs.

Pour un usage personnel, le compromis peut être acceptable si l'appareil ne touche pas à des données sensibles et si l'on accepte de pouvoir réinitialiser. Pour un produit commercial, les exigences sont plus lourdes : tests répétés, maintenance, gestion des erreurs, mises à jour, documentation et contrôle des accès. Un prototype convaincant prouve qu'une idée est faisable. Il ne prouve pas encore qu'elle est "déployable" à grande échelle.

Quels risques de sécurité et de confiance faut-il anticiper ?

Un objet vocal connecté peut traiter des enregistrements, accéder au réseau local et communiquer avec des services tiers. Même si le prototype paraît anodin, il ne faut pas partir du principe que les données restent sur l'appareil. Ici, les requêtes passent par les services de Meta, et la synthèse vocale implique un fournisseur externe. Ça multiplie les acteurs auxquels l'utilisateur doit faire confiance.

Le choix d'utiliser un réseau Wi‑Fi invité sert à limiter les dégâts si l'appareil est mal configuré ou compromis. L'idée est de séparer l'objet, autant que possible, des ordinateurs, serveurs et équipements principaux. Ce n'est pas une garantie absolue, mais c'est une précaution pragmatique dans un scénario où le code et le comportement n'ont pas été audités.

Avant un essai, les contrôles qui comptent restent assez concrets :

• vérifier quelles données partent vers le service distant et si des enregistrements sont conservés ;
• éviter d'associer une adresse mail ou un compte contenant des informations sensibles ;
• isoler l'appareil sur un réseau invité ou un segment dédié ;
• désactiver les fonctions inutilisées, notamment micro ou caméra quand c'est possible ;
• regarder les autorisations de l'application et les jetons d'accès ;
• retirer les secrets du code avant de partager le projet ou de publier des captures d'écran.

En Europe, le RGPD ne se résume pas à afficher une politique de confidentialité. Il faut savoir qui traite les données, dans quel but, pendant combien de temps, et avec quels sous-traitants. Pour un particulier, ce genre d'informations est parfois difficile à obtenir. Pour une entreprise, c'est un prérequis de conception et d'achat.

La sécurité n'est pas le seul enjeu. L'animal virtuel, parce qu'il réclame attention, nourriture ou sommeil, crée une boucle d'engagement. Ce peut être ludique, mais ça peut aussi devenir une mécanique pensée pour relancer l'utilisateur régulièrement. Pour un produit destiné aux enfants, il faudrait examiner la fréquence des notifications, la façon dont la voix est collectée, la personnalisation des réponses et la possibilité de désactiver les relances. Le côté "mignon" de l'avatar ne rend pas ces choix neutres.

Et enfin, l'assistant vocal ne doit pas être confondu avec un compagnon autonome. Il dépend de services, d'une connexion et de règles décidées ailleurs. Si les serveurs répondent lentement, si une API change ou si un abonnement disparaît, certaines fonctions peuvent s'éteindre. Un objet "durable" doit prévoir ce qui fonctionne sans le cloud et ce qui se passe si le fournisseur n'est plus disponible.

Conclusion : le bon objet est celui qui justifie sa place

Ce prototype montre qu'un petit écran connecté peut devenir un objet personnel vraiment sympathique, à condition de pouvoir modifier ses fonctions rapidement. Un historique lisible, une voix pour répondre, une commande photo et un mini-jeu transforment un kit de base en expérience plus cohérente. Mais ces ajouts ne résolvent pas les délais du cloud, ne garantissent pas la qualité du code, et ne règlent pas à eux seuls les questions de confidentialité.

Pour juger un gadget IA, partez de l'usage : qu'est-ce qu'il fait mieux que votre téléphone, et que se passe-t-il s'il perd sa connexion ? Si les réponses sont nettes, le prototype mérite votre attention. Sinon, le format risque surtout de masquer un produit qui n'a pas encore trouvé, pour de bon, sa place dans votre poche.