Contrat avec un prestataire IA : les 8 clauses à ne pas négliger en PME

Vous allez signer avec une agence ou un freelance pour déployer un agent IA ou automatiser une partie de vos process. Le devis est validé, la solution vous plaît. Sauf qu'un projet IA n'a presque rien à voir avec une presta web classique. Qui possède les prompts une fois le projet livré ? Que récupérez-vous si vous changez de prestataire dans 18 mois ? Qui paie si l'agent envoie une réponse fausse à un client ? Voici les 8 clauses à border avant de signer, regroupées pour rester lisibles côté dirigeant non-juriste.

Pourquoi un contrat IA n'est pas un contrat de presta classique ?

Un contrat de développement web classique livre un produit fini que vous hébergez et qui ne bouge plus. Un projet IA livre un système vivant : il dépend d'API tierces (OpenAI, Anthropic, Mistral), il se nourrit de vos données, et sa qualité dérive si personne ne le maintient. Trois différences structurelles changent tout.

Première différence : les actifs sont immatériels et dispersés. Le cœur de valeur d'un agent IA, ce ne sont pas les lignes de code. Ce sont les prompts affinés sur des dizaines d'itérations, la base de connaissances métier, parfois un modèle fine-tuné sur vos données. Ces actifs sont souvent éparpillés entre le compte du prestataire, une instance N8N et des plateformes LLM. Si le contrat ne dit rien, vous ne possédez rien de tangible le jour où ça se passe mal.

Deuxième différence : la dépendance externe est permanente. Votre agent appelle l'API d'un fournisseur LLM à chaque message. Si ce fournisseur change ses tarifs, déprécie un modèle ou modifie ses conditions, votre run mensuel et la qualité de service bougent sans que ni vous ni le prestataire ne décidiez quoi que ce soit.

Troisième différence : l'erreur est probabiliste. Un logiciel classique fait toujours la même chose. Un modèle de langage peut halluciner, sortir une information fausse, mal interpréter une demande. La question de qui assume une erreur de l'IA n'existe pas dans une presta web. Elle est centrale ici.

Conséquence pratique : un contrat IA bien fait protège vos actifs, votre continuité et votre responsabilité. Un mauvais contrat vous enferme. Pour décider en amont quel type d'interlocuteur engager, lisez d'abord notre comparatif agence IA vs freelance vs interne en PME, parce que le niveau de risque contractuel n'est pas le même selon le profil.

Qui possède le code, les prompts et les données ?

C'est la clause la plus négligée et la plus coûteuse. La propriété intellectuelle (PI) doit être traitée poste par poste, pas en une phrase générique du type "le client est propriétaire des livrables".

Quatre actifs distincts doivent être nommés explicitement dans le contrat :

• Le code et les workflows : scripts, automatisations N8N, connecteurs API. Exigez une cession de droits patrimoniaux à la livraison, pas une simple licence d'usage.
• Les prompts : c'est le piège classique. Beaucoup de prestataires considèrent leurs prompts comme leur savoir-faire propriétaire et ne les cèdent pas. Résultat : vous récupérez une coquille vide. Demandez la propriété ou, a minima, une licence perpétuelle, irrévocable et transférable sur tous les prompts utilisés en production.
• Les modèles fine-tunés et embeddings : si un modèle a été entraîné sur vos données, le modèle résultant et les fichiers d'entraînement doivent vous revenir. Sans clause, le prestataire peut réutiliser un modèle nourri par vos données chez un concurrent.
• Les données : vos données métier restent vôtres, ce qui paraît évident mais doit être écrit. Précisez aussi que le prestataire ne peut pas les utiliser pour entraîner d'autres systèmes, sauf accord écrit.

Astuce de négociation : conditionnez le dernier paiement (10 à 20% du setup) à la remise effective de tous ces actifs, sous format exploitable et documenté. Tant que le prestataire n'a pas livré les prompts et la doc, vous ne soldez pas.

Comment sécuriser la réversibilité, le SLA et la maintenance ?

Trois clauses opérationnelles décident si vous restez libre ou prisonnier.

