Dans la gestion des systèmes d’informations, les projets bénéficient bien souvent d’une meilleure visibilité que les applications, du fait des nouveautés apportées, des impacts qu’ils auront sur les utilisateurs au moment du déploiement… Du cadrage projet à la mise en production, les méthodes de gestion de projet sont aujourd’hui bien ancrées dans l’organisation des DSI avec toute la panoplie d’outils et d’indicateurs associés. Le passage en maintenance de l’application mérite souvent, lui, d’être plus préparé.

Une préoccupation encore trop sous-estimée

Les deux constats suivants permettent d’illustrer la sous-estimation de l’importance du MCO (Maintien en Condition Opérationnelle) des applications :

• Une gestion de portefeuille des projets SI (ou PPM pour Projet Portfolio Management), souvent outillée, s’est par exemple fortement développée dans la plupart des entreprises ces dernières années. En revanche, on rencontre rarement des DSI ayant mis en oeuvre une démarche de gestion du portefeuille d’application partagée (ou APM pour Application Portfolio Management).
• Les référentiels de gouvernance et de bonnes pratiques pour les processus de la DSI se sont fortement développés au cours de la dernière décennie, mais ils ne couvrent pas de façon claire et homogène l’ensemble des activités que devra gérer un responsable de la maintenance d’une application. L’approche CMI couvre bien les processus de développement, mais plutôt pour de gros projets. Et si Itil couvre effectivement la mise à disposition d’applications existantes, il concerne plutôt la partie production et non la maintenance évolutive. Enfin, Cobit propose une vision « macro de la DSI », avec une implication du responsable de la maintenance éclatée sur plusieurs des 34 processus au sein les domaines « Planifier et organiser », « Acquérir et implémenter », « Délivrer et supporter », « Surveiller et évaluer ».

La complexité et les enjeux du MCO d’une application sont ainsi souvent sous-estimés : une fois le projet terminé et le système mis en production, le gros du travail est terminé !… Pourtant, une fois l’application ouverte aux utilisateurs, reste à en assurer la stabilité et la pérennité. Cette sortie parfois brutale du « mode projet » implique de nouveaux engagements, de nouveaux acteurs, de nouvelles contraintes… Et tout l’enjeu devient alors de mettre en place l’organisation et les outils qui permettront de sécuriser la production tout en prenant en compte les besoins des nouveaux utilisateurs.

Les problématiques du maintien en condition opérationnelle d’une application, et a fortiori d’une grosse application, sont à prendre en compte à la fois par le responsable de la maintenance, mais aussi par le chef de projet, qui doit anticiper de nombreux points pour assurer la délivrance d’une application qui soit gérable par la suite.

Du projet à MCO : de forts déséquilibres à anticiper

Après mise en production de l’application, les changements apportés feront l’objet de versions (lots d’évolutions ou de corrections). Chacune de ces versions peut être vue comme un projet. Et plusieurs d’entre eux sont menés en parallèle par les mêmes ressources. Une situation qui engendre une organisation matricielle, avec des contentions sur les ressources et les environnements, mais aussi des problématiques supplémentaires à celle d’un projet unique.

En mode maintenance, les relations entre les différents acteurs évoluent, avec un rééquilibrage de l’implication des différents acteurs, et un niveau de complexité supplémentaire :

• En mode projet, les principaux échanges ont lieu entre MOA, AMO et MOE (équipes de développement/ intégration) avec des pics de relation avec les utilisateurs sur la conduite du changement, mais aussi des sollicitations ponctuelles du futur exploitant-hébergeur.

• En mode maintenance, les relations sont plus équilibrées entre l’ensemble des acteurs : MOA, AMO, MOE (équipes de maintenance), exploitant-hébergeur et avec les utilisateurs.

Chaque acteur de cet ensemble a souvent une représentation déformée de l’importance de l’application.
Ainsi, un bon exercice pour le chef de projet puis le responsable de la maintenance consiste à s’imaginer régulièrement « à la place de chacun des autres acteurs », d’appréhender ses enjeux et de visualiser le projet ou l’application sous cet angle. L’exploitant est-il informé de l’arrivée prévisionnelle de 100 nouveaux utilisateurs qui auront certainement un impact sur les performances ? Le métier est-il sensibilisé aux impacts du futur renouvellement de TMA et notamment de la période de ralentissement de la maintenance évolutive ? L’utilisateur est-il informé de l’impact des prochaines livraisons sur son travail le jour de la livraison et par la suite ?…

Autre problématique, le turn-over des équipes. En fin de long (trop long ?) projet, de nombreux participants ont changé de poste, les équipes des prestataires ont été renouvelées et les effectifs sont souvent réduits après la mise en production. Si le responsable projet et le responsable MCO sont différents, une phase de transfert de plusieurs mois est à privilégier avant le démarrage du MCO. Il est aussi indispensable que le responsable projet et responsable maintenance identifient en amont les ressources clefs et s’assurent du maintien d’un minimum de ces dernières par rapport à toutes les problématiques à traiter sur les premiers trimestres suivant la mise en production. Enfin, il est souhaitable d’anticiper l’impact d’un éventuel changement de sponsor ou d’un transfert de responsabilité du donneur d’ordre. Les difficultés générées par le turn-over des équipes sont importantes au démarrage, mais perdureront toute la vie de l’application si elles ne sont pas correctement prises en compte.

Une différence notable porte également sur l’équilibre entre « applicatif » et « donnée ». En mode projet, dans la majorité des cas, « l’énergie » est surtout consacrée à l’applicatif (interface utilisateur et traitements), même s’il existe des problématiques d’initialisation et de reprise de données. En configuration MCO, un équilibre nouveau est à trouver entre les activités consacrées à la gestion de l’applicatif et celles consacrées à la gestion des données (analyses, mises en qualité, traitement de rejets…). Il peut en résulter la prise en compte dans l’activité de maintenance d’un nombre important de « chantiers », avec un planning spécifique et indépendant des versions.

Enfin, dans ce nouveau contexte, le nombre de processus récurrents nécessitant une gestion « au fil de l’eau » s’avère plus important qu’en mode projet. La collection des outils de pilotage du chef de projet (planning, plan de charge, gestion des risques…) reste pertinente, mais sera à compléter par des outils d’un responsable d’« activité » : indicateurs de pilotage par les processus, tableau de bord…