Guides, publié le , 6 min de lecture
Reprendre un logiciel développé par un autre prestataire
Les étapes pour reprendre en main un logiciel métier quand le prestataire d’origine n’est plus là, sans interrompre votre activité ni perdre vos données.
Le freelance a changé de métier, l’agence a fermé ou ne répond plus, le développeur interne est parti. Le logiciel, lui, continue de faire tourner une partie de votre activité. Voici comment le reprendre en main de façon ordonnée.
Étape 1 : récupérer ce qui vous appartient
Avant toute chose, rassemblez :
- le code source, idéalement avec son historique (dépôt Git) ;
- les accès à l’hébergement, au nom de domaine, à la base de données et aux services tiers (envoi d’e-mails, paiement, API) ;
- les sauvegardes et l’endroit où elles sont stockées ;
- le contrat signé avec le prestataire, pour vérifier ce qu’il prévoit sur la propriété et la remise du code.
Si le code n’est pas accessible, vérifiez s’il est présent sur le serveur d’hébergement. Pour une application web en PHP, c’est souvent le cas. Pour un logiciel compilé (WinDev, Delphi), il faut retrouver les sources.
Étape 2 : sécuriser avant de modifier
La première intervention n’ajoute aucune fonctionnalité. Elle consiste à :
- faire une sauvegarde complète et vérifier qu’elle se restaure ;
- placer le code sous gestion de versions s’il ne l’est pas ;
- créer une copie de test, séparée de la production ;
- corriger les failles de sécurité évidentes.
Tant que ces quatre points ne sont pas faits, toute modification est un risque pour votre activité.
Étape 3 : établir un diagnostic
Un diagnostic de reprise répond à des questions simples :
- Sur quelles versions de langage et de framework le logiciel repose-t-il, et sont-elles encore maintenues ?
- Quelles parties du code sont saines, lesquelles sont fragiles ?
- Où sont les règles métier importantes, et sont-elles compréhensibles ?
- Quels risques pèsent sur l’activité à court terme ?
Le résultat doit être un document écrit, avec des risques classés et des options chiffrées.
Étape 4 : documenter ce que fait le logiciel
Un logiciel repris sans documentation reste dépendant de la personne qui l’a repris. Nous documentons au minimum le rôle de chaque module, la procédure de déploiement, l’emplacement des données et les règles de calcul essentielles.
Étape 5 : décider entre maintenir, moderniser ou réécrire
| Option | Quand la choisir |
|---|---|
| Maintenir | Le code est sain, la technologie encore maintenue, les besoins stables. |
| Moderniser par étapes | Le socle est ancien mais les règles métier sont bonnes : on monte de version ou on réécrit module par module. |
| Réécrire | Le code est trop fragile ou la technologie n’est plus viable, et une migration progressive coûterait plus cher. |
La réécriture complète est rarement le premier choix. Elle fait courir le risque de perdre des règles métier que personne n’avait notées. Pour les applications WinDev et Delphi, la migration progressive vers le web est souvent la voie la plus sûre.
Étape 6 : éviter de revivre la situation
- Exigez l’accès permanent au dépôt de code, à votre nom.
- Conservez vous-même les accès à l’hébergement et au nom de domaine.
- Prévoyez un contrat de maintenance applicative qui inclut la documentation.
- Faites tenir à jour le langage et le framework, pour ne pas accumuler une dette technique qui rend la prochaine reprise plus coûteuse.
Par où commencer
Si votre logiciel est dans cette situation, le premier pas est le diagnostic. Demandez un diagnostic technique : nous vous dirons ce qui peut être conservé et ce que coûteraient les différentes options.