Évaluation des fournisseurs d’IA : les 12 questions oubliées

L’essentiel

• L’évaluation des fournisseurs a été bâtie pour une chaîne d’approvisionnement qui livrait des logiciels figés. Elle établit qu’un prestataire est solvable, assuré et certifié, mais ne dit rien des données d’entraînement d’un modèle ni de la manière dont celui-ci évoluera après la signature.
• L’article 25(4) du règlement européen sur l’IA transforme cette diligence en obligation juridique dès lors que le système est à haut risque. Un accord écrit doit préciser les informations, les capacités et l’accès technique nécessaires.
• L’article 25(1) contient le piège que la plupart des acheteurs ignorent : apposer sa marque, modifier substantiellement le système ou en détourner la finalité vous érige en fournisseur.
• La norme ISO/IEC 42001 (A.10.3) et le NIST AI RMF (GOVERN 6.1) convergent sur un principe simple : la responsabilité ne se transfère pas au prestataire.
• Le bon déclencheur d’un réexamen n’est pas la date anniversaire du contrat, mais le changement de version du modèle.

Ce que couvre aujourd’hui l’évaluation des fournisseurs

Interrogez n’importe quelle plateforme de gestion des risques tiers sur le contenu d’une revue et vous obtiendrez la même réponse. L’évaluation des fournisseurs désigne le processus précontractuel qui consiste à vérifier qu’un tiers peut se voir confier une fonction métier. La grille canonique compte six ou sept rubriques : structure juridique et capitalistique, bénéficiaires effectifs, solidité financière, attestations de sécurité et de confidentialité du type SOC 2 ou ISO/IEC 27001, résilience opérationnelle et continuité d’activité, enfin criblage réglementaire portant sur les sanctions, les contentieux et la réputation. Les programmes matures commencent par hiérarchiser les prestataires selon leur criticité, de sorte qu’un gestionnaire de paie fasse l’objet d’un examen plus poussé qu’un fournisseur de papeterie. Ils collectent ensuite les preuves, les confrontent à une appétence au risque définie et fixent une périodicité de réexamen dès l’entrée en relation. Rien de tout cela n’est erroné. Il s’agit d’un processus solide, affiné par vingt ans d’externalisation, et il reste le socle de toute démarche de gouvernance de l’IA. Le problème est plus circonscrit : chacune de ces rubriques décrit l’entreprise à laquelle vous achetez. Aucune ne décrit le modèle que vous achetez.

Due diligence fournisseur et due diligence commerciale

La confusion entre les deux notions est fréquente. La due diligence commerciale cherche à établir si le marché, le portefeuille clients et les revenus d’une cible justifient une valorisation : elle relève d’une opération de fusion-acquisition. L’évaluation des fournisseurs, elle, cherche à établir si un prestataire peut délivrer un service sans importer un risque inacceptable dans vos opérations. Dans le vocabulaire des transactions, la même expression désigne parfois un rapport qu’un vendeur commande sur lui-même pour accélérer une cession. C’est le premier sens, celui du risque tiers, qui nous intéresse ici.

Pourquoi la checklist standard échoue face à un fournisseur d’IA

