Agents, code, données, actifs : comment construire un contrat de confiance

Quand une prestation combine des consultants, des développeurs, des agents, des modèles tiers, des données client et des actifs réutilisables, demander simplement « à qui appartient le livrable ? » ne suffit plus. Le vrai sujet devient : qui peut utiliser quoi, pour quelle finalité, pendant combien de temps, avec quelle capacité de contrôle, de sortie et de preuve, et qui assume lorsque le système se trompe ou agit mal.

La propriété intellectuelle reste essentielle. Mais à l'ère des agents, un bon contrat de confiance est moins un contrat de propriété qu'une architecture de contrôle.

En bref

• •La distinction entre actifs préexistants du prestataire, actifs créés pour le client et éléments co-développés reste utile, mais elle ne suffit plus : il faut aussi traiter les modèles tiers, les données dérivées, les mémoires d'agents, les journaux d'exécution et les résultats générés.
• •« Le client est propriétaire » est souvent une réponse trop pauvre. Il faut préciser les droits d'usage, de modification, de réutilisation, de délégation à un tiers, d'export et de suppression.
• •Les conditions du fournisseur de modèle font désormais partie de l'économie et du risque de la prestation. Elles ne doivent pas rester une dépendance invisible derrière le contrat principal.
• •La réversibilité ne consiste pas nécessairement à céder tout le code ou toute la propriété intellectuelle. Elle consiste d'abord à garantir qu'un client peut continuer, migrer ou faire reprendre le service sans perdre ses données, son historique et sa capacité opérationnelle.
• •Plus les agents gagnent en autonomie, plus la traçabilité devient une condition de responsabilité : sans capacité à reconstituer les données mobilisées, les agents intervenus, les services appelés et les validations humaines, le contrat promet une responsabilité qu'il sera difficile d'établir.

Le nouveau problème : le « livrable » n'a plus de frontière nette

Dans une prestation informatique classique, le découpage contractuel pouvait sembler relativement lisible : le client fournissait des données et des spécifications ; le prestataire fournissait du travail, du code, de la documentation ou un service ; le contrat attribuait ensuite les droits sur les livrables.

Une chaîne agentique brouille ce découpage.

Un agent peut combiner une méthode développée antérieurement par l'ESN, un modèle fourni par un tiers, des bibliothèques open source, la documentation du client, son code source, des tickets, des données récupérées par recherche augmentée, des instructions système, des prompts, une mémoire persistante et des outils capables d'agir sur le système d'information.

Le résultat peut lui-même être du code, une décision proposée, une modification de données ou directement une action exécutée.

Trois catégories restent utiles pour s'orienter : les actifs préexistants du cabinet, les actifs co-créés pendant la mission et les actifs propres au client — une logique qui rapproche progressivement la relation de conseil d'un modèle SaaS, dans lequel le fournisseur conserve son moteur tandis que le client conserve ses données et reçoit des droits d'usage définis.

La transposition aux ESN aboutit au même constat : la propriété intellectuelle, l'intégration, la responsabilité opérationnelle et la confiance deviennent des dimensions structurantes de la prestation augmentée.

Mais cette grille à trois catégories doit désormais être complétée.

La question contractuelle n'est plus seulement « qui possède l'actif ? ». Elle devient « qui garde la maîtrise du système ? »

Ce que les sources montrent réellement

Le changement le mieux documenté n'est pas une nouvelle doctrine universelle de propriété intellectuelle. C'est l'augmentation du nombre de frontières qu'il faut gouverner.

Le guide Cigref-Numeum consacré aux impacts contractuels des projets d'IA recommande explicitement de traiter les droits relatifs aux données d'entraînement, aux données d'entrée, aux résultats générés et au système entraîné à partir des données du client. Il demande également de tenir compte des licences et conditions attachées aux modèles et composants tiers.

Ce même guide traite séparément la responsabilité, l'audit, le reporting et la fin du contrat. Il souligne qu'un système d'IA combine de multiples acteurs et composants, ce qui rend l'imputabilité d'un dysfonctionnement plus difficile. Il recommande donc d'identifier précisément les rôles et d'anticiper contractuellement les responsabilités liées aux résultats.

Ce problème devient encore plus tangible avec les agents. Dans une note publiée en juillet 2026, la CNIL observe que leur capacité à mobiliser plusieurs sources, mémoires, agents et services tiers multiplie les flux de données et rend plus difficiles l'identification, la traçabilité et la maîtrise des traitements. Elle propose notamment de pouvoir reconstituer, pour une tâche, les données mobilisées, les agents intervenus, les services tiers sollicités et leur chronologie.

