Politique de Sécurité du Système d'Information (PSSI)

Ce document est élaboré en conformité avec la loi n°2017-20 du 20 avril 2018 portant Code du numérique en République du Bénin, le référentiel international ISO/IEC 27001:2022, les recommandations OWASP Top 10 2021 et le cadre de gouvernance COBIT 2019. Il complète la Politique de confidentialité, les Conditions Générales d'Utilisation et le Registre des traitements.

1. Préambule et objet

1.1 Contexte et enjeux

L'ADECOB gère, pour le compte des huit (8) communes du département du Borgou au Bénin et avec le soutien financier de la DDC Suisse (Direction du Développement et de la Coopération), une plateforme numérique centralisant 10 402 infrastructures communautaires géo-référencées : écoles, points d'eau, latrines, marchés et centres de santé. La criticité de ces données — indispensables à la planification du développement local et aux décisions d'investissement — impose un niveau de sécurité rigoureux.

La plateforme est une application web développée en Laravel 10, adossée à un SGBD MariaDB, hébergée en ligne et accessible depuis l'ensemble du territoire national et des partenaires internationaux. Elle traite des données à caractère personnel (identités, coordonnées des agents et administrateurs) ainsi que des données sensibles relatives aux plans de développement communaux.

1.2 Fondements juridiques

La PSSI repose notamment sur les textes et standards suivants :

• Loi n°2017-20 du 20 avril 2018 portant Code du numérique en République du Bénin — obligations de sécurité, notification des violations de données (art. 391), sanctions pénales (art. 549 et suivants) ;
• ISO/IEC 27001:2022 — Système de Management de la Sécurité de l'Information (SMSI) ;
• OWASP Top 10 2021 — classification des risques applicatifs les plus critiques et contre-mesures associées ;
• COBIT 2019 — cadre de gouvernance et de gestion du système d'information ;
• Politiques internes de l'ADECOB et exigences contractuelles de la DDC Suisse.

1.3 Objectifs de la PSSI

La PSSI vise à :

1. Définir les règles de sécurité applicables à l'ensemble du périmètre ;
2. Attribuer clairement les responsabilités en matière de sécurité ;
3. Réduire les risques d'intrusion, de fuite de données, d'indisponibilité et de corruption d'informations ;
4. Assurer la conformité légale et réglementaire ;
5. Garantir la continuité de service et la résilience du système ;
6. Fournir un cadre de réponse aux incidents de sécurité.

2. Périmètre d'application

2.1 Systèmes et composants couverts

La PSSI s'applique à l'intégralité du système d'information de la plateforme ADECOB, qui comprend :

2.2 Utilisateurs et parties prenantes couverts

La PSSI s'impose à :

• L'ensemble des utilisateurs authentifiés : super-administrateurs, administrateurs communaux, agents de mairie ;
• Les visiteurs publics pour ce qui concerne les usages des espaces en accès libre ;
• L'équipe ADECOB (direction, personnel technique, chargés de suivi) ;
• Les prestataires et partenaires tiers : hébergeur, prestataires de maintenance, intégrateurs, auditeurs ;
• La DDC Suisse et ses représentants dans le cadre de leurs droits d'accès aux données agrégées.

2.3 Exclusions

La PSSI ne couvre pas les systèmes d'information internes des communes elles-mêmes (mairies, directions techniques locales) sauf dans la mesure où ces systèmes se connectent directement à la plateforme ADECOB.

3. Gouvernance de la sécurité

3.1 Structure de gouvernance

L'ADECOB met en place une gouvernance de la sécurité articulée autour des acteurs suivants, conformément aux principes du cadre COBIT 2019 :

3.2 Canal de contact sécurité

Tout incident, vulnérabilité ou question relative à la sécurité doit être signalé via le formulaire de contact officiel de l'ADECOB en mentionnant explicitement « Sécurité — PSSI » dans l'objet du message. Ce canal est surveillé par le RSSI et le Super-Administrateur technique.

3.3 Cycles de révision et de pilotage

