L'avionique, c'est l'endroit où l'aérospatiale rencontre le logiciel, et c'est l'exemple le plus clair de cette rubrique d'un domaine où la compétence adjacente se transpose moins facilement qu'il n'y paraît.
Pas du logiciel ordinaire avec des documents en plus
Une hypothèse courante veut que le logiciel embarqué certifié soit du logiciel normal, plus une charge de conformité. Cette hypothèse produit des recrutements ratés et des programmes qui échouent.
Quatre différences fondamentales.
Chaque ligne se rattache à une exigence. Le code existe parce qu'une exigence l'a demandé, et ce lien est documenté et revu. Un code qui fait quelque chose de sensé mais n'est pas rattachable à une exigence est une non-conformité.
La couverture de vérification doit être démontrée. Il faut démontrer que les tests exercent le code jusqu'à un niveau de couverture structurelle défini, qui augmente avec le niveau d'assurance. Cela façonne la façon dont le code est écrit, car les constructions complexes deviennent coûteuses à couvrir.
Le déterminisme est exigé. Le timing doit être prévisible et borné. L'allocation dynamique de mémoire, les boucles non bornées et les chemins d'exécution imprévisibles sont évités ou interdits selon le niveau.
Les outils eux-mêmes exigent une qualification. Si la sortie d'un outil est acceptée sans revue indépendante, l'outil doit être qualifié. Compilateurs, générateurs de tests et outils d'analyse en font tous partie.
Un ingénieur logiciel commercial compétent n'est pas automatiquement un bon ingénieur avionique. Les contraintes inversent plusieurs habitudes qui font un bon développeur ordinaire.
La conséquence pour le recrutement est précise : recruter des ingénieurs logiciels généralistes pour des postes certifiés en attendant un ajustement rapide sous-estime systématiquement la transition, et les ingénieurs eux-mêmes la trouvent souvent frustrante avant qu'elle ne devienne satisfaisante.
Ce que couvre cette direction
Le périmètre : électronique aéronautique, GPS, commandes de vol, communications et systèmes embarqués.
Quatre domaines.
Les systèmes de commande de vol. La chaîne depuis la commande du pilote ou du pilote automatique jusqu'au mouvement de la gouverne, y compris les architectures de commande électrique et leur redondance.
Les systèmes de navigation. Navigation par satellite, systèmes inertiels, données air, et la fusion des trois.
Communications et surveillance. Radio, liaison de données, transpondeurs, et les systèmes qui permettent de voir et de coordonner les appareils.
Les architectures intégrées. Comment les fonctions partagent le matériel de calcul avec un cloisonnement garanti, pour qu'une panne dans l'une ne puisse pas en affecter une autre.
Pourquoi les exigences sont aussi strictes
Cela mérite d'être expliqué plutôt qu'affirmé, car c'est cette compréhension qui rend un ingénieur bon dans ce métier, et pas simplement conforme.
Les exigences d'assurance sont déterminées par la conséquence. Une fonction dont la défaillance serait catastrophique porte les obligations les plus lourdes ; une fonction dont la défaillance n'est que gênante en porte beaucoup moins.
Cela produit trois réalités pratiques.
Une même fonction peut porter des obligations différentes. Selon l'appareil, l'architecture et ce qui resterait disponible en cas de défaillance. Le niveau d'assurance découle d'une évaluation de sécurité, pas du nom de la fonction.
L'architecture peut réduire la charge. Concevoir de façon à ce qu'une défaillance soit détectée et gérée par une voie indépendante peut abaisser le niveau d'assurance exigé d'un composant — un véritable compromis d'ingénierie, pas un exercice de paperasse.
Le changement coûte cher. Modifier un logiciel certifié signifie revérifier les parties concernées et reconstituer les preuves, ce qui explique pourquoi des changements apparemment triviaux entraînent un coût disproportionné, et pourquoi le logiciel est figé bien plus tôt que ne l'attendent les équipes commerciales.
La place de cette direction dans le domaine
Avionique, navigation et systèmes aérospatiaux est la cinquième des neuf directions du domaine Spatial, aérospatial et nouvelle mobilité d'Astra Trainer. Elle se situe aux côtés de l'ingénierie aéronautique et des opérations aériennes, et se connecte au domaine robotique, où Systèmes de contrôle couvre la théorie du contrôle sous-jacente.
Elle se combine aussi avec Semi-conducteurs et électronique pour le matériel, et avec IA, données et informatique pour la pratique du génie logiciel — les partenaires doivent toutefois noter que la transition du logiciel commercial vers le logiciel certifié est le cœur de cette direction, pas un détail. Vous pouvez consulter les neuf directions ici.
La navigation, et une dépendance qu'il faut nommer
Une observation factuelle aux conséquences d'ingénierie bien réelles.
La navigation par satellite est devenue une dépendance partagée bien au-delà de l'aviation : transport maritime, transport routier, topographie, agriculture, services d'urgence, et notamment le temps précis pour les réseaux de télécommunications, les systèmes financiers et les réseaux électriques.
Les signaux sont faibles au moment où ils atteignent le sol, ce qui les rend sensibles aux interférences involontaires comme au brouillage ou au leurrage délibérés. Des événements d'interférence affectant la navigation aérienne ont été rapportés dans diverses régions, et le système aéronautique les gère grâce à des procédures, des aides à la navigation alternatives et des systèmes inertiels.
Trois conséquences pour l'ingénierie et les équipes.
Le positionnement alternatif et complémentaire est un domaine actif. Navigation inertielle, navigation par le terrain et par vision, et sources de temps alternatives reçoivent toutes de l'attention à cause de cette dépendance.
La résilience est une exigence de conception, pas une fonctionnalité. Les systèmes qui supposent une disponibilité continue de la navigation par satellite font une hypothèse qui ne se vérifie pas toujours.
Cette compétence est de niche et en croissance. Les ingénieurs qui comprennent à la fois le traitement du signal de navigation par satellite et les systèmes inertiels sont rares, et on en a besoin bien au-delà de l'aviation.
Ceci est énoncé comme une considération d'ingénierie connue. Ce n'est une prédiction sur aucune région ou aucun événement en particulier.
Les métiers, nommément
Ingénieurs logiciel avionique. Logiciel embarqué certifié. La pénurie centrale.
Ingénieurs matériel avionique. Cartes, interfaces, qualification environnementale.
Ingénieurs sûreté de fonctionnement. Évaluation de sécurité, analyse des défaillances et allocation des niveaux d'assurance. Centraux, et en pénurie.
Ingénieurs vérification et validation. Tests basés sur les exigences et analyse de couverture. La population la plus nombreuse dans un programme certifié.
Ingénieurs systèmes de navigation. Navigation par satellite, inertie et fusion de capteurs.
Ingénieurs intégration et essais. Bancs d'essai, iron birds et instrumentation d'essais en vol.
Spécialistes certification pour le logiciel et le matériel électronique complexe.
Techniciens de maintenance avionique. Licenciés, en service, et une pénurie distincte et persistante.
Qui peut être formé pour ce métier
Les ingénieurs venus d'autres domaines à sécurité certifiée. Signalisation ferroviaire, instrumentation et contrôle nucléaires, dispositifs médicaux, sécurité fonctionnelle automobile. Ils acceptent déjà que la preuve fasse partie du produit — l'état d'esprit le plus difficile à instiller —, et il leur manque le cadre spécifique à l'aviation.
Les ingénieurs logiciel embarqué. Venus de l'industrie ou de l'automobile, déjà habitués à des environnements contraints et déterministes. Un pas plus court que depuis le web ou le développement applicatif.
Les ingénieurs essais. Vers la vérification, le plus gros besoin de tout programme certifié et la porte d'entrée la plus accessible.
Les techniciens de maintenance avionique. Vers des rôles de support ingénierie et d'intégration, apportant une connaissance du comportement en service des systèmes qui manque souvent aux équipes de conception.
Les ingénieurs électroniciens. Vers le matériel et l'intégration.
Le personnel avionique militaire. Arrive avec la culture des systèmes et de la navigabilité déjà ancrée.
La certification et les licences relèvent du droit, pas d'une simple procédure. Les systèmes embarqués sont approuvés via des processus réglementaires, et l'agrément d'organisme de conception, le crédit de certification et la libération de navigabilité sont détenus par des organismes agréés et des signataires qualifiés. La maintenance avionique exige une licence assortie des qualifications appropriées. La technologie aéronautique est en outre soumise au contrôle des exportations dans la plupart des pays. La formation construit une compréhension technique et accompagne les personnes qui progressent vers ces voies. Elle ne confère ni agrément, ni crédit de certification, ni licence, ni autorité pour libérer quoi que ce soit en service.
Ce qu'il faut en retenir
Le logiciel certifié est un métier à part, pas du logiciel ordinaire avec des documents en plus, et plusieurs habitudes qui font un bon ingénieur commercial deviennent ici des contraintes.
Le niveau d'assurance suit la conséquence, si bien que des choix d'architecture peuvent réellement réduire la charge — ce qui fait de l'évaluation de sécurité une activité d'ingénierie, pas une simple étape d'approbation.
Le changement coûte cher parce que les preuves doivent être reconstituées, ce qui explique pourquoi le logiciel se fige plus tôt que ne l'attendent les équipes commerciales.
La navigation par satellite est une dépendance partagée bien au-delà de l'aviation, et le positionnement résilient est une compétence de niche en croissance.
Et les ingénieurs venus du ferroviaire, du nucléaire, des dispositifs médicaux ou de la sécurité fonctionnelle automobile se reconvertissent bien mieux que les ingénieurs logiciels généralistes, car ils traitent déjà la preuve comme faisant partie du produit.
Le logiciel avionique certifié, est-ce juste du logiciel avec plus de paperasse ?
Non. Chaque ligne se rattache à une exigence, la couverture de vérification doit être démontrée structurellement, le timing doit être déterministe, et les outils eux-mêmes peuvent exiger une qualification. Plusieurs habitudes qui font un bon ingénieur commercial deviennent des contraintes.
Pourquoi les exigences d'assurance varient-elles ?
Parce qu'elles suivent la conséquence d'une défaillance, déterminée par une évaluation de sécurité. Une même fonction peut porter des obligations très différentes selon l'architecture et ce qui resterait disponible en cas de défaillance.
Pourquoi modifier un logiciel certifié coûte-t-il si cher ?
Parce que les preuves de vérification concernées doivent être reconstituées. C'est pourquoi le logiciel se fige bien plus tôt dans un programme aérospatial que ne l'attendent les équipes commerciales.
Qui se reconvertit vers les métiers de l'avionique ?
Les ingénieurs venus de la signalisation ferroviaire, de l'instrumentation nucléaire, des dispositifs médicaux ou de la sécurité fonctionnelle automobile, car ils acceptent déjà la preuve comme faisant partie du produit. Les ingénieurs logiciel embarqué ont un pas plus court à franchir que les développeurs applicatifs.
Où cela se situe-t-il dans le domaine ?
Cinquième des neuf directions du domaine Spatial, aérospatial et nouvelle mobilité d'Astra Trainer, se connectant aux systèmes de contrôle en robotique et à l'électronique dans le domaine des puces. Vous pouvez les consulter ici.