Contrats de schémas d'outils
Chaque outil qu'un agent utilise vient avec un formulaire précis et versionné qui décrit exactement ce qui entre et ce qui sort — pour que rien ne change de forme en douce et ne casse vos workflows.
Pensez à un bon de commande signé entre vous et un fournisseur. Les deux côtés savent exactement quelles cases existent et ce qui va dans chacune. Si le fournisseur veut changer le formulaire, il publie une nouvelle version et vous laisse le temps de vous adapter — il ne glisse pas une nouvelle case pendant la nuit en espérant que vous la remarquiez.
Le problème, en mots simples
Un de vos workflows dépend d'un outil — disons celui qui cherche une commande. Un jour, l'équipe derrière cet outil renomme un champ, ou change la façon d'écrire les dates. Rien ne l'annonce. Votre agent continue d'appeler l'outil, reçoit quelque chose de légèrement différent de ce qu'il attend, et se met à produire de mauvaises réponses — en silence. Vous l'apprenez par un client mêlé, pas par une alerte, et vous passez ensuite une journée à remonter la bizarrerie jusqu'à un changement dont personne ne vous avait parlé.
Ce que nous mettons en place
Chaque outil publie un contrat écrit en JSON Schema (une façon standard et lisible par machine de décrire la forme exacte des données) : voici de quoi a l'air une requête valide, voici de quoi a l'air une réponse valide. Le registre — le catalogue par lequel passent tous les appels d'outils — vérifie chaque appel contre le contrat à la frontière, avant qu'il n'atteigne le vrai système. Les contrats portent des numéros de version : un changement est une nouvelle version, pas une retouche silencieuse; chaque workflow choisit de s'ancrer à une version de confiance ou de toujours prendre la plus récente. Un changement qui brise l'ancien formulaire passe par une fenêtre de retrait (un préavis avant que l'ancienne version soit éteinte). Et votre jeu d'évaluation — la bibliothèque de questions-tests sur laquelle le système est noté — se relance automatiquement dès qu'un contrat d'outil change.
Comment ça fonctionne, étape par étape
- Chaque outil publie son formulaire
Entrées et sorties décrites précisément, sous un numéro de version. Aucun outil n'entre au catalogue sans ça.
- Chaque appel est vérifié à la porte
Un appel qui ne respecte pas le formulaire est refusé avant d'atteindre le vrai système — une erreur bruyante et précoce plutôt que silencieuse et tardive.
- Les changements reçoivent une nouvelle version
Un formulaire mis à jour est publié comme nouvelle version; l'ancien continue de fonctionner. Les workflows migrent à leur rythme.
- Les bris annoncés ont un préavis
La fenêtre de retrait liste les workflows touchés et donne à leurs responsables le temps de s'adapter avant que l'ancien formulaire soit retiré.
- Les tests se relancent à chaque changement
Un contrat modifié relance automatiquement le jeu d'évaluation : un outil qui se comporte autrement est attrapé avant le déploiement, pas après.
Ce qui change pour vous
Avant : un changement d'outil était une surprise découverte en production, souvent par un client. Après : c'est un événement suivi, avec un numéro de version, une liste connue de workflows touchés et des tests déjà passés. Le débogage passe de « qu'est-ce qui a changé quelque part ? » à la lecture d'un journal des modifications. Ce qu'il ne fera pas : un contrat vérifie la forme des données, pas leur vérité. Un outil peut encore retourner une mauvaise réponse parfaitement bien formée — l'attraper, c'est le travail des évaluations et des citations, pas des schémas.