Salut @StephaneB, désolé pour le délai.
Sur le fond, je ne partirai pas sur une liste de phrases pré-écrites tirées au sort. La direction de Gladys, c’est l’IA : une réponse générée et contextuelle, pas un dictionnaire figé. Donc le sujet à régler ici, ce n’est pas « comment contourner l’IA », c’est « pourquoi l’IA met 15 s chez toi ».
Et 15-20 s, ce n’est pas normal. Pour être transparent sur l’architecture : l’action « Demander à l’IA » ne fait pas un seul appel. Il y a d’abord un appel rapide de classification d’intention, puis l’appel principal, puis un ou plusieurs allers-retours supplémentaires si le modèle décide d’appeler un outil (aller lire une température, par exemple). Mais même à 3 allers-retours on devrait être autour de 1,5-2 s, pas 15. Il se passe donc autre chose de spécifique à ton installation.
Je manque de temps pour mener l’enquête moi-même, mais la bonne nouvelle c’est que tu as tout ce qu’il faut pour la mener sans m’attendre — sans ligne de commande, et Gladys enregistre déjà tout le nécessaire. Voici les clés.
1. Voir exactement ce que l’IA a fait, appel d’outil par appel d’outil
C’est le cœur du diagnostic. Déclenche ta scène, attends la réponse vocale, puis va dans Intégrations → Intelligence Artificielle, section « Debug IA » → « Télécharger le contexte JSON pour debug ».
Ouvre le fichier obtenu (un éditeur de texte suffit) et regarde la section _debug → conversationHistory. Elle contient deux choses :
toolCalls : la liste exacte de tous les outils que l’IA a appelés, avec pour chacun son nom (tool_name), son résultat (tool_status : success ou error), les arguments qui lui ont été passés, et l’heure précise (created_at).
messages : la conversation complète dans l’ordre chronologique — ton message, chaque appel d’outil, la réponse finale — chaque entrée horodatée.
En soustrayant les created_at, tu vois précisément combien d’outils ont été appelés pendant ton exécution de scène, lesquels, et lequel a mangé le temps. Deux signaux à guetter :
- plusieurs appels d’outils pour une simple phrase de confirmation → chaque appel est un aller-retour complet vers le modèle, c’est probablement là que partent tes secondes ;
- un
tool_status: "error" → un outil qui échoue fait repartir le modèle pour un tour supplémentaire, ce qui peut doubler ou tripler le temps total. C’est le genre de chose qu’on ne soupçonne pas et qui saute aux yeux dans ce fichier.
Les appels déclenchés par une scène sont bien enregistrés ici : l’historique est celui de l’utilisateur choisi dans l’action « Demander à l’IA ». Pense donc à déclencher la scène avant de télécharger le fichier.
Accessoirement, la section tools du même fichier liste tous les outils envoyés au modèle à chaque appel. Si elle est très volumineuse (beaucoup de devices), ça alourdit aussi chaque requête.
2. Compléter avec les logs si besoin
Si le fichier ci-dessus ne suffit pas à trancher, Paramètres → Système → Télécharger les logs, puis cherche [AI_CHAT] dans le fichier. Tu obtiens la trace côté serveur, horodatée ligne par ligne :
[AI_CHAT] New request userId=... message=...
[AI_CHAT] Forcing tool_choice=required for categories=device_query
[AI_CHAT] Assistant turn iteration=1 tool_calls=1 tool_choice=required tools=[...]
[AI_CHAT] Running tool=...
[AI_CHAT] Tool finished tool=... status=success resultLength=...
[AI_CHAT] Assistant turn iteration=2 tool_calls=0 ...
[AI_CHAT] Completed answerLength=...
La grille de lecture :
| Où part le temps |
Ce que ça veut dire |
Entre New request et le 1er Assistant turn |
Préparation locale (Gladys reconstruit la liste des outils depuis ta base) + appel de classification |
Beaucoup de lignes Assistant turn iteration= |
Le nombre d’allers-retours vers le modèle explose |
Entre Running tool= et Tool finished tool= |
L’exécution de l’outil sur ton instance qui rame |
Un seul Assistant turn, mais 10 s pour l’atteindre |
Le modèle ou ta liaison réseau |
3. Un test comparatif immédiat
Dans le chat avec Gladys, pose successivement ton prompt complet, puis une version courte sans aucune référence à un capteur : « Donne-moi une phrase courte pour confirmer que tu t’occupes de la demande ». Chronomètre les deux à la montre.
Si le court répond en 2 s et le long en 15 s, c’est confirmé : c’est ton prompt qui déclenche des appels d’outils. Mentionner la température de l’eau fait comprendre au modèle qu’il doit aller lire un capteur avant de répondre. Dans ce cas tu as un gain immédiat en réécrivant ton prompt pour qu’il n’ait besoin d’aucune donnée — et le fichier de l’étape 1 te le montrera noir sur blanc.
Fais-toi aider par une IA pour dépouiller tout ça
C’est typiquement le genre de tâche où Claude (ou ton assistant préféré) est très efficace, et ça t’évite d’attendre après moi. Donne-lui le contenu de _debug.conversationHistory avec une consigne du style :
« Voici l’historique horodaté d’un appel IA dans Gladys Assistant, au format JSON. Liste les outils appelés dans l’ordre, calcule la durée entre chaque étape, et dis-moi où part la majorité du temps total. Signale tout outil en erreur. »
Gladys est open source, donc tu peux aussi lui donner le fichier qui gère tout ce flux pour qu’il raisonne sur le code réel : server/lib/gateway/gateway.forwardMessageToAiChat.js dans le dépôt GitHub du projet.
Petite précaution : ce fichier contient tes messages, tes noms de pièces et de devices. Retire ce que tu ne veux pas partager avant de le coller quelque part, ici comme ailleurs.