PRÉLIMINAIRES

I. Note à l’attention de l’étudiant(e)

Ce manuel constitue votre portail vers l’architecture des données de nouvelle génération. Il ne s’agit pas d’un simple cours, mais d’un entraînement intensif à la pensée non-relationnelle, compétence devenue non-négociable dans l’économie numérique. Chaque chapitre est conçu comme un module opérationnel, vous armant d’une expertise directement monétisable. L’objectif est de vous transformer en un architecte de données capable de concevoir des solutions robustes, scalables et parfaitement adaptées aux défis de la RDC.

II. Objectifs pédagogiques et compétences visées

Au terme de cette Unité d’Enseignement, l’étudiant sera apte à :
1. Maîtriser les fondements théoriques (théorème CAP) et les typologies des systèmes NoSQL.
2. Concevoir des schémas de données flexibles pour les modèles Document, Clé-Valeur et Colonne.
3. Mettre en œuvre des solutions de stockage et de requêtage sur des plateformes comme MongoDB ou Cassandra.
4. Architecturer un entrepôt de données (Data Warehouse) pour le pilotage de la performance.
5. Évaluer l’opportunité d’une architecture Big Data (Hadoop/Spark) face à une problématique métier locale.

III. Prérequis et positionnement de l’UE

Une maîtrise solide du modèle relationnel et du langage SQL est indispensable. Des connaissances fondamentales en algorithmique, structures de données et architecture des systèmes d’information sont également requises. Cette UE se positionne comme une spécialisation avancée, faisant suite aux cours d’introduction aux bases de données. Elle constitue le socle technique indispensable avant d’aborder les Unités d’Enseignement relatives à l’intelligence artificielle et au machine learning.

IV. Méthodologie d’évaluation

L’évaluation est conçue pour mesurer l’acquisition de compétences pratiques. Le Cours Magistral Interactif (CMI) sera validé par un examen écrit final évaluant la maîtrise conceptuelle. Les Travaux Dirigés (TD) feront l’objet de notations continues sur des études de cas. Les Travaux Pratiques (TP) et le Travail Personnel de l’Étudiant (TPE) culmineront en un projet de fin de semestre : le développement d’un prototype d’application exploitant une base NoSQL pour résoudre un problème concret en RDC.

V. Glossaire des acronymes et concepts clés

La terminologie des bases de données non-relationnelles et du Big Data est dense, évolutive et majoritairement anglophone. Cette section fournit un lexique rigoureux des termes essentiels (ex: CAP, BASE, Sharding, Replication, OLAP, OLTP, HDFS, MapReduce). Sa maîtrise est impérative pour une compréhension fine des concepts et une communication professionnelle précise. Ce glossaire servira de référence constante tout au long du semestre et au-delà, dans votre future carrière.

VI. Articulation avec les enjeux socio-économiques de la RDC

La maîtrise des technologies de cette UE est un levier de développement stratégique pour la République Démocratique du Congo. De la traçabilité des minerais dans le Katanga à la gestion des millions de transactions de mobile money à Kinshasa, en passant par l’optimisation des rendements agricoles au Kivu ou la gestion épidémiologique par le Ministère de la Santé, les données massives et flexibles sont au cœur de la performance et de la transparence.

PARTIE 1 : Bases de données non relationnelles, Data Warehousing et Big Data

Chapitre I. Fondements et typologies des bases de données NoSQL

Ce chapitre établit les fondations conceptuelles du monde NoSQL. Il dissèque les raisons de l’émergence de ces technologies en réponse aux limites du modèle relationnel face aux exigences du web moderne (scalabilité, flexibilité, disponibilité). La maîtrise de ces principes est la condition sine qua non pour choisir judicieusement l’outil adapté à chaque problématique technique et économique, notamment dans un contexte de forte croissance des données mobiles en RDC.

I.1 Rupture avec le paradigme relationnel (ACID vs BASE)

Face aux limitations des systèmes SGBDR pour gérer la volumétrie et la variété des données web, le paradigme NoSQL propose une approche alternative. Cette section analyse en profondeur la transition du modèle de consistance forte ACID (Atomicité, Consistance, Isolation, Durabilité) vers le modèle BASE (Basically Available, Soft state, Eventually consistent). Il s’agit de comprendre le compromis fondamental réalisé au profit de la disponibilité et de la performance à grande échelle.

I.2 Le théorème CAP : Arbitrage entre Cohérence, Disponibilité et Tolérance au Partitionnement

