SERGAM-Xpert vous présente son pôle d'expertise

AMOA transverse

Préambule

Ce document est destiné aux personnes souhaitant parfaire leur culture générale et il vise à vulgariser le rôle de l’AMOA dans les projets informatiques pour les non spécialistes fonctionnels ou techniques du domaine. SERGAM-Xpert vous présente ici un échantillon de son expertise dans le domaine fonctionnel qu'est l'AMOA transverse

Il s’adresse aux DSI, RSSI, chefs de projets informatiques et chefs de projets fonctionnels. Mais aussi à tous ceux qui veulent comprendre le sujet sans forcément vouloir en devenir expert.

Volontairement, ce document est élaboré sur un schéma didactique et ne prétend en aucun cas être la critique sous entendue d’un quelconque projet et du choix des Acteurs qui y collaboreront. Il est établi simplement pour éveiller la curiosité sur ce rôle majeur qui, s’il est oublié dans un projet, peut entraîner des retards de livraisons ou des problèmes de relations entre les différents Acteurs du projet.

Ce document n’a pas vocation non plus à expliquer comment réaliser les différentes activités et actions mais bien à présenter ce qu’elles contiennent.

Si vous souhaitez avoir des détails sur les savoir-faire, veuillez contacter SERGAM-Xpert qui répondra à vos questions.

Les termes spécifiques employés sont simples mais s’inscrivent, bien entendu, dans le vocabulaire de l’informatique de gestion.

Création : SERGAM-Xpert (2014)

Source : SERGAM-Xpert

Définition

L’assistance à maîtrise d’ouvrage (AMOA) consiste à intervenir là où la maîtrise d’ouvrage avoue ses limites, ne possède pas de temps ou de compétence pour assurer la bonne rédaction de documents nécessaires à la bonne réalisation d’un projet. L’AMOA ne se substitue pas à la maîtrise d’ouvrage dans son métier et ses activités quotidiennes. Il n’est pas là pour cela. 

Il peut exister autant de forme d’assistance à maîtrise d’ouvrage qu’il existe de maîtrises d’ouvrage. Autrement dit, de métiers.

Avant d'entrer dans le vif du sujet, il est important de rappeler une précision qui a une sérieuse tendance à emmêler les esprits : distinguer les expressions "maîtrise d'ouvrage" de "l'assistance à maîtrise d'ouvrage".

En effet, dans le monde des projets informatiques, il est courant d’entendre l’utilisation d’une expression à la place d’une autre. Notamment, lorsqu’il s’agit d’occuper un poste visant à intervenir au niveau d’un métier ou dans une maîtrise d’ouvrage spécifique. Pour ce poste, il s’agira pour le consultant d’exercer le métier de la maîtrise d’ouvrage. Il devient alors celle-ci. Cependant, il arrive régulièrement qu’on entende que ce consultant soit assimilé à un assistant à maîtrise d’ouvrage. Or, comme il a été vu plus haut, l’assistant à maîtrise d’ouvrage (AMOA) n’intervient que pour assister les équipes projet MOA dans les actions et activités qui requièrent des compétences spécifiques et suffisamment d’objectivité pour fournir des documents clairs, précis et en reflet avec la réalité. De plus, on fait régulièrement intervenir l’AMOA pour effectuer des tâches pour lesquelles la MOA liée au projet ou qui est purement métier, ne possède pas assez de temps, de disponibilité ou d’effectif (comme par exemple, pour la rédaction de cahiers des charges, effectuer des études d’opportunité ou de faisabilité, rédiger des spécifications détaillées, recetter des livraisons de programmes fonctionnels ou techniques, etc.).

Petits rappels sur les Acteurs majeurs d'un projet

Intéractions entre les Acteurs d'un projet informatique

Représentation schématisée des intéractions entre les Acteurs d'un projet informatique avec les flux d'informations, livrables et relations. (non exhaustif...)

Interventions de l'AMOA dans un projet

Qu’il s’agisse des métiers de l’informatique, du bâtiment et de tout autre domaine technique et ou fonctionnel, les maîtrises d’ouvrage et maîtrises d’œuvre existent et cohabitent dans la réalisation d’un projet, quel qu’il soit. Si on constate l’absence d’un de ces acteurs, la bonne réalisation du projet est compromise.

