Réflexions d’un entrepreneur TI (7) : variations du coût d’entretien d’une application TI

C’est l’autre question à cent mille balles, comme disent nos amis Français : combien cela coûtera-t-il à « maintenir » cette application ?   Dans ce cas-ci, par contre, la réponse ne relève pas de mille et un facteurs mais bien de deux facteurs dominants qui feront varier le coût d’entretien; soit, principalement, l’architecture et la documentation !

S’agit-il d’un billet sur la Gestion de Projets ?  Loin de là.  Et Dieu sait que la gestion de Projets a fait couler beaucoup d’encre en TI depuis une décennie et que cela mériterait toute une série de billets en soi… que nous ferons peut-être en 2010.  Mais pour les besoins de ce billet, nous prendrons pour acquis que tous les développeurs appliquent de bonne pratique en matière de Gestion de Projets.

La liste des facteurs ayant un impact sur les coûts d’entretien d’une application TI ne se limite pas à ces deux facteurs, mais ce sont, à notre avis, les deux principaux.

Variations libres sur un thème de « Maintenance » d’une application TI

Il faut documenter, on ne saurait assez le dire et le redire !  Et malgré cela, on trouve encore en entreprise nombre d’applications non-documentées dont l’entretien sera… extrêmement coûteux… voire de 2 à 3 fois plus cher en termes de maintenance. Pourquoi ?  Parce qu’elles ne sont pas documentées.  C’est le vieux principe de la saucisse Hygrade !

L’entretien entraînera toujours des frais minimums que l’on ne saurait quantifier, même dans un monde idéal; trop de facteurs entrant en ligne de compte.

Plus concrètement, la documentation, c’est la mémoire du Développement, le fil d’Ariane de l’application; c’est ce qui nous permettra de comprendre pourquoi on avait fait les choses de cette manière plutôt que telle autre, à quoi servait exactement cette série d’instructions obscures, quelles étaient les contraintes qui ont forcées tels choix de procédures, etc.

Voilà pourquoi la documentation est si importante.  Cela prend du temps mais il est impératif  de bien documenter l’application sur trois plans; soit sur l’Installation, sur la Technologie et sur les Usagers.

Documentation

Dans la majorité des cas, chacun des items suivants « self-explanatory » comme disent nos amis du sud.  L’idée-maitresse est de mettre suffisamment d’information de telle sorte que des programmeurs-analystes qui n’ont pas travaillé au développement de l’application puissent en comprendre les fondements et la logique et puissent, le cas échéant, la corriger et la remettre en selle, si elle « crash » !!!

Docu Installation

• Environnement
  • Matériel
  • Logiciel
• Description de l’application (processus d’affaires, modules et constituants)
• Ordre d’installation
• Privilèges
• Tests
• Retour en arrière (Roll Back) en cas d’implantation échouée

Docu Technologie

• Backup (sauvegarde)
• Niveaux
• Fréquence
• Outils  de Monitoring (fonctionnalités très souvent escamotées… à tort)
• Procédure de récupération en cas de désastre
• Schémas de la Structure de Données
• I / O – Intrants / Extrants de l’application
• Interfaces (protocole de communication avec l’application et l’environnement TI, si nécessaire)

Docu Usagers

• Administrateurs (qui sont-ils : rôles, fonctions, manipulations, etc.)
• Droits et Privilèges (pour les différents niveaux / types d’usagers)
• Intrants / Extrants (I/O)
• Fonctions et Processus (que fait l’application et quelles valeurs produit-elle ?)

CONCLUSION

Peut-être que la parole est d’argent et que le silence est d’or mais en TI, plus qu’ailleurs… les écrits n’ont pas de prix; vous pouvez documenter maintenant ou payer plus tard.

Bonne semaine,

Michel et Denis