Je voulais évoquer le sujet du client mais il faut avant introduire un certain nombre de notions et de définitions dans le domaine d’un projet.
On a vu MOA, AMOA et MOE mais ce sont de grandes fonctions. Et puisqu’on va rencontrer des projets plus complexes, je préfère commencer donner une vue complète et peu détaillée avant de développer chaque acteur d’un projet.
Donc on résume. Dans un projet, vous avez le client. Mais le client n’est pas nécessairement le client final. Un promoteur fait construire une résidence. Il sera donc le client de l’architecte et des entreprises qui participeront au chantier. Ensuite, il revendra les appartements à de futurs propriétaires. Ces derniers sont donc clients du promoteur.
Pour autant les futurs propriétaires ne sont pas toujours les utilisateurs finaux des logements. Ils peuvent louer leur bien. L’utilisateur final du logement sera donc l’occupant. Mais lors de l’avancée du chantier, c’est le client qui signe les chèques.
Il en est de même pour les projets informatiques. Un client peut être une DSI (Direction des systèmes d’informations) qui a besoin d’un de service (comptabilité, commercial, …) et va contacter un spécialiste pour réaliser son besoin. Ce n’est pas le directeur qui utilisera le logiciel mais c’est lui qui a passé les commandes et signé les chèques.
Mais le directeur ne connaît pas pleinement les besoins du service. Il va donc désigner une personne dans le service, un interlocuteur privilégié, qui va exprimer ces besoins. On retrouve là le rôle de la MOA. Cette personne sera en relation avec le spécialiste.
Deux situations, soit au niveau de la DSI il existe une équipe capable de réaliser le besoin, soit il faut passer par un prestataire pour répondre au besoin. Pour rester simple, nous allons considérer deux hypothèses :
- la DSI a une équipe interne qui peut développer le besoin (MOE),
- il existe dans cette équipe une personne qui a des compétences fonctionnelles et techniques suffisantes pour formaliser le besoin (AMOA ici en tant que chef de projet).
On a retrouvé tous nos rôles et on voit apparaître le cycle de développement en V.
Dans un monde parfait, le besoin est parfaitement exprimé. Les développeurs produisent l’application et … la mettent à disposition des utilisateurs après une série d’étape qui ont validé la conformité de l’application.
Apparaît alors une nouvelle activité qui est comment permettre aux utilisateurs d’accéder à leur application. Cette activité est réalisée par un autre service de la DSI : la production. Ce sont eux qui vont se charger de cela.
Restons dans un monde parfait, ils ont des infrastructures suffisantes (pc, réseau, serveurs, …) pour que les utilisateurs clients de l’application puissent l’utiliser. Une application est utilisée en journée par les utilisateurs. Elle peut aussi fonctionner la nuit lorsqu’il est nécessaire de faire des traitements complexes. Dans tous les cas, l’équipe de production s’assurera que l’application rende le service.
On parle ici du coût d’exploitation du projet. Comme dans un immeuble, bien que construit, il faut que les parties communes restent fonctionnelles. Les concierges vont maintenir propre la résidence et rendre divers services, l’ascensoriste de chez Kone va vérifier que l’ascenseur fonctionne, le jardinier entretient les espaces verts, …
Cependant, si un utilisateur n’est pas satisfait du service, il peut adresser ses demandes à une personne désignée, l’AMOA par exemple ou quelqu’un d’autre, qui fera le lien avec l’équipe concernée (développement ou production)
Dans le cas d’un immeuble, adressez vous à votre Syndic.
On verra les problématiques d’évolutions plus tard.
Maintenant que l’on a fait le tour d’un projet de complexité moyenne dans un monde parfait, on peut s’intéresser en détail à chaque acteur du projet … et se demander ce qui se passe lorsque tout n’est pas parfait.