Si l’IA est partout, comment un train peut-il encore en percuter un autre par l’arrière ?

Que savons-nous de l’événement en Espagne ?

Le 28 octobre 2026, une collision impliquant des trains de Renfe et d’Iryo a été signalée près d’Urda, sur la ligne à grande vitesse Madrid–Séville, en Espagne. Dans sa première communication, le gestionnaire d’infrastructure Adif a décrit l’événement survenu entre Mora y Orgaz et Urda par le mot « alcance », qui désigne une collision par l’arrière. Renfe a également publié un communiqué officiel. Les premières informations opérationnelles figuraient sur la page d’Adif consacrée à l’état du réseau.

Ces informations n’expliquent pas la cause technique de la collision. Le système de protection utilisé et son mode de fonctionnement, la succession des mouvements des trains, les autorisations délivrées et le déroulement du freinage sont autant de points à examiner séparément. Ces communiqués ne suffisent pas à attribuer l’événement à un « manque d’IA », à une « défaillance de l’ETCS » ou à l’erreur d’une personne précise.

La priorité va aux voyageurs et aux employés touchés par cet événement. Cet article n’est pas une enquête sur l’accident, mais une analyse générale de la question technologique qu’il soulève. Plutôt que de reprendre un nombre de blessés susceptible d’évoluer rapidement, nous nous concentrons sur les éléments vérifiables et sur des questions techniques plus durables.

Quels systèmes contribuent à éviter les collisions entre trains ?

Réduire la sécurité ferroviaire au signal devant le conducteur ou à un seul ordinateur serait incomplet. Pour qu’un train puisse avancer, plusieurs systèmes doivent fournir des informations cohérentes entre elles. Leur mise en œuvre varie selon l’équipement de la ligne et des véhicules, mais leurs fonctions essentielles peuvent se résumer ainsi :

• Détecter la présence et la position du train : savoir si une section de voie est occupée constitue le point de départ d’un mouvement sûr.
• Établir un itinéraire approprié : la position des aiguillages et les mouvements autorisés ne doivent pas être contradictoires. C’est pourquoi les liaisons de sécurité entre les signaux et les aiguillages sont importantes.
• Transmettre l’autorisation de mouvement : le système concerné et les règles d’exploitation définissent jusqu’où le train peut avancer et dans quelles conditions.
• Surveiller les limites de vitesse : selon l’équipement, le système de protection des trains peut émettre un avertissement ou intervenir sur le freinage avant le dépassement des limites autorisées.
• Permettre l’arrêt physique : l’état du système de freinage, la vitesse, les caractéristiques du train et les conditions de la voie influent sur la manière dont il s’arrête.

Les explications de Network Rail sur la signalisation montrent que cet ensemble comporte de nombreux éléments et que le passage à un état sûr en cas de panne est l’un des principaux objectifs de conception. C’est pourquoi un défaut de signalisation peut parfois provoquer l’arrêt du trafic ou des retards. Dans certains cas, le retard observé par les voyageurs correspond à l’activation d’un mécanisme de sécurité.

On ne peut en déduire la cause d’un accident particulier. Au-delà de la conception des systèmes, leur maintenance, leur configuration, la gestion des modifications et leur exploitation dans des conditions inhabituelles doivent aussi être examinées. Seuls les enregistrements de l’événement permettent de répondre à la question : « Il y avait un ordinateur, pourquoi n’a-t-il pas empêché l’accident ? »

La protection automatique des trains et l’intelligence artificielle sont-elles la même chose ?

Tout système automatique ne relève pas de l’intelligence artificielle. Il faut notamment distinguer l’IA générative des fonctions de commande destinées à la sécurité. Un modèle de langage peut rédiger une explication, rechercher des informations dans des documents et résumer des enregistrements d’événements. Un système de protection des trains est, lui, conçu pour fonctionner dans des conditions d’exploitation et de sécurité définies.

À titre d’exemple général, le système européen de contrôle des trains, ou ETCS, surveille la vitesse et la position du train par rapport aux limites autorisées. Selon les explications de l’Agence de l’Union européenne pour les chemins de fer sur les courbes de freinage, le calculateur embarqué détermine les distances de freinage à partir des caractéristiques de freinage du train et des données sur la voie située devant lui. Si nécessaire, il commande l’intervention des freins du train, qui constituent un système distinct.

L’existence de ce calcul ne signifie pas qu’un modèle conversationnel est utilisé. Nous citons par ailleurs l’ETCS pour expliquer son principe de fonctionnement ; cela ne constitue pas une affirmation selon laquelle l’ETCS était actif ou a échoué lors de l’événement en Espagne.

