Reprise de logiciel existant / Reprise hors PHP
Votre logiciel tient encore, sa technologie ne suit plus
Flash et ActionScript, WinDev, Access, Delphi, VB6, un client lourd installé poste par poste : le logiciel fait son travail depuis dix ou quinze ans, et le monde autour de lui l'a lâché. Nous ne lisons pas ce code, et nous ne ferons pas semblant. Nous analysons le code qu'il contient et nous le reconstruisons sur des technologies actuelles.
Et si vous attendiez cette occasion pour la version 2 que l'ancien ne fera jamais, c'est le moment de la demander.
Comment savoir que c'est obsolète
Ce n'est pas le logiciel qui lâche, c'est ce qui l'entoure
Quatre signes devraient vous alerter et vous pousser à vous interroger pour trouver une solution.
Le navigateur affiche un carré gris à la place de l'application
L'interface reposait sur un module que les navigateurs ont cessé d'exécuter. Flash s'est arrêté en janvier 2021, Silverlight et les applets Java avant lui. Le serveur tourne toujours, mais plus personne ne peut s'en servir sans une vieille machine gardée exprès.
Il faut garder un ancien poste pour le lancer
Le logiciel s'installe poste par poste et un système d'exploitation récent ne veut plus de lui. On garde un Windows qui ne reçoit plus de mise à jour, débranché du réseau si on est prudent, et on croise les doigts.
Une seule personne sait le modifier
Le développeur WinDev, Delphi ou Access qui l'a écrit est encore là, ou l'était jusqu'à l'an dernier. Ce qu'il sait n'est écrit nulle part. Chaque modification est devenue un service qu'on lui demande, puis qu'on a cessé de demander.
L'éditeur ou l'hébergeur a annoncé une date
Fin de commercialisation, fin de support, fermeture de l'hébergement, retrait d'une version : vous avez reçu un courrier, et la date est dedans. Ce n'est plus une question de choix, c'est une question de calendrier.
Faut-il changer maintenant ?
Pas forcément tout de suite, mais avec une date
Un logiciel qui marche est la meilleure situation pour reconstruire : on a le temps, et on a le modèle. Ce qui décide du calendrier, ce n'est pas l'âge du code, c'est l'un de ces quatre événements.
La cartographie vient d'abord. Elle dit ce qui est utilisé, ce qui presse, et ce qui peut attendre. Personne ne lance une reconstruction par peur.
Une date connue
Un navigateur, un système ou un hébergeur qui retire ce dont le logiciel dépend : la reconstruction commence avant, avec assez de marge pour basculer sans précipitation.
Une personne
Celui qui sait le modifier part, prend sa retraite ou n'a plus le temps. Tant qu'il est là, il est la meilleure source de la cartographie. Après, c'est le code seul qui parle, et il parle moins bien.
Une évolution bloquée
Un nouvel établissement, un accès depuis l'extérieur, un client qui veut consulter ses dossiers : ce que l'outil ne sait pas faire, et qu'il ne saura jamais. La V2 attendue est la reconstruction.
Rien de tout ça
Alors rien ne presse. On cartographie ce qui existe, on pose une date de revue, et le logiciel continue de faire son travail. Une carte à jour vaut plus qu'une reconstruction lancée par peur.
La V2 que vous attendiez
Vous ne remplacez pas votre logiciel, vous faites enfin sa version 2
Le cabinet qui ouvre un deuxième établissement, l'atelier dont les commerciaux veulent consulter les dossiers depuis la route, le négoce dont le client veut suivre sa commande : la reconstruction n'est pas un détour avant ces évolutions, c'est le moment où elles deviennent possibles.
Quinze ans de règles métier
Chaque cas particulier ajouté depuis 2010 est une règle que l'entreprise a payée une fois, en la découvrant. Le vieux logiciel est le cahier des charges le plus exact qui existe. On le lit avant d'écrire, on ne le devine pas.
- Règles extraites du code et des écrans
- Vérifiées par ceux qui les appliquent
- Écrites avant d'être codées
Ce qui était impossible devient la commande
Un deuxième établissement, un accès depuis chez soi, des profils par site, un client qui consulte son dossier, une tablette sur le terrain : le vieux logiciel ne le fera jamais. Le nouveau est fait pour ça dès le premier écran, ce n'est pas une option ajoutée après.
- Multi-établissements et droits par profil
- Accessible depuis un navigateur, partout
- Portail client ou partenaire
Les utilisateurs gardent leurs repères
Un écran que l'équipe pratique depuis dix ans se reproduit, un écran qu'elle subit se repense. On distingue les deux avec elle avant de dessiner. La V2 doit lui faire gagner quelque chose dès le premier jour, sinon elle garde l'ancien.
- Écrans connus reproduits
- Écrans subis repensés
- Formation courte, parce que rien n'est dépaysant
La méthode
Cartographier, reconstruire, basculer
L'ancien logiciel reste en service jusqu'au bout. C'est ce qui rend la reconstruction supportable pour ceux qui l'utilisent tous les jours.
Cartographier ce qui existe vraiment
Nous regardons l'outil fonctionner avec ceux qui l'utilisent, nous exportons les données, nous écrivons les règles métier. Ce qui n'est plus utilisé n'est pas repris. Le livrable est une carte du logiciel que vous avez, souvent la première qu'il ait jamais eue, et une date : ce qui presse, ce qui peut attendre.
- Observation de l'outil en usage, pas en démonstration
- Règles écrites, vérifiables par le métier
- Ce qui ne sert plus ne se reconstruit pas
Reconstruire par lots, l'ancien toujours en service
Le nouveau logiciel se construit sur Symfony et Vue.js, par lots qui apportent chacun quelque chose aux utilisateurs. L'ancien continue de tourner : personne ne perd son outil pendant la reconstruction. Quand le métier repose sur un calcul, une suite de cas connus prouve que le nouveau donne les mêmes résultats.
- Par lots utiles, dans l'ordre de ce qui fait le plus mal
- Cas de référence rejoués à chaque mise à jour
- Recette sur un environnement dédié avant production
Basculer, puis exploiter
Reprise finale des données, période de double fonctionnement si nécessaire, retour arrière possible. Puis l'ancien s'éteint, et le logiciel entre dans notre contrat de maintenance : il ne dépendra plus jamais d'une seule personne ni d'une technologie que le monde abandonne.
- Bascule préparée : données, utilisateurs, retour arrière
- Extinction quand plus personne ne s'en sert
- Maintenance applicative
Ce que reprendre veut dire ici
Nous ne reprenons pas le code, nous reprenons tout le reste
Quatre choses passent de l'ancien logiciel au nouveau, et elles valent plus que le code. C'est par elles que commence chaque reprise.
Les données
Exportées, nettoyées, et surtout comprises : ce que chaque colonne veut dire, ce qui est encore utilisé, ce qui est mort. C'est le premier actif du projet, et souvent le seul qui passe tel quel.
- Export et nettoyage
- Sens de chaque colonne
- Ce qui est encore utilisé
Les règles métier
Un calcul, une validation, un enchaînement d'étapes : elles vivent dans le code, dans les formulaires, dans les macros, et dans la tête de ceux qui les utilisent. Nous les écrivons avant de les coder.
- Calculs, seuils, validations
- Écrites avant d'être codées
- Vérifiées par le métier
Les utilisateurs et leurs habitudes
Ce qu'ils font chaque jour, dans quel ordre, et ce qu'ils contournent. Le nouveau logiciel doit leur faire gagner quelque chose dès le premier jour, sinon ils gardent l'ancien.
- Observation en usage
- Ordre réel des opérations
- Ce qu'ils contournent
Les écrans qui marchent
Tout n'est pas à redessiner. Un écran que les utilisateurs connaissent et qui fonctionne se reproduit, un écran qu'ils subissent se repense. On distingue les deux avant de dessiner quoi que ce soit.
- Écrans connus : reproduits
- Écrans subis : repensés
- Tri avant tout dessin
Votre situation actuelle
Chaque technologies avec ses limites habituelles
Chaque technologie a eu des avantages au moment où elle a été sélectionné pour votre projet.L'informatique a évolué et le temps à fait naître des contraintes que vous n'aviez pas prévu.
Une application Flash ou ActionScript
Une interface riche, construite entre 2005 et 2015, souvent pour un simulateur, un configurateur ou un outil de formation. Les navigateurs ne l'exécutent plus depuis janvier 2021. Le serveur, lui, tourne toujours, et c'est souvent lui qui porte le métier ou vous l'utilisez encore en client lourd.
Ce qu'on y trouve
Une interface que personne ne peut plus ouvrir, des calculs parfois côté client, et un serveur en PHP ou en Java qui a continué de vivre.
Ce qui se garde
Le métier et les données. Le serveur, s'il est en PHP : il se reprend et se migre au lieu d'être refait.
Ce qui tombe
Toute l'interface, réécrite en Vue.js, et les calculs qui vivaient dedans, rapatriés côté serveur où ils se testent.
Un logiciel WinDev, Delphi ou VB6
Le client lourd des PME : installé sur chaque poste, rapide, dense, avec une base de données locale ou sur un serveur du bureau. Il a été écrit par une société de services régionale ou un indépendant, et il fait tourner un cabinet, un atelier, un négoce depuis quinze ans.
Ce qu'on y trouve
Des écrans très denses que les utilisateurs pratiquent vite, des règles de calcul partout, une base HFSQL, Paradox ou SQL Server locale, et une personne qui sait.
Ce qui se garde
Les données, les règles de calcul, et les écrans qui marchent : reproduits en mieux, pas redessinés pour le plaisir.
Ce qui tombe
L'installation poste par poste, la base locale, la dépendance à une seule personne. Le nouveau s'ouvre dans un navigateur, depuis n'importe quel établissement.
Une base Access ou un classeur avec ses macros
Le logiciel a commencé par une table, puis un formulaire, puis une macro. Dix ans plus tard, c'est l'outil de gestion de toute l'entreprise, partagé sur un lecteur réseau, et il se corrompt de temps en temps. Pour Excel, c'est une page à part.
Ce qu'on y trouve
Un modèle de données qui a grandi sans plan, des formulaires qui font tout, du VBA que personne ne relit, et des données précieuses.
Ce qui se garde
Les données, après nettoyage, et les règles enfouies dans les requêtes et les macros, écrites noir sur blanc pour la première fois.
Ce qui tombe
Le fichier unique, le verrou quand deux personnes l'ouvrent, la sauvegarde qu'on oublie. Une vraie base, avec des droits et un historique.
Une autre technologie que plus personne ne fait vivre
ASP classique, ColdFusion, 4D, Lotus Notes, PowerBuilder, une applet Java, un module Silverlight : la liste est longue et nous ne la connaissons pas par cœur. Ce qui compte, c'est que le projet qu'elle contient se lit sans elle : par ses écrans, ses données et ses utilisateurs.
Ce qu'on y trouve
Un logiciel qui a survécu à son époque, un métier bien rodé, et aucun développeur à recruter pour le toucher.
Ce qui se garde
Le métier et les données, comme partout. La cartographie se fait en regardant l'outil fonctionner, pas en lisant son code.
Ce qui tombe
La technologie, en entier. Le nouveau logiciel est une application Symfony et Vue.js comme les autres, maintenue comme les autres.
Pourquoi une refonte ici, et pas ailleurs
Ce que la reconstruction vous apporte en plus
Nous ne vendons jamais la refonte par défaut : sur une application PHP, nous reprenons le code et nous le migrons brique par brique. Ici, elle est la réponse honnête : personne chez nous ne peut maintenir du WinDev, du Delphi ou une interface Flash, et un prestataire qui vous promet le contraire vous laissera avec le même problème dans deux ans.
Ce que nous savons faire, c'est reconstruire un logiciel qui dure. Et une reconstruction apporte trois choses que l'ancien n'avait pas.
Une documentation complète, reconstruite avec vous
- Écrite pendant la cartographie : Les règles métier, le modèle de données et les parcours utilisateurs sont écrits avant d'être codés, et vérifiés par ceux qui les appliquent. C'est souvent la première documentation que le logiciel ait jamais eue.
- Tenue à jour à chaque intervention : Chaque lot livré met à jour ce qui change. Notre équipe la maintient tout au long de nos interventions, pas seulement à la livraison : le logiciel ne dépendra plus jamais de ce qu'une seule personne a en tête.
Un code plus sûr, contrôlé à chaque livraison
- Analyse statique : PHPStan relit chaque ligne à chaque mise à jour du code et refuse ce qui ne tient pas : type incohérent, cas non traité, appel obsolète. Une erreur se voit avant la recette, pas en production. C'est le même outillage que notre audit de code PHP, appliqué cette fois à un code que nous écrivons, et nous expliquons ce qu'il attrape sur un projet Symfony.
- Scan des CVE : Les dépendances du projet sont confrontées aux failles publiées à chaque livraison, puis en continu dans le cadre de la gestion des vulnérabilités. Une faille connue ne reste pas installée sans que quelqu'un le sache.
- Scan de sécurité : ZAP attaque l'application comme le ferait un inconnu, depuis l'extérieur, sans lire le code. C'est la différence avec un client lourd sur un Windows débranché : le nouveau logiciel est exposé au web, et il est testé pour ça. En complément, OSV-Scanner scanne les images Docker.
Une confiance retrouvée dans votre outil
- Une base saine : Un socle Symfony et Vue.js que nous exploitons depuis des années, maintenu par une équipe et non par une personne, avec des versions dont la fin de support est connue à l'avance.
- Les évolutions que vous n'osiez plus demander : Quand chaque modification était un risque, on a cessé d'en demander. Sur une base saine, un deuxième établissement, un accès depuis l'extérieur ou un portail client redeviennent des demandes ordinaires, chiffrées et planifiées.
- Un calendrier que vous choisissez : Plus de courrier d'éditeur qui fixe la date à votre place. Les mises à jour se prévoient, se budgètent, et s'inscrivent dans le contrat de maintenance.
Deux reprises menées sans arrêter l'existant
Un éditeur qui ferme, une technologie en fin de vie : ce que nous en avons fait
Deux déclencheurs différents, la même méthode : cartographier ce qui est utilisé, reconstruire par lots, et garder l'ancien en service jusqu'à la bascule.
BMPB France : l'éditeur arrête son activité
Un logiciel d'éditeur remplacé par un outil interne, avant la fin de l'année annoncée
BMPB gère l'assistance commerciale externalisée de ses clients avec le même logiciel d'éditeur depuis plus de douze ans. Un jour, l'éditeur les prévient qu'il cesse son activité à la fin de l'année : douze ans de campagnes, de scripts d'appel et d'historique client sur un outil qui n'aura plus personne derrière lui.
Nous avons cartographié ce que les équipes utilisaient vraiment, repris les données, et reconstruit un logiciel interne sur Symfony et Vue.js : campagnes d'appels, scripts configurables, tableaux de bord, portail client et API. L'ancien outil est resté en service jusqu'à la bascule.
CAPRENOV+ : un client lourd sur une technologie en fin de vie
Garder la technologie que l'équipe maîtrise, et préparer la transition qu'on sait inévitable
CAPRENOV+ est un simulateur de rénovation énergétique installé sur le poste, sans interface web, écrit en ActionScript. Plusieurs tentatives de refonte n'avaient pas abouti. En 2017, nous avons pris le cadrage, l'organisation et le pilotage de la version 3 avec l'équipe de 15 personnes de PIA Production, l'ancienne version restant en production jusqu'à la bascule.
Nous avons fait le choix de conserver la technologie que le client maîtrisait, et de mettre en place les méthodes qui préparent une transition inévitable : séparation nette des moteurs de calcul thermique et d'aide financière du code de l'interface, tests automatisés rejoués sur des simulations de référence, documentation technique et fonctionnelle du projet. En 2019, nous avons refondu le backoffice et l'espace client sur Symfony et Vue.js.
Votre logiciel a dépassé sa technologie ?
Montrez-le-nous en fonctionnement
Un client lourd, une interface qui ne s'ouvre plus, une base Access partagée : décrivez à Nicolas ce qu'il fait tourner, qui l'utilise, et ce que vous voudriez qu'il fasse enfin. On regarde ensemble ce qui presse, ce qui se récupère, et ce qui se reconstruit en premier. Premier échange gratuit, sans engagement.
Appel de 30 min → Cartographie de l'existant → Plan par lots
GLOSSAIRE
Le vocabulaire d'une reconstruction
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.
- EOL (End of Life)
- La date à partir de laquelle une technologie ne reçoit plus rien : ni correction, ni mise à jour de sécurité, ni support de l'éditeur. Flash l'a atteinte en décembre 2020, Windows 7 en janvier 2020, chaque version de PHP ou de Symfony la connaît à l'avance (le modèle en trois phases est expliqué sur <a href="/technologies/fin-de-support/">la page fin de support</a>). Le logiciel écrit avec n'est pas cassé. Il est seul, et chaque faille découverte après cette date le reste.
- Client lourd
- Un logiciel installé sur chaque poste de travail, par opposition à une application qui s'ouvre dans un navigateur. WinDev, Delphi, VB6 et Access produisent des clients lourds. Rapides et denses, ils ne sortent pas du bureau, se mettent à jour poste par poste, et dépendent du système installé sur chacun.
- Base locale
- Une base de données qui vit sur un poste ou sur le serveur du bureau, dans un fichier que le logiciel ouvre directement. Un seul lieu, une sauvegarde qu'il faut penser à faire, et aucun accès depuis l'extérieur. La reconstruction la remplace par une base hébergée, sauvegardée et accessible partout.
- Cartographie
- La carte du logiciel tel qu'il est utilisé : quels écrans, quelles données, quelles règles, par qui et dans quel ordre. Elle se fait en regardant l'outil fonctionner, pas en lisant son code. C'est le premier livrable, et souvent la première documentation que le logiciel ait jamais eue.
- 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é.
- Règles métier
- Ce que le logiciel sait de votre activité : un calcul, un seuil, une validation, un enchaînement d'étapes. Elles vivent dans le code, dans les formulaires, dans les macros, et dans la tête de ceux qui les utilisent. Nous les écrivons avant de les coder, pour que le métier les vérifie.
- Cas de référence
- Une situation dont le résultat attendu est connu, transformée en test automatisé : un dossier, un devis, une simulation, avec les données en entrée et le résultat que l'ancien logiciel a produit. La suite complète est rejouée par la machine à chaque modification du code, et le moindre écart arrête la livraison. L'ancien logiciel fournit les résultats attendus : c'est le meilleur usage qu'on puisse en faire avant de l'éteindre.
- Environnement de recette et double fonctionnement
- Une copie du nouveau logiciel, séparée de la production, où vous validez chaque livraison avant que vos utilisateurs la voient. Pendant la reconstruction, l'ancien et le nouveau y tournent côte à côte : les mêmes opérations sont passées dans les deux, et les résultats se comparent. Un écart se découvre là, sur un environnement dédié, jamais en production.
- Bascule
- Le moment où les utilisateurs passent de l'ancien outil au nouveau. Elle se prépare : reprise finale des données, formation, et un plan pour revenir en arrière si quelque chose ne va pas. Elle ne se fait jamais dans la précipitation.
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.
« Nicolas est intervenu auprès de notre équipe de développement web et son intervention a été aussi utile que personnalisée.
Bien plus qu'un expert technique, il a donné des pistes d'évolution qui ont ouvert de nouvelles perspectives à l'équipe et donc à l'entreprise.
Nous avons donc décidé de continuer l'expérience par des interventions régulières. »
« Une belle expertise dans le développement !
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! »
Pour aller plus loin
Approfondir votre réflexion
No-code, prototype de laboratoire, MVP d'un freelance, application générée par une IA : la première version a fait son travail. C'est une autre page, et un autre raisonnement.
Le cas le plus fréquent de cette page a sa propre page : le classeur qui est devenu l'outil de toute l'entreprise.
Alors le code se reprend et se migre brique par brique, sans reconstruction. C'est une autre page, et une autre méthode.
Ce qui se passe après la bascule : un logiciel qui ne dépend plus d'une personne ni d'une technologie abandonnée, maintenu dans la durée.
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 !
Les deux. Nous reprenons le projet : son métier, ses données, ses utilisateurs, ses écrans, et la responsabilité de le faire vivre. Nous ne reprenons pas le code, parce que personne chez nous ne peut le maintenir. Le logiciel est reconstruit sur Symfony et Vue.js, pendant que l'ancien continue de tourner.
Parce que ce n'est pas lui qui va lâcher, c'est ce qui l'entoure : le navigateur qui cesse d'exécuter son interface, le système qui ne l'installe plus, l'éditeur qui ferme, la personne qui le connaît et qui part. Un logiciel qui marche est la meilleure situation pour reconstruire : on a le temps, et on a le modèle. Ce qui ne marche pas, c'est d'attendre que l'un de ces quatre événements décide de la date à votre place.
Oui, c'est le principe. Il reste en service jusqu'à ce que le nouveau couvre ce qui est utilisé. La bascule se prépare : reprise des données, période de double fonctionnement si nécessaire, retour arrière possible. Rien ne s'arrête un vendredi soir. Il faut tout de même savoir que ce n'est pas toujours vous qui décidez : un hébergeur peut cesser de supporter la version dont le logiciel dépend et l'éteindre à une date qu'il fixe, et une faille de sécurité critique, ou une attaque en cours, peut imposer de le couper du jour au lendemain. C'est pour ça que la cartographie commence par ce qui presse : si l'ancien s'arrête avant l'heure, on sait ce qu'il faut reconstruire en premier.
Pas forcément. Ce qui ne s'exécute plus, c'est l'interface. Si la partie serveur est en PHP, elle se lit, et elle se reprend : c'est un autre parcours, où le code se migre vers Symfony brique par brique au lieu d'être reconstruit. L'interface, elle, se réécrit en Vue.js. Les deux se mènent ensemble.
En le prouvant, pas en l'affirmant. Nous écrivons des tests automatisés : un programme construit pour valider le nouveau logiciel, qui rejoue une suite de cas dont le résultat est connu à chaque mise à jour du code, et arrête la livraison au moindre écart. C'est ce que nous mettons en place dès que le métier repose sur un calcul, et c'est l'ancien logiciel lui-même qui fournit les résultats attendus. La plupart du temps, ce travail met d'abord en évidence des erreurs de l'outil actuel, ou plus exactement des manques : un cas limite jamais traité, un arrondi qui varie, une règle appliquée à moitié. On décide alors avec vous ce que le nouveau doit reproduire, et ce qu'il doit enfin corriger.
C'est le cas le plus fréquent, et il a sa propre page : transformer un fichier Excel en logiciel sur mesure.
Oui : suivant la technologie nous pourrons vous proposer une reprise ou un refonte. Un outil no-code, un prototype de laboratoire, un MVP fait par un freelance ou une application générée par une IA ne sont pas obsolètes : ils ont fait leur travail, et l'étape est finie. C'est le moment de passer à l'échelle.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.