Suivi des révisions : détecter les changements et transférer le travail

Introduction

Peu de situations mettent autant les responsables d'offres mal à l'aise que le message : „Une nouvelle révision du cahier des charges est disponible.“ Après avoir consacré des semaines à classifier, affecter des experts et traiter des centaines d'exigences, une question se pose : qu'est-ce qui a changé et quelle part du travail déjà effectué peut être conservée ?

Selon la UNIFE World Rail Market Study 2024 le marché européen du matériel roulant représente 63,3 milliards d'euros, avec une croissance annuelle de 7,3 % en Europe occidentale. Tous ces projets d'achat commencent par un cahier des charges et presque tous sont révisés au moins une fois pendant la phase d'offre. Dans les grands appels d'offres de transport ferroviaire régional, il n'est pas rare de compter de trois à cinq révisions entre la première publication et la signature du contrat, après des questions de soumissionnaires, des changements réglementaires, des décisions politiques ou des adaptations de lignes.

Dans Software Engineering Economics, Barry Boehm a montré dès 1981 que le coût d'une modification d'exigence augmente de façon exponentielle lorsqu'elle est détectée tardivement : d'un facteur 1 pendant la phase d'exigences à un facteur de 10 à 100 en production. Dans le ferroviaire, l'effet est encore plus marqué. Omettre une exigence modifiée pendant l'offre entraîne des reprises et une lacune de conformité qui peut, dans le pire des cas, compromettre l'homologation.

Voici comment le suivi des révisions fonctionne en pratique, pourquoi il est imposé par la réglementation, où se situent les difficultés et quels outils peuvent aider.

Pourquoi les cahiers des charges sont révisés

Dans l'industrie ferroviaire, les révisions de cahier des charges sont la règle, non l'exception. Elles ont plusieurs causes :

• Questions des soumissionnaires : pendant la phase d'offre, les fournisseurs demandent des précisions ou signalent des contradictions. Le donneur d'ordre répond de manière groupée et publie un cahier des charges révisé. Un corrigendum corrige les erreurs du document initial, tandis qu'un addendum ajoute des contenus ou des conditions qui n'y figuraient pas. Les deux créent une nouvelle révision.
• Évolutions réglementaires : entre la rédaction du cahier des charges et le dépôt de l'offre, des révisions des STI ou de nouvelles normes EN peuvent être adoptées. Le donneur d'ordre met alors à jour les références normatives. L'ERA définit à elle seule 11 STI pour les véhicules ferroviaires, et la modification de l'une d'elles peut toucher des dizaines d'exigences.
• Changements politiques ou financiers : réductions budgétaires, adaptations de lignes, nouvelles exigences d'accessibilité (STI PMR) ou concepts d'exploitation modifiés changent le catalogue d'exigences. Une étude du Parlement européen de 2023 sur la compétitivité de l'industrie ferroviaire a établi qu'en Allemagne, sept à huit ans s'écoulent généralement entre l'appel à la concurrence et la production en série. Les priorités politiques peuvent changer plusieurs fois sur cette période.
• Fragmentation nationale : les normes nationales différentes laissent place à des interprétations. Comme le blog de CONTACT Software le documente, des donneurs d'ordre tirent des exigences différentes des mêmes normes. Lorsqu'ils constatent ces incohérences, une révision suit.
• Corrections rédactionnelles : fautes de frappe, identifiants d'exigences manquants ou renvois incohérents. Même ces corrections mineures entraînent un nouveau numéro de révision.

Le coût d'un mauvais suivi des révisions

Lorsque le suivi des révisions ne fonctionne pas, les coûts apparaissent à trois niveaux :

