Changer de prestataire de développement : la méthode de reprise

À retenir

• L’article L113-9 du code de la propriété intellectuelle attribue les droits sur un logiciel à l’employeur des développeurs. Votre prestataire est cet employeur. Vous ne l’êtes pas.
• Sans clause de cession écrite qui énumère chaque droit cédé et délimite son étendue, sa destination, son lieu et sa durée (article L131-3), vous avez payé le développement sans acquérir le droit de le modifier.
• L’article 28.3.g du RGPD vous donne, indépendamment du contrat de développement, le droit d’exiger au terme de la prestation la restitution ou l’effacement des données personnelles, et la destruction des copies.
• Changer le titulaire d’un nom de domaine déclenche un verrou de transfert de 60 jours (politique de transfert de l’ICANN, section II.C.2). On transfère d’abord entre bureaux d’enregistrement, on change le titulaire ensuite.
• Résoudre un contrat par notification se fait « à ses risques et périls » (article 1226 du code civil) : il faut une mise en demeure écrite qui annonce expressément la résolution et laisse un délai raisonnable.
• L’inventaire des accès se fait avant d’annoncer son départ. Après, chaque demande devient une négociation.
• Un audit de reprise se chiffre poste par poste. Celui qui rend un diagnostic sans chiffrage ne vous avance à rien.

Un prestataire qui ne répond plus n’est pas le pire scénario. Le pire, c’est celui qui répond encore, facture encore, et détient seul les clés : le dépôt de code, le serveur, le compte de la boutique d’applications, le nom de domaine. Vous pouvez partir du jour au lendemain. Vous ne pouvez pas emporter ce que vous n’avez jamais eu.

Cet article ne traite pas de la question juridique de la propriété du code, que nous avons détaillée dans un article dédié. Il traite de l’opération : ce qu’il faut avoir en main avant d’annoncer son départ, combien de temps prend une reprise, et ce qui casse en chemin.

Quels signaux justifient vraiment de changer de prestataire ?

Un bug en production, une livraison en retard ou une hausse de tarif ne sont pas des raisons de changer. Ce sont des incidents, et aucune équipe n’en est exempte. Le signal n’est pas l’incident : c’est ce que le prestataire fait de l’incident.

Ce que vous observez	Ce que ça veut dire	Faut-il changer ?
Un retard, annoncé et expliqué	Une équipe qui mesure son avancement	Non
Un bug en production, corrigé sous 48 h	Un processus de correction qui fonctionne	Non
Une hausse de tarif détaillée ligne par ligne	Une négociation, pas une captivité	Non
Vous n’avez pas d’accès en lecture au dépôt de code	Vous ne pouvez pas vérifier ce que vous payez	Oui
Personne n’est nommé sur votre projet	Vous ne savez pas qui code, ni combien ils sont	Oui
La documentation n’existe pas, et sa demande est facturée	La dépendance est le modèle économique	Oui
Les devis sont au forfait, sans détail	Vous ne pouvez rien arbitrer ni rien comparer	Oui
Plus de la moitié du budget mensuel part en correctifs	Le produit ne se construit plus, il se répare	Oui

Les quatre derniers cas ont un point commun : ils ne se corrigent pas par une conversation. Ce sont des choix d’organisation du prestataire, pas des accidents. C’est cette distinction qui doit décider, pas l’agacement du moment. Les critères à vérifier avant de signer avec le suivant sont détaillés dans notre guide du choix d’une agence.

Que faut-il récupérer avant d’annoncer son départ ?

Tant que la relation est normale, une demande d’accès est une formalité. Une fois le départ annoncé, la même demande devient un point de négociation, parfois un levier. L’inventaire se fait donc en amont, calmement, sans rien annoncer.

