Tribunes

Mettre à profit les principes « Lean » pour recueillir et formaliser les besoins en phase amont d'un projet informatique

La gestion des exigences est une pratique indispensable pour s'assurer que le résultat final d'un projet est conforme aux besoins. L'expression des exigences est souvent effectuée sans démarche spécifique, avec les moyens du bord. Nous présentons ci-après quelques bonnes pratiques qui s'appuient sur les principes Lean pour réussir cette première étape de vos projets informatiques.

PublicitéLe cadrage des besoins : une pratique peu maîtrisée dans les projets SI

Dans un projet informatique, la phase de recueil et de formalisation du besoin est une étape clé : il faut être capable d'identifier tous les acteurs à impliquer dans la démarche, de comprendre correctement le besoin et de le retranscrire efficacement. Elle se limite souvent à un travail de formalisation des pratiques existantes et peu d'analyses sont menées pour optimiser les modes de fonctionnements actuels. De plus les thématiques connexes ne sont pas traitées : sécurité des données, ergonomie des outils, temps de réponse, qualité de service...

En conséquence, trois types de dysfonctionnements sont observés : un surcoût de mise en oeuvre lié à la gestion des modifications demandées, une faible appropriation par les métiers - voire un rejet - et enfin des gains limités en raison du manque d'optimisation.

Les apports du Lean pour chaque étape de recueil et de formalisation des besoins

Etape 1 - Définir le périmètre

Pour cadrer le projet, une définition précise du périmètre est nécessaire. Cette définition est garantie par la mise en oeuvre de la méthode SIPOC (Suppliers, Inputs, Process, Outputs, Customers). Elle comporte trois temps : identifier les objectifs de l'activité, les traduire sous la forme de données de sortie et recenser les données d'entrée nécessaires pour construire ces données de sortie. Ainsi, les activités inutiles ne sont pas conservées. En général, les acteurs se focalisent sur les activités à réaliser : l'existant connu et maîtrisé est alors implicitement reconduit.

Cette définition est réalisée en atelier participatif avec les managers. Des supports visuels complétés en séance facilitent les échanges, la réactivité et la bonne compréhension des concepts manipulés. Cette logique participative est conservée tout au long de la démarche et s'appuie sur des pratiques Lean : aller sur le terrain, écouter la voix du client, rendre visible l'information...

Etape 2 - Définir les activités (à supporter par la solution) et les acteurs associés

Les managers et Les opérationnels sont conviés aux ateliers, qui permettent de définir la liste des cas d'utilisation ainsi que la liste des profils métiers concernés. Il est important de ne pas se limiter aux acteurs fonctionnels et de bien intégrer toutes les parties prenantes (ex. sécurité / sûreté, exploitation, support...).

Un cas d'utilisation comprend trois informations : l'événement déclencheur, l'activité à réaliser et le livrable. Il faut d'abord identifier l'événement déclencheur (ex. réception d'un ordre de travail à réaliser pour maintenir un navire). Ensuite, les livrables attendus sont décrits (ex. PV d'intervention de maintenance). Enfin, les activités à réaliser (ex. mise à jour des stocks de pièces et de la définition technique du navire...) et les profils métiers concernés sont recensés.

PublicitéA ce stade, les opérationnels sont garants de la réalité « terrain » tandis que les managers apportent la vision globale et stratégique. Sans cette confrontation, l'un des deux points de vue prendrait le dessus sur l'autre.

Etape 3 - Décrire finement les besoins

Etape 3 - Décrire finement les besoins

Les ateliers participatifs sont menés avec les opérationnels, qui détaillent les cas d'utilisation sous la forme de user stories : « en tant que ..., j'ai besoin de ..., afin de ... ». Cette formulation permet de vérifier que le besoin répond à un objectif métier et d'identifier les données manipulées. Pour chaque user story, les opérationnels expriment ensuite leurs critères d'acception : critères métiers, d'ergonomie, de performance, de sécurité...

La principale difficulté consiste à travailler au niveau des données et non au niveau des documents ou outils connus et manipulés tous les jours. Une bonne user story doit être intelligible par une personne extérieure au métier et doit être indépendante des solutions actuelles ou pressenties (ex. en tant que responsable de la maintenance, j'ai besoin de la liste des équipements sous haute pression avec leur repère et leur date de dernière visite, afin de savoir si je respecte la réglementation).

Les users stories manipulant les mêmes données sont regroupées en lot. Les opérationnels vérifient alors la cohérence (ex. deux profils métiers ne doivent pas être propriétaires d'une même donnée) et la complétude des lots.

A l'issue de cette étape, les métiers disposent d'un registre d'exigences. Une exigence se compose d'une user story et des critères d'acceptation associés. La rédaction des critères d'acceptation réduit les ambiguïtés. L'exigence constitue l'unité de description du besoin et devient l'élément de discussion entre les métiers et l'informatique.

Etape 4 - Challenger et prioriser les besoins

Les opérationnels et les managers challengent conjointement le besoin pour s'assurer qu'il est pertinent, qu'il apporte de la valeur pour l'entreprise. Les métiers positionnement les users stories sur une matrice de type « accessibilité / enjeux », qui définit un niveau de priorisation, qui pourra être ajusté tout au long du projet.

A l'issue de cette étape, les métiers disposent d'un registre d'exigences priorisées, qui constitue le livrable final du recueil et de la formalisation du besoin.

Les gains liés à la mise en oeuvre des principes Lean

La difficulté majeure des projets informatiques est l'adhésion des utilisateurs à la solution mise en oeuvre. Cette méthode structurée et collaborative offre la possibilité aux métiers de construire réellement la solution qui leur convient. Les représentants métiers mobilisés s'impliqueront plus facilement dans son déploiement et sa promotion auprès de leurs collègues. Leur connaissance fine de l'outil les positionnera naturellement en tant que référent auprès des autres utilisateurs.

Par ailleurs, cette méthode se traduit aussi par un meilleur respect des engagements « coûts-délais-qualité ». Les surcoûts et les retards sont limités car le risque de voir le périmètre évoluer est faible : les acteurs sont intégrés dès le début, les besoins sont clairement identifiés et partagés, les priorités sont validées, les ajustements sont effectués sur la base des priorités. La qualité est assurée par une définition et une mise en oeuvre efficace des tests, faciles à spécifier dès lors que les cas d'utilisation, les users stories et les critères d'acceptation sont définis précisément.

L'utilisation de ces principes Lean-Agile, y compris sur « cycle en V », s'observe de plus en plus. Les résultats obtenus conduisent les entreprises à les adopter.

Article rédigé par

Christophe Coupé, Senior Manager chez Vinci Consulting
Senior Manager chez Vinci Consulting, Christophe Coupé est expert en Lean et Systèmes d'Informations.