Architecture des données cible : comment la définir à partir des usages ?

Une architecture des données cible se définit en partant des usages métier, pas des outils. On recense les décisions que la donnée doit éclairer, on les traduit en exigences (fraîcheur, volume, exposition, traçabilité, sécurité), puis on choisit les briques qui y répondent et on planifie la trajectoire en paliers depuis l'existant.

La plupart des organisations disposent d'un schéma d'architecture. Il est souvent affiché dans un document de cadrage, parfois dans une présentation au comité de direction, avec ses sources à gauche, ses outils de restitution à droite et un entrepôt au milieu. Ce schéma décrit des composants. Il dit rarement à quoi ils servent, ni pour qui.

Le problème apparaît quelques mois plus tard. Une direction métier demande un indicateur rafraîchi toutes les heures, une autre veut croiser ses données avec celles d'un partenaire, une équipe de data science réclame un historique que personne n'a conservé. L'architecture ne répond à aucune de ces demandes, parce qu'elle n'a jamais été conçue à partir d'elles.

Une cible d'architecture ne vaut que par les usages qu'elle rend possibles. Un socle techniquement irréprochable qui ne sert aucune décision métier reste un coût, pas un actif. À l'inverse, une architecture modeste mais alignée sur les vrais besoins produit de la valeur dès ses premières semaines.

Définir une architecture des données cible revient donc à répondre à une série de questions dans un ordre précis : quels usages, quelles exigences, quelles briques, quelle trajectoire. Sauter une étape, c'est construire sur une hypothèse que personne n'a vérifiée.

Architecture des données cible : de quoi parle-t-on exactement ?

L'expression « architecture cible » circule dans tous les projets data, avec des sens très différents selon l'interlocuteur. Pour un Data Architect, elle désigne un ensemble de composants et de flux. Pour une direction générale, elle évoque un budget et un calendrier. Pour un métier, elle se résume souvent à la question de savoir quand il aura enfin ses chiffres.

Une cible décrit un état visé, pas une liste d'outils

Une architecture des données cible décrit la manière dont l'organisation veut collecter, stocker, transformer, exposer et gouverner ses données à un horizon donné, généralement deux à trois ans. Elle fixe des principes, des responsabilités et des capacités. Les outils viennent après, comme une réponse possible parmi d'autres.

