Vos fournisseurs d’IA sont-ils des tiers comme les autres ?

Un fournisseur d’intelligence artificielle ressemble à un éditeur logiciel jusqu’au moment où son modèle change de comportement, où ses données deviennent contestables ou où un sous-traitant invisible modifie l’infrastructure qui exécute le service.

Le risque ne tient pas seulement à l’hébergement, à la cybersécurité ou à la santé financière du prestataire. Il se loge aussi dans un objet qui évolue après la signature : le modèle, ses données, ses garde-fous, ses dépendances techniques et les usages réels qu’en font les équipes.

Évaluer un fournisseur d’IA exige donc d’étendre la gestion des risques tiers, pas de créer un contrôle parallèle réservé aux experts. L’objectif est simple : savoir qui fournit réellement le service, sur quelles ressources il repose, comment son comportement est surveillé et quelles preuves permettront à l’entreprise de remplir ses propres obligations. Cette orchestration profonde ne peut se faire qu’à travers une solution de TPRM comme Aprovall.

Un fournisseur d’IA ne s’évalue pas comme un éditeur logiciel

Une grille classique vérifie l’existence juridique du tiers, sa solidité, ses assurances, ses certifications de sécurité, sa conformité au RGPD et ses engagements de continuité. Ces contrôles restent indispensables. Mais ils décrivent surtout l’entreprise qui signe le contrat et son environnement technique.

Ils ne suffisent pas à qualifier le système d’IA livré. Deux prestataires présentant les mêmes garanties ISO peuvent exposer l’organisation à des risques très différents selon le modèle utilisé, les données qui l’ont entraîné, la possibilité d’expliquer ses résultats et la fréquence de ses mises à jour.

La difficulté vient d’un décalage : le fournisseur est évalué comme une organisation stable, alors que la prestation dépend d’un système probabiliste et évolutif. Une fonctionnalité jugée acceptable au démarrage peut changer après une nouvelle version, un ajustement des filtres ou le remplacement silencieux du modèle sous-jacent.

La bonne unité d’analyse n’est donc plus seulement le fournisseur. Il faut relier le tiers, le cas d’usage, le modèle, les données traitées et les sous-traitants techniques, au même titre que pour la cyber-résilience de vos fournisseurs critiques. Sans ce lien, une entreprise peut valider un prestataire sérieux tout en ignorant le risque précis du service utilisé.

Quels risques spécifiques qualifier chez un fournisseur d’IA ?

Cinq familles de risques complètent utilement une évaluation fournisseur existante. Elles ne remplacent ni l’analyse cyber ni la due diligence juridique : elles révèlent ce que ces contrôles voient mal.

Cette grille évite un piège fréquent : demander au fournisseur s’il est « conforme à l’AI Act » et accepter une réponse binaire. La qualification doit partir du rôle de chaque acteur, du cas d’usage et des preuves disponibles. Un même service peut être faiblement risqué dans une aide à la rédaction interne et beaucoup plus exposé s’il intervient dans le recrutement, l’accès à un service essentiel ou une décision concernant une personne.

L’intégration d’Aprovall directement dans notre outil achats Ivalua nous permet de sécuriser nos processus sans changer les habitudes des équipes. Les documents sont collectés une seule fois, mutualisés au niveau du groupe et immédiatement accessibles. Cela améliore la qualité des données fournisseurs, simplifie le suivi de la conformité et apporte une vraie valeur ajoutée opérationnelle pour l’ensemble des métiers.

Thibaut Rongier

Responsable de projets SI | Eiffage

Le principe vaut également pour l’IA : les nouveaux critères doivent rejoindre le référentiel fournisseur utilisé par les métiers. S’ils restent dans un questionnaire isolé tenu par une équipe experte, ils seront difficiles à actualiser et invisibles au moment des décisions achats.

L’AI Act et la répercussion en chaîne

L’AI Act répartit les responsabilités selon le rôle joué dans la chaîne : fournisseur, importateur, distributeur ou déployeur. L’entreprise qui utilise un système sous sa propre autorité est généralement un déployeur. Pour les systèmes à haut risque, l’article 26 lui impose notamment de suivre les instructions d’utilisation, d’organiser une supervision humaine compétente, de surveiller le fonctionnement et, sous certaines conditions, de conserver les journaux et de signaler les risques ou incidents.[1]

Ces obligations ne peuvent pas être exécutées sans coopération du fournisseur. Pour surveiller le système, le déployeur doit connaître ses limites et ses indicateurs. Pour organiser une supervision humaine, il doit recevoir une information exploitable. Pour conserver des journaux, traiter un incident ou expliquer une décision, il doit obtenir les accès, les données et les modalités contractuelles appropriés.

La règle frappe donc un acteur, mais transforme ses exigences envers l’acteur précédent. C’est la même mécanique de chaîne que pour DORA et les sous-traitants IT : une obligation de preuve, de surveillance ou de résilience descend dans les questionnaires, les clauses, les droits d’audit et les engagements de notification.

