L'opt-out IA qui n'existe pas : ce que nous avons découvert en vérifiant 17 plateformes SaaS

Chaque plateforme SaaS à laquelle votre entreprise est connectée décide en ce moment même, discrètement, si vos contenus entraînent le modèle d'IA de quelqu'un d'autre. Nous avons vérifié les 17 plateformes de la bibliothèque de connecteurs de 8200.dev pour voir comment chacune gère réellement cette question — en nous attendant à trouver des options d'administration dédiées. Ce n'est majoritairement pas le cas.

Voici ce que nous avons découvert. Slack inclut par défaut chaque espace de travail dans l'entraînement de modèles non génératifs — aucune option n'existe nulle part dans la console d'administration ; se désinscrire suppose qu'un propriétaire d'espace de travail envoie un e-mail à [email protected] avec un objet précis, sans aucune traçabilité vérifiable ultérieurement. Salesforce dispose bien d'un paramètre réel, mais il s'agit d'une option Einstein GPT enfouie dans Setup, que la plupart des administrateurs ne savent pas devoir chercher — et y accéder peut nécessiter l'ouverture d'un ticket support selon votre édition. Chez Zendesk, la procédure se résume à un ticket support, un point c'est tout. Le Fin AI d'Intercom propose bien un opt-out au niveau de l'espace de travail, mais il réside dans l'interface, pas dans l'API — personne en dehors de votre console d'administration ne peut vérifier qu'il est réellement activé.

Dropbox constitue le cas le plus intéressant : les comptes américains sont inscrits par défaut aux fonctionnalités d'IA tierces ; les comptes européens, britanniques et canadiens en sont exclus par défaut. Même produit, même entreprise, réglages par défaut opposés selon le lieu d'enregistrement du compte — et la plupart des équipes n'ont jamais vérifié lequel des deux s'applique à elles. WhatsApp Business est également régionalisé : un formulaire d'opposition existe pour l'UE, le Royaume-Uni et le Brésil ; partout ailleurs, il n'existe tout simplement aucun levier à actionner.

À l'inverse, certaines plateformes n'utilisent véritablement pas votre contenu pour l'entraînement — il s'agit d'un engagement contractuel, pas d'un paramètre : Google Workspace, Microsoft 365, Box, Notion et GCP relèvent tous de ce cas. C'est rassurant, mais ce n'est pas non plus quelque chose que vous pouvez vérifier en cliquant dans votre propre console d'administration — vous prenez la parole de l'éditeur pour un engagement enfoui dans un accord de traitement des données que la plupart des gens ne lisent jamais au-delà de la première page.

Le schéma qui se dégage de tout cela : en dehors de Jira et de quelques options d'IA adjacentes (la correspondance avec du code public de GitHub Copilot, les règles d'organisation Vertex de GCP), il n'existe presque nulle part où interroger une API pour obtenir une réponse claire. C'est précisément pour cette raison que cette vérification doit être effectuée plateforme par plateforme, manuellement, une première fois — puis signalée automatiquement à chaque nouvelle connexion, plutôt que de faire confiance au fait que quelqu'un dans votre équipe a déjà lu les petites lignes.

Pourquoi « quelqu'un devrait vérifier ça » échoue silencieusement

La raison pour laquelle ce problème s'enkyste n'est pas la négligence. C'est que le contrôle habituel — désigner une personne, lui demander de vérifier — n'a nulle part où se rattacher.

Regardez à nouveau la liste ci-dessus et notez ce que chaque entrée a en commun : la posture se situe là où aucun tableau de bord ne peut la voir. Dans une clause contractuelle. Dans un réglage régional par défaut fixé à l'inscription. Dans un niveau d'offre qui a changé lors du dernier renouvellement des achats. Dans une adresse e-mail à laquelle il faut écrire. Il n'existe, sur aucune de ces plateformes, un seul écran répondant à la question que toute équipe sécurité a réellement besoin de voir tranchée — *mon organisation contribue-t-elle actuellement à des données d'entraînement, et l'avons-nous décidé délibérément ?*

