Contexte : Construction d'une Data Platform opérationnelle en environnement multi-filiales

Le client

RATP Cap est une filiale du groupe RATP en charge de l'exploitation de délégations de service public (DSP) de transport urbain en Île-de-France. L'entreprise opère un portefeuille de filiales (bus, tramways, tram-train) avec des systèmes d'information hétérogènes et des obligations contractuelles de reporting envers Île-de-France Mobilités (IDFM).

État initial de l'infrastructure

RATP Cap ne disposait d'aucune infrastructure data structurée : absence de plateforme centralisée, absence d'équipe data constituée, et dépendance à des processus manuels pour la production d'indicateurs contractuels.

Points de blocage identifiés :

• Architecture monolithique inadaptée : L'infrastructure existante reposait sur un système unique et rigide nécessitant des tests de non-régression complets à chaque modification, paralysant toute évolution
• Absence de flexibilité : L'intégration de nouvelles sources de données imposait une conformité stricte à un framework central, rendant l'onboarding de nouvelles filiales impraticable
• Ressources insuffisantes : Équipe réduite à trois personnes en définition de besoins et un développeur, structure organisationnelle inadaptée à la croissance
• Risque contractuel : Production manuelle des indicateurs IDFM chronophage et exposition à des pénalités financières en cas de retard de livraison

Objectif technique
Déployer une Data Platform souveraine pour industrialiser l'ingestion de sources hétérogènes, automatiser la production des indicateurs contractuels IDFM, et fournir des dashboards opérationnels aux filiales, tout en garantissant la scalabilité nécessaire à l'intégration de nouveaux marchés.

Solution : Architecture modulaire avec frameworks d'ingestion découplés

Approche : Co-construction et expertise technique

Le projet a été structuré autour d'une approche collaborative combinant expertise technique externe et montée en compétences interne. L'architecture a été conçue pour garantir l'indépendance des flux et la pérennité des développements, avec un focus sur la maintenabilité à long terme et le transfert de compétences progressif vers les équipes internes.

Phase 1 : Fondations infrastructure & Data Engineering (Mois 1-3)

Déploiement de l'infrastructure data sur AWS avec mise en place des composants core de la plateforme.

Data Warehousing & Modélisation

• Déploiement de Snowflake comme Data Warehouse central
• Conception d'une architecture en couches respectant les principes de séparation des responsabilités :
  • Raw Layer : Ingestion brute des données sources sans transformation
  • Staging Layer : Nettoyage, typage et normalisation des données
  • Marts Layer : Modélisation métier et calcul des indicateurs contractuels (ponctualité, régularité, ponctualité voyageur)
• Les outils de restitution (BI) consomment exclusivement les Marts, sans logique de calcul côté front-end

Orchestration & Monitoring

• Déploiement d'Apache Airflow sur infrastructure AWS (ECS/Fargate)
• Configuration de DAGs pour l'orchestration centralisée des pipelines d'ingestion et de transformation
• Mise en place de mécanismes de monitoring, alerting et retry pour garantir la fiabilité des traitements
• Intégration d'Elementary pour l'observabilité et le suivi de la data quality

Data Integration & Architecture des flux

• Conception de frameworks Python modulaires et découplés par source de données
• Chaque framework d'ingestion est indépendant : modification, évolution ou décommissionnement d'un flux sans impact sur les autres
• Architecture opposée au système monolithique initial, permettant le développement en parallèle par plusieurs contributeurs
• Standardisation des patterns d'ingestion via templates réutilisables (connexion, extraction, gestion des erreurs, logging)

Infrastructure as Code & DataOps

• Provisionnement de l'infrastructure via Terraform pour garantir la reproductibilité et la traçabilité des configurations
• Intégration GitLab CI/CD pour l'automatisation des déploiements et la gestion des versions
• Mise en place de stratégies de branching et de pull requests pour assurer la revue de code

Phase 2 : Industrialisation & Cas d'usage métier (Mois 4-6)

Déploiement des couches de transformation et développement des premiers cas d'usage opérationnels pour les filiales.

Transformation & Data Quality

• Implémentation de modèles dbt Core pour la transformation des données du Raw au Staging, puis aux Marts
• Développement de tests de data quality automatisés (unicité, non-nullité, valeurs acceptées, cohérence inter-tables)
• Intégration de dbt dans les DAGs Airflow pour orchestrer les transformations après les ingestions
• Documentation automatique des modèles via dbt docs pour faciliter la compréhension et la maintenance

Développement des indicateurs contractuels IDFM

• Ponctualité : Calcul du pourcentage de courses respectant les horaires théoriques (seuils variables selon les contrats)
• Régularité : Mesure de l'écart entre les passages successifs théoriques et réels
• Ponctualité voyageur : Indicateur composite prenant en compte l'affluence et les retards perçus par les usagers
• Adaptation des calculs selon les typologies de réseaux (bus urbain, tramway, tram-train) et les spécificités contractuelles de chaque DSP

