Confessions d’une dév en TMA

La TMA (ou Tierce Maintenance Applicative) correspond à la maintenance d’applications, de logiciels et/ou de sites web, par une tierce personne, à plus ou moins long terme.

Oui, c’est une définition plutôt vaste et la TMA peut prendre diverses formes en fonction des clients et/ou des contrats qui nous lient à eux, certaines pouvant paraître totalement ésotérique (y compris pour moi-même qui vit la maintenance au quotidien depuis plusieurs années).

Dans mon boulot, la TMA peut recouvrir pas mal d’activités différentes allant de la correction des anomalies plus ou moins tordues à la réalisation d’évolutions plus ou moins variées, en passant par la prévention des risques et/ou la mise en place d’adaptations nécessaires pour que l’application ne finissent pas complètement rouillée (par exemple utilisable uniquement avec IE6 ou déployable uniquement en PHP4). Cela correspond à peu près à tout ce qui peut permettre de maintenir l’application en conditions opérationnelles au quotidien. Et en faisant tout cela, on se retrouve parfois aussi à connaître le fonctionnement de l’application mieux que le client lui-même et à assurer le support des utilisateurs, ce qui peut être assez comique.

À mon humble avis, il n’y a pas vraiment de solution miracle universelle quand on travaille en TMA, tout dépendra du contexte et du projet qui nous est confié et c’est hautement variable. Je vais essayer de vous raconter quelques anecdotes et de vous donner des pistes pour prendre la maintenance (qui n’est pas toujours très drôle) du bon pied et dans la bonne humeur.

Quelques petites perles

Si les super projets ne sont pas exclus en TMA, il ne faut pas se faire trop d’illusions : on récupère souvent en TMA des applications plus ou moins mal ficelées. Avec certaines on risque même de se noyer sous la dette technique. Pas de panique, tout va bien, relativisons et prenons le avec humour. Alors pour rigoler un peu, voici quelques petits exemples de perles plus ou moins graves que j’ai eu l’occasion de rencontrer.

 Exemple n°1 : lire la documentation PHP, ce serait trop simple.

substr(date('Y'), 2, 4)

Ce morceau de code a été trouvé dans une application ayant une bonne dizaine d’années, qui était encore fonctionnelle et ne posait pas de problèmes majeurs. Encore une fois cet exemple est parfaitement fonctionnel, mais utiliser date('y') aurait été beaucoup trop simple. Dans l’application en question, l’accumulation des petits détails comme ça rendait le code source presque digne d’une fusée shadokienne.

Exemple n°2 : utiliser des valeurs magiques sans les expliquer.

if(isset($_POST['acceder'])){
 $_POST['email_recuperer'] = 'foo@bar.com';
}
if(isset($_POST['recuperer'])){
 $_POST['email_acceder'] = 'foo@bar.com';
 $_POST['password'] = 'foo@bar.com';
}

Ce morceau de code (sans le moindre commentaire) a été retrouvé dans une très ancienne application. Au départ, on avait supposé que cela servait à faire une exception ou encore qu’il s’agissait d’un test de débuggage qui aurait été oublié. Après analyse, il s’est avéré que ce morceau de code n’avait plus aucune utilité et son emplacement pouvait laisser des sérieux doutes sur le fait qu’il ait servi un jour, à part peut-être comme piège à doigt pour retenir l’attention d’un développeur qui passerait là par hasard.

Exemples n°3 et 4 : quand on s’aperçoit que l’ancien développeur a un peu souffert.

/**
 * Si toi aussi tu ne comprends pas ce que fait cette méthode, envoie "HELP" au 8 12 12
 */

/* contrainte étrange pour vérifier la présence d'un paramètre id ..?
 * formalisme très étrange ...
 * ou c'est nimporte quoi ou j'ai raté une étape ... non tu n'as pas loupé d'étape */
$isset_pk = (!isset( $isset_pk ) || $isset_pk) && isset( $params ['id'] );

Quand on trouve des commentaires dans ce genre dans une application qu’on reprend, on se dit que les anciens développeurs ont quand même dû sacrément déguster pour boucler l’application en question. La situation n’est pas vraiment drôle mais comment ne pas sourire quand on tombe sur un truc pareil et ne pas le partager ? Certes on va probablement déguster aussi, mais déjà on se sont moins mal quand c’est quelqu’un d’autre qui a produit le code source concerné. Et on aura au moins pu rigoler un peu avant de commencer.

