Intérêt et piliers de l'Ingénierie des Systèmes

Intérêt

L'intérêt de l'Ingénierie Système est de maîtriser la complexité d'un Système qu'on est en train de construire (électrique, mécanique, électronique, logiciel, énergétique etc.) et/ou maîtriser son changement (évolutions pour améliorations ou réparations). Le but étant de délivrer un produit qui répond au besoin avec le niveau de performances souhaité et en conditions désirées, sans régressions.

Cela repose sur 3 éléments : la vision Système, le processus de conception, et l'Ingénieur lui-même.

Pour faciliter la compréhension, considérons qu'un Système ici est un produit physique (et non un process ou une organisation). Par exemple : une trottinette électrique.

La vision

Comment atteindre cette maîtrise de la complexité ? Cela implique de garder une vision exhaustive (en 3 dimensions) du Système tel qu'exposé dans le "cube" ci-dessous.

Ce pavé décrit ma représentation, personnelle et certainement améliorable, de tout Système. Comment lire et appliquer cette vision?

Partons de la tranche horizontale Système et regardons la face parallèle à l'écran. Il faut considérer que :

• Tout système va être utilisé par certaines personnes dans certaines conditions. C'est l'Opérationnel. Les questions à se poser sont donc : qui va utiliser ce système ? Comment ? Combien de temps ? etc.
• Ce système va répondre au Besoin justifiant son existence par des Fonctions. Quelles sont-elles ? 
• Ce système sera peut-être matériel ou mettra un œuvre du matériel. Quel est-il ?
• Ce système devra être fabriqué une fois conçu. Quelles contraintes dois-je prendre en compte dès la définition de ce produit pour qu'il soit effectivement réalisable  ? 
• Une fois en fabrication, quels seront les moyens et outils dont j'aurais besoin ?
• Le Système vivant sa vie, il devra certainement subir de temps en temps une maintenance. Qu'est ce que cela implique sur notre Système ? Qu'il doit y avoir un "mode usine" caché quelque part par exemple.

Restons au niveau Système, considérons la face sur notre droite :

• Tout système verra son comportement spécifié lors de la conception. Il ne faut pas oublier de considérer la partie statique du système (ce qu'il est), mais aussi sa partie dynamique (ce qu'il va faire, dans quel ordre, ...). La composition du Système même peut changer de manière dynamique.
• Face à toutes ces exigences, formant la spécification du Système, une Architecture est définie et y répond. Idem, de manière statique et de manière dynamique pour ce qui change au cours de l'utilisation.
• Au sein de ces spécifications, et de cette architecture (que j'appelle ici Design), il ne faut pas oublier de considérer la Sécurité de Fonctionnement (Fiabilité, Maintenabilité, Disponibilité, Sécurité) et la Sûreté aussi si nécessaire.

Dernière dimension si on considère la verticale du cube :

• Tout Système est en interface avec d'autres Systèmes (le sur-Système), avec des environnements (vibrations, électromagnétisme, eau, température etc.) mais aussi avec une Règlementation. Cette dernière n'est pas une interface Système véritablement mais cela peut tellement le contraindre qu'il ne vaut mieux pas l'oublier.
• Ce Système est composé de sous-systèmes, eux-même composés d'éléments.

Enfin :

• Tous ces petits cubes à la croisée des axes doivent faire l'objet d'un travail dédié (par ex : on doit réfléchir et spécifier le fonctionnel de tous les sous-systèmes, et les interfaces fonctionnelles de tous les sous-systèmes entre eux)...
• ... Mais également les interfaces de ces petits cubes entre eux !

‍

Brodons sur un exemple avec notre trottinette électrique : La trottinette est ici le Système.

Le Système selon les points de vues ci-dessus :

• La trottinette sera utilisée par des personnes de tout poids, qui veulent faire un trajet de 5km le matin et le soir sur terrain plat. Elle est mise en œuvre comme suit : sortie du sac à dos, dépliée, démarrée, et en avant. Opérations inverses lors de l'arrêt.
• Les fonctions, grosso modo, vont tourner autour de la mise en mouvement, du pilotage, de supporter une personne, d'alimentation, ... (je mets de côté pour l'instant les interfaces car elles viennent ci-dessous)
• Le Système est composé : d'un châssis, de roue, de batteries, de phares, d'électronique de pilotage, etc.
• Cette magnifique trottinette doit être fabriquée à coûts maîtrisés sur une série de X exemplaires. On choisit de mouler le châssis. On ne peut donc pas vouloir n'importe quelle forme de châssis à la fin.
• Peut-être qu'en sortie de ligne de production, le fabricant souhaite tester le fonctionnement de son bolide sur un tapis roulant spécifique sur lequel on peut raquer 14 trottinettes en parallèle. Ce moyen de test en production doit certainement être développé spécifiquement, ou acheté si cela existe par ailleurs.
• Si un utilisateur me renvoie sa trottinette en garantie car il y a eu de la casse, je souhaite avoir moyen de me connecter à l'ordinateur de bord et voir comment l'utilisateur a traité son produit. Cela nécessite alors une mémoire dédiée sur l'ordinateur de bord, qui stocke les données que je veux récupérer, et une connectique accessible pour les extraire.

