1. Blog >
  2. Entreprise
  3. L’AI Act impose de nouvelles exigences à vos prestataires externes
Mis à jour le 29 septembre 2026

L’AI Act impose de nouvelles exigences à vos prestataires externes

Publié par

  • Jeanne Delozanne
Document with "Prestataires externes" and an icon of a magnifying glass over a page, set against a blue background with a "3/4" label.

Le règlement européen sur l’intelligence artificielle ne concerne pas uniquement les éditeurs de logiciels. Dès qu’une Direction Achats fait appel à un freelance, une ESN ou un éditeur SaaS qui utilise l’intelligence artificielle pour produire un livrable ou intervenir dans un processus métier, elle doit qualifier une partie du risque : confidentialité des données, propriété intellectuelle, rôle réglementaire, documentation et traçabilité.

La question opérationnelle n’est donc pas seulement : « faut-il autoriser l’IA chez nos prestataires ? » Elle est plutôt : quelles questions poser avant une mission, quelles exigences intégrer au sourcing et au contrat, et quelles preuves demander ?

Cet article propose une méthode achats pour encadrer les usages d’IA des prestataires externes. Il constitue une aide à la décision opérationnelle et non un avis juridique. Les clauses proposées doivent être adaptées et validées par votre direction juridique.

Ce que l’AI Act change pour une Direction Achats

Le règlement (UE) 2024/1689, dit AI Act, est entré en vigueur le 1er août 2024 et s’applique par étapes. Trois jalons intéressent directement les achats.

Depuis le 2 février 2025, les pratiques interdites de l’article 5 sont applicables, tout comme l’obligation de maîtrise de l’IA prévue à l’article 4. Depuis le 2 août 2025, les obligations relatives aux modèles d’IA à usage général sont entrées en application. Depuis le 2 août 2026, le règlement est entré dans sa phase générale d’application, notamment pour les obligations de transparence de l’article 50 et le dispositif de supervision réglementaire.

Le calendrier des systèmes à haut risque a toutefois été ajusté. Les règles applicables à plusieurs cas d’usage de l’annexe III, notamment dans l’emploi et la gestion de la main-d’œuvre, s’appliqueront à partir du 2 décembre 2027. Les systèmes à haut risque intégrés dans des produits réglementés relevant de l’annexe I sont concernés à partir du 2 août 2028, sous réserve des dispositions transitoires applicables. La Commission européenne présente le calendrier et les dernières évolutions officielles.

Le point décisif pour un acheteur tient en une phrase : l’obligation ne s’arrête pas à la frontière de l’entreprise. L’article 4 demande aux fournisseurs et aux déployeurs de prendre des mesures pour garantir un niveau suffisant de maîtrise de l’IA chez leur personnel et chez les autres personnes qui utilisent des systèmes d’IA pour leur compte.

Un prestataire externe ou un freelance qui opère un outil d’IA dans le cadre d’une mission peut donc entrer dans ce périmètre. Il s’agit d’un sujet de contrat, de contrôle et de preuve, pas seulement de sensibilisation interne.

Point de vigilance sur le calendrier

Le calendrier d’application a fait l’objet d’évolutions au niveau européen, notamment pour les systèmes à haut risque. Vérifiez l’état du texte applicable à la date de votre décision avant de figer une politique fournisseurs ou un modèle de clause.

Un dispositif d’achats calé sur une version périmée du calendrier crée une fausse sécurité. Le texte consolidé disponible sur EUR-Lex doit rester la référence pour les qualifications sensibles.

Êtes-vous déployeur ou fournisseur ? Les trois cas de bascule

C’est la première question à trancher avant de rédiger une clause, car elle détermine le volume d’obligations que votre entreprise porte.

Dans la majorité des situations d’achat, l’entreprise qui utilise un système d’IA fourni par un tiers est déployeur. Lorsque le système est à haut risque, l’article 26 prévoit notamment de l’utiliser conformément à la notice d’utilisation, de confier la supervision humaine à des personnes compétentes et formées, de veiller à la pertinence des données d’entrée dans la mesure de son contrôle, de surveiller le fonctionnement, de conserver les journaux et d’informer les travailleurs et leurs représentants avant une mise en service sur le lieu de travail lorsque l’obligation s’applique.

Mais l’entreprise peut basculer en fournisseur et récupérer les obligations attachées à ce rôle. L’article 25 identifie trois situations :

  1. l’entreprise appose son nom ou sa marque sur un système à haut risque déjà mis sur le marché ;

  2. elle apporte une modification substantielle à un tel système ;

  3. elle modifie la finalité d’un système qui n’était pas classé à haut risque, de telle sorte qu’il le devient.

