mySCADA myPRO Manager corrige deux failles d’authentification, dont une critique
mySCADA myPRO Manager fait désormais face à deux failles de sécurité divulguées, dont l’une obtient un score de 9,8, car des interfaces sensibles acceptaient des requêtes sans authentification. Les versions 2.1 et antérieures sont concernées. La version 2.2 intègre les correctifs du fournisseur.
La vulnérabilité la plus grave expose des fonctions de gestion privilégiées via l’API de commandes du produit. La seconde expose un point de terminaison HTTP capable d’envoyer des messages texte arbitraires par l’intermédiaire d’un modem GSM connecté. Aucun de ces deux chemins ne nécessite de compte authentifié avant l’acceptation de la requête concernée.
Cette situation crée une tension nette entre la commodité de la gestion industrielle et le contrôle d’accès élémentaire. myPRO Manager aide les opérateurs à configurer des environnements connectés, mais les interfaces vulnérables ne vérifiaient pas l’identité de l’émetteur de commandes sensibles. Le problème dépasse le cadre d’une application web classique, car les produits mySCADA semblent être utilisés dans des environnements de technologies opérationnelles à travers le monde.
La réponse immédiate est claire. Les opérateurs doivent identifier les installations affectées, les mettre à jour et vérifier quels réseaux peuvent atteindre leurs interfaces de gestion. Le travail le plus difficile commence ensuite, en particulier pour les systèmes isolés, les installations non gérées et les environnements où les interruptions compliquent les mises à niveau.
Ce qui a changé dans mySCADA myPRO Manager
La divulgation identifie deux défaillances d’autorisation distinctes, mais la vulnérabilité de l’API de commandes présente le risque opérationnel le plus élevé.
Le 15 septembre 2026, la CISA a publié un avis industriel concernant mySCADA myPRO Manager. Il identifie CVE-2026-73807 et CVE-2026-82567 dans les versions 2.1 et antérieures.
La version 2.2 est répertoriée comme non affectée. mySCADA Technologies indique que cette version corrige les deux problèmes et recommande de passer à la dernière version disponible.
CVE-2026-73807 concerne l’API de commandes, c’est-à-dire l’interface utilisée par les composants logiciels pour émettre des requêtes de gestion. Selon l’enregistrement officiel, l’API n’applique pas correctement l’authentification aux fonctions privilégiées.
Un attaquant n’a pas besoin de compte existant. Il lui suffit d’avoir un accès réseau à l’interface concernée, puis il peut tenter d’invoquer des fonctions normalement réservées à un administrateur autorisé.
L’enregistrement CVE attribue à la faille un score CVSS 3.1 de 9,8, ce qui la place dans la catégorie critique. Son vecteur décrit une vulnérabilité accessible par le réseau, de faible complexité d’attaque, ne nécessitant ni privilèges ni interaction utilisateur.
L’enregistrement lui attribue également un score CVSS 4.0 de 9,3. Les deux évaluations indiquent un fort impact potentiel sur la confidentialité, l’intégrité et la disponibilité au sein du système vulnérable.
Cette notation n’établit pas que chaque installation est exposée de manière identique. Le CVSS mesure la gravité technique selon des hypothèses standardisées. Il ne sait pas si une API de commandes particulière se trouve derrière plusieurs pare-feu ou est accessible depuis un réseau non fiable.
CVE-2026-82567 affecte la passerelle de notification, qui relie myPRO Manager à la livraison de SMS par l’intermédiaire d’un modem GSM. Le point de terminaison HTTP vulnérable accepte un numéro de téléphone et un message, puis demande au modem d’envoyer ce texte.
Le point de terminaison n’exige pas d’authentification préalable. Un attaquant disposant d’un accès réseau approprié peut donc soumettre des destinataires et des messages arbitraires via le modem connecté.
Cette seconde vulnérabilité obtient un score CVSS 3.1 de 6,3, classé comme moyen. Son vecteur repose sur un chemin d’attaque par réseau adjacent, plutôt que sur le chemin réseau plus large attribué à CVE-2026-73807.
Cette distinction est importante. La faille SMS exige généralement que l’attaquant puisse atteindre le réseau local ou adjacent concerné. La faille critique de l’API de commandes bénéficie d’une classification d’attaque réseau plus large.
Les deux problèmes partagent toutefois la même faiblesse sous-jacente. Une opération sensible accepte une entrée avant d’établir si le demandeur est autorisé à l’exécuter.
La CISA attribue ces découvertes aux chercheurs de SECNORA Rajivarnan R. et Shirshak. Les vulnérabilités ont été découvertes de manière externe et coordonnées dans le cadre du processus de divulgation des systèmes de contrôle industriel de l’agence.
L’avis situe les déploiements concernés dans les secteurs de la fabrication critique, de l’énergie, de l’alimentation et de l’agriculture, des transports, ainsi que de l’eau et des eaux usées. Il décrit le déploiement comme mondial et indique que le siège du fournisseur se trouve en Tchéquie.
Ces désignations sectorielles ne prouvent pas que chaque instance affectée contrôle directement un processus physique. Elles montrent toutefois pourquoi une lacune d’authentification dans ce produit mérite une attention étroite de la part des équipes de technologies opérationnelles.
Pourquoi l’absence d’authentification importe davantage dans les réseaux industriels
Une requête qui atteint une interface de gestion industrielle peut avoir des conséquences bien au-delà du processus logiciel qui la reçoit.
L’authentification répond à une question fondamentale : qui effectue cette requête ? L’autorisation répond à la question suivante : que cette identité est-elle autorisée à faire ?
CVE-2026-73807 rompt cette frontière autour des fonctions de gestion privilégiées. La description officielle ne répertorie pas toutes les fonctions exposées ; les défenseurs ne doivent donc pas présumer d’un résultat spécifique au-delà de l’accès documenté.
Néanmoins, l’expression « fonctions de gestion privilégiées » signale une défaillance de confiance significative. Une interface conçue pour l’administration acceptait des requêtes réseau sans appliquer le contrôle qui devrait distinguer les administrateurs des autres systèmes.
Le vecteur CVSS reflète cette préoccupation. Il suppose l’absence de privilèges, d’interaction utilisateur, une faible complexité et un impact potentiellement élevé sur la confidentialité, l’intégrité et la disponibilité.
Pour un site web d’entreprise, une défaillance du contrôle d’accès peut exposer des données ou des paramètres d’application. Dans un environnement de technologies opérationnelles, un logiciel de gestion peut se trouver à proximité de systèmes qui surveillent les équipements, collectent des données de processus, diffusent des alarmes ou soutiennent les décisions des opérateurs.
La conséquence exacte dépend de chaque déploiement. L’architecture réseau, les équipements connectés, la configuration du produit et les fonctions exposées façonnent tous le risque réel.
Cette variabilité rend le contexte des actifs essentiel. Une installation de laboratoire déconnectée ne présente pas la même exposition qu’un gestionnaire de production accessible depuis un segment d’entreprise partagé.
Une installation exposée à Internet représente un cas encore plus urgent. Bien que l’avis ne publie pas de nombre de systèmes exposés, tout accès direct non fiable supprime une barrière défensive majeure.
La faiblesse SMS présente un impact plus limité, mais illustre le même problème architectural. Les passerelles de notification transportent souvent des alertes opérationnelles auxquelles les utilisateurs sont censés se fier.
Un attaquant qui envoie des messages arbitraires via un modem connu pourrait semer la confusion, usurper des notifications habituelles ou consommer la capacité de messagerie. L’enregistrement officiel n’affirme pas que les attaquants peuvent lire des messages existants ou reconfigurer le modem.
Les défenseurs doivent préserver cette distinction. La capacité divulguée est l’envoi non autorisé de SMS, et non un contrôle démontré de toutes les fonctions de notification.
Néanmoins, des messages arbitraires peuvent avoir de l’importance lors d’un incident. Les opérateurs peuvent dépendre des alertes textuelles lorsqu’ils sont éloignés d’une salle de contrôle ou lorsqu’un autre canal de communication tombe en panne.
Un message frauduleux pourrait être pris pour une alerte système légitime. Une rafale de messages indésirables pourrait également rendre les véritables notifications plus difficiles à identifier.
Ces scénarios constituent des considérations de risque raisonnables, et non des rapports d’exploitation documentés. L’avis établit le chemin d’envoi non autorisé, tandis que chaque organisation doit évaluer ses conséquences opérationnelles.
Le contexte industriel modifie également la rapidité avec laquelle les équipes peuvent appliquer les correctifs. Les environnements de production peuvent nécessiter des interruptions planifiées, des tests de compatibilité, une coordination avec le fournisseur ou une revue de sécurité avant toute modification du logiciel de gestion.
Ces contrôles réduisent les perturbations accidentelles, mais ils peuvent prolonger la période pendant laquelle du code vulnérable reste installé. Les restrictions réseau sont donc importantes avant, pendant et après le processus de mise à jour.
La commodité s’est heurtée au contrôle d’accès
Le problème central n’est pas une chaîne d’exploitation avancée, mais une fonctionnalité sensible exposée sans point de contrôle d’identité efficace.
Les API de gestion existent parce que l’administration manuelle ne passe pas à l’échelle. Elles permettent à des composants logiciels, consoles et services d’échanger des commandes au moyen de requêtes définies.
Les passerelles de notification offrent une commodité similaire. Elles relient les événements industriels aux canaux de communication, permettant au logiciel d’envoyer des alertes via un modem GSM.
Les deux conceptions peuvent être utiles. Leur sécurité dépend du traitement de chaque requête entrante comme non fiable jusqu’à ce que le demandeur prouve une identité acceptée et reçoive une autorisation explicite.
Les failles divulguées montrent ce qui se produit lorsque cette séquence se rompt. Dans l’API de commandes, un demandeur peut atteindre une fonctionnalité privilégiée sans l’application attendue de l’authentification.
Dans la passerelle de notification, le point de terminaison HTTP accepte les données de destination et de message avant de vérifier l’existence d’un utilisateur autorisé. Il transmet ensuite le message demandé au modem connecté.
Aucune ingénierie sociale n’est requise dans l’un ou l’autre des chemins documentés. Aucun administrateur n’a besoin d’ouvrir un fichier malveillant ou d’approuver une invite.
Cela ne rend pas l’exploitation automatique. L’attaquant doit toujours obtenir la connectivité réseau requise, identifier l’interface et soumettre une requête que le service accepte.
Ces prérequis expliquent pourquoi l’architecture réseau reste importante. Un service vulnérable isolé dans une zone de gestion étroitement contrôlée offre moins de chemins d’attaque qu’un service exposé à de vastes réseaux internes.
Toutefois, la segmentation est un contrôle compensatoire, et non une correction de l’absence d’authentification. Les réseaux évoluent, les règles de pare-feu s’accumulent, les chemins d’accès distant s’étendent, et les appareils internes compromis peuvent contourner les hypothèses sur les emplacements de confiance.
La conception la plus sûre combine plusieurs couches. L’application authentifie chaque requête sensible, l’autorisation limite les actions disponibles et le réseau restreint les systèmes qui peuvent atteindre l’interface.
La journalisation doit ensuite enregistrer les activités acceptées et rejetées. La surveillance doit identifier les commandes inhabituelles, les adresses sources inattendues et les destinations SMS irrégulières.
CVE-2026-73807 et CVE-2026-82567 sont importantes parce qu’elles affaiblissent la couche applicative de ce modèle. La version 2.2 restaure le correctif logiciel pris en charge par le fournisseur, tandis que les contrôles réseau réduisent l’exposition autour de celui-ci.
Le contraste explique également la différence de gravité. Le problème de l’API de commandes est évalué pour ses effets potentiellement élevés sur les trois propriétés de sécurité centrales du système vulnérable.
Le point de terminaison SMS reçoit des notes d’impact inférieures et une classification de réseau adjacent. Son résultat documenté se limite à l’envoi de messages arbitraires via un modem connecté.
Traiter les deux découvertes comme identiques masquerait les priorités de correction. Ignorer le problème moins bien noté ferait manquer un chemin d’abus pratique via un canal de notification fiable.
Les équipes doivent donc prioriser l’exposition critique de l’API de commandes tout en corrigeant les deux vulnérabilités au moyen de la même mise à niveau. Une limite de version unique simplifie la décision logicielle, même si le travail de déploiement reste complexe.
Le fournisseur indique que les appareils connectés avertissent les utilisateurs dans mySCADA Pro Manager lorsqu’une nouvelle version est disponible. Les environnements hors ligne exigent que les opérateurs obtiennent la mise à jour séparément depuis la page de téléchargement du gestionnaire.
Les systèmes hors ligne méritent une attention particulière. Leur isolement peut réduire l’exposition, mais il supprime aussi les notifications automatiques de mise à jour et peut masquer des logiciels obsolètes aux outils centralisés d’inventaire.
Une séparation physique ne doit jamais se substituer à la connaissance des versions. Les supports amovibles, les connexions de maintenance temporaires, les ordinateurs portables et un routage mal configuré peuvent créer des voies d’accès absentes lors de la conception initiale.
Le correctif est clair, mais le risque de déploiement demeure
La version 2.2 corrige la faille logicielle documentée, mais les organisations doivent encore prouver que chaque installation concernée a atteint l’état corrigé.
La remédiation du fournisseur est simple : mettre à jour mySCADA myPRO Manager vers la version 2.2 ou ultérieure. La plage concernée s’arrête à la version 2.1.
Cette clarté élimine une source fréquente de confusion. Les équipes n’ont pas à comparer plusieurs correctifs entre différentes branches pour ces deux CVE.
Le défi opérationnel est l’inventaire. Les organisations doivent identifier où le produit est exécuté, quelle version utilise chaque installation et quelles interfaces sont accessibles depuis chaque zone réseau.
Cette tâche peut révéler des lacunes sans rapport avec le nouvel avis. Les logiciels industriels peuvent se trouver sur des postes d’ingénierie, des systèmes de gestion dédiés, des appareils de mise en service temporaires ou des machines maintenues hors des processus d’entreprise habituels.
Un inventaire fiable doit inclure la version de l’application, l’identité de l’hôte, son emplacement réseau, le propriétaire du système, sa fonction opérationnelle et les voies de communication autorisées. Il doit aussi indiquer si un modem GSM est connecté.
Le détail du modem détermine si le chemin SMS documenté existe dans un déploiement donné. Une installation sans ce composant ne présente pas le même scénario pratique pour CVE-2026-82567.
L’API de commandes exige une analyse distincte. Les équipes doivent identifier chaque source autorisée à l’atteindre et vérifier si l’un des chemins provient de réseaux utilisateurs, de segments sans fil, de systèmes d’accès fournisseur ou de l’internet public.
Une règle de pare-feu ne prouve pas à elle seule l’isolement. Les tests de flux de paquets et l’examen de la configuration apportent des preuves plus solides que seuls les systèmes de gestion prévus peuvent se connecter.
Avant la mise à niveau, les opérateurs doivent confirmer les procédures de sauvegarde et de récupération. Ils doivent aussi comprendre les dépendances susceptibles d’échouer si le comportement du gestionnaire change après la mise à jour.
Les tests doivent porter sur les opérations de gestion normales, la transmission des alertes, les notifications SMS, l’authentification et la connectivité avec les systèmes gérés. L’objectif est de détecter les problèmes de compatibilité avant le déploiement en production.
Les équipes doivent ensuite consigner la version installée après le changement. Une notification de mise à jour ou un programme d’installation téléchargé ne prouve pas que chaque hôte a achevé avec succès la mise à niveau.
Lorsqu’une application immédiate du correctif est impossible, la réduction de l’exposition devient urgente. L’accès aux interfaces de gestion doit être limité aux systèmes explicitement autorisés au moyen de pare-feu et de zones réseau segmentées.
L’administration à distance doit emprunter des chemins d’accès contrôlés plutôt que d’exposer directement l’application. Les recommandations établies de CISA pour l’industrie préconisent de réduire l’exposition, de séparer les réseaux de contrôle des réseaux métier et d’utiliser des méthodes d’accès distant sécurisées.
Ses recommandations de défense en profondeur considèrent l’architecture réseau, le contrôle d’accès, la supervision et la réponse aux incidents comme des protections complémentaires. Aucune ne doit être considérée comme un remplacement permanent du logiciel corrigé.
Les contrôles temporaires doivent avoir des responsables et des dates d’expiration. Sans cela, une restriction d’urgence au niveau du pare-feu peut discrètement devenir la réponse à long terme tandis que la version vulnérable reste installée.
La supervision nécessite également des signaux propres au déploiement. Les équipes peuvent examiner les connexions à l’API de commandes, les événements d’authentification refusée après la mise à niveau et les requêtes inhabituelles vers les points de terminaison de notification.
Pour les systèmes compatibles SMS, les opérateurs doivent comparer l’activité du modem aux alertes attendues. Des numéros de destination non reconnus, un contenu de message inhabituel et une fréquence d’envoi anormale méritent une investigation.
Les journaux historiques peuvent aider à déterminer si une activité suspecte s’est produite avant la remédiation. Toutefois, l’absence d’une entrée de journal ne permet pas d’établir qu’aucune tentative n’a eu lieu si le point de terminaison vulnérable ne disposait pas d’une journalisation adéquate.
Les intervenants en cas d’incident doivent préserver les enregistrements réseau, hôte, application et modem pertinents. Si une activité paraît suspecte, ils doivent suivre les procédures établies d’escalade et de signalement.
L’avis ne fournit pas de scénario public d’exploitation. Cela limite ce que les défenseurs peuvent conclure sur le comportement des attaquants, leurs outils ou les victimes observées.
Cela ne réduit pas la gravité technique d’un chemin de gestion non authentifié. L’exposition et l’impact sur la mission doivent déterminer la vitesse de réaction de chaque organisation.
mySCADA a déjà fait l’objet de constats antérieurs de haute gravité
Les nouvelles failles s’inscrivent dans une tendance plus large où les fonctions de gestion deviennent des frontières de sécurité que les attaquants peuvent tester directement.
CISA a publié de précédents avis concernant des produits mySCADA. Ces cas antérieurs ne prouvent pas une cause technique commune, mais ils apportent un contexte utile aux défenseurs.
En 2022, CISA a décrit une vulnérabilité d’injection de commandes dans mySCADA myPRO versions 8.26.0 et antérieures. Un utilisateur authentifié pouvait modifier des paramètres et exécuter des commandes du système d’exploitation.
Ce problème antérieur de myPRO présentait un score CVSS 3 de 9,9. Le fournisseur recommandait une mise à jour vers la version 8.27.0 ou ultérieure.
La faille de l’API de commandes de 2026 diffère d’une manière essentielle. Son vecteur publié ne requiert aucun privilège, alors que le problème de 2022 exigeait un utilisateur authentifié.
Les produits et les schémas de version diffèrent aussi dans les documents, de sorte que les opérateurs ne doivent pas en déduire un chemin de mise à niveau direct entre ces avis. Chaque installation concernée doit être rapprochée des informations précises sur le produit et sa version.
Un avis distinct de 2025 couvrait plusieurs vulnérabilités de myPRO Manager, dont une injection de commandes du système d’exploitation. Cet historique renforce la nécessité de traiter les composants de gestion comme des actifs à forte valeur.
La leçon n’est pas qu’un fournisseur serait particulièrement vulnérable. Les interfaces administratives des produits industriels concentrent régulièrement des capacités que les attaquants recherchent.
Elles exposent la configuration, les communications, les identifiants, les mises à jour ou les connexions à des environnements contrôlés. Un seul contrôle manquant peut donc compromettre plusieurs protections en aval.
C’est pourquoi la gestion des vulnérabilités doit suivre les produits selon leur fonction, et non uniquement selon le nombre de CVE. Un serveur de gestion mérite la priorité, car son rôle peut amplifier l’impact d’une compromission.
Le même raisonnement s’applique aux équipements d’accès distant, aux postes d’ingénierie, aux historiens de données et aux passerelles de notification. Leur proximité avec les opérations donne aux faiblesses logicielles ordinaires une importance accrue dépendant du contexte.
Les organisations doivent aussi éviter de se fier entièrement aux scores mis en avant. CVE-2026-82567 présente un score moyen, mais son exploitation pourrait tout de même perturber le processus d’alerte de confiance d’un site.
À l’inverse, un score de 9,8 ne prouve pas qu’une instance isolée peut être attaquée depuis internet. Il signale des caractéristiques techniques graves une fois que l’attaquant atteint le service vulnérable.
Une priorisation efficace combine gravité, exposition, exploitabilité, fonction opérationnelle et difficulté de récupération. Elle tient aussi compte de la disponibilité immédiate d’une version corrigée.
Ici, la version corrigée existe. Il devient donc de plus en plus difficile de justifier un usage prolongé de la version 2.1 ou antérieure, sauf si une contrainte opérationnelle empêche le déploiement.
Si une telle contrainte existe, la direction doit la documenter. Le document doit nommer le responsable, expliquer la dépendance, lister les contrôles temporaires et définir la prochaine date de revue.
Cela transforme le retard de correctif en décision de risque gérée. Sans ce processus, le retard devient une situation par défaut invisible.
Ce que les opérateurs doivent surveiller ensuite
Les prochains signaux utiles sont une couverture de mise à niveau vérifiée, des preuves d’exploitation et la confirmation que les interfaces sensibles ne sont plus largement accessibles.
Premièrement, les organisations doivent mesurer l’adoption de la version 2.2 ou ultérieure. L’indicateur interne le plus important n’est pas de savoir si un correctif a été téléchargé, mais si chaque actif concerné signale désormais une version corrigée.
Cette mesure doit inclure les systèmes hors des outils d’entreprise habituels. Les installations hors ligne, les appareils gérés par des prestataires et les environnements de test peuvent conserver des versions vulnérables bien après la fin des mises à jour de production.
Un résultat complet renforce l’argument selon lequel le risque logiciel immédiat a été contenu. Les actifs non identifiés ou inaccessibles affaiblissent cette conclusion.
Deuxièmement, les défenseurs doivent surveiller les sources faisant autorité afin de détecter les changements de statut d’exploitation. La publication d’un nouveau code de preuve de concept, d’attaques confirmées ou l’inclusion dans un catalogue gouvernemental d’exploitation modifierait l’urgence de la réponse.
Au moment de la publication, les documents consultables décrivent les vulnérabilités et les correctifs sans établir l’existence d’une campagne d’exploitation active. Les lecteurs doivent distinguer cette absence d’éléments de la preuve qu’une exploitation est impossible.
Les informations sur les menaces peuvent évoluer rapidement après la divulgation. Les attaquants disposent d’un nom de produit clair, d’une plage de versions concernées, d’une catégorie de faiblesse et d’une description des fonctionnalités exposées.
Troisièmement, les opérateurs doivent valider l’architecture environnante. La mise à jour de l’application ne doit pas mettre fin à l’examen de l’exposition des interfaces de gestion.
Une analyse depuis les zones réseau appropriées peut confirmer que l’API de commandes et la passerelle de notification n’acceptent des connexions que depuis des sources approuvées. L’examen du pare-feu doit aboutir à la même conclusion.
Si un segment étendu peut encore atteindre ces services, l’environnement reste inutilement exposé aux futures failles. Un correctif ferme les vulnérabilités connues, tandis que la segmentation limite le rayon d’impact de la prochaine inconnue.
Les équipes doivent également vérifier le comportement de l’application après la mise à jour. Les commandes sensibles doivent exiger un accès authentifié et autorisé, et le point de terminaison SMS doit refuser les requêtes non authentifiées.
Ces tests doivent suivre des procédures approuvées dans un environnement contrôlé. Des tests en production sans coordination peuvent créer un risque opérationnel.
Les conclusions justifient également un examen de la conception des comptes et des accès. Les organisations doivent identifier qui administre le gestionnaire, quels comptes de service interagissent avec lui et comment les identifiants sont protégés.
Le principe du moindre privilège reste important après le rétablissement de l’authentification. Un compte valide ne doit recevoir que les fonctions nécessaires à son rôle.
La journalisation mérite une dernière vérification. Les équipes de sécurité ont besoin de suffisamment de détails pour relier une requête à une source, une identité, une action, un résultat et une heure.
Pour les notifications reposant sur un modem, les enregistrements doivent relier chaque message à l’événement ou à l’utilisateur qui l’a déclenché. Cela aide à distinguer l’automatisation légitime d’un usage non autorisé.
La réponse pratique à mySCADA myPRO Manager va donc au-delà de l’installation d’une seule version. Appliquez d’abord le correctif, puis vérifiez l’accessibilité, l’application des contrôles d’accès, la journalisation et la couverture des actifs.
Si votre organisation utilise myPRO Manager, peut-elle prouver que chaque installation est en version 2.2 ou ultérieure ? Peut-elle également démontrer que des systèmes non fiables ne peuvent pas atteindre les interfaces privilégiées ?
Ces deux réponses définissent le résultat à court terme. Une mise à jour confirmée corrige les failles documentées. Un accès réseau restreint et une authentification testée réduisent le risque que la prochaine interface négligée devienne un incident opérationnel.
