Un assistant donne une réponse incomplète. Un rapport s’arrête à mi-parcours. Une équipe signale que le bot est indisponible. Ces situations peuvent sembler identiques pour l’utilisateur, tout en nécessitant des interventions techniques très différentes.
La première question utile est concrète : à quel endroit la tâche a-t-elle cessé de progresser ?
Dans le déploiement LEED Agency, les rapports approfondis dépendaient de règles propres au client, de rapports antérieurs et de fichiers. Le travail d’ingénierie a consisté à organiser ces connaissances, ajouter leur recherche et ajuster l’exécution des tâches longues. Un assistant de reporting doit disposer d’un accès fiable au bon contexte avant qu’une meilleure consigne puisse être utile.
ConvertSail a révélé un autre type de dysfonctionnement. Un outil pouvait être connecté par un canal tandis que l’assistant en vérifiait un autre et le signalait comme indisponible. La correction consistait à définir l’intégration de référence et à donner au système un moyen prévisible de l’utiliser. Demander à l’utilisateur de reconnecter un service déjà opérationnel aurait ajouté une étape sans résoudre la cause.
Une autre investigation, consacrée à un processus de production de contenus, a particulièrement bien illustré cette distinction. Une plainte concernant l’indisponibilité du bot comprenait un problème d’accès à un canal. La fiabilité du fournisseur et la qualité des résultats constituaient des sujets distincts. Le travail documenté les a séparés, a vérifié les journaux du service et des tâches, puis a produit des échantillons contrôlés pour un examen complémentaire. Un processus actif, un canal accessible et un résultat acceptable sont trois éléments différents à prouver.
Ces exemples proposent une manière concrète d’examiner un processus IA. Partez de la demande de l’utilisateur et identifiez le résultat attendu. Vérifiez la source à lire, le circuit à utiliser, les droits requis et l’enregistrement qui doit exister ensuite. Examinez alors l’endroit précis où la réalité s’écarte de cette séquence.
Un tableau de bord devient utile lorsqu’il rend ces états lisibles. « En cours » en dit moins que de préciser si le système récupère du contexte, attend un accès, prépare un brouillon ou demande une décision. L’interface doit permettre au responsable de comprendre la prochaine étape.
C’est le travail d’ingénierie autour du modèle : fournir à un système capable le bon contexte, les bons accès et le bon parcours opérationnel. L’objectif est un processus que l’équipe peut utiliser et examiner, avec des défaillances assez précises pour être corrigées.