Des guides concrets pour transformer un site en outil vraiment utile.

La transformation numérique des organisations et des processus métier est une dynamique structurelle qui concerne à divers degrés tous les secteurs professionnels publics et privés. Dans ce contexte, les métiers de l’Assistance à Maîtrise d’Ouvrage informatique (AMOA) constituent un maillon indispensable de la mise en œuvre des projets de transformation numérique, à côté des métiers plus techniques (développeurs, architectes, experts DevOps ou sécurité, etc.). En tant qu’interface entre les décideurs et les utilisateurs métier d’une part et les équipes techniques d’autre part, l’AMOA est un traducteur, un facilitateur qui doit posséder des compétences variées en analyse métier et fonctionnelle, en test logiciel, en coordination et gestion de projet. Il doit être capable de travailler aussi bien dans des projets dits « conventionnels » que dans des projets dits « agiles » ou « hybrides », et savoir s’adapter aux spécificités de ces différents contextes.

La certification de Consultant(e) en Assistance à Maîtrise d’Ouvrage informatique vise à l’acquisition de ces compétences variées, tant en termes de savoirs, de savoir-faire que de savoir-être. Elle permet d’accéder à des postes de consultant AMOA, de Product Owner, de Business Analyst, de PMO, de chef de projet.

Bloc 1 : Etude des besoins métier et études fonctionnelles

