yvoria-ai.fr →
← Tous les articles

Audit fournisseur IA sous-traitant AI Act : maîtriser la chaîne de responsabilité

01/07/2026

L'AI Act ne s'arrête pas aux portes de votre DSI. Dès qu'un prestataire ou intégrateur intervient dans la chaîne de valeur d'un système d'IA, la responsabilité se partage — et peut se retourner contre le déployeur s'il n'a pas exercé une diligence raisonnable. Auditer ses fournisseurs IA n'est plus une option : c'est une obligation de gouvernance concrète, dont les premières échéances réglementaires arrivent en 2025.

Pourquoi la sous-traitance IA crée-t-elle un angle mort réglementaire ?

La grande majorité des organisations ne développent pas leurs modèles d'IA en interne. Elles s'appuient sur des fournisseurs de modèles fondamentaux (OpenAI, Mistral, Google…), des éditeurs SaaS qui embarquent de l'IA, et des intégrateurs qui assemblent ces briques. Or, l'AI Act distingue trois rôles aux obligations distinctes :

  • Fournisseur (provider) : conçoit et met sur le marché un système d'IA.
  • Déployeur (deployer) : utilise le système dans un contexte professionnel.
  • Intégrateur : assemble ou personnalise des composants pour un usage spécifique — et peut basculer dans le rôle de fournisseur sans le savoir.

Le risque est double : votre prestataire vous livre un système à haut risque sans documentation conforme, ou vous-même devenez involontairement fournisseur en configurant un modèle tiers pour un usage métier critique.

Cartographier la chaîne de responsabilité avant d'auditer

Étape 1 — Inventaire des composants IA tiers

Commencez par recenser tous les systèmes qui intègrent de l'IA, y compris le shadow AI : outils adoptés sans validation IT, plugins de productivité, API consommées directement par des équipes métier. Un registre des traitements étendu à la dimension IA est ici indispensable.

Étape 2 — Classification par niveau de risque AI Act

Pour chaque composant, déterminez la catégorie de risque (inacceptable, haut risque, risque limité, risque minimal). Les systèmes à haut risque (RH, crédit, décisions médicales, infrastructure critique…) imposent des obligations strictes à toute la chaîne. Un outil de scoring RH fourni par un prestataire entre dans l'Annexe III de l'AI Act et déclenche des exigences documentaires que vous devez pouvoir vérifier.

Étape 3 — Identification des rôles contractuels réels

Ne vous fiez pas aux intitulés marketing. Analysez contractuellement qui contrôle la finalité, les données d'entraînement et les paramètres du modèle. Un intégrateur qui fine-tune un modèle sur vos données métier devient très probablement co-fournisseur au sens de l'article 25 de l'AI Act.

Le programme d'audit fournisseur IA : les 5 piliers

1. Documentation technique et conformité CE

Pour les systèmes à haut risque, l'AI Act exige une documentation technique précise (article 11) : architecture du modèle, données d'entraînement, métriques de performance, limites connues. Demandez systématiquement à votre fournisseur :

  • La notice d'utilisation prévue (intended purpose) et les usages interdits.
  • Les résultats de l'évaluation de conformité ou le certificat d'organisme notifié si applicable.
  • La déclaration UE de conformité et le marquage CE attendu d'ici août 2026.

2. Gestion des données et RGPD

L'audit fournisseur IA chevauche nécessairement l'audit sous-traitant RGPD. Vérifiez que le Data Processing Agreement (DPA) couvre explicitement l'entraînement ou le fine-tuning sur vos données, les transferts hors UE des données d'inférence, et les durées de rétention des logs de requêtes.

3. Gestion des risques et robustesse

L'article 9 de l'AI Act impose un système de gestion des risques continu. Interrogez votre prestataire sur ses procédures de détection de dérives (model drift), ses tests adversariaux et son plan de réponse aux incidents IA. Un fournisseur incapable de produire un rapport de tests de robustesse est un signal d'alerte fort.

4. Traçabilité et logs