Un rapport SOC 2 de type II est l’opinion d’un auditeur selon laquelle une entreprise a appliqué des contrôles annoncés sur une période donnée. Il vous apprend que les locaux sont fermés, que les accès sont revus et que les sauvegardes sont testées. Il ne vous apprend rien sur les données ayant servi à entraîner le modèle, sur la licence attachée à ces données, sur les populations auprès desquelles le modèle a été évalué, ni sur ce qui a changé dans son comportement lors de la dernière mise à jour. Ce sont des questions d’une autre nature, portant sur un autre objet, et le questionnaire standard ne les pose pas. Quatre propriétés des fournisseurs d’IA mettent en défaut la revue traditionnelle. Le produit n’est pas déterministe. Un logiciel classique renvoie le même résultat pour la même entrée, si bien qu’un test unique suffit à caractériser son comportement. Un modèle d’IA n’offre pas cette garantie. La preuve apportée par une phase pilote a donc une valeur probante inférieure à celle d’un test équivalent sur un outil déterministe, et une revue conçue autour d’une recette ponctuelle surestime silencieusement ce qu’elle a démontré. Le produit change sans que le contrat change. Les éditeurs réentraînent leurs modèles, remplacent le modèle de base et ajustent les instructions système en continu. Un système validé en mars peut se comporter différemment en juin, sans avenant, sans préavis et sans nouvelle attestation. Les achats traditionnels n’ont pas prévu d’événement pour cela, puisque le logiciel classique se livrait par versions annoncées sur une feuille de route visible. La chaîne va plus loin que votre registre. Votre prestataire n’est souvent qu’une couche applicative posée sur le modèle de fondation d’un tiers, lui-même hébergé par un quatrième acteur. L’exposition au risque de rang n n’a rien de nouveau, mais dans l’IA le sous-traitant détermine le comportement de ce que vous avez acheté, et pas seulement sa disponibilité. Or la plupart des registres fournisseurs s’arrêtent à la contrepartie directe. La transparence bute sur le secret des affaires. Le NIST observe que les éditeurs refusent régulièrement de communiquer la composition de leurs données d’entraînement, leur architecture ou leurs résultats d’évaluation, au motif de la confidentialité commerciale, et que le contrôle GOVERN 6.1 relatif aux tiers figure parmi ceux qui échouent le plus souvent lors d’audits indépendants. Ce refus constitue en soi une conclusion d’audit, et une revue qui traite « le fournisseur n’a pas répondu » comme une case vide plutôt que comme une cotation de risque ne remplit pas son office. Une cinquième difficulté échappe entièrement au questionnaire. Les éditeurs ajoutent des fonctions d’IA à des outils que vous possédez déjà, de sorte que l’IA entre dans l’organisation par un renouvellement et non par un achat. C’est le visage contractuel du shadow AI, et aucune rigueur précontractuelle ne le détecte si rien ne vient rouvrir le dossier.

L’obligation juridique que la plupart des acheteurs ignorent : l’article 25 du règlement IA

La littérature du secteur présente l’examen des prestataires comme une saine pratique de gestion des risques. Pour une large part des déploiements européens, il s’agit désormais d’une obligation juridique rattachée à un article précis, ce qui modifie à la fois l’urgence et la nature des preuves à conserver.

L’exigence d’accord écrit

L’article 25(4) dispose que le fournisseur d’un système d’IA à haut risque et le tiers qui lui fournit un système, des outils, des services, des composants ou des processus intégrés à ce système précisent, par accord écrit, les informations, les capacités, l’accès technique et l’assistance nécessaires au respect du règlement, sur la base de l’état de l’art généralement reconnu. Il faut lire cette disposition comme une consigne d’achat. Si vous construisez ou mettez sur le marché un système à haut risque dont une partie provient de l’extérieur, le flux d’informations correspondant doit figurer au contrat. L’assurance verbale d’un ingénieur avant-vente n’y suffit pas, pas davantage qu’un questionnaire rempli dormant sur un espace partagé. L’obligation consiste à avoir convenu par écrit, avant d’en avoir besoin, de ce que le prestataire vous communiquera et de l’accès qu’il vous ouvrira.

Quand l’acheteur devient fournisseur au sens du règlement

