La plupart des solutions d’IA d’entreprise ne sont pas développées en interne. Selon Gartner, d’ici 2025, plus de 70 % des organisations devaient avoir adopté au moins une forme d’IA fournie par un prestataire tiers [1]. Ce chiffre n’a fait qu’augmenter. Pourtant, les cadres de gouvernance sur lesquels s’appuient la plupart des organisations ont été conçus pour des logiciels qu’elles contrôlent, et non pour des systèmes probabilistes entraînés sur des données qu’elles n’ont jamais vues, mis à jour selon des calendriers qu’elles ne définissent pas, et fonctionnant selon une logique qui peut rester opaque même pour le fournisseur lui-même.

Le paysage réglementaire s’est aligné sur cette réalité. L’EU AI Act, qui est entré dans sa période d’application progressive en 2025, établit une distinction claire entre les fournisseurs (ceux qui développent ou mettent un système d’IA sur le marché) et les déployeurs (ceux qui l’utilisent sous leur propre autorité). Mais cette distinction ne dégage pas les déployeurs de leurs responsabilités. L’article 26 précise clairement que les déployeurs de systèmes d’IA à haut risque assument des obligations spécifiques en matière de supervision humaine, de qualité des données d’entrée, de surveillance et de tenue des registres [2]. La vérité inconfortable pour les équipes achats et conformité est la suivante : la responsabilité réglementaire ne se transfère pas au fournisseur simplement parce qu’il a construit le modèle.

Ce guide propose un cadre structuré d’évaluation des risques liés aux fournisseurs d’IA, de la due diligence initiale au suivi continu.

Pourquoi les risques liés à l’IA tierce exigent une approche différente

La gestion traditionnelle des risques fournisseurs évalue la disponibilité, la sécurité des données et les accords de niveau de service contractuels. Ces éléments restent nécessaires pour les fournisseurs d’IA, mais ils ne sont pas suffisants. Les systèmes d’IA introduisent une catégorie de risque que l’approvisionnement informatique conventionnel n’a jamais été conçu pour traiter.

Trois caractéristiques rendent l’IA tierce fondamentalement différente des autres logiciels :

Opacité de la logique de décision. Une application SaaS conventionnelle exécute un code déterministe. Un système d’IA peut produire des résultats façonnés par les données d’entraînement, les choix d’ajustement fin et les paramètres d’inférence, sur lesquels l’organisation déployante n’a aucune visibilité. Lorsqu’un modèle de notation de crédit refuse une demande ou qu’un outil de présélection RH classe des candidats, le déployeur doit pouvoir expliquer cette décision. Si le fournisseur ne peut pas fournir une explication pertinente, le déployeur se retrouve responsable de résultats qu’il ne peut pas interpréter.

Comportement non statique. Les logiciels traditionnels évoluent par versions publiées. Les modèles d’IA peuvent modifier leur comportement à la suite d’un réentraînement, d’un ajustement fin ou de changements apportés aux pipelines de données sous-jacents, parfois sans cycle de publication formel. Un modèle qui fonctionnait dans des paramètres acceptables lors de l’approvisionnement peut dériver au cours des mois suivants. Le déployeur peut ne s’en apercevoir qu’après la survenue d’un dommage.

Risque hérité des données. Les données d’entraînement qui façonnent le comportement d’un modèle peuvent contenir des biais, des contenus protégés par le droit d’auteur ou des données personnelles traitées sans base juridique adéquate. Le déployeur hérite des conséquences de ces choix en amont, bien qu’il n’y ait pris aucune part. En vertu du RGPD, si un système d’IA traite des données à caractère personnel d’une manière incompatible avec les accords de traitement des données du déployeur, celui-ci supporte, aux côtés du fournisseur, le risque d’exécution des mesures de contrôle [3].

Les tableaux de bord fournisseurs classiques ne capturent pas ces dynamiques. Un cadre d’évaluation spécialement conçu à cette fin est essentiel.

Un cadre structuré d’évaluation des risques liés aux fournisseurs d’IA

Le cadre suivant organise l’évaluation des fournisseurs d’IA en sept domaines. Chaque domaine correspond à une préoccupation de gouvernance spécifique et peut être noté lors de l’approvisionnement, d’un examen périodique ou d’une réévaluation déclenchée par un événement.

Les organisations qui utilisent des plateformes comme Enzai peuvent intégrer ce cadre dans les flux de travail existants du cycle de vie des fournisseurs, garantissant ainsi que les critères spécifiques à l’IA s’ajoutent aux indicateurs traditionnels de risque informatique plutôt que de constituer un processus séparé et déconnecté.

