Reprise d’application existante : reprendre la main sur un outil dont vous dépendez

Votre entreprise fonctionne avec un logiciel développé il y a des années, et la situation s’est dégradée : le prestataire ne répond plus ou facture chaque question, les évolutions prennent des mois, personne ne sait précisément où se trouve le code ni qui détient les accès. Cette page explique comment se déroule une reprise, ce qui est récupérable, ce qui ne l’est pas, et comment éviter que la situation se reproduise.

Les situations que nous reprenons

• Prestataire silencieux ou disparu. Les demandes restent sans réponse, l’entreprise a fermé, ou le développeur indépendant est passé à autre chose. L’outil tourne, mais plus personne ne peut le modifier.
• Code jamais remis. L’application fonctionne, elle a été payée, mais le code source et les accès serveur n’ont jamais été transmis. Le système est fermé, et toute évolution passe par un seul interlocuteur.
• Application vieillissante. Technologies qui ne sont plus maintenues, incompatibilités qui apparaissent à chaque mise à jour de navigateur ou de système, avertissements de sécurité.
• Outil interne devenu critique. Développé en interne ou par un stagiaire il y a des années, sans documentation, il porte aujourd’hui une part importante de l’activité — et personne n’ose y toucher.
• Rachat ou changement de direction. Vous héritez d’un système que vous n’avez pas choisi et dont vous devez évaluer la valeur et le risque.

Les trois vérifications à faire cette semaine

Indépendamment de tout projet, si vous êtes dans l’une de ces situations, trois vérifications simples réduisent immédiatement votre exposition. Vous pouvez les mener seul.

1. Avez-vous une sauvegarde, et a-t-elle déjà été restaurée ? Une sauvegarde jamais testée n’en est pas une. Demandez où elle se trouve, à quelle fréquence elle est faite, et si quelqu’un a déjà vérifié qu’elle se restaure.

2. Qui détient les accès ? Nom de domaine, hébergement, base de données, certificats, comptes administrateurs. Si la réponse est « le prestataire », votre outil ne vous appartient pas en pratique, quel que soit le contrat.

3. Pouvez-vous obtenir un export complet de vos données ? Aujourd’hui, dans un format lisible. Si ce n’est pas possible, c’est le point le plus urgent à traiter.

L’état des lieux : ce qu’on regarde

Une reprise commence toujours par un diagnostic, jamais par du développement. L’objectif est d’établir des faits, pas de vendre une refonte.

Accès et propriété

Ce qui est réellement en votre possession : domaine, hébergement, code, base, comptes.

Nature du code

Technologies employées, versions, si elles sont encore maintenues, présence de dépendances obsolètes ou vulnérables.

Documentation

Ce qui existe, ce qui manque, ce qui devra être reconstitué par lecture du code.

Données

Structure de la base, volumétrie, qualité, sauvegardes disponibles et restaurables.

Sécurité

Mots de passe stockés correctement ou non, échanges chiffrés, failles connues des composants utilisés, exposition inutile de services.

Fragilités

Points de rupture : serveur unique, certificat expirant, dépendance à un service tiers arrêté, tâches manuelles indispensables.

Usage réel

Ce que les équipes utilisent vraiment — souvent une fraction de ce qui a été développé.

Ce diagnostic produit un document lisible par un dirigeant, pas un rapport technique : ce qui est réutilisable, ce qui doit être repris d’urgence, ce qui peut attendre, et ce qu’il coûterait de ne rien faire.

Le volet juridique : à qui appartient le code

C’est le point qui surprend le plus de dirigeants. En droit français, le fait d’avoir payé un développement n’emporte pas automatiquement la cession des droits sur le code. Sauf clause écrite de cession, l’auteur conserve ses droits patrimoniaux : vous avez payé une prestation, pas nécessairement acquis un actif.

