ssi incendie : guide de conformité SSI en ERP (définition, catégories, zonage, obligations MS 53 à MS 69)

Un ssi incendie (Système de Sécurité Incendie) est l’ensemble coordonné de moyens qui détectent un départ de feu, déclenchent l’alarme et pilotent des équipements de mise en sécurité (désenfumage, portes coupe-feu, etc.) afin de protéger les personnes et faciliter l’intervention des secours. En ERP, il s’inscrit dans un cadre réglementaire précis et se conçoit comme un projet de conformité : objectifs de sécurité, catégorie, zonage, scénarios, essais, puis exploitation et maintenance.

Ce guide vise les exploitants, responsables sécurité, maîtres d’ouvrage et installateurs qui doivent structurer une mise en conformité : comprendre l’architecture SDI/SMSI, choisir une catégorie A à E, relier type d’alarme et exigences, et sécuriser la preuve documentaire (dossiers, registre de sécurité, vérifications).

Cartographier un SSI : finalités de mise en sécurité et périmètre (SSI vs SDI vs SMSI)

Un SSI se comprend en partant de sa finalité : mettre le bâtiment en sécurité selon des scénarios prédéfinis, à partir d’informations (détection/DM) et d’ordres (commande des DAS). Le SSI ne se limite pas à « l’alarme » : il englobe la détection, la gestion de l’alarme et la mise en sécurité.

Dans le vocabulaire des projets, la confusion la plus fréquente consiste à employer « SSI » pour désigner uniquement la détection ou uniquement la centrale. Or, le SSI regroupe classiquement deux sous-ensembles :

• SDI (Système de Détection Incendie) : il collecte l’information incendie (détecteurs automatiques, déclencheurs manuels, équipements de contrôle et de signalisation) et transmet l’état (alarme, défaut, dérangement) au système de mise en sécurité.
• SMSI (Système de Mise en Sécurité Incendie) : il exécute les scénarios de sécurité (évacuation, compartimentage, désenfumage…), en commandant les dispositifs actionnés de sécurité.

Au cœur du SMSI se trouve le CMSI (Centralisateur de Mise en Sécurité Incendie). C’est l’équipement qui interprète les informations (provenant du SDI ou d’entrées) et déclenche les commandes de mise en sécurité selon des logiques paramétrées (zones, temporisations, priorités).

Schéma logique (à lire comme un flux « information → décision → action ») :

Détection (DAI/DM) → SDI (qualification de l’alarme) → CMSI (décision/scénario) → SMSI (ordres) → DAS (désenfumage, portes, clapets, etc.) + UGA (diffusion de l’alarme).

Cette cartographie sert de base à la conformité : elle permet d’identifier les interfaces (désenfumage, portes, ascenseurs, contrôles d’accès) et d’éviter les « zones grises » entre lots techniques, souvent à l’origine de réserves à la réception.

Architecture et composants indispensables : CMSI, UGA, DAI, déclencheurs manuels, DAS (désenfumage, compartimentage, portes, etc.)

Un SSI conforme est une architecture : des capteurs, une logique de traitement, des moyens d’alarme et des actionneurs de sécurité. L’objectif n’est pas d’empiler des équipements, mais d’assurer une chaîne robuste et testable, avec des états de surveillance (défaut/alarme) exploitables.

Les briques « information » : DAI et déclencheurs manuels

Les DAI (détecteurs automatiques d’incendie) déclenchent une alarme sur critères physiques (fumée, chaleur, flamme selon technologie). Ils réduisent le temps de détection, mais imposent un travail de conception pour limiter les alarmes intempestives (environnement poussiéreux, vapeur, contraintes d’exploitation).

Les DM (déclencheurs manuels) permettent une mise en alarme par l’humain. Leur implantation relève d’un raisonnement « parcours d’évacuation », accessibilité et visibilité, en cohérence avec les circulations et les zones.

La brique « décision et commande » : CMSI

