Accompagnement client

Le recueil des besoins

M2 MIAGE IPM
Novembre // Décembre 2022

Enseignante : Raphaëlle Bour

[Link]@[Link]
Présentation de l’enseignante

 Auparavant : Consultante AMOA Assistance à maîtrise d’ouvrage

> Recueil des besoins
> Rédaction de cahier des charges
> Suivi du développement et de la mise en œuvre

 Docteure en informatique : DEMOS // une méthode de co-construction de

systèmes d’information soutenant la démocratie dans organisation
> Ingénierie des méthodes
> Conception participative et agilité
> Ethique informatique

 Aujourd’hui : Fondatrice de la société COADA // Solutions de co-

construction de systèmes d’information pour les organisations
> Cartographie participative de systèmes d’informations et audits
> Accompagnement au recueil des besoins et à la conception de systèmes
d’informations

2
Objectifs du cours
 En cours magistral , les objectifs sont les suivants
> Comprendre les enjeux du recueil des besoins dans le projet informatique
de construction de système d’information numérique
> Comprendre le processus d’ingénierie des besoins et ses différentes
approches
> Connaître des méthodes et outils utiles au recueil des besoins

 En travaux dirigés , les objectifs sont les suivants

> S’approprier les méthodes et outils du recueil des besoins
> Être capable de mobiliser les outils pour mener un recueil des besoins
pertinent

 Un examen (1h30) pour évaluer les connaissances acquises durant le cours

 Des exercices de TD pour mettre en application les connaissances (entretiens,
photolangage, mind mapping…)
 Un projet (commun avec le cours de développement d’applications internet)

3
Organisation du cours
1. Rappels sur le système d’information numérique et sa construction

2. L’ingénierie des besoins // différentes approches

3. L’importance de la phase de recueil des besoins

4. Méthodes et outils pour le recueil des besoins

4
Partie 1 : Rappels sur le système
d’information et sa construction
1.1. La distinction SI et SI numérique
1.2. La genèse du système d’information numérique
1.3. Le projet informatique // phases et position du recueil des besoins

5
Qu’est-ce qu’un système d’information ? Qu’est-ce
qu’un système d’information numérique ?
 Activité de photolangage

6
1.1. La distinction SI et SI numérique
 Qu’est-ce qu’un système d’information ?
> un ensemble d’acteurs sociaux qui mémorisent et transforment des représentations via des
technologies de l’information et des modes opératoires (Reix et Rowe, 2002)
→ L’objet du système d’information, ce sont les représentations

> le SI apparaît donc comme un véritable langage de l'organisation. C'est à travers lui
que cette dernière va se définir elle-même, définir son environnement, et les relations
qui la lient à lui (Salles, Bour, Jardat, 2020)
→ Le système d’information est un système de formalisation de ces représentations à partir
de codifications particulières : c’est un langage

> comme tout langage, le système d’information ne reflète pas de façon neutre une réalité
qui lui serait extérieure (Klinkenberg, 2015)
→ Le système d’information permet de construire la réalité dans laquelle fonctionnera
l’organisation

7
La distinction SI et SI numérique

 Comment s’exprime concrètement le système d’information ?

