Générer automatiquement des spécifications de sous-systèmes : exports par sous-système et métier

Introduction

Selon sa propre page fournisseurs Alstom travaille avec plus de 21 000 fournisseurs dans 83 pays. Les fournisseurs représentent 60 % du chiffre d’affaires annuel. Chacun d’eux doit savoir exactement ce qu’il doit livrer — non pas l’intégralité du cahier des charges avec ses 2 000 exigences, mais précisément le sous-ensemble qui concerne son sous-système. Ce document est le cahier des charges partiel.

Créer des cahiers des charges partiels compte parmi les tâches les plus lourdes de la phase d’appel d’offres. Pour un véhicule comptant 20 à 30 fournisseurs Tier 1, il faut produire autant de dossiers documentaires spécifiques aux sous-systèmes. Chacun doit contenir les bonnes exigences, décrire les interfaces pertinentes et référencer les normes applicables. Dans de nombreuses entreprises, ce travail reste manuel. Les conséquences sont prévisibles : exigences oubliées, interfaces mal attribuées, références normatives obsolètes.

Cet article présente les raisons de cette complexité, les normes qui aident à la structurer, des approches concrètes d’automatisation et les limites des outils actuels.

Qu’est-ce qu’un cahier des charges partiel ?

Un cahier des charges partiel (également appelé spécification fournisseur, dossier d’exigences de sous-système ou, en anglais, sub-specification) est un sous-ensemble filtré et enrichi du cahier des charges global, adapté à un sous-système ou à un fournisseur précis. Un simple extrait ne suffit pas. Le document doit fournir le contexte nécessaire pour que le fournisseur puisse situer sa solution dans le système global.

Un cahier des charges partiel complet contient cinq catégories de contenu :

• Exigences spécifiques au sous-système : toutes les exigences du cahier des charges global qui concernent directement le sous-système concerné, par exemple la capacité de climatisation pour le fournisseur HVAC ou les valeurs de décélération pour le fabricant du système de freinage.
• Exigences d’interface : exigences portant sur les interfaces entre le sous-système et ses voisins : mécaniques (espaces d’installation, points de fixation), électriques (alimentation, bus), logicielles (protocoles TCMS, interfaces de diagnostic). Elles sont généralement formalisées dans des Interface Control Documents (ICD).
• Exigences transversales : elles s’appliquent à tous les sous-systèmes et doivent donc figurer dans chaque cahier des charges partiel. Exemples : protection incendie selon EN 45545, CEM selon EN 50121, conditions environnementales, exigences qualité et objectifs RAMS.
• Références normatives : le sous-ensemble pertinent de la liste globale des normes (TSI, DIN EN, CENELEC), y compris l’indication de version et les consignes d’applicabilité.
• Informations contextuelles : aperçu de l’architecture système, schémas d’interface, profil d’exploitation (catégorie de ligne, zone d’utilisation, températures ambiantes) et informations organisationnelles (interlocuteurs, délais de réponse, schéma de classification).

Pourquoi les cahiers des charges partiels sont particulièrement complexes dans l’industrie ferroviaire

Les cahiers des charges partiels existent dans tous les secteurs qui travaillent avec des fournisseurs de sous-systèmes. Mais l’industrie ferroviaire combine une densité d’interfaces inhabituellement élevée, une vaste diversité de sous-systèmes et une profondeur réglementaire rarement réunies à ce point dans d’autres secteurs.

Diversité des sous-systèmes

Une étude de fiabilité sur les sous-systèmes de véhicules ferroviaires identifie six sous-systèmes principaux d’un véhicule moteur : alimentation auxiliaire (AUX), traction (DYN), contrôle et gestion du train (TCMS), frein mécanique (MEB), bogie (BOG) et couplage du véhicule (MECH). En pratique, la décomposition est bien plus fine : aménagement intérieur, système d’information voyageurs, système de portes, installation sanitaire, climatisation, pantographe, stockage d’énergie et autres sous-systèmes s’y ajoutent. Pour une rame moderne, 20 à 30 fournisseurs Tier 1 sont la norme ; les voitures à deux niveaux ou les trains à grande vitesse peuvent en compter davantage.

