Risque lié aux fournisseurs tiers d’IA : comment évaluer une IA que vous n’avez pas développée

La majeure partie de l’IA d’entreprise n’est pas développée 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 que croître. 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 s’avérer opaque pour le fournisseur lui-même.

Le paysage réglementaire a rattrapé cette réalité. Le règlement européen sur l’IA (EU AI Act), dont la mise en œuvre progressive a débuté en 2025, trace une frontière claire entre les fournisseurs (ceux qui développent ou mettent sur le marché un système d’IA) et les déployeurs (ceux qui l’utilisent sous leur propre autorité). Toutefois, cette distinction ne dédouane pas les déployeurs de leur responsabilité. L’article 26 stipule clairement que les déployeurs de systèmes d’IA à haut risque ont des obligations spécifiques en matière de contrôle humain, de qualité des données d’entrée, de surveillance et de conservation des registres [2]. Pour les équipes chargées des achats et de la conformité, la vérité est inconfortable : la responsabilité réglementaire ne se transfère pas au fournisseur du simple fait que ce dernier a conçu le modèle.

Ce guide propose un cadre structuré d’évaluation des risques liés aux fournisseurs d’IA, depuis les vérifications préalables initiales jusqu’au suivi continu.

Pourquoi le risque lié aux tiers en matière d’IA exige une approche différente

La gestion traditionnelle des risques liés aux fournisseurs évalue la disponibilité, la sécurité des données et les accords contractuels sur les niveaux de service (SLA). Ces éléments restent nécessaires pour les fournisseurs d’IA, mais ils ne suffisent plus. Les systèmes d’IA introduisent une catégorie de risques que les processus d'achats informatiques conventionnels n’ont jamais été conçus pour traiter.

Trois caractéristiques différencient fondamentalement l’IA tierce des autres types de logiciels :

L’opacité de la logique de décision. Une application SaaS classique exécute un code déterministe. Un système d’IA, quant à lui, peut générer des résultats influencés par des données d’entraînement, des ajustements de précision (fine-tuning) et des paramètres d’inférence pour lesquels l’organisation qui déploie le système ne dispose d’aucune visibilité. Lorsqu’un modèle d’évaluation de solvabilité refuse une demande ou qu’un outil de sélection RH classe des candidats, le déployeur doit être en mesure d’expliquer cette décision. Si le fournisseur ne peut lui apporter d’explication claire, le déployeur se retrouve responsable de résultats qu’il est incapable d'interpréter.

Un comportement non statique. Les logiciels traditionnels évoluent au fil de versions clairement définies. Les modèles d’IA peuvent modifier leur comportement à la suite d’un réentraînement, d’un ajustement de précision ou de modifications apportées aux pipelines de données sous-jacents, parfois sans cycle de diffusion officiel. Un modèle performant respectant des paramètres acceptables au cours du processus d'achat peut s'altérer au fil des mois. Le déployeur risque de ne s’en apercevoir qu’une fois le préjudice causé.

Le risque de données héritées. Les données d’entraînement qui façonnent le comportement d’un modèle peuvent contenir des biais, des éléments 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 effectués en amont, quand bien même il n'y a nullement participé. En vertu du RGPD, si un système d’IA traite des données personnelles de manière non conforme aux accords de traitement des données du déployeur, ce dernier s'expose au risque de sanctions au même titre que le fournisseur [3].

Les grilles d’évaluation classiques des fournisseurs ne tiennent pas compte de ces dynamiques. Un cadre d’évaluation spécifiquement conçu à cet effet est donc indispensable.

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

Le cadre présenté ci-après structure l’évaluation des fournisseurs d’IA autour de sept domaines. Chaque domaine correspond à une préoccupation de gouvernance spécifique et peut faire l’objet d’une notation lors du processus d’achat, de revues périodiques ou d’une réévaluation motivée.

