La MOA : 1ère cause d’échec dans les projets informatiques ?

Aujourd’hui, selon différentes sources, 50% des projets informatiques sont livrés hors délais ou ne répondent pas aux attentes des utilisateurs en termes de fonctionnalité (*) . Il est même avancé le chiffre de 30% des projets qui ne voient jamais le jour, purement et simplement abandonnés !
Derrière ces chiffres, ce sont des sociétés pénalisées, désorganisées, des millions d’euro envolés. Le constat est dramatique. Que faire ?

Et la gestion de projet ?

Devant ce phénomène, beaucoup cherchent de nouvelles façons de gérer les projets. Des tas de méthodes ont vu le jour. Même si avec les méthodes agiles, des progrès en matière de gestion de projet sont indéniables (*), on peut se demander : pourquoi alors les projets continuent-ils à si mal se passer ?

1ère cause d’échec

Les SSII, ou les éditeurs commettent leurs propres erreurs. Mais il faut bien reconnaitre que la source des problèmes vient souvent de … la maîtrise d’ouvrage. Aie! Voilà c’est dit. C’est un peu douloureux sur le moment mais ça permet d’avancer après.

La grande erreur de la maitrise d’ouvrage (MOA) c’est de penser que la maitrise d’oeuvre (MOE), éditeur, SSII, va tout comprendre de son métier en lui donnant quelques pages dans un cahier des charges. Le projet démarre sur un chiffrage qui est le point de départ de ce malentendu. Par la suite, impossible de faire marche arrière. Les conflits arrivent les uns après les autres. Les parties prenants s’essoufflent à prouver que la demande, soit fait partie du périmètre du projet, soit est une évolution donnant lieu à un avenant.

Alors comment faire ?

La solution est simple à dire mais elle demande du travail au client. Il doit documenter son système d’information (SI) avec méthode.
Cette documentation doit exister AVANT de lancer le projet, AVANT d’écrire le cahier des charges.
Ainsi, jointe au cahier des charges, cette documentation permettra à la MOE de comprendre sans ambiguïté le métier du donneur d’ordre.

Et les spécifications ?

Certains objecteront : “oui mais ça fait partie des spécifications”. Tout cela est affaire de sémantique. Les spécifications vont permettre de décrire la réponse technique au cahier des charges. Toutes les parties n’ont-elles pas intérêt à les écrire en se basant sur un maximum d’informations ?

Et les ateliers ?

D’autres objecteront : ” oui mais il y a les ateliers”. Les ateliers commencent lorsque la MOE a été choisie. Mais c’est déjà trop tard. Le chiffrage est déjà fait. Le contrat sans doute déjà signé.

Que mettre dans la documentation du SI ?

Un cahier des charges explique le « quoi », le « quand », le « pourquoi », etc. La documentation doit expliquer le « comment ».
Si on veut refaire un logiciel iso fonctionnel alors un guide utilisateur du logiciel existant est un bon départ (à condition de ne rien changer au mode opération, navigation, etc.). L’accent doit être mis sur les fonctionnalités importantes et comment elles sont (ou doivent être) utilisées par l’utilisateur final.

(*) sources : Rapport Standish Group 1994 p.2 et Etude Alain Battandier

Crédit Photo : “La chute” Levalet