Contrats pour les applications d’IA : détecter les changements de modèle, de SDK ou d’outils avant la production

Une démonstration qui répond ne prouve pas la compatibilité

Dans une application d’IA, un changement peut ne produire aucune erreur de transport tout en cassant le produit. Le modèle peut continuer à renvoyer un texte utile pour une personne, mais omettre un champ consommé par un service en aval, choisir un outil non autorisé, modifier le sens opérationnel d’une étiquette ou fonder une conclusion sur un extrait récupéré qui ne l’étaye pas. Vérifier que « cela répond toujours » ne revient donc pas à vérifier que le comportement opérationnel attendu est conservé.

Un contrat est une spécification vérifiable des propriétés qui doivent être préservées à une frontière précise du flux. Ce n’est pas la promesse que le modèle rédigera toujours la même phrase, ni une tentative d’éliminer la variabilité générative. Il définit quelles entrées sont acceptées, quelle forme doit avoir la sortie, quelles invariantes métier ne peuvent pas être violées, quelles actions sont autorisées et quelles preuves sont nécessaires avant d’affirmer quelque chose ou d’exécuter une opération.

L’unité d’analyse doit être le changement incompatible concret. Il peut s’agir d’un remplacement de modèle, d’une mise à jour du SDK, d’une modification du prompt système, d’un changement de schéma, d’une nouvelle définition d’outil ou d’une politique fournisseur mise à jour. L’objectif est de répondre avant de promouvoir le changement : le contrat a-t-il été préservé ? La dégradation reste-t-elle dans une limite acceptée ? Le flux doit-il être adapté ? Ou le changement doit-il être bloqué ?

Les contrats complètent les évaluations agrégées de qualité, mais répondent à un autre problème. Une évaluation peut indiquer que l’utilité moyenne reste élevée alors qu’un cas sur cent émet un ordre d’annulation sans confirmation. Ce cas isolé constitue une incompatibilité critique si l’action produit des effets externes. De même, un JSON valide ne prouve pas qu’un argument est sûr, qu’une citation correspond à sa source ou qu’une classification conserve son sens.

Inventaire des frontières et des dépendances

Avant d’écrire des tests, représentez le parcours complet d’un cas utilisateur. Une frontière existe lorsqu’un composant transmet une représentation qu’un autre interprète : la requête envoyée au fournisseur, l’identifiant du modèle, la réponse du modèle, l’adaptateur du SDK, le récupérateur de contexte, l’appel à un outil, le système cible et l’action externe. Chaque frontière peut avoir un contrat distinct et un propriétaire différent.

L’inventaire doit identifier les versions et configurations réellement appliquées, pas seulement des noms génériques. Consignez le modèle ou le snapshot demandé, la version du SDK et de l’API lorsque cela s’applique, le prompt système, les paramètres de génération, le schéma de sortie, la liste des outils, la définition des permissions, la version de l’index de récupération et les adaptateurs internes. Sans ces informations, il sera difficile d’attribuer ultérieurement un échec à une cause précise.

Toutes les frontières n’exigent pas le même type d’assertion. La requête vers le modèle requiert la vérification des paramètres pris en charge et des valeurs normalisées. Une sortie structurée requiert la validation du schéma et des champs obligatoires. La récupération requiert la vérification de la provenance, de l’actualité et de la suffisance des preuves. Les outils requièrent, en plus de la syntaxe, l’autorisation et la simulation des effets. Selon le risque, le système cible a besoin d’idempotence, de contrôle transactionnel ou de mécanismes de compensation.

La documentation des fournisseurs indique que les cycles de vie des modèles et les interfaces peuvent évoluer. En particulier, les retraits de modèles et certains changements de paramètres peuvent transformer des requêtes auparavant valides en erreurs. Il faut donc tester une migration comme un changement de dépendance, même lorsque le code métier n’a pas changé.

Ce qui doit devenir un contrat