Cette distinction a une conséquence pratique. Une cible formulée en capacités (« historiser les données de vente sur cinq ans », « exposer les indicateurs commerciaux aux équipes terrain en moins d'une heure ») reste valable même si un éditeur disparaît ou si les prix changent. Une cible formulée en noms de produits devient obsolète au premier changement de contrat.

Cible, trajectoire et existant : trois objets à ne pas confondre

Beaucoup de projets d'architecture échouent parce qu'ils mélangent trois objets distincts dans un même document. Le résultat est un schéma hybride, à moitié réel et à moitié souhaité, dont personne ne sait dire ce qui existe déjà.

Les trois objets se travaillent séparément, avec des niveaux de détail différents :

• L'existant : la cartographie honnête de ce qui tourne aujourd'hui, y compris les fichiers partagés, les extractions manuelles et les traitements que seule une personne sait relancer.
• La cible : l'état visé, décrit en capacités et en principes, sans contrainte de calendrier à ce stade.
• La trajectoire : la succession de paliers qui mène de l'existant à la cible, chacun avec un périmètre, un coût et un usage livré.

Cette séparation n'a rien de formel. Elle permet de discuter de la cible sans être bloqué par l'existant, puis de discuter de la trajectoire sans remettre la cible en cause à chaque contrainte.

À quel horizon fixer une architecture des données cible ?

L'horizon de la cible conditionne son niveau de détail. Une cible à six mois se confond avec un plan de projet. Une cible à cinq ans repose sur des hypothèses d'usages trop incertaines pour guider des choix concrets, et les technologies auront changé plusieurs fois avant son terme.

Un horizon de deux à trois ans offre un compromis raisonnable. Il est assez long pour sortir des contraintes immédiates et penser l'organisation des données autrement. Il reste assez court pour s'appuyer sur des usages que les métiers savent déjà décrire.

Le niveau de précision peut d'ailleurs varier selon les briques. Les principes d'organisation et de gouvernance se fixent pour toute la durée de la cible, alors que le choix des outils se décide palier par palier. Cette approche laisse la place aux évolutions du marché sans remettre en cause la structure d'ensemble.

Pourquoi partir des usages pour définir l'architecture des données ?

Partir des usages paraît évident. Dans les faits, la plupart des architectures sont conçues à partir d'autre chose : une technologie à la mode, une offre d'éditeur, une contrainte de migration ou l'expérience passée de l'équipe technique.

Ce qui se passe quand la cible part de la technologie

Une architecture pensée d'abord autour d'un outil produit des symptômes reconnaissables. Le socle est en place, les flux tournent, mais les métiers continuent à travailler dans leurs tableurs. Les demandes s'accumulent et chacune exige un développement spécifique, parce que rien n'a été prévu pour elle.

Ces situations ont un point commun : la question « pour quoi faire ? » a été posée trop tard, ou pas du tout. Les principaux signaux d'une cible conçue à l'envers sont les suivants :

• Des capacités inutilisées : un traitement en temps réel déployé pour des tableaux de bord consultés une fois par semaine.
• Des besoins non couverts : aucun historique conservé, alors que la prévision des ventes en a besoin.
• Des coûts sans propriétaire : une facture qui augmente sans que personne ne puisse rattacher la dépense à un usage métier.
• Des contournements : des extractions manuelles qui réapparaissent pour combler les trous de la plateforme.

Le sujet des coûts mérite une attention particulière. Une facture qui explose sans explication claire est presque toujours le signe d'une architecture dont les composants ne sont pas rattachés à des usages identifiés.

Ce que les usages déterminent réellement dans une architecture

Un usage métier ne se limite pas à un besoin fonctionnel. Il porte en lui des contraintes techniques précises, que l'architecture doit satisfaire. Quatre dimensions pèsent plus que les autres dans les choix de conception.

La fraîcheur attendue de la donnée

Un pilotage mensuel, un suivi quotidien et une détection de fraude n'ont pas les mêmes besoins. La fraîcheur conditionne le mode de traitement, le coût d'exploitation et la complexité de la maintenance. Le choix entre temps réel, quasi temps réel et batch découle directement de cette exigence, et non d'une préférence technique.

Le volume et la fréquence d'accès

Quelques dizaines d'utilisateurs qui consultent un tableau de bord chaque matin ne sollicitent pas une architecture comme un service qui interroge la donnée des milliers de fois par heure. Le volume de données stockées compte moins, dans la plupart des cas, que le nombre et la nature des requêtes.

Le public et le mode d'exposition

Un analyste qui écrit ses propres requêtes, un manager qui consulte un tableau de bord et une application qui consomme la donnée par interface programmatique attendent des formats différents. L'exposition est souvent la brique la plus négligée dans une cible, alors que c'est elle que les utilisateurs voient.

Le niveau de confiance exigé

Une donnée utilisée pour une publication réglementaire ou un calcul de rémunération exige une traçabilité complète, de la source jusqu'au chiffre affiché. Une donnée d'exploration peut tolérer des approximations. Le niveau de confiance attendu détermine la profondeur du contrôle qualité et du data lineage à prévoir.

Anticiper les usages futurs sans surdimensionner la cible

Les usages d'aujourd'hui ne suffisent pas à définir une cible à trois ans. De nouveaux besoins apparaîtront : une direction qui découvre l'intérêt de la prévision, un projet d'IA générative, un partage de données avec des partenaires. La cible doit pouvoir les accueillir.

Anticiper ne signifie pas construire à l'avance. La bonne pratique consiste à distinguer ce que la cible doit permettre et ce qu'elle doit livrer. Un usage futur probable justifie un choix qui ne ferme pas la porte, par exemple conserver les données brutes plutôt que de ne garder que des agrégats. Il ne justifie pas de déployer dès maintenant les composants qui le serviront.

Une architecture ouverte aux usages futurs coûte à peine plus qu'une architecture fermée, alors qu'une architecture construite pour des usages hypothétiques coûte beaucoup plus cher. Le critère de décision reste le même : chaque composant déployé doit servir un usage identifié.

👉 À lire aussi : Quels usages une plateforme data doit réellement supporter ?

Comment recenser les usages qui structurent l'architecture cible ?

Le recensement des usages est l'étape la plus sous-estimée d'un projet d'architecture. Elle demande du temps auprès des métiers, une grille de lecture commune et la capacité à distinguer une vraie demande d'un souhait formulé sans réflexion.

Interroger les métiers sur leurs décisions, pas sur les outils

Demander à un responsable commercial quels outils il souhaite produit une liste de produits connus. Lui demander quelles décisions il prend chaque semaine, avec quelles informations et dans quel délai, produit un besoin exploitable.

Les entretiens les plus utiles tournent autour de quelques questions simples, posées à chaque direction :

• Quelles décisions récurrentes s'appuient sur la donnée ? Par exemple ajuster un prix, relancer un client, réapprovisionner un entrepôt.
• À quel rythme ces décisions sont-elles prises ? Le rythme de la décision fixe la fraîcheur nécessaire.
• Quelles données manquent aujourd'hui pour décider correctement ? Cette question révèle les sources à intégrer en priorité.
• Que se passe-t-il quand la donnée est fausse ou en retard ? La réponse mesure le niveau de confiance exigé.
• Qui consomme le résultat, et sous quelle forme ? La réponse oriente le mode d'exposition.

Ces entretiens gagnent à être menés au plus près des opérationnels. Un directeur décrit les décisions stratégiques, mais ce sont souvent ses équipes qui connaissent les retraitements manuels, les fichiers intermédiaires et les délais réels de mise à disposition.

Associer les bonnes personnes au recensement des usages

Un recensement mené uniquement par l'équipe data reste incomplet. Les usages les plus structurants se trouvent souvent à la frontière entre deux directions, là où personne ne se sent pleinement responsable de la donnée partagée.

Trois profils doivent être associés dès le départ :

• Les responsables métier : ils décrivent les décisions, fixent les priorités et arbitrent entre usages concurrents au sein de leur direction.
• Les utilisateurs opérationnels : ils connaissent les contournements actuels, les données manquantes et les délais réellement subis.
• Les équipes techniques qui exploitent l'existant : elles savent ce que chaque source permet, avec quelle qualité et à quel coût d'extraction.

Un usage décrit sans les personnes qui l'exercent au quotidien est presque toujours sous-estimé. Les contraintes réelles (un fichier reçu en retard chaque lundi, un référentiel mis à jour à la main) n'apparaissent qu'au contact des opérationnels.

Qualifier chaque usage avec une grille commune

Une fois recensés, les usages doivent être décrits de la même manière pour pouvoir être comparés. Sans grille commune, chaque direction présente ses besoins avec son propre vocabulaire, et l'arbitrage devient impossible.

La grille tient sur une ligne par usage. Elle croise la description métier avec les exigences techniques qui en découlent, et elle désigne un responsable côté métier, souvent le futur Data Owner du périmètre concerné.

Distinguer usages structurants et usages ponctuels

Tous les usages n'ont pas le même poids dans la définition de la cible. Un usage structurant mobilise des données partagées par plusieurs directions, revient régulièrement et engage des décisions importantes. Un usage ponctuel répond à une question isolée, souvent traitée une fois.

L'architecture cible se dimensionne sur les usages structurants. Les usages ponctuels doivent rester possibles, mais ils ne justifient pas à eux seuls un composant dédié. Cette distinction évite de bâtir une plateforme qui cherche à tout couvrir et finit par ne rien couvrir correctement.

Traduire les usages en exigences d'architecture des données

Entre la description d'un usage et le choix d'un composant, une étape manque souvent : la formulation explicite des exigences. C'est pourtant elle qui permet de justifier chaque brique de la cible, et de la remettre en cause quand les usages évoluent.

De l'usage à l'exigence : une étape souvent sautée

Un usage dit ce que le métier veut faire. Une exigence dit ce que l'architecture doit garantir pour le rendre possible. « Suivre les ventes par magasin chaque matin » est un usage. « Données de vente disponibles avant 7 heures, au grain du ticket, conservées trois ans » est une exigence.

La différence paraît subtile. Elle change tout au moment du choix technique, parce qu'une exigence chiffrée se vérifie, alors qu'un usage décrit en langage courant laisse place à toutes les interprétations.

Les cinq exigences à formuler explicitement

L'expérience montre que cinq familles d'exigences couvrent l'essentiel des choix d'architecture. Elles se formulent pour chaque usage structurant, puis se consolident à l'échelle de la cible :

• La fraîcheur : le délai maximal acceptable entre l'événement dans la source et sa disponibilité pour l'usage.
• La volumétrie et la profondeur d'historique : le volume à traiter, sa croissance prévisible et la durée de conservation nécessaire.
• L'exposition : les publics, les formats (tableau de bord, table d'analyse, interface programmatique) et les volumes de requêtes.
• La traçabilité : le niveau de documentation attendu sur l'origine et les transformations de chaque donnée.
• La sécurité et la conformité : les données sensibles concernées, les droits d'accès et les obligations réglementaires applicables.

