- TMA
Votre développeur WinDev part à la retraite dans trois mois
C'est la situation la plus fréquente et la plus mal traitée. Ce qu'il faut faire pendant qu'il est encore là, et l'erreur qui coûte le plus cher.
· 4 min de lecture · AzerOps
Une application de gestion tourne depuis quinze ans. Une seule personne la connaît. Elle part dans trois mois. Cette situation se produit chaque semaine dans des entreprises françaises, et la façon dont elle est traitée détermine le coût des cinq années suivantes.
L'erreur la plus coûteuse
Attendre la fin du processus d'achat pour commencer.
Le réflexe naturel est de consulter des prestataires, comparer, négocier, signer, puis démarrer. Ce parcours prend deux à quatre mois dans une ETI. Quand il aboutit, la personne est partie, et le prestataire retenu doit tout reconstituer par rétro-ingénierie.
Deux semaines passées en binôme avec le développeur historique valent trois mois de rétro-ingénierie après son départ. C'est le seul cas où nous recommandons de démarrer une mission courte avant la fin de la négociation contractuelle, quitte à la traiter comme une prestation ponctuelle.
Ce qu'il faut capturer, dans l'ordre
Les règles de gestion non écrites. Pourquoi ce calcul comporte une exception pour les contrats antérieurs à 2015. Pourquoi cet état exclut telle catégorie. Ce savoir n'existe que dans une tête et il ne se déduit pas du code : le code dit ce qui est fait, pas pourquoi.
Les procédures d'exploitation. Que faire quand le traitement de nuit échoue. Qui appeler chez l'éditeur. Où se trouvent les licences. Quel est le mot de passe du compte de service, et où il est stocké.
La cartographie des intégrations. Quels fichiers sont déposés par quels systèmes, à quelle heure, dans quel format. Ce sont ces dépendances non documentées qui cassent en premier.
Les pièges connus. « Ne jamais relancer ce traitement deux fois. » « Ce champ doit rester à zéro sinon l'état de fin de mois est faux. » Chaque application ancienne en compte une dizaine, et chacune coûte un incident si elle est découverte par l'usage.
La méthode qui fonctionne
Ne demandez pas à la personne d'écrire la documentation. C'est ce qu'on lui demande toujours, elle n'en a pas le temps, et le résultat est une liste d'évidences pour elle.
Faites plutôt travailler quelqu'un d'extérieur à côté d'elle, qui pose des questions naïves et écrit. La documentation produite par un tiers qui découvre l'application est utilisable par un autre tiers ; celle produite par l'expert ne l'est pas, parce qu'elle omet tout ce qui lui semble évident.
Le livrable à exiger
Une note de reprise exploitable par un tiers, testée par un test simple : donnez-la à un développeur qui n'a jamais vu l'application et demandez-lui de réaliser une évolution mineure. S'il y parvient sans appeler personne, la note est bonne.
Et après
Formez deux personnes, pas une. Reproduire une dépendance unique avec un prestataire au lieu d'un salarié ne résout pas le problème, il le déplace. La clause à faire écrire dans le contrat de TMA est simple : deux interlocuteurs identifiés nommément, connaissant le dossier, avec obligation d'information en cas de changement.