En décembre 2024, sur le blog d'une agence nantaise, un dirigeant laisse ce commentaire public sous un article consacré à la reprise de logiciel : son prestataire a abandonné la version 2 de leur outil en cours de route, 80 centres travaillent avec ce logiciel tous les jours, et il ajoute cette phrase que je n'ai pas oubliée : « je tombe sur des agences qui utilisent la détresse du moment pour en profiter ». Ce commentaire est toujours en ligne sur le blog d'Oniti. Il résume mieux que n'importe quelle étude ce qui se joue quand on doit reprendre un logiciel développé par quelqu'un d'autre.
En bref
Reprendre un logiciel développé par un autre prestataire est presque toujours possible techniquement. Le vrai blocage est juridique : sans clause de cession de droits conforme, le code ne vous appartient pas. Vérifiez d'abord votre contrat et vos accès, faites auditer le code, puis seulement décidez entre reprise et refonte.
Le vrai blocage n'est pas le code, c'est votre contrat
Voici l'angle mort de presque tous les articles sur le sujet. On vous explique la dette technique, l'obsolescence des librairies, la couverture de tests. Tout cela compte. Mais quand un dossier de reprise capote, dans la majorité des cas que j'ai vus passer, ce n'est pas parce que le code était mauvais. C'est parce que le client n'était pas propriétaire de ce qu'il croyait avoir acheté.
Le droit français est net sur ce point, et il ne joue pas en votre faveur par défaut. L'article L131-3 du Code de la propriété intellectuelle exige que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession, et que le domaine d'exploitation soit délimité quant à son étendue, sa destination, son lieu et sa durée. Traduction pour un dirigeant : une facture intitulée « développement d'une application de gestion » ne vous transfère rien du tout. Sans clause de cession expresse et détaillée, le prestataire indépendant reste titulaire des droits patrimoniaux sur le code qu'il vous a livré.
La confusion vient souvent d'un régime voisin. L'article L113-9 du CPI, rappelé par l'Agence pour la Protection des Programmes, prévoit que les droits patrimoniaux sur un logiciel créé par un salarié dans l'exercice de ses fonctions sont dévolus automatiquement à l'employeur. Beaucoup de dirigeants en déduisent que la même logique s'applique à un prestataire externe. Elle ne s'applique pas. Le salarié, oui, automatiquement. Le prestataire, non, jamais sans contrat qui le dit noir sur blanc.
Cela veut dire qu'avant de faire chiffrer une reprise par qui que ce soit, vous avez un document à ressortir : votre contrat initial. S'il contient une clause de cession de droits conforme, vous êtes propriétaire, la suite n'est qu'une affaire technique. S'il n'en contient pas, vous avez un sujet à traiter avec votre ancien prestataire avant tout le reste, et probablement avec un avocat spécialisé en propriété intellectuelle. Aucune agence, la mienne comprise, ne peut trancher ce point à votre place.
Reprise ou refonte : ce ne sont pas des synonymes
Une fois la question de la propriété réglée, deux chemins s'ouvrent, et le vocabulaire compte parce qu'il engage des budgets et des calendriers très différents.
La reprise consiste à faire passer le logiciel existant, tel quel, entre les mains d'une nouvelle équipe. Le code reste, l'hébergement bascule, les utilisateurs ne voient rien changer. La refonte consiste à ne pas réutiliser le code et à redévelopper l'application. Captive résume bien l'arbitrage avec une image de rénovation : reprendre, c'est rénover une maison dont on ignore l'état des murs porteurs, on peut économiser beaucoup si les fondations sont saines et se ruiner si elles ne le sont pas. Refondre, c'est reconstruire, avec la question de savoir où logent les habitants pendant les travaux.
Un point mérite d'être dit franchement, parce qu'il explique une bonne partie des devis que vous allez recevoir. La même agence nantaise l'écrit sans détour : les prestataires qui acceptent une reprise sont rares, la règle du marché c'est plutôt la refonte, parce que s'approprier le code d'un autre prend du temps et laisse beaucoup d'inconnues. Quand on vous répond « il faut tout refaire » dans les cinq minutes, sans avoir ouvert le code, ce n'est pas un diagnostic. C'est un réflexe commercial. Un vrai diagnostic passe par un audit, et un audit ça se regarde avant de conclure.
Les quatre accès à récupérer avant de parler technique
Il existe une checklist très concrète que je fais faire à chaque fois, et qui n'a rien à voir avec le code lui-même. Quatre choses, dans cet ordre.
Le dépôt de code source, avec son historique complet. Pas une archive zip envoyée par mail, le dépôt Git avec ses commits, parce que l'historique raconte comment le logiciel a été construit et c'est souvent la seule documentation qui existe. Ensuite les accès d'hébergement et de base de données, en administrateur, à votre nom, sur un compte qui appartient à votre société. Ensuite le nom de domaine, dont on découvre régulièrement qu'il est enregistré au nom du prestataire et pas au vôtre. Enfin les comptes tiers : passerelle de paiement, service d'envoi d'e-mails, API externes, stockage de fichiers. Chacun de ces comptes est une dépendance qui peut couper le service du jour au lendemain.
Cette liste paraît évidente écrite comme ça. En pratique, quand un prestataire arrête son activité, c'est exactement là que ça coince, et c'est ce qui transforme un dossier calme en dossier d'urgence.
Ce que je regarde dans un audit de code hérité
Chez Pictogramaweb, nous éditons nos propres logiciels, Simply Spa, Simply Resa, Postwa, Geko, et nous avons cédé un outil métier destiné à des ophtalmologistes. Cette position change complètement le regard qu'on porte sur le code de quelqu'un d'autre, parce qu'on connaît les deux côtés de la passation.
Quand j'ouvre un projet hérité, je regarde d'abord si la base de données est cohérente, parce que c'est elle qui porte vos années de données métier et qu'elle survit à la plupart des refontes. Je regarde ensuite si les dépendances sont encore maintenues, si le framework est dans une version qui reçoit encore des correctifs de sécurité, et s'il existe des tests automatisés, même partiels. Je regarde enfin si le projet démarre sur une machine neuve en suivant les instructions fournies. Ce dernier point est le plus révélateur de tous. Un logiciel qu'on ne sait plus réinstaller est un logiciel qui ne tient que par l'hébergement où il tourne, et c'est un risque bien plus grave qu'une interface datée.
Ce que je n'ai pas envie de vous cacher, c'est que la reprise reste inconfortable pour l'agence qui la fait. Sur du code que nous avons écrit, nous donnons une estimation fiable en quelques minutes. Sur du code hérité, la première évolution demandée coûte toujours plus cher que la même évolution sur un projet maison, parce qu'il faut comprendre avant de toucher. C'est une réalité, elle joue dans votre budget, et vous devez l'entendre avant de signer plutôt qu'après.
Le comparatif de décision
| Situation constatée | Reprise | Refonte |
|---|---|---|
| Prestataire disparu, logiciel utilisé tous les jours, service à sécuriser vite | Oui, c'est la seule option réaliste à court terme | Non, trop long |
| Code lisible, framework encore maintenu, base de données propre | Oui, on reprend et on fait évoluer | Rarement justifié |
| Technologie en fin de vie, plus de correctifs de sécurité | Reprise temporaire pour tenir | Oui, à planifier |
| Besoin métier qui a changé, l'outil ne correspond plus | Non, on repartirait du mauvais pied | Oui, avec un cadrage neuf |
| Vous n'êtes pas propriétaire du code | Impossible tant que ce n'est pas réglé | Impossible à partir de l'existant |
Ce tableau montre une chose que le débat « reprise contre refonte » masque : les deux ne s'excluent pas dans le temps. Le schéma le plus sain est souvent séquentiel. On reprend d'abord pour arrêter l'hémorragie, on stabilise, on prend le temps de regarder, et on décide de la refonte ensuite, en connaissance de cause, module par module. Refondre sous le coup de la panique, c'est reproduire l'erreur qui vous a menés là.
Comment se protéger pour la prochaine fois
Il y a une leçon utile à tirer de tout ça, et elle concerne votre prochain contrat plus que le précédent. Trois exigences suffisent à éviter 90 % des dossiers de reprise douloureux.
Exigez une clause de cession de droits explicite, conforme à l'article L131-3, qui liste les droits cédés et leur étendue. Exigez que tous les comptes techniques, dépôt de code, hébergement, domaine, services tiers, soient créés au nom de votre société et que le prestataire y soit invité, jamais l'inverse. Exigez enfin que le code soit livré en continu sur un dépôt auquel vous avez accès, pas à la fin du projet. Un prestataire sérieux accepte ces trois points sans discuter, parce qu'ils ne lui coûtent rien. Celui qui les refuse vous dit quelque chose d'important sur la suite de votre relation.
C'est d'ailleurs la logique que nous appliquons sur nos propres projets de développement de logiciel sur mesure : le client est propriétaire, les accès sont à son nom, et si un jour il veut partir, il part avec tout. Une agence qui vous rend captif ne défend pas la qualité de son travail, elle compense sa faiblesse.
Le verdict
Reprendre un logiciel développé par un autre prestataire, c'est possible, et beaucoup plus souvent qu'on ne vous le dira. Mais l'ordre des opérations n'est pas celui qu'on croit. On ne commence pas par faire chiffrer du développement. On commence par vérifier qui possède le code, on récupère les quatre accès, on fait auditer l'existant, et alors seulement on arbitre entre reprise et refonte. Un dirigeant qui arrive avec son contrat en main et ses accès sécurisés transforme un dossier de crise en simple décision d'investissement.
Si vous êtes dans cette situation et que vous ne savez pas par où commencer, la meilleure chose à faire est de faire regarder le code par quelqu'un qui n'a pas intérêt à vous vendre une refonte immédiate. Nous pouvons en discuter et poser un diagnostic honnête avant que vous engagiez quoi que ce soit.
Pour aller plus loin sur le cadrage d'un projet, vous pouvez lire notre guide sur le cahier des charges d'une application métier, celui sur le temps nécessaire pour développer une application métier, et notre comparatif entre logiciel sur mesure et logiciel du marché. Si votre besoin porte sur un outil neuf plutôt que sur un existant, notre page logiciels sur mesure à Beauvais détaille notre façon de travailler.
Questions fréquentes
Suis-je propriétaire du logiciel que j'ai payé ?
Pas automatiquement. En droit français, la cession des droits sur un logiciel développé par un prestataire externe doit être expresse et détaillée dans le contrat, conformément à l'article L131-3 du Code de la propriété intellectuelle. Une facture ou un devis ne valent pas cession. Sans clause conforme, le prestataire reste titulaire des droits patrimoniaux sur le code.
Mon prestataire refuse de me donner le code source, que faire ?
Commencez par relire votre contrat pour vérifier si une clause de cession et de livraison du code existe. Si oui, mettez en demeure le prestataire de l'exécuter. Si non, la négociation reste possible mais votre position est faible et un avocat spécialisé en propriété intellectuelle est utile pour arbitrer. Ce point relève du conseil juridique, pas de l'agence de développement.
Reprendre un logiciel existant revient-il moins cher que le refaire ?
À court terme, oui, presque toujours, puisqu'on ne redéveloppe pas ce qui existe déjà. Sur la durée, l'arbitrage dépend de l'état du code : chaque évolution sur du code hérité demande plus de temps que sur du code écrit en interne, et si les fondations sont mauvaises, la reprise peut finir par coûter plus cher qu'une refonte assumée. Seul un audit permet de trancher.
Combien de temps faut-il pour reprendre un logiciel après un prestataire ?
Cela dépend de deux choses seulement : la disponibilité des accès et la lisibilité du code. Quand les accès sont complets et le projet réinstallable, la bascule d'hébergement et la sécurisation du service se traitent rapidement. Quand il faut reconstituer des accès perdus ou reverse-engineerer une installation non documentée, la phase de découverte devient le poste le plus long du projet.
Photo : Mohammad Rahmani sur Unsplash