• La PSSI est revue formellement au moins une fois par an, en principe au cours du premier trimestre de chaque exercice ;
• Elle est également revue dans les 30 jours suivant tout incident de sécurité majeur ou toute évolution significative du système d'information ;
• Chaque révision donne lieu à une montée de version et une mise à jour de la date de publication visible en en-tête du présent document ;
• Un rapport de sécurité annuel est produit par le RSSI à destination de la direction de l'ADECOB et des bailleurs (DDC Suisse), synthétisant les incidents survenus, les mesures prises et les axes d'amélioration.

4. Politique des mots de passe

4.1 Règles par profil utilisateur

La plateforme impose les règles suivantes, vérifiées côté serveur lors de la création, la modification ou la réinitialisation du mot de passe :

4.2 Mots de passe interdits

Sont systématiquement rejetés les mots de passe :

• Identiques ou dérivés du nom, prénom, nom d'utilisateur ou adresse e-mail ;
• Figurant dans les listes publiques de mots de passe compromis (bases de type HaveIBeenPwned ou équivalent) ;
• Constitués de séquences évidentes : 123456789, password, azerty, adecob2026, etc. ;
• Identiques au code d'accès communal ou à tout autre identifiant de la plateforme ;
• Contenant le nom « ADECOB » ou « Borgou » seul ou combiné à un chiffre simple.

4.3 Stockage et hachage

Aucun mot de passe n'est jamais stocké en clair. La plateforme utilise exclusivement l'algorithme bcrypt avec facteur de coût adapté (≥ 12), via la fonction native de Laravel, garantissant un sel aléatoire unique par empreinte. Les mots de passe ne sont pas affichés, loggés, ni transmis par e-mail à aucun moment.

4.4 Tentatives de connexion et verrouillage

4.5 Réinitialisation du mot de passe

Le processus de réinitialisation respecte les étapes suivantes :

1. L'utilisateur demande une réinitialisation depuis la page de connexion ;
2. Un lien à usage unique, signé cryptographiquement et valable 60 minutes, est envoyé à l'adresse e-mail associée au compte ;
3. Le lien est invalidé après utilisation ou expiration ;
4. En cas de suspicion d'incident, le RSSI peut invalider tous les liens en cours par rotation de la clé APP_KEY ;
5. La réinitialisation génère automatiquement une entrée dans les journaux d'audit.

4.6 Sessions utilisateur

5. Gestion des accès et des identités

5.1 Modèle de rôles (RBAC)

La plateforme implémente un contrôle d'accès basé sur les rôles (Role-Based Access Control) avec quatre (4) niveaux distincts, appliquant le principe du moindre privilège : chaque utilisateur ne dispose que des droits strictement nécessaires à l'exercice de ses fonctions.

5.2 Cycle de vie des comptes

Le cycle de vie d'un compte utilisateur sur la plateforme ADECOB suit obligatoirement les étapes ci-après :

1. Inscription (auto-inscription) — L'utilisateur soumet une demande de création de compte en renseignant ses informations personnelles et sa commune de rattachement. Le compte est créé avec le statut en attente et aucune action n'est possible avant validation.
2. Validation de l'e-mail — Un lien de vérification est envoyé à l'adresse e-mail fournie. Sans validation, l'accès reste impossible. Ce mécanisme réduit les inscriptions abusives et les fausses identités.
3. Approbation manuelle — L'administrateur communal (ou le Super Admin) examine la demande, vérifie l'identité et le rattachement communal, puis approuve ou rejette le compte. Cette validation humaine est obligatoire pour tous les profils et ne peut pas être contournée.
4. Attribution du rôle — Le rôle définitif est attribué par un administrateur lors de l'approbation. Toute modification ultérieure du rôle est tracée dans les journaux d'audit.
5. Utilisation active — Le compte est actif tant que l'utilisateur exerce ses fonctions et respecte la PSSI.
6. Révision périodique — Une revue annuelle des comptes actifs est effectuée par les administrateurs, avec vérification de l'adéquation des rôles et suppression des accès obsolètes.
7. Désactivation / Révocation — En cas de départ, de faute ou de compromission, le compte est désactivé (et non supprimé) afin de préserver la traçabilité historique. La réactivation est soumise à une nouvelle approbation.