Commencez par les éléments déterministes. Les types, les champs obligatoires, les limites numériques, les énumérations, les identifiants, la présence d’une source, le format des dates, les outils autorisés et les règles d’autorisation sont de bons candidats. Les invariantes métier le sont également : un remboursement ne peut pas dépasser le montant payé, un agent ne peut pas modifier les données d’un autre client et une opération nécessitant une approbation humaine ne peut pas être exécutée sans cet état.

Ajoutez ensuite des contraintes opérationnelles. Définissez un budget de latence et de coût par cas, assorti d’une méthode de mesure précisée : par exemple, un percentile sur un échantillon contrôlé, et non une impression isolée. Fixez des maxima pour les tentatives, les outils utilisés par exécution, les documents récupérés et la taille du contexte. Une hausse peut être techniquement compatible tout en étant inacceptable pour le produit ; le contrat doit dissocier ces deux plans.

Les étiquettes méritent un traitement sémantique explicite. Si une sortie contient `risque_eleve`, le contrat doit expliquer quels faits la justifient et quelles conséquences elle déclenche. Une correspondance littérale de l’étiquette ne suffit pas si le critère d’attribution a changé. Utilisez des cas limites annotés par des humains et des assertions sur les conditions observables qui doivent conduire à chaque classe.

Dans les réponses fondées sur des preuves, le contrat doit distinguer le fait de disposer d’une citation du fait d’être étayé. Vérifiez au minimum que la source récupérée est admissible dans le domaine, que sa date satisfait la politique d’actualité, que le passage contient des preuves suffisantes pour l’affirmation et que le flux déclare une insuffisance en l’absence de fondement. L’attribution ne doit pas devenir une décoration générée à la fin du processus.

Classer le changement avant de débattre de ses résultats

Classez chaque modification proposée dans l’un de quatre groupes. Un changement compatible préserve tous les contrats applicables. Un changement compatible avec dégradation acceptable manque un objectif non critique tout en restant dans un seuil approuvé, par exemple une variation limitée de latence. Un changement incompatible viole une propriété obligatoire, telle qu’une autorisation d’action ou un champ requis. Un changement inconnu est un changement pour lequel il manque des cas, des fixtures, de la télémétrie ou une définition suffisante pour conclure.

La classification ne doit pas dépendre de la personne qui propose le changement ni du caractère convaincant d’une démonstration. Elle doit être liée à des règles de promotion publiées à l’avance. Si l’équipe découvre qu’une règle ne reflète plus le besoin du produit, elle peut modifier le contrat, mais cette décision doit être explicite, revue et versionnée ; elle ne doit pas être acceptée implicitement à cause d’un test en échec.

Épingler une version précise de modèle réduit une source de variation et facilite la reproduction des résultats. Les alias ou les modèles soumis à des mises à jour peuvent modifier leur comportement sans que le code client change. La documentation d’OpenAI recommande d’épingler les versions de modèle et d’exécuter des évaluations, car les snapshots peuvent varier dans leur comportement de prompting. Par conséquent, un contrat doit enregistrer à la fois l’identifiant demandé et la politique de mise à jour acceptée par l’équipe.

Concevoir une batterie minimale mais diagnostique

Une batterie utile n’a pas besoin d’essayer de représenter toutes les conversations humaines possibles. Elle doit contenir des cas fixes couvrant les parcours critiques, les cas limites et les contre-exemples historiques. Chaque cas doit déclarer l’entrée, l’état initial, la configuration du flux, le résultat attendu, la sévérité et les assertions. Conservez des données de test sans informations sensibles et assurez-vous qu’elles puissent être exécutées de manière répétée.

Utilisez des fixtures pour les outils et les dépendances externes. Une fixture doit renvoyer des états contrôlés, enregistrer les appels et éviter les effets réels. Vous pouvez ainsi vérifier que le modèle a choisi le bon outil, que les arguments ont été interprétés par l’adaptateur et qu’aucune alternative interdite n’a été tentée. Un environnement de test qui appelle la production n’est pas une fixture : il mélange compatibilité et risque opérationnel.

