Contrat avec un fournisseur d'IA : les clauses à vérifier avant de signer (RGPD, entraînement, réversibilité)

Le contrat avec un fournisseur d'IA est l'ensemble des documents qui fixent ce que ce fournisseur a le droit de faire des informations que vous lui confiez : les conditions de service, l'accord de traitement des données (souvent appelé DPA, pour data processing agreement), la liste des sous-traitants, l'annexe de sécurité et les conditions de sortie. C'est lui, et non la page commerciale de l'outil, qui dit si vos données servent à entraîner un modèle, où elles sont hébergées, combien de temps elles sont conservées et ce que vous récupérez le jour où vous partez.

Pour une organisation qui manipule des informations sensibles, la question n'est donc pas seulement « cet outil est-il bon ? », mais « ce que je signe me permet-il de l'utiliser avec mes vraies données ? ». Ce guide explique comment qualifier le rôle du fournisseur au regard du RGPD, quelles mentions de l'article 28 sont obligatoires, quelles clauses propres à l'IA vérifier en plus (entraînement, historiques, modèles tiers, transferts, réversibilité), puis propose une grille de vérification et une méthode en six étapes. Il fait partie de notre série sur le deuxième cerveau, l'IA agentique et l'IA en environnement réglementé. Il ne remplace pas l'avis d'un juriste sur un contrat donné.

Contrat fournisseur d'IA : de quels documents parle-t-on, et qui est responsable ?

Définition courte : le « contrat » d'un service d'IA est rarement un document unique. Pour une offre en ligne, il s'agit d'un empilement de textes, souvent accessibles par des liens, qui se complètent et parfois se contredisent. Les identifier tous est la première étape de la lecture.

Avant même de lire les clauses, il faut savoir qui est responsable de quoi. Au sens du RGPD, l'organisation qui décide d'utiliser l'IA pour ses propres finalités (préparer un rendez-vous, rédiger un compte rendu, rechercher dans ses dossiers) est en principe responsable du traitement. Le fournisseur qui traite les données pour son compte et selon ses instructions est sous-traitant. Dans ses questions-réponses sur l'utilisation d'un système d'IA générative (18 juillet 2024), la CNIL invite l'organisation qui déploie un tel système à s'interroger sur son rôle et sur celui du fournisseur, ce qui peut conduire à conclure un contrat de sous-traitance ou un accord de responsabilité conjointe.

La qualification n'est pas automatique. Dans sa fiche consacrée à la qualification juridique des fournisseurs de systèmes d'IA, la CNIL rappelle qu'un prestataire qui constitue de sa propre initiative un jeu de données et l'exploite pour l'ensemble de ses clients sera vraisemblablement responsable de ce traitement-là. Autrement dit, un fournisseur qui réutilise les données de ses clients pour améliorer son modèle n'agit plus, pour cette réutilisation, comme un simple sous-traitant : il poursuit sa propre finalité, qui doit avoir sa propre base légale, et vous devez pouvoir en informer vos clients. C'est le fil rouge de tout ce qui suit.

Pourquoi un contrat d'IA ne se lit pas comme un contrat SaaS classique

Un logiciel en ligne classique stocke vos données et vous les rend. Un service d'IA fait davantage : il les lit, les combine, les reformule, et peut en garder une trace à plusieurs endroits. Les questions contractuelles se multiplient d'autant.

Analyse : la plupart des risques d'un projet d'IA en profession réglementée ne viennent pas d'une clause abusive, mais d'une clause absente. Un contrat qui ne dit rien de la conservation des historiques ou du recours à un modèle tiers ne vous protège pas sur ces points. Le travail de lecture consiste donc autant à repérer les silences qu'à lire ce qui est écrit. C'est aussi pourquoi cette vérification gagne à être faite avant de relier des sources, comme le recommande notre guide sur la cartographie des sources avant un projet d'IA.

Le socle obligatoire : les mentions de l'article 28 du RGPD

Dès lors que le fournisseur traite des données personnelles pour votre compte, l'article 28 du RGPD impose un contrat écrit. Il vous oblige d'abord à ne choisir qu'un sous-traitant présentant des garanties suffisantes (art. 28, § 1), puis fixe un contenu minimal (art. 28, § 3). Le contrat doit notamment prévoir que le sous-traitant :

