> ## Content Index
> Fetch the complete content index at: https://jppoisson.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# IA et consulting : la confidentialité n’est pas un paramètre, c’est une architecture.
- URL: https://jppoisson.com/ligne-de-fracture/confidentialite-architecture/
- Published: 2026-04-20T11:28:19.000Z
- Updated: 2026-08-26T22:37:07.000Z
- Description: Dans le conseil, le débat sur l’IA est souvent mal posé. On parle de productivité, de copilots, de knowledge search, de RAG, de génération de decks, de vitesse d’exécution.
- Author: Jean-Philippe Poisson
- Tags: Preuve, #ligne-de-fracture

Dans le conseil, le débat sur l’IA est souvent mal posé.

On parle de productivité, de copilots, de knowledge search, de RAG, de génération de decks, de vitesse d’exécution.

On parle beaucoup moins de la vraie question : que devient l’information une fois qu’elle entre dans le système ?

Or les signaux publics récents sont assez clairs pour qu’on cesse de traiter ce sujet comme une simple note de bas de page.

Le cas McKinsey / Lilli a rappelé une première vérité : même un outil interne, conçu pour un usage professionnel, peut devenir un problème majeur de confidentialité si l’architecture applicative autour du modèle est défaillante. CodeWall a affirmé avoir obtenu un accès lecture/écriture à la base de production de Lilli. McKinsey a confirmé l’existence d’une vulnérabilité, indiqué l’avoir corrigée “within hours”, et déclaré n’avoir trouvé aucune preuve que des données client ou informations confidentielles client aient été consultées par le chercheur ou par tout autre tiers non autorisé. Même sans trancher publiquement toute la portée de l’exposition, le message est simple : un système IA concentre dans un même environnement des conversations, des fichiers et des prompts système, avec des couches d’indexation, de recherche et de contrôle d’accès autour du modèle. Le risque ne vient pas seulement du modèle. Il vient de tout ce qui l’entoure

L’affaire U.S. v. Heppner montre l’autre face du problème. Ici, il n’est pas question de faille technique, mais de confidentialité juridique. Dans son memorandum du 17 février 2026, qui formalise sa bench ruling du 10 février, le juge Rakoff a conclu que les documents générés par Heppner avec Claude n’étaient protégés ni par l’attorney-client privilege (secret des échanges avec l’avocat) ni par la work-product doctrine. La motivation du tribunal ne tient pas seulement à la privacy policy d’Anthropic : la cour relève aussi que Claude n’est pas un avocat, que Heppner n’avait pas "d’attente raisonnable de confidentialité" dans ses échanges avec la plateforme, et que ces documents n’avaient pas été préparés à la demande du conseil. Pour les métiers du conseil, la leçon reste forte : le fait qu’un échange ressemble à un brouillon de travail ne lui donne pas automatiquement un statut protégé.

Le précédent Samsung reste, lui, le meilleur rappel du risque le plus banal et le plus fréquent : le copier-coller. Bloomberg a rapporté en mai 2023 que Samsung avait interdit à ses salariés l’usage de certains outils génératifs sur les appareils et réseaux de l’entreprise après la remontée de cas d’upload de code sensible dans ChatGPT. C’est un cas important parce qu’il ne parle ni d’attaque sophistiquée, ni d’architecture complexe. Il parle de la réalité quotidienne : un professionnel pressé, compétent, bien intentionné, qui colle un contenu sensible dans le mauvais environnement.

L’incident ChatGPT de mars 2023 a montré un autre angle mort. OpenAI a expliqué qu’un bug dans une bibliothèque open source avait permis à certains utilisateurs de voir des titres d’historique d’autres utilisateurs. Là aussi, la leçon dépasse le cas lui-même : la confidentialité d’un système IA dépend aussi des caches, des sessions, des bibliothèques, de la couche produit, pas uniquement des CGU ou du modèle sous-jacent.

Le point commun de ces affaires est simple : la confidentialité dans l’usage de l’IA n’est pas une propriété naturelle de l’outil. C’est une propriété du système.

## Le droit pousse dans la même direction

Le cadre juridique ne dit pas “n’utilisez pas l’IA”. En revanche, il rend de plus en plus difficile l’idée qu’on pourrait l’utiliser sans se poser sérieusement la question de la confidentialité.

Le RGPD impose un cadre de minimisation, de limitation des finalités, d’intégrité et de confidentialité pour les données personnelles.

L’AI Act est entré en vigueur le 1er août 2024, certaines obligations s’appliquent depuis le 2 février 2025, celles concernant les fournisseurs de modèles d’IA à usage général depuis le 2 août 2025, et le règlement sera pleinement applicable à partir du 2 août 2026.

