Canonicalisation d'intention & registre à deux plans

1.Problème

Il existe un écart irréductible entre ce qu'un opérateur exprime et ce qui constitue l'information utile. Un opérateur pressé peut formuler une demande en registre familier, incomplet ou ambigu (ex. « ouvre un compte pour Mme X, cheffe du service Médecine, donne-lui les droits qui vont bien, c'est urgent »). Or :

• la forme (ton, vulgarité, fautes) n'a aucune valeur probante ;
• le fond (créer un compte, bénéficiaire, fonction, droits, urgence) est la seule information à tracer fidèlement ;
• certaines parties du fond sont ambiguës et ne doivent pas être résolues silencieusement par la machine.

Une plateforme pour CHU doit produire un rendu professionnel, pédagogique et explicatif de bout en bout, sans jamais falsifier la réalité.

2.Énoncé du principe

La falsification (réécriture du fond, masquage, embellissement faisant paraître une action plus correcte qu'elle ne fut) est proscrite et constituerait un faux (art. 441-1 du code pénal) invalidant toute certification.

3.Les deux plans

3.1 Plan d'interaction

Capture l'entrée brute exactement comme saisie, horodatée, attribuée. C'est un log technique qui contient des données personnelles → traitement RGPD (finalité, base légale, minimisation, durée bornée, accès restreint). N'est jamais diffusé dans un livrable.

3.2 Plan probant

Contient l'intention canonique, l'approbation, l'exécution et son résultat. Professionnel par construction — ne contient jamais le registre familier, non parce qu'on l'a caché, mais parce qu'il n'était pas probant. Inaltérable : chaîné SHA-256, signé, horodaté (RFC 3161), ancré, stocké en WORM.

4.La couche de canonicalisation

Interposée entre la saisie et l'action, en quatre opérations :

1. Normaliser la forme — neutralise ton, vulgarité, fautes (bruit sans valeur probante).
2. Expliciter l'implicite — « les droits qui vont bien » → « profil d'accès du rôle Chef de service Médecine ».
3. Confirmer le matériel — tout élément de fond non trivial est présenté à l'humain pour validation. La machine ne résout jamais silencieusement une ambiguïté de fond.
4. Tracer le canonique — l'intention confirmée est écrite au plan probant, liée par hash à son entrée brute.

INTENTION    ─ Création d'un compte utilisateur standard
Bénéficiaire ─ Mme Michoux
Fonction     ─ Chef du service Médecine  (déclarée)
Droits       ─ Profil d'accès du rôle « Chef de service Médecine »
               ⚠ à confirmer : périmètre exact des droits
Priorité     ─ Urgente
→ Confirmez-vous cette intention ?  [Oui / Ajuster]

L'autorité du document vient de l'approbation humaine + la traçabilité à l'origine, pas de son éloquence. La confirmation protège l'opérateur : la trace prouve qu'il a validé l'interprétation.

5.Le hash de liaison

Chaque intention canonique porte une référence cryptographique vers l'entrée brute qui l'a engendrée :

• sha256 = empreinte SHA-256 du texte brut (UTF-8 normalisé NFC), calculée à l'ingestion ;
• le plan probant ne stocke que l'empreinte, jamais le texte brut → livrable professionnel et fidélité vérifiable ;
• vérification : on relit l'entrée brute, recalcule le SHA-256, compare à celui scellé. Identité ⇒ le brut n'a pas été altéré ;
• si le brut a été purgé (rétention), l'empreinte demeure comme preuve d'existence (conforme à la minimisation).

6.Politique de rétention & accès

Durées exactes arrêtées au registre des traitements (RGPD art. 30) et au plan de classification/rétention du SMSI.

7.Cartographie normative

8.Ligne rouge (anti-falsification)

9.Conséquences

• À construire : la couche de canonicalisation (4 opérations), le champ source_interaction au plan probant, la politique de rétention du plan d'interaction (avec le DPO).
• Déjà acquis : le plan probant (audit chaîné SHA-256), la confirmation humaine (gouvernance 3 modes + approbation nominative), le RBAC.
• À arrêter au SMSI : durées de rétention, bases légales, matrice d'accès, inscription au registre RGPD art. 30.