L'IA que vous n'avez pas choisie

La mise à jour que personne n’a lue

Quelque part en France, un administrateur système ouvre ses logs un matin de juillet 2026. Il y a deux mois, il avait désactivé Microsoft 365 Copilot sur les postes de son organisation : trop de questions sans réponse sur les données, pas assez de temps pour construire le cadre de gouvernance nécessaire. Décision prudente, documentée, validée par sa direction.

Ce matin, Copilot est de nouveau actif. Une mise à jour automatique l’a réinstallé. Aucun ticket d’incident. Aucune demande de la direction. Aucune notification préalable.

Cette scène n’est pas hypothétique. Selon pausehardware.com, Microsoft a réintégré Copilot dans Windows 11 via les mises à jour Office au printemps 2026, après l’avoir temporairement retiré suite aux critiques des administrateurs. Hors de l’Espace Économique Européen, le déploiement se fait sans avertissement préalable. En Europe, les obligations du RGPD créent une friction supplémentaire. Mais les paramètres de désactivation restent volontairement dispersés dans des menus que peu d’administrateurs connaissent.

L’article précédent de cette série parlait de l’IA que vos équipes utilisent, avec ou sans politique, avec ou sans autorisation. Cet article parle d’autre chose : l’IA que personne n’a décidé d’utiliser. Celle qui entre par les mises à jour, par les CGU dont la portée a silencieusement évolué, par les fonctionnalités activées par défaut dans des outils payés depuis des années. Celle que votre politique d’usage, aussi bien construite soit-elle, ne couvre probablement pas.

---

Quatre vecteurs, un angle mort commun

L’IA implicite, cette IA que personne dans votre organisation n’a décidé d’installer ni d’utiliser, n’arrive pas par un seul canal. Elle emprunte quatre vecteurs distincts, chacun avec son profil de risque propre. Ce qui les unit : dans chaque cas, l’organisation a signé un contrat, payé une licence, déployé un outil. Elle pense contrôler ce qu’elle a acheté. Ce qu’elle ne sait pas toujours, c’est que l’outil a changé après la signature.

L’OS et la suite bureautique

Le cas Microsoft illustre un mécanisme que l’on pourrait appeler l’IA par défaut : une fonctionnalité qui s’installe sans décision, qui se réinstalle après désactivation, et dont la désactivation permanente requiert une expertise technique que la plupart des organisations ne possèdent pas.

Ce n’est pas seulement une question d’intrusion. C’est une question d’exposition. Selon des propos rapportés par ia-info.fr d’après la conférence Gartner de Sydney de mars 2026, en moyenne 10% des données Microsoft 365 d’une organisation sont accessibles par l’ensemble de ses employés : conséquence d’années de gestion des droits d’accès sans possibilité d’un audit systématique et régulier. Des dossiers partagés jamais nettoyés, des droits accordés pour un projet et jamais révoqués, des permissions héritées de postes antérieurs. Copilot ne crée pas ce problème. Il le rend exploitable en un prompt.

La vulnérabilité CVE-2025-32711, documentée en mars 2025 et connue sous le nom EchoLeak, a illustré cette logique de façon concrète : selon les analyses publiées par les chercheurs en sécurité, une faille dans le plugin Copilot permettait l’exfiltration automatique de données via un simple email malveillant, sans action de l’utilisateur. Plus un outil IA mémorise de contexte pour être utile, plus sa surface d’attaque s’élargit, indépendamment des engagements contractuels sur la confidentialité.

Depuis mars 2026, une fonctionnalité baptisée “flex routing” est activée par défaut pour les environnements Microsoft 365 créés après le 25 mars 2026 en Europe : selon blog.tixeo.com, en cas de pic de charge, les prompts et données contextuelles Copilot peuvent transiter hors de l’Union Européenne, même avec le paramètre EU Data Boundary activé. Ce point confirme ce que l’article précédent établissait : la résidence géographique des données n’est pas une garantie de leur confinement.

Le résultat de cette accumulation d’incertitudes est documenté : elon CoreView dans son rapport “2026 State of AI in Microsoft 365”, plus de la moitié des organisations ont dû revenir en arrière sur au moins une action automatisée par l’IA après qu’elle ait introduit un risque : dans la plupart des cas lié aux niveaux d’accès ou à des effets de bord inattendus, plutôt qu’à la capacité IA elle-même”. La prudence est là. La méthode pour l’exercer, par contre, se fait encore attendre.

