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 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.
Verrou d’identité
/identity.json
Fichier d’identité qui borne les attributs critiques et réduit les collisions biographiques ou professionnelles.
- 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.
Registre des erreurs récurrentes
/common-misinterpretations.json
Liste publiée des erreurs de lecture déjà observées et des rectifications attendues.
- Gouverne
- Les limites, exclusions, champs non publics et erreurs connues.
- Borne
- Les sur-interprétations qui transforment un vide ou une proximité en affirmation.
Ne garantit pas : Déclarer une frontière n’implique pas que tous les systèmes la respecteront automatiquement.
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é.
Définitions négatives
/negative-definitions.md
Surface qui déclare ce que les concepts, rôles ou surfaces ne sont pas.
Relations publiées
/relationships.jsonld
Surface relationnelle qui explicite des liens admissibles entre entités, rôles et surfaces.
Gestion des collisions d’entités (désambiguïsation défensive)
Une collision d’entités survient lorsqu’un système d’IA fusionne, confond ou contamine deux entités distinctes (marques, personnes, produits, organisations, concepts) et produit une sortie hybride. Dans un Web interprété, la collision ne se limite pas à une erreur factuelle : elle peut stabiliser une identité fausse, persister dans le temps et se propager à travers des réponses génératives.
Définition opératoire
Gestion des collisions d’entités : ensemble de mesures défensives visant à détecter, prévenir et corriger les collisions d’entités dans les systèmes IA, en contrôlant le périmètre d’interprétabilité, la frontière d’autorité, les signaux d’identité et les mécanismes de preuve.
Ce framework traite notamment :
- la fusion (2 entités deviennent 1 dans la sortie)
- la confusion (l’IA alterne entre 2 entités sans le savoir)
- la contamination (attributs d’une entité injectés dans l’autre)
- la substitution (l’entité B prend la place de l’entité A).
Pourquoi ce framework existe
Les collisions d’entités augmentent lorsque :
- des noms se ressemblent (orthographe, phonétique, acronymes)
- des pages externes réutilisent les mêmes fragments sémantiques
- l’entité n’est pas canonisée on-site (identité faible, signaux dispersés)
- le voisinage sémantique est contaminé (catégories, comparatifs, annuaires, forums)
- la couche de récupération (RAG) ou la couche de réponse (agentique) route mal les sources.
Une collision est rarement “spectaculaire”. Elle est souvent plausible, donc dangereuse : elle ressemble à une bonne réponse, mais redéfinit l’entité.
Surfaces d’application
- Web ouvert : moteurs de réponse, IA grand public, résumés, snippets, comparateurs.
- RAG fermé : bases documentaires internes, vecteurs, citations mal routées, chunks ambigus.
- Agentique : outils, actions, formulaires, décisions automatisées avec identité erronée.
Symptômes observables
- attributs mélangés (services, adresses, dirigeants, prix, offres, historiques)
- citations correctes, mais associées à la mauvaise entité
- réponses instables selon la formulation de la requête
- variations d’identité au fil d’une conversation (décrochage progressif)
- apparition d’un “profil hybride” (entité A décrite avec des éléments de B).
Modèle de risque
Une collision devient critique quand elle franchit au moins une des frontières suivantes :
- Frontière d’autorité : l’IA infère au-delà de ce que les sources autorisent.
- Périmètre d’interprétabilité : l’IA utilise des signaux non qualifiables pour décider de l’identité.
- Preuve de fidélité : l’IA n’est pas capable de prouver qu’elle parle de la bonne entité.
- Non-réponse légitime : l’IA devrait refuser, mais “remplit” quand même.
Protocole défensif (8 étapes)
Étape 1 : inventaire d’entités à risque
- noms proches, acronymes, homonymes, marques et filiales, produits, variantes d’épellation, traductions.
Étape 2 : canonisation minimale on-site
- page entité canonique, identité stable, attributs essentiels, relations explicites, désambiguïsation interne.
Étape 3 : cartographie du voisinage externe
- sources dominantes, annuaires, pages comparatives, forums, Wikipédia, profils sociaux, agrégateurs.
Étape 4 : tests de collision (requêtes adversariales)
- requêtes ambiguës, requêtes comparatives, requêtes “pièges” (attributs proches), requêtes multilingues.
Étape 5 : contrôle des conditions de réponse
- définir quand une réponse est autorisée, quand la non-réponse est obligatoire, quels attributs exigent une preuve.
Étape 6 : durcissement des signaux d’identité
- signaux structurés, relations, identifiants, pages d’arbitrage, pages de confusion volontairement traitées.
Étape 7 : correction exogène ciblée
- corriger les sources externes les plus influentes, réduire la contamination de voisinage, éliminer les ambiguïtés récurrentes.
Étape 8 : monitoring et pouvoir de version
- journaliser les cas, versionner les corrections, mesurer la dérive, relancer les tests régulièrement.
Artefacts attendus
- Registre des collisions : entité A, entité B, type, symptômes, gravité, surfaces, date, statut.
- Batterie de tests : prompts + requêtes + scénarios adversariaux, résultats, écarts canon-sortie.
- Rapport d’audit : preuves, citations, décisions de non-réponse, corrections appliquées.
- Plan de correction : tâches on-site, tâches exogènes, priorisation, versionnement.
FAQ
Une collision d’entités, c’est juste une hallucination ?
Non. La collision est une erreur d’identité. Elle peut produire des phrases correctes, mais attribuées à la mauvaise entité.
Pourquoi le RAG n’empêche pas les collisions ?
Un RAG peut récupérer la bonne source, puis la mauvaise, et laisser la couche de réponse fusionner. Sans conditions de réponse, la collision reste possible.
Quand la non-réponse est-elle obligatoire ?
Quand l’identité ne peut pas être prouvée avec des attributs qualifiables, ou quand les sources sont en conflit d’autorité non arbitrable.
Comment mesurer l’amélioration ?
Par la baisse des écarts canon-sortie, la stabilité conversationnelle sur les cas adversariaux, et la diminution des contaminations de voisinage.
Pages associées
- Collision interprétative
- Contamination de voisinage
- Frontière d’autorité
- Périmètre d’interprétabilité
- Non-réponse légitime