Reprise de logiciel existant / De la première version au logiciel stable
Votre première version a fait son travail, passez à un logiciel stable
Un fichier Excel qui pilote l'activité depuis trois ans, un outil no-code monté en quinze jours, un modèle de calcul dans MATLAB, un MVP développé par un freelance, une application générée par une IA : il y a des utilisateurs, et l'outil commence à peser. C'était une bonne première version et il faut reconnaître qu'une étape est finie pour passer à la suivante sans perdre ce que vous avez déjà a appris.
Les signaux que l'étape est finie
Vous avez besoin d'accélérer et vous êtes limité par l'outil
Les limites d'Excel ou du no-code existaient dès le premier jour et n'empêchaient pas de travailler. Ces limites à l'origine acceptable ne le sont plus aujourd'hui car votre activité a changé d'échelle.
L'équipe s'agrandit
Un fichier que son auteur connaît par cœur devient complexe quand il faut le transmettre. Chez Profinégo, le signal a été l'arrivée de nouveaux collaborateurs après deux ans d'Excel. Chez Turfu, 38 utilisateurs sur 6 sites qui appelaient le dirigeant pour connaître l'état d'un dossier.
Les calculs engagent de l'argent
Une commission par commercial, une facture, une aide financière : tant qu'une seule personne fait le calcul et le vérifie, un tableur suffit. Dès que trente personnes attendent le résultat, une erreur de formule devient un litige.
Quelqu'un d'extérieur impose ses exigences
Pour Wellscan, c'est le jour où des entreprises du CAC40 ont demandé des garanties de cloisonnement des données, et où une entreprise « secret défense » a demandé un mode entièrement anonyme. La première version faisait le travail pour quelques dizaines de participants, pas pour ça.
Le produit doit s'ouvrir à d'autres
Le modèle hydrologique de Dimus était juste, validé par un laboratoire, et réservé à quelques experts qui savaient lancer MATLAB. Le rendre accessible à tous les bureaux d'études changeait sa nature : un algorithme qui sert à des gens qui ne l'ont pas écrit n'est plus un prototype.
Une seule personne peut y toucher
Le freelance qui a construit le MVP est le seul à le comprendre, il est occupé ailleurs ou il a changé d'activité. Pour une application générée par une IA, l'auteur est absent dès le premier jour. Le produit marche, et personne ne peut le faire évoluer sans risque.
L'éditeur fixe le prix et les règles
La plateforme no-code facture au siège ce qui devient un problème avec le volume, et vous ne pouvez pas demander de développement spécifique. Le SaaS détourné en logiciel métier tient tant que l'éditeur ne change ni ses tarifs ni ses limites, et il le fait quand il veut.
Pourquoi c'était le bon choix
Une entreprise qui démarre ne connaît pas encore ses règles
Elle sait ce qu'elle vend, pas encore comment elle le suivra, ce qu'elle mesurera ni où elle perdra du temps. L'outil de démarrage est le meilleur du monde pour ça : il coûte peu, il se modifie en direct, et il accepte toutes les exceptions. Chaque exception est une règle métier découverte.
Personne ne se trompe en démarrant petit. La seule erreur possible est de rester sur l'outil de démarrage après que l'activité l'a dépassé, ou de le jeter en croyant qu'il n'a rien appris.
Excel ou Google Sheets
Coûte zéro, se modifie en direct, accepte toutes les exceptions. Chaque colonne ajoutée est une règle métier découverte. Il apprend à l'entreprise quelles données comptent, et lesquelles ne servent jamais.
Un outil no-code ou un SaaS détourné
Monté en quinze jours, il apprend quel parcours les utilisateurs suivent réellement avant d'investir dans un développement. Ses écrans et ses automatisations sont la spécification qu'aucun cahier des charges n'aurait su écrire.
Un modèle MATLAB, R ou Python
La forme naturelle d'un algorithme quand il est encore entre les mains des experts qui le conçoivent. Il est juste, ses auteurs l'ont validé, et c'est exactement ce qu'il devait être à ce stade.
Un MVP développé par un freelance
Il apprend si le produit se vend, ce qui est la seule question qui compte avant de construire davantage. Nous vendons nous-mêmes cette étape : un prototype sert à décider, pas à durer.
Une application générée par une IA
Elle a permis à quelqu'un qui ne code pas de montrer ce qu'il voulait, avec de vrais écrans et de vrais utilisateurs. C'est une maquette qui marche. Sa limite est celle de tout MVP, avec un auteur en moins.
Ce qui se garde
Tout ce que la première version vous a permis d'apprendre
C'est le point que la plupart des refontes ratent. Une première version n'est pas un brouillon à jeter, c'est la seule documentation exacte de ce que l'entreprise fait vraiment. Voici ce que nous reprenons systématiquement.
Les données
Chez Profinégo, la migration depuis Excel s'est faite sans une donnée perdue : des fonctions d'import lisent les fichiers existants plutôt que de demander une ressaisie. Les classeurs étaient la base de données de l'entreprise, ils ont été traités comme telle.
- Import des fichiers existants
- Zéro ressaisie
- Ce qui est mort ne passe pas
Les règles et les formules
Chaque colonne calculée, chaque cellule colorée à la main, chaque automatisation dit quelque chose que personne n'a écrit ailleurs. Pour La Maison Saint-Gobain, les formules de prix et d'aides d'origine sont devenues des tests automatisés qui bloquent le déploiement en cas d'écart.
- Lues avant d'écrire une ligne de code
- Formules devenues tests
- Tunnel de chiffrage LMSG
L'algorithme, à l'identique
Pour Dimus, la contrainte était de porter le calcul MATLAB sur le web avec des résultats strictement identiques. Les experts saisissent un résultat attendu, le logiciel calcule et affiche l'écart, à chaque mise à jour du code. Le modèle de la recherche n'a pas été réinventé, il a été rendu accessible.
- Cas de référence rejoués à chaque livraison
- Écart affiché, vérifiable par le métier
- Dimus, de MATLAB au web
La manière de travailler
Une entreprise qui a piloté trois ans avec un tableur sait très bien ce dont elle a besoin. C'est un client qui décide vite, et ça se voit dans les délais : 7 semaines chez Profinégo, conception comprise, moins de trois mois chez Turfu.
- Besoin déjà connu, pas à inventer
- Décisions rapides
- Délais courts
Six passages
Six premières versions devenues des logiciels stables
Un dirigeant de PME qui a dépassé Excel, un syndicat dont le modèle sortait du laboratoire, un fondateur dont le MVP marchait : le raisonnement est le même, seul le vocabulaire change. Les chiffres sont ceux des projets.
Profinégo : d'Excel à un logiciel de gestion de contrats
7 semaines, conception comprise, et zéro donnée perdue
Jonathan Falzone a structuré son activité de renégociation de contrats dans Excel dès 2020. Deux ans plus tard, le volume et l'arrivée de collaborateurs rendaient les fichiers limitants.
Première version livrée en 7 semaines, conception comprise, avec import des fichiers existants plutôt que ressaisie. La V2 a été commandée alors que la V1 était à moitié faite.
Turfu, puis ENR Manager : d'Excel, puis de Google Sheets, deux fois
38 utilisateurs sur 6 sites, et un client qui a vécu le passage deux fois
Trois entreprises de rénovation énergétique sur 6 sites : chantiers, commissions, paiements et facturation vivaient dans Excel. Logiciel lancé mi-janvier, en production le 5 avril, 38 utilisateurs avec des droits par profil.
Le même client est revenu pour une seconde activité, partie d'un Google Sheets : ENR Manager en a fait un logiciel de gestion de chantier complet.
Pre-etat-date-moins-cher.com : d'Excel à une plateforme en marque blanche
Commande, paiement et envoi en ligne, 4 portails partenaires
Le suivi des commandes de pré-états datés se faisait dans Excel. La plateforme gère aujourd'hui la commande en ligne, le paiement, la réalisation et l'envoi des documents, avec une interface client, une API et 4 portails partenaires en marque blanche, chacun sur son sous-domaine.
Le tableur ne pouvait pas devenir un produit que des partenaires revendent ; ce qu'il avait appris du métier, si.
Dimus : de MATLAB à un outil web pour tous les bureaux d'études
3 mois jusqu'à la production, résultats identiques au modèle d'origine
Le modèle hydrologique de l'ITSEP existait en MATLAB, développé avec le laboratoire ICube de l'ENGEES. Première version web en production en 3 mois, en février 2026, connectée aux données Météo-France et accessible gratuitement.
Résultats identiques au modèle d'origine, vérifiables par les experts à chaque mise à jour : ils saisissent un résultat attendu, le logiciel calcule et affiche l'écart.
La Maison Saint-Gobain : d'Excel et Visio à 130 parcours de chiffrage
7 ans, 3 refontes, un cœur de calcul jamais jeté
Bibliothèque de prix dans Excel, parcours de questions dessinés dans Visio. Première version du tunnel en 2019. Depuis, 3 refontes complètes, des pics de charge lors de spots sur TF1 et M6, et 7 ans de collaboration.
Le cœur du projet, les formules de prix et d'aides, n'a jamais été jeté : il a été protégé par des tests automatisés qui bloquent le déploiement en cas d'écart.
Wellscan : du MVP d'un freelance à une plateforme revendue
Des campagnes de 4 000 participants, et un MVP devenu un actif cessible
La première version avait été développée par un indépendant, et elle faisait le travail : le baromètre de qualité de vie au travail rencontrait un succès croissant. Ce succès a amené des campagnes de plus de 4 000 participants, des grands comptes du CAC40, une médecine du travail en mode anonyme.
Six ans, 8 baromètres, et une plateforme revendue en 2024.
Ce qui ne change pas
La façon de travailler reste celle d'une première version
Passer au logiciel stable ne veut pas dire passer au projet lourd. Les projets racontés plus haut ont tous été menés comme une première version : par cycles courts, en livrant.
La différence n'est pas le rythme, c'est ce qui est garanti à chaque livraison. C'est notre définition de la qualité logicielle : le logiciel stable garde la vitesse du prototype et perd sa fragilité.
Des cycles de deux semaines
Une démonstration en direct à la fin de chaque cycle, un environnement de recette accessible au client. Chez Profinégo, la V2 a été commandée alors que la V1 était à moitié faite : le client voyait ce qu'il aurait, et décidait de la suite.
Trier avant de construire
Chez Turfu, les fonctionnalités demandées ont été classées en trois catégories, obligatoire, confort et cosmétique, et seules les premières ont été développées avant la mise en production. C'est ce qui a tenu le délai.
Ce qui est garanti à chaque livraison
Des tests qui empêchent une régression sur les calculs, des droits d'accès par profil, une base de données unique et à jour, un déploiement reproductible. Le logiciel stable garde la vitesse du prototype et perd sa fragilité.
Selon votre socle
Le raisonnement est le même, le parcours dépend de ce que vous avez
Cette page est en partie un aiguillage, et elle le dit. Ce qui se garde ne dépend pas du socle. Ce qu'on en fait, si : un code qui se lit se reprend, un outil qu'on ne lit pas se reconstruit, et un code dont on ne sait rien s'audite d'abord.
Un fichier Excel ou Google Sheets
Le cas le plus fréquent, et nous le connaissons bien : le classeur devient un logiciel sur mesure, avec import des fichiers existants et formules devenues tests.
- Import sans ressaisie
- Transformer Excel en logiciel
Un MVP dont le code est en PHP
Le code se lit, donc il se reprend : audit, stabilisation, puis évolution, ou migration vers Symfony brique par brique s'il est sur un socle ancien. Rien n'est reconstruit qui peut être repris.
- Audit d'abord, puis reprise
- Reprise d'application PHP
- Reprise de projet Symfony
No-code, SaaS détourné, prototype de laboratoire
Nous ne reprenons pas le code, nous reprenons le projet : données, règles, utilisateurs, écrans. Le nouveau logiciel se construit sur Symfony et Vue.js par lots, pendant que l'ancien continue de tourner.
- Export et modèle de données d'abord
- L'ancien en service jusqu'à la bascule
- Cas de référence si le métier repose sur un calcul
Une application générée par une IA
La question n'est pas le socle, c'est la confiance : ce code est-il utilisable ? L'audit répond en quelques jours, sécurité en premier. Ensuite, selon ce que l'IA a produit, l'un des trois parcours ci-dessus.
- L'audit de code
- Cadrage du préimètre foncitonnel
- Sécurité et droits d'accès en premier
Votre première version a fait son travail ?
Décrivez-la-nous telle qu'elle est
Le fichier, l'outil, le prototype, avec ses onglets, ses colonnes et ses raccourcis : c'est le point de départ le plus utile qui soit, parce qu'il contient déjà tout ce que vous avez appris. Nicolas vous dit ce qui se garde, ce qui se construit en premier, et par quel parcours. Premier échange gratuit, sans engagement.
Appel de 30 min → Lecture de l'existant → Plan par lots
GLOSSAIRE
Le vocabulaire du passage au logiciel stable
Les termes que vous entendrez pendant le projet. Chaque définition dit d'abord ce que ça change pour vous, puis comment ça se passe concrètement.
- Première version
- L'outil qui a permis de démarrer : un classeur, un outil no-code, un prototype, un MVP. Il a réussi s'il a des utilisateurs. Sa limite n'est pas un défaut, c'est sa définition : il n'a jamais été conçu pour porter l'activité de toute une entreprise, et il l'a fait quand même pendant un moment.
- Prototype
- Une version faite pour prouver qu'une idée tient, pas pour durer : un modèle de calcul entre les mains des experts, une maquette qui marche. Il sert à décider. Le garder en production après la décision, c'est lui demander ce pour quoi il n'a pas été fait.
- MVP
- Minimum viable product : la plus petite version d'un produit qui permet de savoir s'il se vend. C'est la seule question qui compte avant de construire davantage, et un MVP qui trouve ses clients a répondu. Ce qu'il a appris se garde ; ce qu'il ne peut plus porter se développe.
- No-code
- Des plateformes (Bubble, Airtable, Softr) qui permettent de construire une application sans écrire de code. Idéales pour démarrer vite. Le prix se paie plus tard : par utilisateur, en performances, et en dépendance à un éditeur qui peut changer ses tarifs ou fermer.
- Vibe coding
- Construire une application en décrivant ce qu'on veut à une IA qui écrit le code. On obtient vite des écrans qui marchent, sans savoir ce qu'il y a derrière. C'est une première version avec un auteur en moins : personne ne peut dire ce que le code fait, ni s'il est sûr, avant de l'avoir lu.
- Changement d'échelle
- Le moment où l'activité dépasse l'outil : plus d'utilisateurs, plus de sites, des clients qui exigent, un produit qui s'ouvre. Aucun des signaux ne dit que l'outil était mauvais. Ils disent que l'entreprise a grandi, et que l'outil de démarrage a fait son travail.
- Reprise de données
- Le transfert des données de l'ancien outil vers le nouveau : export, nettoyage, et surtout compréhension de ce que chaque colonne veut dire. C'est le premier actif du projet, et l'étape qui révèle ce qui était réellement utilisé.
- Cas de référence
- Une série de situations dont le résultat attendu est connu, rejouée à chaque mise à jour du nouveau logiciel. Si le résultat s'écarte, l'écart s'affiche. C'est ainsi que Dimus prouve qu'il calcule comme le modèle MATLAB d'origine, et ce que nous mettons en place dès que le métier repose sur un calcul.
- Régression
- Une fonctionnalité qui marchait et qui ne marche plus après une modification ailleurs. C'est le coût caché d'une première version sans tests : chaque livraison peut casser ce qui était acquis. Les tests automatisés existent d'abord pour ça, et c'est la première chose que le logiciel stable ajoute.
- Environnement de recette
- Une copie du nouveau logiciel, séparée de la production, où vous validez chaque livraison avant que vos utilisateurs la voient. Rien n'arrive en production sans être passé par là.
D'autres termes sont définis dans notre glossaire général.
Notre savoir-faire
L'expertise qui s'adapte à votre situation
Quel que soit votre point de départ, nous avons les compétences pour vous accompagner : créer de zéro, reprendre l'existant, valider une idée ou moderniser un outil qui montre ses limites.
Développement logiciel sur mesure
Vous avez un besoin métier que les logiciels du marché ne couvrent pas. On conçoit votre outil de zéro, depuis le cahier des charges jusqu'à la mise en production.
Reprise et refonte de logiciel
Votre logiciel existant freine votre transformation numérique : trop lent, trop rigide, impossible à faire évoluer. On reprend le code et on développe un outil spécifique à votre contexte.
TMA et maintenance évolutive
Votre logiciel est en production et doit le rester : corrections, évolutions, mises à jour de sécurité. Une équipe dédiée qui le connaît et le maintient dans la durée.
Prototype et MVP
Vous avez une idée de produit ou de SaaS à valider. On construit un premier outil fonctionnel pour tester vite et à moindre coût.
Hébergement et maintenance
Votre application tourne, mais qui s'assure qu'elle reste disponible, sécurisée et à jour ? On prend en charge le déploiement et le suivi.
Transformation Excel en logiciel
Votre Excel fonctionne mais commence à montrer ses limites. On le transforme en outil métier : automatisation des tâches répétitives, collaboration en temps réel, évolutivité sans contrainte.
Un client qui a piloté trois ans avec un tableur sait exactement ce qu'il veut. C'est le projet le plus facile à cadrer, et le plus rapide à livrer.
Une première version n'est pas un brouillon. C'est la seule documentation exacte de ce que l'entreprise fait vraiment, et je la lis avant d'écrire une ligne.
« 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. »
« Je suis très satisfait du travail effectué par Nicolas et son équipe, il a eu une parfaite compréhension de mes besoins et de mon environnement.
Son process est rodé et très bien organisé pour avancer étape par étape sans rien oublié. Ses conseils sont judicieux pour aller au-delà de ce que j'aurai pu imaginer avant de faire appel à Smartbooster.
Je recommande sans hésitation, vous aurez à faire à un véritable professionnel ! »
Pour aller plus loin
Approfondir votre réflexion
Le cas le plus fréquent de cette page a sa propre page : le classeur qui est devenu l'outil de toute l'entreprise.
WinDev, Access, Delphi, Flash : ce n'est pas votre croissance qui l'a dépassé, c'est le monde qui a cessé de le porter. Une autre page, et un autre raisonnement.
Quand la première version n'existe pas encore : comment nous validons une idée avant d'investir dans un développement complet.
Quand la première version a trouvé ses clients et que le produit doit devenir une plateforme : abonnements, multi-clients, montée en charge.
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 !
Non, et nous le disons sans politesse : la preuve, c'est qu'il y a des utilisateurs. Une entreprise qui démarre ne connaît pas encore ses propres règles. Excel, un outil no-code, un prototype ou un MVP les lui ont apprises, à un coût que rien d'autre n'aurait permis. La seule erreur possible est de rester dessus après que l'activité l'a dépassé, ou de le jeter en croyant qu'il n'a rien appris.
En général non. Construire vite une version qui trouve ses clients est un travail difficile, et il l'a fait. Ce que nous demandons est concret : un accès au code et à un environnement, un périmètre écrit, un interlocuteur qui tranche. Ensuite, nous lisons avant de proposer. Une première version qui tourne contient des règles que personne n'a documentées ; les réécrire de mémoire, c'est les perdre.
Nous commençons par la lire, et c'est la seule réponse honnête. Une application vibe-codée est une première version comme les autres, avec un auteur absent par définition. Sa question propre est : ce code est-il utilisable ? L'audit y répond en quelques jours, sur la sécurité d'abord. Selon le socle que l'IA a produit, le code se reprend ou le projet se reconstruit, et nous ne promettons rien avant d'avoir lu.
Oui. Il reste en service jusqu'à ce que le nouveau couvre ce qui est utilisé, et la bascule se prépare : reprise des données, période de double fonctionnement si nécessaire, retour arrière possible. Chez Profinégo, les fichiers Excel ont été importés par des fonctions dédiées, sans ressaisie et sans perte.
Non. Les projets racontés sur cette page ont tous été menés comme une première version : par cycles de deux semaines, avec une démonstration à la fin de chacun et un environnement de recette. Ce qui change, c'est ce qui est garanti à chaque livraison : des tests sur les calculs, des droits par profil, une base unique, un déploiement reproductible.
Presque toujours, par export ou par API. La difficulté n'est pas de les extraire, c'est de leur donner un modèle : un outil détourné range tout dans des tables génériques, et la première étape est de reconstruire ce que ces données veulent dire.
WinDev, Access, Delphi, une interface Flash : ce n'est pas votre croissance qui a dépassé l'outil, c'est le monde qui a cessé de le porter. C'est un autre raisonnement, et une autre page.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.