Revenons au début

Maintenant qu’on s’est gentiment moqué, je vous avoue que la majorité des perles relevées ont été détectées pendant la prise en main des applications concernées et corrigées depuis. Si on l’oublie parfois, la TMA ne se résume pas à la maintenance au quotidien. Avant même d’y venir on passe d’abord par une phase de prise en main de l’application dont on va devoir assurer la maintenance. Avant de savoir marcher, un bébé apprend à ramper ou au moins à se tenir sur ses jambes. C’est un peu la même chose avec la TMA, soigner la prise en main est essentiel pour partir sur une base saine.

Pendant cette phase initiale, le but est de faire connaissance avec le projet, dans tous ses aspects, que ce soit logiciel, fonctionnel, métier ou humain, puis de mettre en place les rails sur lesquels on se basera pour intervenir ensuite au quotidien.

Outre le cœur de l’application sur lequel on va travailler, le but est de comprendre son contexte, le métier qu’elle permet d’aider, les utilisateurs pour lesquels on est susceptible d’intervenir et de prendre la température du projet. Cela passe par diverses réunions ou rencontres avec les intervenants du projet et si possible avec quelques utilisateurs ou encore avec l’ancienne équipe ayant géré le projet. C’est important pour établir une relation de confiance, mais aussi pour que la prise de connaissance soit concrète. Je vais probablement enfoncer une porte ouverte, mais il est quand même largement plus facile de proposer une solution adaptée aux problématiques rencontrées quand on comprend à quoi cette solution doit servir. Et parfois, on ne peut avoir ce contexte qu’en rencontrant effectivement les intervenants. Par exemple, il m’est déjà arrivé de m’apercevoir pendant une réunion fonctionnelle qu’à peine un petit tiers de l’application que je devais prendre en charge était réellement utilisé et que le restant pouvait être complètement laissé de côté. La situation était un peu absurde et n’était évidemment décrite nulle part dans le brief de départ du projet.

La rédaction d’un plan d’assurance qualité (PAQ) est aussi importante pour décrire le projet et les intervenants, définir la méthodologie qu’on appliquera pendant toute la durée de la TMA et d’établir le niveau de qualité auquel on veut s’astreindre. C’est un document clé auquel les différents intervenants du projet pourront se référer, que ce soit le client, ou l’équipe qui assurera la maintenance.
Plus ce document est complet, mieux c’est. Inutile d’aller jusqu’à noter votre liste de course dessus, mais il ne faut pas hésiter à décrire les choses les plus évidentes concernant le projet, y compris la liste des éléments documentaires fournis lors de la prise en main, dont il faut avoir connaissance pour assurer la maintenance et qu’il faudra tenir à jour pendant la vie du projet. Connaissez-vous le client qui ressort magiquement une spécification inconnue de son chapeau après plusieurs mois/années ? Si la réponse est non, vous avez bien de la chance.
Un PAQ doit aussi expliciter le workflow de traitement des demandes, la façon de les qualifier et les délais de réponse et/ou de traitement pour chaque grand type de demande (anomalie, adaptation, évolution, etc) et pour chaque niveau de priorité. Ce point est important pour que chacun ait bien conscience des enjeux et qu’on ne finisse pas par avoir 100% de demandes critiques ou urgentes au risque de perdre complètement de vue la notion d’urgence et de ne plus savoir ce qu’il est préférable de traiter en priorité.
De plus, en fonction de l’application ou du site, il sera important de noter les périodes pendant lesquelles la réactivité devra être maximale et les périodes plus calmes afin que les équipes en face soient dimensionnées en conséquences. Il est assez évident qu’un problème sur un site de location de ski sera plus critique et demandera une réponse beaucoup plus rapide s’il survient en décembre que s’il survient en plein mois de juillet. Dans d’autres cas, il n’y a pas de période de plus fortes activités ou celles-ci sont moins évidentes à discerner d’un point de vue profane, seul le client pourra éclaircir ce point et prévenir les équipes afin qu’un gros événement ne leur tombe pas dessus à la dernière minute et sans préavis. Faut-il encore faire prendre conscience de ce fait au client lors de la prise en main.