Au cœur de la conception de tout système distribué, le théorème CAP (Consistency, Availability, Partition tolerance) de Brewer est une loi incontournable. Ce point expose la règle selon laquelle un système ne peut garantir simultanément que deux de ces trois propriétés. L’analyse de cet arbitrage est cruciale pour architecturer des services résilients, comme les plateformes de paiement mobile qui doivent rester disponibles même en cas de pannes réseau partielles.

I.3 Cartographie des quatre grands modèles NoSQL

Une cartographie précise des modèles NoSQL est essentielle pour naviguer dans cet écosystème. Nous procédons ici à une analyse comparative rigoureuse des quatre familles principales : Clé-Valeur (performance), Document (flexibilité), Orienté-Colonne (scalabilité en écriture) et Graphe (relations complexes). Chaque modèle est présenté avec ses forces, ses faiblesses et ses cas d’usage emblématiques, afin de permettre un choix technologique éclairé et justifié.

I.4 Analyse des cas d’usage pertinents pour la RDC

L’analyse des cas d’usage pertinents pour la RDC ancre la théorie dans la réalité économique locale. Cette section démontre comment les bases Clé-Valeur peuvent optimiser la gestion de sessions des plateformes e-commerce, comment les bases Document peuvent modéliser les dossiers médicaux électroniques, ou encore comment les bases Graphe peuvent détecter les fraudes dans les transactions financières. L’objectif est de traduire directement la connaissance technique en avantage compétitif.

Chapitre II. Modèles Clé-Valeur et Colonne-Orientée

Ce chapitre propose une immersion technique dans deux des modèles NoSQL les plus performants pour des besoins spécifiques. Le modèle Clé-Valeur, par sa simplicité, offre une vitesse de lecture/écriture inégalée pour les caches distribués. Le modèle Colonne-Orientée, lui, est conçu pour l’ingestion et l’analyse de volumes massifs de données, un besoin critique pour l’internet des objets (IoT) et l’analyse de séries temporelles dans le secteur minier ou énergétique congolais.

II.1 Sous l’angle de la performance brute : les bases de données Clé-Valeur

Sous l’angle de la performance brute, les bases de données Clé-Valeur comme Redis ou Riak sont sans égales. Leur structure, un simple dictionnaire associant une clé unique à une valeur opaque (blob), permet des temps d’accès en O(1). Cette section explore leur architecture, les types de données avancés (listes, sets) et les stratégies de distribution de charge pour construire des systèmes à très faible latence, essentiels pour les applications interactives.

II.2 Mise en œuvre d’un système de cache distribué pour une application web à fort trafic

La mise en œuvre d’un système de cache distribué est une application canonique des bases Clé-Valeur. Nous détaillons ici la méthodologie pour soulager une base de données relationnelle principale en mettant en cache les requêtes fréquentes. Ce point est crucial pour garantir la performance et la disponibilité des plateformes de médias en ligne ou des portails gouvernementaux en RDC, souvent sujets à des pics de trafic imprévisibles.

II.3 Pensées pour l’agrégation de données massives : les bases Colonne-Orientée

Pensées pour l’agrégation de données massives, les bases Colonne-Orientée (ex: Apache Cassandra, HBase) inversent le modèle de stockage traditionnel. En groupant les données par colonne plutôt que par ligne, elles optimisent drastiquement les requêtes analytiques qui ne portent que sur un sous-ensemble d’attributs. Cette section décortique ce mécanisme et son impact sur la conception des schémas pour des écritures à très haute vélocité.

II.4 Modélisation des données de séries temporelles issues de capteurs industriels

La modélisation des données de séries temporelles issues des capteurs miniers ou des compteurs intelligents est un défi majeur. Ce sous-chapitre démontre, via un cas pratique, comment utiliser une base de données comme Cassandra pour stocker et interroger efficacement des milliards de points de données (température, pression, consommation). Cette compétence est directement applicable pour la maintenance prédictive dans les usines de la GECAMINES ou la gestion du réseau de la SNEL.

Chapitre III. Le modèle Document et son application à l’écosystème congolais

Ce chapitre se concentre sur le modèle Document (MongoDB, CouchDB), sans doute le plus polyvalent et le plus populaire des modèles NoSQL. Sa capacité à stocker des objets complexes au format JSON ou BSON sans schéma prédéfini offre une flexibilité de développement inégalée. Nous explorerons comment cette flexibilité peut accélérer la création d’applications métiers innovantes, de la gestion de catalogues produits à la digitalisation des services publics en RDC.

III.1 Héritier de la flexibilité du format JSON : le modèle Document

Héritier de la flexibilité du format JSON, le modèle Document permet de stocker des structures de données nichées et hétérogènes au sein d’une même collection. Cette section explique comment cette approche “schema-on-read” facilite les itérations rapides de développement et l’évolution des applications sans migrations de base de données complexes. C’est un atout majeur pour les startups et les équipes agiles développant de nouveaux services numériques à Kinshasa ou Lubumbashi.

