Exigences & architecture

ISO/IEC/IEEE 15288 : les 30 processus du cycle de vie d'un système

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

La norme ISO/IEC/IEEE 15288 est le texte de référence de l'ingénierie système. Elle ne dit pas comment concevoir un avion ou un train, mais elle décrit les processus qu'une organisation met en œuvre tout au long de la vie d'un système, de l'idée initiale au démantèlement. Sa deuxième édition date de mai 2023. Voici ce qu'elle contient, et comment l'utiliser sans en faire un carcan.

Une norme commune à trois organismes

Le triple sigle rappelle que la norme est publiée conjointement par l'ISO, la Commission électrotechnique internationale (IEC) et l'IEEE. L'édition en vigueur, ISO/IEC/IEEE 15288:2023, est la deuxième édition sous ce triple sigle : elle annule et remplace l'édition de 2015, après révision technique. Elle a une norme sœur pour le logiciel, l'ISO/IEC/IEEE 12207, qui suit une structure très proche.

Son domaine d'application est volontairement large. Elle s'applique aux organisations dans leur rôle d'acquéreur comme de fournisseur, et à l'ensemble du cycle de vie : conception, développement, production, utilisation, soutien et retrait. Les processus peuvent être appliqués de manière itérative, concurrente et récursive à chaque niveau de décomposition du système.

Ce que la norme n'impose pas

C'est le point qui surprend le plus ceux qui l'ouvrent pour la première fois : la norme ne prescrit pas de modèle de cycle de vie particulier (en V, incrémental, agile), ni de méthode de développement, ni de technique de modélisation. Elle fournit un ensemble de processus parmi lesquels une organisation construit ses propres cycles de vie, adaptés à ses produits et à ses contraintes. Le processus d'adaptation (tailoring), décrit en annexe, fait partie intégrante de son usage.

Autrement dit, se conformer à la 15288 ne veut pas dire suivre une recette : cela veut dire être capable de montrer que les résultats attendus de chaque processus retenu sont obtenus.

Quatre groupes de processus

L'édition 2023 compte trente processus, répartis en quatre groupes.

Les intitulés français ci-dessus sont des traductions usuelles ; la norme est publiée en anglais. Le détail des processus, avec leurs finalités, résultats attendus et activités, figure dans le texte de la norme, dont la fiche officielle est consultable sur le site de l'ISO.

Les processus techniques, colonne vertébrale de l'ingénierie

Les quatorze processus techniques suivent la vie du système. Les premiers transforment un problème en solution : l'analyse de la mission définit le problème ou l'opportunité ; la définition des besoins des parties prenantes recueille et formalise ce qu'attendent utilisateurs, exploitants et autorités ; la définition des exigences système traduit ces besoins en exigences techniques. Nous détaillons cette étape dans l'article écrire une bonne exigence.

Viennent ensuite la définition de l'architecture, qui explore et choisit une organisation de la solution, et la définition de la conception, qui fournit le détail nécessaire à la réalisation. L'analyse système fournit à toutes ces étapes les données quantitatives (performances, coûts, risques) qui éclairent les décisions. Le lien entre ces processus et les vues fonctionnelle, logique et physique est présenté dans notre article sur les trois architectures.

La réalisation produit les éléments, l'intégration les assemble, la vérification montre qu'ils satisfont les exigences, la transition installe le système dans son environnement d'exploitation, la validation montre qu'il répond au besoin. Les deux notions de vérification et de validation sont distinguées dans notre article dédié. Enfin, l'exploitation, la maintenance et le retrait de service couvrent la vie opérationnelle et la fin de vie, souvent oubliées dans les phases de conception alors qu'elles pèsent lourd dans le coût global.

Le management technique, souvent sous-estimé

Les huit processus de management technique ne sont pas de la « gestion de projet » au sens administratif. La gestion de la configuration garantit que l'on sait, à chaque instant, quelle version de quelle exigence s'applique à quelle version du produit. La gestion des décisions impose de documenter les choix et leurs raisons. La gestion des risques et la mesure fournissent les indicateurs qui permettent de piloter. Une démarche basée sur les modèles touche directement ces processus : le modèle doit lui-même être sous gestion de configuration, et ses indicateurs (couverture des exigences, interfaces définies) alimentent la mesure.

Comment s'en servir

• Comme carte : pour vérifier qu'aucune activité essentielle n'est oubliée dans un plan de développement, en particulier l'analyse de la mission, la transition et le retrait de service.
• Comme langage commun : entre client et fournisseur, ou entre entités d'un même groupe, pour se mettre d'accord sur ce que recouvre « la vérification » ou « l'intégration ».
• Comme base d'audit : pour évaluer la maturité de ses pratiques processus par processus, en s'appuyant sur les résultats attendus décrits par la norme.
• Comme point d'entrée vers d'autres textes : la norme 29148 pour les exigences, la 42010 pour les descriptions d'architecture, la 24641 pour les méthodes et outils de l'ingénierie basée sur les modèles, ou le manuel d'ingénierie système de l'INCOSE, dont la cinquième édition, publiée en 2023, s'aligne sur les processus de la 15288:2023.

Les erreurs d'interprétation courantes

Lire la norme comme un cycle en V déguisé est l'erreur la plus fréquente : l'ordre de présentation des processus techniques n'est pas un ordre d'exécution, et la norme insiste sur leur application itérative et récursive. Une autre erreur consiste à créer un document par processus, ce qui multiplie la paperasse sans améliorer l'ingénierie. Enfin, la norme ne remplace ni les référentiels sectoriels (aéronautique, ferroviaire, automobile, spatial), ni les exigences réglementaires, qui viennent s'y superposer.

À lire ensuite

Plus dans Exigences & architecture

Exigences & architecture

Écrire une bonne exigence

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

Exigences & architecture

Fonctionnelle, logique, physique

Trois vues d'un même système, l'allocation qui les relie, et la manière d'arbitrer entre architectures.

Exigences & architecture

Vérification et validation

« Le produit est-il bien fait ? » et « est-ce le bon produit ? » : deux questions, deux démarches.