La plupart des systèmes d’IA d’entreprise ne sont pas développés 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 la plupart des organisations s’appuient 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 pouvant être opaque, y compris pour le fournisseur lui-même.

Le paysage réglementaire s’est aligné sur cette réalité. L’AI Act de l’UE, entré dans sa période d’application progressive en 2025, établit une distinction claire entre les fournisseurs (ceux qui développent un système d’IA ou le mettent sur le marché) et les déployeurs (ceux qui l’utilisent sous leur propre autorité). Mais cette distinction n’exonère pas les déployeurs de leurs responsabilités. L’article 26 précise 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 n’est pas transférée au fournisseur simplement parce que celui-ci a conçu le modèle.

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

Pourquoi le risque lié à l’IA tierce nécessite une approche différente

La gestion traditionnelle du risque fournisseur évalue la disponibilité, la sécurité des données et les 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 risque que les processus d’achats IT conventionnels n’ont jamais été conçus pour traiter.

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

Opacité de la logique décisionnelle. Une application SaaS classique exécute un code déterministe. Un système d’IA peut produire des résultats influencés par les données d’entraînement, les choix de fine-tuning et les paramètres d’inférence, sans que l’organisation déployeuse n’ait de visibilité sur ces éléments. Lorsqu’un modèle de scoring de crédit rejette une demande ou qu’un outil 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 reste responsable de résultats qu’il ne peut pas interpréter.

Comportement non statique. Les logiciels traditionnels évoluent via des versions publiées. Les modèles d’IA peuvent changer de comportement via le réentraînement, le fine-tuning ou des modifications des pipelines de données sous-jacents, parfois sans cycle de publication formel. Un modèle qui respectait des paramètres acceptables lors de l’achat peut dériver dans les mois suivants. Le déployeur peut ne s’en rendre compte qu’une fois le dommage survenu.

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, du contenu protégé par le droit d’auteur ou des données personnelles traitées sans base légale adéquate. Le déployeur hérite des conséquences de ces choix en amont, même s’il n’a joué aucun rôle dans leur élaboration. En vertu du RGPD, si un système d’IA traite des données personnelles d’une manière incompatible avec les accords de traitement des données du déployeur, celui-ci supporte un risque d’exécution réglementaire aux côtés du fournisseur [3].

Les scorecards fournisseurs classiques ne capturent pas ces dynamiques. Un cadre d’évaluation conçu spécifiquement 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 précise et peut être noté lors de l’achat, d’une revue périodique ou d’une réévaluation déclenchée.

Les organisations utilisant des plateformes telles qu’Enzai peuvent intégrer ce cadre dans les flux de travail existants du cycle de vie fournisseur, en veillant à ce que les critères spécifiques à l’IA soient traités aux côtés des indicateurs traditionnels de risque IT, plutôt que dans un processus séparé et déconnecté.

Questionnaire d’évaluation

Ce tableau doit être considéré comme un instrument vivant. Les seuils de notation varient selon le cas d’usage : un système d’IA à haut risque utilisé pour le triage en santé 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 utile que si les questions sont suffisamment précises pour révéler le 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 model card ou une fiche technique décrivant les cas d’usage prévus, les limites connues et les benchmarks 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 est fondé sur un modèle de fondation tiers (ex. un fournisseur de LLM), pouvez-vous indiquer quel modèle de fondation et quelle version vous utilisez ?

Gouvernance des données et confidentialité

5. Quels jeux 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 ?

6. 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 ?

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

8. Comment les données 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 peut-il s’y opposer ?

Biais, équité et sécurité

9. Ce modèle a-t-il été audité pour les biais sur les caractéristiques protégées telles que définies par le droit anti-discrimination applicable ?

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

11. Quel suivi continu est en place pour détecter l’émergence de biais ou la dégradation des performances entre sous-groupes ?

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

Sécurité et résilience

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

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

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

Conformité et préparation réglementaire

16. Ce système a-t-il été classé selon les catégories de risque de l’AI Act de l’UE, et le cas échéant, quelle classification a-t-il reçue ?

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

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

Réponse aux incidents et responsabilité

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

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

21. Pouvez-vous fournir des exemples d’incidents 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 dépend autant de la manière dont les organisations reçoivent les réponses que du contenu de ces réponses. Certains schémas de réponse doivent déclencher une vigilance renforcée.

