Pôle Applicatif & TMA
Applications métier : maintenir, faire évoluer, et migrer seulement si c'est justifié
Une application qui rend le service attendu n'a pas besoin d'être réécrite. Elle a besoin d'être documentée, testée, et de ne plus dépendre d'une seule personne.
Le réflexe du marché face à une application ancienne est de proposer une réécriture. C'est la mission la plus rentable à vendre et la plus risquée à acheter : elle immobilise un budget important pendant douze à vingt-quatre mois, et elle recrée souvent les mêmes défauts avec une syntaxe plus moderne.
Notre réflexe est différent. Nous commençons par reprendre l'existant : cartographier, documenter, poser des tests de caractérisation, réduire la dépendance à une personne unique. Cette première étape coûte une fraction d'une réécriture et supprime le risque immédiat. La migration reste possible ensuite, module par module, quand un besoin métier la justifie.
Les symptômes que nous voyons le plus souvent
- Une seule personne connaît l'application, et elle part ou approche de la retraite
- Aucune documentation d'architecture ni de règles de gestion
- Le développement se fait directement en production, faute d'environnement de test
- La version du socle technique n'est plus supportée par l'éditeur
- Chaque évolution prend trois fois plus longtemps que prévu
- Les demandes d'intégration avec d'autres outils sont systématiquement refusées faute de moyen
Notre façon de traiter le sujet
L'audit de reprise avant toute décision
Deux à quatre semaines pour cartographier ce qui existe réellement, identifier la dette et écrire une note exploitable par un tiers. C'est ce document qui permet ensuite d'arbitrer entre maintenir et migrer, sur des faits plutôt que sur une intuition.
Des tests de caractérisation avant toute modification
Sur un code non testé, la première chose à écrire n'est pas une correction mais un test qui décrit le comportement actuel, y compris s'il est bizarre. Sans cela, chaque correction crée deux régressions ailleurs.
Ouvrir plutôt que réécrire
Quand le besoin est d'intégrer l'application au reste du système d'information, exposer une API REST sur l'existant règle le problème pour une fraction du coût d'une réécriture, et permet de brancher une interface moderne sans toucher au cœur métier.
Deux personnes sur chaque dossier
La cause du risque n'est pas la technologie ancienne, c'est la dépendance à une personne unique. Nous formons systématiquement deux personnes sur chaque application maintenue, y compris quand une seule suffirait à la charge.
Les services de ce pôle
Questions fréquentes
Une application ancienne doit-elle forcément être remplacée ?
Non. Le critère n'est pas l'âge mais quatre questions : le socle technique est-il encore supporté, l'application est-elle documentée, plus d'une personne sait-elle la faire évoluer, et répond-elle encore au besoin métier. Si les quatre réponses sont bonnes, la remplacer serait dépenser un budget important sans contrepartie.
Combien coûte une reprise de patrimoine non documenté ?
L'audit de reprise va de 3 900 € à environ 8 000 € selon la taille et l'ancienneté de l'application. À l'issue, vous disposez d'une note exploitable et d'un chiffrage ferme de la stabilisation. C'est volontairement une petite dépense : elle sert à décider, pas à engager.
Que faire si le développeur historique part dans deux mois ?
Commencer immédiatement, et faire l'audit en binôme avec cette personne pendant qu'elle est encore là. Le transfert de connaissances tacite est ce qui a le plus de valeur et c'est exactement ce qui disparaît au départ. Deux semaines en binôme valent trois mois de rétro-ingénierie ensuite.
Vingt minutes suffisent pour savoir si nous sommes utiles
Aucune présentation commerciale. Vous décrivez votre besoin ; nous vous disons s'il entre dans notre périmètre, dans quel délai et à quel budget. Si ce n'est pas pour nous, vous le saurez pendant l'appel.