Quitter son prestataire IA sans perdre le produit : propriété du code, réversibilité et clauses de sortie

---

title: "Quitter son prestataire IA sans perdre le produit : propriété du code, réversibilité et clauses de sortie" seoTitle: "Quitter son prestataire IA sans perdre le produit" description: "Le code vous appartient, dit le devis. En pratique, la moitié de ce qui fait marcher votre fonctionnalité IA n'est pas dans le dépôt. Voici les actifs à récupérer, les clauses à exiger avant de signer, et la façon de négocier une sortie quand rien n'a été prévu." seoDescription: "Propriété du code, prompts, index vectoriel, clés d'API : ce qu'il faut exiger pour quitter un prestataire IA sans perdre le produit." date: "2026-10-01" author: "Équipe Raicode" tags: ["IA", "automatisation", "gestion de projet", "audit"] category: "IA & Automatisation" keywords: ["quitter son prestataire IA", "réversibilité projet IA", "propriété du code agence IA", "clause de réversibilité IA", "changer d'agence IA", "cession de droits code sur mesure", "lock-in prestataire IA", "contrat agence intelligence artificielle", "sortie de contrat projet IA"]

La décision est prise : vous changez de prestataire. L'agence qui a construit votre assistant de support répond en quatre jours, la facture mensuelle a doublé sans explication, et la dernière mise en production a cassé deux parcours client. Le contrat prévoit un préavis de trois mois. Votre directeur juridique vous dit que c'est propre, que le devis mentionne « livraison du code source », et qu'il n'y a donc pas de sujet.

Il y a un sujet. Sur une application web classique, récupérer le dépôt Git et la base de données suffit à repartir. Sur un produit à base de LLM, ces deux éléments représentent peut-être la moitié de ce qui fait fonctionner la chose. L'autre moitié — les prompts et leur historique d'arbitrages, le jeu de cas qui sert à vérifier que le modèle ne régresse pas, l'index vectoriel et le pipeline qui l'alimente, les comptes d'API ouverts au nom de l'agence — n'est presque jamais nommée dans le contrat. Elle se négocie au moment où vous avez le moins de levier : après avoir annoncé votre départ.

Cet article décrit ce qu'il faut exiger avant de signer, et ce qu'on peut encore sauver quand on a signé sans rien exiger.

« Le code vous appartient » ne veut rien dire tant que ce n'est pas écrit

Première surprise, et elle est purement juridique. En droit français, le code source est une œuvre de l'esprit : il appartient par défaut à celui qui l'a écrit, c'est-à-dire au prestataire. La cession des droits patrimoniaux ne se déduit pas du paiement de la facture. Elle doit être écrite, expresse, et délimiter les droits cédés, leur destination, leur étendue géographique et leur durée. Une phrase commerciale du type « le code développé vous appartient » dans la proposition commerciale, sans clause de cession formelle dans le contrat, laisse une ambiguïté dont vous ne voulez pas le jour où vous partez fâché.

Ce qui change en pratique, selon la rédaction :

• Cession pleine des droits sur les développements spécifiques. Vous pouvez modifier, faire modifier par un tiers, et redistribuer. C'est ce que vous voulez.
• Licence d'utilisation non exclusive. Vous avez le droit de vous servir du logiciel, pas forcément celui de le faire reprendre par une autre équipe, ni de le dériver. Beaucoup de contrats s'arrêtent là sans que le client s'en aperçoive.
• Cession assortie d'une licence de réutilisation au profit de l'agence sur ses briques génériques. C'est légitime — personne ne veut qu'un prestataire réécrive son système d'authentification à chaque mission — à condition que le périmètre de ces briques soit nommé dans une annexe, pas laissé à l'appréciation du prestataire au moment de la séparation.

Le cas qui fait le plus de dégâts est le troisième mal rédigé. L'agence a construit votre produit sur son socle interne — orchestrateur d'appels au modèle, couche de cache, gestion des traces, connecteurs. Elle vous cède le code métier et garde le socle. Techniquement, elle respecte le contrat. Vous repartez avec une coquille qui ne compile pas sans une bibliothèque privée que vous n'avez pas le droit d'utiliser.

Ce qu'il faut exiger : une clause de cession expresse sur l'ensemble des développements spécifiques, et une annexe qui liste nommément les composants réutilisables du prestataire, assortie d'une licence perpétuelle, irrévocable et transférable sur ces composants-là. « Transférable » est le mot qui compte : sans lui, la licence meurt le jour où vous confiez la maintenance à quelqu'un d'autre.

Les cinq actifs qui ne sont pas dans le dépôt Git

C'est la partie spécifique aux projets IA, et celle que les contrats types ignorent. Un contrat de développement web standard protège ce qui vit dans le dépôt et dans la base. Un produit LLM a cinq actifs supplémentaires, et chacun peut suffire à vous immobiliser.