5.3 Principe du moindre privilège

Chaque fonctionnalité de la plateforme est protégée par des règles d'autorisation (policies Laravel) vérifiées côté serveur à chaque requête. Il est techniquement impossible pour un utilisateur d'accéder aux données d'une autre commune que la sienne, quand bien même il connaîtrait l'identifiant de la ressource. Cette isolation est assurée au niveau des requêtes de base de données et non uniquement via l'interface utilisateur.

5.4 Comptes de service et comptes partagés

Les comptes de service (utilisés pour les imports automatisés, les scripts de sauvegarde, etc.) sont nominatifs, disposent uniquement des droits strictement nécessaires, et ne sont jamais partagés entre plusieurs processus. Aucun compte générique ou partagé entre plusieurs personnes physiques n'est autorisé.

6. Authentification multi-facteurs (MFA)

6.1 Principe et obligation

La MFA est obligatoire et non désactivable pour les profils Super Admin et Admin Commune. Elle constitue un second facteur d'authentification qui s'ajoute au mot de passe et s'active systématiquement à chaque nouvelle ouverture de session, y compris depuis un terminal déjà connu.

6.2 Fonctionnement du code MFA

6.3 Résistance aux attaques

Le dispositif MFA est conçu pour résister aux attaques suivantes :

• Brute-force : le rate-limiting par utilisateur et par IP, combiné à la limitation des renvois, rend toute attaque par force brute infaisable dans la fenêtre de validité de 10 minutes ;
• Interception : le code est transmis par e-mail via une connexion TLS ; il est à usage unique et invalide après expiration ;
• Rejeu : un code déjà utilisé est immédiatement invalidé en base ;
• Fixation de session : l'ID de session est régénéré après validation réussie du code MFA.

6.4 Procédure en cas de perte d'accès à la boîte e-mail

Si un administrateur ne peut plus accéder à son adresse e-mail, il doit contacter le Super Admin (ou le RSSI) par un canal alternatif préalablement enregistré. Après vérification d'identité, le Super Admin peut modifier l'adresse e-mail associée au compte et déclencher une réinitialisation du mot de passe. Cette opération est tracée dans les journaux d'audit.

7. Classification des données

Toutes les données traitées par la plateforme sont classifiées selon quatre (4) niveaux de sensibilité. Cette classification détermine les mesures de protection à appliquer.

7.1 Règles transverses de traitement

• Aucune donnée de niveau Confidentiel ou Secret ne doit être transmise par e-mail en clair ;
• Les exports de données (CSV, Excel) sont réservés aux profils autorisés et tracés dans les journaux d'audit ;
• Toute copie de données sur un support amovible (clé USB) est interdite sans autorisation explicite du RSSI ;
• Les données de niveau Confidentiel et Secret doivent être effacées de manière sécurisée (non récupérable) lors de leur suppression.

8. Mesures techniques de protection

8.1 Sécurité du transport (couche réseau)

8.2 En-têtes de sécurité HTTP

Les en-têtes HTTP suivants sont appliqués sur toutes les réponses de l'application :

8.3 Protection applicative contre les injections (OWASP A03:2021)

• ORM Eloquent et requêtes paramétrées : toutes les interactions avec la base de données passent par l'ORM Laravel (Eloquent) ou des requêtes préparées (DB::select() avec bindings). Aucune concaténation directe de données utilisateur dans une requête SQL n'est autorisée ;
• Validation systématique des entrées : chaque formulaire dispose d'une classe FormRequest définissant les règles de validation (type, taille, format, liste blanche). Les données invalides sont rejetées avant tout traitement ;
• Échappement automatique Blade : le moteur de templates Blade échappe automatiquement toutes les variables affichées via {{ }}. L'opérateur {!! !!} (non échappé) n'est utilisé que dans des contextes contrôlés avec des données exclusivement internes ;
• Protection XSS : combinaison de l'échappement Blade, de la Content-Security-Policy et de la validation des entrées ;
• Protection CSRF : un jeton CSRF unique par session est vérifié sur toutes les requêtes HTTP mutatives (POST, PUT, PATCH, DELETE) via le middleware VerifyCsrfToken de Laravel.