Ces exigences alimentent aussi les arbitrages économiques. Concilier performance, coûts et gouvernance suppose de savoir précisément quel usage justifie quel niveau de service.

Arbitrer quand deux usages réclament des exigences contradictoires

Deux usages peuvent tirer l'architecture dans des directions opposées. Le contrôle de gestion veut des chiffres figés et réconciliés en fin de mois, les équipes commerciales veulent des chiffres frais chaque matin, même provisoires.

La réponse consiste rarement à choisir l'un contre l'autre. Elle passe plus souvent par une architecture en couches, où une même donnée source alimente une vue rapide et une vue consolidée, avec des règles explicites sur ce que chacune garantit. La question de savoir s'il faut une architecture différente pour la BI, l'IA et le self-service relève du même raisonnement : un socle commun, des couches d'exposition adaptées.

Hiérarchiser les exigences quand le budget ne suit pas

Toutes les exigences ne peuvent pas être satisfaites au même niveau, surtout dans les premiers paliers. Un arbitrage est nécessaire, et il doit se faire à partir des usages plutôt qu'à partir des préférences techniques.

Un critère simple aide à trancher : le coût d'une donnée en retard ou erronée pour l'usage concerné. Une erreur sur un reporting réglementaire expose l'entreprise à une sanction, un retard de quelques heures sur une analyse exploratoire ne change aucune décision. L'exigence la plus forte se réserve aux usages pour lesquels un défaut coûte réellement cher.

