Cadre de découvrabilité agentique v0.1

Artefacts de gouvernance

Fichiers de gouvernance mobilisés par cette page

Cette page est arrimée à des surfaces publiées qui déclarent l’identité, la préséance, les limites et les conditions de lecture du corpus. Leur ordre ci-dessous donne la séquence de lecture recommandée.

Entrypoint#01

Entrypoint IA canonique

/.well-known/ai-governance.json

Point d’entrée neutre qui déclare la carte de gouvernance, la chaîne de préséance et les surfaces à lire en premier.

Gouverne: L’ordre d’accès aux surfaces et la préséance initiale.
Borne: Les lectures libres qui contournent le canon ou l’ordre publié.

Ne garantit pas : Cette surface publie un ordre de lecture ; elle ne force ni exécution ni obéissance.

Entrypoint#02

Manifeste IA public

/ai-manifest.json

Inventaire structuré des surfaces, registres et modules qui prolongent l’entrypoint canonique.

Gouverne: L’ordre d’accès aux surfaces et la préséance initiale.
Borne: Les lectures libres qui contournent le canon ou l’ordre publié.

Ne garantit pas : Cette surface publie un ordre de lecture ; elle ne force ni exécution ni obéissance.

Découverte et routage#03

LLMs.txt

/llms.txt

Surface de découverte courte qui oriente les systèmes vers les entrées machine-first utiles.

Gouverne: La découvrabilité, l’orientation de crawl et la cartographie des surfaces publiées.
Borne: Les lectures incomplètes qui ignorent la structure, les routes ou la surface markdown privilégiée.

Ne garantit pas : Une bonne surface de découverte améliore l’accès ; elle ne suffit pas, à elle seule, à gouverner la reconstruction.

Statut du cadre

Le Cadre de découvrabilité agentique est une proposition versionnée. Sa version 0.1 formalise un vocabulaire, une chaîne de transitions, des axiomes et un régime de preuve.

Il ne constitue ni une norme, ni une certification, ni un protocole industriel adopté. Il ne promet pas qu’un objet sera cité, recommandé ou sélectionné par un système tiers.

La définition canonique proposée possède le terme. Le présent cadre organise son application et son observation.

Problème traité

Les mesures de visibilité compressent souvent plusieurs états : une ressource existe, elle est récupérable, elle apparaît dans une réponse, elle est citée, elle est comparée, elle est recommandée ou elle est utilisée.

Ces états ne sont pas équivalents.

Un système peut :

trouver une ressource sans résoudre correctement l’entité ;
résoudre l’entité sans comprendre son offre ;
comprendre l’offre sans la considérer pour l’intention courante ;
la considérer sans la sélectionner ;
la sélectionner tout en la restituant incorrectement ;
la recommander sans pouvoir l’invoquer ou agir avec elle.

Le cadre sert à empêcher ces fusions.

Unité d’analyse

Toute observation doit déclarer au minimum :

D = objet × intention × agent × contexte × temps

Où :

objet : entité, contenu, service, offre, ressource ou capacité numérique ;
intention : problème, besoin, comparaison, recherche, décision ou action à accomplir ;
agent : système, modèle, version, configuration et éventuels outils ;
contexte : langue, région, contraintes, données disponibles, profil de l’utilisateur et état de session ;
temps : instant ou fenêtre d’observation.

Une conclusion qui omet l’une de ces dimensions doit être qualifiée comme partielle.

Chaîne de transitions

Le modèle public peut être résumé ainsi :

Présence → Exposition → Accessibilité → Résolution → Interprétation → Admissibilité → Considération → Sélection → Restitution

Ces neuf portes ne prétendent pas reproduire l’architecture interne de tous les systèmes. Elles constituent une grille de vérification des transitions qu’un observateur peut chercher à établir.

1. Présence

Question : l’objet existe-t-il dans un environnement adressable et suffisamment stable pour être référencé ?

Preuves possibles : route, identifiant, page, entrée de catalogue, ressource, version, date de publication.

Échecs typiques : objet absent, surface non publiée, version introuvable, entité non représentée.

2. Exposition

Question : un système peut-il apprendre que l’objet existe ?

Preuves possibles : maillage, sitemap, catalogue, index, donnée structurée, surface de découverte, relation externe qualifiée.

Échecs typiques : surface orpheline, mauvais routage, catalogue incomplet, signal contradictoire.

3. Accessibilité

Question : le système peut-il atteindre et lire la ressource dans les conditions applicables ?

Preuves possibles : réponse HTTP, rendu exploitable, politique d’accès, authentification, négociation de format, stabilité de la route.

