Intégration technique post-acquisition · aperçu non confidentiel
Définition des exigences côté ingénierie, sélection de l’architecture et coordination de la mise en œuvre pour intégrer l’environnement d’analyse des données d’essais en vol de Kopter à l’écosystème IT d’entreprise de Leonardo — sans suspendre les essais en vol.
01 — Contexte et déclencheur
Après l’acquisition de Kopter par Leonardo, l’IT d’entreprise a lancé une initiative globale de rationalisation des services IT, des ordinateurs portables, des centres de données et de l’infrastructure entre les entités — principalement pour supprimer les systèmes redondants et déclasser l’infrastructure de centre de données suisse existante. Le projet relevait de l’intégration post-acquisition et de l’efficience budgétaire, et non d’une lacune de cybersécurité du côté de Kopter.
L’environnement d’analyse des données d’essais en vol (FTDA) fonctionnait toutefois sous des contraintes fondamentalement différentes de l’IT bureautique : soutenir les campagnes d’essais exigeait une autonomie administrative locale, des chaînes de traitement Python spécifiques, la planification automatisée de tâches et une mise à disposition rapide des données de vol aux équipes d’ingénierie.
En tant que point focal IT désigné de l’équipe FTDA, j’ai représenté l’ingénierie des essais en vol dès la phase de cadrage. L’objectif de référence était clair : préserver et améliorer toutes les capacités opérationnelles nécessaires aux essais en vol à l’intérieur de l’environnement d’entreprise Leonardo, sans aucune interruption opérationnelle.
Il s’agit d’un effort pluriannuel et non d’une bascule ponctuelle : le cadrage a débuté fin 2023, les premières versions des exigences et les entretiens avec les consultants se sont déroulés au premier semestre 2024, la mise en œuvre technique a démarré autour de juin 2024, et les travaux d’architecture, de migration et de déploiement se sont poursuivis en 2025 et 2026. L’environnement est en exploitation, plusieurs points d’intégration restant à finaliser.
02 — Contraintes opérationnelles
Migrer directement les systèmes FTDA dans l’IT d’entreprise standard était impraticable. FTDA avait besoin d’accès distant aux serveurs, d’installations souples de logiciels et de paquets Python, d’automatisations de tâches planifiées, de privilèges administrateur pour l’ingestion des données, de gestion de certificats pour les tableaux de bord internes et d’une connectivité étroite avec l’instrumentation d’essais en vol (FTI).
Les politiques d’entreprise interdisent strictement les privilèges administrateur locaux sur les postes gérés. Passer par des tickets au support IT pour des scripts d’ingénierie et des tâches planifiées de routine a été envisagé, mais un modèle par tickets était incompatible avec le volume et le rythme du développement de scripts et d’outils dont dépendent au quotidien les opérations d’essais.
De plus, pendant les campagnes de développement, les données devaient parvenir à l’ingénierie Leonardo dans un délai d’environ 2 heures après l’atterrissage, pour permettre les décisions go/no-go des vols suivants. L’enjeu central était donc de trouver un modèle architectural et opérationnel satisfaisant des règles strictes de cybersécurité sans étouffer l’agilité d’ingénierie.
03 — Arbitrages d’architecture
Environnement d’entreprise entièrement géré. Il apportait l’intégration aux services corporate, mais restreignait les privilèges administratifs nécessaires à l’automatisation FTDA : tâches planifiées, outillage Python spécifique et développement agile de scripts.
Réseau d’ingénierie isolé, détaché physiquement et logiquement des systèmes d’entreprise. Il préservait toute l’autonomie opérationnelle, mais créait un îlot sans liaison directe aux services Leonardo, entravant fortement la distribution des données et la collaboration à distance.
L’architecture cible retenue. Un modèle Leonardo déjà établi offrant une zone d’ingénierie cloisonnée avec autonomie administrative locale, reliée aux services d’entreprise par des pare-feux strictement gouvernés et des chemins supervisés.
Le Leonardo Business Network (LBN) était une architecture d’entreprise déjà établie. Sur la base des exigences opérationnelles FTDA, j’ai évalué les trois options et sélectionné le LBN comme solution pour l’ingénierie des essais en vol. Les équipes spécialisées de Leonardo ont porté et mis en œuvre le réseau d’entreprise, le routage, les bureaux virtuels et les politiques de pare-feu, tandis que je portais les exigences côté ingénierie, la validation technique et le mappage du pare-feu FTDA local.
Modèle d’exploitation retenu
Le modèle LBN retenu conserve les capacités spécialisées d’essais en vol dans un environnement cloisonné et les relie aux services d’entreprise Leonardo par des interfaces gouvernées. Antoine portait les exigences, la sélection, la validation et la coordination côté ingénierie ; les équipes spécialisées Leonardo portaient la mise en œuvre de l’infrastructure d’entreprise.
LBN
Leonardo
Résultats d’essais en vol approuvés
04 — Évolution du rôle et responsabilités
Des consultants externes avaient d’abord été engagés pour recueillir les besoins et explorer des solutions. Leur mission a ensuite pris fin. Après leur départ, aucun chef de projet ni de programme formel n’a été nommé pour piloter le volet FTDA. Sans titre formel de chef de projet, j’ai progressivement assuré de fait la coordination de la mise en œuvre : définition des jalons opérationnels, gestion d’un epic et de tâches Jira, suivi des points bloquants entre équipes matricielles, escalade des blocages, validation technique et pilotage de la bascule des utilisateurs.
05 — Mise en œuvre et gestion des dépendances
Après le départ des consultants, j’ai structuré le volet ingénierie autour d’une seule question opérationnelle : « Qu’est-ce qui doit fonctionner pour que nous puissions travailler comme avant ? »
La mise en œuvre a progressé par capacités fonctionnelles plutôt que selon un calendrier linéaire rigide, en s’appuyant sur une coordination ciblée, un suivi Jira et l’escalade — sans autorité hiérarchique — pour lever les dépendances entre l’IT d’entreprise, le réseau, la cybersécurité, le cloud et l’ingénierie.
Traduction des processus FTDA et FTI en critères techniques clairs d’autonomie administrative, de stockage, d’accès distant et de délai de mise à disposition.
Comparaison de trois modèles réseau aux besoins opérationnels et sélection du LBN comme équilibre viable entre sécurité et autonomie.
Intégration du matériel local et configuration du pare-feu FTDA pour le mappage d’adresses IP vers le réseau d’entreprise Leonardo.
Validation et déploiement de l’infrastructure de bureaux virtuels pour rétablir l’accès distant sécurisé des ingénieurs aux machines de traitement internes.
Spécification d’environ 100 To de capacité cloud et relance du déploiement cible au-delà des solutions temporaires, par escalade.
Coordination de la migration côté ingénierie du service central d’accès aux données DIAdem vers un nouveau serveur en centre de données d’entreprise, avec rétablissement des accès, des instructions de connexion et des licences pour ~50 ingénieurs en aval.
Maintien des accès historiques jusqu’à vérification des processus au regard de la liste de validation, rédaction de la documentation utilisateur et transition sans interruption.
Maintien de la responsabilité d’ingénierie pour les évolutions de l’environnement, les nouveaux utilisateurs, le renouvellement du matériel et le dépannage résiduel.
06A — Levée de blocage
Contexte : l’approbation de routine d’une exposition réseau essentielle pour la gestion de code et l’analyse est restée bloquée plusieurs semaines après le départ d’un approbateur de la chaîne, sans passation désignée.
Action : cartographie de la chaîne d’approbation multi-étapes entre cybersécurité et IT, localisation de la demande orpheline dans la file, remobilisation des responsables de département concernés et escalade jusqu’à la reprise du processus.
Résultat : déblocage du processus d’approbation et poursuite de l’exposition réseau demandée dans le circuit de gouvernance d’entreprise.
06B — Levée de blocage
Contexte : une solution temporaire de transfert de fichiers permettait de poursuivre les opérations quotidiennes, ce qui a conduit les équipes d’entreprise à déprioriser le déploiement du stockage cloud définitif.
Action : démonstration des limites opérationnelles et de l’inadéquation à long terme de la solution temporaire, maintien d’une pression technique constante et escalade du blocage jusqu’au niveau du CIO.
Résultat : rétablissement de la priorité pour le déploiement de la solution définitive d’environ 100 To de stockage cloud.
07 — Continuité opérationnelle
Les campagnes d’essais en vol ne pouvaient pas être suspendues pour une intégration IT. Maintenir la continuité opérationnelle était une exigence non négociable.
Plutôt qu’une bascule à haut risque, les ordinateurs portables et chemins réseau historiques ont été maintenus en parallèle du nouveau matériel d’entreprise.
L’exploitation en double équipement a ajouté une charge administrative temporaire, mais offrait un repli garanti. Les accès historiques ont été conservés jusqu’à la vérification des processus FTDA au regard de la liste de validation. La migration a été réalisée avec zéro interruption opérationnelle des essais en vol.
08 — Distribution contrôlée des données
Isoler l’environnement d’ingénierie du réseau bureautique standard impliquait de remplacer l’accès direct aux partages de fichiers par un chemin de distribution automatisé et conforme.
J’ai contribué à définir le processus sécurisé de distribution qui transporte les jeux de données de vol approuvés depuis les machines de traitement LBN locales vers le stockage cloud d’entreprise et les utilisateurs d’ingénierie en aval.
Les données d’essais sont ingérées et traitées dans la zone LBN, où l’autonomie administrative et les outils Python spécialisés sont préservés.
Les jeux de données traités sont automatiquement téléversés par des chemins sortants sécurisés vers l’environnement cloud d’entreprise.
Les paquets téléversés traversent la validation de sécurité d’entreprise et les contrôles d’accès avant publication vers les niveaux de consommateurs autorisés.
Les données approuvées sont servies à environ 50 spécialistes d’ingénierie utilisant DIAdem, et les rapports diffusés atteignent jusqu’à environ 200 destinataires plus larges.
Ce processus est volontairement non confidentiel : adresses internes, configurations de pare-feu, noms de tenants cloud, identifiants et produits de sécurité sont omis.
09 — Périmètre et échelle
Ces nombres d’utilisateurs désignent des groupes distincts à des niveaux d’usage différents et ne doivent pas être agrégés en un total artificiel ; ils ne recouvrent pas non plus la même population que les utilisateurs de données cités dans l’étude de cas sur les opérations de données d’essais en vol. Le matériel du périmètre (~15 serveurs et postes, ainsi que plusieurs plateformes de stockage) a été intégré et reconfiguré sur place plutôt que remplacé physiquement. L’architecture a préservé la capacité opérationnelle nécessaire pour mettre les données d’essais à disposition de l’ingénierie dans un délai d’environ deux heures après l’atterrissage.
10A — Responsabilité après livraison
Je reste le point focal d’ingénierie principal de l’environnement LBN : qualification des besoins, coordination du renouvellement du matériel, gestion des demandes de stockage et de pare-feu, et résolution des dépendances inter-domaines, comme l’authentification des partages dans des configurations à domaines mixtes.
10B — Réutilisation de l’architecture
L’approche d’intégration établie pendant la migration principale a ensuite été réutilisée pour un LBN portable hors site, répliquant l’architecture centrale pour soutenir une campagne d’essais prolongée loin du site principal.
11 — Ce que cette intégration a demandé
Le travail a consisté à transformer des exigences opérationnelles spécialisées en une décision d’architecture que les équipes spécialisées pouvaient mettre en œuvre, puis à faire avancer cette décision dans la gouvernance d’entreprise : jalons par capacités, relance continue des points bloquants, escalade quand les circuits d’approbation s’arrêtaient, validation technique au regard de critères opérationnels, et une bascule qui a laissé les essais en vol se poursuivre.
Le périmètre côté ingénierie était le mien ; le réseau d’entreprise, les bureaux virtuels et la mise en œuvre cloud relevaient des équipes spécialisées de Leonardo. Ce qui me reste ensuite, c’est l’environnement lui-même : ses évolutions, ses nouveaux utilisateurs et son dépannage résiduel.