Aller au contenu
CLEVYA Docs

Souveraineté des données

Le principe fondateur

CLEVYA est bâtie sur une règle simple : les identifiants directs sensibles connus (noms, montants, IBAN) ne quittent jamais votre serveur. Avant qu’une requête parte vers un modèle de langage, ces éléments sont remplacés en local par des jetons cohérents et typés. La table de correspondance jeton vers valeur réelle reste sur votre infrastructure ; la retranscription de la réponse se fait également en local.

C’est ce qui distingue CLEVYA d’un appel direct à un assistant cloud : avec un assistant classique, votre texte réel transite chez le fournisseur. Avec CLEVYA, ce qui transite, c’est une version anonymisée dont les valeurs sensibles ont été substituées.

La formulation honnête

Nous ne disons pas « le réel ne quitte JAMAIS le serveur » au sens absolu - ce serait faux et un responsable technique le démonterait en une question. La formulation exacte est :

Les identifiants directs sensibles connus (noms, montants, IBAN) ne quittent jamais le serveur, et toute valeur réelle connue qui resterait est bloquée avant l’envoi. Pour le secret non typable, un mode 100 % local (Ollama) garde la donnée sur place.

Ce qui part réellement au modèle

Pour une note RH typique, le contenu envoyé au modèle ressemble à ceci :

Reste local (jamais envoyé)Ce qui part au modèle
Sophie Marchand[PERSONNE_1]
salaire 48000salaire [SALAIRE_1]
IBAN FR76 3000…[IBAN_1]
Responsable paieResponsable paie (en clair)
demande d’augmentationdemande d’augmentation (en clair)

Partent réellement : les jetons typés et cohérents, la structure relationnelle (« [PERSONNE_1] gère le dossier de [PERSONNE_2] ») et le contexte jugé non sensible laissé en clair (poste, nature de la demande). Ne partent pas : aucun nom réel, aucun montant réel, aucun IBAN réel.

Les limites à connaître

Deux limites réelles, que nous posons nous-mêmes plutôt que de les laisser découvrir :

  1. Re-identification par quasi-identifiants. Le contexte non sensible laissé en clair (poste
    • lieu + événement rare) peut, sur un petit effectif, désigner une seule personne. C’est de l’anonymat insuffisant (k-anonymat), pas une fuite de valeur brute, mais c’est un risque réel.
  2. Donnée sensible non typée et inconnue du référentiel. Un nom de projet interne, une référence produit maison ou une clause de contrat ne sont reconnus ni par la détection d’entités (entraînée sur personnes, lieux, organisations) ni par le contrôle de référentiel.

Réponse produit aux deux : le mode 100 % local (Ollama) pour le secret non typable - la donnée ne part alors nulle part.

Pour aller plus loin