Méthodes concernant un projet

1er janvier 2003

En 1995, une étude du Standish Group portant sur un échantillon de 365 entreprises et 8 380 projets indiquait que parmi les projets informatiques lancés par les entreprises, 16 % seulement peuvent être considérés comme des succès (ils aboutissent dans les délais, et leur coût est celui qui avait été prévu) ; 31 % sont arrêtés en cours de réalisation et 53 % aboutissent mais au prix d'un accroissement du délai et du coût tout en offrant moins de fonctionnalités que prévu, le multiplicateur étant en moyenne de 2,89 pour le coût et de 3,22 pour le délai. Pour les grandes entreprises (qui lancent proportionnellement davantage de gros projets), le taux de succès est de 9 % seulement, 37 % des projets sont arrêtés en cours de réalisation, 50 % aboutissent hors délai et hors budget. 

Parmi les causes de succès, la première est l'implication des utilisateurs qui expriment clairement leurs objectifs et formalisent leurs exigences ; la seconde est l'implication des dirigeants dans le soutien au projet ; parmi les causes d'échec, la première est le manque de clarté des besoins, la seconde l'évolution des spécifications en cours de réalisation. 

Lorsque les dirigeants lancent un projet, ils n'ont pas ces proportions en tête ; l'échec les surprend, les étonne toujours. Lorsqu'un projet est en péril, ils mettent du temps à "réaliser" le danger et à réagir. Parmi les projets qui ont abouti hors délai et hors budget, certains auraient été sans doute arrêtés "si l'on avait su" ce qu'ils allaient coûter. Malgré l'expérience accumulée, les entreprises sont dans l'ensemble excessivement optimistes en ce qui concerne les projets informatiques. 

L'examen des causes de succès et d'échec est instructif : la plupart des échecs proviennent non de l'informatique, mais de la maîtrise d'ouvrage, en comprenant sous ce terme à la fois les dirigeants et les concepteurs des métiers. La technique informatique est puissante ; elle permet beaucoup de choses, et ses possibilités sont même plutôt sous-utilisées. Même si la réalisation d'un projet peut comporter des errements, le professionnalisme des SSII, des informaticiens de l'entreprise est généralement suffisant pour arriver au succès - à condition que la maîtrise d'ouvrage soit, de son côté, de bonne qualité professionnelle. 

C'est pourquoi la professionnalisation de la maîtrise d'ouvrage est une priorité pour les entreprises. Lorsqu'elle a lieu, elle modifie les rapports avec l'informatique et déplace la frontière des responsabilités, ce qui contrarie parfois les informaticiens dans un premier temps ; puis ils en voient bientôt apparaître les bénéfices. 

Le professionnalisme de la maîtrise d'ouvrage lui permet d'éviter des défauts courants, qui se manifestent souvent simultanément :
- expression de besoin initiale confuse ; 
- priorités non définies ;
- caractère inflationniste de la demande ;
- spécifications relevant de la science fiction plus que du réalisme du métier ou de la technique ;
- intention cachée de régler des problèmes "politiques" de l'entreprise à travers le système d'information ;
- versatilité, instabilité de la demande ;
- insouciance en ce qui concerne la conduite de projet.

Les entreprises parlent volontiers de leurs succès, mais elles ne font pas de publicité autour de leurs échecs. Seuls ceux qui sont assez retentissants pour susciter des commentaires dans la presse sont connus. Tous s'expliquent par une conjonction des défauts ci-dessus :
- les difficultés rencontrées lors du lancement du produit Socrate par la SNCF sont dus au volontarisme de la direction qui, pour des raisons politiques et malgré les avertissements des informaticiens, a voulu mettre le système en oeuvre alors qu'il n'était pas au point ; 
- les difficultés rencontrées par l'informatique de la TGB (bibliothèque François Mitterrand) ont été provoquées par la volonté politique de mettre les bibliothécaires au pas, ce qui a poussé à construire le système sans consulter ses futurs utilisateurs : d'où des impropriétés manifestes ; 
- le Ministère de la Justice a prétendu faire remplir par des magistrats le rôle de maîtrise d'ouvrage du système d'information des tribunaux ; leur manque de professionnalisme a provoqué des errements coûteux. 

