Dans les banques et les assurances, une part importante des traitements repose sur des applications construites il y a longtemps. Elles fonctionnent, elles portent des règles métier précises, et leur documentation est souvent incomplète ou ancienne. Les personnes qui les ont conçues ont parfois quitté l’entreprise.
Quand vient le moment de moderniser, de migrer ou de remplacer ces applications, une question se pose avant toutes les autres : que fait exactement le système aujourd’hui ? La rétro-documentation sert à y répondre.
Ce que l’on appelle rétro-documentation
La rétro-documentation consiste à reconstituer, à partir du système existant, une description fiable de ce qu’il fait. On part du code, des schémas de données, des chaînes de traitement, des paramétrages et des échanges avec les autres applications. On interroge aussi les utilisateurs et les équipes d’exploitation.
Le résultat est un ensemble de documents qui décrivent le système tel qu’il fonctionne réellement aujourd’hui. Cette précision compte : au fil des années, les corrections, les évolutions réglementaires et les contournements ont modifié le comportement réel de l’application.
Pourquoi la modernisation en dépend
Un projet de modernisation compare un état actuel à un état cible. Si l’état actuel est mal connu, plusieurs difficultés apparaissent.
Des règles métier perdues
Une règle de calcul, une exception pour une catégorie de contrats, un contrôle ajouté après un incident : ces éléments se trouvent souvent uniquement dans le code. S’ils ne sont pas identifiés, le nouveau système ne les reproduit pas, et l’écart se découvre en recette ou après la mise en production.
Des estimations fragiles
Sans inventaire précis des fonctions, des interfaces et des volumes, le chiffrage d’une migration repose sur des hypothèses. Les écarts de charge et de délai trouvent souvent leur origine dans un périmètre mal connu au départ.
Une recette difficile à construire
Pour vérifier que le nouveau système se comporte correctement, il faut savoir ce que faisait l’ancien. La rétro-documentation fournit la base des cas de test et des critères d’acceptation.
Une dépendance à quelques personnes
Lorsque la connaissance repose sur deux ou trois experts, chaque absence ralentit le projet. Documenter réduit ce risque et facilite l’intégration de nouveaux intervenants.
Cadrer le travail
La rétro-documentation peut devenir un chantier sans fin si elle n’est pas cadrée. Quelques décisions doivent être prises au départ.
Définir l’usage du document
On ne documente pas de la même façon pour une migration technique, une refonte fonctionnelle ou un audit. L’usage détermine le niveau de détail attendu : description des flux pour une cartographie, règles de gestion détaillées pour une réécriture, correspondance des données pour une migration.
Délimiter le périmètre
Il s’agit de lister les applications, les modules, les traitements et les interfaces concernés, et d’exclure explicitement ce qui ne l’est pas. Un périmètre écrit évite les extensions implicites.
Choisir les livrables
Les livrables usuels sont une cartographie applicative, un dictionnaire de données, la description des traitements et de leurs enchaînements, le catalogue des règles de gestion et la liste des interfaces. Le format doit être défini à l’avance et validé par ceux qui utiliseront ces documents.
Identifier les sources et les interlocuteurs
Accès au code source et aux environnements, documentation existante même partielle, disponibilité des experts métier et des équipes d’exploitation : ces conditions se vérifient avant de démarrer, car elles déterminent le rythme du travail.
Commencer par un échantillon
Dans nos missions, nous recommandons de ne pas lancer la rétro-documentation complète d’emblée. Nous proposons de commencer par un échantillon représentatif : un module, une chaîne de traitement ou un domaine fonctionnel.
Cet échantillon a plusieurs fonctions :
- valider le format des livrables avec les futurs lecteurs, avant de le généraliser ;
- mesurer la charge réelle par unité documentée, ce qui permet une estimation fondée du reste du périmètre ;
- révéler les difficultés propres au système : code peu structuré, paramétrages externes, dépendances non répertoriées ;
- donner au client un livrable concret pour juger de la qualité du travail avant de s’engager davantage.
L’échantillon doit être choisi pour sa représentativité. Un module trop simple donne une estimation optimiste ; un module exceptionnellement complexe donne une estimation pessimiste. Le bon choix est souvent un module courant, avec quelques règles métier significatives et au moins une interface.
Les points d’attention
Vérifier avec les utilisateurs
Le code dit ce que le système fait. Les utilisateurs disent ce qui est utilisé, ce qui est contourné et ce qui est devenu inutile. Les deux sources sont nécessaires.
Distinguer le constat de l’interprétation
Un document de rétro-documentation décrit l’existant. Les anomalies ou les règles qui semblent obsolètes doivent être signalées comme telles, sans être corrigées dans la description. La décision de les conserver ou non appartient au projet de modernisation.
Tenir la documentation à jour
Si le système existant continue d’évoluer pendant le projet, la documentation doit suivre. Un processus simple de mise à jour, lié aux évolutions livrées, évite qu’elle devienne obsolète avant la fin de la migration.
Protéger les données
Le travail sur un système existant donne accès à des données réelles. La rétro-documentation doit se faire dans l’environnement du client, avec des données de test ou anonymisées lorsque c’est possible.
En résumé
La rétro-documentation est une étape discrète. Elle transforme une connaissance dispersée en une base partagée, sur laquelle les décisions de modernisation peuvent s’appuyer. Cadrée par un usage clair, un périmètre écrit et un premier échantillon, elle reste un travail maîtrisé en coût comme en délai.