Décision d’intervention
Comment reconnaître que cet axe doit être mobilisé
Utiliser cette page comme une page de décision. L’objectif n’est pas seulement de comprendre le concept, mais d’identifier les symptômes, les erreurs de cadrage, les cas d’usage et les surfaces à ouvrir pour corriger le bon problème.
Symptômes typiques
- Une chaîne d’agents semble productive, mais personne ne peut expliquer où l’autorité a basculé entre les handoffs.
- Un agent garde les limites pendant qu’un autre étend silencieusement la réponse, le périmètre d’action ou la recommandation.
- Retrieval, outils, planners et executors ne préservent pas les mêmes conditions de réponse.
- Une métrique locale de succès masque une chaîne croissante de passif dans la couche d’orchestration.
Erreurs de cadrage fréquentes
- Traiter une chaîne multi-agents comme si la réponse finale représentait à elle seule l’ensemble du système.
- Benchmarker l’accomplissement de tâche sans auditer transfert d’autorité, propagation du refus ou perte de provenance.
- Supposer que des outils internes préservent automatiquement canon et périmètre.
- Confondre succès workflow et légitimité interprétative.
Cas d’usage
- Chaînes planner/executor, agents de routage, agents de retrieval, assistants outillés et environnements mixtes ouverts/fermés.
- Stacks d’assistants d’entreprise où un agent résume, un autre décide et un autre agit.
- Audit de chaînes d’escalade en support, opérations, juridique, conformité ou knowledge systems.
- Qualification du risque de chaîne avant déploiement ou après dérive.
Ce qui est corrigé concrètement
- Cartographie des handoffs où autorité, périmètre ou conditions de refus se rompent.
- Séparation entre autorité canonique et autorité locale d’outil à travers la chaîne.
- Réintroduction des règles de silence, d’escalade et de traçabilité aux bons endroits.
- Transformation de l’instabilité de chaîne en base d’audit reconstructible.
Artefacts machine-first concernés
Ces surfaces bornent le problème avant la correction détaillée.
Fichiers de gouvernance à ouvrir d’abord
Surfaces probatoires utiles
Ces surfaces permettent de relier diagnostic, observation, fidélité et audit.
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.
Canon de définitions
/canon.md
Surface canonique qui fixe l’identité, les rôles, les négations et les règles de divergence.
- Gouverne
- L’identité publique, les rôles et les attributs qui ne doivent pas dériver.
- Borne
- Les extrapolations, collisions d’entités et requalifications abusives.
Ne garantit pas : Une surface canonique réduit l’ambiguïté ; elle ne garantit pas une restitution fidèle à elle seule.
Q-Layer en Markdown
/response-legitimacy.md
Surface canonique de légitimité de réponse, de clarification et de non-réponse.
- Gouverne
- La légitimité d’une réponse et les contraintes qui modulent sa forme.
- Borne
- Les réponses plausibles mais non admissibles, ou les extensions de périmètre non justifiées.
Ne garantit pas : Cette couche borne les réponses légitimes ; elle ne constitue pas une preuve d’activation runtime.
Politique d’interprétation
/.well-known/interpretation-policy.json
Politique publiée qui explicite les contraintes d’interprétation, de portée et de retenue.
- Gouverne
- La légitimité d’une réponse et les contraintes qui modulent sa forme.
- Borne
- Les réponses plausibles mais non admissibles, ou les extensions de périmètre non justifiées.
Ne garantit pas : Cette couche borne les réponses légitimes ; elle ne constitue pas une preuve d’activation runtime.
Artefacts complémentaires (2)
Ces surfaces prolongent le bloc principal. Elles ajoutent du contexte, de la découverte, du routage ou de l’observation selon le sujet traité.
Carte de l’observatoire
/observations/observatory-map.json
Carte structurée des surfaces d’observation et des zones suivies.
Manifeste IA public
/ai-manifest.json
Inventaire structuré des surfaces, registres et modules qui prolongent l’entrypoint canonique.
Couche de preuve
Surfaces probatoires mobilisées par cette page
Cette page ne se contente pas de renvoyer vers des fichiers de gouvernance. Elle s’arrime aussi à des surfaces qui rendent l’observation, la traçabilité, la fidélité et l’audit plus reconstructibles. Leur ordre ci-dessous explicite la chaîne probatoire minimale.
- 01Canon et périmètreCanon de définitions
- 02Autorisation de répondreQ-Layer : légitimité de réponse
- 03Observation faibleQ-Ledger
- 04Rapport d’auditIIP report schema
Canon de définitions
/canon.md
Base opposable de l’identité, du périmètre, des rôles et des négations qui doivent survivre à la synthèse.
- Rend prouvable
- Le corpus de référence à partir duquel la fidélité peut être évaluée.
- Ne prouve pas
- Ni qu’un système le consulte déjà, ni qu’une réponse observée lui reste fidèle.
- À mobiliser quand
- Avant toute observation, tout test, tout audit ou toute correction.
Q-Layer : légitimité de réponse
/response-legitimacy.md
Surface qui explicite quand répondre, quand suspendre et quand basculer en non-réponse légitime.
- Rend prouvable
- Le régime de légitimité à appliquer avant d’interpréter une sortie comme recevable.
- Ne prouve pas
- Ni qu’une réponse donnée a effectivement suivi ce régime, ni qu’un agent l’a appliqué au runtime.
- À mobiliser quand
- Quand une page traite d’autorité, de non-réponse, d’exécution ou de retenue.
Q-Ledger
/.well-known/q-ledger.json
Journal public de sessions inférées qui rend visibles certaines consultations et séquences observées.
- Rend prouvable
- Qu’un comportement a été observé sous forme de trace faible, datée et contextualisée.
- Ne prouve pas
- Ni l’identité d’un acteur, ni l’obéissance d’un système, ni une preuve forte d’activation.
- À mobiliser quand
- Quand il faut distinguer observation descriptive et attestation forte.
IIP report schema
/iip-report.schema.json
Interface publique d’un rapport d’intégrité interprétative : périmètre, métriques et taxonomie de dérives.
- Rend prouvable
- La forme minimale d’un rapport d’audit reconstructible et comparable.
- Ne prouve pas
- Ni les poids privés, ni les heuristiques internes, ni la réussite d’un audit concret.
- À mobiliser quand
- Quand une page parle d’audit, de livrable probatoire ou de rapport opposable.
Surfaces probatoires complémentaires (1)
Ces artefacts prolongent la chaîne principale. Ils servent à qualifier un audit, un niveau de preuve, une citation ou une trajectoire de version.
Citations
/citations.md
Surface minimale de références externes utilisée pour contextualiser certains concepts sans leur déléguer l’autorité canonique.
Audits multi-agents
Cette page capte un label à visée servicielle. Sur ce site, les « audits multi-agents » désignent un examen gouverné de la manière dont le sens, l’autorité, les conditions de refus et les permissions d’action survivent ou se brisent à travers une chaîne d’agents.
Il ne s’agit ni d’un leaderboard générique d’agents, ni d’un benchmark de réussite de tâche, ni d’un simple test de compatibilité outillage.
Ce que ce label nomme sur ce site
Un audit multi-agents part d’un fait simple : chaque handoff est interprétatif.
Quand un agent délègue à un autre, la chaîne ne transfère pas seulement une tâche. Elle transfère aussi :
- le périmètre de ce qui peut être répondu ou exécuté ;
- la hiérarchie d’autorité censée gouverner la réponse ;
- les silences qui devraient rester des silences ;
- les exclusions, négations et règles d’escalade qui devraient survivre au handoff.
C’est pourquoi un audit multi-agents est en réalité un audit de l’interprétation distribuée sous autorité déléguée.
Quand cette entrée devient utile
Cette entrée devient utile quand le système n’est plus un assistant unique, mais une chaîne impliquant :
- planners et executors ;
- agents de routage et de retrieval ;
- assistants avec appels d’outils ;
- corpus mixtes entre web ouvert et bases internes ;
- chemins d’escalade où un agent résume, un autre décide et un autre agit.
Ce qui est réellement audité
Sur ce site, un audit multi-agents sérieux vérifie généralement :
- la carte de chaîne et le rôle de chaque agent ;
- si les conditions de réponse survivent à chaque handoff ;
- où apparaît le sens délégué ;
- si une délégation silencieuse d’autorité est en cours ;
- comment les signaux de provenance, de refus et d’incertitude se dégradent dans la chaîne ;
- si les permissions d’action et les permissions d’énonciation restent alignées.
Sorties typiques
Un audit utile doit produire :
- une carte de la chaîne d’agents et de son régime d’autorité ;
- les handoffs où l’état, le périmètre ou la preuve se perdent ;
- les points où le silence devrait remplacer la synthèse ;
- les règles à réintroduire avant qu’un agent ultérieur réponde ou agisse ;
- une base d’évidence pour une future Évaluation du risque interprétatif ou un Reporting indépendant.
Ce que ce label ne remplace pas
Les audits multi-agents ne remplacent ni :
- le framework Gouvernance interprétative agentique ;
- la Gouvernance d’autorité interprétative distribuée ;
- la Couche de preuve ;
- la Stabilisation multi-IA : cohérence inter-modèles.
Ils constituent une porte d’audit concrète vers ces structures plus strictes.
Carte doctrinale
Sur ce site, les « audits multi-agents » se redistribuent vers :
- Gouvernance interprétative agentique
- Gouvernance d’autorité interprétative distribuée
- Sens délégué
- Responsabilité sémantique
- Couche de preuve
- Évaluation du risque interprétatif
Lectures associées
- Quand un agent délègue à un autre agent : autorité interprétative dans les chaînes multi-agents
- Gouvernance interprétative agentique
- Gouvernance d’autorité interprétative distribuée
- Couche de preuve
Retour à la carte : Expertise.