III.2 Maîtrise du langage de requêtage et du framework d’agrégation

La maîtrise du langage de requêtage et du framework d’agrégation est la clé pour exploiter la puissance des bases Document. Ce point va au-delà des simples opérations CRUD (Create, Read, Update, Delete) pour couvrir les requêtes complexes, les jointures applicatives (via $lookup) et les pipelines d’agrégation. L’étudiant apprendra à transformer et à synthétiser les données directement au sein de la base pour générer des rapports analytiques pertinents.

III.3 Déployer une application de gestion de catalogues produits pour l’e-commerce

Déployer une application de gestion de catalogues produits est un cas d’usage idéal pour le modèle Document. Chaque produit, avec ses attributs variables, ses images et ses avis clients, peut être modélisé comme un document unique. Ce sous-chapitre guide l’étudiant dans la conception du schéma, l’indexation pour la recherche et la gestion des stocks. Il s’agit d’une compétence fondamentale pour développer le secteur du commerce en ligne en RDC.

III.4 L’indexation stratégique des champs critiques pour l’optimisation des requêtes

L’indexation stratégique des champs critiques est la science qui transforme une base de données lente en un système ultra-réactif. Sans une indexation correcte, les performances d’une base Document s’effondrent avec l’augmentation du volume. Cette section technique détaille les différents types d’index (simple, composé, géospatial, texte) et les méthodologies pour analyser les plans d’exécution des requêtes afin d’identifier et de résoudre les goulots d’étranglement.

Chapitre IV. Introduction au Data Warehousing et à la modélisation en étoile

Ce chapitre opère la transition cruciale entre les bases de données opérationnelles (OLTP) et les systèmes décisionnels (OLAP). Il introduit le concept d’entrepôt de données (Data Warehouse) comme le réceptacle unique de la vérité pour l’analyse de la performance d’une entreprise. La maîtrise de la modélisation dimensionnelle (schéma en étoile) est présentée comme la compétence fondamentale de tout analyste ou architecte décisionnel.

IV.1 Distincts des bases de données transactionnelles (OLTP), les entrepôts de données (OLAP)

Distincts des bases de données transactionnelles optimisées pour les écritures rapides, les entrepôts de données sont optimisés pour les requêtes analytiques complexes (OLAP). Cette section clarifie cette dichotomie fondamentale en comparant leurs architectures, leurs objectifs et leurs modèles de données. Comprendre cette différence est le premier pas pour construire une infrastructure de Business Intelligence (BI) cohérente et performante au sein d’une banque ou d’une société de télécoms congolaise.

IV.2 L’architecture d’un entrepôt de données moderne : le processus ETL/ELT

L’architecture d’un entrepôt de données moderne repose sur des processus robustes d’intégration. Nous disséquons ici les flux de données, notamment les processus ETL (Extract, Transform, Load) et leur variante moderne ELT (Extract, Load, Transform). L’accent est mis sur les outils et les techniques permettant de collecter, nettoyer, conformiser et charger les données issues de sources hétérogènes (fichiers plats, API, bases de données) dans l’entrepôt.

IV.3 Au fondement de la Business Intelligence, le schéma en étoile

Au fondement de la Business Intelligence, le schéma en étoile est le modèle de conception le plus répandu et le plus efficace pour les entrepôts de données. Il organise les données en une table de faits centrale (les mesures, ex: montant des ventes) entourée de tables de dimensions (les axes d’analyse, ex: temps, produit, client). Ce sous-chapitre enseigne de manière rigoureuse la méthodologie de conception de ces schémas pour garantir performance et intelligibilité.

IV.4 Concevoir un data mart pour le suivi des performances commerciales d’un réseau de distribution

Concevoir un data mart (un sous-ensemble d’un data warehouse) pour le suivi des performances commerciales est un projet concret et à forte valeur ajoutée. En partant d’un besoin métier (ex: analyser les ventes des produits BRALIMA par province et par canal de distribution), nous guidons l’étudiant dans la définition des faits, des dimensions, et la construction du schéma en étoile correspondant, prêt à être exploité par un outil de reporting.

Chapitre V. L’écosystème Big Data : Architecture et Technologies

Ce chapitre plonge au cœur du phénomène Big Data. Il ne s’agit plus seulement de volume, mais d’une nouvelle façon de stocker, traiter et analyser des données de nature et de vélocité diverses. L’écosystème Hadoop, avec son système de fichiers distribué (HDFS) et son modèle de calcul (MapReduce), est présenté comme la fondation historique, tandis qu’Apache Spark est introduit comme son successeur plus performant et plus polyvalent.