L’article 25(1) est la disposition qui transforme une décision d’achat en engagement de conformité. Un distributeur, un importateur, un déployeur ou tout autre tiers est réputé fournisseur d’un système à haut risque, et se voit appliquer les obligations de l’article 16, dans trois cas : lorsqu’il appose son nom ou sa marque sur un système à haut risque déjà mis sur le marché, lorsqu’il apporte une modification substantielle à un tel système, ou lorsqu’il modifie la destination d’un système qui n’était pas à haut risque de telle sorte qu’il le devienne. Chacune de ces branches décrit une pratique courante que personne ne perçoit comme un acte réglementaire. La commercialisation en marque blanche d’une solution achetée relève du point a). Un affinage sur vos propres données, poussé au point de sortir du périmètre de l’évaluation de conformité initiale, relève du point b). Réorienter un outil de tri généraliste vers des décisions de recrutement relève du point c). L’article 3(23) définit la modification substantielle comme un changement non prévu dans l’évaluation de conformité initiale, qui affecte la conformité aux exigences du chapitre III section 2 ou qui modifie la destination du système. Pour les modèles à usage général, les orientations de la Commission proposent un repère quantitatif indicatif : un affinage mobilisant plus du tiers environ de la puissance de calcul d’entraînement initiale tend à faire assumer au tiers les obligations de fournisseur sur le modèle modifié. Notre guide de l’IA à usage général détaille l’articulation de ces obligations amont avec les vôtres. Pour la revue, la conséquence pratique tient en une question à inscrire au questionnaire : « prévoyons-nous de modifier ce système ? ». La réponse détermine le régime d’obligations que vous achetez. Les travaux académiques sur les systèmes agentiques, notamment AI Agents Under EU Law, relèvent que la dérive comportementale en exécution s’accommode mal de la frontière posée par l’article 3(23), un système qui modifie son propre comportement après déploiement pouvant franchir une ligne que les rédacteurs imaginaient franchie délibérément par un humain.

Ce que le fournisseur initial vous doit

L’obligation n’est pas à sens unique. L’article 25(2) impose au fournisseur initial de coopérer étroitement avec tout nouveau fournisseur, en mettant à disposition les informations nécessaires ainsi que l’accès technique et l’assistance raisonnablement attendus, en particulier pour l’évaluation de conformité. Si le contrat de votre prestataire écarte purement et simplement cette coopération, la clause entre en tension avec le règlement : il est légitime de la soulever en négociation plutôt que de l’accepter comme une mention de style. Le guide opérationnel du règlement IA précise la répartition générale des rôles de fournisseur et de déployeur.

Ce qu’exigent l’ISO 42001, le NIST AI RMF et DORA en matière d’évaluation des fournisseurs

Trois référentiels abordent la gestion des prestataires par des voies distinctes, et une évaluation qui satisfait les trois se défend dans la plupart des juridictions.

ISO/IEC 42001 : la responsabilité ne se transfère pas

Le contrôle A.10 de l’annexe A régit les relations avec les tiers et les clients. Le contrôle A.10.2 impose de répartir clairement les rôles et responsabilités entre toutes les parties externes intervenant dans le cycle de vie du système d’IA, qu’il s’agisse des fournisseurs de données, des concepteurs de modèles, des éditeurs de plateformes ou des intégrateurs, afin qu’aucune obligation ne tombe dans l’interstice entre deux organisations persuadées chacune que l’autre s’en chargeait. Le contrôle A.10.3 impose une gestion active des fournisseurs d’IA, de sorte que les modèles, jeux de données et composants acquis restent alignés sur vos objectifs d’IA responsable, avec pour preuves des évaluations de prestataires et des clauses contractuelles portant sur la transparence et les biais. Le principe qui sous-tend ces deux contrôles compte davantage que leur lettre : la responsabilité ne se transfère pas. Vous restez comptable du résultat même lorsque le prestataire en est la cause. Notre présentation de l’ISO 42001 situe l’annexe A dans l’ensemble du système de management.

NIST AI RMF : le contrôle qui fait échouer les audits