La vérification est donc reportée, puis oubliée, puis héritée. Le réglage par défaut l'emporte par usure. Et ce réglage par défaut a été rédigé par l'éditeur, optimisé pour sa propre feuille de route en matière d'IA, pas pour vos obligations de traitement des données. C'est exactement la même configuration que nous avons détaillée pour une seule plateforme dans ce qui change pour Atlassian Jira le 17 août — sauf qu'il ne s'agit pas d'une seule plateforme. C'est chaque outil connecté qui prend sa propre version de la décision, selon son propre calendrier, dans sa propre cachette.

Une question de conformité, pas une simple curiosité

Si votre organisation détient un rapport SOC 2, travaille à l'obtention de la certification ISO 27001, ou traite des données personnelles au titre du RGPD, la contribution de données s'inscrit directement dans des obligations que vous portez déjà.

Un accord de traitement des données décrit les finalités pour lesquelles vos données peuvent être utilisées. Entraîner un modèle d'IA tiers constitue une finalité. Si le DPA d'un client indique que ses données sont utilisées pour fournir le service, et que l'une de vos plateformes connectées alimente discrètement ces mêmes données dans l'entraînement de modèles, l'écart entre ce que vous avez promis en aval et ce que vous autorisez en amont vous revient de combler — pas à l'éditeur. Les auditeurs ont commencé à poser la question directement, généralement sous une forme du type « l'un de vos sous-traitants entraîne-t-il une IA sur vos données, et comment le savez-vous ? ». Une réponse défendable comporte deux volets : la posture (quelles plateformes contribuent, lesquelles en sont exclues contractuellement) et le registre de décision (qui l'a examinée, quand, et quel choix a été fait). « Nous n'avons jamais vérifié » est la seule réponse qui échoue d'emblée. Nous avons présenté ce que les auditeurs attendent désormais dans ce que les auditeurs exigent réellement pour la gouvernance de l'IA en 2026 ; la contribution de données devient un point standard de cet examen même.

L'audit ponctuel à mener dès maintenant

La bonne nouvelle, c'est qu'il s'agit là d'un des rares points de gouvernance où la correction est véritablement peu coûteuse. Rien ne nécessite de refonte. Il suffit de trouver les paramètres, de décider délibérément, et de consigner la décision par écrit. Concrètement :

1. Dresser l'inventaire du périmètre. Listez chaque plateforme SaaS où le contenu ou les métadonnées de votre organisation résident réellement. Si elle héberge des données clients, des données réglementées, ou quoi que ce soit sous NDA, elle est dans le périmètre — pas seulement l'outil qui vous a envoyé un e-mail cette semaine.
2. Identifier la posture de chaque plateforme. Parfois c'est une page de paramètres, parfois un ticket support, parfois un opt-out par e-mail, parfois une clause contractuelle sans aucun contrôle disponible. Consignez où elle se trouve.
3. Confirmer le niveau d'offre. Sur plusieurs plateformes, la posture dépend du niveau d'offre — GitHub exclut les données Business et Enterprise de l'entraînement tandis que les niveaux inférieurs relèvent de conditions plus larges, et une migration peut inverser silencieusement votre posture.
4. Décider délibérément. Opter pour la participation peut être un choix légitime ; de meilleures fonctionnalités d'IA constituent un avantage réel. Le mode d'échec n'est pas la contribution — c'est une contribution que personne n'a décidée. Excluez ce qui est sensible, puis laissez le reste suivre son cours si tel est votre choix.
5. Consigner la décision par écrit, et revérifier selon un calendrier. Une note datée transforme un réglage par défaut silencieux en preuve de gouvernance, et les éditeurs modifient leurs réglages par défaut suffisamment souvent pour qu'une posture vérifiée une fois ne soit pas une posture gérée.

