Contrat de développement d'un agent IA : les clauses à négocier

Un agent IA ne se contente pas de répondre : il lit une boîte mail, crée un ticket, rembourse un client, modifie une fiche dans l'ERP. Quand il se trompe, l'erreur est déjà exécutée. Le contrat qui encadre son développement doit donc régler des questions qu'un contrat de développement classique ignore : jusqu'où l'agent peut agir, comment recetter un système qui ne répond jamais deux fois de la même manière, qui répond du modèle tiers sur lequel il repose, et qui supporte la facture d'une action erronée. Voici les clauses à négocier, lues côté client et côté prestataire.

Pourquoi un agent IA n'est pas un logiciel comme les autres

Un logiciel classique exécute des règles écrites par ses développeurs. Pour une même entrée, il produit la même sortie, et un défaut se reproduit, se corrige et se teste. Un agent IA repose sur un grand modèle de langage qui déduit, à partir de ses entrées, l'action à mener. C'est exactement la définition du système d'IA de l'article 3, 1), du règlement (UE) 2024/1689 : un système automatisé conçu pour fonctionner à différents niveaux d'autonomie, qui déduit de ses entrées comment générer des sorties pouvant influencer un environnement physique ou virtuel.

Trois différences changent l'économie du contrat.

• L'agent agit. Il dispose d'outils : accès à une API de paiement, droit d'écriture dans le CRM, envoi de courriels au nom de l'entreprise. Le dommage naît d'une opération réalisée, pas d'un affichage erroné.
• Il n'est pas déterministe. Deux requêtes identiques peuvent produire deux réponses différentes.
• Il dépend d'un tiers. Le modèle sous-jacent appartient le plus souvent à un fournisseur extérieur, qui modifie ses versions, ses prix et ses conditions sans demander l'avis du prestataire ni du client.

Le contentieux a commencé par les assistants conversationnels. Le 14 février 2024, le Civil Resolution Tribunal de Colombie-Britannique (Moffatt v. Air Canada, 2024 BCCRT 149) a écarté l'argument d'une compagnie aérienne qui soutenait ne pas répondre des réponses de son chatbot, lequel avait promis à tort un tarif réduit rétroactif. La décision est canadienne, rendue en matière de petites créances, et ne fait pas jurisprudence en France. Mais elle dit l'essentiel : pour le client final, l'agent parle et agit au nom de l'entreprise qui l'a déployé. Le contrat de développement doit organiser la manière dont ce risque se répartit en amont.

Les règles générales sont détaillées dans notre article sur les garanties et responsabilités d'un contrat de développement logiciel. Ce qui suit porte sur ce que l'agent ajoute.

Qualification AI Act : fournisseur, déployeur et modification substantielle

Avant de négocier une clause, il faut savoir qui porte quelle obligation réglementaire. Le contrat ne peut pas déplacer une qualification que le règlement attache à des faits, mais il peut organiser la coopération entre les parties.

Le client qui fait développer est souvent le fournisseur

L'article 3, 3), désigne comme fournisseur celui qui « développe ou fait développer » un système d'IA et le met en service sous son propre nom ou sa propre marque. L'ESN qui code un agent sur commande, livré au client et exploité sous la marque de ce dernier, n'est donc pas forcément le fournisseur au sens du règlement. Le client qui fait développer puis met en service peut l'être. Il est aussi déployeur (article 3, 4) s'il utilise l'agent sous sa propre autorité.

Ce que la qualification change selon le niveau de risque

La plupart des agents d'entreprise (support client, qualification de demandes, rédaction de devis) ne relèvent pas du haut risque. Leurs obligations principales sont alors la transparence de l'article 50, applicable depuis le 2 août 2026 : informer les personnes qu'elles interagissent avec une IA, marquer les contenus de synthèse. Le manquement est passible, selon l'article 99, paragraphe 4, d'une amende pouvant atteindre 15 000 000 € ou 3 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. S'y ajoute l'article 4, réécrit par le règlement (UE) 2026/1744 : fournisseurs et déployeurs prennent des mesures pour favoriser la maîtrise de l'IA de leur personnel.

