La reprise de TMA est un exercice bien particulier qui requiert des compétences solides et des profils expérimentés.
En effet, la reprise d’un environnement de développement et d’un code existant est toujours délicate, d’autant plus que cette prestation intervient potentiellement dans un contexte technique problématique ou résultant d’une situation conflictuelle.
Dans ce contexte particulier, l’audit préalable est une étape cruciale qui doit permettre de bien appréhender la solution étudiée afin de pouvoir clairement s’engager en définissant le cas échéant, des niveaux d’intervention spécifiques et raisonnables. Il convient en effet de bien jauger la dette technique quand elle existe afin de ne pas trop en promettre et de limiter par exemple le contrat de TMA à un strict maintien en condition opérationnelle. Les évolutions fonctionnelles seront alors réservées à une remise à plat de l’application dans le cadre d’un nouveau développement.
La première phase de l’audit passe par la réinstallation de l’application cible sur nos environnements de développement. Cette phase implique la plupart du temps nos experts système et réseaux qui viennent en appui des équipes de développements.
Cela permet de bien comprendre l’architecture logicielle en jeu et d’aborder immédiatement les problématiques de versions et de compatibilité avec des environnements à jour. On juge également de la complexité de la plateforme : une application difficile à installer témoigne d’une application complexe ou d’une architecture mal pensée. On étudie également l’organisation et la gestion des sources ainsi que l’ingénierie de déploiement mise en œuvre. Enfin, cette phase permet de tester la qualité de la documentation si elle existe.
La seconde phase de l’audit doit permettre de rentrer dans le code afin de juger de sa qualité : utilisation des bonnes pratiques liées au langage et/ou au framework, qualité des commentaires, organisation du modèle de données.
Pour que cette étape soit efficace, nous intégrons dès la phase d’audit une étape de correction de bugs ou d’analyse d’une fonctionnalité nouvelle spécifiée par le client. Cet audit à dessein permet d’orienter et de borner dans le temps cette analyse initiale.
L’audit nous permet en premier lieu de statuer sur notre capacité à pouvoir assurer ou non la reprise de TMA de l’application cible. En effet, une dette technique insurmontable ou un code source inaccessible sont des exemples rendant toute TMA vaine.
L’audit nous permet également de fixer des pré-requis à cette reprise de TMA : des pré-requis impératifs (comme des mises à jour système ou de version logicielle) et des pré-requis facultatifs que le client peut choisir de suivre ou non mais qui ne remettront pas en cause notre capacité à mener la mission confiée.
Enfin, l’audit nous permettra de définir en accord avec le client, le cadre du contrat de TMA : maintenance corrective, maintenance évolutive, sur un mode forfaitaire ou au temps passé.