Enfin, la directive européenne sur le secret des affaires protège les informations non divulguées qui tirent précisément leur valeur du fait de rester secrètes.

Pour les métiers du conseil, cela veut dire qu’une mauvaise gouvernance de l’IA n’expose pas seulement à un risque de privacy, mais aussi à un risque de non-conformité, de contentieux et de perte d’actifs informationnels.

## Ce que cela veut dire pour les cabinets… et pour les indépendants

C’est là que je crois qu’il faut éviter un discours trop binaire.

Tout le monde n’a pas une équipe sécurité, un DPO, un stack enterprise, une région dédiée ou un budget pour déployer une architecture complète. Beaucoup de professionnels du conseil travaillent seuls, ou en petite structure, et utilisent des outils grand public parce qu’ils sont accessibles, puissants et immédiatement utiles.

Le sujet n’est donc pas de dire : “n’utilisez jamais l’IA grand public.” Le sujet est de dire : “n’utilisez pas n’importe quelle donnée, n’importe comment, dans n’importe quel contexte.”

Un consultant indépendant peut parfaitement utiliser de l’IA grand public pour :

- reformuler un texte déjà public,
- brainstormer une structure de proposition,
- améliorer un email commercial générique,
- préparer une check-list,
- synthétiser des notes non sensibles,
- ou tester des idées de formulation.

En revanche, dès qu’on entre dans des contenus de type :

- projet M&A,
- données RH,
- éléments contentieux,
- drafts contractuels,
- notes de board,
- documents clients non publics,
- pricing sensible,
- stratégie de négociation,
- due diligence,
- liste de salariés, fournisseurs ou clients,
- ou même hypothèses explicitement liées à un client identifiable,

on change de régime. Ce n’est plus un sujet de confort d’usage. C’est un sujet de maîtrise du risque.

## Une boîte à outils minimale pour les consultants indépendants

Tout le monde ne peut pas construire une architecture complète. Mais tout le monde peut mettre en place une discipline d’usage.

La première règle est simple : classer les usages avant de classer les outils.

Je trouve utile de raisonner en trois couleurs :

Vert : contenus publics, génériques, réutilisables, sans enjeu client direct. Exemples : structure d’un atelier, reformulation d’un post, plan d’entretien, trame de proposition standard.

Orange : contenus professionnels non publics mais encore faiblement sensibles. Exemples : notes internes, préparation d’entretien, synthèse de réunion non critique, première structuration d’idées. Ici, il faut déjà réduire les détails, éviter les noms, retirer les chiffres inutiles, et ne jamais coller un document brut si un extrait ou une reformulation suffit.

Rouge : tout ce qui est client-identifiable, juridiquement sensible, stratégiquement sensible, financièrement sensible, RH, contentieux, M&A, ou couvert par engagement de confidentialité. Là, la bonne règle n’est pas “soyez prudent”. La bonne règle est : ne pas envoyer en clair dans un outil grand public.

La deuxième règle est de séparer le contenu du contexte. Souvent, le contenu utile au raisonnement est moins sensible que le contexte qui l’entoure. On peut demander : “quels sont les risques typiques d’une carve-out en 100 jours ?” sans demander : “prépare un plan pour la carve-out de \[client\], avec les usines A, B, C et 2 300 personnes concernées”.

La troisième règle est de travailler avec des placeholders. Au lieu de coller un nom de client, un nom de cible, un prix, une date ou une ville, remplace-les par : \[CLIENT\], \[TARGET\], \[PRICE\], \[COUNTRY\], \[DATE\], \[COUNTERPARTY\]. La table de correspondance reste chez toi, dans tes notes locales, pas dans l’outil.

La quatrième règle est de ne jamais coller un document entier quand une abstraction suffit. Dans beaucoup de cas, tu n’as pas besoin d’envoyer le contrat, la note ou le deck. Tu peux d’abord en faire toi-même une abstraction de 10 lignes, puis demander à l’IA de t’aider sur cette abstraction.

La cinquième règle est de faire la distinction entre aide à la forme et aide au fond. Pour la forme (reformulation, ton, structure, variantes, titres), l’IA grand public est souvent très utile et relativement peu risquée. Pour le fond (analyse d’une situation client, arbitrage stratégique, matière sensible, synthèse d’éléments confidentiels), le niveau d’exigence doit monter immédiatement.

La sixième règle est de tenir une ligne rouge claire : si tu ne serais pas à l’aise à l’idée de transférer le prompt exact par email à ton client, à son juriste, ou à un auditeur, il ne devrait probablement pas partir tel quel dans un outil grand public.

Enfin, la septième règle est de garder une mémoire locale des éléments sensibles. L’IA peut t’aider à penser. Mais la table de correspondance, les noms réels, les montants exacts, les séquences clients et les documents sources doivent rester dans ton propre environnement de travail.

