Data Architect

Le Data Architect, ou architecte de données, est le professionnel qui conçoit l’organisation technique des données pour répondre aux usages de l’entreprise. Il définit les modèles, la circulation des données et les choix de stockage. Son travail donne aux équipes techniques un cadre pour construire des solutions cohérentes avec les besoins des utilisateurs.

Il part de l’existant : quelles données sont disponibles, d’où viennent-elles et comment sont-elles utilisées ? Il rapproche cette cartographie des attentes métier, puis formalise une architecture. Celle-ci précise les relations entre les données, leurs échanges et les contraintes à prendre en compte pour les rendre accessibles. Les schémas et les métadonnées permettent de partager ces choix et d’examiner les effets d’une nouvelle intégration.

Le rôle s’exerce en relation avec les équipes des systèmes d’information, les ingénieurs de données et les data scientists. Le rattachement et les décisions confiées doivent être précisés dans chaque organisation. Le titre seul ne donne ni une responsabilité hiérarchique ni l’autorité de valider toutes les règles de sécurité ou de conformité. L’architecte intègre les standards et les exigences de protection avec les spécialistes concernés.

Data Architect, Data Engineer et direction data : qui fait quoi ?

• Le Data Architect porte la cohérence des modèles et des choix d’architecture. Il explique les décisions techniques et leurs conséquences pour les usages.
• Le Data Engineer développe et met en œuvre les flux de données. La conception des intégrations peut faire partie de son travail : les compétences des deux métiers se recouvrent.
• La direction data définit la stratégie des données et conduit son déploiement. Ce mandat ne découle pas automatiquement du titre de Data Architect.

Pour cadrer un poste, distinguez donc les recommandations attendues, les décisions que la personne pourra approuver et les réalisations confiées aux autres équipes. Cette répartition évite d’assimiler un besoin d’architecture à un poste de développement ou de direction.

L’architecture des données relie les besoins des utilisateurs aux choix techniques. Un même projet doit tenir compte des données disponibles, de leur format, des échanges entre systèmes et des conditions d’accès. Pour un dirigeant, l’enjeu est de rendre ces choix compréhensibles avant d’engager la réalisation.

Une plateforme peut répondre à un besoin de stockage tout en étant mal adaptée au temps de réponse attendu. Un modèle peut convenir à un usage local et devenir difficile à partager avec d’autres équipes. Le risque est alors de découvrir trop tard qu’un choix technique ne répond pas à l’usage prévu. Demandez que les contraintes de performance, d’hébergement et d’accès soient explicites dans les décisions d’architecture.

La documentation compte autant que le schéma initial. Les modèles doivent pouvoir être actualisés, y compris à partir d’un système déjà en place. Les référentiels de métadonnées aident notamment à étudier les impacts d’une intégration. Sans cette compréhension de l’existant, une décision peut ignorer les données ou les échanges dont dépendent d’autres utilisateurs.

Exemple fictif : une entreprise souhaite réunir des données issues de plusieurs applications pour un nouvel usage métier. Avant de choisir la plateforme, demandez au Data Architect d’expliciter les formats à rapprocher, les flux nécessaires et les conditions d’accès. Faites préciser les attentes de temps de réponse et les informations encore manquantes. Vous pourrez alors discuter d’options techniques à partir du besoin réel.

• Cartographier les sources et les données existantes pour comprendre leur organisation.
• Recueillir les attentes des utilisateurs afin de traduire les usages en exigences d’architecture.
• Concevoir et actualiser les modèles de données, y compris à partir de systèmes existants.
• Définir les flux, les formats et les choix de stockage adaptés aux contraintes techniques.
• Comparer les options d’hébergement et d’accès au regard des besoins de performance.
• Documenter les choix d’architecture et les métadonnées utiles aux intégrations.
• Intégrer les standards et les exigences de protection avec les spécialistes concernés.
• Expliquer les choix techniques aux équipes métier et aux équipes chargées de leur réalisation.

Les parcours documentés comprennent un diplôme d’ingénieur ou un master en informatique, avec une spécialisation liée aux données. Les systèmes d’information et les statistiques font partie des acquis utiles. Ces voies de formation ne constituent pas une obligation de diplôme pour chaque poste : appréciez ce que le candidat sait concevoir et expliquer.

Une expérience en ingénierie des données ou en architecture logicielle peut préparer au métier. Elle devient particulièrement utile au recrutement lorsque la personne peut décrire des responsabilités exercées : comprendre un système existant, proposer un modèle, comparer des choix de stockage ou documenter une intégration. Le passage par un métier voisin ne démontre pas à lui seul l’autonomie sur une architecture globale.

