–
Réussir son analyse des besoins
Dans la conduite d’un projet informatique
Octobre 2007

Réussir son analyse des besoins dans la conduite de projets informatiques
Octobre 2007
Préambule
Ce document est réalisé dans le cadre du PRAI (Programme Régional d’Actions
Innovatrices) conduit par la Région Midi-Pyrénées et soutenu et cofinancé par l’Union
Européenne.
Il est accessible dans le centre de ressources pour l’Internet Public et Citoyen financé par le
PRAI : www.ardesi.fr
L’objectif de ce programme est de favoriser le développement de contenus et de services
numériques de qualité créés par les collectivités territoriales de la Région.
Pour aller plus loin :
- Le Programme régional d’actions innovatrices sur le site Internet de la Région :
www.midipyrenees.fr
- La boîte à outils « Internet Public et Citoyen » : cet espace a pour objectif de fournir
des indications et des outils à toute collectivité désireuse de réaliser ou développer
son projet Internet local.
www.ardesi.fr/page481.htm
« La présente communication n’engage que son auteur. La Commission européenne n’est pas
responsable de l’usage qui pourrait être fait des informations contenues dans cette communication. »
1
SLM/07/315

Réussir son analyse des besoins dans la conduite de projets informatiques
Octobre 2007
L’analyse des besoins est la phase initiale de toute mise en œuvre de projet. Et même si
elle demande une phase préparatoire assez longue, elle conditionne pour une grande
part la réussite et la performance de l’outil à venir. De la qualité de la demande
dépendra la qualité de la réponse.
Voici quelques clés pour mener à bien votre démarche
1 – Connaître son environnement
La conduite de projet fait appel à des environnements différents qui coexistent de l’étude
préalable au moins jusqu’à l’installation de l’outil.
Il faut prendre en compte :
- le contexte et les porteurs de projets avec leur environnement et leurs contraintes
(délais, budget…)
- les fournisseurs : service informatique interne ou prestataire de services et leur
culture (notamment leur niveau technique qui n’est pas accessible aux autres acteurs)
- l’outil et l’impact qu’il aura sur les utilisateurs (parfois agents et administrés) quel
que soit leur niveau d’intervention
Enjeux du projet
OBJECTIFS Fournisseurs
FONCTIONNALITES Solution
Utilisateurs
BESOINS
2
SLM/07/315

Réussir son analyse des besoins dans la conduite de projets informatiques
Octobre 2007
2 - Constituer l’équipe projet
Il faut s’appuyer sur des référents dynamiques et identifier tous les acteurs. Le groupe
doit être représentatif des utilisateurs du futur outil.
Il vaut donc mieux sélectionner des personnes :
- favorables à la dynamique de groupe et l’émulation qu’elle entraîne
- disponibles : leur participation au projet ne va pas ajouter une charge de travail
supplémentaire
- motivées et volontaires qui seront le premier réseau à communiquer sur l’état du
projet, et qui seront donc très utiles au moment du déploiement pour l’accompagnement
du changement
Attention : le mode projet gomme la ligne hiérarchique alors qu’elle doit continuer
d’exister par ailleurs. Il convient de communiquer finement sur les enjeux du projet, et de
définir le jeu des acteurs avec des objectifs définis.
Penser à définir un planning de réunion qui devra être absolument respecté. A chaque
réunion, son objectif avec une prise de décision concrète sur la mise en œuvre du
projet, par exemple :
- Grille d’analyse des besoins,
- Choix des fonctionnalités prioritaire,
- Validation du cahier des charges fonctionnel,
- Choix du ou des prestataires,
- Etablissement du plan de communication,
- Planning de déploiement et de formation
-…
3 – Bien communiquer pour éviter les écueils
Travailler sur un référentiel commun :
Le principe de l’équipe projet implique niveaux de technicités différents. Hors tous les
utilisateurs ne sont pas ingénieurs ou informaticiens. Il faut donc s’entendre sur un
vocabulaire commun permettra de travailler dans un cadre de référence précis et
d’éviter les quiproquos.
Faciliter l’expression du besoin :
Il faut être à l’écoute des futurs utilisateurs. Lors d’un entretien il est important de mettre
une personne à l’aise, de l’écouter et de reformuler pour prouver que son opinion est
importante. Le cadre d’une réunion empêche parfois les plus discrets de s’exprimer. Il
faut surveiller les temps de paroles de chacun et vérifier à la fin de l’exercice que toutes
les idées ont bien été prises en comptes
3
SLM/07/315

