Routage des experts : attribuer les exigences aux bonnes personnes

Introduction

Un cahier des charges pour un véhicule ferroviaire contient des centaines, voire des milliers d’exigences individuelles. Traction, freinage, protection incendie, climatisation, information voyageurs, accessibilité, maintenance : chaque discipline possède ses propres normes, obligations de justification et vocabulaire technique. Aucun ingénieur ne peut tout évaluer seul. Le responsable de l’offre répartit donc les exigences entre des experts métier issus de différents services et disciplines. Ce processus est appelé routage des experts.

Ce qui paraît simple est, dans la pratique, l’un des principaux goulets d’étranglement de la préparation des offres. Dès 2014, un responsable d’un fabricant de systèmes de freinage indiquait à CONTACT Software que le nombre d’exigences à commenter avait au moins décuplé au cours des dix années précédentes. Durant la même période, le volume des documents d’appel d’offres était passé d’un CD à un DVD. Depuis, ce volume a encore augmenté, tout comme le nombre d’experts impliqués.

Les chiffres sont comparables dans tous les secteurs : selon le Loopio 2025 RFP Response Trends Report (plus de 1 500 entreprises, tous secteurs confondus), 48 % des équipes de réponse aux appels d’offres citent la collaboration avec les experts métier comme leur plus grand défi, pour la cinquième année consécutive. Dans le secteur ferroviaire, où 10 à 30 équipes de sous-systèmes travaillent généralement en parallèle, la charge de coordination réelle est sans doute encore plus élevée.

Pourquoi le routage des experts est déterminant

La qualité d’une offre dépend directement du fait que chaque exigence soit évaluée par le bon expert métier. Un ingénieur en protection incendie peut classer avec compétence une exigence relative à EN 45545 mais pas une exigence de compatibilité ETCS. À l’inverse, un ingénieur en signalisation ne peut pas se prononcer sur la résistance structurelle selon EN 12663. Le INCOSE Requirements Working Group définit l’allocation des exigences — l’attribution d’exigences à des éléments de système et à des personnes responsables — comme l’une des activités centrales de la gestion des exigences, au même rang que la traçabilité et la vérification.

Les erreurs de routage ont des conséquences directes :

• Mauvaise classification : un non-expert classe une exigence comme « OK » alors qu’elle n’est réalisable que sous conditions (OKB). Dans le projet, cela devient une demande de modification.
• Retards : une exigence arrive dans le mauvais service, est transférée et se retrouve de nouveau dans une file d’attente. Des jours sont perdus. Selon Loopio, 33 % des équipes indiquent que des réponses plus rapides des experts seraient leur principal levier pour gagner davantage d’appels d’offres.
• Travail en double : sans responsabilité clairement définie, deux services traitent la même exigence indépendamment l’un de l’autre, avec des résultats potentiellement contradictoires.
• Lacunes : une exigence n’est attribuée à aucun expert et reste sans traitement. Dans le pire des cas, la réponse manque dans le cahier des charges détaillé.

Source : CONTACT Software : Bummelzug zum Anforderungsmanagement

La structure LH et EN 15380 : comment les cahiers des charges sont organisés

Dans le secteur ferroviaire, les cahiers des charges sont généralement structurés en sections thématiques couvrant différents sous-systèmes et corps de métier. Une structure courante utilise les catégories dites LH (LH1 à LH8), que le guide VDB de la gestion des exigences décrit comme une aide à la structuration.

Parallèlement, la série de normes EN 15380 définit un système de classification standardisé pour les véhicules ferroviaires. La partie 2 (groupes de produits) divise un véhicule en groupes de produits nommés, la partie 4 (groupes de fonctions) affecte des fonctions comme la traction, le freinage ou la commande des portes, et la partie 5 (System Breakdown Structure) définit la décomposition hiérarchique en systèmes principaux et sous-systèmes. EN 15380 est donc pertinente pour le routage des experts car elle fournit une taxonomie stable et indépendante des constructeurs : si chaque exigence est affectée à un sous-système EN 15380, la décision de routage peut être automatisée ou au moins standardisée.

Volume typique d’exigences par catégorie LH (représentation relative, variable selon le projet et le donneur d’ordre).

La structure LH constitue la base naturelle du routage des experts : les exigences LH3 vont à la traction, LH6 à l’aménagement intérieur, LH7 au service IT. Pourtant, l’affectation est rarement aussi évidente que la structure le laisse entendre.