Chacun de ces fournisseurs a besoin de son propre dossier documentaire, et chaque dossier doit couvrir les interfaces avec tous les sous-systèmes adjacents.

Densité des interfaces

Les retours d’expérience de Crossrail sur l’intégration système montrent ce qui se produit lorsque la définition des interfaces échoue dans les projets ferroviaires : Crossrail suivait plus de 350 Anchor Milestones pour les seules interfaces et utilisait des Interface Control Documents (ICD) dédiés entre les parties contractantes. Le constat est sobre : les définitions d’interface manquantes ou incohérentes sont « très difficiles et coûteuses à corriger dans les phases tardives du projet ».

Appliqué aux cahiers des charges partiels, cela signifie que chaque interface entre deux sous-systèmes doit apparaître dans les deux documents. Le fournisseur HVAC doit connaître l’exigence relative à l’interface électrique avec le réseau de bord ; le fournisseur du réseau de bord doit connaître l’exigence de fourniture de puissance pour la climatisation. Si ces exigences miroir ne sont pas cohérentes, le problème n’apparaît souvent que tardivement.

Exigences transversales et profondeur réglementaire

Un véhicule ferroviaire doit satisfaire simultanément plusieurs spécifications techniques d’interopérabilité (STI). Beaucoup de ces exigences sont transversales : une exigence de protection incendie selon EN 45545 concerne à la fois l’aménagement intérieur, les sièges, le câblage et la climatisation. Les exigences RAMS selon EN 50126 doivent être déclinées du véhicule complet vers les sous-systèmes : c’est l’allocation RAMS, qui répartit les objectifs de fiabilité et de disponibilité entre les différents sous-systèmes.

Le problème est que ces exigences transversales doivent figurer dans chaque cahier des charges partiel concerné, avec une expression propre au sous-système. Le fournisseur HVAC doit savoir quelle classe de protection incendie s’applique à ses composants et quelle valeur MTBF il doit respecter. Des objectifs abstraits à l’échelle du véhicule complet ne lui suffisent pas.

Le modèle à trois niveaux : donneur d’ordre, OEM, fournisseur

Le guide VDB de gestion des exigences décrit le flux d’exigences sur trois niveaux : donneur d’ordre (autorité organisatrice ou exploitant), constructeur de véhicules (OEM) et fournisseur. Sans ce modèle, il est impossible de comprendre pourquoi les cahiers des charges partiels existent et pourquoi leur production est aussi exigeante.

Ce flux fonctionne dans les deux sens. L’OEM doit réintégrer les réponses des fournisseurs dans son processus global. Si le fabricant du système de freinage évalue une exigence comme OKB (réalisable sous conditions), cela influence la propre réponse de l’OEM au donneur d’ordre. Avec 20 à 30 fournisseurs Tier 1 par véhicule, la coordination devient vite difficile à maîtriser.

ISO 22163 (IRIS) : ce que la chaîne d’approvisionnement exige en matière de qualité

Le cadre du flux d’exigences sur ces trois niveaux est fourni par ISO 22163 (IRIS), la norme mondiale de management de la qualité de l’industrie ferroviaire. ISO 22163 repose sur ISO 9001 et y ajoute des thèmes propres au ferroviaire : gestion de projet, First Article Inspection (FAI), RAMS, prise en compte des coûts de cycle de vie. UNIFE a introduit la norme en 2006 afin d’uniformiser la qualité des produits sur toute la chaîne d’approvisionnement.

Concrètement, cela signifie que l’OEM doit démontrer que les exigences ont été transmises au fournisseur de manière complète et cohérente. Le fournisseur doit montrer qu’il les comprend, peut les évaluer et y répond intégralement. De nombreux OEM exigent la certification IRIS avant même qu’un fournisseur soit inscrit sur leur liste. La qualité du cahier des charges partiel est donc aussi une question de conformité, pas seulement d’efficacité interne.

EN 15380 : la norme de structuration pour la décomposition en sous-systèmes

La série de normes européennes EN 15380 constitue le système de classification officiel des véhicules ferroviaires et la base de l’affectation des exigences par sous-système. La norme décrit trois vues différentes d’un véhicule :