Une caractéristique importante de l’assistant à maîtrise d’ouvrage est qu’une fois le projet commencé, il « devient » maître ou maîtrise d’ouvrage. Non pas qu’il prenne la place de la MOA dans ses activités quotidiennes mais il communique en son nom auprès des autres acteurs du projet.

L’AMOA doit s’investir fortement dans l’organisation / la structure qui a fait appel à ses services. Cela signifie qu’il passera la majeure partie du temps allouée à la prestation, avec le client, dans ses locaux, afin d’en bien analyser tous ses éléments constitutifs : organisation, métiers, personnels, spécificités fonctionnelles, données utilisées, outils et solutions techniques présents dans le SI du client, contraintes techniques et fonctionnelles.

L’AMOA est généralement un prestataire de services. Ce statut permet d’avoir des documents qui seront objectifs et sans affect et non subjectifs. Ce qui ne dévalue nullement la qualité des livrables et des relations avec la MOA et les autres Acteurs contributeurs du projet.

Quelques activités demandées à l'AMOA

Les activités d’un AMOA en informatique de gestion sont multiples. Comme on l’a vu plus haut, il intervient là où le client (le Maître d’ouvrage n’en possède pas les moyens), essentiellement pour :

• Analyser de manière objective le fonctionnement de la structure du MOA
• Auditer l’existant : ensemble des éléments qui constitue une MOA ou d’une MOE. Le recensement se termine généralement par des préconisations d’améliorations.
• Préconiser des évolutions dans les processus de fonctionnement de la MOA
• Etudier la faisabilité de l'évolution du système d'informations d'un point de viue fonctionnel mais en tenant compte des contextes et contraintes techniques.
• Recueillir les besoins dans le cas du désir de mettre en place un nouveau système d’information : cette tâche est naturellement lourde dans un projet. Elle impose la mobilisation d’un grand nombre d’individus lorsque la MOA décide d’effectuer le recueil des besoins par elle-même. De plus, un AMOA pourra déceler des manques possibles dans les besoins car son regard sera transverse entre les différents métiers présents dans la MOA.
• Rédiger les cahiers des charges : le cahier des charges rassemble l’ensemble des besoins exprimés en tant que cible à atteindre. Il ne critique pas l’existant mais présente ce que les MOA et MOE veulent voir mis en place et en œuvre lorsque le projet sera terminé. Généralement, une erreur importante est commise dans un cahier des charges : la présentation des solutions technico-fonctionnelles. Le cahier des charges de ne soucie pas des solutions à mettre en œuvre mais tient compte des contraintes fonctionnelles (workflow, données, règles de gestion) et des contraintes techniques présentes ou souhaitées (technologies et outils informatiques à conserver).
• Rédiger les spécifications fonctionnelles générales et détaillées : il s’agit à partir d’un cahier des charges validé par le client, de détailler chaque point pour orienter les pistes de réflexions sur le « comment on va le faire » et le « quelle solution technique sera utilisée ». Le travail partira du général (description des métiers et des fonctions) pour atteindre le détail (description précise des informations et données utilisées, description des règles de gestion, de l’enregistrement des informations, etc.)
• Communiquer avec la MOE : l’AMOA connaît à présent parfaitement les besoins de la MOA. Il sait communiquer avec elle et la MOE pour l’aider dans les choix des solutions techniques et des technologies qui seront utilisées pour répondre parfaitement aux exigences de la MOA (produits du marché ou solutions spécifiques réalisées en interne ou sous-traitées).
• Effectuer les recettes fonctionnelles (et déceler les problèmes techniques consécutifs) : une fois que la MOE a livré tout ou partie des réalisations correspondant aux besoins exprimés par la MOA, l’AMOA intervient avant la maîtrise d’ouvrage pour tester ce qui a été fait. Il s’agit généralement de versions d’outils qui seront en pré-production. Cette pré-production est utilisée dans un environnement indépendant de celui de production quotidienne. Les tests qui reprennent point par point les besoins exprimés serviront à valider les versions successives des outils qui seront – une fois validés par l’AMOA et la MOA – mis en production. Cette phase se nomme la « recette fonctionnelle ».
• Rédiger les comptes-rendus qui sont de plusieurs types :
  • Les comptes-rendus des comités de projet : réunions avec tous les intervenants du projet et appartenant à la MOA, la MOE, l’AMOA et éventuellement l’AMOE. Il s’agit de connaître l’état d’avancement ou de possibles blocages du projet.
  • Les comptes-rendus MOA : comptes-rendus des réunions faites avec la MOA pour valider les informations reçues, comprises et analysées. Un compte-rendu est généralement fait au fil de l’eau, à l’issue de la réunion, avec les interlocuteurs concernés.
  • Les comptes-rendus de recettes : état des recettes fonctionnelles effectuées avec liste des fonctionnalités valides et les anomalies rencontrées. Ces comptes-rendus seront transmis à la MOE et devront être validés par celle-ci, la MOA et l’AMOA.
  • Les tableaux de bord du projet : ensemble des indicateurs positionnés sur l’échelle du temps du projet avec la mise en exergue des jalons atteints, les échéances dépassées, les points de blocage, les alertes, les solutions présentées, les résultats obtenus. Il va de soi qu’un projet qui se déroule correctement possède tous ses indicateurs placés au vert. C’est extrêmement rare.
