Couvre les cas d'évaluation, les métriques de qualité, les limites de latence et de coût, la surveillance, le repli et la gestion des incidents pour l'appel d'outil. Il fixe les limites d'adoption et les preuves d'échec observables tout en gardant les limites spécifiques à l'environnement configurables.
Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n'est faite qu'une implémentation adoptante les ait validés.
Décision
Pour l'appel d'outil, adopter une politique d'orchestration versionnée et une frontière explicite d'appel de modèle. Traiter le bloc comme un contrat de publication et de régression construit à partir de cas positifs représentatifs, de limites, de refus, d'échecs et de récupération. Ce package est un contrat de référence : l'équipe adoptante doit choisir les limites numériques, les fournisseurs, les juridictions et les responsables opérationnels à partir des preuves dans son propre environnement.
Portée
- Les acteurs, entrées, sorties, états, versions de politique ou de schéma, et résultats visibles de l'extérieur décrits par ce bloc de test.
- Interfaces principales et alternatives, travaux en arrière-plan, caches, intégrations, chemins de support, et preuves pouvant exercer la même frontière.
- Configuration spécifique à l'adoption, déploiement, récupération, et responsabilités de vérification nécessaires pour appliquer la référence en toute sécurité.
Hors de ce bloc
- Choisir un fournisseur universel, un framework, une juridiction, un seuil numérique, une période de rétention ou un objectif de niveau de service pour chaque adoptant.
- Affirmer que les scénarios packagés ont été exécutés contre une implémentation en aval ou que cette référence accorde une certification légale, de sécurité ou d'accessibilité.
Contrat
- Persister les versions du prompt, de l'outil, de la récupération, du modèle et de la politique nécessaires pour reproduire ou expliquer chaque résultat matériel.
- Valider la sortie structurée avant tout effet secondaire ; une sortie malformée ou incomplète est une erreur, pas une autorité partielle.
- Séparer le contenu utilisateur non fiable ou récupéré de la politique système et étiqueter chaque élément de contexte avec son origine et sa classe de confiance.
- Limiter les jetons, appels d'outil, latence et dépenses par requête ; franchir une limite déclenche un repli nommé au lieu de continuer sans limite.
- Enregistrer la version du fixture, l'environnement, la configuration, le résultat observé et l'emplacement des preuves pour chaque exécution porteuse de décision.
- Séparer les échecs produit, échecs de dépendance, échecs d'infrastructure de test et preuves non concluantes dans les rapports.
- Exposer les outils via des schémas typés versionnés avec des limites explicites de capacité, données, réseau, coût, délai et effets secondaires, et valider chaque argument avant invocation.
- Autoriser à l'exécution, exiger une approbation pour les actions configurées à fort impact, lier les tentatives à une identité durable, assainir les sorties, et plafonner appels, récursions et dépenses.
Conseils d'implémentation
- Construire le plus petit ensemble déterministe de fixtures couvrant les classes de risque, puis ajouter des cas dérivés de la production uniquement après revue respectueuse de la vie privée.
- Modéliser les entrées, sorties, acteurs, états, invariants, effets secondaires et preuves de l'appel d'outil avant de sélectionner les détails du framework ou du fournisseur.
- Stocker la version applicable du contrat ou de la politique d'appel d'outil avec l'état matériel afin que les migrations, rejouages et décisions de support restent attribuables.
- Introduire le chemin derrière un déploiement contrôlé, comparer les résultats attendus et observés, et conserver une route de récupération testée jusqu'à ce que les preuves d'adoption soient complètes.
Gestion des échecs et protections
- Échec du fournisseur, sortie non sécurisée ou budget épuisé renvoie un repli borné et conserve des preuves diagnostiques sûres pour la corrélation.
- État d'appel d'outil invalide ou contradictoire est rejeté ou mis en quarantaine ; l'implémentation ne devine jamais une valeur qui élargit l'autorité ou duplique un effet.
- Les tentatives sont limitées et utilisent une identité durable ; après épuisement, le travail atteint un état terminal inspectable avec un propriétaire responsable.
Vérification et opérations
- Exécuter la suite deux fois à partir d'un état propre et confirmer que l'ordre, les tentatives et l'exécution parallèle ne modifient pas le verdict.
- Surveiller le succès, le refus, l'échec de validation, l'échec de dépendance, l'épuisement des tentatives et la récupération par version de contrat sans dimensions sensibles de charge utile.
- Réexécuter les fixtures positives et négatives appariées après changements de politique, schéma, dépendance, migration ou frontière et conserver les preuves résultantes.
Hypothèses d'adoption
- Les noms et valeurs dans l'exemple sont un fixture concret, pas des valeurs par défaut universelles ; les adoptants les remplacent par des preuves et une propriété documentées.
- Le système adoptant peut fournir une identité authentifiée, des versions durables d'opération ou d'enregistrement, une télémétrie bornée, et un chemin contrôlé pour le changement.
Les exemples à l'apparence exécutable dans ce package sont des fixtures et des contrats d'acceptation. Exécutez le validateur de collection pour vérifier la structure et les métadonnées, puis traduisez et exécutez les scénarios dans le dépôt cible avant d'enregistrer les preuves d'implémentation.
Références
- NIST AI 600-1, Profil d'IA générative (applicable à partir du 2026-09-08)