Le consultant AMOA a pour mission d’accompagner la maîtrise d’ouvrage, ou de prendre en charge pour le compte de cette dernière les phases amont du projet (étude d'opportunité et de faisabilité du projet en contexte cycle en V ou définition de la stratégie métier et de la vision du Produit en contexte Agile), du diagnostic de l’existant jusqu’à la préconisation de solutions informatiques. Dans un deuxième temps, les études fonctionnelles permettent de décrire en détail ce qui doit être réalisé par le système d’information, en termes de données, de traitements et de processus, afin de fournir à la maîtrise d’œuvre les informations nécessaires à la réalisation du projet.

L’analyse métier permet de faire un état des lieux de l’existant, sur trois axes : organisationnel, processus métier et système d’information. En modélisant les processus métier et en identifiant les différentes hypothèses de réalisation, l’AMOA va cibler le périmètre fonctionnel du projet et un scenario de changement à mener.

Une fois la cible identifiée, la définition des besoins métier vise à recueillir les besoins métier auprès des parties prenantes du projet, et de les formaliser sous forme d’exigences à l’aide d’une méthodologie adaptée et normalisée (Cas d’utilisation, User Stories). Des outils informatiques dédiés (ex. Jira) sont généralement préconisés et mis en place en fonction du contexte et de l’outillage existant.

Les informations issues de l’analyse métier et de la définition des besoins métier sont consignées dans un cahier des charges validé par la Maîtrise d’Ouvrage. Dans le cadre d’un appel d’offre, le cahier des charges est transmis aux soumissionnaires candidats, et leurs réponses sont évaluées afin de choisir le prestataire qui sera retenu pour la réalisation du projet. Ainsi, l’étude et le choix d’une solution informatique consistent à étudier et comparer plusieurs solutions informatiques pouvant répondre aux besoins métier (progiciel, développement spécifique, évolution d’outils existants), en proposant au commanditaire des préconisations sur les choix les plus pertinents.

Les études fonctionnelles consistent ensuite à modéliser une architecture fonctionnelle et à décrire les fonctionnalités attendues. Les systèmes d’informations sont conçus et structurés de manière modulaire, sous forme de composants qui interagissent entre eux. Etablir l’architecture fonctionnelle d’une solution informatique consiste à identifier les flux de données qui circulent entre les composants de la solution d’une part, et les flux d’informations échangés avec les applications existantes du SI d’autre part. L’architecture fonctionnelle est modélisée à l’aide de diagrammes d’architecture issus de langages de modélisation comme UML.

L’analyse fonctionnelle vise à fournir une description fine et détaillée de la solution informatique cible, du point de vue fonctionnel. A partir des besoins métiers établis dans le cahier des charges, le consultant AMOA décrit les fonctionnalités attendues, leurs règles de gestion, la structure des données gérées et les interfaces homme-machine. En particulier, au regard de l’interconnexion croissante entre les applications informatiques, l’AMOA spécifie ce qu’on appelle des Services Web ou des API (Application Programming Interface).

Enfin, les enjeux de conformité et d’éco-conception des solutions informatiques sont de plus prégnants dans l’activité d’études métier et fonctionnelles. Il s’agit d’abord de tenir compte des contraintes légales ou réglementaires qui doivent être implémentées dans les applications informatiques, en formalisant des spécifications adaptées. De la même manière, les exigences de sécurité applicative doivent être intégrées dans les études et les spécifications. C’est également le cas des exigences d’accessibilité des services numériques. En effet, depuis la Loi française de 2005, celles-ci se sont fortement renforcées dans le secteur public et les grandes entreprises : obligation d’une déclaration d’accessibilité (2019), pénalités en cas de non-conformité (2024). Enfin, la mise en œuvre de démarches éco-responsables dans la conception des applications informatiques constitue un enjeu fort dont la prise en compte est de plus en plus requise. L’AMOA joue un rôle important dans ce cadre, en particulier par la promotion de la « sobriété fonctionnelle » (limiter le nombre de fonctionnalités des applications à ce qui est nécessaire ou important) et l’acculturation aux solutions moins consommatrices en énergie.

Bloc 2. Test des solutions informatiques

La part grandissante de l’informatique et son importance stratégique dans les activités des entreprises ont rendu nécessaire un haut niveau de qualité et de fiabilité. Pour atteindre ces objectifs, les activités de tests des solutions informatiques obéissent désormais à des normes et des méthodologie extrêmement formelles, et donnent lieu à des campagnes de tests, composantes cruciales des projets informatiques, pilotées par l’AMOA.

Une campagne de tests se déroule en trois étapes :

* La préparation de la phase tests, qui consiste à définir une stratégie de tests (périmètre, types et niveaux de tests, acteurs concernés…), à partir de laquelle un plan de tests sera élaboré (tests fonctionnels pour vérifier la conformité des fonctionnalités, tests métier pour valider la couverture des process métiers). Ces plans de tests sont détaillés en scénarios de tests qui définissent les cas de tests et les jeux de données à tester.

* L’exécution des tests consiste à exécuter les scénarios de tests et les tests métiers, en remontant et en qualifiant au fur et à mesure les anomalies constatées. Selon le contexte, l’exécution des tests peut être réalisée après la phase de réalisation (« cycle en V »), ou en continu au fil des itérations (méthodes Agiles). L’analyse des résultats de l’exécution est une tâche cruciale et essentielle pour une exécution efficace des tests.

* La clôture de la phase de tests consiste à établir un bilan des tests réalisés afin de valider ou non la mise en service de la solution, et de faire des préconisations en vue d’améliorer la qualité des livrables à venir. Lorsque la solution est mise en service, des tests post-mise en service permettent de valider le bon fonctionnement de la solution dans son environnement de production.

En support à ces trois activités, l’industrialisation de la gestion des tests est une activité transverse indispensable pour pérenniser et fiabiliser le contrôle qualité des applications informatiques. Cette industrialisation consister à choisir et implémenter des outils de gestion du patrimoine de tests et des anomalies, au lieu de s’appuyer uniquement sur des outils bureautiques comme Excel. L’AMOA doit maîtriser ces outils dédiés, qui lui fournissent notamment des tableaux de bords pour mieux piloter les tests. Elle peut également participer à la démarche d’industrialisation en question.

Bloc 3. Coordination et gestion de projet

Le rôle central du consultant AMOA dans un projet rend nécessaire une bonne maîtrise des activités de coordination et de gestion de projet, afin qu’il puisse assurer le pilotage du projet tout au long du cycle de vie du projet.

Au début du cycle de vie, le cadrage du projet vise à définir les grandes lignes du projet en termes d’objectifs et d’enjeux, sur les axes métier, organisationnels et stratégiques. Afin d’améliorer la visibilité et le pilotage du projet, les risques doivent être identifiés et classifiés le plus tôt possible. A chaque risque correspondent des actions à mener pour s’en prémunir et/ou en minimiser l’impact le cas échéant. En fonction de ces informations, l’AMOA doit définir un mode d’organisation (Cycle en V, Agilité…) et un planning prévisionnel, ainsi que les livrables de référence qui devront être produits tout au long du projet et leur circuit de validation.

La gestion opérationnelle du projet englobe les tâches récurrentes de coordination des acteurs du projet, de suivi et d’ajustement du budget et de gestion des risques et des imprévus. Afin de rendre compte de l’avancement du projet auprès des décideurs du projet, l’AMOA organise des comités de pilotage à intervalles réguliers et maintien des tableaux de bord.

Le management d’équipe occupe une place centrale et transverse dans les activités de l’AMOA, pour coordonner la répartition des tâches entre les différents acteurs, assurer la communication, garantir une vision commune, et gérer les conflits entre les membres de l’équipe au plus tôt lorsqu’ils surviennent, afin d’assurer les conditions les plus fluides possibles pour faire avancer le projet.

Au-delà de la qualité intrinsèque de la solution informatique, un facteur crucial de la réussite du projet repose sur la conduite du changement. C’est une étape critique qui vise à accompagner les changements d’organisation et de processus de travail induits par la mise en œuvre de la solution informatique, et accomplir les démarches nécessaires à une adoption de ces changements par les utilisateurs, tant sur le plan technique que psychologique. Ainsi, le pilotage de la conduite du changement consiste d’abord à identifier et catégoriser les acteurs impactés par le projet, à mesurer le niveau d’impact pour chaque catégorie d’utilisateurs, ainsi que les risques de résistance au changement. Il s’agit ensuite d’élaborer un plan d’actions visant à accompagner le changement, en organisant des actions de formation, de communication et de documentation. Enfin, il est nécessaire d’établir une stratégie de déploiement en fonction des contraintes métier, techniques et stratégiques du projet.

Bloc 4. Travailler en contexte Agile

Apparue au début des années 2000 avec le manifeste agile ( ) l’approche agile s’est progressivement imposée comme une méthodologie de référence pour la réalisation de projets informatiques. Depuis le milieu des années 2010, l’adoption des méthodes agiles (notamment Scrum et Kanban) s’est nettement accélérée, un grand nombre d’entreprises ayant choisi de l’utiliser pour tout ou partie de leurs projets.

Les approches traditionnelles (cycle en cascade ou cycle en V) s’articulent autour d’une approche linéaire du cycle de vie d’un projet : chaque étape (analyse, conception, développement…) doit être intégralement terminée avent de pouvoir commencer l’étape suivante. Il en résulte un manque de souplesse pour ajuster le produit en cours de route, et un coût de modifications élevé, ainsi qu’un effet tunnel du fait d’un manque de visibilité entre l’expression du besoin et la livraison du produit fini, qui peut conduire à des écarts conséquents entre le besoin initial et la solution proposée.

L’approche agile tend à répondre à ces problématiques en s’appuyant sur une démarche itérative et incrémentale : le projet est découpé en une succession de sprints (périodes courtes, de 2 à 4 semaines) durant lesquels l’équipe de développement va réaliser un incrément livrable (utilisable en conditions réelles) du produit final, en itérant les différentes phases du cycle de vie (analyse, conception, réalisation…) uniquement sur les fonctionnalités du sprint en cours.

Ainsi, le commanditaire va pouvoir suivre à intervalles rapprochés et réguliers la réalisation du produit, et éventuellement pouvoir commencer à l’utiliser très rapidement. Par ailleurs, l’analyse et la conception ayant lieu au fur et à mesure, il devient possible à très faible coût de revenir sur des fonctionnalités qui n’ont pas encore été réalisées, puisque pas encore précisément spécifiées. Cette approche permet donc de gagner en agilité en étant capable de s’adapter aux évolutions des besoins tout au long du cycle de vie du projet, et d’avoir rapidement une première version exploitable de la solution.

La gestion de projet agile introduit une nouvelle répartition des responsabilités autour de trois rôles clé :

* Le Product Owner, qui est garant de la vision du produit, et qui possède une bonne connaissance du métier, lui permettant de définir les fonctionnalités attendues (user stories) et de les ordonner dans un product backlog en priorisant celles qui apportent le plus de valeur ajoutée au client, afin d’obtenir rapidement un produit utilisable et efficient.

* Le Scrum Master, qui accompagne l’équipe en veillant au respect des principes agiles, en agissant comme un facilitateur et en éliminant toutes les interférences qui pourraient entraver le bon déroulement de la réalisation.

* L’équipe de réalisation, pluridisciplinaire et auto organisée, qui définit et chiffre les tâches à accomplir pour réaliser les user stories et maîtrise toutes les compétences techniques nécessaires. L’équipe est généralement constituée de développeurs-concepteurs, business analyst, testeurs, et tous autres spécialistes requis pour mener à bien la réalisation.

Les métiers de l’AMOA sont directement concernés par cette évolution méthodologique. En effet les métiers de chef de projet et de consultant AMOA connaissent actuellement un glissement vers des rôles de Product owner et potentiellement de Scrum master.

Si les fondamentaux restent les mêmes que pour les méthodes classiques (analyse fonctionnelle, conduite du changement, gestion de projet, pilotage des tests), la nouvelle organisation induite par l’agilité nécessite une connaissance approfondie des principes agiles et de leur mise en œuvre, cette bonne maîtrise de la méthodologie étant la clé d’une transition agile réussie.

La première activité du Product Owner concerne la conception de l’expérience utilisateur, à savoir sa structuration en distinguant les différents types d’utilisateurs (appelés persona) et leurs attentes traduites sous la forme de parcours utilisateurs. Plus largement, le Product Owner orchestre, avec les parties prenantes, la définition de la vision et des objectifs du futur produit informatique à travers des technicités telles que le Product Vision Board et le Lean Canva.

Sa deuxième activité, qui fait suite à la première, consiste dans la gestion du Produit et du flux de valeur tout au long du projet informatique. Il s’agit de maximiser la valeur du produit pour les utilisateurs, en priorisant les fonctionnalités à développer ou faire évoluer au cours des sprints successifs. Pour ce faire, le Product Owner gère le product backlog en fonction de l’évolution des besoins des utilisateurs. Il porte la vision produit lors des cérémonies agiles, et dans ses interactions quotidiennes avec les membres de l’équipe. Il définit le plan de livraison des incréments, en fixant des jalons de mise à disposition réaliste des versions aux utilisateurs. Il utilise un outillage dédié pour faciliter la collaboration avec les parties prenantes, et assurer la transparence sur l’état des développements réalisés, en cours et à venir. Il contribue à la mise en œuvre et la bonne application d’une approche DevOps. Enfin, il évalue l’atteinte effective de la valeur attendue en collectant et en analysant les retours des utilisateurs.

Au-delà de ces activités opérationnelles, le Product Owner comprend et applique les principes de l’agilité. Il connaît les principaux cadres de travail Agile, notamment Scrum, ainsi que les approches de l’agilité à l’échelle, qui s’applique à des projets de grande envergure, voire à l’ensemble des projets informatiques d’une DSI. Par exemple, la méthode SAFe (Scaled Agile Framework) est la méthode actuellement la plus populaire pour l’agilité à l’échelle. Elle définit de nouveaux rôles (Product Manager, Business Manager, Epic Owner) qui sont comparables au rôle de Product owner à plus large échelle.

Réaliser un diagnostic de la situation existante en décrivant et en évaluant les forces et faiblesses de l'organisation, des processus et du système d'information existants afin de fournir un état des lieux précis de l’existant.

Modéliser des processus métiers en définissant des cas d’utilisation afin de cadrer le périmètre global du projet.

Détailler la cible métier en termes d’organisation, de processus et de système d’information en se basant sur une étude comparative de différents scénarios de changement afin de répondre au mieux aux besoins des utilisateurs.

Recueillir et formaliser les besoins métier en utilisant diverses techniques de collecte, élicitation et formalisation de l’information afin de s’assurer que ces besoins sont décrits de manière précise et exhaustive.

Développer une connaissance du marché de l'informatique en identifiant ses acteurs, les catégories de produits et les modèles de commercialisation, afin d'élaborer des stratégies et des préconisations pertinentes pour répondre aux besoins des clients.

Etudier des solutions informatiques en élaborant une grille de choix pour comparer plusieurs solutions afin de préconiser le choix de la solution la mieux adaptée aux besoins et aux contraintes du commanditaire.

Modéliser une architecture fonctionnelle en formalisant les composants du système d’information et leurs interactions pour identifier les flux de données.

Modéliser et décrire les données du système en précisant leur organisation, leurs relations, leur référence, leur mode de transmission, leurs attributs, leur nature, leur format et autres caractéristiques pour spécifier la structure de la base de données et les traitements attendus.

Interroger une base de données en utilisant le langage SQL pour consulter ou modifier des données.

Visualiser et analyser des données en utilisant un outil de Business Intelligence pour guider la prise de décision en termes d'amélioration de process et de produits.

Décrire les interactions à mettre en place entre applications en précisant les données concernées, les modes de communication et les traitements souhaités afin de spécifier des services Web ou des API.

Interroger une API et analyser les réponses en utilisant un outil informatique dédiée et le langage JSON afin de vérifier l'adéquation aux attendus des services exposés et sollicités.

Réaliser ou valider les spécifications fonctionnelles d’une solution informatique en décrivant en détail les fonctionnalités et caractéristiques non-fonctionnelles attendues, ainsi les règles de gestion à appliquer, afin de communiquer aux développeurs et aux testeurs les informations nécessaires à la réalisation et à la vérification du produit.

Intégrer les contraintes de conformité légales ou réglementaires dans la conception des solutions et systèmes informatiques en les formalisant sous formes d'exigences et de spécifications afin de prévenir les risques encourus en cas de non-respect.

Intégrer les contraintes de sécurité du système et de ses données dans la conception de solutions informatiques en les formalisant sous formes d'exigences et de spécifications afin d'éliminer les risques de vol ou d'altération des données mais aussi de dégradation des applications et services.

Intégrer aux caractéristiques d'une solution le respect des normes d'accessibilité numérique en décrivant les critères à respecter afin de créer une expérience utilisateur adaptée à tous.

Intégrer à la conception logicielle une démarche éco-responsable en appliquant les recommandations du cadre référentiel de la responsabilité numérique et de l'éco-conception des services numériques afin de minimiser l'impact environnemental de la production et de l'utilisation de ces services.

Définir la stratégie de test d’une solution informatique en précisant les modalités des procédures de tests afin de garantir le respect de normes de qualité homogènes.

Concevoir le plan de tests fonctionnel d'une solution informatique en élaborant des scénarios de tests basés sur des cas de tests et des jeux de données afin de couvrir l'ensemble des fonctionnalités et des interfaces à tester.

Concevoir le plan de tests métier pour couvrir les process métier en se basant sur les applications impactées d’après l’étude de l’architecture du SI.

Constituer un patrimoine de tests de non-régression (TNR) en définissant les fonctionnalités existantes susceptibles d’être impactées par des évolutions du produit afin de pouvoir détecter d’éventuelles régressions.

Exécuter des scénarios de test en analysant les résultats des tests pour vérifier la conformité des fonctionnalités et des interfaces.

Organiser les tests métier en accompagnant les utilisateurs dans le déroulement de ces tests afin de vérifier l'adéquation d'une solution informatique aux processus métier.

Suivre la résolution des anomalies en assurant la remontée et la qualification des anomalies constatées lorsqu'un cas de test est en échec afin d’en effectuer la correction.

Faire un bilan des tests réalisés en détaillant les résultats obtenus pour fournir au commanditaire des éléments de décision en vue de la mise en service d'une solution informatique.

Faire ou coordonner la réalisation des tests post-mise en service de la solution informatique en utilisant des jeux de tests spécifiques pour s'assurer de son bon fonctionnement en conditions opérationnelles.

Organiser les conditions de test, les cas de test et jeux de données, les exécutions des tests et le traitement des anomalies en utilisant des outils informatiques dédiés pour industrialiser la gestion des tests.

Définir les objectifs et les enjeux du projet au niveau de l'organisation, des processus de travail et du système d'information, en définissant des indicateurs de mesure pertinents afin d’assure une visibilité optimale pour le pilotage du projet.

Définir la valeur ajoutée et la rentabilité du projet en tenant compte des éléments financiers et non financiers afin de calculer le retour sur investissement.

Définir une organisation projet en choisissant une méthode adaptée et ses modalités de mise en œuvre afin de cadrer les processus de conduite du projet.

Définir et les risques associés à un projet en les priorisant en fonction de leur gravité et de leur probabilité en et définissant les actions à mener afin d’éviter ou contrôler la survenue de ces risques.

Définir le planning d'un projet en tenant compte des différents chantiers, acteurs et du chemin critique du projet afin d’établir des jalons et des dates prévisionnelles de mise en œuvre.

Définir la gestion documentaire à mettre en œuvre dans le projet en définissant les modèles de livrables, circuits de validation et modalités de rédaction et de mise à disposition afin de structurer le partage de l’information.

Préparer les comités de pilotage ou de direction pour fournir aux instances de gouvernance de la visibilité sur l'avancement du projet, en spécifiant le déroulement et les informations à présenter.

Suivre le budget d'un projet en mettant en place des outils de suivi budgétaire afin de détecter les éventuels dépassements et préconiser les ajustements requis le cas échéant.

Coordonner les activités du projet en fonction de la méthode adoptée en organisant la répartition des tâches en fonction des compétences et des rôles des acteurs du projet afin d’assurer la coordination des actions menées.

Evaluer la pertinence de l'utilisation d'une solution basée sur l'Intelligence artificielle générative pour l'exécution d'une tâche donnée en analysant les risques induits, les bénéfices et la qualité des résultats obtenus, afin d’optimiser l'efficacité de la production des livrables.

Gérer les conflits au sein de l'équipe projet en écoutant et en observant les interactions entre ses membres afin d’assurer une bonne cohésion.

Assurer une bonne communication ascendante et descendante au sein de l'équipe projet en encourageant les interactions afin de garantir une bonne circulation de l’information.

Identifier les parties prenantes en catégorisant les utilisateurs et acteurs impactés par un changement du Système d’Information afin d’identifier les attentes et les résistances vis-à-vis dudit changement.

Réaliser une étude d’impact en identifiant, pour chaque groupe d’utilisateurs, les fonctionnalités qui les concernent et l’impact du changement sur leurs activités, afin d'établir le plan d'action de l'accompagnement du changement.

Accompagner le changement en planifiant des actions de communication et de formation, en définissant la documentation afin de faciliter l’acceptation du changement et de répondre au mieux aux besoins d’accompagnement des parties prenantes.

Définir le support utilisateur à mettre en place une fois le projet mis en production en définissant les modalités de support afin de pérenniser l’accompagnement des utilisateurs sur le long terme.

Etablir une stratégie de déploiement de la solution informatique en proposant des modalités conformes aux enjeux métier et aux contraintes techniques afin de minimiser l’impact du déploiement sur les activités métier pendant la phase de transition.

Structurer l'expérience utilisateur en identifiant les caractéristiques distinctives des différents types d'utilisateurs, les activités que la solution informatique doit leur permettre de réaliser et leurs parcours dans leur interaction avec l'interface, afin d'optimiser la satisfaction de leurs besoins.

Définir la vision et les objectifs du produit informatique en réalisant des ateliers de travail collaboratifs avec les parties prenantes, afin de guider la planification des itérations et des livraisons.

Organiser la formalisation et le test de concepts/prototypes en animant des sessions de travail collaboratives afin de valider ou invalider des hypothèses avant d'engager le développement d'un nouveau produit.

Structurer et organiser la documentation produit et les spécifications en utilisant un outil informatique dédiés pour industrialiser la gestion des besoins métier et des développements à réaliser.

Porter la vision produit lors des réunions de planification de sprint en exposant clairement les objectifs produit et les besoins des parties prenante afin de livrer au plus tôt un maximum de valeur aux utilisateurs.

Gérer le product backlog en ajoutant, modifiant, supprimant, détaillant, repriorisant les items qui le composent, au gré des évolutions des besoins des utilisateurs, afin d'optimiser la valeur du produit et de préparer les itérations suivantes.

Travailler avec les parties prenantes lors des revues de sprint en analysant avec eux leurs retours pour répercuter dans le Product Backlog les changements à opérer.

Identifier des jalons réalistes de mise à disposition des versions successives du produit sous forme de plan de release en définissant les livrables (MVP, MMP) et les itérations nécessaires pour les réaliser, afin de fournir une visibilité à moyen terme pour l'équipe et les parties prenantes.

Maximiser la valeur délivrée en contribuant à la mise en œuvre d'une approche DevOps afin d'optimiser la qualité du produit et le flux de livraisons.

Evaluer le succès du produit au moyen d'indicateurs définis pour mesurer l'atteinte des objectifs et via l'analyse des retours des utilisateurs, afin d'identifier les ajustements à opérer pour optimiser la valeur délivrée.

Comprendre les valeurs et principes du Manifeste agile, en les analysant, pour les mettre en œuvre au sein d'un équipe agile.

Connaître les cadres de travail agile appliqués en entreprise en analysant leurs composantes afin de participer à leur mise en œuvre opérationnelle.

Comprendre son rôle au sein d'une organisation agile, en comprenant les responsabilités et périmètres d'action définis dans les principaux cadres de travail de l'agilité à l'échelle, pour interagir efficacement avec les collaborateurs et équipes de l'organisation.

Disposer d'un diplôme ou d'un titre RNCP de niveau 6.

Il n'y a pas de prérequis en termes d'expérience ou de connaissance informatique, mais il est conseillé d'avoir une appétence forte pour le numérique.

Le métier de l’Assistance à Maîtrise d’Ouvrage informatique (AMOA), au sein du secteur du numérique, peut s’exercer dans trois typologies d’entreprises ou services employeurs :

* Des cabinets de conseil et des entreprises de services du numérique (ESN) dont la taille est extrêmement variable selon qu’il s’agisse de sociétés généralistes proposant des services variés à des clients appartenant à tous types de secteurs d’activités, ou bien d’entreprises spécialisées en AMOA ou en transformation Agile intervenant dans un ou plusieurs domaines métier privilégiés ;

* Des éditeurs de logiciel dans tous types de secteurs d’activité ;

* Des services d’Assistance à Maîtrise d’ouvrage ou de Maîtrise d’Ouvrage déléguée d’entreprises du secteur privé (industrie ou tertiaire) ou public.

Dans ce dernier cas, le service Assistance à Maitrise d’Ouvrage dépend de la direction métier (i.e. : direction financière, direction marketing, direction commerciale, direction des ressources humaines, direction de la production, …) concernée pour les grands groupes, tandis qu’il dépend de la direction Organisation ou de la direction des Systèmes d’Information pour les entreprises de taille plus modeste.

Plusieurs facteurs peuvent influer sur le contenu du métier de l’AMOA dans un grand groupe :

* Le choix d’organisation en termes de répartition interne des responsabilités avec la maîtrise d’œuvre notamment concernant la modélisation des données, les spécifications détaillées, les tests et la responsabilité d’urbanisme.

* Le fait que les développements informatiques soient réalisés par la maîtrise d’œuvre interne ou sous-traités. La maitrise d’œuvre interne joue alors le rôle d’intégrateur et l’assistance à maitrise d’ouvrage pilote fonctionnellement le sous-traitant.

* La nature des projets traités. Des projets d’intégration de progiciels du marché impliquent par exemple beaucoup de paramétrages, des liens avec l’éditeur et une conduite du changement importante ; le rôle de l’assistance à maitrise d’ouvrage est alors renforcé.

* En fonction de la méthodologie retenue, « cycle en V » ou Agile, les postes et les tâches associées varient sensiblement (chef de projet en « cycle en V », Product Owner en Agile). La difficulté majeure de la transition du rôle de Chef de projet vers celui de Product Owner est alors de respecter une nouvelle répartition des responsabilités, et de ne pas empiéter sur celles des autres acteurs (affectation des tâches par exemple).

* Pour des projets de grande envergure, la mise en œuvre de l’agilité à l’échelle, qui introduit de nouveaux rôles (Product manager, Business owner, Epic owner, etc.), des process et une coordination des équipes plus complexe, et nécessite une formation des acteurs pour une mise en œuvre efficace.

Consultant, avec une grande variété d’intitulés complémentaires (consultant AMOA, SI, solution, fonctionnel, etc.) ;

Analyste métier ou Business Analyst ;

Architecte fonctionnel ;

Testeur fonctionnel, testeur QA (pour Quality Assurance) ;

Consultant en conduite du changement ;

Project Management Officer (PMO) ;

Chef de Projet ;

Pilote de projet.

Product Owner (PO) ;

Proxy Product Owner (PPO) ;

Scrum Master (moins fréquent).

Non applicable.