Votre entreprise fait développer un logiciel intégrant un moteur d'IA, déploie une solution SaaS avec une brique de reconnaissance, ou confie à un prestataire la création d'un modèle entraîné sur vos données. Un cabinet de conseil peut aussi, sans en être pleinement conscient, devenir déployeur d'un système d'IA en signant un devis pour une plateforme d'agents générateurs de rapports. À partir du 2 août 2026, le règlement (UE) 2024/1689 — l'IA Act — devient pleinement applicable. Votre contrat de sous-traitance doit alors qualifier précisément les rôles de chaque partie, organiser la circulation des informations techniques et répartir la charge de la conformité. Un contrat silencieux sur ces points expose le donneur d'ordre à des sanctions pouvant atteindre 15 millions d'euros ou 3 % du chiffre d'affaires mondial. Cet article détaille les clauses à intégrer, la façon de répartir la responsabilité entre donneur d'ordre et sous-traitant, et la démarche à engager sur les contrats déjà signés.
Ce que l'IA Act change pour vos contrats de sous-traitance
Le règlement (UE) 2024/1689, adopté le 13 juin 2024 et publié au JOUE le 12 juillet 2024, instaure un cadre harmonisé pour la mise sur le marché, la mise en service et l'utilisation des systèmes d'intelligence artificielle dans l'Union. Son entrée en vigueur est intervenue le 1er août 2024, mais son application se déroule par paliers fixés à l'article 113.
Le premier palier, au 2 février 2025, a rendu applicables les interdictions de l'article 5 (notation sociale, reconnaissance des émotions au travail, scoring biométrique en lieu public, etc.) et les dispositions générales des chapitres I et II. Le deuxième palier, au 2 août 2025, a activé les obligations relatives aux modèles d'IA à usage général (GPAI) prévues au chapitre V. Le palier décisif pour la très grande majorité des entreprises intervient le 2 août 2026 : application des obligations sur les systèmes d'IA à haut risque listés à l'Annexe III et des obligations de transparence de l'article 50. Un dernier palier, au 2 août 2027, concerne les systèmes d'IA intégrés dans des produits déjà réglementés (machines, dispositifs médicaux, jouets, etc.).
Ce calendrier concerne directement les contrats de sous-traitance pour deux raisons. Premièrement, l'article 25 du règlement impose un accord écrit entre le fournisseur d'un système d'IA à haut risque et les tiers qui lui fournissent des outils, services, composants ou processus intégrés dans ce système. Deuxièmement, l'article 99 assortit le dispositif de sanctions administratives lourdes : jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires mondial pour une violation des pratiques interdites, jusqu'à 15 millions d'euros ou 3 % pour les autres obligations applicables aux opérateurs, jusqu'à 7,5 millions d'euros ou 1 % pour la transmission d'informations incorrectes aux autorités. Un contrat qui ne clarifie pas la répartition des obligations crée un risque financier direct pour chacune des parties.
Qui est fournisseur, qui est déployeur : qualifier les parties dans le contrat
L'article 3 du règlement distingue cinq rôles économiques, dont deux concentrent la charge principale des obligations et méritent une qualification explicite dans le contrat.
Le fournisseur (provider) est défini à l'article 3, paragraphe 3, comme toute personne qui développe un système d'IA ou un modèle d'IA à usage général, ou le fait développer, et le met sur le marché ou le met en service sous son propre nom ou sa propre marque, à titre onéreux ou gratuit. Le déployeur (deployer), à l'article 3, paragraphe 4, est celui qui utilise sous sa propre autorité un système d'IA, sauf dans le cadre d'une activité personnelle non professionnelle. Les trois autres rôles — importateur (§ 6), distributeur (§ 7), fabricant de produit (§ 3 point 6) — concernent des situations plus rares en sous-traitance d'innovation.
Dans un contrat classique de développement sur mesure avec intégration d'un système d'IA, la qualification est rarement évidente. Si le donneur d'ordre fait développer un système qu'il commercialisera ensuite sous sa propre marque, il est fournisseur au sens du règlement, même s'il n'a pas écrit une ligne de code. Le sous-traitant, dans cette configuration, fournit des composants ou des services intégrés au système du donneur d'ordre et relève de l'article 25 paragraphe 4. Si le sous-traitant livre un système finalisé sous sa propre marque et que le donneur d'ordre se contente de l'utiliser, la logique s'inverse : le sous-traitant est fournisseur, le donneur d'ordre est déployeur.
L'article 25 paragraphe 1 prévoit un mécanisme de basculement : un distributeur, un importateur, un déployeur ou tout autre tiers devient fournisseur d'un système d'IA à haut risque — avec toutes les obligations correspondantes — dans trois cas. D'abord s'il appose son nom ou sa marque sur un système déjà mis sur le marché, sans préjudice de stipulations contractuelles prévoyant une répartition différente. Ensuite s'il apporte une modification substantielle à un système haut risque mis sur le marché. Enfin s'il modifie la destination d'un système qui n'était pas initialement à haut risque au point de le faire relever de l'Annexe III.
Les conséquences contractuelles sont directes. Le préambule du contrat doit identifier nommément le fournisseur et le déployeur du système d'IA résultant de la prestation, en renvoyant aux définitions du règlement. Une clause de non-commercialisation sous la marque du sous-traitant doit être intégrée lorsque le donneur d'ordre veut conserver la qualité de fournisseur unique. Les modifications substantielles et les changements de destination doivent être encadrés par une clause d'information et d'approbation préalable écrite, faute de quoi le donneur d'ordre peut voir sa qualité de fournisseur lui échapper sans en avoir conscience. Une clause d'attestation de conformité au règlement signée par le sous-traitant à chaque livraison majeure documente par ailleurs la bonne foi du donneur d'ordre en cas de contrôle.
Les clauses obligatoires pour un système d'IA à haut risque
L'Annexe III du règlement liste huit domaines dans lesquels un système d'IA est qualifié à haut risque : biométrie et catégorisation biométrique, infrastructures critiques, éducation et formation professionnelle, emploi et gestion des travailleurs, accès aux services privés essentiels et services publics, répression pénale, migration et contrôle aux frontières, administration de la justice et processus démocratiques. Dès lors qu'un système tombe dans l'une de ces catégories, l'article 25 paragraphe 4 impose un accord écrit entre le fournisseur et chaque tiers lui fournissant un système d'IA, des outils, des services, des composants ou des processus utilisés ou intégrés dans ce système.
Cet accord doit spécifier, selon la lettre du texte, « les informations, les capacités, l'accès technique et toutes les autres formes d'assistance nécessaires, fondés sur l'état de l'art généralement reconnu, pour permettre au fournisseur du système d'IA à haut risque de se conformer pleinement aux obligations du présent règlement ».
Traduit en clauses opérationnelles, cela suppose d'intégrer six engagements du sous-traitant : la communication de la documentation technique du composant, en cohérence avec l'article 11 et l'Annexe IV (méthodes d'entraînement, jeux de données, performance) ; l'accès aux journaux générés par le composant, conformément à l'article 12 qui impose une traçabilité automatisée ; la fourniture des éléments nécessaires au système de gestion des risques tenu à jour au titre de l'article 9 ; la mise à disposition des informations permettant la supervision humaine imposée par l'article 14 ; le soutien à la démarche d'évaluation de conformité, notamment si un organisme notifié est impliqué ; une obligation de mise à jour continue lorsque le composant évolue après la mise sur le marché.
L'article 25 paragraphe 4 prévoit une exemption pour les tiers mettant à disposition du public, sous licence libre et open source, des outils, services, processus ou composants autres que des modèles d'IA à usage général. L'entreprise qui intègre un module open source n'a pas besoin d'un accord écrit avec la communauté, mais cette exemption ne la dispense pas de respecter ses obligations de fournisseur sur le système final. Le contrat avec le sous-traitant qui intègre ces briques doit donc lui imposer de documenter l'origine, la licence et la version de chaque composant, et de garantir l'absence de contamination par des licences virales incompatibles avec le modèle commercial du donneur d'ordre.
Le Bureau de l'IA institué à l'article 64 est chargé de publier des clauses-types volontaires pour faciliter la rédaction de ces accords. À défaut de leur publication avant la négociation, une rédaction adaptée aux six points ci-dessus est indispensable.
Tous les systèmes d'IA ne relèvent cependant pas du haut risque. Un outil d'aide à la rédaction de rapports destiné à un usage professionnel interne, fondé sur des agents orchestrés par un modèle de langage tiers, ne figure dans aucune catégorie de l'Annexe III : l'article 25 paragraphe 4 ne s'y applique pas, seules les obligations de transparence de l'article 50 s'imposent au fournisseur et au déployeur. L'erreur courante consiste à calquer l'arsenal haut risque sur un contrat qui n'en a pas besoin, ou à l'inverse à considérer le contrat comme hors du règlement. Le régime applicable varie selon la qualification précise, et chaque qualification appelle ses propres clauses.
Répartir la responsabilité entre donneur d'ordre et sous-traitant
Une fois la qualification des rôles stabilisée, le contrat doit allouer la charge des obligations et organiser les conséquences d'un défaut. Plusieurs axes de rédaction méritent une attention particulière, au premier rang desquels la garantie de conformité, l'audit et la répartition financière du risque.
La garantie de conformité du composant livré constitue la première ligne de défense du donneur d'ordre. Le sous-traitant doit garantir que le composant, les données d'entraînement, la documentation et les interfaces livrées permettent au donneur d'ordre de satisfaire ses propres obligations réglementaires. La clause de garantie doit préciser le référentiel (version du règlement applicable à la date de mise sur le marché, lignes directrices de la Commission, normes harmonisées publiées au JOUE) et prévoir un mécanisme de mise à jour continue en cas d'évolution de ces textes. Une garantie statique est insuffisante : le règlement prévoit l'adoption d'actes délégués et d'actes d'exécution qui modifieront les exigences techniques.
La clause d'audit et d'accès aux logs techniques ouvre au donneur d'ordre la possibilité de vérifier la conformité effective du composant. Elle doit préciser le périmètre (journaux applicatifs, journaux d'entraînement, échantillons de données), le délai de mise à disposition, la confidentialité, la possibilité de mandater un tiers indépendant et la prise en charge des coûts. La simple stipulation d'un droit d'audit sans modalités pratiques s'avère rapidement inopérante en cas d'inspection par une autorité nationale compétente.
La répartition des conséquences financières d'une non-conformité est le troisième axe. L'article 99 du règlement fixe des sanctions administratives dont le montant peut excéder largement la valeur du contrat de sous-traitance. Le plafond de responsabilité contractuelle habituel (par exemple 100 % du prix sur douze mois) n'absorbe pas ce risque. Trois options de rédaction existent : un plafond spécifique dérogatoire limité aux violations du règlement, exprimé en valeur absolue ou en pourcentage du chiffre d'affaires du sous-traitant ; une exclusion des sanctions administratives de toute limitation, ce qui suppose une assurance responsabilité civile professionnelle spécifiquement étendue ; un mécanisme d'indemnisation proportionnel à la responsabilité respective de chaque partie dans la cause du manquement.
L'article 25 paragraphe 2 impose par ailleurs une obligation de coopération entre le fournisseur initial et tout nouveau fournisseur dans la chaîne de valeur. Cette obligation légale ne se substitue pas à une clause contractuelle : une clause de coopération documentée, avec délais de réponse et gouvernance dédiée (comité technique, point de contact unique, escalade), sécurise l'exécution de l'obligation légale.
Les clauses complémentaires à ne pas oublier
Au-delà du socle article 25, plusieurs sujets connexes méritent un traitement contractuel distinct pour éviter les zones grises.
Les données d'entraînement soulèvent une double question de propriété et de licéité. L'article 10 du règlement impose au fournisseur d'un système haut risque des obligations fortes de gouvernance des données : pertinence, représentativité, absence d'erreurs, prise en compte des spécificités de l'usage prévu. Le contrat doit définir l'origine des jeux de données (données du donneur d'ordre, données publiques, données tierces licenciées), les droits d'utilisation conférés au sous-traitant, les conditions de réutilisation post-contrat et l'articulation avec le RGPD lorsque des données personnelles sont en jeu. L'article 28 du règlement (UE) 2016/679 impose en effet un contrat de sous-traitance de données personnelles dont les exigences s'ajoutent à celles de l'IA Act sans s'y substituer.
La propriété intellectuelle du modèle entraîné et du système livré mérite une clause dédiée. Deux régimes se superposent : la titularité des droits sur le code source et le modèle (poids, architecture), d'une part ; la titularité des droits sur les données d'entraînement et les sorties générées, d'autre part. Le recours à des briques open source introduit un risque de contamination par des licences copyleft (GPL, AGPL) qu'une clause de politique open source doit neutraliser en imposant une liste blanche de licences compatibles et un mécanisme de validation préalable.
Les obligations de transparence de l'article 50, applicables à partir du 2 août 2026, imposent l'information de l'utilisateur final pour certains systèmes (chatbots, systèmes de reconnaissance des émotions ou de catégorisation biométrique, contenus synthétiques ou manipulés). Le contrat doit désigner la partie responsable de la mise en œuvre de cette information (typiquement le déployeur pour le canal utilisateur, le fournisseur pour la conception des signaux techniques).
La supervision humaine imposée par l'article 14 pour les systèmes haut risque se traduit par des exigences d'architecture du système (interfaces, contrôles, documentation). Le contrat de sous-traitance doit préciser qui conçoit ces dispositifs et qui forme les personnes qui les opéreront, ainsi que la documentation de formation à livrer.
La réversibilité enfin, dans un contrat de sous-traitance d'innovation intégrant un système d'IA, doit couvrir le code source, les poids du modèle entraîné, la documentation technique, les jeux de données annotées et les outils d'entraînement. Une clause de réversibilité classique calibrée pour une infogérance IT est insuffisante pour un actif d'IA.
Trois lacunes se retrouvent dans les contrats SaaS d'outils d'IA signés en 2024-2025. Le réentraînement silencieux : le prestataire réserve « modèles IA, bibliothèques logicielles et savoir-faire » tout en recueillant les données chargées par son client, sans clause interdisant leur réutilisation. Pour un professionnel tenu au secret ou pour une entreprise dont les données intègrent des secrets d'affaires, cette omission est disqualifiante. La limite de responsabilité calquée sur le prix : un plafond égal au montant HT payé n'a aucune commune mesure avec les conséquences d'une sortie erronée intégrée dans un document transmis à une autorité ou à un tiers. La sous-traitance en cascade non transparente : une autorisation générale de sous-traiter « sous réserve d'obligations équivalentes » masque l'intervention de fournisseurs de modèles tiers (OpenAI, Anthropic, Mistral, etc.) dont l'identité reste inconnue du client. L'article 25 paragraphe 4, même non formellement applicable, donne un standard utile : exiger l'identification écrite des tiers intervenant dans la chaîne.
Comment sécuriser un contrat déjà signé avant le 2 août 2026
L'entrée en application du règlement n'emporte pas la nullité des contrats en cours. Les obligations réglementaires s'imposent néanmoins aux parties dès la date d'application, que le contrat les ait ou non anticipées. Un contrat silencieux sur l'IA Act reste valide civilement, mais expose chaque partie à devoir assumer seule les obligations légales qui lui reviennent, sans recours contractuel contre l'autre en cas de manquement partagé.
La démarche à engager avant le 2 août 2026 comporte quatre étapes : cartographier les systèmes d'IA intégrés dans chaque contrat en cours (système propre, brique tierce, modèle d'IA à usage général sous-jacent) ; qualifier ces systèmes au regard du règlement (risque inacceptable, haut risque Annexe III, risque limité article 50, risque minimal) ; identifier les obligations qui pèsent sur chaque partie à la lumière des rôles (fournisseur, déployeur) et des clauses existantes ; proposer un avenant ciblé pour combler les clauses manquantes.
Un avenant-type efficace articule cinq stipulations : une clause de qualification des rôles au sens des articles 3 et 25 ; une clause d'information et de documentation conforme à l'article 25 paragraphe 4 ; une clause de coopération et d'audit adaptée aux articles 12, 14 et 26 ; une clause de répartition de la responsabilité intégrant les sanctions de l'article 99 ; une clause de conformité évolutive couvrant l'adoption d'actes délégués, de normes harmonisées et de lignes directrices postérieures à la signature.
Pour les systèmes d'IA à haut risque déjà mis sur le marché avant le 2 août 2026, l'article 111 prévoit un régime transitoire : ils ne sont soumis aux obligations du règlement que s'ils font l'objet de modifications substantielles après cette date. Cette tolérance n'absorbe pas le risque contractuel : toute mise à jour fonctionnelle peut déclencher l'application du régime plein. Une clause encadrant ces modifications et désignant la partie en charge de la mise en conformité constitue un garde-fou utile.
Le donneur d'ordre agissant en qualité de déployeur d'un système haut risque a ses propres obligations définies à l'article 26 : usage conforme aux instructions du fournisseur, supervision humaine compétente, surveillance du fonctionnement, signalement des incidents graves. Elles ne peuvent pas être transférées au sous-traitant, mais des clauses de formation, de documentation et d'assistance continue allègent la charge opérationnelle du déployeur. Ignorer cette répartition conduit à découvrir, au premier audit, que le donneur d'ordre ne dispose pas des instructions d'usage ni de la documentation de supervision pour se défendre en contrôle.
Un exemple concret illustre la démarche. Un cabinet de conseil en fiscalité de la R&D signe en octobre 2025 un abonnement à une plateforme d'agents d'IA assistant la rédaction de rapports techniques transmis à l'administration. Le système n'est pas à haut risque, le contrat est silencieux sur l'IA Act. L'audit identifie quatre actions : qualifier l'éditeur comme fournisseur et le cabinet comme déployeur ; interdire la réutilisation des données chargées pour entraîner les modèles ; rehausser le plafond de responsabilité face au risque d'une sortie défaillante intégrée dans un livrable client ; obtenir l'identification écrite du modèle de langage sous-jacent et des flux de données vers ses propres fournisseurs. L'avenant reste bref mais couvre l'exposition réelle du cabinet, qui combine responsabilité professionnelle vis-à-vis de ses clients et conformité IA Act.
La conformité IA Act ne se confond pas avec la sécurité juridique complète. Un système à risque limité, conforme aux articles 50 et 113, peut produire une référence inventée ou une donnée extrapolée. Le déployeur qui l'intègre dans un document engage sa propre responsabilité, indépendamment de sa conformité au règlement. Le contrat doit donc couvrir simultanément l'exposition réglementaire (IA Act, RGPD) et la fiabilité opérationnelle (garantie de performance, vérification humaine, audit des sorties, plafond aligné sur l'enjeu).
FAQ
À partir de quand faut-il mettre en conformité les contrats de sous-traitance liés à l'IA ? Les obligations applicables aux systèmes d'IA à haut risque et les obligations de transparence entrent pleinement en application le 2 août 2026 (article 113 du règlement 2024/1689). Les contrats doivent donc être alignés sur le règlement avant cette échéance, avec un avenant lorsque le contrat a été signé antérieurement.
Qui est juridiquement fournisseur d'un système d'IA dans un contrat de développement sur mesure ? Le fournisseur est celui qui met le système sur le marché ou le met en service sous son propre nom ou sa propre marque (article 3 § 3). Dans un développement sur mesure, il s'agit généralement du donneur d'ordre qui commercialise la solution finale, même si le code est écrit par le sous-traitant. La qualification peut basculer en cas de modification substantielle ou d'apposition de marque, conformément à l'article 25 § 1.
Un contrat existant sans clause IA Act est-il nul après le 2 août 2026 ? Non. Le contrat reste valide, mais les obligations réglementaires s'imposent aux parties par l'effet direct du règlement. À défaut de clauses adaptées, chaque partie assume seule les obligations qui lui reviennent et perd tout recours contractuel en cas de manquement imputable à l'autre partie.
Quelles pénalités en cas de non-conformité contractuelle à l'IA Act ? L'article 99 prévoit trois niveaux de sanctions administratives : jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires mondial pour les pratiques interdites (article 5), jusqu'à 15 millions d'euros ou 3 % pour les manquements aux autres obligations applicables aux opérateurs, jusqu'à 7,5 millions d'euros ou 1 % pour la transmission d'informations incorrectes aux autorités compétentes.
L'IA Act s'applique-t-il aux systèmes d'IA développés uniquement pour un usage interne ? Oui, dès lors que le système entre dans le champ matériel du règlement. La qualification de fournisseur est déclenchée par la mise sur le marché ou la mise en service, laquelle inclut l'usage interne sous l'autorité de l'entreprise. Un système haut risque utilisé en interne reste soumis aux obligations du règlement, même s'il n'est pas commercialisé à des tiers.
Pour aller plus loin
Les contrats de sous-traitance d'innovation mobilisent également des questions de propriété intellectuelle du logiciel livré et de gouvernance des licences open source, qui interagissent directement avec les obligations de l'IA Act. Pour les systèmes d'IA commercialisés en mode SaaS, la rédaction des CGV SaaS doit aussi être alignée avec le règlement.
Sources :
Règlement (UE) 2024/1689 du Parlement européen et du Conseil du 13 juin 2024
Article 25 — Responsabilités tout au long de la chaîne de valeur de l'IA
Article 50 — Obligations de transparence
Article 113 — Entrée en vigueur et application