• Aider la MOA dans ses choix de solutions technico-fonctionnelles. Cela signifie d’être informé des solutions correspondant aux besoins du client. Il peut s’agir de solutions existantes sur le marché ou de développements spécifiques, si la MOE et les finances du client le permettent.
• Rédiger les protocoles de conduites du changement. Il s’agit de rédiger les manuels d’utilisation qui informeront les MOA des modifications de comportement ou de travail qu’elles devront adopter pour utiliser parfaitement les solutions informatiques mises à leur disposition.

Quelques actions et livrables de l'AMOA

Voici quelques exemples d’actions et de livrables réalisés par l’AMOA (liste non exhaustive) :

• L’acquisition de la connaissance de la maîtrise d’ouvrage.
• Les études de faisabilité.
• Les ateliers de travail avec les intervenants du projet.
• Les ateliers de travail avec les acteurs directement concernés par les besoins.
• Les recueils des besoins fonctionnels et/ou techniques :
  • La rédaction de cahier des charges.
  • La rédaction du ou des appels d’offres.
  • Le dépouillement des offres.
  • Le choix des offres retenues.
  • La recherche de la ou des solutions correspondant aux besoins fonctionnels et techniques.
• L’analyse des différentes solutions (matrice décisionnelle).
• Le ou les choix de la ou des solutions fonctionnelles et techniques.
• L’étude des analyses d’écart entre les solutions existantes et les besoins de la MOA.
• La rédaction des spécifications fonctionnelles générales et détaillées, avec :
  • La prise en charge des règles de gestion spécifiques du Métier et du SI.
  • La prise en charge des contraintes réglementaires à considérer.
  • Les conseils sur les réglementaires de sécurité ou Métiers à prendre en considération.
  • Les conseils sur des expertises métiers.
  • Les conseils sur des expertises liées à la Sécurité du SI (ex. IAM).
• La coordination avec la MOE en charge de l’intégration et/ou déploiement de la solution retenue.
• Les recettes fonctionnelles.
• La prononciation des GO-NO GO de mise en production.
• La prononciation des périodes de vérification d’aptitude.
• Prononciation des vérifications de service régulier
• L’assistance à la MOA pour la fourniture des données pour la solution retenue.
• La rédaction des comptes-rendus :
  • D’ateliers
  • De comités de projet
• La rédaction des notes spécifiques :
  • Les alertes sur le projet (charges, planning, budget, organisation)
  • Les préconisations (réglementaires, organisation du projet, suivi de production)

Mais aussi :

• L’assistance et le support aux différentes MOA sur certaines actions complexes du projet (ex. création et suivi des tableaux de bord de suivi de projet, définition des droits et rôles d’habilitations, etc.)

Etc.

Devoirs et droits de l'AMOA

À ces activités peuvent s’en ajouter d’autres, connexes, nécessaires pour le bon déroulement du projet. Ces activités complémentaires constituent en général des devoirs et des droits que l’AMOA se doit d’appliquer.

L’AMOA se doit d’être respectueux des procédures. En cela, il devra respecter les clauses définissant son périmètre d’intervention dans le projet. Ces clauses sont décrites dans l’appel d’offres de la prestation. Également, il se devra, dans tous les cas de figures, de connaître et respecter la déontologie liée aux métiers de la MOA et en n’aucun cas, proposer des solutions mettant soit en péril les activités du client, soit risquer de mettre celui-ci en porte-à-faux avec la loi.