Il arrive souvent qu'un système d'information qui fonctionne ne puisse pas rendre les services que l'on pourrait en attendre, en raison d'une définition malencontreuse résultant d'a prioris politiques : il en est ainsi de l'utilisation du système de facturation des opérateurs télécoms à des fins de marketing, lorsque l'objet de la facturation est non le client mais la ligne.  

Le Standish Group décrit deux "failure stories" et deux "success stories" instructives : 

- California DMV ("California Department of Motor Vehicles") a lancé en 1987 un grand projet pour introduire les nouvelles technologies dans la gestion des permis de conduire. Le projet a été arrêté en 1993, après avoir coûté 45 millions de dollars. En fait, le projet était volontariste ; il n'avait convaincu ni les dirigeants ni les utilisateurs et ses spécifications étaient confuses. 
- American Airlines : un projet de réservation de chambres d'hôtel et de location de voitures a été abandonné en 1994 après avoir coûté 165 millions de dollars. On explique l'échec par le trop grand nombre de partenaires impliqués, l'imprécision et l'instabilité des spécifications, le manque d'implication des utilisateurs.

- Les hôtels Hyatt ont réussi leur système de réservation en impliquant les utilisateurs, avec le soutien des dirigeants, des spécifications claires et une définition modulaire du projet. 
- Banco Itamarati : cette banque brésilienne a monté un système efficace de relation avec ses clients, et une architecture client/serveur, grâce à une équipe de maîtrise d'ouvrage professionnelle entretenant une bonne coopération avec les informaticiens. 

La professionnalisation d'une maîtrise d'ouvrage réside essentiellement dans son aptitude à modéliser le SI du métier ; le maître mot est modélisation. Lorsque le modèle du SI est de bonne qualité, sobre, clair, stable, la maîtrise d'œuvre peut travailler dans de bonnes conditions. Certes la qualité du modèle n'est pas une condition suffisante du succès : il faut aussi que la conduite du projet soit convenable, que la recette et le déploiement soient réussis ; mais une maîtrise d'ouvrage capable de modéliser sera, a fortiori, capable de réaliser convenablement le reste des opérations. 

Le langage UML se présente aujourd'hui comme la lingua franca de la maîtrise d'ouvrage. Il fournit son vocabulaire à la modélisation ; il facilite la consultation des experts du métier, la concertation avec la maîtrise d'œuvre, la formalisation du besoin. Il aide à rendre naturelle, au sein du métier, la démarche d'abstraction sans laquelle il ne peut pas exister de SI et qui constitue parfois le principale obstacle, à la fois philosophique et intellectuel. Il permet aussi, à condition que le modèle soit convenablement résumé, une validation authentique du formalisme du SI par les dirigeants. Enfin, lorsque le modèle UML a été entièrement établi, une partie du programme peut être écrite automatiquement par des générateurs de code, ce qui soulage d'autant le travail de réalisation. 

Cependant le langage UML ne peut être utilisé que si l'on a au préalable étudié et mis en forme les processus de travail du métier considéré ; il ne peut être efficace que si l'expression de besoin est pertinente, sobre, cohérente ; en retour, l'élaboration du modèle permet de repérer les défauts de cohérence, d'exprimer l'exigence de sobriété, et elle concourt donc à la qualité de l'expression du besoin. 

La technologie objet, qui comporte les deux phases de modélisation et de programmation, introduit une modification profonde du rôle de la maîtrise d'ouvrage, responsable de la modélisation. Lorsque les entreprises auront compris à quel point le succès des projets informatiques dépend de la professionnalisation de la maîtrise d'ouvrage, et auront mis en place l'organisation nécessaire, les études du Standish Group feront apparaître que l'informatique est arrivée à maturité : alors les taux d'échec des projets informatiques ne seront pas supérieurs à ceux que l'on rencontre dans d'autres domaines comme le bâtiment ou l'ingénierie industrielle.

Voici la succession des méthodes à utiliser pour réussir un projet :

Première expression de besoin

Étude "opportunité, faisabilité, risque"
Fiche de synthèse de mission
Modélisation du processus  

Conduite de projet  

Recette

Déploiement
Évaluation