Cette montée de la supervision est cohérente avec ce qu'on observe par ailleurs : sur un panel de trente organisations sélectionnées pour leurs signaux organisationnels, sans prétention de représentativité, plusieurs cas documentent un déplacement du travail vers la review, la supervision et le traitement des exceptions. Les modèles « humain sur les exceptions » et « développement agentique » placent précisément la boucle de contrôle humain au cœur du fonctionnement.

Le cas Roundtable est particulièrement intéressant pour la gouvernance : dans cette activité régulée, les contraintes juridiques sont intégrées en amont des automatisations et non traitées seulement après la mise en production. C'est un témoignage, pas une preuve que cette organisation constitue un standard sectoriel.

Ce que ces sources ne permettent pas d'affirmer

Elles ne permettent d'abord pas de conclure qu'il existe un bon modèle universel de partage de propriété intellectuelle.

Les actifs co-créés relèvent fréquemment d'une propriété partagée, avec cet avertissement : exiger une restitution complète des actifs peut décourager l'investissement du fournisseur. C'est une grille économique intéressante, mais ce n'est ni une règle juridique générale ni une solution optimale dans toutes les situations.

Pour un système critique développé presque entièrement pour un client, pour un composant stratégique sans solution de substitution, ou lorsqu'une défaillance du fournisseur créerait un risque opérationnel majeur, une cession large du code ou des mécanismes proches de l'entiercement peuvent être parfaitement rationnels.

À l'inverse, exiger la propriété du moteur générique, des méthodes et de tous les composants réutilisables d'un fournisseur peut rendre économiquement impossible leur mutualisation entre plusieurs clients.

Il faut donc résister aux deux réflexes symétriques :

« j'ai payé, donc tout m'appartient » n'est pas une stratégie de souveraineté suffisante.

« c'est notre plateforme, donc vous n'avez besoin de rien d'autre qu'un droit d'accès » n'est pas davantage un contrat de confiance.

Le bon équilibre dépend de la nature de l'actif, de son caractère différenciant, de sa substituabilité et du coût d'une rupture de la relation.

La conviction : la propriété est une dimension du contrôle, pas son synonyme

Il est utile de raisonner sur quatre dimensions distinctes.

La titularité répond à la question : qui détient juridiquement les droits disponibles ?

L'usage répond à : qui peut exploiter, modifier, partager, réutiliser ou faire exploiter l'actif ?

La sortie répond à : que reste-t-il au client lorsqu'il change de fournisseur ?

La responsabilité répond enfin à : qui doit pouvoir démontrer ce qui s'est passé lorsqu'une erreur survient ?

Cette séparation évite une grande partie des faux débats contractuels.

Un client peut ne pas être propriétaire d'un moteur agentique tout en disposant d'un droit d'usage durable, d'une capacité d'export de ses configurations, de ses données et de ses historiques, d'une documentation permettant la reprise par un tiers et d'un mécanisme de substitution du modèle.

À l'inverse, il peut juridiquement posséder un développement spécifique tout en étant incapable de le faire fonctionner parce qu'il dépend d'un modèle, d'une plateforme, d'un index ou d'une couche d'orchestration qu'il ne contrôle pas.

Posséder sans pouvoir sortir est une souveraineté théorique.

Séparer les actifs préexistants de ce qui est réellement créé pour le client

La première discipline consiste à établir le patrimoine avant la mission.

Une ESN devrait pouvoir déclarer ce qu'elle apporte déjà : framework, agent, connecteur, librairie, architecture, dataset licencié, suite d'évaluation, méthode, moteur de règles ou composant logiciel.

Le client peut alors distinguer clairement ce pour quoi il finance un droit d'usage de ce qu'il finance réellement en développement spécifique.

Cette distinction protège les deux parties. Elle évite au fournisseur de découvrir à la fin du projet que le client revendique son socle générique. Et elle évite au client de découvrir qu'un élément présenté comme « son » nouveau système dépend en réalité d'un actif inaccessible après rupture du contrat.

Le sujet est particulièrement important pour le code généré par IA : son origine automatique ne transforme pas magiquement tous ses composants en propriété nouvelle et exclusive. Les licences de composants tiers, les dépendances open source et les éléments préexistants restent à analyser.

