Évaluation des risques fournisseurs d’IA : questionnaire, modèle de notation et liste des justificatifs (2026)
L’évaluation des risques fournisseurs d’IA est l’examen à mener avant qu’un produit ou une API d’IA tiers n’accède à vos données : vous classez le cas d’usage selon son niveau de risque, posez des questions propres à l’IA (entraînement sur vos données, conservation, sous-traitants et fournisseurs de modèles, tests de sécurité, risques liés aux réponses, réglementation), recueillez des justificatifs pour chaque réponse, attribuez une note au fournisseur, puis définissez les clauses contractuelles et le suivi. Par rapport à un examen classique des fournisseurs, l’IA introduit le comportement des modèles, la réutilisation des données et une chaîne de fournisseurs de modèles en aval. Ce guide propose un questionnaire prêt à l’emploi, un modèle de notation et une liste des justificatifs, à jour au 26 octobre 2026.
Il s’adresse aux équipes sécurité, achats et plateforme chargées d’approuver des API d’IA, des passerelles d’IA et des outils SaaS intégrant des fonctionnalités d’IA. Il ne constitue pas un avis juridique.
Pourquoi les risques fournisseurs d’IA sont différents
Un examen traditionnel des tiers porte sur le contrôle d’accès, le chiffrement, la disponibilité et les certifications. Pour les fournisseurs d’IA, il faut couvrir tous ces points, ainsi que les suivants :
| Nouveau risque | Pourquoi il compte | Exemple de question |
|---|---|---|
| Réutilisation des données pour l’entraînement | Vos prompts pourraient améliorer un modèle utilisé par d’autres | Les données clients sont-elles utilisées par défaut pour l’entraînement ou l’évaluation ? |
| Prestataires indirects | Le fournisseur peut transmettre les données à des fournisseurs de modèles | Quels fournisseurs de modèles traitent nos données, et dans quelles régions ? |
| Comportement des modèles | Les réponses peuvent être erronées, dangereuses ou divulguer des données | Comment le système est-il testé contre l’injection de prompt et les fuites de données ? |
| Évolution rapide | Les modèles et leurs versions changent sans préavis | Comment les changements de modèles sont-ils annoncés et versionnés ? |
| Réglementation | Le règlement européen sur l’IA et les règles sectorielles ajoutent des obligations | Comment classez-vous ce système au regard du règlement européen sur l’IA ? |
| Risque de dérive des coûts | Une tarification à l’usage peut entraîner une hausse brutale de la facture | Existe-t-il des quotas, des plafonds de dépenses et des alertes ? |
Le cadre de gestion des risques liés à l’IA du NIST couvre explicitement les risques liés à l’IA des tiers dans ses fonctions Govern et Map, et le profil du NIST pour l’IA générative (AI 600-1) recense les risques liés à la chaîne de valeur et à l’intégration des composants parmi les risques de l’IA générative.
Étape 1 : classer le fournisseur selon le cas d’usage
Tous les outils d’IA ne nécessitent pas le même niveau d’examen. Définissez d’abord le niveau de risque, puis adaptez le questionnaire.
| Niveau | Critères | Étendue de l’examen |
|---|---|---|
| Niveau 1 (élevé) | Données clients, données personnelles, données soumises à une réglementation, ou IA qui exécute des actions (envois, paiements, modification d’enregistrements) | Questionnaire complet, justificatifs, tests de sécurité, examen juridique |
| Niveau 2 (moyen) | Données internes, chaque réponse est vérifiée par une personne | Questionnaire de base + justificatifs essentiels |
| Niveau 3 (faible) | Données publiques uniquement, aucune intégration | Formulaire court + examen des conditions contractuelles |
Consignez le niveau et sa justification dans le dossier fournisseur. Réévaluez ce classement lorsque le cas d’usage change.
Étape 2 : envoyer le questionnaire sur les risques fournisseurs d’IA
Ajoutez ces questions à votre questionnaire de sécurité habituel (par exemple le SIG de Shared Assessments ou la matrice de contrôles de l’IA de la CSA).
Traitement des données et confidentialité
- Nos données (prompts, fichiers, réponses) servent-elles à entraîner ou à évaluer un modèle ? Quel est le réglage par défaut ? Peut-on s’y opposer ou obtenir un engagement contractuel ?
- Combien de temps les prompts, les réponses et les journaux sont-ils conservés ? Pouvons-nous définir une conservation nulle ou courte ?
- Où les données sont-elles traitées et stockées (régions) ? Pouvons-nous imposer une région ?
- Quels sous-traitants et fournisseurs de modèles reçoivent nos données ? Comment sommes-nous informés des changements ?
- Un accord de traitement des données (DPA) est-il disponible, et couvre-t-il les traitements par l’IA et les transferts internationaux ?
Gouvernance des modèles et du système
- Quels modèles le produit utilise-t-il, et s’agit-il de vos propres modèles ou de modèles tiers ?
- Comment les changements de modèles ou de versions sont-ils communiqués et testés ?
- Quelles évaluations réalisez-vous en matière d’exactitude, de biais et de sûreté, et pouvez-vous en partager les résultats ?
- Disposez-vous d’une documentation sur l’usage prévu et les limites connues (fiches de modèle ou de système) ?
Sécurité
- Quelles certifications ou attestations couvrent le service d’IA (SOC 2 Type II, ISO 27001, ISO 42001) ? Le produit d’IA entre-t-il dans leur périmètre ?
- Comment testez-vous l’injection de prompt, les fuites de données et l’autonomie excessive (par exemple selon le Top 10 de l’OWASP pour les applications LLM) ?
- Comment les clés API sont-elles créées, leurs permissions définies, puis les clés renouvelées et révoquées ?
- Que contiennent les journaux, qui peut y accéder et pouvons-nous les exporter ?
- Quels sont votre dispositif de réponse aux incidents liés à l’IA et vos délais de notification ?
Exploitation et coûts
- Quel est l’accord de niveau de service (SLA), et couvre-t-il les fonctionnalités d’IA et les fournisseurs de modèles en amont ?
- Que se passe-t-il lorsqu’un fournisseur de modèles en amont est indisponible : basculement, mode dégradé ou échec ?
- Existe-t-il des quotas par clé, des plafonds de dépenses et des alertes d’utilisation ?
- Quelles sont les conditions de sortie : export des données, confirmation de suppression, délais de préavis ?
Réglementation
- Comment classez-vous le système au regard du règlement européen sur l’IA, et quelles obligations remplissez-vous en tant que fournisseur ou en appui au déployeur ? Le calendrier de mise en application indique actuellement que les exigences relatives aux systèmes à haut risque de l’annexe III s’appliquent à partir du 2 décembre 2027.
- Les contenus générés par l’IA font-ils l’objet d’une information ou d’un marquage lorsque cela est obligatoire ?
Étape 3 : recueillir des justificatifs, au-delà des réponses
Chaque « oui » obtenu lors de l’examen d’un fournisseur de niveau 1 doit renvoyer à un élément que vous pouvez archiver.
| Réponse | Justificatifs à demander | Points à vérifier |
|---|---|---|
| « Nous n’entraînons pas nos modèles sur vos données » | Clause contractuelle, DPA, documentation du paramétrage du produit | Réglage par défaut ou opposition nécessaire ; couvre aussi les sous-traitants |
| « Les données sont conservées 30 jours » | Politique de conservation, capture d’écran du paramétrage administrateur | S’applique aux journaux et aux sauvegardes |
| « SOC 2 Type II » | Rapport sous accord de confidentialité, lettre de continuité de couverture | Service d’IA dans le périmètre ; date de fin de la période couverte ; exceptions |
| « Nous testons l’injection de prompt » | Synthèse des tests ou rapport de test d’intrusion | Date, périmètre, constats, nouveaux tests après correction |
| « Quotas par clé » | Documentation ou capture d’écran de la console ; votre propre test | Les limites bloquent effectivement les requêtes |
| « Fournisseurs de modèles répertoriés » | Liste des sous-traitants avec leurs régions | Correspond à vos besoins de résidence des données |
Un certificat est un élément de présélection, pas la preuve que votre cas d’usage est sûr. Pour les justificatifs propres aux passerelles, consultez les justificatifs SOC 2 pour une passerelle d’API d’IA, la liste de contrôle du DPA d’une passerelle d’IA et la liste de contrôle de la conservation des données d’API d’IA.
Étape 4 : noter le fournisseur
Attribuez une note de 1-5 à chaque domaine (5 = solide et étayé par des justificatifs), puis pondérez selon les priorités de votre cas d’usage :
| Domaine | Pondération (exemple de niveau 1) | Note 1 | Note 5 |
|---|---|---|---|
| Utilisation et conservation des données | 25% | Entraînement sur les données par défaut, conservation mal définie | Aucun entraînement, conservation paramétrable, engagements contractuels |
| Sécurité et tests | 25% | Aucun test propre à l’IA | Justificatifs récents de tests, avec nouveaux tests après correction |
| Prestataires indirects et résidence des données | 15% | Fournisseurs de modèles inconnus | Liste complète, régions, préavis de changement |
| Gouvernance et changements | 15% | Changements de modèles sans notification | Changements versionnés, annoncés et évalués |
| Exploitation et maîtrise des coûts | 10% | Aucun SLA, aucun quota | SLA, basculement, quotas, plafonds |
| Préparation réglementaire | 10% | Aucune position définie | Classification et obligations documentées |
Un script de notation simple à conserver dans le dossier fournisseur :
WEIGHTS = {"data": .25, "security": .25, "fourth_parties": .15,
"governance": .15, "operations": .10, "regulatory": .10}
def vendor_score(scores: dict, evidence: dict) -> dict:
"""scores: 1-5 per domain; evidence: True if the score is backed by filed evidence"""
capped = {d: (s if evidence.get(d) else min(s, 2)) for d, s in scores.items()} # no evidence -> max 2
total = sum(WEIGHTS[d] * capped[d] for d in WEIGHTS)
decision = "approve" if total >= 4 else "approve with conditions" if total >= 3 else "reject or escalate"
return {"score": round(total, 2), "decision": decision, "capped": capped}
print(vendor_score(
{"data": 5, "security": 4, "fourth_parties": 4, "governance": 3, "operations": 4, "regulatory": 3},
{"data": True, "security": True, "fourth_parties": True, "governance": False, "operations": True, "regulatory": False},
))
La règle de plafonnement est essentielle : une affirmation non étayée ne doit jamais obtenir une note aussi élevée qu’une affirmation vérifiée par un test.
Étape 5 : vérifier vous-même les affirmations à risque
Pour les fournisseurs de niveau 1, testez quelques points dans un environnement isolé avant de signer :
- Révocation des clés : révoquez une clé de test et vérifiez que les requêtes échouent immédiatement.
- Quotas : définissez un quota bas et vérifiez que les requêtes sont bloquées lorsqu’il est atteint.
- Liste des modèles autorisés : appelez un modèle qui ne devrait pas être autorisé et vérifiez que l’appel est refusé.
- Contenu des journaux : vérifiez ce qu’un journal de requêtes enregistre (métadonnées uniquement ou prompt complet).
# After revoking the test key in the vendor console, this should return 401
curl -s -o /dev/null -w "%{http_code}\n" https://api.vendor.example/v1/chat/completions \
-H "Authorization: Bearer $REVOKED_TEST_KEY" -H "Content-Type: application/json" \
-d '{"model":"any-model","messages":[{"role":"user","content":"ping"}]}'
Un questionnaire décrit les engagements déclarés du fournisseur ; ces tests en vérifient directement quelques-uns. Un test de sécurité complet de votre propre application d’IA constitue un travail distinct, abordé dans notre guide d’audit de sécurité de l’IA.
Étape 6 : inscrire les mesures de contrôle dans le contrat
| Clause | Objectif |
|---|---|
| Aucun entraînement sur les données clients (y compris par les sous-traitants) | Empêcher la réutilisation des données |
| Limite de conservation et suppression à la sortie | Limiter l’exposition |
| Préavis de changement de sous-traitant ou de fournisseur de modèles | Permettre de s’opposer à de nouveaux prestataires indirects |
| Délai de notification des violations de données et des incidents liés à l’IA | Accélérer la réponse |
| Droits d’audit et d’accès aux justificatifs | Permettre de vérifier à nouveau les affirmations |
| SLA couvrant les fonctionnalités d’IA | Rendre les engagements de disponibilité opposables |
| Résidence des données | Respecter les règles de transfert |
Étape 7 : assurer le suivi après approbation
- Réexaminez les fournisseurs de niveau 1 chaque année, ainsi que lorsqu’ils changent de modèles, de sous-traitants ou de conditions contractuelles.
- Suivez l’utilisation et les coûts par fournisseur et par clé.
- Surveillez les incidents et les avis de sécurité.
- Tenez une liste des modèles approuvés afin que tout nouveau modèle fasse l’objet d’un examen (processus d’approbation des modèles d’IA).
Évaluer une passerelle d’API d’IA en tant que fournisseur
Une passerelle se situe entre vos applications et plusieurs fournisseurs de modèles : évaluez donc les deux niveaux, à savoir la passerelle elle-même (clés, journaux, quotas, facturation, assistance) et chaque fournisseur en amont vers lequel elle achemine les requêtes. Demandez la liste des routes et précisez quelles données sont transmises à quels fournisseurs. Avec Flatkey, par exemple, vous pouvez consulter le modèle, les tokens, le coût et la clé de chaque requête dans le tableau de bord d’utilisation, exporter les journaux au format CSV/JSON comme justificatifs, et créer ou révoquer des clés par environnement dans la gestion des clés API. Ajoutez ces exports au dossier d’achat, à côté du questionnaire. Notre dossier de justificatifs pour l’achat d’une passerelle d’IA en présente la liste complète, et l’examen des justificatifs des fournisseurs de modèles couvre les fournisseurs en amont.
FAQ
Qu’est-ce qu’une évaluation des risques fournisseurs d’IA ?
C’est un examen structuré d’un produit ou d’une API d’IA tiers, réalisé avant approbation, qui vérifie l’utilisation des données, la sécurité, les fournisseurs de modèles indirects, la gouvernance, l’exploitation et la préparation réglementaire, à l’aide de justificatifs et d’une note de risque.
Quelles questions faut-il inclure dans un questionnaire fournisseur d’IA ?
Au minimum : l’utilisation éventuelle de vos données pour entraîner des modèles, la conservation, les régions de traitement, les sous-traitants et fournisseurs de modèles, les certifications couvrant le service d’IA, les tests de sécurité propres à l’IA, les contrôles sur les clés et les journaux, le SLA et le basculement, la maîtrise des coûts, les conditions de sortie et la classification au regard du règlement européen sur l’IA.
En quoi la gestion des risques fournisseurs d’IA diffère-t-elle de la gestion classique des risques liés aux tiers (TPRM) ?
L’IA ajoute la réutilisation des données pour l’entraînement, les fournisseurs de modèles indirects, des réponses de modèles imprévisibles, des changements fréquents de modèles et une réglementation propre à l’IA. Les contrôles habituels de gestion des risques liés aux tiers restent applicables.
L’IA peut-elle aider à gérer les risques fournisseurs ?
Oui, les outils d’IA peuvent synthétiser les questionnaires et signaler les justificatifs manquants, mais la décision d’approbation et la vérification des justificatifs doivent revenir à une personne, en particulier pour les fournisseurs de niveau 1.
Un rapport SOC 2 suffit-il pour approuver un fournisseur d’IA ?
Non. Vérifiez que le périmètre et la période couverte par le rapport incluent bien le service d’IA, puis posez tout de même des questions propres à l’IA sur l’entraînement, la conservation, les fournisseurs de modèles et les tests. La présentation de SOC 2 par l’AICPA explique ce que couvre un rapport SOC 2.
Quels référentiels aident à évaluer les risques fournisseurs d’IA ?
Le NIST AI RMF et son profil pour l’IA générative, le Top 10 LLM de l’OWASP pour les risques techniques, la matrice de contrôles de l’IA de la CSA, ISO/IEC 42001 pour les systèmes de management de l’IA et le questionnaire SIG de Shared Assessments.
Sources
Vérifiées le 26 octobre 2026 : NIST AI RMF, NIST AI 600-1, Top 10 de l’OWASP pour les applications LLM, matrice de contrôles de l’IA de la CSA, SIG de Shared Assessments, calendrier du règlement européen sur l’IA, liste de contrôle RGPD pour une passerelle d’API d’IA.