V.1 Définie par les “V” (Volume, Vélocité, Variété…), la problématique Big Data

Définie par ses caractéristiques intrinsèques (Volume, Vélocité, Variété, Véracité, Valeur), la problématique Big Data dépasse les capacités des technologies traditionnelles. Cette section formalise ces concepts et illustre leur manifestation concrète en RDC : volume des données de géolocalisation des téléphones, vélocité des transactions financières mobiles, variété des rapports textuels et des images satellites pour le suivi de la déforestation.

V.2 L’écosystème Hadoop : HDFS pour le stockage et MapReduce pour le traitement

L’écosystème Hadoop, avec HDFS (Hadoop Distributed File System) pour le stockage et MapReduce pour le traitement, a été la première solution open-source à démocratiser le traitement des données massives sur des clusters de serveurs standards. Ce point en explique l’architecture, le principe de distribution des données et de parallélisation du calcul. Comprendre Hadoop est essentiel pour saisir les principes fondamentaux sur lesquels reposent les technologies Big Data modernes.

V.3 Au-delà du traitement par lots : Apache Spark et le calcul en mémoire

Au-delà du traitement par lots de MapReduce, Apache Spark a révolutionné l’écosystème en introduisant le calcul distribué en mémoire (in-memory). Cette innovation permet des performances jusqu’à 100 fois supérieures et unifie le traitement batch, le traitement interactif (SQL), le streaming en temps réel et le machine learning au sein d’une seule plateforme. Nous explorons ici son architecture (RDD, DataFrames) et ses avantages décisifs.

V.4 L’orchestration d’un pipeline de données Big Data de l’ingestion à la restitution

L’orchestration d’un pipeline de données Big Data est un exercice d’ingénierie complexe. Ce sous-chapitre présente une vue d’ensemble des composants d’une chaîne de traitement typique : l’ingestion des données brutes (avec Sqoop ou Flume), leur stockage sur HDFS ou un data lake, leur transformation avec Spark, et leur exposition pour l’analyse via des bases NoSQL ou des outils de BI. L’accent est mis sur la robustesse et l’automatisation du processus.

Chapitre VI. Valorisation des données massives pour le pilotage stratégique en RDC

Ce chapitre final synthétise l’ensemble des connaissances acquises en se concentrant sur l’objectif ultime : la création de valeur. Il démontre, à travers des études de cas sectorielles adaptées à la RDC, comment la combinaison des technologies NoSQL, Data Warehousing et Big Data permet de passer de la donnée brute à la décision stratégique éclairée, générant ainsi des gains de productivité, de nouveaux revenus et une meilleure gouvernance.

VI.1 Une connaissance approfondie des dynamiques de la clientèle pour les banques et télécoms

Une connaissance approfondie des dynamiques de la clientèle, obtenue par l’analyse de milliards de transactions et d’interactions, permet une segmentation fine et la personnalisation des offres. Cette section montre comment une banque comme Rawbank ou un opérateur comme Vodacom peut utiliser Spark pour calculer des scores de risque de crédit en temps réel, prédire le “churn” (départ des clients) et optimiser ses campagnes marketing.

VI.2 L’analyse prédictive appliquée à la maintenance des équipements miniers

L’analyse prédictive appliquée à la maintenance des équipements miniers est une application à très haute valeur ajoutée. En analysant les données des capteurs (vibrations, température) des engins de chantier dans le Lualaba, les algorithmes de machine learning peuvent anticiper les pannes avant qu’elles ne surviennent. Cela permet de réduire les temps d’arrêt coûteux et d’optimiser les plannings de maintenance, générant des millions de dollars d’économies.

VI.3 Face aux défis de la gestion des terres et des ressources naturelles

Face aux défis de la gestion des terres, de la déforestation et de l’agriculture, le Big Data offre des outils de suivi et d’aide à la décision sans précédent. Ce sous-chapitre explore comment le croisement d’images satellites, de données cadastrales et de relevés de terrain, traité via des plateformes distribuées, peut aider les agences gouvernementales et les ONG à mieux planifier l’aménagement du territoire et à lutter contre les activités illégales.

VI.4 La construction de tableaux de bord décisionnels (dashboards) interactifs

La construction de tableaux de bord décisionnels est l’étape finale de la valorisation, rendant l’information accessible aux dirigeants. Ce point aborde la connexion des entrepôts de données et des data lakes à des outils de visualisation comme Power BI ou Tableau. L’objectif est de créer des rapports interactifs permettant aux décideurs d’explorer les données, d’identifier les tendances et de piloter la performance de leur organisation en se basant sur des faits.