Ce n’est pas une architecture parfaite. Mais c’est déjà une vraie hygiène de confidentialité.

## Et pour les cabinets de conseil ?

À ce stade, beaucoup de cabinets opposeront une objection légitime : nous ne sommes pas dans un usage naïf de l’IA. Nous avons un DPA, parfois des garanties de rétention très limitées, voire de zero data retention, et, dans certains cas, nous pouvons aller vers des solutions plus maîtrisées sur le plan de la résidence ou de la juridiction, par exemple une offre business avec garanties renforcées, ou un déploiement dédié d’un modèle sur infrastructure européenne.

C’est vrai. Et il faut le dire clairement : ces briques comptent. Un DPA améliore le cadre contractuel et la répartition des responsabilités. Des politiques de rétention réduite, voire de zero data retention dans certains cas éligibles, abaissent le risque de persistance côté fournisseur. OpenAI indique supporter la signature d’un DPA pour ses usages business et son API, et proposer des contrôles de rétention, y compris une option de zero data retention pour certaines organisations éligibles sur l’API platform.

Des déploiements plus souverains ou plus dédiés peuvent aussi mieux répondre à des contraintes de résidence, de juridiction et de maîtrise de l’infrastructure. Mistral publie un Data Processing Addendum dans son Legal Center. Et OVHcloud a publié une reference architecture décrivant le déploiement de Mistral Large 123B dans un environnement présenté comme souverain et hébergé en Europe, autrement dit, un déploiement maîtrisé de bout en bout, et non le simple appel à une API standard.

Mais aucune de ces briques, à elle seule, n’épuise le sujet. Un DPA traite une partie du cadre juridique, il ne dit pas, à lui seul, comment circulent les données entre vos modules, vos connecteurs, vos batchs, vos logs, vos outils annexes et vos workflows de reprise. Le zero data retention réduit un risque important, mais il ne répond pas automatiquement à toutes les questions de journaux applicatifs, de caches, d’artefacts intermédiaires, d’indexations, de prompts système, de connecteurs ou de copies secondaires. Et une solution plus souveraine ou hébergée en Europe améliore fortement la position de départ, sans rendre pour autant l’architecture saine par magie. Cette dernière reste à concevoir, gouverner et auditer.

Autrement dit : DPA, ZDR et souveraineté sont des prérequis utiles ou des accélérateurs sérieux. Ils ne remplacent pas une architecture de confidentialité. Ils la rendent plus crédible, ils ne la rendent pas inutile.

## Pour une firme de conseil, la confidentialité n’est plus seulement une question de politique d’usage. Elle devient un sujet d’architecture critique.

Pourquoi ? Parce qu’à mesure qu’on passe d’un simple assistant conversationnel à des systèmes plus “agentic” (avec outils, mémoire, étapes intermédiaires, enrichissement documentaire, workflows asynchrones, batchs, checkpoints et reprise), on multiplie les endroits où l’information sensible peut être copiée, routée, journalisée, enrichie, rechargée ou rejouée. Le risque ne porte plus seulement sur la requête initiale. Il porte sur toute la chaîne d’exécution. Les flux sensibles ne passent plus seulement par l’appel principal au modèle, mais aussi par les enrichissements, les batchs, les backfills, les sidecars, les exceptions et les chemins de secours.

La première exigence, pour une firme, est donc de traiter le chemin d’egress LLM comme une infrastructure critique. Autrement dit : on ne “branche” pas un modèle sur des flux métier comme on branche une API de commodité. On définit un point de passage unique, gouverné, observable, et capable d’appliquer les mêmes règles à tous les appels. C’est précisément la logique du gateway : conserver un seul contrat d’appel, puis décider en interne du provider, de la région, des headers, des retries, des traductions de payload et des règles de sécurité, plutôt que de laisser chaque module parler directement à un fournisseur différent.

La deuxième exigence est de rendre la résidence explicite, traçable et fail-closed. Dans beaucoup d’organisations, la résidence reste implicite : elle dépend d’un environnement, d’une convention ou d’un paramétrage global. Dans un cabinet de conseil, cela ne suffit pas. Il faut pouvoir dire, pour un client, un engagement ou un run donné : quel provider a été utilisé, dans quelle région, avec quel fallback, et selon quelle règle. Il faut éviter les defaults silencieux, éviter les “residency traps”, et préférer des valeurs nulles qui forcent une résolution explicite plutôt qu’un faux sentiment de conformité. L’objectif n’est pas d’avoir “en moyenne” une bonne résidence, c’est de pouvoir démontrer, cas par cas, la route réellement prise par les données.