> Par des entités reconnues comme existant (et ayant un sens pour
l'organisation)
> Par des catégories des nomenclatures
> Par des indicateurs
> Par la description de la coopération entre les acteurs
> Par les éléments et la structure d’un organigramme
> Par un lexique les dénominations des éléments qui précèdent (et leur
définition), mais aussi des termes plus vagues

Quels sont selon vous les éléments du système d’information de

l’Université ?

8
La puissance du système d’information
 Le SI fait exister, il crée des objets
> catégorie des chercheurs-publiants → provoque des critères chiffrés, des
comportements des chercheurs et des labos...
> Nomenclatures des affections médicales (ne sont pas les mêmes dans
d'autres types de médecine) → permettent une offre pharmaceutique, des
protocoles de soins, des remboursements (ou non)...
 Le SI crée un système d’invisibilité : ce qui n’est pas dans le SI
n’existe pas
> nomenclatures de tâches d'où telle tâche est exclue
> SI comptable : pas dégradation du capital humain ni environnemental
 Le SI et l’organisation sont consubstantiels
> changement de la mission de la recherche => produire des articles
> SI comptables : les normes comptables ne se représentent pas les
entreprises comme un lieu de répartition
• les salaires, au même titre que toutes les consommations, sont considérés
uniquement comme des charges, qui donc minorent (dégradent) le résultat
• ce statut de charge donné aux salaires => entraîne mécaniquement des objectifs
de réduction de masse salariale, de limitation des augmentations de salaires,
d'externalisations, etc 9
La genèse du système d’information numérique
 Passer de la « réalité » au
système d’information
numérique

 Des filtres pour :

• Simplifier
• Façonner

 Des renforcements
• De la normativité
• Du caractère formel

 Des effets de rétroaction

10
La distinction SI et SI numérique

 Qu’est ce que le système d’information numérique ?

> Si l’on s’accorde à dire que le système d’information est le langage
de l’organisation, alors le système d’information numérique en est la
partie informatisée ( Bour, Jardat 2020)
> Il s’agit d’une sous partie « artificielle », qui nécessite l’usage de
technologies, de programmes, de méthodes et de modèles

 De quoi est composé le système d’information numérique

> De bases de données
> De logiciels, de progiciels, d’application
> De tableau de bord et plus généralement d’outils de BI
> D’infrastructures réseau, sécurité, etc

11
La particularité du SI numérique

 Le SI numérique code le SI
• selon les choix faits et les contraintes de la technologie
• réduit la complexité
• rigidifie/fige
• ex. : on ne change pas aisément la structure d'une base de données
• ex. : on ne change pas aisément un processus encodé dans un système
informatique

 Domination du quantitatif
 Normativité et performativité renforcées
 exemple des tableaux de bord

12
13
Quelques impacts du SI sur l’organisation

 Renforcement des normes

> difficultés à s'éloigner de la tâche prescrite
> limitation de l'innovation
 Impossibilité de discuter des normes inscrites dans les
logiciels
> impossibilité dispute démocratique ou "coopération conflictuelle" (Y.
Clot)
> conflits de valeurs => souffrance au travail
> l'outil de travail est aussi l'outil d'encadrement et l'outil de
contrôle
> "taylorisme assisté par ordinateur" (Gaborieau)
 Domination du nombre, du quantitatif et de l'atomisation
 Effets de rétroactions
14
15
Vidéo D. Gaboriau

16
Le filtre du passage du SI au SI numérique

 Plusieurs composantes du filtrage permettant de passer du

système d’information à sa version numérisée
> Le filtre des technologies est incarné par les choix techniques qui
sont faits
• Types de bases de données, langage informatique, développement ad hoc ou
mise en place de progiciels
> Méthodes de conception de systèmes d’information
• Ces méthodes imposent elles aussi un processus, mais surtout certains types
de formalisation
> Cependant, tout ce qui est présent dans le système d’information ne
saurait être modélisé, et encore moins encodé
> On peut ajouter à ces éléments du filtrage l’implication ou non de
futurs utilisateurs du système d’information numérique lors des
démarches de conception

17
Le projet informatique // phases et position du
recueil des besoins
 Le projet informatique permet
de passer du système
d’information au système
d’information numérique.

 Il est organisé en phases :

> Recueil des besoins
> Conception
> Développement d’un logiciel /
acquisition d’un progiciel
> Déploiement
> Maintenance

18
Partie 2 : l’ingénierie des
besoins // différentes approches
2.1. Qu’appelle-t-on les besoins ?
2.2. Missions et objectifs de l’ingénierie des besoins
2.3. Les approches traditionnelles, centrées sur le Quoi
2.4. Les approches dirigées par les buts, centrées sur le Pourquoi
2.5. Les difficultés propres au recueil des besoins

19
Qu’appelle-t-on les besoins ?

 Les besoins… un terme vague pour désigner :

> Les fonctions , c’est à dire ce que le système doit faire
> Les contraintes et les qualités attendues du système (on parle parfois
d’exigences)
> Les buts : les raisons qui motivent la création d’un nouveau système

 Ce que les besoins ne désignent pas :

> Le comment, c’est à dire la façon dont les fonctions vont être
implantées
> Les questions ayant trait au développement : choix des technologies,
description d’algorithme, ergonomie…

20
Missions et objectifs de l’ingénierie des besoins

 L’ingénierie des besoins est un processus permettant de

> Passer d’une idée floue…
> … à une spécification précise des besoins

 Les missions de l’ingénierie des besoins :

> Découvrir les besoins
> Spécifier les besoins
> Négocier et valider les besoins
> Et gérer l’évolution des besoins dans le temps

21
2.3. Les approches traditionnelles centrées sur le quoi

 Objectifs de l’ingénierie des besoins dans les méthodes

traditionnelles (telles que Merise) :
> Décrire ce que le système doit faire (schéma conceptuel)
> Faire valider la description (maquette et prototypage)

 Ici, l’étape de découverte du besoin se fait à la lecture du

cahier des charges et via des interviews.

 Ce processus est centré sur le QUOI : qu’est ce que le

système doit faire ?

22
2.3. Les approches traditionnelles centrées sur le quoi

 Pourquoi est- ce insuffisant aujourd’hui ?

> Part du principe que les besoins sont stables
X Faux : les organisations d’aujourd’hui changent très rapidement , les
besoins aussi (parfois même au cours du projet !)

> Part du principe que l’analyste qui a rédigé le cahier des charges
connaît tous les besoins
X Faux : on sait aujourd’hui que les parties prenantes ont des visions
différentes sur le projet (utilisateurs finaux, managers, responsables
de mise en place du système, etc)

> Part du principe que le schéma conceptuel permet de valider les

besoins
X Faux : le schéma conceptuel est déjà une interprétation du besoin, une
spécification abstraite qui est difficile à valider. Il est plus aisé de
valider un document reprenant les besoins.

23
2.4. Les approches dirigées par les buts, centrées sur le pourquoi

 Objectifs de l’ingénierie des besoins dirigée par les buts

> Découvrir les besoins en partant des buts et objectifs que le système doit
garantir
> Spécifier les besoins dans une forme précise et non ambiguë
> Valider les besoins avec toutes les parties prenantes
> Négocier les besoins en identifiant et en gérant les conflits entre points
de vue divergents
 Les règles dans l’ingénierie des besoins centrée sur le pourquoi :
> La spécification des besoins n’est complète que si elle répond à tous les
buts
> Un besoin n’existe que s’il y a un but qui justifie sa présence dans la
spécification
> Tous les acteurs apportent des points de vue intéressants, parfois
divergents, qui peuvent générer des conflits. Le recueil des besoins dirigé
par les buts doit permettre de les expliciter et de les régler.

→ Se centrer sur le pourquoi afin d’en dériver un quoi motivé

→ Décrire le quoi en termes d’objectifs que le système doit
satisfaire et non de spécification des fonctionnalités du système
24
2.4. Les approches dirigées par les buts, centrées
sur le pourquoi
 Les buts ne sont pas simples à
décrire. Ils peuvent être décomposés
de différentes manières :
> Par niveaux d’abstraction
• Des buts stratégiques de haut niveau…
• Jusqu’au buts techniques de bas niveau
• On peut établir un graphe de buts afin de
décomposer les buts de haut niveau en de
multiples buts de niveau moyen et de bas
niveau
→ Permet d’assurer le passage du pourquoi
au quoi

> Par catégories :

• Buts fonctionnels
• Buts non fonctionnels
→ Permet de faire une distinction entre
fonctions attendues et qualités attendues

25
Les difficultés propres au recueil des besoins
 Le système doit être considéré selon de multiples points de vue :
socio économiques, physiques, opérationnels, évolutifs etc.

 Il y a d’autres aspects à prendre en compte en plus des aspects

fonctionnels du système qui viennent en premier lieu à l’esprit,
ceux ci peuvent être en conflit les uns avec les autres

 Il y a de nombreuses parties prenantes qui ont des points de vue

divergents , voire conflictuels.

 Les spécifications des besoins peuvent être entachées de

nombreuses erreurs et certaines d’entre elles peuvent avoir des
effets désastreux sur les étapes suivantes du développement et/ou
sur la qualité du produit final.

26
Partie 3 : L’importance de la
phase de recueil des besoins
3.1. Demander pourquoi : une question d’éthique
3.2. Les constats d’échec au sujet des projets informatiques
3.3. Le développement du Shadow IT et la question de
l’innovation

27
Demander pourquoi, une question d’éthique
 On l’a déjà dit, le logiciel n’est pas un simple outil neutre :
• Il est une sous partie du système d’information, c’est à dire d’un système
de représentation
• Il est donc porteur d’une certaine vision du monde

 S’interroger uniquement sur le quoi revient à ne pas s’intéresser

à la formation du système d’information lui même, de le considérer
comme « allant de soi ».

 Demander pourquoi revient à interroger le niveau du système

d’information (sans forcément le remettre en cause)

 Les différents enjeux éthiques liés :

• La question du respect des points de vue divergents
• La question de la désinformation
• La question de la gouvernementalité

28
Les constats d’échec au sujet des projets
informatiques
 Les risques liés à une phase de recueil des besoins insuffisante :
> Incohérence entre le système développé et les besoins réels :
• Besoins changeants
• Expression des besoins incomplète
• Sur spécification
> Manque de participation des parties prenantes (et notamment des
utilisateurs)
• « Résistances » au changement
• Freins au projet

 Rapport Chaos report du Standish Group :

> 80% des projets informatiques échouent : soit ils sont abandonnés (30%),
soit ils sont terminés sans respect des charges et des coûts (50%). Les deux
principaux facteurs d’échec :
• Difficultés au niveau des besoins (exigences mal définies ou besoins périmés)
• Manque d’implication des utilisateurs

29
Le développement du Shadow IT et la question de
l’innovation
 Conséquence directe des problèmes d’éthique et des difficultés
rencontrées lors des projets informatiques
→ Le développement du Shadow IT : parties de système d’information
réalisées et mises en œuvre au sein d'organisations sans
approbation de la direction des systèmes d'information

 Inconvénients
> Activité chronophage
> Perte de référentiel
> Risques de sécurité (perte de données notamment
 Avantages
> Capacité des utilisateurs à conceptualiser un besoin pour le transformer
en outil
> Autre vision… autre outil
> des possibilités d’innovation considérables

30
Partie 4 : Méthodes et outils
pour le recueil des besoins
4.1. Organiser la phase de recueil des besoins : étapes et livrables
4.2. Des outils pour faciliter la phase de recueil des besoins
4.3. Le recueil des besoins participatif // l’exemple de la méthode DEMOS

31
4.1. Organiser la phase de recueil des besoins //
étapes et livrables
 Cadrage du projet :
• Objectifs stratégiques → Note de cadrage
• Périmètre du projet
• Instances décisionnaires

 Organisation du recueil des → Feuille de route de la phase de

besoins : recueil des besoins
• Identification des parties prenantes
• Planification de la phase de recueil
des besoins

 Spécification des besoins :

• Découverte des besoins →Document de spécification des
• Spécification des besoins besoins

 Validation
• Négociation autour des
spécifications des besoins → Document de spécification des
• Validation du document de recueil besoins validé
32
des besoins
4.1. Organiser la phase de recueil des besoins //
étapes et livrables
 Cadrage du projet // les questions qui se posent

> Pourquoi :
• Quel est l’objet, la raison d’être du projet ?
• Quels sont les objectifs stratégiques que le nouveau système doit
atteindre ?

> Quoi :
• Quels sont les domaines / services couverts par le projet ?
• Quel type d’outil informatique : logiciel ? Progiciel ?

> Qui :
• Qui est le commanditaire du projet ?
• Qui sont les bénéficiaires du projet ? Les personnes impactées ?
• Qui compose l’instance décisionnaire du projet (comité de pilotage) ?
• Qui compose l’instance de gestion du projet (comité projet) ? 33
4.1. Organiser la phase de recueil des besoins //
rappels sur la distinction logiciel - progiciel
 Logiciel
> Il a une utilité fonctionnelle (logiciel applicatif métier)
> Il est créé à la demande d’un client (logiciel spécifique)
> Il est un outil de travail pour les utilisateurs
> Il est composé de programmes informatiques
> Il s’appuie sur des données, donc sur une base de données

 Progiciel
> Contraction de « produit » et de « logiciel »
> Un progiciel est un logiciel « standard » (logiciel sur étagère)
> Il est développé par un éditeur à destination d’une multitude de clients
> Les PGI (Progiciels de gestion intégrée) et les ERP (Enterprise Resource
Planning) sont des progiciels dont la couverture fonctionnelle est très
large pour l’entreprise : RH, comptabilité, gestion financière, vente,
approvisionnement, stocks, distribution, etc) → un seul progiciel pour
tous ces domaines.
> Un progiciel intègre la base de données et propose des tableaux de bord 34
4.1. Organiser la phase de recueil des besoins //
étapes et livrables
 Organisation du projet

> Identification des parties prenantes :

• Distinction comité de pilotage / comité de projet
• Identification des futurs utilisateurs
• Constitution de groupes de travail

> Planification de la phase de recueil des besoins (où, quand)

• Planification des ateliers avec les groupes de travail / des entretiens
• Planification des réunions de compte rendu auprès du comité projet
• Planification des réunions de validation avec le comité de pilotage

35
4.1. Organiser la phase de recueil des besoins //
rappel sur les acteurs des projets informatiques
 Du côté du besoin :
> Le commanditaire : celui qui prend la décision de faire développer ou
d’acheter un logiciel
> Le client : celui qui paye pour le produit
> Les utilisateurs : les futurs utilisateurs du logiciel (utilisateurs
directs ou indirects)
> Le chef de projet fonctionnel

 Du côté de la solution
> En cas d’achat de progiciel : une société éditrice de progiciels
• Commerciaux, consultants métier, consultants techniques
> En cas de développement de logiciel :
• Architectes, développeurs, concepteurs et chef de projet technique (en
interne ou chez un prestataire)

 En accompagnement : une assistance à maîtrise d’ouvrage

36
4.1. Organiser la phase de recueil des besoins //
rappel sur les instances des projets informatiques
 L’instance décisionnaire : comité de pilotage
> Le commanditaire
> Le client ou son représentant
> Le chef de projet fonctionnel

 Définit la stratégie à suivre pour le projet (ex : achat

d’un progiciel ou développement spécifique)
 Fait les arbitrages (ex : planification du projet, acteurs
impliqués) et prend les décisions de passage d’une étape à
l’autre
 Valide la/les livraisons
 Accorde les moyens (financiers, RH, temps)

37
4.1. Organiser la phase de recueil des besoins //
rappel sur les instances des projets informatiques
 Le suivi opérationnel : comité de suivi ou comité de projet
> Le chef de projet fonctionnel
> Le chef de projet technique
> Le commanditaire ou son représentant
> D’autres parties prenantes peuvent être intégrées : comité
d’utilisateurs, membres de l’équipe technique, etc
→ suivi de l’avancement du projet, coordination, préparation de COPIL

 Le comité d’utilisateurs
> Sélection de futurs utilisateurs impliqués de manière plus ou moins
importante dans les différentes étapes du projet
> Son rôle est à minima d’effectuer la recette.

38
4.1. Organiser la phase de recueil des besoins //
étapes et livrables
 Spécification du besoin

> Par groupe de travail

• Identification des buts et sous buts liés au projet
• Identification des besoins (fonctionnels)
• Identification des contraintes (non fonctionnelles)
• Cartographie des besoins et contraintes

> Mise en commun

• Cartographie globale des besoins et contraintes
• Identification des conflits (buts, besoins, contraintes)

39
4.1. Organiser la phase de recueil des besoins //
étapes et livrables
 Différents niveaux de validation

> Validation des comptes rendus de chaque atelier de travail auprès du

groupe de travail

> Discussions autour de la cartographie globale auprès du comité de

projet
• Présentations des points de divergence
• Discussion et négociation
• Propositions de solutions

> Validation de la cartographie globale et des solutions proposées

auprès du comité de pilotage

40
4.2. Des outils pour faciliter la phase de recueil
des besoins
 Plusieurs types de mise en contact :
> Les entretiens
> Les ateliers de travail participatifs

 Plusieurs moyens pour animer et organiser les discussions :

> Le mind mapping (ou carte conceptuelle) pour organiser les idées
> Le photolangage pour exprimer des concepts abstraits et/ou se projeter
dans le futur
> La user story pour exprimer un besoin

41
4.2. Des outils pour faciliter la phase de recueil
des besoins
 Les entretiens // démarche générale

 Préparation logistique
 Grille d’entretien
> Informations cadres
> Enchaînement des questions
> Thèmes
> Contenu des questions
> Types de questions
 Conduite de l’entretien
> Phase d'exposition
> Phase d'écoute, compréhension et analyse
> Phase de conclusion
> Difficultés
 Exploitation
 Validation

42
Guide pour mener des entretiens

 Préparation (1/2)

• Choix des personnes (nominatif)

• Choix du type de lieu
• sur site ou loin du site
• près du poste de travail ou dans une salle de réunion, etc.
• Communication avec la hiérarchie
• document de présentation de l’étude
• document de présentation des conditions de l’entretien (contenu, lieu,
durée)
• présentation simplifiée de la démarche (planning, étapes, validations,
etc.)
• éventuellement, double des documents qui seront transmis avant entretien

43
Guide pour mener des entretiens

 Préparation (2/2)

• Prise de rendez-vous
• fiche de suivi de rendez-vous
• réservation des locaux
• moyens (rétro, tableau, poste de travail)
• Réalisation de la grille/guide d’entretien
• Transmission des documents
• guide d’entretien
• documents complémentaires
• liste des documents à préparer (par la personne rencontrée)
• liste des décisions à prendre
• Confirmation (2 jours avant)

44
Guide pour mener des entretiens

 Guide d’entretien : informations cadres

• Informations cadre
• étude concernée
• objectif de l'entretien
• types de cibles (fonctions)
• argumentaire de départ
• Par interview
• date, heure et durée de l'interview
• nom et fonction interviewé (orthog. et intitulés exacts)
• nom et fonction du ou des interviewers
• rappels à faire (documents transmis, décisions à prendre,etc.)
• documents à récupérer
• informations logistiques à demander pour aider la suite de l’étude (qui
faut-il rencontrer, quels docs demander, etc.)

45
Guide pour mener des entretiens

 Guide d’entretien : enchaînement des questions

• Questions d'introduction
• gagner la sympathie
• laissent l'interlocuteur s'exprimer
• Questions qualifiantes
• vérifier que l'interlocuteur est le bon
• ou orientation si questionnaire multiple
• Questions de mise en route
• amener le correspondant vers les questions précises objets de l'enquête

46
Guide pour mener des entretiens

 Guide d’entretien : questions et thèmes

• Questions spécifiques (centrées sur l'objectif)

• leur forme doit être en cohérence avec les traitements futurs (voir "types
de questions")
• respecter les langages spécialisés
• Les questions doivent être regroupées par thèmes
• Thèmes
• chaque thème doit avoir un titre
• entre 3 et 5 thèmes sont en général suffisants, mais il peut y avoir des
exceptions

47
Guide pour mener des entretiens

 Guide d’entretien : thèmes

• en cas de thèmes trop nombreux, se poser la question : y a-t-il des
regroupements possibles ?
• attention aux questions mal positionnées dans un thème, aux répétitions des
mêmes questions sous des formes différentes
• Vérifier que l'ordre des thèmes est convaincant
• puis travailler l'enchaînement des questions au sein d'un
• même thème
• Prévoir les transitions entre les thèmes
• pour éviter des "blancs", des ruptures de rythme
• parfois, une simple phrase suffit à assurer cette transition,
• mais encore faut-il l'avoir préparée à l'avance…

48
Guide pour mener des entretiens

 Guide d’entretien : contenu des questions (1/2)

• Éviter les questions trop vagues, trop générales

• Pour garantir un bon rythme à l'entretien, pour bien gérer le temps, mais
surtout pour avoir des réponses intéressantes
• il faut poser des questions précises, bien informées,
• exemplifiées
→ Plus la personne qui pose les questions est informée, plus elle récoltera
d'information utile (et inversement !)
• Ainsi, on aide l'interlocuteur à répondre au lieu de risquer de le
mettre dans l'embarras
• ex. ne pas demander "quelle est votre vision de…" ni "quelle est votre
définition de…"
• mais dire plutôt "voici une définition, qu'en pensez-vous ? êtes-vous en
accord avec cette définition ? " …/…

49
Guide pour mener des entretiens

 Guide d’entretien : contenu des questions (2/2)

• La grille doit être orientée vers l'organisation à laquelle appartient

la personne interrogée, vers ses activités et vers son actualité
• Il faut donc s'informer pour spécifier les questions
• Ne jamais poser de questions dont il est possible de trouver les réponses
dans les sources d'information disponibles
• ex. : pas de question du type "Pouvez-vous nous décrire l'activité de votre
société ?", ou "quels sont les principaux produits de votre société
? » (sauf si vous voulez vérifier l'information que vous avez collectée=
• Pensez à demander quels sont les problèmes qui ont été rencontrés
• en rapport à la thématique de l'entretien
• Les problèmes, voire les échecs, apportent souvent (s'ils sont analysés)
beaucoup plus d'information utile que ce qui "roule« sans problème

50
Guide pour mener des entretiens
 Guide d’entretien : les phases de l’entretien

• Phase d’exposition
• Rappels du contexte, des objectifs, de la règle du jeu (prise de notes,
validation prévue, etc)
• Rappel des suites de l’entretien (planning, contenu…)
• Phase d’écoute, compréhension, analyse
• respect du rythme et des silences des interlocuteurs (mais dans le même temps,
avoir une attitude incitatrice)
• position neutre, pas de jugement
• non directivité dans l’ordre des thèmes
• reformulations en cours, avec support divers
• Phase de conclusion
• exprimée par l’enquêteur ou l’interlocuteur (suivant les types d’entretiens)
• reprise des principales informations recueillies ou décisions prises
• rappel des documents complémentaires à fournir
• rappel de la suite (date d’envoi du compte rendu, délai pour modifications,
etc.)
51
Guide pour mener des entretiens

 Guide d’entretien : les difficultés (1/2)

1. Semble inventer les réponses plutôt que d’admettre son ignorance

• Après l’entretien, regrouper les réponses suspectes
2. Essaie de dire à l’enquêteur ce que celui-ci veut entendre, plutôt
que la réalité
• Eviter de poser les questions sous une forme qui sous-entende les réponses
• Après l’entretien, regrouper les réponses suspectes
3. Donne une profusion de détails hors sujet ou fabule
• Avec courtoisie mais fermeté, ramener sur la bonne voie
4. Cesse de parler si l’enquêteur prend des notes
• Ne plus prendre de note, limiter le nombre de questions
5. Tente d’accélérer l’entretien
• Proposer de revenir plus tard

52
Guide pour mener des entretiens

 Guide d’entretien : les difficultés (2/2)

6. S’estime satisfait de l’existant et ne veut rien changer
• Faire développer de façon précise les avantages actuels
7. Paraît méfiant, reste sur sa réserve, semble dissimuler des choses
• Essayer de l’amener sur le sujet qui le préoccupe
8. Sabote l’entretien par un manque évident de coopération - Refuse de
donner l’information
• Demander : "si quelqu’un me fournit cette information, vous sera-t-il
possible de la vérifier ?". Le faire.
9. Se lamente sur son travail, sa hiérarchie, ses collaborateurs…
• Ecouter avec intérêt, noter ce qui est intéressant. Faire une déclaration
amicale mais qui n'engage pas. Ramener au sujet de l'enquête. Par la suite,
vérifier, au cas où...
10. Fait preuve de beaucoup d'enthousiasme pour tous les gadgets,
nouvelles idées, etc.
• Noter les idées valables. Ne pas se laisser gagner par un enthousiasme
excessif 53
Guide pour mener des entretiens

 Guide d’entretien : exploitation de l’entretien

• Pendant l'entretien / Deux « écoles »

1. La prise de notes exhaustive
• reprise des termes précis
• aide au compte rendu destiné aux interviewés
• plus long à exploiter pour diagnostic
2. La prise de notes synthétique
• perte d'information
• risque d'interprétation abusive
• focus sur l'essentiel
• diagnostic / synthèse déjà prêt(e) en partie

• Après l’entretien : compte-rendu dans les 2 / 3 jours qui suivent

54
Guide pour mener des entretiens

 Guide d’entretien : validation de l’entretien

• Première validation (éventuellement)

• envoi à l'interviewé
• du compte rendu
• de schémas associés, commentés
• à envoyer dans les 3 jours
• exiger un délai de réponse bref
• Deuxième validation
• confrontation (interne à l'équipe projet) des entretiens
• recoupements, élimination réponses aberrantes, etc.
• diagnostic, synthèse
• (éventuellement) envoi des conclusions pour recueil des réactions

55
4.2. Des outils pour faciliter la phase de recueil
des besoins
 Les ateliers de travail participatif

 Préparation logistique
> Taille du groupe
> Durée des séances
 Elaboration des règles de l’atelier
> Comportement général
> Circulation de la parole
 Organisation du séquencement de l’atelier
> Activité brise glace (non obligatoire)
> Réflexions / partage / discussions
> Choix des outils
 Supports à l’atelier de travail
> Paper board
> Supports numériques
 Exploitation et compte rendu

56
La préparation d’un atelier participatif

 La règles des 7P
> Pertinence : quels sont les objectifs de l’atelier ?

> Participants : qui sont les participants ? Pourquoi ?

> Produit attendu : quelles sorties à la fin de l’atelier ? Livrable ?

Compte-rendu ? Photos ?

> Process : comment va se dérouler l’atelier ? Quelles sont les différentes

séquences ?

> Préparation : qu’est-ce qui doit être préparé en amont ?

> Pratique : comment l’atelier se déroule de façon logistique ?

> Pièges : quels sont les risques ? Comment y remédier ?

57
Activités – atelier de travail participatif

 Brise glace

 Emergence d’idées

 Construction de plan d’actions

 Priorisation

58
La préparation d’un atelier participatif
 Selon vous, quels sont les risques/les pièges lors de
l’animation d’un atelier participatif ?

 Règle du jeu :
• Placez-vous par groupe de 5
• Prenez 3 post-it chacun
• Sur chaque post-it, notez une idée de piège/risque → 5 minutes (en
silence)
• A tour de rôle, vous lirez les post it et vous les organiserez
• A la fin du tour, un rapporteur pour chaque groupe présentera le
travail

 Nous déterminerons ensemble les solutions qui peuvent être

envisagées…

59
Posture d’animateur/facilitateur
 Les facilitateurs veillent à ce que chacun ait la même opportunité
de participer. A travers une écoute active et en posant les «
bonnes » questions, ils démontrent que chaque contribution a sa
valeur propre.

 Deux rôles :
• Cadrage
• Ecoute active

 Beaucoup de qualités :
• enthousiasme, dynamisme, bonne humeur (l’humour peut aussi être très
utile…)
• bienveillance, écoute, respect, tolérance, partage
• Autorité (sans autoritarisme !)

 Un peu nerveux à l’idée d’animer un atelier ? C’est normal ! Les

participants le sont peut-être aussi…
60
Quelques bonnes pratiques (1/2)

 A chaque tour de table, assurez-vous que tout le monde a

compris les règles et rappelez le temps dédié au tour.

 Pour un « participant perturbateur » : trop bavard, qui

interrompt les autres, montre une supériorité…
• Lui retirer la parole « le temps est limité, chacun doit pouvoir
s’exprimer » tout en soulignant les apports de sa prise de parole
• Désignez vous-même les personnes qui peuvent prendre la parole en vous
assurant d’une équité
• Faites respecter les règles suivantes : « tout le monde doit pouvoir
s’exprimer » et « lorsqu’une personne parle, les autres écoutent »

61
Quelques bonnes pratiques (2/2)

 Sur la gestion du temps :

• Utilisez le sablier pour minuter les temps de parole : tout le monde
voit le sablier.
• Ne laissez pas dériver les discussions, ramenez toujours au sujet. Ca
peut-être fait sur le ton de l’humour : « je vous propose qu’on en
reparle pendant le repas ! »
• De l’autorité, sans autoritarisme : sachez vous adapter pour accepter
un temps de parole un peu plus long que prévu.

 Ecoute active
• Regardez la personne qui parle
• Reformulez ce qui a été dit si cela vous semble nécessaire
• N’hésitez pas à poser des questions, demander des clarifications
• Demandez leur avis aux autres participants lorsque vous rencontrez une
difficulté
• Prenez une minute de synthèse à chaque fin de tour
62
4.2. Des outils pour faciliter la phase de recueil
des besoins
 Le mind mapping pour organiser les idées

 Dans quels cas utiliser le mindmapping ?

> Lors de la phase de cadrage pour définir l’organisation du projet
> Lors de la phase de recueil du besoin
> Pour organiser les buts et sous buts
> Pour organiser les besoins autour des buts

 Les caractéristiques du mind mapping (par Tony Buzan) :

[Link] sujet d'attention est cristallisé dans une image centrale
[Link] grands thèmes irradient, ou se ramifient comme des branches à partir
de l'image centrale
[Link] branches comportent une image ou un mot imprimé sur une ligne. Les
thèmes de moindre importance sont également représentés sous forme de
branches partant de branches plus centrales
[Link] branches forment une structure nodale.
63
4.2. Des outils pour faciliter la phase de recueil
des besoins
 Le photolangage

 Dans quels cas utiliser le photolangage ?

> Lors de la phase de cadrage pour exprimer la raison d’être du projet
> Lors de la phase de recueil du besoin
> Pour exprimer des buts de haut niveau
> Pour imaginer le système de demain (et ne pas « stagner » dans le passé)

 Les règles du photolangage :

[Link] d’une diversité d’images aux participants autour d’une
question claire
[Link] (dans le silence) d’une image par chacun des participants
[Link]ésentation de l’image à l’atelier et réponse à la question avec comme
point de départ la métaphore

 Le photolangage peut être couplé avec une activité de mind mapping

64
Intérêts du photolangage

 Les intérêts
• Subjectivité / point de vue
• « originalité » des réponses
• Individualité
• Ecoute
• Appui pour des questions abstraites/haut niveau
• Facilitateur pour la prise de parole
• Aspect ludique/dynamique de groupe

 A ne pas négliger
• Vérifier que chacun a compris la règle
• Imposer le silence durant le choix des images
• Respecter le tour de parole et le temps imparti à chacun

65
4.2. Des outils pour faciliter la phase de recueil
des besoins
 La User story pour exprimer un besoin

 Pourquoi la User Story est intéressante ?

> Permet de définir le pourquoi et d’en faire découler un quoi motivé
> La User story est décrite en langage naturel
> Les user stories peuvent supporter plusieurs niveaux de décomposition
> La forme des user story permet une organisation visuelle

 Comment s’exprime une user story ?

> En tant que … → prise en compte des points de vue
> Je veux … → réponse au quoi
> Afin de … → réponse au pourquoi

66
4.3. Le recueil des besoins participatif // l’exemple
de la méthode DEMOS
 La notion de méthode :
> Un processus (une démarche)
> Un langage (une façon de modéliser)
> Des outils

67
4.3. Le recueil des besoins participatif // l’exemple
de la méthode DEMOS
 L’atelier de cadrage

 Les objectifs :
> Construire une vision globale de la raison d’être du projet
> Du périmètre du projet
> Distinguer les missions de chacun
> Identifier les différents points de vue

 Les outils :
> Le photolangage
> Le mind mapping
> Les post it

68
Retour sur un atelier de cadrage

69
Retour sur un atelier de cadrage

70
4.3. Le recueil des besoins participatif // l’exemple
de la méthode DEMOS
 Les ateliers point de vue

 Les objectifs :
> Construire une représentation par point de vue
> Définir des besoins par point de vue

 Les outils :
> Modèle conceptuel
> Photolangage
> User stories

71
4.3. Le recueil des besoins participatif // l’exemple
de la méthode DEMOS
 L’atelier de mise en commun

 Les objectifs :
> Valider une représentation commune correspondant aux points de vue de
chacun
> Vérifier la possibilité de prendre en compte les besoins de tous
> Discuter les besoins antagonistes ou conflictuels

 Les outils :
> Activités de brainstorming
> Consensus
> Représentation conceptuelle / Processus BPMn
> User stories

72