PARTIE 2 : Bases de données non relationnelles, Data Warehousing et Big Data

Chapitre VII. De la base de données transactionnelle à l’entrepôt de données

VII.1 La saturation des systèmes OLTP pour l’analyse

Face à la saturation des systèmes transactionnels (OLTP) par les requêtes analytiques, une ségrégation architecturale s’impose. L’exécution de rapports complexes sur une base de production ralentit les opérations critiques, un risque inacceptable pour une banque à Kinshasa traitant des milliers de transactions par minute. Cette section expose la justification technique et économique de la séparation des charges de travail transactionnelles et décisionnelles pour garantir la performance et la disponibilité des services.

VII.2 Le concept d’entrepôt de données (Data Warehouse)

Concept central de l’informatique décisionnelle, l’entrepôt de données consolide et historise les informations issues de sources hétérogènes pour l’analyse stratégique. Il ne s’agit pas d’une simple copie, mais d’une transformation des données en un format optimisé pour la requête. Nous étudions ici comment un tel entrepôt permettrait à la SNCC (Société Nationale des Chemins de fer du Congo) d’analyser des décennies de données logistiques pour optimiser les futurs corridors de fret.

VII.3 Distinction fondamentale : OLTP vs. OLAP

Distincts par leur finalité, leur structure et leurs métriques de performance, les systèmes OLTP (Online Transaction Processing) et OLAP (Online Analytical Processing) constituent deux univers techniques. L’un est optimisé pour des écritures rapides et atomiques, l’autre pour la lecture et l’agrégation de vastes volumes de données. Ce point clarifie la dichotomie en modélisant la gestion des abonnés d’une société de télécoms (OLTP) versus l’analyse de leurs schémas de consommation (OLAP).

VII.4 Les magasins de données (Data Marts) : une approche spécialisée

Sous-ensemble logique de l’entrepôt de données, le Data Mart répond aux besoins spécifiques d’un département ou d’une ligne métier. Sa portée réduite accélère sa mise en œuvre et la pertinence des analyses. Cette section détaille la conception d’un Data Mart pour le ministère de la Santé de la RDC, focalisé exclusivement sur le suivi des campagnes de vaccination et des chaînes d’approvisionnement en vaccins dans la province de l’Ituri, pour une prise de décision ciblée et rapide.

Chapitre VIII. Ingénierie de l’entrepôt de données : Modélisation et ETL

VIII.1 Le processus ETL : Extraction, Transformation, Chargement

Processus critique d’alimentation, l’ETL automatise la collecte de données depuis des systèmes sources, leur nettoyage et leur restructuration, puis leur injection dans l’entrepôt. La maîtrise de ce flux est vitale pour la qualité de la donnée décisionnelle. Nous disséquons ici les trois phases en simulant l’intégration de données issues des registres douaniers de la DGDA, des déclarations fiscales et des statistiques de production de la GÉCAMINES pour obtenir une vue unifiée du secteur minier.

VIII.2 Modélisation en étoile (Star Schema)

Modèle de prédilection pour sa simplicité et ses performances en requête, le schéma en étoile structure les données autour d’une table de faits centrale (mesures, métriques) et de tables de dimensions dénormalisées (axes d’analyse). Son application est ici démontrée pour analyser les ventes d’une brasserie de Bukavu, avec une table de faits sur les volumes vendus et des dimensions pour les produits, les points de vente, les clients et le temps.

VIII.3 Modélisation en flocon (Snowflake Schema)

Normalisation plus poussée du schéma en étoile, le modèle en flocon décompose les tables de dimensions en hiérarchies distinctes, réduisant la redondance au prix de jointures plus complexes. Ce sous-chapitre analyse le compromis performance/maintenance et illustre son utilité pour modéliser la structure administrative complexe de la RDC (Provinces > Territoires > Secteurs/Chefferies) dans une analyse démographique pour l’Institut National de la Statistique (INS).

VIII.4 L’alternative moderne : le paradigme ELT

Une inversion paradigmatique du processus classique, l’ELT (Extract, Load, Transform) tire parti de la puissance de calcul des entrepôts de données modernes. Les données brutes sont d’abord chargées dans le système cible, puis transformées sur place. Cette approche offre une flexibilité accrue et est particulièrement adaptée aux architectures de type Data Lake. Nous explorons son application pour l’analyse de données de capteurs brutes issues des barrages d’Inga.

Chapitre IX. Fondements conceptuels du Big Data

IX.1 Les “V” du Big Data : Volume, Vélocité, Variété

