Assurance API

Rattachez un document OpenAPI à un cas de test et chaque exécution le traversant devient une preuve contractuelle. Autonomy attribue le trafic produit par le parcours aux opérations documentées, valide les réponses par rapport au schéma et dérive un verdict unique pour l'exécution.

L'intérêt est la séparation des responsabilités. Une assertion générée par un modèle dit « la réponse avait l'air correcte ». Une vérification contractuelle dit « cette réponse viole le schéma que vous avez publié » — et ce verdict ne peut pas être supplantée par un modèle.

Révisions contractuelles

Un document OpenAPI 3 ou Swagger 2 accepté — JSON ou YAML — est compilé en une révision contractuelle : un artefact canonique et déterministe avec les références locales résolues, les exemples retirés, les opérations normalisées et l'ensemble haché.

Les révisions sont immuables et dédupliquées par empreinte :

• Un cas de test pointe vers une révision.
• Une exécution fixe la révision qu'elle a utilisée.
• Réimporter un document modifié crée une nouvelle révision. Elle ne mute jamais l'ancienne et ne réinterprète jamais une exécution historique.

Cette immuabilité est ce qui rend les preuves défendables six mois plus tard. Le verdict de l'exécution du trimestre précédent fait toujours référence au contrat tel qu'il existait ce jour-là.

La compilation est stricte sur les références. Les valeurs $ref locales sont résolues ; les références externes, de fichiers voisins et pendantes sont rejetées catégoriquement plutôt que silencieusement affaiblies. Les schémas récursifs ou à profondeur limitée sont marqués comme tels, et la validation les signale comme indéterminés — une branche non résolue ne peut jamais être rapportée comme réussie.

Rattacher un contrat

Téléversez le document en pièce jointe lorsque vous rédigez un cas de test avec Describe the flow — le sélecteur de fichiers accepte OpenAPI / Swagger (.yaml, .json). Il est analysé au plan sécurité comme tout autre téléversement, compilé, et la révision résultante est liée au cas de test.

Deux conséquences découlent du rattachement d'un contrat :

• Autonomy peut rédiger des assertions réseau en complément des étapes d'interface, car il sait ce que l'API est censée faire.
• Chaque exécution de ce cas de test dérive un rapport d'assurance.

Ce que dérive une exécution

Lorsqu'une exécution atteint un état terminal, une passe d'assurance idempotente produit :

• Couverture des opérations — combien d'opérations documentées le parcours a réellement exercées, et lesquelles n'ont jamais été touchées.
• Dérive dans les deux sens — le trafic qui ne correspond à aucune opération documentée, et les opérations documentées qui n'apparaissent jamais dans le trafic.
• Constatations contractuelles — violations déterministes de statut, de content-type, d'en-têtes requis et de schéma de réponse.
• Documents OpenAPI Overlay — patchs en lecture seule, sans valeur, décrivant le changement que les preuves impliquent, liés à l'empreinte source et téléchargeables depuis l'exécution.
• Références de forme de réponse et de latence, avec les écarts par rapport aux exécutions précédentes.
• Un verdict de porte : passing, failed ou indeterminate, avec des raisons explicites.

L'espace de preuves de l'exécution affiche ces informations sous forme d'une ligne de faits : le statut de la porte, n/m operations observed, les échecs contractuels et les résultats indéterminés, et le décompte des constatations ventilées par isolation, cross-canal et sondes de fuzz. Les patchs overlay inférés sont listés avec leur justification et peuvent être téléchargés au format JSON.

indeterminate est une réponse réelle, pas un échec atténué. Cela signifie que les preuves n'ont pu prouver le contrat ni dans un sens ni dans l'autre — une branche de schéma non résolue, ou une capture réseau que la plateforme n'a pas pu observer de manière fiable. Traitez-le comme « inconnu », pas comme « tout va bien ».

Sécurité des preuves

Le trafic en cours d'exécution contient des identifiants, des données personnelles et des identifiants de locataire ; les observations sont donc structurelles par construction. Une observation enregistre la méthode, la forme du chemin canonique, les noms des paramètres de requête et des en-têtes, le statut, le type de contenu, le minutage et la taille bornés, les empreintes de forme JSON, l'identité de l'opération vérifiée et les codes d'erreur de validation fixes.

Elle n'enregistre jamais un nom d'hôte, un chemin ou une valeur de requête bruts, une valeur d'en-tête, un cookie, un corps, un exemple de schéma, un identifiant ou une donnée personnelle. La capture brute reste dans le processus du runner et y est bornée. Aucune requête client n'est jamais rejouée.

Identifiants et sondes multi-identité

Les plans de test stockent des références d'identifiants, jamais des valeurs. Un profil source un identifiant depuis une variable d'environnement du runner ou depuis une valeur extraite plus tôt dans la même exécution, et les valeurs d'étapes sensibles utilisent des espaces réservés explicites tels que {{env.API_TOKEN}}. Le runner les résout dans sa frontière de dispatch — les valeurs résolues n'entrent jamais dans le contexte du modèle, les traces, les observations ou les arguments de fonctions backend.

C'est ce qui rend les sondes d'autorisation possibles. Une sonde BOLA/IDOR doit référencer une étape mutatrice antérieure ayant créé une ressource, utiliser deux profils d'identité distincts, et prouver avant le dispatch que les deux principaux diffèrent réellement. Si elle ne peut pas le prouver — jetons opaques, claims manquantes, principaux identiques — la sonde signale un résultat indéterminé plutôt que de déclarer un succès.

Dans les pull requests

Lorsqu'un cas de test a un contrat rattaché, le résultat d'assurance est ajouté au commentaire de pull request Autonomy à côté de la matrice d'exécution, et se répercute dans la conclusion du check run. Voir Application GitHub.

Dépannage

La couverture est à zéro

Le parcours n'a pas produit de trafic qu'Autonomy a pu attribuer. Confirmez que l'exécution a utilisé une plateforme avec capture réseau prise en charge, et que les chemins serveur documentés correspondent à la cible réellement atteinte par l'exécution.

Tout est indéterminé

Généralement un schéma non résolvable. Vérifiez que le compilateur n'a rien rejeté à l'import, et recherchez des définitions récursives ou à profondeur limitée dans les opérations concernées.

Le contrat a changé mais les exécutions citent encore l'ancien

Les révisions sont immuables par conception. Réimportez le document pour créer une nouvelle révision et liez le cas de test à celle-ci ; les exécutions historiques continuent de citer la révision contre laquelle elles ont été exécutées.