Questionnaire d’évaluation

Ce tableau doit être considéré comme un instrument évolutif. Les seuils de notation varieront selon le cas d’usage : un système d’IA à haut risque utilisé dans le triage médical exige une transparence bien plus stricte qu’un outil de recommandation de contenu à faible risque.

Questions clés à poser aux fournisseurs

Un questionnaire ne fonctionne que si les questions sont suffisamment précises pour mettre en évidence un risque réel. Les questions vagues appellent des réponses vagues. Les questions suivantes, organisées par catégorie, sont conçues pour produire des réponses exploitables.

Transparence et explicabilité du modèle

1. Quelle architecture de modèle ce système utilise-t-il, et quelle version est actuellement déployée en production ?

2. Pouvez-vous fournir une fiche de modèle ou une fiche technique décrivant les cas d’usage prévus, les limites connues et les références de performance ?

3. Quelles méthodes sont disponibles pour expliquer les prédictions ou décisions individuelles aux personnes concernées ?

4. Si le modèle repose sur un modèle de fondation fourni par un tiers (par ex. un fournisseur de LLM), pouvez-vous divulguer quel modèle de fondation et quelle version vous utilisez ?

Gouvernance des données et confidentialité

1. Quelles bases de données ont été utilisées pour entraîner et valider ce modèle, et pouvez-vous fournir un registre de provenance des données ?

2. Quelle est la base juridique, au titre du RGPD (ou d’une réglementation équivalente), pour le traitement des données personnelles lors de l’entraînement ?

3. Le modèle conserve-t-il, mémorise-t-il ou reproduit-il des données d’entraînement lors de l’inférence ? Quelles garanties empêchent toute fuite de données ?

4. Comment les données client sont-elles utilisées après le déploiement - sont-elles réinjectées dans l’entraînement du modèle, et le client peut-il s’y opposer ?

Biais, équité et sécurité

1. Ce modèle a-t-il fait l’objet d’un audit des biais couvrant les caractéristiques protégées définies par la législation anti-discrimination applicable ?

2. Qui a réalisé l’audit, et les résultats sont-ils disponibles à l’examen ?

3. Quel dispositif de surveillance continue est en place pour détecter les biais émergents ou la dégradation des performances entre sous-groupes ?

4. Pour les systèmes d’IA générative : quelles mesures de protection empêchent la génération de résultats nuisibles, trompeurs ou juridiquement problématiques ?

Sécurité et résilience

1. Quelles protections spécifiques sont en place contre les attaques adversariales, l’injection de prompt, l’inversion du modèle ou l’extraction des données d’entraînement ?

2. Le système a-t-il fait l’objet de tests d’intrusion ou d’exercices de red teaming spécifiques à l’IA, au-delà des tests de sécurité applicative standards ?

3. Quel est le plan de reprise après sinistre et de continuité d’activité spécifique aux composants d’IA de ce service ?

Conformité et préparation réglementaire

1. Ce système a-t-il été classé selon les catégories de risque de l’EU AI Act, et si oui, quelle classification a-t-il reçue ?

2. Pouvez-vous fournir la documentation d’une évaluation de conformité pour les systèmes d’IA à haut risque, comme l’exige l’article 43 ?

3. Quel est votre calendrier pour une conformité complète aux réglementations applicables en matière d’IA dans nos juridictions d’exploitation ?

Réponse aux incidents et responsabilisation

1. Quel est votre plan de réponse aux incidents spécifique à l’IA, et quels éléments déclenchent la classification d’un incident ?

2. Quel est le délai contractuel de notification pour les incidents liés à l’IA affectant notre déploiement ?

3. Pouvez-vous fournir des exemples d’incidents d’IA passés et la manière dont ils ont été résolus ?

Toutes les questions ne s’appliqueront pas à tous les fournisseurs. Mais l’absence de réponses crédibles aux questions qui s’appliquent clairement constitue en soi un constat.

Signaux d’alerte dans les réponses des fournisseurs

L’évaluation d’un fournisseur consiste autant à analyser la manière dont les organisations reçoivent les réponses qu’à examiner le contenu de ces réponses. Certains schémas de réponse doivent déclencher un examen approfondi.

L’ambiguïté déguisée en confidentialité