Au cœur de la définition du Big Data, les trois “V” initiaux décrivent les défis posés par ces nouvelles masses de données. Le Volume (échelle), la Vélocité (flux en temps réel) et la Variété (formats hétérogènes) forcent un changement radical des outils et des architectures. Ce point contextualise ces concepts en RDC : le volume des données de téléphonie mobile, la vélocité des transactions de mobile money, et la variété des données géospatiales du bassin du Congo.

IX.2 Le lac de données (Data Lake) : un réservoir de données brutes

Paradigme de stockage flexible, le Data Lake conserve les données dans leur format natif, structuré ou non, sans schéma prédéfini. Il sert de réceptacle unique pour toutes les données d’une organisation, permettant des explorations futures non anticipées. Nous examinons ici la pertinence d’un Data Lake national pour la recherche agronomique, stockant des données météorologiques, des images satellites, des analyses de sol et des rapports de terrain de l’INERA.

IX.3 La dichotomie des données : structurées, semi-structurées, non structurées

La distinction fondamentale entre les types de données conditionne leur mode de stockage et d’analyse. Alors que les bases relationnelles excellent avec les données structurées, le Big Data tire sa valeur de l’exploitation des données non structurées (textes, images, vidéos). Ce sous-chapitre démontre comment analyser des milliers de rapports textuels d’ONG pour cartographier les besoins humanitaires dans le Kasaï, une tâche impossible avec les outils traditionnels.

IX.4 L’impératif d’une infrastructure de traitement distribué

L’échelle du Big Data rend le traitement sur une machine unique physiquement impossible. La solution réside dans le calcul distribué, où une tâche est divisée et exécutée en parallèle sur un cluster de plusieurs machines (nœuds). Cette section aborde les principes fondamentaux de cette approche et les défis qu’elle représente en RDC, notamment en termes de connectivité réseau et de fiabilité de l’alimentation électrique pour les centres de données locaux.

Chapitre X. L’écosystème Hadoop : Traitement distribué

X.1 HDFS : le système de fichiers distribué

Fondation du stockage dans l’écosystème Hadoop, HDFS (Hadoop Distributed File System) est conçu pour stocker des fichiers de très grande taille sur des clusters de machines standards, en garantissant la haute disponibilité et la tolérance aux pannes par la réplication des données. Nous simulons son déploiement pour archiver de manière résiliente et économique les données sismiques et géologiques de l’Observatoire Volcanologique de Goma.

X.2 MapReduce : le modèle de programmation parallèle

Modèle de programmation pour le traitement parallèle de larges volumes de données, MapReduce simplifie le développement d’applications distribuées en abstrayant la complexité du parallélisme. Le développeur ne spécifie que deux fonctions : Map et Reduce. Ce point explique le fonctionnement interne du modèle en l’appliquant à un cas concret : le calcul de l’incidence du paludisme par localité à partir de millions de dossiers médicaux anonymisés.

X.3 YARN : le gestionnaire de ressources du cluster

Gestionnaire de ressources au sein du cluster, YARN (Yet Another Resource Negotiator) est le cerveau qui alloue la puissance de calcul (CPU, RAM) aux différentes applications tournant sur Hadoop. Il permet la cohabitation de multiples moteurs de traitement (MapReduce, Spark, etc.) sur le même cluster. Son rôle est ici comparé à celui d’un régulateur de trafic aérien, assurant une utilisation optimale et équitable des ressources du cluster pour l’INS.

X.4 Limites et évolution de l’écosystème Hadoop

Malgré son rôle pionnier, le modèle MapReduce originel présente des limitations, notamment sa latence due aux écritures disque intermédiaires et sa complexité de programmation. Ces faiblesses ont ouvert la voie à des technologies plus performantes comme Apache Spark. Cette section analyse de manière critique les contraintes de MapReduce pour des cas d’usage comme la détection de fraude en temps réel dans les services financiers à Kinshasa.

Chapitre XI. Architectures modernes de la donnée : Spark et le streaming

XI.1 Apache Spark : la vitesse par le traitement en mémoire

Successeur de facto de MapReduce, Apache Spark révolutionne le traitement Big Data grâce à son moteur d’exécution qui privilégie le traitement en mémoire (in-memory), le rendant jusqu’à 100 fois plus rapide pour certaines applications. Nous démontrons sa supériorité pour des algorithmes itératifs de machine learning, comme la classification des zones de déforestation à partir d’images satellites du parc des Virunga.

XI.2 Traitement par lots (Batch) vs. Traitement en temps réel (Streaming)

Deux temporalités de traitement aux objectifs distincts structurent les architectures de données. Le traitement par lots analyse des données au repos sur de longues périodes, tandis que le traitement en flux continu analyse les données à la volée, dès leur création. Ce sous-chapitre oppose un rapport mensuel sur la production de cuivre (batch) à un système d’alerte sur les fluctuations du prix du cobalt sur les marchés internationaux (streaming).

