Contrat avec un fournisseur d'IA : les clauses à lire deux fois

Signer un contrat fournisseur IA ressemble beaucoup à signer avec n'importe quel éditeur de logiciel en mode service. Les mêmes documents, le même vocabulaire, la même longueur décourageante. Sauf que trois ou quatre clauses, souvent enfouies au milieu, décident de choses qui n'existaient pas dans un contrat classique : ce que devient votre texte une fois envoyé, quel modèle tourne réellement derrière l'interface, et ce qui se passe le jour où ce modèle disparaît du catalogue.

Un contrat fournisseur IA se lit donc avec une grille un peu particulière. Pas parce que le droit changerait, mais parce que l'objet du contrat est mouvant : vous achetez l'accès à un système qui sera modifié pendant la durée de l'abonnement, sans que vous en décidiez. Les clauses qui comptent sont celles qui encadrent ce mouvement.

Cet article passe en revue les points sur lesquels une relecture attentive change vraiment quelque chose, avec pour chacun le problème qu'ils préviennent. Précision utile : il décrit des principes contractuels, il ne constitue pas un conseil juridique.

Un contrat fournisseur IA, c'est trois documents

Première source de malentendus : ce que vous signez tient rarement dans un seul fichier. Dans la plupart des offres professionnelles, l'ensemble contractuel se compose de trois briques.