Les organisations utilisant des plateformes telles que Enzai peuvent intégrer ce cadre à leurs flux de gestion du cycle de vie des fournisseurs existants, garantissant ainsi que les critères spécifiques à l’IA côtoient les indicateurs de risques informatiques traditionnels au sein d'un processus unifié.

Questionnaire d’évaluation

Ce tableau doit être considéré comme un outil évolutif. Les seuils de notation varieront selon les cas d’usage : un système d’IA à haut risque utilisé pour 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 n'est efficace que si ses questions sont suffisamment précises pour révéler des risques réels. Des questions vagues appellent des réponses évasives. Les questions suivantes, catégorisées, sont formulées pour obtenir 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 ainsi que les indicateurs de performance de référence ?

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

4. Si le modèle repose sur un modèle de fondation tiers (ex. un fournisseur de LLM), pouvez-vous divulguer quel modèle et quelle version sont utilisés comme base ?

Gouvernance des données et confidentialité

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

2. Quelle est la base légale, 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 la phase d’inférence ? Quelles mesures de protection empêchent la fuite de données ?

4. Comment les données des clients sont-elles utilisées après le déploiement ? Sont-elles réinjectées dans l’entraînement du modèle, et le client dispose-t-il d'une option d'exclusion (opt-out) ?

Biais, équité et sécurité

1. Ce modèle a-t-il fait l’objet d’un audit de biais portant sur les caractéristiques protégées par les lois anti-discrimination applicables ?

2. Qui a réalisé cet audit, et les conclusions sont-elles disponibles pour examen ?

3. Quel suivi continu est mis en place pour détecter l’apparition de nouveaux biais ou une dégradation des performances parmi certains sous-groupes ?

4. Pour les systèmes d’IA générative : quels garde-fous empêchent la génération de contenus préjudiciables, trompeurs ou juridiquement problématiques ?

Sécurité et résilience

1. Quelles protections spécifiques sont en place contre les attaques contradictoires, les injections de requêtes, l'inversion de modèle ou l’extraction de données d’entraînement ?

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

3. Quel est le plan de reprise d’activité et de continuité d’activité appliqué spécifiquement 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 risques de l'EU AI Act ? Si oui, quelle est sa classification ?

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

3. Quel est votre calendrier pour assurer une mise en conformité totale avec les réglementations sur l’IA en vigueur dans nos zones d’activité ?

Gestion des incidents et responsabilité

1. Quel est votre plan de réponse aux incidents spécifique à l’IA, et quels critères 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 ces questions ne s'appliqueront pas à l'ensemble des fournisseurs. Néanmoins, l’absence de réponses crédibles à des questions de toute évidence applicables constitue en soi un signal d'alerte.

Signaux d’alerte dans les réponses des fournisseurs

L’évaluation des fournisseurs dépend autant de la manière dont les réponses sont apportées que de leur contenu. Certains comportements de la part des fournisseurs doivent inciter à une vigilance accrue.

Le flou artistique sous couvert de confidentialité

La protection des secrets commerciaux repose sur un motif légitime. Toutefois, 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 sa propriété intellectuelle. Il masque un risque. Un fournisseur qui rétorque « notre modèle est propriétaire et nous ne pouvons partager aucun détail » à chaque question sur la transparence n’est pas en mesure d’accompagner efficacement un déployeur dans ses obligations réglementaires.

L’absence de documentation

Si un fournisseur s'avère incapable de fournir une fiche de modèle, une politique de gouvernance des données ou un plan de réponse aux incidents, il est fort probable que ces documents n’existent tout simplement pas. L’absence de documentation n’est pas un élément neutre. Elle indique que le fournisseur n’a pas investi dans l'infrastructure de gouvernance nécessaire à un déploiement responsable.

La réticence face aux droits d’audit

Tout fournisseur qui s'oppose aux clauses de droit d’audit contractuel, que ce soit sous prétexte de contraintes logistiques ou de déraison commerciale, doit être abordé avec la plus grande prudence. L'EU AI Act prévoit explicitement que les déployeurs devront vérifier la conformité de leur fournisseur [4]. Un fournisseur qui refuse les dispositions d’audit est un fournisseur dont la transparence laisse à désirer.

