La question de l'IA et de la conformité des sous-traitants, ou, pour le dire dans le jargon, d'IA et conformité sous-traitants, arrive rarement par la porte juridique. Elle surgit quand une direction métier signe un outil en ligne, quand un prestataire annonce qu'il a « ajouté de l'IA » à son service, ou quand un client grand compte envoie un questionnaire de sécurité auquel personne ne sait répondre.

Sur les SI que nous accompagnons, le constat est constant : la chaîne de sous-traitance s'est enrichie de briques d'IA sans que le registre des traitements ni les contrats aient bougé. Cet article décrit ce que le RGPD et l'AI Act exigent réellement, puis montre, par un exemple concret, comment automatiser une partie de ce contrôle sans transformer votre direction juridique en centre de saisie.

IA et conformité des sous-traitants en entreprise 2026

Temps de lecture : ~11 min

1. Pourquoi l'IA et la conformité des sous-traitants deviennent un sujet de CODIR

2. Qui est quoi, et pourquoi ce vocabulaire compte

3. Ce que le RGPD exige concrètement d'un fournisseur d'IA

4. La chaîne de sous-traitance, le point aveugle le plus fréquent

5. Exemple concret : automatiser le contrôle de conformité des fournisseurs

6. Les obligations du déployeur face à un système à haut risque

7. La checklist avant mise en production

8. Faire de la conformité un cadre de décision, pas un frein

9. FAQ

Pourquoi l'IA et la conformité des sous-traitants deviennent un sujet de CODIR

Trois mouvements qui impactent vos sous-traitants IA

Trois mouvements se superposent. D'abord, vos prestataires historiques intègrent des modèles dans leurs produits, parfois sans vous en informer autrement que par une mise à jour de conditions générales. Ensuite, vos équipes souscrivent directement à des services en ligne, et ce qui ressemble à un abonnement individuel est en réalité un traitement de données personnelles opéré pour votre compte.

Enfin, le cadre réglementaire s'est durci, avec un calendrier d'application de l'AI Act qui avance : la Commission européenne indique que les obligations de transparence prévues à l'article 50 s'appliquent à partir du 2 août 2026.

Ce qui se joue n'est pas un sujet de conformité formelle. C'est une question de maîtrise. Quand un fournisseur change de modèle, d'hébergeur ou de sous-traitant ultérieur, votre exposition change aussi, sans que personne ne l'ait décidé. Ce que nous constatons chez nos clients, c'est que les entreprises capables de répondre en quelques jours à une demande d'audit client gagnent des appels d'offres, et que les autres les perdent. C'est précisément ce qui justifie de présenter ce sujet au conseil d'administration plutôt que de le laisser traîner dans un coin de la direction juridique.

Qui est quoi, et pourquoi ce vocabulaire compte

Le RGPD distingue le responsable de traitement, qui détermine les finalités et les moyens, et le sous-traitant, qui traite les données personnelles pour son compte et selon ses instructions. Un éditeur SaaS qui héberge vos données et les traite pour vous rendre un service est, dans la très grande majorité des cas, un sous-traitant. Ce n'est pas automatique, cela dépend de la réalité du traitement, mais l'étiquette commerciale du contrat ne décide de rien : c'est le rôle effectif qui qualifie.

L'AI Act ajoute une seconde grille, indépendante de la première. Le fournisseur développe le système d'IA et le met sur le marché sous son nom. Le déployeur l'utilise dans le cadre de son activité professionnelle. Une entreprise qui achète une solution d'IA externe reste déployeur, même si elle n'a écrit aucune ligne de code.

Autrement dit, vous pouvez être à la fois responsable de traitement au sens du RGPD et déployeur au sens de l'AI Act, pour un système que vous n'avez pas conçu. Cette double qualification est le point de départ de toute cartographie sérieuse des systèmes d'IA.

Comparaison entre le RGPD et l'AI Act

• Critère: Objet RGPD: Protection des données personnelles AI Act: Encadrement des systèmes d'IA

• Critère: Champ RGPD: Tout traitement de données personnelles AI Act: Systèmes d'IA, même sans données personnelles

• Critère: Acteurs RGPD: Responsable de traitement, sous-traitant, sous-traitant ultérieur AI Act: Fournisseur, déployeur, importateur, distributeur

• Critère: Contrat RGPD: Contrat de sous-traitance obligatoire, article 28 AI Act: Répartition des responsabilités selon le rôle

• Critère: Évaluation RGPD: Analyse d'impact relative à la protection des données AI Act: Classification du risque et mesures associées

• Critère: Sécurité RGPD: Mesures techniques et organisationnelles adaptées au risque AI Act: Robustesse, cybersécurité, journalisation, contrôle humain

Ce que le RGPD exige concrètement d'un fournisseur d'IA