Vaguité déguisée en confidentialité

Il existe des motifs légitimes de protection des 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 sa propriété intellectuelle. Il masque le risque. Un fournisseur qui répond « notre modèle est propriétaire et nous ne pouvons pas partager de détails » à chaque question de transparence n’est pas un fournisseur capable de soutenir les obligations réglementaires d’un déployeur.

Absence de documentation

Si un fournisseur ne peut produire ni model card, ni politique de gouvernance des données, ni plan de réponse aux incidents, l’explication la plus probable est que ces éléments 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, qu’il invoque des difficultés logistiques ou des motifs commerciaux, doit être traité avec prudence. L’AI Act de l’UE prévoit explicitement que les déployeurs devront vérifier la conformité des fournisseurs [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 à « Quel est votre plan de réponse aux incidents IA ? » est le silence, un renvoi vers une gestion générique des incidents IT, ou une promesse d’en élaborer un, l’organisation doit se demander si elle est prête à assumer seule l’intégralité des conséquences d’une défaillance IA sans soutien fournisseur.

Langage contractuel de transfert de responsabilité

Surveillez les formulations contractuelles qui tentent de transférer l’intégralité de la responsabilité des résultats IA au déployeur. Bien que les déployeurs aient effectivement des obligations, un fournisseur qui n’accepte aucune responsabilité quant à la performance du modèle, aux biais ou aux défaillances envoie un signal sur sa confiance dans ses propres systèmes.

La tendance d’ensemble importe davantage que chaque réponse prise isolément. Un fournisseur transparent sur ses limites réelles est bien moins risqué qu’un fournisseur qui revendique la perfection sans fournir de preuve.

Protections contractuelles pour les achats d’IA

L’évaluation est nécessaire, mais insuffisante. Les constats doivent être intégrés dans des clauses contractuelles opposables. Les contrats standards d’achat logiciel contiennent rarement des dispositions adéquates pour les risques spécifiques à l’IA. Les clauses suivantes doivent être envisagées dans tout contrat avec un fournisseur d’IA.

Droits d’audit

Le contrat doit accorder au déployeur le droit d’auditer les systèmes d’IA du fournisseur, directement ou via un tiers indépendant, à intervalles raisonnables et en cas d’événements déclencheurs définis (comme un incident signalé ou une enquête réglementaire). Ce droit doit couvrir les données de performance du modèle, les résultats de tests de biais et les pratiques de gouvernance des données.

Notification des incidents

Le contrat doit préciser des délais maximums 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 doit inclure la nature de l’incident, les systèmes affectés, l’impact estimé et les mesures correctives.

Traitement et conservation des données

Le contrat doit préciser de façon exacte comment les données clients sont utilisées en lien avec le système d’IA : si elles sont utilisées pour améliorer le 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. Ceci est particulièrement critique au regard de l’attention réglementaire continue sur l’articulation entre entraînement IA et droits de protection des données [5].

Notification des changements de modèle

Le contrat doit imposer au fournisseur de notifier à l’avance tout changement matériel du modèle, y compris le réentraînement sur de nouvelles données, les changements d’architecture et les ajustements significatifs 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 n’entre en production dans son environnement. Une fenêtre de notification de 30 jours pour les changements non urgents constitue une base raisonnable.

Benchmarks de performance et SLA

Au-delà des SLA de disponibilité traditionnels, le contrat doit établir des benchmarks 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. Le non-respect de ces benchmarks doit entraîner des obligations de remédiation définies et, le cas échéant, des droits de résiliation.

Répartition de responsabilité

Le contrat doit répartir la responsabilité des préjudices 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 doit assumer une responsabilité proportionnée pour les défauts de ces composants. Une indemnisation générale 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 d’exécution qui rend la gouvernance opérationnelle.

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

Une évaluation d’un fournisseur d’IA réalisée une seule fois lors de l’achat puis archivée est un artefact de conformité, pas une pratique de gestion des risques. Les systèmes d’IA évoluent, et les risques qu’ils présentent aussi.

Indicateurs de suivi continu

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

• Dérive de performance. Suivez la qualité des sorties du système d’IA par rapport aux benchmarks établis lors de l’achat. Une 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. Enregistrez tous les incidents liés à l’IA, y compris les quasi-incidents, et analysez leur tendance dans le temps. Une augmentation de la fréquence des sorties anormales justifie une investigation.

• Évolutions réglementaires. Surveillez les changements de la réglementation IA applicable 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é — 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 de revue régulier :

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

• Un incident IA significatif survient, qu’il concerne le déploiement de l’organisation ou qu’il soit signalé publiquement

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

• L’organisation modifie son usage du système d’IA d’une manière qui altère matériellement le profil de risque

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

Intégrer le suivi dans les workflows de gouvernance

Un suivi continu efficace exige plus que de bonnes intentions. Il nécessite des outils qui intègrent la supervision des fournisseurs dans les cadences de gouvernance existantes. Enzai fournit l’infrastructure nécessaire à un suivi continu de l’IA tierce, en connectant les résultats d’évaluation, les obligations contractuelles et les indicateurs de performance en temps réel dans un workflow de gouvernance unifié. Sans cette intégration, les obligations de suivi ont tendance à se dégrader avec le temps, exposant les organisations précisément lorsque la vigilance est la plus nécessaire.

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

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

L’une des dispositions les plus déterminantes et les moins bien comprises de l’AI Act de l’UE concerne les circonstances dans lesquelles un déployeur est requalifié en fournisseur. L’article 25 stipule qu’un déployeur est considéré comme 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 à haut risque, modifie la finalité prévue 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 d’origine [6].

Cela a des implications directes pour les organisations qui personnalisent l’IA tierce. Le fine-tuning d’un modèle fournisseur sur des données propriétaires, la modification de ses sorties via des couches de traitement supplémentaires, ou son déploiement pour un cas d’usage substantiellement différent de la finalité prévue déclarée par le fournisseur peuvent chacun suffire à déclencher une requalification.

Les conséquences de la requalification sont majeures. Un fournisseur assume l’intégralité des obligations de l’AI Act de l’UE pour les systèmes à haut risque, notamment 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 contraignantes que celles imposées aux déployeurs.

Mesures pratiques pour éviter ce piège

• Documenter la finalité prévue. Conservez des enregistrements clairs de la finalité prévue 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 l’étendue de la personnalisation. Avant tout fine-tuning, réentraînement ou modification substantielle d’un système d’IA tiers, réalisez une évaluation visant à déterminer si la modification constitue une « modification substantielle » au sens de l’Acte. Les orientations de la Commission européenne sur ce point devraient apporter davantage de clarté, mais le risque existe dès maintenant [7].

• Clarté contractuelle. Assurez-vous que le contrat fournisseur délimite clairement quelle partie est fournisseur et laquelle est déployeur, et précise les conditions dans lesquelles cette qualification pourrait évoluer.

• Solliciter un conseil juridique en amont. La frontière fournisseur-déployeur est une question de substance, pas d’étiquettes. Se qualifier de déployeur dans un contrat ne prévaut pas sur la détermination factuelle selon laquelle on agit en réalité comme fournisseur.

Le piège de l’article 25 n’est pas hypothétique. À mesure que les organisations personnalisent et affinent davantage les systèmes d’IA fournisseurs, la frontière entre déploiement et fourniture deviendra probablement l’un des domaines les plus activement 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 case à cocher dans les achats. C’est une discipline continue de gouvernance qui couvre les domaines juridiques, techniques et opérationnels. Les organisations qui gèrent efficacement ce risque sont celles qui appliquent à la supervision des fournisseurs d’IA la même rigueur qu’aux contrôles financiers ou à la protection des données.

Le cadre présenté ici constitue un point de départ : évaluation structurée, questions spécifiques, protections contractuelles, suivi continu et vigilance face 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 qui déploient des systèmes d’IA à haut risque dans des environnements réglementés.

Pour les organisations souhaitant opérationnaliser la gouvernance de l’IA tierce à grande échelle, Enzai fournit l’infrastructure de plateforme nécessaire pour gérer les évaluations fournisseurs, suivre les obligations et maintenir une supervision continue sur l’ensemble du portefeuille IA. Demandez une démonstration pour découvrir son fonctionnement concret.

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 (AI Act de l’UE), 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 (AI Act de l’UE), 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 (AI Act de l’UE), 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’AI Act de l’UE.