À 

propos de la Qualité des Exigences 

z
Un outil est-il concevable pour réconcilier les utilisateurs et leurs projets de
système d'information ?
Hervé Guérin, Directeur Associé ACAPNOS
avec l'aide précieuse de Dominique Bergerot, membre du comité d’ADELI

zyxwvutsrqpo
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 ?

La maîtrise d'ouvrage doit alors valider l'ensemble de

ces exigences comme correspondant aux buts
Le contexte : Place des exigences dans qu'elle a assignés au projet.
la gestion des projets Les exigences sont exprimées avec des textes et/ou
des schémas, et elles sont en général numérotées
Ingénierie des Systèmes, Génie Logiciel et pour pouvoir plus facilement les suivre et les prendre
Gestion des Exigences en référence tout au long de la vie du projet.
Pour positionner le rôle des exigences dans les Dans ce contexte, une bonne exigence doit donc :
projets informatiques, je conseillerai tout simplement  être « mesurable » pour pouvoir la confronter au
la lecture des premiers articles du dernier n° de la produit à réaliser lors de la livraison de celui-ci,
lettre d’Adeli (n°76 été 2009) qui resituent le Génie
 être comprise par la maîtrise d'ouvrage et validée
Logiciel par rapport à l'Ingénierie des Systèmes,
par celle-ci comme représentant valablement une
l'histoire du Génie Logiciel et ses approches les plus
partie de ses buts,
récentes, qui remplacent le classique « cycle en V »
 être comprise par la maîtrise d’œuvre pour
unique (conception → réalisation → recette) par
qu’elle puisse s’engager à la respecter de
plusieurs cycles itératifs et incrémentaux allant de la
manière responsable.
conception à la réalisation.
C'est le dernier point qui distingue l'expression des
En résumé, toutes ces approches recommandent de
buts (qui peuvent être purement métiers) des
débuter un projet en définissant le (ou les) buts à
exigences du projet (qui doivent pouvoir être
atteindre avant d'aborder le comment atteindre ces
engageantes pour la maîtrise d'œuvre).
buts.
La notion d'exigence correspond à un niveau assez
Lorsqu'elle est utilisée, cette expression des buts
détaillé d'expression de ces buts mais sans être
sous forme d'exigences remplace les éléments de
encore du « comment réaliser ».
contractualisation plus classiques comme une
spécification fonctionnelle ou un cahier des charges.
Voici un exemple : pour la refonte d'un site web de
Les exigences sont identifiées, alors on peut suivre
vente grand public le demandeur pourrait avoir
tout au long du projet :
comme but « augmentation de 5% de la marge » et
comme exigences : « temps de recherche de produit
inférieur à 0,7s » (il faudrait préciser un panel de  l'évolution de ces exigences, individuellement et
recherches de référence), « obtention du label globalement, en reportant dans celles-ci toutes
d'accessibilité AccessiWeb
(2)
pour l'ensemble du les nouvelles demandes des utilisateurs, et en
site », etc. faisant valider ces changements par la maîtrise
d'ouvrage et la maîtrise d'œuvre ;
En pratique, traduire le but métier en exigences est
recommandé pour servir de base solide au contrat  la prise en compte de chaque exigence par le
entre la maîtrise d'ouvrage(4) et la maîtrise d'œuvre(5) projet car chaque écart est identifiable et peut
du projet. faire l'objet d'une analyse et d'une prise de
décision. Un écart accepté par toutes les parties
On cherche alors à ce que les buts soient devient alors une modification de l'exigence.
décomposés en exigences – éléments unitaires de la
demande – qui soient les plus simples possibles.

26  La Lettre d’ADELI n°77 – Automne 2009

 La traduction des buts en exigences est actuellement
de plus en plus recommandée pour formaliser les La qualité d'expression des attentes dépend-elle
demandes de la maîtrise d'ouvrage dans les projets alors plus de l'expertise du consultant, de ses outils,
informatiques. ou bien d'éléments  qualitatifs apportés par les
Elle est en particulier mise en avant par son rôle utilisateurs intéressés ? Car ce sont ces éléments –
important dans le référentiel de bonnes pratiques l'Envie (et la disponibilité d'esprit) et l'Adhésion - qui
CMMI(3) auquel s'intéressent actuellement la plupart seuls peuvent débloquer la Participation nécessaire
des grands donneurs d'ordres en informatique. (le temps) et la Coopération entre les différentes
équipes internes et externes.
Positionnement du problème Comment enclencher le cycle vertueux - Envie, Co­
opération, Adhésion - sachant qu'il ne se décrète pas
et que même un objectif managérial affirmé, s'il reste
La tendance actuelle consiste donc à mettre en place seul, ne conduit trop souvent qu'à une participation
un processus de Gestion des Exigences, souvent minimum ?
dans le cadre d'une démarche CMMI(3) de niveau 2,
dans le but d'optimiser les coûts et bénéfices des Peut-on concevoir un outil qui déclencherait tout cela
projets de système d'information. ou presque…?
Mais mieux gérer les exigences n'améliore pas Quel challenge devrait-il résoudre et dans quel
directement la qualité  d'expression de ces nouveau contexte ?
exigences ou leur meilleure  validation par les
demandeurs.
Or, toutes les études montrent que c'est cette qualité Impact d'exigences mal exprimées
d'expression et de validation des exigences qui pose
le plus de problèmes. De nombreuses études ont été consacrées depuis
des années aux causes d'échecs et de succès des
L'optimisation de la gestion des exigences n'apparait projets informatiques.
donc alors que comme un palliatif. Elle est utile et Ces études sont globalement très cohérentes entre
correspond à un certain état de l'art, mais en ne elles à propos des résultats suivants :
traitant pas le problème à la source, les résultats ne
peuvent être que mitigés.