La description honnête de cette liste est *récurrente, transversale et rébarbative* — exactement le genre de contrôle qui se délite lorsqu'il dépend d'un être humain qui doit s'en souvenir.

À quoi cela a ressemblé quand nous avons mené cette vérification sur nous-mêmes

Le 31 juillet 2026, nous avons ouvert la console d'administration de notre propre organisation Atlassian et parcouru les cinq étapes ci-dessus. Rapporter le résultat avec précision importe, car il joue dans les deux sens.

Le contrôle au niveau de l'organisation était déjà désactivé. Atlassian Administration → Security → Data contribution propose un choix unique Activé/Désactivé pour l'ensemble de l'organisation — pas un par produit — et le nôtre était réglé sur Désactivé, avec une liste d'inclusion vide, de sorte que rien n'avait été réinclus sélectivement. Rien à corriger. Voilà à quoi ressemble un bon réglage par défaut, ou une bonne décision antérieure.

Vient ensuite la phrase imprimée directement sous ce contrôle : *« Metadata is always contributed. »* Le commutateur que nous avions réglé régit le contenu applicatif — ce que les utilisateurs rédigent dans les tickets et les pages. Les métadonnées se situent en dehors de ce périmètre, et sur notre offre, la page ne propose aucun contrôle les concernant. Notre abonnement Jira est Premium ; l'opt-out complet des métadonnées est une fonctionnalité réservée à Cloud Enterprise. Une bannière affichée sur chaque écran d'administration indique la date d'entrée en vigueur du changement : le 17 août 2026.

Ainsi, une organisation ayant déjà pris la décision délibérée, sur une offre payante, ne pouvait toujours pas se désinscrire complètement — et la seule façon de le découvrir était de lire une ligne de texte sur une page de paramètres qu'elle n'avait aucune raison particulière de revisiter. Bitbucket et Trello, quant à eux, sont facturés séparément et se situent entièrement en dehors de cette page ; quelle que soit leur posture, elle relève d'une vérification différente, sur un écran différent.

Rien de tout cela ne constitue une critique d'Atlassian, qui au moins rend le contrôle visible, énonce clairement sa limite, et publie la date. C'est l'argument même de cet article, démontré sur nous-mêmes : la décision et ses limites résident là où aucun tableau de bord ne les montre, et « nous l'avons désactivé » n'équivaut pas à « nous ne contribuons pas ».

Comment 8200.dev fait apparaître cela automatiquement

8200.dev génère désormais un constat de posture d'entraînement IA pour chaque plateforme que vous connectez. Connectez Slack, Dropbox, Salesforce, GitHub, ou n'importe laquelle des autres plateformes prises en charge, et l'analyse vous indique — juste à côté de vos constats de partage et de permissions — si cet éditeur utilise vos données pour l'entraînement de l'IA par défaut, où se trouve l'opt-out ou la garantie contractuelle, et à quand remonte la dernière vérification de cette posture. Les plateformes en opt-in par défaut génèrent des constats exigeant une décision ; les plateformes contractuellement sûres génèrent des attestations que vous pouvez remettre à un auditeur.

Lorsqu'une plateforme expose bien une politique lisible par API sur un axe voisin, nous la vérifions en temps réel : le connecteur GitHub lit le paramètre de correspondance avec du code public de Copilot de votre organisation, et le connecteur GCP signale lorsque Vertex AI fonctionne sans aucune règle d'organisation le contraignant. Chaque constat est accompagné d'un guide de remédiation étape par étape, et le catalogue complet des vérifications se trouve sur la page des fonctionnalités.

L'important n'est pas que les fonctionnalités d'IA soient dangereuses — beaucoup méritent d'être activées. L'important est que la contribution de données doit être une décision, pas un réglage par défaut, sur chaque plateforme que votre organisation utilise déjà. Si vous préférez que cela soit révélé automatiquement plutôt que retenu manuellement, consultez les offres et tarifs et connectez votre première plateforme en quelques minutes.