Summary

  • Une conversation expurgée peut être nette pour un lecteur tout en restant opaque pour le logiciel : ni l'emplacement, ni le participant, ni la méthode ne sont nécessairement signalés.
  • Le noyau VCON permet de référencer un prédécesseur, de hacher un contenu externe et de signer le dérivé. Il lie des octets et une identité ; il ne prouve ni l'exhaustivité de l'expurgation, ni la vérité d'une valeur de remplacement.
  • Avant tout usage à conséquence, le destinataire devrait exiger un reçu de transformation vérifiable et appliquer sa propre politique. Ce reçu est une proposition opérationnelle de cette analyse, pas une norme déjà définie par la révision 00.

Le dossier est lisible, mais son silence ne l'est pas

Pour une équipe conformité, une archive « propre » est tentante. Le texte ne montre plus le numéro de compte. L'audio ne prononce plus le nom. Une signature est valide. Le dossier peut donc circuler.

Mais que doit comprendre un moteur d'analyse lorsqu'il rencontre trois secondes de silence ? Le silence appartenait-il à l'appel ? A-t-on retiré une phrase ? Le locuteur masqué était-il le client, un témoin ou l'agent ? Une valeur d'apparence normale a-t-elle remplacé l'original ? Sans signal structuré, le destinataire ne sait pas quelles inférences ont disparu et lesquelles sont devenues dangereuses.

draft-rosenberg-vcon-redaction-00, publié le 29 septembre 2026, donne un vocabulaire utile à ce problème. C'est un Internet-Draft individuel à statut visé Informational, destiné à la discussion. Il n'est ni RFC, ni texte adopté par le groupe de travail VCON, ni consensus IETF, ni preuve de déploiement.

Sa contribution décisive consiste à séparer des propriétés que l'on confond souvent : expurgation signalée ou non ; indication de la position ; indication du participant ; modification détectable ou indétectable ; retrait du contenu ou simple étiquetage laissant la donnée en place. Une même opération peut bien protéger l'identité et mal préserver la valeur probante.

Le noyau VCON conserve une lignée, pas une vérité

La révision 04 du noyau VCON prévoit qu'un objet redacted référence par UUID une version non expurgée ou moins expurgée. Il peut ajouter une URL à accès restreint et un hachage ; si l'URL est présente, le hachage est obligatoire. L'entité qui produit le dérivé devrait le signer. Lorsqu'un élément de tableau est entièrement supprimé, un emplacement vide est recommandé afin de ne pas déplacer les indices suivants.

Ces mécanismes répondent à des questions précises. Le hachage permet de constater que des octets référencés ont changé. La signature permet d'identifier l'auteur de l'assertion. L'UUID relie les versions. L'emplacement vide préserve certaines références.

Ils ne répondent pas à la question de conformité sémantique. Les méthodes d'expurgation du texte, de l'audio et de la vidéo sont volontairement hors du périmètre du noyau. Le signataire peut donc attester un dérivé sans démontrer qu'il a trouvé chaque information sensible. Une valeur conservée n'est pas exacte parce qu'elle est signée. Une valeur substituée n'est pas devenue une observation. Et la position vide peut elle-même révéler le moment d'une intervention ou l'identité probable d'un participant.

Le projet sur l'expurgation ouvre cette zone sans la fermer. Il décrit des exigences et esquisse des structures possibles ; il ne fournit pas encore un profil interopérable complet pour les localisateurs, les erreurs, la canonicalisation, l'autorisation et les conséquences en aval.

Chaque technique échange une preuve contre une autre

Supprimer l'objet de dialogue entier masque efficacement son contenu, mais efface aussi l'énoncé non sensible qui l'entourait. Les indices peuvent bouger, les références devenir fausses et la chronologie perdre une étape.

Conserver une coquille garde les participants, le début et la durée. L'auditeur voit qu'une intervention a eu lieu, mais le tour mixte—une demande légitime contenant un seul identifiant—disparaît dans son entier. La coquille protège le contexte structurel au prix du contexte sémantique.

