Une entreprise peut posséder les meilleurs outils cloud et produire malgré tout des données incohérentes. Construire une architecture de données moderne exige de relier ingestion, stockage, traitement, gouvernance et usages métiers. Ce guide explique comment choisir les bonnes briques, maîtriser les coûts et éviter une stack impossible à maintenir.
Une entreprise peut disposer d’un Data Lake, d’un entrepôt cloud et de tableaux de bord flambant neufs, tout en publiant trois chiffres d’affaires différents. Le problème ne vient pas forcément de ses logiciels : il vient des connexions, des responsabilités et des règles qui manquent entre eux.
Concevoir une architecture de données moderne, ce n’est donc pas acheter toute la panoplie du Data Engineering. C’est organiser le trajet de l’information, de sa création jusqu’à son utilisation, avec des garanties sur sa qualité, sa sécurité, sa fraîcheur et son coût. Voici comment construire cette stack sans multiplier les outils inutiles.
Une stack moderne n’est pas une collection de logos
Le terme stack data désigne l’ensemble des composants nécessaires pour collecter, transporter, stocker, transformer, documenter et exploiter les données d’une organisation. L’architecture décrit leurs relations : où circulent les informations, qui les contrôle et ce qui se passe lorsqu’un composant tombe en panne.
La distinction est décisive. Installer Kafka ne rend pas automatiquement un système « temps réel ». Déposer des fichiers dans S3 ne suffit pas à créer un Data Lake exploitable. Ajouter un outil de visualisation ne garantit pas que deux équipes calculeront un indicateur de la même manière.
Le Data Management constitue le cadre général de cette maîtrise. L’architecture en est la traduction technique et organisationnelle. Elle sert aussi bien à une PME qui consolide cinq applications qu’à un groupe international traitant des flux industriels et des données issues de dizaines de pays.
Avant de choisir les fournisseurs, il faut répondre à cinq questions : quelles décisions les données doivent-elles alimenter ? Quelle fraîcheur est réellement nécessaire ? Quels volumes et quelles variations de charge faut-il absorber ? Qui peut accéder à quoi ? Quel coût total est acceptable, exploitation humaine comprise ?
Cette démarche rejoint les principes du Data Analytics Lens d’AWS, qui évalue une architecture selon sa fiabilité, sa sécurité, ses performances, ses opérations, ses coûts et sa durabilité. Le point essentiel : une architecture se juge sur les contraintes qu’elle satisfait, pas sur le nombre de services déployés.
Sept briques, un seul trajet pour la donnée
Une architecture analytique classique peut se lire de gauche à droite. Les applications métier produisent des événements et des enregistrements. Des mécanismes d’ingestion les acheminent vers une zone de stockage. Des traitements les rendent cohérents. Les résultats sont ensuite exposés aux analystes, aux logiciels, aux tableaux de bord ou aux modèles d’intelligence artificielle.
Sources → Ingestion → Stockage → Transformation et calcul → Exposition → Usages. Deux fonctions traversent toute cette chaîne : l’orchestration et l’observabilité d’une part, la gouvernance et la sécurité d’autre part.
| Brique | Question à résoudre | Exemples de solutions |
|---|---|---|
| Sources | D’où viennent les données ? | ERP, CRM, PostgreSQL, API, IoT, logs |
| Ingestion | Comment les récupérer sans perte inutile ? | Connecteurs, CDC, Kafka, services managés |
| Stockage | Où conserver le brut et le préparé ? | S3, Azure Data Lake Storage, Google Cloud Storage, entrepôt |
| Transformation et calcul | Comment corriger, joindre et agréger ? | SQL, dbt, Spark, Flink |
| Orchestration et contrôle | Comment déclencher, tester et surveiller ? | Airflow, Dagster, tests de données, alertes |
| Gouvernance et sécurité | Qui possède, comprend et consulte la donnée ? | Catalogue, IAM, classification, lineage, audit |
| Exposition | Comment la rendre utile aux métiers ? | BI, SQL, API, produits de données, applications IA |
Cette grille est volontairement indépendante des marques. Une plateforme intégrée peut couvrir plusieurs briques ; une architecture modulaire peut recourir à plusieurs prestataires. Il n’est pas nécessaire d’avoir sept abonnements. En revanche, les sept responsabilités doivent être attribuées, même lorsque certaines sont assurées par le même service.
Batch, streaming et CDC : trois besoins différents
Le batch traite des données par lots, par exemple chaque nuit. C’est souvent le meilleur choix pour une comptabilité quotidienne ou des rapports commerciaux. Le streaming traite des événements au fil de leur arrivée, ce qui devient utile pour détecter une fraude ou suivre un équipement critique.
La Change Data Capture (CDC) suit les modifications d’une base opérationnelle afin de les répliquer sans réexporter toute la table. Elle peut alimenter un pipeline quasi temps réel, mais ne remplace ni les règles métier ni le traitement des erreurs. Un projet qui n’a besoin que d’un indicateur actualisé chaque matin ne gagne rien à financer une infrastructure de flux permanente.
Warehouse, Lake et Lakehouse : choisir le terrain
Le Data Warehouse organise des données préparées pour l’analyse et les requêtes SQL. Le Data Lake accueille des formats plus variés, souvent sur du stockage objet. Le Lakehouse associe le stockage de fichiers à des mécanismes de gestion des tables, de transactions et de gouvernance. Ces modèles ne s’excluent pas : certaines entreprises utilisent un lac pour les données historiques et un entrepôt pour les indicateurs opérationnels.
Les formats de table ouverts comme Apache Iceberg, Delta Lake ou Hudi améliorent notamment la gestion de données conservées sous forme de fichiers. Mais l’interopérabilité réelle dépend aussi des catalogues, des moteurs et des fonctions supportées. Notre enquête sur la bataille entre Iceberg, Delta Lake et Hudi montre pourquoi choisir un format ne suffit pas à supprimer toutes les dépendances.
Bronze, Silver, Gold : utile, mais pas magique
L’architecture dite médaillon classe les données en trois niveaux. Bronze conserve les données reçues, avec leur contexte d’origine. Silver applique les validations, dédoublonnages et règles de cohérence. Gold publie les jeux de données prêts à servir un besoin métier : ventes quotidiennes, marge par produit ou stock disponible.
Databricks présente ce modèle comme une bonne pratique recommandée, et non une obligation. Microsoft documente également des architectures Lakehouse dans Fabric, où ingestion, stockage et consommation peuvent être réunis dans une plateforme intégrée.
L’intérêt du médaillon est de séparer les responsabilités. Si une règle de calcul évolue, l’équipe peut retraiter des données brutes conservées dans la zone Bronze. Si une source introduit soudain des identifiants manquants, le problème peut être isolé avant de contaminer les tableaux de bord Gold. Cela suppose toutefois de prévoir les politiques de conservation, la reproductibilité des transformations et le contrôle des accès à chaque niveau.
Le risque inverse est la duplication. Copier systématiquement tous les fichiers dans trois couches, puis dans un autre entrepôt, peut gonfler le stockage, les transferts et la maintenance. Les tables virtuelles, les vues, les transformations incrémentales et les politiques d’expiration permettent parfois de limiter ces copies. Bronze, Silver et Gold sont des niveaux de confiance, pas une obligation de tripler les données.
Cette conférence diffusée par Databricks est intéressante précisément parce qu’elle questionne la rigidité de ces couches et la manière de les adapter aux usages réels.
La bonne architecture dépend du métier
Prenons un distributeur fictif qui vend en magasin et sur Internet. Ses commandes sont enregistrées dans une base transactionnelle, ses produits dans un ERP, sa relation client dans un CRM et ses visites dans un outil d’analyse web. L’objectif du projet n’est pas de « faire du Big Data », mais de produire un indicateur fiable de marge par catégorie et de détecter rapidement les ruptures de stock.
Premier arbitrage : la marge peut être recalculée une fois par nuit si l’équipe financière ne la consulte que le lendemain. En revanche, l’alerte sur les stocks peut nécessiter des mises à jour beaucoup plus fréquentes. Les deux besoins n’imposent pas le même rythme de traitement. Ils peuvent partager le catalogue, la gestion des identités et certaines données de référence sans partager tous les moteurs.
Deuxième arbitrage : le chiffre d’affaires doit suivre une définition commune. Faut-il inclure les commandes annulées, les retours, les taxes, les frais de livraison ? Sans décision métier, le meilleur moteur SQL du monde produira simplement des réponses contradictoires plus vite.
Troisième arbitrage : les changements dans la source doivent être maîtrisés. Si l’ERP renomme une colonne ou modifie les codes de statut, les traitements peuvent échouer ou, plus dangereusement, continuer à calculer un résultat erroné. Les tests intégrés aux pipelines sont donc aussi importants que le choix du stockage. La documentation de dbt décrit par exemple des vérifications de valeurs manquantes, d’unicité et d’intégrité référentielle.
Dans cette architecture cible, une équipe data légère peut commencer avec une ingestion planifiée, un entrepôt managé, des transformations SQL versionnées et un tableau de bord. Elle ajoutera un bus d’événements seulement si les alertes de stock ou d’autres usages justifient les contraintes opérationnelles du temps réel.
À l’inverse, une banque surveillant des transactions suspectes ou une usine détectant un défaut en continu pourra privilégier des flux persistants, un traitement à faible latence, des mécanismes de rejeu et des engagements de disponibilité plus exigeants. L’architecture n’est pas « plus moderne » parce qu’elle est plus complexe. Elle doit être proportionnée aux conséquences d’un retard ou d’une erreur.
Le retour d’expérience d’Atlassian, présenté sur la chaîne officielle de Databricks, illustre les arbitrages d’une architecture d’entreprise : séparation des environnements, gouvernance du catalogue et industrialisation des pipelines. Il s’agit d’un cas concret, pas d’un modèle universel à reproduire.
Le vrai coût se cache entre les services
Les comparaisons commerciales mettent souvent en avant le prix du stockage au gigaoctet ou celui d’une heure de calcul. Mais une stack data génère des coûts supplémentaires : requêtes répétées, ingestion et synchronisation, transferts réseau, rétention de plusieurs copies, catalogue, supervision, licences et interventions humaines.
Un exemple purement illustratif suffit à montrer l’écart. Un pipeline ingère 5 Go de nouvelles données par jour, soit environ 150 Go sur trente jours. Si des traitements relisent chaque jour 1 To d’historique, le volume lu atteint environ 30 To dans le même mois. Ce n’est pas une estimation de facture : selon les plateformes, le calcul peut être facturé à la capacité, au temps d’exécution, aux octets analysés ou selon une combinaison de métriques. Mais l’exemple montre pourquoi le volume ingéré ne permet pas, à lui seul, de prévoir le coût de l’analytique.
Le cadre d’allocation FinOps recommande de rattacher les dépenses aux équipes, projets ou produits grâce à des comptes, des tags et d’autres métadonnées. Concrètement, une plateforme data devrait pouvoir répondre à la question : combien coûte l’indicateur produit, du stockage des données sources jusqu’à son rafraîchissement ?
Pour éviter les mauvaises surprises, il faut mesurer le coût d’une exécution complète, suivre la croissance des tables, fixer des budgets et déclencher des alertes. Les traitements incrémentaux, la limitation des colonnes lues, la bonne organisation des fichiers et l’arrêt des ressources inutilisées sont souvent plus rentables que l’ajout d’une nouvelle couche logicielle. Voir également notre dossier consacré au pilotage FinOps des dépenses cloud.
Il existe enfin un coût de sortie : réécrire des pipelines liés à des fonctions propriétaires, déplacer des historiques, retrouver les règles d’accès et reformer les équipes. Choisir un format ouvert peut réduire certains obstacles, mais ne rend pas automatiquement les pipelines, les catalogues ni les contrats portables.
Gouvernance et sécurité ne viennent pas à la fin
La gouvernance commence bien avant le premier tableau de bord. Chaque jeu de données critique doit avoir un propriétaire, une définition, une classification, des règles d’accès, une fréquence de mise à jour et une durée de conservation. Un Data Catalog facilite leur découverte. Le Data Lineage, ou traçabilité, indique d’où viennent les données et quelles transformations les ont produites.
Cette traçabilité devient indispensable lorsqu’un indicateur est contesté. Le standard ouvert OpenLineage définit notamment des métadonnées décrivant les jeux de données, les tâches et leurs exécutions, pour mieux relier les outils d’un pipeline. Il ne garantit pas, à lui seul, la qualité des calculs : il aide à comprendre leur provenance et leur dépendance.
En matière de sécurité, les contrôles fondamentaux restent le principe du moindre privilège, la séparation des environnements, le chiffrement, la gestion des clés, la journalisation et les procédures de restauration testées. Les jeux de données contenant des informations personnelles exigent aussi des règles de minimisation, de durée de conservation et d’accès conformes au RGPD.
Le guide de sécurité de la CNIL insiste sur la protection des données dès la conception et sur l’encadrement du cloud et de la sous-traitance. Héberger une base dans une région européenne ne règle pas, à lui seul, toutes les questions de souveraineté : il faut également examiner les contrats, les accès possibles, les sous-traitants, les transferts et la capacité réelle à changer de fournisseur.
L’intelligence artificielle rend ces choix plus sensibles. Alimenter un assistant interne avec des documents d’entreprise implique de maîtriser les autorisations au moment de la recherche, la provenance des extraits, leur fraîcheur et la suppression de données devenues interdites d’usage. Une base vectorielle peut faciliter la recherche sémantique, mais elle ne remplace ni le catalogue, ni les règles d’accès, ni la source de vérité. Ajouter de l’IA sur une architecture désordonnée peut simplement rendre la circulation de données incorrectes ou confidentielles plus rapide.
Du schéma sur papier à la production : la méthode
Un déploiement sérieux procède par paliers. Le premier livrable ne devrait pas être une liste de cinquante technologies, mais une carte des sources, des consommateurs, des flux critiques et des contraintes d’exploitation. Le second doit être un produit de données limité, utilisé par un vrai métier et mesuré en production.
- Choisir une décision métier. Par exemple : calculer une marge quotidienne fiable ou détecter une rupture de stock avant réassort.
- Cartographier les sources et les droits. Recenser formats, propriétaires, sensibilité, volumétrie et qualité constatée. Identifier les dépendances externes.
- Définir un contrat de service. Préciser la fraîcheur attendue, les contrôles de qualité, le délai de reprise, les utilisateurs autorisés et le budget.
- Construire le plus petit flux de bout en bout. Source, ingestion, transformation testée, données documentées, consommation réelle. Éviter les composants sans besoin démontré.
- Tester les incidents. Fichier en retard, doublon, changement de schéma, indisponibilité d’API, restauration après effacement, augmentation soudaine du volume.
- Mesurer et étendre. Suivre coût par produit, délai de rafraîchissement, échecs, qualité et satisfaction des utilisateurs avant d’intégrer d’autres domaines.
Les indicateurs de succès ne doivent pas se limiter au volume stocké. Il est plus utile de suivre le pourcentage de rafraîchissements dans le délai prévu, la proportion d’enregistrements rejetés, le temps de résolution d’un incident, le nombre de jeux de données documentés et le coût d’un rapport réellement consulté.
À mesure que plusieurs équipes produisent leurs propres données, la question de leur responsabilité devient centrale. Le Data Mesh propose de confier des produits de données aux domaines métier dans un cadre partagé. La documentation de Google Cloud rappelle que cela exige une plateforme commune et des standards de gouvernance : distribuer la responsabilité sans ces fondations revient à multiplier les silos.
Le choix entre plateformes intégrées et outils assemblés doit alors être documenté. Une offre intégrée simplifie parfois les opérations, mais renforce certaines dépendances. Une approche modulaire donne davantage de latitude, au prix d’une intégration et d’une supervision plus importantes. Un Data Mesh est avant tout un modèle de responsabilité ; un Lakehouse, un modèle de plateforme. Ils peuvent donc coexister.
Conclusion : la meilleure stack est celle que l’on comprend
Pour concevoir une architecture de données moderne, partez d’un usage, dessinez le trajet complet de ses informations, affectez un responsable à chaque étape, puis choisissez les outils les plus simples capables de tenir les engagements. Le cloud, les Lakehouses, les formats ouverts et les services managés offrent de nombreuses possibilités. Aucun ne dispense de définir les indicateurs, de tester les flux et de contrôler les accès.
La véritable modernité d’une stack se mesure à sa capacité à produire des données fiables, traçables et utiles sans coût ni dépendance incontrôlables. Avec la généralisation des assistants IA et des systèmes automatisés, cette discipline devient encore plus importante : une erreur autrefois visible dans un tableau de bord peut désormais être réutilisée par plusieurs applications sans intervention humaine.
FAQ
Qu’est-ce qu’une architecture de données moderne ?
C’est l’organisation des systèmes qui collectent, transportent, stockent, transforment, protègent et diffusent les données d’une entreprise. Elle peut s’appuyer sur le cloud, des logiciels installés en interne ou une combinaison des deux. Ce qui la rend moderne n’est pas la présence obligatoire d’un outil précis, mais sa capacité à adapter les ressources aux besoins, à automatiser les contrôles et à rendre les données utilisables avec une provenance claire. Une bonne architecture prévoit également les incidents, les coûts et l’évolution des usages.
Quelles sont les principales briques d’une stack data ?
On distingue généralement les sources, l’ingestion, le stockage, les moteurs de transformation et de calcul, l’orchestration, la gouvernance et les outils de consommation comme la BI ou les API. La sécurité, l’observabilité et les métadonnées traversent plusieurs de ces briques. Certaines plateformes regroupent ces fonctions dans une offre intégrée, tandis que d’autres architectures combinent des produits spécialisés. L’objectif n’est pas de multiplier les logiciels, mais de s’assurer que chaque fonction indispensable possède un responsable et des contrôles adaptés.
Faut-il choisir un Data Lake, un Warehouse ou un Lakehouse ?
Le choix dépend des types de données, des requêtes, des compétences et du besoin de flexibilité. Un Warehouse managé peut suffire à une entreprise dont les usages sont essentiellement SQL et reporting. Un Data Lake est pertinent lorsque les formats sont variés et que l’on souhaite préserver de grands ensembles de données. Le Lakehouse cherche à combiner stockage de fichiers et gestion avancée des tables. Beaucoup d’organisations conservent plusieurs systèmes complémentaires. Il faut d’abord comparer les besoins réels, puis le coût et l’effort d’exploitation.
Une PME a-t-elle besoin de Kafka et de Spark ?
Pas nécessairement. Kafka facilite la circulation et la conservation de flux d’événements, tandis que Spark sert notamment au traitement distribué. Ces outils deviennent utiles lorsque les contraintes de débit, de parallélisme, de traitement ou de reprise le justifient. Pour une PME consolidant des données de CRM, de facturation et de commerce électronique une fois par jour, des connecteurs planifiés, un entrepôt cloud et des transformations SQL peuvent être plus simples à exploiter. Le temps réel doit répondre à un problème concret, pas à une mode technologique.
Comment sécuriser une architecture de données utilisée par l’IA ?
Il faut contrôler les droits sur les sources et sur les résultats, classifier les informations sensibles, journaliser les accès et définir la durée de conservation des données. Les systèmes de recherche documentaire pour l’IA doivent respecter les permissions des documents au moment où ils les récupèrent. Les réponses générées gagnent également à conserver des références vers les sources et leur date de mise à jour. Une base vectorielle ou un service de modèle ne remplace pas la gouvernance : la sécurité doit être conçue sur toute la chaîne, de l’ingestion à la réponse finale.
- Partager l'article :
