En bref : reprendre un logiciel développé par un autre prestataire est tout à fait possible, à condition de commencer par un audit du code et de récupérer les accès (code source, serveurs, comptes). Un prestataire sérieux passe par une phase de prise en main avant de modifier quoi que ce soit, pour éviter de casser l’existant et pour chiffrer la suite de façon réaliste.
Un prestataire injoignable, une société qui ferme, un développeur qui part : il arrive un moment où il faut confier à quelqu’un d’autre un logiciel qu’on n’a pas fait construire soi-même. C’est une situation courante et gérable. Voici comment une reprise se déroule, et les points à sécuriser avant de changer d’équipe.
- Dans quels cas reprend-on un logiciel existant ?
- Peut-on vraiment reprendre le code de quelqu’un d’autre ?
- Les documents et accès à récupérer
- Les étapes d’une reprise réussie
- Les risques à surveiller
- Combien de temps avant de pouvoir faire évoluer le logiciel ?
- Questions fréquentes
Dans quels cas reprend-on un logiciel existant ?
Les motifs sont presque toujours les mêmes. Le prestataire d’origine ne répond plus, ou a cessé son activité. Les délais et les tarifs ne conviennent plus. Le développeur interne qui maîtrisait l’outil est parti. Ou simplement, le logiciel doit évoluer et l’équipe en place n’a plus les compétences nécessaires. Dans tous ces cas, le besoin est le même : retrouver la main sur un outil dont dépend parfois toute une activité.
Peut-on vraiment reprendre le code de quelqu’un d’autre ?
Oui, dans la très grande majorité des cas. Un logiciel, même mal documenté, reste lisible par des développeurs expérimentés. La difficulté n’est pas de comprendre le code en lui-même, mais de reconstituer les intentions derrière : pourquoi telle règle de gestion, quelle logique pour tel calcul. C’est le rôle de la phase d’audit. La seule vraie condition bloquante serait de ne pas disposer du code source. Avec le code en main, une reprise est quasiment toujours faisable.
Les documents et accès à récupérer
Avant toute chose, rassemblez ce qui permettra au nouveau prestataire de travailler. Sans ces éléments, la reprise démarre à l’aveugle.
- Le code source complet et son historique de versions s’il existe.
- Les accès serveurs et bases de données (hébergement, comptes d’administration).
- Les comptes liés aux services externes utilisés par le logiciel (paiement, envoi d’e-mails, cartographie, etc.).
- La documentation disponible, même partielle : schémas, procédures, identifiants techniques.
- Les éventuels contrats précisant à qui appartiennent le code et les droits.
Si certains de ces éléments manquent, tout n’est pas perdu, mais il faut le savoir au départ : cela change le temps de prise en main et le chiffrage.
Les étapes d’une reprise réussie
Une reprise sérieuse ne commence jamais par modifier le code. Elle commence par le comprendre. La première étape est un audit du code source : qualité, sécurité, dépendances obsolètes, zones à risque. Vient ensuite la mise en place d’un environnement de test, pour pouvoir expérimenter sans toucher à la production. Puis une première intervention simple et sans danger, qui sert à valider que l’équipe maîtrise bien l’ensemble. Ce n’est qu’après que l’on planifie les évolutions attendues, avec un chiffrage désormais fondé sur une connaissance réelle du logiciel.
Les risques à surveiller
Trois risques reviennent souvent. Le premier est la dette technique accumulée : un code vieillissant, des bibliothèques plus maintenues, des choix dépassés qui compliquent chaque modification. Nous détaillons ce sujet dans notre article sur la manière d’éliminer la dette technique. Le deuxième est l’absence de tests automatisés : sans eux, chaque changement peut casser une fonction ailleurs sans que personne ne s’en aperçoive avant la mise en production. Le troisième est la dépendance à des éléments non documentés, comme un script lancé manuellement chaque mois, dont plus personne ne connaît l’existence.
Un audit applicatif en amont met ces risques en lumière, plutôt que de les découvrir au pire moment. C’est l’objet de notre guide sur l’audit applicatif.
Combien de temps avant de pouvoir faire évoluer le logiciel ?
Pour un logiciel de taille moyenne, la phase de prise en main et d’audit demande en général de 2 à 4 semaines. À l’issue, le nouveau prestataire peut traiter les correctifs urgents et planifier les évolutions avec un chiffrage fiable. Vouloir sauter cette étape pour gagner quelques jours est un mauvais calcul : c’est exactement là que se préviennent les régressions coûteuses.
Questions fréquentes
Faut-il l’accord de l’ancien prestataire pour reprendre le logiciel ?
Pas pour travailler sur le code si vous en détenez les droits et le code source. Une passation documentée reste préférable, mais une reprise se fait très bien sans la coopération de l’équipe précédente.
Et si je n’ai pas le code source ?
C’est le point le plus sensible. Il faut d’abord tenter de le récupérer auprès de l’ancien prestataire ou de l’hébergeur. À défaut, une reconstruction partielle est parfois nécessaire, ce qui change l’ampleur du projet.
La reprise coûte-t-elle plus cher qu’un développement neuf ?
Rarement. Conserver l’existant et ses données est généralement plus économique que tout refaire. L’audit initial permet de trancher au cas par cas.
Le logiciel peut-il continuer à tourner pendant la reprise ?
Oui. La prise en main se fait sur un environnement de test, sans interrompre la production. Les utilisateurs continuent de travailler normalement.
Comment éviter de se retrouver à nouveau coincé plus tard ?
En exigeant dès le départ le code source, une documentation à jour et des tests automatisés. Ces trois éléments garantissent que le logiciel restera reprenable par une autre équipe si besoin.
Un logiciel à reprendre, un prestataire qui ne répond plus ? Demandez un audit de reprise : nous évaluons l’état du code et des accès, puis nous vous disons clairement ce qui est faisable et à quel rythme.
