Comment savoir que vous êtes dans cette situation ?
Les messages restent sans réponse depuis trois semaines. Le freelance qui a développé votre plateforme a changé de métier, l'agence a fermé, ou le projet s'est arrêté après un désaccord sur une facture. L'application tourne encore, mais une mise à jour du store est bloquée, un paiement échoue, et vous constatez que le nom de domaine, l'hébergement et le compte développeur sont au nom du prestataire.
Les situations typiques :
- le code source n'a jamais été livré, ou seulement une archive ancienne ;
- les accès d'administration (hébergement, base de données, stores, paiement, e-mails) sont détenus par le prestataire ;
- un projet resté à moitié fait, payé en grande partie, sans version utilisable ;
- une application en production, sans documentation, que personne n'ose toucher.
Le coût d'attendre est concret : un certificat qui expire coupe le site, une politique de store non respectée fait retirer l'application, une faille non corrigée expose vos données clients. Chaque semaine d'immobilité augmente le risque sans rien régler.
Les premières 48 heures : que faire tout de suite ?
- Dresser l'inventaire de tout ce dont dépend le logiciel : nom de domaine, hébergeur, base de données, dépôt de code, comptes Apple et Google, prestataire de paiement, envoi d'e-mails, services tiers. Pour chacun, notez qui est titulaire du compte.
- Récupérer ce qui est à votre nom : connectez-vous à tous les comptes dont vous êtes titulaire et changez les mots de passe. Retirez les accès des personnes qui ne doivent plus en avoir.
- Sauvegarder : export de la base de données, copie des fichiers déposés par les utilisateurs, téléchargement du code s'il est accessible quelque part.
- Relancer par écrit le prestataire, avec une liste précise des éléments demandés (code, accès, documentation), en vous appuyant sur votre contrat.
- Ne rien modifier en production tant que la sauvegarde n'est pas faite et vérifiée.
Pour les comptes détenus par le prestataire, les plateformes prévoient des procédures de transfert. Apple permet de transférer une application d'un compte développeur à un autre en conservant son identifiant, ses notes et ses avis, et les utilisateurs continuent de recevoir les mises à jour. Google Play transfère de même les utilisateurs, les notes et avis et la fiche de l'application. Dans les deux cas, c'est le titulaire du compte d'origine qui lance le transfert (chez Apple, le compte destinataire l'accepte ensuite) : d'où l'importance d'obtenir sa coopération, ou d'agir par voie contractuelle.
Que vérifie l'audit de reprise ?
Une fois le code et les accès récupérés, un audit dit ce que vaut réellement ce que vous avez payé. Il couvre :
| Axe | Question posée |
|---|---|
| Complétude | Le code récupéré correspond-il à la version en production ? Peut-on la reconstruire à l'identique ? |
| Sécurité | Secrets écrits en clair dans le code, dépendances avec failles connues, comptes administrateurs oubliés, données exposées |
| Dépendances | Versions des langages et des bibliothèques, composants qui ne sont plus maintenus |
| Qualité | Lisibilité, structure, présence de tests, duplication |
| Données | Modèle de données cohérent, sauvegardes en place, volumes |
| Écart fonctionnel | Ce qui était prévu au contrat, ce qui existe, ce qui marche vraiment |
L'audit aboutit à un document qui vous appartient, avec une recommandation argumentée, même si vous confiez ensuite la suite à quelqu'un d'autre.
Reprise, refonte progressive ou reconstruction ?
La décision dépend de l'audit, pas de la préférence du nouveau prestataire. Les trois voies sont décrites en détail sur notre page pour moderniser un logiciel ancien ; dans un contexte d'abandon, quelques spécificités :
- Reprise du code : justifiée quand le code est récent, lisible et écrit avec des technologies courantes. On sécurise, on documente, on ajoute des tests sur les parcours critiques, puis on reprend les évolutions.
- Refonte progressive : quand une partie est saine et l'autre non. On remplace les modules fragiles un par un, l'application reste en service.
- Reconstruction : quand le projet n'a jamais été terminé, que le code est inexploitable ou qu'une technologie de niche ne trouve plus de développeurs. Les données et les écrans existants servent alors de cahier des charges.
Un piège fréquent : vouloir terminer à l'identique un projet resté à mi-chemin. Le besoin a souvent évolué depuis le contrat initial. Le moment de la reprise est le bon pour reprendre le cadrage, sur la base de ce qui existe.
Ce que nous avons appris en reprenant des systèmes existants
Reprendre l'existant demande de la méthode plus que du talent. Sur le projet Cap Vert, nous avons repris un système d'information hérité (tableau de bord, base de données et applications terrain iOS et Android) sans arrêter l'activité : migration de MongoDB vers Supabase vérifiée champ par champ, synchronisation pendant toute la transition, bascule des équipes quand le client a donné son accord, et aucune donnée perdue sur les 10 000 enregistrements migrés.
Les principes qui en découlent : on ne supprime jamais une donnée pendant une migration, l'ancien système reste ouvert en consultation jusqu'à ce que le nouveau ait convaincu, et on bascule par étapes réversibles.
Pour éviter de revivre la situation, la reprise est aussi l'occasion de remettre les fondamentaux à votre nom : dépôt de code sur votre compte, comptes stores et hébergement au nom de votre entreprise, documentation, et un contrat qui écrit noir sur blanc la propriété du code et la réversibilité. Sur nos propres projets, le client devient propriétaire du code dès le paiement complet, et ce code, documenté, est déposé sur ses comptes ; le sujet est approfondi dans notre guide sur la propriété du code source et la réversibilité.
Quand la reprise n'est pas la bonne réponse
- Un logiciel du marché fait désormais le travail : si le besoin qui justifiait le développement est aujourd'hui couvert par un outil standard, migrer les données vers cet outil coûte souvent moins cher que reprendre le code.
- Le projet n'a plus d'utilisateurs : avant de reprendre, vérifiez que l'application sert encore. Il est parfois plus sage d'archiver les données et d'arrêter.
- Le prestataire est seulement débordé : un échange franc, avec un calendrier et une remise du code au fil de l'eau, peut suffire à relancer la collaboration.
- Le différend est d'abord juridique : si le prestataire retient le code en contrepartie d'une facture contestée, le sujet relève de votre avocat avant d'être technique.
Pour un premier diagnostic, décrivez la situation sur notre page devis : ce qui tourne, ce que vous avez récupéré, ce qui manque.
Questions fréquentes
- Le code de mon logiciel m'appartient-il si je l'ai payé ?
- Payer le développement ne suffit pas toujours : la propriété du code d'un logiciel développé par un prestataire dépend de ce que prévoient le contrat et les conditions générales sur la cession des droits. Relisez ces documents et faites-vous conseiller par un avocat en cas de doute. Chez YMHB Web, le client devient propriétaire du code une fois le paiement complet effectué, et le code est déposé sur ses comptes.
- Comment récupérer une application mobile publiée sur le compte du prestataire ?
- Apple et Google prévoient tous deux le transfert d'une application d'un compte développeur à un autre. Chez Apple, l'application garde son identifiant, ses notes et ses avis, et les utilisateurs continuent de recevoir les mises à jour. Chez Google Play, les utilisateurs, notes, avis et fiche sont transférés. Dans les deux cas, c'est le titulaire du compte d'origine qui doit lancer le transfert.
- Peut-on reprendre un logiciel sans aucune documentation ?
- Oui, un logiciel sans documentation peut être repris. La reprise commence par la lecture du code et de la base de données, complétée par des entretiens avec les utilisateurs quotidiens qui connaissent les règles métier. La documentation est rédigée au fil de l'audit et devient votre propriété, ce qui facilite toute reprise future.
- Combien de temps prend l'audit d'un logiciel abandonné ?
- La durée de l'audit d'un logiciel abandonné dépend de la taille du code, du nombre de technologies, de la présence ou non d'une documentation et de la facilité d'accès aux environnements. Elle est estimée après un premier examen du code. Le préalable est d'avoir récupéré le code et des accès en lecture : sans eux, l'audit se limite à ce qui est visible de l'extérieur.
- Que faire si le prestataire refuse de rendre le code et les accès ?
- Si le prestataire refuse de rendre le code et les accès, sécurisez d'abord ce qui est à votre nom et sauvegardez vos données. Envoyez ensuite une demande écrite précise, fondée sur votre contrat, puis consultez un avocat si elle reste sans effet. En parallèle, l'application peut être reconstruite à partir des données et de l'usage observé, si l'attente devient trop risquée.