Votre logiciel dicte le process. On reprend la main.
Module par module, en commençant par celui qui vous coûte le plus cher. Sans jour de bascule et sans arrêter l'activité.
30 minutes, sans engagement. Réponse sous 24h.
Ce qu'on retrouve à chaque fois.
- Les données sont sur un serveur local, sans API.
- Chaque manque du logiciel est comblé par un tableur.
- L'éditeur ne répond plus, ou facture chaque modification.
- Les équipes ressaisissent les mêmes lignes dans deux outils.
Le vieux logiciel s'éteint tout seul.
- 01
On mesure ce que ça coûte
Quel module fait perdre le plus de temps, et à combien de personnes. C'est celui-là qu'on prend en premier.
- 02
On sort les données
Même sans API. Base, exports, scripts. Ces données sont les vôtres, on va les chercher.
- 03
On remplace un module
Le nouveau tourne à côté de l'ancien. Les équipes basculent quand il fait mieux, pas avant.
- 04
On passe au suivant
Module après module. Pas de grand jour de bascule où toute la boîte retient son souffle.
Pour qui on fait ça.
- PME industrielles, BTP et négoce, de 10 à 250 personnes.
- Entreprises sous un progiciel que l'éditeur ne fait plus évoluer.
- Ateliers et bureaux qui vivent à moitié dans le logiciel, à moitié dans Excel.
Si le logiciel fait le travail et que personne ne s'en plaint, ne changez rien. Une migration se justifie par ce qu'elle vous fait gagner.
Asicar : d'une idée à un ERP complet.
ASICAR
Quatre mois entre la première conversation et un ERP qui fait tourner l'ensemble de leur activité. Ils n'avaient pas d'équipe technique en interne.
Lire l'étude de casVous partez quand vous voulez, avec tout.
- Le code est à vous, sur votre dépôt, à chaque étape.
- La documentation avance avec le code, pas six mois après.
- Une stack standard, que n'importe quelle équipe peut reprendre.
- L'hébergement et les comptes sont à votre nom.
On ne construit pas de dépendance. Le jour où vous arrêtez de travailler avec nous, rien ne s'arrête chez vous.
Les questions qui reviennent à chaque premier appel.
- On ne peut pas arrêter la production pendant six mois.
- On ne l'arrête pas une journée. Le module qu'on écrit tourne à côté de l'ancien, sur les mêmes données. Vos équipes basculent quand il fait mieux le travail — et s'il ne fait pas mieux, on le corrige avant de parler de bascule.
- Nos données sont chez l'éditeur, il n'y a pas d'API.
- C'est le cas presque à chaque fois. On va les chercher dans la base, dans les exports, au besoin avec un script de reprise. Ces données sont les vôtres : l'absence d'API est une contrainte technique, pas un obstacle juridique.
- Et si vous disparaissez en cours de route ?
- Le code est sur votre dépôt dès le premier module, la documentation avance avec lui, et la stack est standard. On a été appelés plusieurs fois pour reprendre ce qu'un autre avait laissé en plan : c'est précisément pour ça qu'on livre comme ça.
- Par quel module faut-il commencer ?
- Par celui qui vous coûte le plus cher, pas par le plus simple à écrire. Ça se détermine en mesurant où passe le temps de vos équipes, et c'est l'objet de l'audit de dépendance : une réponse chiffrée, pas une intuition.
L'audit de dépendance.
Audit de dépendance
Ce qui tourne aujourd'hui, qui sait le maintenir, ce qui casse en premier si cette personne s'en va, et un plan de sortie module par module. Écrit, et utilisable même si vous continuez sans nous.
Une journée sur site, restitution écrite
Le budget se cadre pendant l'appel de trente minutes qui précède. On ne chiffre pas un audit avant de savoir ce qu'il y a à auditer.
Quel module vous coûte le plus cher ?
Dites-moi lequel. On regarde si les données sont sortables et par où on commencerait.
Réponse sous 24h.