Data Pipeline Planning : De l'Expression de Besoin à l'Architecture
Mar 2026Application d'un framework rigoureux pour traduire un besoin métier critique (Scoring de micro-crédit en temps réel) en spécifications techniques d'architecture data.
Contexte : Le problème de l’alignement métier-technique dans les projets Data
L’une des causes principales d’échec des projets Data est le décalage entre les exigences métier et les choix techniques. On construit trop souvent des systèmes d’une complexité inutile (sur-ingénierie) ou, à l’inverse, inadaptés aux vraies contraintes de la donnée (latence, sécurité, volume).
Ma méthodologie est simple : avant de tracer le moindre diagramme d’architecture ou d’écrire la première ligne de code, j’utilise un framework de planification rigoureux. Inspiré des standards de l’industrie (notamment les principes de design d’AWS et l’architecture Medallion), l’objectif est de documenter les décisions d’architecture de manière pragmatique. Ce document sert de contrat de base. Une fois cette grille d’analyse remplie, le choix des outils Cloud et le dessin de l’architecture finale deviennent une évidence logique, et non plus une supposition.
Il est important de préciser qu’il faut voir ce planning comme un brouillon évolutif. Son but est de guider mes choix d’architecture, mais ce plan n’est absolument pas figé : il peut être modifié à n’importe quel moment. Il doit toujours s’adapter aux exigences fonctionnelles, à la taille de l’entreprise et à la réalité du terrain. Par conséquent, les technologies mentionnées plus bas (comme Kafka ou Postgres, lakehouse) ne sont pas des choix absolus. Elles peuvent tout à fait changer. Ce sont simplement les outils qui m’ont semblé les plus adaptés au budget et au besoin précis du cas d’usage que j’ai sélectionné ici.
Ce projet démontre ma capacité à :
- Traduire un besoin métier en contrainte technique (ex: “Je veux un score en temps réel” -> “Il nous faut un broker de messages type Kafka”)
- Auditer le cycle de vie de la donnée en identifiant les sources, en définissant la Source Unique de Vérité (SSOT) et en anticipant les formats de stockage (Data Lake vs Base Opérationnelle).
- Intégrer le Data Management dès le Jour 1, en anticipant la sécurité (masquage PII/RGPD), la gouvernance et les compromis financiers (FinOps) avant même le déploiement.
Cas Pratique : Le Scoring de Crédit Alternatif (Microfinance)
Comprendre le Métier : Microfinance et Données Alternatives (Une idée de projet qui pourrait être mise en œuvre dans une entreprise réelle en Afrique de l’Ouest)
Pour ceux qui ne sont pas familiers avec ces termes, la microfinance consiste à offrir des services financiers (souvent de tout petits prêts) à des populations qui sont exclues du système bancaire traditionnel. En Afrique de l’Ouest, par exemple, beaucoup d’agriculteurs et commerçants n’ont pas de compte en banque, mais possèdent un téléphone portable.
C’est là qu’intervient le Scoring de Crédit Alternatif. Comment savoir si l’on peut prêter 50, 000 FCFA (equivalent à 76,22€) à quelqu’un dont on ne connaît pas l’historique bancaire ? On utilise des données “alternatives” : la fréquence à laquelle il recharge son crédit téléphonique, son comportement sur notre application mobile, etc. C’est un défi data passionnant, car il faut croiser des sources très hétérogènes en un temps record pour évaluer le risque.
Le Besoin Métier (Business Need)
Notre application mobile de microfinance souhaite donc accorder ces micro-crédits de manière instantanée. Les contraintes métier sont extrêmes :
- Temps de réponse : Si l’application met plus de 5 minutes à statuer sur le prêt, l’utilisateur abandonne.
- Risque critique : S’il y a un biais dans l’algorithme ou une fuite de données personnelles (PII), l’entreprise risque des sanctions sévères, voire la fermeture.
Les Données (Le point de départ)
Pour établir ce score, nous devons croiser trois flux de données distincts :
- L’historique d’achats de crédit téléphonique de l’utilisateur (récupéré chez l’opérateur Télécom partenaire via API).
- L’historique des clics et de la navigation sur notre propre application mobile.
- La base de données interne de l’entreprise contenant les fonds disponibles pour prêter.
ÉTAPE 1 : Analyse des 5V (Pour comprendre les contraintes de la donnée)
| Dimension | Analyse pour le cas Microfinance |
|---|---|
| Volume | Modéré (~100 000 transactions/jour + des millions d’événements de clics). |
| Vélocité | Élevée. Le pipeline exige une ingestion et un traitement en Streaming (temps de réponse < 5 minutes). |
| Variété | Structurée : Tables relationnelles (Base de données interne).Semi-structurée : Fichiers JSON (API) et JSONLines ou .log (Appli mobile). |
| Véracité | Critique. Les données contiennent des PII (données personnelles) qu’il faut impérativement masquer avant tout stockage analytique. |
| Valeur | Identifier instantanément les profils solvables non-bancarisés pour accorder des micro-crédits sûrs, augmentant ainsi le chiffre d’affaires et l’inclusion financière. |
ÉTAPE 2 : Audit Général du Pipeline de Données
| Question (Checklist) | Réponse (Cas Microfinance) |
|---|---|
| L’organisation a-t-elle les données pour répondre au besoin ? Où sont-elles stockées et dans quel format ? | Partiellement. 1. Fonds : Base Postgres interne (Tables relationnelles). 2. Historique client : Serveur de l’opérateur (API REST). 3. Comportement : Serveur de l’App (Fichiers logs). |
| Aurai-je besoin de combiner des données de multiples sources ? | Oui. Croisement des logs (App), des tables (Interne) et des JSON (API). |
| Quel est le type et la qualité de la donnée ? Quelle sera la Source de Vérité (SSOT) ? | Qualité variable (risque de données manquantes côté API externe). La SSOT (Single Source of Truth) est la référence absolue en cas de litige : ici, le SSOT du solde financier est la base Postgres interne (et non l’application mobile). |
| Quelles sont les exigences de sécurité ? Qui a besoin d’y accéder et dans quel état ? | Masquage des PII (Noms, Téléphones) obligatoire en vol. L’App ne reçoit qu’un booléen (OUI/NON). Les Data Analysts n’accèdent qu’à la donnée historique anonymisée (voir mon approche RGPD). |
| Quels mécanismes sont nécessaires pour transférer la donnée dans le pipeline ? | 1. Broker type Kafka/PubSub pour écouter les logs de l’App en temps réel. 2. Requêtes HTTP (GET) asynchrones vers l’API Télécom. |
| Quelle est la quantité de données, et à quelle fréquence sont-elles traitées ? | Traitement continu (Streaming) déclenché à chaque action d’un utilisateur sur l’application. |
ÉTAPE 3 : Analyse de la Source (Extraction)
| Question (Checklist) | Réponse (Cas Microfinance) |
|---|---|
| Avec qui allons-nous collaborer ? | Développeurs Mobile (pour les logs), Ingénieurs du partenaire Télécom (pour l’API). |
| Comment la donnée sera-t-elle utilisée ? | Pour alimenter un modèle de Machine Learning de scoring en temps réel. |
| Quel est le format d’extraction ? | 1. Interne : Lignes/Colonnes SQL. 2. Appli : Événements streamés en JSONLines via un SDK. 3. Télécom : Payload JSON. |
| Quelle est la fréquence et le volume ? | Streaming (Temps réel). Pings très légers (quelques Ko par requête) mais à haute fréquence (milliers par heure). |
| Quel traitement est requis en amont ? | Aplatissement (Flattening) des fichiers JSON imbriqués, et masquage immédiat des PII via une fonction de hachage. |
ÉTAPE 4 : Analyse de la Destination (Stockage)
| Question (Checklist) | Réponse (Cas Microfinance) |
|---|---|
| Avec qui allons-nous collaborer ? | Analystes Risque et Data Scientists. |
| Comment la donnée sera-t-elle utilisée ? | Reporting des défauts de paiement et entraînement futur des modèles d’IA. |
| Y a-t-il de multiples destinations ? | Oui. Une base rapide (Opérationnelle) et un Data Lake (Analytique). |
| Quel est le format de stockage ? | 1. Fichiers Parquet (compressés en colonnes) pour le Data Lake. 2. Paires Clé-Valeur pour la base NoSQL opérationnelle. |
| Comment la donnée sera-t-elle stockée (Architecture) ? | Approche Medallion (Architecture Lakehouse) : Bronze (Brut), Silver (Nettoyé/Anonymisé), Gold (Agrégé pour le métier). |
ÉTAPE 5 : Évaluation de la Véracité (Focus Data Engineering)
| Question (Checklist) | Réponse (Cas Microfinance) |
|---|---|
| Comment la source est-elle gérée et maintenue ? | L’API Télécom est externe : il est impératif de prévoir des règles de “Retry” (nouvelle tentative) et de “Dead Letter Queue” si elle tombe en panne. |
| A-t-on besoin de tous les champs et tous les enregistrements ? | Non. On “Drop” (supprime) les champs techniques inutiles du mobile dès l’ingestion pour réduire les coûts de stockage (FinOps). |
| Existe-t-il des pistes d’audit (Audit trails) ? | À construire. Chaque décision du modèle (OUI/NON) doit être horodatée avec l’ID précis de la version du modèle utilisé pour garantir la traçabilité réglementaire. |
ÉTAPE 6 : Stratégies pour Obtenir la Meilleure Valeur (L’Architecture Finale)
La conclusion de cette planification permet d’établir des directives claires, justifiant techniquement chaque choix d’architecture :
- Confirmer que la donnée répond au besoin : Le croisement des logs internes et de l’historique télécom est jugé suffisant pour déduire une solvabilité sans accès bancaire.
- Sécuriser l’acquisition : Nécessite la mise en place d’une clé API sécurisée et de règles strictes de pare-feu (VPC/Security Groups) pour se connecter au système du partenaire.
- Faire correspondre le design à la donnée : L’utilisation d’un courtier de messages (Kafka) est obligatoire pour absorber les pics de requêtes de l’App (buffer) sans risquer de faire tomber la base de données interne.
- Équilibrer débit (throughput) et coût (FinOps) : Pour éviter une facture Cloud explosive due à un cluster de Streaming allumé en permanence, il faut configurer un filtrage strict à la source (le SDK mobile ne déclenche l’envoi de données que si l’utilisateur a explicitement validé les conditions générales).
- Simplifier l’accès métier : L’équipe Risque requêtera directement la “Zone Gold” du Data Lake via SQL, sans jamais avoir à se soucier de parser les JSON complexes de l’API d’origine.
- Garantir la gouvernance : Mise en place de rôles IAM (Identity and Access Management) stricts. Seul le compte de service du pipeline a le droit de lire les données brutes dans la zone Bronze avant l’étape de hachage et d’anonymisation.
Liens pertinents et Ressources
Pour approfondir les méthodologies utilisées dans ce projet :
- AWS Data Analytics Lens : Principes de conception pour l’analytique sur AWS (Well-Architected Framework)
- Architecture Medallion : Comprendre le modèle de données Bronze/Silver/Gold (Databricks)