Entreprise de reprise de code : reprendre en main un logiciel existant

Qu’est-ce que la reprise de code ?

Reprendre du code, c’est devenir responsable d’un logiciel qu’on n’a pas écrit. Le logiciel tourne déjà et sert votre activité : il ne s’agit pas de repartir de zéro, mais de retrouver la capacité de le faire fonctionner, de le corriger et de le faire évoluer sans risque. Une reprise commence par les accès et l’état des lieux, continue par la mise en sécurité de la production, puis par des évolutions livrées par petits lots.

Le mot recouvre plusieurs prestations que l’on confond souvent. Le tableau ci-dessous les distingue : une reprise de code peut déboucher sur l’une ou plusieurs d’entre elles, selon ce que montre l’audit.

Quand faire appel à une entreprise de reprise de code ?

Le cas le plus fréquent : le prestataire, l’agence ou le développeur freelance qui a construit le logiciel n’est plus là. L’agence a fermé, le freelance ne répond plus, l’associé technique est parti, ou la relation s’est arrêtée. Le logiciel fonctionne encore, mais plus personne ne sait comment le déployer, ni ce qui casse si l’on touche à quoi.

La reprise se justifie aussi sans départ de prestataire, quand la dette technique paralyse le produit : chaque évolution coûte plus cher que la précédente, les mêmes défauts reviennent, une mise à jour de sécurité est repoussée depuis des mois parce qu’elle risque de tout casser. Ces signaux justifient une reprise de code, pas forcément une reconstruction. Le premier besoin est de distinguer les risques immédiats des irritants qui peuvent attendre.

• Prestataire, agence ou freelance parti, défaillant ou injoignable
• Évolutions bloquées par la peur de casser la production
• Défauts qui reviennent après chaque mise à jour
• Dépendances ou versions plus maintenues, failles de sécurité connues non corrigées
• Sauvegardes, hébergement et déploiement que personne ne sait décrire
• SaaS devenu difficile à faire évoluer : réusinage de code nécessaire
• Logiciel hérité après le rachat d’une société ou d’une activité
• Application construite très vite (outil no-code, code généré par IA) qu’il faut fiabiliser

Quels logiciels une agence de reprise de code peut-elle reprendre ?

Nous intervenons sur des logiciels déjà en production. Nous lisons le code avant de nous engager, et si sa technologie sort de nos compétences ou si le code n’est pas récupérable, nous vous le disons à l’audit, pas au troisième mois.

• Application web ou mobile développée par une agence ou un freelance
• SaaS en production à faire évoluer ou à fiabiliser
• Logiciel interne devenu difficile à maintenir
• Application construite avec un outil no-code ou du code généré par IA, à fiabiliser
• Logiciel hérité après le rachat d’une société ou d’une activité

Choisir une agence de reprise de code : les bonnes questions

Une agence de reprise de code doit lire votre code avant de chiffrer quoi que ce soit. Proposer de tout réécrire est la réponse la plus rapide à donner, et la plus chère à payer. Un bon repreneur vous explique ce qu’il a vu, ce qu’il ignore encore, et ce que coûte chaque option. Il ne doit pas non plus créer la dépendance dont vous essayez de sortir.

Voici les questions à poser à toute entreprise de reprise de code, nous compris. Notre guide Freelance ou agence de développement ? aide à comparer les deux types de prestataires.

• L’audit est-il vendu séparément, sur un périmètre fermé, avec un rapport qui vous reste même si vous continuez ailleurs ?
• Le repreneur dit-il clairement ce qu’il n’a pas pu vérifier ?
• Le code produit sera-t-il sur votre dépôt, et les comptes (hébergement, domaines, stores) à votre nom ?
• Y a-t-il une licence, un frais de sortie ou une maintenance imposée ? Chez nous : non.
• Qui lit le code et qui le maintiendra ensuite ? La même équipe, de préférence.
• Comment le service reste-t-il ouvert pendant les travaux ?

L’audit de code avant reprise : ce que nous regardons