Contrat de sous-traitance : les points de vigilance avec l'IA

Le contrat de sous-traitance de l'article 28 du RGPD n'est pas une formalité. Il doit préciser l'objet et la durée du traitement, sa nature et sa finalité, les catégories de données et de personnes concernées, les instructions du responsable de traitement, les obligations de confidentialité, les mesures de sécurité, les conditions de recours à un sous-traitant ultérieur, l'assistance à l'exercice des droits et en cas de violation, les modalités d'audit, puis la restitution ou la suppression des données en fin de contrat. La CNIL déconseille explicitement de démarrer une prestation avant la signature d'un contrat reprenant ces exigences.

Deux points méritent une vigilance particulière avec l'IA. Le premier concerne la conservation des prompts, des fichiers déposés, des sorties et des métadonnées associées. Ces éléments peuvent rester dans les journaux du fournisseur, servir à améliorer le service ou être accessibles à des équipes de support. Le contrat doit trancher explicitement, ce qui suppose de sécuriser les prompts et les applications d'IA dès la conception du processus.

Le second concerne l'entraînement du modèle : l'interdiction de réutiliser vos données à cette fin sans accord écrit doit figurer noir sur blanc, et pas seulement dans une page d'aide susceptible d'évoluer. La CNIL recommande par ailleurs d'intégrer dès la conception la minimisation des données, la pseudonymisation, la journalisation, la limitation des accès des tiers et la capacité d'audit.

Bon à savoir

Une certification de sécurité constitue un indice de fiabilité lors de l'évaluation d'un prestataire, jamais une preuve de conformité. Elle ne dit rien de la base légale de votre traitement, ni des finalités réellement autorisées dans votre contrat.

La chaîne de sous-traitance, le point aveugle le plus fréquent

Votre fournisseur direct est rarement seul à toucher les données. Derrière lui, on trouve un hébergeur cloud, un fournisseur de modèles, parfois un prestataire d'annotation, un service d'analyse d'usage ou un support technique situé hors de l'Espace économique européen. Chacun de ces acteurs est un sous-traitant ultérieur, et le responsable de traitement doit pouvoir les identifier, connaître leur localisation et encadrer les changements.

Dans la pratique, ces listes vivent sur une page web du fournisseur, modifiée sans préavis commercial. Exiger contractuellement une information préalable, un délai de réaction et un droit d'opposition ou de résiliation est la seule protection réelle. Les entreprises qui négligent ce volet découvrent souvent le problème au pire moment, lors d'une notification de violation de données qui remonte d'un acteur dont elles ignoraient l'existence.

Le sujet rejoint celui, plus large, de la souveraineté des données et du lieu d'exécution des traitements.

Exemple concret : automatiser le contrôle de conformité des fournisseurs

Une ETI de services que nous accompagnons gérait son suivi fournisseurs dans un tableur, alimenté une fois par an. Le juridique passait des semaines à relire des contrats de sous-traitance pour y chercher toujours les mêmes informations. Nous avons construit avec eux un dispositif simple, où l'IA sert d'outil de lecture et non d'autorité de décision.

Le mécanisme tient en quatre temps. Les contrats, DPA et conditions d'utilisation de chaque prestataire sont centralisés dans un espace unique. Un modèle en extrait ensuite une dizaine de points de contrôle normalisés : localisation de l'hébergement, réutilisation éventuelle des données pour l'entraînement, durée de conservation des prompts et des sorties, liste des sous-traitants ultérieurs, existence d'un droit d'audit, délai contractuel de notification d'incident, mesures de sécurité déclarées comme le chiffrement, l'authentification multifacteur et la journalisation des accès.

Ces points sont comparés à une grille de référence interne, et chaque écart devient une alerte qualifiée. Enfin, une veille automatisée surveille les pages publiques listant les sous-traitants ultérieurs et signale toute modification.

Le résultat n'est pas une conformité automatique, cela n'existe pas. C'est un gain de temps de lecture, une base de preuves à jour, et surtout un déplacement du travail juridique vers l'arbitrage : le juriste ne cherche plus l'information, il décide à partir d'une information présentée. Le contrôle humain reste entier, ce qui est précisément ce que l'AI Act attend d'un déployeur sur un système sensible. C'est le type de cas d'usage que nous priorisons lors d'un Diagnostic IA, parce qu'il touche un processus réel, mesurable et répétable.

Les obligations du déployeur face à un système à haut risque

L'AI Act repose sur une approche par le risque, du risque minimal aux pratiques interdites, en passant par le risque limité et les systèmes à haut risque. Le niveau dépend de la finalité et du contexte d'usage, pas de la technologie : un même outil généraliste peut relever de régimes différents selon qu'il trie des candidatures ou rédige des comptes rendus internes.

