La plupart des IA d'entreprise ne sont pas conçues 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 majorité 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, même 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 application 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é). Mais cette frontière ne dédouane pas les déployeurs de leurs responsabilités. 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]. La vérité dérangeante pour les équipes d'achats et de conformité est la suivante : la responsabilité réglementaire ne se transfère pas au fournisseur simplement parce 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 l'audit préalable initial jusqu'à la surveillance continue.

Pourquoi le risque lié aux IA tierces exige 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 (SLA) 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 risques que les processus d'achats informatiques conventionnels n'ont jamais été conçus pour traiter.

Trois propriétés différencient fondamentalement l'IA tierce des autres logiciels :

L'opacité de la logique de décision. Une application SaaS classique exécute un code déterministe. Un système d'IA peut produire des résultats façonnés par des données d'entraînement, des choix d'ajustement fin (fine-tuning) et des paramètres d'inférence auxquels l'organisation utilisatrice n'a aucun accès. Lorsqu'un modèle de notation de crédit 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 pas fournir d'explication claire, le déployeur est tenu responsable de résultats qu'il ne peut pas interpréter.

Un comportement non statique. Les logiciels traditionnels évoluent par le biais de versions successives. Les modèles d'IA peuvent voir leur comportement varier en fonction d'un réentraînement, d'un ajustement ou de modifications des pipelines de données sous-jacents, parfois sans cycle de diffusion officiel. Un modèle performant respectant des paramètres acceptables lors de l'achat peut dériver au fil des mois suivants. Le déployeur peut ne s'en rendre compte que lorsqu'un préjudice s'est déjà produit.

Le risque de données hérité. 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 en amont, même s'il n'y a joué aucun rôle. En vertu du RGPD, si un système d'IA traite des données personnelles d'une manière non conforme aux accords de traitement des données du déployeur, ce dernier partage le risque de sanction avec 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 est donc indispensable.

Un cadre structuré d'évaluation des risques des 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 évalué lors de l'achat, des examens périodiques ou à la suite d'une réévaluation déclenchée par un événement.

Les organisations utilisant des plateformes telles qu'Enzai peuvent intégrer ce cadre dans leurs processus de gestion du cycle de vie des fournisseurs existants, garantissant ainsi que les critères spécifiques à l'IA cohabitent avec les indicateurs de risques informatiques traditionnels plutôt que de rester dans un processus distinct et déconnecté.

Questionnaire d'évaluation

Ce tableau doit être traité comme un document évolutif. Les seuils d'évaluation varieront selon les cas d'usage : un système d'IA à haut risque utilisé pour le tri 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 les questions sont suffisamment précises pour révéler les risques réels. Des questions vagues appellent des réponses vagues. Les questions suivantes, classées par catégorie, sont conçues 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 et les indicateurs de performance ?

3. Quelles méthodes sont disponibles pour expliquer des prédictions ou des 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 sur quel modèle de fondation et quelle version vous vous appuyez ?

Gouvernance des données et confidentialité

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