L’audit examine le code et tout ce qui le fait tourner. Il sépare ce qui peut être conservé de ce qui mérite une réécriture, avec les raisons. La dette technique est découpée en lots chiffrés en jours et ordonnée par risque et par valeur métier. Vous recevez un plan exploitable même si vous faites réaliser la suite ailleurs.

Un audit n’efface pas toute incertitude : certaines parties ne deviennent compréhensibles qu’en observant le logiciel en usage. Le cadrage comprend donc une journée sur place avec les utilisateurs, qui met en regard le fonctionnement attendu, les données réelles et ce que fait le code aujourd’hui. Cette comparaison évite de qualifier de « bug » une règle métier inhabituelle, ou de conserver une anomalie sous prétexte qu’elle existe depuis longtemps.

• Le dépôt : historique, branches, ce qui est réellement en production
• La construction et le déploiement : peut-on reconstruire et livrer le logiciel aujourd’hui, sans l’ancien prestataire ?
• Les dépendances : versions, composants abandonnés, failles connues
• L’architecture : comment les parties s’appellent, où sont les règles métier
• Les données : schéma de la base, qualité, doublons, volumes
• Les sauvegardes : existent-elles, et a-t-on déjà réussi à restaurer ?
• La sécurité : gestion des accès, mots de passe et clés techniques, données personnelles
• Les tests et la supervision : ce qui prévient d’une panne, ce qui protège d’une régression
• Les coûts d’exploitation : hébergement, services tiers, abonnements en cours

Les étapes d’une reprise de code et leurs délais

Une reprise suit toujours le même ordre : on ne fait pas évoluer un logiciel qu’on ne sait pas encore redéployer. Les délais dépendent surtout de ce que vous pouvez fournir au départ. La durée de l’audit est annoncée avant de commencer, sur un périmètre fermé ; le calendrier des travaux suivants se fixe à partir de ce qu’il a trouvé, lot par lot.

1. Premier échange : vous décrivez le logiciel, son usage et ce que vous n’osez plus modifier
2. Récupération des accès : dépôt, hébergement, base de données, domaines, comptes tiers
3. Audit de code et journée sur place avec les utilisateurs, puis rapport écrit
4. Mise en sécurité : sauvegardes vérifiées par une restauration, correctifs urgents, supervision
5. Réusinage, corrections et évolutions par lots, chacun testé et documenté
6. TMA : maintenance et évolutions dans la durée, ou transfert à votre équipe

Checklist : ce qu’il faut récupérer avant la reprise

Une reprise se passe bien quand ces éléments sont réunis dès le début. S’il en manque, ils deviennent la première tâche de l’état des lieux, avant tout développement. Demandez-les par écrit à l’ancien prestataire, et vérifiez au nom de qui chaque compte est ouvert : un compte au nom du prestataire est un risque, même s’il fonctionne aujourd’hui. Le guide Reprendre le code d’un prestataire détaille la marche à suivre.

Réusinage de code SaaS : faire évoluer un SaaS sans tout casser

Le réusinage de code (refactoring) consiste à réorganiser une partie du logiciel pour la rendre plus facile à faire évoluer, sans changer ce que les utilisateurs en attendent. Sur un SaaS, il faut en plus protéger les données de chaque client, les abonnements et les accès pendant l’opération : une erreur ne touche pas un utilisateur, mais tous vos clients à la fois.

Nous procédons par lots lisibles. Avant de toucher une partie, nous posons des tests sur les parcours critiques (connexion, facturation, saisies importantes) pour savoir immédiatement si quelque chose a changé. Les montées de version se font une par une, en commençant par celles qui exposent la production. Chaque lot est livré, vérifié, puis documenté avant le suivant.

Ces travaux n’ont de valeur que s’ils répondent à un risque ou à un besoin identifié : une partie du code qui ralentit chaque évolution, une dépendance qui n’est plus maintenue, un traitement fragile. Nous éditons et exploitons notre propre SaaS, Trackary, et connaissons ces contraintes de l’intérieur. Pour un SaaS à construire ou à étendre, voir aussi Développement SaaS B2B.