Cet aspect étant très rigoureux, si l’AMOA doute de la faisabilité de certains de ses choix, il devra en rendre compte à la MOA et au comité directionnel du projet, afin que toute ambiguïté soit levée et que les actions soient réalisées en toute connaissance de cause.

Les outils utilisés par l’AMOA sont ceux du client avec : les suites bureautiques (Word, Excel, PowerPoint, Outlook, parfois Access), Microsoft Visio pour les schémas techniques et fonctionnels complexes, les outils de messagerie, Internet, le réseau interne de l’entreprise, les imprimantes. L’idéal est de travailler avec des postes de travail équipés de deux écrans.

En ce qui me concerne, les documents et les projets peuvent être réalisés aussi bien en français qu’en anglais, selon les contextes imposés par le Client.

Envisager l’intervention d’un AMOA restant à son domicile est très difficilement concevable. Cette possibilité est envisageable une fois le recueil des besoins et des analyses effectués, pour rédiger ses comptes-rendus.

Un AMOA qui ne peut être en contact constant avec le client ne peut exercer ses activités. Une grande part du temps est dédiée à l’acquisition de l’information et à la capitalisation de la connaissance qui sont présentes chez un client. Il s’agira de reproduire ce qui a déjà été fait et approuvé chez des clients afin d’être sûr des résultats à obtenir. Il est très rare d’être obligé d’inventer de toutes pièces une solution présentant des caractéristiques communes avec un client du passé.

Les aspects humains de l'AMOA

Sur le plan humain, l’AMOA se doit de regrouper certaines qualités que l’on peut présenter et illustrer sous forme de ce que j’appelle volontairement la « marguerite des valeurs et forces d’un AMOA ».

Cette figure représente ce que l'AMOA devrait porter comme valeurs et forces pour exercer correctement son métier.

Cette carte des "valeurs" est une vision strictement personnelle.

"Marguerite" des valeurs et des forces d'un AMOA. 

Prenons le temps de détailler les « pétales » de cette marguerite. Il n’existe aucun ordre de lecture de cette « marguerite ». Nous prendrons donc les valeurs une par une.