Élément	Qui doit en être titulaire	Ce qui bloque si vous ne l’avez pas
Nom de domaine, chez le bureau d’enregistrement	Votre société, avec votre adresse de contact	Vous ne pouvez ni déplacer le site ni recevoir vos e-mails
Dépôt de code, avec tout l’historique	Votre organisation Git, pas celle du prestataire	La reprise devient une réécriture
Hébergement et infrastructure	Un compte à votre nom, facturé à votre société	Le serveur s’arrête le jour où la facture n’est plus payée
Base de données, et une sauvegarde restaurée au moins une fois	Vous	Vous perdez les données, pas le code
Compte Apple Developer et compte Google Play	Votre société, pas le prestataire	Vous ne pouvez plus publier de mise à jour, et l’application reste sous son nom
Comptes de paiement et services tiers	Votre société	Les encaissements, les e-mails et les SMS s’arrêtent sans préavis
Secrets, clés d’API, variables d’environnement	Un coffre que vous contrôlez	Le code ne démarre pas, même complet
Zone DNS et certificats	Vous	Le site devient injoignable au premier renouvellement manqué

Un point se joue dans l’ordre et non dans la liste : ne changez pas le titulaire du nom de domaine avant de l’avoir transféré chez votre propre bureau d’enregistrement. La politique de transfert de l’ICANN impose un verrou de 60 jours après un changement de titulaire, et un autre après un transfert entre bureaux. Dans le mauvais ordre, vous vous enfermez deux mois chez le prestataire que vous quittez.

Qui possède le code, et que faire si le prestataire le garde ?

Le réflexe est de penser que ce qui est payé est acquis. Le droit français dit autre chose. L’article L113-9 du code de la propriété intellectuelle attribue les droits patrimoniaux sur un logiciel à l’employeur des développeurs qui l’ont écrit. Votre prestataire est leur employeur. Vous êtes son client, ce qui n’est pas la même chose.

Pour que les droits vous reviennent, il faut une cession écrite, et l’article L131-3 est exigeant sur la forme : chaque droit cédé doit être mentionné distinctement, et le domaine d’exploitation délimité quant à son étendue, sa destination, son lieu et sa durée. Une ligne de devis disant « cession des droits » ne remplit aucune de ces conditions.

Si le code vous échappe, il reste un levier distinct du contrat de développement : les données. L’article 28.3.g du RGPD oblige le sous-traitant, au choix du responsable de traitement, à effacer ou à renvoyer les données personnelles au terme de la prestation, et à détruire les copies. Ce droit ne dépend ni de la cession des droits d’auteur, ni de la bonne volonté du prestataire. Dans les faits, récupérer la base est souvent plus déterminant que récupérer le code : un code se réécrit, une base de clients ne se reconstitue pas.

Comment rompre sans se mettre en tort ?

C’est l’étape où l’on perd le plus souvent, et toujours de la même façon : en allant trop vite. L’article 1226 du code civil autorise à résoudre un contrat par simple notification, mais ajoute trois mots qui changent tout : à ses risques et périls. Si le prestataire conteste devant le juge, c’est à vous de prouver que l’inexécution était suffisamment grave.

Le même article impose un passage obligé, sauf urgence : une mise en demeure préalable, écrite, qui laisse un délai raisonnable pour s’exécuter et qui mentionne expressément que la résolution est envisagée. Un courriel demandant des correctifs ne remplit pas cette condition. Une lettre recommandée qui qualifie le manquement, fixe un délai et annonce la sanction, oui.

Deux réflexes coûtent cher, et ils sont fréquents. Suspendre les paiements pour faire pression : sans fondement contractuel, vous devenez à votre tour le débiteur défaillant, et vous perdez l’avantage que vous cherchiez. Annoncer son départ avant d’avoir fait l’inventaire : chaque accès devient alors une monnaie d’échange.

Un mot sur le séquestre de code source, souvent présenté comme la solution. Il n’en est une que s’il a été prévu au contrat avant le conflit : c’est un dépôt chez un tiers de confiance, avec une liste limitative de cas de libération. Sans clause de cession ni séquestre, aucun texte n’oblige un prestataire à remettre ses sources, même défaillant. C’est au moment de signer que cela se joue, pas au moment de partir.

Ces éléments décrivent le cadre, ils ne remplacent pas l’avis d’un avocat sur votre contrat. Avant toute mise en demeure, faites relire vos clauses de résiliation, de réversibilité et de propriété intellectuelle par un conseil.

Combien de temps prend une reprise, étape par étape ?

Une reprise n’est pas un développement. On ne construit rien, on prend la main sur quelque chose qui tourne, sans l’arrêter. Voici les durées que nous observons sur nos propres reprises, pour une application en production de taille moyenne.