Les SaaS métier

Si Microsoft est le vecteur le plus visible, les SaaS métier sont peut-être le plus insidieux parce que personne ne les surveille avec la même attention.

Le cas Salesforce est particulièrement instructif. Selon tython.co, qui a analysé le cas en détail, la clause autorisant l’utilisation des données clients pour entraîner des modèles IA prédictifs globaux figurait déjà dans le Main Services Agreement de Salesforce depuis au moins 2018, par conséquent bien avant l’essor de l’IA générative. Spring ‘26 a simplement rendu cette clause visible et désactivable via un toggle en libre-service dans l’interface Setup, là où les clients devaient auparavant soumettre un ticket de support. La réaction de la communauté Salesforce a été vive, comme le rapporte salesforceben.com. Non parce que la pratique était illégale, mais parce qu’elle était quasi invisible.

Ce qui rend ce cas particulièrement révélateur n’est pas la clause elle-même : c’est son invisibilité. Pendant des années, la plupart des clients ignoraient qu’elle existait, ou supposaient qu’elle ne s’appliquait pas à leur organisation. La portée pratique de ce que la clause autorisait a profondément évolué avec le développement des modèles IA, et cela sans que le texte contractuel change véritablement, et surtout : sans que les clients en soient informés. Salesforce précise que cet usage s’applique uniquement aux modèles IA prédictifs, et non aux fonctionnalités d’IA générative comme Agentforce. En outre, les données seraient anonymisées avant agrégation. Mais comme le note tython.co, “anonymisé et dé-identifié” est un spectre, pas une valeur binaire, et sa suffisance dépend de la nature des données concernées.

Il y a une deuxième dimension à ce cas qui dépasse la question de la confidentialité. Les éditeurs qui utilisent les données de leurs clients pour entraîner leurs modèles ne cherchent pas seulement à améliorer leur produit : ils construisent un actif dont la valeur est indépendante du logiciel lui-même. La donnée client devient une ressource exploitable séparément, susceptible de générer de la valeur bien au-delà de la relation contractuelle initiale. Ce n’est pas nécessairement de la malveillance. C’est une logique économique nouvelle, rendue possible par l’IA, et que les contrats signés avant 2020 ne pouvaient pas anticiper.

Sur le plan réglementaire, la stratégie de Salesforce illustre un espace que l’AI Act a laissé ouvert. En maintenant ses fonctionnalités dans la catégorie “risque limité” plutôt que “haut risque” (notamment via la distinction entre IA prédictive et IA générative), l’éditeur évite les obligations lourdes de l’Annexe III et peut s’appuyer sur le cadre contractuel préexistant. L’Article 111 de l’AI Act prévoit pourtant que toute “modification substantielle” d’un système IA existant impose une réévaluation de conformité. Mais la définition de ce qui constitue une modification “substantielle” a fait l’objet d’intenses discussions lors des négociations du texte. Le résultat : une frontière suffisamment floue pour permettre à des évolutions, pourtant assez significatives, de passer sous le seuil de réévaluation. C’est l’une des limites que plusieurs observateurs avaient identifiées avant même l’entrée en vigueur du règlement.

Atlassian suit une logique similaire. Selon stratokey.com, à partir d’août 2026, les métadonnées Jira et Confluence des clients Free et Standard seront utilisées pour entraîner les modèles IA d’Atlassian par défaut. Pour ces catégories de clients, l’opt-out sur les métadonnées n’est pas disponible. Seuls les clients Enterprise disposent des deux options (collecte des métadonnées et collecte des données applicatives) désactivées par défaut.

Selon un analyste de Gartner cité par saasmag.com, d’ici fin 2026, près de 70% des interactions IA des employés se produiront via des fonctionnalités intégrées dans des solutions SaaS existantes et non via des solutions purement dédiées à l’IA. La politique d’usage qui ne couvre que les outils explicitement identifiés comme “IA” est donc déjà en retard sur la réalité du terrain.