Le workflow de routage dans la pratique

Qu’une entreprise travaille avec Excel, un système ALM ou une plateforme spécialisée, le processus de routage suit un schéma comparable :

RACI et matrices de compétences : systématiser le routage

Pour les grands cahiers des charges, attribuer les exigences au cas par cas ne suffit pas. Les entreprises qui ont systématisé le processus utilisent deux outils :

Matrice RACI pour le routage : pour chaque catégorie LH (ou chaque sous-système EN 15380), elle définit qui est Responsible, Accountable, Consulted et Informed. L’ingénieur traction est par exemple Responsible pour les exigences LH3 et Consulted pour les exigences LH4 ayant une interface de traction. La matrice RACI évite que les exigences transversales ne se perdent dans l’affectation, car le rôle de consultation (Consulted) est documenté explicitement.

Matrice de compétences par projet : un tableau d’affectation qui documente, pour chaque expert métier disponible, les normes, sous-systèmes et technologies qu’il peut couvrir. Lorsqu’un cahier des charges contient pour la première fois des exigences relatives à la traction hydrogène, la matrice indique immédiatement si le savoir-faire est disponible en interne ou doit être acquis à l’extérieur. La plupart des entreprises construisent leur matrice à partir de projets antérieurs et l’actualisent projet par projet.

Où se créent les pertes de fluidité

Sur le papier, ce workflow paraît linéaire. La réalité est différente.

1. Le problème de la répartition

Pour un cahier des charges de 1 500 exigences, l’affectation initiale peut à elle seule durer plusieurs jours ouvrés si elle est effectuée manuellement. Le responsable de l’offre doit lire, comprendre et attribuer chaque exigence au bon expert. Pour les exigences transversales, la décision n’est pas triviale, surtout si le responsable de l’offre ne connaît pas toutes les disciplines avec la même précision. Dans le secteur technologique, selon Loopio , 57 % des équipes signalent même des difficultés de coordination des experts métier, le taux le plus élevé de tous les secteurs.

2. Disponibilité des experts

Les experts métier du secteur ferroviaire ne sont pas des collaborateurs dédiés aux offres. Ils travaillent en parallèle sur des projets en cours, des tâches de développement et d’autres appels d’offres. Lorsqu’un expert en protection incendie est mobilisé pendant deux semaines sur un projet d’homologation, ses exigences restent en attente, quel que soit le système de routage utilisé par l’entreprise. Selon sa propre page fournisseurs , Alstom coordonne environ 19 000 fournisseurs dans 77 pays. Chacun d’eux a ses propres goulots de capacité, qui influencent les délais de réponse de l’OEM.

3. Manque de transparence sur l’état de traitement

Dans les workflows basés sur des documents (Excel, Word envoyés par e-mail), le responsable de l’offre ne dispose pas d’une vue en temps réel des exigences déjà traitées, de celles qui restent ouvertes et des points où se forment les goulets d’étranglement. Les demandes de statut par e-mail ou en réunion prennent du temps et fournissent souvent des résultats imprécis. Selon Loopio, 39 % des équipes ont des difficultés à trouver des réponses actuelles et précises aux questions techniques. Dans le secteur ferroviaire, où les exigences renvoient fréquemment à des sources normatives qui changent d’une révision à l’autre, ce problème est particulièrement marqué.

4. Problèmes de cohérence

Lorsque 20 experts traitent des exigences indépendamment les uns des autres, des contradictions peuvent apparaître : le service A classe une interface « OK », le service B classe l’exigence réciproque correspondante « OKB ». Ces incohérences ne sont souvent détectées qu’à la phase de consolidation tardive, lorsque le temps pour les corriger est limité. La norme EuroSpec de gestion des exigences traite ce problème à travers ses six domaines clés (caractéristiques des exigences, syntaxe, attributs, traçabilité, validation/vérification, échange de données), mais le respect de ces normes suppose que tous les experts impliqués travaillent dans le même système.

Modèles organisationnels pour le routage

La manière dont les entreprises organisent le routage des experts dépend de leur taille, de leur organisation et du niveau de soutien outillé. Trois modèles sont courants dans la pratique :

