Pour l’anniversaire de mon colocataire, je lui avais acheté un petit écran LED qui affiche les vols passant près de notre fenêtre. C’était un cadeau plutôt sympa, mais à force de voir les avions apparaître à l’écran, je me suis demandé ce qu’on pourrait bien y afficher d’autre. La météo ou mon agenda, par exemple ? Et si, au moment de sortir, je pouvais simplement demander « À quelle heure passe le prochain train ? » et lire la réponse à l’écran ?
C’est vite devenu un projet perso avec un Raspberry Pi, un panneau LED HUB75 de 128 × 64 pixels, Codex et un assistant que j’ai fini par appeler Jack. C’est GPT-Live-1, le modèle vocal full-duplex que nous avons récemment lancé dans l’API, qui assure la conversation. Un autre modèle s’occupe des recherches et un moteur de rendu se charge des pixels. Au départ, on était loin d’avoir aussi bien réparti les rôles. Voici comment on y est arrivés.
Comment Codex m’a aidé à faire fonctionner un panneau LED RVB HUB75
Pour commencer, il fallait que Codex et moi trouvions comment afficher quelque chose d’utile à l’écran. J’avais un panneau RVB HUB75 de 128 × 64 pixels, mais je connaissais mal le contrôleur et le câblage, et je ne savais pas comment lui envoyer autre chose que ce qu’il affichait déjà.
J’ai commencé par envoyer des photos à Codex en lui demandant de m’expliquer ce que j’avais sous les yeux. Il m’a aidé à repérer les branchements importants, à comprendre le fonctionnement du contrôleur à base d’ESP32 et à voir comment un panneau HUB75 reçoit les données à afficher. Il a même annoté les photos pour me montrer les éléments à repérer. Ça m’a bien aidé, parce que tout ce que je voyais, c’était un circuit imprimé et un tas de façons de me tromper en essayant de deviner le rôle de chaque composant.
Une fois le fonctionnement du matériel compris, Codex m’a aidé à faire tourner WLED-MM sur le contrôleur et à vérifier que le panneau était bien configuré pour une résolution de 128 × 64 pixels. On a alors pu lui envoyer nos propres trames et commencer à tester ce qui rendait bien sur un si petit écran. Codex se chargeait des recherches et du dépannage. De mon côté, je faisais les branchements et je lui décrivais ce qui ne fonctionnait pas comme prévu.
Un prototype d’écran LED à commande vocale sur mon Mac
La première version qui a fonctionné était bien plus simple que celle à laquelle on a abouti. Une fois WLED-MM en place sur le contrôleur, Codex m’a aidé à créer un moteur de rendu et un skill personnalisé. J’ai ensuite utilisé ChatGPT Voix dans l’application de bureau ChatGPT pour lui dire quoi afficher à l’écran.
Ça changeait déjà ma façon d’utiliser l’écran. Il pouvait afficher la météo, mon agenda, les prochains passages du métro, des graphiques financiers, des messages, des comptes à rebours, des photos, des œuvres d’art ou une scène animée sur mesure. Chaque fois qu’une idée rendait mal sur ce petit écran, on ajustait le moteur de rendu.
Je dialoguais toujours à voix haute avec Codex, et le skill personnalisé lui permettait de modifier ce qui s’affichait au mur. Sur mon Mac, le moteur de rendu convertissait la mise en page en trames RVB de 128 × 64 pixels et les envoyait sur le réseau local via DDP. Le contrôleur ESP32 sous WLED-MM se chargeait ensuite de les afficher sur le panneau.
Codex m’a aussi aidé à tirer parti du peu de place disponible. Sur un écran de 128 × 64 pixels, comment faire tenir du texte, des images, la météo, les rendez-vous de mon agenda et les prochains passages du métro sans que l’ensemble devienne illisible ? Je disais à Codex ce qui me gênait, il ajustait le moteur de rendu ou la mise en page, puis on réessayait. Petit à petit, l’écran de veille a pris une forme que j’avais vraiment envie de laisser affichée.
Le problème, c’est que tout dépendait encore de mon Mac. C’est là que tournait le moteur de rendu et que je lançais la conversation. Dès que mon portable se mettait en veille ou que je l’emportais ailleurs, l’écran mural ne me servait plus comme je le souhaitais. Dans l’idéal, je voulais pouvoir rentrer du travail et demander à mon mur de m’afficher quelque chose.
Passage de l’assistant vocal et du moteur de rendu sur un Raspberry Pi
J’ai dit à Codex que je voulais pouvoir me passer de mon portable. On a donc transféré sur un Raspberry Pi les composants qui devaient fonctionner en permanence, placé le code dans un dépôt privé et vérifié qu’on avait une sauvegarde et un moyen de revenir en arrière en cas de problème. Une fois le Pi branché, Codex s’est occupé de faire tourner le code, de consulter les journaux et de résoudre les problèmes à mesure qu’ils se présentaient. De mon côté, je continuais à lui décrire ce que je voulais obtenir.
Le Pi exécute désormais deux petits services :
- Le service vocal gère le microphone, l’audio avec PipeWire, l’annulation d’écho avec WebRTC, le réveil et la mise en veille, les interruptions, la connexion à GPT-Live-1 et la délégation côté client.
- Le service de rendu anime l’écran de veille, actualise la météo et les prochains passages du métro de la MTA, utilise les données nettoyées de mon agenda, valide les descriptions de scènes et transmet les trames à l’écran mural.
Avec un micro et un haut-parleur branchés au Pi, je pouvais entrer dans la pièce, dire « Hey Jack » et lui demander quelque chose sans ouvrir mon ordinateur. On a passé un peu de temps à améliorer son réveil et sa façon de répondre. Mais c’est surtout le passage du Mac au Pi qui a transformé cette démo sur portable en un assistant qu’on pouvait tout simplement laisser allumé.
Comment GPT-Live-1 et le Raspberry Pi travaillent ensemble
On a fini par répartir le travail ainsi : c’est avec GPT-Live-1 que je parle, tandis qu’un autre composant dessine ce qui s’affiche au mur. GPT-Live-1 maintient la conversation ouverte, m’écoute même quand il parle, me laisse l’interrompre et détermine quand une demande nécessite autre chose qu’une réponse orale.
Dans ce cas, le Raspberry Pi reçoit la tâche déléguée et lance côté client une requête à l’API Responses avec GPT-5.6 Luna, en réglant l’effort de raisonnement sur un niveau faible. Luna peut faire des recherches sur le Web public, consulter mon agenda via une connexion en lecture seule, trouver des images réutilisables sur Wikimedia Commons et choisir le type de scène adapté à ma demande.
Un jour, j’ai demandé à Jack d’afficher une photo au mur et il m’a répondu qu’il ne pouvait pas. Le moteur de rendu savait déjà afficher des images, mais je n’avais donné à l’assistant vocal aucun outil pour en trouver une et l’envoyer. Codex m’a aidé à le connecter à Wikimedia Commons pour qu’il puisse chercher une image correspondant à ma demande, vérifier sa licence et savoir à qui l’attribuer. On a aussi ajusté l’affichage des images sur le panneau. Le Pi les redimensionnait pour qu’elles tiennent dans les 128 × 64 pixels tout en conservant leurs proportions, ce qui évitait de les étirer à l’écran.
À mesure qu’on ajoutait des fonctionnalités, Codex m’a aidé à garder les rôles bien distincts. Le code sur le Pi détermine quels outils Luna peut utiliser. Luna identifie les informations ou la scène nécessaires. Le moteur de rendu vérifie le JSON de la scène avant de produire une trame RVB d’exactement 128 × 64 pixels. Il envoie ensuite les trames via DDP au contrôleur WLED-MM, qui pilote le panneau HUB75.
L’un des premiers bugs est apparu au cours d’une conversation tout à fait banale. Je demandais à Jack quel temps il faisait à New York, puis je lui disais « Affiche ça au mur », et il ne savait pas à quoi renvoyait « ça ». Codex a découvert que notre application ne transmettait que la dernière demande au modèle chargé d’actualiser l’écran. On a modifié ce transfert pour y inclure les derniers échanges et les résultats précédents.
De « Hey Jack » aux pixels sur l’écran LED
Quand je demande à Jack de chercher quelque chose et de l’afficher à l’écran, voici en gros ce qui se passe :
- Le Raspberry Pi capte ma voix sous forme de signal audio PCM à 24 kHz et traite le son localement.
- GPT-Live-1 reçoit le flux, comprend ma demande et maintient la conversation ouverte pour que je puisse l’interrompre ou ajouter une précision.
- Si ma demande nécessite une recherche, des informations tirées de mon agenda, une image ou une mise à jour de l’écran mural, GPT-Live-1 délègue la tâche côté client et le Pi l’envoie à GPT-5.6 Luna via l’API Responses.
- Luna utilise les outils que j’ai mis à sa disposition pour cette demande, par exemple la recherche web hébergée, la connexion en lecture seule à mon agenda, la recherche d’images réutilisables ou l’outil de mise à jour de l’écran mural.
- Si une scène existante convient pour afficher la météo, mon agenda, un message ou un compte à rebours, Luna la choisit. Si je demande quelque chose qu’on n’avait pas prévu, Luna crée une nouvelle scène.
- Le moteur de rendu local valide la scène, la convertit en trames RVB de 128 × 64 pixels et les envoie à l’écran mural via DDP pendant que GPT-Live-1 me dit ce qu’il a trouvé.
Ce qui me plaît, c’est de pouvoir reprendre la parole sans attendre que l’assistant vocal ait fini de répondre. Je peux interrompre Jack, préciser ce que je voulais dire, et la recherche comme le rendu se poursuivent en arrière-plan.
Au fond, c’était un projet perso assez simple. Je n’avais jamais travaillé avec des panneaux HUB75, des contrôleurs ESP32, des Raspberry Pi ou des modèles vocaux. À une autre époque, je me serais probablement arrêté dès que j’aurais ouvert le boîtier de l’écran. Avec Codex, j’ai pu comprendre comment tout fonctionnait au fur et à mesure. Dès que je tombais sur quelque chose que je ne connaissais pas, il me suffisait de lui poser la question.
Si vous avez un projet de ce genre et que vous ne savez pas par où commencer, demandez à Codex. Vous pourriez bien vous surprendre à aller plus loin que prévu.