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'écrivions une seule ligne de code pour un nouveau projet. 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 conçu, avant que le premier point d'accès API soit tracé.
Chaque système que nous construisons — qu'il s'agisse d'une application mobile fonctionnant sur un téléphone Android à Kampala ou d'une plateforme web accessible depuis un navigateur à Nairobi, Dakar ou Abidjan — est conçu avec la sécurité comme exigence fondamentale. Pas une fonctionnalité à ajouter ultérieurement. Pas une liste de contrôle à remplir avant la mise en production. Une propriété structurelle du système lui-même.
Cet article explique, en termes clairs, les mesures concrètes que nous appliquons à l'ensemble de nos applications.
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 soit écrite, notre équipe établit l'architecture de sécurité : comment les données seront stockées, comment elles circuleront entre les systèmes, qui y aura accès, et ce qui se passera en cas d'incident. Nos produits — Maduuka, Aqar, nos systèmes de gestion pharmaceutique et de restauration, Longhorn ERP — sont tous construits sur cette fondation.
Chiffrement des données en transit
Toutes les données circulant entre nos applications et leurs serveurs 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, par exemple — 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. Pour nos applications Android, nous appliquons le certificate pinning sur les points d'accès à haute sensibilité. L'application ne communique qu'avec des serveurs présentant le certificat correct et vérifié — pas n'importe quel certificat techniquement valide.
Chiffrement des données au repos
Les informations sensibles stockées sur l'appareil sont conservées dans un espace de stockage chiffré. Sur Android, nous utilisons EncryptedSharedPreferences pour les identifiants et les jetons de session. Pour les bases de données contenant des enregistrements particulièrement sensibles, nous appliquons le chiffrement Room via SQLCipher.
Côté serveur, les champs sensibles — numéros d'identification nationale, données financières, dossiers médicaux — sont chiffrés au niveau de la colonne, indépendamment des contrôles d'accès applicatifs standard. Si quelqu'un obtenait une copie brute de la base de données, il ne pourrait pas lire ces champs. 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.
Authentification et gestion des sessions
Nous implémentons l'authentification avec soin, sans raccourcis.
- Les mots de passe ne sont jamais stockés en clair. Nous utilisons bcrypt avec un facteur de travail calibré pour être coûteux en calcul pour les attaquants, tout en restant suffisamment rapide pour les utilisateurs légitimes.
- Les sessions sont émises sous forme de jetons cryptographiquement signés avec des fenêtres d'expiration courtes. Les sessions inactives sont invalidées automatiquement.
- L'authentification multi-facteurs est disponible et recommandée pour tous les comptes administrateurs — notamment pour les utilisateurs ayant accès aux données financières ou à la gestion des stocks dans Maduuka et Longhorn ERP.
- Le contrôle d'accès basé sur les rôles (RBAC) garantit que chaque utilisateur ne voit que ce que son rôle lui autorise. Un caissier ne peut pas accéder à la paie. Un directeur de succursale ne peut pas modifier les paramètres système globaux.
Protection contre les vulnérabilités web courantes
Notre code PHP et JavaScript est écrit 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.
Cross-Site Scripting (XSS)
Bloqué par l'échappement systématique de toutes les sorties rendues dans le navigateur. Les données utilisateur sont validées à la frontière serveur avant traitement et échappées avant affichage.
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.
Téléchargements de fichiers
Validés pour le type MIME, la taille et le contenu — pas seulement l'extension. Les fichiers sont stockés hors de la racine web. Un fichier malveillant ne peut pas être exécuté directement via le serveur web.
Conception sécurisée des API
Nos API REST sont conçues selon le principe du moindre privilège : chaque point d'accès n'expose que ce qui est strictement nécessaire, rien de plus.
Les clés API et les jetons JWT portent des revendications d'expiration et des restrictions de portée. Un jeton d'authentification émis pour l'application mobile ne peut pas être utilisé pour appeler des points d'accès API administratifs. Toutes les requêtes API provenant de nos applications mobiles sont authentifiées — il n'existe pas de points d'accès publics renvoyant des enregistrements sensibles.
La limitation de débit est appliquée aux points d'accès sensibles — authentification, réinitialisation de mot de passe et exportation de données — pour prévenir les attaques par force brute. Nous journalisons toute l'activité API à des fins d'audit : qui a accédé à quoi et quand, sans journaliser les données sensibles elles-mêmes.
Isolation des données multi-tenant
Plusieurs de nos plateformes — Maduuka, Aqar, notre système de gestion pharmaceutique — servent plusieurs organisations clientes depuis une infrastructure partagée. Dans ces environnements, l'isolation stricte des tenants est non négociable.
Chaque requête base de données est délimitée par l'identifiant du tenant authentifié. Il est architecturalement impossible qu'une requête d'un tenant renvoie les enregistrements d'un autre — non pas en raison de vérifications de logique applicative ajoutées après coup, mais parce que la construction de la requête ne peut physiquement pas traverser les frontières entre tenants.
L'isolation des données entre tenants est vérifiée lors des revues de code et testée explicitement avant la mise en production de toute fonctionnalité multi-tenant.
Sécurité des dépendances et de la chaîne d'approvisionnement
Les bibliothèques tierces introduisent des risques lorsqu'elles ne sont pas gérées avec soin. Nous maintenons un inventaire actualisé de toutes les dépendances dans nos projets et surveillons les vulnérabilités publiées. Les bibliothèques qui ne sont plus maintenues ou qui présentent des vulnérabilités connues non corrigées sont remplacées.
Nos serveurs fonctionnent avec des installations minimales — seuls les paquets nécessaires à l'application sont présents. Les services, ports et comptes inutilisés sont supprimés. Un serveur qui ne fait tourner que ce dont il a besoin présente une surface d'attaque nettement plus réduite.
La sécurité dans le processus de développement
La sécurité n'est pas examinée uniquement en fin de projet. 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 et la gestion des données. Notre équipe suit des standards de codage sécurisé documentés pour PHP, Android/Kotlin et JavaScript.
Les nouvelles fonctionnalités traitant des données personnelles font l'objet d'une analyse d'impact sur la vie privée avant le début de l'implémentation. Si une nouvelle fonctionnalité d'Aqar doit stocker les coordonnées ou l'historique financier des locataires, cette analyse est réalisée avant que la fonctionnalité soit codée — pas après. Nous effectuons des audits de sécurité périodiques de nos propres plateformes à l'aide de listes de contrôle structurées.
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 nos plateformes hébergées, couvrant :
- → La détection — via une journalisation structurée qui met en évidence les schémas anormaux
- → Le confinement — des étapes spécifiques pour les scénarios de compromission d'identifiants, d'accès non autorisé et d'exposition de données
- → La communication — des protocoles pour notifier rapidement les clients affectés
- → La revue post-incident — pour combler la vulnérabilité et prévenir toute récidive
Nos clients ne sont jamais laissés à eux-mêmes pour découvrir un problème.
9 mesures de sécurité appliquées à chaque projet
Ce que cela signifie pour vous
Lorsque vous nous confiez un projet, vous recevez un logiciel construit sur des principes de sécurité — pas un logiciel auquel des fonctionnalités de sécurité ont été ajoutées après coup.
Nous documentons les mesures de sécurité appliquées à chaque système que nous livrons. Vous saurez précisément quelles protections sont en place. Vous pourrez répondre aux questions de vos propres clients, auditeurs et régulateurs en toute confiance, car vous disposez de la documentation pour l'étayer.
La sécurité n'est pas un avantage concurrentiel pour nous. C'est une norme professionnelle fondamentale. Chaque organisation qui utilise nos logiciels — d'une pharmacie à Mbarara à une agence immobilière à Nairobi — mérite un système qui traite ses données avec le soin qu'elles requièrent.
Publié par l'équipe de développement de Chwezi Core Systems. Dernière révision : mars 2026.
Chwezi Core Systems
Consultants en Technologie, Conseil et Sécurité — Kampala, Ouganda
Nous concevons, construisons et accompagnons des logiciels d'entreprise, des applications mobiles et des infrastructures de sécurité pour des organisations à travers l'Afrique. Nos produits incluent Maduuka (point de vente et comptabilité), Aqar (gestion immobilière) et Longhorn ERP.