Pilier Régulation

Régulation

Régulation est le pilier du contrôle : constater, qualifier, sanctionner, automatiser les barèmes, et collecter les déclarations périodiques.

Forfait : Professional et au-delà (infractions, sanctions, regulatory_rules, reporting). Le GRC (Enterprise / auto-régulateur) complète la conformité interne — voir GRC — sans remplacer ce pilier lorsqu’il s’agit de pouvoirs ou de discipline opérationnelle.

Ce que le pilier couvre

Capacité	Où ça vit	Notes
Infractions / constats	Admin → Régulation ; Collector ; parfois Public	Types + workflows de PV
Sanctions	Catalogue + mesures appliquées	Depuis infraction, plainte, ou voie directe
Règles métier	Moteur de règles versionné	Barèmes, enchaînements, seuils
Rapports réglementaires	Admin → Rapports ; Entity	Formulaires (même builder que Collect)
Lien plaintes	Menu Licences (module complaints)	Souvent amont d’un constat

Chaîne métier typique

Signalement / contrôle / plainte
        ↓
   Infraction (PV)
        ↓
   Sanction (catalogue)
        ↓
   Suivi d’exécution

En parallèle : campagnes de rapports (périodicité) → soumission Entity → revue admin → données Analytics.

Infractions

But : formaliser qu’un écart a été observé (terrain, dossier, signalement public).

Dans l’admin : types d’infraction, workflows (brouillon / simulation → validation → exécution selon votre config), file d’instruction.

Sources possibles : agent admin, Collector, portail public (si ouvert), suite d’une plainte.

Sanctions

But : appliquer une mesure cohérente avec votre catalogue (avertissement, amende, suspension, mesure corrective interne…).

Régulateur : exercice d’un pouvoir public.
Auto-régulateur : discipline de réseau / mesures internes — même moteur, autre lecture juridique.

Une sanction peut s’attacher à une infraction, à une plainte, ou être saisie selon vos droits.

Règles métier

But : éviter de tout traiter « à la main » : règles versionnées pour barèmes, seuils, enchaînements automatiques ou semi-automatiques.

Utile dès que le volume de constats / dossiers dépasse le traitement artisanal.

Rapports réglementaires

But : exiger des déclarations structurées (mensuelles, trimestrielles, ad hoc).

1. Admin crée un type + formulaire (form builder partagé).
2. Campagne / échéance ouverte.
3. Entity (ou collecte) soumet.
4. Revue admin ; données disponibles pour le pilotage.

Ce n’est pas le GRC : ici on parle de reporting opérationnel / réglementaire, pas du cycle ISO risques-audits (même si les deux coexistent chez un auto-régulateur).

Applications concernées

Interface	Rôle
Admin	Catalogues, instruction PV, sanctions, règles, revue des rapports
Entity	Soumettre rapports, répondre aux suites, voir impacts sur licences / obligations
Public	Signalement / plainte selon config
Collector	Constats terrain selon bootstrap

REGULATOR vs SELF_REGULATOR

Mode	Lecture Régulation
REGULATOR	Contrôle d’opérateurs externes, PV, sanctions publiques
SELF_REGULATOR	Contrôle interne du réseau, mesures correctives, reporting membres

Limites

• Indisponible sur Essential (hors plaintes seules).
• GRC ≠ ce pilier : Enterprise / auto-régulateur pour risques-audits-frameworks.
• Automatisation des règles : puissance réelle, mais à configurer — pas magique hors catalogue.

Suite

• Modules et interfaces
• Autorisations — amont licences / obligations
• Intelligence — exploiter les données de contrôle
• GRC et conformité interne
• Forfaits