• Reprise directe : lorsqu'une équipe travaille sur une exigence obsolète sans avoir vu la modification, elle produit des résultats qu'il faut reprendre entièrement une fois l'erreur découverte. Avec plus de 1 000 exigences et 15 à 30 équipes de sous-systèmes impliquées, une seule modification substantielle manquée peut provoquer des semaines de reprise.
• Risque de conformité : EN 50126 impose la traçabilité complète de chaque modification d'exigence sur l'ensemble du cycle de vie RAMS. Sans documentation des changements, l'offre en cours et l'homologation ultérieure du véhicule par l'organisme notifié (NoBo) sont menacées.
• Risque contractuel : des engagements de conformité dans le cahier des charges détaillé, fondés sur une ancienne révision, peuvent entraîner une baisse de notation ou l'exclusion. Les priorités UNIFE 2024 à 2029 mettent l'accent sur le principe MEAT (Most Economically Advantageous Tenders) et les coûts du cycle de vie. Les incohérences dans la matrice de conformité sont sanctionnées.

Source : CONTACT Software, Bummelzug zum Anforderungsmanagement

Une analyse du secteur ferroviaire australien chiffre les économies possibles grâce à une clarification précoce et à une gestion structurée des exigences jusqu'à 30 % des coûts du projet. À l'inverse, mal suivre les révisions et détecter tard les changements expose à des dépassements budgétaires importants dus à des reprises évitables.

Ce qu'une révision implique pour le travail en cours

Lorsqu'un responsable d'offre reçoit une révision d'un cahier des charges, il doit prendre plusieurs décisions dans un ordre défini. Le Systems Engineering Body of Knowledge (SEBoK) de l'INCOSE décrit ainsi le processus : dès que les exigences sont „defined, assessed, and approved“, elles sont figées comme référence. Chaque modification doit ensuite contenir le „rationale why the change is necessary“ et être évaluée dans toute la hiérarchie d'architecture, „including suppliers“.

Dans la pratique quotidienne d'un responsable d'offre, cela signifie :

La comparaison manuelle : pourquoi elle ne passe pas à l'échelle

La première approche pour détecter le delta est la comparaison manuelle : ouvrir les deux versions côte à côte et les examiner ligne par ligne. Elle peut convenir pour un cahier des charges de 20 exigences. Pour un cahier des charges typique de transport régional, elle n'est pas praticable.

Le blog de CONTACT Software documentait déjà en 2014, que les documents de spécification d'un seul appel d'offres étaient passés „d'un CD à un DVD“. Leur volume a encore augmenté depuis. La comparaison manuelle de deux versions d'un document de cette taille prend du temps et provoque des erreurs. Après des heures à comparer deux tableaux Excel ligne par ligne, on manque forcément des éléments. C'est humain.

Même lorsqu'un donneur d'ordre joint un journal de révision, ce qui n'est pas toujours le cas, il risque d'être incomplet. Les responsables d'offres expérimentés le savent : faites confiance au delta, pas à la lettre d'accompagnement.

La comparaison fondée sur les identifiants : le socle

La méthode la plus fiable pour détecter un delta repose sur des identifiants d'exigences uniques. Chaque exigence d'un cahier des charges possède un identifiant stable, par exemple REQ-LH3-0147, qui est conservé d'une révision à l'autre. L'algorithme de comparaison est alors simple :

• ID présente en rév. B, absente en rév. A → nouvelle exigence
• ID présente en rév. A, absente en rév. B → exigence supprimée
• ID présente dans les deux, texte identique → inchangée, travail transférable
• ID présente dans les deux, texte différent → modifiée, vérification nécessaire

Cette approche suppose que le donneur d'ordre emploie des identifiants stables, ce que le guide VDB de gestion des exigences recommande expressément. Ce guide normalise la création, l'échange et le commentaire des spécifications entre donneurs d'ordre, constructeurs de véhicules et fournisseurs. Il prévoit l'échange électronique au format ReqIF et précise qu'avec ce format, „les nouvelles entrées et les modifications peuvent être détectées immédiatement par un marquage automatisé, ce qui évite les pertes de temps liées aux comparaisons lourdes avec les états de travail précédents.“

