Comment Maduuka protège les données de votre entreprise — chaque couche, chaque module

Vos données ne nous appartiennent pas. Il ne nous revient donc pas de les maltraiter.

Cette phrase guide chaque conversation interne avant que nous n'ajoutions la moindre fonctionnalité à Maduuka. Ce n'est pas un slogan. C'est une contrainte opérationnelle — le type de contrainte qui oriente les décisions avant même que l'architecture soit définie, avant que le schéma de base de données soit enrichi, avant que le premier point d'accès API soit tracé.

Maduuka conserve certaines des informations les plus sensibles qu'une petite entreprise génère au quotidien. Chaque vente enregistrée à votre caisse. Chaque paie exécutée pour chaque succursale. Chaque facture fournisseur, chaque solde client à crédit, chaque ordonnance dispensée en pharmacie, chaque folio d'un hôtel, chaque communication entre votre cuisine et votre salle. Si ces données fuient, sont altérées ou disparaissent simplement, votre entreprise s'arrête.

Cet article explique — en termes clairs — les protections concrètes que nous appliquons à chaque module de Maduuka. Vous n'y trouverez pas des formules marketing comme « sécurité bancaire » sans l'ingénierie qui les justifie.

Pourquoi la sécurité ne peut pas être une réflexion après coup

De nombreuses équipes de développement traitent la sécurité comme quelque chose à greffer sur le système une fois les fonctionnalités construites. C'est une erreur grave — et coûteuse à corriger.

Les vulnérabilités introduites au stade de l'architecture sont extraordinairement difficiles à corriger une fois le système en production. Un contrôle d'authentification absent sur un point d'accès API. Une requête base de données qui concatène des chaînes fournies par l'utilisateur. Un jeton de session qui n'expire jamais. Chacun de ces défauts prend trente minutes à introduire et des mois à détecter, corriger, et dont se remettre.

Nous adoptons l'approche inverse. Avant qu'une ligne de code Maduuka soit écrite pour un nouveau module, notre équipe établit l'architecture de sécurité correspondante : comment les données seront stockées, comment elles circuleront entre le serveur et l'application Android, qui y aura accès, et ce qui se passera en cas d'incident. Les modules point de vente, gestion des stocks, RH et paie, comptabilité, pharmacie, restauration et hôtellerie reposent tous sur la même fondation de sécurité. Chaque nouveau module en hérite.

Ce que Maduuka conserve réellement

Avant de décrire les protections, il convient de préciser ce que nous protégeons. Un locataire Maduuka typique (une entreprise opérant sur notre plateforme) stocke :

• L'historique des ventes — chaque transaction, chaque ligne, chaque clôture de caisse, indexé par succursale et par caissier.
• Les données de stock — catalogue produit, prix d'achat, relations fournisseurs, mouvements de stock entre succursales.
• Les données financières — recettes journalières, charges, compte de résultat, déclarations de TVA, soldes clients et fournisseurs.
• RH et paie — dossiers des employés, salaires, prêts, soldes de congés, cotisations sociales et impôts sur le revenu.
• Données pharmaceutiques — fiches patients, ordonnances, numéros de lot, dates de péremption, registres des substances contrôlées.
• Données hôtelières — folios clients, informations passeport, débiteurs du grand livre clients, pistes d'audit de nuit.
• Données restaurant — carte, consommation d'ingrédients, bons de commande cuisine, affectation des tables.
• Références de paiement — identifiants de transaction MTN Mobile Money et Airtel Money, références de virements bancaires, soldes de ventes à crédit.

Chacune de ces catégories présente un profil de risque différent. Les protections décrites ci-dessous s'appliquent à toutes.

Traitement des paiements — ce que nous touchons et ce que nous ne touchons pas

Les données de cartes bancaires sont la chose la plus dangereuse qu'une application de petite entreprise puisse conserver. Nous ne les conservons donc pas.

