Que se passe-t-il quand l’IA lit un cahier des charges ? Retour d’expérience ferroviaire

Introduction

Que se passe-t-il réellement lorsqu'on remet à un système d'IA un cahier des charges contenant 800 exigences techniques et qu'on lui dit : „Évalue cela“ ? La réponse n'est ni la vision de science-fiction d'une machine à établir des offres entièrement automatisée, ni la variante cynique „rien d'utilisable“. La réalité se situe entre les deux, et elle est plus nuancée que ne le laissent supposer la plupart des promesses marketing des fournisseurs d'IA.

Cet article décrit, étape par étape, ce qui se passe réellement lorsqu'un système d'IA traite un cahier des charges réel issu de la technologie ferroviaire. Il s'appuie sur l'expérience de véritables dossiers d'appel d'offres, y compris les cas où la technologie fonctionne et ceux où elle échoue.

La question n'est pas académique. Selon le Loopio 2025 RFP Response Trends & Benchmarks Report 68 % des équipes de réponse aux appels d'offres, tous secteurs confondus, utilisent déjà l'IA générative, soit le double des 34 % de 2023. L'industrie ferroviaire n'en est encore qu'au début, bien que des plateformes spécialisées comme Tendric répondent précisément à ce cas d'usage. L'atelier annuel NLP4RE (Natural Language Processing for Requirements Engineering) montre toutefois que l'automatisation de l'analyse des exigences par le NLP a depuis longtemps dépassé le stade de niche.

Que voit l'IA lorsqu'elle ouvre un cahier des charges ?

Pour un système d'IA, un cahier des charges est d'abord un document : un fichier Excel avec 8 feuilles de calcul (LH1 à LH8), des milliers de lignes et une douzaine de colonnes. Ou un PDF. Ou, idéalement, un jeu de données structuré au format ReqIF (Requirements Interchange Format), la norme OMG d'échange d'exigences entre outils, née dans l'industrie automobile et de plus en plus utilisée dans la technologie ferroviaire.

Avant tout traitement du contenu, le système doit résoudre trois tâches fondamentales :

1. Reconnaissance de la structure : quelles lignes sont des exigences, lesquelles sont des titres de section, des lignes vides ou des commentaires ? Le guide VDB sur la gestion des exigences recommande une structure d'attributs uniforme pour les cahiers des charges. Dans la pratique, la réalité s'en écarte toutefois considérablement.
2. Extraction des champs : où se trouvent l'ID de l'exigence, le texte, le niveau de caractère obligatoire (doit/devrait/option), la référence normative ? La norme internationale ISO/IEC/IEEE 29148:2018 définit certes les attributs qu'une exigence devrait avoir, mais les donneurs d'ordre ferroviaires suivent rarement cette norme de façon explicite.
3. Nettoyage : cellules fusionnées, retours à la ligne au milieu du texte, caractères Unicode spéciaux (‰ contre %), différents formats de date et mises en forme de cellules sémantiquement pertinentes (couleurs, gras), qui se perdent lors d'un simple export de texte.

Ce prétraitement semble trivial, mais il ne l'est pas. Chaque donneur d'ordre structure son cahier des charges différemment. L'ordre des colonnes varie, les titres de sections figurent dans la même colonne que les textes d'exigence, et certains utilisent les couleurs ou la mise en forme comme information sémantique, laquelle se perd à l'importation. Le domaine de recherche Document Parsing décrit précisément ce problème : les documents sont des „visually rich text data“. Leur signification ne découle pas du seul texte, mais aussi de la mise en page, de la police, de la structure tabulaire et des éléments visuels.

Phase 1 : extraction des exigences

L'extraction des exigences individuelles du document brut est la première étape, et la plus critique. Les erreurs commises ici se propagent à toutes les étapes de traitement suivantes. Une extraction erronée ne peut être compensée ni par une bonne classification ni par un bon routage.

L'extraction comprend plusieurs sous-étapes, chacune présentant ses propres défis :