Traduction achats : qualifier les rôles avant de signer

Un projet dans lequel un prestataire paramètre, entraîne ou adapte un outil pour un usage métier spécifique, sous votre marque, peut vous transformer en fournisseur sans qu’aucune décision explicite n’ait été prise.

La clause à écrire n’est donc pas seulement une clause d’interdiction. C’est d’abord une clause de qualification : qui est fournisseur, qui est déployeur, quelles obligations sont assumées par chaque partie et qui notifie l’autre en cas de changement susceptible de modifier cette qualification.

Pour revoir les définitions de fournisseur et de déployeur, vous pouvez consulter notre guide général sur l’AI Act.

Le cas des achats de prestations intellectuelles

L’annexe III classe à haut risque certains systèmes utilisés dans le domaine de l’emploi et de la gestion de la main-d’œuvre, notamment ceux destinés au recrutement, à la diffusion ciblée d’offres, à l’analyse et au filtrage de candidatures et à l’évaluation de candidats.

Les achats de prestations intellectuelles sont donc concernés dès qu’un outil intervient dans la présélection ou le scoring de profils, y compris pour des travailleurs indépendants. Ce point doit être qualifié explicitement avec votre direction juridique avant de déployer un outil de matching, quel que soit son fournisseur.

Un outil proposé par un prestataire qui analyse l’engagement, détecte un niveau de stress ou évalue des émotions au travail doit également faire l’objet d’un examen spécifique. L’article 5 interdit notamment certains systèmes de reconnaissance des émotions sur le lieu de travail, en dehors de cas très limités.

Pour les achats RH, la bonne pratique consiste à traiter ces usages dès le sourcing, et non au stade du pilote. Le filtre juridique et conformité doit intervenir avant la sélection finale du prestataire.

Trois profils de prestataires, trois profils de risque

L’erreur la plus fréquente consiste à traiter « les prestataires » comme une catégorie unique. Les risques n’ont ni la même nature, ni le même remède contractuel.

Profil de prestataire Risque dominantExigence prioritaire
Freelance ou consultant indépendant
Fuite de données dans un outil non maîtrisé, réutilisation des contenus transmis, incertitude sur les droits attachés au livrable
Politique IA fournisseurs, déclaration d’usage et règles de données annexées au contrat
ESN, agence ou intégrateur
Répartition des rôles dans la chaîne de valeur, sous-traitance et adaptation du système
Matrice de responsabilités, documentation et information mutuelle sur les changements
Éditeur de logiciel ou service en ligne
Qualification du système, documentation, performances, limites et transparence
Exigences documentaires opposables dès l’appel d’offres et vérifiables pendant le contrat

Le freelance utilise souvent des outils d’IA grand public, sur son propre compte, avec ses propres réglages. Le risque dominant est alors contractuel et informationnel.

L’ESN, l’agence ou l’intégrateur peut concevoir, paramétrer ou intégrer une solution dans votre système d’information. Le risque se déplace vers la chaîne de valeur : qui est fournisseur au sens de l’article 25, quelles preuves sont transmises et comment sont gérées les sous-traitances ultérieures ?

L’éditeur de logiciel met un système d’IA sur le marché. Le risque porte davantage sur la qualification du système, la notice d’utilisation, les performances, les limites connues et les obligations de transparence de l’article 50.

Cette segmentation doit se retrouver dans vos grilles de sourcing. Poser les mêmes questions à un freelance en rédaction technique et à un éditeur de solution de scoring produit un questionnaire mal renseigné et une fausse impression de contrôle.

Les 12 questions à poser avant de démarrer une mission