La troisième exigence, dans des environnements plus agentiques, est de figer le routage au bon niveau temporel. C’est un point très fin, mais central. Dans un système avec missions longues, pause/reprise, checkpoints, backfills et runs multiples, il ne suffit pas de stocker un paramètre “provider” quelque part. Il faut se demander à quel moment il est gelé. Sinon, on crée un risque de “partial residency” : la première partie d’une mission part vers un fournisseur, la reprise ou la suite part vers un autre, et l’on se retrouve avec une même mission éclatée entre plusieurs régimes de confidentialité. c’est le risque de mid-mission cutover drift : tant qu’on ne snapshotte pas correctement provider/région au bon niveau, une bascule en cours de mission peut devenir un incident de conformité presque invisible.

La quatrième exigence est de traiter les prompts, chats, pièces jointes, system prompts, logs, batch payloads et vector stores comme des actifs sensibles à part entière. Pas comme des sous-produits techniques. Pas comme des “métadonnées”. Pas comme du bruit de fond. C’est l’un des grands enseignements communs de Lilli, DeepSeek et, dans un autre registre, des environnements RAG modernes : la matière la plus sensible n’est pas toujours dans le document source, elle peut être dans l’instruction, dans l’index, dans la mémoire, dans la trace de décision, dans le système prompt, ou dans un payload de batch “temporaire” qui restera plus longtemps que prévu. Il arrive que certains batchs censés être secondaires emportent en réalité du contenu client substantiel, et qu’ils peuvent contourner la couche de redaction s’ils ne repassent pas par le même point de contrôle.

La cinquième exigence est de penser les flux secondaires avec la même rigueur que le flux principal. C’est souvent là que les architectures se dégradent. L’appel principal est bien gouverné, mais les chemins annexes ne le sont pas : batch de post-qualité, enrichment, connecteurs, scripts de backfill, workflows n8n, GitHub Actions, sidecars, export vers BigQuery ou GCS, etc. Or, du point de vue de la confidentialité, ces chemins “annexes” comptent autant que le reste dès lors qu’ils emportent de la matière client. La vraie maturité n’est pas seulement d’avoir sécurisé le chat principal, mais d’avoir recensé et contrôlé toutes les sorties, y compris celles qui paraissent périphériques.

La sixième exigence est de repositionner la redaction au bon endroit dans la pile. Dans beaucoup d’organisations, l’anonymisation devient la rustine qui permet de continuer à utiliser une architecture non conçue pour la confidentialité. C’est pratique, mais intellectuellement fragile. Mieux : la redaction ne doit pas être la justification principale d’un flux discutable ; elle doit être une couche complémentaire, utile notamment pour certains clients, certains outils externes, certains cas de recherche ou certains garde-fous secondaires. C’est exactement ce que dit le plan quand il cherche à faire de Presidio une defense-in-depth plutôt qu’une primary compliance gate.

Enfin, la septième exigence est l’observabilité. Une firme sérieuse doit être capable de voir ce qui se passe, pas seulement de l’espérer. Cela veut dire journaliser le provider utilisé, la région, les fallbacks, les erreurs d’egress, les retries, les écarts de qualité, les chemins batch et les effets de bord des migrations. Sans cela, une régression reste invisible jusqu’au moment où elle devient un incident client ou un sujet d’audit. Ton plan va dans ce sens quand il ajoute des dimensions d’observabilité comme egress\_provider dans les traces de décision, précisément pour éviter qu’une régression spécifique à un provider soit noyée dans le bruit général.

En pratique, cela veut dire qu’une firme de conseil mature ne devrait plus se contenter de demander : “Avons-nous une offre enterprise ?”

Elle devrait se demander : avons-nous un point de sortie unique ? pouvons-nous imposer une région explicitement ? snapshottons-nous le bon niveau de contexte pour éviter les dérives en cours de mission ? gouvernons-nous aussi les batchs, backfills, connecteurs et workflows annexes ? traitons-nous prompts, logs et index comme des actifs classifiés ? pouvons-nous prouver, a posteriori, la route réellement prise par une donnée sensible ?

C’est là que la confidentialité cesse d’être un sujet de doctrine pour devenir un sujet de système.

Pour les indépendants, la confidentialité dans l’usage de l’IA commence par une discipline : minimiser, abstraire, pseudonymiser, séparer le contexte du contenu et garder une ligne rouge claire sur ce qui ne part jamais dans un outil standard.

Pour les firms, elle commence plus loin : dans le design même du système.

La confidentialité dans l’usage de l’IA n’est pas une propriété naturelle de l’outil. C’est une propriété du système.

Et plus l’environnement devient agentique, plus cette phrase cesse d’être théorique.