Le problème
Imagine que tu écrives : « envoie l'adresse du restaurant de mon dîner de vendredi à tous les invités ». Pour y arriver, il faut lire ton agenda, retrouver le dîner, en tirer le lieu, chercher chaque invité dans tes contacts, puis préparer un e-mail. Cinq gestes, trois services.
Donner tout cela d'un bloc à un seul modèle de langage, avec tous les outils sous les yeux, marche mal. Plus il voit d'outils, plus il hésite et plus il se trompe d'outil. Chaque appel coûte plus cher. Et quand ça rate, impossible de savoir où.
Ce que je voulais
Je voulais que LIA travaille comme une petite équipe bien organisée : quelqu'un trie la demande, quelqu'un prépare le plan, quelqu'un le vérifie, quelqu'un l'exécute, et quelqu'un te répond. Chaque rôle fait une seule chose. Autour d'eux, chaque domaine apporte ses propres outils et leur mode d'emploi : e-mails, agenda, contacts, tâches, fichiers, météo, lieux, itinéraires, recherche web, et même les serveurs MCP que tu ajoutes toi-même.
Pour relier ces rôles, j'ai choisi LangGraph, une bibliothèque qui décrit un traitement comme un graphe : des étapes, et des règles qui disent laquelle vient ensuite. Ton message suit ce graphe du début à la fin.
Comment ça se passe
- Le tri. Le routeur lit ton message et décide s'il s'agit d'une conversation ou d'une demande d'action, et quels domaines sont concernés. « Merci, c'était parfait » part tout droit vers la réponse. Le dîner de vendredi part vers le planificateur, avec l'agenda, les contacts et les e-mails.
- Le plan. Le planificateur ne reçoit que les outils de ces domaines. Il écrit un plan : quelles étapes, avec quels paramètres, et lesquelles attendent le résultat d'une autre.
- La vérification. Avant le moindre appel, LIA contrôle ce plan : un outil inventé, une étape qui en attend une autre introuvable, une valeur hors limites. Ce qui se répare est réparé, ce qui reste douteux repart chez le planificateur.
- L'exécution. Les étapes indépendantes partent en même temps, les autres attendent ce dont elles ont besoin. Ici : l'agenda d'abord, puis tous les invités en parallèle, puis le brouillon d'e-mail, que tu valides avant l'envoi.
- Le petit plus. Une fois les résultats revenus, LIA regarde s'il manque une information qu'elle peut simplement lire. Si un e-mail propose une réunion jeudi, elle peut jeter un œil à ton agenda de jeudi. Elle peut aussi te suggérer une action, sans l'exécuter.
- La réponse. Un dernier rôle rassemble ce qui s'est passé et te l'écrit, en distinguant ce qui a réussi de ce qui a échoué.
Deux façons de travailler
Ce circuit, c'est le mode Pipeline : planifier d'abord, exécuter ensuite. C'est le plus économique et le plus prévisible, et c'est le mode par défaut. Mais certaines questions ne se planifient pas d'avance. « Qu'est-ce qu'on fait ce week-end ? » dépend de ce que LIA va découvrir en chemin. Pour celles-là, tu peux passer en mode ReAct d'un clic sur le bouton de mode, en haut de l'écran : LIA avance pas à pas, lit chaque résultat et choisit la suite. Les deux modes partagent la même mémoire et les mêmes confirmations, et se rejoignent sur la même étape de réponse.
Un fil qui ne se perd pas
Après chaque étape, l'état de la conversation est enregistré dans la base de données (PostgreSQL). Quand LIA attend ta validation, elle reprend exactement là où elle s'était arrêtée dès que tu réponds, tant que la question n'a pas expiré. Si tu fermes l'onglet, la réponse continue côté serveur et t'attend à ton retour. Et quand une conversation devient très longue, LIA en résume le début pour son propre usage, sans rien effacer de l'historique que tu vois.
Les limites
Le tri peut se tromper. Quand le routeur doute vraiment, il te répond sans agir, et une reformulation suffit souvent. Le mode Pipeline fixe son plan avant d'avoir vu les résultats : si une étape échoue, il te le dit, sans improviser un autre chemin. Et un domaine n'existe pour LIA que si le service est connecté : sans ton agenda, aucun plan ne peut le lire.
Le circuit complet est décrit sur la page technique.
Pour approfondir : Un plan avant d'agir : comment LIA prépare et vérifie tes demandes en plusieurs étapes ; Pipeline ou ReAct : deux façons pour LIA de mener ta demande.