Business Intelligence & Restitution

• Développement de dashboards Qlik connectés aux Marts Snowflake
• Création de vues métier pour chaque filiale avec indicateurs opérationnels et contractuels
• Mise à disposition de rapports standardisés pour IDFM (export automatisé selon calendrier contractuel)

Mise en production

• Plateforme opérationnelle livrée après 6 mois avec les premiers cas d'usage en production
• Processus de validation métier avec les filiales pilotes avant généralisation

Phase 3 : Transfert de compétences & Autonomisation (Mois 7-12)

Montée en compétences des équipes internes et passage progressif en mode run autonome.

Constitution de l'équipe data interne

• Recrutement et onboarding de profils Analytics Engineer pour l'exploitation de la plateforme
• Formation des nouvelles recrues sur la stack technique (Snowflake, dbt, Airflow, Qlik)
• Transfert de compétences sur les frameworks d'ingestion et les patterns de développement

Réduction du périmètre Data Ops

• Passage progressif de la responsabilité opérationnelle (monitoring, incidents, maintenance) à l'équipe interne
• Concentration de l'accompagnement externe sur le développement de nouveaux cas d'usage métier
• Documentation complète de l'architecture, des processus de déploiement et des procédures d'incident

Montée en autonomie

• L'équipe interne assure désormais le développement de nouveaux indicateurs et l'intégration de nouvelles sources
• Capacité à onboarder de nouvelles filiales sans intervention externe
• Roadmap data pilotée en interne avec priorisation métier

Stack technique déployée

Cloud Provider : AWS

‍Orchestration : Apache Airflow (ECS/Fargate)

‍Data Warehouse : Snowflake

‍Transformation : dbt Core

‍Business Intelligence : Qlik

‍Observabilité : Elementary

‍Infrastructure as Code :Terraform

‍CI/CD : GitLab

‍LanguagesPython, SQL

Résultats mesurés

Performance technique

• Modularité opérationnelle : Les flux d'ingestion sont découplés. L'évolution d'un projet ne nécessite pas de tests de non-régression sur l'ensemble de la plateforme, réduisant considérablement le time-to-market pour l'intégration de nouvelles sources
• Maintenabilité : La standardisation via templates Python et dbt facilite l'onboarding de nouveaux développeurs et réduit les délais d'intégration sur les projets existants. Le taux de compréhension d'un flux par un nouveau contributeur est significativement amélioré
• Scalabilité : L'architecture supporte l'ajout de nouvelles filiales avec des systèmes sources hétérogènes (GMAO, aide à l'exploitation, commandes de service, main courante) sans refonte structurelle. Le coût marginal d'intégration d'une nouvelle filiale est réduit de manière significative
• Fiabilité : Les mécanismes de monitoring et d'alerting garantissent la détection rapide des anomalies et la reprise automatique en cas d'erreur

Impact organisationnel

• Automatisation des indicateurs contractuels : Suppression complète des processus manuels de production des rapports IDFM, élimination du risque de pénalités financières et réduction de la charge de travail des équipes opérationnelles
• Adoption métier : Taux d'utilisation croissant des dashboards par les filiales (consultation quotidienne par les directeurs d'exploitation), validant la pertinence des cas d'usage développés et la qualité des données restituées
• Reconnaissance direction : Validation en comité opérationnel transverse des solutions data déployées, avec mention explicite de la qualité des livrables et de la fiabilité de la plateforme
• Sécurisation de la feuille de route : L'équipe data dispose d'une plateforme stable et documentée permettant la concentration des ressources sur le développement de valeur métier (nouveaux indicateurs, analytics avancées) plutôt que sur la maintenance correctrice
• Autonomie stratégique : RATP Cap dispose d'une infrastructure data souveraine, ne dépendant plus d'outils ou de prestataires externes pour l'exploitation de ses données opérationnelles critiques

Conclusion

En 12 mois, RATP Cap a déployé une Data Platform opérationnelle de niveau entreprise à partir d'une feuille blanche. L'architecture modulaire par frameworks d'ingestion découplés, la rigueur de la modélisation Snowflake en couches (Raw / Staging / Marts), et la standardisation via dbt permettent l'intégration scalable de nouvelles filiales aux systèmes hétérogènes. La plateforme est dimensionnée pour supporter l'expansion de RATP Cap sur de nouveaux marchés (Tram & Bus, Transilien) sans refonte architecturale majeure. L'équipe interne constituée dispose des compétences techniques, de la documentation et des outils nécessaires pour opérer et faire évoluer la plateforme de manière autonome, positionnant RATP Cap comme un acteur mature sur les sujets data dans le secteur du transport public en Île-de-France.

‍