ElatoAI : la voix temps réel sur ESP32, et ce que le dépôt dit vraiment

Le problème concret : faire parler un ESP32 sans héberger de modèle

Un ESP32 n'a ni la mémoire ni la puissance pour exécuter un modèle de reconnaissance vocale ou de synthèse. ElatoAI prend le problème par l'autre bout : le microcontrôleur capture l'audio, le compresse, l'envoie par WebSocket sécurisé vers un serveur qui parle à une API vocale distante, puis restitue la réponse audio sur le haut-parleur. Le README précise que l'appareil ne nécessite pas de PSRAM, ce qui élargit la gamme de cartes utilisables. Le public visé est donc précis : développeurs Arduino et PlatformIO qui veulent un compagnon ou un jouet connecté capable de tenir une conversation, sans écrire eux-mêmes la couche de transport audio ni la gestion des sessions. Le dépôt cite aussi un webapp Next.js pour piloter l'appareil depuis un téléphone, le contrôle du volume, la gestion du Wi-Fi par portail captif et la réinitialisation d'usine. Autrement dit, le projet vend une chaîne complète, pas seulement un firmware.

Deux architectures serveur, pas une seule

Le dépôt distingue clairement deux chemins. Le premier, sous server/deno, regroupe des intégrations speech-to-speech : OpenAI Realtime, Gemini Live, xAI Grok Voice Agent, Eleven Labs Conversational AI Agents, Hume AI EVI-4 et Boson Higgs Realtime. Dans ce cas, le serveur edge relaie l'audio vers une API qui gère elle-même la détection de parole et la génération. Le second chemin, Cloudflare Workers, assemble une chaîne en trois étages : un modèle STT, un LLM parmi ceux listés par Cloudflare Workers AI, puis un modèle TTS. La note de version d'avril 2026 indique que Workers AI fournit Deepgram STT et TTS nativement, ce qui réduit le nombre de clés API à fournir. Un troisième chemin existe sous server/fastapi, présenté comme un moyen de composer son propre pipeline vocal. Cette séparation est utile : elle montre que le choix du fournisseur n'est pas figé dans le firmware, mais déplacé côté serveur. Le firmware, lui, ne connaît qu'un endpoint WebSocket.

Le trajet de l'audio, du micro au haut-parleur

D'après la liste de fonctionnalités, l'audio est compressé en Opus avant transmission, ce qui limite la bande passante consommée par l'ESP32. La détection de tour de parole est faite côté serveur (Server VAD), pas sur le microcontrôleur. C'est un choix cohérent avec les contraintes matérielles, mais il implique une latence aller-retour qui dépend entièrement du réseau et de l'API distante. Les transcriptions en temps réel sont stockées dans Supabase, et le webapp Next.js utilise WebRTC tandis que l'ESP32 utilise des WebSockets. Cette dualité est logique : un navigateur gère nativement WebRTC, un microcontrôleur non. Le dépôt mentionne aussi les mises à jour OTA du firmware et l'authentification des appareils. Ce qui n'est pas détaillé dans le matériel fourni, c'est la taille exacte des trames Opus, la fréquence d'échantillonnage retenue ou le mécanisme de reconnexion en cas de coupure WebSocket. Ces points comptent pour un appareil qui doit tenir plus de vingt minutes de conversation selon la description du projet, et le README ne les tranche pas.

Mise en route : ce que la documentation indique

Le README renvoie vers trois guides de démarrage : Quick Start, Build with PlatformIO et Build on Arduino IDE, tous hébergés sur elatoai.com/docs. Le dépôt lui-même ne contient pas ces instructions en ligne, ce qui signifie que la première étape consiste à sortir du dépôt pour lire la documentation du site. Pour le serveur, le point d'entrée dépend du chemin choisi : server/deno pour les intégrations temps réel, server/fastapi pour un pipeline personnalisé, et la voie Cloudflare Workers pour la chaîne STT/LLM/TTS. La note d'avril 2026 précise que dans ce dernier cas, seule une clé API LLM est à fournir, Workers AI prenant en charge Deepgram pour la parole. Le firmware se compile avec PlatformIO ou l'IDE Arduino. Rien dans le matériel fourni ne donne les noms exacts des variables d'environnement ou des fichiers de configuration, donc je ne peux pas les citer. C'est une lacune réelle pour qui veut évaluer le temps d'installation avant de cloner.

