Politique de Gouvernance et de Souveraineté Énergétique

KOURANM — Système intelligent de gestion énergétique

Version 1.0 — Effective au 2026-05-16 Domaine d'application : ensemble des sites équipés du contrôleur KOURANM Document de référence pour les contrats clients, audits réglementaires et engagements opérationnels.

1. Préambule

KOURANM conçoit et exploite une plateforme logicielle et matérielle de gestion énergétique destinée aux PME et résidences en Haïti. Notre activité touche directement à l'infrastructure critique de nos clients : alimentation des bâtiments, équipements médicaux, climatisation, éclairage de sécurité.

Toute manipulation à distance d'une charge électrique (relais, disjoncteur, inverter) a un impact dans le monde physique réel. Cette politique formalise les engagements de KOURANM pour que cette responsabilité soit exercée avec la rigueur attendue d'un opérateur d'infrastructure énergétique.

Elle s'aligne sur les standards internationaux suivants :

2. Les Trois Piliers de la Souveraineté Client

🛡️ Pilier 1 — Souveraineté du Client

Le contrôle final des charges électriques d'un site appartient exclusivement à son propriétaire ou à ses délégataires explicites.

KOURANM développe des algorithmes d'optimisation et d'intelligence artificielle (prédiction de consommation, détection d'anomalies, délestage automatique sur SOC critique). Ces algorithmes opèrent uniquement dans le cadre que le client a configuré et activé lui-même via son tableau de bord.

Un employé de KOURANM, quel que soit son niveau de privilège (superadmin global compris), ne peut pas modifier unilatéralement la configuration de distribution électrique d'un client à distance.

🚫 Pilier 2 — Zéro Interférence Arbitraire

Aucun accès opérationnel d'un employé KOURANM à un site client n'est implicite ou permanent.

Toute action sur l'infrastructure d'un client s'inscrit dans une de ces quatre catégories, traitées différemment :

🔒 Pilier 3 — Traçabilité Immuable

Chaque action sur l'infrastructure d'un client est enregistrée dans un journal d'audit append-only, attribuable à un être humain identifié, et conservé.

KOURANM s'engage à :

• Non-répudiation : chaque action de mutation est attribuée à l'user_id de la personne physique qui a cliqué, jamais au user_id d'un client si c'est un employé KOURANM qui agit (pas d'impersonation opaque).
• Append-only : la table audit_logs est protégée par Row-Level Security PostgreSQL pour interdire UPDATE et DELETE — toute correction passe par une nouvelle ligne avec action: "correction_of:{previous_id}".
• Métadonnées contextuelles : pour chaque action sur un site, le journal contient l'horodatage UTC, l'adresse IP, le user-agent, l'identifiant de site, l'action, la ressource cible et, le cas échéant, la raison textuelle fournie.
• Conservation : les journaux d'audit sont conservés au minimum 7 ans après cessation de la relation contractuelle, conformément aux pratiques de l'audit comptable et de la responsabilité civile.

3. Procédures opérationnelles par catégorie d'action

Catégorie A — Diagnostic en lecture

Périmètre : visualisation des graphiques de consommation, de l'état des appareils, des alertes générées par l'IA, des journaux historiques.

Procédure : un opérateur support KOURANM (rôle admin ou technicien global) accède au tableau de bord en mode Support Lecture. Aucune mutation possible. L'accès est tracé sans déclencher d'alerte client (consultation routinière).

Justification : pour résoudre un ticket d'assistance, le support doit pouvoir reproduire la situation du client. La lecture seule n'altère pas l'installation.

Catégorie B — Configuration matérielle

Périmètre : champs marqués "Admin / Technicien" dans /dashboard/settings (profil batterie, profil solaire, paramètres MQTT QoS et rétention, identifiant système).

Procédure : un technicien certifié KOURANM modifie la configuration pendant ou après une installation/maintenance physique. La modification :

1. Exige un rôle superadmin, admin ou technicien sur le site (rôle attribué au moment de la souscription/intervention)
2. Est journalisée avec l'identifiant du technicien et la raison de la modification
3. Déclenche un email récapitulatif au propriétaire du site dans les 24 heures suivant la modification

Garantie technique actuelle : RBAC fin appliqué côté serveur (apps/backend/schemas/site_settings.py, fonction check_settings_permission). Les champs hors périmètre sont rejetés avec HTTP 403 sans modification de la base.

Catégorie C — Contrôle temps réel des charges

Périmètre : POST /loads/{id}/toggle, POST /loads/shed, modification du seuil de délestage automatique.

