Quand les petits projets représentent un gros budget

dossier Management de projets
Quand les petits projets
représentent un gros budget...
Pourquoi s’intéresser içi à la
maintenance des applications ?
C’est un véritable casse-tête pour les
services informatiques. Les budgets de
maintenance applicative dérapent de
10% à 15% par an en moyenne dans les
situations que nous observons. La
question qui se pose est donc de savoir
où s’arrêtent les projets informatiques et
où commencerait une maintenance
applicative pilotée et maîtrisée.
Dominique Moisand
Secrétaire Général de l’AFAI
Le portefeuille des applications
dans les grands comptes est
techniquement hétérogène et
difficile à piloter et à maintenir.
Le recours à l’externalisation
(TMA) est parfois vu comme la
seule solution tant les budgets
de maintenance dérivent d’année en année. Nous avons
demandé à Dominique Moisand
qui a dirigé l’ouvrage « maîtrise
d’ouvrage des projets informatiques » de nous donner son
point de vue sur ce sujet difficile.
Comment se passe
la transition entre projet
informatique et maintenance ?
Le passage en « maintenance » signe
théoriquement la fin du mode projet.
Ceci se traduit très concrètement par
une démobilisation des équipes du
maître d’œuvre, surtout lorsqu’elles
s’appuient sur des contrats de réalisation au forfait, ce qui laisse un grand
vide du côté de la Direction
Informatique. Ce vide, on s’empresse de
le combler en prolongeant le contrat
d’une partie de l’équipe de réalisation
ou en passant un contrat de tierce
maintenance applicative (TMA), lorsque
celui-ci n’a pas été souscrit avec la
réalisation elle-même.
Le vent de panique qui entoure cette
transition est préjudiciable à la mise au
point d’une solution de maintenance
adaptée et pilotée.
• La revue n° 76 - Juillet 2004
La fin du projet ne représente
donc pas un point de départ
solide pour la suite ?
16
Non. Les projets ont du retard, la maîtrise
d’œuvre (et les intégrateurs) n’en sont
pas toujours responsables et refusent
d’en supporter les conséquences
financières au-delà d’un certain seuil. Il
faut donc trouver des solutions contractuelles qui permettent d’habiller la suite.
On a d’abord recours à l’avenant puis, un
jour ou l’autre, se posera la question de
la mise en service, éventuellement sur
un périmètre réduit, d’une première
version du projet. La zone d’ombre entre
la période de test et d’amélioration de
l’application et la recette définitive, ce
que l’on aurait souhaité trouver dans
une période de garantie dont on a déjà
consommé le budget, pourra parfois
basculer en contrat de maintenance.
Dans cette situation, trop fréquente
malheureusement, le client se retrouve
seul responsable de terminer le projet
qu’il avait pensé confier au forfait à un
tiers. Il est difficile dans ces conditions
de jeter les bases d’un contrat de TMA
solide, ce qui pousse à avoir recours à la
bonne vieille formule de la « régie » avec
les difficultés de maîtrise des coûts et
des délais qui l’accompagne.
Quels sont les composantes
essentielles d’un contrat de TMA ?
Un contrat de TMA comprend deux
volets :
• La maintenance curative : elle concerne
la fiabilisation de l’application, les
corrections de bogues et à l’amélioration des performances. Ce volet inclut
en général les modifications nécessaires
pour assurer les montées de version sur
les composants du SI utilisés par l’application.
• La maintenance évolutive : il s’agit des
évolutions fonctionnelles qui proviennent soit des demandes de la maîtrise
d’ouvrage soit des évolutions réglementaires. Pour ce dernier cas, on peut
choisir d’isoler le volet « réglementaire »
lorsque le partenaire est supposé le
maîtriser (c’est le cas, par exemple sur le
réglementaire lié à la paie ou à la comptabilité).
Est-ce que l’on ne s’éloigne pas
du mode projet dans tout cela ?
Oui et non, la maintenance curative est
bien bordée à condition de partir d’une
situation de départ assez saine. J’ai en
tête un contrat de maintenance curative
qui dure depuis plus de 18 mois sur une
application qui avait été développée au
forfait par un grand intégrateur…
D’autres situations apparaissent, en
termes de cohérence des architectures
amenant à des interventions lourdes
sans valeur ajoutée directe sur le plan
fonctionnel.
Management de projets dossier
Que devient la relation
entre maîtrise d’ouvrage et
informatique dans ce cadre ?
Comme je l’ai dit plus haut, le passage
en maintenance a pour premier résultat
de démobiliser la structure projet. La
MOA est en général représentée à deux
niveaux distincts :
• Le niveau des utilisateurs fédérés
autour d’un key-user ou d’un comité de
suivi de l’application. Ce niveau décide
d’évolutions limitées (confort, changements mineurs) correspondant à des
charges de travail inférieures à une
vingtaine de jours.
• Le niveau de décision de la MOA qui
décide du bien fondé d’évolutions
majeures.
Face aux demandes de la MOA, les
représentants de l’informatique sont en
général assez démunis car les seuls
acteurs mobilisés sur le projet sont des
réalisateurs. L’arbitrage MOA / MOE
fonctionne mal, d’autant plus mal que
les réalisateurs sont facturés plus ou
moins au temps passé.
Cette situation est critique dans la maintenance des progiciels. Les réalisateurs
et la MOA ne connaissent pas toujours
les dernières fonctionnalités qui
permettraient d’éviter des développements et, à l’inverse, les développements
artisanaux sont ensuite compliqués à
faire évoluer dans les upgrades des
versions applicatives.
Peut-on continuer
à incriminer une faiblesse
de la maîtrise d’ouvrage ?
Dans les grandes entreprises, la maîtrise
d’ouvrage semble avoir plus de compétences en termes de SI. Elle n’hésite pas à
se faire accompagner par des assistants
internes ou externes pour palier son
indisponibilité voire son manque de
compétence. Ce qui est en jeu, c’est
plutôt le processus lui-même, le respect
d’un minimum de méthodes et de
discipline afin de limiter les risques au
niveau des tests et la fréquence des
changements de version pour les utilisateurs.
La MOA peut justifier la dispersion de ses
demandes et le resserrement de ses
exigences par des considérations
indiscutables de réactivité. Il n’empêche
qu’elle se heurte là à un processus industriel qui a du mal à être aussi flexible que
voulu.
Est-ce que les méthodes
appliquées dans les projets
sont reconductibles ?
La réponse est paradoxale. Sur de petits
incréments, on a peu de chance
d’introduire des dysfonctionnements
collatéraux et les tests se limiteront bien
souvent à la vérification de la fonctionnalité mise en œuvre.
Mais les petits incréments entraînent la
multiplication des versions ce qui dégrade
considérablement le processus aval, de
la mise en production en relation avec les
utilisateurs.
Cet inconvénient et la difficulté de trouver des « fenêtres » de changement dans
des plannings de production surchargés
conduisent à grouper les modifications
dans une même version.
En thermes de méthode, on touche aux
limites de validité des méthodes
employées sur les projets. En effet, les
points faibles sont accentués par
l’absence de véritable structure projet :
• L’évaluation des charges à l’issue de la
spécification : il est bien rare que l’on
travaille autrement qu’à « dire d’expert »
pour évaluer les charges. La mise en
route d’un processus d’achat au forfait
est trop lourd et finalement c’est le client
qui s’engage, rarement le prestataire.
• Les tests : parents pauvres des projets,
ils restent le maillon faible tant il est
difficile de constituer et de maintenir un
jeu de test qui serait automatiquement
passé à chaque mise en service avec
production automatique des écarts et
des anomalies.
• L’intégration : la mise en production est
souvent lourde et compliquée, elle exige
des ressources mobilisées en mode
projet mais pas toujours disponibles en
maintenance.
• La validation par les utilisateurs : elle se
fait bien souvent en situation d’utilisation réelle, faute de temps et d’environnement ad hoc.
Les ERP offrent-ils
une solution à ces problèmes ?
Tant qu’un ERP est une succession de
progiciels plus ou moins indépendants
(multiples mandants), on se ramène aux
cas précédents. La différence essentielle
vient de l’intégration des ERP avec
l’apparition d’une nécessité de cohérence fonctionnelle forte qui passe par les
règles de gestion et les données.
Ainsi par exemple, est-ce que la structure
de la tarification gérée par le marketing
va influer sur la chaîne de facturation,
voire sur le formulaire lui-même ; est-ce
que les informations de la supply chain
vont écraser des informations utiles à la
comptabilité client ? etc
L’ERP intégré fait émerger la nécessité
d’une équipe apte à conserver une vision
globale de très haut niveau sur le SI de
l’entreprise, sans rapport, de mon point
de vue, avec une ressource de
« réalisation » informatique, par ailleurs
nécessaire aussi. Les tâches de planification, d’estimation, d’arbitrage et de
pilotage demeurent essentielles. C’est le
mode projet pérennisé !
• La revue n° 76 - Juillet 2004
Ceci étant, l’essentiel de la difficulté me
paraît dépendre de la maintenance
évolutive qui est complètement liée à la
gestion, l’arbitrage et la planification des
demandes. Supposée traiter des petites
modifications, la maintenance évolutive
peut se trouver devant une série de
petits projets informatiques sans se
doter des structures nécessaires pour les
piloter.
17