Le CMSI centralise et exécute les scénarios de mise en sécurité. Concrètement, il gère : la logique de zone (quelle alarme déclenche quoi), les temporisations (pré-alarme/alarme générale selon cas), les priorités (ce qui doit agir immédiatement), et la surveillance des lignes/équipements pour détecter les défauts.

La brique « alarme » : UGA et équipements de diffusion

L’UGA (Unité de Gestion d’Alarme) pilote la diffusion de l’alarme (diffuseurs sonores, messages vocaux selon configuration). Elle s’inscrit dans la stratégie d’évacuation : alarme générale, sélective par zone, ou organisation adaptée à l’exploitation (ex. établissement avec personnels formés).

Les brique « action » : DAS et exemples d’équipements asservis

Les DAS (Dispositifs Actionnés de Sécurité) sont les organes qui changent d’état pour mettre le bâtiment en sécurité. Selon les cas, le SSI peut commander ou asservir :

• Désenfumage : ouvrants, exutoires, volets, commandes de DENFC, mise en route de ventilateurs, selon conception.
• Compartimentage : fermeture de portes coupe-feu, clapets coupe-feu, verrouillages électromagnétiques.
• Évacuation : déverrouillage de sorties, gestion de portes contrôlées, mise en sécurité de certains accès.
• Autres interfaces : arrêt technique de certains équipements (ex. ventilation/confort) si prévu, renvoi d’information vers une supervision, etc.

Point de vigilance : un DAS n’est pas « juste » un équipement à raccorder. Il implique une cohérence de priorités de commande, une preuve d’essais, et une gestion des défauts (détection de rupture, position, alimentation) selon le niveau attendu. Les interfaces entre le lot SSI et le lot CVC/désenfumage/portes sont une source classique de non-conformités, faute de responsabilités clairement écrites.

Catégories de SSI (A à E) : logique de classement, ce que chaque catégorie embarque vraiment, limites d’usage

Les catégories A à E structurent le niveau d’intégration du SSI : elles décrivent la présence et l’association des fonctions de détection, d’alarme et de mise en sécurité, ainsi que l’organisation des équipements (notamment autour du CMSI). Le choix ne se fait pas « à l’habitude » : il découle des objectifs de sécurité, de la typologie de l’ERP, de son exploitation et des scénarios attendus.

Sur le terrain, deux erreurs reviennent : (1) confondre catégorie de SSI et type d’alarme (ce sont deux notions distinctes) ; (2) sous-estimer l’impact du désenfumage/compartimentage sur la catégorie et sur le travail de conception (zonage, asservissements, essais).

La bonne approche consiste à partir des fonctions indispensables (évacuation, désenfumage, compartimentage, gestion des interfaces), puis à vérifier que la catégorie retenue permet de les réaliser avec le niveau d’intégration et de contrôle attendu. En ERP, cette décision s’ancre dans les exigences de sécurité incendie et dans le dialogue avec la maîtrise d’œuvre et les organismes de contrôle, sans se substituer aux textes.

Zonage et scénarios de mise en sécurité : ZDA/ZA/ZC, asservissements, temporisations, niveaux d’alarme (type 1/2a/2b/3/4)

Le zonage et les scénarios traduisent la stratégie de sécurité en logique exécutable : quelle information déclenche quelle action, sur quelle zone et à quel moment. C’est le cœur « opérationnel » d’un SSI, et la principale source d’écarts entre une installation qui fonctionne et une installation qui passe les essais.

Les zones : ZDA, ZA, ZC (logique fonctionnelle)

Sans figer un modèle unique, la pratique distingue généralement :

ZDA (Zone de Détection Automatique) : regroupement de détecteurs automatiques cohérents (ex. un niveau, un compartiment, une zone à risque). L’objectif est de localiser rapidement l’alarme et de piloter des actions pertinentes.

ZA (Zone d’Alarme) : périmètre dans lequel l’alarme est diffusée (sirènes/BAAS/sonorisation selon conception). Une ZA peut correspondre à l’ensemble de l’établissement ou à des sous-zones si une évacuation sélective est prévue.

