Missions opérationnelles de l’animateur

4.1 Animation phase Initialisation

4.1.1 Recrutement animateur et coordonnateurs

Un projet RAD commence lorsqu’une direction exige la réussite d’un projet informatique et engage un animateur spécialisé en communication. Cet animateur doit être dépendant de la direction générale ou d’une instance neutre en regard des principaux acteurs engagés dans le projet.

4.1.2 Présentation de la méthode choisie

La mission de l’animateur est en premier lieu d’informer les participants des contraintes inhérentes aux avantages offerts par la méthode. La direction nomme ensuite le coordonnateur des ressources utilisateurs et le coordonnateur des ressources informatiques. L’animateur détaille leurs engagements réciproques sous une forme contractuelle. Il organise avec eux le plan de communication du projet.

4.1.3 Immersion du groupe de coordination

Cette étape consiste en une immersion de l’animateur et des coordonnateurs dans le domaine fonctionnel du projet afin d’en délimiter le périmètre, puis d’en évaluer globalement les coûts. Le produit de cette étape se matérialise par divers documents qui répertorient les acteurs, les traitements ainsi que les principaux flux d’information. La production de cette phase se concrétise dans un document présentant le futur système sous la forme de 5 classes de descriptions.

A ce niveau de granularité, la perception est qualifiée de " Vision " :

Vision Stratégique : un descriptif des ambitions de la future application.

Vision Fonctionnelle : le périmètre fonctionnel et les exigences en découlant.

Vision Technologique : les solutions technologiques innovantes et l'architecture technique garantissant la faisabilité opérationnelle.

Vision Organisationnelle : l’impact et les solutions d’accompagnement du changement à appliquer aux processus et à l’organisation.

Vision Contraintes : les conditions de projet, ressources, délais, budget, visibilité.

4.1.4 Définition du plan de communication

La mission de l’animateur débute par un recensement des acteurs (entités de l’organisation et personnes physiques) en relation avec le périmètre du projet et ses dépendances fonctionnelles ou organisationnelles.

A. Structure de l’organisation : Nom de la structure, responsables, coordonnées, mission de la structure, implication dans le projet.

B. Acteur : Nom, prénoms, adresse postale, téléphonique, fax, mail, titre ou qualité, rattachement à la structure de l’organisation, rôle dans la structure.

L’animateur dérive ensuite de la liste des acteurs et des thèmes du projet une organisation en groupes de travail qui doit faire l’objet d’un large assentiment des responsables concernés.

Au niveau " Groupe de travail ", la structure du document obtenu est la suivante :

C. Identification des groupes de travail

 Complet (pour la réunion de lancement et les focus).

 Dirigeant (pour l’engagement et l’impact organisationnel).

 Verticaux (par phases : Cadrage, Design, Construction).

 Horizontaux (par thèmes, éventuellement parallélisés).

Dans chaque groupe il faut ensuite identifier des rôles ou relations acteur-groupe :

D. Relation acteur / groupe

 Rôle dans le groupe (animateur, rapporteur, membre, invité).

 Type intervention (pour action, pour information).

 Date de début, date de fin, actif / inactif, commentaire.

4.1.5 Les acteurs signifiants

La nature même des nouvelles applications implique une participation accrue de la maîtrise d’ouvrage, donc sa formation préalable. Il n’est pas sérieux d’imaginer aujourd’hui des utilisateurs significatifs ne portant aucun intérêt à une application qu’ils devront utiliser parfois durant plusieurs années. Il est fondamental, dans l’intérêt des utilisateurs, qu’ils définissent eux-mêmes le détail opérationnel de leur outil de travail.

La composition des groupes respecte un équilibre des représentations. Les participants sont représentatifs de l'ensemble des clients de l'application et sont impliqués à des niveaux de hiérarchie dotés de pouvoirs suffisants à la prise de décisions. Ce dernier point s’intitule " habilitation à modifier l’organisation ".

4.1.6 Le groupe de décision-validation

Cette structure n’est pas indispensable pour les petits projets lorsque les intervenants disposent de pouvoirs suffisants. Dans les projets plus conséquents, une structure classique telle qu’un comité de pilotage se réunira à chaque phase pour décider de la poursuite du projet ou de ses grandes orientations.