La fonction GOVERN 6 traite des risques induits par les logiciels, les données et la chaîne d’approvisionnement de tiers. Le contrôle GOVERN 6.1 étend votre gouvernance aux modèles de prestataires, aux interfaces applicatives externes, aux jeux de données pré-entraînés et aux composants open source. Il énonce sans ambiguïté que l’exposition juridique liée à la contrefaçon de propriété intellectuelle, aux données d’entraînement protégées par le droit d’auteur et aux atteintes à la vie privée incorporées dans un modèle tiers demeure celle de l’organisation qui le déploie. Le contrôle GOVERN 6.2 exige des dispositifs de continuité en cas de défaillance d’un tiers, incluant des solutions de repli et des critères de retrait du service. Notre guide du NIST AI RMF en présente l’architecture complète.

DORA : le registre et les clauses obligatoires

Les entités financières supportent une couche supplémentaire. Le règlement DORA, applicable depuis le 17 janvier 2025, impose aux articles 28 à 30 la tenue d’un registre d’informations recensant chaque accord contractuel avec un prestataire tiers de services TIC, en distinguant ceux qui soutiennent des fonctions critiques ou importantes. L’article 30 fixe les clauses devant figurer dans ces contrats : description du service et niveaux de performance, localisation des données, notification des changements, droits d’audit, notification des incidents, continuité d’activité et droits de résiliation. Les fournisseurs d’IA et de grands modèles de langage peuvent entrer dans ce périmètre en qualité de prestataires tiers de services TIC. En novembre 2025, les autorités européennes de surveillance ont désigné les dix-neuf premiers prestataires tiers critiques, une liste dominée par les plateformes cloud sur lesquelles reposent la plupart des services d’IA. En France, l’ACPR relaie ces attentes auprès des établissements assujettis, tandis que la CNIL et l’ANSSI couvrent respectivement le volet données personnelles et le volet sécurité.

Les 12 questions à ajouter à votre questionnaire d’évaluation des fournisseurs

Ces questions viennent compléter vos rubriques existantes de sécurité, de solidité financière et de continuité, sans s’y substituer. Pour chacune, l’intérêt réside dans la preuve attendue, non dans la réponse elle-même. Le découpage ci-dessous reprend celui du guide sous licence ouverte AI Vendor Security and Safety Assessment Guide de Dennis Ah-king, conçu pour s’insérer dans un dispositif de gestion des risques tiers existant.

Provenance et données

1. Sur quelles données le modèle a-t-il été entraîné, et sous quelle licence ? Attendez une déclaration documentée nommant les sources et le fondement juridique de leur usage. « Données publiquement disponibles » n’est pas une réponse. 2. Nos données servent-elles à entraîner vos modèles, par défaut ou sur option ? Attendez un engagement contractuel, pas une capture d’écran de paramétrage. Vérifiez si la valeur par défaut change au renouvellement. 3. Quels sous-traitants et quels fournisseurs de modèles interviennent derrière ce service ? Attendez une liste nominative assortie d’un engagement de notification. Si le prestataire revend un modèle de fondation, les conditions du fournisseur amont vous concernent aussi.

Comportement du modèle et évolutions

4. Quelles évaluations ont été menées, sur quelles populations, avec quels résultats ? Attendez des rapports présentant des résultats ventilés. Une précision globale masque précisément les défaillances qui créent l’exposition juridique. 5. Comment nous notifierez-vous un changement de version du modèle, et avec quel préavis ? Attendez un délai et un canal définis. C’est la réponse la plus précieuse de toute la liste. 6. Comment détectez-vous et signalez-vous la dérive des performances après déploiement ? Attendez une surveillance dont vous voyez les résultats, idéalement un indicateur que vous recevez plutôt qu’un tableau de bord qu’ils consultent. 7. Quelle est la destination du système telle que vous l’avez évaluée ? Attendez une déclaration écrite. Un usage prévu qui s’en écarte constitue le chemin le plus rapide vers les obligations de fournisseur.

Chaîne et dépendances