Il existe une base légitime pour protéger les secrets commerciaux. Mais un fournisseur qui refuse de divulguer la famille d’architecture générale d’un modèle, les catégories de données d’entraînement utilisées ou l’existence de tests de biais ne protège pas la propriété intellectuelle. Il obscurcit le risque. Un fournisseur qui répond « notre modèle est propriétaire et nous ne pouvons pas partager de détails » à chaque question relative à la transparence n’est pas un fournisseur en mesure de soutenir les obligations réglementaires d’un déployeur.

Absence de documentation

Si un fournisseur ne peut produire ni fiche de modèle, ni politique de gouvernance des données, ni plan de réponse aux incidents, l’explication la plus probable est que ces documents n’existent pas. L’absence de documentation n’est pas un constat neutre. Elle indique que le fournisseur n’a pas investi dans l’infrastructure de gouvernance nécessaire à un déploiement responsable.

Résistance aux droits d’audit

Tout fournisseur qui s’oppose aux droits d’audit contractuels, que ce soit en invoquant des difficultés logistiques ou un caractère commercialement déraisonnable, doit être traité avec prudence. L’EU AI Act prévoit explicitement que les déployeurs devront vérifier la conformité du fournisseur [4]. Un fournisseur qui résiste aux clauses d’audit est un fournisseur qui pourrait ne pas résister à un examen approfondi.

Absence de processus de réponse aux incidents

Si la réponse du fournisseur à la question « Quel est votre plan de réponse aux incidents d’IA ? » est le silence, une redirection vers la gestion générique des incidents informatiques ou la promesse d’en développer un, l’organisation devrait se demander si elle est prête à supporter seule le poids complet d’une éventuelle défaillance de l’IA, sans soutien du fournisseur.

Glissement de la formulation de responsabilité

Soyez attentifs aux formulations contractuelles qui cherchent à transférer l’intégralité de la responsabilité des résultats liés à l’IA au déployeur. Certes, les déployeurs assument des obligations. Toutefois, un fournisseur qui n’accepte aucune responsabilité pour la performance, les biais ou les défaillances du modèle en dit long sur sa confiance dans ses propres systèmes.

Le schéma global compte davantage que toute réponse individuelle. Un fournisseur transparent sur les limites réelles présente un risque bien moindre qu’un fournisseur qui prétend à la perfection sans fournir aucune preuve.

Protections contractuelles pour l’approvisionnement en IA

L’évaluation est nécessaire, mais elle n’est pas suffisante. Les conclusions doivent être intégrées dans des clauses contractuelles opposables. Les accords standards d’approvisionnement logiciel contiennent rarement des dispositions adaptées aux risques spécifiques de l’IA. Les clauses suivantes devraient être envisagées dans tout contrat avec un fournisseur d’IA.

Droits d’audit

L’accord devrait accorder au déployeur le droit d’auditer les systèmes d’IA du fournisseur, soit directement, soit par l’intermédiaire d’un tiers indépendant, à intervalles raisonnables et à l’occurrence d’événements déclencheurs spécifiques (tels qu’un incident signalé ou une demande réglementaire). Ce droit devrait s’étendre aux données de performance des modèles, aux résultats des tests de biais et aux pratiques de gouvernance des données.

Notification des incidents

L’accord devrait préciser des délais maximaux de notification pour les incidents liés à l’IA, distincts des incidents de service généraux. Pour les systèmes à haut risque, une notification dans les 24 heures suivant la découverte constitue un point de départ raisonnable. La notification devrait inclure la nature de l’incident, les systèmes affectés, l’impact estimé et les mesures correctives.

Traitement et conservation des données

L’accord devrait préciser de manière exacte comment les données client sont utilisées en relation avec le système d’IA : si elles sont utilisées pour l’amélioration du modèle, comment elles sont stockées, quand elles sont supprimées et si le client peut demander leur retrait des jeux de données d’entraînement. Ce point est particulièrement critique au regard de l’attention réglementaire continue portée à l’intersection de l’entraînement de l’IA et des droits en matière de protection des données [5].

Notification des changements de modèle

L’accord devrait obliger le fournisseur à notifier à l’avance tout changement substantiel du modèle, y compris le réentraînement sur de nouvelles données, les changements d’architecture et les ajustements importants de paramètres. Le délai de notification devrait permettre au déployeur de procéder à des tests avant que le modèle mis à jour n’entre en production dans son environnement. Une fenêtre de notification de 30 jours pour les changements non urgents constitue une base raisonnable.

Références de performance et SLA

Au-delà des SLA de disponibilité traditionnels, l’accord devrait établir des critères de performance mesurables pour le système d’IA, notamment des seuils de précision, des métriques d’équité et des exigences de latence. Tout manquement à ces seuils devrait déclencher des obligations de remédiation définies et, le cas échéant, des droits de résiliation.