• Les conditions générales (parfois appelées conditions d'utilisation professionnelles ou business terms) : l'ossature commerciale, la propriété, la responsabilité, la durée.
• L'accord de traitement des données, ou DPA : le document qui organise le rôle de chacun au sens du règlement européen sur la protection des données, la liste des sous-traitants et les lieux d'hébergement.
• Les engagements de service, ou SLA : disponibilité, support, éventuelles pénalités.

Ces documents sont presque toujours accessibles par lien depuis le contrat principal, et modifiables unilatéralement par le fournisseur. Premier réflexe : vérifier si le contrat renvoie à une page web (« telle qu'accessible à l'adresse suivante ») ou à une version figée annexée. Dans le premier cas, l'engagement que vous croyez avoir obtenu peut évoluer sans votre accord. Demander l'annexion d'une version datée est une négociation raisonnable, y compris chez un gros éditeur.

Les mêmes réflexes valent d'ailleurs pour vos contrats entrants, ceux que vous devez analyser à réception. Nous avons détaillé ce travail dans notre article sur la relecture de contrats assistée par l'IA.

La clause données d'entraînement, celle qu'on lit trop vite

C'est la clause emblématique des conditions d'utilisation IA entreprise. Elle répond à une question simple : ce que vous envoyez au fournisseur (vos prompts, vos documents, les réponses générées) peut-il servir à améliorer ses modèles ?

Sur les offres professionnelles, la réponse par défaut est non. Sur les offres grand public et les paliers gratuits, elle est souvent oui, avec une option de désactivation. Le piège n'est donc pas tant le contenu de la clause données d'entraînement que le décalage entre le contrat signé par la direction et les comptes personnels ouverts par les équipes.

Une clause correctement rédigée précise quatre choses :

1. Que les contenus soumis et générés ne sont pas utilisés pour entraîner, réentraîner ou affiner des modèles, y compris à des fins de recherche interne.
2. La durée de conservation des échanges, et le motif de cette conservation (typiquement, la détection d'abus).
3. Le cas de la revue humaine : qui peut lire vos contenus, dans quelles circonstances, et si vous pouvez la refuser.
4. Le sort de ces données à la fin du contrat.

Le point trois est le plus souvent oublié. Beaucoup d'offres prévoient qu'un échange signalé par les filtres de sécurité soit examiné par un opérateur humain. Ce n'est pas illégitime, mais si vous traitez des données médicales ou des dossiers en contentieux, c'est une information nécessaire à votre analyse d'impact.

Localisation, sous-traitants et transferts

Le DPA vous intéresse pour trois raisons pratiques. D'abord la localisation du traitement : le fournisseur peut proposer une région d'hébergement européenne, mais la restreindre à certaines fonctions, l'inférence par exemple, en laissant la journalisation, l'authentification ou le support ailleurs. La question à poser n'est pas « est-ce hébergé en Europe » mais « quelles opérations sortent de l'Union, et lesquelles ».

Ensuite la liste des sous-traitants ultérieurs. Un fournisseur d'IA repose presque toujours sur un hébergeur tiers, parfois sur un fournisseur de modèle tiers. La clause doit prévoir un préavis avant l'ajout d'un nouveau sous-traitant et un droit d'objection réel, c'est-à-dire assorti d'une porte de sortie si l'objection n'est pas suivie d'effet.

Enfin le mécanisme de transfert hors Union européenne. L'article 28 du règlement européen fixe le socle du contrat entre un responsable de traitement et son sous-traitant : instructions documentées, confidentialité, sécurité, assistance, sort des données en fin de contrat, audits. Un DPA qui n'aborde pas ces points est incomplet, quelle que soit sa longueur.

Sur la partie protection des données proprement dite, notre article sur le RGPD appliqué aux projets d'IA en entreprise détaille la démarche côté conformité.

Le changement de modèle en cours de contrat

Voici le risque le plus spécifique à ce type de contrat, et le moins souvent traité. Vous avez validé un cas d'usage avec un modèle donné, mesuré sa qualité sur un jeu de tests, calibré vos prompts. Six mois plus tard, le fournisseur retire ce modèle ou le remplace par une version dite équivalente. Vos résultats bougent, parfois de dix points sur votre mesure de qualité, sans que personne vous ait prévenu.

Ce qu'on cherche à obtenir dans le contrat :

• Un préavis de dépréciation chiffré : six ou douze mois entre l'annonce de retrait d'une version et son arrêt effectif.
• Le versionnage explicite : la possibilité d'appeler une version figée du modèle, et non un alias qui pointe vers « la dernière version ».
• Une notification écrite des changements de comportement significatifs, y compris ceux qui touchent les filtres de sécurité.

Les fournisseurs sérieux publient déjà des politiques de dépréciation. Le travail consiste à les rattacher au contrat plutôt qu'à les laisser à l'état de documentation. Et côté client, à maintenir un jeu de tests qui détecte la dérive : sans lui, la clause ne sert à rien puisque vous ne saurez pas qu'elle a été violée.

Engagement de service IA : ce que le SLA couvre, et ce qu'il ne couvre pas

Un engagement de service IA ressemble à un SLA classique : un pourcentage de disponibilité mensuel, une méthode de calcul, un avoir en cas de manquement. Trois nuances méritent l'attention.

La latence n'est presque jamais couverte. Un service peut être disponible à 99,9 % et répondre trois fois plus lentement qu'au moment de votre test de charge. Si votre usage est synchrone, demandez un engagement sur un percentile de latence, ou dimensionnez votre architecture pour tolérer la dérive.

Les limites de débit sont un sujet contractuel à part entière. Beaucoup d'offres appliquent des quotas par minute qui ne figurent pas dans le SLA mais dans la documentation. Un pic saisonnier peut donc vous mettre en erreur sans que la disponibilité contractuelle soit entamée.

Enfin, l'avoir en cas d'indisponibilité est un pourcentage de l'abonnement, jamais une indemnisation du préjudice. Sur des dépenses d'API modestes, il est symbolique : c'est un signal, pas une couverture.

Indemnisation, sorties et réversibilité

Trois derniers points, souvent traités à la fin du contrat et lus dans la fatigue.

La propriété des contenus générés. Le contrat doit dire clairement que les sorties vous appartiennent, ou du moins que le fournisseur vous cède tous les droits qu'il pourrait détenir. Attention : cette clause règle la relation avec le fournisseur, pas la question de savoir si une production générée est protégeable en droit d'auteur. Ce sont deux sujets distincts, que nous avons séparés dans notre article sur l'IA et la propriété intellectuelle.

L'indemnisation en cas de réclamation d'un tiers. Plusieurs fournisseurs proposent une garantie couvrant les actions en contrefaçon liées aux contenus générés. Elle est presque toujours conditionnée : usage conforme, filtres activés, notification rapide. Lisez les conditions autant que la promesse, et vérifiez le plafond, souvent indexé sur les sommes payées sur les douze derniers mois.

La réversibilité. Que récupérez-vous en partant ? Vos documents sources, mais aussi les conversations, les jeux d'évaluation, les index vectoriels, les éventuels modèles affinés. Un modèle affiné n'est en général pas exportable, ce qui est acceptable si vous le savez : conservez alors le jeu de données d'affinage de votre côté pour refaire l'opération ailleurs.

Une grille de relecture en dix minutes

Avant de faire intervenir un juriste, un premier passage permet de repérer les contrats à écarter d'emblée. Cherchez ces dix éléments, dans cet ordre :

1. Les annexes sont-elles figées ou renvoyées à une page web modifiable ?
2. L'exclusion d'usage pour l'entraînement est-elle écrite, et s'applique-t-elle aux sorties comme aux entrées ?
3. Quelle est la durée de conservation des échanges, et peut-elle être réduite ?
4. Où se fait l'inférence, où se font la journalisation et le support ?
5. La liste des sous-traitants est-elle publiée et notifiée en cas de changement ?
6. Existe-t-il une politique de dépréciation des modèles, et est-elle contractuelle ?
7. Peut-on appeler une version figée du modèle ?
8. Le SLA couvre-t-il autre chose que la disponibilité brute ?
9. Les sorties sont-elles cédées sans réserve ?
10. Quel format d'export en fin de contrat, et sous quel délai ?

Beaucoup de contrats échouent sur les points 6 et 7. Ce n'est pas rédhibitoire : c'est un risque à documenter et à surveiller avec vos propres tests.

Ce qu'il faut retenir

Un contrat fournisseur IA n'est pas plus dangereux qu'un autre contrat de service. Il est simplement plus instable : l'objet acheté évolue pendant la durée de l'engagement. Les clauses à relire deux fois sont donc celles qui encadrent cette évolution (dépréciation, versionnage, notification) et celles qui déterminent ce que vous confiez sans le vouloir (entraînement, revue humaine, localisation).

La démarche pratique tient en trois gestes : exiger des annexes datées, obtenir un préavis écrit sur les changements de modèle, et garder chez vous ce qui vous permettrait de partir (jeux de tests, données d'affinage, documents sources). Le reste se négocie mieux quand ces trois points sont acquis. Et rappelons-le une dernière fois : ces principes ne remplacent pas l'avis d'un avocat sur votre situation.