Entre les réunions et le PAQ, l’un des points que certains clients demandent et qui peut paraître assez obscur quand on ne le connaît pas, c’est la rédaction d’un rapport d’étonnement. Aussi étrange que cela puisse paraître, c’est un petit document qui ne peut qu’être bénéfique à votre prise en main car il s’agit de lister tous les points susceptibles d’être des atouts ou d’être pénalisant pour le maintien en conditions opérationnelles de l’application qui vous a été confiée (que ce soit au niveau des documents fournis, du code source de l’application ou de sa base de données) et de faire, le cas échéant, des suggestions d’amélioration. Si on ne peut pas forcément aller jusqu’à faire un audit complet, on peut parfois quand même lever quelques lièvres et commencer à faire connaissance avec la dette technique de l’application. C’est en rédigeant ce genre de document que j’ai trouvé la majorité des perles précédentes. Cela permet de mettre en relief le contenu du plan d’assurance qualité et de s’assurer que les critères de satisfaction choisis pour la qualité du code source à produire sont bien cohérents avec la qualité actuelle du code source de l’application.

Et encore avant cela ?

A mon avis, le meilleur moyen de récupérer des supers projets en TMA reste encore d’avoir réalisé soi-même ces projets et d’avoir gagné la confiance de son client pour la suite et pour la vie du projet lorsque la période de garantie sera échue. Dans cette optique, on peut envisager de réaliser chaque nouveau projet en gardant bien en tête ce qui est important pour que la maintenance soit ensuite facilitée et que le futur du projet se passe bien. Cela peut d’ailleurs être un argument pour se distinguer des agences qui cherchent juste à faire des bons coups et qui ont tendance à ensuite jeter ensuite le bébé avec l’eau du bain.

Il y a des centaines de méthodes différentes pour gérer les projets, certaines sont plus efficaces que d’autres. Je vais juste me contenter de vous indiquer quelques points qui sont importants pour que la maintenance se passe bien ensuite :

• la mise en place de convention de codage/nommage et leur respect,
• la mise en place d’outil de suivi des pannes et/ou des problèmes techniques,
• la documentation, la documentation et encore la documentation.

Quelque soit le framework, le CMS et/ou l’outil choisi, il est important de bien préparer son projet et de commencer par établir des conventions de codage et/ou de nommage qui serviront de fil rouge pendant le projet. Peu importe la convention choisie, il ne s’agit pas de se fâcher et la convention la plus compliquée n’est pas nécessairement la meilleure. Pour moi, la meilleure convention de codage est celle que l’équipe de développement sera capable de s’astreindre à suivre. Établir des règles c’est bien, les suivre c’est mieux. En effet, il sera encore plus important de s’assurer que les conventions choisies au départ sont bien respectées pendant toute la réalisation et que les commentaires sont pertinents pour qu’un tiers puisse comprendre ce que fait le code source, d’autant plus si plusieurs personnes travaillent sur le projet et/ou doivent se relayer. Le but étant que la lisibilité du code source ne soit pas dépendante du nombre de personnes y ayant participé.

Pour les applications plus complexes ou plus sensibles, il faut mettre l’accent sur les informations enregistrées en cas de panne ou de problèmes techniques critiques qui sont importantes pour résoudre rapidement les anomalies. Si vous comptez sur le fait qu’il n’y aura pas de panne, que la base de données sera toujours accessible, que le serveur d’email ne tombera jamais, que les utilisateurs ne feront aucune bêtise ou que les feuilles ne tomberont pas des arbres en automne, votre client ou vous-même risquez fort d’aller au devant de belles déconvenues. Les solutions pour enregistrer des logs et le type de logs enregistrés peuvent être aussi variables que les projets sur lesquels on travaille, il faut en choisir une en fonction des spécificités de votre projet.
Je prendrai juste un exemple avec une application de candidature en ligne en interne, fortement reliée à différents webservices du client très hétérogènes. Pour celle-ci l’authentification passait par un SSO, un certificat, puis par 3 webservices différents pour permettre l’initialisation des dossiers de candidatures. Pour corser le tout, on ne pouvait pas accéder au serveur de production, seulement à celui de recette et encore en passant par un VPN et deux autres systèmes complémentaires pour montrer patte blanche, et on ne nous avait communiqué aucun des réglages mis en place sur les différents autres services. Et évidemment à chaque fois qu’un des webservices ne répondait pas correctement (faute d’un réglage adéquat), c’était toujours de notre faute d’après le client et il était de notre responsabilité de résoudre le problème sur notre application puisque c’était notre application qui ne fonctionnait pas. A l’époque aucun système de logs n’avait été prévu dans le cadre du forfait de réalisation de l’application, ce qui était une grossière erreur car chaque anomalie de ce type nous prenait un nombre d’heures quasi incalculable pour tout décortiquer et finir systématiquement démontrer que c’était les réglages d’un des webservices externes qui étaient en faute et que le client devait modifier pour que les choses rentrent dans l’ordre. Dans ce cas, nous avons rapidement décidé de mettre en place à nos frais un système de log complémentaire sous forme de fichier plat quotidien pour gérer chacune des erreurs susceptibles de se produire avec chacun des webservices utilisés, et cela s’est rapidement montré payant puisque nous avons ensuite largement regagné notre temps par derrière en mettant moins de 2 minutes chrono à déceler chacune des anomalies suivantes et aujourd’hui nous avons toujours cette application en TMA.

