Votre prestataire est parti, ne suit plus, ou ne vous convient plus. Ou bien votre MVP a réussi et il faut en faire un vrai logiciel. Dans tous les cas, quelqu'un doit reprendre un code qu'il n'a pas écrit : c'est notre point de départ habituel.
Nous reprenons les projets là où ils en sont, avec méthode et sans repartir de zéro quand le code le permet. Quand la base n'est pas saine, nous vous expliquons pourquoi et vous proposons un plan d'action.
5
|
4,7
Ça vous parle ?
Les quatre raisons pour lesquelles un projet change de mains
Votre prestataire a disparu
Développeur indépendant parti, agence fermée, équipe interne dissoute : le logiciel tourne encore, plus personne ne répond. Le problème est d'abord un problème d'accès : dépôt, serveurs, nom de domaine, données.
Votre prestataire refuse, ou n'a plus la capacité
Il ne veut plus y toucher, il a doublé ses tarifs, ou il ne reste qu'une personne débordée. Le problème est un rapport de force, et il se règle en récupérant ce qui vous appartient.
Les régressions reviennent, les délais glissent, les choix techniques ne sont jamais expliqués. Le problème est une décision à prendre, et vous ne savez pas si votre exigence est légitime. Nous vous donnons des critères, pas un verdict.
Faut-il changer de prestataire ? →
Le projet a dépassé celui qui l'a démarré
Un MVP fait par un freelance, une première version en no-code, un prototype de laboratoire : il a réussi, il y a des utilisateurs, et il faut maintenant en faire un vrai logiciel. Personne n'a failli, le projet a changé d'échelle.
Selon ce que vous avez
Quatre situations, quatre façons de reprendre
Ce qui change d'un projet à l'autre, ce n'est pas le motif, c'est ce que nous pouvons faire du code. Chaque situation a sa page, avec ce que nous y lisons et par quoi nous commençons.
Le code se reprend tel quel. Nous lisons les dépendances, les bundles, les versions face au calendrier de support, nous stabilisons, puis nous améliorons palier par palier. Si la base est de qualité, rien n'est refait.
Sans framework, sur Symfony 1, Copix, CodeIgniter, Zend, ou greffée sur WordPress : le code se reprend et migre vers Symfony brique par brique, sur la même base de données, sans arrêter le logiciel.
Flash, WinDev, Access, Delphi, VB6 : le monde a cessé de porter la technologie. Nous ne reprenons pas le code, nous reprenons le projet, données, règles métier et utilisateurs, et nous le reconstruisons pendant que l'ancien tourne.
Excel, no-code, prototype de laboratoire, MVP d'un freelance, application générée par une IA : l'outil était le bon pour l'étape d'avant, et l'étape est finie. Ce qu'il a appris se garde, ce qu'il ne peut plus porter se construit.
De la première version au logiciel stable →
Notre approche
Ménage, documentation et tests automatisés
Avant de corriger ou d'ajouter quoi que ce soit, nous prenons du recul sur ce qui existe.
Cette phase préalable conditionne le coût et la durée de toute la reprise.
Faire le tri d'abord
Toutes les fonctionnalités ne méritent pas d'être reprises. Certaines ne sont plus
utilisées, d'autres ont été contournées depuis des années. Les identifier et les
supprimer avant de reprendre, c'est la décision à plus fort retour sur investissement.
Pas de réunion pour les concevoir
Pas de développement ni de tests à écrire
Pas de documentation à maintenir
Pas de complexité ajoutée dans les interconnexions
Cartographier avant de coder
Schémas d'architecture, cartographie des modules, description des processus métier :
nous formalisons ce qui existe avant de toucher au code. Ce travail donne à toute
l'équipe une vision partagée du système et évite les régressions invisibles lors des
modifications.
Architecture et dépendances entre modules
Processus métier documentés
Fonctionnalités actives identifiées
Points de fragilité cartographiés
Tests automatisés dès la reprise
Sans couverture de tests, chaque modification est un risque. Nous ajoutons
progressivement des tests sur les parties critiques avant d'y toucher. Sur Symfony et Vue.js, notre stratégie de qualité logicielle est intégrée dès la reprise, pas ajoutée après coup.
La règle des interconnexions : doubler le nombre de
fonctionnalités quadruple le temps de développement. Chaque fonctionnalité crée des
interactions avec toutes les autres : réunion pour la concevoir, développement, tests
croisés, documentation, maintenance future. Supprimer avant de reprendre, c'est choisir de
payer quatre fois moins pour le même périmètre utile.
Notre stack technique
Les technologies que nous exploitons au quotidien
Un projet repris est un projet que nous allons exploiter pendant des années : il doit tenir sur des outils que nous maîtrisons en profondeur, pas seulement que nous connaissons. Voici un panel des principales que nous pouvons vous proposer.
Pas d'improvisation, pas de surprise. Chaque reprise suit le même processus structuré, du premier audit jusqu'à la mise en production.
1
Étape 1 : Audit
État des lieux et plan d'action
Avant de toucher une ligne de code, nous prenons le temps de comprendre ce que vous avez. Architecture, dépendances, qualité du code, risques identifiés, dette technique : tout est passé en revue.
Le livrable est un rapport d'audit clair avec un plan d'action priorisé et une estimation réaliste du travail de reprise. Vous savez où vous en êtes avant de vous engager.
Architecture et qualité du code
Structure, patterns utilisés, qualité globale, dette technique identifiée et points de fragilité à traiter en priorité.
Dépendances et sécurité
Inventaire des librairies, CVE ouvertes, versions dépréciées ou non maintenues, avec une priorisation par niveau de risque.
Rapport et plan d'action
Document structuré avec priorités, estimations et recommandations. Vous validez avant de vous engager sur la suite.
2
Étape 2 : Reprise technique
Remise en ordre et livraison sur recette
Nous travaillons en sprints de 2 semaines sur les priorités définies à l'audit : corrections des bugs critiques, mises à jour des dépendances, ajout de tests sur les parties sensibles, documentation technique et fonctionnelle.
Chaque sprint se conclut par une livraison sur un environnement de recette dédié. Vous validez, nous affinons, avant que quoi que ce soit n'arrive en production.
Notre stratégie de qualité logicielle s'applique dès cette étape : tests sur les parties critiques, analyse statique, revues de code. Chaque modification est sécurisée avant d'être livrée.
Sprints de 2 semaines
Livrables concrets à chaque sprint : corrections, mises à jour, nouvelles fonctionnalités ciblées. Vous voyez l'avancement semaine par semaine.
Environnement de recette dédié
Chaque livraison est déployée et testée sur recette avant toute mise en production. Vous validez dans un environnement identique à la production.
Documentation progressive
Documentation technique et fonctionnelle construite au fil de la reprise, pour que la connaissance du projet ne repose plus sur une seule personne.
Tests au fil de l'eau
Couverture de tests ajoutée progressivement sur les parties critiques pour sécuriser chaque modification.
3
Étape 3 : Migration production
Déploiement sur vos nouveaux serveurs
Une fois la recette validée, nous planifions la migration de production. Infrastructure Clever Cloud, hébergement souverain en France, procédure de rollback testée. Rien n'est laissé au hasard.
La migration s'effectue avec une fenêtre de maintenance planifiée et une vérification complète après déploiement. La plupart de nos migrations se font sans interruption de service perceptible.
Infrastructure Clever Cloud
Hébergement souverain certifié en datacenter français. Configuration des environnements, CI/CD, monitoring continu.
Plan de migration
Fenêtre de maintenance planifiée, procédure de rollback testée : rien n'est laissé au hasard avant la bascule.
Vérification post-déploiement
Check complet après déploiement : fonctionnalités, performances, monitoring actif. Nous restons disponibles les jours suivants.
4
Étape 4 : Évolutions
Nouvelle vie et refonte progressive
Un logiciel stabilisé, documenté et couvert de tests peut de nouveau évoluer dans de bonnes conditions. Les nouvelles fonctionnalités sont planifiées par priorité métier, les parties les plus vieillissantes refontes progressivement : module par module, sans interruption de service.
Nous ne recodons pas tout d'un coup. Chaque partie ancienne est remplacée par un équivalent moderne au rythme qui correspond à votre budget et vos besoins : c'est notre méthode de modernisation sans tout refaire. C'est la même rigueur que pour un développement sur mesure neuf, appliquée à un projet qui a déjà une histoire.
Cette phase s'inscrit naturellement dans notre offre de TMA : maintenance préventive, corrections, nouvelles fonctionnalités et refonte progressive selon votre rythme et votre budget.
Nouvelles fonctionnalités
Chaque évolution est estimée et planifiée avec vous avant de démarrer. Le socle sain créé à l'étape 2 les rend moins risquées et moins coûteuses.
Refonte progressive
Les parties les plus anciennes sont remplacées module par module. Le logiciel reste opérationnel et les utilisateurs ne voient pas de coupure.
Montées de version
Symfony, Vue.js, dépendances : chaque mise à jour est planifiée et testée pour éviter l'accumulation de dette technique.
STRATÉGIE
Migration ou refonte : deux réponses différentes
Ces deux mots sont souvent confondus. Pourtant, ils répondent à des situations différentes et n'ont pas le même budget ni le même périmètre de travail.
Migration de version
L'architecture reste la même, la logique métier est préservée. On met à jour les versions
majeures (PHP 8.1 vers 8.4, Symfony 6 vers 7), on adapte le code aux nouvelles API et on
supprime les appels dépréciés. C'est un chantier de
modernisation applicative préventive : mesurable, planifiable, sans
rupture fonctionnelle.
Base de code saine avec peu de dette technique
Logiciel fonctionnel mais sur une version vieillissante
Migrations régulières pour anticiper les dates EOL
Quand la dette technique est trop importante pour une migration classique, une refonte
s'impose. On repense tout ou partie de l'architecture pour repartir sur des bases
maintenables et évolutives. C'est un investissement plus conséquent, mais
parfois la seule option viable sur le long terme.
Base de code très dégradée, architecture obsolète
Trop de versions de retard pour une migration progressive
Besoin de changements fonctionnels profonds en même temps
Notre position
Ce que nous ne faisons pas
Pour vous fournir une prestation de qualité, nous préférons nous concentrer sur nos zones de compétences plutôt que d'intervenir sur n'importe quel projet sans condition.
Nous sommes également persuadé que la situation actuelle s'explique par des choix surement très pertinents à l'époque où ils ont été faits et qu'ils ne sont simplement plus adapté à votre contexte d'aujourd'hui.
1
Un projet sur un framework vivant dont nous ne sommes pas spécialistes
Laravel, par exemple : nous savons le lire et le migrer vers Symfony s'il n'a plus de prestataire, ou si Symfony est une choix plus adapté. Nous ne vous proposerons pas de le maintenons pas sur le long terme. Un projet Laravel en bonne santé mérite un spécialiste de Laravel.
2
Un site e-commerce ou un site vitrine
Prestashop, Magento, un site WordPress sans outil métier derrière : on ne migre pas un produit, on le remplace, et ce n'est pas notre métier. Si un outil métier a été greffé sur le site, c'est l'outil que nous reprenons. La reprise du site est possible si elle est inclu dans le cadre d'une migration.
3
Une reprise où personne n'arbitre
Un prestataire en place hostile et un client qui ne tranche pas : ce projet est perdu pour tout le monde. Nous sommes experts en développement et vous restez expert de votre métier. Si vous recherchez un outil où vous n'avez rien à cadre, la meilleure option est de choisir le projet d'un éditeur de logiciels pertinent pour votre méiter.
4
Dire du mal du prestataire sortant
Notre objectif est d'écouter votre situation, d'observer de manière factuelle et de vous proposer un plan d'action. Parfois le plan d'action inclura le prestataire actuel dans le périmètre où il reste la meilleure solution pour vous et parfois il sera sorti de la solution. Dans tous les cas, un historique s'explique pour ne pas refaire les mêmes erreurs mais nous préférons nous concentrer sur l'avenir pour avancer avec vous.
Votre logiciel a besoin d'un nouveau départ ?
Parlez-nous de votre situation
Vous avez un logiciel qui accumule de la dette ou un prestataire qui n'est plus disponible ? Nicolas analyse votre situation et vous dit ce qui est récupérable, ce qui peut être simplifié et ce que cela représente concrètement. Premier échange gratuit, sans engagement.
Appel de 30 min → Analyse gratuite → Proposition sous 5 jours
Vous êtes pleinement propriétaire du code que nous développons pour vous et pouvez maîtrisez son évolution.
Développement 100 % en France
Équipe est basée en France, communication simplifié sans décalage horaire pour une bonne compréhension.
Hébergement cloud souverain
Déploiement sur une infrastructure française avec support réactif. Vos données restent en France.
« Au départ, nous avons contacté SmartBooster pour réaliser un outil de suivi de contrat en facturation en remplacement de notre outil de gestion sous Excel.
Ce qui nous a plus par la suite, c'est la possibilité de rajouter progressivement de nouvelles fonctionnalités en fonction de nos besoins.
À présent, notre outil intègre un CRM, des statistiques pour le suivi de l'activité, l'accès aux fonctionnalités en fonction des droits des collaborateurs et nous réfléchissons à une interface client pour l'année prochaine.
»
Jonathan Falzone
Président Profinégo - votre service d'achat décentralisé
Une équipe sympathique, réactive, toujours à l'écoute de nos besoins et surtout force de proposition dans la mise en place de nouvelles fonctionnalités optimales nous faciliter le quotidien.
Cela fait plus de 3 ans que SmartBooster nous accompagne, je recommande vivement!
»
Le rapport de l'étape 1 est celui de notre audit de code : analyse statique, dépendances, tests, architecture, plan d'action priorisé. Il est le vôtre, même si vous ne continuez pas avec nous.
L'état des lieux commence toujours par là : quelles technologies tournent en production, jusqu'à quand elles sont supportées, et ce qui relève du patch de sécurité plutôt que de la refonte.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
En général 2 à 5 jours selon la taille du projet. Nous analysons l'architecture, les dépendances, la qualité du code et les risques identifiés. Le livrable est un rapport d'audit avec un plan d'action priorisé et une estimation du travail de reprise.
Oui, c'est même notre cas le plus fréquent. L'audit initial sert précisément à reconstruire la connaissance du projet. Nous complétons la documentation et ajoutons progressivement des tests sur les parties critiques au fil de la reprise.
Nous travaillons en sprints de 2 semaines, comme pour un développement classique. Chaque sprint produit des livrables concrets : corrections, mises à jour, fonctionnalités. La recette se fait sur un environnement dédié avant chaque déploiement en production.
Pas si elle est bien préparée. Nous planifions la migration avec une fenêtre de maintenance, une procédure de rollback testée et une vérification complète après déploiement. La plupart de nos migrations se font sans interruption de service perceptible.
Oui, et c'est le motif le plus simple à traiter, parce que personne n'a failli : le premier prestataire a prouvé que l'idée tenait, la preuve est qu'il y a des utilisateurs. C'est le projet qui a changé d'échelle. Selon la technologie du MVP, le code se reprend ou le projet se reconstruit : la page première version fait l'aiguillage.
Si votre projet est sur Symfony, le code se reprend tel quel : page reprise de projet Symfony. S'il est en PHP ancien, sans framework ou sur un framework abandonné, le code se migre brique par brique vers Symfony : page reprise d'application PHP. S'il est sur une technologie que le monde a lâchée, Flash, WinDev, Access, nous reprenons le projet et nous le reconstruisons : page technologie obsolète. Si c'est une première version dépassée par votre croissance, Excel, no-code, prototype, MVP, application générée par une IA : page première version. Vous ne savez pas ? Dites-le-nous, c'est la première question qu'on pose.
Oui. La reprise aboutit naturellement à un contrat de TMA. Après la migration, nous assurons la maintenance préventive, corrective et évolutive selon votre rythme et votre budget, et notre veille vous signale ce qui mérite d'entrer dans le projet.
Nous travaillons
avec et pour nos clients
Ces 10 dernières années, nous avons développé des dizaines de logiciels sur mesure
pour nos clients.
SmartBooster est une entreprise qui place la relation client au cœur de son activité.
Nous travaillons en étroite collaboration avec nos clients pour comprendre et répondre
à leurs besoins.
Notre expertise ne se limite pas au développement technique. Nous accompagnons nos
clients dans la réflexion et la mise en place de solutions sur mesure qui s'adaptent
parfaitement à leurs processus métiers.
En choisissant SmartBooster, vous bénéficiez d'un partenaire qui s'engage à vos côtés
pour concevoir et développer les fonctionnalités dont vous avez besoin.