Reprendre une application dont personne n'a la documentation

Une application critique tourne depuis douze ans. Personne ne l'a documentée. La personne qui la connaît part. Vous consultez trois prestataires et les trois proposent une réécriture chiffrée entre douze et vingt-quatre mois.

C'est la réponse la plus fréquente et c'est rarement la bonne.

Pourquoi la réécriture est la réponse par défaut

Elle est plus facile à vendre : le périmètre est celui d'un projet neuf, la technologie est moderne, l'équipe commerciale sait la présenter. Elle est aussi plus confortable à livrer : personne n'a besoin de comprendre le code existant.

Le problème est qu'elle recrée souvent les mêmes défauts avec une syntaxe plus récente. Les règles de gestion accumulées sur douze ans ne sont écrites nulle part ailleurs que dans ce code. Les réécrire signifie les redécouvrir une par une, généralement au moment où un utilisateur signale que le nouveau système donne un résultat différent de l'ancien.

L'alternative : la reprise

La reprise consiste à faire de l'application existante quelque chose de maintenable, sans la remplacer. Elle se déroule en quatre temps.

L'audit de reprise. Deux à quatre semaines pour cartographier ce qui existe réellement : modules, dépendances, traitements planifiés, intégrations, points de fragilité. Le livrable est une note exploitable par un tiers, c'est-à-dire par quelqu'un qui n'a jamais vu l'application.

Les tests de caractérisation. 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 quand ce comportement est bizarre. Un test de caractérisation ne dit pas « ceci est correct », il dit « ceci est ce que fait le système aujourd'hui ». Sans ce filet, chaque correction crée deux régressions ailleurs.

La reproductibilité. Un environnement de test reconstructible et une restauration de sauvegarde effectivement exécutée. Beaucoup d'applications anciennes sont développées directement en production faute d'environnement, ce qui est le vrai risque, bien avant la vétusté du langage.

La sortie de dépendance. Deux personnes formées au lieu d'une. C'est la seule mesure qui traite la cause réelle du problème, qui n'est pas la technologie mais la concentration de la connaissance.

Le calcul honnête

Un audit de reprise coûte entre quatre et huit mille euros selon la taille. Une stabilisation complète, quelques dizaines de milliers. Une réécriture d'application métier de taille moyenne, plusieurs centaines de milliers, avec un risque de dépassement élevé et une période de double exploitation pendant laquelle vous payez les deux systèmes.

Le rapport est d'un ordre de grandeur. Cela ne veut pas dire que la réécriture est toujours mauvaise, cela veut dire qu'elle doit être décidée après l'audit et non avant.

Les quatre questions qui décident

Le critère n'est pas l'âge de l'application mais :

1. Le socle technique est-il encore supporté par son éditeur ?
2. L'application est-elle documentée, ou peut-elle l'être en quelques semaines ?
3. Plus d'une personne sait-elle la faire évoluer ?
4. Répond-elle encore au besoin métier ?

Si les quatre réponses sont bonnes, remplacer l'application revient à dépenser un budget important sans contrepartie fonctionnelle. Si deux ou plus sont mauvaises, la question de la migration se pose sérieusement — mais elle se pose avec des chiffres, après l'audit.

Si la personne clé part dans deux mois

Commencez immédiatement, et faites l'audit en binôme avec elle pendant qu'elle est encore là. Le transfert de connaissance 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.

C'est la seule situation où nous conseillons de démarrer sans avoir fini de négocier le contrat.