Lifecycle stage — Build
L'obstacle le plus difficile entre un prototype d'IA fonctionnel et une machine critique pour la sécurité en production est le dossier de sécurité — l'argumentation structurée, étayée par des preuves, démontrant que le système est suffisamment sûr. L'apprentissage automatique remet en cause les hypothèses sur lesquelles reposent les processus de sécurité fonctionnelle traditionnels : il n'existe pas de spécification ligne par ligne à tracer, le comportement est statistique, et les organismes notifiés n'accepteront pas un modèle non documenté dans un véhicule, un système aéronautique ou une ligne industrielle. L'ingénierie du dossier de sécurité et des preuves de certification est la capacité de produire cette argumentation et cette piste de preuves — analyse des risques, évaluation des risques, décomposition ASIL/DAL/SIL, construction du dossier d'assurance, et traçabilité de la vérification et validation — mappée sur la norme qui régit votre domaine. C'est la ligne de démarcation la plus nette entre un spécialiste Physical AI et un consultant IA généraliste, et c'est le principal bloqueur dans tous les secteurs critiques pour la sécurité. Pour être explicite sur la frontière : un organisme notifié attribue la classification de sécurité réelle et certifie le système. J'ingénierie le dossier de sécurité et les preuves qu'il évalue — je n'émets pas de certifications.
Le ML remet en cause la V&V traditionnelle. Les normes de sécurité fonctionnelle présupposent une spécification traçable test par test ; un modèle appris n'en possède aucune. L'argumentation d'assurance doit être reconstruite pour un comportement statistique, et la plupart des équipes n'ont pas la méthode pour le faire.
Les organismes notifiés rejettent le ML non documenté. Un modèle qui performe bien en validation mais qui arrive sans analyse des risques, décomposition des exigences et piste de preuves traçable ne passera pas l'évaluation de conformité — la performance est nécessaire mais loin d'être suffisante.
Les preuves doivent être construites dès le départ, pas assemblées à la fin. Rétrofiter un dossier de sécurité sur un système qui n'a pas été conçu pour produire des preuves est la manière la plus coûteuse de découvrir ce que la norme exigeait.
Mappé sur la norme qui régit votre domaine — ISO 26262 (automobile), DO-178C/EASA (aérospatiale), IEC 61508 (industrie), ISO 13482 (robots de service) — et délimité à une fonction système définie.
Réaliser la HARA (ou l'équivalent du domaine) : identifier les dangers, évaluer l'exposition/la contrôlabilité/la gravité, et dériver les questions de classification des risques qu'un organisme notifié posera — sans anticiper la classification qu'il attribue.
Décomposer les objectifs de sécurité en exigences de sécurité fonctionnelles et techniques allouées à travers l'architecture, y compris l'élément ML et ses mécanismes de sécurité, moniteurs et solutions de repli.
Construire l'argumentation d'assurance structurée (ex. GSN) reliant les affirmations aux preuves, rendant le raisonnement de sécurité explicite et révisable plutôt qu'implicite et supposé.
Définir et assembler les preuves de vérification et validation ainsi que la matrice de traçabilité des exigences aux tests, afin que le dossier technique soit complet et prêt pour l'audit.
OEM automobiles et équipementiers Tier-1 (ISO 26262), maîtres d'œuvre aérospatiaux et de défense (DO-178C/EASA), intégrateurs industriels et robotiques (IEC 61508, ISO 10218/13482), et opérateurs énergétiques déployant du ML dans des fonctions où un incident de sécurité est un événement réglementaire et de responsabilité — pas un ticket de bogue. Pour les équipes qui ont un modèle fonctionnel et qui doivent maintenant prouver qu'il est sûr.
Non. Un organisme notifié ou un évaluateur accrédité attribue la classification de sécurité et certifie le système. J'ingénierie le dossier de sécurité et la piste de preuves qu'il évalue — l'analyse des dangers, la décomposition des exigences, le dossier d'assurance et la traçabilité V&V. Prétendre le contraire serait malhonnête, et un organisme notifié le détecterait.
Celle qui régit votre domaine — ISO 26262 pour l'automobile, DO-178C/EASA pour l'aérospatiale, IEC 61508 pour la sécurité fonctionnelle industrielle, ISO 10218/13482 pour les robots. La première étape de la mission établit la norme applicable et la frontière du système.
La conformité à l'EU AI Act concerne les obligations de gouvernance et de documentation du règlement. La certification de sécurité fonctionnelle est un régime distinct, plus ancien et plus approfondi, portant sur la sécurité physique de la machine. Un système d'IA critique pour la sécurité nécessite généralement les deux ; ce service couvre la partie sécurité fonctionnelle.
Découvrez d'autres services qui complètent cette offre
30 minutes. Je diagnostique votre situation, je vous dis honnêtement si ce service convient — et sinon, lequel conviendrait.