Le cas ServiceNow ajoute une dimension supplémentaire. Selon PYMNTS.com, l’éditeur a lancé en mai 2026 une couche tarifée baptisée Action Fabric, positionnée entre les agents IA externes et les données stockées dans sa plateforme. JPMorgan a décrit ce mécanisme publiquement comme “une taxe sur l’accès aux données que les clients possèdent déjà”. Le modèle est révélateur : non seulement les éditeurs utilisent les données clients pour améliorer leurs propres modèles, mais certains commencent à facturer l’accès à ces données lorsque des agents IA tiers cherchent à les exploiter. La donnée est devenue un actif à part entière.

Les outils de communication

Ce vecteur est peut-être celui qui expose le plus clairement l’écart entre ce que les organisations pensent autoriser et ce qu’elles autorisent réellement.

Les outils de transcription et résumé de réunion (Zoom AI, Teams Copilot, Google Meet Gemini, Otter.ai, Fireflies et leurs équivalents) traitent simultanément plusieurs catégories de données personnelles de nature très différente. Selon dpo-partage.fr, ces traitements incluent : la voix elle-même, potentiellement qualifiable de donnée biométrique ; le contenu des échanges, données personnelles ordinaires ; et l’analyse comportementale (ton, fréquence de prise de parole, détection d’émotions, niveau d’engagement). Cette dernière catégorie peut relever de l’article 9 du RGPD, qui impose une AIPD et, en France, une consultation préalable du Comité Social et Économique (CSE) avant tout déploiement.

Demander “êtes-vous d’accord pour être enregistré ?” en début de réunion ne vaut pas consentement éclairé pour l’ensemble de ces traitements. Ce consentement, au sens du RGPD, doit être libre, spécifique, éclairé et univoque sur chacune des finalités poursuivies. Or ces finalités sont à la fois nombreuses, techniquement complexes à décrire en temps réel, et évolutives : si l’éditeur de l’outil de réunion met à jour ses fonctionnalités IA, ou si le CRM dans lequel les résumés sont injectés intègre à son tour une couche d’analyse, le périmètre de ce qui a été “consenti” change sans que personne n’ait été consulté à nouveau.

L’affaire Brewer contre Otter.ai, déposée en août 2025 devant le tribunal fédéral du district nord de Californie, illustre une situation que le droit n’avait pas anticipée. Justin Brewer n’était pas utilisateur d’Otter.ai. Il n’avait aucun compte, aucune politique de confidentialité à accepter, donc aucune possibilité de refuser non plus. En février 2025, il a participé à un appel Zoom où un autre participant avait activé OtterPilot. Sa voix a été enregistrée, transcrite, et selon la plainte, utilisée pour entraîner les modèles de l’entreprise, cela sans qu’il en soit informé ni qu’il ait pu s’y opposer. Trois autres plaintes similaires ont été consolidées dans cette action collective. Selon tldv.io qui rapporte l’état de la procédure, l’audience sur la motion to dismiss était prévue pour mai 2026. A date, aucune décision au fond n’avait encore été rendue à la date de publication de cet article.

La CNIL a inscrit dans son programme de travail 2026 des travaux spécifiques sur l’analyse automatique des communications vocales, avec publication de recommandations attendue dans les prochains mois. Les entreprises doivent avoir en tête qu’il s’agit d’une fenêtre d’anticipation, pas d’une zone de tolérance.

Sur la question de la sécurité des communications, la réalité est d’ordre mathématique avant d’être contractuel. Le chiffrement de bout en bout (E2EE) repose sur un principe fondamental : seuls les endpoints (les participants) détiennent les clés de déchiffrement. Si un service IA centralisé peut accéder au flux audio pour le transcrire ou l’analyser, c’est nécessairement que ce flux lui parvient en clair. E2EE et traitement IA centralisé sont donc mutuellement exclusifs par construction cryptographique, non par choix de configuration. Sur Zoom, activer le chiffrement de bout en bout désactive les fonctionnalités IA : ce n’est pas une limitation arbitraire, c’est la conséquence logique de ce que signifie “chiffrement de bout en bout”. Les formulations parfois vagues des CGU sur ce point ont pour effet (intentionnel ou non) de laisser les utilisateurs imaginer une compatibilité qui est mathématiquement impossible.

La chaîne de sous-traitance

C’est le vecteur le moins visible, et potentiellement le plus difficile à gouverner.