Étape	Durée	Ce qu’elle produit
Inventaire des accès	1 à 2 jours	La liste de ce que vous détenez vraiment, et de ce qui manque
Audit de reprise	2 à 5 jours	Un rapport chiffré poste par poste, pas un diagnostic
Transfert des accès et du domaine	1 à 15 jours	Tout est à votre nom, y compris les comptes de boutique
Stabilisation et premier correctif	10 à 20 jours	La nouvelle équipe livre en production sans rien casser

L’étape qui déborde le plus souvent n’est pas l’audit : c’est le transfert. Un bureau d’enregistrement peut demander une validation par courriel au titulaire déclaré, une boutique d’applications peut exiger une pièce justificative de société, et le verrou de 60 jours de l’ICANN s’applique sans dérogation. Ce sont des délais administratifs que personne ne raccourcit, d’où l’intérêt de les lancer en premier.

Une étape ne figure pas dans ce calendrier parce qu’elle court en parallèle : le tuilage, c’est-à-dire la période pendant laquelle l’équipe sortante reste joignable pendant que l’entrante prend la main. Deux à quatre semaines suffisent, et cela se négocie au moment de la résiliation, pas après. Un tuilage payé au temps passé coûte toujours moins qu’une semaine de rétro-ingénierie sur une fonction que personne ne comprend.

Qu’est-ce qui casse pendant une reprise ?

Le code est rarement le problème. Ce qui casse, c’est tout ce qui vivait autour de lui sans être écrit nulle part.

• Les secrets non documentés. Clés d’API, jetons, mots de passe de service : ils vivent dans l’environnement du prestataire. Le code complet ne démarre pas sans eux.
• Les tâches planifiées. Facturation mensuelle, relances, exports comptables : souvent un cron sur une machine qui n’appartient à personne dans le dépôt. Il s’arrête sans message d’erreur.
• Les webhooks. Un paiement, une signature, un envoi : chacun appelle une adresse. Si elle pointe chez l’ancien prestataire, les événements se perdent en silence.
• Les certificats. Le renouvellement automatique est lié à un compte. Il tient jusqu’au jour où il ne tient plus, et le site devient injoignable d’un coup.
• Les comptes de boutique. Une application publiée sous le compte du prestataire ne se déplace pas en un clic, et ses notes et son historique ne se transfèrent pas toujours.
• Les sauvegardes. Beaucoup de projets en ont. Peu ont vérifié qu’elles se restaurent. Le jour de la reprise est un mauvais moment pour le découvrir.

La parade est simple et tient en une phrase : exiger que la reprise commence par un démarrage complet du projet sur une infrastructure neuve, à votre nom, avant toute modification du code. Tant que ce démarrage n’a pas eu lieu, personne ne sait ce qui manque.

La migration des données mérite son propre chapitre. Récupérer une base n’est pas la remettre en service : il faut vérifier les jeux de caractères, les enregistrements orphelins laissés par des suppressions incomplètes, les fichiers référencés en base mais absents du stockage, et les identifiants de services tiers qui pointent vers des comptes que vous ne contrôlez plus. Ce travail de nettoyage est systématiquement sous-estimé, parce qu’il n’apparaît qu’une fois la première restauration tentée.

Questions fréquentes

Peut-on changer de prestataire sans son accord ?

Oui. Un contrat de prestation se résilie selon ses propres termes, et aucune clause ne peut vous obliger à rester. Ce que son accord conditionne, en revanche, c’est la facilité du transfert : accès, documentation, transmission de connaissance. D’où l’intérêt de préparer l’inventaire avant d’annoncer, et de résilier dans les formes prévues plutôt que par un courriel d’humeur.

Combien coûte un audit de reprise ?

Il se chiffre au temps passé : deux à cinq jours selon la taille du projet et la qualité de la documentation existante. Ce qui compte n’est pas le prix mais le livrable. Un audit utile donne une estimation chiffrée pour chaque point relevé, de sorte que vous puissiez arbitrer ce que vous corrigez et ce que vous laissez. Un audit qui conclut « le code est de mauvaise qualité » ne vous permet de décider de rien.

Mon prestataire refuse de livrer le code, que faire ?