Échecs typiques : blocage, rendu vide, dépendance critique à un état tardif, permission ambiguë, ressource inaccessible.

4. Résolution

Question : l’objet est-il correctement identifié et distingué de ses voisins ?

Preuves possibles : identifiants, nom canonique, relations, version, organisation propriétaire, périmètre.

Échecs typiques : homonymie, fusion de marque, mauvaise version, attribution à la mauvaise entité.

5. Interprétation

Question : le rôle, le sens, les conditions et les limites sont-ils reconstruits fidèlement ?

Preuves possibles : comparaison avec le canon, matrice d’affirmations, tests de portée, détection d’omissions.

Échecs typiques : rôle élargi, condition omise, capacité inventée, distinction conceptuelle effacée.

6. Admissibilité

Question : l’information ou la capacité est-elle utilisable pour l’intention courante selon son autorité, sa provenance, son état et ses limites ?

Preuves possibles : source canonique, hiérarchie de sources, preuve datée, condition d’applicabilité, autorité déclarée.

Échecs typiques : source faible, état périmé, preuve insuffisante, portée non applicable, permission absente.

7. Considération

Question : l’objet entre-t-il dans le champ des options pertinentes pour l’intention déclarée ?

Preuves possibles : trace d’un agent instrumenté, liste explicite de candidats, comparaison visible, justification de routage.

Échecs typiques : objet accessible mais jamais envisagé, filtre implicite, contexte incompatible, candidat ignoré.

Dans un système en boîte noire, cette étape est souvent NOT_EVALUATED.

8. Sélection

Question : l’objet est-il choisi, recommandé, cité comme source principale ou retenu pour une action ?

Preuves possibles : sortie finale, recommandation explicite, choix de source, invocation, décision tracée.

Échecs typiques : concurrent sélectionné, objet relégué, choix non soutenu, recommandation hors contexte.

9. Restitution

Question : l’objet sélectionné est-il présenté fidèlement, avec les limites, attributions et conditions nécessaires ?

Preuves possibles : comparaison canon-sortie, attribution, exactitude des affirmations, conservation des exclusions.

Échecs typiques : mauvaise description, citation trompeuse, conditions supprimées, périmètre élargi.

Axiomes

1. Axiome de relationalité

La découvrabilité n’est jamais une propriété absolue. Elle dépend de l’objet, de l’intention, de l’agent, du contexte et du temps.

2. Axiome de non-équivalence

Présence, récupération, compréhension, citation, considération, recommandation, sélection et action ne sont pas interchangeables.

3. Axiome d’éligibilité

Une absence de recommandation n’est pas un échec lorsque l’objet n’était pas approprié à l’intention. Les taux de recommandation et de sélection doivent utiliser un dénominateur constitué de scénarios réellement éligibles.

4. Axiome de fidélité

Une apparition ou une sélection fondée sur une représentation erronée ne constitue pas une réussite complète.

5. Axiome d’observabilité

Une étape interne non observable ne doit pas être affirmée. Le statut correct est NOT_EVALUATED, pas une explication inventée.

6. Axiome de temporalité

Toute observation est liée à une version de système, une région, une langue, une configuration et un instant.

7. Axiome de séparation des permissions

La découverte ne vaut pas permission d’entraînement, d’extraction, d’invocation, de transaction ou d’action.

Statuts de preuve

Chaque porte doit recevoir un statut explicite :

Statut	Signification
`OBSERVED`	La transition est directement soutenue par une trace ou une sortie inspectable.
`SUPPORTED_INFERENCE`	La conclusion est inférée à partir de preuves déclarées, sans être directement observée.
`NOT_EVALUATED`	Les preuves disponibles ne permettent pas d’évaluer la transition.
`NOT_APPLICABLE`	La transition ne s’applique pas au scénario ou au type d’objet.
`FAILED`	Une preuve observable établit que la transition attendue a échoué.

SUPPORTED_INFERENCE ne doit jamais être présenté comme OBSERVED.

Trois modes d’observation

Mode 1 : audit des surfaces

Ce mode vérifie ce que l’éditeur contrôle directement :

routes et canons ;
HTML et données structurées ;
surfaces de découverte ;
graphes d’entités ;
politiques et conditions d’accès ;
catalogues de services ou de capacités ;
provenance, versions et hiérarchie des sources.

Il mesure une préparation contrôlable. Il ne prouve pas la considération ou la sélection par un système tiers.

Mode 2 : agent instrumenté

Un agent contrôlé est exécuté avec des traces permettant d’observer :

les ressources consultées ;
les candidats identifiés ;
les critères utilisés ;
les rejets ;
la source ou la capacité sélectionnée ;
l’éventuelle invocation ;
la restitution produite.