Répartition de la responsabilité

L’accord devrait répartir la responsabilité des dommages liés à l’IA d’une manière reflétant le degré de contrôle de chaque partie. Un fournisseur qui contrôle le modèle, les données d’entraînement et le cycle de mise à jour devrait assumer une responsabilité proportionnée pour les défauts de ces composants. Une indemnisation générale au bénéfice du fournisseur n’est pas appropriée pour des déploiements d’IA.

Des contrats solides ne remplacent pas la gouvernance, mais ils fournissent le mécanisme d’exécution qui rend la gouvernance opérationnelle.

Suivi continu : au-delà de l’évaluation ponctuelle

Une évaluation de fournisseur d’IA réalisée une seule fois à l’approvisionnement puis archivée est un artefact de conformité, non une pratique de gestion des risques. Les systèmes d’IA évoluent, tout comme les risques qu’ils présentent.

Indicateurs de suivi continu

Les organisations devraient mettre en place un suivi continu sur plusieurs dimensions :

• Dérive des performances. Suivre la qualité des sorties du système d’IA par rapport aux références établies lors de l’approvisionnement. Toute dégradation peut indiquer une dérive du modèle, des problèmes de pipeline de données ou des changements de modèle non divulgués.

• Fréquence et gravité des incidents. Consigner tous les incidents liés à l’IA, y compris les quasi-incidents, et analyser leur évolution dans le temps. Une augmentation de la fréquence des sorties anormales justifie une enquête.

• Évolutions réglementaires. Suivre les modifications des réglementations applicables en matière d’IA susceptibles de modifier la classification de risque du système ou d’imposer de nouvelles obligations aux déployeurs.

• Stabilité financière et opérationnelle du fournisseur. Un fournisseur en difficulté financière peut réduire ses investissements dans la maintenance des modèles, la sécurité et la conformité - autant d’éléments qui affectent directement le déployeur.

Déclencheurs de réévaluation

Certains événements devraient déclencher une réévaluation complète du fournisseur, en dehors du cycle d’examen régulier :

• Le fournisseur annonce une mise à jour majeure du modèle ou un changement d’architecture

• Un incident significatif lié à l’IA se produit, que ce soit dans le déploiement de l’organisation ou signalé publiquement

• Une orientation réglementaire modifie la classification de risque du système d’IA

• L’organisation modifie son utilisation du système d’IA d’une manière qui altère sensiblement le profil de risque

• Le fournisseur est acquis, fusionne ou connaît un changement de direction important

Intégrer la surveillance dans les flux de gouvernance

Un suivi continu efficace exige davantage que de bonnes intentions. Il requiert des outils qui intègrent la supervision des fournisseurs dans les cadences de gouvernance existantes. Enzai fournit l’infrastructure nécessaire à une surveillance continue de l’IA tierce, en reliant les résultats d’évaluation, les obligations contractuelles et les indicateurs de performance en temps réel dans un flux de gouvernance unique. Sans cette intégration, les obligations de suivi ont tendance à se dégrader au fil du temps, laissant les organisations exposées précisément au moment où la vigilance compte le plus.

La gouvernance n’est pas un événement. C’est une pratique continue.

Le piège de l’article 25 : lorsque les déployeurs deviennent des fournisseurs

L’une des dispositions les plus déterminantes et les moins comprises de l’EU AI Act concerne les circonstances dans lesquelles un déployeur est requalifié en fournisseur. Article 25 stipule qu’un déployeur est considéré comme un fournisseur s’il appose son nom ou sa marque sur un système d’IA à haut risque déjà mis sur le marché, apporte une modification substantielle à un système à haut risque, modifie la destination d’un système d’IA de sorte qu’il devienne à haut risque, ou met sur le marché un système à haut risque après qu’un tiers l’a déjà fait dans le cadre d’un accord avec le fournisseur initial [6].

Cela a des implications directes pour les organisations qui personnalisent une IA tierce. L’ajustement fin d’un modèle de fournisseur sur des données propriétaires, la modification de ses sorties au moyen de couches de traitement supplémentaires ou son déploiement pour un cas d’usage sensiblement différent de la destination déclarée par le fournisseur peuvent chacun suffire à déclencher une requalification.

