Le problème
Tu écris : « envoie à Jean un résumé de la météo de demain ». Derrière cette phrase, il y a trois gestes : lire la météo, retrouver Jean dans tes contacts, puis composer l'e-mail. L'ordre compte : l'e-mail ne peut pas partir avant d'avoir la météo et l'adresse.
Un modèle de langage qui improvise ces gestes au fil de l'eau peut se tromper d'ordre, inventer un outil qui n'existe pas ou demander dix résultats à un outil qui n'en rend que cinq. Tant que rien n'est parti, l'erreur ne coûte rien. Une fois l'e-mail envoyé, si.
Ce que je voulais
Je voulais que tout ce qui peut se vérifier le soit avant le premier appel, au moment où une correction est encore gratuite. Et qu'une fois le plan lancé, LIA te dise honnêtement ce qui s'est passé, sans rejouer d'étapes dans ton dos.
À quoi ressemble un plan
Un plan est une liste d'étapes. Chacune nomme l'outil à appeler, ses paramètres et les étapes dont elle a besoin. Pour Jean : (1) la météo de demain, (2) le contact Jean, (3) le brouillon d'e-mail, qui attend les deux premières et reprend l'adresse trouvée à l'étape 2.
- Des vagues en parallèle. Les étapes qui n'attendent rien partent ensemble. Ici, la météo et le contact se cherchent en même temps, puis l'e-mail suit. Une demande qui touche plusieurs domaines ne prend donc pas forcément plus de temps.
- « Pour chaque ». « Envoie l'ordre du jour à chacun des participants de ma réunion de demain » devient une seule étape qui se répète sur une liste, avec un plafond. Si l'un des envois échoue, les autres gardent leur résultat. Et avant d'agir sur toute une liste, LIA te montre combien d'éléments sont concernés, avec un aperçu.
- Des conditions. Une étape peut aussi être un test : faire ceci seulement si cela est vrai.
Ce qui est vérifié avant le premier appel
- Des outils réels. Un nom d'outil inventé est repéré, et les petites erreurs de nom les plus courantes sont corrigées.
- Un plan possible. Pour répondre à un e-mail, il faut son identifiant, donc un outil qui lit les e-mails. LIA s'assure que chaque donnée exigée par un outil peut être obtenue par un autre outil présent. Sinon, aucun plan valide n'existerait et le modèle n'aurait plus qu'à inventer.
- Des limites annoncées. Chaque outil dit ce qu'il accepte, par exemple combien de résultats il rend d'un coup, et le planificateur le voit. Une valeur qui dépasse est ramenée dans les bornes, et le plan continue.
- Chercher, puis trier. « Mes rendez-vous médicaux du mois » : ton agenda sait chercher par date ; la notion de « médical », il ne la connaît pas. Le planificateur est guidé pour récupérer la période et laisser le tri à la réponse, et le validateur repère quand un tel mot se glisse dans une recherche.
- La cohérence. Un plan qui fait moins ou plus que demandé (« tous mes contacts », mais un seul traité), une étape qui cite une étape inexistante, une action risquée sur une information vague : le plan repart chez le planificateur, un nombre de fois limité. S'il manque une information que personne ne peut deviner, comme le contenu d'un e-mail, LIA te pose la question. Et si un plan qui modifie quelque chose reste douteux après ces reprises, elle s'arrête et te pose la question.
Quand une étape échoue
Une fois le plan lancé, rien n'est rejoué derrière ton dos. Une panne passagère est déjà retentée par la connexion qui l'a rencontrée. Un service déconnecté ou un accès refusé ne se contourne pas avec un nouveau plan. Un résultat vide est une réponse. Chaque étape ratée arrive entière jusqu'à la réponse, qui te dit quel outil a échoué, pourquoi, et ce qui a fonctionné à côté.
À l'inverse, ce qu'une lecture a trouvé y arrive aussi : les temps de trajet d'un itinéraire ou la page suivante d'une recherche ne restent pas coincés dans les données de l'outil. Et le refus d'un service n'est pas transformé en succès en chemin.
Lorsque tu désignes un résultat par son expéditeur, son titre ou sa position, LIA reprend d’abord les éléments qu’elle a réellement montrés. Si plusieurs correspondent, elle te demande lequel. Une recherche planifiée qui agirait sur le premier de plusieurs résultats attend aussi ton choix, puis continue sur cet élément.
Les limites
Un plan est écrit avant d'avoir vu les résultats. Il ne change pas de route en cours de chemin : si tu veux que LIA cherche une autre source quand la première ne répond pas, c'est le rôle du mode ReAct, que tu actives avec le bouton de mode, en haut de l'écran. Et la vérification contrôle la forme du plan ; elle ne lit pas dans tes pensées. Un plan bien formé peut mal comprendre ce que tu voulais. C'est pour cela qu'un envoi, une modification ou une suppression passe encore par ta confirmation, à part quelques gestes qui ne touchent que toi et se défont d'un clic.
Pour approfondir : Garder la main sans être dérangé : comment LIA te demande ton accord ; Voir LIA travailler : les étapes qui s'affichent pendant que tu attends.