Les dépendances avant la priorité
Un Limit Report prioritaire ne peut pas démarrer avant la réussite du post-traitement. Dès que cette dépendance est levée, il devient immédiatement éligible — même lorsque plusieurs vols sont en file.
Système d’ingénierie en production · responsabilité technique
Opérations de données d’essais en vol
Une plateforme qui transforme les données arrivant après l’atterrissage en résultats d’ingénierie priorisés et traçables — sans qu’un ingénieur ait à orchestrer chaque étape de traitement.
Responsabilité technique
Architecture, développement et exploitation quotidienne de la plateforme d’orchestration ; intégration d’outils spécialisés et de logique d’ingénierie développés par des collègues.
Depuis 2022en évolution continue en production
~15tâches planifiées par vol
700+vols traités depuis l’origine
~50 Gode données brutes par heure de vol
01 — Le problème opérationnel
L’humain était le moteur du processus.
L’instrumentation d’essais en vol (FTI) convertit les enregistrements bruts de l’appareil — au format d’enregistreur Chapter 10 — en TDMS, le format de fichiers de mesure lu par les outils d’analyse. À partir de là, un ingénieur de l’analyse des données d’essais (FTDA) devait encore sélectionner les fichiers, lancer les traitements dans DIAdem — l’environnement d’analyse de mesures utilisé par l’équipe — et ses scripts VBS, attendre, démarrer les rapports et les calculs de fatigue, puis surveiller chaque passage de relais.
Le coût principal n’était pas le nombre de clics. La latence humaine entre les étapes, les tâches oubliées, l’exécution séquentielle et la faible visibilité sur l’état d’avancement devenaient d’autant plus risquées que davantage de traitements étaient automatisés et que plusieurs vols ou prototypes pouvaient être actifs.
Le modèle d’exploitation visé est devenu clair : l’automatisation exécute le travail déterministe ; l’ingénieur de permanence supervise les exceptions et les décisions d’ingénierie.
02 — Évolution
Construite par étapes, au rythme de la réalité opérationnelle.
Ce travail n’a jamais été lancé comme un programme de plateforme formalisé. Chaque génération a répondu à la contrainte suivante révélée en production.
- 2022
Scripts manuels → interface centrale
Une interface unique a remplacé la sélection répétée de fichiers, le chargement de scripts et l’enchaînement manuel des quatre ou cinq premiers traitements.
- 2024–25
Interface → déclenchement automatique
Le déclenchement sur nouveau vol a remplacé la supervision active, et le post-traitement principal est passé de VBS à Python.
- T1 2026
Orchestration persistante
PostgreSQL, un Planner et un Worker ont introduit un état durable, des priorités, des dépendances, l’exécution parallèle et des échecs visibles.
- Juin 2026
Exploitation distribuée sur le terrain
Le même modèle d’exploitation a soutenu une campagne d’essais en vol délocalisée, après des essais préparatoires sur site et réseau.
03 — Architecture actuelle
Un état persistant rend le processus visible et rattrapable.
Les définitions de tâches et les priorités sont décrites en configuration JSON. PostgreSQL conserve le travail planifié, son état, les dépendances, l’affectation au Worker et le détail des échecs. Un Worker en exécution continue ne sélectionne que le travail éligible au regard des contraintes de priorité, de dépendance et d’exécution.
La base de données est la référence opérationnelle — et non une file en mémoire — ce qui permet à l’équipe d’inspecter, de rattraper et de relancer un traitement sans avoir à reconstituer ce qui s’est passé.
Architecture actuelle du traitement des données d’essais en vol
- 01Livraison FTI
Le Chapter 10 est converti manuellement en TDMS brut, déposé sur le stockage partagé, puis suivi d’un déclencheur sur dossier.
- 02Planner Python · scan toutes les ~3 minutes
Vérifie le nommage, la cohérence des sources et les informations de vol associées, puis planifie une quinzaine de tâches.
- 03PostgreSQL
Conserve priorités, dépendances, état d’exécution, affectation, traçabilité et erreurs Python.
- 04Worker Python
Verrouille le travail éligible et exécute d’abord les tâches critiques, en parallèle les tâches indépendantes, et de nuit celles de moindre priorité.
- 05Sorties et exploitation
Rapports, données décodées et jeux de données d’ingénierie sont restitués avec l’état sur tableau de bord, des notifications bureau et des commandes de relance.
04 — Décisions d’ingénierie
Un ordonnancement calé sur l’urgence d’ingénierie.
Parallélisme encadré
Des tâches indépendantes peuvent s’exécuter pendant le Limit Report, qui dure environ 45 minutes, tandis que des règles de concurrence explicites protègent les opérations sensibles de génération de rapports et de PDF.
Travail immédiat ou nocturne
Les livrables d’ingénierie critiques passent en premier. La maintenance du stockage et de la base peut attendre la nuit, ou être repriorisée manuellement si l’exploitation l’exige.
Exploitabilité plutôt que complexité
La conception accepte plusieurs Workers, mais l’exploitation normale utilise délibérément un Planner et un Worker sur la même machine, pour une équipe de trois personnes.
05 — Vérification et exploitation
Tester le processus, préserver la logique d’ingénierie validée.
Les évolutions majeures d’orchestration sont éprouvées sur des vols historiques, dans des dossiers contrôlés, avec des déclencheurs simulés et des sorties connues, avant un déploiement en production suivi de près.
Lorsque c’est la logique de traitement elle-même qui change — comme lors de la migration de VBS vers Python — les sorties sont comparées directement à celles de l’implémentation établie. Cela sépare la validation du processus de celle des algorithmes d’ingénierie.
En cas d’échec, le compteur du tableau de bord s’incrémente, l’ingénieur de permanence reçoit une notification bureau et la trace d’erreur Python est enregistrée dans PostgreSQL pour investigation et relance.
06 — Campagne délocalisée
Les capacités critiques restent près de l’appareil.
Un serveur de campagne peut exécuter un Planner et un Worker locaux tout en partageant le modèle d’exploitation PostgreSQL avec le site principal. L’affectation des Workers et les priorités déterminent où chaque tâche s’exécute, avec une réaffectation locale possible lorsque la connectivité empêche le traitement central.
- Traiter sur placeLe post-traitement, le Limit Report et le décodage du bus avionique ARINC 429 peuvent s’exécuter sur le site de campagne.
- Compresser et vérifierLes données sont compressées et une empreinte BLAKE3 est calculée avant transfert.
- Poursuivre au centralAprès décompression et vérification de l’empreinte sur le site principal, les tâches restantes se poursuivent sur le Worker central.
Preuve opérationnelle : des tests préparatoires de site et de réseau, puis une campagne d’essais en vol délocalisée en juin 2026, sans défaillance majeure de la plateforme.
07 — Un impact mesuré et défendable
Moins de latence, un retour d’ingénierie plus tôt.
Le gain principal est la fiabilité du flux : l’enchaînement automatique supprime les temps d’attente humains, le parallélisme évite qu’une tâche longue bloque des sorties sans rapport, et les échecs deviennent immédiatement visibles.
La comparaison entre environ une heure et deux heures reflète plusieurs changements d’architecture et d’implémentation, et non un facteur unique mesuré. Un Limit Report disponible plus tôt peut révéler un besoin d’inspection avant la fin de la journée et préserver le créneau de vol suivant.
Les trois opérateurs et les 50 à 75 utilisateurs d’ingénierie sont deux groupes distincts : trois ingénieurs exploitent la plateforme, tandis qu’une population d’ingénierie plus large consomme ce qu’elle produit. Ces chiffres ne s’additionnent pas et ne recouvrent pas les mêmes populations que celles de l’étude de cas sur l’intégration de l’infrastructure.
08 — Mon rôle
Responsabilité technique et opérationnelle de bout en bout.
J’ai initié la première interface, conçu le processus automatique et l’architecture Planner / Worker / PostgreSQL, et développé environ 99 % du code de la plateforme. J’ai également réalisé la plupart des traitements intégrés, le tableau de bord, le File Manager, le Cloud Uploader et l’architecture des campagnes délocalisées.
La responsabilité se poursuit après le déploiement : je recueille les retours des opérateurs, définis les améliorations, teste et déploie les générations majeures, prépare la documentation, forme mes collègues et assure le support en production auprès des interfaces FTDA, FTI, ingénierie d’essais en vol, ingénierie spécialisée et infrastructure.
La frontière compte : j’ai conçu et développé la plateforme d’orchestration et la plupart des traitements, en intégrant des outils spécialisés et des logiques d’ingénierie produits par des collègues. Il s’agit d’une responsabilité technique et de plateforme, non de la paternité de chaque algorithme ni d’une gestion de programme formelle.
09 — Ce que son exploitation m’a appris
L’architecture suit l’exploitation
Le système n’est passé d’une interface pratique à une orchestration persistante puis distribuée que lorsque les conditions d’exploitation justifiaient chaque étape.
L’observabilité change le métier
Un état durable, des échecs visibles et des notifications permettent à une petite équipe de superviser des exceptions au lieu d’accompagner en continu chaque traitement.
La simplicité d’exploitation est un choix de conception
Conserver la capacité multi-Workers tout en colocalisant le Planner et le Worker courants a rendu la plateforme plus simple à exploiter pour trois opérateurs directs.