Étude de cas · Data Engineer
Refondre la chaîne d'ingestion de données cloud d'une startup SaaS
Une startup qui édite un logiciel SaaS B2B repose sur une chaîne de données qui collecte chaque jour les rapports de consommation de plusieurs fournisseurs cloud, les transforme et les expose au produit. Construite vite, cette chaîne montrait ses limites : extractions partiellement prises en compte, dépassements de mémoire, tests instables. Un Senior Data Engineer freelance, que nous avons présenté, l'a fiabilisée puis refondue en quelques mois, à temps plein.
Par L'équipe Top Profil · Mis à jour le · 6 min de lecture
01
Une chaîne de données construite vite, devenue fragile
Le client est une startup éditrice d'un logiciel SaaS B2B. Son produit s'appuie sur une plateforme de données qui collecte les rapports de consommation et de facturation de plusieurs fournisseurs cloud, les normalise puis les transforme pour chacun de ses clients. La chaîne suit une architecture en couches : extractions brutes (bronze), données nettoyées (silver) et tables prêtes pour le produit (gold), écrites en Python avec pandas et orchestrées quotidiennement.
Construite au rythme d'une startup, cette chaîne atteignait ses limites. La couche silver ne prenait en compte que la dernière extraction bronze, au risque d'ignorer des sessions intermédiaires. Les transformations en mémoire provoquaient des dépassements (OOM) sur les volumes les plus importants. La suite de tests échouait de façon aléatoire et accumulait les avertissements, ce qui freinait chaque mise en production.
L'équipe tech, de taille réduite, cherchait un Data Engineer senior capable de reprendre cette plateforme sans arrêter le service, de la moderniser et de la refondre périmètre par périmètre. La commande portait sur un pipeline ELT complet en Python et SQL, orchestré avec Kestra, testé, intégré à la CI/CD et documenté, ainsi que sur un modèle analytique partagé et un cadre de qualité des données. Nous avons présenté un profil évalué sur ce type de refonte et sur sa pratique de l'IA ; il a démarré à temps plein.
02
Les enjeux
Technique : refondre sans interrompre
La chaîne alimente le produit chaque jour. Toute refonte devait coexister avec l'existant, être validée à l'identique sur les mêmes données, puis basculée environnement par environnement, du développement à la production.
Qualité : une base saine avant la réécriture
Une suite de tests instable et des dépendances en retard rendaient chaque changement risqué. Fiabiliser l'outillage était un préalable à toute évolution de fond.
Performance : tenir les volumes
Les dépassements de mémoire sur les transformations pandas bloquaient certains périmètres. La refonte devait traiter les volumes actuels et absorber les prochains fournisseurs cloud sans nouvelle réécriture.
03
La démarche, mois après mois
- 01
Prendre en main et mettre à niveau
Les premières semaines ont servi à configurer l'environnement, à migrer une table de paramétrage liée à l'onboarding des clients et à engager la migration de pandas de la version 2 à la version 3, avec validation fonctionnelle des résultats. Cette migration a été mise en production dès le deuxième mois.
- 02
Fiabiliser l'ingestion et les tests
La couche silver a été rendue multi-sessions : elle intègre désormais toutes les extractions bronze depuis la dernière intégration réussie, et non plus seulement la dernière. Le périmètre cloud a été livré et testé en staging. En parallèle, les échecs aléatoires de la chaîne de tests ont été corrigés, les avertissements nettoyés et l'outillage renforcé : intégration de Ruff, durcissement de mypy, mise à jour des dépendances et preuve de concept d'une migration vers uv, Pyrefly et Python 3.14.
- 03
Redessiner le flux cloud
Le flux cloud a été redessiné avec une couche intermédiaire supplémentaire entre silver et gold, documentée. Les environnements de développement et de staging ont été fusionnés et des tests iso-legacy, qui comparent la nouvelle chaîne à l'ancienne, validés. Un second périmètre de données a reçu un filtrage par pays et par site. La dette technique a été traitée au passage : fin de la migration pandas 3, normes de typage et de dates, chargement atomique des tables de paramétrage.
- 04
Généraliser et accélérer en SQL
Deux nouveaux modes de collecte, l'un fondé sur la dépense, l'autre sur une API au format standardisé, ont été implémentés et fusionnés en staging. La chaîne quotidienne a été rendue générique par couple collecteur et fournisseur. Les transformations silver et gold sont passées en SQL exécuté par DuckDB, ce qui a mis fin aux dépassements de mémoire. L'aval a été rebranché sur la nouvelle chaîne en staging et les tests iso-legacy validés sur une vingtaine de couples client et fournisseur.
- 05
Outiller, exploiter, préparer la production
Le serveur S3 de test a migré de MinIO vers RustFS, les suites de tests s'exécutent en parallèle, une fuite de connexions PostgreSQL et des bornes de fenêtres de dates ont été corrigées. Côté run, un incident de mémoire sur un flux de tags en staging a été traité et les couches bronze et silver réparées. La mise en production de la nouvelle chaîne est en cours, avec validation iso-legacy, traitement des écarts remontés par tickets, durcissement du typage et ajout d'un quatrième fournisseur cloud.
04 · IA
L'IA dans cette mission
Avant la mission, nous avons évalué la pratique de l'IA du freelance, critère éliminatoire chez nous. En entretien technique, en partie en partage d'écran, il a montré les assistants qu'il utilise sur du code Python et SQL, et surtout la manière dont il relit un pipeline généré : idempotence, doublons et valeurs nulles, coût mémoire des transformations. Il a décrit ses garde-fous sur la donnée : accès en lecture seule, environnements séparés, validation humaine avant toute écriture en production. C'est cette exigence sur le code, généré ou non, que la mission a confirmée.
05
Ce que l'équipe a obtenu
- Migration vers pandas 3 menée à terme et mise en production dès le deuxième mois, avec les normes de typage et de dates qui l'accompagnent.
- Couche silver multi-sessions livrée pour le périmètre cloud : plus aucune extraction intermédiaire ignorée depuis la dernière intégration réussie.
- Nouvelle chaîne cloud générique par couple collecteur et fournisseur, transformations en SQL DuckDB, fin des dépassements de mémoire, validée iso-legacy en staging et documentée.
- Suite de tests stabilisée et parallélisée, outillage modernisé et correctifs de fond livrés (connexions PostgreSQL, fenêtres de dates).
FAQ
Vos questions sur cette mission
Un Data Engineer senior, à l'aise en Python et en SQL, qui a déjà refondu un pipeline en production sans l'arrêter. Dans ce cas, la capacité à fiabiliser d'abord (dépendances, tests, outillage) puis à refondre périmètre par périmètre a compté davantage que la connaissance d'un orchestrateur précis.
En faisant coexister l'ancienne et la nouvelle chaîne, puis en comparant leurs sorties sur les mêmes données : ce sont les tests iso-legacy de cette mission. La bascule se fait ensuite environnement par environnement, du développement au staging puis à la production, en traitant les écarts remontés avant de retirer l'ancienne chaîne.
Les transformations en mémoire avec pandas atteignaient les limites de la machine sur les volumes les plus importants. DuckDB exécute du SQL analytique depuis un projet Python existant et sait déborder sur disque lorsque la mémoire ne suffit plus. Dans cette mission, ce passage a mis fin aux dépassements de mémoire.
Nous présentons 1 ou 2 profils évalués en moins de 48h ; le démarrage dépend ensuite de la disponibilité du freelance, en général une à trois semaines. Le cadre contractuel reste simple : un seul interlocuteur, un contrat et une facturation portés par nous, et un suivi régulier de la mission.
Étude rédigée par L'équipe Top Profil.
Publiée le , mise à jour le .
Un besoin proche de cette mission ?
Précisez votre contexte. Un expert Top Profil vous rappelle sous 1 jour ouvré.