Les snapshots conviennent aux artefacts délibérément stables, comme une requête normalisée, un schéma d’outil ou une liste ordonnée d’identifiants récupérés. Ils sont fragiles pour une prose complète produite par un modèle. Pour le langage naturel, préférez des assertions sémantiques limitées : présence de faits obligatoires, absence d’affirmations interdites, correspondance avec les preuves et comportement d’abstention lorsque les données sont insuffisantes.

Certaines mesures ne sont pas déterministes. Le taux de réussite, la distribution de latence et la fréquence d’une classification peuvent nécessiter plusieurs exécutions, un échantillon fixé ainsi qu’un intervalle ou une tolérance prédéfinis. Ne transformez pas un faible écart statistique en régression critique, et ne laissez pas l’incertitude statistique masquer une violation déterministe de sécurité.

Sorties structurées et appels d’outils : le schéma n’est pas une autorisation

Une sortie structurée doit être validée deux fois : d’abord au regard de sa représentation, puis de sa signification. La première validation vérifie le JSON, les types, les champs requis, les plages et les valeurs autorisées. La seconde vérifie les relations entre les champs et l’état externe. Par exemple, que la date de début soit antérieure à la date de fin, que le montant appartienne à la commande indiquée et qu’un code de motif soit cohérent avec le cas.

Les interfaces d’outils des fournisseurs peuvent décrire les paramètres au moyen de JSON Schema et proposer des modes stricts de respect du schéma. C’est une aide importante pour réduire les arguments mal formés, mais elle ne remplace pas la validation de l’application. Un argument peut être correctement typé tout en désignant un mauvais compte, une opération hors politique ou une action nécessitant une approbation. L’exécuteur doit appliquer les autorisations, les préconditions et les limites avant de produire des effets.

Le contrat doit également fixer l’ordre des opérations. Dans un flux qui vérifie l’éligibilité avant d’émettre un remboursement, n’acceptez pas une séquence inversée au seul motif que les deux appels sont individuellement valides. Enregistrez les outils autorisés par étape, le nombre maximal d’invocations, les arguments normalisés, la réponse de fixture et l’absence d’appels non autorisés. Cela permet de détecter les changements dans lesquels le modèle semble résoudre la tâche, mais emprunte un raccourci opérationnel dangereux.

Si le fournisseur modifie le modèle, la définition d’outil ou l’adaptateur du SDK, exécutez les mêmes fixtures. Un test de JSON valide détecterait un objet mal formé ; cette batterie peut détecter qu’un autre outil a été choisi, que la vérification préalable a été omise ou que le système a tenté de répéter une action déjà confirmée.

Contrats pour la récupération et les réponses avec sources

Dans un flux RAG, le contrat commence avant la rédaction. Établissez quelles collections le cas peut consulter, quels métadonnées minimales chaque extrait doit renvoyer et comment l’actualité est résolue. Si une réponse dépend d’une politique en vigueur, un document ancien peut être techniquement récupérable tout en étant inadmissible pour la justifier. Le test doit examiner la provenance, et non seulement le texte final.

Définissez une preuve minimale selon le type d’affirmation. Une conclusion normative peut nécessiter un passage explicite provenant d’une source autorisée ; une synthèse peut nécessiter plusieurs extraits cohérents ; un chiffre peut exiger une correspondance exacte avec le document. Si les résultats ne remplissent pas cette condition, le comportement correct peut être de demander davantage de contexte, de déclarer une incertitude ou de ne pas répondre à l’affirmation. Cette abstention est une sortie contractuelle, et non une erreur d’expérience par défaut.