1. Les prompts et l'historique des arbitrages. Les prompts de production sont souvent dans le code, donc techniquement cédés. Ce qui ne l'est pas, c'est le raisonnement derrière : pourquoi cette consigne a été ajoutée en mars, quel incident client l'a motivée, ce qui a été essayé avant. Sans cette mémoire, votre nouvelle équipe va « nettoyer » un prompt bavard et ressusciter un bug corrigé il y a huit mois. Exigez que les prompts soient versionnés dans le dépôt, avec un commentaire ou un fichier de décisions, et non stockés dans une interface tierce ou une variable d'environnement.

2. Le jeu d'évaluation. C'est l'actif le plus précieux et le plus souvent perdu. Quelques centaines de cas réels avec la réponse attendue, construits incident après incident : c'est ce qui permet de changer un prompt, un modèle ou un paramètre sans jouer à la roulette. Reconstituer un jeu d'évaluation représente plusieurs semaines de travail et suppose un accès aux données historiques que vous n'aurez peut-être plus. S'il n'est pas explicitement listé comme livrable, il reste chez le prestataire — parfois simplement parce qu'il vit dans un tableur sur le poste d'un développeur.

3. L'index vectoriel et le pipeline d'ingestion. L'index lui-même n'est pas le problème : il se reconstruit. Ce qui coûte, c'est la chaîne qui le fabrique — les règles de découpage des documents, le modèle d'embedding retenu et sa version, les filtres de métadonnées, les correctifs appliqués aux documents sales. Un index reconstruit avec un découpage légèrement différent donne des résultats légèrement différents, et votre fonctionnalité se met à répondre moins bien sans que personne ne sache pourquoi. Exigez le pipeline, sa configuration, et la version exacte du modèle d'embedding utilisé.

4. Les comptes et clés d'API. C'est le point de blocage le plus brutal. Si l'accès au fournisseur de modèle, à la base vectorielle ou à l'hébergeur est ouvert au nom de l'agence, vous ne possédez ni l'historique de consommation, ni les quotas négociés, ni parfois les données qui y sont stockées. Le jour de la sortie, il faut rouvrir des comptes, refaire valider la conformité, et migrer sans coupure. Compter deux à quatre semaines est réaliste. La règle est simple et doit figurer au contrat : tous les comptes fournisseurs sont ouverts au nom du client dès le premier jour, le prestataire y est invité comme utilisateur. Cela vaut aussi pour le dépôt Git, qui doit vivre dans votre organisation et non dans la sienne.

5. Les traces et les retours d'usage. Les journaux d'appels au modèle, les signalements des utilisateurs, les conversations marquées comme mauvaises. C'est la matière première de toute amélioration future et, pour beaucoup de projets, une donnée à caractère personnel dont vous êtes responsable de traitement. Exigez un export dans un format exploitable, avec sa durée de conservation et son périmètre.

Si vous héritez d'un projet dont ces cinq actifs sont incomplets, la reprise ne commence pas par la lecture du code. Nous décrivons la méthode qui donne un verdict en cinq jours dans l'audit de la première semaine d'une reprise de projet IA, et c'est typiquement le genre de situation où nous intervenons dans le cadre d'une reprise de projet IA : établir ce qui est récupérable avant d'arbitrer entre continuer et réécrire.

Le lock-in plateforme : exporter n'est pas migrer

Deuxième famille de blocage, indépendante du contrat. Si votre prestataire a construit sur une plateforme d'agents propriétaire — un orchestrateur visuel, une solution d'agents clé en main, un éditeur de workflows — la question n'est plus de savoir à qui appartient le code, mais ce que l'export produit.

Posez la question dans ces termes exacts, et demandez une démonstration plutôt qu'une réponse : montrez-moi un export complet, et dites-moi ce qu'il faut pour le faire tourner ailleurs. Les trois réponses possibles :

• L'export est un JSON de configuration interprétable uniquement par la plateforme. Vous récupérez une description de vos flux, pas un programme. C'est une documentation, pas une réversibilité. Le coût de sortie équivaut à une réécriture.
• L'export est du code dans un langage standard mais dépendant du SDK de l'éditeur. Sortie possible, à condition de remplacer les appels au SDK. Comptez quelques semaines selon la surface.
• Le produit tourne sur des briques standards — votre dépôt, votre base, des appels directs aux API des fournisseurs de modèles. Vous n'avez pas de problème de plateforme.

Le choix d'architecture initial détermine donc le coût de sortie bien avant que la question ne se pose. C'est un critère qui mérite d'être pesé au moment de la sélection, au même titre que les questions qui remplacent utilement les certifications d'un prestataire IA. L'argument « pas de lock-in » est devenu un standard d'annonce sur les pages d'agences. Il ne coûte rien à écrire ; demandez la démonstration d'export, pas la promesse.

La clause de réversibilité : six lignes qui changent tout

La réversibilité est une obligation courante dans les contrats d'infogérance. Elle est rare dans les contrats d'agence IA, où le modèle commercial reste proche du développement au forfait. Elle tient pourtant en quelques points, à insérer avant la signature :

