ALFRED : d'un prototype fonctionnel à une véritable interface d'assistant intelligent
ALFRED franchit une nouvelle étape. Son interface évolue d'un prototype fonctionnel vers un véritable environnement d'assistance intégrant interaction vocale, agenda, tâches, météo, gestion du contexte et transparence du traitement. Prochain chantier : synchroniser précisément les quinze visèmes de l'avatar avec les phonèmes produits par Piper.
D'un prototype de test à un environnement d'assistance unifié : avatar, mode vocal, agenda, tâches, météo et contexte
Lorsque j'ai commencé à développer ALFRED, l'objectif prioritaire était simple : vérifier que les principales briques techniques pouvaient fonctionner ensemble. L'ancienne interface permettait déjà d'afficher l'avatar, de saisir une demande, de visualiser les réponses et de suivre certains états internes, comme le mode actif, l'émotion utilisée ou la phase de réflexion. Cette première version avait donc une fonction essentielle : transformer une idée en prototype utilisable.
Aujourd'hui, ALFRED franchit une nouvelle étape. Son interface ne sert plus seulement à tester des fonctionnalités. Elle commence à traduire pleinement la vision du projet : proposer un assistant personnel accessible, transparent, évolutif et capable de centraliser les informations utiles du quotidien.
La première interface : une base indispensable
La première version d'ALFRED prenait la forme d'une application de bureau relativement compacte. L'avatar occupait la partie centrale de la fenêtre, tandis que les principaux réglages étaient accessibles depuis une barre de navigation supérieure : son, microphone, caméra et paramètres.
Une zone textuelle permettait d'afficher les réponses d'ALFRED. L'utilisateur pouvait également connaître l'état de fonctionnement de l'assistant grâce à différentes indications techniques, comme :
- le mode actif ;
- l'émotion sélectionnée ;
- l'état de réflexion ;
- la disponibilité du microphone ;
- la réponse en cours de génération.
Cette interface était encore très proche d'un outil de développement. Elle rendait visibles les mécanismes internes nécessaires aux tests, sans chercher à masquer totalement la complexité technique.
Elle a néanmoins permis de valider plusieurs éléments fondamentaux : l'intégration de l'avatar, les premiers échanges textuels et vocaux, l'affichage des états ainsi que les bases de l'interaction entre l'utilisateur et ALFRED. Autrement dit, cette version n'était pas un simple brouillon. Elle constituait le socle sur lequel l'interface actuelle a pu être construite.
Une nouvelle interface pensée comme un véritable environnement numérique
La nouvelle version marque un changement important, aussi bien visuel que fonctionnel. ALFRED ne se présente plus comme une petite fenêtre isolée, mais comme un véritable espace de travail organisé autour de plusieurs services.
L'interface repose désormais sur trois grandes zones :
- une navigation latérale donnant accès aux principales fonctionnalités ;
- un espace central consacré à l'interaction avec ALFRED ;
- un panneau contextuel regroupant les informations vocales, les actions suggérées et les sources de données utilisées.
Cette organisation permet de rendre l'application plus lisible tout en préparant l'intégration progressive de nouvelles fonctionnalités.
L'objectif n'est pas d'accumuler des boutons comme dans le cockpit d'un avion mal luné. Chaque élément doit aider l'utilisateur à comprendre ce qu'ALFRED fait, ce qu'il utilise et comment il traite la demande.
Un mode vocal plus clair et plus immersif
Le mode vocal occupe désormais une place centrale dans l'expérience. L'utilisateur peut visualiser les différentes étapes d'une interaction :
- inactif ;
- écoute ;
- transcription ;
- analyse ;
- réponse ;
- interruption ;
- microphone coupé ;
- erreur.
Cette représentation améliore considérablement la compréhension du fonctionnement de l'assistant. Lorsqu'un assistant vocal reste silencieux quelques secondes, l'utilisateur peut rapidement se demander s'il écoute encore, s'il réfléchit ou s'il a simplement abandonné la conversation pour partir vivre sa meilleure vie numérique. La visualisation des états permet d'éviter cette incertitude : elle montre précisément où en est le traitement de la demande.
L'avatar devient également un point de repère central. Il ne sert plus uniquement à illustrer l'application : il est destiné à traduire visuellement l'état de l'assistant par la posture, le regard, les expressions faciales, les mouvements de la bouche et les micro-animations.
Une interface plus transparente sur le traitement des données
La nouvelle interface affiche également le mode de traitement utilisé par ALFRED : local, hybride ou distant. Cette distinction est importante dans le cadre du projet.
ALFRED repose sur une approche local-first. Les commandes simples et les traitements compatibles avec les ressources disponibles peuvent être réalisés directement sur la machine de l'utilisateur. Le mode hybride permet de conserver une partie du traitement en local tout en utilisant ponctuellement des services distants pour les requêtes plus complexes. Le mode distant, quant à lui, correspond à l'utilisation de ressources externes lorsque celles-ci sont nécessaires et autorisées.
L'objectif est de ne pas présenter l'intelligence artificielle comme une boîte noire. L'utilisateur doit pouvoir savoir comment sa demande est traitée et dans quel environnement les données sont mobilisées.
Des informations vocales immédiatement accessibles
Le panneau consacré au statut vocal permet de visualiser plusieurs paramètres essentiels : l'état général du système, le mot d'activation, la langue utilisée, la voix sélectionnée, le microphone actif, la qualité audio et le mode de traitement.
Ces informations peuvent sembler techniques, mais elles ont une réelle utilité. Elles permettent notamment de vérifier rapidement qu'ALFRED utilise le bon microphone, qu'il fonctionne dans la bonne langue et que la qualité du signal audio est suffisante.
Cette visibilité facilite aussi le diagnostic en cas de problème. Au lieu de demander à l'utilisateur de chercher dans plusieurs fenêtres de configuration, l'interface rassemble les principaux indicateurs au même endroit.
Des actions proposées à partir de la conversation
ALFRED ne doit pas seulement répondre à une question. Il doit également être capable de transformer une conversation en action concrète. La nouvelle interface intègre ainsi des actions suggérées, par exemple :
- créer un rappel ;
- résumer l'échange ;
- envoyer un élément vers la liste des tâches ;
- enregistrer une information utile ;
- préparer une action à partir du contexte.
Cette approche permet de réduire le nombre d'étapes nécessaires pour passer d'une intention à une action. Une discussion concernant un rendez-vous peut ainsi conduire à la création d'un rappel. Une réflexion sur un projet peut être transformée en tâche. Un échange long peut être résumé et conservé pour être retrouvé plus tard.
ALFRED évolue donc progressivement d'un assistant conversationnel vers un assistant opérationnel, capable de relier la parole, le contexte et l'organisation personnelle.
L'agenda, les tâches et la météo intégrés dans un même environnement
La navigation latérale donne accès à plusieurs domaines fonctionnels : tableau de bord, mémoire, tâches, agenda, connaissances, émotions, appareils et paramètres. L'interface propose également l'accès aux informations météorologiques.
La météo n'est pas ajoutée comme un simple gadget visuel. Elle peut devenir une véritable donnée contextuelle utilisée par l'assistant. ALFRED pourra, par exemple, prendre en compte les conditions météorologiques pour :
- préparer le résumé de la journée ;
- adapter une suggestion de déplacement ;
- rappeler de prévoir un vêtement adapté ;
- signaler un épisode de chaleur, de froid ou de pluie ;
- compléter les informations liées à un rendez-vous extérieur ;
- proposer une organisation différente selon les conditions annoncées.
L'intérêt réside dans la capacité à croiser plusieurs sources : agenda, tâches, météo, préférences et contexte de la conversation.
L'utilisateur ne consulte alors plus une succession d'applications indépendantes. Il accède à un environnement capable de relier les informations entre elles.
Un contrôle visible du contexte utilisé
Une autre évolution importante concerne les sources de contexte. L'interface permet de sélectionner les informations qu'ALFRED peut utiliser pendant la conversation, comme l'agenda du jour, les dernières tâches, les préférences vocales ou d'autres données personnelles autorisées. Chaque source peut être activée ou désactivée.
Ce fonctionnement répond à un objectif essentiel de gouvernance : ne pas utiliser automatiquement toutes les données disponibles simplement parce qu'elles existent. L'utilisateur conserve la possibilité de décider quelles informations peuvent être mobilisées pour une conversation donnée.
Cette approche favorise une utilisation plus maîtrisée de l'intelligence artificielle et renforce la compréhension du système.
Une identité visuelle plus cohérente
L'évolution de l'interface est également visible dans son identité graphique. La nouvelle version adopte une apparence plus structurée, avec une palette sombre, des accents violets, une hiérarchie visuelle plus nette, des panneaux clairement délimités, un avatar mieux intégré, des boutons d'action plus visibles et une présentation plus homogène des informations.
Le résultat est plus proche d'un produit numérique abouti que d'une interface expérimentale. Cette cohérence visuelle est importante, car elle contribue directement à la compréhension de l'application. Une interface claire réduit les hésitations, facilite l'apprentissage et limite la charge cognitive.
L'accessibilité reste un axe de travail permanent. La lisibilité des textes, les contrastes, la navigation, les états visibles et la possibilité d'utiliser plusieurs modes d'interaction doivent continuer à être testés et améliorés.
Le prochain chantier : améliorer la synchronisation labiale
La prochaine évolution majeure concernera la synchronisation entre la voix d'ALFRED et les mouvements de sa bouche. Quinze visèmes ont déjà été créés pour représenter les principales positions de la bouche associées aux sons français. Un visème correspond à la représentation visuelle d'un son ou d'un groupe de sons : plusieurs phonèmes peuvent produire une forme de bouche similaire et être associés au même visème.
L'objectif est désormais de ne plus animer la bouche à partir d'un rythme approximatif, mais de l'aligner sur les phonèmes réellement prononcés par le moteur vocal Piper.
Exploiter les alignements réels de Piper
Le package Python piper-tts, dans la version actuellement utilisée par le projet, peut renvoyer les durées d'alignement des phonèmes lorsque l'option correspondante est activée. Cette donnée est particulièrement intéressante, car elle provient du modèle vocal lui-même : il ne s'agit donc pas d'une estimation basée uniquement sur la longueur du texte ou sur le volume du signal audio.
Adapter le modèle ONNX
Le modèle vocal français actuellement utilisé devra être adapté afin d'exposer les données d'alignement. Piper fournit un outil dédié à cette opération. Cette modification devrait rester relativement mécanique, mais elle devra être réalisée sur une copie du modèle, testée et documentée afin de conserver une version stable en cas de problème.
Vérifier le fonctionnement de l'API Python sous Windows
Le principal risque technique se situe dans l'intégration actuelle. La synthèse vocale d'ALFRED n'utilise pas directement l'API Python de Piper : elle passe par le binaire piper.exe, lancé en sous-processus. Ce choix avait été effectué pour contourner un problème rencontré sous Windows avec Python 3.13, où l'API Python pouvait générer un fichier audio vide.
Or, les alignements détaillés des phonèmes sont disponibles par l'API Python, mais pas par l'utilisation classique du programme en ligne de commande. Il faudra donc commencer par vérifier si ce problème est toujours présent dans la configuration actuelle. Deux scénarios sont possibles :
- le problème a été corrigé et l'API Python peut produire correctement l'audio et les alignements ;
- le problème persiste et une solution hybride devra être mise en place.
Dans le second cas, l'API Python pourrait être utilisée uniquement pour calculer les timings, tandis que le binaire continuerait à générer l'audio réellement joué. Cette solution est plus complexe, car les deux flux devront rester parfaitement synchronisés.
Associer les phonèmes français aux quinze visèmes
Une table de correspondance devra ensuite relier chaque phonème français au visème approprié. Cette table devra prendre en compte les principales familles de sons : lèvres fermées, sons labiodentaux, consonnes dentales, voyelles ouvertes, voyelles étirées, voyelles arrondies, sons projetés, positions avec langue visible, silence et fermeture de la bouche.
Le premier mapping pourra être construit à partir des conventions phonétiques françaises, mais il devra être validé visuellement. Une correspondance théoriquement correcte peut produire un résultat peu naturel lorsqu'elle est appliquée à un avatar stylisé. Les transitions entre deux positions seront donc aussi importantes que le choix du visème lui-même.
Synchroniser l'animation avec la lecture audio
Les durées extraites devront ensuite être transmises à l'interface afin de déclencher les visèmes au bon moment. Le minuteur JavaScript devra suivre le temps réel de lecture et gérer le début de la parole, la durée de chaque phonème, les transitions entre visèmes, les pauses, les silences, les interruptions, la fin de la lecture et le retour à la bouche neutre.
Une partie de cette logique pourra être mutualisée avec les travaux réalisés sur l'enveloppe de volume et les animations de l'avatar. L'objectif final n'est pas de produire une animation mécaniquement parfaite image par image. Il s'agit d'obtenir un mouvement suffisamment précis, stable et naturel pour renforcer la sensation de présence sans provoquer un effet artificiel.
Le chantier de synchronisation labiale représente environ trois à cinq jours de travail effectif. Cette estimation comprend l'adaptation du modèle vocal, la vérification du problème lié à l'API Python, la construction du mapping entre phonèmes et visèmes, le câblage entre Piper et l'interface, la gestion du minuteur, les tests sur des phrases réelles et les corrections visuelles et temporelles.
La durée dépendra principalement du comportement de Piper sous Windows et Python 3.13. Un premier test ciblé permettra de déterminer rapidement si le développement se rapproche du scénario le plus favorable ou s'il nécessite la mise en place d'une architecture hybride.
Conclusion
Comparer les deux interfaces permet de mesurer le chemin parcouru. La première version démontrait qu'ALFRED pouvait exister techniquement. La nouvelle version commence à montrer comment il pourra être utilisé quotidiennement. L'évolution ne concerne donc pas uniquement le design : elle touche également l'architecture de l'information, la transparence du traitement, la gestion du contexte, l'accessibilité, la gouvernance des données, la transformation des conversations en actions, l'intégration de services comme l'agenda, les tâches et la météo, ainsi que la représentation visuelle des états de l'assistant.
ALFRED n'est plus seulement un prototype qui affiche une réponse. Il devient progressivement un environnement numérique cohérent, capable d'écouter, de comprendre, d'organiser, de contextualiser et d'accompagner l'utilisateur.
Cette nouvelle interface représente une étape importante du projet ALFRED. Elle donne une forme plus concrète à sa vision : proposer un assistant personnel doté d'une identité propre, tout en restant transparent sur son fonctionnement et respectueux des choix de l'utilisateur.
Le travail est encore loin d'être terminé. La synchronisation labiale, les expressions faciales, les micro-mouvements, les émotions, les interactions vocales et l'intégration complète des services devront encore être développés et testés. Mais la direction est désormais clairement visible : ALFRED n'est plus seulement une idée décrite dans un cahier des charges. Il commence à devenir un produit, avec une interface, une voix, une identité et une véritable expérience utilisateur. Et le plus intéressant reste encore à construire.
Cet article marque une étape que j'attendais depuis longtemps : voir ALFRED cesser d'être un banc de test pour commencer à ressembler à un produit. La prochaine étape, la synchronisation labiale, est aussi celle qui me tient le plus à cœur — c'est le détail qui transforme un avatar qui parle en un avatar qui semble présent.
Céline Rousselot — Cognitive Products Lab · Mastère Expert IT IA & Big Data
💬 Votre avis nous intéresse
Cet article vous a été utile, vous avez une question ou un point de vue différent ? N'hésitez pas à laisser un commentaire ci-dessous.
Aucun commentaire pour le moment — soyez le premier à réagir !