Déployer des réseaux de neurones dans des systèmes automobiles, industriels et embarqués critiques pour la sécurité exige de concilier deux philosophies d'ingénierie fondamentalement différentes : le monde probabiliste et fondé sur les données de l'apprentissage automatique, et le monde déterministe et fondé sur les preuves de la sécurité fonctionnelle. Ce guide explique les normes qui régissent ces environnements — ISO 26262, SOTIF/ISO 21448, IEC 61508 et IEC 62443 — et comment structurer un déploiement de ML qu'un ingénieur sécurité peut accepter.
Dernière révision : mai 2026
La sécurité fonctionnelle est la partie de la sécurité globale d'un système qui dépend du fonctionnement correct des composants électriques, électroniques et électroniques programmables. Lorsqu'un composant d'IA ou de ML est déployé dans un système critique pour la sécurité — freinage d'urgence autonome, arrêt d'urgence industriel, planification de mouvement robotique — les normes de sécurité fonctionnelle exigent la preuve que le système défaille de manière sûre, se comporte correctement dans ses conditions d'exploitation définies et tolère les défaillances matérielles et logicielles. Le défi pour l'apprentissage automatique est que ces normes ont été conçues pour des logiciels déterministes, et que les réseaux de neurones ne sont pas déterministes au sens traditionnel.
Les normes de sécurité fonctionnelle qui régissent les systèmes automobiles et industriels — ISO 26262, IEC 61508, IEC 62061 — ont été élaborées pour des logiciels déterministes : du code qui traite des entrées au moyen d'une logique définie et produit des sorties pouvant être spécifiées formellement, testées selon des critères de couverture structurelle et vérifiées comme correctes dans les conditions d'exploitation du système.
Les réseaux de neurones ne correspondent pas à ce modèle. Ils sont entraînés — et non programmés — et leur comportement émerge de millions de paramètres appris plutôt que d'une logique explicite. La même entrée présentée deux fois peut produire des sorties légèrement différentes selon le comportement en virgule flottante du matériel et l'ordonnancement des threads. Leurs modes de défaillance sont statistiques, non déterministes : ils donnent de bons résultats en moyenne mais peuvent échouer sur des entrées spécifiques sous-représentées dans les données d'entraînement. Et ils ne peuvent pas être vérifiés de façon exhaustive par rapport à une spécification formelle, car aucune spécification formelle n'existe — la spécification est implicite dans les données d'entraînement.
Cela crée une tension fondamentale que tout ingénieur déployant de l'IA dans un système critique pour la sécurité doit résoudre : comment construire un dossier de sécurité pour un composant dont le comportement ne peut être spécifié ni vérifié formellement au sens traditionnel ? La réponse — qui émerge aujourd'hui des organismes de normalisation, des consortiums industriels et de l'expérience des premiers programmes — combine des motifs architecturaux (moniteurs de sécurité, définition de l'ODD, chemins de repli) et des preuves statistiques (grands jeux de validation, tests de robustesse) qui constituent ensemble un dossier de sécurité défendable.
Les six tensions fondamentales ci-dessous représentent les défis d'ingénierie que tout déploiement de ML critique pour la sécurité doit relever.
Les normes de sécurité fonctionnelle (ISO 26262, IEC 61508) supposent un comportement déterministe : pour les mêmes entrées, une fonction de sécurité produit les mêmes sorties à chaque fois. Les réseaux de neurones entraînés par descente de gradient stochastique et dropout n'offrent pas cette garantie. Même des entrées identiques peuvent produire des sorties légèrement différentes selon l'implémentation matérielle en virgule flottante et l'ordonnancement des threads.
Les dossiers de sécurité exigent la traçabilité — vous devez pouvoir expliquer pourquoi un système prend une décision et démontrer qu'aucune décision dangereuse n'est possible à l'intérieur du domaine de conception opérationnelle (ODD) défini. Les réseaux de neurones profonds sont fondamentalement opaques. Les méthodes d'explicabilité (SHAP, LIME, cartes d'attention) fournissent des approximations, pas des preuves.
Un modèle entraîné sur une distribution de données d'entraînement peut se comporter de manière inattendue sur des entrées qui sortent de cette distribution — un problème connu sous le nom de dérive de distribution. Les normes de sécurité exigent que le système se comporte correctement sur l'ensemble complet de ses conditions opérationnelles définies. La dérive de distribution est fondamentalement en contradiction avec cette exigence.
Les logiciels critiques pour la sécurité traditionnels sont vérifiés par rapport à des spécifications formelles à l'aide de métriques de couverture structurelle (MC/DC pour ASIL D). Les réseaux de neurones ne peuvent pas être vérifiés ainsi — la « spécification » est implicite dans les données d'entraînement. La validation statistique sur de grands jeux de données réservés remplace la vérification formelle, mais les autorités de sécurité divergent sur ce qui constitue une preuve suffisante.
Les logiciels certifiés pour la sécurité sont soumis à une gestion des changements stricte : toute modification exige une réévaluation. Les modèles de réseaux de neurones peuvent être affinés, mis à jour ou remplacés à mesure que les données s'accumulent. Chaque mise à jour peut invalider le dossier de sécurité existant et exiger une revalidation — créant une tension entre l'amélioration opérationnelle et le maintien de la certification.
Les systèmes de sécurité en périphérie disposent de budgets de latence de bout en bout serrés — souvent inférieurs à 10ms pour les boucles de contrôle en temps réel. L'inférence de réseaux de neurones sur du matériel contraint (MCUs, FPGAs, petits SoCs) doit tenir dans ce budget tout en laissant une marge pour le reste du chemin de contrôle. La quantification et l'élagage aident mais introduisent leurs propres modes de défaillance.
ISO 26262 est la norme de sécurité fonctionnelle automobile, applicable aux véhicules routiers d'une masse maximale en charge (MGVM) jusqu'à 3 500 kg. Elle définit le cadre Automotive Safety Integrity Level (ASIL) — quatre niveaux (de A à D) qui spécifient la rigueur du processus d'ingénierie de la sécurité requis pour une fonction de sécurité donnée. ASIL D est le plus strict ; ASIL A est le moins exigeant.
Le niveau ASIL d'une fonction est déterminé au moyen d'une analyse des dangers et évaluation des risques (HARA) qui considère trois facteurs : la gravité (S) du préjudice potentiel, l'exposition (E) à la situation dangereuse et la contrôlabilité (C) par le conducteur ou l'opérateur. La combinaison de S, E et C détermine l'attribution de l'ASIL.
Le V-model est le cadre du processus de développement : les exigences sont spécifiées et décomposées sur la branche gauche du V ; l'implémentation se trouve au bas ; l'intégration, la vérification et les tests de validation se trouvent sur la branche droite, en miroir de chaque artefact de la branche gauche. Chaque exigence de sécurité doit être tracée depuis l'objectif de sécurité au niveau du véhicule à travers les niveaux système, matériel et logiciel, et vérifiée au niveau correspondant sur la branche droite.
SOTIF (ISO 21448:2022) étend ISO 26262 pour couvrir les dangers qui découlent des limites de la fonction prévue elle-même — non pas de défaillances, mais de situations où le système se comporte exactement comme conçu alors que la conception est insuffisante pour les conditions d'exploitation réelles. Cela est directement pertinent pour le ML : un modèle de perception qui classe mal un piéton dans un éclairage inhabituel n'est pas « en défaillance » au sens traditionnel — il fonctionne tel qu'entraîné, mais l'entraînement était insuffisant pour cette condition. L'analyse SOTIF exige d'identifier et de tester systématiquement ces conditions déclenchantes.
Exigence de sécurité fonctionnelle la plus basse. Applicable aux systèmes où la gravité du danger est faible ou l'exposition peu fréquente.
Implication pour le déploiement de ML
Une validation statistique sur des jeux de test modérés peut être acceptée. Des moniteurs d'exécution de base suffisent.
Exigence de sécurité modérée. Couramment appliquée aux fonctions d'aide à la conduite à potentiel de danger modéré.
Implication pour le déploiement de ML
Exige un ODD documenté, des métriques de performance sur les cas limites de l'ODD et une surveillance des entrées hors distribution.
Exigence de sécurité élevée. S'applique aux systèmes où des défaillances pourraient entraîner des blessures graves sans atténuation externe.
Implication pour le déploiement de ML
Dossier de sécurité complet requis. Moniteurs d'assurance à l'exécution, chemin de repli explicite et analyse SOTIF obligatoires. Une revue par un tiers est généralement attendue.
Niveau de sécurité fonctionnelle automobile le plus élevé. S'applique aux systèmes où une défaillance peut entraîner des dangers mettant la vie en péril.
Implication pour le déploiement de ML
Les composants de réseaux de neurones sont généralement limités à des rôles de perception/conseil, jamais dans le chemin de contrôle critique final. Des moniteurs déterministes redondants sont requis. Consensus industriel actuel : les composants purement ML ne sont pas certifiables à ASIL D en tant que fonction de sécurité unique.
IEC 61508 est la norme générique de sécurité fonctionnelle pour les systèmes relatifs à la sécurité électriques, électroniques et électroniques programmables (E/E/PE). C'est la norme mère dont dérivent les normes sectorielles : IEC 62061 (machines), EN 50128 (ferroviaire), IEC 61511 (industries de transformation) et IEC 61513 (nucléaire). Le cadre Safety Integrity Level (SIL) est l'équivalent de l'ASIL pour IEC 61508 — quatre niveaux (SIL 1–4) définis par la probabilité de défaillance à la demande (PFD) requise pour une fonction de sécurité.
Pour les déploiements d'IA dans les systèmes industriels, la question clé est : quel niveau SIL est attribué à la fonction de sécurité à laquelle le composant d'IA contribue ? Cela détermine la rigueur des preuves de validation requises et les contraintes sur la manière dont le composant d'IA peut être utilisé au sein de cette fonction.
Le principe général est le même que dans ISO 26262 : les composants de réseaux de neurones peuvent contribuer à des fonctions de SIL inférieur en tant qu'éléments consultatifs ou déclencheurs, mais les fonctions de sécurité à la plus haute intégrité exigent des implémentations déterministes ou des moniteurs de sécurité déterministes qui priment sur les sorties du composant ML.
Niveau d'intégrité de sécurité le plus bas. S'applique aux fonctions où une défaillance unique est peu susceptible de provoquer un événement dangereux sans facteurs contributifs multiples.
Note ML
Les systèmes consultatifs fondés sur le ML qui alimentent une fonction de sécurité SIL 1 doivent démontrer une fiabilité statistique dans les conditions d'exploitation définies.
Niveau intermédiaire. Courant dans les fonctions instrumentées de sécurité des industries de transformation : arrêts d'urgence, déclenchement de soupapes de sûreté, détection incendie et gaz.
Note ML
La détection d'anomalies par ML alimentant un arrêt SIL 2 doit être traitée comme un élément déclencheur dans la boucle de sécurité — sa probabilité de fonctionnement intempestif (défaillance dangereuse) doit être démontrée.
Niveau d'intégrité élevé. Présent dans les systèmes d'urgence des usines chimiques, la signalisation ferroviaire et les fonctions de soutien d'instrumentation nucléaire.
Note ML
Les composants de réseaux de neurones ne sont actuellement pas acceptés comme implémentations de fonction de sécurité SIL 3 par la plupart des organismes de certification. Le ML peut soutenir des diagnostics ou des chemins de données non critiques pour la sécurité aux côtés d'une couche de sécurité déterministe éprouvée.
Niveau IEC 61508 le plus élevé. Systèmes de protection des réacteurs nucléaires, fonctions vitales ferroviaires. Extrêmement rare en pratique.
Note ML
Aucun composant ML n'est accepté à SIL 4 comme partie de la fonction de sécurité elle-même à l'heure actuelle.
IEC 62443 est la série internationale de normes pour la cybersécurité des systèmes d'automatisation et de contrôle industriels (IACS). Elle définit un modèle de zones et conduits : le réseau OT est divisé en zones selon la criticité des actifs qu'elles contiennent, et les communications entre zones doivent passer par des conduits définis dotés de contrôles de sécurité appropriés.
Pour les déploiements d'IA, la question IEC 62443 est : dans quelle zone se trouve le serveur d'inférence IA, et quels contrôles de sécurité régissent ses communications avec le réseau de contrôle ? Placer un serveur d'inférence IA qui communique directement avec des automates (PLC) ou des équipements de terrain sans contrôles de conduit appropriés viole le modèle de zones et crée un risque de cybersécurité — un attaquant qui compromet le serveur IA obtient une voie d'accès vers la zone de contrôle.
De plus, les systèmes d'IA constituent une surface d'attaque nouvelle : des entrées adversariales — des entrées soigneusement conçues pour amener le modèle à produire des sorties incorrectes — peuvent provoquer des défaillances pertinentes pour la sécurité. L'analyse de cybersécurité IEC 62443 pour les systèmes d'IA devrait inclure des tests de robustesse adversariale ainsi que les contrôles de sécurité informatique classiques.
Réseaux informatiques d'entreprise — ERP, messagerie d'entreprise, connectivité cloud. Les modèles d'IA déployés ici ont la plus large surface d'attaque et le moindre impact OT en cas de compromission, mais aussi la plus faible fraîcheur des données et la latence la plus élevée.
Recommandation de placement de l'IA
Approprié pour l'IA de reporting, le résumé de documents, l'analytique métier. INAPPROPRIÉ pour le contrôle en temps réel ou l'inférence adjacente à la sécurité.
Systèmes de contrôle de supervision, bases de données historiques, serveurs SCADA. L'inférence IA déployée ici peut accéder aux données de procédé en temps réel via OPC-UA ou OSIsoft PI sans accès direct aux équipements de terrain.
Recommandation de placement de l'IA
Approprié pour la maintenance prédictive, le conseil en optimisation de procédé, la détection d'anomalies. Exige des contrôles de conduit IEC 62443-3-3 vers la Zone 2.
Automates (PLC), DCS, contrôleurs de terrain. Les boucles de contrôle critiques pour la sécurité s'exécutent ici. L'inférence IA en Zone 2 est inhabituelle et exige un durcissement SL (Security Level) 2 : authentification, communications chiffrées, journalisation d'audit.
Recommandation de placement de l'IA
Les moniteurs d'assurance à l'exécution et les détecteurs hors distribution peuvent opérer ici si les contraintes matérielles le permettent. La responsabilité directe d'une fonction de sécurité exige une analyse de sécurité fonctionnelle (ISO 26262 / IEC 61508).
Capteurs, actionneurs, instruments intelligents. Équipements extrêmement contraints — généralement des MCUs ou de simples RTUs. L'inférence IA ici est limitée à des modèles TinyML (quantifiés INT8, inférieurs à 1MB) sur des co-processeurs d'inférence dédiés.
Recommandation de placement de l'IA
Détection d'anomalies sur des flux de capteurs bruts. Faisable avec du matériel de classe MCU au niveau SL 1. La responsabilité d'une fonction de sécurité à cette couche exige une évaluation formelle IEC 61508.
Hyperion conseille sur la couche d'architecture IA et edge : où le ML s'inscrit dans l'architecture de sécurité, comment structurer le moniteur de sécurité et le chemin de repli, quelle chaîne d'outils edge convient à votre matériel, et comment préparer le dossier de preuves de sécurité. Nous ne sommes pas un organisme de certification — mais nous vous aidons à construire une architecture qu'un organisme de certification peut accepter.
Un dossier de sécurité est un argument structuré, étayé par des preuves, attestant qu'un système est acceptablement sûr pour une application donnée dans un environnement donné. Pour les composants ML, le dossier de sécurité doit traiter les modes de défaillance spécifiques des réseaux de neurones — dérive de distribution, opacité, non-déterminisme — au moyen de motifs architecturaux et de preuves statistiques plutôt que de vérification formelle. Les six éléments suivants constituent le cœur d'un dossier de sécurité défendable pour un composant ML en périphérie.
Définissez les conditions précises dans lesquelles le composant ML est valide : conditions environnementales, plages des données d'entrée, plages de fonctionnement des capteurs, enveloppes de vitesse/charge. L'ODD est le contrat entre le système ML et le dossier de sécurité. Toute entrée hors de l'ODD doit déclencher un état sûr — le système ML ne doit pas produire silencieusement des sorties dangereuses sur des entrées hors domaine.
Un moniteur déterministe parallèle — implémenté en logiciel ou matériel conventionnel — surveille les sorties du composant ML et bloque ou prime toute sortie qui viole la contrainte de sécurité. C'est le motif standard pour déployer du ML dans des systèmes critiques pour la sécurité : le composant ML est consultatif, le moniteur déterministe fait autorité. Le moniteur doit lui-même être certifié au niveau ASIL/SIL requis.
Un détecteur OOD — généralement fondé sur l'erreur de reconstruction des entrées, le désaccord d'ensemble ou la distance de Mahalanobis — signale les entrées qui sortent de la distribution d'entraînement. Lors d'une détection OOD, le système bascule vers le chemin de repli plutôt que de continuer à inférer. Les détecteurs OOD doivent être validés quant à leur propre taux de faux négatifs dans le dossier de sécurité.
Tout déploiement de ML critique pour la sécurité doit disposer d'un repli défini : un état sûr dans lequel le système entre lorsque le composant ML défaille, est primé par le moniteur de sécurité ou détecte une entrée OOD. La transition vers l'état sûr doit elle-même être évaluée ASIL/SIL. Motifs de repli courants : mode limité/conservateur (vitesse réduite, marges de sécurité accrues), demande de reprise par le conducteur/opérateur, arrêt contrôlé.
Parce que la vérification formelle (couverture MC/DC) ne peut s'appliquer aux réseaux de neurones, la validation statistique sur un grand jeu de test indépendant et représentatif prend sa place. La taille et la composition du jeu de test, les métriques de performance et les intervalles de confiance doivent être documentés et acceptés par l'autorité de sécurité. ISO PAS 21448 (SOTIF) et la future ISO 8800 fournissent des orientations émergentes.
La fonction de sécurité globale est décomposée en sous-éléments, chacun se voyant attribuer un niveau ASIL/SIL. Le composant ML se voit généralement attribuer un niveau ASIL/SIL inférieur, la différence étant compensée par le moniteur de sécurité déterministe. Cette décomposition ASIL doit être documentée et revue formellement. Le système total doit satisfaire à l'exigence ASIL/SIL de plus haut niveau.
Note sur les normes : La méthodologie de construction des dossiers de sécurité pour les composants ML évolue activement. ISO/TR 4804, UL 4600 et l'ISO 8800 en développement (IA et véhicules routiers) fournissent les orientations les plus actuelles. Les organismes de certification et les constructeurs automobiles établissent encore leurs positions d'acceptation sur des techniques spécifiques — ce qui constitue une preuve statistique suffisante, quelles approches de détection OOD sont acceptables, et comment la décomposition ASIL s'applique aux paires ML-logiciel conventionnel. Engagez toujours tôt le dialogue avec votre organisme de certification cible pour vous aligner sur le dossier de preuves.
Les systèmes en périphérie critiques pour la sécurité imposent des contraintes qui excluent la plupart des motifs de déploiement d'IA à usage général. Voici les contraintes d'ingénierie qui façonnent tout déploiement d'IA en périphérie dans un contexte de sécurité automobile ou industriel, ainsi que les choix de chaîne d'outils qui y répondent.
Les systèmes de sécurité automobiles exigent généralement une latence de bout en bout inférieure à 10–50ms. Les boucles de contrôle industrielles peuvent être plus serrées : 1–10ms pour les fonctions temps réel dur. L'inférence d'IA en périphérie doit être profilée à la latence du pire cas (99e centile), et non à la latence moyenne, par rapport à la marge temporelle disponible.
Les systèmes en périphérie critiques pour la sécurité ne doivent pas dépendre de la connectivité cloud pour l'inférence en temps réel. Le cloud peut servir à l'entraînement des modèles, à la surveillance et à l'orchestration des mises à jour à distance, mais le chemin d'inférence doit fonctionner entièrement hors ligne. Les partitions réseau sont une condition de conception, non un cas marginal.
Les ECU automobiles et les automates/contrôleurs edge industriels fonctionnent généralement sur des cœurs ARM Cortex-M/R ou RISC-V avec 256KB–4MB de RAM. Les modèles d'apprentissage profond complets n'y tiennent pas. Techniques : quantification INT8 (TensorFlow Lite Micro, ONNX Runtime pour MCUs), élagage structuré, distillation de connaissances vers des architectures plus petites (MobileNet, EfficientNet-Lite, CNN sur mesure).
Le chemin de déploiement en production dominant pour l'IA en périphérie dans les environnements contraints : entraîner dans PyTorch → exporter vers ONNX → optimiser avec TensorRT (NVIDIA Jetson / Drive) ou ONNX Runtime avec le delegate XNNPACK/NNAPI (SoC ARM). ONNX Runtime prend aussi en charge le déploiement MCU via ONNX Runtime for Microcontrollers. Ces chaînes d'outils ont un comportement documenté qui doit être validé dans le dossier de sécurité.
Les systèmes de sécurité exigent que la même entrée produise toujours la même sortie. Cela requiert : arithmétique à virgule fixe (INT8 au lieu de FP32), désactivation des optimisations à l'exécution qui varient d'une exécution à l'autre, affinité de threads fixe, aucune allocation de mémoire dynamique pendant l'inférence. Atteindre un déterminisme exact au bit près sur l'ensemble des déploiements exige une configuration soignée de la chaîne d'outils et une validation matérielle.
Les contrôleurs de sécurité en périphérie disposent d'enveloppes mémoire fixes — souvent pas plus de 4–16MB de Flash et 1–4MB de RAM partagés sur l'ensemble de l'application. Les budgets énergétiques des appareils alimentés par batterie ou contraints thermiquement limitent la fréquence d'inférence. La quantification des modèles et l'inférence planifiée (plutôt que continue) sont des solutions courantes.
Déploiement Physical AI
Architecture d'IA en périphérie et chaîne d'outils d'inférence embarquée pour les systèmes adjacents à la sécurité
Laboratoire LLM expert métier
Pipelines d'entraînement, de quantification et de validation de modèles pour matériel contraint
LLM souverain (secteur public)
IA isolée du réseau pour les infrastructures critiques et les environnements classifiés
Ce qui suit est un compte rendu factuel du parcours d'Hyperion en lien avec l'IA en périphérie dans les systèmes critiques pour la sécurité. Ce sont des faits vérifiés, pas des affirmations marketing.
Divulgation du périmètre : Hyperion est un cabinet de conseil en architecture IA et edge. Nous conseillons sur la couche IA/edge — architecture, sélection de la chaîne d'outils, conception du moniteur de sécurité, définition de l'ODD, structure du dossier de preuves. Nous ne sommes pas un organisme de certification, un organisme notifié, ni un évaluateur de sécurité accrédité. Nous ne délivrons pas de certifications ASIL ou SIL. Le travail de certification formelle exige un tiers accrédité.
Le fondateur Mohammed Cherifi a passé 17+ années en ingénierie automobile et systèmes embarqués, notamment chez Renault-Nissan-Mitsubishi Alliance, Cisco et ABB. Ce parcours inclut une exposition directe aux processus de sécurité fonctionnelle dans le développement logiciel automobile, les systèmes de contrôle embarqués et les contraintes opérationnelles des environnements critiques pour la sécurité. Hyperion apporte cette expérience à la couche IA/edge — non en tant qu'organisme de certification, mais en tant qu'équipe d'ingénierie qui comprend l'environnement.
La venture phare d'Hyperion, Auralink, est une plateforme d'agents déployée en périphérie bâtie sur 400+ microservices avec environ 20 agents d'IA. L'architecture d'Auralink démontre les motifs d'ingénierie requis pour l'inférence d'IA sur du matériel edge contraint — chemins d'inférence à faible latence, frontières de contrôle déterministes et séparation entre la couche consultative d'IA et la couche de contrôle faisant autorité. C'est une preuve transférable de la discipline architecturale requise pour l'IA en périphérie adjacente à la sécurité, et non une certification de sécurité.
Le service physical-ai-deployment d'Hyperion couvre l'architecture d'IA en périphérie, la sélection de la chaîne d'outils d'inférence embarquée et la couche d'intégration entre l'inférence d'IA et les systèmes de contrôle OT/embarqués. Notre rôle est la couche d'architecture IA et edge. Nous conseillons sur l'endroit où les composants ML s'inscrivent dans une architecture de sécurité, comment structurer le moniteur de sécurité et le chemin de repli, et quelles chaînes d'outils conviennent au matériel. Nous ne sommes pas un organisme de certification et ne délivrons pas de certifications ASIL/SIL — ce travail exige un organisme notifié.
Un preprint publié sur arXiv porte sur des agents d'IA autonomes déployés en périphérie pour l'infrastructure physique. Il s'agit d'un travail à caractère académique — un preprint, et non une publication dans une revue à comité de lecture — mais il reflète la profondeur architecturale qu'Hyperion applique aux déploiements d'IA en périphérie dans les systèmes physiques.
Mohammed Cherifi détient le titre d'Ambassadeur IA du programme Osez l'IA du gouvernement français et a été reconnu par FranceNum. Cela reflète un engagement dans la politique de l'IA et les défis réglementaires du déploiement de l'IA dans les environnements industriels et automobiles réglementés.
Pas en tant que fonction de sécurité unique — pas avec la méthodologie actuelle ni les positions d'acceptation de la plupart des organismes de certification. L'approche standard consiste à déployer le composant ML à un niveau ASIL/SIL inférieur (par ex. ASIL B ou QM), un moniteur de sécurité déterministe certifié au niveau supérieur comblant la différence par décomposition ASIL. Le système total peut alors satisfaire ASIL D, mais le composant ML lui-même ne porte pas cette désignation. Cette position reflète les orientations actuelles d'ISO 26262-6:2018 et d'IEC TR 63069:2019 — elle évoluera à mesure que les organismes de normalisation développeront des orientations spécifiques au ML (ISO/TR 4804, ISO 8800).
Le SOTIF (Safety of the Intended Function), publié sous le nom d'ISO 21448:2022, traite des dangers qui découlent non pas de défaillances du système mais des limites de la fonction prévue elle-même — lacunes de perception, conditions environnementales inattendues et comportement aux frontières de l'ODD. ISO 26262 couvre les défaillances du système par rapport à sa spécification. Le SOTIF couvre les insuffisances de la spécification elle-même. Pour les fonctions ADAS et autonomes, les deux normes s'appliquent : vous devez démontrer à la fois que le système défaille de manière sûre (ISO 26262) et que son comportement prévu est sûr sur l'ensemble de l'ODD (SOTIF/ISO 21448).
Un moniteur de sécurité est un composant logiciel ou matériel déterministe, vérifié indépendamment, qui s'exécute en parallèle du composant ML. Il vérifie la sortie du ML par rapport à un ensemble de contraintes de sécurité formelles — limites physiques, bornes de taux de variation, cohérence avec les données des capteurs — et bloque ou prime toute sortie qui viole ces contraintes. Le moniteur de sécurité est certifié au niveau ASIL/SIL requis indépendamment du modèle ML. Cette séparation est le motif architectural clé pour déployer du ML dans des systèmes critiques pour la sécurité : le composant ML est consultatif, le moniteur fait autorité.
L'ODD définit les conditions spécifiques dans lesquelles le système ML est valide : paramètres environnementaux (température, éclairage, météo), caractéristiques des données d'entrée (plages des capteurs, formats de données, qualité du signal), états de fonctionnement du véhicule ou de la machine, et contraintes géographiques ou propres à l'application. Toute entrée qui sort de l'ODD ne devrait pas être traitée par le composant ML — le système doit basculer vers un état de repli. Définir, valider et surveiller la frontière de l'ODD est l'une des tâches d'ingénierie les plus importantes d'un déploiement de ML critique pour la sécurité.
IEC 62443 définit un modèle de zones et conduits pour la cybersécurité industrielle. Les serveurs d'inférence IA, comme tout actif informatique, doivent être placés dans la bonne zone (généralement la Zone 3 — Supervision) et toutes les communications avec la Zone 2 (Contrôle) doivent passer par un conduit doté de contrôles de sécurité définis : authentification, chiffrement, vérification de l'intégrité des messages. Déployer un serveur d'inférence IA qui communique directement avec des automates (PLC) ou des équipements de terrain sans contrôles de conduit viole le modèle de zones. Le serveur IA lui-même doit satisfaire aux exigences de niveau de sécurité (SL) de sa zone, y compris la gestion des correctifs, l'authentification et la journalisation d'audit.
Il n'existe pas de liste unique de configurations acceptées — cela dépend du niveau ASIL/SIL cible, de l'organisme de certification et du cas d'usage spécifique. En général : les modèles optimisés avec TensorRT sur les plateformes NVIDIA Drive/Jetson sont largement utilisés dans les programmes ADAS jusqu'à ASIL B, avec des moniteurs d'assurance à l'exécution. ONNX Runtime sur SoC ARM est utilisé dans les applications industrielles aux SIL 1–2. Pour les niveaux d'intégrité plus élevés, une qualification formelle du moteur d'inférence lui-même (qualification d'outil selon ISO 26262-8) peut être requise. Hyperion conseille sur la sélection de la chaîne d'outils et la stratégie de qualification — le travail de qualification formelle exige l'implication du fournisseur de la chaîne d'outils.
Non. Hyperion est un cabinet de conseil en architecture IA et edge. Nous conseillons sur l'endroit où les composants ML s'inscrivent dans les architectures de sécurité, comment structurer les moniteurs de sécurité et les chemins de repli, quelles chaînes d'outils edge conviennent au matériel contraint, et comment concevoir des déploiements compatibles avec les exigences de sécurité fonctionnelle et d'IEC 62443. Les évaluations de certification ASIL/SIL proprement dites — le travail d'évaluation de conformité qui produit un certificat — doivent être réalisées par un évaluateur tiers accrédité ou un organisme notifié. Hyperion peut vous aider à préparer cette évaluation et à concevoir l'architecture pour la rendre praticable, mais nous ne délivrons pas de certifications.
La sécurité fonctionnelle (ISO 26262, IEC 61508) demande : le système défaille-t-il de manière sûre ? Elle se concentre sur les modes de défaillance matériels et logiciels, la tolérance aux fautes et l'intégrité des fonctions de sécurité lorsque des composants défaillent. IEC 62443 demande : le système est-il protégé contre une attaque délibérée ? Elle se concentre sur les contrôles de cybersécurité — authentification, chiffrement, segmentation réseau, gestion des vulnérabilités. Les deux sont requises pour les systèmes d'IA industriels : un système peut être fonctionnellement sûr (il défaille gracieusement) mais vulnérable en cybersécurité (il peut être attaqué et amené à défaillir). Pour les systèmes d'IA en particulier, les attaques adversariales sont un point de chevauchement — une entrée délibérément adversariale peut provoquer un comportement ML dangereux qu'une évaluation de sécurité fonctionnelle seule ne révélerait pas.
ISO 26262:2018 (2018). "Road vehicles — Functional safety (Parts 1–12)."
Contexte : La principale norme de sécurité fonctionnelle automobile. La Partie 6 couvre les exigences de développement logiciel, y compris les métriques de couverture structurelle spécifiques à l'ASIL. La Partie 10 inclut des orientations sur les composants IA/ML (non normatives au moment de la publication, évoluant dans les éditions ultérieures).
ISO 21448:2022 (2022). "Road vehicles — Safety of the intended functionality (SOTIF)."
Contexte : Traite des dangers liés aux insuffisances fonctionnelles dans la spécification ou la performance de la fonctionnalité prévue, y compris les limites des capteurs et le comportement aux frontières de l'ODD dans les systèmes ADAS et de conduite autonome.
ISO/TR 4804:2020 (2020). "Road vehicles — Safety and cybersecurity for automated driving systems — Design, verification and validation."
Contexte : Rapport technique fournissant des orientations sur la combinaison de l'analyse de sécurité fonctionnelle et de cybersécurité pour la conduite automatisée. Couvre le SOTIF, ISO 26262 et les renvois à SAE J3061.
IEC 61508:2010 (2010). "Functional safety of electrical/electronic/programmable electronic safety-related systems (Parts 1–7)."
Contexte : La norme internationale générique pour la sécurité fonctionnelle des systèmes E/E/PE. Définit les SIL 1–4, la probabilité de défaillance à la demande (PFD) et les exigences de développement et de validation logiciels.
IEC 62443 Series (2018–2024). "Industrial automation and control systems — Security."
Contexte : Norme multi-parties couvrant la cybersécurité pour la technologie opérationnelle. IEC 62443-3-3 définit les niveaux de sécurité (SL) et le modèle de zones/conduits. IEC 62443-4-2 couvre les exigences de sécurité des composants applicables aux serveurs d'inférence IA dans les réseaux OT.
IEC TR 63069:2019 (2019). "Industrial-process measurement, control and automation — Framework for functional safety and security."
Contexte : Rapport technique traitant de la relation entre la sécurité fonctionnelle (IEC 61508) et la cybersécurité (IEC 62443). Directement pertinent pour les déploiements d'IA qui couvrent les deux domaines.
UL 4600:2020 (2020). "Standard for Safety for the Evaluation of Autonomous Products."
Contexte : Première norme complète traitant spécifiquement des systèmes autonomes fondés sur le ML. Couvre la construction du dossier de sécurité, la définition de l'ODD, la surveillance opérationnelle et l'assurance à l'exécution pour les composants ML. Largement référencée dans les programmes automobiles nord-américains.
ISO/IEC TR 24029-2:2023 (2023). "Artificial Intelligence — Assessment of the robustness of neural networks — Part 2: Methodology for use in formal methods."
Contexte : Fournit des orientations sur les méthodologies de test de robustesse pour les réseaux de neurones, y compris la robustesse adversariale — pertinente à la fois pour la sécurité fonctionnelle et l'analyse de cybersécurité IEC 62443.
Les déploiements de ML critiques pour la sécurité exigent plus qu'une bonne performance de modèle — ils requièrent une architecture défendable, la bonne chaîne d'outils pour les contraintes matérielles et un dossier de sécurité documenté qu'un organisme de certification peut accepter. Hyperion apporte 17+ années d'expérience en ingénierie automobile et systèmes embarqués à la couche IA/edge. Nous conseillons sur l'architecture et la stratégie de preuves ; la certification formelle reste du ressort de l'organisme accrédité approprié. Commencez par une revue d'architecture ciblée.
Fondateur et Responsable de la stratégie IA
Mohammed Cherifi est le fondateur d'Hyperion Consulting, avec 17+ années en ingénierie automobile et systèmes embarqués. Il a travaillé chez Renault-Nissan-Mitsubishi Alliance, Cisco et ABB — des environnements où les processus de sécurité fonctionnelle régissent le développement logiciel. Il est spécialisé dans l'architecture d'IA en périphérie pour les systèmes physiques, y compris les déploiements adjacents à la sécurité dans les environnements automobiles et OT industriels.
Architecture d'IA en périphérie et inférence embarquée pour les systèmes physiques
De la simulation au déploiement en production dans la robotique de fabrication
Déploiement d'IA souverain et isolé du réseau pour les environnements industriels
Le Physical AI Stack à 6 couches pour la robotique, l'IA en périphérie et l'automatisation industrielle