1. Déclencheurs. La réversibilité s'applique à la fin du contrat, quelle qu'en soit la cause — y compris une résiliation pour faute de votre côté. Un prestataire qui conditionne la restitution au règlement de tout litige en cours tient votre produit en otage.
2. Périmètre nommé. Code, dépendances privées, prompts et décisions associées, jeu d'évaluation, pipeline d'ingestion et configuration d'index, scripts d'infrastructure, secrets, traces et données d'usage, documentation d'exploitation. Nommez-les un par un : ce qui n'est pas listé ne sera pas livré.
3. Format. Dépôt Git avec son historique complet, pas une archive. L'historique est ce qui permet de comprendre une décision six mois plus tard ; une archive ZIP vous livre un état sans mémoire.
4. Critère de recette. La réversibilité est acquise quand un tiers désigné par vous a reconstruit l'environnement à partir des seuls livrables et obtenu les mêmes résultats sur le jeu d'évaluation. Tant que ce test n'est pas passé, la prestation n'est pas achevée. C'est la clause la plus importante, parce qu'elle est la seule vérifiable.
5. Assistance de transition. Un volume de jours ouvré, à un tarif fixé d'avance, mobilisable dans les quatre-vingt-dix jours suivant la fin du contrat. Sans tarif prédéfini, la journée de transfert se négocie quand vous n'avez plus le choix.
6. Délai et pénalité. Trente jours après la demande, avec une pénalité journalière. Une obligation sans échéance ni sanction est une intention.

Si rien n'a été prévu : la séquence de sortie

La situation la plus fréquente est celle où vous lisez cet article avec un contrat déjà signé et muet sur tout ce qui précède. Le levier qui reste est le calendrier, et il s'use vite. L'ordre des opérations compte plus que la fermeté du ton.

Avant d'annoncer quoi que ce soit, faites l'inventaire. Listez les comptes et au nom de qui ils sont ouverts, l'emplacement réel du dépôt, l'existence d'un jeu d'évaluation, les dépendances privées dans les fichiers de configuration, ce qui tourne sur une plateforme tierce. Cette heure de travail détermine votre position de négociation. Une relation qui se tend après l'annonce rend l'inventaire beaucoup plus difficile à obtenir.

Récupérez ce que vous pouvez récupérer sans autorisation. Clonez le dépôt avec son historique si vous y avez accès. Exportez les traces et les données. Faites une copie de la configuration de l'index. Rien d'agressif : vous ne faites que vous assurer de disposer de ce qui vous revient.

Transformez la sortie en prestation payante. C'est le point qui débloque le plus de situations. Un prestataire sortant n'a aucune incitation à documenter gratuitement un produit qu'il perd. Un transfert chiffré, avec un périmètre écrit et une recette — reconstruction par votre équipe, à partir des seuls livrables, avec les mêmes résultats sur un échantillon de cas — change la conversation. Quelques jours facturés coûtent beaucoup moins qu'un trimestre de rétro-ingénierie.

Exigez la passation en personne, pas en documents. Deux sessions de deux heures avec le développeur qui a réellement écrit la fonctionnalité valent plus que trente pages rédigées après coup. Préparez vos questions à partir de l'inventaire : pourquoi ce seuil, quels cas ont motivé cette consigne, qu'est-ce qui a déjà été essayé et abandonné.

Ne coupez rien avant d'avoir reproduit. La seule preuve que la reprise a fonctionné, c'est un environnement reconstruit par votre équipe, alimenté par vos clés, qui donne les mêmes réponses que la production sur un échantillon de cas réels. Tant que ce test n'est pas passé, gardez l'accès au prestataire sortant. C'est aussi à ce moment-là qu'il faut vérifier que vous disposez de l'instrumentation minimale pour exploiter le produit seul — le sujet que nous traitons dans mettre un agent IA en production sans voler à l'aveugle.

Les trois erreurs qui coûtent le plus cher

Annoncer avant d'inventorier. C'est l'erreur dominante. Elle transforme une opération d'une demi-journée en négociation de plusieurs semaines.

Accepter une archive à la place d'un dépôt. Un ZIP de 400 Mo a l'air d'une livraison. Il ne contient ni historique, ni branches, ni messages de commit, et ne dit rien de ce qui a été tenté. C'est la forme la plus courante de conformité apparente.

Confondre « ça tourne » et « on peut le faire tourner ». Un produit qui fonctionne en production chez le prestataire ne prouve rien sur votre capacité à le relancer ailleurs. Seule la reconstruction depuis zéro, avec vos comptes, le prouve. Tant qu'elle n'a pas eu lieu, vous n'avez pas repris le produit : vous en avez reçu une copie.

Par où commencer cette semaine

Si vous êtes en train de choisir un prestataire, ajoutez trois lignes à votre contrat : cession expresse des développements spécifiques, licence perpétuelle et transférable sur les briques réutilisables listées en annexe, et comptes fournisseurs ouverts à votre nom dès le premier jour. Elles ne coûtent rien à la signature et valent plusieurs semaines le jour de la sortie.

Si le contrat est déjà signé, faites l'inventaire aujourd'hui, avant toute annonce : où vit le dépôt, au nom de qui sont les clés, existe-t-il un jeu d'évaluation, et que produit un export de la plateforme utilisée. Vous saurez en une heure si votre sortie est une formalité ou une négociation — et dans le second cas, vous saurez sur quoi elle portera.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.