8. Ce système est-il classé à haut risque au sens du règlement IA, et sur quel fondement ? Attendez une classification motivée. Un désaccord sur ce point mérite d’être arbitré avant signature. 9. Si nous affinons le modèle ou apposons notre marque, comment la répartition des responsabilités évolue-t-elle ? Attendez une réponse qui traite explicitement de l’article 25. Un prestataire qui n’y a pas réfléchi vous renseigne déjà. 10. Quelle documentation technique fournirez-vous, et sera-t-elle tenue à jour ? Attendez un engagement aligné sur ce que vous devez vous-même à votre autorité de contrôle. Notre guide de la documentation des systèmes d’IA en fixe le socle.

Preuves et réversibilité

11. De quels droits d’audit disposons-nous, et s’étendent-ils à votre fournisseur de modèle ? Attendez des droits qui franchissent la frontière du sous-traitant, puisque c’est là que le comportement se détermine réellement. 12. À la résiliation, qu’advient-il de nos données, des poids affinés et des vecteurs d’embarquement ? Attendez un engagement de suppression couvrant les artefacts dérivés, et pas seulement les enregistrements sources. Lorsqu’un prestataire refuse de répondre, consignez le refus, cotez le risque résiduel et transmettez-le à celui qui porte l’acceptation du risque. Une question déclinée est un résultat.

Les clauses contractuelles qui rendent les réponses opposables

Les réponses à un questionnaire n’engagent personne. Les clauses qui les transforment en obligations sont précisément celles qui manquent le plus souvent aux contrats d’IA, parce qu’un contrat logiciel généraliste n’a pas été rédigé pour un produit non déterministe. Les guides destinés aux juristes qui négocient avec des éditeurs d’IA identifient invariablement le même ensemble : restriction de l’usage des données clients à des fins d’entraînement, propriété et licence des productions du modèle, droits de notification et d’approbation sur les changements de modèle, consentement sur les sous-traitants et les fournisseurs de modèles, droits d’audit atteignant le fournisseur amont, obligations de test et de correction des biais, niveaux de service adaptés à une production probabiliste, enfin stipulations de réversibilité couvrant les poids affinés et les vecteurs autant que les enregistrements stockés. Deux méritent une attention particulière. Les clauses de modification unilatérale, banales dans les contrats logiciels, changent de portée lorsque l’objet modifié est le modèle lui-même. Et les plafonds de responsabilité calés sur douze mois de redevances ont été calibrés pour des interruptions de service, non pour une condamnation pour discrimination née d’un modèle que vous n’avez pas construit. Notre guide de la conformité IA replace ces éléments dans un dispositif d’ensemble.

Réexamen : les événements qui doivent rouvrir le dossier

La plupart des programmes réexaminent leurs prestataires une fois par an, ou au renouvellement du contrat. Pour un fournisseur d’IA, cette périodicité est décalée par rapport au risque, puisque l’objet examiné évolue au rythme des livraisons de l’éditeur et non de votre calendrier d’achats. Remplacez ou complétez le calendrier par des déclencheurs événementiels :

• Un changement de version du modèle, ou un changement de modèle de fondation sous-jacent
• L’entrée d’un nouveau sous-traitant ou d’un nouveau fournisseur de modèle dans la chaîne
• Une extension de capacités, en particulier lorsqu’elle ouvre au système de nouvelles actions ou de nouveaux outils
• Une modification de la destination déclarée, du fait de l’une ou l’autre partie
• Toute décision de votre côté d’affiner le modèle, d’y apposer votre marque ou de réorienter le système, qui active l’article 25(1)
• Un incident à signaler, chez le prestataire comme dans votre propre déploiement
• Une dérive mesurée franchissant un seuil défini à l’entrée en relation

Les deux derniers relient ce processus à des contrôles que vous exploitez peut-être déjà, ceux décrits dans notre guide de la gestion des risques liés à l’IA. Rattacher la revue des prestataires à ces signaux, plutôt qu’à une date, est ce qui rend le dispositif réactif au comportement réel des fournisseurs d’IA.

Questions fréquentes