4.1.7 Les groupes " utilisateurs "

Les groupes de travail utilisateurs sont des structures de production qui ont pour rôle de :

 transmettre à l'équipe de projet les connaissances fonctionnelles,

 assurer le relais entre l’équipe technique et l'ensemble des utilisateurs,

 permettre aux utilisateurs de s'approprier le projet qui leur est destiné.

Les groupes de travail utilisateurs constituent la base privilégiée des entretiens RAD. Ces groupes ne doivent pas se limiter à une participation des niveaux supérieurs de la hiérarchie. Car, dans ce cas pourtant fréquemment rencontré, le risque évident est de passer à côté des vrais problèmes en obtenant une vision uniquement théorique doublée d’un mauvais niveau de granularité de ce qui " devrait être fait ".

Lorsque des divergences marquées apparaissent entre les visions des divers groupes, une réingénierie des procédés est en général nécessaire.

La phase de Cadrage fonctionnel alterne des groupes réduits lors des réunions de spécification et des groupes plus larges lors des réunions de validation. La phase de Design emploie le même principe. La phase de Construction s’effectue par prototypage, la séance type implique alors un ou deux utilisateurs et s’élargit au groupe lors des réunions de validation.

4.2 L’entretien propriétaire

4.2.1 Validation des visions globales

Suite à la définition d’une vision globale du projet et de son plan de communication, un entretien initial a lieu avec le futur propriétaire de l’application :

 la stratégie de la direction est précisée,

 l'engagement sur les contraintes de la méthode est obtenu,

 le but du projet, ses limites et ses objectifs sont fixés.

L'engagement RAD est un point fondamental. L'animateur s'assure ainsi de la reconnaissance des objectifs par les maîtrises d'œuvre et d'ouvrage. Il rédige et fait approuver le protocole du projet. Si tous les dirigeants signent, le principe du développement RAD est alors acquis.

Le plus important dans le fait de donner un nom à un projet est certainement le processus qui conduit à son choix en organisant une large concertation préalable à laquelle participeront le plus grand nombre d'acteurs. Cette première action qui pourrait sembler insignifiante révèle en fait le style du management.

4.2.2 Lettre d’engagement de la MOA

Compte tenu des exigences du plan de communication, un engagement nominatif des utilisateurs est planifié. Il est quantifié sur la base de l’évaluation globale du projet. Le coordonnateur de la maîtrise d’ouvrage le signe.

4.2.3 Environnement des réunions

L’animateur s'assure de la disponibilité de l'environnement matériel nécessaire à la réunion et au développement (salle équipée, vidéoprojecteur, micros puissants, logiciels, réseau indépendant si nécessaire), puis :

 les intervenants du projet sont recensés, classifiés et groupés,

 les moyens et les circuits de communication sont identifiés,

 les informations sont formalisées dans des documents normalisés,

 l’émission des convocations et des invitations est ordonnancée.

Cet ensemble est partie constituante du plan de communication. En terme d’instrumentation, l'emploi d'un courrier électronique (MS Mail, E-Mail, Lotus Note, etc.) est un minimum pour l'efficacité requise du RAD. La plupart des projets qui ont échoué ne disposaient pas d'une messagerie moderne. Cette même messagerie est un composant stratégique du groupware et du workflow. La disponibilité, sur le réseau, d'un outil de présentation classique ou Intranet de type " plate-forme de travail collaboratif " représente un autre pas significatif vers une communication intelligente et spécialisée. Cet aspect technique est d’ailleurs traité en annexe.

Tous les entretiens de groupe et toutes les réunions officielles sont organisés suivant un mode opératoire précis. Ce mode opératoire est une des techniques incontournables du RAD où chaque réunion est structurée en trois étapes :

1. pré-session (planification thèmes et minutage),

2. session (clôture et ouverture de " points d’actions "),

3. post-session (analyse des impacts).

Le mode opératoire des sessions a déjà été détaillé.

4.3 La réunion " préparatoire "