Procédure (engagement cible, voir section 8 pour le calendrier d'implémentation) :

1. Demande d'accès : l'opérateur KOURANM envoie une demande motivée via /support/request-access (référence ticket, durée souhaitée ≤ 2 heures, périmètre lecture vs écriture).
2. Consentement client : le propriétaire du site reçoit une notification (WhatsApp + email) et doit valider explicitement via un code à usage unique (OTP) ou un bouton dans son tableau de bord.
3. Session limitée : une fois la demande approuvée, une support_session est créée avec date d'expiration (≤ 2h). Au-delà, l'accès est révoqué automatiquement.
4. Notification permanente : chaque action de mutation pendant la session déclenche une notification WhatsApp/email au propriétaire en temps réel (« KOURANM Support vient de couper le climatiseur — raison : test thermique de la batterie »).
5. Rapport post-session : à la fin de la session, un rapport PDF cryptographiquement signé est envoyé au propriétaire, listant toutes les actions effectuées.

Garantie technique actuelle : la non-répudiation est déjà en place — l'audit_logs.user_id reflète l'identifiant de l'employé KOURANM, jamais celui du client. La couche consentement/session/notification temps réel sera livrée d'ici la fin du Sprint Support Mode.

Catégorie D — Suspension de service commercial

Périmètre : suspension du dashboard et des automatisations IA pour cause d'impayé ou de violation des conditions contractuelles. N'inclut jamais la coupure physique de l'électricité (qui reste sous le contrôle du client et de son installation).

Procédure :

1. Préavis écrit (email + WhatsApp + notification dashboard) au minimum 7 jours avant l'effet
2. Possibilité de régler la situation pendant le préavis sans dégradation de service
3. À l'effet : passage du compte en mode lecture seule, conservation intégrale des données pour réactivation
4. Action exécutée par un superadmin global, journalisée avec référence de facture ou clause contractuelle invoquée

Garantie technique actuelle : workflow opéré manuellement aujourd'hui. Automatisation prévue dans le module billing Celery (tasks/billing.py:check_expired_subscriptions).

4. Architecture de souveraineté technique

KOURANM applique la philosophie "Defense in Depth + Local Override Always Wins", conforme à IEC 62443 et à la pratique des opérateurs SCADA matures.

4.1 — Zones de confiance

┌─ Zone 4 : Internet public ─────────────────────────────────────────┐
│   Tableau de bord client (kouranm.com) — utilisateurs finaux       │
│   Dashboard support (kouranm.com/dashboard) — employés KOURANM     │
└────────────────────────────┬───────────────────────────────────────┘
                             │ HTTPS TLS 1.3 + JWT ES256
                             ▼
┌─ Zone 3 : API de contrôle (api.kouranm.com) ───────────────────────┐
│   FastAPI + RBAC + Rate limiting + RLS PostgreSQL                  │
│   Validateurs Pydantic stricts (XSS, Flux injection bloqués)       │
└────────────────────────────┬───────────────────────────────────────┘
                             │ MQTT TLS 8883
                             ▼
┌─ Zone 2 : Broker MQTT (HiveMQ Cloud) ──────────────────────────────┐
│   Topics nominatifs : kouranm/box/{hardware_id}/...                │
│   Authentification username/password + certificats X.509           │
└────────────────────────────┬───────────────────────────────────────┘
                             │
                             ▼
┌─ Zone 1 : Contrôleur ESP32-S3 (firmware KOURANM) ──────────────────┐
│   Validation locale des commandes contre safety rules              │
│   Override physique inconditionnel via commutateur de façade       │
│   Refus de toute commande qui violerait l'intégrité du système     │
└────────────────────────────┬───────────────────────────────────────┘
                             │
                             ▼
                       Charges physiques

Chaque zone applique son propre contrôle. La compromission d'une zone supérieure ne permet pas de bypasser la zone inférieure.

4.2 — Principe d'override local

Engagement KOURANM : le commutateur physique de bypass présent sur chaque contrôleur ESP32-S3 court-circuite tout signal cloud. Lorsque l'opérateur sur place active le bypass :

1. Le firmware publie kouranm/box/{id}/override_active (retenu) sur le broker MQTT
2. Le firmware ignore toutes les commandes entrantes sur kouranm/box/{id}/command jusqu'au reset
3. Le tableau de bord client et le tableau de bord support affichent un bandeau rouge "MODE LOCAL ACTIF — Cloud désactivé par l'opérateur sur place"

Cette garantie protège le client contre :

• Un compromis de compte support KOURANM
• Une attaque par compromission de la chaîne d'approvisionnement
• Une défaillance des algorithmes IA
• Une erreur humaine côté KOURANM

Calendrier d'implémentation : intégré dans la roadmap du firmware (iot/firmware/).

4.3 — Validation locale par safety rules

Le firmware refuse d'exécuter une commande cloud si elle viole l'une des règles de sécurité suivantes :

• Activation d'une charge alors que SOC batterie < 5 %
• Activation d'une charge qui dépasserait la capacité de l'onduleur (somme des puissances > 110 % de la capacité nominale)
• Activation simultanée de charges incompatibles déclarées par le client (ex : pompe + climatiseur sur même phase)

Toute commande refusée est journalisée et notifiée au cloud via kouranm/box/{id}/command_rejected.

5. Gouvernance interne et accès aux comptes administrateur

5.1 — Attribution du rôle administrateur global

Le rôle superadmin global (accès théorique à tous les sites de la plateforme) est attribué :

• Aux fondateurs / dirigeants de KOURANM
• Aux ingénieurs de niveau senior chargés de la maintenance plateforme
• Sur demande nominative écrite et validation interne

Chaque attribution est journalisée dans audit_logs avec l'identité de l'attributaire et du bénéficiaire.

5.2 — Révocation

Le rôle est révoqué automatiquement :

• À la fin du contrat de travail / de prestation
• Après 90 jours sans connexion
• Sur demande de tout dirigeant KOURANM ou en cas d'incident de sécurité

5.3 — Authentification renforcée (engagement à venir)

Les comptes administrateur de KOURANM passeront au 2FA obligatoire (authentification à deux facteurs) avant la mise en production grand public. Calendrier dans la roadmap Phase 7 Sécurité.

5.4 — Séparation des privilèges

KOURANM applique la séparation des privilèges suivants :

Ces rôles sont implémentés côté serveur par la fonction core.rbac.verify_site_permission et la fonction core.rbac.get_user_role_on_site. Toute mutation est rejetée si l'appelant n'a pas le rôle attendu.

6. Engagement de transparence vis-à-vis du client

6.1 — Notifications proactives

KOURANM s'engage à notifier le propriétaire d'un site dans les cas suivants, sans qu'il ait besoin de demander :

6.2 — Accès aux journaux d'audit

Tout propriétaire de site peut consulter les actions effectuées par KOURANM sur son site via la page /dashboard/security/audit-logs (en cours de finalisation). Export CSV / PDF possible pour archivage personnel.

6.3 — Délégation de l'accès support par le client

Le propriétaire d'un site peut, à tout moment, interdire l'accès support KOURANM à son site (à l'exception des actions critiques de sécurité). Le paramètre support_access_enabled (à venir) permet ce contrôle granulaire.

7. Conformité et réglementation

7.1 — Localisation des données

7.2 — Données personnelles

KOURANM collecte le minimum nécessaire à la prestation : email, nom, téléphone (optionnel), adresse de site, données de consommation énergétique. Aucune donnée biométrique, aucun profil comportemental hors énergie, aucune revente à des tiers.

Les droits du client conformes au RGPD européen (consultation, rectification, portabilité, oubli) sont exerçables par email à privacy@kouranm.com avec un délai de réponse maximal de 30 jours.

7.3 — Sécurité technique

Les contrôles de sécurité techniques en place sont documentés dans apps/frontend/web/README.md (section "Sécurité — headers HTTP") et dans le bilan d'audit interne :

• TLS 1.3 obligatoire sur toutes les communications externes
• HSTS sur kouranm.com (2 ans + includeSubDomains + preload)
• Content Security Policy stricte (frame-ancestors 'none')
• Validation d'entrée Pydantic v2 sur toutes les API
• Row-Level Security PostgreSQL sur les tables sensibles
• Rate limiting (100 req/min/IP)
• CI/CD avec lint et tests à chaque PR/push (filet anti-régression)
• Audit logs append-only

7.4 — Conformité contractuelle

Le contenu de cette politique est repris dans les Conditions Générales d'Utilisation (/terms) et la Politique de Confidentialité (/privacy) publiques. Une violation grave et démontrée de cette politique par KOURANM ouvre droit à dédommagement selon les clauses contractuelles.

8. Calendrier d'implémentation des engagements

Cette politique reflète à la fois ce qui est déjà en place et ce qui constitue un engagement à livrer. Tableau de transparence :

🟢 État Livré : engagement vérifiable dans le code et activé en production aujourd'hui. 🟡 État Engagement : conception validée, calendrier engageant, vérifiable par le client à l'échéance.

KOURANM s'engage à publier mensuellement un état d'avancement de ces engagements sur cette page.

9. Procédure de signalement d'incident

Tout client, partenaire, employé ou tiers ayant connaissance d'une violation de cette politique peut signaler l'incident à :

• Email confidentiel : security@kouranm.com
• Téléphone : +509 3742 8962 (heures ouvrables Port-au-Prince)
• Courrier : Delmas 33, Rue Clermont, Port-au-Prince, Haïti

KOURANM s'engage à un accusé de réception sous 48 heures et à une réponse circonstanciée sous 30 jours. Les signalements de bonne foi sont protégés contre toute représaille.

10. Évolution de cette politique

Cette politique est révisée au minimum tous les 12 mois, et chaque fois qu'un changement significatif d'architecture, de régulation applicable, ou d'incident le justifie. Toute évolution donne lieu à :

1. Publication du nouveau texte sur cette page avec numéro de version incrémenté
2. Notification email aux propriétaires de sites au moins 30 jours avant l'entrée en vigueur
3. Archivage de la version précédente dans l'historique Git du dépôt KOURANM (auditable)

Document validé par : Direction Technique KOURANM Prochaine révision prévue : 2027-05-16 Référent interne : ingénieur sécurité KOURANM (security@kouranm.com) Référent client : support KOURANM (support@kouranm.com)