C’est le mode privilégié pour évaluer directement la considération et la sélection.

Mode 3 : panel externe en boîte noire

Des scénarios versionnés sont soumis à plusieurs systèmes externes. Les variations contrôlées peuvent porter sur la langue, la région, l’intention, les contraintes, la formulation et le moment.

Dans ce mode, seules les sorties visibles sont déclarées comme observées. Les mécanismes internes demeurent NOT_EVALUATED.

Trois profils de sortie

Profil de préparation contrôlable

Il décrit ce que l’éditeur peut corriger :

exposition des ressources ;
résolution d’entité ;
clarté des offres et capacités ;
provenance et autorité ;
limites, permissions et conditions ;
stabilité des routes et interfaces.

Profil de découvrabilité observée

Il décrit ce que les systèmes font effectivement dans les scénarios testés :

apparition ;
citation ;
inclusion dans une comparaison ;
recommandation ;
sélection ;
variation entre agents, langues, régions et temps.

Profil d’intégrité interprétative

Il décrit la qualité de la restitution :

fidélité des affirmations ;
attribution ;
respect du périmètre ;
conservation des limites ;
conformité à la source canonique ;
absence d’élargissement injustifié.

Ces profils ne doivent pas être fusionnés silencieusement.

Métriques initiales

La version 0.1 interdit un score universel sur 100. Elle autorise des métriques séparées, assorties de leurs dénominateurs et limites.

Métrique	Objet
`surface_exposure_coverage`	Couverture des surfaces attendues effectivement exposées.
`entity_resolution_fidelity`	Exactitude de l’identité reconstruite.
`claim_fidelity`	Conformité des affirmations aux sources canoniques.
`source_precedence_compliance`	Respect de l’ordre d’autorité déclaré.
`observed_appearance_rate`	Proportion de scénarios observés où l’objet apparaît.
`eligible_recommendation_rate`	Recommandations parmi les scénarios où l’objet était réellement éligible.
`selection_rate_given_inclusion`	Sélections parmi les scénarios où l’inclusion était elle-même observable.
`attribution_fidelity`	Exactitude de l’association entre affirmation et source.
`cross_agent_variance`	Écart de résultat entre agents ou environnements comparables.
`language_parity_gap`	Écart entre langues pour des scénarios équivalents.
`temporal_stability`	Variation dans une fenêtre d’observation versionnée.

Chaque métrique doit publier son corpus, son échantillon, son mode d’observation et ses états NOT_EVALUATED.

Contrat minimal d’observation

Un enregistrement devrait conserver au minimum :

identifiant de l’objet ;
type d’objet ;
intention ;
système, modèle et version ;
langue et région ;
contexte et contraintes ;
instant d’observation ;
porte évaluée ;
statut de preuve ;
résultat ;
provenance ;
artefact brut ou référence à celui-ci ;
empreinte du contenu observé ;
limites et facteurs non évalués.

La séparation suivante doit être maintenue :

brut → structuré → interprété → dérivé

Frontière avec l’actionnabilité

La découvrabilité s’arrête à la sélection et à la restitution.

L’actionnabilité commence lorsqu’un agent doit invoquer une capacité, transmettre des données, réserver, acheter, soumettre, modifier ou exécuter.

Un objet peut être découvrable sans être actionnable. Une capacité peut être actionnable sans être appropriée à l’intention. L’autorisation et la gouvernance de l’action restent des objets séparés.

Non-promesses

Le cadre ne prouve pas :

qu’un système tiers consultera une surface ;
qu’une marque sera citée ou recommandée ;
qu’un rang interne existe ou peut être reconstruit ;
qu’un résultat observé restera stable ;
qu’un protocole technique entraîne une sélection ;
qu’une recommandation est commercialement favorable ;
qu’une invocation est autorisée ou réussira.

Paternité et citation

Cette publication ne revendique pas l’invention de l’expression générique « découvrabilité agentique ». Elle établit la publication datée de cette formalisation particulière par Gautier Dorval : unité relationnelle, neuf portes, sept axiomes, statuts de preuve, profils de sortie et séparation de l’actionnabilité.

Citation suggérée :

Dorval, Gautier. « Cadre de découvrabilité agentique », version 0.1 proposée, 27 août 2026, https://gautierdorval.com/frameworks/cadre-decouvrabilite-agentique/.

Historique

Version	Date	Statut	Modification
0.1	2026-08-27	Proposée	Première publication de la chaîne de transitions, des axiomes, des statuts de preuve, des profils et des métriques initiales.

Cadre de découvrabilité agentique