Cette hiérarchie a un effet direct sur le dimensionnement. Elle évite de traiter toute la plateforme au niveau de service requis par un seul usage critique, ce qui reste l'une des causes les plus fréquentes de surcoût.

Quels composants pour une architecture des données cible ?

Une fois les exigences posées, le choix des composants devient un exercice de correspondance. Chaque brique doit pouvoir être reliée à au moins une exigence, elle-même reliée à au moins un usage structurant. Une brique qui ne se rattache à rien est un candidat à la suppression.

Les briques communes à toute architecture des données cible

Quelle que soit la taille de l'organisation, une architecture cible s'organise autour de cinq fonctions. Leur poids relatif varie selon les usages, mais aucune ne peut être ignorée sans conséquence :

• L'ingestion : la collecte des données depuis les sources (applications métier, fichiers, partenaires, objets connectés), avec une fréquence adaptée à chaque flux.
• Le stockage : la conservation des données brutes et préparées, au format et à la durée exigés par les usages.
• La transformation : le nettoyage, la mise en cohérence et le calcul des indicateurs, idéalement versionnés et testés.
• L'exposition : la mise à disposition auprès des publics identifiés, sous la forme qui leur convient.
• La gouvernance et les métadonnées : la documentation, les règles d'accès, le contrôle qualité et la traçabilité qui rendent l'ensemble fiable.

Ces cinq fonctions forment ce que l'on appelle couramment une plateforme data. La gestion des métadonnées est souvent reportée à plus tard, alors qu'elle conditionne la capacité à faire évoluer la cible sans perdre la maîtrise de ce qui existe.

Choisir le modèle de stockage selon les usages

Le choix entre entrepôt de données, lac de données et lakehouse alimente de nombreux débats. Ramené aux usages, il devient plus simple. Des usages majoritairement analytiques, sur des données structurées et bien identifiées, orientent vers un entrepôt. Des usages qui mêlent données structurées, documents et données volumineuses pour la data science orientent vers un lac ou un lakehouse.

La bonne question n'est pas de savoir quel modèle est le plus moderne, mais lequel couvre les usages structurants avec le moins de complexité. Une organisation sans projet de data science à deux ans n'a aucune raison de dimensionner sa cible pour cet usage.

👉 À lire aussi : Data Lake vs Data Warehouse vs Data Lakehouse : un comparatif pour les décideurs data

Traiter l'exposition comme une brique à part entière

L'exposition est la partie de l'architecture que les utilisateurs voient. C'est pourtant celle qui reçoit le moins d'attention dans la plupart des cibles, souvent réduite à un outil de tableaux de bord ajouté en bout de chaîne.