2. Quelle est la base légale au titre du RGPD (ou 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 sont les garanties contre les fuites de données ?

4. Comment les données des clients sont-elles utilisées après le déploiement ? Sont-elles réintégrées dans l'entraînement du modèle, et le client peut-il s'y opposer (opt-out) ?

Biais, équité et sécurité

1. Ce modèle a-t-il été audité pour détecter d'éventuels biais concernant des caractéristiques protégées par les lois anti-discrimination applicables ?

2. Qui a mené cet audit et les résultats sont-ils consultables ?

3. Quelle surveillance continue est mise en place pour détecter l'apparition de biais ou une dégradation des performances sur 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 fait l'objet de tests d'intrusion spécifiques à l'IA ou de simulations d'attaques (red-teaming) allant au-delà des tests de sécurité applicative standards ?

3. Quel est le plan de reprise d'activité 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 risques 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 la conformité pour les systèmes d'IA à haut risque, comme l'exige l'article 43 ?

3. Quel est votre calendrier pour assurer une totale conformité avec les réglementations applicables en matière d'IA dans nos zones d'activité ?

Gestion des incidents et responsabilité

1. Quel est votre plan de gestion des 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 passés liés à l'IA et la manière dont ils ont été résolus ?

Toutes les questions ne s'appliqueront pas à chaque fournisseur. Cependant, l'absence de réponses crédibles à des questions manifestement pertinentes 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 présentées que de leur contenu. Certains comportements dans les réponses des fournisseurs doivent inciter à une vigilance accrue.

Le flou artistique sous couvert de confidentialité

Il existe des motifs légitimes pour protéger les secrets d'affaires. 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épond à chaque question sur la transparence par « notre modèle est propriétaire et nous ne pouvons pas partager de détails » n'est pas en mesure d'aider un déployeur à respecter ses obligations réglementaires.

L'absence de documentation

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

La résistance aux droits d'audit

Tout fournisseur qui s'oppose aux droits d'audit contractuels, que ce soit sous prétexte de contraintes logistiques ou de déraison commerciale, doit être considéré avec prudence. L'EU AI Act prévoit explicitement que les déployeurs devront vérifier la conformité des fournisseurs [4]. Un fournisseur qui refuse les clauses d'audit est un fournisseur qui craint un examen approfondi.

Aucun processus de gestion des incidents

Si la réponse du fournisseur à la question « Quel est votre plan de gestion des incidents lié à l'IA ? » est le silence, un renvoi vers la gestion générique des incidents informatiques ou la promesse d'en élaborer un futur, l'organisation doit se demander si elle est prête à assumer seule le poids d'une défaillance de l'IA sans le soutien du fournisseur.

Un glissement sémantique sur la responsabilité

Soyez attentif aux clauses contractuelles qui tentent de transférer l'intégralité de la responsabilité des résultats de l'IA sur le déployeur. Bien que les déployeurs aient des obligations, un fournisseur qui décline toute responsabilité quant aux performances, aux biais ou aux défaillances de son modèle envoie un signal négatif sur la confiance qu'il porte à ses propres systèmes.

La cohérence globale importe plus qu'une réponse isolée. Un fournisseur transparent sur ses limites réelles présente bien moins de risques qu'un autre revendiquant la perfection sans apporter de preuves.

Protections contractuelles pour l'achat de solutions d'IA

L'évaluation est nécessaire, mais elle ne suffit pas. 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. Il convient d'envisager l'intégration des clauses suivantes dans tout accord avec un fournisseur d'IA.

Droits d'audit

L'accord doit accorder au déployeur le droit d'auditer les systèmes d'IA du fournisseur, directement ou par l'intermédiaire d'un tiers indépendant, à intervalles raisonnables et lors de la survenance d'événements déclencheurs spécifiques (comme un incident signalé ou une enquête réglementaire). Ce droit doit s'étendre aux données de performance du modèle, aux résultats des tests de biais et aux pratiques de gouvernance des données.

Notification des incidents

Le contrat doit spécifier 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 est un point de départ raisonnable. La notification doit préciser la nature de l'incident, les systèmes concernés, l'impact estimé et les mesures de remédiation.

Traitement et conservation des données

L'accord doit définir précisément comment les données du client sont utilisées par le système d'IA : servent-elles à l'amélioration du modèle, comment sont-elles stockées, quand sont-elles supprimées et le client peut-il demander leur retrait des ensembles de données d'entraînement. Cela est particulièrement critique compte tenu de l'attention réglementaire constante portée à l'intersection entre l'entraînement des IA et les droits de protection des données [5].

Notification des modifications du modèle

Le contrat doit exiger du fournisseur qu'il notifie à l'avance toute modification substantielle du modèle, y compris les réentraînements sur de nouvelles données, les changements d'architecture et les ajustements majeurs de paramètres. Le délai de préavis doit permettre au déployeur d'effectuer des tests avant que le modèle mis à jour ne soit mis en production dans son environnement. Un préavis de 30 jours pour les modifications non urgentes constitue une base de référence raisonnable.

Indicateurs de performance et SLA

Au-delà des SLA classiques de disponibilité, l'accord doit établir des indicateurs de performance mesurables pour le système d'IA, y compris des seuils de précision, des critères d'équité et des exigences de latence. Le non-respect de ces indicateurs doit déclencher des obligations de remédiation définies et, le cas échéant, des droits de résiliation.

Répartition de la responsabilité

Le contrat doit répartir la responsabilité des préjudices liés à l'IA d'une manière qui reflète 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 doit assumer une responsabilité proportionnelle aux défauts de ces composants. Une clause d'indemnisation globale en faveur du fournisseur n'est pas appropriée pour les déploiements d'IA.

Des contrats solides ne remplacent pas la gouvernance, mais ils fournissent le mécanisme de contrainte qui la rend opérationnelle.

Surveillance continue : au-delà de l'évaluation ponctuelle

Une évaluation de fournisseur d'IA réalisée une seule fois lors de l'achat, puis classée, est une formalité administrative, non une pratique de gestion des risques. Les systèmes d'IA évoluent, tout comme les risques qu'ils présentent.

Indicateurs de surveillance continue

Les organisations doivent mettre en place une surveillance continue selon plusieurs dimensions :

• Dérive des performances. Suivez la qualité des résultats du système d'IA par rapport aux indicateurs établis lors de l'achat. Une dégradation peut indiquer une dérive du modèle, des problèmes dans le pipeline de données ou des modifications non divulguées du modèle.

• Fréquence et gravité des incidents. Enregistrez tous les incidents liés à l'IA, y compris les quasi-incidents, et analysez leur tendance dans le temps. Une fréquence croissante de résultats anormaux justifie une investigation.

• Évolutions réglementaires. Suivez les modifications des réglementations applicables à l'IA qui pourraient modifier la classification des risques du système ou 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, la sécurité et la conformité du modèle, ce qui affecte directement le déployeur.

Déclencheurs de réévaluation

Certains événements doivent 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 survient, qu'il concerne le déploiement de l'organisation ou qu'il soit signalé publiquement

• Les directives réglementaires modifient la classification des risques du système d'IA

• L'organisation modifie son utilisation 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 changement de direction important

Intégrer la surveillance dans les processus de gouvernance

Une surveillance continue efficace nécessite plus que de bonnes intentions. Elle exige des outils qui intègrent la supervision des fournisseurs dans les rituels de gouvernance existants. Enzai fournit l'infrastructure nécessaire à la surveillance continue des IA tierces, en reliant les résultats d'évaluation, les obligations contractuelles et les indicateurs de performance en temps réel au sein d'un processus de gouvernance unique. Sans cette intégration, les obligations de surveillance ont tendance à s'affaiblir avec le temps, exposant les organisations précisément au moment où la vigilance est la plus cruciale.

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

Le piège de l'article 25 : quand les déployeurs deviennent fournisseurs

L'une des dispositions les plus lourdes de conséquences et les moins bien comprises de l'EU AI Act concerne les circonstances dans lesquelles un déployeur est reclassé en tant que 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à présent sur le marché, s'il apporte une modification substantielle à un système à haut risque, s'il modifie la destination d'un système d'IA de sorte qu'il devienne à haut risque, ou s'il 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].

