Le contexte
Des consultants indépendants vendent, sur le terrain, les contrats d'une quinzaine de partenaires : fournisseurs d'énergie, opérateurs télécoms, assureurs. Chaque partenaire impose son propre formulaire de souscription, ses règles d'éligibilité, ses justificatifs et son format d'échange.
Le défi n'est pas la vente en elle-même, c'est l'hétérogénéité : ajouter un partenaire ne doit pas signifier réécrire l'application, et une modification chez l'un ne doit jamais affecter les autres.
Ce que j'ai construit
Modules de contrats par partenaire
chaque partenaire dispose de son propre périmètre : produits, offres groupées, règles de validation et documents.
Signature électronique
parcours de signature intégré au tunnel de souscription.
Génération et remplissage de documents
production des contrats en PDF, y compris le remplissage automatique de formulaires officiels fournis par les partenaires.
Notifications et campagnes
messages poussés vers l'application mobile des consultants.
Synchronisation ERP
échange bidirectionnel avec le progiciel de gestion du groupe.
Suivi commercial
conventions, portefeuille clients, historique et tableaux de bord.
Architecture & choix techniques
Le cœur de l'architecture est la séparation par partenaire. Le tronc commun gère le client, le consultant et le cycle de vie d'un contrat ; chaque partenaire branche dessus ses spécificités. C'est ce qui a permis d'en intégrer de nouveaux sans déstabiliser les existants.
Les traitements lourds — génération documentaire, notifications de masse, synchronisation ERP — sont sortis du cycle de requête et confiés à des files d'attente, puis diffusés aux autres services par un bus d'événements. Un contrat signé émet un événement ; la facturation, le support et l'ERP y réagissent chacun de leur côté, sans dépendance directe entre eux.
L'application tourne sous un serveur applicatif persistant plutôt qu'en cycle PHP classique : le framework reste chargé en mémoire entre les requêtes, ce qui réduit nettement la latence pour des consultants souvent en réseau mobile.
Le remplissage de formulaires officiels a nécessité une chaîne dédiée : les partenaires imposent leurs propres PDF, qu'il faut alimenter champ par champ puis fusionner — un besoin qu'aucune bibliothèque de rendu HTML ne couvre.
Les défis techniques
Quinze logiques métier dans une seule application. Isoler suffisamment pour que les partenaires n'interfèrent pas, factoriser assez pour éviter quinze fois le même code.
La cohérence entre services. Le bus d'événements impose de penser en asynchrone : un contrat peut être signé avant que l'ERP ne l'ait enregistré, et l'interface doit rester compréhensible dans cet intervalle.
Le terrain. Consultants en mobilité, réseau instable, appareils modestes — d'où l'attention portée à la latence et à la taille des réponses.
La donnée légale. Contrats signés, mandats, coordonnées bancaires : des données réglementées, avec journalisation des accès et validation stricte des identifiants bancaires.
La montée de version. Une application vivante pendant quatre ans traverse plusieurs versions majeures de framework, sans interruption de service.