• L’humilité : l’AMOA doit apprendre du client. Il aura certes des connaissances et des savoir-faire qui proviennent d’expériences antérieures, il n’empêche que son Client est celui qui détient la Connaissance et le Savoir-faire sur le projet. Des éléments qui appartiennent à ses activités quotidiennes et à celles regroupées pour réaliser le projet. L’AMOA se doit d’être humble face aux nouvelles connaissances et savoir-faire qui seront présentés par son Client. S’il s’avère que des dysfonctionnements se présentent dans les modes opératoires, l’AMOA devra en faire part à titre de conseil et de suggestions mais en aucun cas, il devra vouloir imposer ses points de vue ou ses connaissances.
• Conseiller : un AMOA intervient dans un contexte particulier et pour un projet spécifique. Au-delà des simples actions qu’il a pour tâches, il a un devoir de conseil. Surtout s’il constate que son Client effectue des actions qui risquent de perturber le bon déroulement du projet ou s’il enfreint certaines règles liées à l’État de l’Art. Ces conseils doivent être proposés et il est prudent de les communiquer par écrit s’ils sont fondés. De même, ce qui tient des stratégies à mettre en œuvre pendant le projet ou après, doit être communiqué sous forme de conseils.
• Opérationnel : un AMOA intervenant chez un client doit être opérationnel très rapidement sur les phases où le client peut montrer ses limites. Il doit prouver ses capacités à s’intégrer rapidement à l’équipe et montrer sa valeur ajoutée dans le projet. Pour cela, il ne devra pas hésiter à prendre à sa charge certaines responsabilités ou la restitution de livrables afin de soulager au plus tôt le client, de ces actions qui pourraient l’alourdir.
• Écouter : une des caractéristiques maîtresses de l’activité et de la qualité d’un AMOA est sa capacité d’écoute. En effet, tout nouveau projet est source de nouvelles connaissances et savoir-faire à acquérir. Le devoir d’écoute et de respect du temps de parole des différents intervenants est primordial pour bien comprendre et apprendre. Même, s’il est amené à conseiller, l’AMOA devra le faire avec intelligence en laissant à son client les temps de paroles nécessaires à ses besoins d’expression. Et cette écoute se fera aussi envers les autres acteurs impliqués dans le projet. Il est impossible de comprendre correctement si on parle en même temps que son interlocuteur.
• Créatif et astucieux : il est rare qu’un projet fournisse l’ensemble des outils nécessaires à son bon suivi ou à la réalisation de certaines tâches spécifiques (tableaux de bord de suivi d’actions, etc.). Pour cela, l’AMOA doit avoir la capacité de fabriquer de manière autonome ses propres outils et de les faire évoluer afin qu’ils répondent aux attentes du projet et du client. Voire, accessoirement, des autres acteurs du projet.
• Communiquer : une autre caractéristique importante de l’AMOA est la communication avec son client et l’ensemble des acteurs impliqués dans le projet, sur ses activités, ses avancements, voire ses difficultés. Cette communication est importante à la bonne réalisation du projet. Elle permet d’avoir régulièrement, une visibilité sur l’avancement des réalisations ou des points de blocages. De plus, en communiquant tôt, il est plus facile de prévoir et trouver les solutions des problèmes.
• Autonomie : très rapidement, l’AMOA doit être autonome sur les parties dont il a la responsabilité. Il doit être facilement et rapidement en capacité de trouver la ou les informations qui lui permettront de travailler et de fournir ses livrables. Pour cela, il devra s’inscrire dans l’organisation du client, quitte à adopter – peut-être, selon les cas et les capacités – des méthodes qui lui permettront de contourner des blocages qui pourraient ralentir la fourniture des données. Mais avec une bonne communication et conseiller correctement, il est rare de ne pas obtenir les informations utiles et nécessaires.
• Déontologie : il est inconcevable qu’en sa qualité de conseil et de support, un AMOA ne respecte pas les Règles de l’Art et l’État de l’Art dans la réalisation de ses activités. Il est prépondérant que l’AMOA ait une forte capacité à respecter la déontologie liée à son métier, celui de son client et aux bonnes pratiques en termes de relations humaines et de réalisation de projet. Car dans le cas inverse, non seulement il s’exposerait à de graves sanctions mais aussi et surtout, il exposerait son client à d’importants dommages. Il ne faut pas oublier qu’un AMOA intervient pour son client mais aussi, il agit en son nom et il « devient le client » (il endosse son nom et ses besoins), en défendant ses intérêts pour la bonne réalisation du projet.
• Curiosité : il est important, pour être AMOA, d’être curieux de nouveaux savoir-faire, de nouvelles techniques, d’évolutions de métiers ou de modes opératoires. Aussi, comme on l’a vu plus tôt avec l’humilité, l’AMOA ne doit pas hésiter à poser les questions qui lui permettront de mieux connaître son client et ses activités professionnelles, mais aussi son organisation et son ou ses modes de fonctionnement. L’AMOA pourra ainsi compléter son « catalogue » personnel de connaissances qui pourront lui servir plus tard de « bagage » utile aux retours d’expériences et de conseils. Cependant, l’AMOA doit pouvoir les mettre en concurrence, en compétition afin de les analyser et les évaluer pour être bien certain que les Règles de l’Art sont respectées. Et dans le cas contraire, intervenir pour conseiller et suggérer des corrections à apporter pour que le client s’inscrive à nouveau dans les règles de déontologie.
• Méthode et organisation : pour effectuer ses activités, l’AMOA doit savoir être organisé et méthodique afin de s’inscrire dans les modèles de fonctionnement du projet, de son client mais aussi dans le planning de livraison de ses documents. Au besoin et si le client ne l’a pas imposé sur le projet dans son mode opératoire, l’AMOA pourra utiliser les modèles ISO de documents pour les siens. De même, il devra maîtriser l’ordonnancement des études et des réalisations propres à un projet informatique (par exemple, avant de choisir une solution ou un outil, on recueille et on consigne les besoins fonctionnels et techniques dans un cahier des charges).

Enfin, par expérience, il est essentiel d’aimer l’humain pour ne pas être foncièrement en contradiction avec le métier d’Assistant à Maîtrise d’ouvrage.