Succès des projets

Beaucoup de projets n'atteignent pas les objectifs fixés

Taux de réussite des projets en 2004 : 

Succès : respect des
engagements en coût, délai et
Succès  fonctionnalités
29% Echec : projet arrêté à un stade ou 
Mitigé 
un autre 
53% 
Echec 
Mitigé : dépassement en coût, 
18%  délai ou écart en fonctionnalités 

7)
(Extrait traduit de “Chaos Rising” – Standish Group 2005 )

7 (1)
Documents téléchargeables sur le site www.standishgroup.com

La Lettre d’ADELI n°77 – Automne 2009

zyxwv 27 
 Délais et coûts

Taux d
de Ret
Retaard et
et d
de S
Surcoût ­­ 1994/2004 
1994/2004
200%
200% 

150%
150% 

100%
100%  Retard

50%
50% 
Surcoût
0%
0%  1994
1994  1996 
1996 1998 
1998 2000 
2000 2002 
2002 2004 
2004
Retards
Retards  164%
164%  131% 
131% 79% 
79% 63% 
63% 82% 
82% 84%
84% 
Surcoûts
Surcoûts  180%
180%  142% 
142% 69% 
69% 45% 
45% 43% 
43% 56%
56% 

(Extrait traduit de “Chaos Rising” – Standish Group 2005)

Les écarts sur les projets qui « dérapent » (plus de la moitié des projets) sont loin d'être négligeables, et même

zyxwvutsr
si des progrès ont été réalisés depuis 15 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 »).

Facteurs de succès
Les premiers facteurs de succès sont d'une stabilité remarquable depuis des années
(le top-3 est inchangé en 15 ans malgré tous les changements de technologies et de méthodologies !)

Classement 1994 : Classement 2005 :

  Facteurs de succès des Projets      
% des réponses    Facteurs de succès des Projets  

1er Implication des utilisateurs 15,90% 1er Implication des utilisateurs

2e Soutien de la direction 13,90% 2e Soutien de la direction

3e Demande claire et actée 13,00% 3e Objectifs métier clairs

4e Planning bien géré 9,60% 4e Optimisation du périmètre et des exigences

5e Attentes réalistes 8,20% 5e Expérience du chef de projet

6e Jalons rapprochés 7,70% 6e Processus projet itératif et/ou agile

7e Equipe compétente 7,20% 7e Gestion financière du projet

8e Maîtrise d’ouvrage bien identifiée 5,30% 8e Equipe compétente

9e Vision et objectifs clairs 2,90% 9e Méthodologie bien formalisée

10e Equipe motivée et « au travail » 2,40% 10e Outils et infrastructure standards

Autres facteurs 13,90%

(1) (1)
(Extrait traduit de “The Chaos Report” – Standish Group 1994 ) (Extrait traduit de “Chaos Rising” – Standish Group 2005 )

Les premières causes de succès des projets se rapportent donc à :

 la motivation et l'implication des acteurs métiers qui se traduisent en implication des utilisateurs et soutien
de la direction ;
 des attentes et exigences des utilisateurs claires et bien définies.

