Comment Robo-8 v2 a été planifié, conçu et construit
Le récit d’un artisan sur Robo-8 v2 : les contraintes, les choix d’architecture, la direction de design et la vérification.
Partir des contraintes
Je n’ai pas commencé par les fonctions. J’ai commencé par quatre conditions que l’application devait respecter. Elle doit marcher sans serveur. Tout usage du cloud doit être facultatif et gratuit à essayer. Aucune clé ne doit vivre dans l’APK ou dans le stockage web. Et elle doit tourner sur Android 6 et au-delà. Tout le reste pouvait plier autour de ces règles.
Une hypothèse impossible à contourner
Le matériel de signature d’origine de la v1 n’était pas disponible. Cela compte plus qu’il n’y paraît : Android ne met pas à jour une application signée avec une autre clé. La v2 est donc devenue un paquet distinct qui s’installe à côté de la v1. Je l’ai noté comme une hypothèse plutôt que de la présenter comme une mise à jour.
Architecture : une WebView et un très petit pont natif
J’ai comparé trois formes. Une page hébergée tombe en panne dès que l’on est hors ligne. Un environnement complet d’interface d’agent apporte un routeur payant et un serveur, ce qui viole la règle du gratuit uniquement. La forme retenue embarque le HTML, le CSS, le JavaScript et les polices dans l’application, chargés dans une WebView depuis une origine propre à l’application, avec une toute petite couche native pour deux tâches : faire l’appel HTTPS vers NVIDIA et recueillir la clé. Comme l’appel est natif, le navigateur ne voit jamais la clé et le problème de CORS disparaît.
La clé ne touche jamais la page
La clé est saisie dans une boîte de dialogue native qui bloque les captures d’écran, conservée dans la mémoire du processus pendant la session et effacée à la déconnexion. La WebView ne peut pas la lire. Une requête ne contient que le message saisi et une consigne fixe, avec une taille de corps bornée, des délais de connexion et de lecture, et aucune redirection suivie. Il n’y a pas d’historique de conversation à faire fuiter, puisqu’aucun n’est gardé.
Design : un petit objet vivant, pas un tableau de bord
La direction que j’ai écrite était celle d’un instrument ludique : un téléphone posé sur un bureau sous la lumière du soir doit ressembler à un petit être vivant. D’où une surface bleu marine profond, des yeux vert menthe pâle, un seul accent vermillon, un texte blanc coquillage, et une seule signature : des yeux arrondis asymétriques dans une ouverture de visage physique. Space Grotesk et IBM Plex Mono sont embarquées localement. J’ai écarté les dégradés, le verre, les cartes imbriquées et les boucles décoratives. Le mouvement n’existe que pour montrer le regard, le clignement, le toucher, la réflexion ou la respiration, et « Réduire les mouvements » coupe l’animation au repos. Le robot est le premier écran ; les outils et la conversation viennent dessous.
Un visage original, seulement des principes empruntés
La description publique des expressions, de la personnalité et du comportement au repos d’EMO a servi d’inspiration. Je n’en ai copié ni graphismes, ni micrologiciel, ni animations. À deux projets sous licence MIT j’ai pris des idées, pas du code d’exécution : une manière d’afficher des composants d’interface générés selon une liste autorisée, et l’habitude de garder les clés éphémères. Les deux sont crédités dans les mentions.
Sûr par construction là où c’était possible
Les réponses générées ne peuvent pas exécuter de code. Le rendu n’accepte que des schémas de composants fixes et écrit le texte avec textContent : une réponse hostile reste du texte. Les appels réseau sont plafonnés. Les animations masquées sont mises en pause. J’ai listé ces cas de panne avant d’écrire le code, puis écrit des tests pour eux.
La vérification, et ce qu’elle n’a pas couvert
J’ai prévu les contrôles comme autant de façons de montrer que la conception était fausse : rendu en 320 et 390 pixels, toutes les interactions hors ligne, erreurs cloud simulées, inspection de la signature et du manifeste de l’APK, installation et lancement. Le compte rendu indique 11 assertions du moteur et 34 assertions d’interface dans le navigateur réussies, et une installation et un lancement sur un émulateur Android 6. Le premier essai sur l’émulateur a révélé un vrai défaut : la WebView embarquée était trop ancienne pour le JavaScript moderne, j’ai donc transpilé le code pour un vieux Chrome et ajouté des solutions de repli CSS, puis réinstallé et revérifié. Ce qui n’a pas été testé : un vrai téléphone, les versions récentes d’Android, la gestion de batterie des fabricants, la signature de publication et une réponse NVIDIA authentifiée, faute de clé. Je le dis aussi sur la page de l’application.
Ce que je ferais ensuite
Tester sur du vrai matériel, lancer une session cloud authentifiée avec une clé d’essai, et décider si la caméra et la parole de la v1 méritent de revenir derrière une autorisation explicite. D’ici là, la v2 est un compagnon calme, hors ligne, avec un cerveau facultatif.
Version 3 : capteurs, mémoire et ce que je n’ai pas pu vérifier
La v3 prolonge le design de la v2 en ajoutant des sens. Le compagnon réagit désormais quand on le soulève, le secoue, le fait tourner, l’incline ou le lâche, à la lumière et à l’obscurité, aux claquements de mains et aux caresses, garde la mémoire des séries et des étapes d’un jour à l’autre, et a de petits comportements au repos. Le micro est désactivé par défaut, car une fonction d’écoute doit être choisie. Je lui ai aussi donné un nom de paquet neutre, com.jackgross.robo8, pour que l’identifiant ne porte que le projet. La construction a révélé un vrai bug : les événements natifs des capteurs partaient avant le chargement du JavaScript de la page, et les premières réactions se perdaient. Il a été corrigé, et la version hébergée ici est la version corrigée. Ce qui a été vérifié, selon le projet : une installation et un lancement sur un émulateur Android 6, des réactions testées en direct (batterie, sommeil selon la lumière et l’obscurité, face vers le bas, réveil et danse au repos), 97 assertions du moteur et 27 contrôles sur 27 dans le navigateur. Ce qui ne l’a pas été : capteurs, micro et vibration sur un vrai téléphone, et une réponse NVIDIA authentifiée. Considérez les seuils des capteurs comme non prouvés tant qu’un essai sur téléphone n’a pas eu lieu.