Une bonne annexe de propriété intellectuelle devrait ressembler moins à une clause générique qu'à une nomenclature d'architecture.

Ne pas confondre actif co-créé et copropriété automatique

La notion d'actif « co-créé » est utile intellectuellement : un agent ou une automatisation peut effectivement résulter d'une méthode fournisseur, d'un développement réalisé pendant le contrat et de données ou de règles métier apportées par le client.

Mais la copropriété juridique n'est pas nécessairement la meilleure traduction de cette situation. Elle peut au contraire rendre les réutilisations futures difficiles.

Le contrat gagne à décomposer l'actif. Le fournisseur peut par exemple conserver ses briques génériques ; le client recevoir les droits sur les développements purement spécifiques ; chacun disposer de droits précisément définis sur la couche d'adaptation.

Dans d'autres situations, une licence large, perpétuelle ou transférable peut protéger davantage le client qu'une copropriété mal définie.

Un client peut d'ailleurs négocier une licence sur des éléments personnalisés, exclusive ou non, sachant que l'utilité d'une cession peut être limitée si les autres composants nécessaires au fonctionnement restent hors de sa maîtrise.

Le débat n'est donc pas « propriété ou licence ? ».

Il est : de quels droits opérationnels aurons-nous besoin dans trois ans ?

Traiter les données client comme un flux, pas comme une ligne de contrat

Écrire « les données restent la propriété du client » ne suffit pratiquement plus.

Un système agentique peut manipuler les données originales, mais également des extraits, index, embeddings, caches, historiques de conversations, mémoires, traces d'outils ou corpus créés pendant l'exploitation.

La CNIL souligne précisément que les mémoires multiples et la circulation entre agents et services tiers rendent plus complexes la localisation, la rectification et la suppression des données personnelles.

Il faut donc documenter le cycle complet : provenance, finalité, destinations, conservation, accès, sous-traitants, suppression et éventuelle réutilisation pour améliorer le service.

Pour les données personnelles, la qualification juridique des acteurs ne peut pas être décidée uniquement par une phrase commerciale. Un prestataire peut être sous-traitant pour certains traitements tout en étant responsable de traitement pour d'autres, selon la manière dont il détermine les finalités et les moyens.

Le contrat de confiance doit donc répondre à une question très concrète : quelles données peuvent sortir de quel périmètre, pour aller où, et pourquoi ?

Mettre les modèles tiers à l'intérieur du contrat, pas derrière lui

Une prestation peut être vendue par une ESN tout en dépendant profondément d'OpenAI, Anthropic, Google, Microsoft ou d'un autre fournisseur.

Le risque est alors d'avoir un contrat principal extrêmement précis et une dépendance déterminante renvoyée en pratique à des conditions tierces que personne n'a réellement intégrées à l'architecture contractuelle.

Il est recommandé de tenir compte des conditions applicables aux modèles, logiciels et composants tiers et d'adapter la structure du contrat selon que le client contracte directement avec le fournisseur du modèle ou que l'intégrateur assume une responsabilité globale.

Les engagements doivent être vérifiés au niveau du service réellement utilisé, et pas seulement au niveau de la marque. OpenAI indique par exemple ne pas entraîner ses modèles sur les données business par défaut et attribuer au client ses inputs et outputs « dans la mesure permise par la loi » ; pour l'API, la politique de conservation dépend également des endpoints et des configurations, avec jusqu'à trente jours dans certains cas et des options de rétention zéro pour certains usages éligibles.

Ce n'est pas ici une recommandation en faveur ou contre ce fournisseur.

C'est exactement le problème : « nous utilisons tel modèle » n'est pas une information contractuelle suffisante.

Il faut connaître la version du service, les conditions applicables, les lieux de traitement, la politique de conservation, les changements possibles, les droits accordés, les garanties, les limites d'usage et les modalités de remplacement.

Ne pas promettre sur les outputs des droits que personne n'est certain de détenir

Les résultats générés par IA créent un piège particulier.

Il est relativement simple d'écrire contractuellement que le résultat doit être livré au client, rester confidentiel ou ne pas être réutilisé par le prestataire.

Il est beaucoup plus délicat d'affirmer que chaque output est nécessairement protégé par un droit d'auteur exclusif et cessible.

La protection des résultats générés reste une question non entièrement tranchée : il est recommandé, dans cette incertitude, de définir contractuellement leur attribution et d'utiliser si nécessaire des mécanismes de confidentialité ou d'exclusivité. L'EUIPO décrit lui aussi les enjeux de protection des contenus générés comme un domaine encore en évolution, notamment autour de l'originalité et de la contribution humaine.

