MonAGIL

Monagil est une marketplace qui met en relation des gestionnaires de biens et conciergeries avec des artisans (plombiers, électriciens, agents de ménage…). Un gestionnaire déclare ses logements, crée une demande d'intervention, et la plateforme prévient les artisans compétents à proximité. Ensuite viennent l'intervention, la clôture, la facturation et le paiement.ProblématiqueL'API existante, un monolithe Symfony, avait atteint ses limites :- Logique métier concentrée dans quelques fichiers énormes. Chaque évolution devenait risquée et coûteuse, et rien n'était testable de façon isolée.- Traitements fragiles reposant sur des crons. La diffusion des demandes aux artisans, les notifications et la facturation passaient par des tâches planifiées. En cas d'erreur, rien n'était relancé et aucune trace n'était visible : un artisan pouvait ne jamais être prévenu, une facture ne jamais être émise.- Dépendances techniques figées. Le prestataire de paiement MangoPay a été abandonné et le service de géocodage était codé en dur, sans alternative possible.- Contrainte forte de continuité. La nouvelle API doit fonctionner sur la base de données de production existante, sans interrompre le service ni casser l'application mobile et web déjà en place.<h1>Solution apportée</h1>J'ai conçu et développé une nouvelle API en PHP 8.4, Symfony 8 et API Platform 4, avec une architecture DDD hexagonale + CQRS.1. Architecture découpée par domaines métier- Neuf contextes indépendants : Authentification, Autorisation, Utilisateurs, Logements, Catalogue de prestations, Demandes d'intervention, Facturation, Notifications et un socle partagé.- Chaque contexte est découpé en couches Domaine / Application / Infrastructure / UI. Les règles métier ne dépendent ni du framework ni de la base de données.- Les commandes, requêtes et événements passent par des bus distincts. Chaque cas d'usage correspond à une classe dédiée, lisible et testable.2. Fiabilité des traitements asynchrones- Une architecture événementielle remplace les crons : par exemple, « demande créée » déclenche la diffusion aux artisans et l'émission du devis.- J'ai mis en place le pattern Outbox. Les événements sont enregistrés en base dans la même transaction que la donnée métier, puis un worker dédié les relaie vers RabbitMQ. Aucun événement n'est perdu si le broker est indisponible, et les échecs restent visibles (nombre de tentatives, dernière erreur).- Tous les traitements sont idempotents. Si un message est reçu deux fois, l'artisan n'est pas notifié deux fois et aucune facture n'est émise en double.3. Fonctionnalités métier reprises et fiabilisées- Authentification : JWT, refresh token et déconnexion.- Comptes : inscription artisan et gestionnaire, validation par email, réinitialisation du mot de passe, informations personnelles, photo de profil, solde artisan.- Logements : création, mise à jour et consultation. Les coordonnées GPS sont calculées automatiquement à la création.- Catalogue de prestations et tarification.- Demandes d'intervention : création, puis sélection des artisans éligibles selon la prestation, la distance et les disponibilités. Ils reçoivent une notification push (Firebase) et un email, et le demandeur reçoit un accusé de réception.- Facturation automatisée via l'API VosFactures, avec une politique explicite pour chaque étape : - à la création de la demande : devis ; - à la clôture : facture gestionnaire et relevé artisan, avec un traitement différent pour un paiement par carte ou par virement ; - à l'encaissement d'un virement : facture marquée payée.4. Fournisseurs externes interchangeables- Le géocodage peut passer par la Base Adresse Nationale, Google ou Nominatim. On change de fournisseur par configuration, sans toucher au code.- La facturation (VosFactures) et les notifications (Firebase, email) sont isolées derrière des interfaces. Remplacer un prestataire ne touche pas le métier.5. Migration progressive sans interruption- La nouvelle API fonctionne sur le schéma existant.- Des commandes de migration par lots attribuent des identifiants UUID aux données historiques (utilisateurs, logements, demandes), ce qui permet aux deux API de cohabiter pendant la transition.6. Qualité et industrialisation- Environ 240 tests automatisés (Pest), en unitaire et en fonctionnel, avec des doubles en mémoire. Ils sont rapides et ne dépendent d'aucun service externe.- L'environnement est entièrement dockerisé : PHP-FPM, MariaDB, RabbitMQ, Redis, des workers dédiés (relais outbox et consommateurs d'événements) et un serveur de test d'emails.Résultats- Un code découpé, testé et documenté : on peut faire évoluer un domaine sans risquer d'en casser un autre.- Des traitements critiques (diffusion aux artisans, facturation) fiables, rejouables sans risque et traçables.- La possibilité de changer de prestataire (paiement, géocodage, facturation) sans réécrire le métier.- Une migration progressive, sans arrêt du service ni impact pour les utilisateurs actuels.Stack : PHP 8.4, Symfony 8, API Platform 4, Doctrine ORM 3, Messenger, RabbitMQ, Redis, MariaDB, JWT, Firebase Cloud Messaging, VosFactures, Docker, Pest, Stripe.