Pour lire un parcours, distinguez l’exposition à un environnement de la responsabilité d’une décision. Un candidat a pu contribuer à la mise en œuvre d’un flux sans choisir l’architecture d’ensemble. Un autre peut avoir conçu un modèle et accompagné ses évolutions avec les équipes techniques. Ces expériences éclairent des niveaux d’autonomie différents, même si les outils cités sur les CV se ressemblent.

L’Apec mentionne TOGAF et ArchiMate parmi les compléments de formation du profil big data. Considérez-les comme des éléments de parcours à contextualiser, sans en faire des certifications obligatoires ni une preuve automatique de maîtrise. Pour le poste envisagé, privilégiez la cohérence entre les acquis, les décisions déjà assumées et les responsabilités que vous souhaitez confier.

Le socle de l’évaluation GetPro

GetPro structure l’évaluation autour d’une grille de critères prioritaires. Elle distingue ce qui peut être vérifié sur le parcours du candidat de ce qui doit être approfondi en entretien. Chaque critère est associé à une modalité d’évaluation. Les entretiens s’appuient sur des questions ouvertes et des exemples concrets pour apprécier les compétences clés.

Conseils pour évaluer un Data Architect

Les pistes ci-dessous sont proposées pour ce métier et restent à adapter aux responsabilités du poste. Elles ne décrivent pas un protocole spécifique appliqué par GetPro aux Data Architects.

1. Définissez les critères avant les entretiens

Distinguez les décisions que le candidat devra prendre, les recommandations qu’il formulera et les validations confiées à d’autres personnes. Reliez chaque attente à une réalisation observable : modèle, schéma de flux, comparaison technique ou documentation.

Pondérez les critères selon votre environnement. Accordez davantage de place au traitement en flux si votre plateforme l’exige, sans transformer cette compétence en prérequis universel. Définissez aussi le niveau d’autonomie attendu sur les modèles et les intégrations.

2. Examinez une architecture passée

Demandez au candidat de présenter un projet et son rôle exact. Faites préciser les besoins des utilisateurs, les sources disponibles et les contraintes connues au moment des choix. Distinguez ses décisions de celles de l’équipe.

Invitez-le à expliquer comment il a construit ou actualisé le modèle et documenté les flux. Demandez ce qu’il modifierait avec les informations disponibles aujourd’hui. Cherchez un raisonnement compréhensible, avec des hypothèses identifiées et des limites reconnues.

Un récit qui ne décrit que les outils employés appelle un approfondissement. Faites préciser ce que ces outils permettaient de résoudre et quelles autres options avaient été envisagées. Ne déduisez pas l’autonomie d’une simple liste de technologies.

3. Proposez un cas proche du poste

Exemple fictif : proposez de relier plusieurs sources à un nouvel usage métier, avec des contraintes d’accès et de temps de réponse. Demandez un schéma simple, puis une explication des choix.

Observez les questions posées avant la solution. Le candidat cherche-t-il à comprendre les données existantes, les formats et les attentes des utilisateurs ? Demandez-lui d’indiquer les informations manquantes et les hypothèses retenues.

Faites comparer deux options de stockage ou d’hébergement. Introduisez une contrainte budgétaire pour examiner la façon dont il expose les compromis, sans lui attribuer la validation du budget. Demandez quelles conséquences doivent être discutées avec les responsables concernés.

Un signal favorable est la capacité à relier chaque choix à une contrainte explicite. Une proposition très détaillée qui ignore les conditions d’accès ou les usages mérite une relance ciblée.

4. Évaluez la communication et la coopération

Demandez une présentation de la même décision à un ingénieur, puis à un responsable métier. Appréciez la précision de l’explication et la capacité à conserver les conséquences utiles sans multiplier les termes techniques.

Explorez un désaccord sur un modèle ou un standard. Faites préciser les interlocuteurs consultés et la manière de distinguer recommandation et validation. Évaluez le management uniquement si le poste comprend une responsabilité d’encadrement explicite.

5. Faites examiner le cas technique et prenez des références

Si votre entreprise ne dispose pas de l’expertise nécessaire, faites examiner le cas par un architecte expérimenté capable d’évaluer les hypothèses et les compromis. Donnez-lui les mêmes critères qu’aux autres évaluateurs.

Avec l’accord du candidat, utilisez les références pour préciser son rôle dans les projets évoqués, son autonomie et sa coopération avec les équipes. Comparez ces éléments aux exemples présentés, sans attendre d’une référence qu’elle révèle des informations confidentielles.