Une architecture Big Data organise la collecte, le stockage, le traitement et l'exploitation de données que les outils traditionnels ne parviennent plus à gérer correctement. Elle ne se résume pas au choix d'un logiciel. Elle doit partir d'un usage précis, d'un niveau de fraîcheur attendu et des contraintes réelles de l'entreprise.
Avant de parler de Hadoop, de Spark ou de traitement en temps réel, une question mérite donc d'être posée : quelle décision ces données doivent-elles aider à prendre ? Sans réponse nette, le projet risque de produire une infrastructure coûteuse, difficile à maintenir et peu utilisée par les équipes.
Qu'est-ce qu'une architecture Big Data ?
Une architecture Big Data est l'organisation technique qui relie les sources de données aux outils de collecte, de stockage, de traitement et d'analyse. Elle sert à exploiter des volumes ou des formats que les bases de données classiques ne peuvent plus prendre en charge dans des conditions acceptables de coût, de délai ou de performance.
Les caractéristiques des données massives
Le Big Data est souvent décrit à partir de trois caractéristiques : le volume, la variété et la vitesse. Le volume désigne la quantité de données à conserver ou à traiter. La variété correspond à la coexistence de fichiers structurés, de textes, d'images, de journaux techniques, de données issues d'applications et de flux provenant d'objets connectés.
La vitesse concerne le rythme auquel les informations arrivent et doivent être exploitées. Certaines analyses peuvent attendre le lendemain. D'autres, comme la détection d'une opération inhabituelle ou le suivi d'un équipement industriel, réclament une réaction en quelques secondes.
Il n'existe donc pas de seuil universel à partir duquel une entreprise entre dans le Big Data. Quelques centaines de gigaoctets peuvent déjà poser un problème si les données arrivent rapidement, changent souvent ou proviennent de systèmes incompatibles. À l'inverse, un volume plus élevé peut rester simple à gérer lorsqu'il est homogène et peu consulté.
Les composants d'une architecture Big Data
Le schéma repose généralement sur plusieurs couches qui remplissent chacune une fonction précise :
- les sources produisent les données, par exemple un logiciel de gestion, un site web, une application mobile, des capteurs ou des fichiers transmis par des partenaires ;
- la couche d'ingestion récupère les données et les achemine vers la plateforme ;
- le stockage conserve les informations brutes, préparées ou agrégées ;
- les moteurs de traitement nettoient, rapprochent et transforment les données ;
- les outils d'analyse rendent les résultats accessibles sous forme de rapports, d'indicateurs, d'alertes ou de modèles prédictifs ;
- la gouvernance définit les droits d'accès, les responsabilités, les règles de qualité et le cycle de vie des données.
Cette dernière couche est parfois ajoutée après les choix techniques. C'est une erreur coûteuse. Une entreprise doit savoir qui peut consulter une donnée, qui peut la modifier et combien de temps elle doit être conservée avant d'ouvrir les accès.
Comment fonctionne une architecture Big Data ?
Une architecture Big Data fait circuler les données dans une chaîne composée de plusieurs étapes : collecte, ingestion, stockage, préparation, traitement et restitution. Le parcours varie selon la fréquence d'arrivée des informations et le délai accepté entre leur production et leur utilisation par les équipes ou les applications métier.
La collecte et l'ingestion des données
La collecte commence par l'inventaire des sources. Il peut s'agir d'une base clients, d'un progiciel de gestion intégré, d'un outil de relation client, de fichiers journaux, d'une interface de programmation applicative ou de capteurs connectés. Chaque source possède son format, sa fréquence de mise à jour et ses propres règles d'accès.
L'ingestion transporte ensuite les données vers la plateforme. Elle peut fonctionner par lots, à intervalles réguliers, ou en flux continu. Le traitement par lots convient aux consolidations quotidiennes, aux historiques de ventes et aux calculs qui ne réclament pas une réponse immédiate. Le traitement en flux sert lorsque chaque événement doit être analysé rapidement.
Le temps réel a un prix. Il demande une infrastructure disponible en permanence, une surveillance plus fine et des compétences techniques adaptées. Si un tableau de bord peut être actualisé toutes les heures sans gêner les décisions, une chaîne complexe de streaming n'apporte pas forcément de bénéfice mesurable.
Le stockage dans un data lake ou un entrepôt de données
Le data lake conserve de grandes quantités de données dans leur format d'origine. Cette souplesse facilite l'intégration de sources hétérogènes, mais elle ne dispense pas de documenter leur contenu. Sans catalogue, règles de nommage et responsables identifiés, le lac de données finit par devenir un ensemble de fichiers dont personne ne connaît vraiment la qualité.
L'entrepôt de données accueille plutôt des informations structurées, nettoyées et organisées pour l'analyse. Il convient bien aux indicateurs financiers, commerciaux ou opérationnels qui reposent sur des définitions stables. Une entreprise peut employer les deux : le data lake pour recevoir les données brutes et l'entrepôt pour diffuser des indicateurs validés.
Les architectures dites « lakehouse » cherchent à réunir la souplesse du data lake et les fonctions de gestion d'un entrepôt. Le terme est courant dans les offres des éditeurs, mais le nom du modèle compte moins que les garanties obtenues sur la qualité, les accès, les performances et la réversibilité.
Le traitement et la restitution des résultats
Une fois stockées, les données sont contrôlées, dédupliquées, rapprochées et transformées. Des outils distribués peuvent répartir les calculs entre plusieurs machines. Le résultat alimente ensuite un tableau de bord, une application métier, un système d'alerte ou un modèle d'intelligence artificielle.
La restitution doit rester liée à un usage. Un indicateur sans propriétaire ni décision associée occupe de l'espace et du temps de calcul, mais ne produit pas de valeur pour l'entreprise. Lors du cadrage, chaque sortie devrait donc être reliée à un utilisateur, à une fréquence de consultation et à une action possible.
Quels modèles d'architecture Big Data peut-on choisir ?
Les modèles Lambda et Kappa sont souvent présentés comme deux solutions opposées. Dans la pratique, le choix dépend surtout du rapport entre données historiques, traitement en flux, besoin de recalcul et capacité de maintenance de l'équipe.
L'architecture Lambda associe les lots et les flux
L'architecture Lambda fait fonctionner deux circuits en parallèle. La couche batch traite un historique complet et produit des résultats consolidés. La couche temps réel analyse les nouveaux événements avec une faible latence. Une couche de restitution rapproche ensuite les résultats des deux traitements.
Ce modèle convient lorsqu'une entreprise a besoin d'une vue historique fiable tout en suivant certains événements presque immédiatement. Il présente néanmoins un coût caché : les règles de calcul doivent parfois être développées, testées et maintenues dans deux chaînes différentes. Les écarts entre les résultats deviennent alors difficiles à expliquer.
L'architecture Kappa privilégie le traitement en flux
L'architecture Kappa repose sur un flux principal d'événements. Les nouvelles données sont traitées au fil de leur arrivée. Lorsqu'un recalcul est nécessaire, les événements conservés peuvent être rejoués dans la chaîne.
Cette approche réduit la duplication entre les traitements par lots et en temps réel. Elle convient aux alertes, à la surveillance d'équipements, à l'analyse de journaux techniques et à certains mécanismes de détection d'anomalies. Elle exige toutefois une gestion rigoureuse de l'ordre des événements, des doublons, des erreurs et des reprises après incident.
Une architecture plus simple reste parfois le meilleur choix
Toutes les entreprises n'ont pas besoin d'une architecture Lambda ou Kappa. Une base relationnelle, un entrepôt de données et quelques traitements planifiés peuvent suffire pour produire des indicateurs quotidiens. Ajouter du streaming à un besoin qui accepte un délai de plusieurs heures revient souvent à payer une complexité sans usage réel.
Le bon critère n'est donc pas la modernité du modèle. Il faut comparer la latence réellement attendue, le volume, les compétences disponibles, les coûts d'exploitation et la tolérance aux interruptions.
Comment cadrer la sécurité et la gouvernance des données ?
Une architecture performante peut rester inutilisable si les données ne sont ni fiables ni correctement protégées. La gouvernance doit couvrir l'origine des informations, leur qualité, les responsabilités, les accès, les durées de conservation et les conditions de suppression.
Définir les règles avant le choix des technologies
Le cadrage peut commencer par quelques questions concrètes :
- quelles données sont réellement nécessaires au cas d'usage ?
- qui en est responsable dans l'entreprise ?
- quels utilisateurs doivent pouvoir les lire ou les modifier ?
- quelle durée de conservation correspond à leur finalité ?
- quel niveau d'indisponibilité l'activité peut-elle accepter ?
- comment récupérer les données en cas de changement de prestataire ?
Quand des données personnelles sont traitées, l'entreprise ne peut pas tout conserver au seul motif qu'une utilisation future serait possible. La finalité doit être définie, les données collectées doivent rester proportionnées et leur durée de conservation doit être justifiée. Les mesures de sécurité dépendent ensuite de la nature des informations et des risques encourus.
Contrôler les accès et suivre les opérations
Les droits doivent être attribués selon les fonctions exercées, puis révisés lors des changements de poste ou des départs. Les comptes techniques, souvent très privilégiés, demandent une surveillance particulière. La journalisation aide à repérer les consultations inhabituelles et à comprendre l'origine d'un incident.
Le chiffrement, les sauvegardes et la réplication réduisent certains risques, mais aucun de ces mécanismes ne suffit seul. Une sauvegarde non testée peut être inutilisable. Une donnée chiffrée reste exposée si trop d'utilisateurs possèdent les droits de déchiffrement. La protection repose donc autant sur l'organisation que sur la technologie.
Évaluer le cloud au-delà du prix affiché
Le cloud facilite l'ajout de capacité sans acheter immédiatement des serveurs. La facture dépend toutefois du stockage, de la puissance de calcul, des transferts, des sauvegardes et du niveau de service. Une architecture peu surveillée peut accumuler des ressources inutilisées ou multiplier les copies de données.
Le contrat doit également préciser la localisation des données, les responsabilités du prestataire, les conditions de réversibilité, les modalités d'assistance et les engagements de disponibilité. Lorsque des données personnelles sont confiées à un sous-traitant, ces vérifications doivent être rapprochées des obligations applicables au traitement concerné.
Quels critères utiliser pour choisir son architecture ?
Le choix peut être ramené à cinq critères : le cas d'usage, la latence, le volume, la sensibilité des données et les moyens disponibles. La technologie vient après.
Partir d'un cas d'usage mesurable
Un premier projet peut se concentrer sur une seule question métier : anticiper une rupture de stock, consolider des données commerciales ou détecter plus vite une anomalie. Il faut ensuite définir le résultat attendu, les sources nécessaires et le délai acceptable.
Cette approche limite le périmètre et facilite l'évaluation. Si les données sont incomplètes ou incompatibles, le problème apparaît avant l'achat d'une plateforme trop ambitieuse.
Chiffrer le coût total de fonctionnement
Le budget ne se limite pas aux licences ou à l'hébergement. Il comprend la collecte, le nettoyage, les développements, la surveillance, la sécurité, la documentation, la formation et la maintenance. Le temps consacré par les équipes métier doit aussi être compté, car elles devront expliquer les données et valider les résultats.
J'ai déjà vu des outils achetés sur une promesse de centralisation rester sous-utilisés faute de responsable désigné et de données suffisamment propres. L'erreur venait du cadrage, pas du logiciel. Avant de choisir une plateforme, demandez donc à un architecte data de chiffrer un périmètre pilote, son exploitation mensuelle et son coût de sortie. Ces trois montants donnent une vision plus utile qu'une démonstration technique.
