Le problème
AGROCAM S.A. est une entreprise agro-industrielle camerounaise qui gère l'intégralité de ses opérations — RH, comptabilité, achats, commandes clients, chaîne d'approvisionnement — sur un système monolithique legacy. L'architecture ne passait plus à l'échelle. Ajouter un module risquait de faire tomber le reste. Les agents terrain en zone reculée n'avaient aucun moyen d'enregistrer des opérations sans connexion. Et la chaîne d'approvisionnement n'avait aucune traçabilité immuable — pourtant indispensable pour la conformité et le contrôle qualité dans le secteur alimentaire.
L'objectif : remplacer ce système par une architecture distribuée moderne, conçue pour les contraintes opérationnelles africaines réelles.
Le problème de connectivité
Les agents terrain travaillent dans des zones sans internet fiable. Tout système nécessitant une connexion permanente était inutilisable — et les pertes de données sur le terrain sont inacceptables.
Le problème de conformité
La loi camerounaise (n°2010/012) impose que les données RH et financières restent sur le territoire national. Une approche 100% cloud n'était pas légalement viable.
Le problème de traçabilité
La chaîne d'approvisionnement n'avait aucun audit immuable. Les enregistrements d'expéditions pouvaient être modifiés après coup — un risque de responsabilité pour un producteur alimentaire.
Le problème de scalabilité
Le système monolithique ne permettait pas de mises à jour modulaires. Chaque changement risquait de casser d'autres parties du métier — le développement avançait au ralenti.
Ce que j'ai construit
5 microservices isolés avec une API Gateway comme point d'entrée unique — centralisant JWT/OAuth2, le rate limiting, et jouant le rôle de reverse proxy. Les services métier ne valident jamais les tokens directement ; ils font confiance aux en-têtes injectés par le gateway. Chaque service possède sa propre base PostgreSQL avec un schéma dédié et 17 index de performance.
RBAC granulaire (5 rôles) : admin, manager, comptable, agent_terrain, analyste — chacun avec une matrice d'accès précise appliquée par des middlewares partagés entre tous les services. Un agent terrain ne voit que CRM et Supply Chain. Un comptable ne voit que l'ERP. Zéro fuite de données cross-modules par construction.
Supply Chain offline-first : Conçu spécifiquement pour les agents en zones de faible connectivité. Un endpoint POST /sync/push accepte un lot d'opérations INSERT/UPDATE/DELETE avec un offline_id pour la déduplication côté serveur. Un worker Redis traite la queue toutes les 30 secondes avec mécanisme de retry et dead-letter — les opérations saisies hors ligne se synchronisent automatiquement dès que la connexion revient.
Traçabilité blockchain immuable (Hyperledger Fabric) : Chaque expédition et checkpoint est enregistré sur la blockchain Fabric via un chaincode de 147 lignes. getHistoryForKey() fournit des historiques d'audit complets. Une fonction verifyChainIntegrity() valide l'intégrité de toute la chaîne — chaque checkpoint est lié au précédent via un index composite. Les enregistrements ne peuvent pas être modifiés rétroactivement.
BI Service (FastAPI/Python) : Agrège les KPIs de tous les services via HTTP avec cache Redis de 5 minutes. Expose des endpoints de snapshots, tendances, et tableaux de bord — donnant à la direction une visibilité temps réel sur l'ensemble de l'opération sans requêter les bases de production directement.
Infrastructure cloud hybride : AWS af-south-1 (Cape Town) pour le compute — ECS Fargate, RDS PostgreSQL Multi-AZ, ElastiCache Redis, ALB. Azure South Africa North pour l'identité entreprise (Azure AD). On-premise Douala pour les données RH et financières (conformité légale). Entièrement géré par Terraform via 8 modules, avec rotation des secrets (90 jours) et monitoring GuardDuty.
Pipeline CI/CD (GitHub Actions, 5 étapes) : Lint → Tests Jest → Lint Python (Ruff) → Build Docker multi-stage + push ECR → Deploy ECS. Environnements staging et production séparés.
Impact
Zéro perte de données terrain
L'architecture offline-first permet aux agents de travailler sans connexion. Les opérations sont mises en queue localement et synchronisées automatiquement — plus de ressaisie manuelle, plus d'enregistrements perdus.
Conformité légale complète
Les données RH et financières restent on-premise à Douala (loi camerounaise n°2010/012). L'architecture hybride a été conçue autour de cette contrainte dès le départ — pas ajoutée après coup.
Audit supply chain immuable
Chaque checkpoint d'expédition est désormais sur la blockchain. Les enregistrements ne peuvent plus être modifiés après coup — éliminant le risque de responsabilité lié aux logs mutables pour un producteur alimentaire.
~450 $/mois d'infrastructure estimée
Un système multi-cloud production-ready avec monitoring, alerting, DRP (RTO 5–60 min, RPO 5 min) et autoscaling — à un coût accessible pour une PME camerounaise.
Monitoring & Observabilité
- Prometheus : Scrape les 5 endpoints de santé des services, Redis, PostgreSQL, et les nœuds Kubernetes
- Grafana : Dashboard 7 panneaux (statut services, CPU/mémoire, Redis hit ratio, connexions PG, erreurs 5xx, logs récents)
- CloudWatch : 10 widgets incluant latence ALB/p99, IOPS RDS, Redis hit/miss, coûts estimés
- Alerting : 7 règles Prometheus couvrant ServiceDown, HighErrorRate, HighLatency, HighCPU, PGConnectionsHigh, RedisCacheMissHigh, DiskSpaceLow
Ce que cette expérience m'a appris
Concevoir pour une agro-industrie camerounaise m'a confronté à des contraintes qui n'apparaissent pas dans les architectures de manuel : agents sans connexion, réglementation sur la résidence des données, et exigences de traçabilité légale pour la chaîne alimentaire. Chaque compromis technique était dicté par le métier — pas par les préférences technologiques.
J'ai aussi appris à concevoir un système déployable de trois façons différentes (Docker Compose, Kubernetes, ECS Fargate) sans changer une ligne de code métier — une contrainte qui force une séparation plus nette entre infrastructure et application dès le départ.