Cela a des implications directes pour les organisations qui personnalisent des IA tierces. Ajuster le modèle d'un fournisseur sur des données propriétaires, modifier ses résultats via des couches de traitement supplémentaires ou le déployer pour un cas d'usage sensiblement différent de l'usage prévu par le fournisseur peuvent chacun suffire à déclencher un reclassement.

Les conséquences d'un reclassement sont majeures. Un fournisseur assume l'intégralité des obligations de l'EU AI Act pour les systèmes à haut risque, notamment les évaluations de conformité, la documentation technique, la surveillance après commercialisation et l'enregistrement dans la base de données de l'UE. Ces obligations sont considérablement plus lourdes que celles imposées aux déployeurs.

Mesures pratiques pour éviter ce piège

• Documenter la destination du système. Conservez des registres clairs de l'usage prévu 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 de conformité.

• Évaluer la portée des personnalisations. Avant d'ajuster, de réentraîner ou de modifier de manière substantielle un système d'IA tiers, déterminez si cette modification constitue une « modification substantielle » au sens du règlement. Les directives de la Commission européenne sur ce point devraient apporter plus de clarté, mais le risque existe dès à présent [7].

• Clarté contractuelle. Veillez à ce que l'accord avec le fournisseur définisse clairement quelle partie est le fournisseur et laquelle est le déployeur, et spécifie les conditions dans lesquelles cette classification pourrait changer.

• Consulter le service juridique le plus tôt possible. La frontière entre fournisseur et déployeur est une question de fait, non de dénomination. Se qualifier de déployeur dans un contrat ne l'emporte pas sur un constat factuel démontrant que l'on agit en qualité de fournisseur.

Le piège de l'article 25 n'est pas 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 est appelée à devenir l'un des domaines les plus disputés de la réglementation de l'IA.

Bâtir un programme d'IA tierce solide

L'évaluation des risques liés aux fournisseurs d'IA tiers n'est pas une simple case à cocher lors de l'achat. C'est une discipline de gouvernance continue qui englobe les domaines juridique, technique et opérationnel. Les organisations qui géreront efficacement ce risque seront celles qui traiteront la supervision des fournisseurs d'IA avec la même rigueur que celle appliquée aux contrôles financiers ou à la protection des données.

Le cadre décrit ici constitue un point de départ : évaluation structurée, questions précises, protections contractuelles, surveillance continue et sensibilisation aux pièges réglementaires qui peuvent transformer un déployeur en fournisseur du jour au lendemain. Rien de tout cela n'est optionnel pour les organisations déployant des systèmes d'IA à haut risque dans des environnements réglementés.

Pour les organisations qui souhaitent opérationnaliser la gouvernance des IA tierces à grande échelle, 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 plateforme de gouvernance de l'IA d'entreprise leader, conçue spécifiquement pour aider les organisations à passer d'une politique abstraite à une supervision opérationnelle. Notre plateforme de gestion des risques d'IA fournit l'infrastructure spécialisée requise pour gérer la gouvernance de l'IA agentique, maintenir un inventaire complet de l'IA et assurer la conformité avec l'EU AI Act. En automatisant les processus complexes, Enzai permet aux entreprises de déployer l'IA en toute confiance tout en restant en phase avec les normes mondiales telles que ISO 42001 et 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 (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, « Opinion on the Interplay Between the AI Act and the GDPR, » 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, « Guidelines on the Use of Personal Data in AI Model Training, » 2025.

[6] Parlement européen et Conseil, Règlement (UE) 2024/1689 (EU AI Act), 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 de l'EU AI Act.