La conséquence opérationnelle est importante : le contrat peut organiser la relation entre les parties ; il ne peut pas créer un droit de propriété intellectuelle que la loi ne reconnaît pas.

Pour un actif stratégique, mieux vaut donc raisonner simultanément en droits disponibles, confidentialité, secret des affaires, contrôle des réutilisations et contribution humaine documentée.

Faire de la réversibilité une propriété de l'architecture

Dans un système classique, une clause de réversibilité pouvait se résumer à une remise de données et de documentation.

Dans un dispositif agentique, la sortie peut nécessiter davantage : configurations, historiques, jeux d'évaluation, règles métier, connecteurs, schémas, mapping des permissions, documentation des agents, inventaire des modèles, procédures d'exploitation et connaissance des dépendances tierces.

Il est recommandé d'anticiper dès le contrat ce qui arrive au système et aux données lorsque la relation prend fin : poursuite d'utilisation, reprise par un tiers, restitution, effacement et droits sur les éléments modifiés.

Le Data Act européen, applicable depuis le 12 septembre 2025, renforce par ailleurs les possibilités de changement entre fournisseurs de services de traitement de données, notamment dans le cloud. Il prévoit un cadre facilitant le switching, tout en maintenant des distinctions avec les éléments protégés par la propriété intellectuelle ou les secrets commerciaux du fournisseur.

La réversibilité n'exige pas nécessairement que le client devienne propriétaire de toute la technologie du fournisseur. Elle exige qu'il ne devienne pas prisonnier de ce qu'il ne possède pas.

Remplacer « l'auditabilité » abstraite par une liste de preuves disponibles

« Le système est auditable » est une promesse beaucoup trop vague.

Auditabilité de quoi ? Des données utilisées ? Du modèle sélectionné ? De l'instruction système ? Des appels d'outils ? Des décisions humaines ? Des changements de configuration ? Des incidents ? Du respect des seuils d'autonomie ?

Il est recommandé de tenir une documentation et des registres pendant le cycle de vie, ainsi que de permettre au client d'obtenir des éléments d'audit sur le fonctionnement, l'exploitation, la maintenance et la gestion des risques.

La CNIL va plus loin pour les agents : elle envisage une traçabilité permettant d'identifier les données, les agents, les services tiers et la chronologie des actions. Elle recommande également de limiter les accès, de cloisonner les mémoires et de maintenir une intervention humaine pour les actions critiques.

Cela ne signifie pas pour autant que le fournisseur doive systématiquement dévoiler tous ses prompts propriétaires ou son code interne.

Un compromis est possible : journaux d'exécution, versions, empreintes de configuration, registre des modèles et services, historique des changements, métriques, incidents et validations peuvent rendre une prestation vérifiable sans livrer tous ses secrets industriels.

L'auditabilité ne devrait pas être mesurée au volume d'informations accessibles, mais à la capacité de reconstituer un événement important.

Faire suivre la responsabilité par le contrôle réel

C'est probablement la règle la plus importante.

Un fournisseur ne devrait pas assumer sans limite un résultat qu'il ne contrôle pas. Mais un client ne devrait pas non plus porter seul la responsabilité d'un comportement déterminé par une architecture, un paramétrage ou des garde-fous qu'il ne maîtrise pas.

Le contrat doit donc distinguer plusieurs couches. Le fournisseur du modèle contrôle une partie du comportement du modèle. L'ESN ou l'intégrateur contrôle l'orchestration, le contexte, certaines protections et les interfaces. Le client contrôle certaines données, permissions, règles métier et décisions finales. Un éditeur tiers peut contrôler l'application dans laquelle l'agent agit.

La répartition des responsabilités doit refléter cette réalité opérationnelle, avec la responsabilité sur les résultats, les seuils d'erreur et les obligations de vérification traités explicitement.

L'AI Act renforce cette nécessité de penser en rôles : les obligations dépendent de la place occupée dans la chaîne de valeur et de la catégorie du système, et non uniquement de ce que les parties ont choisi d'écrire en tête de leur contrat. Certaines obligations de transparence de l'article 50 s'appliquent depuis le 2 août 2026.

La CNIL formule le même problème pour les données : même dans un système composé de multiples agents, un responsable du traitement doit rester identifiable.

