Cofondateur & Directeur Technique d'Intelart Technology. Plus de 8 ans à concevoir, construire et faire évoluer des architectures cloud résilientes — dispatch temps réel, paiements, santé numérique — du prototype à la production.
Basé à Yaoundé, je travaille depuis plus de huit ans sur des systèmes qui doivent rester debout sous la charge réelle : plateformes de dispatch temps réel, moteurs de facturation, applications de santé numérique multi-sites.
En tant que Cofondateur et Directeur Technique d'Intelart Technology, je conjugue exécution technique directe — architecture, code, revue — et vision produit : sécurité, résilience multi-cloud, et intégration réfléchie de l'intelligence artificielle quand elle apporte une vraie valeur.
En parallèle, j'interviens comme consultant IT indépendant : audits techniques, synthèses de pilotage pour des directions générales, et encadrement d'équipes de développement.
Sur ces projets, je n'exécutais pas un cahier des charges remis par quelqu'un d'autre — j'ai identifié le problème moi-même, décidé de la solution, et livré.
Une grande partie des invendus alimentaires des commerçants locaux finit jetée en fin de journée, faute de canal simple pour les écouler à prix réduit avant fermeture.
J'ai conçu et développé seul une plateforme complète — API Laravel, interface Next.js, application Flutter — permettant à un commerçant de publier ses invendus en quelques secondes et à un client de réserver et venir les récupérer, avec verrouillage transactionnel pour éviter la survente.
Un produit fonctionnel de bout en bout (mobile + web + API), un business plan formalisé, et une architecture pensée dès le départ pour un passage à l'échelle (authentification JWT RS256, séparation claire des rôles vendeur/client).
L'analyse des données de production a révélé un taux de complétion des courses faible et une proportion élevée d'annulations et d'échecs d'attribution (« NO DRIVER FOUND »), en partie liés à une interface perçue comme datée face aux standards Uber/Bolt.
Refonte complète de la couche visuelle de l'application pour aligner l'expérience sur les standards du secteur, en conservant la logique métier BLoC existante — sans casser les intégrations Firebase en production.
Une expérience utilisateur modernisée, livrée sans interruption de service, posant les bases pour mesurer l'effet de l'interface sur la conversion et la rétention conducteur.
Les mêmes données de production ont mis en évidence des incohérences dans la logique d'attribution des courses (erreurs de nommage de modèles Eloquent, requêtes géospatiales mal formées), contribuant directement aux échecs d'attribution.
Diagnostic ligne par ligne de la chaîne d'attribution, correction des requêtes géospatiales (ST_Distance_Sphere), stabilisation des instances BLoC par onglet conducteur, et ajout d'une preuve de livraison avec signature électronique.
Une logique d'attribution de courses plus fiable et une chaîne conducteur→livraison correctement instrumentée, réduisant les sources connues d'échec silencieux.
Conception et migration monolithe → microservices, gestion de flux temps réel à forte concurrence, cohérence des données sur plusieurs environnements.
Flutter/BLoC, Next.js, Laravel — de l'interface au schéma de base de données, avec une attention constante à la maintenabilité.
Diagnostic et correction de systèmes en production : requêtes géospatiales, pagination, verrouillage transactionnel, haute disponibilité.
Multi-cloud, déploiements hors-ligne en réseau local, distribution par conteneurs et protection de la propriété intellectuelle logicielle.
Intégration d'intelligence artificielle dans des produits existants lorsqu'elle résout un vrai problème utilisateur — pas comme argument marketing.
Direction d'équipe de développement, revues de sprint, arbitrage de périmètre, synthèses techniques pour des directions générales.
Une partie des systèmes conçus, développés ou redressés techniquement au cours des dernières années.
Modernisation intégrale de la couche visuelle d'une application VTC pour l'aligner sur les standards Uber/Bolt, en conservant la logique BLoC et les intégrations Firebase existantes.
Preuve de livraison avec signature électronique, correctifs d'architecture BLoC (instances indépendantes par onglet), refonte de la logique d'attribution des courses.
Application anti-gaspillage alimentaire en clean architecture : parcours vendeur/client distincts, réservation d'offres synchronisée avec le back-end.
Monolithe modulaire Laravel 12 couplé à une interface Next.js 14, authentification JWT RS256, réservation d'offres avec verrouillage transactionnel côté serveur.
Plateforme de gestion de dispatch pour les partenaires CaryGoo : moteur de facturation à l'usage (quota → crédit → solde, remboursement automatique en cas d'échec), partage par QR code.
Système de gestion du risque pour une société de trading propriétaire : paliers de risque dynamiques, authentification par rôle, connecté à un Expert Advisor MQL5.
Plateforme de gestion pour centres de santé : correctifs de performance sur la pagination, architecture pensée pour un déploiement hors-ligne en réseau local.
Conception d'une architecture pouvant fonctionner en cloud multi-tenant ou en déploiement local isolé, pour des clients aux contraintes réseau variables.
Mécanisme de distribution par images Docker, obfuscation du code PHP et vérification de licence pour des déploiements SaaS chez des clients multiples.
Diagnostic et correction de la logique d'attribution de courses : requêtes géospatiales, cohérence des modèles de données, réduction des échecs d'attribution.
Synthèses techniques hebdomadaires livrées à une Direction Générale, sur plusieurs projets menés en parallèle avec des priorités et risques clairement arbitrés.
Audit d'une application mobile en amont d'un chantier de remédiation : cartographie des accès, des vulnérabilités et priorisation des correctifs.
Pilotage de revues de sprint, synthèses individuelles et collectives, arbitrage de périmètre pour consolider les acquis techniques plutôt que disperser l'effort.
Plutôt qu'une liste de plus, voici comment j'ai raisonné sur deux problèmes concrets — la contrainte, les options envisagées, la décision et pourquoi.
Comment facturer un dispatch de manière fiable quand trois sources de solde coexistent — sans jamais double-débiter ni bloquer un partenaire à tort.
Les partenaires CaryGoo consomment des dispatches selon trois sources différentes selon leur plan : un quota inclus, des crédits achetés, ou un solde de compte. Un dispatch peut échouer après la consommation (échec de création de course, de paiement) — il fallait rembourser automatiquement sans jamais laisser le système dans un état incohérent.
Aucune double consommation possible, même en cas d'erreur partielle en cours de traitement.
Débiter après confirmation complète — rejetée : trop tard pour empêcher un partenaire à sec de lancer plusieurs dispatches en parallèle.
Consommation immédiate dans l'ordre quota → crédit → solde, avec un remboursement explicite déclenché depuis le bloc catch de la création de dispatch.
Un seul point d'entrée de facturation, testable indépendamment, et une logique de remboursement qui ne dépend d'aucun état applicatif externe.
Quelques retours de clients, partenaires et collègues sur la façon dont je conçois et pilote les projets techniques.
« Cédric a une qualité rare chez un CTO : il descend dans le code quand il le faut, mais ne perd jamais de vue l'impact business de ce qu'on construit. On lui confie un problème flou, il revient avec une architecture claire et un plan d'exécution. »
« Ce qui m'a marqué, c'est sa rigueur sur les sujets de sécurité et de protection des données — dès la phase de conception, pas après coup. On sentait qu'il avait déjà géré ce genre de contrainte en production. »
« En tant que junior sur l'équipe, j'ai beaucoup appris de sa façon d'expliquer un choix d'architecture avec des mots simples, sans jamais donner l'impression que la question était trop basique. »
Un graphe de services avec une vraie physique (forces de répulsion/ressort) et un vrai calcul de plus court chemin (Dijkstra). Clique sur un nœud pour le mettre en panne — le système recalcule sa route sans interruption du trafic.
Un émulateur de terminal qui exécute réellement, ligne par ligne, des scripts d'automatisation représentatifs de mes déploiements — build, tests, conteneurisation, migrations sécurisées.
Un flux d'activité technique
Disponible pour des rôles d'ingénierie senior, des missions d'architecture cloud, ou du conseil technique ponctuel.
Me contacter