La réunion préparatoire (qui peut se confondre avec la réunion de lancement pour les petits projets) regroupe l’animateur, la coordination technique et la coordination métier. D’une durée d’une demi-journée à une journée, elle prend en compte les éléments de l'étude préalable avec pour objectifs de :

 délimiter le projet ,

 identifier le travail préparatoire,

 effectuer des collectes d'informations sur l'existant (flux, volumes),

 initier des enquêtes internes de réflexion sur les exigences.

A l'issue de cette étape, les participants disposent de tous les éléments pour réaliser la réunion de lancement.

4.4 La réunion de lancement

La réunion de lancement est une opération couplant des aspects publicitaires à la mise en évidence de contraintes organisationnelles. La notion de publicité a pour ambition de promouvoir l’intérêt du projet pour l’organisation. A cette étape, sauf cas particulier, les contraintes organisationnelles évoquées se limitent à celles induites par la participation des utilisateurs à l’expression des besoins. La réunion est organisée en deux parties. Elle débute par la partie " information " où l’ensemble des acteurs impliqués de près ou de loin dans le projet sont invités à prendre connaissance de son objectif général et des moyens et contraintes mis en œuvre pour l’atteindre. Elle se poursuit par la partie " action ", une séance de travail à laquelle seuls participent les acteurs directement impliqués dans l’expression des besoins.

4.4.1 Partie " information " du lancement

Cette étape de la réunion regroupe les acteurs suivants :

 l'animateur,

 les rapporteurs,

 les coordonnateurs du projet,

 des utilisateurs significatifs,

 des représentants des directions impliquées,

 des représentants des directions générale et financière,

 des experts des domaines concernés,

 des observateurs intéressés (facultatif).

Elle débute par une présentation des principes, avantages et contraintes du RAD. Un animateur RAD expérimenté dispose en général d’une présentation générale (de 15 à 60 minutes) et de présentations spécialisées propres à chaque maîtrise. La durée de cette étape dépend à la fois de l’importance du projet et des habitudes des participants en regard de l’organisation structurée des réunions.

Dans un second temps, la limitation du périmètre du projet est précisée à partir d’un modèle global de flux ou de cas d’utilisation, et, parfois plus simplement, d’une liste des fonctionnalités globales attendues (cette étape dure de 30 à 60 minutes). Le périmètre est alors décliné sous la forme de thèmes.

Dans le cadre du plan de communication, les utilisateurs sont répartis dans des groupes de travail organisés par thème. Cette étape doit s’effectuer en quelques dizaines de minutes.

Figure3. — Planification de la participation aux réunions

4.4.2 Partie " action " du lancement

En seconde partie de la réunion, et pour chaque groupe de travail, l’animateur va individualiser les travaux à mener en préalable au début " informatique " du projet : la phase de Cadrage.

Le travail de groupe impliquera plus tard la disponibilité totale et permanente de tous les participants, particulièrement des décisionnaires. Ce point doit être explicitement reconnu par les membres du groupe et par leur encadrement. Il conditionne la réalité du planning d’engagement des ressources (Figure 3).

A l'issue de cette réunion, les participants disposent de quelques jours pour réaliser la préparation de la première réunion de Cadrage. Ils en fixent la date définitive. Dans chaque groupe de travail, les points d’actions ouverts sont attribués, en termes de responsabilité, à la ressource la mieux à même de rechercher une solution ou des informations. Suite à l’analyse des divers points d’actions ouverts, la date de la première session de Cadrage est définitivement fixée.

En post-session, le compte-rendu de la réunion de lancement est produit. Les principes du projet et la composition des groupes et comités sont publiés.

Les utilisateurs associés en permanence à un développement sont, selon la terminologie Agile, des " end-users ". Cette condition implique la participation des exécutants effectifs des tâches à automatiser.

Le choix des utilisateurs participant au projet est aussi fonction de leur motivation . Ce point est essentiel à une méthode Agile comme le RAD, car les futurs clients du système représentent la force de proposition fonctionnelle.

La réunion de lancement est souvent considérée comme le début officiel du projet.

4.5 Animation phase CADRAGE

Un groupe de travail en phase de Cadrage réunit généralement moins d’une douzaine de personnes qui concourent à l’expression du besoin.

La phase de Cadrage se conclut par un focus de cadrage.

