Plateforme LBC/FT sur site ou dans le cloud : que choisir pour les banques africaines ?

Pour une institution financière européenne qui évalue des technologies de lutte contre le blanchiment de capitaux et le financement du terrorisme (LBC/FT), le choix entre cloud et sur site est avant tout une question d'économie et de stratégie informatique. Les fournisseurs de cloud offrent des cadres solides de protection des données, des montages contractuels conformes au règlement général sur la protection des données (RGPD, ou GDPR) et des centres de données implantés dans la plupart des grandes juridictions de l'UE. L'environnement réglementaire est globalement favorable au déploiement dans le cloud des charges de travail non sensibles, avec des orientations claires sur ce qui constitue un usage acceptable du cloud pour les données financières.

Pour une banque d'Afrique de l'Est, la même décision est nettement plus complexe. Les exigences réglementaires de résidence des données évoluent et restent parfois ambiguës. L'infrastructure cloud disponible dans la région immédiate est limitée par rapport à l'Europe ou à l'Amérique du Nord. La fiabilité de la connexion Internet varie fortement entre les centres urbains et les réseaux d'agences rurales. Enfin, les inspecteurs informatiques de la banque centrale ont traditionnellement montré une préférence pour les solutions qu'ils peuvent inspecter physiquement.

Ce guide aide les dirigeants des fonctions conformité et informatique des institutions financières d'Afrique de l'Est à prendre leur décision de déploiement en disposant de l'ensemble du contexte réglementaire, technique et économique.

---

Le contexte réglementaire de la résidence des données en Afrique de l'Est

Les exigences de la CBK en matière de résidence des données

La Central Bank of Kenya (CBK, banque centrale du Kenya), dans ses Prudential Guidelines on Outsourcing and Cloud Computing (lignes directrices prudentielles sur l'externalisation et l'informatique en nuage), impose aux établissements agréés de veiller à ce que les données clients et les enregistrements de transactions restent soumis à la juridiction kényane. Les exigences précises n'interdisent pas de manière générale le stockage de données financières dans le cloud : elles imposent que les fournisseurs de cloud acceptent des clauses contractuelles permettant à la CBK d'accéder aux données lors de ses contrôles, que les données soient accessibles depuis le Kenya à tout moment et que la banque conserve un contrôle effectif sur ses données, quel que soit leur lieu de stockage.

En pratique, les inspecteurs de la CBK se montrent plus ou moins à l'aise avec les systèmes financiers hébergés dans le cloud. Les systèmes bancaires centraux (core banking) doivent fonctionner sur une infrastructure dédiée, aux capacités de résilience et de reprise éprouvées. Les charges de travail de conformité et d'analyse — y compris les plateformes de déclaration LBC/FT — relèvent d'orientations moins prescriptives, mais les institutions doivent disposer d'évaluations des risques documentées à l'appui de leur choix de déploiement.

Les dispositions du Banking Act du Kenya relatives aux enregistrements électroniques et les exigences du Proceeds of Crime and Anti-Money Laundering Act en matière de conservation des documents imposent toutes deux que les documents LBC/FT soient conservés sous une forme consultable pendant les durées prescrites. Le stockage dans le cloud satisfait à ces exigences, pourvu que les dispositions contractuelles et techniques en garantissent la disponibilité et l'intégrité.

La préférence du FRC pour le sur site ou un cloud implanté dans le pays

Le Financial Reporting Centre (FRC) du Kenya a exprimé, dans ses communications de supervision, une préférence pour que les données de conformité LBC/FT soient stockées sur une infrastructure placée clairement sous le contrôle de la juridiction kényane. Cette préférence ne constitue pas une interdiction légale du stockage dans le cloud, mais c'est un facteur que les institutions soucieuses de leur conformité prennent au sérieux lorsqu'elles préparent les contrôles du FRC.

La préoccupation concrète du FRC est l'accès : en cas d'enquête ou de demande de données, le FRC peut-il obtenir rapidement les documents de conformité de l'institution, sans dépendre de la coopération d'une entité étrangère ? Un déploiement sur site ou dans un centre de données cloud domicilié au Kenya répond directement à cette préoccupation. Un déploiement dans une région cloud européenne ou américaine, avec réplication des données vers le Kenya, y répond aussi, mais exige une documentation contractuelle plus rigoureuse.

FIU (Tanzanie), FIA (Ouganda), FIC (Zambie) : les exigences de localisation des données

Dans la région, la situation en matière de résidence des données est contrastée :