Une exposition bien conçue distingue plusieurs couches selon les publics. Les analystes ont besoin de tables documentées et stables, sur lesquelles ils peuvent écrire leurs propres requêtes. Les managers ont besoin d'indicateurs certifiés, présentés sous une forme qui ne laisse pas de place à l'interprétation. Les applications métier ont besoin d'un accès programmatique, avec des temps de réponse garantis.

Une même donnée peut être exposée de trois manières différentes, à condition que ces trois expositions partagent les mêmes définitions. C'est à cette condition que l'architecture évite les chiffres contradictoires d'une direction à l'autre, problème que l'ajout de nouveaux outils ne règle jamais.

Intégrer la gouvernance dès la conception de la cible

La gouvernance est souvent traitée comme un chantier parallèle, lancé une fois la plateforme en place. Cette séparation coûte cher : les responsabilités sur la donnée, les règles d'accès et le contrôle qualité s'intègrent beaucoup plus facilement au moment de la conception qu'après coup.

Concrètement, la cible doit préciser pour chaque grand domaine de données qui en est responsable côté métier, qui l'exploite côté technique, quelles règles de qualité s'appliquent et comment les accès sont accordés. Ces éléments n'alourdissent pas l'architecture. Ils conditionnent sa capacité à grandir sans perdre la confiance des utilisateurs.

Centralisé ou distribué : une question d'organisation autant que d'architecture

Le dernier choix structurant porte sur la répartition des responsabilités. Une architecture centralisée confie la plateforme et les traitements à une équipe unique. Une architecture distribuée confie à chaque domaine métier la production de ses propres données, sur un socle commun.

Ce choix dépend moins de la technologie que de la maturité des équipes et de la taille de l'organisation. Les impacts réels de la centralisation ou de la distribution se mesurent d'abord dans l'organisation du travail, ensuite seulement dans les schémas techniques.

Construire la trajectoire vers l'architecture des données cible

Une cible sans trajectoire reste un document de réflexion. La trajectoire transforme l'intention en programme de travail, avec des étapes, des coûts et des résultats attendus à chaque palier.

Partir de l'existant sans s'y enfermer

L'existant impose des contraintes réelles : des contrats en cours, des compétences disponibles, des traitements critiques qui ne peuvent pas s'arrêter. Il serait irréaliste de les ignorer. Il serait tout aussi dommageable de laisser ces contraintes redéfinir la cible elle-même.

La méthode consiste à confronter la cible à l'existant composant par composant. Pour chacun, trois issues sont possibles : le conserver tel quel, le faire évoluer ou le remplacer. Ce tri conditionne l'ampleur réelle du chantier, et il évite de lancer une migration de données plus large que nécessaire.

Découper la trajectoire en paliers qui livrent chacun un usage

Un palier de trajectoire ne se mesure pas au nombre de composants installés, mais à l'usage qu'il rend possible. Chaque étape doit livrer au moins un usage structurant de bout en bout, de la source jusqu'à l'utilisateur final.

Ce découpage présente trois avantages :

• Une valeur visible rapidement : les métiers constatent un résultat concret dès le premier palier, ce qui entretient leur engagement.
• Une validation progressive des choix : chaque palier confronte les hypothèses d'architecture à un usage réel, avant d'engager la suite.
• Une réduction de l'ancien socle au fil de l'eau : les usages migrés libèrent progressivement les composants historiques, ce qui limite la période de double exploitation.

Chiffrer la trajectoire de façon réaliste

Le chiffrage d'une trajectoire d'architecture se limite trop souvent aux licences et à l'infrastructure. Ces postes sont visibles et faciles à estimer. Ils ne représentent pourtant qu'une partie du coût réel.

Un chiffrage complet intègre plusieurs postes, à évaluer pour chaque palier :

• La construction : conception, développement des flux et des transformations, tests et recette avec les métiers.
• La double exploitation : la période pendant laquelle l'ancien et le nouveau socle tournent en parallèle.
• L'exploitation courante : la surveillance, la maintenance et la correction des incidents, sur la durée.
• L'accompagnement des utilisateurs : la formation, la documentation et le support au démarrage de chaque usage.

La double exploitation est le poste le plus souvent oublié, et celui qui dérape le plus vite quand les paliers s'allongent. Retirer un composant ancien à chaque palier reste le moyen le plus sûr de la contenir.

Prévoir les points de révision de la cible