Il n’est donc pas nécessaire d’attendre l’IA générative pour prévenir une collision par l’arrière. Le bon fonctionnement des dispositifs de sécurité existants est déjà indispensable. Les projets d’intelligence artificielle doivent préciser le bénéfice supplémentaire qu’ils apportent, plutôt que de rendre cette responsabilité moins claire.

Où l’intelligence artificielle peut-elle être utile dans le ferroviaire ?

Les possibilités les plus concrètes concernent les tâches qui nécessitent l’analyse régulière de grandes quantités de données. Les exemples suivants sont des domaines d’application possibles ; ils ne décrivent ni les capacités actuelles d’une ligne précise ni une solution certaine à un accident donné.

Repérer des variations inhabituelles dans les données des capteurs

L’analyse conjointe de la température, des vibrations, des mesures électriques et des historiques de maintenance peut permettre d’étudier des évolutions invisibles dans une mesure isolée. Par exemple, un équipement dont le comportement s’écarte de son historique dans des conditions d’exploitation comparables peut être signalé comme nécessitant un contrôle.

La détection d’une anomalie ne constitue pas, à elle seule, un diagnostic de panne. Le capteur peut être défectueux, les conditions d’exploitation peuvent avoir changé ou un enregistrement peut avoir été mal associé. L’alerte doit donc préciser les données utilisées, leur horodatage et la raison du contrôle ; le résultat doit être soumis au spécialiste concerné.

Définir des priorités pour la maintenance prédictive

La maintenance prédictive vise à évaluer plus tôt les besoins de maintenance en surveillant l’état des équipements. L’IA peut rechercher des liens récurrents entre les pannes passées et les mesures, puis proposer des priorités aux équipes de maintenance. Son intérêt ne se limite pas à la prévision du modèle : il se concrétise lorsque la recommandation débouche sur un ordre de travail, une inspection et une trace documentée.

Il faut également distinguer les niveaux de maturité des travaux dans ce domaine. La solution de maintenance dynamique d’Europe’s Rail décrit une aide à la décision combinant des données d’état et de maintenance issues de plusieurs sources. La page présente la solution comme un prototype de niveau TRL 6, démontré dans un environnement représentatif, et souligne la nécessité de projets pilotes et de validations supplémentaires. Un résultat de recherche ne doit pas être présenté comme une garantie de sécurité prête à être déployée partout.

Assister les contrôles fondés sur des images

Les modèles de traitement d’images peuvent mettre en évidence, dans les images d’inspection, les zones qui nécessitent l’attention de spécialistes. L’objectif est de faciliter la sélection des cas à examiner parmi un grand nombre d’images. Les performances doivent être réévaluées lorsque la lumière, la météo, l’angle de la caméra ou la qualité des images changent.

Les résultats du projet RAILS publiés par la Commission européenne portent notamment sur la détection d’obstacles par caméra, l’inspection des infrastructures et les jumeaux numériques pour la maintenance prédictive. Ces pistes de recherche sont prometteuses ; elles ne doivent pas être considérées comme des solutions abouties offrant les mêmes performances dans tous les scénarios.

Faire parvenir les informations dispersées à l’équipe qui décide

Lorsqu’une alerte figure sur un écran, l’historique de maintenance dans une autre application et une note de terrain dans un fil de messages, les équipes ont plus de mal à comprendre la situation. Une couche d’intégration peut regrouper les enregistrements relatifs à un même équipement. L’IA peut ensuite aider à les classer ou à les résumer.

Le point critique est ici la mise en correspondance des données. Si les identifiants des équipements, les horodatages et les versions des enregistrements ne concordent pas entre les systèmes, un résumé bien rédigé peut donner une image erronée de la situation. Les liens vers les sources et le signalement des données manquantes peuvent avoir plus de valeur qu’une explication fluide.

Rechercher dans les documents et analyser après un événement

L’intelligence artificielle générative peut servir d’assistant pour rechercher dans des documents techniques approuvés ou organiser de longs enregistrements en vue d’un premier examen. Il faut indiquer sur quel document et quelle version repose la réponse, empêcher l’accès aux informations non autorisées et confier les cas incertains à un spécialiste.

Autoriser cet assistant à modifier seul une consigne opérationnelle représente un autre niveau de risque. La recherche documentaire et l’action sur un système physique ne doivent pas être regroupées sans distinction dans le même périmètre de projet. Les autorisations doivent être définies séparément selon l’usage prévu.

Pourquoi davantage d’IA ne suffit-il pas à renforcer la sécurité ?

Même si un modèle obtient de bons résultats en moyenne, ses performances peuvent être insuffisantes dans des scénarios critiques. Une situation rare peut être très peu représentée dans ses données d’entraînement. On ne peut pas supposer que des résultats obtenus sur une autre ligne, avec un autre type d’équipement ou à une autre saison restent valables dans de nouvelles conditions.