Le guide VDB recommande aussi de vérifier en amont la compatibilité des implémentations ReqIF, signe que les problèmes d'interopérabilité sont bien réels. Le ProSTEP iViP ReqIF Implementor Forum a mené six benchmarks jusqu'en 2024. Le plus récent couvrait 56 combinaisons de systèmes et 2 800 critères d'évaluation. Malgré ces progrès, les extensions propres aux éditeurs et les incompatibilités de versions restent difficiles à gérer.

EuroSpec et EN 15380 : les attributs du suivi des modifications

L' initiative EuroSpec (European Specification for Railway Vehicles) a défini un modèle d'attributs pour les exigences dans sa spécification Requirements Management, version 3.0. La spécification couvre six domaines : caractéristiques des exigences, syntaxe, attributs, traçabilité, validation/vérification et échange de données. Les attributs suivants comptent particulièrement pour le suivi des révisions :

• ID : identifiant unique et stable de l'exigence
• Status : état actuel du traitement dans le cycle de vie
• Change History : historique documenté des modifications avec horodatage et description
• Source : origine de l'exigence, donneur d'ordre, norme ou document interne
• Traceability : lien avec les exigences, preuves et risques associés
• Comments : commentaires libres justifiant la modification

EuroSpec structure les exigences selon l' EN 15380-5, la norme européenne relative à la System Breakdown Structure (SBS) des véhicules ferroviaires. La série EN 15380 comporte plusieurs parties : partie 2, groupes de produits ; partie 4, groupes fonctionnels ; partie 5, structure du système. Cette structuration permet de suivre les changements non seulement au niveau de l'exigence individuelle, mais aussi au niveau du sous-système : „LH3, la traction, a connu 12 changements, LH6, l'aménagement intérieur, aucun.“

Concrètement, lorsqu'une révision contient 47 exigences modifiées, dont 40 concernent LH5, les systèmes de freinage, et seulement 7 d'autres sous-systèmes, les experts concernés peuvent être avertis de façon ciblée. Sans agrégation par sous-système, chaque expert doit examiner toute la liste du delta. Avec 15 à 30 équipes impliquées, cela consomme du temps.

Cadre réglementaire : EN 50126, ISO 22163 et INCOSE

Le suivi des révisions est aussi une exigence réglementaire. Plusieurs normes le demandent simultanément, avec des exigences qui se recoupent parfois.

CENELEC EN 50126 : cycle de vie RAMS et gestion de configuration

La CENELEC EN 50126 définit le cycle de vie RAMS, Reliability, Availability, Maintainability, Safety, pour toutes les applications ferroviaires. La norme exige une gestion de configuration documentée à chaque phase du cycle de vie : chaque changement d'exigence doit être documenté, approuvé et traçable, de la définition du concept jusqu'au retrait du service.

Cela commence dès la phase d'offre, et non au début du développement. Les engagements de conformité pris à ce stade constituent la première référence du projet ultérieur. Si elle repose sur une révision obsolète du cahier des charges, des incohérences apparaissent lors de l'examen par l' organisme notifié (NoBo). Comme LDRA le résume, la famille de normes EN 5012x impose une traçabilité entre tous les artefacts de développement, une chaîne qui commence par la référence des exigences.

ISO 22163:2023 (IRIS Rev. 04) : configuration et contrôle des changements réunis

La ISO 22163:2023 a été publiée en juillet 2023 comme norme internationale complète, après avoir existé sous la forme de la spécification technique ISO/TS 22163:2017. Sa principale nouveauté structurelle est la réunion des anciens sous-sections 8.1.4, „gestion de configuration“, et 8.1.5, „gestion des changements“, dans une section commune 8.1.4, „gestion de configuration et contrôle des changements“.

Cette réunion n'est pas seulement cosmétique. La norme traite désormais le suivi des changements comme une partie de la configuration, et non comme un processus séparé. La IRQB Guideline 8 (Configuration & Change Management) fournit des instructions détaillées de mise en œuvre. La norme demande précisément :