• EN 15380-2 : Product Breakdown Structure (PBS) : découpage selon les groupes de produits physiques (ensembles, composants). Pertinent pour la nomenclature et l’affectation physique aux périmètres de fourniture.
• EN 15380-4 : Function Groups : découpage selon les fonctions (traction, freinage, information, climatisation, etc.). Pertinent pour l’analyse fonctionnelle des exigences et la démonstration RAMS selon EN 50126.
• EN 15380-5 : System Breakdown Structure (SBS) : découpage par systèmes et sous-systèmes. C’est le niveau le plus important pour les cahiers des charges partiels : la SBS définit les systèmes principaux et sous-systèmes d’un véhicule, y compris les éléments transversaux découlant de sa conception architecturale. Chaque exigence peut être affectée à un élément SBS, et le cahier des charges partiel d’un fournisseur contient exactement les exigences affectées à ses éléments SBS.

Les trois structures sont liées : SBS (EN 15380-5), PBS (EN 15380-2) et groupes fonctionnels (EN 15380-4) donnent des vues différentes du même véhicule. Lors de la génération de cahiers des charges partiels, la SBS est le filtre principal. La vue fonctionnelle est nécessaire pour l’allocation RAMS, la vue produit pour l’affectation à des périmètres de fourniture concrets.

EuroSpec : la recommandation sectorielle

L’ initiative EuroSpec recommande explicitement, dans sa spécification Requirements Management (V3.0) l’utilisation d’EN 15380-5 pour structurer les exigences. Cette spécification couvre six domaines : caractéristiques des exigences, syntaxe, attributs, traçabilité, validation/vérification et échange de données.

Pour générer des cahiers des charges partiels, le modèle d’attributs est déterminant : outre l’ID, le texte et la classification, chaque exigence reçoit un attribut system element (selon EN 15380-5), un product element (selon EN 15380-2) et un function element (selon EN 15380-4). Lorsque ces attributs sont correctement maintenus, le cahier des charges partiel peut être généré comme export filtré : system element = « Climatisation » extrait toutes les exigences destinées au fournisseur HVAC.

Création manuelle : pourquoi elle ne passe pas à l’échelle

Dans de nombreuses entreprises, les cahiers des charges partiels sont encore créés manuellement : un ingénieur système ou un responsable d’offres filtre les exigences pertinentes de la liste globale, les copie dans un nouveau document, complète les descriptions d’interface et met le résultat en forme dans un fichier Word ou Excel. L’ article de CONTACT Software sur la gestion des exigences dans l’industrie ferroviaire indique que la plupart des constructeurs n’ont longtemps même pas été en mesure de livrer leurs spécifications au format correct.

La création manuelle présente trois problèmes. D’abord, elle est lente : un à plusieurs jours-personnes par fournisseur, soit des semaines de travail documentaire pour 25 fournisseurs. Ensuite, elle est source d’erreurs, car des exigences peuvent être oubliées, des interfaces mal affectées et des références normatives obsolètes. Enfin, elle n’est pas sûre du point de vue des révisions : à chaque révision du cahier des charges, tous les cahiers des charges partiels doivent être vérifiés et mis à jour manuellement.

Approches d’automatisation

L’automatisation de la création des cahiers des charges partiels repose sur un principe simple : si chaque exigence est correctement annotée avec des attributs (sous-système selon EN 15380-5, type d’exigence, références normatives, appartenance à une interface), le cahier des charges partiel peut être généré comme export filtré.

Prérequis : une attribution d’attributs rigoureuse

La qualité du cahier des charges partiel généré dépend entièrement de l’attribution des attributs dans la base de données d’exigences. En détail :

• Chaque exigence doit être affectée à au moins un élément SBS (EN 15380-5). EuroSpec définit à cet effet l’attribut system element.
• Les exigences d’interface doivent être identifiées comme telles, idéalement en indiquant les deux sous-systèmes concernés afin qu’elles apparaissent dans les deux cahiers des charges partiels.
• Les exigences transversales doivent porter un attribut les identifiant comme inter-systèmes (par ex. scope = cross-cutting).
• Les références normatives doivent être saisies de façon structurée, comme entités propres avec numéro de norme, version et section, et non seulement en texte libre dans l’exigence.
• Les allocations RAMS doivent être modélisées comme exigences dérivées, avec un lien de traçabilité vers l’exigence du véhicule complet.