Remplacer par XXX ou REDACTED rend l'intervention visible à beaucoup de lecteurs. Pourtant ce marqueur reste du contenu ordinaire. Il peut avoir été prononcé, varie selon la langue et n'indique pas précisément le type ni la portée de la modification.

Un remplacement plausible fait l'inverse : il protège l'original sans attirer l'attention. Un faux numéro de compte au bon format peut alors être lu comme une donnée source et déclencher un remboursement réel au mauvais endroit. La transformation la plus discrète est parfois la plus risquée pour l'action.

Enfin, l'étiquetage conserve la valeur sensible et délègue son masquage au destinataire autorisé. Il préserve davantage de preuve, mais déplace le contrôle vers chaque lecteur, exportateur et système de partage. Une étiquette ignorée n'est pas une expurgation.

La question opérationnelle n'est donc pas « le dossier est-il expurgé ? » mais « quelles affirmations cette version peut-elle encore porter, et auprès de quel destinataire ? »

Un reçu pour le passage entre deux réalités

Une version destinée à des décisions importantes devrait être accompagnée d'un reçu séparé et signé. Cette exigence est l'analyse de Daniel Kade, non le contenu normatif de la révision 00. Le reçu devrait engager l'identité et le hachage de la source et du dérivé, la version et la finalité de la politique, les emplacements exacts et la classe sémantique avant modification.

Pour chaque emplacement, il devrait nommer l'opération : retrait, coquille conservée, substitution visible, substitution plausible, étiquetage ou chiffrement. Il devrait dire si la position et le participant sont conservés ou supprimés, identifier le transformateur et le contexte de sa clé, dater l'opération et publier le résultat de résolution de chaque localisateur. Un seul localisateur non résolu doit interdire l'usage à conséquence.

RFC 6901 offre JSON Pointer pour adresser une position, mais laisse à l'application le traitement des erreurs. RFC 7515 fournit JWS pour l'intégrité et l'identité cryptographique. RFC 8785 stabilise la représentation JSON pour des engagements reproductibles. Aucun de ces outils ne prouve que la détection était complète ou que la valeur de remplacement est vraie.

Le reçu doit enfin exprimer l'interdit d'usage : aucune opération de paiement, aucun changement de compte ou de justificatif, aucune attribution juridique et aucun apprentissage de modèle à partir d'un substitut plausible sans revalidation autorisée. Si une action est quand même tentée, son propriétaire produit un reçu d'action séparé. L'enquête peut alors relier ce qui a été reçu, la règle appliquée et l'effet obtenu.

La signature ne fusionne pas les responsabilités

Le projet compagnon sur les conversations vérifiables d'agents rappelle qu'une signature valide établit le signataire, non la véracité du contenu. Il distingue l'exécution, l'enregistreur, le stockage, le vérificateur et le décideur. Cette séparation devient essentielle lorsque les VCON contiennent des invites, des entrées d'outils, des sorties, des identifiants ou des commandes capables d'agir.

La doctrine des couches de réalité de Lu Heng donne ici une règle simple. La conversation source est une observation. Le dérivé est une vue de confidentialité. Le reçu est une assertion sur le changement. L'action ultérieure constitue encore une autre réalité. La propreté visuelle et la validité cryptographique ne doivent jamais faire hériter automatiquement au dérivé l'autorité de la source.

Sources et limites

Le texte étudié est une première révision incomplète, avec des choix encore ouverts. Cette analyse n'évalue aucun centre d'appels, fournisseur de modèle, produit d'expurgation ou déploiement VCON. Elle ne conclut pas à la conformité juridique d'une technique particulière. L'article 5 du RGPD et le NIST SP 800-122 éclairent la tension entre minimisation, exactitude et protection ; ils ne consacrent pas le reçu proposé ici.