• des procédures documentées pour identifier et contrôler les modifications ;
• une évaluation de l'effet de chaque modification avant sa mise en œuvre, ou Change Impact Analysis ;
• la traçabilité : qui a changé quoi, à quel moment et pour quelle raison ?
• la gestion des références : des états de configuration définis et figés comme points de référence.

La certification IRIS selon les nouvelles règles IRIS Rev. 04 est obligatoire pour tous les audits depuis le 1er janvier 2024. L' UNIFE (Union des Industries Ferroviaires Européennes) est propriétaire des règles de certification.

Source : DQS Global, IRIS Revision 04

INCOSE et SEBoK : bonnes pratiques d'ingénierie système

Au-delà des normes propres au ferroviaire, le Systems Engineering Body of Knowledge (SEBoK) de l'INCOSEénonce des principes généraux de gestion des exigences. Quatre s'appliquent directement au suivi des révisions :

• Baselining : les exigences approuvées sont figées comme référence. Toute modification exige une justification formelle et une analyse d'impact.
• Traçabilité bidirectionnelle : chaque exigence doit être traçable jusqu'aux scénarios d'exploitation, risques, exigences liées et artefacts de vérification.
• Contrôle des changements : l'INCOSE recommande d'établir le processus de contrôle des changements „early in the effort“, et non seulement à l'arrivée de la première révision.
• Intégration des fournisseurs : les changements doivent être évalués à „multiple levels in the architecture hierarchy (including suppliers)“. C'est particulièrement important pour les OEM qui comptent plus de 10 000 fournisseurs.

Outils de suivi des révisions

Les outils vont des approches manuelles aux systèmes ALM intégrés. Le choix détermine la quantité de travail automatiquement reprise lors d'une révision et celle qui doit être refaite manuellement.

Word/PDF : comparaison Redline

Microsoft Word propose une fonction intégrée de comparaison de documents, „Comparer des documents“, qui marque les changements sous forme de Redline. C'est un premier repère pour les documents libres, mais l'approche atteint ses limites avec des listes d'exigences structurées : Word compare du texte, non des exigences. Une exigence déplacée apparaît comme une suppression suivie d'une création, non comme un déplacement. Il n'est pas possible de transférer automatiquement la classification existante ou le commentaire d'expert vers la nouvelle version.

Excel : formules et RECHERCHEV

Dans les flux de travail fondés sur Excel, une comparaison par identifiant peut s'appuyer sur des formules RECHERCHEV (VLOOKUP) : les identifiants de l'ancienne révision sont rapprochés de ceux de la nouvelle, et les différences de texte sont détectées avec des formules EXACT. Cette approche fonctionne mais reste fragile, notamment face aux décalages de colonnes et aux changements de format, et elle ne crée pas d'historique durable. À la révision suivante, la logique de formule doit être reconstruite. Le blog de CONTACT Software constatait déjà en 2014 que de nombreux petits fournisseurs ferroviaires échangeaient encore leurs exigences par Excel. La situation n'a évolué que lentement depuis.

IBM DOORS : références et analyse d'impact

IBM DOORS (Dynamic Object Oriented Requirements System) est la norme de fait des secteurs réglementés depuis les années 1990. Le système offre une prise en charge native des baselines, des instantanés figés d'un état d'exigences servant de référence pour les comparaisons ultérieures. Sa fonction de comparaison de baselines montre la différence exacte entre deux états pour chaque exigence, y compris les changements d'attributs.

Dans DOORS Classic, les baselines sont créées au niveau des modules, un modèle qui a fait ses preuves pendant plus de deux décennies. IBM DOORS Next (DNG) suit une autre approche : les baselines sont créées au niveau du composant ou du projet, ce qui apporte des avantages aux grands projets avec plusieurs sous-systèmes. Exemple concret : Rail Projects Victoria (Melbourne) a retenu DOORS Next en SaaS pour le Metro Tunnel Project afin de gérer les exigences de manière centralisée entre plusieurs parties prenantes.

