J’ai reproduit de bout en bout le système que la NASA utilise pour recevoir et traiter les photos et les données environnementales du rover Perseverance sur Mars. Ce n’est pas un notebook d’exemple : c’est un vrai pipeline de données, avec le protocole spatial authentique, qui tourne avec des données générées en continu.

Le problème

Chaque fois que le rover Perseverance prend une photo ou mesure la température sur Mars, ces données voyagent encapsulées dans un protocole spatial réel (CCSDS), traversent entre 3 et 22 minutes d’espace jusqu’à la Terre, et ce n’est qu’à ce moment qu’une équipe d’ingénierie les reçoit, les valide, les calibre et les transforme en données exploitables par les scientifiques. J’ai voulu construire ce système complet : non pas une simulation de jouet, mais l’architecture qu’utiliserait une équipe data professionnelle pour résoudre ce problème.

Système d’information – Architecture

Ce que j’ai construit

• Le vrai protocole, pas une version inventée : un simulateur qui encapsule images et télémétrie exactement comme le standard CCSDS 133.0-B-2 le spécifie, avec la somme de contrôle CRC-16.
• Une architecture Medallion complète : les données passent par les couches Raw → Bronze → Silver → Gold, chacune avec sa responsabilité. Rien n’est validé deux fois, aucune étape n’est sautée.
• Détection automatique des anomalies : le système contrôle chaque mesure de température, de pression et de vent, et signale celles qui sortent des seuils, sans que personne ait à examiner un tableau à la main.
• Tout versionné comme du code : pas seulement le pipeline. Le tableau de bord de supervision et l’infrastructure cloud vivent aussi dans le dépôt, et ne sont pas assemblés à la main dans une interface.
• Infrastructure hybride : fonctionne en local avec Docker, et dispose de la variante AWS (Terraform) prête à être déployée selon le coût réel de chaque service.

AWS – architecture diagram

La preuve

Le tableau de bord n’affiche pas de données d’exemple : la courbe de température reproduit la forme réelle du modèle physique de Mars (minimum avant l’aube, maximum après midi solaire martien), générée par le simulateur lui-même et traitée par le pipeline complet jusqu’à l’écran.

Orchestration avec Airflow

Une histoire vraie : comment j’ai failli perdre le tableau de bord (et pourquoi ça n’arrivera plus)

J’ai construit le tableau de bord de supervision directement dans l’interface de Grafana. Il semblait terminé. Le lendemain, les panneaux avaient disparu : il ne restait que le titre. La cause réelle : rien de la configuration de Grafana n’était enregistré sous forme de code, donc tout ne vivait que dans un volume interne qu’un simple redémarrage pouvait effacer, sans avertissement. La solution n’a pas été de refaire les panneaux à la main une deuxième fois. J’ai traité le tableau de bord comme n’importe quelle autre partie du système : je l’ai écrit sous forme de fichiers versionnés (datasource.yml, le JSON du tableau de bord) qui se reconstruisent automatiquement à chaque démarrage du service. Désormais, un redémarrage, un changement de machine ou la perte du disque ne supprime plus des mois de travail de configuration.

Méthodologie : Spec-Driven Development

Tout le projet a été construit selon une méthodologie de développement piloté par les spécifications : chaque fonctionnalité est spécifiée, planifiée et testée avant d’être implémentée, selon une constitution de 8 principes non négociables (fidélité au domaine réel, architecture Medallion sans raccourcis, vérification réelle par tests automatisés, aucun secret écrit en dur, entre autres). C’est ainsi que j’apprends à travailler avec des agents d’IA sur des projets réels : l’agent accélère l’écriture du code, mais la compréhension, les décisions d’architecture et la validation restent de mon ressort.

Stack technique

Python · Apache Kafka · Apache Airflow · dbt · PostgreSQL/PostGIS · Docker · Terraform · AWS · Grafana · GitHub Actions

Voir le dépôt complet sur GitHub