La plupart des entreprises utilisent un modèle hybride : le responsable de l’offre effectue la pré-répartition grossière au niveau des sous-systèmes (sur la base des catégories LH ou de l’affectation EN 15380), puis les responsables de sous-systèmes répartissent finement dans leur domaine. Les exigences transversales sont identifiées par le responsable de l’offre et attribuées plusieurs fois. Dans les grands appels d’offres en consortium, comme le contrat de 15 milliards d’EUR pour le S-Bahn de Berlin (DB, Siemens, Stadler), les exigences sont en outre réparties entre les partenaires du consortium, ce qui ajoute un niveau de routage supplémentaire.

Traçabilité : ce qu’exigent EN 50126 et ISO 22163

Le routage des experts est aussi une exigence réglementaire. La CENELEC EN 50126 définit le cycle de vie RAMS (fiabilité, disponibilité, maintenabilité, sécurité) et exige une traçabilité complète dans le cadre du modèle en V. Chaque exigence doit pouvoir être rattachée à une activité de vérification, à un responsable et à une preuve. La spécification et l’allocation des exigences système constituent une phase propre du cycle de vie du modèle en V, avec des rôles définis pour chaque phase. Savoir qui a évalué quelle exigence fait partie du dossier de sécurité ; ce n’est pas une option.

La ISO 22163:2023 (IRIS Rev. 04) exige, dans ses sections consacrées à la conception et au développement, la traçabilité des exigences clients jusqu’à la preuve de conception. IRIS va au-delà d’ISO 9001 et ajoute des exigences ferroviaires spécifiques en matière de gestion de projet, First Article Inspection (FAI), démonstrations RAMS et coûts du cycle de vie. La norme s’applique à toute la chaîne d’approvisionnement : de l’entreprise de développement au fabricant et au fournisseur, jusqu’à l’opérateur de maintenance. Dans le contexte des offres, cela signifie que l’affectation des exigences aux experts métier et leurs évaluations doivent être documentées de manière traçable, non seulement pour l’équipe projet interne, mais aussi pour les auditeurs externes et l’organisme de certification IRIS.

Outils pour le routage des experts

Les outils vont des tableaux Excel aux systèmes ALM. Le choix de l’entreprise détermine dans quelle mesure le routage, le suivi des statuts et la traçabilité fonctionnent au quotidien.

Excel avec colonnes d’affectation

L’approche la plus simple : chaque ligne d’exigence reçoit une colonne « Responsable » dans laquelle est inscrit le nom de l’expert métier. Des vues filtrées par expert permettent une répartition rudimentaire du travail. Inconvénients : pas de notifications, pas de suivi de statut, pas de traitement parallèle (la célèbre question « Qui a la version actuelle ? »). L’ article de CONTACT Software rapportait en 2014 que même Deutsche Bahn n’avait que « récemment » introduit un système de gestion des exigences reposant sur une base de données.

IBM DOORS / DOORS Next

Le système leader de gestion des exigences dans les secteurs ferroviaire et aéronautique. DOORS offre des affectations fondées sur des règles, la traçabilité et des analyses d’impact des changements. Exemple concret : Rail Projects Victoria (Melbourne) a choisi DOORS Next comme solution SaaS pour le Metro Tunnel Project de 11 milliards AUD. Le système a créé un environnement central et collaboratif dans lequel les exigences pouvaient être gérées en temps réel à travers de multiples parties prenantes internes et externes. Point particulièrement pertinent pour le routage : l’intégration des Hazard Logs et des registres d’interfaces garantissait que les contrôles et les exigences étaient correctement affectés aux bonnes parties. RPV applique désormais les connaissances acquises à d’autres projets, dont Regional Rail Revival et Melbourne Airport Rail.

Siemens Polarion

Polarion est l’alternative de Siemens avec le même éventail de fonctions. Hitachi Rail a intégré Polarion à ses workflows de projet afin de remplacer Excel et Word comme supports d’exigences. Depuis 2025, Polarion propose également des fonctions assistées par IA pour l’extraction automatique d’exigences à partir de documents d’appel d’offres. L’IA analyse les objets d’exigence par domaine et, sur la base des responsabilités associées aux domaines identifiés, les affecte aux services compétents ; selon Siemens, cela réduit l’effort manuel jusqu’à 70 %.

Plateformes spécialisées