La partie Spécification et Architecture :

• Cette trottinette est certainement le sujet principal d'une documentation très fournie chez le fabricant qui veut maîtriser la qualité de son Système.
• L'architecture retenue à la fin est celle qu'on aurait sous les yeux si on démontait tous les composants de cette trottinette, qu'on analysait les mécanismes, l'électronique, qu'on sondait le logiciel etc.
• Lors de ces spécifications, le fabricant s'est certainement dit des choses telles que "si la trottinette n'a plus que 20% de batterie, avertir l'utilisateur via une LED. Dès qu'on est à 10%, ralentir progressivement pour que l'utilisateur puisse descendre tranquillement sans arrêt brusque".

L'autour du Système :

• Ce système a visiblement une capacité d'interfaçage à d'autres Systèmes : la route, l'être humain, le sac à dos, le smartphone de l'utilisateur (via une app certainement), etc.
• Il doit pouvoir être opéré en ville ou en campagne, par beau comme mauvais temps, en été comme en hiver, sans éteindre la télévision de tous les foyers auprès desquels il passe, et sans se casser au premier ralentisseur.
• Et comme tout objet commercialisé en Europe, il doit être marqué CE et donc obéir à la règlementation en vigueur sur ce type de produit. Peut-être que d'autres règlementations sont également à prendre en compte.

Et quid des interfaces des petits cubes composant mon pavé :

• L'interface entre le fonctionnel du moteur (sous-système) et son matériel ?
• L'interface entre le fonctionnel du moteur et de la Trottinette complète ? 
• etc.

(Les points présentés ici sont bien entendus non exhaustifs).

Évidemment, quand on conçoit un Système depuis la feuille blanche, on n'est pas à ce niveau d'information tout de suite. La construction de ce cube va se faire progressivement, au cours de la conception, à l'aide d'un Processus d'Ingénierie Systèmes dont je parle plus bas.

Si cet effort de management et de clarté technique est conservé de bout en bout de la réalisation du produit, depuis le cahier des charges client jusqu'à la phase de Support (après-vente) alors le Système sera certainement OK du premier coup, ayant une architecture (logicielle, matérielle, informationnelle, etc.) claire et maîtrisée. Cela assure une robustesse et une évolutivité à notre produit, en plus de répondre au besoin.

Le rôle

Suffit-il qu'une personne garde un œil sur le cube ci-dessus pour que la réalisation d'un produit se passe aussi bien ? Malheureusement, non.

Cette vision doit être portée par une personne qui va la mettre en œuvre quotidiennement via un processus de conception et des méthodes sous-jacentes. Cette personne, l'Ingénieur Systèmes, est ainsi le bras armé du Chef de Projet. C'est le pendant Technique du management effectué par le Chef de Projet. 

Les 2 rôles sont complémentaires :

• le Chef de Projet veillera au bon déroulé contractuel du projet, à l'atteinte des objectifs internes et externes à l'Entreprise, dans des conditions calendaires, budgétaires et qualité convenues (si nous devions résumer)
• alors que l'Ingénieur Système est responsable du bon fonctionnement du produit, aux performances souhaitées.

NOTA : quand un Ingénieur Systèmes a un rôle managérial prononcé, comme le management d'autres Ingénieurs Systèmes par exemple, on l'appelle parfois Architecte Systèmes.

Le processus

Voyons pourquoi il est important d'en avoir un lorsqu'on se lance dans la réalisation d'un produit.

Un produit complexe est un véritable chemin de croix à mettre au monde. Prenons l'exemple de notre lanceur spatial que j'aborde dans un autre article (cela fonctionne aussi avec la trottinette).

