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.