Les conséquences de la requalification sont importantes. Un fournisseur supporte l’intégralité des obligations de l’EU AI Act pour les systèmes à haut risque, y compris les évaluations de conformité, la documentation technique, la surveillance post-commercialisation et l’enregistrement dans la base de données de l’UE. Ces obligations sont nettement plus lourdes que celles imposées aux déployeurs.

Mesures pratiques pour éviter le piège

• Documenter la destination. Conservez des enregistrements clairs de la destination déclarée par le fournisseur pour le système d’IA et du cas d’usage réel de l’organisation. Tout écart doit être examiné par les équipes juridiques et conformité.

• Évaluer la portée de la personnalisation. Avant tout ajustement fin, réentraînement ou modification substantielle d’un système d’IA tiers, évaluez si la modification constitue une « modification substantielle » au sens du règlement. Les orientations de la Commission européenne sur ce point devraient apporter davantage de clarté, mais le risque existe déjà [7].

• Clarté contractuelle. Veillez à ce que le contrat avec le fournisseur précise clairement quelle partie est le fournisseur et laquelle est le déployeur, et définisse les conditions dans lesquelles cette classification pourrait évoluer.

• Solliciter un conseil juridique tôt. La frontière fournisseur-déployeur est une question de substance, non d’étiquette. Se qualifier de déployeur dans un contrat n’annule pas une détermination factuelle selon laquelle l’on agit comme fournisseur.

Le piège de l’article 25 n’est pas théorique. À mesure que les organisations personnalisent et ajustent davantage les systèmes d’IA de leurs fournisseurs, la frontière entre déploiement et mise à disposition devrait devenir l’un des domaines les plus contentieux de la réglementation de l’IA.

Construire un programme d’IA tierce défendable

L’évaluation des risques liés aux fournisseurs d’IA tiers n’est pas une simple case à cocher lors de l’approvisionnement. C’est une discipline de gouvernance continue qui couvre les dimensions juridiques, techniques et opérationnelles. Les organisations qui gèrent efficacement ce risque seront celles qui traiteront la supervision de leurs fournisseurs d’IA avec la même rigueur que leurs contrôles financiers ou la protection des données.

Le cadre présenté ici offre un point de départ : évaluation structurée, questions précises, protections contractuelles, suivi continu et compréhension des pièges réglementaires capables de transformer du jour au lendemain un déployeur en fournisseur. Rien de tout cela n’est facultatif pour les organisations qui déploient des systèmes d’IA à haut risque dans des environnements réglementés.

Pour les organisations qui souhaitent opérationnaliser à grande échelle la gouvernance de l’IA tierce, Enzai fournit l’infrastructure de plateforme nécessaire pour gérer les évaluations des fournisseurs, suivre les obligations et maintenir une supervision continue sur l’ensemble du portefeuille d’IA. Demandez une démonstration pour voir comment cela fonctionne en pratique.

Enzai est la principale plateforme de gouvernance de l’IA d’entreprise, conçue spécifiquement pour aider les organisations à passer d’une politique abstraite à une supervision opérationnelle. Notre plateforme de gestion des risques liés à l’IA fournit l’infrastructure spécialisée nécessaire pour gérer la gouvernance de l’IA agentique, maintenir un inventaire de l’IA complet et garantir la conformité à l’EU AI Act. En automatisant des flux de travail complexes, Enzai permet aux entreprises d’étendre l’adoption de l’IA en toute confiance tout en restant alignées sur des normes mondiales telles que ISO 42001 et NIST.

Références

[1] Gartner, « Gartner prévoit que 70 % des organisations réorienteront leur attention vers la gouvernance de l’IA », 2024.

[2] Parlement européen et Conseil, Règlement (UE) 2024/1689 (EU AI Act), article 26 - Obligations des déployeurs de systèmes d’IA à haut risque, 2024.

[3] Comité européen de la protection des données, « Avis sur l’interaction entre l’AI Act et le RGPD », 2024.

[4] Parlement européen et Conseil, Règlement (UE) 2024/1689 (EU AI Act), article 13 (Transparence et fourniture d’informations aux déployeurs) et article 26 (obligations des déployeurs), 2024.

[5] Comité européen de la protection des données, « Lignes directrices sur l’utilisation des données personnelles dans l’entraînement des modèles d’IA », 2025.

[6] Parlement européen et Conseil, Règlement (UE) 2024/1689 (EU AI Act), article 25 - Responsabilités tout au long de la chaîne de valeur de l’IA, 2024.

[7] Commission européenne, « Lignes directrices sur la modification substantielle des systèmes d’IA » (à paraître), citées au considérant 88 de l’EU AI Act.