Risques fournisseurs IA : gérer les tiers selon A.10

Pourquoi les tiers changent la donne en IA

Un système d'IA ne vit presque jamais en autarcie. Modèles pré-entraînés, jeux de données d'entraînement, API d'inférence hébergées, outils d'annotation, plateformes de déploiement : la chaîne de valeur d'un éditeur de solutions IA repose sur des composants fournis par des tiers dont le comportement échappe en partie à son contrôle. L'ISO/IEC 42001 couvre explicitement l'ensemble de cette chaîne, puisque son périmètre s'applique à toute organisation qui développe, fournit ou utilise des produits ou services intégrant des systèmes d'IA^[1].

Le risque tiers en IA se distingue du risque fournisseur classique en informatique. Un modèle de langage intégré via API peut dériver silencieusement après une mise à jour du fournisseur, sans que l'éditeur en soit informé. Des données d'entraînement fournies par un partenaire peuvent véhiculer des biais non documentés. L'ISO 42001 reconnaît cette double nature du risque IA : un risque pour l'organisation elle-même, mais aussi un risque pour les individus et la société touchés par le système^[5].

La pression du marché accélère la prise en compte de ce sujet. Selon Bright Defense, en septembre 2026, l'ISO 42001 est passée du statut de norme volontaire à celui d'exigence concrète dans les processus d'achat. Des fournisseurs majeurs comme AWS, Anthropic, Snowflake ou ServiceNow ont publié leur certification, et les acheteurs en entreprise demandent désormais des preuves de gouvernance IA avant tout déploiement^[4]. Pour un éditeur romand qui vend à des clients régulés, la gestion des risques fournisseurs n'est plus un exercice théorique.

Ce que la norme attend : l'Annexe A.10 décryptée

L'Annexe A de l'ISO 42001 regroupe 38 contrôles répartis en neuf catégories^[6]. La catégorie A.10 traite spécifiquement des relations avec les tiers impliqués dans le cycle de vie des systèmes d'IA. En substance, elle demande à l'organisation de définir et d'appliquer des mesures pour s'assurer que les fournisseurs, sous-traitants et partenaires respectent les exigences de son SMIA.

Concrètement, les contrôles A.10 couvrent, selon notre interprétation de la norme, trois axes. Le premier est l'identification des tiers intervenant dans la chaîne de valeur IA. Le deuxième porte sur l'évaluation et le traitement des risques liés à ces tiers. Le troisième concerne la surveillance continue et la documentation des preuves associées.

Ces contrôles ne fonctionnent pas de manière isolée. Ils s'inscrivent dans le processus global d'appréciation des risques défini à la clause 6, qui exige d'identifier, d'analyser et de traiter les risques liés aux systèmes d'IA^[5]. Les contrôles A.10 sont les mesures de traitement que l'organisation sélectionne dans sa déclaration d'applicabilité pour répondre aux risques tiers identifiés lors de cette appréciation.

Pour un éditeur de solutions IA, la portée de A.10 est large. Elle ne se limite pas aux fournisseurs de composants techniques. Elle peut inclure les prestataires de données d'entraînement, les fournisseurs d'infrastructure cloud, les partenaires d'intégration, voire les clients qui fournissent des données opérationnelles alimentant le système. L'élaboration de la déclaration d'applicabilité impose de justifier, pour chaque contrôle A.10, s'il est retenu ou exclu, et pourquoi.

Inventorier la chaîne d'approvisionnement IA

Avant de gérer un risque, il faut savoir d'où il vient. La première étape consiste à dresser un inventaire des tiers qui interviennent dans le cycle de vie de chaque système d'IA couvert par le périmètre du SMIA. L'ISO 42001 exige que l'organisation identifie et documente les ressources nécessaires aux activités du SMIA^[2], ce qui inclut les composants et services fournis par des tiers.

Cet inventaire doit être plus granulaire qu'un simple registre de fournisseurs IT. Pour chaque tiers, il convient de documenter la nature du composant ou service fourni (modèle, données, infrastructure, annotation, etc.), le rôle du tiers dans le cycle de vie du système IA (développement, entraînement, déploiement, opération), et le niveau d'accès aux données ou au système.

Catégories de tiers dans la chaîne de valeur IA