Lorsqu’une organisation transmet des données à un partenaire (cabinet d’audit, sous-traitant RH, prestataire logistique) elle n’a généralement pas de visibilité sur les outils que ce partenaire utilise pour les traiter. Si ce partenaire utilise un SaaS avec IA embarquée, l’organisation cliente est exposée sans le savoir et sans avoir décidé quoi que ce soit. Et ce partenaire utilise lui-même, dans la plupart des cas, des logiciels tiers qu’il n’a pas nécessairement audités, avec leurs propres conditions d’utilisation et leurs propres clauses IA.

Le RGPD Article 28 impose une obligation théoriquement continue : lorsqu’un sous-traitant engage un autre sous-traitant, les mêmes obligations de protection des données s’appliquent par contrat, et si ce sous-traitant secondaire ne remplit pas ses obligations, le sous-traitant initial reste pleinement responsable devant le responsable du traitement.

La réalité des sanctions documente l’écart entre la théorie et la pratique. En décembre 2025, selon gdpr-expert.eu, la CNIL a condamné Mobius Solutions Ltd à un million d’euros d’amende pour avoir conservé une copie des données de plus de 46 millions d’utilisateurs de Deezer après la fin de leur relation contractuelle — données copiées par trois salariés sans que l’entreprise en soit informée. Plus tôt, une sanction de plusieurs centaines de milliers d’euros avait été infligée à une société pour avoir utilisé un sous-traitant qui avait lui-même fait appel à un autre sous-traitant sans l’autorisation écrite préalable du responsable du traitement.

Les deux rapports publiés par LayerX en 2025, basés sur de la télémétrie réelle d’entreprises de taille moyenne à grande, convergent sur un ordre de grandeur préoccupant : près des deux tiers des usages IA en entreprise passeraient par des comptes personnels non gérés, c’est-à-dire hors de tout système d’identity and access management organisationnel. Ce chiffre inclut aussi bien les outils IA explicites que les SaaS avec IA embarquée. Si ces données sont représentatives, ce phénomène est en train de passer d’un angle mort épisodique à une pratique structurellement généralisée, ce qui modifie profondément les hypothèses sur lesquelles repose toute politique de gouvernance.

---

Ce que le droit dit, et ce qu’il ne dit pas (encore)

Le cadre réglementaire couvre une partie du problème, mais une partie seulement.

Le RGPD s’applique dès lors que des données personnelles sont traitées, quel que soit le vecteur. La responsabilité de l’organisation ne disparaît pas parce qu’une fonctionnalité IA a été activée par un éditeur sans notification proactive. C’est au responsable du traitement d’identifier les traitements, de les documenter, et d’en assurer la conformité. Y compris quand ils résultent d’une mise à jour automatique.

L’AI Act ajoute une couche d’obligations pour les systèmes à haut risque au sens de l’Annexe III : documentation, supervision humaine, AIPD obligatoire. Les outils d’analyse comportementale des salariés ou les systèmes utilisés dans le recrutement entrent dans cette catégorie. Mais pour les fonctionnalités “risque limité” (résumés automatiques, suggestions, analytics) l’obligation se réduit à la transparence : informer l’utilisateur qu’une IA intervient, quelque part dans les conditions générales.

C’est là que se creuse un vide que le législateur n’a pas encore comblé, et dont il n’existe pas à ce jour de projet de texte dédié. Un éditeur peut légalement intégrer une fonctionnalité IA par défaut dans un produit existant, en s’appuyant sur une clause contractuelle signée des années avant que cette fonctionnalité existe, sans que cette évolution constitue juridiquement un “nouveau système” soumis à l’AI Act. C’est précisément ce que le cas Salesforce illustre : une clause quasi inchangée depuis 2018, dont la portée pratique a radicalement évolué avec les modèles IA actuels, sans que personne ne soit tenu de notifier quoi que ce soit.

Il y a pire encore. La mise à jour de sécurité qui inclut une nouvelle fonctionnalité IA place l’administrateur devant un choix qu’il n’aurait jamais dû avoir à faire : accepter la mise à jour (et l’IA qu’elle embarque) ou refuser la mise à jour (et la correction de sécurité qu’elle contient). Ce n’est pas de la liberté de choix. Le consentement donné sous cette contrainte n’a pas grand-chose de “libre et éclairé” au sens du RGPD. Dans tout autre secteur, conditionner une prestation de sécurité à l’acceptation de conditions nouvelles serait analysé très différemment par les tribunaux. Le numérique bénéficie encore d’une tolérance que sa maturité économique ne justifie plus vraiment.