8.4 Protection contre les attaques par force brute et abus

• Rate-limiting appliqué sur tous les formulaires sensibles : connexion, inscription, réinitialisation de mot de passe, MFA, contact, et recherche — avec des seuils adaptés à chaque action ;
• reCAPTCHA v3 intégré sur les formulaires d'inscription, de connexion et de contact, avec seuil de score configurable par le Super Admin ;
• Délais progressifs (exponential backoff) entre les tentatives d'authentification échouées ;
• Alertes automatiques en cas de dépassement de seuils critiques (voir section 4.4).

8.5 Chiffrement des données sensibles

• Les champs sensibles de la base de données (numéro de téléphone, code d'accès communal) sont chiffrés à l'aide du cast encrypted de Laravel, utilisant la clé APP_KEY (AES-256-CBC) ;
• La clé APP_KEY est stockée exclusivement dans le fichier .env, jamais dans le code source ni dans le dépôt Git ;
• La rotation de la clé APP_KEY est effectuée après tout incident de compromission potentielle ;
• Les mots de passe sont hachés avec bcrypt (voir section 4.3).

8.6 Sécurité des sessions

8.7 Sécurité des dépendances

Les dépendances Composer (PHP) et NPM (JavaScript) font l'objet d'une surveillance régulière. Le Super Admin technique vérifie mensuellement les avis de sécurité publiés pour les composants utilisés et applique les correctifs de sécurité dans les meilleurs délais (voir section 12).

9. Journalisation et traçabilité

9.1 Événements journalisés

La plateforme enregistre dans la table audit_logs l'ensemble des événements sensibles suivants, avec horodatage UTC, identifiant de l'utilisateur, adresse IP source et description de l'action :

9.2 Durée de conservation et accès

• Les journaux d'audit sont conservés au minimum 12 mois en base de données active, puis archivés pour une durée totale de 36 mois conformément aux exigences légales du Code du numérique béninois ;
• L'accès aux journaux est réservé exclusivement aux Super Admins ; aucun autre profil ne peut consulter les journaux d'audit ;
• Les journaux sont en lecture seule pour tous les utilisateurs, y compris les Super Admins : ils ne peuvent ni être modifiés, ni être supprimés via l'interface applicative ;
• Toute consultation des journaux est elle-même consignée dans les journaux (méta-audit).

9.3 Ce qui n'est jamais journalisé

• Mots de passe, même hachés ;
• Codes MFA en clair ;
• Jetons de session, tokens de réinitialisation en clair ;
• Clés API et secrets d'application ;
• Contenu intégral des champs chiffrés (téléphone, code commune) ;
• Données bancaires ou financières individuelles.

10. Sauvegardes et plan de continuité d'activité

10.1 Politique de sauvegarde

10.2 Objectifs de continuité

10.3 Procédure de restauration

1. Déclenchement par le RSSI ou le Super Admin après qualification de l'incident ;
2. Identification de la sauvegarde la plus récente et intègre ;
3. Restauration sur l'environnement cible avec vérification des intégrités ;
4. Tests fonctionnels post-restauration (connexion, lecture, écriture, MFA) ;
5. Communication aux utilisateurs sur la période de données éventuellement perdue ;
6. Documentation de l'incident et de la restauration dans le registre des incidents.

11. Gestion des incidents de sécurité

11.1 Définition d'un incident de sécurité

Est considéré comme incident de sécurité tout événement, avéré ou suspecté, compromettant la confidentialité, l'intégrité ou la disponibilité du système d'information, notamment :

• Intrusion avérée ou tentée dans le système ;
• Fuite, accès non autorisé ou divulgation de données personnelles ou confidentielles ;
• Compromission d'un compte administrateur (phishing, vol de credentials) ;
• Injection de code malveillant (malware, ransomware, backdoor) ;
• Indisponibilité majeure ou non planifiée de la plateforme ;
• Corruption ou destruction de données ;
• Usurpation d'identité d'un utilisateur de la plateforme ;
• Violation des règles définies dans la présente PSSI par un utilisateur interne.

11.2 Niveaux de gravité

11.3 Procédure de réponse aux incidents (6 étapes)

1. Détection et signalement. L'incident est détecté par un utilisateur, un outil de surveillance automatisé, le RSSI ou un tiers. Il est signalé immédiatement via le formulaire de contact officiel (mention « INCIDENT SÉCURITÉ » dans l'objet) ou par e-mail direct au RSSI et au Super Admin. Un numéro de dossier est attribué et la date/heure de détection est enregistrée.
2. Qualification et évaluation. Dans le délai correspondant au niveau de gravité (voir tableau 11.2), le RSSI qualifie l'incident : nature, périmètre affecté, données concernées, vecteur d'attaque probable. Il détermine s'il s'agit d'un incident de violation de données à caractère personnel au sens de l'article 391 du Code du numérique béninois.
3. Confinement. Actions immédiates visant à limiter la propagation : désactivation du ou des comptes compromis, blocage des adresses IP suspectes, isolation du composant affecté si nécessaire, invalidation des jetons de session actifs, rotation des secrets suspectés d'être compromis (APP_KEY, mots de passe administrateurs, credentials de base de données).
4. Éradication et remédiation. Identification et suppression de la cause racine : déploiement d'un correctif, restauration à partir d'une sauvegarde saine, scan complet de l'application et de la base de données, vérification de l'intégrité de tous les composants. Les actions de remédiation sont documentées.
5. Notification.
   • En cas de violation de données à caractère personnel, l'APDP (Autorité de Protection des Données Personnelles du Bénin) est notifiée dans les 72 heures suivant la découverte de l'incident, conformément à l'article 391 du Code du numérique (loi n°2017-20 du 20 avril 2018) ;
   • Si le risque pour les personnes concernées est élevé, ces dernières sont informées directement dans les meilleurs délais ;
   • La direction de l'ADECOB et la DDC Suisse sont informées de tout incident de niveau Élevé ou Critique dans les 24 heures.