Siemens Polarion : LiveDoc et comparaison de révisions

Siemens Polarion adopte une approche centrée sur le document avec sa fonction LiveDoc : les documents d'exigences sont gérés comme des documents vivants, dans lesquels chaque paragraphe est identifiable et traçable. Toute modification crée automatiquement un Version History Record, et des Document Baselines peuvent être créées à des points définis, par exemple après approbation. Pour chaque baseline, Polarion génère automatiquement un lien vers la LiveDocs Compare View qui montre la différence par rapport à la baseline précédente.

Depuis 2025, Polarion prend aussi en charge l' extraction d'exigences assistée par IA, qui peut également s'appliquer aux documents de révision non structurés, PDF ou Word.

PTC Codebeamer : streams et Delta Merge

PTC Codebeamer propose avec Streams, Baselines et Delta Merge une approche adaptée au Product Line Engineering (PLE) : les Stream Baselines capturent les instantanés de tous les projets d'un stream et Delta Merge permet de réunir les changements de façon contrôlée entre plateformes et variantes. C'est particulièrement pertinent pour les appels d'offres multi-produits, où le même cahier des charges doit recevoir une réponse pour différentes variantes de véhicules.

ReqIF : comparaison structurée des révisions

Le format ReqIF (Requirements Interchange Format) convient au suivi des révisions car il transporte les exigences sous forme d'objets de données structurés, dotés d'identifiants stables et d'attributs typés. Deux fichiers ReqIF, rév. A et rév. B, peuvent être comparés automatiquement, exigence par exigence et attribut par attribut.

La norme a été développée en 2004 par la Herstellerinitiative Software (HIS) de l'industrie automobile allemande, Daimler, VW, Porsche, Audi et BMW Group, puis est maintenue depuis 2011 par l' OMG dans sa version 1.2 de 2016, développée par 14 entreprises. Le ReqIF Implementor Forum, animé par ProSTEP iViP, mène depuis 2018 des benchmarks réguliers d'interopérabilité. Le sixième benchmark de 2024 comprenait 56 combinaisons de systèmes et 2 800 critères d'évaluation.

Une limite importante subsiste : ReqIF ne prévoit pas lui-même l'échange d'un historique des modifications ou de commentaires de modification. La comparaison doit donc se faire au niveau de l'outil : deux fichiers ReqIF sont comparés, mais l'historique n'est pas transporté dans le format. Pour les flux qui nécessitent un historique cumulé sur plusieurs révisions, c'est une lacune que l'outil destinataire doit combler.

Autres outils

Visure Requirements fournit des modèles pour la conformité EN 50126 et relie de bout en bout exigences, tests, risques et artefacts. PHA et FMEA sont intégrées pour l'analyse des risques lors de changements d'exigences. Jama Connect s'appuie sur la „Live Traceability“ : lorsqu'une exigence amont change, tous les éléments aval sont automatiquement marqués comme „suspect“. Cela accélère sensiblement la Change Impact Analysis.

Transférer le travail : la question centrale des révisions

La détection du delta n'est que la première étape. La vraie question est : quelle part du travail existant peut être transférée ?

Transférabilité typique du travail existant selon le type de modification, appréciation qualitative qui varie selon la révision.

En pratique, 60 à 80 % des exigences restent inchangées entre deux révisions ; le travail existant peut donc être repris directement pour la plus grande part. Le Bidara Research estime à 66 % le taux de réutilisation du contenu dans les appels d'offres, tous secteurs confondus. Dans le ferroviaire, ce taux est sans doute encore plus élevé entre les révisions, car les changements substantiels ne touchent généralement qu'une partie des exigences.