Aucun processus de réponse aux incidents

Si un fournisseur oppose un silence, renvoie à une gestion d'incidents informatiques génériques ou promet de concevoir un plan ultérieurement lorsqu'il est interrogé sur sa politique de réponse aux incidents d’IA, l’organisation doit évaluer si elle est prête à assumer seule toutes les conséquences d’une défaillance de l’IA.

Une formulation glissante en matière de responsabilité

Il convient de surveiller attentivement les clauses contractuelles visant à transférer l’intégralité de la responsabilité des résultats de l’IA sur le déployeur. Bien que les déployeurs assument des devoirs, un fournisseur qui décline toute responsabilité quant aux performances, aux biais ou aux dérives de son modèle témoigne d’un manque de confiance évident dans ses propres systèmes.

La cohérence globale importe plus qu’une réponse isolée. Un fournisseur transparent sur ses limites réelles s'avère bien moins risqué qu’un autre prétendant à la perfection sans apporter de preuves.

Garanties contractuelles pour l’acquisition d’IA

L’évaluation préalable est une condition indispensable mais insuffisante. Les conclusions doivent être intégrées dans des clauses contractuelles contraignantes. Les contrats d’achat de logiciels standards contiennent rarement des dispositions adaptées aux risques spécifiques de l’IA. Les clauses suivantes devraient être envisagées dans tout accord avec un fournisseur de solutions 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 réguliers ou lors d’événements déclencheurs spécifiques (tels qu'un incident signalé ou une enquête réglementaire). Ce droit d’audit doit inclure les données de performance du modèle, les résultats des tests de biais et les pratiques de gouvernance des données.

Notification des incidents

L’accord devrait spécifier des délais maximaux de notification pour les incidents spécifiques à 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 est un point de départ raisonnable. La notification doit préciser la nature de l’incident, les systèmes affectés, l’impact estimé et les mesures de remédiation envisagées.

Traitement et conservation des données

L’accord devrait préciser scrupuleusement la manière dont les données du client sont exploitées par le système d’IA : sont-elles utilisées pour améliorer le modèle ? Comment sont-elles stockées ? Quand sont-elles supprimées ? Le client peut-il demander leur retrait des jeux de données d’entraînement ? Cette clause s'avère particulièrement cruciale au regard de l’attention constante des régulateurs sur l’articulation entre l'entraînement des IA et les droits de protection des données [5].

Notification de modification de modèle

L’accord devrait contraindre le fournisseur à informer préalablement le déployeur de toute modification substantielle apportée au modèle, y compris les phases de réentraînement sur de nouvelles données, les changements d’architecture et les ajustements de paramètres significatifs. Le délai de prévis doit permettre au déployeur de mener des tests avant que le modèle mis à jour ne soit exploité en production dans son environnement. Un préavis de 30 jours pour les modifications non urgentes constitue une référence cohérente.

Indicateurs de performance et SLA

Au-delà des traditionnels engagements de disponibilité du service (SLA), l’accord devrait fixer des indicateurs de performance mesurables pour l’IA, notamment en matière de précision minimale, de mesures d’équité et de temps de latence. Tout manquement à ces seuils de performance devrait activer des obligations de remédiation définies et, si nécessaire, un droit de résiliation.

Répartition de la responsabilité

L’accord devrait définir la répartition des responsabilités en cas de préjudices causés par l’IA, proportionnellement au degré de contrôle de chaque partie. Un fournisseur qui maîtrise le modèle, les données d’entraînement et les cycles de mise à jour doit assumer la responsabilité des défaillances liées à ces éléments. Une clause d’exonération totale de responsabilité au profit exclusif du fournisseur n’est pas acceptable pour les déploiements d’IA.

Si des contrats solides ne sauraient remplacer une bonne gouvernance, ils apportent un cadre coercitif indispensable pour la rendre opérationnelle.

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

Une évaluation de fournisseur d'IA réalisée à l'achat et classée sans suite n’est qu’une formalité administrative, non une démarche active de maîtrise des risques. Les systèmes d’IA évoluent, et les risques qu’ils comportent également.

Indicateurs de veille continue

Les organisations se doivent de mettre en place une surveillance continue selon plusieurs axes :

• Dérive des performances. Comparez la qualité des résultats du système d’IA aux indicateurs de référence établis au moment de l’achat. Tout fléchissement peut indiquer une dérive du modèle, des dysfonctionnements dans les pipelines de données ou des évolutions de modèle non documentées.

• Fréquence et gravité des incidents. Consignez l’ensemble des incidents d’IA, y compris les anomalies évitées de justesse, et analysez leur tendance au fil du temps. Une recrudescence de résultats anormaux doit impérativement déclencher une investigation.

• Évolutions réglementaires. Suivez de près les évolutions des réglementations applicables en matière d’IA susceptibles d’avoir un impact sur la classification du niveau de risque du système ou d’imposer de nouvelles obligations aux déployeurs.

• Stabilité financière et opérationnelle du fournisseur. Un fournisseur confronté à des difficultés financières risque de réduire ses investissements dans la maintenance, la sécurité et la conformité de son modèle, ce qui impacte directement le déployeur.

Événements déclencheurs de réévaluation

Certaines situations particulières exigent une réévaluation complète du fournisseur, en dehors du calendrier de révision ordinaire :

• Le fournisseur annonce une évolution majeure du modèle ou un changement de son architecture ;

• Un incident d’IA significatif survient, qu’il affecte directement l’organisation ou qu'il soit rendu public ;

• De nouvelles directives réglementaires révisent la classification de risque du système d’IA ;

• L’organisation réoriente son usage du système d'IA d'une manière qui altère substantiellement son profil de risque ;

• Le fournisseur fait l’objet d’une acquisition, d’une fusion ou d’un remaniement de direction majeur.

Intégration du suivi dans les flux de gouvernance

Maintenir une surveillance continue efficace implique d’aller au-delà des intentions. Cela requiert des outils permettant d'intégrer le suivi des tiers dans les rituels de gouvernance existants. Enzai fournit l’infrastructure nécessaire à cette surveillance continue des IA tierces, en consolidant les conclusions d’évaluations, les engagements contractuels et les indicateurs de performance en temps réel au sein d’un flux de gouvernance unique. Faute d'une telle centralisation, le suivi tend à s’essouffler, exposant l’organisation au moment même où la vigilance est requise.

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

Le piège de l’article 25 : quand le déployeur devient fournisseur

L’une des dispositions les plus lourdes de conséquences, et pourtant méconnues, de l'EU AI Act concerne les cas dans lesquels un déployeur est requalifié en fournisseur. L’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à sur le marché, apporte une modification substantielle à un système d’IA à 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 d’IA à haut risque après qu’un tiers l’a déjà fait en vertu d’un accord avec le fournisseur d’origine [6].

Cette règle a des incidences directes pour les organisations qui personnalisent des solutions d’IA tierces. Procéder à un ajustement de précision (fine-tuning) du modèle d’un fournisseur sur des données propriétaires, altérer ses résultats par des couches de traitement complémentaires ou l’exploiter pour une finalité s'écartant sensiblement de l’usage initial prévu par le fournisseur peut suffire à provoquer cette requalification.

Les conséquences de cette requalification s'avèrent de taille. Le fournisseur assumed l'ensemble des obligations imposées par l'EU AI Act pour les systèmes à haut risque, à savoir les évaluations de conformité, la documentation technique, la surveillance après commercialisation et l’enregistrement dans la base de données de l’Union européenne. Ces obligations s'avèrent infiniment plus contraignantes que celles incombant aux simples déployeurs.

Recommandations pratiques pour éviter ce piège

• Documenter la destination d’usage. Veillez à conserver un registre précis de la finalité d’usage stipulée par le fournisseur d’une part, et des cas d’usages effectifs de l’organisation d’autre part. Toute divergence notable doit impérativement faire l'objet d'une analyse par les départements juridique et conformité.

• Évaluer la portée des personnalisations. Avant d'engager tout travail d'ajustement, de réentraînement ou de modification substantielle d’un système d’IA tiers, déterminez si cette intervention s’apparente à une « modification substantielle » selon les définitions du règlement. Les directives à venir de la Commission européenne devraient apporter des éclaircissements, mais le risque juridique doit être anticipé dès à présent [7].

• Précision contractuelle. Rédigez le contrat d’achat de sorte qu’il identifie clairement les rôles respectifs de fournisseur et de déployeur, et encadre rigoureusement les conditions susceptibles d’entraîner une évolution de ces rôles.

• Consulter vos conseils juridiques en amont. La qualification de fournisseur ou de déployeur dépend des faits, non de simples dénominations. Se déclarer « déployeur » dans un contrat n’exclura pas une décision de requalification administrative si la réalité démontre un rôle de fournisseur.

Le piège de l’article 25 n’a rien de théorique. À mesure que les organisations personnalisent et ajustent les systèmes d'IA de leurs fournisseurs, la frontière entre déploiement et fourniture s'annonce comme l’un des territoires les plus litigieux du droit de l’IA.

Bâtir un programme robuste pour la gestion des IA tierces

L’évaluation des risques liés aux fournisseurs d’IA tiers ne se résume pas à cocher des cases lors du processus d’achat. Il s’agit d’une démarche continue à la croisée des domaines juridique, technique et opérationnel. Les organisations qui maîtriseront au mieux ces risques seront celles qui appliqueront à la surveillance de leurs prestataires d'IA la même rigueur qu’à leurs contrôles financiers ou à la protection de leurs données.

Le cadre proposé ici offre une base de travail solide : des grilles d’évaluation structurées, des questionnements précis, des protections juridiques contractuelles, un suivi régulier et une vigilance constante quant aux aspects réglementaires pouvant requalifier un déployeur en fournisseur. Rien de tout cela n'est facultatif pour les organisations déployant des systèmes d’IA à haut risque dans des secteurs réglementés.

Pour les organisations désireuses d’industrialiser la gouvernance des IA tierces, Enzai propose une plateforme logicielle conçue pour orchestrer les évaluations de fournisseurs, suivre la bonne exécution des obligations et assurer un contrôle constant sur l’ensemble du parc de solutions d’IA. Demandez une démonstration pour découvrir l’outil en pratique.

Enzai s'impose comme la plateforme de référence pour la gouvernance des IA d'entreprise, spécialement conçue pour aider les organisations à traduire les grandes orientations stratégiques en contrôle opérationnel concret. Notre plateforme de gestion des risques liés à l'IA offre l'infrastructure spécialisée indispensable pour encadrer la gouvernance des IA agentielles, tenir un inventaire complet des IA et garantir la conformité vis-à-vis de l'EU AI Act. En automatisant les processus complexes, Enzai permet aux entreprises d'accélérer l'adoption de l'IA en toute sécurité, dans le respect des standards internationaux tels que l'ISO 42001 et le référentiel du NIST.

Références

[1] Gartner, "Gartner Predicts 70% of Organisations Will Shift Focus to AI Governance," 2024.

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

[3] Comité européen de la protection des données, "Opinion on the Interplay Between the AI Act and the GDPR," 2024.

[4] Parlement européen et Conseil, Règlement (UE) 2024/1689 (règlement sur l'IA), 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, "Guidelines on the Use of Personal Data in AI Model Training," 2025.

[6] Parlement européen et Conseil, Règlement (UE) 2024/1689 (règlement sur l'IA), article 25 - Responsabilités le long de la chaîne de valeur de l'IA, 2024.

[7] Commission européenne, "Guidelines on Substantial Modification of AI Systems" (à paraître), mentionné au considérant 88 du règlement sur l'IA.