Testez les contradictions et le contexte insuffisant. Incluez des fixtures contenant des documents obsolètes, des sources de moindre autorité, des extraits mentionnant des termes similaires et des ensembles présentant des informations conflictuelles. Le contrat doit indiquer si le flux priorise une source, expose le conflit ou transmet le cas à une revue. Il n’est pas raisonnable d’affirmer qu’une citation est correcte au seul motif qu’elle partage des mots avec la réponse.

Conservez pour chaque exécution l’ensemble des documents candidats, ceux qui ont été sélectionnés, leurs identifiants et métadonnées pertinentes, la version de l’index, la requête transformée et le résultat final. Cette télémétrie permet de distinguer si le non-respect est apparu lors de la récupération, de l’interprétation par le modèle ou de la représentation des preuves.

Intégration dans la CI/CD, décision et réversion

Exécutez la batterie lorsqu’un des artefacts enregistrés change : version de modèle, SDK, prompt système, paramètres, schéma, définition des outils, récupérateur, index ou politique. Le changement doit produire un manifeste comparable incluant les versions, les hachages ou identifiants internes, les résultats par cas, la durée, la consommation mesurée lorsqu’elle est disponible et les traces des outils et de la récupération. Évitez qu’une mise à jour implicite échappe au contrôle des changements.

Organisez les portes de CI par sévérité. Les assertions critiques, telles que les autorisations, les effets interdits, l’isolation des clients ou les preuves obligatoires, doivent bloquer. Les assertions de sévérité élevée bloquent normalement jusqu’à l’obtention d’une adaptation approuvée. Les métriques de qualité ou de performance assorties d’une tolérance peuvent nécessiter une revue. Un résultat inconnu ne doit pas devenir automatiquement compatible par absence de signal.

Lorsqu’un contrat échoue, localisez d’abord la frontière. Comparez la requête normalisée, l’artefact du modèle, la réponse brute, l’adaptation du SDK, les documents récupérés et le journal des outils. Choisissez ensuite entre corriger l’intégration, adapter le contrat parce qu’un besoin légitime a changé, versionner le flux pour conserver les deux comportements ou rejeter le changement. Documentez pourquoi la décision est valide et qui l’a approuvée.

La réversion doit être conçue avant la promotion. Conservez la configuration antérieure permettant de restaurer le modèle, le prompt, le schéma, les outils et les adaptateurs compatibles. Si le fournisseur retire une version, une réversion exacte peut ne pas être possible ; l’alternative est alors un flux versionné avec une adaptation testée. Les politiques de retrait publiées par les fournisseurs constituent une raison supplémentaire de planifier les migrations avant la date limite, plutôt qu’après la détection d’un incident.

Modèle de manifeste de contrat par flux

Un manifeste court transforme l’intention en un artefact révisable. Il doit vivre à côté du flux et évoluer selon le même processus de revue que le code. Il n’a pas besoin de contenir des secrets ni toutes les conversations de test ; il doit pointer vers des identifiants internes de fixtures et définir précisément les propriétés qu’il régit.

Incluez : le nom et l’objectif du flux ; le propriétaire technique et produit ; la version du contrat ; les identifiants de modèle, de SDK et de configurations ; le prompt ou une référence vers sa version ; le schéma de sortie ; les outils autorisés et les permissions ; les dépendances de récupération ; la liste des cas ; les seuils de performance et de coût ; la sévérité de chaque règle ; la politique de promotion ; la télémétrie requise ; la stratégie de réversion ; et la date de révision. Si une règle n’a pas de propriétaire ou de critère d’échec, ce n’est pas encore un contrat opérationnel.

Le modèle ne supprime pas le jugement technique. Les sources disponibles documentent des mécanismes de versionnement, de retrait, de schémas et d’usage strict des outils, mais elles ne peuvent pas décider quelle preuve est suffisante pour votre domaine ni quelle action exige une approbation humaine. Ces décisions relèvent de l’équipe responsable et doivent être formulées comme des politiques vérifiables. L’avantage du manifeste est de forcer leur visibilité avant qu’une mise à jour ne les contredise.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.