Pourquoi la diligence raisonnable sur l'IA des fournisseurs est une obligation réglementaire, et non une simple préférence d'achat

Les régulateurs des différentes juridictions s'accordent sur un point : la responsabilité des systèmes d'IA ne peut pas être externalisée aux fournisseurs. Les articles 25 et 26 de l'AI Act de l'UE établissent une chaîne de valeur claire des responsabilités, les fournisseurs (providers) conservent la responsabilité des systèmes qu'ils mettent sur le marché, et les déployeurs (les organisations qui utilisent des systèmes d'IA dans leurs propres produits et services) sont responsables de la manière dont ces systèmes sont déployés et surveillés. En vertu de la norme CPS 230 australienne, les fournisseurs d'IA soutenant des opérations critiques sont des prestataires de services essentiels soumis à une diligence raisonnable obligatoire, à des protections contractuelles et à un suivi continu. La lettre d'avril 2026 de l'APRA (Australian Prudential Regulation Authority) a constaté que certaines entités réglementées manquaient de visibilité adéquate sur leur chaîne d'approvisionnement en IA, y compris les dépendances de quatrième niveau (fourth-party).

Une diligence raisonnable insuffisante à l'égard des fournisseurs crée une exposition réglementaire directe. Une organisation incapable de démontrer qu'elle a évalué, avant l'achat, les pratiques de données, la posture de sécurité, la gouvernance des modèles et la conformité réglementaire de son fournisseur d'IA se trouve en position défavorable lorsqu'un régulateur examine un incident, qu'une plainte pour biais est déposée, ou qu'une mesure d'exécution est engagée contre un produit reposant sur le système de ce fournisseur.

Les cinq domaines que toute évaluation de fournisseur d'IA doit couvrir

1. Pratiques en matière de données et conformité à la protection de la vie privée. Comment le fournisseur utilise-t-il vos données, y compris les données que vous transmettez via son API ? Le fournisseur utilise-t-il les données clients pour entraîner ou affiner ses modèles ? Dans quelles circonstances, et avec quel consentement ? Qui sont les sous-traitants du fournisseur ? Où les données sont-elles traitées et stockées ? L'accord de traitement des données du fournisseur satisfait-il aux exigences du Privacy Act 1988 (entités australiennes), du RGPD (entités de l'UE/du Royaume-Uni traitant des données de résidents de l'UE), ou d'une autre loi de protection de la vie privée applicable ? Pour les fournisseurs traitant des catégories sensibles d'informations, données de santé, données financières, données biométriques, quels contrôles spécifiques s'appliquent-ils ?

2. Gouvernance et documentation des modèles. Le fournisseur peut-il fournir une fiche modèle (model card) ou une documentation technique décrivant l'usage prévu du modèle, les données d'entraînement, les limites connues et les caractéristiques de performance ? Le modèle a-t-il fait l'objet d'une évaluation indépendante des biais ? Quels groupes démographiques ont été utilisés lors des tests, et pour quelles tâches ? Le modèle fait-il l'objet d'un suivi continu par le fournisseur après le déploiement ? Quel est le processus du fournisseur pour identifier et traiter la dérive du modèle, les biais et la dégradation des performances ? Pour les systèmes d'IA à haut risque au sens de l'AI Act de l'UE, les fournisseurs doivent produire une documentation technique répondant aux exigences des articles 11 et 13, le fournisseur peut-il la fournir ?

3. Sécurité et résilience. Quel est le statut de certification de sécurité du fournisseur, SOC 2 Type II, ISO 27001, ou équivalent ? Le fournisseur a-t-il réalisé des tests adverses (adversarial testing) du système d'IA, y compris des tests d'injection de prompt pour les systèmes fondés sur des LLM ? Quels sont les engagements contractuels du fournisseur en matière de disponibilité pour les systèmes utilisés dans des opérations critiques ? Quel est le processus du fournisseur en matière de réponse aux incidents et de notification, en particulier, dans quel délai vous notifiera-t-il un incident de sécurité ou une défaillance importante du modèle ? La norme CPS 230 de l'APRA impose des obligations contractuelles de notification des incidents pour les prestataires de services essentiels.

4. Statut de conformité réglementaire. Dans quelles juridictions le fournisseur opère-t-il, et quelles obligations réglementaires reconnaît-il ? Le fournisseur a-t-il réalisé une évaluation de classification des risques au titre de l'AI Act de l'UE pour ses systèmes ? Pour les systèmes d'IA à haut risque relevant de l'annexe III, le fournisseur dispose-t-il d'une évaluation de conformité et du marquage CE (lorsque requis) ? Le système du fournisseur est-il enregistré dans la base de données de l'AI Act de l'UE pour les systèmes à haut risque ? Quelle est la position du fournisseur sur la responsabilité au titre de la réglementation applicable en matière d'IA, accepte-t-il les obligations incombant aux déployeurs ou cherche-t-il à décliner toute responsabilité réglementaire ?