4.6 Animation phase DESIGN

Un groupe de travail en phase de Design réunit généralement de quatre à huit personnes qui concourent à l'élaboration de la solution.

La phase de Design se conclut par un focus de design.

4.7 Animation phase CONSTRUCTION

En Construction, il faut distinguer les groupes de prototypage et les réunions nommées focus.

4.7.1 Le groupe de prototypage

Un groupe de prototypage réunit généralement de deux à quatre personnes qui concourent au développement et à la validation permanente d’une partie de l’application. En général, l’équipe se compose d'un ou deux utilisateurs pour un informaticien de développement (deux dans le cas d’un travail en binôme).

La validation permanente, comme son nom l’indique, est réellement permanente et s’effectue au cours de chaque séance de travail avec l’utilisateur. Elle garantit, à chaque ajout de fonctionnalité dans le prototype opérationnel, la conformité au besoin.

Les avantages de l’approche itérative-incrémentale à la base du concept de prototypage " actif " sont les suivants :

 les premiers niveaux réduisent le risque,

 leurs évolutions consacrent les besoins,

 la réalisation est progressive en complexité,

 la réactivité est immédiate,

 les validations sont permanentes,

 l'utilisation partielle est envisageable,

 un site pilote peut naturellement être implanté.

4.7.2 Le focus de construction

Un développement RAD se distingue par la mise en œuvre de plusieurs techniques de réalisation qui sont détaillées dans le chapitre " méthode RAD " aux paragraphes détaillant la phase de Construction.

La responsabilité de la mise en œuvre de ces techniques est normalement du domaine de la maîtrise d’œuvre. Néanmoins, l’animateur doit en avoir connaissance, car, dans les organisations qui n’ont pas encore mis en pratique ces techniques de la qualité, il devra en initier l’usage.

4.8 L’organisation d’un focus de construction

Le facteur décisif pour fixer la cadence des focus doit être le nombre de fonctionnalités additionnelles attendues et non pas des dates fixées arbitrairement à intervalle fixe.

La notion de focus couvre en pratique l’enchaînement de plusieurs étapes contraignantes pour le SWAT (Figure 4). Concrètement, un focus débute par la planification d’une charge de travail à réaliser dans un délai précis (20 jours maximum pour les grands projets). Participent au focus tous les acteurs du projet. Outre le travail de développement, la planification comprend la préparation du focus, sa réalisation et le laps de temps nécessaire à l’exploitation des informations que cette manifestation permet de dégager. L’organisation de la communication préalable au focus relève de la responsabilité de l’animateur.

Quelques jours avant la date fixée pour le focus, en fonction de l’avancement validé, le coordonnateur technique stoppe les développements. Les utilisateurs ayant participé aux séances de spécification et de validation permanente sont alors impliqués dans une étape de vérification de la qualité fonctionnelle. Le maximum de corrections de divergences visuelles ou mineures doit être effectué. En général, la validation permanente réduit cette tâche à une simple formalité. Cette étape cesse au plus tard deux jours avant le focus.

Chaque membre du SWAT focalise alors sur l’amélioration technique qualitative de sa propre production. Si les normes de codage publiées et acceptées ont été respectées, une journée suffit pour vérifier une production de deux semaines. L’équipe procède alors à des revues croisées. Le niveau de qualité requis peut être très variable d’une application à une autre selon sa typologie. Cette étape prend fin lorsque la qualité de l’application atteint un niveau suffisant en robustesse, normalisation, documentation et conformité aux exigences fonctionnelles. Le membre du SWAT chargé de l’intégration des modules réalise alors cette opération. Il s’attache tout particulièrement à tester les interfaces des applicatifs mettant en œuvre des données communes (externes, globales).

Les utilisateurs ayant participé aux séances de spécification et de validation permanente sont alors rappelés pour la dernière étape de vérification de la qualité fonctionnelle.

L’intervention des utilisateurs est indispensable, car ils devront manipuler l’application durant le focus et ils sont susceptibles de déclencher des événements que le développeur n’aurait pas imaginés. A ce point, seules les divergences bloquantes et majeures sont corrigées. Cette opération implique un minimum de tests de non-régression et une étape complète d’intégration.

