Challenge |

Cadrage et alignement

• Animer les ateliers avec les business analysts et l'équipe du programme.

• S'appuyer sur les capacités métier et les processus identifiés par les business analysts et les architectes d'entreprise, et en dériver les objets de données qui les portent.

• Formuler les principes d'architecture des données applicables au programme et les aligner sur les principes directeurs d'entreprise

Analyse de l'existant (AS-IS)

• Inventorier les sources de données du pouvoir organisateur : applications, référentiels, bases, fichiers, échanges avec les administrations et les établissements.

• Cartographier les flux actuels : producteurs, consommateurs, fréquences, mécanismes d'échange, dépendances.

• Identifier les points de douleur : silos, redondances, ressaisies, latence, défauts de qualité, zones sans propriétaire.

Modélisation du domaine

• Établir le modèle conceptuel puis logique des objets métier structurants

• Identifier les données de référence, désigner les systèmes maîtres et clarifier les règles de propriété de la donnée.

• Produire le dictionnaire de données du domaine et les règles de qualité associées.

Construction de l'architecture cible

• Instruire les paradigmes envisageables (hub de données, lakehouse, approche fédérée de type mesh, virtualisation) et les comparer au regard du contexte, des contraintes et des moyens disponibles.

• Confronter ces options aux architectes d'entreprise, aux architectes de solution et au centre de compétences data interne : la cible n'est pas arrêtée a priori et doit résulter de ce travail collectif.

• Établir les règles d'usage des patterns d'échange et d'exposition (API, événementiel, réplication, virtualisation, alimentation analytique) : quel pattern pour quelle classe de besoin et à quelles conditions. Le choix des composants et leur mise en œuvre par application relèvent des architectes de solution.

• Positionner l'architecture cible vis-à-vis des socles et services mutualisés et de la stratégie data de l'entreprise.

• Traduire les contraintes de sécurité, de protection des données à caractère personnel, de souveraineté et de sobriété numérique en règles d'architecture opposables.

• S'assurer que l'architecture retenue ne ferme pas les usages analytiques et d'IA (qualité, traçabilité, accessibilité des données), sans préempter les cas d'usage.

Gouvernance des données — prérequis

• Définir les fondations minimales de gouvernance nécessaires à l'adoption de l'architecture : rôles (propriétaire, intendant de la donnée), instances, processus de décision.

• Spécifier le référentiel de métadonnées et le catalogue documenté attendus, ainsi que la maîtrise des droits d'accès.

• Décrire la mise en œuvre concrète du principe du « only once » sur le périmètre WBE.

Trajectoire et transfert

• Découper la cible en lots cohérents et définir les architectures data de transition intermédiaire.

• Prioriser la feuille de route selon la valeur métier et le risque, en cohérence avec le calendrier du programme.

• Assurer le transfert de connaissances vers les équipes internes, de manière à ce que les livrables restent exploitables après la fin de la mission. Un appui expert ponctuel aux équipes reste possible pendant la durée de la mission.

Casting |

• Animation d'ateliers et décisions d'architecture — 5 ans minimum

• Cartographie des données et analyse des écarts — 10 ans minimum

• Données de référence et qualité — MDM, SoR, dictionnaire et catalogue — 5 ans minimum

• Frameworks d'architecture — TOGAF, ArchiMate, DAMA-DMBOK ou équivalents — 5 ans minimum

• Gouvernance des données — rôles, cycle de vie, accès, RGPD, « only once » — 10 ans minimum

• Modélisation conceptuelle, logique et dimensionnelle — Merise, UML, ArchiMate — 10 ans minimum

• Outils de modélisation, cartographie et catalogage — 5 ans minimum

• Architectures de données — hub, lakehouse, data mesh, data fabric, virtualisation ; comparaison et arbitrage — 10 ans minimum

• Échange et exposition — API, événementiel, réplication, virtualisation, analytique ; patterns et règles d'usage — 5 ans minimum

• Sécurité et souveraineté des données — contraintes traduites en règles d'architecture — 5 ans minimum

• Pratique professionnelle de l'Anglias

• Natif en Français