La réversibilité (clause d'exit). C'est votre assurance anti-lock-in. Elle doit garantir qu'à la fin du contrat, pour quelque raison que ce soit, vous récupérez l'intégralité de votre système en état de marche : export des workflows N8N, transfert de propriété des comptes API (ou la procédure pour les recréer à votre nom), bases de connaissances, prompts, documentation technique. Exigez un délai plafonné, par exemple 15 jours ouvrés, et précisez le format de remise. Sans clause de réversibilité, certains prestataires hébergent tout sur leurs propres comptes et vous tenez par les comptes le jour où vous voulez partir.

Le SLA (niveau de service). Définit ce que "ça marche" veut dire contractuellement : disponibilité visée (par exemple 99,5% hors maintenance planifiée), délai de prise en compte d'un incident bloquant, délai de résolution cible. Distinguez clairement les niveaux de gravité. Un agent qui ne répond plus n'a pas le même délai qu'une amélioration cosmétique.

La maintenance et les évolutions. Précisez qui maintient, ce qui est inclus dans le run mensuel et ce qui est facturé en sus. Point spécifique IA : les mises à jour de modèles. Quand un fournisseur LLM déprécie un modèle ou en sort un meilleur, qui gère la migration, sous quel délai, à quel coût ? Le détail de ce qui rentre dans un contrat de run sain est développé dans notre guide sur la maintenance d'un agent IA en production.

Quelles clauses sur la confidentialité, le RGPD et la responsabilité ?

Trois clauses qui protègent contre les risques juridiques et financiers.

Confidentialité et RGPD. Dès que votre agent traite des données personnelles (messages clients, fiches prospects, emails), le prestataire devient sous-traitant au sens RGPD. Le contrat doit s'accompagner d'un DPA (accord de traitement de données) conforme à l'article 28 du RGPD. Vérifiez où les données sont hébergées, par quels sous-traitants elles transitent (votre prestataire utilise lui-même des API tierces), et surtout les transferts hors UE. Un appel à une API américaine est un transfert. Il doit reposer sur une base légale valable (clauses contractuelles types, garanties d'adéquation). Notre article sur le RGPD et l'IA générative côté CNIL détaille les points que la CNIL regarde en priorité.

Responsabilité et gestion des erreurs. Un modèle de langage peut halluciner. Le contrat doit dire qui assume si l'agent donne une réponse fausse, prend un engagement à votre place ou commet une erreur de traitement. Personne de sérieux ne garantira "zéro hallucination". Ce qui se négocie, c'est l'obligation de moyens : garde-fous techniques (validation humaine sur les actions sensibles, fact-checking, limites d'action de l'agent), procédure d'alerte, et un plafond de responsabilité. Refusez une exonération totale du prestataire, c'est un signal d'amateurisme.

Articulation avec l'AI Act. Selon l'usage, votre système peut tomber sous des obligations de transparence ou de supervision humaine. Le contrat doit répartir clairement qui fait quoi entre fournisseur et déployeur. Notre checklist de conformité AI Act pour PME précise cette répartition des rôles, parce qu'en tant que déployeur vous gardez des obligations même avec un bon prestataire.

Comment cadrer le prix, le run et la dépendance aux LLM ?

Deux dernières clauses, économiques cette fois.

Prix, run mensuel et révision. Séparez nettement le setup (one-shot) du run mensuel récurrent. Pour le run, exigez le détail de ce qu'il couvre : maintenance, supervision, support, coûts d'API refacturés. Encadrez surtout les conditions de révision tarifaire : un prestataire qui peut augmenter son run sans cadre vous tient. Demandez un préavis de révision (90 jours par exemple), un plafond annuel d'augmentation, et la possibilité de résilier si la hausse dépasse ce plafond. Pour comprendre comment un run sain se construit côté agence, voir notre méthode pour chiffrer une proposition d'automatisation IA.

Dépendance aux fournisseurs LLM. Votre agent dépend d'une API que ni vous ni le prestataire ne contrôlez. Trois scénarios à anticiper dans le contrat. Si le fournisseur augmente ses prix, qui absorbe la hausse et dans quelle proportion ? Si un modèle est déprécié, qui gère la migration et sous quel délai ? Si l'API change ses conditions d'usage, qui assure la mise en conformité ? Une clause de portabilité multi-fournisseurs est un vrai atout : un système conçu pour basculer d'un LLM à un autre vous protège bien mieux qu'une architecture verrouillée sur un seul.

Sur les contrats importants (engagement pluriannuel, run élevé, données sensibles), faites relire ces clauses par un avocat. Ce guide vous donne les bons réflexes de négociation, pas un avis juridique sur votre situation précise.