Pré-calculer les réponses récurrentes
Sortir la lecture répétée des fichiers du chemin de la demande et réutiliser les statistiques stockées.
Architecture de données d’ingénierie · responsabilité technique
Base analytique des essais en vol
Une plateforme analytique PostgreSQL qui transforme les questions récurrentes sur l’historique complet des vols d’essai en requêtes indexées, avec ingestion automatisée et package Python partagé.
Responsabilité technique
Responsable technique depuis la première conception.
Fin 2022première version livrée
400–500vols à l’origine du besoin
~30 000Event Markers à l’échelle initiale
~800voies dans la conception initiale
01 — Le verrou technique
Les vols étaient indexés. L’historique de leurs signaux ne l’était pas.
À mon arrivée dans l’analyse des données d’essais en vol en juin 2022, une petite base SQLite reliait déjà les numéros de vol aux fichiers enregistrés et à quelques métadonnées. Ce catalogue était utile, mais il ne pouvait pas indiquer où un signal avait atteint son maximum historique ni si un seuil avait déjà été dépassé.
Chaque demande imposait encore d’ouvrir tous les fichiers concernés, de charger les voies demandées, de calculer le résultat et de recommencer sur des centaines de vols. Le temps augmentait fortement avec le nombre de signaux : les extractions Python importantes prenaient souvent, d’après les estimations rétrospectives, quatre à cinq heures, les plus volumineuses pouvaient approcher dix heures, et certaines analyses DIAdem tournaient toute la nuit.
Ces durées sont des ordres de grandeur rétrospectifs, pas des benchmarks réalisés à l’époque. La contrainte essentielle était que chaque nouvelle question relisait le même historique brut.
02 — Initiative personnelle
Stocker des statistiques réutilisables au lieu de rouvrir chaque fichier.
Vers septembre–octobre 2022, quelques mois après mon arrivée comme ingénieur à plein temps, j’ai commencé de ma propre initiative à concevoir une base analytique. Ce n’était ni une mission formelle de l’IT ou du management, ni un projet qui m’avait été attribué : l’idée venait de ce verrou récurrent. La première version a été mise en œuvre fin 2022.
L’ingestion automatisée pré-calcule les statistiques des signaux et conserve leur contexte de vol et d’Event Marker dans PostgreSQL. Les extrema historiques, dépassements de seuil et emplacements exacts sont ensuite accessibles sans relire toute la campagne.
Modèle d’ingénierieVol → Event Marker → données système organisées par ATA
Les Event Markers proviennent des opérations d’essais en vol : l’équipage marque dans les données enregistrées le début et la fin des conditions d’essai. La base utilise ce contexte sans limiter les recherches historiques aux seuls points stabilisés.
03 — Architecture
Pourquoi PostgreSQL, et pourquoi ce modèle de données.
J’ai d’abord envisagé d’étendre SQLite. Mais un prototype représentait déjà environ 400–500 vols, quelque 30 000 Event Markers et près de 800 voies. Stocker des statistiques pré-calculées à cette échelle exigeait un système relationnel plus vaste et durable.
Après avoir étudié les solutions disponibles, j’ai choisi PostgreSQL : une plateforme open source, mature et adaptée au volume attendu sans complexité excessive. Il s’agissait de ma décision technique, pas du résultat d’un comité d’architecture formel.
Le schéma suit le domaine d’ingénierie. Les vols contiennent les Event Markers opérationnels ; en dessous, les tables indexées sont réparties par système aéronef et chapitre ATA. Cette structure évite une table monolithique et reste alignée sur les sous-systèmes utilisés dans l’analyse.
04 — Flux analytique
Du vol traité à un historique réutilisable.
- 01
Le vol traité et ses Event Markers enregistrés sont disponibles
- 02
L’ingestion lit les voies d’ingénierie disponibles
- 03
Les statistiques sont calculées avec le contexte du vol et de l’Event Marker
- 04
Les résultats sont insérés dans des tables PostgreSQL indexées et organisées par ATA
- 05
Des règles peuvent identifier le vol avant, le vol stationnaire, la montée et la descente
- 06
Les ingénieurs sélectionnent vols et signaux depuis Python ou SQL
L’ingestion s’exécute dans l’infrastructure plus large des opérations de données d’essais en vol. Cette base constitue l’historique analytique construit à partir des données traitées.
05 — Décisions d’ingénierie
Conserver le contexte opérationnel
Utiliser les Event Markers enregistrés par l’équipage pour localiser les conditions sans réduire l’historique aux seuls points stabilisés.
Répartir par domaine d’ingénierie
Organiser les données par chapitre ATA afin que le modèle relationnel reste lisible au fil des campagnes.
Classer avec des règles explicites
Une couche par arbre de décision / règles applique des critères de stabilité, de niveau et d’état de vol ; il ne s’agit pas d’une prétention de machine learning.
06 — Échelle et performance
Des périmètres vérifiés, pas des totaux gonflés.
Les chiffres ci-dessous décrivent le contexte initial et une analyse ultérieure vérifiée. Ils ne sont pas présentés comme des totaux actuels de la base.
- 400–500 vols
- ~30 000 Event Markers
- ~800 voies
- 50–100 en général
- ~30 sur certains vols courts
- 150–200 sur certains vols complexes
Processus observé
- Avantplusieurs heures ou une nuit
- Positions historiquesrenvoyées en quelques secondes
- Étude thermique~10–15 s par capteur
Limite de mesure : il n’existe pas de benchmark universel avant/après. Les anciens temps dépendaient du nombre de vols et de voies ; ce sont des estimations rétrospectives.
Pour une étude de températures de fuselage liée à la certification et couvrant environ 900–1 000 vols de deux prototypes, un capteur pouvait être extrait en 10–15 secondes environ. Reproduire cette analyse précise avec l’ancien processus de type DIAdem aurait, selon l’estimation, nécessité un long week-end d’environ quatre jours ; il ne s’agit pas d’un benchmark formel.
07 — Pérennité opérationnelle
Conçue pour rester utilisable au-delà de son auteur.
La responsabilité dans la durée couvre le modèle, l’ingestion, les accès, la restauration et les anomalies propres aux historiques réels d’essais en vol.
Accès
Des identifiants distincts existent en lecture et en écriture ; les secrets applicatifs restent dans des fichiers .env non versionnés.
Contrôle des écritures
Les opérations d’écriture Python sont en plus limitées selon le poste et le contexte utilisateur authentifiés.
Restauration
Des sauvegardes automatiques chaque soir font partie des opérations de données ; les vingt plus récentes environ sont conservées.
Maintenance
L’évolution du schéma, les problèmes d’ingestion, la configuration des accès, la maintenance et les mises à niveau PostgreSQL restent sous ma responsabilité technique.
Les contrôles sont décrits à leur niveau réel : identifiants de base, vérifications applicatives et sauvegardes opérationnelles — pas SSO d’entreprise ni plateforme IAM distincte.
08 — Accès Python et adoption
Un outil individuel devenu une infrastructure d’équipe.
Pendant près d’un an, j’ai été l’utilisateur principal. La rapidité des extractions a progressivement dirigé davantage de demandes vers moi, créant un nouveau goulot d’étranglement. À partir de début 2024, les autres ingénieurs de l’analyse des données d’essais en vol ont commencé à interroger eux-mêmes le système.
J’ai structuré la couche d’accès en package Python documenté dans le dépôt Git de l’équipe. Installé avec pip en mode éditable et mis à jour par le processus du dépôt partagé, il fournit des fonctions simples pour sélectionner signaux et vols et restituer les données directement dans Python. J’ai aussi fourni des exemples SQL, des instructions PostgreSQL / pgAdmin et un accompagnement sur les accès.
Les utilisateurs directs appartiennent à l’analyse des données d’essais en vol. Le bureau d’études et les autres métiers demandent généralement une extraction et reçoivent des CSV, graphiques, tableaux d’extrema ou historiques détaillés, sans interroger eux-mêmes PostgreSQL.
09 — Usage d’ingénierie
Les questions historiques sont devenues des analyses courantes.
La base permet de retrouver extrema, dépassements de seuil, valeurs atypiques et le vol ou l’Event Marker exact d’une condition. Elle peut aussi localiser un vol à partir d’une valeur dont un ingénieur se souvient et fournir l’historique détaillé nécessaire pour expliquer un point inhabituel.
Dans l’exemple des températures de fuselage, les manœuvres classées par règles ont servi à comparer environ 10–15 capteurs par type de manœuvre sur quelque 900–1 000 vols, à identifier extrema et valeurs atypiques, puis à extraire les historiques des points à expliquer. Ces résultats ont soutenu l’évaluation de l’exposition thermique et de la représentativité d’une condition dans le spectre d’utilisation de l’aéronef.
La base est une source analytique pour les investigations liées à la certification. L’analyse des données d’essais en vol fournit jeux de données, graphiques et investigations d’anomalies ; le bureau d’études ou les ingénieurs système restent responsables des systèmes, des conclusions d’ingénierie et des rapports de certification.
10 — Mon rôle
Responsable technique depuis la première conception.
J’ai identifié le verrou, étudié l’architecture et mis en œuvre la première version PostgreSQL fin 2022. J’ai conçu le schéma et son indexation, développé l’ingestion et le package d’accès Python, puis accompagné mes collègues avec documentation, exemples et support direct.
Je reste responsable de l’architecture, de l’évolution du schéma, de l’ingestion, de la maintenance, des accès, des sauvegardes et de la capacité de restauration, des mises à niveau PostgreSQL, du support utilisateur et de l’analyse des anomalies de données. Le système est ainsi passé d’une solution individuelle à une infrastructure d’équipe récurrente.
La frontière compte : il s’agit d’un projet d’ingénierie et d’architecture de données lancé de ma propre initiative, pas d’une mission de gestion de projet. Je suis responsable de la plateforme analytique ; le bureau d’études et les ingénieurs système restent responsables de leurs rapports de certification et des conclusions tirées des analyses fournies.
11 — Enseignements d’ingénierie
Retirer le travail répété du chemin de la demande
Le pré-calcul a changé le mode d’accès à l’origine du délai, au lieu d’optimiser encore le même balayage de fichiers.
Modéliser le domaine d’ingénierie
Les vols, Event Markers opérationnels et systèmes ATA structurent mieux l’analyse qu’une table générique de mesures isolées.
L’adoption exige une couche d’accès
Le package Python partagé, la documentation et l’accompagnement ont transformé une base utile en infrastructure d’équipe.