Une architecture des données cible n'est pas figée. Les usages évoluent, de nouvelles sources apparaissent, des priorités métier changent. Une cible définie en début de programme et jamais révisée finit par décrire une organisation qui n'existe plus.

La révision se planifie à chaque fin de palier. Elle porte sur trois points : les usages structurants sont-ils toujours les mêmes, les exigences ont-elles bougé, la suite de la trajectoire reste-t-elle pertinente ? Ces révisions s'appuient sur des décisions documentées, faute de quoi chaque revue rouvre des débats déjà tranchés. Les principes pour faire des choix d'architecture qui tiennent dans le temps s'appliquent pleinement à cette étape.

Qui doit porter la définition de l'architecture des données cible ?

Une architecture des données cible engage l'organisation sur plusieurs années et sur des budgets significatifs. Sa définition ne peut pas reposer sur une seule fonction, ni être confiée entièrement à un prestataire ou à un éditeur.

Une responsabilité partagée entre la direction data, les métiers et la DSI

La définition de la cible mobilise plusieurs acteurs, chacun avec un rôle distinct. La confusion des rôles produit soit une cible trop technique, soit une cible trop vague pour être construite.

La répartition qui fonctionne le mieux s'organise ainsi :

• La direction data (ou le Chief Data Officer) : elle porte la démarche, arbitre entre les directions et garantit le lien avec la stratégie de l'entreprise.
• L'architecte data : il traduit les usages en exigences puis en composants, et veille à la cohérence technique de l'ensemble.
• Les responsables métier : ils décrivent les usages, fixent les priorités et valident que la cible répond à leurs décisions.
• La DSI : elle apporte les contraintes d'infrastructure, de sécurité et d'exploitation, et prépare l'intégration avec le reste du système d'information.

Le partage entre ce qui relève de la technique et ce qui relève de l'organisation reste un point de friction fréquent. Une décision d'architecture qui modifie les responsabilités d'une direction métier n'est pas une décision technique, même si elle s'exprime dans un schéma technique.

Une instance de validation qui se réunit à chaque palier

La cible se valide une première fois au lancement, puis se réexamine à chaque fin de palier. Une instance restreinte, réunissant la direction data, deux ou trois responsables métier et la DSI, suffit dans la plupart des cas.

Son rôle consiste à vérifier que les usages livrés correspondent à ce qui était prévu, à arbitrer les demandes nouvelles et à valider le palier suivant. Une instance trop large se transforme en comité d'information. Une instance absente laisse l'équipe technique décider seule de sujets qui engagent les métiers.

Les erreurs qui fragilisent une architecture des données cible

Certaines erreurs reviennent d'un projet à l'autre, quelle que soit la taille de l'organisation. Elles ont rarement une origine technique. Elles viennent presque toujours d'un défaut de méthode au moment de la définition de la cible :

• Concevoir pour tous les usages imaginables : une cible qui prévoit l'IA, le temps réel et le partage avec des partenaires sans usage identifié pour chacun devient coûteuse et lente à livrer. La question d'une architecture spécifique pour l'IA illustre bien ce risque.
• Oublier l'exploitation : chaque composant ajouté doit être surveillé, mis à jour et documenté. Une cible qui ne chiffre pas l'effort d'exploitation sous-estime son coût réel.
• Négliger la gouvernance dès la conception : une plateforme qui grossit sans règles de responsabilité devient trop complexe pour être gouvernée, et la remise en ordre coûte bien plus cher que la prévention.
• Valider la cible sans les métiers : une cible validée uniquement par la direction technique risque de répondre à des besoins que personne n'a exprimés.
• Confondre cible et projet d'outillage : remplacer un outil par un autre sans revoir les usages reproduit les mêmes difficultés sur une technologie plus récente.

Architecture des données cible : les décisions à trancher avant de valider

Une cible prête à être validée répond sans ambiguïté à un nombre limité de questions. Si l'une d'elles reste ouverte, la cible n'est pas mûre, même si le schéma paraît complet.

La qualité d'une architecture des données cible ne se juge pas à la sophistication de son schéma. Elle se juge à la facilité avec laquelle chaque composant peut être relié à une décision métier qu'il permet de prendre. Une cible qui passe ce test résiste aux changements d'outils, aux évolutions d'équipe et aux arbitrages budgétaires.

Le travail le plus utile se fait donc en amont des choix techniques : recenser les usages, les qualifier, formuler les exigences. Le reste en découle, avec beaucoup moins de débats.