En Ouganda, la Financial Intelligence Authority (FIA) et les orientations informatiques de la Bank of Uganda exigent que les données financières soient stockées en Ouganda lorsque c'est possible. L'écosystème ougandais d'infrastructures cloud est moins mature que celui du Kenya, si bien que le déploiement sur site est la voie la plus couramment choisie par les institutions ougandaises.

En Tanzanie, la Financial Intelligence Unit (FIU) et les orientations de la Bank of Tanzania suivent un schéma semblable à celui de l'Ouganda, avec une attente générale que les données restent sous la juridiction tanzanienne. La Tanzanie, membre actif de l'ESAAMLG (Groupe anti-blanchiment de l'Afrique orientale et australe), examine de plus en plus attentivement l'efficacité des systèmes LBC/FT des institutions financières.

En Zambie, le FIC exerce ses missions en vertu du Financial Intelligence Centre Act et des règlements associés, qui exigent que les documents LBC/FT puissent être présentés lors des contrôles sans retard déraisonnable. La Zambia Information and Communications Technology Authority (autorité zambienne des technologies de l'information et de la communication) a publié des orientations sur l'usage du cloud qui imposent une classification des données et une notification au gouvernement pour les déploiements portant sur des données personnelles de citoyens zambiens.

Au Rwanda, la National Bank of Rwanda (Banque nationale du Rwanda, BNR) et le Centre de renseignement financier (FIC) ont adopté une approche plus ouverte du cloud et de l'adoption des technologies, à l'image de la stratégie technologique nationale du Rwanda dans son ensemble. Le cadre de la BNR autorise un usage encadré du cloud pour les services financiers, sur la base d'évaluations des risques documentées.

En quoi ces exigences diffèrent du RGPD en Europe

Les institutions européennes soumises au RGPD disposent d'un cadre réglementaire mature et détaillé pour le traitement des données dans le cloud — notamment les clauses contractuelles types, les décisions d'adéquation relatives à certaines juridictions et des orientations détaillées des autorités nationales de protection des données. Le RGPD crée de la complexité en matière de conformité, mais il crée aussi de la clarté.

En Afrique de l'Est, les cadres réglementaires applicables aux données et au cloud en sont à un stade moins avancé de leur développement. Les orientations sont moins détaillées, la pratique de supervision est moins homogène et l'environnement réglementaire évolue rapidement. Cette ambiguïté joue dans les deux sens : les déploiements dans le cloud ne sont pas clairement interdits, mais ils ne sont pas non plus clairement approuvés. Les institutions qui choisissent le cloud doivent être prêtes à défendre leur évaluation des risques devant des inspecteurs parfois peu familiers de l'architecture cloud.

---

Le déploiement sur site : les arguments en sa faveur

Une souveraineté totale sur les données

Un déploiement sur site — serveurs, stockage et réseau physiquement situés dans le centre de données de l'institution ou dans une installation de colocation — offre le plus haut niveau de souveraineté des données possible. Les données de transaction, les exposés des faits des déclarations de soupçon (STR), les dossiers et les journaux d'audit ne quittent jamais l'infrastructure physique de l'institution. Il n'y a aucune dépendance à l'égard des engagements contractuels ou des politiques de confidentialité d'une entité étrangère, ni de sa réponse aux procédures judiciaires engagées par des gouvernements étrangers.

Pour les hauts responsables de la conformité et les comités d'audit soucieux de la confidentialité des données de STR en particulier — qui décrivent des soupçons de blanchiment de capitaux visant des personnes et des entités nommément désignées —, le stockage sur site offre la meilleure protection possible contre une divulgation accidentelle.

Préférence réglementaire de la CBK et du FRC, et sérénité lors des contrôles

Lorsque les inspecteurs de la CBK ou les superviseurs du FRC se rendent dans une institution pour un contrôle LBC/FT, une plateforme LBC/FT sur site permet à l'équipe conformité de présenter directement le système, de montrer l'infrastructure physique aux inspecteurs et de donner un accès immédiat à l'ensemble des documents, sans aucune dépendance à la connexion Internet ou à des systèmes tiers. Ce niveau de transparence renforce la confiance des inspecteurs et se traduit généralement par des contrôles plus fluides.

Les institutions dont de précédents contrôles LBC/FT ont relevé des insuffisances technologiques choisissent souvent le déploiement sur site pour leurs mises en œuvre suivantes, précisément parce qu'il élimine de l'équation tout risque réglementaire lié au cloud.

Aucune dépendance à Internet pour les processus de conformité essentiels

Les plateformes de déclaration LBC/FT accèdent au portail de la cellule de renseignement financier (CRF) via Internet pour la transmission — mais le travail quotidien de conformité (création des dossiers, investigation, documentation, approbation) ne nécessite pas d'accès à Internet. Sur une plateforme sur site, les responsables de la conformité peuvent travailler sur les dossiers même pendant les coupures d'Internet, les transmissions étant mises en file d'attente jusqu'au rétablissement de la connexion.

Cette résilience compte en Afrique de l'Est, où la connexion Internet — en particulier dans les villes moyennes et les réseaux d'agences rurales — peut être moins fiable que dans les grandes métropoles. Une plateforme LBC/FT dont tout le fonctionnement dépend de la connexion au cloud crée une vulnérabilité de conformité à chaque interruption de la connexion.

Comparaison entre CapEx ponctuelles et OpEx récurrentes

Le profil financier d'un déploiement sur site diffère fondamentalement de celui des modèles d'abonnement cloud. Le sur site implique d'importantes dépenses d'investissement initiales en serveurs, équipements réseau, stockage et infrastructure de centre de données — généralement de 50 000 $ à 150 000 $ pour une institution de taille moyenne, selon la capacité existante de son centre de données. Les coûts récurrents se limitent à la maintenance, à l'électricité, aux licences logicielles et au temps du personnel.

Pour les institutions dont l'infrastructure de centre de données existante peut accueillir des charges de travail supplémentaires, le coût marginal d'un déploiement sur site peut être nettement inférieur à celui d'un abonnement cloud sur un horizon de 5 ans. Les directeurs financiers et les administrateurs issus du secteur bancaire préfèrent souvent la prévisibilité d'un actif immobilisé à un engagement d'abonnement à durée indéterminée.

---

Le déploiement sur site : les difficultés

Le coût de l'infrastructure

Toutes les institutions ne disposent pas d'un centre de données capable d'héberger une plateforme LBC/FT conteneurisée. Celles qui n'ont pas d'infrastructure de serveurs dédiée doivent supporter l'intégralité du coût d'investissement de l'acquisition : serveurs physiques dotés de suffisamment de CPU et de RAM pour des charges de travail Kubernetes, stockage d'entreprise avec sauvegarde, infrastructure réseau, onduleurs et groupes électrogènes de secours, sécurité physique et contrôles environnementaux. Au Kenya, un projet d'acquisition de serveurs pour une institution de taille moyenne prend généralement de 8 à 16 semaines, du bon de commande à l'installation complète en baie.

Les compétences requises de l'équipe informatique

Exploiter une plateforme de microservices conteneurisée sur Kubernetes exige des compétences DevOps que toutes les équipes informatiques des banques d'Afrique de l'Est ne possèdent pas. La gestion des conteneurs, l'administration des clusters Kubernetes, la configuration des politiques réseau, la gestion des secrets et les procédures de déploiement progressif (rolling deployment) sont des compétences spécialisées. Une institution qui ne dispose pas déjà de capacités DevOps doit recruter ou former du personnel avant de pouvoir maintenir efficacement un déploiement sur site.

L'obstacle n'est pas insurmontable, mais c'est une véritable contrainte de capacité que le plan de mise en œuvre doit traiter. Les plateformes conçues spécifiquement pour un déploiement bancaire sur site incluent généralement un accompagnement à la mise en œuvre, de la formation et, en option, des services gérés continus pour combler le déficit de compétences.

La gestion des mises à jour logicielles

Les déploiements sur site obligent l'institution à gérer elle-même les mises à jour logicielles : récupérer les images de conteneurs mises à jour, les tester en préproduction et les déployer en production. C'est une tâche d'exploitation courante dans les organisations DevOps matures, mais elle alourdit la charge de travail de l'équipe informatique et exige un processus formel de gestion des changements. Lorsqu'une vulnérabilité de sécurité est corrigée ou qu'une mise à jour du schéma réglementaire est publiée, la mise à jour doit être appliquée rapidement, ce qui suppose à la fois des capacités techniques et une bonne réactivité de l'organisation.

La complexité de la reprise après sinistre

Concevoir et tester une configuration de reprise après sinistre pour une plateforme LBC/FT sur site exige une architecture réfléchie. L'institution doit maintenir un site d'infrastructure secondaire (site de secours en propre ou installation de colocation), répliquer les données du site principal vers le site secondaire en quasi temps réel et tester périodiquement les procédures de basculement. Cette infrastructure de reprise double à peu près le coût de l'infrastructure et exige une discipline de tests réguliers pour garantir qu'elle fonctionne réellement le moment venu.

---

Le déploiement en cloud privé sur Azure

L'infrastructure Azure pour l'Afrique de l'Est

Microsoft Azure exploite la région South Africa North, située à Johannesburg, comme principal centre de données Azure desservant l'Afrique de l'Est. C'est la région Azure la plus proche de Nairobi à proposer un catalogue de services complet, et elle offre une résidence des données en Afrique du Sud — soit sous une juridiction africaine, mais pas à l'intérieur des frontières des pays d'Afrique de l'Est concernés.

Il n'existe pas de région Azure au Kenya, et aucune ne figure parmi les régions disponibles ou à venir. Microsoft et G42 ont annoncé en mai 2024 une région cloud pour l'Afrique de l'Est (East Africa Cloud Region) au Kenya, mais aucune date de lancement n'a été publiée, et des articles de presse parus en mai 2026 ont décrit le projet comme bloqué par des questions de capacité électrique et d'engagements d'achat — le ministère kényan des TIC a parlé d'un retard plutôt que d'une annulation. Pour les institutions qui doivent aujourd'hui conserver leurs données au Kenya, c'est le déploiement sur site qui le permet ; la région South Africa North, assortie de protections contractuelles appropriées, est l'alternative la plus pratique sur Azure.

Les centres de données Azure sont certifiés ISO 27001 et audités SOC 2 Type II, et Microsoft publie les rapports d'audit qu'une banque peut présenter aux inspecteurs de la CBK chargés d'examiner un déploiement dans le cloud. La documentation de conformité Banking & Financial Services de Microsoft fournit la base de preuves permettant de démontrer la conformité réglementaire.

Des services gérés qui allègent la charge informatique

Le principal avantage opérationnel du cloud par rapport au sur site est la suppression de la gestion de l'infrastructure. Azure Kubernetes Service (AKS) gère automatiquement le plan de contrôle Kubernetes : provisionnement des nœuds, correctifs de sécurité, répartition entre zones de disponibilité et mise à l'échelle. Azure Database for PostgreSQL Flexible Server gère la disponibilité, les sauvegardes et les correctifs de la base de données. Azure Service Bus fournit une file de messages gérée, adossée au SLA de disponibilité de 99,9 % de Microsoft.

Pour des équipes informatiques bancaires déjà sollicitées par de multiples priorités technologiques, confier la gestion de l'infrastructure aux services gérés d'Azure peut suffire largement à justifier le coût d'abonnement récurrent.

La rapidité de déploiement

Le déploiement d'une plateforme LBC/FT dans le cloud est nettement plus rapide que le déploiement sur site. Sans les délais d'acquisition et d'installation en baie, l'infrastructure peut être provisionnée par le code en quelques heures plutôt qu'en plusieurs semaines. Un déploiement cloud type demande 6 à 8 semaines entre le lancement du projet et la première transmission en production, contre 8 à 12 semaines pour le sur site (acquisition de l'infrastructure comprise).

Pour les institutions soumises à une pression réglementaire les poussant à automatiser rapidement leur dispositif LBC/FT, l'avantage de rapidité du cloud est un facteur déterminant.

---

Le déploiement hybride : le meilleur des deux mondes

Cas d'usage : données de conformité sur site, sauvegardes dans le cloud

Un modèle de déploiement hybride stocke les données de conformité principales — dossiers actifs, enregistrements de transactions, dossiers de déclarations de soupçon et de déclarations des transactions en espèces (STR/CTR), journaux d'audit — sur une infrastructure sur site, et utilise le stockage cloud pour la réplication des sauvegardes. Il répond ainsi à la préférence de la CBK et du FRC pour la souveraineté des données principales, tout en tirant parti de l'économie et de la résilience du cloud pour la reprise après sinistre.

Les services principaux de la plateforme LBC/FT fonctionnent sur site. Les sauvegardes nocturnes de la base de données PostgreSQL sont chiffrées et répliquées vers Azure Blob Storage (South Africa North, ou une autre région de votre choix). En cas de sinistre, la plateforme peut être restaurée dans le cloud à partir de la sauvegarde la plus récente, en acceptant un objectif de point de reprise d'un jour et un objectif de délai de reprise qui se compte en heures.

Une migration par étapes pour les banques qui quittent un système historique

Pour les banques qui migrent d'anciens systèmes LBC/FT vers des plateformes modernes, un déploiement hybride permet une transition par étapes. La nouvelle plateforme est déployée dans le cloud pour les nouvelles transmissions et les dossiers de la période en cours, tandis que l'ancien système continue de répondre aux requêtes sur les données historiques. Au fil du temps, les données historiques sont migrées vers la nouvelle plateforme et l'ancien système est mis hors service. On évite ainsi une bascule de migration en mode « big bang » et les risques qui l'accompagnent.

---

Grille de décision : quelle option pour votre institution ?

---

Points de mise en œuvre propres à chaque modèle

Dimensionnement du matériel sur site

Les besoins matériels dépendent principalement du volume de transactions, du nombre d'utilisateurs simultanés côté conformité ainsi que de la fréquence et de l'ampleur des traitements par lots des CTR. À titre indicatif, pour les banques d'Afrique de l'Est :

Petite institution (moins de 100 000 comptes, un seul pays) : 2 serveurs d'application (8 cœurs de processeur et 32 Go de RAM chacun), 1 serveur de base de données (16 cœurs de processeur, 64 Go de RAM, 2 To de SSD), 1 To de stockage SAN pour les sauvegardes.

Institution de taille moyenne (100 000 à 500 000 comptes, 1 à 2 pays) : 3 serveurs d'application (16 cœurs de processeur et 64 Go de RAM chacun), 2 serveurs de base de données en configuration haute disponibilité (32 cœurs de processeur, 128 Go de RAM, 5 To de SSD), 5 To de stockage SAN avec réplication hors site.

Grande institution (500 000 comptes et plus, plusieurs pays) : une étude de dimensionnement professionnelle est recommandée, fondée sur les volumes de transactions et les besoins de traitement par lots propres à l'institution.

Cloud : prérequis de l'abonnement Azure et connectivité avec les CRF

Les déploiements Azure nécessitent un abonnement Azure doté de quotas de ressources adaptés, une configuration d'appairage de réseaux virtuels (peering) pour la connectivité privée, et des règles de groupe de sécurité réseau autorisant le trafic HTTPS sortant vers les points de terminaison du portail de la CRF compétente dans chaque pays. Tout accès entrant aux services de conformité est authentifié par clés d'API et JWT : aucun service de conformité n'est accessible publiquement sans authentification.

Les portails des CRF du Kenya, de l'Ouganda, de la Tanzanie, de la Zambie et du Rwanda sont tous accessibles via l'Internet public, en HTTPS. Les déploiements Azure se connectent à ces portails au moyen d'une passerelle NAT dotée d'une adresse IP sortante statique, que la CRF peut inscrire sur liste blanche si nécessaire.

Pour les deux modèles : configuration de Kubernetes, calendrier des sauvegardes et fenêtres de maintenance

Quel que soit le modèle de déploiement, la plateforme LBC/FT nécessite :

• Un cluster Kubernetes (sur site : RKE2 ou K3s sur serveurs physiques ; cloud : AKS) d'au moins 3 nœuds pour la haute disponibilité
• Une base de données PostgreSQL 15 avec une sauvegarde automatisée configurée pour s'exécuter au moins chaque nuit, et une conservation des sauvegardes d'au moins 90 jours pour la restauration (les sauvegardes ne sont pas l'archive des documents LBC/FT : au Kenya, ces documents doivent être conservés au moins sept ans)
• Un registre d'images de conteneurs (sur site : Harbor ou Docker Registry ; cloud : Azure Container Registry) pour stocker et versionner les images des services
• Des fenêtres de maintenance définies pour les mises à jour de la plateforme, planifiées en heures creuses et communiquées à l'avance aux responsables de l'équipe conformité

---

Passez à l'étape suivante

La plateforme de déclaration goAML de Creodata est conçue pour se déployer proprement sur site, sur Azure ou en configuration hybride — avec les mêmes fonctionnalités et les mêmes capacités de conformité, quel que soit le modèle de déploiement. Notre équipe de mise en œuvre a réalisé des déploiements selon ces trois modèles dans des environnements bancaires d'Afrique de l'Est et peut vous conseiller sur l'option la mieux adaptée au profil réglementaire, aux capacités informatiques et aux contraintes de calendrier de votre institution.

Échangez avec notre équipe sur vos besoins de déploiement : Demander une démo sur creodata.com/demo