Ce questionnaire peut être intégré au RFI, à l’appel d’offres ou à l’onboarding du prestataire. Il doit produire des réponses écrites, datées et annexées au contrat. Une réponse orale n’est pas une preuve.

  1. Quels outils d’IA utilisez-vous pour produire les livrables de cette mission ? Demandez le nom de l’outil, sa version et le type d’abonnement. Un plan grand public et un plan entreprise n’offrent pas nécessairement les mêmes garanties.

  2. Nos données servent-elles à entraîner ou améliorer des modèles ? Exigez une réponse contractuelle claire, et non un simple renvoi vers des conditions générales modifiables.

  3. Où les données sont-elles traitées et hébergées ? Identifiez les sous-traitants ultérieurs, les transferts hors Union européenne et la base légale applicable au titre du RGPD.

  4. Qui détient les droits sur les livrables produits avec assistance IA ? Demandez une cession de droits explicite et une garantie d’éviction couvrant le risque de contrefaçon.

  5. Quelle part du livrable est générée ou fortement assistée ? Demandez une déclaration d’usage par livrable, plutôt qu’une mention générale en début de mission.

  6. L’outil relève-t-il d’une pratique interdite ou d’un usage listé à l’annexe III ? Une réponse positive non maîtrisée doit déclencher un examen juridique avant toute mise en œuvre.

  7. Quel est votre rôle réglementaire déclaré ? Demandez au prestataire de préciser s’il intervient comme fournisseur, déployeur, importateur ou distributeur.

  8. Pouvez-vous fournir la documentation technique et la notice d’utilisation, ainsi que les informations sur les performances, les limites connues et les conditions d’usage prévues ?

  9. Quelles mesures de supervision humaine appliquez-vous ? Quel niveau de formation à l’IA ont les personnes affectées à la mission, au regard de l’article 4 ?

  10. Comment nous informez-vous d’un changement de modèle, de version, de sous-traitant, d’un incident ou d’un biais détecté ? Fixez un délai de notification, pas seulement un principe.

  11. Quelles preuves pouvez-vous produire ? Demandez, selon la criticité, une certification ISO/IEC 42001, des rapports d’audit, des tests de robustesse, des évaluations de biais ou des résultats de revue de sécurité. ISO présente le rôle de la norme ISO/IEC 42001.

  12. Quelle est la réversibilité en fin de mission ? Précisez la restitution et la suppression des données, le sort des prompts, des historiques et des index vectoriels, ainsi que la portabilité des livrables dans un format exploitable.

Une règle simple s’applique à l’exploitation de ce questionnaire : une réponse non vérifiable équivaut à une absence de réponse. Le déclaratif fournisseur non étayé est l’un des principaux angles morts des démarches de conformité engagées dans l’urgence.

Proposer une politique IA fournisseurs en 6 règles

Une politique IA fournisseurs n’est pas nécessairement un document juridique de trente pages. C’est un document court, diffusable à l’ensemble de votre panel, qui rend vos attentes prévisibles et comparables.

  1. Définir un périmètre commun. Précisez ce que vous appelez usage d’IA : génération de contenu, aide au code, analyse de données, traitement de documents ou agent automatisé.

  2. Distinguer trois niveaux d’usage. Séparez l’usage bureautique sans données sensibles, l’assistance à la production de livrables et l’intégration d’un système d’IA dans un processus métier. Le troisième niveau justifie une instruction complète et une revue juridique.

  3. Fixer une règle de données explicite. Indiquez quelles informations ne doivent jamais être transmises à un outil d’IA : données personnelles, données clients, code source propriétaire, éléments couverts par le secret des affaires et informations financières non publiques.

  4. Imposer une déclaration d’usage. Tout usage d’IA générative ayant contribué substantiellement à un livrable doit être déclaré, avec l’outil concerné. Cette règle sert la traçabilité et rejoint, pour certains contenus, les obligations de transparence de l’article 50.

  5. Maintenir la responsabilité du prestataire. L’usage d’un outil d’IA ne réduit ni l’obligation de vérification, ni la garantie de conformité, ni la responsabilité sur les erreurs factuelles.

  6. Organiser la traçabilité et la révision. Désignez un point de contact, exigez la conservation des éléments de preuve pendant la durée du contrat et prévoyez une révision périodique de la politique.

Publiez cette politique avant de l’imposer contractuellement et laissez un délai d’appropriation. Un panel de freelances confronté du jour au lendemain à une clause IA non expliquée peut refuser de signer ou signer sans l’avoir comprise. Aucune de ces situations ne réduit votre risque.

Intégrer les exigences dans le sourcing et les contrats

Au stade du sourcing

Trois ajouts suffisent à déplacer la conformité en amont. Le premier consiste à intégrer un volet IA au questionnaire de présélection, calibré selon le profil du prestataire. Le deuxième est un critère éliminatoire clair : pratique interdite au sens de l’article 5, refus de garantir la non-utilisation des données pour l’entraînement ou impossibilité de documenter un système intervenant dans un processus sensible.

Le troisième ajout consiste à pondérer la maîtrise de l’IA dans la grille de notation. Sans pondération, le critère ne pèsera sur aucune décision d’attribution.

Le principe est le même que pour la sécurité ou le RGPD : formaliser les exigences avant la mise en concurrence, plutôt que découvrir les écarts pendant l’exécution. C’est la logique d’un sourcing outillé, où les exigences, réponses et preuves restent attachées au profil du prestataire et traçables dans le temps.

L’article Achats augmentés : comment l’IA réinvente le cycle Source-to-Pay ? présente les enjeux de l’IA dans les achats de prestations intellectuelles et complète ce volet opérationnel.

Au stade du contrat

Les clauses suivantes doivent être adaptées et validées par votre direction juridique :

