À quoi servent le middleware et les validations humaines ?
Situer les contrôles logiciels et l’accord humain avant une action, sans les confondre avec une consigne au modèle.
Notre agence de voyage a demandé de comparer des séjours à Agadir, sans réserver. Même si cette consigne figure dans le prompt, le modèle pourrait proposer un appel de réservation. Qu’est-ce qui empêche alors son exécution ?
Une instruction guide le modèle. Un contrôle logiciel décide si l’action peut réellement avoir lieu. La validation humaine intervient lorsqu’un choix doit rester entre les mains d’une personne.
Le middleware intervient dans l’exécution
Un middleware est du code qui intervient à un point prévu du traitement, par exemple avant ou après un appel au modèle ou à un outil. Il peut examiner les données, les modifier, laisser continuer l’appel ou le bloquer. Ce n’est ni un prompt supplémentaire ni nécessairement un autre agent.
Microsoft Agent Framework distingue ces points d’intervention. Dans notre application de voyage, ils pourraient servir à :
- Avant le modèle : retirer des informations personnelles inutiles à la demande.
- Avant l’outil : vérifier les droits, la destination, les dates et les montants ; refuser l’appel ou demander une validation si nécessaire.
- Après l’outil : examiner le résultat, signaler un échec et enregistrer la durée de l’appel sans recopier de données sensibles.
Tout middleware n’est donc pas un contrôle de sécurité. Celui qui mesure seulement la durée ne bloque aucune réservation. Ses effets dépendent du code exécuté et de l’endroit où il intervient.
Contrôler avant l’effet réel
Dans la mission actuelle, l’application peut ne fournir aucun outil de réservation. Si cet outil existe pour d’autres missions, son exécution doit vérifier les autorisations, même lorsque le modèle le demande.
Un contrôle effectué après l’appel peut détecter un problème, mais il n’annule pas une réservation déjà faite. La décision d’autoriser doit précéder l’action concernée. Les règles d’accès restent applicables : un bouton d’approbation ne donne pas à une personne des droits qu’elle ne possède pas.
Demander un accord sur une action précise
Pour illustrer la suite, imaginons une autre mission : préparer une réservation, puis attendre l’accord avant de l’effectuer. Cet exemple est simulé ; aucune réservation réelle n’est exécutée.
- Présenter la proposition. Afficher l’offre exacte, les dates, le prix total, la devise et les conditions d’annulation. « Continuer ? » ne permet pas de comprendre ce qui sera engagé.
- Contrôler et suspendre. L’application vérifie les droits et les paramètres ; si le contrôle échoue, elle bloque l’appel. Sinon, elle le suspend en conservant les informations nécessaires à la reprise. Le modèle n’a pas besoin de continuer à produire du texte pendant l’attente.
- Recueillir la décision. La personne autorisée accepte, refuse ou demande une modification. Un refus ne déclenche pas l’appel.
- Revérifier puis exécuter. Avant l’appel, vérifier que l’offre et les paramètres correspondent toujours à l’accord. Si le prix ou les conditions changent, présenter la nouvelle proposition pour validation.
Cette intervention est appelée human-in-the-loop, ou humain dans la boucle. LangChain Deep Agents permet de choisir les outils soumis à approbation, avec des décisions d’acceptation, de modification ou de refus selon la configuration. Google ADK propose aussi des confirmations d’action ; cette fonctionnalité est indiquée comme expérimentale dans la documentation consultée.
Valider au bon endroit, pas à chaque étape
Demander un accord pour chaque calcul ou chaque recherche rend le parcours pénible et peut inciter à cliquer sans lire. L’agence doit définir les contrôles selon les conséquences : consulter des offres publiques n’engage pas la cliente comme une réservation payante.
Une lecture n’est toutefois pas toujours sans risque : une requête de recherche peut transmettre une information privée à un service externe. Il faut examiner les données et les permissions, pas seulement le nom de l’outil.
Enfin, l’accord humain ne garantit pas le succès. Après l’appel, l’application doit distinguer réservation confirmée, refusée ou résultat incertain. « Approuvé » ne signifie pas « effectué ».
À retenir : le middleware applique les contrôles prévus ; l’humain décide lorsque son accord est requis. Ni l’un ni l’autre ne dispense de vérifier ce qui a réellement été exécuté.