La documentation est aussi un point important pour que la maintenance soit plus facile, mais surtout la documentation utile. Il ne s’agit pas de documenter pour le plaisir de documenter, surtout si le client ne l’a pas demandé, mais de simplement conserver les clés qui permettront à n’importe qui de reprendre assez facilement le projet (y compris soi-même dans quelques mois/années) et notamment de l’installer sur un serveur blanc sans que ça plante ou encore de le réinitialiser sans tout perdre. Cela dépendra du contexte et de la complexité de l’application.

Si on prend un cas simple avec un site basé sur un CMS, cela peut se résumer à expliquer les éventuels modules/plugins/thèmes/etc. utilisés (et leur raison), ainsi que les éventuels contenus « magiques » nécessaires pour que cela fonctionne bien (rubriquages, menus, mots clés, compte utilisateur, etc.). Le premier listing sera aussi très important lorsqu’une montée de version se profilera à l’horizon car il permettra de d’établir les points d’attention pour vérifier la compatibilité des éléments annexes installés avec la nouvelle version du CMS. Le second le sera tout autant si un jour le client s’aperçoit qu’il a fait quelque chose qu’il n’aurait pas du et a cassé son propre site (ou qu’il s’est fait pirater), oups.

Personnellement je travaille assez peu avec des CMS, mais j’ai toujours, à minima, un listing partagé des points importants à faire pour effectuer les mises en production, afin d’être sûre de ne rien oublier y compris les points les plus triviaux. Dans mon cas c’est d’autant plus important que je n’ai aucun accès sur les serveurs de mes clients principaux et c’est leur équipe d’exploitation qui installe les applications à partir des livrables applicatifs et du mode opératoire que je leur fournis. C’est un sacré exercice de rigueur, mais on en retire d’assez grands avantages car n’importe quel intervenant est ensuite capable d’effectuer la livraison (y compris quand on se chope la grippe de façon imprévue la veille et qu’un collègue doit vous relayer au pied levé).

En conclusion, sans aller jusqu’à faire de la sur-qualité, il s’agit de s’assurer que la qualité de l’application produite soit suffisante pour que celle-ci puisse vivre plusieurs années et surtout que les potentiels points faibles soient bien connus afin qu’ils puissent être améliorés par la suite. Et cela se documente également.

Le mot de la fin

Quelques points important pour prendre la maintenance du bon pied : bien se mettre à l’écoute du client, communiquer et instaurer un climat de confiance, apprendre à connaître sa dette technique et bien communiquer à son sujet, penser au futur et surtout garder le sourire.

Il ne faut pas se leurrer, notre code d’aujourd’hui sera probablement truffé de petites maladresses, de failles ou de dette technique demain ou après-demain. Personnellement certaines des erreurs que je retrouve assez facilement aujourd’hui sont des erreurs que je faisais moi-même il y a quelques mois/années et j’en fais probablement encore aujourd’hui que je détecterai mieux demain. Pour moi, cela reste un des points important à garder à l’esprit non seulement pour apprendre chaque jour de nouvelles choses, mais aussi pour rester humble et aller de l’avant.