Nos expertises / Modernisation
Modernisez votre application sans tout refaire
Vous avez demandé une fonctionnalité, et on vous a répondu qu'il faudrait d'abord tout reconstruire. Ou une règle de calcul change et personne n'ose toucher au code. Dans les deux cas, ce n'est pas votre logiciel qui est condamné, c'est la façon de le faire évoluer qui manque.
Nous modernisons brique par brique, pendant que le logiciel tourne : d'abord un filet de sécurité, puis chaque chantier dans l'ordre de ce qui vous gêne. Chaque étape livre quelque chose, et vos utilisateurs s'habituent un écran à la fois.
Ce qui déclenche la demande
Ça vous parle ?
Quatre situations, toujours les mêmes, qui amènent un dirigeant à taper « moderniser mon application ». Aucune ne condamne le logiciel : chacune dit par quelle brique commencer.
On vous a répondu : « pas sans tout refaire »
Vous avez demandé une fonctionnalité, un export, un nouvel écran. La réponse a été qu'il faudrait d'abord tout reconstruire. Ce n'est pas la fonctionnalité qui bloque, c'est ce qu'il faut assainir avant de l'ajouter, et ça se fait par étapes.
Une règle métier change, personne n'ose toucher le code
Une réglementation modifie un calcul, un barème, une échéance. La modification tient en quelques lignes, mais personne ne sait ce qu'elle casse ailleurs. Le problème n'est pas la règle, c'est l'absence de filet.
Ça plante quand un service ne répond pas
Le serveur de mail est indisponible deux minutes et l'utilisateur voit un écran d'erreur à la fin d'une saisie de vingt minutes. Un traitement qui dépend d'un service extérieur ne devrait jamais bloquer un écran.
Chaque mise en production est une soirée de stress
Le déploiement se fait à la main, le soir, avec une personne qui sait. Les mises à jour sont repoussées parce qu'elles font peur, et le retard s'accumule jusqu'à la fin de support.
Notre méthode
L'amélioration progressive, pas une refonte complète
Refaire un logiciel d'un bloc, c'est un tunnel de plusieurs mois pendant lequel rien ne sort, et une journée de bascule où tout change pour tout le monde. Nous préférons proposer l'inverse : la brique neuve pousse autour de l'ancienne jusqu'à la remplacer, et le logiciel ne s'arrête jamais.
La méthode repose sur 3 règles essentielles :
- Sécuriser avant de bouger
- Mise à jour sur des versions en zone de support, tests posés sur ce qui va être touché, scans de sécurité. On ne se lance pas dans des modifications sans préparer le terrain.
- L'ancien et le nouveau coexistent
- Chaque brique neuve remplace une brique ancienne pendant que le reste continue de tourner. Le challenge pour que votre logiciel ne s'arrête jamais, c'est de choisir judicieusement la stratégie de migration.
- Chaque étape livre quelque chose
- Un écran, un traitement, un déploiement : chaque lot est utilisable, budgété et validé séparément. Pas de tunnel de douze mois. C'est essentiel pour constater les éventuels écarts au plus tôt et les ajuster.
Selon vos priorités
Moderniser, ça veut dire quoi pour vous ?
Nous ne modernisons pas pour moderniser par simple plaisir. Chaque chantier répond à quelque chose que vous ou vos utilisateurs subissez, le plan d'action se définit sur le périmètre et dans l'ordre que vous choisissez.
Le filet de sécurité
Mettre à jour et poser les tests avant de toucher au reste
Le premier chantier est toujours le même : remonter les versions en zone de support, puis poser les tests qui protègeront tout ce qui suit. Quand le code le permet, les tests s'écrivent à l'intérieur, avec PHPUnit. Quand il ne le permet pas, parce qu'un code ancien ne se teste pas unitairement sans le réécrire, les tests se posent de l'extérieur avec Playwright : ils rejouent les parcours réels et signalent ce qui change d'écran en écran.
Deux scans complètent le filet : ZAP pour ce qu'un attaquant verrait de l'application, OSV-Scanner pour les vulnérabilités connues des dépendances. Ils tournent avant, pendant et après chaque étape.
Les tâches techniques
Extraire les traitements de fond sur une stack à jour
Compilation de statistiques la nuit, mails d'alerte, génération de document, exports comptables, imports de données : ces traitements tournent en tâche planifiée et n'ont pas besoin de l'interface. Ils peuvent sortir de l'ancien code en premier, s'exécuter sur une stack à jour, couverts par des tests, pendant que l'application continue de tourner comme avant.
C'est souvent la première brique qu'on déplace car elle peut être réalisée de manière transparente pour vos utilisateurs et les résultats sont généralement faciles à vérifier.
Les traitements asynchrones
Un service qui tombe ne doit plus bloquer un écran
Envoyer un mail, appeler une API, générer un document : quand ces actions se font pendant que l'utilisateur attend, le moindre incident chez le service extérieur devient son écran d'erreur. En asynchrone, l'action est mise en file d'attente puis exécutée dès que possible. En cas d'erreur, il est possible de relancer le traitement.
Nos nouveaux projets sont construits ainsi dès le départ, pour l'envoi de mails chez BMPB comme pour les extractions comptables et les statistiques commerciales de Caprenov. Sur un logiciel existant, chaque traitement bascule un par un, en commençant par celui qui a fait le plus d'écrans d'erreur.
L'interface
Dynamiser les écrans composant par composant
Un écran de saisie de quarante champs, validé d'un bloc, avec les erreurs en haut de page : c'est l'écran que les utilisateurs contournent. Le découper en étapes, avec une validation intermédiaire, se fait avec Vue.js sur ce seul écran, sans toucher aux autres.
C'est la raison pour laquelle nous avons choisi Vue.js : il s'accroche à du HTML existant sans étape de compilation, là où React demande une chaîne de build dès le premier composant. GitLab a fait ce choix en 2016 pour remplacer jQuery écran par écran, et c'est ce que nous faisons sur les logiciels que nous modernisons.
L'aspect graphique
Améliorer l'interface avec un style plus moderne
Un logiciel qui a l'air vieux fait douter de ce qu'il calcule, y compris chez vos propres clients. Tailwind CSS permet de reprendre l'apparence page par page à partir d'un jeu de composants communs, sans dépendre d'une feuille de style historique que plus personne n'ose modifier.
Les écrans repris et les écrans anciens cohabitent le temps du chantier. On commence par ceux que vos clients voient, on finit par ceux que seuls vos collaborateurs utilisent.
Les outils de développement et de déploiement
Rendre la maintenance ordinaire
Un environnement de développement sous Docker, identique pour chaque développeur et pour la production, supprime le « ça marche chez moi ». Une chaîne GitLab CI joue les tests à chaque modification et déploie sans intervention manuelle.
Ce chantier ne change rien pour vos utilisateurs mais il permet de retrouver progressivement de la productivité : une mise en production redevient un geste de quelques minutes, et les mises à jour ne sont plus repoussées.
Les outils de qualité suivent le même mouvement. PHPStan, PHP CS Fixer, ESLint et Prettier s'installent avec une baseline qui fige l'existant : ils ne bloquent que le code nouveau, et l'ancien se corrige lot par lot, dans le flux de la maintenance. C'est le parcours que décrivent nos conventions de code.
Une fonctionnalité bloquée, une règle qui change ?
Parlez-nous de ce qui vous gêne
Nicolas lit votre situation et vous dit par quelle brique commencer, ce qu'elle change pour vos utilisateurs et ce qu'elle rend possible ensuite. Premier échange gratuit, sans engagement.
Appel de 30 min → Analyse gratuite → Proposition sous 5 jours
Le parcours
Quatre étapes, et rien ne s'arrête
Sécuriser, choisir, moderniser, exploiter. L'ordre est le même pour tous les logiciels, le contenu de chaque étape dépend du vôtre.
Sécuriser : un filet avant le premier geste
Versions remontées en zone de support, tests posés sur ce qui va être touché, à l'intérieur quand le code le permet et de l'extérieur sinon, scans de sécurité. Cette étape ne change rien de visible : elle rend toutes les suivantes possibles.
Zone de support
Chaque version confrontée à son calendrier de fin de support, et remontée avant l'échéance.
Tests intérieurs ou extérieurs
PHPUnit quand le code s'y prête, Playwright sur les parcours réels quand il ne s'y prête pas.
Scans ZAP et OSV-Scanner
Ce qu'un attaquant verrait, et les vulnérabilités connues des dépendances.
Choisir : quoi moderniser, et dans quel ordre
L'audit de code dit ce que le logiciel supporte et ce qui le fragilise. Vous dites ce qui vous gêne : l'écran contourné, le traitement qui plante, la règle qui va changer. Le plan croise les deux et commence par la brique qui rapporte le plus pour le moins de risque. Le livrable est une liste de lots, chacun avec ce qu'il change pour vos utilisateurs, ce qu'il coûte et ce qu'il rend possible ensuite.
L'audit de code
Un rapport en 2 à 5 jours : dépendances, analyse statique, tests, architecture, plan priorisé.
Vos symptômes
Ce qui gêne au quotidien pèse autant que ce que l'analyse relève.
Des lots, pas un projet
Chaque lot est estimé et livrable seul. Vous engagez le suivant quand le précédent tourne.
Moderniser : brique par brique, pendant que ça tourne
Une tâche planifiée sort du code ancien, un traitement passe en asynchrone, un écran est découpé, une page reprend son apparence. À chaque lot, l'ancien et le nouveau cohabitent, et le lot est validé sur un environnement de recette avant d'arriver en production. Les architectes ont un nom pour cette façon de faire, le strangler fig : la brique neuve pousse autour de l'ancienne jusqu'à la remplacer. Nous l'appliquions depuis des années avant d'apprendre qu'elle avait un nom.
Coexistence
Rien ne s'arrête. Une brique remplacée est une brique de moins à porter, tout de suite.
Recette avant production
Chaque lot est vérifié par vous sur un environnement identique à la production.
Les utilisateurs suivent
Un écran à la fois, avec la possibilité de dire ce qui gêne avant le lot suivant.
Exploiter : les fonctionnalités redeviennent ordinaires
Une fois le socle modernisé, la fonctionnalité qu'on vous refusait est une évolution comme une autre : estimée, développée, testée, déployée. C'est le rythme de notre maintenance évolutive, sur un budget annuel que vous pilotez.
Évolutions
La demande de départ, enfin, et les suivantes au même rythme.
Versions suivies
Les montées de version deviennent des lots ordinaires, planifiés avant l'échéance.
Budget annuel
Un cadre que vous décidez, des lots que vous priorisez.
Le changement, côté utilisateurs
Vos collaborateurs et vos clients suivent le mouvement
Un logiciel modernisé par étapes est aussi un changement que les gens absorbent par étapes. C'est le second avantage du progressif, et il pèse autant que le premier.
S'habituer un écran à la fois
Un logiciel refait d'un bloc change tout le même jour, pour tout le monde. Un logiciel modernisé par étapes change un écran, puis un autre : chacun garde ses repères sur le reste pendant qu'il apprend le nouveau.
Participer plutôt que subir
Chaque lot est montré avant d'être livré. Vos collaborateurs disent ce qui les gêne, vos clients ce qui leur manque, et le lot suivant en tient compte. Ce sont eux qui construisent le logiciel à nos côtés.
Être plus performant
Lorsque le changement se passe par étapes et que l'on a la possibilité de participer, chacun se sent pleinement acteur de ce changement et cela a un réel impact sur la performance collective à long terme.
Notre position
Quand le progressif ne s'applique pas
Moderniser suppose un socle suffisamment sain sur lequel greffer. Quand la base n'est pas pertinente, rien ne sert de vous proposer des solutions alambiquées qui vous feront simplement perdre du temps et du budget.
Flash, WinDev, Access, Delphi : il n'y a pas de brique neuve à greffer sur un socle que plus personne ne porte. Là, on ne modernise pas, on reprend le projet, données, règles et utilisateurs, et on le reconstruit pendant que l'ancien tourne. C'est réellement une refonte qui est nécessaire.
Un prototype, un MVP fait par un freelance, un outil no-code, une application générée par une IA : ce qu'il a appris se garde, mais le socle technique, souvent, ne se modernise pas : il se construit.
Dans le cas où le code n'est pas extraordinaire et que vous nous expliquez qu'une grande partie de son fonctionnement ne correspond pas vraiment à ce que vous voulez, nous serons sûrement plus efficaces en vous proposant un nouveau développement. Nous l'avons vécu, parfois écrire directement ce que vous voulez est simplement beaucoup plus pertinent.
Nos engagements
Ce que vous pouvez exiger de nous
Propriété totale du code source
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.
« La qualité est au rendez-vous et les délais maîtrisés. C'est un gage de sérénité que de travailler avec SmartBooster. »
« Tout au long de notre collaboration, Nicolas a toujours su être un professionnel exemplaire. En tant que project manager, il sait prendre tous les sujets à bras-le-corps et les prioriser avec intelligence.
Il sait aussi donner la visibilité suffisante et rassurante sur les avancées de ses équipes. Nicolas se révèle être un interlocuteur crédible et efficace autant sur le plan technique que sur le plan de la gestion projet. »
Pour aller plus loin
Approfondir votre réflexion
Le rapport de l'étape 2 : analyse statique, dépendances, tests, architecture, plan d'action priorisé. Il est le vôtre, même si vous ne continuez pas avec nous.
Cycle de vie des technologies, chaîne de dépendances, migration version par version : le chantier du filet de sécurité, vu du côté technique.
Un outil gratuit qui confronte vos versions à leur calendrier de fin de support, avant même de nous parler.
Une fois le socle modernisé, les fonctionnalités redeviennent des évolutions ordinaires, sur un budget annuel que vous pilotez.
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 !
Par l'audit de code : un rapport en 2 à 5 jours qui dit ce que le logiciel supporte, ce qui le fragilise et par quelle brique commencer. Si vous voulez un premier repère avant de nous parler, l'outil d'analyse de montée de version confronte vos versions à leur calendrier de support en quelques minutes.
Oui, c'est le principe. Chaque brique neuve remplace une brique ancienne pendant que le reste continue de tourner. Il n'y a pas de bascule globale, donc pas de coupure ni de journée de migration. La seule exception est une montée de version majeure de la base de données, planifiée avec vous dans une fenêtre de maintenance.
Entre deux et six semaines selon la brique : une tâche planifiée extraite se livre vite, un écran découpé en étapes demande de la conception avec vos utilisateurs. Chaque lot est estimé et validé séparément, et vous engagez le suivant quand le précédent tourne en production.
C'est fréquent sur un code ancien : pas d'injection de dépendances, des requêtes dans les écrans, des fonctions de deux mille lignes. On ne le réécrit pas pour le tester, on le teste de l'extérieur : Playwright rejoue les parcours réels dans un navigateur et signale ce qui change. Les tests intérieurs viennent ensuite, brique par brique, à mesure que le code neuf remplace l'ancien.
Oui. Vue.js s'accroche à un morceau de page HTML existant et le pilote, sans étape de compilation ni réécriture des autres pages. On l'ajoute sur l'écran qui pose problème, on le retire si l'essai ne convainc pas. React permet aussi de s'ajouter par morceaux aujourd'hui, mais il demande une chaîne de build dès le premier composant : sur un logiciel existant, cette différence compte.
Oui, et c'est souvent le premier lot visible : la vitrine, l'espace de démonstration ou l'inscription en ligne sont ce que vos prospects voient avant l'application. Ils se reprennent avec les mêmes composants graphiques que les écrans modernisés, pour que l'un ne fasse pas mentir l'autre.
Quand il n'y a pas de socle sur lequel greffer : une technologie abandonnée, ou une première version dont l'architecture ne porte pas la charge. Et quand refaire coûte moins cher : un code médiocre dont une grande partie ne fait pas ce que vous voulez se réécrit plus vite qu'il ne se modernise. Dans les trois cas nous le disons dès l'audit, avec le motif. Un logiciel qui tient et fait ce qu'on lui demande ne se refait pas.
Les fonctionnalités redeviennent des évolutions ordinaires, sur un budget annuel de maintenance que vous pilotez. Les montées de version suivantes sont planifiées avant leur échéance, les scans continuent de tourner, et la demande qui avait tout déclenché est livrée. Notre veille signale les évolutions qui méritent un lot, avant qu'elles ne s'imposent.
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.
Équipe française
Vous pourrez communiquer avec nous en français et sans décalage horaire, c'est l'idéal pour être sûr de se comprendre !
Socle technique moderne
Nous travaillons avec des outils professionnels implémentant les meilleurs standards de qualité et de sécurité.
Personnalisation
Le sur mesure vous offre toutes les possibilités de personnalisation qu'il vous faut pour adapter votre logiciel à votre vocabulaire et à vos usages.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.