Type de tiers	Exemples	Risque principal
Fournisseur de modèle	API de LLM, modèle pré-entraîné	Dérive, opacité, dépendance
Fournisseur de données	Jeux de données, annotation	Biais, qualité, licéité
Hébergeur / cloud	Infrastructure GPU, plateforme MLOps	Localisation, disponibilité, confidentialité
Intégrateur / revendeur	Partenaire de déploiement	Mauvaise configuration, responsabilité floue

L'inventaire n'est pas un document figé. La norme impose un cycle d'amélioration continue (PDCA)^[1], ce qui signifie que cet inventaire doit être revu périodiquement, en particulier lorsqu'un nouveau fournisseur est intégré ou qu'un composant change de version. La cartographie des systèmes IA constitue le socle de ce travail.

Évaluer les risques de chaque fournisseur

Une fois l'inventaire établi, chaque relation fournisseur doit passer par le processus d'appréciation des risques défini à la clause 6.1.2. Ce processus, aligné sur l'ISO 31000 et l'ISO/IEC 23894, demande de définir des critères de risque, puis d'identifier, analyser et évaluer les risques^[5].

Pour les risques fournisseurs IA, les critères d'évaluation dépassent les dimensions habituelles de la sécurité de l'information. Il faut considérer la qualité et la provenance des données fournies, la transparence du fournisseur sur ses pratiques d'entraînement, sa capacité à documenter les limites connues de ses modèles, et les mécanismes de notification en cas de changement significatif (mise à jour de modèle, changement d'infrastructure, incident).

L'analyse d'impact des systèmes d'IA joue ici un rôle complémentaire. Lorsqu'un composant tiers affecte directement les sorties d'un système à haut risque, l'évaluation d'impact doit intégrer les scénarios de défaillance du fournisseur. Par exemple, si un modèle de scoring intègre une API tierce de vérification d'identité, l'impact d'une erreur de cette API sur les individus concernés doit être documenté.

Le registre des risques IA doit contenir une section dédiée aux risques tiers. Chaque risque identifié y est associé à un niveau de criticité, à un propriétaire, et à une mesure de traitement. Les contrôles A.10 constituent précisément ces mesures de traitement pour la catégorie des risques fournisseurs.

Les organisations qui définissent des critères de risque IA clairs en amont gagnent en cohérence lors de l'évaluation. Un fournisseur de modèle dont on ne peut pas auditer les données d'entraînement représente un risque résiduel différent d'un fournisseur d'infrastructure cloud certifié ISO 27001.

Clauses contractuelles et preuves auditables

L'évaluation des risques ne suffit pas. L'organisation doit traduire ses exigences en engagements contractuels vérifiables. La norme demande que les contrôles soient documentés et que leur efficacité soit mesurable^[8]. En pratique, cela signifie que les contrats avec les fournisseurs IA doivent contenir des clauses spécifiques.

Parmi les clauses que les démarches observées intègrent le plus souvent, on retrouve l'obligation de notification en cas de changement de modèle ou de données d'entraînement, le droit d'audit ou d'accès à des rapports d'audit tiers (SOC 2, ISO 27001, ISO 42001), les engagements sur la qualité et la provenance des données, les conditions de sous-traitance (le fournisseur peut-il lui-même recourir à des sous-traitants pour le composant IA ?), et les modalités de réversibilité.

Côté preuves, l'auditeur de certification s'attend à trouver un registre des fournisseurs IA à jour, les résultats des évaluations de risques fournisseurs, les contrats ou avenants contenant les clauses IA, les rapports d'audit ou certifications des fournisseurs, et les comptes-rendus de revues périodiques. L'ISO 42001 exige une documentation structurée de chaque décision de contrôle dans la déclaration d'applicabilité^[5]. Pour les contrôles A.10, cela implique de justifier pourquoi tel fournisseur fait l'objet d'un audit annuel et tel autre d'une simple revue documentaire.

Piège fréquent : la sous-traitance invisible

Le piège le plus courant dans la gestion des fournisseurs IA concerne la sous-traitance en cascade. Votre fournisseur de modèle utilise peut-être un service tiers pour l'hébergement, qui lui-même recourt à un fournisseur de GPU dans une juridiction que vous n'avez pas identifiée. Cette chaîne de sous-traitance crée des risques de localisation des données, de dépendance technologique et de perte de contrôle sur les conditions de traitement.