On ne devrait jamais attribuer une responsabilité importante sans attribuer simultanément le pouvoir de contrôler le risque correspondant.

Le contre-argument : pourquoi ne pas simplement tout donner au client ?

Cette approche a une apparente simplicité.

Le client paie. Il obtient les données, le code, les prompts, les modèles adaptés, les automatisations et tous les droits. Plus de question de dépendance.

Elle peut être rationnelle sur certains périmètres très spécifiques.

Mais appliquée systématiquement, elle pose trois difficultés.

La première est économique : un fournisseur ne peut pas industrialiser un actif entre plusieurs clients s'il en cède l'intégralité au premier projet.

La deuxième est technique : disposer du code source ne garantit pas que le client puisse reproduire la plateforme, les modèles ou les services tiers nécessaires à son fonctionnement.

La troisième est stratégique : le fournisseur peut finir par traiter chaque mission comme un développement jetable au lieu d'investir dans des actifs maintenus.

L'erreur inverse serait cependant de transformer cet argument en justification du lock-in.

Le bon contrat cherche donc moins à maximiser la propriété d'une partie qu'à rendre les dépendances explicites et substituables.

C'est à cet endroit que se construit la confiance : le fournisseur protège ce qu'il doit pouvoir réutiliser ; le client protège ce qu'il doit pouvoir continuer à exploiter.

Une matrice de questions pour négocier le contrat

Le test DRYVE : trois scénarios à simuler avant de signer

Un contrat de confiance devrait pouvoir survivre à trois questions simples.

Le fournisseur du modèle double son prix ou retire le modèle utilisé. Peut-on migrer ? Qui finance l'opération ? Quels tests permettent de vérifier que le modèle de remplacement reste acceptable ?

L'ESN disparaît ou le client souhaite changer de prestataire. Le nouvel opérateur peut-il récupérer les données, configurations, connaissances d'exploitation et historiques indispensables sans reconstruire le système depuis zéro ?

Un agent réalise une action erronée à fort impact. Peut-on reconstituer le contexte, identifier les données et systèmes utilisés, connaître la version du modèle et de l'agent, retrouver les validations humaines et déterminer l'origine probable de l'erreur ?

Si le contrat ne permet pas de répondre clairement à ces scénarios, sa faiblesse n'est probablement pas dans une clause juridique isolée. Elle est dans l'architecture même de la relation.

Auto-diagnostic : votre contrat est-il réellement prêt pour les agents ?

Reprenez votre contrat ou votre cahier des charges actuel et attribuez un point chaque fois que vous pouvez répondre précisément, sans interprétation, à chacune des dix lignes de la matrice précédente.

8 à 10 réponses claires : votre architecture contractuelle commence à refléter la réalité technique.

5 à 7 : le dispositif est probablement exploitable, mais plusieurs dépendances restent implicites.

0 à 4 : le contrat traite probablement encore l'IA comme un outil utilisé par le prestataire, alors qu'elle est devenue une composante de la chaîne de production.

Le score importe moins que les cases vides. Ce sont elles qui indiquent où commencer la discussion entre direction, juridique, achats, sécurité et delivery.

Cette grille est une grille de gouvernance et de décision ; elle ne remplace pas l'analyse juridique adaptée à un projet et à son contexte réglementaire.

La conviction

L'IA agentique ne rend pas les contrats impossibles. Elle révèle plutôt une faiblesse ancienne : nous avons longtemps utilisé le mot « propriété » pour traiter des problèmes qui relevaient en réalité du contrôle, de la dépendance et de la responsabilité.

La réponse ne consiste pas à ajouter une annexe « IA » de vingt pages à un contrat classique.

Elle consiste à faire correspondre trois architectures.

L'architecture technique décrit les modèles, agents, données, logiciels et flux.

L'architecture contractuelle attribue les droits, les obligations, les responsabilités et les possibilités de sortie.

L'architecture managériale détermine qui décide, qui vérifie et qui assume.

Lorsque ces trois architectures se contredisent, la confiance repose sur la bonne volonté des personnes.

Lorsqu'elles s'alignent, un client peut laisser davantage d'autonomie à ses partenaires et à ses agents précisément parce qu'il sait ce qui restera sous son contrôle.

C'est probablement là que se joue le vrai contrat de confiance à l'ère de l'IA : ne pas chercher à supprimer toutes les dépendances, mais rendre chacune d'elles visible, gouvernable et réversible.