Pour un système à haut risque, le déployeur doit notamment utiliser le système conformément aux instructions du fournisseur, assurer un contrôle humain confié à des personnes disposant des compétences, de la formation et de l'autorité nécessaires, surveiller le fonctionnement, contrôler la qualité des données d'entrée dont il a la maîtrise, conserver les journaux applicables, signaler les incidents sérieux et informer les personnes concernées lorsque la réglementation l'impose.

Une analyse d'impact relative à la protection des données s'impose dès que le traitement est susceptible d'engendrer un risque élevé pour les droits et libertés, ce qui est fréquent en matière de ressources humaines, de scoring ou de traitement de données sensibles. La CNIL recommande de vérifier qu'une AIPD a bien été menée et qu'une documentation existe sur la collecte et la gestion des données, l'algorithme, la qualité des résultats, la journalisation et les mesures de sécurité. Structurer cette démarche suppose souvent un plan d'action de mise en conformité à l'AI Act propre à chaque système identifié.

La checklist avant mise en production

Checklist de déploiement d'un système d'IA fourni par un tiers

Avant d'ouvrir l'accès à un système d'IA fourni par un tiers, nous passons systématiquement en revue les mêmes points avec nos clients.

• Le rôle juridique de chaque acteur est tranché, responsable de traitement, sous-traitant, fournisseur ou déployeur.

• Le contrat article 28 est signé, les finalités autorisées et les usages interdits sont écrits.

• L'hébergement et les transferts hors Espace économique européen sont documentés, de même que la liste des sous-traitants ultérieurs.

• L'interdiction d'entraînement sur vos données figure au contrat, avec la durée de conservation des prompts.

• L'AIPD a été réalisée lorsqu'elle était nécessaire, et le dossier de conformité est constitué.

• Les accès sont restreints, la journalisation activée, la procédure d'incident écrite et un responsable interne désigné.

À retenir

Si un fournisseur refuse un contrat conforme à l'article 28 ou tout droit d'audit, même indirect par la communication de rapports de sécurité, ce refus est une réponse en soi. Il appartient au CODIR d'arbitrer entre le bénéfice métier et un risque qui restera contractuellement non couvert.

Faire de la conformité un cadre de décision, pas un frein

Les entreprises qui avancent le plus vite sur l'IA ne sont pas celles qui contrôlent le moins. Ce sont celles qui ont posé un cadre clair en amont : une cartographie des systèmes d'IA tenue à jour, une classification du risque assumée, une gouvernance contractuelle homogène et une traçabilité suffisante pour répondre à un client ou à un régulateur.

Ce cadre se décide au niveau du CODIR, pas dans un coin de la direction juridique. C'est l'objet de notre atelier IA CODIR, une demi journée de quatre heures dans vos locaux, dont le budget se situe souvent entre 5 000 et 7 000 € HT selon la taille de l'entreprise, à l'issue de laquelle chaque dirigeant repart avec la même lecture du sujet et une trajectoire commune. Le reste, c'est de l'exécution, et elle se pilote processus par processus.

FAQ

Un fournisseur SaaS d'IA est-il automatiquement sous-traitant au sens du RGPD ?

Non, mais il l'est dans la grande majorité des cas dès qu'il traite des données personnelles pour votre compte. La qualification dépend de qui détermine réellement les finalités et les moyens. Un fournisseur qui réutilise vos données pour ses propres finalités devient responsable de traitement pour cette partie, ce qui change toute l'analyse.

Qui est responsable en cas d'erreur commise par une IA fournie par un prestataire ?

La responsabilité se répartit selon les rôles. Le fournisseur répond de la conformité du système et de sa documentation, le déployeur du contrôle humain et de la qualité des données d'entrée qu'il maîtrise. Vis à vis de vos clients et des personnes concernées, c'est vous qui restez en première ligne.

Comment vérifier qu'un prestataire n'entraîne pas son modèle sur nos données ?

Par le contrat d'abord, qui doit l'interdire explicitement sans accord écrit, puis par les preuves : paramétrage documenté de la non conservation des données, rapports de sécurité, réponses écrites à un questionnaire d'évaluation. Une déclaration commerciale sans engagement contractuel ne vaut rien en cas de contentieux.

Faut-il refaire l'analyse quand le fournisseur change de modèle ?

Oui, dès lors que le changement touche l'hébergement, les sous traitants ultérieurs ou la nature du traitement. C'est la raison pour laquelle le contrat doit imposer une information préalable. Sans clause de notification, vous découvrez le changement après coup, et votre documentation devient fausse.

Par où commencer quand aucun inventaire n'existe ?

Par le recensement des outils réellement utilisés, y compris ceux souscrits hors processus achat. Cette cartographie révèle presque toujours des usages non gouvernés, et elle sert à la fois de base de conformité et de point de départ à une feuille de route de valeur.