À côté des grands systèmes ALM, des plateformes spécialisées, centrées sur le processus de réponse aux appels d’offres, se développent de plus en plus. Tendric s’appuie par exemple sur un routage fondé sur des règles, avec une barrière d’entrée plus faible que DOORS ou Polarion, mais un support ciblé pour le routage, la classification et l’export du cahier des charges détaillé. Les données intersectorielles montrent que les équipes disposant d’une bibliothèque de contenus structurée atteignent un taux de réutilisation de 66 % et ont presque deux fois plus de chances d’obtenir des taux de gain élevés. Les plateformes spécialisées interviennent là où Excel ne passe plus à l’échelle, mais où un système ALM complet serait surdimensionné.

L’IA peut-elle automatiser le routage ?

L’affectation automatique des exigences aux experts métier est un cas d’usage naturel des systèmes basés sur l’IA. L’idée centrale : lorsqu’un système apprend, à partir de milliers d’exigences historiquement affectées, quelles formulations et quels thèmes appartiennent à quel service, il peut proposer une première affectation pour les nouveaux cahiers des charges.

Pour les exigences clairement attribuables, cela fonctionne bien : une exigence contenant « EN 45545 » ou « classe de protection incendie » est affectée de manière fiable à l’équipe incendie. Des systèmes modernes comme Polarion avec couche IA vont plus loin : ils comprennent la sémantique des exigences (et non la seule correspondance de mots-clés), comparent les nouvelles exigences aux existantes et détectent automatiquement les changements entre révisions. Toutefois, pour les exigences transversales ou les formulations inédites (par exemple traction hydrogène, FRMCS successeur de GSM-R), le taux de réussite baisse nettement.

Selon Loopio , 68 % des équipes de réponse aux appels d’offres utilisent déjà l’IA générative dans tous les secteurs, soit le double des 34 % de 2023. Parmi celles qui utilisent l’IA, 70 % le font au moins chaque semaine. Dans le ferroviaire, cette évolution n’en est encore qu’à ses débuts, mais les premières solutions intégrées (Polarion AI, DRIM, Tendric) montrent la direction prise.

Cas pratique : Melbourne Metro Tunnel Project

Le Melbourne Metro Tunnel Project est l’un des plus grands projets d’infrastructure d’Australie : un nouveau corridor ferroviaire souterrain destiné à plus de 500 000 voyageurs supplémentaires par semaine, pour un volume de 11 milliards AUD. Rail Projects Victoria (RPV) devait coordonner des milliers d’exigences sur plusieurs lots de travaux et entre des centaines d’ingénieurs issus de différentes organisations.

RPV a choisi IBM Engineering Requirements Management DOORS Next comme solution SaaS. Le résultat : un environnement collaboratif central et sécurisé, faisant office de « source unique de vérité », dans lequel les exigences pouvaient être gérées en temps réel et partagées sélectivement avec chaque organisation, en fonction de ses domaines fonctionnels dans le projet. L’intégration des Hazard Logs et des registres d’interfaces garantissait que les exigences étaient correctement affectées aux bonnes parties.

Sur la base de cette expérience, RPV développe maintenant un cadre standardisé de gestion des exigences qui doit être transféré à d’autres projets (Regional Rail Revival, Melbourne Airport Rail).

Conclusion

Le routage des experts est le goulet d’étranglement invisible de la préparation des offres dans le secteur ferroviaire. Le défi ne réside pas seulement dans la technique, mais dans la combinaison du volume (des centaines à des milliers d’exigences), de la complexité (des dizaines de disciplines spécialisées, des normes allant des STI à CENELEC et ISO 22163) et de la pression du temps (des délais de remise de quelques semaines).

Un bon système de routage, qu’il repose sur des tableaux ou sur des outils, doit remplir quatre fonctions : une répartition initiale rapide fondée sur une taxonomie stable (catégories LH, EN 15380), un suivi transparent des statuts en temps réel, une documentation traçable pour la traçabilité EN 50126 et l’équilibrage de charge entre tous les experts impliqués.

IBM DOORS et Siemens Polarion couvrent le segment enterprise, les plateformes spécialisées comme Tendric celui des ETI, et les solutions assistées par IA l’allocation initiale. Mais plus que le choix de l’outil, c’est la discipline qui compte : matrices RACI, affectations de compétences, suivi systématique. Car le plus grand risque n’est pas le mauvais outil, mais des exigences qui ne sont attribuées à aucun expert ou dont personne ne connaît l’état de traitement.