Vérifiez d’abord ce que dit le contrat : sans clause de cession conforme à l’article L131-3, il n’a pas d’obligation de vous livrer les sources. Deux leviers restent disponibles. Les données personnelles, qu’il doit restituer ou effacer au titre de l’article 28.3.g du RGPD. Et la mise en demeure, qui n’a de sens que si une obligation contractuelle précise est inexécutée.

Faut-il tout réécrire après une reprise ?

Presque jamais, et c’est la proposition qu’il faut regarder avec le plus de méfiance. Réécrire est confortable pour l’équipe entrante et coûteux pour vous : vous payez une seconde fois ce qui existe, sans gagner une seule fonctionnalité. La réécriture se justifie quand une dépendance majeure n’est plus maintenue ou quand une faille structurelle ne se corrige pas localement. Pas parce que le code déplaît. Quand elle s’impose vraiment, elle se fait par remplacement progressif : on construit le nouveau module à côté, on bascule le trafic fonction par fonction, et on supprime l’ancien une fois qu’il ne sert plus. Jamais en une bascule unique, qui est le meilleur moyen de passer six mois sans rien livrer.

Qui est responsable des bugs du code repris ?

La nouvelle équipe ne peut pas garantir ce qu’elle n’a pas écrit, et c’est normal. La formulation saine : elle garantit ses propres livraisons, et traite les anomalies antérieures au temps passé, après un audit qui les a recensées. Une équipe qui garantit d’emblée l’intégralité d’un code qu’elle découvre promet ce qu’elle ne peut pas tenir.

Peut-on garder l’ancien prestataire pendant la transition ?

C’est même ce qu’il faut viser. Un tuilage de deux à quatre semaines, facturé au temps passé et cadré par écrit, permet à l’équipe entrante de poser ses questions pendant que l’application tourne encore sous la surveillance de ceux qui l’ont écrite. Cela se négocie dans le même échange que la résiliation : une fois le dernier jour passé, plus personne n’a de raison de répondre.

Combien de temps avant que la nouvelle équipe soit autonome ?

Comptez un mois pour qu’elle livre sans surveillance sur une application de taille moyenne, et un trimestre pour qu’elle connaisse les angles morts du produit. Ce délai se raccourcit surtout par la documentation produite pendant l’audit, pas par la taille de l’équipe.

Glossaire

• Bureau d’enregistrement : la société chez qui le nom de domaine est enregistré. Le titulaire déclaré chez elle est le propriétaire du domaine, quel que soit celui qui paie la facture.
• Réversibilité : la capacité à quitter un prestataire en emportant ce qui vous appartient. Elle s’organise au contrat, pas au moment du départ.
• Séquestre de code source : dépôt du code chez un tiers de confiance, qui le remet au client si une condition prévue au contrat survient. Utile quand la cession des droits n’est pas négociable.
• Dette technique : le coût futur des raccourcis pris aujourd’hui. Elle ne se voit pas à l’usage, elle se voit au moment d’ajouter une fonctionnalité.
• Tierce maintenance applicative : la prise en charge d’une application existante par une équipe qui ne l’a pas construite. C’est le cadre habituel d’une reprise une fois celle-ci stabilisée.

Sources

• Article L113-9 du code de la propriété intellectuelle · dévolution des droits sur un logiciel à l’employeur · Légifrance
• Article L131-3 du code de la propriété intellectuelle · conditions de forme d’une cession de droits · Légifrance
• Règlement général sur la protection des données, article 28 · obligations du sous-traitant, dont la restitution des données · CNIL
• Article 1226 du code civil · résolution par notification et mise en demeure préalable · Légifrance
• Transfer Policy · verrous de 60 jours après un changement de titulaire ou un transfert · ICANN

À lire aussi sur le blog

• Propriété du code source : vos droits face à une agence · la question juridique en détail, et les clauses qui protègent
• Choisir une agence de développement web en France · les huit critères à vérifier avant de signer avec le suivant
• L’acompte de cadrage · ce que doit produire une phase d’analyse, audit de reprise compris
• Agence française contre offshore · pourquoi le coût réel se mesure sur trois ans
• MVP ou produit fini · le piège du MVP devenu produit, cause fréquente des reprises

Aller plus loin avec nous

• Tierce maintenance applicative · la prise en charge d’une application existante, sans engagement, à partir de 145 € par mois
• Un premier échange sous 48 h · on regarde ce que vous détenez déjà et ce qui manque