6. Retour d'expérience (Post-mortem). Dans les 15 jours suivant la clôture de l'incident, le RSSI produit un rapport d'analyse post-incident comprenant : chronologie, cause racine, impact réel, mesures de remédiation prises et recommandations pour prévenir la récidive. Ce rapport entraîne si nécessaire une révision de la PSSI.

12. Gestion des vulnérabilités

12.1 Politique de divulgation responsable

L'ADECOB encourage la divulgation responsable des vulnérabilités. Toute personne découvrant une vulnérabilité affectant la plateforme est invitée à la signaler de manière confidentielle via le formulaire de contact (mention « DIVULGATION RESPONSABLE — SÉCURITÉ »), en fournissant :

• Une description précise de la vulnérabilité ;
• Les étapes pour la reproduire ;
• L'impact potentiel estimé ;
• Les éventuelles preuves de concept (Proof of Concept).

L'ADECOB s'engage à accuser réception dans un délai de 72 heures, à analyser le signalement dans un délai de 7 jours ouvrables et à informer le déclarant de la suite donnée. En contrepartie, le déclarant s'engage à ne pas divulguer publiquement la vulnérabilité avant qu'un correctif ait été déployé ou qu'un délai de 90 jours se soit écoulé depuis le signalement initial.

12.2 Gestion des correctifs (Patch Management)

Le Super Admin technique surveille mensuellement les bulletins de sécurité de Laravel, MariaDB, PHP, des dépendances Composer/NPM, et du système d'exploitation du serveur. Toute mise à jour de sécurité est testée sur un environnement de préproduction avant déploiement en production.

