Un SaaS B2B reçoit un questionnaire sécurité de 80 questions d'un prospect grand compte. À la question 37, on lui demande la liste des sous-traitants qui utilisent de l'intelligence artificielle pour traiter les données de ses clients. Son registre RGPD, rempli en 2023, ne répond pas. Deux semaines de recherches en interne, trois relances à ses fournisseurs, et toujours une réponse partielle.
Ce scénario se joue plusieurs fois par mois chez nos clients depuis début 2026. La raison est simple : le RGPD encadre la sous-traitance des données personnelles depuis 2018 via l'article 28, mais l'AI Act ajoute une couche spécifique à l'IA que peu de registres existants savent cartographier. Cet article propose une méthode opérationnelle pour auditer l'IA dans sa chaîne de sous-traitance, sans transformer le DPO en détective privé.
Pourquoi un audit IA des sous-traitants devient obligatoire en 2026
Trois forces se combinent.
La première, c'est l'AI Act. Le règlement européen (UE) 2024/1689 distingue plusieurs rôles dans la chaîne IA : fournisseurs, déployeurs, distributeurs, importateurs. Les obligations ne pèsent pas aux mêmes endroits selon le rôle, mais une entreprise qui utilise un outil intégrant de l'IA haut risque a des devoirs qu'elle ne peut pas déléguer : documentation technique, supervision humaine, traçabilité des décisions, gestion des incidents. Si son fournisseur ne tient pas ses propres obligations, c'est elle qui supporte le risque réglementaire. Les autorités compétentes pour l'AI Act en France ont commencé à détailler leurs attentes, et la CNIL, depuis la nomination de son premier directeur des technologies et de l'IA en avril 2026, coordonne activement avec la DGCCRF et l'ARCEP.
La deuxième, c'est l'article 28 du RGPD. Ce texte n'a pas attendu l'AI Act pour exiger un encadrement strict de la sous-traitance. L'article 28 impose au responsable de traitement de ne recourir qu'à des sous-traitants qui présentent des garanties suffisantes, avec un contrat écrit (DPA), une information claire sur la sous-traitance ultérieure, et la traçabilité des traitements. Depuis 2024, l'EDPB précise dans ses lignes directrices que l'usage d'IA générative par un sous-traitant modifie l'analyse de conformité : il ne suffit plus de signer un DPA standard, il faut comprendre ce que fait vraiment l'IA avec la donnée.
La troisième, c'est la pression commerciale. Les grands comptes européens (banques, assureurs, secteur public, groupes SaaS internationaux) ont tous intégré depuis le T4 2025 des questionnaires de pré-sélection fournisseur qui exigent une cartographie IA de la sous-traitance. Les RFP que nous voyons passer demandent explicitement la liste des ST, leur usage d'IA, la classification AI Act de chaque système, et le plan de gestion des incidents IA. Les SaaS qui ne peuvent pas répondre en 48 h perdent le deal.
Conclusion pratique : l'audit IA des sous-traitants n'est plus un sujet juridique, c'est un livrable commercial. Le traiter comme un sous-chapitre de l'audit RGPD classique, comme un post-it ajouté au registre, ne marche plus.
Identifier les sous-traitants qui utilisent l'IA (sans leur faire confiance aveuglément)
Premier obstacle : les sous-traitants ne déclarent pas spontanément leur usage d'IA. Certains par méconnaissance (ils intègrent une librairie tierce et ne se voient pas comme fournisseurs d'IA), d'autres par calcul (une déclaration IA les expose à un questionnaire plus lourd), d'autres enfin parce que la feature IA a été ajoutée silencieusement lors d'une mise à jour entre deux audits.
La bonne nouvelle : on peut travailler avec trois sources, en redondance.
1. Le questionnaire ciblé, avec les bonnes questions. Un formulaire générique "utilisez-vous de l'IA ?" reçoit souvent des "non" par réflexe. Il faut décomposer :
Les quatre dernières questions collectent plus d'aveux que la première.
2. L'analyse de la documentation produit publique. Les CTO et équipes produit communiquent beaucoup sur leurs usages IA dans leur marketing, leurs changelogs, leurs articles de blog et leurs conférences. Une lecture structurée des 12 derniers mois de communication d'un fournisseur révèle souvent ce que son service juridique n'a pas pensé à déclarer.
3. Le monitoring automatisé des changements. C'est là que nous avons construit Hari, l'IA interne de Leto qui scrute en continu les pages légales, les politiques de confidentialité, les changelogs et les communiqués de presse des sous-traitants référencés dans le registre. Quand une feature IA est annoncée par un fournisseur, le DPO reçoit une alerte automatique. Cette partie est opérationnelle depuis 2025 côté Leto, mais la logique est reproductible sans notre outil, simplement plus coûteuse en temps humain.
Le résultat : un inventaire des ST IA, daté, sourcé, que le DPO peut défendre face à un auditeur. C'est le prérequis du score de risque.
À lire aussi : Sous-traitant RGPD : définition, obligations et audit de conformité, la méthode générale d'audit des sous-traitants, que l'audit IA vient enrichir.
Scorer le risque IA de chaque sous-traitant
Une fois la liste établie, tous les ST IA ne présentent pas le même risque. Une matrice de scoring à trois dimensions tient la route chez nos clients.
Dimension 1 : classification AI Act du système. L'AI Act distingue quatre niveaux :
Pour un DPO, un ST en catégorie "haut risque" impose un contrôle renforcé (documentation technique complète, supervision humaine documentée, registre des incidents).
Dimension 2 : nature des données traitées par l'IA. Une IA qui traite des données de santé, des données de mineurs, des données sensibles au sens de l'article 9 du RGPD ou des données hautement personnelles (références bancaires, géolocalisation fine) impose un niveau de garantie supérieur. Un ST qui traite une adresse email de prospection est à un cran en-dessous.
Dimension 3 : criticité métier. Un ST IA qui pilote un processus critique (la réponse client automatisée, le moteur de recommandation produit, le scoring crédit) expose l'entreprise à un risque business qui dépasse le RGPD. Sa défaillance a des conséquences réputationnelles ou opérationnelles qui pèsent dans l'arbitrage "on le garde / on le change".
La matrice produit un score final entre 1 et 9 (par exemple : catégorie × données × criticité), qui hiérarchise l'action : les ST au-dessus de 7 demandent un audit annuel complet, les ST entre 4 et 6 un point semestriel, les ST en-dessous de 4 un simple suivi documentaire.
Contractualiser l'usage de l'IA avec ses sous-traitants
Le DPA classique, même à jour des guidelines EDPB 2021-2023, n'est plus suffisant. Il faut l'enrichir, soit par un addendum dédié, soit par des clauses injectées dans le DPA existant. Les points à couvrir en pratique :
Ces clauses rejoignent la logique de l'article 29 du RGPD, qui impose un traitement des données "sur instruction" du responsable. Cette instruction doit désormais intégrer les paramètres d'usage IA.
Pour la mécanique générale du DPA : Qu'est-ce qu'un DPA et comment le rédiger ?
Gérer les changements et les mises à jour IA dans la chaîne ST
Le risque réel en 2026 n'est pas qu'un sous-traitant soit mal audité à l'instant T. C'est qu'il change son usage IA six mois plus tard, sans le dire, et que personne ne le remarque avant le contrôle CNIL ou le prochain RFP.
Trois mécanismes complémentaires :
Veille contractuelle active. Intégrer dans le DPA une clause de notification préalable pour tout ajout ou modification d'un système IA. Concrètement : 30 jours avant déploiement d'une nouvelle feature IA dans le service fourni, le ST envoie une note écrite précisant la nature du changement et sa classification AI Act.
Veille externe automatisée. S'abonner aux changelogs, blogs produit et release notes des ST critiques, avec un parsing automatisé qui déclenche une revue dès qu'un mot-clé IA apparaît (nouveau, AI, machine learning, GPT, génératif, etc.).
Fréquence de reverification formalisée. Inscrire dans le registre des traitements une date de prochaine revue par ST, calée sur le score de risque. Les ST "haut risque" passent en revue 1 fois/an minimum, sur un créneau dédié, avec compte rendu archivé.
La distinction entre responsable de traitement, sous-traitant et co-responsable devient particulièrement sensible ici. Certains fournisseurs IA basculent de facto vers un rôle de co-responsable quand ils entraînent leurs modèles sur les données clients. Cette bascule doit être surveillée dans les mises à jour contractuelles.
Checklist audit IA ST + erreurs fréquentes
Checklist opérationnelle (10 points) :
- Recenser exhaustivement les ST qui traitent des données personnelles.
- Pour chaque ST, administrer un questionnaire IA ciblé (5 questions minimum).
- Croiser avec la documentation publique (blog produit, changelog 12 derniers mois).
- Classer chaque ST IA selon la grille AI Act (inacceptable / haut / limité / minimal).
- Scorer chaque ST IA sur la matrice à 3 dimensions (classification × données × criticité).
- Mettre à jour le DPA avec les 7 clauses IA (ou ajouter un addendum AI Act).
- Documenter la date de la dernière revue et la prochaine échéance dans le registre.
- Poser un processus de notification préalable à 30 jours pour tout changement IA.
- Archiver les preuves (questionnaires, contrats, attestations) dans un espace dédié.
- Intégrer l'audit IA ST au reporting DPO annuel, avec indicateurs chiffrés.
Top 5 erreurs fréquentes que nous voyons chez les nouveaux clients Leto :
- Erreur 1, faire l'audit une fois et ne plus y revenir. Un audit IA ST n'est pas un livrable, c'est un processus.
- Erreur 2, déléguer la cartographie IA à l'IT. L'IT connaît les outils déployés, pas leur traitement de données personnelles. Le DPO reste aux commandes.
- Erreur 3, mélanger audit IA et audit sécurité ISO 27001. Les deux doivent se parler, pas se confondre. Un ST peut être ISO 27001 conforme et utiliser une IA non encadrée côté RGPD.
- Erreur 4, accepter un "non" comme réponse. Si un ST déclare ne pas utiliser d'IA mais propose des features de "résumé automatique", il y a probablement une IA à quelque part dans sa stack.
- Erreur 5, traiter la sous-traitance ultérieure comme un problème mineur. Beaucoup de ST IA dépendent eux-mêmes d'une API OpenAI, Anthropic, Mistral ou d'un autre éditeur. Les obligations RGPD descendent toute la chaîne.
Conclusion
L'audit IA des sous-traitants est la colonne vertébrale de la conformité RGPD × AI Act en 2026. Pas un sous-chapitre, pas un addendum : un processus propre, avec sa méthode, sa cadence, ses livrables. Un DPO qui sait dire en 48 h quels sont ses ST IA, leur score de risque et leurs obligations a résolu un des points les plus difficiles de sa feuille de route. Les autres (sensibilisation, AIPD, exercice des droits) deviennent plus simples à piloter.
Le reste, c'est de la rigueur ops.
FAQ
Faut-il un audit spécifique IA au-delà du registre des traitements RGPD classique ?
Oui. Le registre RGPD cartographie les traitements de données personnelles, mais ne détaille pas les systèmes IA qui les opèrent ni leur classification AI Act. Un audit IA spécifique est devenu nécessaire pour répondre aux exigences de l'AI Act, des questionnaires grands comptes et des contrôles CNIL à venir en 2026.
Quelle différence entre un sous-traitant et un sous-traitant ultérieur pour l'IA ?
Le sous-traitant est le fournisseur direct de l'entreprise (ex : un SaaS RH). Le sous-traitant ultérieur est le fournisseur de ce sous-traitant (ex : l'API OpenAI utilisée par le SaaS RH pour ses résumés). Les obligations RGPD et AI Act s'appliquent aux deux : le DPO doit cartographier toute la chaîne, pas seulement le premier rang.
Comment détecter qu'un sous-traitant utilise une IA sans le déclarer ?
Trois méthodes complémentaires : un questionnaire décomposé en 5 questions précises (au lieu d'un "utilisez-vous de l'IA ?" générique), l'analyse des communications publiques du fournisseur (blog, changelog, communiqués), et un monitoring automatisé des changements de politique et de documentation produit.
Quels articles de l'AI Act s'appliquent à mes sous-traitants ?
Selon le rôle du sous-traitant : s'il est fournisseur d'un système IA haut risque, les articles 16 à 27 (obligations du fournisseur) s'appliquent. S'il est déployeur pour votre compte, les articles 26 et 27 (obligations du déployeur) s'appliquent. Dans tous les cas, les obligations de transparence (art. 50) s'appliquent aux systèmes à risque limité.
Faut-il un addendum AI Act au DPA existant, ou le récrire ?
Un addendum spécifique est en général suffisant pour les ST existants : il permet de couvrir les nouvelles obligations IA sans renégocier l'ensemble du DPA. Pour les nouveaux contrats, intégrer directement les clauses IA dans le DPA initial est plus propre.
À quelle fréquence refaire l'audit IA de ses sous-traitants ?
La fréquence dépend du score de risque : les ST IA "haut risque" (classification AI Act annexe III + données sensibles + criticité métier forte) demandent un audit complet annuel, les ST à risque modéré un point semestriel, les ST à risque limité un suivi documentaire annuel suffit. Tout changement IA déclaré par le ST déclenche une revue hors cycle.
