Exigences & architecture

Architecture fonctionnelle, logique et physique : trois vues d'un même système

Exigences & architecture · Publié le 2026-10-12

« Quelle est l'architecture du système ? » La question paraît simple, mais elle appelle plusieurs réponses selon le point de vue. L'ingénierie système distingue en général trois descriptions complémentaires : l'architecture fonctionnelle (ce que fait le système), l'architecture logique (comment on organise la solution sans choisir de technologie) et l'architecture physique (avec quoi on la réalise). Les relier proprement est l'essentiel du travail de conception.

Pourquoi plusieurs vues ?

Un système complexe ne peut pas être décrit d'un seul regard. La norme ISO/IEC/IEEE 42010, qui définit ce qu'est une description d'architecture, part de ce constat : une architecture se décrit par un ensemble de vues, chacune répondant aux préoccupations de certaines parties prenantes selon un point de vue défini. Le client s'intéresse aux services rendus, l'équipe électronique aux cartes et aux bus, l'équipe de sûreté aux chemins de défaillance. Aucune vue ne suffit seule ; leur cohérence est ce qui compte.

La séparation entre fonctionnel, logique et physique est la plus répandue de ces décompositions. On la retrouve, sous des noms parfois différents, dans la plupart des méthodes d'ingénierie système basée sur les modèles, dont la méthode Arcadia.

L'architecture fonctionnelle : ce que fait le système

Elle décrit les fonctions du système et les échanges entre elles, sans préjuger de leur réalisation. Pour un système de freinage, on trouvera par exemple : acquérir la demande du conducteur, estimer l'adhérence, calculer l'effort de freinage, appliquer l'effort, signaler une défaillance. Chaque fonction a des entrées et des sorties ; l'ensemble forme une chaîne qui part des stimuli de l'environnement et y retourne.

L'architecture fonctionnelle est le meilleur endroit pour vérifier que les exigences sont couvertes : chaque exigence fonctionnelle doit être réalisée par une ou plusieurs fonctions. En SysML, elle s'exprime avec des diagrammes d'activité, et les fonctions peuvent être décomposées sur plusieurs niveaux. Le piège classique consiste à y glisser des choix techniques (« transmettre par le bus CAN ») qui relèvent de l'architecture physique.

L'architecture logique : l'organisation de la solution

Elle regroupe les fonctions en composants logiques : des éléments de solution définis par leur rôle, pas par leur technologie. Un « gestionnaire d'énergie », un « calculateur de freinage », une « interface conducteur » sont des composants logiques. On fixe à ce niveau les grands principes de la solution : répartition des responsabilités, redondances, interfaces principales, sans encore choisir entre un calculateur dédié ou une fonction logicielle hébergée sur un calculateur partagé.

Ce niveau intermédiaire est précieux. Il permet d'évaluer plusieurs organisations de la solution sans s'enfermer dans des choix de fournisseurs, et il reste stable quand la technologie évolue. Dans les programmes longs, où les composants physiques deviennent obsolètes au cours de la vie du système, c'est souvent l'architecture logique qui assure la continuité.

L'architecture physique : avec quoi on la réalise

Elle décrit les éléments réels : équipements, cartes, logiciels, câbles, liaisons, structures mécaniques. Les composants logiques y sont réalisés par des éléments physiques, et les interfaces deviennent des connecteurs, des protocoles, des liaisons mécaniques. C'est à ce niveau que l'on fait les bilans de masse, de puissance, de coût et de fiabilité, et que l'on prépare les spécifications des sous-traitants.

L'allocation, fil conducteur entre les vues

Le passage d'une vue à l'autre se fait par allocation : chaque fonction est allouée à un composant logique, chaque composant logique à un ou plusieurs éléments physiques, et chaque échange fonctionnel à une interface. Ces liens sont des éléments du modèle à part entière. Ils permettent de répondre à des questions essentielles :

• Toutes les fonctions sont-elles allouées ? Une fonction sans composant est une fonction que personne ne réalisera.
• Quelles exigences portent, par transitivité, sur tel équipement ? C'est la base de sa spécification.
• Deux fonctions dont la défaillance simultanée serait dangereuse sont-elles allouées au même équipement ? C'est une question de sûreté de fonctionnement.

L'allocation prolonge ainsi la traçabilité des exigences jusqu'au matériel et au logiciel.

Arbitrer entre architectures

Il n'y a presque jamais une seule architecture possible. La norme ISO/IEC/IEEE 15288 distingue d'ailleurs un processus de définition de l'architecture, qui explore des solutions candidates, d'un processus de définition de la conception, qui détaille la solution retenue, et prévoit un processus d'analyse système pour éclairer les choix. Ces processus sont présentés dans notre article sur la norme 15288.

Un arbitrage rigoureux suit en général les mêmes étapes :

1. définir les critères à partir des exigences et des objectifs du projet (performance, masse, coût, sûreté, maintenabilité, délais, risques) ;
2. pondérer ces critères avec les parties prenantes, avant de regarder les solutions ;
3. décrire chaque architecture candidate au même niveau de détail ;
4. évaluer chaque candidate, par analyse ou par simulation quand c'est possible ;
5. documenter le choix et ses raisons, pour pouvoir le reconsidérer si les hypothèses changent.

La dernière étape est souvent négligée. Pourtant, une justification d'architecture tracée dans le modèle évite, quelques années plus tard, de rouvrir un débat déjà tranché, ou au contraire permet de le rouvrir à bon escient quand une hypothèse est tombée.

Un exemple simplifié

Prenons un éclairage public intelligent. L'architecture fonctionnelle contient : détecter une présence, mesurer la luminosité ambiante, décider du niveau d'éclairage, commander la lampe, remonter les pannes. L'architecture logique regroupe ces fonctions en un « module de perception », un « module de décision », un « module de puissance » et un « module de communication ». L'architecture physique peut ensuite réaliser la perception et la décision sur une seule carte électronique, ou au contraire déporter la décision vers un serveur central. Les deux solutions satisfont les mêmes fonctions ; elles diffèrent par le coût, la consommation, la résilience en cas de perte du réseau. C'est exactement le type de choix que l'arbitrage doit éclairer.

Une bonne architecture se juge aussi à la qualité des exigences qu'elle permet de dériver pour les sous-systèmes : claires, vérifiables, au bon niveau. Les règles présentées dans écrire une bonne exigence s'appliquent pleinement à ces exigences dérivées.

À lire ensuite

Plus dans Exigences & architecture

Exigences & architecture

La traçabilité des exigences

Dérivation, satisfaction, vérification : les liens à établir et l'usage qu'on en fait pour l'analyse d'impact.

Exigences & architecture

Les processus de la norme 15288

Quatre groupes, trente processus : la carte de référence de l'ingénierie système, et ce qu'elle n'impose pas.

Exigences & architecture

Écrire une bonne exigence

Les qualités attendues, des gabarits de phrase, des exemples réécrits et les pièges à éviter.