Organiser la maintenance de son site web 2/3 – Les cycles de maintenance corrective
La mise en place de la nouvelle version d’une application web nécessite, au moins dans les premiers temps, la mise en place de correctifs pour les bugs d’usage. Ces derniers surviennent sur des zones de l’application testées durant la recette, mais qui peuvent connaître des dysfonctionnements lors de certaines actions d’utilisateurs pourtant considérer normales.
Second volet de notre série sur la maintenance d’un site ou d’une application web, cet article vous propose de voir pourquoi il est important de mettre en place un cycle de maintenances correctives, avant d’en voir la réalisation.
Pourquoi mettre en place un cycle de maintenance corrective
La correction en flux tendu, c’est à dire au fur et à mesure de la découverte des bugs est très souvent utilisée, notamment dans la tierce maintenance applicative des sites web. Si elle permet de donner une impression de très grande réactivité, elle pose rapidement plus de problèmes qu’elle en résout, tout particulièrement dans le cas d’une application au cycle de vie important. On ne compte alors plus les effets de bord : régressions sur d’autres parties de l’application, rustines mal posées, et, à terme, code impossible à maintenir. Le comble pour une application sensée évoluer dans le temps.
La solution la plus pérenne consiste donc en la mise en place d’un véritable cycle de maintenance corrective formalisé. Connu de tous, il permet d’anticiper les livraisons. Planifié, il permet d’organiser le planning des développeurs et des équipes de test. Régulier, il donne de la visibilité et rassure les clients, au prix de la perte de cette trompeuse idée efficacité que donne la réactivité.
Mise en place du cycle de maintenance corrective
Le cycle de maintenance corrective fait partie intégrante du cycle de vie de l’application. Il vise à corriger les nouveaux bugs d’usage, mais également les régressions résultant de la livraison précédente.
J’entends déjà les chantres de l’Extrême Programming me faire remarquer que, dans le cadre de développements conduits par les tests, il n’y a pas de régressions possibles. C’est parfaitement faux, les tests unitaires et les tests fonctionnels peuvent parfaitement passer sur une application par ailleurs inutilisables. Nous avons connu le problème avec Typo 5.0.3 : l’intégralité des tests passait, mais un bug Javascript rendait le contenu étendu de l’éditeur inutilisable en édition. La meilleure solution réside certainement dans la mise en place de tests sur l’interface graphique, Javascript compris, par exemple à l’aide de Selenium IDE, là où des mocks sur les vues se révèlent inefficaces. Cependant, l’expérience m’a montré que ces derniers étaient beaucoup trop lourds à maintenir sans une équipe dédiée, puisqu’ils doivent être réécrits au moindre changement de DOM dans les pages. Mais ceci n’est pas l’objet de cet article, et nous y reviendrons une autre fois.
Un cycle de maintenance corrective nécessite trois choses :
- La centralisation des incidents qualifiés.
- La planification des corrections.
- Le cycle de maintenance lui-même.
Centralisation des incidents qualifiés
Dans la centralisation des incidents qualifiés, la notion de qualification est presque plus importante que celle de centralisation. Chaque incident doit en effet être qualifié avant d’être transmit à l’équipe de maintenance, par exemple par l’assistance utilisateurs ou le service client.
L’anomalie qualifiée répondra donc aux questions suivantes :
- Quelle est l’URL de la page posant problème ?
- Quelle scénario permet de reproduire le bug ? La reproduction est-elle systématique ?
- Quel est l’environnement de l’utilisateur ? Système d’exploitation, navigateur, restrictions éventuelles dues à un proxy d’entreprise…
- Le bug est-il reproductible ?
- Le récipiendaire de la déclaration d’incident parvient-il à reproduire l’anomalie ?
Dans la majorité des cas, on aura affaire à une erreur de manipulation des utilisateurs. Mais pas toujours.
Une fois le bug qualifié par ce premier interlocuteur, il sera transmis à l’équipe de maintenance qui pourra ouvrir un incident sur son outil de suivi des incidents. Il en existe de nombreux, dans de nombreux langages, qui permettent également le suivi des sources. Citons Redmine et Retrospectiva en Ruby on Rails, Trac en Python, ou Jira en Java avec son excellente applet de capture d’écran pour les outils en mode hébergé. En mode SAAS, ma préférence va à Version1 ou à Lighthouse pour son interfaçage avec Github.
Assignation et planification des bugs
Une fois déclarés, les bugs sont assignés aux développeurs et planifiés sur un tableau de livraison mensuelle, en tenant compte de la charge de travail pour chacun, tests compris. On aura donc un tableau du type :
| Développeur | Semaine 1 | Semaine 2 | Semaine 3 | Semaine 4 | Semaine 5 |
|---|---|---|---|---|---|
| Développeur 1 | Bugs | Bugs | Bugs | Bugs | Bugs |
| Développeur 2 | Bugs | Bugs | Bugs | Bugs | Bugs |
| Développeur 3 | Bugs | Bugs | Bugs | Bugs | Bugs |
| Développeur 4 | Bugs | Bugs | Bugs | Bugs | Bugs |
À propos de l’assignation des bugs, il peut être bon, dans l’idéal, que tout le monde travaille sur toutes les parties de l’applications. Il est certes plus simple de corriger un code que l’on connaît, cependant on en vient très rapidement à se spécialiser, jusqu’à la défection du spécialiste de…
Le cycle de maintenance
Le cycle de maintenance en lui-même peut se dérouler sur une ou deux semaines, en fonction de la complexité du cycle d’exploitation de l’application. Il se déroule peu ou prou de cette manière :
J + 0 : entrée des bugs qualifiés au tableau de correction de la semaine. On a la visibilité sur la liste des corrections à livrer en fin de phase. Début des corrections. Les corrections sont comitées dans la branche de maintenance, et reportées sur le trunk.
J + 2 : fin des corrections de la semaine et freeze de la branche. On va pouvoir passer en phase de tests.
J + 3 : vérification de l’ensemble des bugs traités par l’équipe de tests, et fermeture des bugs le cas échéant. Passage du ou des scénari de test validant le bon fonctionnement de l’application.
J + 4 : si aucune régression n’est détectée, on tag la version de la semaine qui sera fournie à l’exploitation.
Et la semaine d’après, on recommence…
Cet article est volontairement incomplet, et ne reprend que les grands principes de la mise en place d’un tel cycle de corrections. Il doit notamment être adapté au cycle d’exploitation de l’application qui peut être autrement plus compliqué que “je test, je livre, je déploie”. Retenez cependant deux choses particulièrement importantes : l’interface avec le service utilisateurs est indispensable pour isoler les développeurs du cycle d’exploitation, et, sauf bug particulièrement critique, il est impératifs de conserver le rythme donné, même contre les contraintes d’exploitation.