12.3 Test d'intrusion (Pentest)

Un test d'intrusion applicatif et d'infrastructure est recommandé annuellement, réalisé par un prestataire indépendant qualifié. Les conclusions du pentest font l'objet d'un plan de remédiation priorisé, dont le suivi est assuré par le RSSI. Les rapports de pentest sont classifiés Confidentiel et conservés 3 ans.

12.4 Surveillance continue

Des outils de surveillance automatisée (journaux applicatifs, alertes d'anomalie) sont mis en place pour détecter les comportements anormaux : pics de trafic inhabituels, multiplication d'erreurs 4xx/5xx, tentatives d'authentification en masse, accès à des URLs inhabituelles. Les alertes sont transmises au RSSI et au Super Admin.

13. Sécurité des accès physiques et des tiers

13.1 Infrastructure d'hébergement

La plateforme est hébergée chez un prestataire tiers. L'ADECOB exige de son hébergeur les garanties minimales suivantes, formalisées dans un contrat de service :

• Sécurité physique des centres de données (contrôle d'accès, vidéosurveillance, alimentation redondante, anti-incendie) ;
• Isolation des environnements (virtualisation sécurisée, cloisonnement réseau) ;
• Surveillance réseau 24h/24 et 7j/7 avec alertes en cas d'anomalie ;
• Sauvegardes indépendantes de niveau hébergeur ;
• Procédures documentées de gestion des incidents physiques ;
• Notification de l'ADECOB dans un délai de 4 heures en cas d'incident affectant son environnement.

13.2 Accords de traitement des données avec les tiers

Conformément à la loi n°2017-20 du 20 avril 2018, tout prestataire traitant des données personnelles pour le compte de l'ADECOB (hébergeur, mainteneur, auditeur) doit signer un accord de traitement des données (équivalent DPA — Data Processing Agreement), précisant :

• La nature et la finalité des traitements sous-traités ;
• Les mesures de sécurité techniques et organisationnelles appliquées ;
• L'obligation de confidentialité du personnel du prestataire ;
• L'interdiction de sous-traiter sans accord préalable de l'ADECOB ;
• Les modalités de notification des incidents de sécurité à l'ADECOB ;
• Les conditions d'audit et de contrôle par l'ADECOB ou un tiers mandaté.

13.3 Accès des prestataires à la plateforme

Tout accès technique d'un prestataire externe (mainteneur, auditeur, développeur tiers) à la plateforme ou à ses données est soumis aux règles suivantes :

• Autorisation préalable écrite du RSSI ;
• Création d'un compte nominatif temporaire avec droits limités au strict nécessaire ;
• Traçabilité complète de toutes les actions dans les journaux d'audit ;
• Révocation immédiate du compte à la fin de l'intervention ;
• Interdiction d'emporter des données hors du périmètre sans accord explicite.

14. Sensibilisation et formation

14.1 Accueil des nouveaux administrateurs

Tout nouvel utilisateur disposant d'un rôle Admin Commune ou Super Admin reçoit, préalablement à l'activation de son compte, une note de sécurité d'intégration couvrant les points suivants :

• Présentation synthétique de la PSSI et des obligations associées ;
• Règles de création et de gestion du mot de passe ;
• Fonctionnement et importance de la MFA ;
• Identification des tentatives de phishing et de l'ingénierie sociale ;
• Procédure de signalement d'un incident ou d'une anomalie ;
• Règles de confidentialité des données accessibles via la plateforme ;
• Interdiction de partager ses credentials avec quiconque, y compris le RSSI.

La réception de cette note est attestée par signature (physique ou électronique) avant toute attribution de droits d'administration.

14.2 Formation annuelle de rappel

Une session de sensibilisation à la sécurité informatique est organisée chaque année à destination de l'ensemble des utilisateurs ayant un accès authentifié. Elle aborde notamment :

• Le bilan des incidents de l'année écoulée et les leçons tirées ;
• Les évolutions de la PSSI depuis la dernière formation ;
• Les nouvelles menaces et techniques d'attaque émergentes ;
• Les bonnes pratiques d'hygiène informatique au quotidien ;
• Un rappel des sanctions encourues en cas de manquement.

14.3 Communication continue

Le RSSI peut, à tout moment, diffuser des alertes de sécurité ponctuelles aux administrateurs (via l'interface de la plateforme ou par e-mail) en cas de menace émergente, de correctif critique à appliquer sur leurs postes de travail, ou de modification importante des règles de sécurité.

15. Sanctions

15.1 Manquements visés

Constituent des manquements à la présente PSSI, de manière non exhaustive :

• Le partage de ses identifiants de connexion avec un tiers ;
• L'utilisation de la plateforme à des fins étrangères à sa mission ;
• La tentative d'accès à des données hors de son périmètre autorisé ;
• L'export non autorisé de données confidentielles ;
• Le contournement délibéré d'une mesure de sécurité (MFA, rate-limit, CSRF) ;
• La dissimulation d'un incident de sécurité ;
• La modification non autorisée des journaux d'audit ;
• L'installation de logiciels malveillants ou de backdoors.

15.2 Sanctions administratives internes

Tout manquement aux règles de la PSSI peut entraîner, selon la gravité et la nature de la violation, les mesures suivantes décidées par la direction de l'ADECOB :

• Avertissement écrit ;
• Suspension temporaire de l'accès à la plateforme ;
• Révocation définitive du compte et des droits d'accès ;
• Signalement à l'autorité de tutelle concernée (commune, ministère) ;
• Résiliation du contrat ou de la convention de collaboration.

15.3 Sanctions légales

Indépendamment des sanctions administratives, tout manquement constitutif d'une infraction pénale en vertu de la législation béninoise peut faire l'objet de poursuites judiciaires. Notamment :

• Accès frauduleux à un système informatique — Code du numérique du Bénin, art. 549 et suivants : peines d'emprisonnement et amendes ;
• Atteinte à l'intégrité des données — art. 554 et suivants : sanctions pour toute modification, suppression ou altération non autorisée de données ;
• Violation des données personnelles — art. 391 combiné avec les dispositions répressives du Code du numérique : obligation de notification et sanctions en cas de manquement délibéré ;
• Escroquerie et usurpation d'identité numérique — dispositions pénales du Code du numérique et du Code pénal béninois.

L'ADECOB se réserve le droit de porter plainte auprès des autorités compétentes (APDP, CRIET — Cour de Répression des Infractions Économiques et du Terrorisme) pour tout acte malveillant avéré.

16. Révision et mise à jour

16.1 Déclencheurs de révision

La PSSI est révisée dans les cas suivants :

• Révision annuelle planifiée (au plus tard au 31 mars de chaque année) ;
• Dans les 30 jours suivant tout incident de sécurité de niveau Élevé ou Critique ;
• Lors de toute évolution technologique majeure de la plateforme (nouveau framework, changement de fournisseur d'hébergement, intégration d'un nouveau service tiers) ;
• En cas d'évolution du cadre légal ou réglementaire applicable ;
• Sur recommandation suite à un audit ou un test d'intrusion.

16.2 Processus de révision

1. Le RSSI prépare une proposition de révision documentant les changements envisagés ;
2. La direction de l'ADECOB valide les modifications ;
3. La version révisée est publiée sur la plateforme avec un numéro de version incrémenté et une nouvelle date d'entrée en vigueur ;
4. Les utilisateurs concernés (administrateurs) sont informés des modifications significatives par notification dans la plateforme ou par e-mail.

16.3 Historique des versions

16.4 Entrée en vigueur

La présente version 1.1 de la PSSI entre en vigueur le 30 juin 2026. Elle annule et remplace toutes les versions antérieures. Tout utilisateur de la plateforme est réputé avoir pris connaissance de ce document et en accepter les termes dès lors qu'il accède à la plateforme après cette date.