5. Protections contractuelles. Plusieurs protections contractuelles sont soit légalement requises, soit essentielles sur le plan opérationnel. Requis au titre de la CPS 230 pour les entités réglementées par l'APRA ayant des prestataires de services essentiels : droits d'audit permettant à l'entité réglementée ou à son auditeur d'évaluer les contrôles du fournisseur ; délais de notification des incidents ; dispositions adéquates en matière de responsabilité ; et plans de sortie et de transition. Essentiel sur le plan opérationnel pour toute relation avec un fournisseur d'IA : propriété des résultats (qui détient le contenu ou les décisions produits par le système d'IA, l'organisation ou le fournisseur ?) ; usages interdits (qu'interdit la politique d'utilisation acceptable du fournisseur, et certaines de ces interdictions sont-elles incompatibles avec votre usage prévu ?) ; notification des changements (le fournisseur vous informera-t-il avant d'apporter des mises à jour du modèle susceptibles de modifier le comportement du système ?) ; et suppression des données à la résiliation.

Questions à poser aux fournisseurs d'IA avant l'achat

Voici les questions les plus importantes à poser directement à un fournisseur lors de l'évaluation préalable à l'achat. Elles visent à distinguer les fournisseurs ayant réellement investi dans la gouvernance de ceux qui se contentent d'arguments marketing :

Sur les données : « Si j'envoie des données clients via votre API, pouvez-vous confirmer qu'elles ne seront pas utilisées pour entraîner ou améliorer votre modèle ? Où sont-elles traitées, et pendant combien de temps sont-elles conservées ? Qui sont vos sous-traitants pour le traitement lié à l'IA ? »

Sur le comportement du modèle : « Pouvez-vous fournir une fiche modèle ou une documentation technique pour ce système ? Quels groupes démographiques étaient représentés dans vos tests de biais, et quels en ont été les résultats ? Quel est votre processus de détection et de traitement de la dérive du modèle après le déploiement ? »

Sur les incidents : « Quelle est votre définition d'un incident significatif pour ce système, et quel est votre engagement contractuel pour nous en informer ? Des incidents significatifs impliquant ce système sont-ils survenus au cours des 12 derniers mois ? »

Sur le statut réglementaire : « Avez-vous classé ce système selon le cadre de risque de l'AI Act de l'UE ? S'il est à haut risque, disposez-vous d'une documentation technique et d'une évaluation de conformité que nous pouvons examiner ? Quelle est votre position sur vos obligations en tant que fournisseur au titre de l'AI Act de l'UE, par rapport à nos obligations en tant que déployeur ? »

Sur la sortie : « À quoi ressemblent nos données et notre configuration de modèle à la résiliation ? Quelle est la période de transition, et quelle assistance fournissez-vous pour migrer vers un système alternatif ? »

Suivi continu, la diligence raisonnable n'est pas un exercice ponctuel

La diligence raisonnable sur l'IA des fournisseurs ne s'arrête pas à l'achat. Les attentes réglementaires exigent un suivi continu : la CPS 230 impose un examen et des tests réguliers des dispositifs mis en place avec les prestataires de services essentiels ; l'AI Act de l'UE impose une surveillance post-commercialisation des systèmes d'IA à haut risque par les déployeurs (article 72) ; et la lettre d'avril 2026 de l'APRA a spécifiquement signalé le risque de concentration lorsque des entités dépendent fortement d'un seul fournisseur d'IA pour de multiples cas d'usage.

Un cycle annuel d'examen des fournisseurs devrait couvrir : toute mise à jour du modèle effectuée depuis l'examen précédent et son impact sur le comportement du système ; les certifications de sécurité mises à jour ; le statut de conformité réglementaire au regard de l'évolution du droit ; l'historique des incidents et des quasi-incidents ; et le maintien de l'adéquation avec l'appétence au risque de l'organisation. Pour les prestataires de services essentiels relevant de la CPS 230, l'examen devrait également évaluer la chaîne des sous-traitants et des dépendances de quatrième niveau (fourth-party) du fournisseur, afin de détecter les changements susceptibles d'affecter le risque lié à la chaîne d'approvisionnement.

Pour aller plus loin

Pour aller plus loin : ISO/IEC 42001