XI.3 Apache Kafka : l’épine dorsale du streaming de données

Système de messagerie distribué, pub-sub, hautement performant et tolérant aux pannes, Apache Kafka s’est imposé comme le standard de fait pour la construction de pipelines de données en temps réel. Il agit comme un tampon centralisé pour les flux de données. Nous modélisons son utilisation pour ingérer et distribuer les données de géolocalisation des motos-taxis d’une métropole comme Lubumbashi vers divers services consommateurs.

XI.4 Architectures Lambda et Kappa pour une vue unifiée

Architectures de référence, Lambda et Kappa proposent des solutions pour combiner traitement batch et temps réel afin d’offrir une vue complète et précise des données. La Lambda combine les deux voies, tandis que la Kappa vise une simplification en utilisant un seul moteur de streaming. Nous comparons les deux approches dans le contexte d’une grande entreprise de distribution en RDC, désirant une vision à la fois historique et instantanée de ses stocks.

Chapitre XII. Valorisation des données et gouvernance en contexte congolais

XII.1 De la donnée à la décision : la Business Intelligence (BI)

Discipline transformant les données brutes en informations exploitables pour la prise de décision, la Business Intelligence (BI) s’appuie sur les entrepôts de données et les outils d’analyse. Elle se matérialise par des rapports et des tableaux de bord interactifs. Ce point illustre la création d’un tableau de bord pour le cabinet du Ministre de l’Économie, consolidant les indicateurs clés de performance (inflation, balance commerciale, etc.).

XII.2 L’art et la science de la visualisation de données (DataViz)

La visualisation de données est la traduction graphique d’informations complexes pour en faciliter la compréhension et en révéler les motifs cachés. Une bonne visualisation est plus éloquente qu’un long rapport. Nous explorons les principes de la DataViz en concevant une carte interactive des projets d’infrastructures en RDC, financés par différents bailleurs, pour le suivi par la présidence.

XII.3 La gouvernance des données : un enjeu de souveraineté

Cadre formel de gestion des actifs de données, la gouvernance des données définit les règles, les rôles et les responsabilités pour garantir la qualité, la sécurité, la conformité et la disponibilité des données. Pour un État comme la RDC, c’est un enjeu de souveraineté numérique. Cette section esquisse les piliers d’une politique de gouvernance pour les données critiques de la Banque Centrale du Congo (BCC).

XII.4 Éthique, régulation et protection de la vie privée

Face au potentiel de la donnée, des questions éthiques et réglementaires cruciales émergent. La collecte et l’analyse de données personnelles doivent être encadrées pour prévenir les abus, la discrimination et les atteintes à la vie privée. Ce dernier point analyse les défis et la nécessité pour la RDC de se doter d’une loi sur la protection des données personnelles, en s’inspirant des standards africains et internationaux.

PARTIE 3 : Bases de données non relationnelles, Data Warehousing et Big Data

Chapitre XIII. Fondements et Architectures des Bases de Données Non Relationnelles (NoSQL)

XIII.1 Rupture avec le modèle relationnel : Le théorème CAP

Face à la volumétrie et la vélocité des données générées par les applications modernes, le modèle relationnel montre ses limites en scalabilité horizontale. Le théorème CAP (Consistency, Availability, Partition tolerance) formalise le compromis inévitable dans les systèmes distribués. Cette section analyse comment les bases NoSQL sacrifient la cohérence forte au profit d’une disponibilité et d’une tolérance aux pannes supérieures, un arbitrage crucial pour les services mobiles et financiers en RDC.

XIII.2 Taxonomie des systèmes NoSQL : Clé-valeur, Document, Colonne et Graphe

Une classification rigoureuse des modèles NoSQL permet de sélectionner l’outil adéquat pour chaque problématique métier. Nous disséquons ici les quatre familles principales : clé-valeur pour le caching ultra-rapide, document pour la flexibilité schématique, colonne pour l’analytique massive et graphe pour la modélisation des relations complexes. L’objectif est de permettre à l’étudiant de cartographier un besoin métier (ex: logistique minière du Katanga) au modèle NoSQL le plus performant.

XIII.3 Modélisation de données orientée document avec MongoDB

Sous l’angle de l’implémentation pratique, la modélisation en base de données document diffère radicalement de l’approche relationnelle. Ce point se concentre sur les techniques d’imbrication (embedding) et de référencement (linking) dans MongoDB. L’étudiant apprendra à concevoir des schémas flexibles et performants, capables de gérer la diversité des données d’un projet d’e-gouvernement ou d’une plateforme de commerce électronique pour l’artisanat congolais, où les attributs varient constamment.

