|
|||||
|
|
|
De l'expression à l'Analyse des besoins dans les systèmes d'Information par Philippe RIGAIL Société FORMES & TECHNOLOGIES Article publié dans la revue "LA VALEUR" n°88, Avril 2001 |
|||
|
La conduite des projets informatiques Les facteurs d’incomplétude et de déformation des besoins exprimés Les facteurs de surabondance des besoins exprimés Les apports de l’analyse fonctionnelle
La conduite des projets informatiques Les méthodes de conduite de projets informatiques mettent en oeuvre des processus lourds et très structurés. Souvent personnalisées par les entreprises, elles tirent généralement leur ossature de la méthode « MERISE ». Elles débutent généralement, après une étude d’opportunité, par une phase intitulée «expression des besoins des utilisateurs ». Nos retours d’expériences sur une dizaine d’années montrent que les besoins exprimés par les utilisateurs s’avèrent souvent sensiblement différents de leurs besoins réels. Nous analysons les principales causes de ce décalage :
Les facteurs d’incomplétude et de déformation des besoins exprimés Le processus d’expression des besoins, conduit sans méthodologie particulière et trop rapidement, les utilisateurs n’acceptant pas d’y consacrer le temps qu’il mériterait, est déjà générateur de lacunes : L’expression limitée aux insatisfactions de l’existant Les projets initiés en terrain vierge ne représentent qu’une infime minorité. La grande majorité visent à refondre ou étendre des systèmes existants. Dans une expression des besoins, les utilisateurs se contentent généralement de citer tout ce qui les insatisfait dans le système actuel : les insatisfactions d’un système vieillissant concernent généralement de 10 à 20% des services assurés. Pour les 80 à 90% restants, la formulation de la demande se limite à « une poursuite des services assurés par le système existant ». Faute de mieux, les maîtres d’œuvre génèrent un cahier des charges à partir d’une analyse de cet existant : il en découle des solutions qui satisfont…les besoins des utilisateurs d’il y a 10 ans. L’expression non structurée Les méthodes de développement de projets informatiques ne disposent d’aucun outil pour encadrer une expression des besoins. Il en résulte une liste hétérogène, mêlant sur un même plan des objectifs stratégiques et des points de détail opérationnels. L’expression en terme de solutions La vulgarisation de l’informatique induit que tout utilisateur se pique d’en posséder une bonne connaissance, et l’amène, peut-être plus encore que dans d’autres domaines, à exprimer les besoins non pas en terme de services à rendre, mais de solutions. Les successions d’interprétations Les maîtres d’ouvrages délégués ou assistants à la maîtrise d’ouvrage, métiers relativement récents dans ce secteur d’activité, et en plein essor, ont pour mission de faciliter la relation entre utilisateurs et maître d’ouvre, et de contrôler les prestations de la maîtrise d’œuvre en termes de coûts, délais et qualité. Mais nombre d’entre eux, souvent anciens utilisateurs eux-mêmes, s’investissent de la mission de représenter les utilisateurs, et de se substituer à eux pour exprimer leurs besoins. L’expérience montre qu’un ancien utilisateur, dès 6 mois d’éloignement de la réalité quotidienne, en a déjà une vision déformée. Les facteurs de surabondance des besoins exprimés Outre les failles du processus d’expression, un certain nombre de facteurs conduisent les utilisateurs à un alourdir leur expression de faux besoins : Le principe inflationniste de l’« expression » Si l’on demandait aux utilisateurs d’analyser leurs besoins, ils entameraient une démarche critique de ces besoins. L’appellation « expression des besoins » les incite à émettre une liste de demandes la plus large possible, sans aucune censure. Les besoins exprimés « pour voir » Les utilisateurs ont en particulier tendance à exprimer certains besoins qu’ils perçoivent instinctivement comme luxueux ou surabondants, suivant le principe que les maîtres d’œuvre chiffreront les solutions correspondant à l’ensemble des besoins exprimés, et qu’ils opéreront ensuite un tri parmi les solutions proposées au vu des coûts annoncés. Le premier défaut de cette procédure est de gaspiller du temps et de l’énergie à chiffrer des solutions qui ne seront pas retenues. Le deuxième, plus grave, est que les maîtres d’œuvre, à partir des besoins exprimés, bâtissent des solutions cohérentes. Lorsque le comité de pilotage du projet, à l’annonce des coûts en fin de phase d’avant-projet, revient à des besoins plus raisonnables, la tendance est de procéder à des amputations sur ces solutions pour rentrer dans le budget. Le plus souvent, la prise en compte au départ de besoins juste nécessaire aurait conduit à une architecture de solutions fondamentalement différente. Mais il n’est pas naturel à ce stade de remettre en cause les choix effectués, et par ce processus d’amputations on initie des études détaillées de solutions déjà incohérentes. La
vision limitée au système informatique Un système d’information se définit comme l’ensemble des moyens permettant aux informations de parvenir à ceux qui en ont l’utilité : il est la somme d’une organisation fonctionnelle, de processus et d’un système informatique. La plupart du temps, sous l’appellation « système d’information », on parle en réalité d’un système informatique, et les projets se limitent au domaine informatique. C’est ainsi que l’on informatise à grands frais des procédures que l’on pourrait simplifier, voire supprimer. La méconnaissance des coûts et des enjeux L’analyse des coûts et enjeux suppose que le projet soit situé au niveau « système d’information », que l’on procède au préalable à une analyse d’activité des utilisateurs, et que l’on accepte une transparence des coûts de procédures entre maîtrise d’ouvrage et maîtrise d’œuvre de projets informatiques. Traditionnellement, analyses de processus et projets informatiques sont deux domaines disjoints, et les projets informatiques dimensionnés sans mesure de coûts et enjeux. La méconnaissance de l’état de l’art et la culture micro-informatique Tout utilisateur est fasciné par les possibilités des outils bureautiques dont il dispose sur son poste de travail, capables de répondre en quelques secondes aux problèmes les plus complexes. Cette facilité le pousse à demander des performances identiques aux gros systèmes. Il ne mesure pas que sous l’effet des volumes et des interactions les gros systèmes ont peu de points communs avec des applications bureautiques. L’automatisation à priori à 100% Les utilisateurs n’envisagent pas spontanément que l’on puisse aujourd’hui définir un système informatique autrement que 100% automatique. Même avec les techniques actuelles, les solutions à valeur optimisée conservent pourtant souvent un traitement manuel de cas particuliers complexes à faible occurrence. L’auto-alimentation des projets Le scénario classique d’auto-alimentation des projets se déroule de la façon suivante : un projet est initié pour répondre à des besoins bien précis d’une catégorie d’utilisateurs. Par exemple, les commerciaux ont besoin de mieux connaître leurs clients. Une solution apparaît évidente : la création d’une « base de données clients ». Immédiatement naît l’idée que cette « base de données clients » pourrait servir à d’autres métiers : les gestionnaires de contrats, les statisticiens, etc.… et le service commercial obtiendra plus facilement un budget pour le projet s’il le rend fédérateur. Chaque nouvelle catégorie d’utilisateurs fait ajouter les données dont il a besoin dans la « base de données clients », qui enfle… Ce type de projets connaît deux types d’issues : le projet est devenu tellement cher qu’il est abandonné, et le besoin initial des commerciaux n’est pas rempli, ou une lourde base de données finit par voir le jour, et les commerciaux s’arment de patience lorsqu’ils ont besoin de données sur un client. La reconduction de solutions dont l’origine a disparu La trop hâtive reconduction de la part de l’existant qui ne produit pas d’insatisfactions conduit parfois à réétudier ou reconduire des fonctionnalités devenues inutiles, par suite de modifications de réglementation, de produits, de processus… La surconsommation par les possibilités techniques Les progrès techniques fulgurants en informatique reculent de plus en plus les limites du possible. Cela conduit les maîtres d’œuvre à pousser les utilisateurs à la consommation, et les groupes projets à retenir des fonctionnalités non pas parce qu’elles correspondent à un réel besoin, mais parce qu’il est techniquement facile de les assurer. Malgré tous les facteurs tendant à une surabondance dans l’expression des besoins, cela n’empêche pas pour autant qu’une part des besoins réels ne s’y trouve pas : L’autocensure Si la culture micro-informatique conduit les utilisateurs à exprimer de faux besoins, à l’inverse, cette culture limite pour eux la perception du champ du possible. Ils sont ainsi amenés à ne pas exprimer des besoins uniquement parce qu’ils considèrent, à tord, que leur satisfaction est impossible avec l’état de l’art actuel. La non-qualité ancrée dans les habitudes L’insuffisance de remise en cause des processus et du service aux clients dans l’expression des besoins des systèmes informatiques peut conduire à reconduire des sous-performances sur certains services, uniquement parce que les utilisateurs sont habitués à ce niveau de performance, et que la non-qualité ne génère que des coûts cachés, ou une insatisfaction non explicite des clients. Les besoins émergents Un projet de système d’information d’envergure peut demander 2 ans d’études, pour livrer un ensemble dont la durée de vie, intégrant des maintenances évolutives, peut couramment dépasser 10 ans. Instinctivement, les utilisateurs expriment leurs besoins actuels. Ceux sur lesquels doit être bâti le futur système sont les besoins résultant d’une analyse prospective à 5 ans. Les apports de l’analyse fonctionnelle L’ensemble de ces facteurs conduit à ce que les études détaillées de projets démarrent sur la base d’une expression des besoins des utilisateurs incomplète, comportant une part significative de faux besoins, et omettant certains besoins réels. Le décalage avec les besoins réels est amplifié par une interprétation de la maîtrise d’œuvre, obligée de générer par reconduction de l’existant ou arbitrairement la part des besoins non exprimés. Sur 11 projets, nous avons eu l’occasion de mener une étude de management par la valeur sur des projets déjà en phase d’études détaillées, disposant donc au démarrage d’avant-projets décrivant les besoins et solutions chiffrées qui avaient été validées. Bien que sur ce type d’interventions, il soit aisé de faire le bilan de l’apport global de la méthodologie, mais difficile d’affecter les résultats entre l’analyse fonctionnelle et les phases suivantes de recherche et analyse de la valeur de solutions, nous pouvons en tirer les bilans suivants : 2 projets particuliers montraient une sous-estimation des besoins des utilisateurs d’un facteur deux, par une insuffisance de l’investissement des utilisateurs dans les cahiers des charges, et un manque de dimension prospective : une trop grande prééminence de la maîtrise d’œuvre dans l’élaboration des spécifications fonctionnelles conduisait à remplacer à grand frais un système obsolète par un système de performances trop similaires. Les 9 autres projets présentaient, parmi les besoins exprimés, un pourcentage de « faux besoins » de :
Il est intéressant de souligner que les faux besoins, s’ils génèrent des surcoûts proportionnels à leur taux, n’apportent pas pour autant une meilleure satisfaction des utilisateurs : au contraire, facteurs d’augmentation de la complexité des systèmes, ils induisent des insatisfactions.
|
|||||
|
|
|
|
|||