Tout dépend de la capacité de l'outil à faciliter cette reprise ou de la nécessité pour le responsable d'offre de recopier manuellement classifications et commentaires dans la nouvelle version. Dans des systèmes ALM comme DOORS ou Polarion, et dans des plateformes spécialisées comme Tendric, la migration du travail peut être largement automatisée. Dans les flux Excel, elle signifie du copier-coller sur des centaines de lignes, avec le risque de décaler des affectations.

L'approche diff : ce que le développement logiciel apporte

Dans le développement logiciel, le suivi des versions est un problème résolu. Des outils comme Git gèrent des millions de modifications de texte sur des milliers de fichiers, détectent automatiquement les conflits et permettent à des centaines de développeurs de travailler en parallèle. Les concepts de base, commits, diffs, branches et merges, se transfèrent directement à la gestion des exigences :

La différence essentielle est la suivante : le contrôle de versions est la norme en développement logiciel depuis les années 1990. Dans la gestion des exigences de l'industrie ferroviaire, de nombreuses entreprises en sont encore au stade où les développeurs se trouvaient avant CVS et Subversion : copies de fichiers numérotées à la main et espoir que personne n'écrase par erreur la mauvaise version. Le blog de CONTACT Software documentaitque même la Deutsche Bahn n'a introduit un système de gestion des exigences fondé sur une base de données qu'autour de 2012 ou 2013.

IA et détection du delta

D'après le Loopio 2025 RFP Response Trends Report, 68 % des équipes de proposition utilisent déjà l'IA générative tous secteurs confondus, soit le double des 34 % de 2023. Le ferroviaire n'a pas encore connu cette transformation dans la même mesure. Le suivi des révisions offre trois points d'application :

• Documents non structurés : lorsque le donneur d'ordre fournit une révision en PDF ou Word, sans identifiants stables ni ReqIF, l'IA peut analyser le texte libre et tenter d'associer sémantiquement les exigences entre les versions, même si les formulations ont changé ou si les exigences ont été déplacées. Siemens Polarion propose cette fonction depuis 2025. PTC a également annoncé de nouvelles fonctions d'IA en 2026 pour Codebeamer.
• Évaluation des modifications, ou triage : l'IA peut proposer si un changement de texte est substantiel, par exemple une exigence technique ou référence normative modifiée, ou rédactionnel, comme une reformulation sans effet sur le contenu. Au lieu de faire examiner une par une 83 exigences modifiées par un expert, l'IA peut prioriser les 15 modifications substantielles.
• Analyse des effets en cascade :l'IA peut analyser les renvois entre exigences et identifier automatiquement les exigences inchangées qui pourraient être indirectement touchées par une modification. C'est similaire au mécanisme „suspect“ de Jama Connect, mais au niveau sémantique plutôt qu'au moyen de liens explicites.

Flux de travail pratique : une révision en cinq étapes

Une méthode structurée pour traiter les révisions se résume en cinq étapes. Ce flux de travail repose sur les principes du SEBoK de l'INCOSE et est compatible avec les exigences d'EN 50126 et d'ISO 22163:2023 :

Conclusion

Le suivi des révisions révèle le niveau réel de maturité du processus de gestion des exigences d'une entreprise. Une organisation qui utilise des identifiants stables, des formats structurés et des baselines propres traite une nouvelle révision en quelques heures. Celle qui dépend de comparaisons manuelles de documents perd des jours et risque de manquer des changements substantiels.

La réglementation ne laisse aucune marge : EN 50126 exige une traçabilité complète, ISO 22163:2023 a réuni la gestion de configuration et le contrôle des changements dans sa section 8.1.4, et IRIS Rev. 04 est obligatoire depuis 2024.

L'outil et le processus de traitement des révisions doivent être en place avant de classifier la première exigence. Le guide VDB et EuroSpec apportent les normes, ReqIF le format d'échange, et DOORS, Polarion, Codebeamer ainsi que des plateformes spécialisées comme Tendric fournissent l'infrastructure technique. L'IA aide quand les données structurées font défaut, mais elle ne remplace pas les fondations : identifiants stables, baselines propres et historique documenté des modifications.