XIII.4 Stratégies d’indexation et d’optimisation des requêtes

L’efficacité d’une base NoSQL repose sur une stratégie d’indexation alignée sur les patrons de requêtes applicatives. Cette section explore la création d’index simples, composés et spécialisés (géospatiaux, textuels) pour accélérer la lecture des données. L’enjeu est de garantir des temps de réponse minimaux, que ce soit pour une application de suivi en temps réel de la flotte de transport sur l’axe Kinshasa-Matadi ou pour l’analyse de sentiments sur les réseaux sociaux locaux.

Chapitre XIV. Ingénierie du Data Warehouse et Écosystèmes Big Data

XIV.1 Principes de l’entreposage de données : Modélisation en étoile et en flocon

Distinct de la base de données transactionnelle (OLTP), l’entrepôt de données (DWH) est optimisé pour l’analyse (OLAP). Ce sous-chapitre expose les fondements de la modélisation dimensionnelle, notamment les schémas en étoile et en flocon, à travers la distinction entre tables de faits et tables de dimensions. L’étudiant sera capable de concevoir un DWH pour une banque commerciale de la RDC, afin d’analyser la profitabilité des produits par agence et par segment de clientèle.

XIV.2 Processus ETL/ELT : Extraction, Transformation et Chargement des données

Au cœur de l’alimentation du Data Warehouse, le processus ETL (Extract, Transform, Load) garantit la qualité et la cohérence des données décisionnelles. Nous détaillons ici les trois phases : l’extraction depuis des sources hétérogènes (fichiers, API, bases de données), la transformation (nettoyage, agrégation, standardisation) et le chargement dans le DWH. L’application pratique portera sur la consolidation des données de vente issues des multiples points de service d’un opérateur télécom en RDC.

XIV.3 Introduction à l’écosystème Hadoop : HDFS et MapReduce

Face à des volumes de données dépassant les capacités d’un serveur unique, l’écosystème Hadoop offre une solution de stockage et de traitement distribués. Ce point introduit ses deux piliers : HDFS (Hadoop Distributed File System) pour un stockage résilient sur un cluster de machines standards, et MapReduce comme paradigme de calcul parallèle. Le potentiel pour la RDC réside dans l’analyse de données agronomiques à grande échelle pour optimiser les rendements agricoles dans la plaine de la Ruzizi.

XIV.4 Orchestration et traitement de données à grande échelle avec Apache Spark

Une évolution majeure du traitement distribué, Apache Spark, surpasse MapReduce en performance grâce à son traitement en mémoire. Ce sous-chapitre présente son architecture unifiée (Spark SQL, Streaming, MLlib) qui permet de combiner requêtes, traitements en temps réel et machine learning. L’étudiant explorera comment Spark peut être déployé pour analyser les données du réseau électrique de la SNEL, afin de prédire les pannes et d’optimiser la distribution depuis les barrages d’Inga.

ANNEXES

A. Étude de cas : Architecture Big Data pour l’optimisation des services de Mobile Money en RDC

Face à la saturation des réseaux mobiles à Kinshasa et Lubumbashi, cette étude de cas dissèque l’implémentation d’une architecture de données hybride. Elle combine une base de données orientée documents (MongoDB) pour les profils clients et une base graphe (Neo4j) pour l’analyse des réseaux de transactions. L’objectif est de modéliser une solution permettant de prédire les pannes, de personnaliser les offres et de détecter les fraudes en temps réel, créant un avantage concurrentiel décisif pour les opérateurs télécoms congolais.

B. Lexique Technique et Stratégique (Français – Anglais)

Une maîtrise terminologique précise est le fondement de l’expertise technique. Ce lexique bilingue ne se contente pas de traduire ; il contextualise les concepts clés du cours (Data Lake, ETL, CAP Theorem, Sharding, etc.) dans le cadre de la gestion d’entreprise. Il sert de référence rapide pour la rédaction de rapports techniques, la communication avec des partenaires internationaux et la préparation aux certifications professionnelles, assurant que l’étudiant maîtrise le jargon global du Big Data.

Lire aussi :

Cours de Archivéconomie, licence-3, ARC1351,

Cours de Droit administratif 2, licence-1, DAD1122,

Cours de Stage et projet professionnel, master-2, GAA1241

Cours de Droit du travail, des affaires et de la propriété intellectuelle, licence-3, DAP1361

Cours de Méthodologie de Recherche et Ecriture Scientifique, annee-inconnue, MRS1111

Cours de Projet tutoré, nonspécifié, PSM1242,