Les conséquences des deux types d’erreurs sont également différentes. Ne pas détecter un problème réel peut retarder l’intervention. À l’inverse, produire continuellement des alertes sans qu’il y ait de problème peut alourdir le travail de vérification et rendre les alertes moins crédibles. L’évaluation doit distinguer ces deux résultats et leurs effets opérationnels, plutôt que de se limiter au taux global d’exactitude.

Les modifications demandent la même vigilance. Remplacer un capteur, renommer un champ de données ou mettre à jour un modèle peut modifier un comportement déjà testé. Il faut préciser qui peut effectuer des changements, ce qui doit être retesté et comment revenir à la version précédente si nécessaire.

Dans son analyse de la sécurité numérique, l’ORR, le régulateur ferroviaire britannique, souligne que les risques peuvent provenir non seulement de chaque système, mais aussi de leur intégration, de leur modification et de leur exploitation. Les processus de décision humains et la chaîne d’approvisionnement font également partie de cet ensemble.

C’est pourquoi affirmer qu’« une validation humaine est prévue » ne suffit pas. La personne chargée de valider doit pouvoir consulter la source, comprendre l’alerte, la rejeter si nécessaire et disposer du temps nécessaire pour le faire. La simple présence d’une personne devant un écran ne constitue pas un contrôle solide si elle n’a pas le pouvoir d’intervenir ou ne voit pas ce qu’elle approuve.

Quel rapport avec les projets d’IA en entreprise ?

Les conséquences d’une erreur de stock dans le commerce en ligne ne sont évidemment pas les mêmes que celles d’un accident ferroviaire. Certaines questions à poser pour évaluer un déploiement technologique restent pourtant communes : les données sont-elles à jour ? Qui a le pouvoir de décider ? Comment repère-t-on une opération incorrecte ? Comment l’équipe continue-t-elle à travailler si le système s’arrête ?

Par exemple, si un assistant de service client utilise une ancienne version de la politique de retour, un langage plus fluide ne résoudra pas le problème. Si l’intégration des stocks prend du retard, un modèle de recommandation commerciale peut recommander plus efficacement un produit indisponible. Dans un hôtel, classer correctement le message d’un client reste également insuffisant si l’on ne vérifie pas que la tâche a été transmise à la bonne équipe et accomplie.

Ces exemples montrent pourquoi le conseil en IA doit examiner le processus de travail avant de choisir un modèle. Il faut partir d’une opération précise dans laquelle les équipes perdent régulièrement du temps ou commettent des erreurs. La source des données, les limites du pouvoir de décision, le contrôle humain et les critères de réussite doivent ensuite être conçus ensemble.

Certains problèmes ne nécessitent même pas de nouveau modèle. Une connexion fiable aux données, une règle claire ou un circuit de validation peuvent offrir une solution plus simple et plus facile à contrôler. C’est en comparant l’IA à ces options que l’on peut établir sa valeur ajoutée.

Comment concevoir un projet pilote d’IA mesurable ?

Le plan suivant constitue le cadre de travail que nous proposons aux entreprises pour démarrer des projets d’IA opérationnelle. Il ne remplace ni l’ingénierie de sécurité ferroviaire, ni l’évaluation de conformité, ni les procédures d’autorisation propres à un secteur. Pour une approche générale des risques, le NIST AI Risk Management Framework est une référence utile : il envisage la gestion des risques sur l’ensemble du cycle de vie du système.

1. Choisir un seul processus et définir ses limites

Plutôt que de vouloir « transformer l’entreprise grâce à l’IA », choisissez par exemple l’orientation des demandes d’assistance vers la bonne équipe. Précisez par écrit si le système se limitera à faire des recommandations, créera des dossiers ou exécutera aussi des opérations. Évaluez séparément les autorisations telles que l’envoi de messages aux clients, les paiements ou la suppression de données.

2. Mesurer la performance actuelle

Mesurez le temps de traitement, le taux d’erreur et la charge des équipes avant le pilote. Sans connaître la situation de départ, il est difficile de vérifier une amélioration annoncée. Comparez des volumes d’activité et des conditions similaires ; une comparaison directe entre une période de campagne commerciale et une période calme peut être trompeuse.

3. Définir les données et réserver des cas de test distincts

Déterminez quelle source fait autorité, le seuil d’ancienneté acceptable des données et les droits d’accès. Ne mesurez pas la réussite uniquement sur les exemples utilisés pour préparer le système. En plus de cas de test distincts, examinez des situations telles que des enregistrements incomplets, des informations contradictoires, des demandes inattendues et des interruptions de connexion.

