Vue d'ensemble
Vue d'ensemble
Une architecture sobre, éprouvée, dimensionnée pour vos contraintes.
Nos choix ne sortent pas d'un catalogue. Ils découlent, un par un, de quatre chiffres de votre cahier des charges : ≤ 3 secondes en 4G, disponibilité 99,5 %, 2 000 utilisateurs simultanés, et une feuille de route qui va jusqu'à la banque. Ajoutez le bilingue FR/EN, le hors-ligne partiel et la sécurité de niveau bancaire, et vous obtenez le cahier des contraintes que voici — traduit en système.
L'architecture de bout en bout
Voici ERK+ dans son intégralité — du smartphone d'un chef de chantier jusqu'aux sauvegardes chiffrées répliquées sur trois sites. Chaque nœud porte le logo réel de sa technologie ; les points qui circulent le long des liaisons sont de vraies requêtes en vol.
ERK+ · flux & trafic temps réel
vraies requêtes, à l'échelle
Chaque client ne parle qu'à la passerelle Go en TLS 1.3 ; la passerelle distribue vers des services isolés ; la donnée ne quitte jamais sa couche. Les points sont des requêtes en vol.
Chaque couche a une seule responsabilité et une seule raison de changer. Le client ne parle jamais directement à la base de données ; la base ne connaît jamais l'identité d'un utilisateur ; le cœur métier ignore s'il est appelé depuis le web, iOS ou le logiciel de bureau. Ce cloisonnement n'est pas de la théorie : c'est ce qui rend un système auditable, testable et réparable sous pression.
La même pile, vue en volume
Six couches, un déploiement
Le style : monolithe modulaire
Nous assumons un choix à contre-courant de la mode microservices. ERK+ est un monolithe modulaire : les frontières logiques sont celles de microservices, mais il n'y a qu'un seul artefact à déployer, superviser et faire tenir à 99,5 %.
| Microservices classiques | Monolithe modulaire (notre choix) | |
|---|---|---|
| Latence interne | Réseau entre services | Nulle — appels en mémoire |
| Coût d'infra | Élevé (N services, N bases) | Divisé — décisif pour un budget africain |
| Complexité opérationnelle | Orchestration, service mesh | Un déploiement, une équipe de trois |
| Transactions | Distribuées, fragiles | ACID natives — critique pour les paiements |
| Évolution V2 | Déjà éclaté | Extraction module par module, sans réécriture |
Le pari est simple : à l'échelle d'ERK+ (une entreprise, quelques milliers d'utilisateurs), le coût des microservices est payé d'avance sans le bénéfice. Le jour où la marketplace V2 imposera de sortir le module Paiements en service indépendant, le bus d'événements est déjà là pour le faire proprement — sans toucher au reste.
Prêt pour vos V2 et V3
- Frontières de modules alignées sur vos 8 familles fonctionnelles — pas sur des tables de base de données
- Le registre de paiement V1 est déjà structuré pour des flux multi-marchands (V2) et des produits financiers (V3)
- API versionnée et documentée dès le premier jour : ce qui est publié ne casse jamais un client existant