Systemier

Introduction

Cet article présente la notion de systémier dans le cadre de l'aéronautique. Le terme systémier recouvre l'entité ou les entités en charge de la conception, du développement et du maintien en opération du système spatial qui comprend: l'engin spatial (fusée, satellite, sonde,...), les infrastructures, l'environnement (ambiances externes, internes), les interfaces avec le monde extérieur. Le besoin d'un systémier provient de la complexité des engins spatiaux qui font intervenir de nombreux domaines d'études aux compétences variées, de multiples technologies, des missions longues avec une pléthore de séquence d'évènements. Il y a donc besoin d'un coordinateur (qu'on appelle aussi, selon le contexte contractuel, organisationnel ou politique, un architecte ou un maître d'œuvre) qui s'occupe de s'assurer de la cohérence des différents éléments qui constituent le système spatial, de gérer les interfaces entre elles et au final d'assurer le fonctionnement de l'ensemble.

Du fait du caractère abstrait de sa nature, le rôle du systémier fait en permanence l'objet de controverses, notamment sur la limite de son champs d'action. D'autre part, chaque composant d'un système spatial peut être aussi considéré comme un sous-système: chaque participant au projet joue donc aussi à son niveau le rôle de systémier pour le produit qu'il développe.

Rôle

Les différentes tâches

Le systémier doit assurer les tâches suivantes:

• Définir le cahier des charges avec le client (type de mission, technologie spécifique à utiliser, contraintes de sécurité, etc.)
• Définir les différents types d'architecture du système spatial répondant au cahier des charges (nombre de moteurs, de réservoirs, types d'algorithme)
• Décliner le cahier des charges en spécifications vers les participants du projets (sous-traitants, sous-systémiers, co-traitants...). Les spécifications précisent les performances, les ambiances, les contraintes opérationnelles et les interfaces (mécaniques, électriques) que doivent tenir chaque sous-ensemble. Cette déclinaison se fait en suivant l'arborescence de l'architecture du système. Chaque contractant développe alors son produit de façon à respecter ces spécifications
• Suivre le développement de chaque composant: il s'agit de vérifier qu'il n'y a pas d'incohérences qui apparaissent entre les différents produits. Des difficultés peuvent en effet apparaître dans le développement d'un composant particulier qui amène à réviser la spécification et cela au détriment d'un autre produit. C'est un jeu d'équilibriste permanent entre les besoins et les contraintes des différents participants.
• Utiliser les informations que font remonter chaque participant sur leur produit afin d'élaborer le système complet: chaque produit a des caractéristiques données, un principe de fonctionnement donné et génère des ambiances mécaniques, thermiques,... Toutes ces données sont imbriquées les unes dans les autres par le systémier qui évalue alors le fonctionnement de l'ensemble et les ambiances qu'il génère; par exemple, pour une fusée, il va évaluer la masse totale, les centrages, les inerties, il va élaborer les lois de guidages, de navigation et d'attitude, analyser les ambiances subies par chaque partie du lanceur. Au final, il s'assurera qu'une masse utile suffisante peut être mise en orbite avec la précision requise.

La conception système

Les différentes activités évoquées précédemment ne l'ont pas été dans un ordre précis. En effet, le développement système repose sur l'interaction permanente entre toutes ces tâches: c'est ce qu'on appelle les boucles système; c'est le motif de conception que l'on retrouve le plus fréquemment au niveau système. Il part de l'idée qu'un système ne suit pas un processus de développement linéaire et qu'il n'y a pas un jeu de données d'entrée parfaitement défini; il faut donc faire des hypothèses, travailler sur ces hypothèses puis les affiner en fin de boucle.
On retrouve néanmoins à une échelle macroscopique une certaine tendance dans l'évolution du développement. Dans le cas des systèmes spatiaux, c'est le schéma du Cycle en V : dans la partie descendante, on met en place les spécifications, puis on les décline vers le bas à chaque sous-ensemble; dans la partie ascendante, chaque sous-ensemble fait remonter vers le niveau supérieur ses caractéristiques afin d'être intégrées dans le système.

Les bases

Il existe différentes définitions du systémier, souvent théoriques, qui amènent à des schémas d'organisation très différents. Celui présenté ici a l'avantage de se révéler pragmatique.
Un systémier repose sur quatre bases fondamentales:

• Les objectifs: le systémier doit toujours connaître les objectifs de ses actions. Cela paraît trivial mais la complexité des systèmes spatiaux fait qu'au bout de quelques années de développement et sous l'effet des nombreuses pressions politiques et économiques, les objectifs perdent en clarté. Or, son rôle est de maintenir le cap du développement d'un projet et d'éviter toute dérive qui pourrait engendrer des surcoûts ou de prises de risques inutiles.
• La maîtrise de la technologie: le rôle du systémier n'est pas de développer chaque composants: c'est le travail des motoristes, électroniciens... Par contre, il doit pouvoir être à même de bien comprendre et maîtriser les subtilités de fonctionnement des sous-ensembles et cela afin de s'assurer qu'ils s'intègrent au mieux. En effet, chaque composant ne doit pas être optimisé par lui-même: c'est le système complet qui doit l'être et non pas chaque sous-ensemble. Il faut donc comprendre quels sont les paramètres majeurs d'un équipement et connaître la sensibilité du fonctionnement à ces paramètres. Pour cela, le systémier doit disposer d'une batterie d'outils qui permettent d'analyser chaque produit ainsi que la technologie et la physique associées. Mais il doit aussi s'appuyer sur la compétence de ses ingénieurs dans chaque domaine et travailler au maintien de cette compétence en leur permettant de travailler au contact du matériel.
• Les humains: un systémier, c'est avant tout un ensemble d'être humains: le plus souvent nombreux, avec des compétences différentes, des éducations différentes et des manières de penser différentes. Et toute la difficulté consiste à faire interagir ces gens. C'est la base du métier de systémier: être capable d'établir des relations constructives avec d'autres ingénieurs.
• La gestion de l'information: la complexité d'un système se traduit par le nombre des interfaces qui sont à gérer et donc par la quantité d'information qui transite par ces interfaces. Ces informations varient par leur nature, par leur histoire, par leur niveau de mise à jour. La maîtrise de ces informations est donc l'une des clefs de la réussite d'un projet système. La principale difficulté associée est l'absence d'information; elle peut être due soit à la rétention pour des raisons politiques ou personnelles soit au manque d'avancement du projet. Des outils se mettent peu à peu en place afin d'améliorer au mieux la gestion de l'information.

Les écueils

On notera ici un certain nombre de conseils de base issus de l'expérience et qui permettent d'avoir une vue d'ensemble des obstacles à éviter dans l'ingénierie système.

• Les problèmes d'interfaces peuvent apparaître très tard si une mauvaise analyse est faite au départ. Ces problèmes sont néanmoins récupérable si suffisamment de marges ont été prises dans le dimensionnement du système et dans la logique de développement.
• Il faut veiller à rester pragmatique dans l'approche des problèmes. Il ne faut pas chercher systématiquement l'exhaustivité de la démarche "rouleau compresseur". La méthodologie doit s'adapter aux objectifs et aux justifications nécessaires.
• Il faut toujours rester vigilant sur la communication dans les relations avec d'autres organismes.
• Il faut toujours établir un glossaire, un référentiel (les mêmes vocables n'ont pas nécessairement la même signification; les référentiels "métiers" peuvent être inversés).
• Il ne faut pas faire d'impasse sur les contrôles qui peuvent avoir des conséquences importantes. Il doit y avoir un responsable "interface" qui puisse faire les ultimes validations.
• Nécessité de connaître l'utilisation qui sera faite du matériel et qui ne peut pas toujours être explicité dans une spécification. Intérêt pour l'ingénieur de "voir" le site et l'environnement (matériel, humain). Le concepteur doit aller sur site. L'utilisateur ne sait pas forcément raisonner en spécifications.
• Non-suivi de l'évolution d'un paramètre au fil des modifications. Abandon d'opérations finissant par être considérée comme inutile au fil du temps dans un contexte de planning tendu. Traçabilité de la définition et des paramètres de performance et de sécurité.
• Les problèmes se répètent d'une génération de système à l'autre sans qu'aucune correction ne soit apportée.
• Les opérations d'essai doivent être suffisamment espacées pour une bonne prise en compte des évolutions de besoin et de procédures.
• Il est important d'anticiper et d'organiser suffisamment à l'avance les prestations clefs du programme -> permet de s'apercevoir des trous.
• Nécessiter de diffuser au maximum l'information (mais pas n'importe comment et pas à n'importe qui).

Voir aussi

• Liste des articles relatifs à l'astronautique
• Equipementier

• Portail de l’astronautique