Ce qui me 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 ?

28  La Lettre d’ADELI n°77 – Automne 2009

 Situations vécues !
Nous avons l'impression de nous mettre en danger
Le malaise du responsable métier face à la refonte en entrant dans un tunnel dont nous ne connaissons
de son système d'information : ni la structure, ni le bout.
Cadre au sein d'un département métier de Comment être rassurés ? »
l'entreprise, pourquoi ce manque d'envie pour ce
projet ?

z
« Dans ce projet, je ne comprends pas bien ce que Quelle meilleure réponse apporter à ces
l’on me demande ! Quand je parle de mon métier et situations ?
de son environnement, notre interlocuteur me le
transcrit dans des documents auxquels je ne suis pas
habitué, qui ne me permettent pas de retrouver ce Quelle réponse apporter aux utilisateurs du futur
que j'ai exprimé. système ? Et comment les faire s'impliquer ?
Il ne suffit pas d'écouter  les  utilisateurs, il faut
Alors j'ai pris le temps de comprendre ces
prendre en compte tout ce qu'ils disent et dans  
documents, avec quelques autres - pas tous les
l'ordre  dans  lequel  ils  le  disent, et pour qu'ils
autres car cela représentait un coût trop important
s'expriment jusqu'au bout, il est aussi indispensable
pour l'entreprise - mais malgré cela je ne suis pas sûr
de les libérer  des  formalismes des langages
d'avoir pensé à tout.
experts.
Pour que l'utilisateur puisse reconnaître ses
Pour ce projet, il faudrait que j'arrive à décrire ma
descriptions lors des validations, toutes les
future organisation, à me l'approprier, et à la partager
informations fournies doivent apparaître dans les
avec mes collègues pour qu’ils valident au moins les
restitutions, même si elles n'ont aucun intérêt dans
cas d'usages courants. Il faudrait même qu'ils
l'étape de conception en cours.
puissent la comprendre suffisamment pour pouvoir la
critiquer et l'améliorer.
Il faut les rassurer  et donc les faire  agir et réagir,
Ainsi ce ne serait plus « mon » projet mais « notre »
sur des éléments qu'ils maîtrisent. Il faut leur fournir
projet. Mais comment vais-je faire pour partager ce
très tôt, en particulier pour les grands principes
projet alors que j'ai moi-même des difficultés à me le
structurants (processus principaux, principaux rôles,
représenter ? »
etc.…) une suite de résultats  intermédiaires  
tangibles, même s'ils sont partiels et incomplets. Le
Les réticences du chef d'équipe consultant pourra ainsi recueillir leurs avis et
Responsable d'équipe, votre coopération est-elle remarques et obtenir progressivement leur
acquise ? adhésion.
Ces résultats doivent également être partageables 
« Mon équipe est déjà surchargée, alors elle a par le plus grand nombre pour les confronter à tous
d'autres priorités. Et après tout, l'expert c'est le les points de vue utiles au projet (utilisateurs et
consultant ! Alors pourquoi devrait-on passer autant responsables des différents services, direction, etc.).
de temps sur ce projet ? »
Un des résultats indispensables à la compréhension
réelle des utilisateurs est une maquette
L'attentisme du personnel opérationnel
opérationnelle du futur système.
Utilisateur de terrain, pourquoi ce manque d'adhésion C'est le seul moyen qui leur permette de se projeter  
pour ce projet ? facilement dans la future organisation de leur travail.

« Mes collègues et moi, nous ne maîtrisons pas la Et il paraît pertinent de co­construire cette maquette
démarche, les outils et le déroulement du projet. des grands principes du futur système (fonctions,
Nous ne savons pas vraiment combien de temps cela règles, usages) avec les utilisateurs eux-mêmes et
va nous prendre, ni quand le projet sera terminé. En donc pour cela de leur fournir un outil simple qu'ils
plus ce temps passé ne sert pas notre performance pourront utiliser, de façon itérative et interactive, en
au quotidien. groupe et assistés d'un expert pour aboutir
progressivement à une vision métier cohérente et
Malgré tout, nous savons que le projet ne peut pas complète de leur futur système.
se faire sans nous, d'ailleurs nous devons valider des
tas de documents que nous ne comprenons pas
toujours très bien, mais nous n'avons pas le choix.

La Lettre d’ADELI n°77 – Automne 2009 29 

 Quels outils doit-on fournir au consultant ?