• Détection des ID : le format typique X.35.YYYY.ZZ est identifié par reconnaissance de motifs. Le taux de réussite est élevé tant que le donneur d'ordre utilise un schéma d'ID cohérent. Les formats divergents posent problème : certains donneurs d'ordre utilisent des ID hiérarchiques (3.2.1.4), d'autres des numéros séquentiels (REQ-0412), d'autres encore renoncent complètement aux ID formels et travaillent avec des numéros de ligne.
• Détection du caractère obligatoire :„doit“, „devrait“, „peut“, „est tenu de“ sont reconnus comme des indicateurs de caractère obligatoire. Cela suit la distinction entre formulations impératives et optionnelles ancrée dans la systématique INCOSE . Les formulations dépendantes du contexte, telles que „devrait, si possible“ (s'agit-il de „devrait“ ou de „peut“ ?), sont plus difficiles. Il en va de même pour les constructions passives : „le respect de la norme est présupposé“ ne contient aucun „doit“ explicite, mais est clairement obligatoire.
• Extraction des références normatives :identification de normes telles que „DIN EN 45545-2:2020+A1:2023“, y compris le numéro de version et les amendements. Ici aussi, le taux de réussite est élevé pour les graphies normalisées. Mais les donneurs d'ordre écrivent parfois „conformément à la norme de protection incendie“ sans numéro de norme précis, ou renvoient à la „version en vigueur“ d'une norme, qui peut être différente à la conclusion du contrat de celle en vigueur lors du dépôt de l'offre.
• Limites contextuelles des exigences :où se termine une exigence et où commence la suivante ? Dans les documents en texte libre, un seul paragraphe contient parfois plusieurs exigences implicites : „Le véhicule doit pouvoir circuler sur la classe de ligne D4 tout en respectant les valeurs limites de bruit selon TSI Noise.“ Ce sont techniquement deux exigences indépendantes (charge à l'essieu et bruit), réunies dans une phrase.

Phase 2 : propositions de classification

Après l'extraction, on passe au contenu : chaque exigence est comparée à la base de connaissances interne. En pratique, cela se fait aujourd'hui typiquement au moyen d'une architecture RAG (Retrieval-Augmented Generation) : le système recherche les passages les plus pertinents dans les fiches produit, les spécifications du fabricant et les registres de normes, les transmet avec l'exigence à un modèle de langage et obtient une proposition de classification : OK, OKB, NOK, OKM ou R.

Pourquoi le RAG ? Au lieu de laisser un modèle de langage généraliste „répondre librement“ (ce qui conduit à des hallucinations), le modèle est limité à des documents sources concrets. Il ne peut accéder qu'aux informations réellement présentes dans la base de connaissances et doit étayer sa réponse par des références aux sources. Cela réduit les hallucinations, sans toutefois les éliminer.

La qualité de ces propositions varie fortement selon le type d'exigence :

Taux de réussite estimé de la première classification par l'IA selon le type d'exigence (appréciation qualitative fondée sur l'expérience pratique, non destinée à servir de benchmark). Les recherches actuelles sur la classification automatique des exigences par NLP montrent des tendances similaires : scores F1 de 0,73 à 0,84 selon l'approche méthodologique (Nature Scientific Reports, 2024).

Là où cela fonctionne bien

Les exigences paramétriques sont le point fort : „vitesse maximale d'au moins 100 km/h“ est comparée à la fiche produit (notre valeur : 100 km/h), la logique de comparaison est appliquée (≥ 100 → satisfait) et le résultat est un „OK“ justifié avec référence à la source. Cela fonctionne parce que le type d'exigence est clairement quantitatif, que l'opération de comparaison est nette (≥, ≤, =) et que les données sources sont lisibles par machine.

La comparaison fonctionne tout aussi bien pour les exigences normatives si le registre interne des normes est tenu à jour : l'IA reconnaît la référence normative dans le texte de l'exigence, recherche le statut de conformité dans le registre et fournit la classification avec le numéro de certificat.

Là où cela devient difficile

Les exigences qualitatives et les formulations nouvelles constituent le point faible. Lorsqu'une exigence indique „le soumissionnaire doit présenter un concept de maintenance couvrant le cycle de vie du véhicule sur 30 ans“, l'IA peut :

• reconnaître qu'il s'agit de maintenance (correct)
• attribuer le domaine du sous-système „maintenance“ (correct)
• établir le lien avec la RAMS, c'est-à-dire que l'exigence concerne la dimension de maintenabilité au sens de EN 50126 (RAMS) (correct)
• mais ne peut pas évaluer si l'entreprise dispose d'un tel concept ou peut en établir un (cela dépend d'un savoir interne rarement entièrement documenté)

Dans ces cas, „R“ (question à clarifier) est la classification la plus honnête. Un bon système d'IA devrait précisément proposer cela, plutôt que d'halluciner un „OK“ non justifié. La recherche sur les hallucinations des LLM montre le problème : les modèles de langage „apprennent à deviner avec assurance au lieu d'exprimer une incertitude calibrée“. Dans la classification des exigences, c'est dangereux parce qu'un „OK“ erroné a des conséquences contractuelles directes.

Source : CONTACT Software, Bummelzug zum Anforderungsmanagement. Cette citation date de 2014. Depuis, la densité d'exigences a encore augmenté. Les appels d'offres actuels pour des véhicules comprennent régulièrement 1 500 à 3 000 exigences dans l'ensemble des cahiers des charges partiels.

Phase 3 : reconnaître et relier les normes

Dans la pratique, la reconnaissance automatique des normes apporte le plus grand gain de temps. Un cahier des charges typique pour un véhicule ferroviaire renvoie, directement et indirectement, à un nombre de normes à trois chiffres. L'écosystème normatif ferroviaire est défini au niveau européen par l' ERA (European Union Agency for Railways), à travers les spécifications techniques d'interopérabilité (STI), puis traduit par CEN/CENELEC en normes européennes harmonisées.

Pour un fournisseur, cela signifie que lorsqu'un cahier des charges exige „EN 45545-2“ (protection incendie), il doit connaître non seulement le statut de cette norme, mais aussi :

• la STI SRT associée (Safety in Railway Tunnels), qui définit le cadre réglementaire
• les méthodes d'essai d'EN 45545-1 (exigences générales)
• les classifications des matériaux selon EN 45545-2 (comportement au feu)
• les certifications spécifiques au produit et leur période de validité

L'IA peut rendre ces liens visibles en quatre étapes :

Le comité DIN pour l'infrastructure et les véhicules ferroviaires (FSF) coordonne l'élaboration et la mise en œuvre nationale des normes ferroviaires. Le paysage normatif qui en résulte comprend environ 50 à 60 normes pertinentes pour les véhicules ferroviaires. Sous forme de catalogue structuré, il est gérable une fois recensé et tenu à jour. Le problème est sa dynamique : les normes sont révisées, des amendements publiés, les STI actualisées. Rien qu'en 2025, l'ERA a publié plusieurs spécifications STI mises à jour , dont la nouvelle STI Télématique, qui entre en vigueur le 2 mars 2026 et définit pour la première fois des exigences relatives à la qualité des données et à la cybersécurité pour le transport ferroviaire.

Phase 4 : propositions de routage vers les experts

Sur la base du sujet détecté et des références normatives, l'IA peut proposer le service expert qui devrait être responsable de chaque exigence. Selon le Loopio 2025 RFP Response Trends Report , 48 % des équipes de réponse aux appels d'offres, tous secteurs confondus, signalent des difficultés dans leur collaboration avec les experts métier. Le routage automatisé peut au moins partiellement y remédier.

Dans l'industrie ferroviaire, le problème du routage est marqué. Un cahier des charges pour un véhicule de grande ligne couvre 10 à 15 sous-systèmes différents, de la caisse du véhicule à la traction et au freinage, en passant par l'information voyageurs et la documentation de maintenance. Les experts compétents sont répartis dans différents services, parfois sur différents sites. Sans routage structuré, le responsable des offres consacre une part importante de son temps à attribuer manuellement les exigences aux bonnes personnes.

Comment l'IA fonctionne techniquement : RAG et recherche fondée sur les embeddings

Pour les lecteurs ayant une formation technique, il vaut la peine de regarder sous le capot. Le principe de base des systèmes d'IA modernes destinés au traitement des cahiers des charges repose sur une architecture Retrieval-Augmented Generation (RAG), qui combine deux composants :

1. Retrieval (recherche) : l'exigence est convertie en vecteur numérique (embedding) et comparée à une base de données vectorielle de la base de connaissances interne. Le résultat consiste en 5 à 10 passages textuels les plus pertinents issus de fiches produit, de registres de normes et d'offres antérieures.
2. Generation (évaluation) : un Large Language Model (LLM) reçoit l'exigence avec les documents sources trouvés et génère une proposition de classification avec justification et référence à la source.

L'avantage par rapport à un LLM „nu“ : le système ne peut accéder qu'aux informations réellement présentes dans la base de connaissances. Si aucune source pertinente n'est trouvée, le système devrait proposer honnêtement „R“ (question à clarifier), plutôt que d'halluciner une réponse qui paraît plausible mais ne peut être étayée.

Là où l'IA atteint ses limites

Un regard honnête sur les limites est plus important que toute annonce de succès. Les systèmes d'IA appliqués au traitement des cahiers des charges se heurtent aujourd'hui à cinq limites systématiques :

1. Connaissance implicite

Le savoir le plus précieux d'une entreprise n'est souvent pas documenté. Lorsqu'un ingénieur expérimenté sait qu'une exigence précise a conduit à l'exclusion lors d'un appel d'offres antérieur et formule donc une réponse stratégique, l'IA n'a pas accès à cette information. Elle ne voit que les documents mis à sa disposition. Ce „Tacit Knowledge“ joue un rôle majeur dans l'industrie ferroviaire, car la communauté est de taille limitée. Les responsables d'offres expérimentés connaissent les préférences et les critères d'évaluation de donneurs d'ordre spécifiques grâce à des années de collaboration.

2. Évaluation stratégique

La classification d'une exigence en NOK est parfois une décision stratégique, non purement technique. Les responsables d'offres expérimentés formulent délibérément des questions de clarification afin d'„assouplir“ des exigences, par exemple en demandant au donneur d'ordre pourquoi une exigence est plus stricte que la norme sous-jacente. Ils peuvent aussi saisir l'occasion de proposer une alternative plus innovante qui convaincra le donneur d'ordre. Ce type de communication stratégique dépasse les capacités de l'IA.

3. Qualité des documents

La qualité des résultats de l'IA dépend directement de la qualité des documents internes. Des fiches produit obsolètes, des registres de normes incomplets ou des spécifications fabricant contradictoires conduisent à des propositions de classification erronées. Le principe „Garbage in, garbage out“ s'applique sans restriction. Paradoxalement, les entreprises qui entretiennent bien leur documentation auraient le moins „besoin“ de l'assistance de l'IA ; celles qui en auraient le plus besoin disposent de la pire base de données.

4. Absence de contexte de négociation

Un cahier des charges n'est pas un document statique. Il est le point de départ d'une négociation. La deuxième révision contiendra des exigences différentes de la première, sur la base des retours de tous les soumissionnaires. L'IA peut traiter la version actuelle, mais elle ne peut anticiper quelles exigences le donneur d'ordre assouplira vraisemblablement. Les responsables d'offres expérimentés développent cet instinct au fil d'années de collaboration avec certains donneurs d'ordre.

5. Le risque d'hallucination

Même avec une architecture RAG, il subsiste le risque que le modèle de langage établisse des liens inexistants, ou interprète les documents sources de sorte qu'ils semblent satisfaire l'exigence alors que, à y regarder de plus près, des différences essentielles existent. Un survey récent sur les hallucinations des LLM décrit le problème : les modèles de langage sont optimisés pour générer des réponses plausibles, non pour exprimer une incertitude calibrée. Dans un processus d'offre où chaque classification implique un engagement contractuel, c'est un risque réel.

Ce qui change : le flux de travail avec et sans IA

Selon le Loopio 2025 RFP Response Trends Report , 68 % des équipes de réponse aux appels d'offres, tous secteurs confondus, utilisent déjà l'IA générative (soit le double des 34 % de 2023). 65 % utilisent des logiciels RFP spécialisés (contre 48 % l'année précédente) et le taux de réussite moyen est de 45 %. L'industrie ferroviaire, traditionnellement plus réservée face à la gestion numérique des exigences, n'en est encore qu'au début. Selon Bidara , le taux de réutilisation de contenu atteint 66 % tous secteurs confondus. La plupart des entreprises ferroviaires n'exploitent pas ce potentiel faute d'une base de connaissances interrogeable. Des plateformes comme Tendric interviennent ici en construisant une base de connaissances transversale aux projets et en la rendant consultable.

Conclusion

Que se passe-t-il lorsqu'une IA lit un cahier des charges ? Elle effectue le travail de routine : extraction, structuration, comparaison des paramètres, reconnaissance des normes. Plus vite et plus complètement qu'un processus manuel. Pour 70 à 80 % des exigences, elle fournit une première proposition utilisable avec référence à la source. Pour les 20 à 30 % restants, c'est-à-dire les exigences stratégiques, qualitatives et nouvelles, elle signale correctement son incertitude et transmet le dossier à l'expert humain.

Ce n'est pas un échec, c'est le but. L'IA donne à l'expert métier la liberté de se concentrer sur les exigences où son jugement fait réellement la différence, au lieu de passer des heures à chercher dans des fiches produit. Le groupe de travail INCOSE sur les AI Systems appelle cela „AI for SE“ : l'IA au service des processus d'ingénierie système.

La prochaine tâche n'est pas de disposer de meilleurs modèles. Ce sont des registres de normes entretenus, des fiches produit à jour et des archives consultables d'offres antérieures. Des outils comme Tendric répondent précisément à ce besoin : ils créent la base de données structurée sur laquelle une classification assistée par l'IA peut, enfin, fonctionner de manière fiable.