• Signe qu’un réusinage est utile : une petite évolution touche des fichiers partout
• Signe qu’un réusinage est utile : personne n’ose mettre à jour le framework
• Signe qu’un réusinage est utile : les mêmes calculs sont codés à plusieurs endroits, avec des résultats différents
• Ce qu’il ne doit pas faire : changer le comportement sans que vous l’ayez décidé

Reprise progressive ou refonte complète ?

Une refonte de logiciel existant ne commence pas par éteindre ce qui sert encore. Nous regardons d’abord les sauvegardes, la restauration, les correctifs urgents et la supervision, puis nous stabilisons les incidents qui gênent réellement les équipes. Si une réécriture s’impose, elle se fait de préférence par morceaux, avec une bascule préparée et un service qui continue de fonctionner pendant la transition.

Tout réécrire paraît plus simple sur un schéma, mais oblige à redécouvrir des exceptions accumulées dans l’usage et à déplacer d’un coup les données et les habitudes. À l’inverse, conserver chaque élément ancien à tout prix peut immobiliser le produit. La décision porte sur chaque partie du système : conserver, corriger, isoler ou remplacer. Si vous préférez remplacer le logiciel par un outil neuf plutôt que le reprendre, voir logiciel métier sur mesure.

Après la reprise : TMA et évolutions

La TMA (tierce maintenance applicative) est le contrat qui suit la reprise : correction des anomalies, mises à jour de sécurité et de versions, surveillance des sauvegardes, et évolutions fonctionnelles au fil des besoins. Une TMA sérieuse commence par une reprise : on ne s’engage pas sur des délais de correction pour un logiciel qu’on n’a pas lu.

Le périmètre de maintenance est distinct de la reprise et choisi selon vos besoins : rien ne vous oblige à le prendre chez nous. Si vous préférez réinternaliser le logiciel, la documentation produite pendant la reprise et un temps de passation avec votre équipe font partie du plan. Une TMA qui vous rendrait dépendant d’un seul fournisseur reproduirait le problème qui vous amène ici.

• Maintenance corrective : les anomalies signalées sont analysées et corrigées
• Maintenance préventive : mises à jour, sauvegardes vérifiées, supervision
• Maintenance évolutive : nouvelles fonctions, livrées par lots
• Réversibilité : documentation à jour et passation possible à tout moment

Combien coûte une reprise de code ?

Une reprise de code est chiffrée sur devis, après audit. Le coût dépend de l’accès réel au code et aux environnements, du volume de données, de l’état des sauvegardes, des incidents à traiter et du périmètre d’évolution souhaité. Il faut séparer l’audit du travail qui en découle : sans diagnostic, un devis de refonte donne une impression de précision trompeuse. Le cadrage est facturé séparément et son résultat vous appartient. Notre guide Combien coûte un logiciel sur mesure ? explique les facteurs de chiffrage, et Combien coûte un SaaS ? les coûts d’exploitation d’un logiciel en ligne.

Pour le travail que nous réalisons, le code rejoint votre dépôt dès le premier commit et les comptes tiers restent à votre nom. Aucune licence, aucun frais de sortie, aucune maintenance imposée. Cette liberté compte particulièrement dans une reprise : le problème initial vient souvent d’une dépendance à un prestataire devenue difficile à dénouer.

Pourquoi confier la reprise de votre code à The Level Code

THE LEVEL CODE est un studio de développement logiciel installé à Lille (The Level Code SASU, présidée par Romain Nivelle). Nous développons des logiciels métier, des applications web et mobiles et des SaaS, et nous éditons notre propre logiciel en production, Trackary. Reprendre un logiciel, pour nous, c’est appliquer à votre code les exigences que nous appliquons au nôtre : sauvegardes restaurées pour de vrai, déploiements reproductibles, historique conservé.

Nous intervenons à Lille, dans la métropole lilloise et partout en France : la journée de cadrage se fait sur place, l’audit et les travaux à distance. Si le code n’est pas récupérable ou si sa technologie sort de nos compétences, nous vous le disons à l’audit, et non au troisième mois. Pour le détail de notre façon de travailler, voir la page Méthode.