Comment 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
zyxwvu
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 à
soient) car ce sont ceux de son métier et c'est sous tous.
cette forme qu'il communique le plus efficacement
avec ses confrères pour la réalisation du système. Il faut laisser à l'outil la juste complexité liée à son
seul objectif : obtenir, grâce à une mise en
Il est donc indispensable que l'outil puisse satisfaire   communication des équipes et à une co-construction
les  experts  en publiant pour eux, dès le début du de prototypes, une adhésion  formelle  et  
travail et autant de fois que nécessaire, des rapports  contractualisable des utilisateurs, et déclencher  le  
et modèles techniques qui décriront les processus, cycle vertueux évoqué au début de cet article.
les règles métiers, les schémas de données, les
listes d'exigences et même les composantes 
décisionnelles des processus. Un outil
Ainsi, les experts pourront être consultés à chaque Face à ce constat, j’ai lancé en 2007 un projet avec
fois que la maîtrise d'ouvrage souhaitera vérifier que le soutien d'OSEO et d'Atlanpole (incubateur public
son projet est réaliste ou en optimiser le coût. Ces des Pays de Loire) pour proposer un outil qui
rapports doivent donc aussi aider au permette à l'utilisateur de suivre une démarche  
dimensionnement technique et financier du projet. naturelle pour la description de son besoin et
Grâce à ces échanges, les documents techniques restitue à l'expert les éléments  techniques qui lui
seront progressivement reconnus comme suffisants sont nécessaires.
par les équipes de mise en œuvre pour leur L'outil est centré sur un seul objectif : obtenir, grâce à
transmettre le témoin du projet le moment venu. la mise en communication des équipes et à la co-
construction de l'expression des besoins, une
Grâce à la production automatique de ces compréhension totale de celle-ci par tous ceux qui
documents, l'expert concentrera son énergie sur le doivent la valider.
système  d'information  des  utilisateurs et moins
sur la méthode formelle et sa traduction aux Cet outil est aujourd’hui opérationnel et permet de
utilisateurs du projet. valider des descriptions de processus, de données et
de règles de gestion.
Est-il besoin de compléter (d'alourdir ?) l'outil par Et il a effectivement permis de lever facilement des
des contraintes d'intégration ou d'interopérabilité difficultés de conception qui ne l’auraient pas été
sans lui, ce dont peuvent témoigner les premiers
avec d'autres systèmes existants ? utilisateurs.
Le moyen le plus efficace pour faire valider une
expression de besoin par des utilisateurs est de les La prochaine étape consiste maintenant à
confronter à des « cas d'utilisation » réels, et donc expérimenter l’outil sur de nouveaux projets pour le
d'utiliser des données réelles dans le cas de la valider ou en étendre les fonctionnalités, mon but
recette d'une application informatique. En fonction de étant de le confronter à une variété de cas suffisante
cette expérience, le prototype doit donc pour savoir ce qu’il apporte en plus des outils
principalement intégrer des données réelles. habituels, en fonction des types de problèmes
rencontrés.
Mais il doit également rester indépendant du système
Si ma vision du recueil des exigences vous a

zyvu
d'information de « production » du métier. Les
contraintes habituelles d'interopérabilité  et  intéressée et si vous pensez qu’un tel outil peut vous
d'intégration ne s'appliquent donc pas au prototype. aider à l’atteinte des objectifs de votre projet, je vous
invite à en devenir utilisateur pilote.

N’hésitez pas à me contacter pour une présentation

personnalisée.▲

Si vous avez l'envie de prolonger cet échange :

[email protected]
06 20 88 05 60

30  La Lettre d’ADELI n°77 – Automne 2009

 Glossaire :
(2)
Accessiweb : Certificat d'accessibilité décerné par l’association BrailleNet, sur la base d'un référentiel propre,
inspiré des directives d’accessibilité des contenus Web (WCAG) du W3C.
(3)
CMMI® : Capability Maturity Model® Integration, référentiel de bonnes pratiques pour la gestion de projet
géré par le SEI (Software Engineering Institute) de l'université de Carnegie-Mellon, USA.
(4)
Maîtrise d'Ouvrage : le client d'un projet (définition personnelle, mais simple ...).
(5)
Maîtrise d'Œuvre : l'entité en charge de la réalisation du projet confié par la Maîtrise d'Ouvrage
correspondante (définition aussi personnelle et simple que la précédente).

La Lettre d’ADELI n°77 – Automne 2009 31  xw