Les applications sont éternelles

gabi-gitanLorsqu’un système d’information a été livré, la reprise de donnée terminée, les utilisateurs formés et connectées, le travail des concepteurs développeurs n’est pas terminé.
Arrive la phase dite de Maintenance ou de Maintien en Condition Opérationnelle (MCO). Elle regroupe les actions qui permettent le fonctionnement quotidien de l’application. Les processus doivent fonctionner de la façon la plus fluide possible, et donc ces actions doivent être les moins visibles et les moins couteuses possible. Elles peuvent être regrouper en trois groupes : la gestion des anomalies, l’adaptation à l’environnement, l’accompagnement des utilisateurs.

Les anomalies

Il faut d’abord corriger les anomalies du système. Quelque que soit l’importance des tests réalisés, et même si ceux-ci ont été menés par des perfectionnistes maniaques, il reste des anomalies. Celles-ci peuvent venir de multiples causes, erreurs dans la rédaction du code, imperfections du système technique (la microcoupure du réseau électrique est l’explication définitive du développeur qui n’a pas d’explications aux anomalies qui lui sont signalées), non application des consignes par les utilisateurs (qui lit encore un mode opératoire ?), etc.
Tache ingrate, mais indispensable à la survie de l’application. Le concepteur-développeur se transforme en Sherlock Holmes du numérique, recherchant dans les milliers de lignes du code rédigé où se trouve la minuscule virgule qui manque, la boucle mal fermée. Ecoutons l’avis de quelqu’un qui sait de quoi il parle :
corriger les anos est intéressant à plein de niveaux :
Cela permet de bien voir tous les aspects du projet, que cela soit technique ou fonctionnel, favorisant une vision globale bénéfique. C’est particulièrement intéressant quand on arrive sur une nouvelle mission, un nouveau projet inconnu.
C’est l’occasion de faire le boyscout (d’après la règle éponyme), d’améliorer les choses par petites touches, partout où on passe.…
Enfin, la correction n’est pas forcément facile ou rapide, et cela permet aussi de belles constructions techniques, tout comme les nouvelles fonctionnalités, voire plus encore, puisqu’on a appris des erreurs.
Après corriger des anos a un gros inconvénient :
la dépression
Quand on est un petit peu impliqué, engagé sur un projet, passer ses journées focalisé sur tous les problèmes, avec éventuellement les retours des utilisateurs sous les yeux (favorisant l’empathie) implique une charge émotionnelle. Se focaliser sur les bugs, c’est déprimant. (Voir le texte complet sur le blog de Raphael Lemaire).

Suivre les changements de l’environnement

Un système d’information est fait en fonction du contexte du moment. Le changement du contexte impose de faire évoluer le programme. Evolution de la réglementation, changement d’organisation de l’entreprise,… obligent à modifier le code. Un simple changement dans la TVA, peut s’avérer un cauchemar. D’abord un changement de taux, un passage de 19 à 20%, s’accompagne souvent de modifications plus profondes des règles : changement d’assiette (la liste des produit à taux réduit évolue), des régions à taux particulier (Corse, département d’outre-mer). Ensuite, il faut non seulement changer quelques lignes de programme, mais aussi reprendre les prix sur un grand nombre de produits, éventuellement refaire les étiquetages. C’est là qu’il apparaît que le système d’information ne se résume pas à des lignes de code.

Suivre les progrès des utilisateurs

Mais là où la MCO gagne la partie, c’est lorsqu’elle est capable d’accompagner les utilisateurs dans leurs progrès. Au début, les clients n’utilisent qu’une partie des potentialités de l’application. Ils trouvent le système trop compliqué, refusent de perdre du temps à se former ou de lire les modes d’emploi. Puis ils s’y habituent, commencent à maîtriser les principes et le fonctionnement de l’application, à en explorer les recoins, les fonctionnalités cachées. Là, l’application doit être à même de suivre les nouveaux besoins qui apparaissent.
Google est un bon exemple de système qui a su évoluer avec ses utilisateurs. Au premier coup d’œil c’est toujours la même application, la même page blanche avec une barre de saisie au milieu. Mais en haut de page on trouve nombre d’applications compagnes, traduction, cartographie, messagerie, agenda et annuaire, et maintenant toutes les applications de conservation des données sur le cloud. Cette croissance des fonctionnalités s’est faite progressivement, par développement interne ou rachat, pour construire un ensemble cohérent de fonctionnalités, utilisables sur n’importe quel appareil de l’ordinateur au smartphone.

Vraiment éternelles ?

En évoluant ainsi par petites touches, les applications deviennent éternelles.
C’est ainsi qu’est arrivé le bug de l’an 2000. Pendant longtemps, les concepteurs développeurs estimaient que les deux premiers chiffres de l’année (19) étaient non signifiants puisqu’ils étaient toujours identiques. Lorsque l’an 2000 s’est approché il a bien fallu revoir le code, le corriger pour permettre aux applications de continuer à fonctionner. Car la durée de vie d’une application est quelque chose d’assez imprévisible.
Certaines applications sont construites pour durer. Ce sont des locomotives qui ont nécessité des mois de construction. Ce type d’application peut résister plusieurs dizaines d’années. Lorsque l’équipe d’origine est entièrement partie, elle seule conserve la mémoire des règles métiers. Les raisons du fonctionnement du système sont oubliées et personne n’ose toucher certaines parties du programme. Ce genre de colosse disparaît presque par accident : une évolution technologique, des modifications majeures de l’environnement les rend inutiles ou trop couteuses à maintenir. Ainsi les fusions d’entreprises sont une cause majeure de disparition de ce type d’application, le nouveau management ne supportant pas d’avoir plusieurs applications différentes faisant la même chose.
A l’inverse, certaines applications sont développées vite pour répondre à un besoin urgent ;  le quick and dirty (vite fait mal fait) est une maladie génétique du monde du système d’information. Le management n’a pas le temps d’attendre un travail correct et les concepteurs-développeurs le font avec l’idée que tout cela a une durée de vie très limitée.
Cette idée peut s’avérer fausse. Certaines bidouilles infâmes durent des années, Comme en plus elles ont résolues partiellement le problème, le gain apporté par une solution correctement développée est trop faible pour justifier le remplacement. En somme les applications sont souvent comme le sparadrap du capitaine Haddock, il est difficile de s’en débarrasser.

Cet article, publié dans developpement, système d'information, est tagué , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s