Le projet en un coup d’œil
Dans l’assurance automobile, un parcours de souscription ne supporte ni les ruptures de données ni les statuts ambigus. Une offre, un véhicule, un IBAN ou une signature mal propagés peuvent laisser un dossier commercialement avancé mais inexploitable par la gestion.
Pour Opteven, Dawap a construit deux applications complémentaires. La première guide la souscription jusqu’au contrat signé et orchestre HubSpot, l’ERP métier et DocuSign. La seconde organise les partenaires, contrôle leurs fichiers et transmet les contacts qualifiés. Ce chantier réunit une refonte de logiciel métier et une véritable intégration API.
La valeur du projet tient dans cette continuité : chaque étape garde son état, les systèmes externes restent contenus derrière des contrats dédiés et une erreur d’échange peut être reliée à la transaction qui l’a produite.
1. Présentation du client
Comprendre le contexte business avant la solution
Opteven conçoit et gère des garanties et services automobiles. Le parcours étudié doit réunir qualification, véhicule, offre, informations du souscripteur, coordonnées bancaires, document contractuel et signature.
Le dispositif implique aussi un réseau de partenaires qui apporte des dossiers au moyen de fichiers structurés. Ces fichiers doivent être contrôlés ligne par ligne avant que les contacts soient créés ou mis à jour dans HubSpot.
Le besoin n’était donc pas d’ajouter un formulaire isolé, mais d’articuler parcours public, back-offices, règles d’assurance et systèmes externes dans un ensemble lisible.
2. Méthode projet Dawap
Analyse, priorisation, delivery agile et sécurisation du run
La logique du produit part des objets réellement manipulés : partenaires, contacts, véhicules, offres, formules, polices, transactions et documents. Ce découpage donne une responsabilité claire à chaque étape.
La souscription progresse en six états : création du lead, sélection de l’offre, informations personnelles, IBAN, signature DocuSign et finalisation. Le second socle traite en parallèle les partenaires, leurs fichiers, les contrôles de lignes et le déploiement vers HubSpot.
La qualité repose sur 156 classes PHPUnit réparties entre services métier, accès aux données et contrôleurs. Les deux applications disposent aussi d’images distinctes pour les environnements de validation et de production.
3. Contexte Opteven
Faire tenir le parcours commercial, contractuel et partenaire dans un même dispositif
La souscription automobile associe une personne, un véhicule, une offre, une formule et une police. Chacun de ces éléments doit rester cohérent quand le dossier passe du parcours web au CRM, à la signature puis à la gestion.
En parallèle, les partenaires transmettent des fichiers de contacts qui doivent être contrôlés avant intégration. Une ligne invalide ne doit ni bloquer toute la lecture du lot, ni entrer silencieusement dans le CRM.
Ces deux besoins partagent le même enjeu : rendre chaque transition explicite au lieu de laisser les équipes reconstituer le dossier entre plusieurs outils.
4. Objectifs métier
Industrialiser sans effacer les règles d’assurance
Le premier objectif était de donner une progression explicite à la transaction. Tant que l’offre, les informations personnelles, l’IBAN ou la signature ne sont pas prêts, l’étape suivante ne doit pas être activée par erreur.
Le deuxième consistait à conserver la cohérence entre le dossier local, le contact HubSpot, la police connue de l’ERP et l’enveloppe DocuSign.
Le troisième concernait les partenaires : importer leurs fichiers, contrôler chaque ligne, distinguer souscription et renouvellement, puis transmettre les contacts valides sans traiter tout le fichier comme un bloc opaque.
5. Deux applications complémentaires
Séparer la souscription de la gestion des apports partenaires
L’application de souscription rassemble programmes, groupes, offres, formules, véhicules, polices et transactions. Ces objets structurent le parcours autour des données nécessaires au contrat.
Le portail partenaire gère produits d’assurance, utilisateurs invités, modèles de fichiers, imports, lignes de contrôle et contacts à transmettre.
Cette séparation évite de surcharger le parcours public avec des opérations de gestion, tout en gardant des contrats d’échange explicites entre les deux usages.
6. Architecture API
Découpler le métier des systèmes externes
Les services métier manipulent leurs propres contrats de lecture et d’écriture. Les connecteurs HubSpot, ERP et DocuSign restent dans la couche d’infrastructure : leurs formats ne dictent pas toutes les règles de la souscription.
Les appels externes alimentent un journal de monitoring avec le service appelé, la requête, la réponse et son statut. Une anomalie reste ainsi rattachée à l’échange qui l’a produite.
Cette architecture rejoint notre approche de création d’API sur mesure : construire une frontière métier stable devant des systèmes qui évoluent selon leurs propres contraintes.
7. Souscription en six étapes
Du lead au contrat finalisé
La transaction commence par le lead, puis enchaîne la sélection de l’offre, la collecte des informations, la saisie de l’IBAN, l’affichage DocuSign et la finalisation.
Les dates de police tiennent compte de la situation connue dans l’ERP, de la durée de la formule et d’une éventuelle information CRM. La prise d’effet n’est donc pas réduite à une valeur libre dans un formulaire.
L’utilisateur avance dans un parcours lisible, tandis que les services métier contrôlent les données nécessaires à chaque changement d’état.
8. HubSpot, ERP et DocuSign
Prolonger le dossier au-delà du formulaire
HubSpot sert à rechercher et mettre à jour le contact, le véhicule et les informations documentaires utiles au parcours.
Le connecteur ERP recherche notamment les véhicules et polices existants, puis reçoit les informations de la transaction lorsque le document signé est prêt.
DocuSign porte l’enveloppe et son statut. Un webhook et des commandes dédiées récupèrent le document signé puis déclenchent les propagations CRM et ERP.
9. Traitements asynchrones
Isoler les trois actions qui suivent la signature
La récupération du document signé, sa mise à jour dans le CRM et sa transmission à l’ERP ne sont pas regroupées dans une seule requête longue.
Symfony Messenger affecte un transport à chaque action. Une stratégie de reprise autorise trois tentatives avant d’orienter le message vers la file d’échec.
Cette séparation conserve le contexte de la transaction lorsqu’un service externe connaît une indisponibilité temporaire et évite de rejouer tout le parcours.
10. Sécurité et traçabilité
Protéger les dossiers et expliquer les échanges
Les espaces d’administration et de gestion sont protégés par les rôles applicatifs, tandis que les secrets HubSpot et DocuSign sont injectés par la configuration des environnements.
Les webhooks et retours d’autorisation disposent de routes dédiées. Les documents signés sont stockés via une couche de fichiers séparée du cœur métier.
Le monitoring des appels externes rend un échec HubSpot, ERP ou DocuSign plus simple à qualifier qu’un statut global sans contexte.
11. Portail partenaires et fichiers
Contrôler un apport de contacts ligne par ligne
Un fichier partenaire suit son propre cycle : réception, extraction, contrôle, validation puis déploiement. Ses lignes conservent chacune leur état.
Les contacts valides sont ensuite créés ou mis à jour dans HubSpot. Cette chaîne donne un point de contrôle entre le fichier reçu et le CRM.
Le portail gère aussi les partenaires, leurs utilisateurs, leurs produits d’assurance et leurs modèles de fichiers, afin que chaque import soit interprété dans le bon contexte.
12. Scénario terrain
Une souscription qui doit rester cohérente jusqu’au document signé
Un conducteur choisit une offre, complète ses informations et son IBAN, puis ouvre la signature DocuSign. La transaction conserve son étape et les références nécessaires au passage suivant.
Après signature, la plateforme récupère le document, le rattache au dossier et déclenche les traitements vers HubSpot et l’ERP. Chaque système reçoit l’information adaptée à son rôle.
Si un appel externe échoue, le monitoring et les messages séparés indiquent quelle propagation doit être reprise. Le reste du parcours n’a pas besoin d’être rejoué à l’aveugle.
13. Gains opérationnels
Une continuité observable plutôt que des promesses abstraites
La souscription dispose d’un état explicite à chaque étape, de l’offre jusqu’à la finalisation. Les règles de date, de véhicule, de formule et de police vivent dans des services identifiables.
Le document signé poursuit son chemin vers le CRM et l’ERP sans nouvelle saisie dans le parcours. Les équipes peuvent relier une erreur à l’appel externe concerné.
Le portail partenaire apporte la même lisibilité aux fichiers : un lot, des lignes contrôlées, des statuts et un déploiement HubSpot traçable. Ce sont les gains démontrés par le produit, sans extrapoler un taux de conversion non mesuré.
14. Conclusion
Pourquoi ce projet donne envie de travailler avec Dawap
Le projet Opteven montre qu’une souscription connectée se joue autant dans les transitions que dans les écrans. Une offre sélectionnée, une signature reçue ou un fichier partenaire n’ont de valeur que si leur état reste compréhensible dans le système suivant.
La séparation entre règles métier, connecteurs et traitements asynchrones permet d’enrichir les produits, les partenaires ou les échanges sans réécrire tout le parcours.
Pour reprendre un dispositif comparable, notre expertise en intégration API, en intégration HubSpot, en intégration DocuSign et notre approche des services réglementés permettent de traiter ensemble parcours, données et exploitation.