Quelle différence entre due diligence client et due diligence fournisseur ? La due diligence client relève de la lutte contre le blanchiment : vérifier l’identité d’un client, ses bénéficiaires effectifs et son statut au regard des sanctions avant l’entrée en relation, sous l’impulsion de la réglementation financière. L’évaluation des fournisseurs suit le chemin inverse et porte sur un prestataire dont vous allez dépendre. Les deux partagent des techniques de criblage et souvent les mêmes bases de données, d’où la confusion, mais elles répondent à des questions distinctes devant des autorités distinctes. Quelle différence entre évaluation des fournisseurs et due diligence commerciale ? La due diligence commerciale détermine si une entreprise vaut le prix qu’un acquéreur s’apprête à payer, en examinant sa position de marché, la concentration de son portefeuille et la qualité de ses revenus : elle appartient au monde des transactions. L’évaluation des fournisseurs détermine si un prestataire peut délivrer sans importer un risque inacceptable dans vos opérations : elle appartient aux achats et à la gestion des risques tiers. Un rapport SOC 2 suffit-il pour un fournisseur d’IA ? Non. Un rapport SOC 2 est une opinion sur l’application effective de contrôles annoncés pendant une période : gestion des accès, gestion des changements, supervision. Il est utile et ne dit rien de la provenance des données d’entraînement, des résultats d’évaluation, des tests de biais ni de la gestion des versions du modèle. Considérez-le comme nécessaire mais insuffisant, et ajoutez les questions propres au modèle. À quel moment l’achat d’un système d’IA fait-il de nous son fournisseur ? Au titre de l’article 25(1) du règlement IA, dans trois situations : vous apposez votre nom ou votre marque sur un système à haut risque déjà mis sur le marché, vous lui apportez une modification substantielle, ou vous modifiez la destination d’un système au point de le rendre à haut risque. Chacune vous transfère les obligations de fournisseur de l’article 16, dont le système de gestion de la qualité, la documentation technique et l’évaluation de conformité. À quelle fréquence réexaminer un fournisseur d’IA ? Conservez une revue annuelle pour les volets continuité et solidité financière, et ajoutez des déclencheurs événementiels pour tout ce qui touche au modèle. Un changement de version, un nouveau sous-traitant, une extension de capacités, un incident ou une dérive mesurée doivent rouvrir le dossier indépendamment de la date du dernier examen. Réexaminer un prestataire sur la seule base du calendrier revient à évaluer un système qui n’est peut-être plus celui que vous aviez évalué. Que faire si un fournisseur refuse de communiquer ses données d’entraînement ? Consignez le refus comme une conclusion et non comme une question restée sans réponse, puis cotez le risque résiduel en conséquence. Le NIST traite la non-divulgation au titre du secret des affaires comme une caractéristique reconnue de ce marché, non comme une anomalie. Des positions acceptables existent : une garantie contractuelle couvrant les réclamations de propriété intellectuelle et de vie privée nées des données d’entraînement, une attestation de tiers, ou une garantie plus étroite portant sur le fondement juridique des licences plutôt que sur la divulgation complète.

Conclusion

La discipline dispose d’un bon processus. Vingt ans de gestion des risques tiers ont produit une revue qui établit de façon fiable si un prestataire existera encore l’an prochain et si son réseau interne tient la route. Ce qu’elle n’a jamais été conçue pour faire, c’est décrire un modèle : d’où viennent ses données d’entraînement, comment il se comporte face aux personnes que vous servez, et ce qui a changé en lui la semaine dernière. L’article 25(4) a déjà transformé cet écart en question juridique pour les déploiements à haut risque en Europe, et l’ISO/IEC 42001 comme le NIST AI RMF y parviennent par la gouvernance plutôt que par la loi. Le remède ne consiste pas à bâtir un nouveau programme. Il tient en douze questions supplémentaires, quelques clauses qui rendent les réponses opposables, et un déclencheur qui se déclenche sur un changement de version plutôt que sur une date. Pour situer la preuve fournisseur dans un ensemble de contrôles plus large, commencez par notre guide du risque IA.