Au 16 septembre 2026, le règlement est applicable de manière générale depuis le 2 août 2026. Les obligations relatives aux modèles d’IA à usage général s’appliquent depuis le 2 août 2025 et les règles de transparence depuis août 2026. Après l’évolution du calendrier européen, certaines règles sur les systèmes à haut risque s’appliqueront plus tard : le 2 décembre 2027 pour les cas d’usage sensibles concernés et le 2 août 2028 pour les systèmes intégrés à certains produits réglementés.[2]

Ce calendrier ne justifie pas d’attendre. Il faut du temps pour inventorier les usages, classifier les systèmes, obtenir les informations des fournisseurs et renégocier les contrats. Le contrôle fournisseur est précisément l’endroit où l’anticipation réglementaire devient une action opérationnelle.

Le shadow AI : les fournisseurs que vous n’avez pas référencés

Le fournisseur d’IA le plus risqué n’est pas toujours celui qui a échoué à l’évaluation. C’est souvent celui qui ne l’a jamais passée. Un collaborateur active un assistant dans un outil SaaS déjà autorisé, souscrit une offre en ligne avec une carte, connecte une extension à sa messagerie ou transmet des documents à un service gratuit.

Le tiers entre alors dans l’organisation par l’usage, pas par les achats. Il peut traiter des données confidentielles, produire des contenus utilisés dans une décision ou s’appuyer sur plusieurs fournisseurs techniques sans apparaître dans le référentiel officiel. Le contrat existe parfois uniquement sous la forme de conditions générales acceptées en ligne.

Le shadow AI prolonge le shadow IT, mais il ajoute une difficulté : la fonctionnalité d’IA peut être intégrée à un fournisseur déjà référencé. Le tiers est connu, mais le nouveau service, son modèle et ses flux de données ne le sont pas. Un inventaire limité aux nouveaux fournisseurs laissera donc passer une partie importante de l’exposition.

La réponse ne consiste pas seulement à interdire. Il faut rendre l’entrée dans le processus simple : déclaration courte du cas d’usage, pré-évaluation rapide, catalogue de solutions autorisées et circuit renforcé uniquement lorsque la criticité le justifie. Plus le contrôle est disproportionné, plus les équipes chercheront à le contourner.

Comment adapter votre grille d’évaluation existante ?

Créer un dispositif autonome pour les fournisseurs d’IA multiplierait les référentiels, les propriétaires et les campagnes de collecte. Il est plus robuste d’ajouter un embranchement à l’évaluation tiers existante : quelques questions identifient la présence d’IA, puis un questionnaire proportionné s’ouvre selon le cas d’usage.

L’évaluation amont peut notamment demander :

La profondeur des justificatifs dépend ensuite de la criticité. Un outil de génération d’idées sans données sensibles n’appelle pas la même diligence qu’un système qui trie des candidatures ou contribue à une décision de crédit. La proportionnalité évite de transformer l’IA en exception permanente tout en concentrant les contrôles sur les usages qui peuvent réellement créer un dommage.

Comment piloter des fournisseurs qui évoluent après la signature ?

Une évaluation datée du jour de la signature ne couvre pas un service dont le modèle, l’infrastructure et les conditions d’utilisation changent régulièrement. Le suivi doit porter sur des événements : nouvelle version majeure, changement de modèle amont, ajout d’un sous-traitant, transfert géographique, modification de l’usage des données, baisse de performance, vulnérabilité ou incident.

Chaque événement n’impose pas de recommencer toute la due diligence. Il doit déclencher le bon niveau de réévaluation. Une mise à jour mineure peut être journalisée ; un changement de modèle ou de politique d’entraînement peut exiger de nouveaux tests, une validation juridique et une décision du propriétaire métier.

L’automatisation des contrôles réglementaires nous a permis de sécuriser nos processus tout en libérant du temps pour notre cœur de métier. L’équipe achats peut désormais se concentrer davantage sur l’accompagnement des prescripteurs et sur la qualité de nos relations fournisseurs.

Amadou Seck

Responsable du Pôle achats, Direction des Affaires Financières | UPEC

À l’UPEC, le suivi de plus de 250 tiers s’appuie notamment sur des alertes en temps réel lorsque la situation d’un fournisseur change. Pour les fournisseurs d’IA, cette logique doit être enrichie de signaux propres au service et au modèle, mais le principe reste identique : détecter un changement, le rattacher au tiers concerné et conserver la trace de la réponse apportée.

Une plateforme TPRM comme Aprovall peut centraliser cette gouvernance : segmentation des fournisseurs d’IA, questionnaires conditionnels, chaîne de sous-traitance, preuves, échéances, alertes et historique des décisions. Elle ne mesure pas seule la qualité technique d’un modèle ; elle permet de relier cette expertise aux processus achats, juridiques, sécurité, conformité et métiers.

La première action n’est donc pas de créer un comité supplémentaire. Elle consiste à interroger le référentiel tiers : quels fournisseurs proposent déjà une fonctionnalité d’IA, quels usages soutiennent-ils et lesquels peuvent changer sans nouvelle validation ? Tant que ces trois réponses ne sont pas disponibles, l’entreprise ne pilote pas ses fournisseurs d’IA : elle les découvre au fil des incidents.