Freelance Data Architecture Lead

Présentation

• Gestion des infrastructures IT : réseaux, sécurité, data centers et cloud.
• Développement d’applications métiers sur mesure.
• Accompagnement des projets digitaux : analyse fonctionnelle, UX/UI et gestion de projet.
• Cybersécurité et protection des données.
• Support aux utilisateurs et formation.

Dans un contexte orienté innovation, performance et service public, cette mission vise à renforcer les équipes sur un projet d’architecture des données à fort enjeu opérationnel.

Mission

La mission consiste à apporter une expertise en architecture des données afin d’analyser le paysage de données de WBE, d’en produire la cartographie ainsi que la modélisation conceptuelle et logique, et de co-construire l’architecture cible avec les équipes concernées, ainsi que sa trajectoire de mise en œuvre.

Il s’agit d’une mission de cadrage et d’architecture data produisant des modèles, des scénarios argumentés, des décisions documentées et une feuille de route exploitable.

Le/la Data Architect analyse l’existant, modélise le domaine, prépare et justifie les options d’architecture des données, puis en déduit une trajectoire priorisée. Le rôle s’exerce en appui des business analysts et des architectes d’entreprise pour traduire le cadrage métier en exigences et modèles de données, en lien étroit avec les architectes de solution chargés de la déclinaison applicative.

Responsabilités

Cadrage et alignement

• Animer les ateliers avec les business analysts et l’équipe programme.
• S’appuyer sur les capacités métier et les processus identifiés afin d’en déduire les objets de données associés.
• Définir les principes d’architecture des données applicables au programme et les aligner sur les principes d’architecture d’entreprise.

Analyse de l'existant (AS-IS)

• Inventorier les sources de données : applications, référentiels, bases, fichiers et échanges avec les administrations et établissements.
• Cartographier les flux actuels : producteurs, consommateurs, fréquences, mécanismes d’échange et dépendances.
• Identifier les points de douleur : silos, redondances, ressaisies, latence, défauts de qualité et zones sans propriétaire.
• Réaliser une analyse des écarts sur le paysage de données existant.

Modélisation du domaine

• Élaborer le modèle conceptuel puis logique des objets métier structurants du domaine.
• Utiliser des approches de modélisation telles que entité-association / Merise, UML, ArchiMate et, lorsque pertinent, la modélisation dimensionnelle.
• Identifier les données de référence, les systèmes maîtres (SoR) et clarifier les règles de propriété de la donnée.
• Produire le dictionnaire de données, le catalogue de métadonnées attendu et les règles de qualité associées.
• Utiliser des outils de modélisation, de cartographie et de catalogage de données, de type Sparx Enterprise Architect.

Construction de l'architecture cible

• Étudier les paradigmes envisageables — hub de données, lakehouse, data mesh, data fabric, virtualisation — et les comparer au regard du contexte, des contraintes et des moyens disponibles.
• Construire, avec les parties prenantes, deux à trois scénarios argumentés avec critères de comparaison explicites, avantages, limites et conditions d’adoption.
• Confronter les options avec les architectes d’entreprise, les architectes de solution et les équipes data afin de faire émerger une cible issue d’un travail collectif.
• Définir les règles d’usage des patterns d’échange et d’exposition : API, événementiel, réplication, virtualisation et alimentation analytique.
• Positionner l’architecture cible par rapport aux socles mutualisés et à la stratégie data de l’organisation.
• 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 applicables.
• Veiller à ce que l’architecture retenue préserve les usages analytiques et IA en matière de qualité, traçabilité et accessibilité des données.

Gouvernance des données — prérequis

• Définir les fondations minimales de gouvernance nécessaires à l’adoption de l’architecture : rôles, instances et processus de décision.
• Préciser les attentes en matière de métadonnées, de catalogue de données, de cycle de vie et de gestion des droits d’accès.
• Décrire l’application concrète du principe du « only once » sur le périmètre concerné.
• Structurer les règles de gouvernance des données en cohérence avec le RGPD et les besoins de qualité des données.

Trajectoire et transfert

• Découper la cible en lots cohérents et définir les architectures de transition.
• Prioriser la feuille de route selon la valeur métier et le risque,