• Par où commencer ? La conception de la structure ? Ou de ses lois de Pilotage (GNC) ? 
• De quelles compétences vais-je avoir besoin ? Un trajectographe extra atmosphérique est-il nécessaire ? 
• Et à quel moment ? Tout de suite, dans 6 mois ? Simplement à la fin ?
• A quel moment dois-je contacter des fournisseurs pour avoir des tôles d'aluminium et des ordinateurs blindés ?
• Où serait le meilleur endroit pour un port spatial ? 
• Comment être sûr que l'équipe de propulsion a bien pris en compte les demandes de l'équipe GNC ? et Mécanique ? 
• Quelle est la masse totale de mon lanceur ? 
• Quelle est la taille des satellites que vont me demander d'envoyer mes clients ? Et d'ailleurs, qui sont/seront-ils ?
• Comment m'assurer que le lanceur sera assemblable à la fin ? 
• etc.

Cette liste de question est quasi infinie au démarrage d'un projet. Et on a l'impression qu'elle ne fait que croître à mesure qu'on avance.

Si on a un processus sous la main qui nous indique quelles activités d'ingénierie faire, à quel moment, pourquoi, alors il ne faut pas s'en priver. Cela permettra de répondre aux questions précédentes, et plus globalement de :

• Savoir quelles sont toutes les parties prenantes que nous avons à satisfaire avec notre produit, et qui peuvent nous aider
• Savoir quels métiers devront agir et interagir, et à quel moment
• Placer un cadre de collaboration entre toutes ces expertises (outils, modèles, objectifs, exigences, etc.)
• Penser à tous les éléments qu'on a tendance à oublier : l'industrialisation du produit, sa production série, les outils nécessaires, les autres systèmes avec lesquels il interagira, son soutien logistique, sa maintenance, ...
• Cadencer le développement
• Vérifier que chaque partie du produit fonctionne comme convenu, et valider que le Système tout assemblé répond au besoin initial

J'aurai l'occasion de reparler maintes fois du Cycle en V, que j'apprécie particulièrement pour sa rigueur. C'est un exemple de processus d'Ingénierie Systèmes.

Au-delà de la gestion du risque technique que cela apporte, le Chef de Projet aimera également un processus car cela lui apporte une maîtrise du risque Projet ainsi qu'une prédictibilité :

• Les grandes activités sont relativement connues donc le calendrier s'éclaire (pas de syndrome de la feuille blanche)
• Les délais peuvent être estimées sur cette base ("Je sais que je vais devoir faire telle activité à tel moment, et la dernière fois cela avait pris 3 mois")
• Ainsi que les coûts ("J'aurais besoin de faire des essais en laboratoire à telle date, et c'est généralement de l'ordre de X€")
• Des critères objectifs de Qualité peuvent être établis ("Actuellement, mon Système est conforme de 89% de ses exigences client")

Pour finir, on peut ajouter que certaines certifications de produits, notamment dans l'Aéronautique, demandent explicitement aux entreprises de suivre un processus de conception qui soit clarifié dès le début du projet. On ne peut donc même pas y couper si le voulait.

Je ferai un article dédié sur les différents types de processus, et parlerai plus longuement du Cycle en V.

Exemple

Un exemple très connu, à la fois drôle et tragique, permet d'illustrer ce à quoi on s'expose si on n'adopte pas (ou trop peu) de discipline Systèmes au sein de son projet : Mars Climate Orbiter.

En 1999, une mission de la NASA vers Mars a échoué car la sonde envoyée vers la planète rouge a dysfonctionné et s'est trop écartée de sa trajectoire voulue.

La raison ? Le sous-système de navigation mis au point par les Ingénieurs de la NASA (Jet Propulsion Laboratory) attendait en entrée des données d'accélération de la sonde en unité du Système International (métrique). Les Ingénieurs de Lockheed Martin, en charge de la fourniture de ces données via un autre sous-système de leur fabrication, ont eux raisonné en unités du Système Impérial (inch, pounds etc.) !

The loss of the Mars probe was the latest in a series of major spaceflight failures this year that destroyed billions of dollars worth of research, military and communications satellites or left them spinning in useless orbits.

Quelle zone du cube de l'Ingénierie Systèmes ci-dessus s'est trouvée en défaut pour le Mars Climate Orbiter ? 

‍

Aurélien NARDINI