Retour au sommaire

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


19/11/2012

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. Les progrès en matière de gestion de projet sont indéniables. Pourtant 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.

 

Commentaires

Flovc, le 11/01/2013

Excellent article ! J'ajouterai à ce titre que l'anticipation est l'une des clés de la réussite.

Des délais trop courts conduisent à faire des erreurs malgré toutes les bonnes volontés. Le recul est indispensable ; pas seulement pour la conception mais pour être capable de prioriser les fonctionnalités à mettre en oeuvre lorsque les délais se tendent.

De même, il est désastreux de constater le manque de professionnalisme des commerciaux des sociétés informatiques. Ils vous diront toujours que vos délais sont jouables même s'ils savent pertinement qu'il n'en est rien car "il y a des supermen dans la boîte", "on est les meilleurs, nos tarifs le prouvent".

Bien coder ne veut pas dire bien comprendre ce qu'il y a à coder. La préparation du dossier chez le client est donc l'une des clés principales et je rejoins le propos à 100%. Elle consiste à bien formaliser le métier, prévoir un timing raisonnable de réalisation ainsi qu'un périmètre projet "officieusement" décalable au cas où celui-ci prendrait du retard.

Laurent_lecousindeRennes, le 23/01/2013

Je souscris également à ce qui est écrit par Clarsi et Flovc.

Et pour ma part j'ajouterais que cet article permet de bien comprendre le rôle d'un troisième acteur dans les projets SI : l'AMOA.

Cette assistance à maîtrise d'ouvrage (AMOA) apparaît parfois bien nécessaire pour jouer le rôle de "traducteur" entre un homme du métier qui a du mal à exprimer son besoin en termes "informatiquement compréhensible", et une maîtrise d'oeuvre qui a du mal à vulgariser ses contraintes informatiques.

Une AMOA pertinente et à très forte valeur ajoutée dans le projet est alors une personne qui connaît suffisamment précisément le "métier" de l'utilisateur, mais qui est aussi à l'aise dans les modalités informatiques de mise en oeuvre. Un parfait "bilingue" somme toute !

Régis Moeneclaey, le 25/01/2013

Bonjour,
Je suis d’accord sur la démarche et les précautions qu’elle entraîne. Je pense toutefois qu’il y a un problème du fait que les responsables de PME (qui ne sont, pas souvent, des spécialistes de l’informatique) ont face a eux un monde de l’informatique qui fait ou laisse croire qu’un projet informatique n’est pas si compliqué (un logiciel permettrait de faire beaucoup de choses et s’il y a une difficulté l’informaticien trouvera une solution pour adapter !!).
Le monde de l’informatique devrait dire qu’il n’y a pas de solutions/ de logiciels universels. Par comparaisons comme :
- un technicien en électronique ne peut être suffisamment compétent en mécanique
- un chef de chantier du bâtiment compétent pour un chantier de travaux publics……
De même un logiciel utilisé par une entreprise qui exerce un métier donné et un dirigeant qui a sa propre personnalité et ses propres objectifs, ne sera pas (ou plus ou moins mal) adapté à une autre ou d’autres entreprises qui ont chacun leur propre métier et leur dirigeant avec des objectifs différents.
A cause de tout ce que l’ont laisse ainsi croire, des dirigeants de PME simplifient trop l’importance de leur projet informatique et ne prennent pas de précautions suffisantes. J’ajouterai que souvent, et c’est compréhensible, ils n’ont pas en interne les compétences et le temps pour mener, avec toutes les précautions nécessaires, leur projet. Ils ne sont aussi, pas souvent, mis en garde sur les dangers qu’ils font courir à leur entreprise.
Mon interrogation : comment faire passer cette idée et en convaincre les responsables de PME ?
Dernier point le monde de l’informatique et trop d’informaticiens pratiquent un langage et des termes trop techniques qui nuisent t à une bonne communication et empêchent leurs clients / futurs clients de bien suivre et comprendre tout ce qui est dit (chaque métier à son langage, si on le veut vraiment on peut toujours « traduire » en termes compréhensibles par tous.
Sur mon site internet : http://www.moeneclaey-consultant.fr plusieurs articles traitent de ce sujet comme celui « informatiser une entreprise »
Régis Moeneclaey

nox, le 18/10/2013

Tt ce que vous dites est vrai. Vous oubliez par contre la dimension politique qui joue un role tres important a ts les niveau (faire passer un dev pour un bug ou inversement, cumuler les roles, mal communiquer, mal ecouter etc.)

franck-divet, le 18/10/2013

Bonjour Nox. Merci pour votre commentaire. Pourriez vous être plus explicite sur l'expression "dimension politique" et le lien avec le fait de "faire passer les dev pour des bug, ..." ?