La norme couvre l'ensemble de la chaîne de valeur IA, du développement de composants jusqu'à l'exploitation^[1]. Si l'organisation ne cartographie pas les sous-traitants de ses fournisseurs, elle ne peut pas prétendre maîtriser ses risques tiers. L'auditeur posera la question.

Un autre piège concerne les mises à jour silencieuses. Lorsqu'un fournisseur de LLM met à jour son modèle sans notification, le comportement du système IA de l'éditeur peut changer de manière non anticipée. Les systèmes d'IA sont probabilistes et dépendants des données : leur comportement émerge de l'entraînement et peut se dégrader silencieusement^[5]. Sans clause de notification contractuelle et sans mécanisme de test de régression, l'éditeur découvre le problème par ses utilisateurs.

Lien avec les exigences de procurement et l'AI Act

La gestion des fournisseurs selon A.10 ne se joue pas uniquement dans le périmètre de l'ISO 42001. Elle s'inscrit dans un contexte réglementaire plus large, notamment celui de l'AI Act européen. Selon Bright Defense, le programme de normalisation de la Commission européenne couvre la gestion des risques, la gouvernance des données, la tenue de registres, la transparence, la supervision humaine et la gestion de la qualité^[4]. Plusieurs de ces exigences ont une dimension fournisseur directe.

L'ISO 42001 ne satisfait pas automatiquement l'AI Act^[4], mais elle fournit un cadre structuré pour organiser les preuves que le règlement demande. Pour un éditeur suisse qui exporte vers l'UE, la documentation des contrôles fournisseurs selon A.10 constitue une base solide pour démontrer la conformité aux obligations de la chaîne de valeur de l'AI Act.

La pression vient aussi du côté acheteur. Les entreprises régulées (finance, santé, secteur public) ne peuvent plus se fier aux déclarations marketing de leurs fournisseurs IA. Elles exigent des rapports d'audit, des périmètres de certification documentés et des conditions contractuelles qui soutiennent leur propre dossier de conformité^[4]. L'éditeur qui anticipe ces demandes en structurant sa gestion fournisseurs selon A.10 gagne un avantage concret lors des appels d'offres.

Pour approfondir le recouvrement entre ISO 42001 et AI Act, il convient de vérifier l'évolution des normes harmonisées, dont la citation au Journal officiel de l'UE n'était pas encore confirmée à la date de publication de cet article.

Exemple : un éditeur romand face à ses fournisseurs

Prenons le cas fictif d'un éditeur de logiciel basé en Suisse romande, qui développe une solution de tri automatisé de documents pour des cabinets d'avocats. Sa solution intègre trois composants tiers : une API de reconnaissance optique de caractères (OCR), un modèle de langage accessible via API pour la classification sémantique, et une plateforme cloud pour l'hébergement.

Pour se conformer à A.10, cet éditeur commence par inventorier ces trois fournisseurs dans son registre, en documentant pour chacun le composant fourni, le rôle dans le cycle de vie du système, et le niveau d'accès aux données des cabinets clients. Le fournisseur de LLM, par exemple, reçoit potentiellement des extraits de documents juridiques pour la classification : le risque de confidentialité est élevé.

L'évaluation des risques révèle que le fournisseur de LLM ne publie pas de détails sur ses données d'entraînement et ne notifie pas ses clients lors des mises à jour de modèle. L'éditeur inscrit ce risque dans son registre avec un niveau élevé et définit deux mesures de traitement : une clause contractuelle imposant la notification préalable de tout changement de modèle, et un test de régression automatisé déclenché à chaque nouvelle version détectée.

Pour le fournisseur d'infrastructure cloud, déjà certifié ISO 27001, l'éditeur juge le risque résiduel acceptable et documente cette décision dans sa déclaration d'applicabilité. Il conserve néanmoins une revue annuelle du certificat et des conditions de sous-traitance du fournisseur.

Ce type de démarche, proportionné à la taille de l'éditeur, répond aux attentes de la norme sans nécessiter un dispositif disproportionné. La norme s'applique à des organisations de toute taille^[1], et la profondeur des contrôles doit correspondre aux risques réels identifiés. L'évaluation des risques IA guide cette proportionnalité.

Questions fréquentes

À lire ensuite