4. Tester d’abord sans exécuter d’opérations

Le fonctionnement en mode fantôme consiste à laisser le système produire des recommandations sans modifier les décisions réelles. On peut ainsi comparer ses propositions au processus existant. Les échecs peuvent être analysés et le périmètre réduit. À l’étape suivante, avancer avec des autorisations limitées et une validation humaine permet d’observer les problèmes dans un cadre mieux maîtrisé.

5. Fixer à l’avance les critères de poursuite et d’arrêt

Avant le début du pilote, indiquez quels résultats justifieront son extension, quelles erreurs entraîneront son arrêt et qui en sera responsable. Atteindre un objectif ne doit pas masquer un autre risque. Si le traitement s’accélère mais que les opérations incorrectes ou la charge de vérification augmentent, l’application n’apporte peut-être pas encore le bénéfice attendu.

Le rapport de résultats doit au minimum présenter côte à côte les mesures suivantes :

• Résultat métier : l’objectif retenu, par exemple le temps de traitement, la bonne orientation ou l’achèvement dans les délais.
• Répartition des erreurs : problèmes non détectés, fausses alertes et exemples d’erreurs critiques.
• Travail humain : temps consacré aux contrôles, aux corrections et à la gestion des exceptions.
• Coût total : coût d’utilisation du modèle, mais aussi de l’intégration, de la maintenance et des vérifications.
• Capacité d’exploitation : traçabilité des enregistrements, fraîcheur des données, comportement en cas d’interruption et bon fonctionnement du retour à l’état précédent.

Un bon pilote n’aboutit pas toujours à un « déploiement plus large ». Revenir à la préparation si les données sont insuffisantes, conserver une solution fondée sur des règles si le gain est limité ou arrêter le projet si le risque est élevé sont aussi des résultats utiles.

Questions fréquentes

L’intelligence artificielle peut-elle empêcher tous les accidents ferroviaires ?

Une telle garantie n’est pas possible. L’IA peut aider à la détection précoce et à la décision pour certaines tâches ; la sécurité exige toutefois de considérer ensemble les infrastructures, la protection des trains, la maintenance, l’exploitation et les facteurs humains. Chaque application doit être validée dans ses propres conditions d’utilisation.

L’ETCS est-il un système d’intelligence artificielle ?

L’ETCS est le système européen de contrôle des trains qui surveille le respect des limites autorisées de vitesse et de distance. L’utilisation de calculs mathématiques, comme les courbes de freinage, n’en fait ni une IA générative ni un modèle conversationnel.

La maintenance prédictive supprime-t-elle la maintenance existante ?

Pas automatiquement. Les prévisions fondées sur les données peuvent aider à définir les priorités de maintenance. Les obligations de maintenance ou les procédures de sécurité existantes ne doivent pas être modifiées sur la seule recommandation d’un modèle ; toute modification doit faire l’objet de l’évaluation technique appropriée.

Par où une entreprise doit-elle commencer un projet d’IA ?

Par un processus limité dont les données sont accessibles, le responsable identifié et le résultat mesurable. Mesurez d’abord la performance actuelle, puis évaluez ensemble les gains, les erreurs et le contrôle humain dans le cadre d’un petit pilote.

Le conseil en IA consiste-t-il uniquement à choisir des outils ?

Le choix de l’outil n’est qu’une partie du travail. Si les sources de données, les intégrations, les droits d’accès, la formation des équipes, les circuits de validation et la mesure des résultats ne sont pas traités ensemble, même un bon outil peut rester en marge des opérations quotidiennes.

Évaluons ensemble où l’IA peut être utile à votre entreprise

Chez GadgetMall, nous abordons la transformation par l’IA à travers l’évaluation des processus et des sources de données, la définition d’une feuille de route, l’intégration, la formation des équipes et la mesure des résultats. Cette démarche s’adresse aux processus d’entreprise tels que le service client, les contenus, le commerce et les opérations internes.

Vous n’avez pas besoin de préparer un cahier des charges technique complet pour commencer. Il suffit de nous présenter une tâche récurrente, les outils que vous utilisez et le résultat que vous souhaitez améliorer. Nous pourrons discuter des étapes adaptées à l’automatisation, des points où une validation humaine doit être maintenue et de la façon de mesurer un pilote.

Échangez avec GadgetMall sur votre transformation par l’IA ou écrivez à hello@gadgetmall.uk.

Voir l’IA partout ne signifie pas que tous les systèmes fonctionnent automatiquement mieux. Le progrès réel commence lorsque nous pouvons montrer clairement le problème résolu, les limites de la solution et les résultats obtenus sur le terrain.