Expression des besoins pour le système d'information. Guide d'élaboration du cahier des charges

Extrait de la préface de Michel VolleD'après le Standish Group, les projets informatiques connaissent un taux d'échec qui ne saurait être toléré dans aucun autre domaine de l'ingénierie: de ses enquêtes, on peut retenir qu'en gros 25 % des projets échouent, 50 % aboutissent avec un délai et un coût très supérieurs à la prévision, 25 % seulement sont convenablement réussis. En cas d'échec, on entend souvent dire «c'est la faute de l'informatique», mais en fait, il convient de dire que, par principe, c'est toujours la faute du métier que le produit informatique devait outiller (maîtrise d'ouvrage, MOA). Certes, il arrive que le réalisateur du produit (maîtrise d'oeuvre, MOE) soit défaillant, mais alors la MOA aurait dû prendre en temps utile des mesures pour redresser la situation. Souvent d'ailleurs, le seul tort de la MOE sera d'avoir accepté un contrat impossible, car l'ingénierie des besoins a été défaillante et le projet était donc condamné dès le départ: la MOA s'est lancée dans le projet sans savoir ce qu'elle voulait faire, sans avoir exprimé ses priorités ni levé les ambiguïtés du vocabulaire, puis par la suite elle a été versatile, etc. Une expression de besoin bien faite garantit le succès ou du moins (car on ne peut jamais se prémunir contre toutes les surprises) une probabilité de succès de l'ordre de 90 %: on mesure l'enjeu si l'on compare ce taux aux données du Standish Group.Jean-Pierre Meinadier est l'un des maîtres français les plus respectés en ingénierie des systèmes industriels. Invité à participer à un projet de système d'information (SI), il fut immédiatement congédié pour avoir posé une question jugée incongrue: «qui est responsable?». Il a alors compris que contrairement à un projet d'automobile ou d'avion, dont les enjeux techniques sont mesurables et «froids», un SI est «chaud»: chaque projet comporte implicitement de tels enjeux «politiques» de légitimité, de découpage des pouvoirs et de responsabilité, que l'entreprise préfère souvent laisser implicites les données nécessaires à son succès. C'est cette «chaleur» du SI qui explique le taux d'échec extravagant des projets. Les acteurs ne manquent ni de bon sens ni d'intelligence, mais ils les mettent au service de priorités qui ne sont pas celles de l'efficacité de la production de l'entreprise ni de la qualité de ses produits - objectifs qui, en revanche, sont précisément ceux que sert un SI.