Application de mise en relation entre gestionnaires de bien et artisans

Clean Architecture

Hexagonal Architecture

Fullstack Development

WhatBoutik

En Afrique et même parfois en Europe, les petits commerçants, restaurants et créateurs vendent déjà massivement sur WhatsApp, mais sans outil adapté. Ils renvoient sans cesse les mêmes photos et tarifs, répondant aux mêmes questions avec quelques fois des pertes de commandes dans les conversations, ou tout simplement parce que n'ayant pas répondu à une demande. Les solutions e-commerces classiques ne sont pas adaptés car trop complexes ou ne prenant pas en compte le paiement mobile.J'ai donc conçu et développé WhatBoutik, une plateforme SaaS qui permet à chaque vendeur de créer sa boutique en ligne en quelques minutes:<ul><li>Vitrine et catalogue en ligne</li><li>Commande via WhatsApp: le client commande directement via WhatsApp </li><li>Bot conversationnel 24h/24: il répond aux clients et permet la prise de commandes</li><li>Paiement direct au vendeur: l'outil permet à l'acheteur de payer directement via différents moyens de paiement intégrant notamment le paiement mobile (Orange, MTN...) . La plateforme ne manipule à aucun moment l'argent. Chaque vendeur configure son mode paiement en fonction ce ceux disponible dans sa région.</li></ul>Solution et choix d'archhitecture:Clean Architecture : le code est organisé en couches concentriques (Domain, Application, Infrastructure, UI). Le domaine métier (Boutique, Produit, Commande, Vendeur) est indépendant du framework, de la base de données et des services externes. WhatsApp, les fournisseurs de paiement et la persistance sont des adaptateurs branchés sur des ports définis par le domaine.CQRS : les écritures (créer une boutique, passer une commande, confirmer un paiement) sont séparées des lectures (afficher une vitrine, lister les commandes d'un vendeur). Chaque cas d'usage est une commande ou une requête traitée par un handler dédié, ce qui rend la logique métier explicite, testable unitairement et facile à faire évoluer.Architecture multi-tenant : chaque vendeur dispose de sa boutique isolée sur une plateforme commune.Commerce conversationnel : le client parcourt une vitrine web et la commande est transmise sur WhatsApp. Un bot traite les demandes 24h/24 via API WhatsApp BusinessDécouplage volontaire du flux financier : la plateforme n'encaisse jamais pour le compte des vendeurs. Chaque boutique déclare son propre moyen d'encaissement en fonction de son pays : Stripe, Paypal, MTN Mobile Money, agrégateurs comme Nyole ou paiement à la livraison. Ce choix évite le statut d'intermédiaire de paiement et ses contraintes réglementaires, supprime la dépendance à un prestataire unique et retire l'étape KYC de l'inscription vendeur. Stack: Symfony, API Platform, Angular 21, MySQL, API WhatsApp Business, Docker, Github Action, Stripe, Paypal, MTN Mobile Money, Nyole.

Application permettant à n'importe quel vendeur de créer en quelques minutes une boutique en ligne reliée à WhatsApp : ses clients parcourent le catalogue et commandent directement, sans application à installer.

Domain Driven Design

Cyberdiplômé avancé

Introduction à la programmation orientée objet (en Java)

Initiation à la programmation (en Java)

Developpeur Backend PHP

Développeur web

Développeur Full Stack

Developpeur-Concepteur

Développeur Web

Developpeur PHP

- Maintenance et développement de sites internet et intranet
- Formation des utilisateurs
- Spécifications fonctionnelles
- Rédaction de manuels utilisateurs

- Maintenance et développement de nouvelles fonctionnalités pour le logiciel de gestion de caisse E-necy

Développeur PHP

- Rédaction du cahier des charges pour la création du site internet de la MEF-PSA
- Développement du site internet

Emile Camara dit Delassus

Developpeur Backend PHP

À propos

Expérience de travail

Développeur web

Développeur Full Stack

Developpeur-Concepteur

Développeur Web

Developpeur PHP

Developpeur PHP

Développeur PHP

Chargé de projet WEB (Stage)

Formation

Université de Picardie Jules Verne (Amiens)

Licences et certifications

Cyberdiplômé avancé

Introduction à la programmation orientée objet (en Java)

Initiation à la programmation (en Java)

Portfolio

MonAGIL

MonAGIL

WhatBoutik

WhatBoutik

Talents

Recruteurs

À propos