Qu'est-ce qu'une reprise de code ?
Une reprise de code consiste à prendre en charge une application développée par une autre équipe : auditer le code existant, identifier la dette technique, stabiliser la mise en production, documenter l'architecture, puis reprendre les évolutions. Le but est de redonner le contrôle du produit à son propriétaire.
Ce n'est pas une réécriture. Une réécriture jette le travail déjà payé et repart de zéro, avec des mois avant la première mise en production. Une reprise part de ce qui existe et fonctionne déjà. Nous ne proposons une réécriture partielle que sur les composants qui la justifient réellement, et nous le disons avant de commencer, pas au milieu du projet.
Est-ce que c'est votre situation ?
Cinq cas reviennent presque toujours. Si vous en reconnaissez un, une reprise est probablement la bonne réponse.
Votre développeur freelance ne répond plus
Le code est là, la personne qui l'a écrit n'est plus joignable. Personne ne sait comment déployer, ni ce qui casse si on touche à quoi.
Le courant ne passe plus avec votre agence
La relation est bloquée mais le produit doit continuer à vivre. Il faut organiser le transfert sans casser la production en cours de route.
Votre associé technique est parti
Le savoir est parti avec lui. L'application fonctionne, mais chaque évolution devient un risque parce que personne ne comprend plus les choix d'architecture.
Vous avez racheté une société et son logiciel maison
L'outil interne fait partie du deal. Vous héritez d'une base de code que vos équipes n'ont pas écrite et dont vous devez pourtant garantir la continuité.
L'application a été générée avec l'IA et personne ne sait la faire évoluer
Un prototype construit avec Lovable, Cursor, Replit ou Bolt a fini en production. Il marche, jusqu'au jour où il faut l'ouvrir à toute l'entreprise, le sécuriser ou simplement le modifier.
Ce que l'hébergement de plateforme ne couvre pas
Une application générée par une plateforme est généralement hébergée par cette même plateforme, via un abonnement de l'ordre de 15 à 25 dollars par mois et par application. Pour un outil que vous utilisez seul, c'est souvent le bon choix, et nous vous le dirons franchement. Trois choses changent la donne.
Le seuil de l'abonnement
À partir de 15 dollars par mois, un abonnement doit se justifier. Tant que l'outil sert une personne, le calcul est simple. Multiplié par le nombre d'applications et d'utilisateurs, il devient une ligne budgétaire que quelqu'un finira par questionner.
Le plafond au moment du déploiement
Les limites de la plateforme se font sentir dès que l'application sort de son usage individuel : tarification par application ou par siège, quotas, absence de gestion fine des droits, impossibilité de brancher votre annuaire d'entreprise. Ce qui suffisait pour une personne bloque à l'échelle d'une organisation.
La sécurité n'est pas fournie
L'hébergement vous donne une URL qui répond. Il ne vous donne pas une posture de sécurité : gestion des secrets, contrôle des accès, cloisonnement des données, journalisation, conformité RGPD. Sur une application qui ne contenait que vos propres données, l'enjeu était faible. Dès qu'elle touche aux données de vos clients ou de vos salariés, il ne l'est plus.
Et le code lui-même
Les problèmes qui n'apparaissent qu'en charge réelle sont les mêmes à chaque audit : requêtes N+1 qui écroulent les temps de réponse dès que le volume monte, logique dupliquée au lieu d'être factorisée, aucune couverture de tests, donc aucun moyen de modifier quoi que ce soit sans risque de régression.
Rien de tout cela n'est un reproche fait aux outils. Nous les utilisons aussi. C'est simplement la liste de ce qu'il faut avoir vérifié avant de déployer largement une application générée rapidement.
À qui appartient votre code source ?
C'est la première question que nous posons, avant même de regarder le code. Sans droit de modification sur les sources, une reprise est juridiquement impossible, et le sujet se règle avant la technique.
À vérifier avant toute reprise
- Le contrat prévoit une cession des droits sur le code produit, pas une simple licence d'utilisation.
- Vous avez un accès administrateur au dépôt Git, ou au minimum une archive complète de l'historique.
- Les comptes d'hébergement, de nom de domaine et de base de données sont à votre nom, pas à celui du prestataire.
- Les dépendances propriétaires et les clés d'API sont identifiées, avec leurs licences et leurs échéances.
Si un de ces points manque, nous vous aidons à le débloquer avant de chiffrer la reprise. C'est plus rapide que de le découvrir au milieu du projet.
Comment se déroule une reprise
Trois étapes, dans cet ordre. Chacune se termine par un livrable et une décision : vous pouvez vous arrêter à la fin de l'audit.
- 1
Audit du code existant
Nous lisons la base de code, nous cartographions l'architecture, nous mesurons la dette technique et nous listons les failles de sécurité. Livrable : un rapport qui dit ce qui est sain, ce qui est à reprendre, ce qui est à jeter, avec une estimation chiffrée pour chaque point. Deux à cinq jours selon la taille du projet.
- 2
Reprise technique
Nous remettons le projet en état de marche pour une équipe qui ne l'a pas écrit : environnement de développement reproductible, tests sur les parcours critiques, documentation de l'architecture, chaîne de déploiement automatisée. À la fin de cette étape, une modification n'est plus un pari.
- 3
Migration en production et évolutions
Nous reprenons l'hébergement sur une infrastructure que vous contrôlez, nous mettons en place la supervision et les sauvegardes, puis nous enchaînons sur les évolutions produit. À ce stade, nous sommes votre équipe de développement.
Combien coûte un audit de code ?
Nos prix sont publics. L'audit est forfaitaire, ce qui veut dire que vous connaissez le coût de la première étape avant de vous engager sur la suite.
| Prestation | Prix | Ce que vous obtenez |
|---|---|---|
| Audit de code | 2 500 € forfaitaires | Rapport d'audit complet : architecture, dette technique, sécurité, estimation chiffrée des travaux. Sans engagement sur la suite. |
| Reprise technique | à partir de 800 € par jour | Remise en état, tests, documentation, chaîne de déploiement. Le volume de jours sort de l'audit, il n'est pas estimé à l'aveugle. |
| Évolutions produit | à partir de 800 € par jour | Développement des nouvelles fonctionnalités, une fois le projet repris en main. |
Ce qui fait varier le nombre de jours
- La taille de la base de code et le nombre de services à reprendre.
- La couverture de tests existante. Sans tests, il faut en écrire avant de pouvoir modifier quoi que ce soit sans risque.
- L'âge des dépendances et du langage. Une version qui n'est plus supportée impose une montée de version avant tout le reste.
- L'état de la mise en production. Un déploiement manuel non documenté coûte plus cher à reprendre qu'une chaîne automatisée.
L'audit à 2 500 € est volontairement un engagement court. Si notre conclusion est qu'il ne faut pas reprendre le projet, nous vous le disons et vous repartez avec le rapport.
Questions fréquentes
Qu'est-ce qu'un audit de code ?
Un audit de code est un examen de la base de code d'une application par une équipe externe. Il porte sur l'architecture, la qualité du code, la couverture de tests, la sécurité et la dette technique. Il produit un rapport qui liste ce qui est sain, ce qui doit être corrigé et ce que chaque correction représente en charge de travail.
Combien coûte un audit de code ?
Chez Reflekt Lab, l'audit de code est forfaitaire à 2 500 €, pour une durée de deux à cinq jours selon la taille du projet. La reprise qui suit démarre à 800 € par jour, et le nombre de jours est estimé à partir des conclusions de l'audit, pas avant.
Faut-il tout réécrire ?
Presque jamais. Une réécriture complète jette du travail déjà payé et repousse la première mise en production de plusieurs mois. Dans la grande majorité des cas, la bonne réponse est de stabiliser l'existant, d'ajouter des tests sur les parcours critiques, puis de remplacer les composants problématiques un par un.
Peut-on reprendre une application développée avec Lovable, Cursor ou Replit ?
Oui, à condition de pouvoir exporter le code source. Les points d'attention habituels sur ces projets sont la sécurité, l'absence de tests, les requêtes non optimisées et la dépendance à l'abonnement de la plateforme d'origine. L'audit commence par vérifier que l'export est complet et exploitable.
À qui appartient le code source de mon application ?
Cela dépend de votre contrat. Une prestation de développement peut prévoir une cession des droits ou une simple licence d'utilisation. Sans droit de modification sur les sources, aucun autre prestataire ne peut légalement reprendre le projet. C'est le premier point à vérifier, avant même l'audit technique.
Que se passe-t-il si mon prestataire actuel ne répond plus ?
Nous pouvons travailler à partir de ce à quoi vous avez accès : le dépôt Git, une archive du code, ou dans les cas difficiles l'application déployée elle-même. Nous vous aidons aussi à récupérer les accès qui manquent, notamment l'hébergement et le nom de domaine, qui doivent être à votre nom.
Combien de temps prend une reprise de projet ?
L'audit prend deux à cinq jours. La reprise technique va généralement de deux à six semaines selon la taille du projet et l'état de la couverture de tests. Ces deux étapes sont séparées précisément pour que vous décidiez de la seconde avec un chiffrage, et non sur une estimation faite à l'aveugle.
Que contient le rapport d'audit ?
Une cartographie de l'architecture, un inventaire des dépendances et de leur état de support, la liste des failles de sécurité classées par gravité, la mesure de la couverture de tests, les points de rupture attendus en charge, et pour chaque problème une estimation en jours. Le rapport vous appartient, y compris si vous ne poursuivez pas avec nous.
Sur quelles technologies travaillez-vous ?
Principalement Go, Python, TypeScript et React, avec PostgreSQL, sur Kubernetes ou sur des plateformes managées. Nous auditons aussi des projets PHP, Symfony et Node.js. Si une technologie sort de notre périmètre, nous le disons avant de prendre la mission.
Que faire si l'application n'a aucun test ?
C'est le cas le plus fréquent, et cela ne bloque pas une reprise. La première tâche consiste à écrire des tests sur les parcours métier critiques, ceux dont une panne coûte de l'argent. Ils servent de filet de sécurité pour tout ce qui suit. C'est aussi le poste qui pèse le plus dans le nombre de jours estimé.
Une application dont vous avez perdu la main ?
Dites-nous ce qui s'est passé et quelles technologies sont en jeu. Nous vous dirons honnêtement si une reprise vaut le coup, et ce qu'elle représente.