ZC (Zone de Compartimentage) : périmètre sur lequel des actions de compartimentage sont appliquées (fermeture de portes/clapets) pour limiter la propagation des fumées et du feu.

Un zonage cohérent évite deux dérives : des zones trop grandes (perte d’information et actions disproportionnées) ou trop petites (complexité, maintenance difficile, risques de paramétrage). Le zonage doit rester compréhensible pour l’exploitation, car il conditionne les procédures internes et la lecture des événements.

Scénarios et asservissements : exemples concrets

Un scénario de mise en sécurité décrit un enchaînement d’actions (souvent simultanées) déclenchées par une condition (alarme en ZDA X, action manuelle, défaut critique…). Exemples typiques :

• Évacuation : diffusion d’alarme en ZA, déverrouillage de certaines issues, mise en sécurité d’accès contrôlés.
• Désenfumage : ouverture d’exutoires/ouvrants et/ou mise en route d’extraction, fermeture de volets non concernés, selon la stratégie retenue.
• Compartimentage : fermeture de portes coupe-feu et clapets coupe-feu en ZC, afin de contenir fumées et chaleur.

La difficulté n’est pas de « commander un contact », mais de gérer les états : confirmation de position, défaut de ligne, alimentation, et priorités entre ordres (par exemple entre un ordre de confort et un ordre de sécurité). C’est ici que les interfaces multi-lots doivent être contractuellement et techniquement verrouillées.

Temporisations et niveaux d’alarme : lien avec les types 1/2a/2b/3/4

Les types d’alarme (1, 2a, 2b, 3, 4) décrivent des organisations d’équipements d’alarme (diffusion sonore, gestion, déclenchement) et sont souvent associés aux exigences de certains ERP. Ils ne se confondent pas avec la catégorie A à E, qui qualifie l’ensemble SSI (détection + mise en sécurité + alarme et leur intégration).

En pratique, un projet peut devoir articuler : (1) une catégorie de SSI (architecture globale), et (2) un type d’alarme (modalités de diffusion et de gestion de l’alarme). Les temporisations (pré-alarme, délai d’évacuation, déclenchement de certains DAS) se définissent alors en cohérence avec l’exploitation, le public, les consignes et les exigences applicables.

« Un SSI efficace n’est pas celui qui déclenche le plus d’équipements, mais celui dont les scénarios sont compréhensibles, vérifiables et maintenables, avec une traçabilité d’essais à chaque étape du cycle de vie. »

Cadre normatif & obligations : ERP (articles MS 53 à MS 69), dossiers à produire, vérifications/essais, registre de sécurité

En ERP, la conformité SSI s’appuie sur le cadre de sécurité incendie et, pour le SSI, sur les dispositions connues des articles MS 53 à MS 69. L’enjeu opérationnel est double : concevoir selon les exigences et pouvoir le prouver (dossiers, essais, registre de sécurité).

Sans paraphraser les textes, ces articles encadrent notamment : l’organisation du SSI, ses constituants, les conditions de mise en œuvre et d’exploitation, ainsi que les principes de vérification et de maintenance. Ils s’articulent avec les normes et règles de l’art applicables aux équipements et à leur installation, et avec les prescriptions propres au type et à la catégorie d’ERP.

Les livrables attendus : ce qui doit exister pour être « exploitable et contrôlable »

Un SSI se défend par un dossier clair. À minima, le projet doit produire des éléments permettant de comprendre et de vérifier :

• La prescription fonctionnelle : objectifs de mise en sécurité, scénarios, zones (ZDA/ZA/ZC), interfaces (désenfumage, portes, etc.).
• Les plans et schémas : implantation, synoptiques, repérage des zones, tableaux d’asservissements.
• Les notices et documents constructeurs : caractéristiques des équipements, conditions d’installation, maintenance.
• Les PV d’essais et de mise en service : résultats, écarts, réserves levées.

Ces pièces alimentent le registre de sécurité : c’est l’outil de traçabilité de l’exploitation (événements, contrôles, essais périodiques, interventions). Un registre incomplet n’est pas un détail administratif : il fragilise la démonstration de conformité lors des contrôles et augmente le risque de dérives en exploitation.

Vérifications et essais : logique de conformité et de maintien en condition

Les essais ne se limitent pas à « faire sonner les sirènes ». La logique attendue couvre : la détection (DAI/DM), la transmission d’information, la commande des DAS, la gestion des défauts, et la cohérence de l’ensemble par scénarios (y compris les temporisations et les priorités). En exploitation, des essais périodiques et des interventions de maintenance contribuent au maintien en condition opérationnelle.

Point clé : chaque modification (extension, réaménagement, changement d’usage, remplacement d’équipement, ajout d’un DAS) doit être traitée comme un mini-projet SSI, avec mise à jour du dossier et revalidation des scénarios impactés. C’est une cause fréquente de non-conformité « progressive » : un SSI conforme à la réception peut devenir incohérent après quelques travaux.

Piloter un projet SSI : prescription, choix des acteurs (MOE/installeur/mainteneur), réception & maintenance, coûts/risques et erreurs à éviter

Un projet SSI réussi se pilote comme une chaîne de responsabilités : une prescription claire, une exécution maîtrisée, puis une exploitation outillée (registre, essais, maintenance). La technique ne compense pas un cadrage flou : en SSI, le risque principal vient des interfaces et des scénarios implicites.

Méthode projet : de la prescription à la réception

1) Prescription fonctionnelle : définir les objectifs (évacuation, désenfumage, compartimentage), les zones (ZDA/ZA/ZC), les scénarios et les interfaces. C’est aussi l’étape où l’on fixe les exigences de tests et de livrables.

2) Conception et coordination : assurer la cohérence inter-lots (désenfumage, portes, contrôle d’accès, ascenseurs le cas échéant), et préparer les essais en identifiant les prérequis (alimentation, retours d’état, accessibilité des organes).

3) Installation & paramétrage : pose, adressage/repérage, paramétrage des scénarios dans le CMSI, mise au propre des plans de récolement.

4) Mise en service, essais, réception : exécuter des essais par scénarios et par zones, documenter les résultats et lever les réserves. L’objectif est d’obtenir un système compréhensible (pour l’exploitant) et testable (pour les vérifications).

Checklist de conformité (réception et exploitation)

Cette checklist résume les points qui évitent le plus d’écarts lors des contrôles et en exploitation :

• Zonage : ZDA/ZA/ZC cohérents, repérage identique entre plans, centrale et terrain.
• Tableaux d’asservissements : chaque DAI/DM → scénario → DAS est tracé, avec priorités et temporisations.
• Essais : PV d’essais par scénarios (pas uniquement par point), incluant défauts et pertes d’alimentation simulées si applicable.
• Interfaces : responsabilités écrites entre lots, retours d’état disponibles et testés, asservissements non ambigus.
• Registre de sécurité : documents à jour, maintenance planifiée, historique des interventions et modifications.

Coûts et délais : repères prudents et facteurs de variation

Le coût d’un SSI varie fortement selon la surface, le type d’ERP, la densité de détection, le nombre de zones, la quantité de DAS et la complexité des interfaces. À titre indicatif, un projet « simple » peut se chiffrer en quelques milliers d’euros, tandis qu’un SSI avec désenfumage/compartimentage multi-zones et intégration poussée peut atteindre plusieurs dizaines de milliers d’euros, voire davantage sur des sites complexes.

Les délais dépendent moins du matériel que de la coordination : disponibilité des locaux, accès, phasage d’exploitation, mises au point inter-lots, et temps d’essais. Une stratégie efficace consiste à « acheter » du temps de conception (scénarios, interfaces) pour éviter des semaines de reprises en fin de chantier.

Erreurs fréquentes à éviter

À éviter : choisir une catégorie « par habitude » sans formaliser les scénarios ; sous-estimer le lot désenfumage et ses retours d’état ; réaliser des modifications sans mise à jour du dossier et sans revalidation ; livrer un système sans nomenclature claire des zones ; confondre type d’alarme et catégorie SSI.

À vérifier : cohérence des alimentations secourues, accessibilité des organes de manœuvre, lisibilité de l’affichage des défauts, formation minimale des équipes d’exploitation, et capacité du mainteneur à produire des comptes-rendus exploitables.

Derniers repères pour décider : la conformité SSI dans la durée

La conformité d’un SSI se gagne à la réception, mais se conserve par la discipline d’exploitation : registre tenu, essais périodiques, maintenance adaptée, et traitement rigoureux de chaque modification. Un SSI « figé » sur plans n’existe pas : le bâtiment vit, et le système doit rester cohérent avec les usages.

Pour décider rapidement, la question utile n’est pas seulement « quelle catégorie ? », mais : quels scénarios de mise en sécurité sont réellement nécessaires, quelles interfaces doivent être asservies, et comment prouver, dans le registre de sécurité, que le système est testé et maintenu conformément aux exigences ERP (MS 53 à MS 69). C’est cette traçabilité qui sécurise l’exploitant, autant que la technique.

FAQ

Quelle différence entre SSI, SDI, SMSI et CMSI ?

Le SSI est l’ensemble du dispositif de sécurité incendie automatisé : détection, alarme et mise en sécurité. Le SDI correspond à la partie « information » (détecteurs/DM et équipements associés). Le SMSI correspond à la partie « action » (mise en sécurité). Le CMSI est le centralisateur qui exécute les scénarios de mise en sécurité.

Comment déterminer la catégorie de SSI (A, B, C, D, E) pour mon établissement ?

La catégorie se déduit des objectifs de mise en sécurité (évacuation, désenfumage, compartimentage), de la présence/étendue de la détection, du besoin d’intégration via CMSI et de la complexité des scénarios/zones. En ERP, la décision s’inscrit dans le cadre des exigences applicables (MS 53 à MS 69) et doit être formalisée dans la prescription et le dossier de sécurité.

Qu’est-ce qu’un DAS et quels équipements peuvent être asservis par le SSI ?

Un DAS est un dispositif actionné pour mettre le bâtiment en sécurité (ouverture/fermeture, arrêt/commande). Il peut s’agir d’ouvrants et volets de désenfumage, de portes coupe-feu, de clapets coupe-feu, ou de dispositifs de déverrouillage liés à l’évacuation, selon la conception et les scénarios retenus.

Quelle réglementation encadre les SSI en ERP (MS 53 à MS 69) et que faut-il fournir au registre de sécurité ?

En ERP, les exigences relatives au SSI sont notamment cadrées par les articles MS 53 à MS 69, qui structurent l’organisation du SSI, ses constituants et ses conditions de vérification/exploitation. Le registre de sécurité doit permettre de prouver la conformité dans la durée : dossier à jour (plans/synoptiques, zonage, asservissements), comptes-rendus de maintenance, PV d’essais et historique des modifications.

Quels essais et vérifications sont obligatoires lors de la mise en service et en exploitation d’un SSI ?

La logique attendue couvre la vérification du fonctionnement par scénarios : déclenchement via DAI/DM, diffusion d’alarme, commandes des DAS (désenfumage, compartimentage), gestion des défauts et cohérence des temporisations/priorités. En exploitation, des essais périodiques et la maintenance assurent le maintien en condition, avec traçabilité au registre de sécurité.

Alarme type 1, 2a, 2b, 3, 4 : quel lien avec le SSI et quand les utiliser ?

Le type d’alarme décrit la configuration des équipements d’alarme (diffusion/gestion) ; la catégorie de SSI décrit l’architecture globale (détection + mise en sécurité + alarme et intégration). Un établissement peut être tenu à un type d’alarme donné tout en relevant d’une catégorie SSI définie par les scénarios et le niveau d’intégration requis. Le choix se fait en cohérence avec l’ERP, l’exploitation et les objectifs de mise en sécurité.