la méthode


intervenant


conseil


nos clients


formation


publications


 

 

 


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 besoins caché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.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 :

 

retour

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.

 

 retour

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.

 

 retour

Les besoins cachés

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.

 

 retour

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 :

  • 25% pour 1 projet, dans l’ordre de grandeur de ce que la méthodologie met en lumière dans d’autres secteurs d’application

  • 50% à 65% pour 4 projets, gonflés, sur une base de besoins correctement appréciés, par l’accumulation de tous les facteurs inflationnistes cités ci-avant,

  • 65% à 90% pour 4 projets : dans ces cas les besoins étaient exprimés sous forme d’une solution préconçue très décalée par rapport aux réels besoins. L’analyse fonctionnelle a conduit à adopter des solutions conceptuellement différentes.

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.

 

 

retour