Définir le périmètre avant de choisir la technologie
La première étape d'une conception ne touche pas au modèle mais au périmètre. Que doit faire l'assistant, et surtout que ne doit-il pas faire ? Un assistant qui répond à tout suscite une confiance excessive puis des déceptions. Délimiter les tâches, les sources autorisées et les sujets sur lesquels il doit se taire ou passer la main est un travail de cadrage, pas d'ingénierie. Les outils utiles ici restent modestes : arbres de décision, cartes de parcours, scénarios d'usage. Leur vertu est d'obliger à écrire ce qu'on attend avant d'être séduit par une démonstration.
Ce cadrage doit aussi nommer les interdits. Un assistant personnel accède souvent à des informations intimes : agenda, messages, habitudes. Chaque accès ouvre un risque si l'assistant les utilise hors de propos ou les expose par erreur. Décider par écrit ce qu'il n'exploitera jamais vaut mieux que de l'espérer. Cette discipline paraît ralentir le projet ; en réalité elle évite les reprises douloureuses. Un assistant dont le périmètre est flou finit par être jugé sur des tâches qu'on ne lui avait jamais demandées, et l'échec est attribué à la technologie plutôt qu'à la conception.
La mémoire : ce qui distingue un assistant d'un moteur de réponses
Un assistant devient utile quand il se souvient : des préférences, des décisions passées, du contexte d'une conversation. La mémoire est un choix de conception, pas un automatisme. Faut-il retenir chaque échange, seulement certains faits, ou rien du tout ? Chaque option a un coût en pertinence et en vie privée. Trop de mémoire rend l'assistant indiscret et expose des données sensibles ; trop peu le condamne à tout redemander et épuise l'utilisateur. Concevoir la mémoire signifie décider ce qui persiste, pendant combien de temps et comment la personne peut le consulter ou l'effacer.
Les outils de conception aident à rendre ces choix visibles. Schémas de données, politiques de rétention, interfaces de gestion des souvenirs : autant de dispositifs qui traduisent un principe abstrait en comportement observable. Un utilisateur doit pouvoir savoir ce que l'assistant garde et le corriger. Cette transparence n'est pas un supplément d'ergonomie, c'est une condition pour que la relation tienne. Un assistant qui se souvient de tout sans le dire et qui oublie au mauvais moment produit exactement l'effet inverse de celui recherché : il inquiète au lieu de soulager.
Orchestrer des outils et des modèles sans casser l'expérience
Un assistant personnel n'est presque jamais un seul modèle. Il combine souvent un modèle de langage pour comprendre et formuler, des services externes pour agir, une base de connaissances pour les faits, et des règles pour les cas sensibles. Concevoir revient à orchestrer ces pièces : qui décide de la prochaine étape, comment gérer la panne d'un des composants, comment éviter qu'une action irréversible parte sur une simple supposition. Les outils de conception technique, gestion des flux, journaux d'exécution, tests d'intégration, servent à rendre cette mécanique lisible. Un assistant opaque dans son fonctionnement est impossible à corriger.
Cette orchestration touche directement à la sûreté. Un assistant qui envoie un message, déplace un rendez-vous ou engage une dépense doit distinguer ce qu'il fait seul de ce qu'il fait après confirmation. Le bon réflexe ne consiste pas à tout soumettre à validation, ce qui rendrait l'outil inutile, mais à repérer les actions aux conséquences irréversibles et à y placer un garde-fou. Ce travail se mène avant la mise en service, avec des scénarios écrits. Une fois l'assistant lancé, personne ne prend plus le temps de se demander ce qui se passe s'il comprend mal.
Tester la relation, pas seulement les réponses
L'assistant sera jugé sur la relation qu'il instaure autant que sur l'exactitude de ses réponses. Ordonne-t-il les tâches, comprend-il une demande ambiguë, sait-il dire qu'il ne sait pas ? Ces qualités s'observent en mettant l'outil entre les mains de vrais utilisateurs, dans des situations réalistes, et en regardant où ils butent. Les tests de conversation, les prototypes cliquables, les journaux d'usage donnent de la matière. Aucun de ces outils ne remplace l'observation directe, qui révèle les frictions qu'aucun scénario n'avait anticipées. Un assistant jugé agréable en démonstration peut se révéler pénible à l'usage quotidien, quand la personne doit répéter, corriger ou contourner. Ces observations nourrissent une version suivante du produit : c'est par itérations, et non par une grande conception initiale, qu'un assistant devient réellement utilisable.
Concevoir un assistant personnel engage enfin des choix d'accessibilité. Les référentiels du RGAA et la norme EN 301 549 rappellent qu'une interface doit rester utilisable au clavier, avec un lecteur d'écran, ou sans dépendre d'un seul canal. Une interaction uniquement vocale exclut les personnes sourdes ou les environnements bruyants. Prévoir des alternatives, texte et voix, écrit et geste, n'appauvrit pas l'expérience : elle l'ouvre. Un assistant personnel pensé pour une seule manière de communiquer laisse de côté une partie de ceux auxquels il était destiné, ce qui contredit l'idée même de service.
Aller plus loin
Concevoir un assistant demande de le mettre en situation réelle et d'observer comment les gens s'en servent, l'abandonnent ou se rattrapent. Notre catalogue des 31 formations détaille les parcours consacrés aux systèmes conversationnels et à l'expérience utilisateur.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations