1. Comprendre et amorcer une démarche d’Architecture d’Entreprise

Figure 1: Questions à se poser en ce qui concerne l’architecture d’entreprise

1.1. Qu’est-ce que l’architecture d’entreprise?

Il existe plusieurs définitions de l’architecture d’entreprise, dont la suivante, qui est issue de l’AEGT.

L’AE constitue un outil d’aide à la prise de décision stratégique. Elle s’inscrit dans une démarche de gouvernance pour une utilisation efficace et efficiente de l’information et des ressources informationnelles à l’échelle organisationnelle et gouvernementale.L’architecture d’entreprise donne une vision d’ensemble qui permet à l’organisme public de tirer profit des ressources informationnelles en tant que levier de transformation organisationnelle. Elle est constituée d’un ensemble de cadres de référence destinés aux gestionnaires, aux analystes métiers et aux développeurs, qui leur permet notamment :

• D’élaborer les principes d’encadrement des projets, les modèles sur lesquels construire les systèmes d’information, les normes, les règles et les standards;

• De positionner les projets dans une perspective d’ensemble;

• D’anticiper les occasions de mise en commun et de réutilisation;

• De s’assurer que l’ensemble de leurs systèmes d’information sont interopérables, tout en maintenant les niveaux de sécurité appropriés.

Indice

Architecturer… c’est élaborer, construire une œuvre, en organisant avec rigueur ses différentes parties

1.2. Quels sont les objectifs de l’architecture d’entreprise ?

L’architecture d’entreprise est principalement un outil d’aide à la décision au service de la maîtrise du SI et de satransformation, pour la maîtrise d’ouvrage et les DSI. Les objectifs visés par cette démarche sont les suivants :

Objectif 1

Faciliter le dialogue entre les acteurs métier et les acteurs des TIC, il s’agit d’une intermédiation durable

• fournir et maintenir un langage et une vision commune (processus métier, POS…)

• positionner les demandes d’évolutions (initiatives, projets, MCO, etc.) dans un environnement existant métier en évolution

• capitaliser et structurer la connaissance pour une meilleure lisibilité du SI, en intégrant les différents points de vue (stratégique, métier, technique, mais aussi humain, comptable, sécuritaire, etc.)

• faciliter les études et les prises de décision

• faciliter les transformations du SI

Objectif 2

Structurer l’étude des demandes de transformation, par une action volontaire et opportuniste à l’occasion des projets de construction et de mise en place de nouveaux services

• encourager et faciliter les études d’impacts

• assister les métiers dans leurs transformations : analyse d’activité, et des besoins sous-jacents en ressources (informations, ressources humaines, outils informatiques, ressources financières)

• conseiller et ouvrir la recherche de solutions (services) en fonction des effets attendus (résultats de l’usage des services)

Objectif 3

Appuyer l’évolution stratégique du SI

• animer une démarche progressive et continue pour cibler les investissements, définir, entretenir et aligner les services et les systèmes d’information sur les métiers et leurs stratégies

• développer la capacité à intégrer et transformer le SI : application des règles, intégrité des données, standardisation des interfaces et des échanges, et au final, une interopérabilité effective du SI

• faciliter la convergence technologique (ex. cadre d’interopérabilité)

Objectif 4

Animer la gouvernance des données

• considérer les données manipulées par l’Etat comme un actif stratégique, et à ce titre assurer la gestion comme telle : recensement, responsabilité, standardisation, facilité d’accès et de partage, etc.

Objectif 5

Faciliter, simplifier les évolutions du SI, par une aide à l’allocation et l’optimisation de l’emploi des ressources (financières, humaines, données, applications, infrastructures, etc.)

• aider les décisions d’allocation et d’arbitrage sur les ressources.

• accompagner les projets lors de leur conception pour identifier des composants modulaires et indépendants (forte cohésion et faible couplage).

• proposer systématiquement la réutilisation ou la mutualisation de composants en favorisant une logique d’intégration au lieu d’un développement de nouveaux composants.

• rechercher systématiquement la simplification du SI pour les utilisateurs (interne ou externe)

• constituer un catalogue de services, de composants et d’architectures de référence

Objectif 6

Partager et communiquer : la démarche, la connaissance du patrimoine, la cible et les perspectives

• promouvoir et faire utiliser les livrables de l’architecture d’entreprise dans les comités de tous niveaux (des comités stratégiques aux comités de projet en passant par les revues métiers)

• utiliser le référentiel d’architecture d’entreprise pour la production des cadres stratégiques ministériels

1.3. Quels sont les avantages de l’architecture d’entreprise?

Le SI de l’Etat est confronté à des évolutions et des transformations continuelles :

• évolution du cadre législatif national et international (notamment sous-régional et régional),

• mise en place de nouveaux services ou moyens d’accès à ces services pour les usagers, innovation pour accroître l’efficience du service rendu aux citoyens et aux entreprises,

• rationalisation du fonctionnement des organisations (refonte ou optimisation des processus, gouvernance renouvelée) pour des raisons économiques,

• (dé) concentration et/ou (dé) centralisation : mise en place de nouveaux opérateurs, décentralisation de certaines missions nationales, réorganisation territoriale, etc.

• Réorganisation fréquente des organisations,

• obsolescence technique de certains outils informatiques.

Note

L’architecture d’entreprise peut fonctionner comme un GPS pour un organisme public et le guider dans ses choix au fur et à mesure des différentes étapes à traverser, en réduisant l’incertitude et en fournissant les informations nécessaires à la bonne évaluation des différentes possibilités.

Le CIGREF a décrit dans son rapport de 2008[1], les apports d’une démarche d’architecture d’entreprise, en fonctiondes situations rencontrées par les entreprises ou les administrations. La figure ci-après est construit à partir del’analyse du CIGREF et personnalisé sur les situations rencontrées spécifiquement par l’administration.

Figure 2: Apport de la démarche vis-à-vis des enjeux et des situations organisationnelles rencontrées

A l’échelle de l’Etat, les bénéfices attendus par le développement d’une telle démarche d’architecture d’entreprise sont les suivants :

• un meilleur alignement des différents éléments du SI, dont les technologies de l’information et de la communication choisies par l’Etat, sur les métiers de l’Etat, et leurs stratégies de transformation. Le bénéfice d’une telle démarche ne porte pas uniquement sur le métier lui-même, mais bien sur l’ensemble des vues du SI

• des prises de décisions plus pertinentes et efficaces ainsi qu’une meilleure collaboration entre les acteurs SI des différentes autorités administratives (ministères, et opérateurs), grâce notamment à :

  • un vocabulaire et des règles d’architectures d’entreprises communs,

  • une connaissance partagée du patrimoine SI,

  • une plus grande efficacité dans les phases d’étude et de conception.

• une rationalisation du patrimoine SI (applications et infrastructures ministérielles et interministérielles), tout en développant sa capacité à se transformer efficacement :

  • mutualisation de composants logiciels ou d’infrastructures communs ou d’applications transverses,

  • meilleure intégration des briques du SI entre elles, grâce notamment à la standardisation, à l’aide apportée par la démarche aux travaux de convergence technologique, à une connaissance approfondie des référentiels et services partagés.

  • une plus grande agilité du SI de l’Etat face aux nécessaires et permanentes adaptations, et évolutions.

Pour une organisation, voici des exemples d’avantages auxquels elle peut s’attendre :

• Meilleur alignement stratégique et meilleure gestion de la transformation

  • Amène une synergie et assure une meilleure cohérence au sein de l’organisation en alignant les projets avec le schéma directeur et les stratégies opérationnelles;

  • Permet le développement et le partage de connaissances de l’organisation, sous l’angle métier, de l’information et des TI, point de départ essentiel à toute transformation;

  • Mobilise les acteurs de l’organisation autour des mêmes objectifs, car tous y participent et se reconnaissent lors d’une transformation.

• Prestation de services plus efficiente

  • Amène une diminution des coûts dans la prestation de services grâce à une organisation plus agile et plus optimale;

  • Facilite le partage de l’expertise, ce qui influe positivement sur la productivité dans toute l’organisation;

  • Favorise la réutilisation, tant à l’échelle de l’organisation qu’à l’échelle du gouvernement, dans la perspective du « mieux servir », du « mieux travailler » et du « mieux dépenser ». Le fait de demander une seule fois un élément de preuve au client pour le bénéfice de l’ensemble de l’appareil gouvernemental en est un exemple.

• Exploitation plus efficace des TI

  • Diminution des coûts associés au développement ou à l’acquisition, au soutien et à la maintenance en raison de l’influence de l’AE au sein de l’organisation;

  • Amélioration de la portabilité des applications, de l’interopérabilité et de la sécurité grâce à la vue d’ensemble. Par exemple, il est plus facile de mettre à jour ou de remplacer un composant technologique grâce à un meilleur découplage.

• Meilleur rendement du capital investi et réduction des risques lors de futurs investissements ou dépenses

  • Engendre d’importantes économies en raison de la réduction de la complexité autant des opérations que des TIC dans les projets;

  • Permet de réduire globalement les risques liés aux projets en les identifiant, les analysant et les justifiant au moyen d’une architecture cible;

  • Amène une valeur ajoutée aux services rendus à la clientèle, par l’aide apportée dans le choix des meilleurs projets.

• Approvisionnement plus rapide, plus simple et à moindre coût

  • Simplifie les décisions d’acquisition, notamment, par une meilleure connaissance du portrait de ses TIC et de leur gestion;

  • Permet d’accélérer le processus d’approvisionnement et d’accroître la facilité à traiter avec les différents fournisseurs par un positionnement préétabli.

Note

Les stratégies arrimées à l’architecture d’entreprise entraînent d’énormes économies mesurées, non pas en termes de centaines ou de milliers, mais plutôt de millions d’euros.

Selon un rapport de Corporate Executive Research, la compagnie d’assurance John Hancock a réalisé une économie de 6,25 millions de dollars US à la suite de la découverte de redondances par l’architecture d’entreprise. La compagnie Dow, pour sa part, a réalisé 300 millions de dollars US de nouveaux revenus en raison de la mise en œuvre de nouveaux projets reconnus par les travaux d’architecture d’entreprise. Finalement, Key Corporation a réalisé une réduction de 20 % de la maintenance de ses applications, ce qui s’est traduit par une économie de 7 millions de dollars US dès la première année.

1.4. Quand doit-on mettre en œuvre une architecture d’entreprise?

L’architecture d’entreprise peut être mise en œuvre à n’importe quel moment au cours des activités régulières de l’organisation. Le début d’un cycle de planification offre souvent une bonne occasion pour réviser les façons de faire et entamer l’élaboration d’une architecture d’entreprise en vue d’alimenter la réflexion. On peut également considérer l’établissement d’une architecture d’entreprise avant une réforme majeure, puisqu’elle permet à l’organisation de bien se préparer en vue d’entreprendre une telle transformation.La mise en œuvre d’une architecture d’entreprise s’avère en effet l’occasion :

• de dresser le portrait actuel de ses opérations, l’inventaire et l’état de ses actifs informationnels;

• de définir une cible et sa portée puis d’évaluer la capacité des ressources de l’organisation d’y parvenir, influant ainsi sur la planification;

• de structurer les transformations à l’aide de balises et de principes clés.

1.5. Quelles sont les conditions préalables pour réaliser une architecture d’entreprise ?

La réussite d’une démarche d’architecture d’entreprise est avant tout une question de gouvernance. Elle repose en effet sur l’engagement et le soutien des instances dirigeantes qui :

• communiquent, d’une seule voix, leurs engagements en la matière;

• mettent à disposition de leur personnel les moyens nécessaires pour y arriver;

• s’assurent de comprendre et de s’approprier les principes et la vision de l’architecture d’entreprise;

• s’assurent que les avis et les recommandations de l’architecture d’entreprise sont pris en considération à travers le choix et la réalisation des projets de transformation;

• veillent à ce que toutes les parties prenantes de l’organisation s’engagent pleinement et collaborent à cette démarche pour en assurer le succès;

• s’assurent de bien gérer le changement par l’établissement d’un canal de communication permanent afin d’atténuer les risques et de garder le cap vers les cibles établies.

Une volonté claire de la haute direction de l’organisme agit comme un catalyseur essentiel pour instaurer l’AE dans l’organisation.Finalement, avant d’élaborer une architecture d’entreprise, il importe que l’organisation se pose les questions suivantes :

• Les instances dirigeantes comprennent-elles les éléments d’une architecture d’entreprise?

• A-t-on le soutien et l’appui de la haute direction?

• Les parties prenantes se sentent-elles interpellées?

• L’organisation compte-t-elle s’engager dans la transformation de son offre de services, l’optimisation de ses processus internes, la standardisation de l’information et des TIC et la réduction des coûts d’exploitation?

• Est-ce que l’organisation dispose des effectifs nécessaires pour organiser, coordonner et mettre en œuvre une AE?

• Quels seraient les projets porteurs qui bénéficieraient le plus de la mise en place d’une AE?

La réponse à ces questions vise à réunir les conditions gagnantes tout en permettant d’établir la manière dont l’AE pourra être mise en œuvre.

1.6. Facteurs clés de succès

Concernant les démarches d’architecture d’entreprise, le CIGREF, dans son rapport de 2008,identifie un certain nombre de facteurs clés de succès. Jugés pertinent pour ce guided’architecture d’entreprise à l’échelle de l’Etat, ces facteurs sont repris ici :

• L’architecture d’entreprise appartient à l’organisation dans son ensemble, pas à une entité spécifique. Même si globalement la fonction d’architecture d’entreprise est portée aujourd’hui majoritairement par les DSI, car initiée sur les couches de la responsabilité des DSI, il existe des fonctions ou des embryons de fonctions d’architecture d’entreprise SI au sein de directions métiers. Le positionnement de cette fonction et sa diffusion feront probablement l’objet d’ajustement ou d’évolutions en fonction du positionnement des DSI au sein des ministères ou des administrations d’une part, et en fonction de l’évolution de la maturité de la fonction d’architecture d’entreprise elle même d’autre part.

• L’architecture d’entreprise est pluridisciplinaire par nature (connaissance de la stratégie, du métier et de sa législation, des données, des applications, des infrastructures). Les architectes doivent avant tout assurer un rôle de promoteur, de facilitateur, d’animateur, de médiateur. Ils doivent créer les conditions favorables aux travaux d’architecture d’entreprise qui sont le fait de l’ensemble des acteurs impliqués dans le SI (métier, architecte, production, etc…).

• L’architecture d’entreprise doit s’appuyer sur une gouvernance solide, avoir des objectifs connus, mesurables et suivis. La démarche de consolidation du patrimoine SI doit être soutenue au plus haut niveau et la connaissance associée, cœur de la démarche, doit être partagée largement, et l’usage d’outil commun encouragé. Le présent guide contribue directement à ce facteur de succès, en explicitant les objectifs, la gouvernance associée et les indicateurs correspondants.

• L’architecture d’entreprise est une démarche, pas un projet. Elle doit s’inscrire durablement dans le temps. C’est pourquoi elle doit démarrer sur un périmètre limité, puis s’étendre progressivement en fonction de l’évolution de la maturité des acteurs sur le sujet. Son action doit être opportuniste sur toutes les actions de transformation du SI. Tous les effets ne seront pas visibles immédiatement et sans effort, de fait, chacun doit le comprendre, s’y préparer et agir en conséquence. Ce n’est pas contradictoire avec la délivrance de premiers résultats observables très tôt dans la démarche.

• L’architecture d’entreprise nécessite des ressources dédiées, même s’il s’agit principalement de réaffecter des ressources et de faire participer l’ensemble des acteurs MOA et MOE, métiers et techniques.

• L’architecture d’entreprise exige un engagement réciproque des acteurs impliqués, en particulier des acteurs métiers. Ce n’est pas une prestation de service mais une coproduction. L’architecture d’entreprise doit être couplée et coordonnée avec d’autres démarches (gestion de portefeuilles projets, programmation et gestion budgétaire, gestion de programmes et de projets, gestion des changements…). Il faut garder une logique coopérative et équilibrée entre toutes ces démarches, notamment en matière de maturité. Elles s’enrichissent toutes mutuellement pour une meilleure gouvernance globale du SI. Il s’agit donc d’éviter une logique de domination d’une démarche au profit d’une autre.

• Les outils et méthodes pour mettre en œuvre et animer une démarche d’architecture d’entreprise existent, même s’ils n’ont pas tous le même niveau de maturité. Dans bien des cas, telle ou telle organisation les possède déjà. C’est leur usage qui doit évoluer et être renforcé. Leur choix est important mais pas essentiel. L’industrialisation de la démarche sur le long terme, par contre, est essentielle.

• Un Guide est nécessaire et utile, s’il est un fil rouge et un garde-fou, pas s’il est une idéologie rigide et figée. C’est ce principe qui a régi l’élaboration de cette première version du Guide de l’Architecture d’Entreprise.

1.7. Trame des activités de l’architecture d’entreprise

La démarche d’architecture d’entreprise retenue dans ce guide est aujourd’hui répandue dans de grandes entreprises etdans certaines administrations. Elle est structurée autour de plusieurs activités organisées selon la figure ci-dessous, reprise du Club Urba-EA 34, et complétée ou précisée sur certains points. Ces activitéss’articulent en 3 sous-ensembles :

• Des activités de pilotage de la démarche ;

• Des activités de cœur de métier, qui se structurent à leur tour selon 3 axes :

  • 2 activités stratégiques qui portent sur le SI dans son ensemble, et qui globalement définissent les grands plans d’architecture du SI ;

  • 5 activités qui visent à développer, maintenir et ancrer les éléments constitutifs, transverses et ciblés de la démarche : processus métier, données de références, applications, échanges, infrastructure ;

  • 3 activités qui portent sur des actions de transformations limitées : initiatives, études, projets, maintenance…

• Des activités de soutien.

Figure 3: Les activités de la démarche d’architecture d’entreprise

Il s’agit bien des activités de la démarche d’architecture d’entreprise prise dans son ensemble, réalisées par l’ensemble des acteurs,et donc pas uniquement les activités des architectures SI.

La démarche d’architecture d’entreprise s’articule avec les autres processus de transformation du SI identifiés dans la figure ci-après. Il s’agit des processus suivants :

• Le processus de conduite de projet : de la réingénierie et transformation métier jusqu’à la conception et la fourniture des services ;

• Les processus stratégiques : de la stratégie métier, la stratégie SI, à la planification et au pilotage des portefeuilles projets.

Figure 4: Articulation des activités d’architecture d’entreprise avec la gouvernance SI

Le SI de l’Etat est par nature complexe. La maîtrise de sa transformation dans le temps est également tout aussicomplexe. Il est donc tout à la fois nécessaire de travailler sur des résultats concrets que de travailler également sur lesprocessus eux même qui permettent de traiter tel ou tel aspect de cette complexité. Ce présent guide donneune première version commune des tâches à réaliser pour pouvoir avancer sur la maîtrise du SI de l’Etat. Il seranécessaire d’adapter ce guide, de le faire évoluer à travers l’apprentissage, la réflexion au fil de l’eau, etl’amélioration continue.

La conduite de ces activités est nécessairement distribuée dans l’organisation de l’Etat. Le principe de subsidiarités’applique également ici. En fonction de la portée et du périmètre considéré, ces actions sont menées au niveau d’unedirection générale, d’un opérateur ou d’un service à compétence nationale, ou encore au niveau ministériel, voire auniveau interministériel pour les activités qui nécessitent une plus grande coordination. Le POS du SI de l’Etat estégalement conçu pour aider et éclairer le niveau de pilotage nécessaire pour ces activités.

1.7.1. Élaborer et réviser le guide de l’Architecture d’Entreprise

L’objectif premier de cette activité consiste à définir, et entretenir dans le temps, le guide méthodologique permettantde structurer la démarche d’architecture d’entreprise du SI de l’Etat. La complexité intrinsèque au système d’information de l’Etatnécessite une démarche d’ensemble structurée, un cadre partagé, qui doit permettre de renforcer la maîtrise et lacapacité d’évolution du SI. Cette démarche ne doit pas apporter de nouvelles contraintes, ou peser davantage sur cettecomplexité. Elle doit au contraire faciliter et encourager l’agilité qui est attendue du SI. L’agilité ne doit pas être uneabsence de règles, ou un prétexte au non-respect d’un cadre établi. Un guide commun est nécessaire. Cette activité a pour objetd’entretenir dans le temps ce guide formel, en particulier les nomenclaturesassociées (dont le Plan d’Occupation des Sols, la Nomenclature de référence Applicative, etc.)

Figure 5: Activité « Elaborer & réviser l’AE »

La mise en place d’une gouvernance du SI de l’Etat s’appuyant sur ces nomenclatures fait également partie de cetteactivité. L’objectif est en particulier d’identifier les responsables de zones fonctionnelles (RZF) pour chaque zone duPOS du SI de l’Etat.

1.7.2. Définir et réviser la trajectoire d’évolution SI pour l’aligner sur le métier

Il s’agit de comprendre les évolutions majeures des métiers, d’en mesurer les impacts sur le SI et son architecture, etainsi, être en mesure d’accompagner efficacement à court, moyen et long terme ses nécessaires transformations.

L’objectif n’est pas de subir mais bien d’anticiper la transformation, grâce à une stratégie, une ligne directrice à moyenterme, tout en étant opportuniste à l’occasion des projets.

Figure 6: Activité « Aligner le SI sur la stratégie métier »

L’objectif de ce processus est de tenir à jour une trajectoire d’évolution du SI, et des propositions de révisions oud’arbitrage des portefeuilles de projets. Il ne s’agit pas à proprement parler d’un travail de prédiction lourd et long surl’évolution optimale du SI, exercice difficile sur un système complexe comme le SI de l’Etat. Il s’agit d’avantaged’adopter une posture stratégique, grâce à des échanges réguliers avec les métiers, les équipes projets, et l’ensemble dela communauté concernée, de collecter, d’entretenir, d’évaluer et de diffuser continuellement la meilleure vision du SI :

• tel qu’il est aujourd’hui : l’existant, en identifiant les zones perfectibles ou présentant des risques notoires. En portant plus explicitement un jugement de valeur sur le patrimoine SI, en particulier le patrimoine applicatif.

• tel qu’il pourrait être en cible à long terme (que faudrait-il retirer d’inutile ? d’obsolète ? quels sont ses composants pérennes ?), la cible.

• tel qu’il est devrait être à moyen terme (18-24 mois) compte tenu du portefeuille des projets en cours, une vision intermédiaire à réactualiser.

Le travail d’architecture d’entreprise doit rendre visible et compréhensible des sujets qui sont parnature conceptuels, notamment grâce à des schémas ou des cartographies. Ce travail sur la trajectoire du SI, doitpouvoir se matérialiser graphiquement, en partant du Plan d’Occupation des Sols et en le déclinant sur trois vues :

• Existant : projection du patrimoine applicatif sur le POS (positionnement de toutes les applications en cours de construction et en production), avec une identification des applications « cibles » et applications à risque (qui peut se formaliser par un avis de péril). Les règles d’éligibilité pour une application « cible » devront être définies précisément dans la mise sous contrôle du patrimoine applicatif. De même les applications à dé-commissionner doivent être explicitement identifiées. L’objectif est de porter un jugement de manière plus transparente, pour le partager avec notamment les maîtrises d’ouvrage et ainsi emporter leur dé-commissionnement à l’occasion de projets métiers. Il peut s’agir par exemple d’applications obsolète technologiquement (composant non maintenu, compétence plus disponible, coût d’exploitation et de MCO croissant, etc.), mais aussi des applications en fort décalage par rapport aux besoins et aux attentes des utilisateurs, à la réglementation en vigueur, etc

Figure 7: Exemple de description du patrimoine applicatif existant sur 2 zones du domaine « Support »

• Cible : projection du patrimoine applicatif sur le POS uniquement pour les applications (identifiées, en construction, ou en production) qui sont jugées « cibles ».

Figure 8: Exemple de description du patrimoine applicatif cible sur 2 zones du domaine « Support »

• Intermédiaire : projection sur le POS :

  • de l’ensemble des applications (identifiées, en construction, en production, dont le retrait – le démantèlement- est prévu)

  • des projets (majeurs) qui impactent l’évolution du patrimoine applicatif, avec les liens (projets-applications) précisant la nature de l’impact : création de l’application, modification de l’application, décommissionnement de l’application

Figure 9: Exemple de description de l’étape transitoire - impact des projets sur le patrimoine applicatif

Ce travail de trajectoire doit être réalisé par l’autorité administrative sur l’ensemble des zones, avec une consolidationinterministérielle pour les secteurs fonctionnels transverses (domaines « pilotages & contrôles », « échange »,« données transverses », « support »), ou des secteurs du domaine « Opération » à caractère interministériel (sécuritéroutière, gestion de crise, archive définitive, enseignement, aides, subventions, etc.). Le Responsable de zonefonctionnelle à en particulier la charge de valider cette trajectoire pour la zone qui le concerne.

Ce travail sur la trajectoire a également comme objectif de consolider les éléments financiers autour dufonctionnement et de la transformation du SI de l’Etat. La figure suivante illustre un exemple de restitution possible,par zone et quartier, d’indicateurs sur le patrimoine applicatif et sur le budget de fonctionnement et d’investissement.

Figure 10: Exemple de description de la trajectoire (indicateurs sur le patrimoine applicatif et le budget)

Ce type de restitution doit faciliter la prise de décision concernant les arbitrages projets et financiers de niveaustratégique. Il ne s’agit pas nécessairement de mettre en place une comptabilité analytique pour pouvoir réaliser cetype d’outil de pilotage, mais bien de disposer d’indicateurs agrégés, de représentation graphique de ce type, parsecteurs fonctionnels du POS du SI de l’Etat. Cette trajectoire du SI sera donc constituée de manière collective parl’ensemble des ministères et consolidée par l’ATD. La représentation sous forme graphique permet plus facilementde communiquer, de partager une complexité sous-jacente grâce à un « modèle », et ainsi de renforcer la cohésion desacteurs intervenant dans l’analyse et la prise de décision. C’est un puissant outil d’aide à la décision.

1.7.3. Accompagner les métiers sur la maîtrise de leurs transformations

Ce processus est principalement centré sur la promotion, la valorisation, voire l’accompagnement à la mise en place dela démarche de pilotage par les processus et de réingénierie de processus :

• Il s’agit de promouvoir et d’accompagner de telles démarches auprès des directions métiers, d’expliciter pourquoi de telles démarches sur les processus sont une aide capitale pour la conception et l’entretien de systèmes d’information, pour l’amélioration du service rendu aux usagers, pour l’efficience de l’administration, et pour une meilleur conception du SI (vue fonctionnelle et applicative, qui sont fondamentalement dépendantes des choix métiers).

• Accompagner les métiers ou maîtrise d’ouvrage dans ces réflexions et notamment dans la pérennisation d’une telle démarche, avec un outillage structurant la connaissance du métier, son analyse et le travail d’optimisation ou de simplification : modélisation des processus, cartographie des macro-processus, des risques, etc. Il s’agit d’adopter une posture d’offre de service et proactive sur ce sujet pour faire émerger cette nécessaire réflexion sur la vue Métier du SI.

Figure 11: Activité « Accompagner les métiers sur la maîtrise de leurs transformations »

Au-delà de la démarche processus elle-même, il s’agit de réaliser un premier niveau de lien avec les fonctionnalités etles applications utilisées dans le cadre des processus / activités / procédures. Il est nécessaire d’encourager l’analyse,la formation et la réutilisation des objets de la vue Fonctionnelle, et Applicative. Inversement, la cohérence et l’impactdes travaux sur la vue Métier doivent être anticipés dans les travaux respectifs sur la vue fonctionnelle et la vueapplicative.

Le responsable de zone fonctionnelle (RZF) joue un rôle tout particulier. Responsable de la déclinaison de la stratégiemétier, il peut être, il doit être l’un des catalyseurs pour des démarches de pilotage par les processus.

1.7.4. Gouvernance des données & Mise sous contrôle les données de références

L’Etat crée et utilise un nombre important de données sous différentes formes, souvent dispersées et organisées ensilos, pour différents besoins. La facilité d’accès et la qualité de ces données conditionnent bien souvent directementl’efficacité de l’action de l’Etat. Le volume de ces données ne cesse continuellement de croître, et le besoin de pilotagede l’action publique, basée sur l’agrégation de ces données pour en constituer des informations utiles, n’a jamais étéaussi nécessaire dans le contexte budgétaire actuel fortement contraint.

De plus, la démarche de transparence et les problématiques de l’Open Data, accentuent ce phénomène,et imposent de mettre en place une véritable gouvernance d’ensemble.

Figure 12: Activité « Gouvernance des données & Mise sous contrôle les données de références »

La maîtrise des données devient un impératif. Ce processus a pour objectif de faciliter la mise sous contrôle des données(en particulier les données de référence). Il s’agit :

• de définir un ensemble de bonnes pratiques, une doctrine générale, sur la gouvernance des données:

  • cycle de vie standard d’une donnée (notamment pour déterminer ses durées de conservation)

  • modélisation, dictionnaire de données et administration des données

  • responsabilités

  • métadonnées et géolocalisation

  • gestion des droits d’accès, de la confidentialité, de l’intégrité et de la non-répudiation (le fait de s’assurer qu’un « contrat » ne peut être remis en cause par l’une des parties)

  • contextualisation, historisation, journalisation, auditabilité

• d’identifier concrètement les données transverses (ou appelées encore données de références), leurs points d’accès et les autorités qualifiées :

  • identifier et mettre sous contrôle leurs processus de mise à jour

  • identifier les référentiels et les autorités métiers référents

  • entretenir un dictionnaire des données transverses

  • encourager et faciliter leurs réutilisations (tout en limitant la prolifération des « stockages locaux » ou en proposant des services de synchronisation) : mise en place d’un catalogue de services d’accès aux données de références de l’Etat.

• de standardiser les services d’accès aux données transverses :

  • définir les principes d’architecture pour les services d’accès à des données transverses,

  • recenser les services disponibles répondants aux critères,

  • promouvoir, encourager la réutilisation de composants « sur étagère ».

Figure 13: Cycle de vie type d’une donnée

La définition de cycle de vie sur les données, illustré par la figure ci-dessus, doit comprendre :

• L’utilisation des données, et en particulier des données transverses, dans un contexte opérationnel.

• L’utilisation des données dans un contexte de pilotage, de décisionnel : définition de principes communs d’échanges entre le domaine « Opération » et le domaine « Pilotage et contrôle », identification et partage de briques communes, etc. quelles sont les règles applicables sur l’alimentation et l’entretien d’outils par exemple de type datawarehouse, datamart, etc. ?

• Les règles de mise à disposition des données pour l’Open Data.

• Les règles de suppression logique et physique

• Les règles d’archivage de l’information (archivage courant, intermédiaire et définitif)

• Les règles liées à l’entretien et la gestion des métadonnées.

1.7.5. Mettre sous contrôle les évolutions du patrimoine applicatif

L’application est un objet structurant et pivot dans le SI situé dans la vue applicative : c’est un élément logiciel(ensemble d’objets informatiques : exécutables, programmes, fichiers…) qui implémente un ensemble defonctionnalités nécessaires au bon déroulement de processus et procédures. Cet élément est au cœur même desactivités de construction, de maintenance et d’exploitation du SI, car il constitue la granularité de communication àtout niveau ; sa mise sous contrôle est donc un pré-requis important dans toutes actions de rationalisation.

Figure 14: Activité « Mettre sous contrôle les évolutions du patrimoine applicatif »

L’objectif de ce processus est donc :

• De définir le cycle de vie d’une application et les principes de gestion de portefeuilles d’applications (GPA), et d’assurer leur déclinaison opérationnelle :

  • Cycle de vie d’une application,

  • Les jalons clés : identification, permis de construire, avis de péril, permis de retrait,

  • Modèle de données autour du concept d’application (structure de données),

  • Les notions « d’application cible », et « d’avis de péril » feront l’objet de critères d’éligibilité partagés sur les 4 couches (métier, fonctionnelle, applicative et infrastructure). Ces critères devront permettre d’identifier simplement les applications dont l’utilisation, l’architecture, le support sont en phase ou non avec les règles d’architecture d’entreprise,

• De mettre sous contrôle le catalogue des applications composant le SI de l’Etat (Gestion de Portefeuille d’Application) :

  • Outillage ministériel et interministériel,

  • Agrégation interministérielle du catalogue : positionnement sur le POS et sur la trajectoire

• D’étudier la rationalisation du patrimoine applicatif, et proposer des projets d’évolution et de simplification.

  • Il s’agit donc clairement d’être en mesure de retirer (décommissionner) des applications jugées vieillissantes ou à risques. L’action volontaire des DSI sur ce sujet doit encourager également cette activité de retrait. Il faut également se permettre d’arrêter, le plus tôt la construction ou l’intégration d’une nouvelle application dont le projet n’est plus maîtrisé.

1.7.6. Standardiser et simplifier les échanges

Le système d’information de l’Etat est un vaste ensemble de ressources (humaines, matérielles, logicielles) organiséespour collecter, stocker, traiter, manipuler, échanger, archiver, communiquer des informations. Pour pouvoir maîtriserla transformation de ce système d’information, il faut agir à la fois sur les composants du SI(comme sur les applications), mais aussi sur les échanges entre ces composants. L’évolution continue,non concertée, et hétérogène a conduit le plus souvent à concevoir ces échanges deux à deux, avec des logiquesspécifiques de construction.

La standardisation et la simplification des échanges, à la fois vues sous un angle de rationalisation pour une meilleuremaîtrise, mais aussi d’amélioration de l’interopérabilité pour un meilleur service ou une meilleure agilité du SI, sontun axe majeur de la démarche d’architecture d’entreprise.

Figure 15: Activité « Standardiser & simplifier les échanges »

Il s’agit de :

• définir et d’entretenir un Cadre Commun d’Interopérabilité (CCI) sur la sphère administration de l’Etat, comprenant les normes et standards applicables pour la mise en place d’échanges entre les administrations et entre les usagers et l’administration. Ce document normatif est organisé en plusieurs volets :

  • un volet technique qui décrit les normes et standards applicables en matière de transport de données, d’interconnexion, d’appels de services, d’interfaces homme-machine, de communication interpersonnelle, de syntaxe (formats techniques utilisés pour transporter les données) et de sécurité.

  • un volet sémantique qui décrit les normes et standards applicables en matière de description, de modélisation, et d’identification des données échangées. Il comprend également l’identification des nomenclatures et référentiels de données nationaux utilisables.

  • un volet organisationnel qui décrit l’organisation générale et les principes de construction des échanges. Il comprend les normes et standards applicables en matière de modélisation de processus, mais aussi les règles applicables en matière de gouvernance de l’information, de gestion des identités, accréditations et des accès, ainsi qu’en matière de gestion de la relation utilisateur (usager et agent).

  • un volet légal ou juridique qui décrit le cadre juridique auquel les échanges doivent se conformer

Figure 16: Les 4 niveaux d’interopérabilité

• Mettre sous contrôle les évolutions des échanges :

  • encadrer les réponses apportées aux besoins en échanges, sur les 4 niveaux de l’interopérabilité

  • promouvoir et vérifier le bon usage des standards identifiés dans le Cadre Commun d’Interopérabilité

• Rationaliser et simplifier les flux inter applicatifs : encourager les études de rationalisation et de mise en conformité des flux inter applicatifs. Cette rationalisation sur les échanges va de pair avec la rationalisation du patrimoine applicatif. Ce travail comprend deux axes de travail :

  • l’analyse des besoins d’échanges métiers, et donc sur l’optimisation des processus métiers.

  • l’analyse des solutions (services, composants, technologie) utilisées dans la mise en œuvre d’échange, en recherchant l’utilisation de briques mutualisées (exemple : système d’authentification).

1.7.7. Assurer la cohérence avec l’infrastructure informatique

Il est important de rappeler que la démarche d’architecture d’entreprise ne porte pas uniquement sur un ou deux des domaines dusystème d’information, mais bien sur l’orchestration d’actions structurées et concertées sur ces domaines ; c’est avanttoute chose un travail d’intégration et de cohérence. Il s’agit donc dans ce processus de s’assurer que les principesd’architecture d’entreprise sont correctement déclinés et en phase avec les orientations techniques majeures principalement sur lavue applicative et infrastructure.

Il existe de nombreux points d’adhérence entre les questions d’architecture fonctionnelle, applicative, d’infrastructure.Il faut par exemple, que le découpage fonctionnel défini à travers le Plan d’Occupation des Sols, qui conditionne leniveau de granularité des composants applicatifs ne soit pas en total contradiction avec les contraintes liées àl’exploitation des infrastructures. De même, la structuration d’un SI autour de la construction de composantsréutilisables, ne peut s’envisager sans les outils et normes de développement ad hoc.

Il s’agit donc dans ce processus d’ :

• identifier et prendre en compte les contraintes d’exploitation et de déploiement dans le découpage applicatif, et donc dans l’architecture logicielle.

• assurer la cohérence des choix en matière de produits et d’équipement en évitant la prolifération technologique.

• atteindre une masse critique (achat, maintenance) des produits utilisés au niveau applicatif et infrastructure, pour en assurer la pérennité financière et humaine dans le temps.

Figure 17: Activité « Assurer la cohérence avec l’infrastructure »

L’arrimage entre la vue Applicative et la vue Infrastructure est un enjeu fort. Ces liens doivent permettre une vraielecture de bout en bout depuis le besoin métier jusqu’aux éléments matériels, et inversement : passage d’une vue à uneautre. Ces liens peuvent être plus ou moins fins selon les enjeux recherchés. Mais il est important de considérer quedans un contexte de virtualisation et de mutualisation (et à terme de cloud) la description d’un lien simple entre uneapplication et son socle d’exécution est suffisante. L’architecture technique de la vue infrastructure vaprogressivement devenir une question totalement transparente pour les DSI ministérielles, pour devenir plus unequestion de gestion des engagements de services : disponibilité, performance, sécurité, réversibilité…

Quel que soit le niveau de granularité retenu, la maîtrise de cette connaissance et ces liens, même macro, entre les deuxvues Applicative et Infrastructure sont indispensables à la maîtrise du SI, et à la réalisation d’engagements de services.

1.7.8. Participer à la gestion des portefeuilles d’initiatives et de projets

L’architecture d’entreprise n’est pas un projet en soit, mais une action continue sur le SI (cf. facteurs clés de succès). Elle seconcrétise au rythme des projets et grâce à eux. Il est donc crucial d’identifier au plus tôt les projets qui peuvent avoirun impact conséquent sur l’évolution du SI, pour que la composante architecture d’entreprise soit dès le départ intégrée dans lesobjectifs de ceux-ci. Il s’agit bien d’être opportuniste dans l’intervention sur les projets, de s’assurer de leuralignement sur les principes, la stratégie et la trajectoire. Mais également par une intervention en amont, il s’agitd’être proactif, et donc en mesure de recadrer rapidement si nécessaire la stratégie et la trajectoire elle-même.L’adoption d’une démarche « agile » qui s’améliore en fonction des projets métiers menés est un critère de succèsindéniable.

L’architecture d’entreprise a également un rôle fort dans la promotion de projets transverses : composant technique, infrastructureapplicative, projet technique de rationalisation, etc. Il s’agit de guider l’évolution du SI en proposant des projets derestructuration ou d’évolution de secteurs fonctionnels, même si les métiers n’en ont pas l’initiative.

Ce travail passe par la formalisation de ce qui est appelé dans ce guide « portefeuille d’initiatives et de projets ». Ils’agit de consolider l’ensemble des demandes métiers explicites ou non, les propositions des DSI ou des projets, et lesprojets identifiés, planifiés et en cours de réalisation. L’objectif est d’avoir une vision globale non seulement sur lestransformations en cours, mais également sur celles qui sont attendues ou qui seraient souhaitables de réaliser. Cesportefeuilles sont constitués idéalement par ministère, avec une consolidation interministérielle pour lestransformations portant sur des zones transverses. Ils sont au cœur du pilotage des projets et dans le suivi de la relationMOE/MOA.

Figure 18: Activité « Participer à la gestion des portefeuilles d’initiatives et de projets »

Les architectes d’entreprises, avec l’aide des métiers, doivent chercher à qualifier ces initiatives, le plus en amont possible, avantqu’elles ne deviennent véritablement des projets et qu’elles soient inscrites dans la programmation physico-budgétaire.La qualification des initiatives consiste à identifier celles qui feront l’objet d’un suivi particulier par rapport à l’actiond’architecture d’entreprise du SI. L’aspect coût n’est pas le seul élément à considérer. Les aspects stratégiques, la valeur apportée,les risques, les impacts, la capacité à faire, etc. doivent être considérés. En particulier l’intégration dans la trajectoiredu SI doit être imaginée très tôt. Des petites initiatives, d’un point de vue du coût de leur réalisation, peuvent êtreidentifiées comme stratégique car apportant pour le métier (et/ou sur l’une ou plusieurs des autres vues du SI) uneévolution à forte valeur ajoutée (ex. simplification d’une démarche, modification d’une application pour faciliterl’enchaînement de 2 processus métiers à fort volume).

Ce portefeuille d’initiatives et de projets constitue un outil de dialogue entre tous les acteurs : métiers, MOA, MOE,architectes d’entreprises, DSI, architectes, et bien sûr les projets. Il doit être suivi et publié régulièrement. L’architecte d’entreprise de par savision globale et notamment son action sur la trajectoire du SI est à même de proposer des ajustements (périmètre,calendrier) en cas de conflits, notamment de ressources, mais aussi pour anticiper d’éventuelles difficultés (planning,ressources, techniques, métiers, réglementaires, etc.). Ces ajustements peuvent conduire à réviser, à la marge latrajectoire d’évolution du SI, sans pour autant impacter la stratégie d’ensemble. Dans le cas de difficultés avérées quinécessitent une refonte majeure du cadre stratégique, ou de la trajectoire du SI, il s’agira de réviser l’alignement duSI sur la stratégie, et de remonter en comité stratégique ce sujet pour l’instruire.

Un suivi régulier de ce portefeuille d’initiatives et de projets, facilitera l’identification des risques et leur résolution.Un suivi macro et une grande réactivité sont à privilégier.

1.7.9. Participer et cadrer les études avant-projet (études préalables)

Un dispositif doit donc permettre de définir « ce qu’il faudrait faire » (c’est-à-dire dans le respect des règlesd’architecture d’entreprise), le confronter le plus tôt avec « ce qu’il est possible de faire » (c’est-à-dire dans le respect descontraintes coûts & délais), afin que les instances de pilotage puissent rendre les arbitrages nécessaires. L’architecture d’entreprisedoit faciliter la prise de décision par un éclairage sur la prise de risque vis-à-vis de la trajectoire du SI.

Cette action est par construction ministérielle, dans le cas de projet touchant aux zones du domaine « Opération » duPOS (spécifique donc à une mission ministérielle – au sens métier), et par nature interministérielle pour tous les autrescas (transverses par construction).

Ce processus se décompose de la manière suivante :

• La qualification du projet : à partir de la qualification de l’initiative à l’origine du projet, compléter l’apport du projet pour la stratégie métier et SI, et la trajectoire d’évolution du SI.

• L’assistance aux acteurs de pilotage du projet pour mener l’avant-projet et identifier son intégration dans la trajectoire du SI

• Evaluation de la valeur du projet identifié

• La fourniture d’un avis (respect des principes et règles, positionnement dans la trajectoire)

• L’action plus systématique de vérification du respect des règles d’architecture d’entreprise du SI dans les phases amont des projets

Figure 19: Activité « Participer et cadrer les études avant-projets »

L’avant projet, consiste d’une part à identifier les éléments du SI (sur la vue métier et fonctionnelle avant tout, sur lavue applicative et infrastructure quand c’est possible) qui vont être impactés par cette transformation : les ajouts, lesmodifications, les retraits. Il consiste, d’autre part, à vérifier si ces impacts sont compatibles avec l’architecture d’entreprise gouvernementale et la trajectoire du SI.

L’objectif consiste à prendre en compte les besoins de transformation métiers et à les analyser :

• Identifier les processus et activités métiers impactés ; ce point est un pré-requis important. Les acteurs en charge de cet avant projet doivent également être force de proposition quant à l’optimisation de cette transformation métier. Il ne s’agit pas à ce stade d’obtenir une analyse détaillée des processus et activités mises en place ou impactées par le projet, mais bien de les identifier selon les éléments d’analyse suivants :

  • Partir de la connaissance actuelle du métier

  • Élargir la vision, penser à l’administration élargie et l’ensemble de la chaîne de valeur, mais agir par étape limitée dans la transformation

  • Identifier les variantes de processus ou déviations possibles (cas particuliers, qui produisent de la complexité et des surcoûts supplémentaires souvent beaucoup plus importants que leur fréquence rare le ferait penser)

  • Innover dans la résolution de problème organisationnel, fonctionnel ou technique

  • Identifier à quel moment il sera nécessaire de décrire précisément les nouveaux processus, la nouvelle organisation et mener la nécessaire conduite du changement

• Recenser les fonctionnalités et les objets métiers attendus ; les définir et les positionner sur le POS. Les principes d’architecture d’entreprise sur les données sont à ce titre très structurants.

• Identifier les applications couvrant tout ou partie des fonctionnalités identifiées, et le cas échéant couvrant des blocs du POS concernés par le projet.

L’objectif est de pouvoir, à partir d’une analyse critique de l’existant (couverture, obsolescence, charge, pérennité), dela trajectoire du SI et de l’analyse des besoins métiers, d’identifier le ou les scénarios optimums de transformation dupatrimoine fonctionnel et applicatif, sur la base d’hypothèses de transformation métier, tout en respectant les principesd’architecture d’entreprise (en particulier ceux concernant la conception qui s’appliquent tout particulièrement dans cette activité).

Le dossier d’architecture d’entreprise ainsi constitué devra faire l’objet d’une validation formelle par les instances de pilotage del’architecture d’entreprise au niveau ministériel (ou interministériel dans le cas d’un projet transverse). Le comité ad hoc (ex :comité d’architecture d’entreprise ministériel) formulera ainsi un avis à destination du comité de pilotage du projet.

Dans l’évaluation de la valeur des projets,, il est avantageux de répondre aux questions suivantes :

• Alignement stratégique

  • Les objectifs poursuivis par le projet sont-ils en phase avec la vision et les orientations stratégiques de l’organisation?

  • Justification légale ou économique

  • Les bénéfices sont-ils suffisants pour assurer le rendement des investissements?

  • Sinon, s’agit-il d’obligations légales ou réglementaires qui justifient, à elles seules, la nécessité d’agir (p. ex. changement de loi, décret)?

• Niveau de risque

  • Le niveau de risque du projet est-il acceptable (risque humain, technique, financier, etc.)?

  • Suivi des résultats attendus

  • Les avantages du projet sont-ils clairement identifiés et leur concrétisation sera-t-elle suivie à l’aide d’indicateurs adéquats?

La méthodologie MAREVA (méthode d’analyse et de remontée de la valeur) peut, par exemple, être employée pour déterminer la valeur de chaque projet, enconsidérant toutefois qu’elle doit être adaptée au contexte de l’organisation.

Que ce soit avec cette méthodologie ou une autre, il importe d’établir les critères, accompagnés d’une pondération, qui permettront d’évaluer adéquatement chaqueprojet en considérant la dimension financière, mais aussi les autres dimensionsjugées pertinentes pour l’organisation (réponse aux objectifs d’affaires, réponse auxprincipes d’AE, etc.). L’idée est que les critères établis fassent consensus dansl’organisation, d’où l’importance de les soumettre préalablement à la structure degouvernance pour approbation

L’avis du comité d’architecture d’entreprise doit se prononcer sur la faisabilité du projet, son intégration dans la trajectoire du SI(et donc la stratégie), sa conformité par rapport aux principes et règles d’architectures, s’il présente des risques noncouverts, et s’il doit être suivi de manière particulière (projet qualifié de « stratégique »).

1.7.10. Suivre et accompagner les études, projets et opérations de maintenance

L’objectif de ce suivi est multiple. Il s’agit à la fois de :

• s’assurer que le cadrage effectué sur les projets est respecté,

• s’assurer que globalement les principes et les règles d’architecture d’entreprise sont respectés,

• et enfin, de faire en sorte que la connaissance du SI soit fidèle à ce qui est réellement produit par les projets

Il est donc important de suivre, a minima, les projets stratégiques (identifiés dans le portefeuille comme tels), oucertaines évolutions qui portent sur des applications critiques (identifiées dans le portefeuille applicatif comme telles).Dans le cas de projet important, les phases de conception, de développement et même de tests peuvent donner lieu àcertains ajustements pour de multiples raisons (arbitrage MOA sur les coûts et les délais, contributeur pas au rendez-vous,changement de périmètre fonctionnel, contraintes techniques sous-évaluées, etc.). Ces ajustements peuvententraîner un écart par rapport au cadrage initial. Il s’agit dans les cas jugés critiques de réinstruire cesécarts, ou le cas échéant, de réaligner le cadrage initial sur ces nouveaux ajustements.

Figure 20: Activité « Suivre et accompagner les études, projets et maintenances »

La phase de bilan projet est également le lieu permettant d’évaluer les écarts entre le cadrage initial et ce qui a étéréellement réalisé. Il peut être l’occasion d’un réalignement de la connaissance sur le réalisé. Ce bilan doit égalementpermettre de tirer les enseignements sur les difficultés rencontrées, notamment vis-à-vis de l’application des principeset règles d’architecture d’entreprise, vis-à-vis de la maîtrise de l’existant et de sa transformation. Ces bilans doivent être largementpubliés pour partager les réussites comme les difficultés, et ainsi faire progresser la maturité en matière de pilotage.

1.7.11. Piloter l’architecture d’entreprise du SI

Il s’agit de piloter la mise en œuvre du dispositif d’architecture d’entreprise (d’architecture d’entreprise) au niveau ministériel etinterministériel. La mesure de la maturité de ce dispositif est réalisée à partir d’indicateurs d’architecture d’entreprise, construitssur les meilleures pratiques du moment (reprise des indicateurs d’architecture d’entreprise du Club Urba-EA). L’annexe duprésent guide définit la structure des indicateurs et leur signification.

La formalisation du niveau de maturité sous forme d’indicateurs permet de donner la visibilité nécessaire à l’ensembledes acteurs opérationnels, mais aussi décideurs de la démarche, dans le but de partager les objectifs et les moyensalloués au dispositif.

Figure 21: Activité « Participer à la gestion des portefeuilles d’initiatives et de projets »

L’objectif est donc périodiquement (sur une base annuelle, au dernier trimestre lors de la préparation de laprogrammation de l’année suivante) de valoriser les indicateurs d’architecture d’entreprise avec les différents acteurs MOA etMOE concernés. L’analyse permet de mettre en perspective les résultats en fonction d’éléments de contexte propre(stratégie, projet, organisation). La diffusion et la transparence des résultats sont nécessaires pour embarquerl’ensemble des acteurs dans une dynamique d’amélioration continue.

En plus de l’analyse des indicateurs valorisés, il est nécessaire d’objectiver le niveau souhaité, la valeur cible pourchaque indice, en fonction de la stratégie de chaque administration et des axes d’efforts envisagés.

Il s’agit enfin de définir un plan d’actions permettant d’atteindre ces objectifs fixés (formations, projets, évolutions deprocessus internes aux DSI) et donc les valeurs cibles des indicateurs d’architecture d’entreprise.

La constitution d’un tableau de bord reprenant les éléments clés issus de l’analyse des indicateurs et le plan d’actionscorrespondant permettra de suivre régulièrement l’avancée des travaux. Il s’agit tout à la fois de fédérer les pratiquesdes différents acteurs de l’architecture d’entreprise, en particulier des RZF, et de décliner une ambition commune de maturité.

1.7.12. Participer aux comités stratégiques et aux comités d’arbitrage projets

Faire l’architecture d’entreprise d’un SI c’est aussi conseiller et participer à l’arbitrage et l’ordonnancement des projets, afin d’éviter parexemple les réalisations en double, ou encore d’éviter de construire des solutions temporaires en attendant lescomposants cibles. Pour assurer ce travail de conseil, il est nécessaire de disposer de la stratégie métier ou d’élémentsde stratégie métier (priorités, orientations, évolutions réglementaires, etc.), d’une vision globale du patrimoine SIactuel, et surtout d’une vision consolidée du portefeuille projets valorisés. C’est à partir de ces éléments et de latrajectoire du SI, que l’architecte d’entreprise SI peut conseiller et proposer des adaptations ou des évolutions de latrajectoire dans les instances d’arbitrage ou de planification stratégique.

Ce travail d’analyse et d’arbitrage stratégique peut conduire les architectes d’entreprises à proposer des scénarios alternatifs(révision du périmètre, du lotissement et du calendrier de projets, voire en proposant de nouveaux projets notammentsur des sujets transverses).

1.7.13. Outiller, maintenir et diffuser la connaissance du patrimoine SI

Cette activité de support à la démarche d’architecture d’entreprise est particulièrement importante. Elle permet de collecter des données,de les synthétiser, les modéliser sous forme d’information utiles à l’analyse et aux prises de décisions, pour finalement en constituerla connaissance sur le patrimoine SI.

Cette activité se décompose de la manière suivante :

• La définition et l’entretien d’un métamodèle commun : il s’agit du dictionnaire des données manipulées avec leur structure. Dans un objectif de partage de la connaissance, il est nécessaire d’aligner l’ensemble des pratiques sur un métamodèle unique au niveau de l’Etat.

• La mise en œuvre du référentiel permettant de gérer et d’outiller cette connaissance, sur la base du métamodèle unique. La mise en place d’un outil unique n’est pas à ce stade un objectif recherché. Toutefois, la convergence des choix au moment de renouvellement de marché par exemple, est un levier fort de convergence des pratiques et de partage de la connaissance. Dans tous les cas, les outils devront se conformer au métamodèle commun.

• La mise en place de dispositifs de collecte, d’entretien, de validation et de publication de la connaissance ancrés dans les processus courant des DSI (gestion de portefeuille projets et gestion des changements). Ces dispositifs comprendront :

  • des processus formalisés a minima pour accompagner la mise en place,

  • des guides de modélisation pour structurer la collecte et la modélisation de la connaissance.

• Enfin, la publication de la connaissance.

Figure 22: Activité « Outiller, maintenir et diffuser la connaissance du patrimoine SI »

Il est important de rappeler ici que ce travail de gestion de la connaissance doit contribuer aux objectifs fondamentaux dela démarche d’architecture d’entreprise : aider la décision de transformation du SI et piloter le patrimoine. Il est donc nécessaired’intégrer dans la collecte également des informations sur les coûts (coût d’exploitation par exemple pour uneapplication) et les budgets (prévisionnels sur les projets par exemple).

1.7.14. Veille métier et technologique

La démarche d’architecture d’entreprise s’engage clairement sur le long terme, la maîtrise de la transformation du SI passe doncégalement par une action de veille visant :

• à suivre et identifier les évolutions de l’environnement métier ou du métier lui-même (évolution de la réglementation internationale ou nationale, projets sous-régionaux et régionaux, retour d’expérience provenant d’autres états…). Il s’agit d’anticiper ces évolutions et leurs impacts sur le SI.

• à identifier et accompagner de façon proactive les opportunités technologiques de nature à modifier le métier ou son environnement ou encore à créer des opportunités pour les administrations. Il s’agit d’anticiper de façon proactive l’impact de ces technologies sur l’architecture globale du SI.

Il ne s’agit pas ici, encore une fois, d’une veille spécifique pour l’architecture d’entreprise, mais bien de définir que l’action deveille qui est l’une des fonctions assurées par les DSI, concourt à la démarche d’architecture d’entreprise du SI.

1.7.15. Communiquer et développer les compétences en architecture d’entreprise SI

Pour que cette démarche d’architecture d’entreprise et ce cadre se concrétisent de manière opérationnelle, et deviennent un desguides de construction dans les projets, il est nécessaire que les principes soient largement partagés dansl’administration. Cette acculturation est nécessaire aussi bien pour les maîtrises d’ouvrage que les maîtres d’œuvre ; ilest en effet plus facile d’avoir un dialogue constructif quand chaque acteurs partage les principaux enjeux : disposerd’un SI pérenne, « agile », maîtrisé, et à son niveau, connait les règles qui en découlent.

Ce large partage est d’autant plus nécessaire qu’un des fondements de l’architecture d’entreprise réside dans le fait de disposerd’une vision partagée du SI entre les Directions Métiers et les DSI, en évitant une rupture totale entre les deuxpréoccupations (métier – SI) ; l’architecture fonctionnelle constitue une zone de partage, de contact, privilégiée entreces deux grandes familles d’acteurs.

Figure 23: Activité « Promouvoir et développer les compétences en Architecture SI »

Cette activité comprend avant tout un travail de promotion, à travers des communications, des évènementsspécifiques, des rencontres avec des experts externes du sujet. Il s’agit également de former durablement les futursarchitectes d’entreprises et d’entretenir le niveau de compétence des architectes d’entreprises en poste, en mettant en place un dispositif et dessupports de formation au niveau interministériel.

L’entretien d’un vivier est également un moyen efficace pour identifier les agents à potentiel et être en mesure de leurproposer une évolution de carrière.

Compte tenu de la portée du SI de l’Etat, cette démarche d’architecture d’entreprise ne peut se déployer de manière centralisée.Elle repose sur un fonctionnement au contraire totalement décentralisé, un réseau de contributeurs (stratégie, métier,données, applicatif, infrastructure, projet…). L’animation de ce réseau et la recherche permanente de nouveaux relaissont deux éléments clés de réussite de la démarche.

1.8. Portée

Le terme organisme public peut désigner un organisme de Sécurité sociale et de Protection Sociale, une Collectivité territoriale, un ministère (ex : le ministère de la justice), une direction centrale d’un ministère (ex : DGDN), un opérateur sous tutelle d’un ministère ou d’une direction générale (ex : l’ARCEP), d’un service déconcentré d’un ministère (ex : une préfecture). Une autorité administrative est définie par ses missions, son organisation, et ses ressources (humaines, financières, techniques…).

Figure 24: Portée du terme « Organisme Public » utilisé dans le guide

1.9. Les acteurs de la démarche, leurs rôles et responsabilités

Cette partie décrit le rôle des différents intervenants, encore appelés acteurs (personnes ougroupes), dans la démarche d’architecture d’entreprise. L’identification des différents acteurs précède le tableau desynthèse définissant ces rôles sous forme de RACI : R pour Réalisé, A pour Autorité, C pour Consulté et I pourInformé.

L’acteur qui joue le rôle de A est celui qui est responsable de l’action ou du livrable, qui le valide. Le R réalisel’action ou rédige le livrable. Il y a au moins un R pour chaque action / livrable. Il peut y en avoir plusieurs.Notamment dans le cas de documents à portée variable, il est possible d’imaginer un R pour la portée ministérielle etun R pour la portée interministérielle. Les C sont les acteurs qui doivent être consultés et qui apportent leur avis voireune contribution au(x) R dans la réalisation d’un livrable. Les I sont les acteurs qui doivent être informés de l’action.Ils seront a minima destinataires des livrables.

Il ne s’agit pas à ce stade d’imposer une organisation particulière pour piloter et réaliser cette démarched’architecture d’entreprise. Chaque administration et ministère doivent s’inspirer de la présente définition des acteurs et deleurs responsabilités pour décliner ou aligner, en fonction de leur contexte et environnement propre, ladémarche d’architecture d’entreprise.

Le principal objectif de la démarche, il est nécessaire de le rappeler, est l’efficacité de la coopération des différentsacteurs de la transformation autour d’un cadre formel et de règles communes.

1.9.1. Les acteurs

Le présent guide identifie les acteurs majeurs de la démarche et leurs activités, sans pour autant désigner dans le détaill’ensemble des rôles et fonctions nécessaires à la mise en œuvre de la démarche.

Comité interministériel de suivi des projets de la Feuille de route : Ce comité est une entité multidisciplinaire composée de représentants de divers ministères, chargée de superviser et de coordonner l’exécution des projets stratégiques définis dans la feuille de route gouvernementale sur la période de 2020 à 2025. Il assure le suivi régulier des progrès, évalue l’atteinte des objectifs à différentes étapes, et garantit que les initiatives interministérielles soient menées de manière cohérente et alignée avec les politiques globales de l’État. Le comité joue un rôle crucial dans la facilitation de la communication entre les ministères, la résolution de problèmes transversaux, l’allocation des ressources nécessaires, et la prise de décisions stratégiques pour ajuster ou redéfinir les orientations des projets en fonction des enjeux et des défis rencontrés

Secrétaire Général (ministériel) : Il assiste le ministre dans l’orientation générale et la conduite des opérations. Ilcoordonne les directions du ministère et conduit les chantiers transversaux majeurs ainsi que les politiques demodernisation et les stratégies de réforme.

Direction Métier : Assure la responsabilité fondamentale d’un métier de l’administration dans toutes ses dimensions :stratégiques, humaines, organisationnelles, financières, techniques, etc. Toutefois, certaines de ces composantes dansleur gestion et leur mise en place peuvent être déléguées et/ou mutualisées (notion de fonction support). Une directionmétier pilote l’ensemble des projets de transformation de ce métier dans toute sa complexité. Elle est garant de l’enjeustratégique de la transformation du métier concerné, pour l’administration de l’Etat et l’ensemble des tiers. Le termedirection métier, désigne de manière générique dans ce cadre, le responsable d’un métier d’une administration et lesagents qui y travaillent. Il désigne également les directions en charge de fonction support. Les DRH exercentégalement un métier, celui de la gestion des ressources humaines

DSI ministériel, ou DSI d’une autorité administrative : Le terme de DSI désigne tout autant le « Directeur des SI »lui-même que l’encadrement d’une manière générale de la DSI. Le Directeur SI conduit la mise en œuvre desorientations stratégiques en matière de systèmes d’information et de communication. Il est garant de l’alignement duSI sur la stratégie de l’administration concernée, formalisée dans le cadre stratégique ministériel. Il est responsable dela conception, de la mise en œuvre et du maintien en condition opérationnelle du SI et de sa qualité. Il fixe et valide lesgrandes orientations informatiques de l’administration concernée. Il anticipe les évolutions nécessaires en fonction ducadre stratégique ministériel et interministériel. Il évalue et préconise les investissements en fonction des sautstechnologiques souhaités. Il s’assure de l’efficacité et de la maîtrise des risques liés au SI. Il gère les ressourceshumaines, financières et techniques dont il a la responsabilité pour assurer ses missions.

Architecte SI : L’architecte SI est l’un des acteurs clé dela démarche d’architecture d’entreprise. Il doit veiller à la cohérence de la transformation du SI dans son ensemble (sur lepérimètre qui lui est défini : un ministère, une administration, une zone du POS du SI de l’Etat), dans le respect desobjectifs de l’Etat définis dans le présent cadre. Il doit être dans le circuit de validation de toutes actions d’évolutionsstructurantes du SI, et doit soumettre à la décision des recadrages éventuels, voire soumettre d’autres actionsd’évolutions permettant de garantir à long terme une transformation plus efficiente du SI, plus aligné sur la stratégiemétier. Le présent guide de l’Architecture d’Entreprise définit précisément son rôle, les principes qui régissent son action, etses activités. Le positionnement dans l’organisation de l’architecte SI n’est pas tranché dans ce cadre. Premièrementcar il dépend fortement du niveau de maturité des métiers en matière SI, du niveau de maturité de la conduite desprojets (rôle MOA et MOE), et de la fonction SI. L’architecte SI est avant tout un intermédiaire entre les métiers, lesprojets et les DSI, et un soutien à ces acteurs pour toutes les décisions stratégiques de transformation. Deuxièmement,car cette fonction ne peut être complètement centralisée au niveau interministériel voire même ministériel. Uneproximité avec les métiers est absolument nécessaire. Actuellement cette fonction est positionnée majoritairement ausein des DSI, avec une démarche portée majoritairement sur la vue fonctionnelle et applicative. L’objectif de ce cadreest d’étendre cette action à l’ensemble du périmètre SI (stratégie, métier, fonctionnelle, applicatif et infrastructure),avec une priorité, en terme d’effort à long termes, sur la vue Métier et Stratégie. Une évolution du positionnement desarchitectes sera probablement à étudier à l’issue des premiers résultats concrets de cette démarche.

Architecte Technique : l’architecte technique définit l’architecture technique de tout ou partie du SI d’un ministèreou d’une autorité administrative. Il garantit la cohérence et la pérennité de l’ensemble des moyens informatiques (vueinfrastructure et applicative), en exploitant au mieux les possibilités de l’art dans le respect de l’Architecture d’EntrepriseGouvernementale du Togo.

Projet : Le projet est considéré dans ce cadre comme un acteur unique (MOA+MOE). C’est une organisation, nonpérenne, rassemblant plusieurs compétences, réalisant un ensemble d’activités et d’actions dans le but d’obtenir unrésultat optimal et conforme aux exigences métiers formulées par un commanditaire (cf. direction métier ci-après), ence qui concerne la qualité, les performances, le coût, le délai et la sécurité. Le projet ici est considéré comme un tout :une transformation de tout ou partie d’un métier et de son SI. Il conduit donc également pour la partie SI, laconception jusqu’à la réception de toutes les transformations nécessaires sur le patrimoine fonctionnel, applicatif, etinfrastructure du SI conformément aux exigences formulées par le commanditaire métier, en ce qui concerne laqualité, les performances, le coût, le délai et la sécurité.

Expert : L’intervention d’experts sera nécessaire pour certaines activités de la démarche d’architecture d’entreprise. Ils ne sontpas explicitement mentionnés dans la description des processus, ni dans le tableau ci-après. Il s’agit de l’expertise surles compétences suivantes : métier, sécurité SI, archive, ergonomie, accessibilité, juridique, etc. Dans une versionultérieure, il pourra être utile de préciser leur rôle et mode d’intervention.

Responsable de Zone Fonctionnelle (RZF) : Le RZF est en charge de la stratégie d’évolution du SI sur un sousensemble du SI de l’Etat, sur une zone du POS (Le Plan d’Occupation des Sols du SI de l’Etat définit l’ensemble deszones fonctionnelles à considérer). Le RZF définit le schéma directeur de sa zone, et décline localement la démarched’architecture d’entreprise, selon les principes définis par le présent cadre, pour assurer la cohérence et la maîtrise des actions detransformation du SI de l’Etat sur cette zone. En dehors du responsable lui-même, il est également nécessaired’identifier un architecte référent par zone du POS. Le RZF est une fonction nouvelle à l’échelle de l’Etat, ses droits etdevoirs seront précisés ultérieurement. Il s’agira de décrire très concrètement ses missions mais aussi ses devoirs vis-à-vis del’ensemble des autres acteurs (les autres RZF, les acteurs interministériels, etc.). Il s’agit une fois de plus demonter progressivement en maturité sur la gouvernance de cette démarche complexe.

Comité stratégique SI ministériel : il constitue l’instance de pilotage stratégique de plus haut niveau au sein d’unministère. Il est chargé des arbitrages stratégiques et de la validation du cadre stratégique ministériel.

Comité des DSI :Ce comité réunit les responsables des SI de l’ensemble des ministères. Le comité peut être consulté sur toute question relevant des attributions de la DISIC. Il peutentendre, sur ces questions, toute personne qualifiée

1.9.2. Les rôles et responsabilités

La figure ci-après définit pour chaque livrable (lignes) le rôle et les responsabilités des acteurs (colonnes) listésprécédemment. Les livrables sont positionnés en regard des activités qui les produisent.

Figure 25: Rôle et responsabilités

Références

[1]

Rapport du CIGREF.