Tous les articles
Fondamentaux6 min de lecture

Pourquoi le traitement côté navigateur protège vos données

Traitement « client-side » : quand les données ne quittent pas le navigateur, il n'y a rien à intercepter côté serveur. Le principe, ses limites, ses garanties.

Par Pierre de ONYRI

Le traitement côté navigateur (« client-side ») protège vos données parce qu'elles ne quittent jamais votre poste : la détection et le remplacement des données sensibles s'exécutent localement, en mémoire, sans transiter par un serveur. Il n'y a donc rien à intercepter, à logger ou à fuiter côté backend. C'est une garantie de conception (« privacy by design »), pas une simple promesse contractuelle.

Client-side vs server-side : où vit la donnée ?

Dans une architecture server-side, votre texte part vers un serveur qui le traite : il faut alors faire confiance à ce serveur (chiffrement, rétention, accès, juridiction). Dans une architecture client-side, le traitement a lieu dans votre navigateur : le serveur ne voit jamais la donnée brute. La différence est structurelle, pas seulement contractuelle.

  • Rien à intercepter : la donnée sensible n'est pas transmise.
  • Rien à logger : pas de contenu à conserver côté serveur.
  • Surface réduite : moins de composants exposés = moins de risques.
  • Vérifiable : le comportement réseau peut être observé (DevTools).

Le mapping reste local : la clé ne part pas

Quand on anonymise un prompt, la correspondance jeton ↔ valeur d'origine est la donnée la plus sensible. La maintenir en mémoire dans le navigateur — et ne jamais la transmettre — garantit que personne d'autre ne peut ré-identifier. C'est ce qui transforme une tokenisation en protection réelle.

Les limites à connaître

Le client-side protège la donnée tant qu'elle reste locale. Dès qu'un texte anonymisé est volontairement envoyé à un service IA, c'est ce texte (sans PII) qui transite — pas le mapping. L'enjeu devient alors la qualité de la détection : ce qui n'est pas détecté n'est pas anonymisé. D'où l'importance d'une couverture large et adaptée au contexte.

Le moteur d'ONYRI Sanitize tourne à 100 % dans le navigateur : le mapping jeton ↔ valeur ne transite jamais vers le backend. Seul le texte déjà anonymisé peut, de façon opt-in, partir vers un modèle IA.

Questions fréquentes

Client-side, ça veut dire « sans serveur » ?
Non : un serveur peut exister pour le compte, les réglages ou un proxy IA. Mais le traitement des données sensibles (détection, mapping, restauration) reste dans le navigateur et n'est pas transmis.
Comment vérifier que rien ne part ?
Les outils de développement du navigateur (onglet Réseau) permettent d'observer les requêtes : sur une page qui traite vos données en local, vous ne devez voir partir aucun contenu sensible.
Le client-side suffit-il à lui seul ?
Il protège la donnée tant qu'elle reste locale. La protection dépend ensuite de la qualité de la détection : ce qui n'est pas détecté ne sera pas anonymisé avant un envoi volontaire.

Sources et références

Gardez vos données sensibles dans votre navigateur

ONYRI Sanitize détecte et masque vos données sensibles avant l'envoi à l'IA, puis restaure la réponse — du nom à la clé API.

Anonymiser mon prompt

À lire aussi