Skip to main content

Où vont vraiment vos données quand vous branchez un LLM ?

Olivier Lange

En dix-huit mois, l'IA générative est passée du POC au tissu opérationnel. Copilote de code, assistant SOC, résumé de réunions, fonctions « AI » activées par défaut dans la moitié de vos SaaS. L'intégration a été plus rapide que la cartographie — et c'est exactement là que se loge l'angle mort.

Le test des trente secondes

Posez cette question à votre équipe : « Quand notre copilote lit un ticket client, le traitement se produit où, physiquement — et sous quelle juridiction ? »

Dans la plupart des organisations, la réponse est un silence. Pas par négligence : parce que l'inférence IA n'apparaît sur aucun diagramme de flux de données. On a documenté les bases de données, les sauvegardes, les intégrations SaaS. Pas les prompts.

Chaque intégration IA est un transfert de données

Un appel LLM, c'est un prompt plus du contexte. Et le contexte, c'est vos données : extraits de code source, journaux d'incidents, contenus de tickets, renseignements personnels de clients, parfois des secrets qui traînent dans un log collé au prompt. Multipliez par le nombre d'appels quotidiens de chaque copilote, chaque assistant, chaque fonction « AI » cochée par défaut, et vous obtenez un flux d'egress continu — invisible parce que personne ne l'a jamais dessiné.

Ce n'est pas un flux anodin. C'est probablement le canal de sortie de données le moins gouverné de votre organisation.

« Chiffré en transit » n'est pas « souverain »

C'est la confusion la plus répandue. TLS protège le tuyau. À l'arrivée, le prompt est traité en clair par le point d'inférence du fournisseur. La vraie question n'est donc pas « le lien est-il chiffré ? » mais deux questions distinctes :

Où est le point d'inférence ? Un datacenter au Canada n'est pas un datacenter au Québec, et un endpoint « région Montréal » d'un hyperscaler n'est pas un fournisseur québécois.

Qui a autorité sur le fournisseur ? Le CLOUD Act permet aux autorités américaines de contraindre un fournisseur américain à remettre des données sous son contrôle, peu importe où elles sont physiquement stockées. Un datacenter canadien opéré par une entité américaine ne vous protège pas de la juridiction américaine. La localisation du disque et la localisation du pouvoir sont deux choses différentes.

Côté québécois, la Loi 25 exige une évaluation des facteurs relatifs à la vie privée (EFVP) avant de communiquer des renseignements personnels hors Québec — avec la conclusion que l'information bénéficiera d'une protection adéquate. Un prompt qui contient des renseignements personnels et part vers un endpoint d'inférence hors Québec, c'est une communication au sens de la loi. Elle est juste invisible dans vos processus, parce qu'elle passe par une clé API et non par un contrat de transfert.

La souveraineté comme contrainte d'architecture, pas comme case à cocher

Traiter ça en conformité — un registre, une politique, un audit annuel — ne fonctionne pas à la vitesse où les intégrations IA apparaissent. La seule approche qui tient dans le temps, c'est de faire de la souveraineté une contrainte d'architecture, au même titre que la haute disponibilité ou le moindre privilège. Trois exigences :

  1. Visibilité totale : aucun appel IA ne quitte l'organisation sans être vu.
  2. Routage par politique : c'est la classification de la donnée qui décide de la destination, pas le paramétrage par défaut d'un outil.
  3. Preuve : chaque appel laisse une trace attribuable — qui, quoi, vers où, à quel coût.

Le pattern : un point de contrôle unique pour toute l'IA

L'implémentation de ces trois exigences tient dans un pattern simple à énoncer et exigeant à tenir : tout appel IA de l'organisation passe par une passerelle unique. Aucune application, aucun script, aucun poste ne parle directement à un fournisseur d'IA. Zéro exception — c'est l'exception qui tue le modèle.

Ce que le point de passage unique rend possible :

  • Routage par politique : les données sensibles vont vers des backends souverains ; les tâches génériques peuvent aller vers des modèles de frontière si — et seulement si — la politique l'autorise explicitement.
  • Clés virtuelles par application, équipe ou usage : révocables, plafonnées, attribuables. Fini la clé API du fournisseur copiée dans douze dépôts.
  • Audit et coût par appel : vous savez enfin qui envoie quoi, où, et pour combien.
  • Un seul endroit à couper en cas d'incident ou de changement de politique.

Le pattern est réalisable avec des briques open source — c'est le pattern qui compte, pas le produit. Nous l'opérons quotidiennement en production, sous une doctrine sans contournement : la valeur du chokepoint est binaire. À 100 %, c'est un plan de contrôle. À 95 %, c'est un tableau de bord avec des angles morts.

Les compromis, honnêtement

La souveraineté de l'inférence a un prix, et le taire décrédibilise le discours. Un hop de plus, c'est de la latence. Les modèles souverains ou auto-hébergés accusent un écart de qualité sur certaines tâches face aux modèles de frontière — parfois négligeable, parfois pas. Opérer une passerelle, c'est de l'ingénierie en continu.

Et il y a le théâtre : si vos données clients vivent déjà dans trois SaaS américains, « souverainiser » uniquement le LLM est une ligne Maginot. La souveraineté se mesure sur la chaîne complète, ou elle n'est qu'un argument marketing. La cohérence prime sur la pureté d'un seul maillon.

Par où commencer lundi

  1. Inventorier. Chaque appel IA sortant, y compris les fonctions IA activées par défaut dans vos SaaS. C'est plus long qu'on pense — et c'est le livrable le plus rentable de l'exercice.
  2. Classifier. Quelles données partent dans quels prompts. Croisez avec vos obligations (Loi 25 en tête si des renseignements personnels sont en jeu).
  3. Contrôler. Imposez le point de passage unique, puis routez par politique. Dans cet ordre : on ne route pas ce qu'on ne voit pas.

La question n'est pas « pour ou contre l'IA ». Elle est : qui décide où vos données sont traitées — vous, ou le paramétrage par défaut de vos fournisseurs ?