Réussir son analyse des besoins dans la conduite de projets informatiques
Octobre 2007
4 - Les questions fondamentales du besoin
Toujours penser au postulat de base : un outil informatique est toujours une interface
entre deux environnements majeurs qui justifient son existence.
Il n’est pas nécessaire de développer des fonctionnalités qui serviront à la marge de vos
activités. Il est faux de penser que l’automatisation (par le biais d’un nouvel outil
informatique) va effectuer le travail à la place des agents. Il permet de repenser les
métiers pour les faciliter les tâches et rendre les agents plus performants.
- Quels sont les deux environnements majeurs qui justifient le développement
(ou l’acquisition) de cet outil ? QUI ? QUOI ?
- Quel est le service fondamental rendu par cet outil ? POUR QUOI ? Quelles
finalités ?
- Dans quel but ce service est-il rendu ? (dans ce cas on évoque notamment
l’ensemble des fonctionnalités de l’outil à venir) COMMENT ?
C’est la réponse à cette troisième question qui représente le besoin.
Il est très important de distinguer :
- POUR QUOI, dont la réponse doit commencer par « afin de… » et formalise
l’objectif (on peut aussi remplacer la question par Dans quel but ?)
- POURQUOI, dont la réponse est « parce que » et formalise la cause.
A partir de ces questions initiales il est intéressant de s’intéresser au :
- QUAND ? : Dans quel délai ? Quelle fréquence ?
- OÙ ? : Dans le cas d’une solution informatique, il s’agira essentiellement de se
pencher sur les problématiques de mobilité des agents, de multi sites, et
d’accessibilité (borne, PC …)
- COMBIEN ? Aborde la problématique du coût.
Il faut idéalement répondre à ces 7 interrogations, car si la simplicité et le manque de
temps incitent à n’aborder que les quatre premières. Les suivantes décrivent souvent les
contraintes qui vont border le champ du projet lui-même. Il arrive aussi qu’elles soient
prépondérantes dans la problématique à définir (par exemple un outil en multi sites)
4
SLM/07/315

Réussir son analyse des besoins dans la conduite de projets informatiques
Octobre 2007
5 – Hiérarchiser les besoins
La hiérarchisation des besoins permet de définir les priorités.
Il est important de construire un tableau de bord simple qui va proposer de lister
l’ensemble des fonctionnalités qui sont souhaitées.
Pour les classer on peut par exemple leur attribuer une valeur numéraire :
3 : indispensable :
2 : important :
1 : utile …
Ne pas oublier : les utilisateurs.
Il peut être intéressant de faire une grille croisée. Lors de la mise en place d’un outil
collaboratif, la valeur du besoin peut changer en fonction du métier. Les fonctionnalités
qui sont indispensables aux Ressources Humaines, sont différentes de celles des
agents d’accueil. Aussi il faut penser au projet dans son ensemble.
Exemple :
Faire apparaître
Utilisateurs Accueil RH Cabinet la « valeur » du
besoin de 1 à 3
Besoins Du maire
Communiquer les décisions
Faire apparaître les congés
…
6 - Avant la rédaction du cahier des charges
Une fois les éléments du besoin défini et pour confirmer que le cadre du projet est
cohérent, l’idéal est de voir ce qui se fait ailleurs. Essayer de trouver une collectivité
semblable à la votre en taille et en compétence et observer les solutions qu’elle a
choisies. Ne pas hésiter à se pencher sur ses réussites mais également sur ces erreurs.
Cela pourrait permettre de gagner un temps précieux.
5
SLM/07/315

Réussir son analyse des besoins dans la conduite de projets informatiques
Octobre 2007
Conclusion
Le résultat de ce travail peut parfois aboutir à un projet complexe. Il arrive que la
solution choisie implique alors un grand nombre de changement qu’il soit en terme de
formation (à un nouvel outil) que de culture (partage de l’information).
Il ne faut alors pas hésiter à phaser et à expérimenter des sous projets plus courts. Ainsi
les futurs utilisateurs pourront s’approprier cet outil à leur rythme (fonctionnalité par
fonctionnalité).
BIBLIOGRAPHIE
Paul Hubert des Mesnards. Réussir son analyse des besoins. 2007
6
SLM/07/315