La licence NOASSERTION, un vrai obstacle

GitHub classe ce dépôt en NOASSERTION, ce qui signifie que l'outil n'a pas reconnu de licence standard dans le fichier fourni. Concrètement, vous ne pouvez pas déduire les droits d'usage, de modification ou de redistribution à partir de cette étiquette. Le dépôt est public et non archivé, mais cela ne suffit pas à établir une autorisation. Pour un usage personnel ou une expérimentation, la question se pose moins. Pour intégrer ElatoAI dans un produit commercial, dans un jouet vendu ou dans un firmware redistribué, l'absence de licence identifiée est un blocage tant que le fichier LICENSE n'a pas été lu et, si nécessaire, clarifié avec l'auteur. Je ne donne pas de conseil juridique ici : je constate seulement que le matériel fourni ne permet pas de trancher. C'est le premier point à vérifier, avant même de compiler.

Dépendance aux API et modèles locaux

Chaque chemin serveur suppose un fournisseur externe : OpenAI, Gemini, xAI, Eleven Labs, Hume, Boson, ou Cloudflare Workers AI. La qualité de la conversation, la latence et le coût par minute dépendent donc de services tiers, pas du code du dépôt. Le README mentionne un projet distinct, local-ai-toys, lancé en mars 2026, pour exécuter des modèles locaux avec MLX sur Qwen ou Mistral. Ce projet est séparé et n'est pas décrit en détail ici. La conséquence pratique est simple : si votre contrainte est la souveraineté des données ou l'absence de réseau, ElatoAI dans sa forme documentée n'est pas l'outil adapté. Un pipeline entièrement local sur un serveur domestique reste possible via le chemin FastAPI, mais le dépôt ne fournit pas d'exemple complet de modèles vocaux locaux dans le matériel consulté. C'est une frontière à connaître avant de choisir.

Alternatives et différence d'approche

Un projet comme Pipecat, que le README mentionne lui-même pour le serveur FastAPI, adopte une approche différente : il fournit un cadre de composition de pipelines vocaux où vous assemblez explicitement les étages STT, LLM et TTS, avec un contrôle fin sur les transitions et les interruptions. ElatoAI, à l'inverse, privilégie des intégrations speech-to-speech clés en main où le fournisseur gère la détection de tour. La différence n'est pas cosmétique : avec Pipecat vous orchestrez et déboguez chaque étape, avec ElatoAI vous déléguez la logique conversationnelle à l'API. Pour un appareil embarqué, la seconde approche réduit le code serveur à maintenir. Pour un produit qui doit ajuster finement le comportement de la conversation, la première offre plus de prise. Le dépôt reconnaît cette complémentarité puisqu'il expose les deux chemins, ce qui est plus honnête que de prétendre couvrir tous les cas.

Ce qu'il faut vérifier avant d'investir du temps

Le dépôt n'a pas de release publiée dans les informations récupérées, et la dernière poussée date de septembre 2026. Le développement semble actif au vu des notes de version d'avril 2026, mais l'absence de releases versionnées complique le suivi des changements de firmware. Pour un appareil déployé chez des utilisateurs, une mise à jour OTA qui casse la compatibilité serveur est un risque concret, et rien dans le matériel fourni ne décrit une politique de versionnage. Trois vérifications s'imposent donc : lire le fichier LICENSE pour connaître les droits réels, consulter les guides PlatformIO et Arduino pour estimer le travail d'installation, et tester vous-même la tenue d'une session longue sur votre réseau avant de généraliser. Le reste, notamment la latence et la qualité audio perçue, dépendra de l'API vocale que vous branchez, pas du code du dépôt.

Conclusion éditoriale

ElatoAI convient aux développeurs embarqués qui veulent expérimenter la conversation vocale temps réel sur ESP32 sans PSRAM et qui acceptent de dépendre d'API tierces. Il ne convient pas aux projets nécessitant une licence claire ou un fonctionnement hors ligne. Avant d'adopter, vérifiez le fichier LICENSE, les versions de firmware dans le dépôt et les quotas des API vocales que vous comptez utiliser.

Sources officielles

1. akdeb/ElatoAI on GitHub
2. Issues
3. Project website
4. README