La capacité à expliquer une décision automatisée dépend directement des logs conservés par votre prestataire. Contractualisez l'accès aux journaux d'audit, la durée de conservation minimale (l'AI Act recommande 6 mois pour les systèmes à haut risque) et les modalités d'export en cas de litige ou d'enquête régulatoire.

5. Plan de continuité et exit strategy

La dépendance à un modèle propriétaire crée un risque de souveraineté. Évaluez la portabilité des données, la possibilité de migration vers un autre fournisseur et les clauses de résiliation en cas de non-conformité réglementaire avérée du prestataire.

Exemple concret : auditer un prestataire de scoring crédit IA

Une banque régionale sous-traite son scoring crédit à un éditeur fintech. Le système entre dans l'Annexe III (décisions affectant l'accès au crédit). L'audit révèle :

  • Absence de documentation sur les biais détectés lors de l'entraînement.
  • DPA silencieux sur l'usage des données de remboursement pour re-entraîner le modèle.
  • Logs d'inférence conservés seulement 30 jours, incompatibles avec les délais de réclamation client.

Résultat : renégociation du contrat, ajout d'un avenant IA Act, et audit annuel conditionné au maintien du partenariat. Ce cas illustre pourquoi l'audit ne peut pas se limiter à un questionnaire auto-déclaratif.

Intégrer l'audit IA dans votre gouvernance existante

L'audit fournisseur IA n'est pas un processus isolé. Il s'intègre dans :

  • Le registre des traitements RGPD étendu aux systèmes IA.
  • La politique achats avec une clause IA Act obligatoire dans tout contrat impliquant un traitement automatisé décisionnel.
  • Le plan d'audit interne du RSSI, avec une fréquence adaptée au niveau de risque (annuel pour le haut risque, bisannuel pour le risque limité).

Les outils de gouvernance IA comme Yvoria permettent d'automatiser cet inventaire, de scorer le niveau de risque de chaque fournisseur et de centraliser les preuves de conformité pour répondre rapidement à une demande d'autorité de contrôle.

Ce que vous devez retenir

  • Toute la chaîne prestataire/intégrateur est concernée par l'AI Act, pas seulement votre organisation.
  • Cartographiez les rôles réels (fournisseur, déployeur, intégrateur) avant de rédiger vos contrats.
  • Un audit fournisseur IA couvre documentation technique, RGPD, robustesse, traçabilité et exit strategy.
  • Sans contractualisation explicite, vous assumez seul les manquements de vos prestataires face au régulateur.

FAQ

Mon prestataire SaaS qui intègre de l'IA est-il soumis à l'AI Act ?

Oui, dès lors que le SaaS met à disposition un système d'IA sur le marché européen. S'il s'agit d'un système à haut risque, le fournisseur doit produire une documentation technique, une évaluation de conformité et apposer le marquage CE. Vous, en tant que déployeur, devez vérifier l'existence de ces éléments avant tout déploiement.

Quelle différence entre un déployeur et un fournisseur au sens de l'AI Act ?

Le fournisseur conçoit et met sur le marché le système d'IA ; il porte les obligations les plus lourdes (documentation, conformité CE). Le déployeur l'utilise dans un contexte professionnel. Attention : un déployeur qui modifie substantiellement le système ou en change la finalité bascule dans le rôle de fournisseur.

Un questionnaire auto-déclaratif suffit-il pour auditer un fournisseur IA ?

Non. Pour les systèmes à haut risque, l'AI Act exige une documentation vérifiable. Un questionnaire est un point de départ, mais l'audit doit inclure la revue de la documentation technique, des DPA, des logs et idéalement un droit d'audit contractualisé.

À quelle fréquence faut-il auditer ses fournisseurs IA ?

Pour les systèmes à haut risque, un audit annuel est recommandé, complété par un audit déclenché en cas de mise à jour majeure du modèle ou d'incident. Pour les systèmes à risque limité, une revue bisannuelle est généralement suffisante.

L'audit fournisseur IA remplace-t-il l'audit sous-traitant RGPD ?

Non, il le complète. L'audit RGPD couvre la licéité des traitements de données personnelles ; l'audit AI Act vérifie la conformité du système d'IA lui-même. Les deux sont nécessaires et souvent menés conjointement pour éviter les doublons.