L'IA sans exposer vos données

Le risque réel n'est pas celui qu'on croit

Quand on parle de sécurité et d'IA, on imagine des attaques sophistiquées. La réalité est plus banale : la fuite passe par l'usage quotidien. Un commercial qui colle un contrat dans un chatbot grand public. Un développeur qui envoie un extrait de base de données « pour déboguer ». Une équipe qui adopte un outil IA gratuit sans validation — la fameuse shadow AI.

Chacun de ces gestes envoie des données potentiellement sensibles vers des serveurs tiers, sous des conditions d'utilisation que personne n'a lues — parfois avec un droit d'entraînement sur vos contenus.

Avant tout : savoir ce qui est vraiment sensible

« Données sensibles » est une expression piège : tout n'a pas la même valeur ni le même régime juridique, et traiter tout au même niveau coûte cher pour rien. En pratique, trois niveaux suffisent pour démarrer :

• Public ou inoffensif : documentation produit, contenus marketing, code open source. Un outil grand public peut les traiter — c'est même le bon terrain d'apprentissage pour les équipes.
• Confidentiel métier : contrats, devis, code propriétaire, données clients non personnelles. Ne sort que vers des services sous contrat (DPA, non-entraînement, rétention limitée) — jamais vers un compte gratuit.
• Critique ou réglementé : données personnelles, santé, paie, secrets industriels. Périmètre maîtrisé obligatoire : hébergement choisi, accès par rôle, journalisation — et souvent pseudonymisation avant tout appel à un modèle.

Cette cartographie a une vertu cachée : elle débloque les usages au lieu de les freiner. Une fois le niveau 1 clairement délimité, les équipes peuvent utiliser l'IA sereinement dessus — et la tentation de contourner les règles chute.

Trois questions à poser avant d'adopter un outil IA

• Où vont les données ? Quel hébergement, quelle juridiction, quelle durée de rétention ?
• Servent-elles à entraîner des modèles ? Si la réponse n'est pas un non contractuel, considérez que c'est oui.
• Qui y a accès ? Côté fournisseur comme côté interne — quels rôles, quels journaux d'accès ?

Vos données restent les vôtres — ou elles deviennent celles de quelqu'un d'autre.

Les parades concrètes

Héberger l'IA chez vous (ou presque)

Les modèles open-weight (Mistral, Llama, Qwen…) se déploient aujourd'hui dans votre environnement — cloud européen, voire infrastructure interne. Performances très honorables, données qui ne sortent jamais.

Un RAG local plutôt qu'un chatbot public

Brancher l'IA sur vos documents via un socle maîtrisé (recherche locale, sources citées, contrôle d'accès par rôle) donne des réponses plus justes et plus sûres : la donnée reste dans votre périmètre, chaque consultation est tracée.

Une gouvernance simple et tenue

Une charte d'usage claire, des outils validés et accessibles (la shadow AI prospère quand l'alternative officielle est inexistante), des garde-fous techniques — filtrage des données sensibles, journal d'audit — et la conformité RGPD pensée dès la conception.

À quoi ressemble un socle maîtrisé

Concrètement, l'architecture qui permet de profiter de l'IA sans s'exposer tient en cinq briques — c'est le schéma que nous déployons, quelle que soit la taille de l'entreprise :

• Une porte d'entrée unique : tous les appels aux modèles passent par une passerelle interne — un seul endroit où appliquer les règles, au lieu de dix outils dans la nature.
• Un filtre avant envoi : détection et pseudonymisation des identifiants (noms, emails, numéros) avant que le prompt ne quitte votre périmètre, quand ils ne servent pas la tâche.
• Une récupération périmétrée : le RAG ne cherche que dans les documents auxquels l'utilisateur a déjà droit — l'IA n'est jamais un moyen de contourner les permissions.
• Un journal complet : qui a demandé quoi, quelles sources ont servi, quelle réponse est sortie. Indispensable pour auditer, et pour répondre si une personne exerce ses droits.
• Des modèles interchangeables : API sous contrat aujourd'hui, open-weight chez vous demain — l'architecture ne doit pas épouser un fournisseur.

Aucune de ces briques n'est exotique. Ce qui est rare, c'est de les poser avant le premier incident plutôt qu'après.

RGPD et IA : les réflexes minimaux

Sans transformer cet article en consultation juridique — pour ça, votre DPO ou un avocat —, quelques réflexes de conception évitent l'essentiel des mauvaises surprises quand un traitement IA touche des données personnelles :

• Minimiser ce qui entre dans le prompt : pseudonymiser ou filtrer les identifiants (noms, emails, numéros) avant l'appel au modèle quand ils ne sont pas nécessaires à la tâche.
• Documenter le traitement : quel outil, quelles données, quelle finalité, quelle durée — le registre des traitements doit refléter vos usages IA réels, pas ceux d'il y a deux ans.
• Encadrer le fournisseur : contrat de sous-traitance (DPA), localisation des données, engagement de non-entraînement — des clauses qui se vérifient avant la signature, pas après l'incident.
• Tracer pour pouvoir répondre : si une personne exerce ses droits, il faut savoir où sa donnée est passée. Un socle qui journalise chaque consultation rend cette réponse possible.

C'est exactement la philosophie du Cœur IA d'entreprise : vos données, votre socle, vos règles — et notre engagement de process : aucune donnée envoyée vers des API tierces sans votre accord. Et si vous voulez savoir où vous en êtes aujourd'hui, un audit sécurité dresse l'état des lieux, usages IA compris.