Génération basée sur ReqIF

Le Requirements Interchange Format (ReqIF) prend en charge nativement la génération de cahiers des charges partiels : les exigences sont stockées sous forme d’objets de données structurés avec des attributs typés, filtrables selon n’importe quels critères. Un cahier des charges partiel n’est alors rien d’autre qu’un export ReqIF filtré :

Élément SBS = « Climatisation » OU (type = « Interface » AND systèmeImpliqué = « Climatisation ») OU tag = « Transversal »

Le consortium prostep ivip décrit ReqIF comme un format ouvert permettant l’« échange d’exigences sans perte et indépendant des outils » au-delà des frontières de l’entreprise. Les canaux de communication pris en charge comprennent OEM/OEM, OEM/coentreprise, client/fournisseur et la communication interne entre unités d’affaires. Le fournisseur peut importer directement l’export ReqIF dans son propre système de gestion des exigences, sans ressaisie manuelle depuis un document Word.

Dans la pratique, des problèmes d’interopérabilité documentés subsistent néanmoins : lors de l’ import de ReqIF Polarion dans IBM DOORS, des objets sont marqués comme verrouillés. Les extensions propres aux éditeurs et les incompatibilités de version restent des sujets d’actualité. Les ReqIF Implementor Forums de prostep ivip travaillent depuis 2018, au moyen de benchmarks réguliers, à améliorer l’interopérabilité des outils.

Génération assistée par ALM

Les outils établis dans le secteur ferroviaire offrent différentes approches pour générer des cahiers des charges partiels :

• IBM DOORS : standard de facto depuis des décennies dans les secteurs réglementés. Les modules dotés de vues filtrées n’affichent que les exigences d’un sous-système donné. Les modules filtrés peuvent être enregistrés comme baseline et exportés en ReqIF.
• Siemens Polarion : grâce à sa fonctionnalité LiveDoc, il produit des documents dynamiques qui se mettent automatiquement à jour lorsque les exigences sous-jacentes changent. Support ReqIF natif pour l’export sans perte de paquets d’exigences filtrés.
• Reqtify de Dassault Systèmes : surcouche de traçabilité avec plus de 100 interfaces, reliant les exigences sur l’ensemble du cycle en V. Offre une génération de rapports configurable pour les analyses de couverture et d’impact par sous-système.

Assurance qualité : ce que le cahier des charges partiel doit contenir

Un bon cahier des charges partiel est plus qu’un extrait filtré d’exigences. Le fournisseur doit pouvoir comprendre les exigences dans leur contexte, les évaluer correctement et y répondre de manière complète. La directive DB relative à l’assurance qualité lors de l’acquisition de véhicules ferroviaires et ISO 22163:2023 exigent une traçabilité sans lacune sur toute la chaîne d’approvisionnement.

Composantes d’un cahier des charges partiel de haute qualité par pertinence (évaluation qualitative fondée sur le modèle d’attributs EuroSpec et les exigences ISO 22163).

Cas particulier : l’allocation RAMS au niveau du sous-système

La série de normes CENELEC EN 5012x exige des démonstrations de sécurité fonctionnelle sur tout le cycle de vie RAMS. EN 50126 définit 12 phases de cycle de vie et exige l’allocation des objectifs RAMS au niveau des sous-systèmes. Pour les cahiers des charges partiels, cela signifie :

• La disponibilité du véhicule complet (par ex. 99,5 %) doit être déclinée sur les sous-systèmes. Chaque sous-système reçoit sa propre valeur cible MTBF et MTTR.
• La traçabilité entre l’exigence RAMS du véhicule complet et l’exigence de sous-système dérivée doit être documentée dans le cahier des charges partiel.
• Si le fournisseur ne peut pas respecter la valeur MTBF allouée, cela affecte la disponibilité du véhicule complet et, par conséquent, tous les autres sous-systèmes. Plus ces boucles de rétroaction sont détectées tard, plus elles coûtent cher.

Révisions et cahiers des charges partiels : le double défi

