Vous avez décidé d’équiper votre établissement d’un logiciel de conformité. Avant de consulter des solutions, il faut écrire un cahier des charges : sans lui, chaque démonstration impose son propre vocabulaire et son propre périmètre, et la comparaison devient impossible. Cet article propose une trame de critères prête à l’emploi, organisée en cinq rubriques, pour cadrer le besoin réel d’un exploitant d’établissement recevant du public. Il prolonge notre guide sur la façon de bien choisir un logiciel de conformité réglementaire ERP : ici, on passe du raisonnement à la trame que vous pouvez reprendre.

Pourquoi rédiger un cahier des charges avant de consulter

La conformité d’un ERP est une obligation de preuve, pas une simple gestion technique. Il faut pouvoir démontrer, date par date et document à l’appui, que les vérifications obligatoires ont été réalisées par les bons intervenants et que les observations ont été levées. Un cahier des charges force à partir de ce besoin de preuve, puis à le décliner en exigences vérifiables, au lieu de comparer des listes de fonctionnalités hétérogènes.

Il a aussi une vertu pratique : il devient votre grille de lecture commune. Chaque solution consultée se voit appliquer les mêmes critères, dans le même ordre, avec la même exigence de réponse. Une réponse “c’est paramétrable” ne vaut pas une réponse “c’est intégré en natif”, et le cahier des charges rend cette différence visible.

1. Exigences réglementaires : le socle non négociable

C’est la première rubrique, et la plus structurante. Deux textes cadrent le sujet. L’article R. 143-38 du Code de la construction et de l’habitation impose de maintenir installations et équipements conformes au règlement de sécurité contre l’incendie (arrêté du 25 juin 1980 modifié). L’article R. 143-44 prévoit le registre de sécurité qui en apporte la preuve.

Votre cahier des charges doit donc exiger, sans concession :

  • un registre de sécurité au sens de l’article R. 143-44, consultable en l’état lors d’une visite de commission de sécurité, y compris au format dématérialisé (voir notre guide du registre de sécurité dématérialisé) ;
  • le suivi des périodicités de vérification propres à chaque équipement (installations électriques, SSI, désenfumage, extincteurs, gaz, ascenseurs), calées sur le type et la catégorie de l’établissement, comme détaillé dans notre guide des contrôles réglementaires ERP et de leurs échéances ;
  • la traçabilité de la levée des réserves issues des rapports de vérification et des procès-verbaux de commission, avec dates, responsables et preuves ;
  • l’articulation avec le DUERP, obligation distincte du Code du travail qui coexiste avec le registre sans s’y substituer (voir DUERP et registre de sécurité : ne pas confondre).

Pour chacun de ces points, la bonne exigence n’est pas “l’outil permet de”, mais “l’outil intègre la réglementation applicable et la met à jour”, afin que ce ne soit pas à vous de paramétrer chaque fréquence.

2. Exigences fonctionnelles

Une fois le socle réglementaire posé, décrivez les fonctions attendues au quotidien :

  • un échéancier qui anticipe les vérifications à venir au lieu de les découvrir en retard, avec alertes et vue par équipement ;
  • une gestion documentaire centralisant rapports d’organismes, procès-verbaux et attestations, rattachés au bon équipement et au bon site ;
  • un suivi des réserves comme objets à part entière, du signalement à la levée documentée ;
  • la préparation d’une visite de commission : pouvoir générer, à la demande, l’état de conformité attendu (cette exigence rejoint notre article sur la manière de préparer une commission de sécurité et d’éviter les réserves) ;
  • la consolidation multi-sites : une vue par établissement et une vue de parc, avec le même niveau de preuve partout.

3. Exigences techniques et souveraineté des données

Les données de conformité d’un ERP sont sensibles : elles décrivent la sécurité et l’exploitation de vos établissements. Inscrivez au cahier des charges :

  • un hébergement souverain en France, conforme au RGPD, sans transfert des données hors Union européenne ;
  • des garanties de disponibilité, de sauvegarde et de continuité de service ;
  • la réversibilité : la capacité d’exporter l’intégralité de vos données et documents en cas de changement de solution, dans un format exploitable ;
  • une gestion fine des droits et des accès par site et par profil (exploitant, gestionnaire de parc, prestataire).

La souveraineté n’est pas un argument technique décoratif : elle protège la continuité de votre conformité et évite une dépendance à un prestataire hors de portée juridique.

