CookiesClause de réversibilité : ce qu'on vérifie avant de reprendre un logiciel sur mesure
Avant de reprendre un logiciel écrit par un autre prestataire, on lit d'abord les papiers : cession écrite des droits, licences des composants, clause de réversibilité, qui dit ce que l'ancien prestataire remet à la sortie. On vérifie que le nom de domaine et les comptes sont à votre nom. Puis trois épreuves qu'un audit de code ne remplace pas : reconstruire le logiciel depuis son code source, le déployer, restaurer une sauvegarde. Enfin, ce que l'ancien prestataire sait sans l'avoir écrit.
Votre logiciel peut-il changer de prestataire ?
Répondez à 4 questions rapides
Changer de prestataire informatique, quand il s'agit d'un logiciel développé pour vous, n'a rien d'une simple résiliation. Quelqu'un d'autre va devoir faire tourner, corriger et faire évoluer du code qu'il n'a pas écrit. La clause de réversibilité du contrat dit ce que l'ancien prestataire doit remettre ; ce que le repreneur vérifie avant d'accepter dit si le logiciel peut vivre sans la personne qui l'a écrit.
📖 Clause de réversibilité : définition
Qu’est-ce qu’une clause de réversibilité ? C’est la clause d’un contrat informatique qui organise la sortie : elle garantit au client la possibilité de reprendre ce qu’il avait confié à un prestataire, pour l’exploiter lui-même ou le confier à un autre, et elle dit ce que le prestataire sortant remet, comment et dans quel délai. Le guide de l’ANSSI sur l’externalisation, publié en 2010, veut qu’elle puisse être activée à tout moment, sans avoir à se justifier, dans le délai fixé au contrat.
Pour un logiciel sur mesure, elle va de pair avec la cession des droits : la cession dit à qui appartient le code, la réversibilité dit comment vous le récupérez, avec les données, la documentation et les comptes. Un plan de réversibilité, annexé au contrat, en porte le détail.
Voici ce que nous vérifions, dans l’ordre, avant de reprendre un logiciel. Une partie se fait sans aucun accès, et vous pouvez la faire vous-même cette semaine.
🔭 Ce qu’on voit avant d’avoir le moindre accès
Le code que reçoit le navigateur, son poids, les scripts qu’il charge et sa vitesse se mesurent depuis n’importe quel poste. Les enregistrements DNS du domaine disent chez qui le logiciel est hébergé.
Le nom de domaine, surtout, se vérifie tout de suite. Pour un nom en .fr, le Whois de l’Afnic indique le titulaire, c’est-à-dire la personne qui détient les droits et les responsabilités attachés au nom.
Voici un relevé de ce genre, fait sans identifiant ni accès les 23 et 24 septembre 2026 ; ses mesures sont celles de ces deux jours, le site a pu changer depuis.
📜 Avant le code, les papiers
La cession des droits. Comme le rappelle Bpifrance Création sur la titularité des droits d’un logiciel, commander un logiciel à un prestataire externe ne fait pas du client le titulaire des droits. Il faut un contrat de cession, ou au minimum une clause de cession dans le contrat de développement. Avoir payé ne remplace pas cet écrit : c’est pour cela qu’un cahier des charges logiciel bien construit consacre un chapitre aux droits sur le code et à la réversibilité.
Les composants libres. Un logiciel sur mesure embarque des bibliothèques open source, et certaines créent des obligations pour qui modifie le code. La licence GNU AGPL v3, par exemple, impose à qui exploite une version modifiée de proposer son code source aux utilisateurs qui s’en servent à distance, par le réseau (article 13). Avant de reprendre, on dresse la liste de ces conditions : une seule peut changer ce que vous avez le droit de faire du logiciel.
🔁 Clause et plan de réversibilité : organiser le changement de prestataire
La clause type du guide de l’ANSSI sur l’externalisation montre ce qu’une clause complète contient. Elle ne s’arrête pas aux données, à rendre dans un format standard : le prestataire sortant remet aussi tous les éléments du logiciel, documentation, programmes et chaînes de compilation, sous une forme que son successeur peut installer sur la plateforme de son choix.
Une clause utile dit aussi comment, quand et à quel prix ; un plan de réversibilité annexé au contrat peut en porter le détail. Sans elle, la sortie se négocie au pire moment.
- Comment : l’assistance pendant la migration, et qui la donne
- Quand : le préavis, puis la durée de la transition
- À quel prix : qui paie la sortie, selon qui met fin au contrat
Pour les données personnelles, le droit fixe un plancher : l’article 28 du RGPD prévoit qu’au terme de la prestation, le prestataire qui les traite pour vous supprime toutes les données ou vous les renvoie, selon votre choix, et détruit les copies existantes.
Qui paie la réversibilité ?
Nous n’avons trouvé aucun texte qui fixe, pour un contrat de développement entre entreprises, qui paie la sortie selon qui met fin au contrat : c’est le contrat qui le dit. S’il se tait, le coût de la réversibilité se négocie au moment où vous avez le moins de marge. Deux textes donnent tout de même des repères.
La clause type de l’ANSSI met la restitution de tout ce qui a été confié au prestataire, matériels, logiciels et documentation, à ses frais, dans le mois qui suit l’arrêt des prestations. Elle l’engage aussi à assister la migration, sans en fixer le prix.
Le règlement européen sur les données (règlement (UE) 2023/2854, dit Data Act) vise les services d’infrastructure, de plateforme et de logiciel à la demande. Jusqu’au 12 janvier 2027, les frais qu’un tel fournisseur facture pour un changement de fournisseur ne peuvent pas dépasser les coûts directement liés à ce changement ; à partir de cette date, ils sont interdits (article 29). Mais l’article 31 écarte de cette règle les services conçus pour l’essentiel sur mesure pour un client, quand ils ne sont pas proposés à grande échelle sur catalogue : un logiciel développé pour vous seul peut entrer dans ce cas. Le fournisseur doit alors vous dire, avant de signer, quelles obligations ne s’appliquent pas.
Pour un logiciel sur mesure, la réponse est donc au contrat. Cinq lignes à y écrire :
🔑 Nom de domaine et comptes tiers : à votre nom avant la bascule
Si le Whois donne votre société comme titulaire, vous pouvez changer de bureau d’enregistrement à tout moment : selon les règles de l’Afnic pour un nom en .fr, la demande de transfert passe par le nouveau bureau, avec le code AUTH_INFO que l’ancien doit vous fournir. S’il donne le prestataire, le nom sous lequel vos clients vous trouvent n’est pas à vous : il faut une transmission, qui demande sa validation. Obtenez-la avant d’annoncer votre départ.
Le même tri vaut pour chaque compte dont dépend le logiciel : le compte chez le bureau d’enregistrement, où se trouve en général ce code, l’hébergeur, le dépôt du code source, les services extérieurs (envoi d’e-mails, paiement, mesure d’audience). Pour chacun : à quel nom, qui paie, qui administre ? Ce qui est au nom du prestataire passe au vôtre pendant la passation, ou se recrée à votre nom avant la bascule.
🧪 Un audit de code ne suffit pas : trois épreuves
Un audit de code répond à une question : ce code est-il bien écrit, et quelle dette technique porte-t-il ? Une reprise en pose une autre : ce logiciel vit-il sans son auteur ? Un code propre peut y échouer, un code moyen la réussir. Elle ne se tranche pas sur rapport, mais en faisant.
Construire et lancer le logiciel depuis son seul code source, sur un environnement neuf.
Mettre en production une modification sans risque, depuis des comptes au nom de votre entreprise.
Remonter une sauvegarde sur un environnement séparé, et vérifier les données qu'elle rend.
Reconstruire. Sur un environnement neuf, ce qui manque apparaît tout de suite : une bibliothèque privée, une clé absente, un script qui pointe vers le poste d’un développeur. On compare ensuite avec la production : un écart veut dire qu’une modification a été faite sur le serveur, sans passer par le code.
Déployer. Cette épreuve teste le contrôle, pas le code. Le 1er octobre 2026, nous avons vu Vercel refuser de déployer parce que la dernière modification enregistrée dans le code venait de quelqu’un qui n’était pas membre de l’équipe, même quand un membre lançait lui-même le déploiement. La documentation de Vercel sur la collaboration le dit : pour une équipe Pro, l’auteur de la modification doit être membre de l’équipe qui porte le projet, et l’offre gratuite ne permet pas de collaborer sur un code privé. Avoir les comptes à son nom ne suffit donc pas : le repreneur doit y être invité, avec les bons droits, avant la première correction.
Restaurer. Une sauvegarde qui n’a jamais été restaurée ne prouve rien.
🗝️ Ce qui n’est écrit nulle part : l’entretien de passation
Une partie de ce qui fait tourner un logiciel n’existe dans aucun fichier : la tâche qui tourne la nuit, le réglage fait un jour sur le serveur, le contournement jamais documenté.
Notre ordinateur de travail est mort et a emporté tout ce qui n'était pas sur GitHub : la documentation et le savoir sur l'automatisation de notre blog. Le code avait survécu ; le savoir sur le code, non. D'où une base de connaissance versionnée, qui garde ce savoir comme on garde le code.
Tant que le prestataire sortant est joignable, ce savoir se récupère ; après, il se reconstitue, et c’est plus long. Un entretien de passation, préparé et noté par écrit, couvre l’essentiel.
Une réponse floue est aussi une information : elle dit où la lecture du code devra creuser. Les réponses s’écrivent à côté du code source.
⚖️ Reprendre ou reconstruire : la ligne de partage
Deux réponses décident de la nature du chantier : le logiciel se reconstruit-il depuis son code source, et les droits sont-ils à vous ? Les comptes, eux, se transfèrent pendant la passation.
Le logiciel peut changer de mains. Si les bibliothèques ou les tests sont en retard, la remise à niveau passe avant les évolutions.
Le code existe mais ne vous appartient pas. La cession se règle avec l'ancien prestataire, ou avec un avocat, avant tout devis de reprise.
On comble l'écart à partir de ce qui tourne en production et des comptes à votre nom. Si rien n'est accessible, c'est une reconstruction.
On refait un logiciel qui rend les mêmes services, sans reprendre une ligne de l'ancien code.
Reconstruire n’est pas un échec. Le droit d’auteur protège le code, pas les fonctionnalités : un logiciel qui rend les mêmes services peut être réécrit, à condition de ne pas recopier l’ancien.
C’est cette lecture que nous faisons avant tout devis de reprise et maintenance applicative : le code source, la production et la liste des comptes, avec un accès en lecture seule. Le devis, gratuit et plafonné, vient après, et il dit s’il vaut mieux reconstruire.
🎯 En résumé
Si vous préparez ce changement, commencez par ce qui ne demande l’accord de personne : le Whois de votre nom de domaine, le contrat et sa clause de réversibilité, la liste des comptes et de leurs titulaires. Pour fixer ce que vous exigerez du suivant, notre guide sur la sécurité des applications web dit quoi demander et comment le vérifier.
Questions fréquentes
Ce que le prestataire remet à la sortie : les données dans un format standard, le code source et de quoi le reconstruire, la documentation, les comptes. Puis comment se passe la migration et qui l'assiste, le préavis et la durée de la transition, et qui paie la sortie. Le guide de l'ANSSI sur l'externalisation en propose une clause type.
Celui que le contrat désigne : nous n'avons trouvé aucun texte qui le fixe pour un contrat de développement entre entreprises. La clause type de l'ANSSI met la restitution des logiciels et de la documentation aux frais du prestataire sortant, sans chiffrer l'assistance à la migration. Le règlement européen sur les données limite aux coûts directs, puis interdit à partir du 12 janvier 2027, les frais de changement de fournisseur des services en nuage, mais il en écarte les services conçus pour l'essentiel sur mesure pour un client et absents du catalogue du fournisseur. Écrivez donc au contrat ce que la sortie comprend, le prix de l'assistance et qui paie selon la cause de la rupture.
Relisez d'abord la clause de réversibilité du contrat, s'il en a une. Demandez un export complet et vérifiez qu'il s'ouvre avant de couper les accès de l'ancien prestataire. Le RGPD prévoit qu'au terme de la prestation, le sous-traitant renvoie ou supprime les données personnelles, au choix du client : demandez le renvoi d'abord, la suppression ensuite. Et restaurez une sauvegarde avant la bascule.
Pas le client, par défaut. Commander un logiciel à un prestataire externe ne transfère pas les droits : il faut un contrat de cession, ou au minimum une clause de cession. Pour un salarié, c'est l'inverse : le logiciel écrit dans le cadre de ses fonctions appartient à l'employeur. Chez OTTOPILOTE, le code source est transféré au client à la livraison, une fois le projet réglé.
Relisez le contrat, puis faites une demande écrite avec la liste précise des comptes et une date. Ce qui est déjà à votre nom se récupère auprès du fournisseur lui-même : pour un nom en .fr dont vous êtes titulaire, le bureau d'enregistrement doit vous fournir le code de transfert (AUTH_INFO). Pour le reste, un avocat tranche mieux qu'un développeur.
Oui, si le logiciel se reconstruit depuis son code source et si les droits sont à vous. La documentation s'écrit alors pendant la reprise, à partir du code, de la production et d'un entretien avec l'ancien prestataire. Sans code source ni production accessible, c'est une reconstruction.
Vérifiez d'abord ce qui ne demande l'accord de personne : le titulaire de votre nom de domaine, le contrat signé, les comptes déjà à votre nom. Annoncez ensuite, et demandez l'entretien de passation tant que la relation permet encore de poser des questions.