Concrètement, avant toute reprise, il faut examiner le contrat d’origine, le devis ou les conditions générales, et chercher une clause de cession de droits, une mention de remise des sources, ou à défaut une licence d’utilisation. Trois cas se présentent. Si la cession est écrite, la récupération du code est un droit que vous pouvez faire valoir. Si rien n’est prévu, une négociation reste souvent possible — de nombreux prestataires acceptent de remettre les sources contre un règlement raisonnable. Si le prestataire est introuvable ou l’entreprise liquidée, la situation est plus délicate et mérite l’avis d’un avocat spécialisé.

Nous ne sommes pas juristes et ne délivrons pas de conseil juridique : notre rôle est d’établir l’état technique et de vous indiquer précisément quels documents rassembler avant de consulter, le cas échéant, un professionnel du droit.

Sécurisation immédiate

Avant toute évolution, l’objectif est que l’activité ne soit plus suspendue à un incident. Cette phase est courte et produit un effet immédiat.

• Sauvegardes reprises en main : mise en place si elles n’existent pas, et surtout test de restauration réel sur un environnement séparé.
• Accès repris et documentés : comptes à votre nom, mots de passe renouvelés et consignés dans un coffre, suppression des accès obsolètes.
• Correctifs bloquants : traitement des vulnérabilités exploitables et des expirations imminentes — certificats, noms de domaine, services tiers.
• Environnement de test : une copie du système sur laquelle travailler sans risquer la production.
• Documentation minimale : de quoi permettre à un autre intervenant de reprendre le dossier.

Reprendre, moderniser ou reconstruire

C’est la vraie question, et la réponse honnête dépend de l’état du code et de vos priorités. L’état des lieux existe précisément pour la trancher sur des faits.

Il arrive que la conclusion soit de ne presque rien toucher : sécuriser, documenter, maintenir, et consacrer le budget à autre chose. C’est un résultat parfaitement acceptable d’un diagnostic.

Comprendre la dette technique sans être informaticien

La dette technique est l’écart accumulé entre l’état du logiciel et ce qu’il devrait être pour évoluer sereinement. Elle n’est pas visible à l’écran, mais elle se mesure à un symptôme très concret : chaque modification coûte plus cher que la précédente, et casse quelque chose ailleurs.

Trois signaux permettent de l’évaluer sans compétence technique. Le délai des petites demandes — si changer un libellé prend une semaine, la dette est élevée. La peur de toucher — quand plus personne n’ose modifier une partie du système, elle est déjà hors de contrôle. Les régressions — si corriger un point en casse un autre, l’absence de tests automatisés rend toute évolution risquée.

Une dette élevée n’impose pas la reconstruction. Elle impose de la mesurer avant de s’engager, car elle détermine directement le coût de chaque évolution future.

Ce qui fait varier le budget

• La disponibilité du code et des accès — le facteur le plus déterminant.
• L’âge et la nature des technologies, et l’existence de compétences disponibles pour les maintenir.
• La qualité de la base de données, souvent la partie la plus précieuse et la plus récupérable.
• Le volume de fonctionnalités réellement utilisées — reconstruire l’usage réel coûte souvent moins que maintenir l’ensemble.
• L’urgence : une sécurisation immédiate est un chantier court ; une modernisation se planifie.

Une reprise se découpe naturellement : l’état des lieux est un livrable autonome, chiffré et limité, à l’issue duquel vous décidez en connaissance de cause. Vous n’êtes pas engagé sur la suite.

Après la reprise : ne pas refaire la même erreur

Une reprise n’a de sens que si elle empêche la situation de se reproduire. Quatre points doivent être acquis à la fin : un dépôt de code dont vous avez la maîtrise, une documentation permettant à un tiers de reprendre le dossier, des accès d’hébergement à votre nom, et une procédure de sauvegarde et de restauration testée. Ces quatre éléments constituent votre indépendance réelle ; le reste relève de la relation commerciale.

Si, à l’issue du diagnostic, la reconstruction s’impose sur tout ou partie du système, la démarche rejoint celle décrite sur la page logiciel métier sur mesure, avec l’avantage considérable de partir d’un existant qui documente vos règles de gestion réelles.

Questions fréquentes