Connect981 – Content Dev

FAQ Category : gouvernance sémantique

  • Qui doit être responsable des définitions de KPI dans un programme ISO 22400 ?

    Dans un programme ISO 22400, aucune fonction ne devrait détenir unilatéralement la responsabilité des définitions de KPI. L’approche la plus efficace consiste à mettre en place un groupe de gouvernance formel et transverse, responsable de la définition, de l’approbation et de la modification des définitions de KPI, avec des rôles clairement attribués au sein de ce groupe.

    Modèle de responsabilité recommandé

    Pour les environnements réglementés et brownfield, une répartition pratique des responsabilités est la suivante :

    En pratique, cela se rattache à la gouvernance des KPI ISO 22400 lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

    • Sponsor exécutif (direction des opérations ou du site) : Responsable du cadre global des KPI, des priorités et de la résolution des conflits. Il veille à ce que les KPI soutiennent la stratégie, et pas seulement la disponibilité des données.
    • Propriétaires de processus (Opérations / Méthodes industrielles / Maintenance) : Responsables du sens opérationnel de chaque KPI (par exemple, ce qui est comptabilisé comme temps de production planifié, ce qui constitue un arrêt valide, la manière de traiter les changements de série ou les inspections). Ils pilotent l’utilisabilité et évitent les définitions théoriquement correctes mais inutilisables en exploitation.
    • Qualité / QMS : Responsable de la traçabilité, de la documentation et de la maîtrise des changements des définitions de KPI. La fonction veille à ce que les définitions, les formules et les sources de données soient gérées en versions, revues et alignées avec les procédures qualité et les attentes d’audit.
    • IT / OT / référents données MES : Responsables de la mise en œuvre technique des définitions de KPI dans le MES, les historiens, les data lakes et les outils de reporting. Ils sont responsables de la filiation des données, de la correspondance avec les structures ISO 22400 et de la cohérence de calcul des KPI entre les différents systèmes.
    • Finance / Contrôle de gestion (le cas échéant) : Valide que les KPI de coût, d’efficacité et d’utilisation sont alignés avec le reporting financier et ne créent pas de « vérités » contradictoires entre les tableaux de bord du site et ceux du groupe.

    Pourquoi la responsabilité partagée est essentielle pour ISO 22400

    ISO 22400 fournit une terminologie normalisée et des structures de formules, mais chaque site doit encore décider :

    • Comment classer et segmenter le temps (p. ex. arrêts planifiés vs non planifiés, changements de série, fenêtres de maintenance).
    • Quels équipements et flux de valeur entrent dans le périmètre de chaque KPI.
    • Comment traiter les cas limites (rework, cycles de test, essais d’ingénierie, blocages qualité).
    • Comment aligner les définitions des KPI entre les outils MES, ERP, SCADA et de reporting.

    Si la responsabilité des KPI relève uniquement de l’IT, vous risquez d’obtenir des indicateurs techniquement cohérents mais sans signification opérationnelle. Si elle relève uniquement des opérations, vous risquez des optimisations locales, une documentation insuffisante et des divergences entre sites. Si elle relève uniquement de la qualité, vous pouvez obtenir de bonnes procédures mais une faible adoption. Un modèle partagé, avec des responsabilités de gouvernance explicites, équilibre ces risques.

    Attentes en matière de gouvernance et de maîtrise des changements

    Dans les environnements réglementés et à cycle de vie long, la responsabilité des définitions de KPI doit inclure une gouvernance structurée, et pas seulement un comité informel. A minima :

    • Catalogue de KPI faisant autorité : Une liste unique et maîtrisée des KPI ISO 22400, incluant le nom, la formule, les données d’entrée, les exclusions, le niveau de calcul (machine, ligne, site) et le système de référence.
    • Flux de travail d’approbation formel : Les nouveaux KPI proposés ou les modifications de définition sont examinés et approuvés par le groupe de gouvernance (opérations, qualité, IT/OT et finance selon les besoins), avec une justification et un impact documentés.
    • Gestion des versions et traçabilité : Chaque définition de KPI dispose d’un historique de versions indiquant clairement quand et pourquoi une modification a été apportée, quels systèmes ont été impactés et quelles périodes ne sont pas comparables en raison d’un changement de définition.
    • Évaluation d’impact et validation : Avant la mise en production des changements, les référents données et les propriétaires de processus valident que la mise en œuvre correspond à la définition approuvée, et que les rapports, tableaux de bord et alertes se comportent comme prévu.
    • Communication et formation : Les modifications des définitions de KPI sont communiquées aux superviseurs, ingénieurs et analystes afin que les tendances de performance soient interprétées correctement.

    Coexistence avec les systèmes existants dans les usines brownfield

    Dans les environnements brownfield, la responsabilité de la définition des KPI est contrainte par les MES/SCADA, les historiseurs, les ERP et les outils de reporting existants, dont beaucoup intègrent leurs propres calculs de KPI. Une approche réaliste de la responsabilité reconnaît que :

    • Vous ne pouvez souvent pas remplacer toute la logique KPI existante dans les systèmes hérités sans validation majeure, arrêt de production et requalification. À la place, vous définissez généralement un système de référence pour chaque KPI et documentez la manière dont les autres systèmes l’approximent ou le consomment.
    • Différentes lignes, usines ou fournisseurs peuvent aujourd’hui utiliser des formules de KPI légèrement différentes. La responsabilité inclut de décider s’il faut les harmoniser et, le cas échéant, selon quel horizon temporel et avec quelle charge de revalidation.
    • Les efforts d’intégration et de mapping des données doivent être portés conjointement par l’IT/OT et les responsables de processus afin que les champs ISO 22400 soient renseignés correctement et de manière cohérente entre les interfaces.
    • Le reporting externe (auprès des clients, des autorités de régulation ou du groupe) peut déjà s’appuyer sur des définitions spécifiques. Les modifier peut avoir des implications d’audit et contractuelles qui nécessitent une revue qualité et juridique.

    Comme le remplacement complet de la logique KPI des systèmes hérités peut être risqué et coûteux dans des contextes réglementés, le groupe de gouvernance priorise souvent :

    • La définition et la documentation, en premier lieu, de KPI canoniques alignés sur ISO 22400.
    • Le mapping des sorties des systèmes actuels vers ces définitions, avec des notes claires lorsqu’elles diffèrent.
    • La refactorisation ou la consolidation progressive des calculs de KPI à mesure que les systèmes sont mis à niveau ou revalidés.

    Étapes pratiques pour attribuer la responsabilité

    Pour établir la responsabilité sans réorganiser toute votre structure :

    1. Désignez un responsable du programme de KPI ISO 22400 (souvent issu de l’excellence opérationnelle ou de l’ingénierie de fabrication) qui coordonne les travaux, sans être seul propriétaire des définitions.
    2. Créez une charte de gouvernance des KPI qui désigne le groupe central (opérations, qualité, IT/OT, finance) et précise les droits de décision, les flux de travail d’approbation et les attentes en matière de documentation.
    3. Commencez par un ensemble restreint et critique de KPI (p. ex., disponibilité, performance, taux de qualité, OEE, NPT) et attribuez à chacun des propriétaires de processus et des référents de données spécifiques.
    4. Documentez l’état actuel par rapport à l’état cible aligné sur ISO 22400 pour chaque KPI, y compris les écarts des systèmes existants.
    5. Intégrez les changements de définition des KPI dans les processus de maîtrise des changements existants (p. ex., gestion des changements IT et maîtrise documentaire du QMS), afin que les modifications soient suivies comme tout autre changement maîtrisé.

    En résumé, les définitions de KPI dans un programme ISO 22400 doivent être portées par un groupe de gouvernance transverse avec des responsabilités clairement établies : les opérations pour le sens pratique, la qualité pour la traçabilité et la maîtrise des changements, l’IT/OT pour l’intégrité des données et la mise en œuvre, et la finance pour l’alignement avec le reporting métier. L’organigramme exact importe moins que l’existence de rôles explicites, de décisions documentées et d’une gestion rigoureuse des changements dans vos systèmes existants.

  • Quel est le rôle de la base de données OASIS dans la maîtrise des fournisseurs ?

    La base de données OASIS, gérée par l’International Aerospace Quality Group (IAQG), est un répertoire centralisé des organismes certifiés selon les normes de la série AS9100, ainsi que des organismes de certification et des auditeurs qui les supervisent. Dans le cadre de la maîtrise des fournisseurs, son rôle est de fournir des informations de certification et d’audit fiables et normalisées, que vous pouvez utiliser comme l’un des éléments d’entrée de vos processus d’approbation, de surveillance et de gestion des risques fournisseurs.

    Comment OASIS soutient la maîtrise des fournisseurs

    Concrètement, la plupart des organisations de l’aéronautique, de l’aérospatial et de la défense utilisent OASIS dans la maîtrise des fournisseurs pour :

    En pratique, cela se rattache à la coordination des fournisseurs et de la chaîne d’approvisionnement lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

    • Vérification de la certification : confirmer si un fournisseur actuel ou candidat détient une certification active de la série AS9100, identifier son organisme de certification (CB) et vérifier les dates de validité.
    • Couverture du périmètre et des sites : vérifier quels sites sont certifiés et quelles activités, quels produits ou quels services sont couverts par le périmètre du certificat, afin de l’aligner sur les travaux que vous envisagez de confier.
    • Visibilité sur les audits et les non-conformités : examiner les résultats d’audit de haut niveau, y compris les non-conformités majeures éventuelles et leur clôture, afin d’éclairer les évaluations de risque et la planification de la surveillance.
    • Contrôles lors de l’intégration des fournisseurs : utiliser les informations OASIS dans le cadre de la diligence préalable avant d’approuver un fournisseur, en particulier pour les catégories de produits à risque plus élevé ou les procédés spéciaux.
    • Surveillance continue : confirmer périodiquement que la certification d’un fournisseur reste valide et qu’aucun problème significatif non résolu n’a été signalé par son CB.

    Ces usages soutiennent un processus de maîtrise des fournisseurs davantage fondé sur des preuves, et réduisent la dépendance à des copies statiques de certificats qui peuvent être obsolètes ou incomplètes.

    Ce qu’OASIS ne fait pas en matière de maîtrise des fournisseurs

    Il est important d’être clair sur ce qu’OASIS ne fournit pas. S’y fier seul ne suffit pas pour assurer une maîtrise robuste des fournisseurs dans des environnements réglementés à longs cycles de vie :

    • Aucune garantie de performance : Les enregistrements OASIS ne garantissent ni la performance de livraison, ni la qualité produit, ni la capabilité des processus. Vous devez toujours disposer de vos propres indicateurs, tels que l’OTD, les PPM, les taux de NCR et la gravité des non-détections.
    • Aucun remplacement de la qualification fournisseur : OASIS ne se substitue pas à vos activités internes de qualification (par exemple, évaluations techniques, revues de capabilité des processus, inspection du premier article (FAI) ou approbations de procédés spéciaux).
    • Aucune donnée détaillée sur les processus ou les produits : La base de données ne fournit pas de flux de processus détaillés, de PFMEA, de plans de contrôle ni d’historique qualité au niveau pièce. Ces éléments restent dans vos propres systèmes (ERP, MES, QMS) et dans les soumissions des fournisseurs.
    • Aucune intégration directe à votre modèle de risque par défaut : Sauf si vous avez construit et validé une intégration, les informations OASIS n’alimenteront pas automatiquement vos tableaux de bord fournisseurs, vos classements de risque ou vos flux de travail d’approbation.

    Modes courants d’intégration d’OASIS dans les processus de maîtrise des fournisseurs

    Dans une gestion mature des fournisseurs aéronautiques, OASIS est généralement intégré à plusieurs points de contrôle :

    • Intégration et approbation des fournisseurs : Avant d’ajouter un nouveau fournisseur aéronautique, les responsables de familles d’achats ou les ingénieurs qualité consultent OASIS afin de confirmer le statut de certification, de vérifier que le périmètre couvre les travaux prévus et de relever toute non-conformité majeure récente.
    • Revue périodique des fournisseurs : Lors des revues annuelles ou périodiques des fournisseurs, l’équipe confirme dans OASIS que les certificats sont toujours valides et rapproche toute divergence avec les copies fournies par le fournisseur.
    • Planification des audits : Lors de la planification des audits fournisseurs sur site, les auditeurs internes examinent l’historique d’audit OASIS du fournisseur afin de se concentrer sur les zones à haut risque, les constats récurrents ou les faiblesses systémiques identifiées par le CB.
    • Escalade et confinement : En cas de défaut critique non détecté ou de problème qualité majeur, les équipes qualité et achats peuvent consulter OASIS pour rechercher d’éventuels constats récents du CB chez ce fournisseur susceptibles d’être liés au problème, et en tenir compte pour décider d’une surveillance supplémentaire ou d’un statut probatoire.

    Dans tous les cas, OASIS constitue une donnée d’entrée. Il complète, mais ne remplace pas, vos propres évaluations techniques et commerciales.

    Limites, dépendances et qualité des données

    L’efficacité d’OASIS dans la maîtrise fournisseurs dépend de plusieurs facteurs :

    • Actualité des mises à jour des CB : OASIS s’appuie sur les organismes de certification pour maintenir les données. Si les CB tardent à mettre à jour les enregistrements, le statut du certificat ou les constats peuvent être en décalage avec la réalité.
    • Contrôles d’accès et confidentialité : Certaines informations d’audit détaillées ne sont visibles que par certains utilisateurs ou par accord mutuel. Votre équipe peut ne pas voir toutes les preuves sous-jacentes sans dispositions supplémentaires avec le fournisseur ou le CB.
    • Maturité des processus internes : Si votre processus de maîtrise fournisseurs ne fait pas systématiquement référence à OASIS, ou si les vérifications ne sont pas documentées dans votre QMS, les données disponibles n’influenceront pas les décisions de manière fiable.
    • Qualité de l’intégration (le cas échéant) : Si vous intégrez les données OASIS dans un ERP, un QMS ou des portails fournisseurs, vous devez valider les correspondances de données, la fréquence de synchronisation et la gestion des erreurs. Dans les environnements réglementés, de telles intégrations doivent passer par une gestion formelle des changements et, le cas échéant, une validation.

    Les organisations doivent définir explicitement dans leurs procédures la manière dont OASIS est utilisé (par exemple lors de l’approbation fournisseur, de la réapprobation et de la revue périodique) et les actions à mener lorsque les données OASIS contredisent la documentation fournie par le fournisseur.

    Coexistence avec les systèmes existants et réalité des environnements brownfield

    Dans la plupart des environnements aérospatiaux et de défense, OASIS coexiste avec un ensemble de systèmes hérités et modernes :

    • ERP et données de référence fournisseurs : les informations OASIS sont généralement utilisées comme référence lors de la création ou de la mise à jour des fiches fournisseurs, mais l’ERP demeure le système de référence pour déterminer qui est approuvé pour recevoir des pièces ou des familles d’achats particulières.
    • QMS et flux de travail de qualification fournisseurs : les flux de travail QMS incluent souvent une étape visant à documenter les vérifications OASIS (par exemple, captures d’écran ou identifiants de référence) en tant que preuves objectives dans les enregistrements d’approbation et de revue périodique.
    • Portails fournisseurs et tableaux de bord : certaines organisations répliquent des attributs clés d’OASIS (type de certification, date d’expiration) dans les tableaux de bord fournisseurs, mais cela se fait généralement par saisie manuelle ou via des intégrations légères plutôt que par automatisation complète, en raison de contraintes de validation, de coût et de maîtrise des changements.

    Tenter de traiter OASIS comme une plateforme complète de maîtrise des fournisseurs échoue généralement en pratique. Les longs cycles de vie des équipements, la dette d’intégration et la charge liée à la qualification de nouveaux outils font que la plupart des sites continuent d’utiliser OASIS comme source de données de référence, tout en conservant l’ERP, le QMS et le MES comme systèmes opérationnels de référence pour la maîtrise des fournisseurs.

    Comment utiliser OASIS dans une stratégie de maîtrise des fournisseurs fondée sur les risques

    Pour utiliser OASIS de manière efficace et réaliste :

    • Définir quand OASIS doit être consulté : par exemple, lors de l’approbation d’un nouveau fournisseur, de la revue annuelle des fournisseurs stratégiques, et avant de confier des travaux pour des pièces critiques ou des procédés spéciaux.
    • Lier le statut OASIS aux cotations de risque : intégrer le statut de certification, l’adéquation du périmètre et les non-conformités majeures récentes comme facteurs dans votre modèle de risque fournisseur, aux côtés de vos propres indicateurs de performance.
    • Documenter les preuves et les décisions : conserver les références OASIS (par exemple, impressions ou identifiants) dans votre QMS ou votre dossier fournisseur afin de disposer de preuves traçables lors des audits.
    • Ne pas s’y fier excessivement : considérer OASIS comme un élément de preuve corroborant, et non comme la preuve qu’un fournisseur présente un faible risque. Continuez à surveiller les performances réelles, la capabilité des processus et les données de conformité.

    Utilisé de cette manière, OASIS renforce la maîtrise des fournisseurs en rendant les données de certification plus transparentes et traçables, tout en maintenant vos décisions opérationnelles ancrées dans votre propre expérience en matière de qualité et de livraison.

  • Qu’est-ce que la norme ISA-95 ?

    ISA-95 (également publiée à l’international sous la référence IEC 62264) est une norme qui fournit des modèles et une terminologie pour intégrer les systèmes de gestion avec les opérations de fabrication et les systèmes de contrôle-commande. Elle est largement utilisée pour structurer la manière dont les ERP, MES, SCADA, historiseurs et systèmes de contrôle d’atelier échangent des informations et des responsabilités.

    Ce que définit réellement ISA-95

    ISA-95 se concentre sur les modèles et interfaces, et non sur des produits logiciels spécifiques. Les éléments clés comprennent :

    En pratique, cela rejoint la cartographie des données et l’interopérabilité des systèmes lorsque les équipes doivent transformer la réponse en pratiques d’exécution répétables.

    • Niveaux fonctionnels : une vue en couches allant du contrôle terrain (niveaux 0 à 2), en passant par la gestion des opérations de fabrication (niveau 3, généralement MES/LIMS/WMS), jusqu’à la planification et la logistique d’entreprise (niveau 4, généralement ERP).
    • Modèles fonctionnels : descriptions normalisées des activités qui relèvent de chaque niveau, telles que la planification de la production, le dispatching, la collecte de données, les opérations qualité et les opérations de maintenance.
    • Modèles d’information : structures communes pour des éléments tels que les définitions de matière, les modèles d’équipement, les définitions de travail (recettes/gammes), les programmes de production, la performance de production et le personnel.
    • Nommage des objets et des attributs : méthodes normalisées pour décrire des entités telles que les produits, les équipements, les actifs physiques et les opérations de travail, afin que différents systèmes puissent référencer le même élément de manière cohérente.

    L’objectif est de donner aux équipes IT, ingénierie et opérations un langage commun pour déterminer quelles informations doivent circuler entre les systèmes, où se situent les responsabilités et comment les données doivent être modélisées.

    Ce qu’ISA-95 ne fait pas

    Dans des environnements réglementés et brownfield, il est important d’être explicite sur ce qu’ISA-95 ne fournit pas à lui seul :

    • Aucune conformité automatique : utiliser la terminologie ou les modèles ISA-95 ne crée ni ne garantit la conformité réglementaire, les résultats d’audit ou l’intégrité des données. Ceux-ci dépendent de vos processus, contrôles et activités de validation spécifiques.
    • Aucune interopérabilité prête à l’emploi : deux fournisseurs peuvent tous deux revendiquer une « compatibilité ISA-95 » tout en nécessitant encore une intégration sur mesure, un mapping de données et des essais importants. La norme réduit les ambiguïtés, mais elle ne supprime pas l’effort d’intégration.
    • Aucune prescription d’architecture complète : ISA-95 n’impose pas une topologie système particulière, une pile fournisseur spécifique ni une répartition cloud/on-premise. Elle cadre quelles fonctions et données sont nécessaires, mais pas exactement comment les mettre en œuvre.
    • Aucune validation ni qualification : la validation, la qualification et la maîtrise des changements restent des responsabilités du site. ISA-95 peut soutenir la traçabilité et des spécifications plus claires, mais ce n’est pas un cadre de validation.

    Pourquoi ISA-95 est important dans les environnements industriels et réglementés

    Pour les organisations exploitant des MES, ERP, historians et systèmes de contrôle-commande multifournisseurs sur de longs cycles de vie des actifs, ISA-95 est principalement utile comme outil de structuration et de communication :

    • Des frontières système claires : il aide à définir quel système doit être responsable de quelle fonction (par exemple l’ordonnancement détaillé dans le MES par rapport à la planification grossière dans l’ERP) et réduit les chevauchements et les ambiguïtés dans la durée.
    • Une conception d’intégration plus robuste : les modèles d’information fournissent un point de départ pour spécifier les interfaces, les contenus échangés et les flux de données entre systèmes. Cela peut réduire les mauvaises interprétations et les reprises lors des projets d’intégration.
    • Traçabilité et gouvernance des données : un modèle cohérent pour les équipements, les matières et les définitions de travail facilite la compréhension de l’origine des enregistrements critiques, de leur transformation et de leur consommation dans les différents systèmes.
    • Maîtrise des changements sur de longs cycles de vie : lorsque les équipements et les systèmes restent en place pendant des décennies, les modèles de la norme créent une référence stable qui résiste aux changements de fournisseurs, aux réécritures d’interfaces et aux mises à niveau incrémentales.

    Comment ISA-95 s’intègre aux systèmes existants (brownfield)

    Dans la plupart des usines, ISA-95 est appliquée à un environnement existant plutôt qu’à partir d’une situation entièrement nouvelle. Les schémas typiques comprennent :

    • Cartographier les systèmes actuels selon les niveaux ISA-95 : identifier quelles capacités sont effectivement fournies par quels systèmes existants, et où les fonctions sont dupliquées ou manquantes.
    • Utiliser les modèles ISA-95 pour concevoir les intégrations : lors de la création ou de la refonte d’interfaces (par exemple entre ERP et MES), utiliser les entités ISA-95 telles que le planning de production, la définition matière et la performance de production comme contrat conceptuel, puis les mapper vers les structures de données réelles de chaque système.
    • Alignement incrémental : plutôt que de remplacer un MES ou un ERP hérité uniquement pour « être conforme à ISA-95 », les équipes standardisent progressivement les interfaces et la nomenclature, généralement en parallèle d’autres projets (tels que de nouvelles lignes, de nouveaux produits ou des mises à niveau d’historian).
    • Documenter l’architecture et les responsabilités : les documents d’architecture, les URS et les spécifications d’interface utilisent souvent les termes ISA-95 afin de rendre auditables les responsabilités et les flux de données, en particulier lorsque différents fournisseurs ou équipes internes se partagent la propriété.

    Le remplacement complet de systèmes hérités uniquement pour s’aligner sur ISA-95 est rarement justifié dans des environnements fortement réglementés, en raison de la charge de qualification, du risque d’arrêt de production et de la complexité d’intégration. ISA-95 apporte généralement davantage de valeur comme modèle de référence pour guider des améliorations par étapes.

    Relation avec d’autres normes et pratiques

    ISA-95 apparaît souvent aux côtés d’autres cadres :

    • Modèles de référence MES : de nombreux fournisseurs de MES structurent leurs capacités fonctionnelles et leurs modèles de données directement sur ISA-95, en particulier pour les opérations de production, de qualité, de maintenance et de stocks.
    • Schémas d’intégration d’entreprise : ISA-95 décrit conceptuellement ce qui est échangé. Les schémas d’intégration technique (API, bus de messages, OPC UA, transferts basés sur des fichiers) définissent comment ces modèles sont mis en œuvre et gouvernés.
    • Modélisation des données et données de référence : les modèles ISA-95 peuvent soutenir les démarches de gestion des données de référence en clarifiant les entités communes telles que les matières, les équipements, les ressources et les gammes à travers ERP, PLM et MES.

    Limites pratiques et modes de défaillance

    Les difficultés courantes lors de l’utilisation d’ISA-95 comprennent :

    • Adoption partielle : les sites peuvent adopter le modèle par niveaux tout en ignorant les modèles d’information, ce qui entraîne des contrats de données ambigus et de la confusion malgré les étiquettes « ISA-95 ».
    • Surinterprétation : traiter ISA-95 comme un référentiel de règles rigide peut entrer en conflit avec les contraintes du terrain, telles que des contrôleurs existants ou des flux de travail validés qui ne peuvent pas être facilement restructurés.
    • Écarts d’interprétation entre fournisseurs : différents fournisseurs interprètent la norme différemment. La spécification des interfaces et les essais restent essentiels, même lorsque toutes les parties revendiquent un alignement sur ISA-95.
    • Travail d’intégration sous-estimé : supposer que des systèmes « conformes ISA-95 » s’intégreront avec un effort minimal conduit souvent à des glissements de planning. Une cartographie détaillée, des règles de transformation et des tests de validation restent nécessaires.

    Utilisé avec discernement, ISA-95 est un modèle de référence stable qui aide à structurer l’intégration, à clarifier les rôles des systèmes et à soutenir la maintenabilité à long terme. Sa valeur dépend de la rigueur avec laquelle il est appliqué dans l’architecture, les spécifications et la maîtrise des changements, et non des seules étiquettes.

  • Pouvons-nous accepter certains risques liés à la sécurité de l’information au titre d’ISO 27001 ?

    Oui. ISO 27001 vous autorise explicitement à accepter des risques liés à la sécurité de l’information au lieu de les traiter, mais uniquement de manière maîtrisée et documentée, alignée sur vos obligations commerciales, contractuelles et réglementaires.

    Ce qu’ISO 27001 attend réellement

    L’acceptation du risque est l’un des résultats possibles du processus de traitement des risques. Pour être cohérent avec ISO 27001, vous devez :

    En pratique, cela se rattache aux preuves de sécurité industrielle lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

    • Utiliser une méthode d’évaluation des risques définie et reproductible (incluant des critères de vraisemblance et d’impact).
    • Déterminer les critères d’acceptation des risques applicables à l’échelle de votre organisation et les faire approuver par la direction.
    • Évaluer chaque risque au regard de ces critères et des obligations applicables (réglementaires, contractuelles, politiques internes).
    • Choisir une option de traitement : réduire, éviter, partager/transférer ou accepter.
    • Documenter la décision et sa justification lorsqu’un risque est accepté.

    ISO 27001 n’interdit pas d’accepter des risques ; elle exige que vous maîtrisiez le processus et que vous soyez en mesure de démontrer comment et pourquoi un risque a été accepté.

    Quand l’acceptation du risque n’est généralement pas appropriée

    Même si ISO 27001 prévoit ce mécanisme, vous ne pouvez pas simplement « accepter » un risque qui entre en conflit avec des exigences externes impératives. Dans les environnements de fabrication réglementés, l’acceptation du risque est souvent limitée par :

    • Réglementation et droit : Les contrôles à l’exportation, les lois sur la protection de la vie privée, les règles de cybersécurité propres à un secteur et les réglementations liées à la sécurité peuvent imposer des contrôles spécifiques. Vous ne pouvez pas accepter une non-conformité comme décision de risque.
    • Obligations contractuelles : Les contrats avec des OEM ou des entités gouvernementales imposent souvent des normes ou des contrôles nommément désignés (par exemple, un chiffrement spécifique, des modèles de contrôle d’accès ou une journalisation). L’acceptation du risque ne peut pas les supplanter.
    • Politiques internes : Les politiques d’entreprise en matière de sécurité de l’information et de sécurité peuvent définir des exigences non négociables (par exemple, l’authentification multifacteur pour l’accès distant aux réseaux OT).
    • Sécurité et intégrité du produit : Pour les systèmes liés à la qualité produit, à la sécurité des patients ou à la navigabilité, « accepter » des risques susceptibles de compromettre la traçabilité, les enregistrements qualité ou les fonctions de sécurité n’est généralement pas tolérable.

    Dans ces cas, vos options consistent généralement à corriger, reconcevoir ou, dans de rares cas, restreindre ou mettre hors service le processus ou le système concerné, plutôt qu’à accepter le risque.

    À quoi ressemble une décision conforme d’acceptation du risque

    Pour les risques qui peuvent légitimement être acceptés, vous devez pouvoir présenter les éléments suivants :

    • Description claire du risque : actif, menace, vulnérabilité, impact sur la confidentialité, l’intégrité et la disponibilité, ainsi que tout impact en aval sur la qualité, la sécurité ou les enregistrements réglementaires.
    • Niveau de risque mesuré : vraisemblance et impact évalués selon votre méthode définie, incluant une comparaison avec vos critères d’acceptation.
    • Contexte et contraintes : pourquoi un traitement supplémentaire n’est pas proportionné ou réalisable (par exemple, des équipements existants qui ne peuvent pas être corrigés sans requalification ou sans temps d’arrêt inacceptable).
    • Mesures compensatoires : toute atténuation partielle (segmentation réseau, contrôles procéduraux, surveillance renforcée, fenêtres d’utilisation restreintes).
    • Responsable du risque : un responsable nommé disposant de l’autorité appropriée (généralement au niveau de la direction métier ou de la direction de site, et pas seulement de l’IT).
    • Approbation formelle : validation documentée par la direction, souvent via le plan de traitement des risques et la Déclaration d’applicabilité.
    • Cadence de revue : une date ou un déclencheur défini pour réévaluer le risque (par exemple, le prochain cycle de revue du SMSI, une mise à niveau système, un renouvellement de contrat).

    Ce niveau de documentation est important lors des audits : vous ne démontrez pas une « absence de risque », vous démontrez une acceptation maîtrisée et motivée dans des limites définies.

    Réalités des environnements brownfield et de l’OT hérité

    Dans les environnements OT/IT mixtes, de nombreux sites font face à des risques liés aux équipements hérités et aux longs cycles de vie des actifs. Exemples fréquents :

    • Systèmes de contrôle-commande hérités qui ne peuvent pas recevoir de correctifs ni être mis à niveau sans revalidation ou recertification.
    • Serveurs critiques pour la production exécutant des systèmes d’exploitation non pris en charge, liés à des intégrations MES/QMS validées.
    • Équipements verrouillés par fournisseur, pour lesquels les options de configuration sécurisée sont limitées.

    Dans ces situations, ISO 27001 n’exige pas de tout remplacer immédiatement. Elle attend de vous que vous :

    • Identifiiez et évaluiez les risques de manière réaliste, en tenant compte de l’impact sur la production, la qualité et la sécurité.
    • Appliquiez des mesures de contrôle compensatoires réalisables (par exemple, segmentation, contrôle d’accès strict, maîtrise rigoureuse des changements, journalisation renforcée et procédures).
    • Preniez une décision documentée si le risque résiduel, au-delà de ces mesures de contrôle, subsiste et doit être accepté temporairement.
    • Reliiez l’acceptation du risque à une feuille de route (mises à niveau planifiées, remplacement de fournisseur ou évolutions d’architecture) plutôt que d’accepter le risque indéfiniment par défaut.

    Le remplacement complet de systèmes critiques uniquement pour combler une seule lacune de sécurité de l’information est souvent impraticable dans une fabrication fortement réglementée, en raison de la charge de requalification, du risque d’arrêt de production et de la complexité d’intégration. Une acceptation du risque compatible avec ISO 27001 peut combler cet écart, à condition que la décision soit explicite, justifiée et réexaminée périodiquement.

    Mesures de maîtrise opérationnelles autour des risques acceptés

    Si vous acceptez un risque, vous avez néanmoins besoin de garde-fous pour garder cette décision sous contrôle :

    • Maîtrise des changements : Toute modification du système, du réseau ou du processus concerné doit déclencher une nouvelle vérification du risque accepté et de ses hypothèses.
    • Surveillance et réponse aux incidents : Surveillance renforcée des actifs concernés, avec des procédures claires si des indicateurs de compromission ou des défaillances apparaissent.
    • Traçabilité : Relier le risque accepté aux processus, équipements et enregistrements impactés afin que les responsables qualité et opérations comprennent les effets potentiels.
    • Visibilité transverse : Impliquer les opérations, l’ingénierie, la qualité et l’IT dans les revues ; les risques de sécurité acceptés peuvent avoir des impacts en aval sur la qualité et la conformité.

    Ces pratiques ne font pas disparaître le risque ; elles réduisent l’effet de surprise et soutiennent des décisions défendables lors des audits et des revues internes.

    ISO 27001 et considérations d’audit

    Accepter des risques ne vous empêche pas d’être certifié ISO 27001, mais cela peut générer des constats d’audit si la démarche est mal gérée. Les problèmes d’audit typiques incluent :

    • Des critères d’acceptation des risques qui ne sont pas clairement définis ou qui ne sont pas approuvés au niveau approprié.
    • Des risques acceptés « implicitement » parce qu’aucune décision de traitement n’a été enregistrée.
    • Des risques acceptés qui contredisent des exigences légales, réglementaires ou contractuelles.
    • Des décisions relatives aux risques prises uniquement par l’IT, sans implication des propriétaires de processus ou des responsables qualité.
    • Des risques acceptés qui ne sont jamais réexaminés, même lorsque l’environnement évolue.

    Pour éviter cela, assurez-vous que l’acceptation des risques suit les procédures de votre SMSI, qu’elle est clairement traçable et qu’elle est visible dans les revues de direction.