Un agent qui trie des candidatures, évalue des salariés ou apprécie la solvabilité d'un client entre dans l'annexe III. Les obligations du chapitre III s'appliqueront alors à partir du 2 décembre 2027, date fixée par l'article 113 modifié par l'omnibus numérique. Le simulateur de niveau de risque AI Act donne une première indication.

Le piège de la destination modifiée

L'article 25, paragraphe 1, prévoit qu'un déployeur ou tout autre tiers devient fournisseur d'un système à haut risque s'il y apporte une modification substantielle (définie à l'article 3, 23) ou s'il modifie la destination d'un système qui n'était pas à haut risque de manière qu'il le devienne. Un agent livré pour répondre aux questions des candidats, que le client branche ensuite sur le tri des CV, change de catégorie. Le contrat doit donc décrire la destination de l'agent, interdire son extension sans avenant et prévoir qui supporte les obligations si le client passe outre.

Point de vigilance. L'omnibus numérique a réécrit l'article 25, paragraphe 4 : l'accord écrit entre le fournisseur d'un système à haut risque et ses fournisseurs de composants vise désormais expressément « un modèle d'IA ». Le manquement à cette obligation entre dans le barème de l'article 99, paragraphe 4 (point d bis). Pour un agent à haut risque, le contrat avec le prestataire et avec le fournisseur de modèle n'est plus une simple précaution commerciale.

Spécifications et périmètre d'action de l'agent

La clause la plus importante d'un contrat d'agent n'existe pas dans un contrat de développement classique : la liste de ce que l'agent a le droit de faire.

Lister les outils et les droits

Le cahier des charges doit énumérer les outils connectés (API, bases, messagerie), le niveau de droit sur chacun (lecture, création, modification, suppression) et les opérations interdites. Un agent de support qui lit l'historique de commande n'a pas besoin de supprimer un compte client. Le moindre privilège devient une obligation du prestataire : il livre un agent limité aux droits listés, et il le démontre.

Plafonds, validations humaines et coupe-circuit

Prenons un scénario type : un e-commerçant commande un agent de service client autorisé à rembourser. Le contrat fixe un plafond par opération (par exemple 150 €), un plafond journalier cumulé (par exemple 3 000 €), et une validation humaine obligatoire au-delà. Il impose un coupe-circuit : la possibilité pour le client de suspendre l'agent en un geste, sans intervention du prestataire. Ces chiffres sont des hypothèses : l'essentiel est qu'ils figurent au contrat et que la recette vérifie qu'ils tiennent.

Le comportement attendu face à l'incertitude

Un bon cahier des charges décrit aussi ce que l'agent fait quand il ne sait pas : il transmet à un humain, il refuse, il demande une précision. Pour le prestataire, c'est une protection : un agent qui escalade conformément aux spécifications n'est pas défaillant.

Recette d'un système non déterministe

La recette d'un logiciel classique repose sur des cas de test : telle entrée, tel résultat attendu. Appliquée à un agent, cette méthode échoue. Un test passé lundi peut échouer mardi sans que personne n'ait touché au code, parce que le modèle a été mis à jour ou parce que la génération varie.

Recetter sur un jeu d'évaluation et des seuils

Le contrat doit remplacer le résultat attendu par une mesure statistique. Les parties constituent ensemble un jeu d'évaluation représentatif (par exemple 500 demandes réelles anonymisées), définissent ce qu'est une réponse correcte, une réponse acceptable et une faute grave, puis fixent un seuil de réussite et un seuil de tolérance zéro. Une seule action interdite exécutée, un remboursement au-delà du plafond, une donnée d'un client communiquée à un autre, fait échouer la recette quel que soit le score global.

Prononcer la recette sans signer à l'aveugle

Les juges ne s'arrêtent pas toujours à l'intitulé du document signé. Dans un arrêt du 22 février 2017 (Cass. com., n° 15-12.253), la Cour de cassation a rejeté le pourvoi d'un prestataire qui se prévalait d'un « procès-verbal de recette » portant « acceptation sans réserve » : les juges du fond avaient souverainement retenu que ce document validait seulement des étapes d'un processus restant à parfaire, et que les « enrichissements » facturés à part relevaient en réalité du forfait. Pour un agent, la leçon vaut dans les deux sens. Le client doit pouvoir émettre des réserves sur un comportement observé en production. Le prestataire a intérêt à un procès-verbal précis, qui liste le jeu d'évaluation, les scores obtenus et la version du modèle utilisée.

Prévoyez enfin une période sous surveillance après la mise en production, puis une nouvelle évaluation sur le même jeu à chaque changement de version du modèle.

Modèle sous-jacent, API et dépendances

L'agent fonctionne grâce à un modèle que ni le prestataire ni le client ne maîtrisent. C'est le point le plus souvent absent des contrats.

Qui signe avec le fournisseur de modèle

Deux schémas coexistent. Soit le prestataire revend l'accès au modèle et en refacture la consommation : il porte alors le risque des conditions qu'il a acceptées et doit les répercuter. Soit le client souscrit directement l'abonnement et le prestataire ne fait qu'intégrer : le client doit alors lire lui-même les conditions du fournisseur de modèle, souvent non négociables. Dans ce second cas, l'article 1171 du Code civil sur le déséquilibre significatif dans les contrats d'adhésion peut être invoqué, mais la loi applicable choisie par ces conditions est rarement la loi française.

Changements de version, de prix et d'interdits

Le contrat doit prévoir ce qui se passe quand le fournisseur retire une version du modèle, augmente ses tarifs ou interdit un usage. Trois clauses s'imposent : une obligation de veille et d'alerte du prestataire, une procédure de migration vers une autre version avec recette de non-régression, et une répartition du surcoût (au-delà d'un seuil de hausse, renégociation ou sortie sans pénalité).

Le coût d'une dépendance mal anticipée

L'arrêt du 22 février 2017 cité plus haut l'illustre hors IA. La licence accordée au client sur un moteur de recherche ne lui permettait pas de faire fonctionner le logiciel, conçu pour reposer sur d'autres dispositifs appartenant au prestataire. Les juges du fond ont évalué le préjudice à la valeur de remplacement du logiciel, soit 516 000 €, et la Cour de cassation a rejeté le pourvoi. Un agent construit sur des briques propriétaires du prestataire (orchestrateur, bibliothèque d'outils, base vectorielle hébergée) expose le client au même risque. Le contrat doit lister ces dépendances et garantir leur disponibilité ou leur remplacement.

Propriété intellectuelle : code, prompts, données et résultats

Un agent se compose de plusieurs couches qui n'ont pas le même statut juridique. Le contrat doit les traiter une par une.

Le code et la configuration

Le code de l'agent est un logiciel, protégé par le droit d'auteur (CPI, article L112-2, 13°). La dévolution automatique de l'article L113-9 ne joue qu'au profit de l'employeur pour les logiciels créés par ses salariés. Face à un prestataire extérieur, le client n'est titulaire de rien sans cession écrite, et cette cession doit respecter l'article L131-3 : mention distincte de chaque droit cédé, domaine d'exploitation délimité quant à son étendue, sa destination, son lieu et sa durée. Une clause « le client devient propriétaire de tous les développements futurs » se heurte en outre à la nullité de la cession globale des œuvres futures (article L131-1).

Les prompts système et les chaînes d'outils

Les instructions qui définissent le comportement de l'agent sont souvent sa vraie valeur. Leur protection par le droit d'auteur reste incertaine : tout dépend de leur originalité. Mieux vaut ne pas s'en remettre à la qualification. Le contrat doit les nommer comme livrables, préciser qui peut les réutiliser, et les couvrir par une clause de confidentialité et de savoir-faire. Côté prestataire, c'est l'endroit où réserver ses composants génériques réutilisables, en concédant au client une licence d'usage plutôt qu'une cession.

Les données d'évaluation et les résultats générés

Le jeu d'évaluation construit avec les données du client lui appartient et doit lui revenir en fin de contrat. Quant aux contenus produits par l'agent, leur protection par le droit d'auteur est discutée, faute d'auteur humain identifiable : la question est développée dans notre article sur la titularité des droits sur une œuvre générée par une IA. Le contrat doit au minimum garantir que le prestataire ne revendique aucun droit sur ces sorties et ne les réutilise pas.

La correction des erreurs

Par défaut, l'utilisateur légitime d'un logiciel peut en corriger les erreurs sans l'autorisation de l'auteur. Mais l'article L122-6-1 du CPI permet à l'auteur de se réserver ce droit par contrat. Pour tout composant dont le prestataire reste titulaire, le client doit donc vérifier que le contrat ne contient pas cette réserve s'il veut faire corriger l'agent par un tiers, ou le corriger lui-même. Sinon, chaque correction passe par le prestataire initial.

Données personnelles et confidentialité

Un agent qui traite des demandes de clients, de salariés ou de candidats manipule des données personnelles. Le prestataire qui l'héberge ou l'exploite pour le compte du client est en principe sous-traitant au sens du RGPD, ce qui impose un contrat écrit conforme à l'article 28. Le fournisseur de modèle, s'il reçoit ces données, est un sous-traitant ultérieur qu'il faut identifier.

Trois points sont propres aux agents. D'abord, la réutilisation des échanges pour entraîner le modèle : le contrat doit l'interdire ou l'encadrer, et vérifier que les conditions du fournisseur de modèle offrent la même garantie. Ensuite, la journalisation : pour reconstituer une action contestée, il faut conserver l'entrée, le raisonnement intermédiaire et l'appel d'outil, ce qui entre en tension avec la minimisation des données. Enfin, la localisation des traitements, quand le modèle est servi hors de l'Union. Bases légales, sous-traitance et journalisation sont détaillées dans agents IA et RGPD.

Pour un agent à haut risque, l'article 26, paragraphe 6, impose au déployeur de conserver les journaux générés automatiquement pendant au moins six mois, dans la mesure où ils sont sous son contrôle. Le contrat doit donc garantir au client l'accès à ces journaux, même s'ils sont techniquement stockés chez le prestataire. Lorsque l'agent est utilisé sur le lieu de travail, l'article 26, paragraphe 7, impose d'informer les représentants des salariés. L'agent doit enfin figurer dans l'inventaire des systèmes d'IA tenu par le DPO, ce qui suppose que le prestataire documente les données qu'il traite.

Responsabilité, plafonds et assurance

C'est la négociation la plus dure. Le prestataire veut plafonner sa responsabilité au montant du contrat, parce qu'il ne maîtrise ni le modèle ni l'usage. Le client veut être couvert pour les actions de l'agent, parce qu'il en supporte les conséquences face à ses propres clients.

Ce que le droit commun permet

Le plafond est valable en principe. Il tombe en cas de faute lourde ou dolosive : l'article 1231-3 du Code civil réserve ce cas pour la limitation aux dommages prévisibles, et la jurisprudence l'étend aux clauses limitatives. Il est aussi réputé non écrit s'il prive de sa substance l'obligation essentielle du prestataire (article 1170). Un plafond dérisoire sur un agent dont la fonction même est d'exécuter des opérations fiables est exposé. Le prestataire ne peut pas non plus s'exonérer de son devoir d'information précontractuelle (article 1112-1, alinéa 5) : il doit révéler les limites connues de sa solution qui sont déterminantes pour le consentement du client, par exemple le fait qu'un modèle produit des réponses inventées sur certains types de questions.

Répartir par nature de dommage

Plutôt qu'un plafond unique, je recommande une répartition par cause. Une action exécutée hors du périmètre contractuel, parce que le prestataire a accordé des droits non prévus, relève de sa responsabilité sans plafond réduit. Une erreur dans le périmètre, mais sous le seuil de qualité recetté, relève d'un plafond négocié. Une action hors périmètre décidée par le client, ou une extension de destination non validée, reste à sa charge. Les violations de données et de confidentialité font l'objet d'un plafond spécifique.

Le nouveau régime des produits défectueux

La directive (UE) 2024/2853 intègre expressément les logiciels dans la notion de produit (article 4, 1) pour les produits mis sur le marché après le 9 décembre 2026, date limite de transposition. Au 3 novembre 2026, le Code civil n'a pas encore été modifié : son article 1245-2 vise toujours « tout bien meuble ». Deux règles intéressent directement le contrat d'agent. La responsabilité envers la victime ne peut être ni limitée ni exclue par contrat (article 15). Et un fabricant qui intègre un composant logiciel n'a pas de recours contre le fabricant de ce composant, s'il s'agit d'une micro ou petite entreprise et que le contrat l'a écarté (article 12, paragraphe 2) : une startup prestataire a intérêt à le prévoir. En revanche, la directive ne couvre pas les biens utilisés exclusivement à des fins professionnelles ni les données utilisées à des fins professionnelles (article 6) : le préjudice d'exploitation du client professionnel reste régi par le contrat.

L'assurance

Demandez l'attestation d'assurance responsabilité civile professionnelle du prestataire et vérifiez qu'elle couvre les opérations exécutées par un système d'IA, ce que des polices pensées pour le développement classique ne garantissent pas toujours.

Maintenance, supervision et sortie du contrat

Un agent se dégrade sans qu'on y touche : le modèle évolue, les données changent, les usages dérivent. La maintenance conditionne la qualité recettée.

Ce que la maintenance doit couvrir

• La supervision : tableau de bord des actions, alertes sur les opérations bloquées ou escaladées, revue périodique d'un échantillon.
• La non-régression : réévaluation sur le jeu de recette à chaque nouvelle version du modèle ou du prompt, avec rapport transmis au client.
• Les mises à jour de sécurité : la directive 2024/2853 refuse l'exonération du fabricant quand le défaut tient à une mise à jour logicielle ou à l'absence d'une mise à jour de sécurité restée sous son contrôle (article 11, paragraphe 2). Le contrat doit dire qui décide et qui déploie.
• L'assistance réglementaire : pour un système à haut risque, l'article 25, paragraphe 2, réécrit par l'omnibus, détaille ce que le fournisseur initial doit transmettre à celui qui reprend la qualification de fournisseur (documentation technique, limitations et modes de défaillance connus, accès technique pour test). Ces éléments méritent d'être transposés contractuellement, même hors haut risque.

Réversibilité

En fin de contrat, le client doit récupérer le code cédé, les prompts, la configuration des outils, le jeu d'évaluation, les journaux et la documentation permettant à un autre prestataire de reprendre l'agent. Le contrat fixe le format, le délai et le prix de cette restitution. Les clauses contractuelles types de la Commission européenne pour l'achat public de systèmes d'IA (MCC-AI, version de février 2025), simple document de travail non contraignant, offrent une base de comparaison utile, même entre entreprises privées.

Ce que je recommande avant de signer

Commencez par trois documents : la liste des actions autorisées avec leurs plafonds, le protocole de recette sur jeu d'évaluation, et la cartographie des dépendances, modèle compris. Le reste du contrat se négocie à partir d'eux. Je relis ces contrats avec un double regard d'avocat et de développeur, côté client comme côté prestataire, dans le cadre d'un accompagnement en droit de l'intelligence artificielle. Si votre agent est en cours de cadrage ou si un contrat vous est soumis, échangeons sur votre projet d'agent avant la signature.