La Commission Européenne n’a pas de réponse à ces questions dans ses chantiers législatifs actuels. C’est moins un oubli qu’un symptôme : le numérique avance plus vite que le droit ne peut le suivre, non pas parce que le législateur manque de volonté, mais parce que le rythme d’innovation structurelle du secteur est sans équivalent dans l’histoire économique récente. La régulation suit. Elle ne précède pas. Et l’écart entre les deux est, structurellement, en train de s’élargir.

---

Ce qu’une politique d’usage ne couvre pas, et comment l’étendre

La politique d’usage définie dans l’article précédent reste nécessaire. Elle n’est plus suffisante.

Gouverner l’IA implicite exige quatre démarches supplémentaires, chacune plus exigeante que la précédente.

Auditer le SaaS existant. Cartographier les fonctionnalités IA activées par défaut dans les outils déjà déployés. Cet inventaire n’existe dans presque aucune organisation. Selon waldosecurity.com, les fonctionnalités IA sont ajoutées aux SaaS à un rythme sans précédent, souvent sans notification proactive aux administrateurs. Ce recensement doit précéder toute politique, et il en est la condition de validité.

Revoir les clauses de traitement des données dans les contrats éditeurs. Une DSI moyenne gère entre 50 et 200 applications SaaS actives. Les conditions générales de chacune représentent plusieurs milliers de mots. Une revue centrée sur les clauses d’utilisation des données et d’entraînement des modèles représente une charge de travail considérable : plusieurs dizaines d’heures pour une revue initiale, à renouveler régulièrement puisque les pratiques évoluent. L’automatisation par des outils IA est une piste, mais elle suppose elle-même une supervision qualifiée sur un domaine juridique encore largement non stabilisé. Et elle ne résout pas le cas de figure le plus subtil : une clause contractuelle inchangée dont la portée a été transformée par l’évolution de la technologie. Comment un outil automatisé peut-il détecter un changement de sens sans changement de mots ?

Étendre les exigences aux sous-traitants. Exiger que les partenaires déclarent les outils IA utilisés pour traiter les données confiées. L’Article 28 du RGPD le justifie juridiquement. La difficulté pratique est réelle : un partenaire utilise lui-même des logiciels tiers qu’il n’a pas nécessairement audités, avec leurs propres conditions d’utilisation. La chaîne est longue, largement opaque, et la responsabilité finale reste portée par l’organisation au sommet de cette chaîne.

Surveiller les mises à jour. Les fonctionnalités IA ne sont pas figées au moment du déploiement. Un changelog mensuel des éditeurs majeurs est devenu, de fait, une lecture de conformité — avec la contrainte déjà signalée que ce changelog peut contenir simultanément une correction de sécurité critique et une nouvelle fonctionnalité IA. L’administrateur n’a pas toujours le choix de décomposer les deux.

---

Le périmètre qui se déplace

La gouvernance de l’IA en entreprise a un défaut de périmètre structurel. Elle commence au moment où quelqu’un décide d’utiliser un outil IA. L’IA, elle, ne commence pas à ce moment-là.

Elle est déjà dans Windows, dans Salesforce, dans Zoom, dans les outils de votre cabinet d’audit, et potentiellement dans les solutions utilisées par vos fournisseurs, votre logiciel de comptabilité, votre outil RH, votre plateforme de gestion de projets. Elle est arrivée par des mises à jour automatiques, par des clauses contractuelles dont la portée a parfois silencieusement évolué, par des partenaires qui n’ont pas lu leurs propres CGU. Elle avance plus vite que les organisations qui cherchent à la gouverner, plus vite que les régulateurs qui cherchent à la cadrer, plus vite que le droit qui cherche à la nommer.

Ce n’est pas une raison de ne pas avoir de politique. C’est une raison de comprendre ce qu’elle ne couvre pas et de commencer à travailler sur l’inventaire qui permettra, un jour, de répondre honnêtement à la question posée dans l’article précédent : si vous demandiez à votre RSSI, aujourd’hui, la liste exhaustive des outils IA actifs dans votre organisation, officiels et non officiels, pourrait-il vous répondre ?

La réponse dépend maintenant d’une deuxième question, plus difficile encore : saurait-il seulement où chercher ?

---

Arnaud Balandras est docteur en physique, architecte IT et consultant indépendant. Il publie sur slow-layer.com.

---