Lorsque le donneur d’ordre publie une nouvelle révision du cahier des charges global (voir également notre article suivi des révisions dans les cahiers des charges), tous les cahiers des charges partiels doivent eux aussi être mis à jour. L’ étude du Parlement européen (2023) sur les achats de matériel roulant indique que les phases d’appel d’offres en Allemagne durent 7 à 8 ans. Durant cette période, plusieurs révisions du cahier des charges sont la règle.

Le défi est double :

• Quels sous-systèmes sont concernés ? Une modification d’une exigence de protection incendie (EN 45545) peut concerner tous les sous-systèmes. Une modification d’une exigence de climatisation ne concerne que le système HVAC et ses partenaires d’interface. Sans attribution structurée des attributs, l’analyse d’impact est une opération manuelle à répéter à chaque révision.
• Qu’est-ce qui a changé ? Le fournisseur ne doit pas seulement savoir que son cahier des charges partiel a été mis à jour, mais exactement quelles exigences ont changé, sur le fond et pas seulement sur la forme. Sans cette transparence, il risque de tout retravailler.

Avec une attribution structurée des attributs, cela fonctionne mieux : la comparaison des deltas au niveau du cahier des charges global peut être filtrée par élément SBS, de sorte que chaque fournisseur ne reçoit que les changements qui le concernent. La spécification EuroSpec est précisément conçue à cet effet : les modifications sont suivies « au niveau de l’exigence individuelle et au niveau du sous-système ». Avec une création manuelle, en revanche, chaque révision implique de vérifier et mettre à jour à la main tous les cahiers des charges partiels. Dès la troisième révision, cet effort devient difficile à justifier.

Génération de cahiers des charges partiels assistée par IA

Selon le Loopio 2025 RFP Response Trends Report, 68 % des équipes de réponse aux appels d’offres utilisent déjà l’IA générative, tous secteurs confondus — deux fois plus qu’en 2023 (34 %). Dans l’industrie ferroviaire, cela est encore peu répandu, bien que des plateformes spécialisées comme Tendric proposent déjà l’affectation de sous-systèmes assistée par IA. Pour la création de cahiers des charges partiels, deux cas d’usage concrets se dégagent :

Cahiers des charges partiels pour les appels d’offres multi-produits

La situation se complique encore lorsque l’appel d’offres comprend plusieurs variantes de véhicules, par exemple un train régional et une variante de RER sur la même plateforme. Une même exigence peut avoir une affectation de sous-système différente selon la variante. Le fournisseur a alors besoin d’un cahier des charges partiel par variante, ou d’un document combiné avec un marquage clair des variantes.

Ce cas est traité en détail dans l’article Appels d’offres multi-produits : maîtriser plusieurs variantes dans un projet. En résumé : le modèle d’attributs doit prendre en charge la variante de produit comme dimension de filtrage, en plus de l’élément SBS.

Conclusion

Créer des cahiers des charges partiels manuellement ne passe pas à l’échelle. Aucun outil isolé ne résout le problème à lui seul, mais quatre éléments le font ensemble :

1. Attribution structurée d’attributs selon EN 15380-5 : chaque exigence doit être affectée à un élément SBS, avec une identification claire des exigences d’interface et transversales.
2. Échange de données standardisé via ReqIF : afin que le fournisseur puisse importer directement les exigences dans son propre système, sans ressaisie manuelle.
3. Génération de documents fondée sur des modèles : modèles de documents par sous-système, remplis automatiquement à partir de la base de données d’exigences.
4. Allocation RAMS et gestion des normes intégrées : afin que les exigences de sous-système dérivées et les références normatives arrivent automatiquement dans les bons cahiers des charges partiels.

Qui dispose de ces quatre éléments accélère considérablement la création de cahiers des charges partiels et calcule automatiquement le delta par sous-système lors des révisions. Il n’est pas nécessaire de tout mettre en œuvre d’un coup : de la création manuelle à la génération entièrement automatisée avec assistance IA pour l’affectation, le niveau de maturité peut progresser étape par étape. Des outils comme Tendric répondent précisément à cette démarche progressive et prennent en charge à la fois l’export Excel pour les workflows existants et la gestion structurée des exigences avec affectation aux sous-systèmes.