1. ne traite les données que sur instruction documentée du responsable de traitement, y compris pour les transferts hors de l'Union ;
2. veille à ce que les personnes autorisées à traiter les données soient tenues à la confidentialité ;
3. prend les mesures de sécurité requises par l'article 32 ;
4. ne recrute un sous-traitant ultérieur qu'avec votre autorisation écrite préalable, spécifique ou générale, en vous informant de tout changement pour que vous puissiez vous y opposer (art. 28, § 2 et § 4) ;
5. vous aide à répondre aux demandes d'exercice des droits des personnes ;
6. vous aide à respecter vos obligations de sécurité, de notification des violations et, le cas échéant, d'analyse d'impact (art. 32 à 36) ;
7. au terme du service, supprime ou restitue toutes les données, selon votre choix, et en détruit les copies ;
8. met à votre disposition les informations nécessaires pour démontrer le respect de ses obligations et permet des audits.

Ces mentions ne sont pas propres à l'IA ; elles valent pour tout prestataire, comme nous l'avons détaillé pour le CRM conforme au RGPD. Pour gagner du temps, la Commission européenne a publié des clauses contractuelles types entre responsable et sous-traitant (décision d'exécution (UE) 2021/915 du 4 juin 2021). Leur usage n'est pas obligatoire, mais un DPA qui s'en écarte beaucoup mérite une lecture plus attentive.

Deux points demandent une vigilance particulière avec l'IA. Le premier est l'instruction documentée : si le contrat autorise le fournisseur à traiter vos données « pour fournir et améliorer ses services », la seconde partie de la phrase sort du cadre de vos instructions. Le second est la chaîne des sous-traitants : dans son avis 22/2024 du 7 octobre 2024, le Comité européen de la protection des données (CEPD) indique que le responsable de traitement doit disposer à tout moment de l'identité de tous les sous-traitants de la chaîne, y compris ceux de second rang. Pour un service d'IA, cela inclut souvent l'éditeur du modèle de langage appelé en arrière-plan.

Comparer ce que vous lisez à des engagements écrits

Pour appliquer la grille de cet article, partez d'un cas concret. La page sécurité de Brain détaille ses engagements : hébergement en Union européenne chez Scaleway à Paris, chiffrement AES-256 au repos et en transit, données qui n'entraînent aucun modèle public, droits d'accès par collaborateur et par périmètre, et un engagement contractuel comprenant un accord de traitement des données et un registre des traitements partagé. Confrontez chaque point aux questions des sections suivantes.

Lire les engagements de sécurité Voir la méthode Brain

Hébergement UE • Accord de traitement des données • Aucun entraînement de modèle public

Les clauses propres à l'IA (1/2) : entraînement, historiques, modèles tiers, transferts

Au-delà du socle de l'article 28, quatre sujets concentrent l'essentiel des écarts entre les offres. Ils se vérifient offre par offre, et parfois paramètre par paramètre, car les conditions évoluent.

1. Réutilisation des données pour l'entraînement ou l'« amélioration des services »

C'est la première question à poser. Les formulations varient : « entraînement », « amélioration des modèles », « développement de nouveaux services », « analyse des retours ». Le contrat doit dire clairement si vos requêtes, vos documents et les réponses produites peuvent être utilisés au-delà de la fourniture du service, et si oui, avec quel mécanisme de refus. La CNIL recommande, lorsqu'un service public en ligne réutilise les données, de mener une analyse au cas par cas pour décider s'il faut interdire d'y fournir des données personnelles ; elle relève que cette restriction n'est pas nécessaire lorsqu'un déploiement sur site rend toute réutilisation impossible (CNIL, 18 juillet 2024).

Vérifiez aussi les exceptions : les retours volontaires des utilisateurs (noter une réponse), les échanges avec le support, ou la revue humaine d'une partie des conversations sont parfois traités à part. Une exclusion de principe peut être assortie de ces réserves.

2. Conservation des requêtes, des réponses et des historiques

Ne pas entraîner un modèle ne veut pas dire ne rien conserver. Le contrat ou la politique de données doit préciser, pour chaque catégorie, la durée de conservation : historiques de conversation, mémoires d'assistant, index construits à partir de vos documents, journaux techniques, et toute conservation temporaire prévue, par exemple, pour la détection des abus. Demandez qui peut y accéder chez le fournisseur et si l'effacement d'un document entraîne celui de ses copies dans les index. Ces données d'usage sont elles-mêmes sensibles : une requête du type « préparer la succession de M. X » en dit autant qu'un dossier.

3. Le modèle d'un éditeur tiers

Beaucoup d'applications d'IA ne développent pas leur propre modèle : elles appellent celui d'un autre éditeur. Le contrat doit alors indiquer quels modèles sont utilisés, dans quelle région ils s'exécutent, et quelles garanties le fournisseur a lui-même obtenues de cet éditeur (absence d'entraînement, conservation, localisation). Les engagements que vous lisez ne valent que si la chaîne entière les respecte : c'est le sens de l'avis 22/2024 du CEPD cité plus haut.

4. Localisation, accès depuis l'étranger et transferts

Un hébergement en Europe ne règle pas tout. Il faut distinguer la localisation du stockage, celle des traitements (le modèle peut s'exécuter ailleurs), et les accès à distance (support, maintenance) depuis un pays tiers, qui constituent aussi des transferts au sens du chapitre V du RGPD. Pour les États-Unis, la décision d'adéquation du 10 juillet 2023 (décision d'exécution (UE) 2023/1795, dite Data Privacy Framework) couvre les entreprises certifiées ; le recours en annulation formé contre elle a été rejeté par le Tribunal de l'Union européenne le 3 septembre 2025 (affaire T-553/23, Latombe c. Commission). Pour les autres cas, des garanties appropriées sont nécessaires, le plus souvent les clauses contractuelles types de transfert.

Fait / analyse : la conformité d'un transfert au RGPD et l'exposition d'un fournisseur à des lois extra-européennes sont deux questions distinctes. Une organisation qui veut traiter ce second risque peut s'appuyer sur des critères plus exigeants, comme ceux du référentiel SecNumCloud de l'ANSSI, ou privilégier un hébergement et un éditeur européens. Ce choix relève de votre analyse de risque, pas d'une obligation générale.

Les clauses propres à l'IA (2/2) : confidentialité, sorties, évolution du service, réversibilité

5. Confidentialité au-delà des données personnelles

Le RGPD ne protège que les données personnelles. Or une organisation confie aussi à l'IA des informations qui n'en sont pas : stratégie, tarifs, données sur des sociétés, contenu de procédures internes. Pour une profession tenue au secret ou à une obligation contractuelle de confidentialité envers ses clients, il faut une clause de confidentialité couvrant toutes les informations transmises, avec les mêmes limites d'usage que pour les données personnelles. Notre article sur l'IA et le secret professionnel détaille ces trois obligations distinctes.

6. Sécurité et notification des violations

Le sous-traitant doit vous notifier une violation de données « dans les meilleurs délais » après en avoir pris connaissance (art. 33, § 2 RGPD), et vous disposez vous-même de 72 heures pour notifier la CNIL lorsque la violation présente un risque. Un contrat qui fixe un délai précis de notification et le contenu de l'information transmise vous laisse le temps d'agir. Vérifiez aussi les mesures propres aux usages d'IA : cloisonnement entre clients, contrôle d'accès, journalisation, et protections contre l'injection de prompt si l'outil lit des courriels ou documents entrants.

7. Propriété des sorties et responsabilité

Le contrat doit préciser à qui appartiennent les contenus produits (synthèses, comptes rendus, courriers) et si vous pouvez les utiliser librement. Il comporte presque toujours une limitation de responsabilité et une absence de garantie sur l'exactitude des réponses. Ce n'est pas anormal, mais cela confirme que la validation humaine reste à votre charge : le contrat ne transférera pas au fournisseur la responsabilité d'un conseil.

8. Évolution du service et changement de modèle

Les conditions d'un service d'IA changent plus souvent que celles d'un logiciel classique, et le modèle sous-jacent peut être remplacé. Cherchez une clause qui prévoit une information préalable des modifications substantielles (nouvelle finalité, nouveau sous-traitant, changement de localisation) et un droit de résilier sans pénalité si elles ne vous conviennent pas. Une clause du type « nous pouvons modifier ces conditions à tout moment » sans préavis est un signal d'alerte.

9. Réversibilité : export, délais, effacement

La réversibilité est la capacité à quitter un fournisseur en récupérant ses données dans un format exploitable. Pour les services de traitement de données, dont les logiciels en ligne, le règlement (UE) 2023/2854 sur les données (Data Act), applicable depuis le 12 septembre 2025, encadre désormais le changement de fournisseur. Son article 25 impose notamment que le contrat prévoie :

• un préavis maximal de deux mois pour engager le changement ;
• une période transitoire de trente jours au plus pour mener la migration (prolongeable jusqu'à sept mois si le fournisseur démontre une impossibilité technique) ;
• une période d'au moins trente jours pour récupérer les données après la période transitoire, puis leur effacement ;
• une description des données et actifs numériques exportables.

L'article 29 prévoit en outre la suppression des frais de changement à compter du 12 janvier 2027. Ces règles ne disent pas tout : elles ne garantissent pas que l'export contienne vos historiques ou vos synthèses dans un format réutilisable par un autre outil. La meilleure protection reste une architecture où la mémoire ne dépend pas du fournisseur du modèle, comme nous l'avons exposé dans notre guide pour intégrer l'IA à ses outils existants ou changer de logiciel.

Grille de vérification : douze questions à poser à un fournisseur d'IA

La grille ci-dessous se remplit avec les documents du fournisseur sous les yeux. Une réponse orale ou un argument commercial ne compte pas : chaque ligne doit renvoyer à un article ou à une page précise.

Les entités financières soumises au règlement DORA ((UE) 2022/2554) disposent en outre, à son article 30, d'une liste de clauses obligatoires pour leurs prestataires de services informatiques. La plupart des petits cabinets de conseil n'y sont pas soumis directement, mais cette liste reste une bonne source d'inspiration pour compléter la grille (niveaux de service, coopération avec l'autorité, stratégie de sortie).

Méthode en six étapes, et le cas d'un cabinet patrimonial

1. Partir de l'usage. Décrivez la tâche visée (préparer un rendez-vous, rédiger un compte rendu, rechercher dans les dossiers) et les catégories de données qu'elle implique. La sensibilité de l'usage détermine le niveau d'exigence contractuelle, comme dans une charte d'usage de l'IA.
2. Rassembler tous les documents. Conditions, DPA, liste des sous-traitants, politique de conservation, annexe de sécurité, conditions de sortie, dans leur version datée.
3. Qualifier les rôles. Qui est responsable de traitement, qui est sous-traitant, et y a-t-il une réutilisation par le fournisseur pour son propre compte ?
4. Remplir la grille. Une ligne par question, une référence par réponse, et les silences notés comme tels.
5. Négocier ou compenser. Demandez un avenant pour les points bloquants ; à défaut, limitez l'usage (pas de données clients nominatives) ou écartez l'offre.
6. Documenter et revoir. Inscrivez le traitement au registre, conservez la version des documents signée et prévoyez une revue à chaque changement notifié, et au moins une fois par an.

Illustration (cabinet fictif). Prenons un cabinet de conseil en gestion de patrimoine de quatre personnes qui veut utiliser l'IA pour préparer ses rendez-vous à partir des courriels, des comptes rendus et des documents clients. La lecture de l'offre qu'un collaborateur utilisait déjà révèle trois points : un compte individuel relevant des conditions grand public, une clause d'amélioration des services activée par défaut, et aucune information sur l'export des historiques. L'usage avec des données clients est suspendu, ce qui rejoint la démarche décrite dans notre guide sur l'IA fantôme.

Le cabinet compare alors deux voies : une offre professionnelle du même éditeur, avec un DPA, ou une couche de mémoire qui se branche sur ses outils existants et dont le moteur d'IA est interchangeable. C'est l'approche de Majors Brain : selon sa page sécurité, les données sont hébergées en Union européenne, les données sensibles sont pseudonymisées et ne sortent pas en clair, elles n'entraînent aucun modèle public, et une copie de la mémoire est synchronisée vers une cible définie lors de l'audit. Le moteur d'IA peut être changé si le fournisseur actuel fait défaut. Pour la ligne 12 de la grille, ce point change la nature de la question : la mémoire du cabinet ne dépend plus du fournisseur du modèle. Dans les deux cas, le cabinet remplit la même grille et conserve les documents au dossier.

Plus largement, un contrat bien lu est la condition pour passer d'usages isolés à un deuxième cerveau d'entreprise relié aux vraies sources, puis, plus tard, à des agents IA qui agissent sur ces données. Plus l'IA accède à des sources et agit, plus ce qui est écrit dans le contrat compte.