Maduuka s'intègre à des passerelles de paiement tierces établies, au cas par cas, selon les canaux que l'entreprise utilise réellement. Les options prises en charge incluent DPO Pay (Visa, Mastercard, cartes régionales), PesaPal (carte et argent mobile en Afrique de l'Est), MTN Mobile Money et Airtel Money. Pour les entreprises ougandaises, nous intégrons également EFRIS — le système de reçus fiscaux électroniques de l'Uganda Revenue Authority — afin que les clients assujettis à la TVA restent conformes au moment de la vente.

Les données brutes de carte — PAN, CVV, date d'expiration — ne touchent jamais le serveur Maduuka. Elles sont capturées directement par la page hébergée ou le SDK de la passerelle, puis tokenisées avant que quoi que ce soit ne nous parvienne. Ce que nous stockons avec la vente, c'est le résultat de la transaction : montant, jeton de référence de la passerelle, type de méthode, statut. Parce que Maduuka ne traite ni ne stocke de données de carte, la plateforme relève de la catégorie PCI DSS SAQ A — le palier commerçant le moins risqué, applicable lorsque tout le traitement carte est entièrement externalisé vers une passerelle certifiée PCI. Les prestataires de passerelle avec lesquels nous nous intégrons détiennent la certification PCI DSS Niveau 1 et portent la responsabilité PCI pour les données de carte elles-mêmes.

Toute communication avec les passerelles de paiement et EFRIS circule via HTTPS avec TLS 1.2+. Les identifiants API sont stockés côté serveur dans des variables d'environnement — jamais intégrés au code source, jamais visibles dans le code applicatif, jamais exposés au navigateur.

Chiffrement des données en transit

Toutes les données circulant entre le serveur Maduuka et votre application Android, votre navigateur, votre poste de bureau ou la tablette d'un caissier transitent via HTTPS avec TLS 1.2 ou supérieur. Si quelqu'un intercepte le trafic réseau — via un point d'accès Wi-Fi public dans le hall d'un hôtel, par exemple, ou via un routeur compromis dans une succursale — il ne voit que des octets chiffrés, illisibles.

Nous appliquons cette règle sans exception. Les connexions HTTP sont automatiquement redirigées vers HTTPS à la frontière du serveur, avec des en-têtes HSTS qui indiquent au navigateur de ne plus jamais tenter HTTP. Pour l'application Android Maduuka, nous appliquons le certificate pinning sur les points d'accès d'authentification et de paiement : l'application ne communique qu'avec les serveurs présentant le certificat correct et vérifié — pas n'importe quel certificat techniquement valide.

Cela neutralise toute une catégorie d'attaques où un point d'accès Wi-Fi malveillant délivre son propre certificat et déchiffre discrètement le trafic. L'application Maduuka refuse purement et simplement la tentative.

Chiffrement des données au repos

Les informations sensibles stockées sur votre appareil Android sont conservées dans un espace de stockage chiffré. Pour les identifiants de connexion et les jetons de session, nous utilisons EncryptedSharedPreferences d'Android — adossé à des clés conservées dans l'Android Keystore matériel lorsque l'appareil le prend en charge. Un téléphone perdu ou volé ne permet pas de simplement extraire et lire les données de l'application.

Pour le cache de ventes hors ligne — la file des transactions réalisées pendant que l'appareil était déconnecté, en attente de synchronisation — nous appliquons le chiffrement Room via SQLCipher. Si quelqu'un obtenait physiquement le stockage de l'appareil et tentait de lire le fichier SQLite hors ligne, il ne verrait que des pages chiffrées.

Côté serveur, les champs sensibles sont traités avec la même discipline. Les mots de passe ne sont jamais stockés en clair. Les références de paiement, les numéros d'identification nationale et les identifiants similaires sont isolés des données de vente générales. Les clés de chiffrement sont gérées via des magasins de clés sécurisés et ne sont jamais intégrées dans le code source — l'une des causes les plus fréquentes de divulgation accidentelle dans l'industrie.

Authentification, mots de passe et sessions

Nous implémentons l'authentification avec soin, sans raccourcis.

Politique de mot de passe

• Hachage : bcrypt via la fonction password_hash() de PHP — le standard industriel pour le stockage des mots de passe. Ni MD5, ni SHA-1, ni SHA-256 non salé.
• Règles de complexité : minimum 8 caractères, maximum 72. Doit contenir une majuscule, une minuscule, un chiffre et un caractère spécial. Règle appliquée côté serveur, pas seulement dans le navigateur.
• Vérification de compromission : à l'inscription et à chaque changement de mot de passe, Maduuka vérifie le mot de passe choisi contre la base Have I Been Pwned selon le modèle de k-anonymat. Seuls les cinq premiers caractères d'un hachage SHA-1 sont envoyés — pas de texte en clair, pas de nom d'utilisateur, aucune information identifiante ne quitte le système. Si le mot de passe est apparu dans une violation publique, l'utilisateur doit en choisir un autre.

Authentification à deux facteurs (TOTP)

Maduuka prend en charge la 2FA TOTP basée sur les standards (RFC 6238). Les utilisateurs s'enrôlent en scannant un QR code avec n'importe quelle application d'authentification standard — Google Authenticator, Microsoft Authenticator, Authy, 1Password, et d'autres. Aucun verrouillage vers un service tiers spécifique, aucun compte cloud requis ; la vérification TOTP s'exécute entièrement sur le serveur Maduuka. Nous recommandons fortement la 2FA pour chaque administrateur — notamment les utilisateurs ayant accès à la paie, aux paiements fournisseurs, à la validation des clôtures et à la dispensation d'ordonnances.

Gestion des sessions

• Délai d'inactivité de 30 minutes — les sessions inactives sont invalidées automatiquement.
• Les identifiants de session tournent toutes les 15 minutes — empêchant les attaques par fixation de session même si un jeton est intercepté.
• Les cookies de session sont HttpOnly, SameSite=Strict et Secure — verrouillés contre le vol par script, la falsification inter-sites et l'exfiltration non-HTTPS.
• La déconnexion invalide le JWT immédiatement côté serveur — un jeton déconnecté ne peut pas être rejoué.
• Liaison à l'agent utilisateur à chaque requête — le jeton est lié à l'empreinte de l'appareil auquel il a été délivré. Un jeton apparaissant soudainement depuis un autre navigateur ou appareil est rejeté.

Protection contre la force brute

• Maximum de 10 tentatives de connexion par tranche de 15 minutes par adresse IP, appliqué dans le code applicatif.
• Dépasser la limite retourne 429 Too Many Requests avec un en-tête Retry-After — pas un échec silencieux.
• Chaque tentative échouée est journalisée avec le nom d'utilisateur, l'adresse IP, l'agent utilisateur et l'horodatage. Le compteur par utilisateur se remet à zéro après une connexion réussie.

Récupération de compte

• La réinitialisation de mot de passe passe par un jeton par courriel sécurisé, à durée limitée, à usage unique — pas de question secrète, pas de mot de passe temporaire généré.
• En boutique, la vérification par code PIN superviseur est disponible pour les opérations POS élevées — ainsi un caissier ayant besoin de dépasser un plafond de remise peut être autorisé par le superviseur de service sans partager d'identifiants de direction.

Protection contre les vulnérabilités web courantes

Le back-end PHP de Maduuka et son front-end JavaScript sont écrits en tenant compte du Top 10 OWASP à chaque étape.

Injection SQL

Prévenue par l'utilisation systématique de requêtes préparées et paramétrisées. Nous ne construisons pas de SQL en concaténant des chaînes fournies par l'utilisateur — jamais. Les points d'accès product_search, customer_lookup et tous les autres qui acceptent des entrées utilisateur les passent par un mécanisme de liaison de paramètres, pas par une interpolation de chaînes. Cette seule discipline élimine la majorité des compromissions d'applications web encore signalées dans la région.

Cross-Site Scripting (XSS)

Bloqué par l'échappement systématique de toutes les sorties rendues dans le navigateur. Les contenus fournis par l'utilisateur — noms de produits, adresses clients, notes RH, instructions d'ordonnance — sont validés à la frontière serveur avant traitement et échappés en HTML avant affichage. Un nom de client comme <script>steal(document.cookie)</script> apparaît sur le reçu comme du texte, pas comme du code exécutable.

Falsification de requête inter-sites (CSRF)

Appliquée sur toutes les requêtes modifiant l'état, via des schémas de jetons synchronisés. Un site malveillant ne peut pas piéger le navigateur d'un utilisateur Maduuka authentifié pour créer silencieusement une annulation de vente ou un transfert de stock.

Téléchargements de fichiers

Les images de produits, les logos de reçus, les photos d'employés et les documents fournisseurs sont tous validés selon le type MIME, la taille et le contenu — pas seulement l'extension. Les fichiers sont stockés hors de la racine web et servis via des gestionnaires contrôlés.

En-têtes de sécurité — sur chaque réponse

Chaque réponse HTTP quittant Maduuka porte un ensemble durci d'en-têtes de sécurité. Le navigateur reçoit des instructions explicites sur ce qu'il peut et ne peut pas faire avec la page :

• Strict-Transport-Security: max-age=31536000; includeSubDomains — ne plus jamais accepter HTTP.
• Content-Security-Policy — restreint l'exécution de scripts aux sources de même origine et approuvées, neutralisant de nombreuses charges XSS même si l'une venait à passer.
• X-Frame-Options: SAMEORIGIN — empêche le clickjacking via des iframes malveillantes.
• X-Content-Type-Options: nosniff — bloque les ruses de reniflement MIME qui transforment des téléchargements en scripts.
• Referrer-Policy: strict-origin-when-cross-origin — limite la fuite de référents vers les tiers.
• Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=() — refuse l'accès aux API navigateur puissantes dont l'application n'a pas besoin.
• Cross-Origin-Resource-Policy: same-origin — isole les ressources contre les attaques inter-sites.

Les en-têtes divulguant la version du serveur (X-Powered-By, Server) sont supprimés — un attaquant qui sonde la plateforme n'obtient pas un inventaire gratuit de notre pile technique.

Conception sécurisée des API

L'API REST de Maduuka — la colonne vertébrale qui connecte l'application Android, le tableau de bord web et toute future intégration tierce — est conçue selon le principe du moindre privilège : chaque point d'accès n'expose que ce qui est strictement nécessaire, rien de plus.

• Chaque point d'accès est audité. Tous nos points d'accès REST v1 ont été explicitement revus ; la très grande majorité exige un JWT valide et rejette catégoriquement les requêtes non authentifiées. Les quelques rares routes non authentifiées sont des utilitaires étroits et sans état (vérifications de santé et similaires) qui n'exposent aucune donnée métier.
• Les jetons JWT portent des revendications d'expiration et des restrictions de portée. Un jeton émis pour l'application caissier mobile ne peut pas être utilisé pour appeler des points d'accès administratifs de paie, même si quelqu'un l'extrait de l'appareil.
• Les opérations à haut risque imposent des contrôles de permissions explicites et nommés au niveau API. Annulations, remboursements, validations de bons de commande, exécutions de paie et changements de rôle exigent chacun une permission nommée spécifique, pas seulement « l'utilisateur est-il connecté ? ».
• La limitation de débit est appliquée aux points d'accès sensibles — connexion, réinitialisation de mot de passe, vérification 2FA et export en masse. Les tentatives par force brute sont freinées et journalisées.
• Toute l'activité API est journalisée à des fins d'audit. Qui a accédé à quel enregistrement, quand, depuis quel appareil — sans journaliser les données sensibles elles-mêmes.

Isolation des données multi-tenant

Ce point compte plus que tout autre, il mérite donc sa propre section.

Maduuka est une plateforme SaaS multi-tenant. Des milliers d'entreprises partagent le même serveur applicatif et la même base de données. Dans ce modèle, l'isolation stricte des locataires n'est pas négociable. Une entreprise ne doit jamais, en aucune circonstance, voir les données d'une autre entreprise.

Chaque requête base de données dans Maduuka est délimitée par l'identifiant du locataire authentifié. Ce n'est pas un filtre appliqué après coup, ni un contrôle éparpillé dans le code applicatif qu'un développeur pourrait oublier. L'identifiant du locataire fait partie de la construction même de la requête — intégré dans le constructeur de requêtes au niveau du framework. Une requête qui oublie sa portée locataire échoue au niveau du framework, pas en production.

Concrètement, cela signifie :

• Il est architecturalement impossible qu'une requête de la Boutique A renvoie les enregistrements de ventes de la Boutique B.
• Un employé de la Boutique A disposant du plus haut niveau de privilèges ne peut pas s'élever pour accéder aux données de la Boutique B.
• Un compte compromis d'un locataire ne peut pas être utilisé pour moissonner les données d'un autre locataire.

L'isolation des données entre locataires est vérifiée lors de chaque revue de code et testée explicitement avant la mise en production de toute fonctionnalité multi-tenant. C'est la promesse la plus importante que Maduuka fait à chaque entreprise présente sur la plateforme.

Permissions granulaires — ce que votre caissier peut et ne peut pas faire

Le système RBAC de Maduuka n'est pas une simple case à cocher. C'est un modèle de permissions entièrement flexible et entièrement personnalisable, appliqué au niveau API à chaque requête. Nous livrons des rôles standards prêts à l'emploi — Employé, Caissier, Responsable, Administrateur, Super Administrateur — mais n'importe quel rôle peut être renommé, supprimé ou construit de zéro, et n'importe quelle permission peut être attribuée ou retirée à n'importe quel rôle.

Les permissions sont fines et nommées. Une liste partielle de ce que nous contrôlons :

• CREATE_SALE, VOID_SALES, PROCESS_REFUND, APPLY_DISCOUNT
• APPROVE_PURCHASE_ORDERS, APPROVE_STOCK_ADJUSTMENTS
• MANAGE_USERS, MANAGE_ROLES, MANAGE_PAYROLL, RUN_PAYROLL
• VIEW_FINANCIAL_REPORTS, SYSTEM_ADMIN

Un Employé par défaut peut traiter des ventes. Les annulations, remboursements, remises au-dessus d'un seuil configurable et ajustements de stock exigent chacun des permissions séparées, explicitement attribuées, qui ne font pas partie du rôle Employé par défaut — pour imposer la séparation des tâches. Les configurations de rôles par franchise sont prises en charge afin que les entreprises multi-succursales puissent faire fonctionner des ensembles de permissions différents selon les emplacements.

Pour une escalade en boutique, la vérification par code PIN superviseur permet à un caissier d'effectuer momentanément une action à privilèges plus élevés (par exemple, dépasser un plafond de remise) sans que le superviseur ait à confier son mot de passe. L'action est journalisée au nom des deux utilisateurs.

Piste d'audit — chaque modification de données, avec avant et après

Chaque action modifiant des données dans Maduuka est écrite dans tbl_audit_logs. Chaque entrée enregistre :

• ID utilisateur, ID franchise, adresse IP, agent utilisateur, ID de session
• Type d'action — CREATE, UPDATE, DELETE, VOID, LOGIN, LOGOUT, et d'autres
• Snapshots complets avant/après sous forme JSON — vous pouvez voir exactement ce qui a changé, pas seulement que quelque chose a changé
• Horodatage côté serveur

Cela couvre chaque transaction, chaque remboursement, chaque annulation, chaque mouvement de stock, chaque changement de compte utilisateur, chaque modification de permission, chaque changement de rôle et chaque événement de connexion/déconnexion. Lorsque vous avez besoin de savoir qui a annulé une vente à 14h27 mardi dernier, la réponse se trouve à un filtre près.

En plus du journal applicatif, Maduuka utilise des déclencheurs (triggers) de base de données comme journal secondaire indépendant et inviolable. Les mouvements de stock et les variations de soldes financiers sont enregistrés au niveau de la base, indépendamment du code applicatif, par des dizaines de déclencheurs — de sorte qu'une tentative de contourner l'application pour modifier directement la base laisse tout de même une trace.

Les journaux d'audit peuvent être exportés en CSV via l'interface (rôle Administrateur), filtrables par période, utilisateur, type d'action et enregistrement. Ils sont disponibles pour examen de conformité à tout moment.

Hébergement et durcissement serveur

Maduuka fonctionne sur une infrastructure cloud tier-1 certifiée ISO 27001, hébergée dans une juridiction dotée d'une loi de protection des données robuste, avec des liaisons réseau Tier 1 redondantes et une protection DDoS réseau intégrée. Les centres de données fonctionnent sous sécurité physique 24/7, contrôles d'accès biométriques, vidéosurveillance et systèmes anti-incendie.

Côté serveur, nous appliquons la même discipline de durcissement qu'au niveau applicatif :

• Les règles de pare-feu restreignent l'accès entrant — uniquement HTTPS (port 443) et SSH à authentification par clé depuis des adresses IP administrateur autorisées. Les mots de passe ne sont pas acceptés sur SSH.
• Le serveur de base de données est sur un réseau privé — inaccessible publiquement depuis Internet. Il n'accepte des connexions qu'en provenance du serveur applicatif.
• PHP-FPM s'exécute sous un utilisateur système restreint sans shell interactif et sans accès au-delà du répertoire applicatif.
• Terminaison SSL/TLS au serveur web avec redirection HTTPS automatique — aucun chemin de code ne sert du HTTP en clair en production.
• Les en-têtes divulguant la version du serveur sont supprimés — les scanners qui sondent la plateforme n'obtiennent aucune donnée de reconnaissance gratuite.

Sauvegarde et plan de reprise d'activité

Les sauvegardes ne sont pas une réflexion après coup — ce sont la dernière ligne de défense quand quelque chose tourne vraiment mal.

• Sauvegardes automatisées de la base de données toutes les 3 heures. Votre perte de données maximale dans le pire des scénarios est donc bornée à trois heures.
• Les sauvegardes sont téléversées automatiquement vers une infrastructure cloud séparée, hors site — un prestataire entièrement différent de l'environnement d'hébergement primaire. Aucune sauvegarde n'est conservée uniquement sur le serveur primaire.
• La restauration est possible sur un nouveau serveur — une autre région ou un autre fournisseur cloud — sans dépendre de l'environnement d'hébergement d'origine. La perte complète de l'environnement primaire n'implique pas la perte de vos données.
• Rétention de 30 jours par défaut. Une rétention plus longue peut être organisée pour les clients ayant des exigences de conformité spécifiques.
• Objectif RTO : inférieur à 4 heures pour une restauration complète du système. La restauration depuis sauvegarde a été testée et documentée.

Pile de développement sécurisée

Maduuka est construit sur des composants activement maintenus et supportés en sécurité — pas sur des runtimes hérités accumulant des CVE non corrigées.

• PHP 8.2+ — avec declare(strict_types=1) appliqué à travers tout le back-end. Le typage strict élimine toute une classe de bugs de sécurité par jonglage de types qui a historiquement touché les applications PHP.
• MySQL 8.0+ — chacune de nos tables est accédée via des requêtes PDO préparées ou des procédures stockées. Aucune interpolation brute de chaînes dans les requêtes, nulle part.
• Composer avec composer.lock — chaque dépendance PHP verrouillée sur une version exacte. Les mises à niveau silencieuses en amont ne peuvent pas se glisser dans un déploiement. composer audit s'exécute à la demande contre la base PHP Security Advisories.
• Dépendances JavaScript verrouillées — la même discipline côté front-end.
• Style de code imposé — PHP CS Fixer et ESLint détectent les patterns dangereux avant la revue.

Sécurité des dépendances et de la chaîne logicielle

Les bibliothèques tierces introduisent des risques lorsqu'elles ne sont pas gérées avec soin. Un paquet open source populaire peut être détourné et pousser une mise à jour malveillante dans des milliers d'applications du jour au lendemain.

Nous maintenons un inventaire actualisé de toutes les dépendances dans le code de Maduuka, surveillons les bases de vulnérabilités publiques et remplaçons les bibliothèques qui cessent d'être maintenues. Les fichiers de verrouillage Composer et npm figent les versions exactes — une mise à niveau silencieuse ne peut pas se glisser dans un déploiement. Les correctifs de sécurité sont priorisés et déployés selon un calendrier mesuré en jours, pas en mois.

Nos serveurs fonctionnent avec des installations minimales. Seuls les paquets nécessaires à Maduuka sont présents. Les services, ports, shells SSH, comptes par défaut et applications d'exemple inutilisés sont supprimés.

La sécurité dans le processus de développement

La sécurité n'est pas examinée uniquement en fin de cycle de publication. Elle fait partie de chaque étape.

Les revues de code incluent une liste de contrôle de sécurité couvrant la validation des entrées, l'encodage des sorties, les flux d'authentification, les frontières de permissions et la gestion des données. Nos développeurs suivent des standards de codage sécurisé documentés pour PHP, Android/Kotlin et JavaScript. Les demandes d'intégration touchant à l'authentification, aux paiements ou aux frontières entre locataires reçoivent un second relecteur par politique.

Les nouvelles fonctionnalités traitant des données personnelles — dossiers patients dans le module pharmacie, passeports des clients dans le module hôtellerie, numéros d'identification nationale des employés dans la paie — font l'objet d'une analyse d'impact sur la vie privée avant le début de l'implémentation. Les décisions prises lors de cette analyse sont documentées avec la fonctionnalité afin que les réponses survivent aux changements d'équipe.

Préparation à la réponse aux incidents

Aucun système n'est entièrement à l'abri des incidents. Ce qui compte, c'est la rapidité et l'efficacité avec lesquelles un incident est contenu et résolu.

Nous maintenons des procédures documentées de réponse aux incidents pour Maduuka, couvrant :

• La détection — via une journalisation applicative et serveur structurée qui met en évidence les schémas anormaux, les pics d'échecs de connexion et les volumes d'export inhabituels.
• Le confinement — des étapes spécifiques et éprouvées pour les scénarios de compromission d'identifiants, d'accès non autorisé, d'exposition de données et des scénarios propres aux modules.
• La communication — des protocoles pour notifier rapidement les entreprises affectées, avec les informations précises dont elles ont besoin pour agir.
• La revue post-incident — pour combler la vulnérabilité sous-jacente, mettre à jour la liste de contrôle et prévenir toute récidive.

Si quelque chose tournait mal un jour, vous ne l'apprendrez pas par un client ou par la presse. Vous l'apprendrez d'abord par nous, avec des informations précises.

Lacunes honnêtes — ce que nous continuons d'améliorer

Toute équipe logicielle sérieuse a une liste de choses qui sont bonnes mais pas encore finies. Nous pensons que vous êtes mieux servi par un prestataire qui nomme ces éléments directement, plutôt que par un qui les cache derrière du langage marketing. Les voici donc.

• Chiffrement transparent au niveau base de données pour les champs PII. Les mots de passe sont déjà hachés individuellement avec bcrypt. Le chiffrement transparent au niveau colonne pour les autres données personnelles (champs de contact client, numéros d'identification nationale des employés) est le prochain jalon majeur de notre feuille de route de durcissement — pas une ambition lointaine, un chantier actif.
• Outils GDPR / DPPA en libre-service. Dans la version actuelle, les demandes d'exercice de droits et les actions de suppression sont exécutées par un administrateur système à réception d'une demande validée. Des flux automatisés en libre-service sont sur la feuille de route à court terme ; le processus manuel respecte la lettre de la loi dans l'intervalle.
• Test de pénétration externe. Maduuka a fait l'objet d'une revue de sécurité interne approfondie tout au long du développement. Un test de pénétration indépendant par une société de sécurité qualifiée est programmé dans le cadre de notre travail de maturation conformité. Nous publierons un résumé des conclusions et des corrections une fois terminé.
• Certification ISO 27001 / SOC 2. Nous opérons déjà sur une infrastructure d'hébergement certifiée ISO 27001 et appliquons des contrôles alignés sur les deux cadres. La certification formelle de Maduuka en tant qu'organisation est sur la feuille de route.
• SAST/DAST automatisé dans le pipeline CI. L'audit des dépendances via Composer et la revue manuelle couvrent ce terrain aujourd'hui. L'analyse automatisée continue est un ajout prévu.

Aucun de ces points ne compromet la posture de sécurité de base aujourd'hui — les données en transit sont entièrement chiffrées, les mots de passe sont hachés avec bcrypt, le RBAC est appliqué à chaque requête, les pistes d'audit capturent chaque modification, et des sauvegardes hors site s'exécutent toutes les trois heures. Mais nous les nommons explicitement pour que vous puissiez prendre une décision éclairée, sans surprise plus tard.

Positionnement de conformité

Maduuka est conçu pour aider les entreprises qui l'utilisent à respecter leurs propres obligations de conformité, pas seulement les nôtres. Concrètement :

• Lois locales de protection des données — dans les marchés que nous servons (Ouganda, Kenya, Rwanda, Sénégal, Côte d'Ivoire, Cameroun, RDC), nous opérons selon les principes que ces textes consacrent.
• Déclarations fiscales — les rapports générés par Maduuka pour la TVA, l'impôt sur le revenu et les cotisations sociales sont conçus pour correspondre aux formats réellement attendus par les administrations concernées.
• Conformité pharmaceutique — le module pharmacie journalise la dispensation des médicaments contrôlés, le suivi des lots et la gestion des dates de péremption dans une forme adaptée aux inspections des régulateurs.
• Contrôles liés aux paiements — pour les locataires traitant les paiements par carte via des passerelles intégrées, nous nous alignons sur les bonnes pratiques de réduction du périmètre PCI DSS.