Prélude à tout projet informatique, chacun s’accorde pour dire l’importance de la phase de recueil des exigences, (ou ses équivalents comme « expression des besoins », « rédaction du cahier des charges »…). Comment peut-on alors optimiser, voire garantir la qualité de cette étape essentielle ?
Toutes ces approches de gestion de projets recommandent de débuter un projet en définissant le (ou les) buts à atteindre avant d’aborder le « comment atteindre ces buts ». La notion d’exigence correspond à un niveau assez détaillé d’expression de ces buts mais sans être encore du « comment réaliser ».
Prenons un exemple : pour la refonte d’un site Web de vente grand public, le demandeur pourrait avoir comme but « augmentation de 5 % de la marge » et comme exigences « temps de recherche de produit inférieur à 0,7 s » (il faudrait préciser un panel de recherches de référence), « obtention du label d’accessibilité AccessiWeb pour l’ensemble du site », etc.
En pratique, traduire le but métier en exigences est recommandé pour servir de base solide au contrat entre la maîtrise d’ouvrage et la maîtrise d’œuvre du projet. On cherche alors à ce que les buts soient décomposés en exigences (éléments unitaires de la demande) qui soient les plus simples possible, et la maîtrise d’ouvrage doit valider l’ensemble de ces exigences comme correspondant aux buts qu’elle a assignés au projet.
Les exigences sont alors exprimées avec des textes et/ou des schémas, et elles sont en général numérotées pour pouvoir plus facilement les suivre et les prendre en référence tout au long de la vie du projet.
Dans ce contexte, une bonne exigence doit donc répondre aux critères suivants :
- être « mesurable » pour pouvoir être confrontée au produit à réaliser lors de la livraison de celui-ci ;
- être comprise par la maîtrise d’ouvrage et validée par celle-ci comme représentant valablement une partie de ses buts ;
- être comprise par la maîtrise d’œuvre pour que celle-ci puisse s’engager à la respecter de manière responsable.
C’est le dernier point qui distingue l’expression des buts (qui peuvent être purement métiers) des exigences du projet (qui doivent pouvoir être engageantes pour la maîtrise d’œuvre).
Lorsqu’elle est utilisée, cette expression des buts sous forme d’exigences remplace les éléments de contractualisation plus classiques comme une spécification fonctionnelle ou un cahier des charges. Les exigences sont identifiées et l’on peut alors suivre tout au long du projet :
- l’évolution de ces exigences, individuellement et globalement, en reportant dans celles-ci toutes les nouvelles demandes des utilisateurs, et en faisant valider ces changements par la maîtrise d’ouvrage et la maîtrise d’œuvre ;
- la prise en compte de chaque exigence par le projet car chaque écart est identifiable et peut faire l’objet d’une analyse et d’une prise de décision. Un écart accepté par toutes les parties devient alors une modification de l’exigence.
La traduction des buts en exigences est actuellement de plus en plus recommandée pour formaliser les demandes de la maîtrise d’ouvrage dans les projets informatiques. Elle est en particulier mise en avant par son rôle important dans le référentiel de bonnes pratiques CMMi (Capability Maturity Model Integration) auquel s’intéressent actuellement la plupart des grands donneurs d’ordres en informatique.
La qualité d’expression et de validation des exigences pose problème
La tendance actuelle consiste donc à mettre en place un processus de gestion des exigences, souvent dans le cadre d’une démarche CMMi de niveau 2, dans le but d’optimiser les coûts et bénéfices des projets de système d’information. Mais mieux gérer les exigences n’améliore pas directement la qualité d’expression de ces exigences ou leur meilleure validation par les demandeurs. Or, les études montrent que c’est cette qualité d’expression et de validation des exigences qui pose le plus de problèmes.
L’optimisation de la gestion des exigences n’apparaît donc alors que comme un palliatif. Elle est utile et correspond à un certain état de l’art, mais en ne traitant qu’une partie du problème, les résultats ne peuvent être que mitigés.
La qualité d’expression des attentes dépend-elle alors plus de l’expertise du consultant, de ses outils, ou bien d’éléments qualitatifs apportés par les utilisateurs intéressés ? Car ce sont ces éléments – l’envie (et la disponibilité d’esprit) et l’adhésion – qui seuls peuvent débloquer la participation nécessaire (le temps) et la coopération entre les différentes équipes internes et externes.
Comment enclencher le cycle vertueux – envie, coopération, adhésion – sachant qu’il ne se décrète pas et que même un objectif managérial affirmé, s’il reste seul, ne conduit trop souvent qu’à une participation minimum ?
De nombreuses études ont été consacrées depuis des années aux causes d’échecs et de succès des projets informatiques. Ces études sont globalement très cohérentes entre elles : beaucoup de projets n’atteignent pas les objectifs fixés. Et les écarts sur les projets qui « dérapent » (plus des deux tiers des projets) sont loin d’être négligeables, et même si des progrès ont été réalisés depuis quinze ans, ceux-ci marquent le pas depuis la diffusion des technologies Web et le développement de la demande d’une informatique plus réactive pour les métiers (demande « e-business »).
Les principaux facteurs de succès des projets sont d’une stabilité remarquable depuis des années dans les études du Standish Group (le top 3 est inchangé depuis quinze ans malgré tous les changements de technologies et de méthodologies ! ) : l’implication des utilisateurs, le soutien de la direction générale et des objectifs métiers clairs.
Ce qui ramène au questionnement précédent : puisque ces problèmes de motivation et de qualité des exigences sont si importants et très liés, pourquoi ne pas les traiter en premier ?
Pour progresser sur ces sujets, il ne suffit pas d’écouter les utilisateurs, il faut prendre en compte tout ce qu’ils disent et l’ordre dans lequel ils le disent, et pour qu’ils s’expriment jusqu’au bout, il est aussi indispensable de les libérer des formalismes des langages experts.
Pour que l’utilisateur puisse reconnaître ses descriptions lors des validations, toutes les informations fournies doivent apparaître dans les restitutions, même si elles n’ont aucun intérêt dans l’étape de conception en cours.
Il faut les rassurer et donc les faire agir et réagir sur des éléments qu’ils maîtrisent. Il faut leur fournir très tôt, en particulier pour les grands principes structurants (processus principaux, principaux rôles, etc.), une suite de résultats intermédiaires tangibles, même s’ils sont partiels et incomplets.
Le consultant pourra ainsi recueillir leurs avis et remarques et obtenir progressivement leur adhésion. Ces résultats doivent également être partageables par le plus grand nombre pour être confrontés à tous les points de vue utiles au projet (utilisateurs et responsables des différents services, directions, etc.).
Un des résultats indispensables à la compréhension réelle des utilisateurs est une maquette opérationnelle du futur système. C’est le seul moyen qui leur permette de se projeter facilement dans la future organisation de leur travail. Et il paraît pertinent de construire cette maquette des grands principes du futur système (fonctions, règles, usages) avec les utilisateurs eux-mêmes et donc pour cela de leur fournir un outil simple qu’ils pourront utiliser, de façon itérative et interactive, en groupe et assistés d’un expert pour aboutir progressivement à une vision métier cohérente et complète de leur futur système.
Faire le lien avec les équipes de spécification et de réalisation ?
Jamais un expert informaticien qui s’inscrit dans une démarche qualité pour la conception et la réalisation n’acceptera de travailler en dehors d’une démarche méthodologique. Jamais il ne pourra se passer de langages et de descriptions formelles (quels qu’ils soient) car ce sont ceux de son métier et c’est sous cette forme qu’il communique le plus efficacement avec ses confrères pour la réalisation du système.
Il est donc indispensable qu’un outil puisse satisfaire les experts en publiant pour eux, dès le début du travail et autant de fois que nécessaire, des rapports et modèles techniques qui décriront les processus, les règles métiers, les schémas de données, les listes d’exigences et même les composantes décisionnelles des processus.
Ainsi, les experts pourront être consultés à chaque fois que la maîtrise d’ouvrage souhaitera vérifier que son projet est réaliste ou en optimiser le coût. Ces rapports doivent donc aussi aider au dimensionnement technique et financier du projet. Grâce à ces échanges, les documents techniques seront progressivement reconnus comme suffisants par les équipes de mise en œuvre pour leur transmettre le témoin du projet le moment venu.
Grâce à la production automatique de ces documents, l’expert concentrera son énergie sur le système d’information des utilisateurs et moins sur la méthode formelle et sa traduction aux utilisateurs du projet.
Le moyen le plus efficace pour faire valider une expression de besoin par des utilisateurs est de les confronter à des « cas d’utilisation » réels, et donc d’utiliser des données réelles dans le cas de la recette d’une application informatique. En fonction de cette expérience, le prototype doit donc principalement intégrer des données réelles.
Mais il doit également rester indépendant du système d’information de « production » du métier. Les contraintes habituelles d’interopérabilité et d’intégration ne s’appliquent donc pas au prototype.
De même, vis-à-vis du système d’information, du consultant ou de la DSI, la priorité est que l’outil reste simple, accessible aux métiers et aux consultants avec un fonctionnement possible sur un poste isolé. L’exemple en ce domaine vient des outils bureautiques qui, de fait, sont accessibles à tous.
Il faut laisser à l’outil la juste complexité liée à son seul objectif : obtenir, grâce à une mise en communication des équipes et à une construction en commun de prototypes, une adhésion formelle et contractualisable des utilisateurs, et déclencher le cycle vertueux évoqué au début de cet article.
Face à ce constat, Acapnos, projet lancé en 2007 avec le soutien d’Oseo et d’Atlanpole (incubateur public des Pays de la Loire), a développé un outil qui permet à l’utilisateur de suivre une démarche naturelle pour la description de son besoin et restitue à l’expert les éléments techniques qui lui sont nécessaires.
L’outil est centré sur un seul objectif : obtenir, grâce à la mise en communication des équipes et à la construction en commun de l’expression des besoins, une compréhension totale de celle-ci par tous ceux qui doivent la valider. Cet outil est aujourd’hui opérationnel et permet de valider des descriptions de processus, de données, de règles de gestion et des scénarios d’utilisation. Et il a effectivement permis de lever facilement des difficultés de conception qui ne l’auraient pas été sans lui. •
Cet article a été écrit par Hervé Guérin, directeur associé de Acapnos et ex-DSI de STX Cruises France.
Situations vécues
Le malaise du responsable métier face à la refonte de son système d’information : « Dans ce projet, je ne comprends pas bien ce que l’on me demande ! Quand je parle de mon métier et de son environnement, notre interlocuteur me le transcrit dans des documents auxquels je ne suis pas habitué et qui ne me permettent pas de retrouver ce que j’ai exprimé. Alors j’ai pris le temps de comprendre ces documents, avec quelques autres – pas tous les autres car cela représentait un coût trop important pour l’entreprise-, mais malgré cela je ne suis pas sûr d’avoir pensé à tout. Pour ce projet, il faudrait que j’arrive à décrire ma future organisation, à me l’approprier, et à la partager avec mes collègues pour qu’ils valident au moins les cas d’usage courants. Il faudrait même qu’ils puissent la comprendre suffisamment pour pouvoir la critiquer et l’améliorer. Ainsi, ce ne serait plus « mon » projet mais « notre » projet. Mais comment vais-je faire pour partager ce projet alors que j’ai moi-même des difficultés à me le représenter ? »
Les réticences du chef d’équipe : « Mon équipe est déjà surchargée, alors elle a d’autres priorités. Et après tout, l’expert, c’est le consultant ! Alors pourquoi devrait-on passer autant de temps sur ce projet ? »
L’attentisme du personnel opérationnel : « Mes collègues et moi, nous ne maîtrisons pas la démarche, les outils et le déroulement du projet. Nous ne savons pas vraiment combien de temps cela va nous prendre, ni quand le projet sera terminé. En plus, ce temps passé ne sert pas notre performance au quotidien. Malgré tout, nous savons que le projet ne peut pas se faire sans nous, et nous devons d’ailleurs valider quantité de documents que nous ne comprenons pas toujours très bien, mais nous n’avons pas le choix. Nous avons l’impression de nous mettre en danger en entrant dans un tunnel dont nous ne connaissons ni la structure, ni le bout. »