4. Automatisation et intelligence artificielle

C’est la rubrique qui distingue une solution de nouvelle génération d’un simple registre numérique. Un rapport de vérification comporte des dizaines d’informations à reporter : équipements, dates, observations, échéances suivantes. Le faire à la main est chronophage et propice aux oublis.

Exigez donc une extraction automatique des données des rapports par IA : l’outil lit le rapport d’un organisme, en déduit les échéances et les observations, et met le registre à jour sans ressaisie. Cette capacité fiabilise les dates et transforme une charge de saisie en simple validation. Notre page sur la GMAO augmentée par l’IA et notre présentation de l’autopilote de conformité détaillent ce fonctionnement.

Au delà de l’extraction, précisez le comportement attendu de l’automatisation : solliciter le bon interlocuteur au bon moment, signaler ce qui approche de l’échéance, et rendre visible ce qui reste à traiter, plutôt qu’attendre une action manuelle.

5. Déploiement, reprise de l’historique et support

Le meilleur outil échoue s’il ne se met pas en service proprement. Ajoutez une rubrique de mise en oeuvre :

  • la reprise de l’historique : la capacité à intégrer vos registres et rapports existants, idéalement en s’appuyant sur l’extraction automatique pour éviter une ressaisie massive du papier ;
  • le cadrage du déploiement multi-sites et la formation des équipes ;
  • les conditions de support : canal, horaires en jours ouvrés, délai de réponse, et niveau de disponibilité garanti.

Comparer les familles de solutions face à votre cahier des charges

Une fois la trame écrite, appliquez la à chaque famille d’outils, sans vous limiter à un nom : chacune répond à une intention différente.

  • Les GMAO industrielles généralistes excellent sur la maintenance des équipements, mais n’embarquent en général ni les périodicités réglementaires des ERP, ni le registre de sécurité au sens de l’article R. 143-44 : la conformité y reste un paramétrage manuel.
  • Les outils de facility management tertiaire pilotent bien les prestations et les espaces, mais visent la performance des bâtiments plus que la preuve réglementaire de sécurité incendie.
  • Les outils légers polyvalents couvrent une partie du suivi, mais atteignent vite leurs limites sur le multi-sites et la profondeur réglementaire.
  • Les modules de conformité d’ERP de gestion ajoutent une brique à un outil de comptabilité ou de gestion, souvent générique et éloignée du règlement de sécurité.
  • Les solutions de conformité natives ERP partent au contraire des obligations des établissements recevant du public : registre, périodicités, réserves, DUERP et multi-sites sont intégrés, et la réglementation est maintenue dans le produit.

Aucune famille n’est disqualifiée par principe : le cahier des charges sert justement à mesurer, exigence par exigence, ce que chacune couvre en natif et ce qu’elle vous laisse à la charge.

La trame en une page

Pour reprendre l’essentiel dans votre document, cinq questions suffisent à trancher :

  • Les périodicités réglementaires sont-elles intégrées au produit selon le type et la catégorie de mes établissements, ou dois-je les paramétrer moi-même ?
  • L’outil produit-il un registre de sécurité au sens de l’article R. 143-44, consultable en l’état par une commission ?
  • Les observations et réserves sont-elles suivies avec dates, responsables et preuves de levée ?
  • Les données sont-elles hébergées en France, avec réversibilité garantie ?
  • L’outil extrait-il automatiquement les données des rapports par IA, ou faut-il tout ressaisir ?

L’essentiel à retenir

  • Un cahier des charges se rédige avant de consulter : il transforme le besoin de preuve d’un ERP en une grille de critères commune à toutes les solutions.
  • Cinq rubriques structurent la trame : exigences réglementaires, fonctionnelles, techniques et de souveraineté, automatisation par IA, déploiement et support.
  • La bonne exigence distingue toujours ce qui est intégré en natif de ce qui reste à paramétrer et à tracer à la main : c’est là que se joue la charge réelle, et le risque.

Daftar est une solution de conformité réglementaire native ERP : registre de sécurité dématérialisé, périodicités intégrées, extraction IA des rapports, consolidation multi-sites et hébergement souverain en France. Pour voir comment elle répond, rubrique par rubrique, à un cahier des charges de conformité, découvrez notre approche de la GMAO augmentée par l’IA ou demandez une démonstration.