Figure 4. — Architecture de réalisation (focus de visibilité)

Durant le focus, les rapporteurs devront consigner les éventuels incidents et les observations qui ne manqueront pas d’être émises par une nombreuse assistance. Les personnes ne participant pas aux spécifications ont souvent un avis a posteriori et parfois une vision plus profonde ou plus précise des évolutions du métier. Ces ressources étant le plus souvent des décisionnaires, leurs recommandations doivent être étudiées sous un angle de vision prospective. C’est d’ailleurs souvent cette absence de vision qui confine une application dans un cadre strictement opérationnel alors qu’elle aurait pu revêtir une dimension stratégique.

L’intervalle entre deux focus ne doit pas être assimilé à un effet tunnel (même réduit). Le focus est une affaire de visibilité externe ponctuelle et non un moyen de validation interne. Entre deux focus, les concepteurs-développeurs sont en contact avec les utilisateurs qui participent en direct au codage du détail de la spécification et à sa validation immédiate. Lors d’un focus, l’utilisateur manipule la partie de l’application à laquelle il a contribué. Les spectateurs observent et critiquent. Le groupe d’animation et de rapport note les observations.

 Sur le plan des communications, l’organisation d’un focus est identique à celle d’une session de travail. Le nombre de focus dépend de la durée du projet et de sa complexité : Un projet considéré comme " petit " selon les critères du RAD engage une ou deux ressources expérimentées pour une durée de 30 à 90 jours.

 Un projet " intermédiaire " engage une équipe (SWAT, Skill With Advanced Tools) de 4 à 6 concepteurs-développeurs pour une durée de 60 à 120 jours.

 Les grands projets utilisent des techniques de parallélisation durant la phase de Design et de sérialisation durant la phase de Construction. La planification des focus dépend alors du nombre d'équipes et du style de projet.

Il est en général planifié 3 ou 4 focus pour un " petit " projet, et de 4 à 8 focus pour un projet intermédiaire.

Lors du focus, la discrétion de l’informaticien est proportionnelle à son efficacité technique et à la puissance de sa méthode.

Tableau 1. — Nombre de focus en fonction du projet
Durée du projet en jours 30 60 90 120
Nombre moyen de focus 2, 3, 4, 5

Il ne faut pas confondre la validation permanente qui découle naturellement de la présence de l'utilisateur lors du prototypage et l'état de livraison permanente qui est obtenu uniquement lors de la préparation d’un focus de Construction après la validation d’un jalon zéro-défaut .

Exemple : Considérons un projet type où la maîtrise d'œuvre est engagée pour 360 jours (SWAT de 4 personnes dans une dimension temporelle de 90 jours), la maîtrise d'ouvrage doit prévoir une charge minimale de 54 jours, le groupe d'animation et de rapport une charge de 36 jours. La prévision du nombre de focus fait état d'une possibilité de 6 à 8 focus mais comporte seulement 3 états de livraison permanente et la livraison finale.

Tableau 2. — Nombre de focus (NF) pour un projet moyen :
Dans l'ouvrage Systèmes d'Information et Processus Agiles

La phase de Construction se conclut par un focus de … recette.



Suite et compléments publiés dans l'ouvrage

Systèmes d'information et processus Agiles
Hermès Science Publication, 3 juillet 2003

Systèmes d’information et processus Agiles a pour objectif de former les ressources (maîtrise d'ouvrage comme maîtrise d'œuvre), engagées dans un projet d’organisation et/ou de système d’information.
Systèmes d’information et processus Agiles décrit d'abord les aspects stratégiques de l'Agilité puis en détaille les concepts opérationnels. Il s'adresse aux dirigeants et à tous les cadres de l'organisation, dont évidemment, les DSI et chefs de projets "informatiques" ou "utilisateurs".

Outil de compréhension de l'agilité organisationnelle et support de sa mise en œuvre technique, l'ouvrage afin d'offrir une réponse appropriée aux intérêts de chaque acteur du projet, est organisé en 3 sections :

  • Organisation et Urbanisation
  • Communications et ressources humaines
  • Agilité en conduite de projet



  • www.RAD.fr ® © Jean-Pierre Vickoff