ClauseExigence à formaliser
Déclaration et autorisation d’usage
Liste des outils autorisés, procédure de validation d’un nouvel outil et interdiction de tout usage non déclaré
Non-entraînement et confidentialité renforcée
Engagement de non-utilisation des données transmises à des fins d’entraînement, y compris par les sous-traitants ultérieurs
Propriété intellectuelle
Cession des droits sur les livrables, garantie d’éviction et prise en charge des conséquences d’une atteinte aux droits de tiers
Qualification réglementaire
Rôle déclaré de chaque partie au sens des articles 25 et 26, avec information immédiate en cas de changement
Documentation et preuves
Livraison de la notice d’utilisation, informations sur les limites, certifications éventuelles et engagement de maintien à jour
Incidents et évolutions
Délai de notification en cas de changement de modèle, version, sous-traitant, biais ou dysfonctionnement
Audit et vérification
Droit de demander des preuves complémentaires, voire un audit pour les usages les plus critiques
Responsabilité et assurance
Répartition des responsabilités, plafonds et attestation d’assurance couvrant l’activité concernée
Réversibilité et sortie
Restitution, suppression, portabilité et traitement des éléments dérivés
Évolution réglementaire
Mécanisme de mise en conformité en cours de contrat, sans renégociation complète

La directive (UE) 2024/2853 sur la responsabilité du fait des produits défectueux traite explicitement le logiciel comme un produit dans le cadre de la responsabilité sans faute. Son application doit être examinée avec le juridique, notamment au regard des règles nationales de transposition et de la nature de la mission.

Ne pas oublier les données personnelles

L’AI Act ne remplace pas le RGPD : les deux cadres s’appliquent en parallèle. Dès qu’un outil d’IA traite des données personnelles, les obligations habituelles subsistent, y compris l’analyse d’impact lorsqu’elle est requise.

La CNIL propose un guide d’auto-évaluation pour les systèmes d’IA, qui distingue notamment les rôles de fournisseur, d’utilisateur final, de responsable de traitement et de sous-traitant. Cette analyse doit être menée au cas par cas.

Les exigences fournisseurs doivent également couvrir la base légale, la minimisation des données, les durées de conservation, les droits des personnes, la réutilisation éventuelle des données et les transferts internationaux. L’avis 28/2024 du Comité européen de la protection des données apporte des éléments sur le traitement des données personnelles dans le contexte des modèles d’IA.

Pour les secteurs régulés, la maîtrise du risque prestataire doit enfin s’articuler avec les cadres existants sur la résilience opérationnelle et la cybersécurité. Mieux vaut étendre un dispositif existant que créer un processus parallèle.

Les 5 erreurs qui coûtent le plus cher

ErreurPourquoi elle fragilise le dispositif
Interdire l’IA à tous les prestataires
Une interdiction générale est difficilement vérifiable et peut favoriser l’usage clandestin, donc la perte de traçabilité
Collecter des questionnaires sans les vérifier
Le risque devient documenté mais non traité, ce qui fragilise l’entreprise en cas de contrôle ou de litige
Copier une clause sans qualifier les rôles
Une clause qui ne distingue pas fournisseur et déployeur devient difficilement applicable
Traiter le sujet uniquement au juridique
La qualification dépend de l’usage réel, connu des équipes métier, de la DSI et des acheteurs
Figer le dispositif sur un calendrier
Les échéances et le périmètre des obligations évoluent, ce qui impose une revue périodique

Structurer la relation avec vos prestataires externes

La maîtrise du risque IA ne repose pas sur un document unique, mais sur trois éléments alignés : des exigences formulées avant la mise en concurrence, des engagements écrits et vérifiables au contrat, et une traçabilité conservée pendant toute la durée de la mission.

C’est le même sujet que celui de la maîtrise du panel de prestataires en général : savoir qui intervient, avec quels outils, sous quelles conditions, et pouvoir le démontrer. Une plateforme de sourcing centralisant les profils, les engagements et les documents contractuels facilite cette traçabilité, là où un suivi par échanges de courriels la rend rapidement difficile.

Si vous souhaitez cadrer vos exigences IA avant de lancer une consultation ou sécuriser une mission déjà engagée avec des experts externes, échangez avec LittleBig Connection pour préciser votre besoin.

Les règles applicables peuvent varier selon le rôle de l’organisation, le type de système, la criticité de la mission, les données traitées et le cadre contractuel. Il est préférable de faire valider les qualifications et les clauses par les équipes juridiques, conformité, DSI, achats et protection des données concernées.

FAQ

FAQ sur l’AI Act et les prestataires externes

Blog LittleBig Connection

Découvrez plus d’articles sur
le même sujet