Vue d’ensemble
Dossier est une plateforme B2B de recherche et de personnalisation conçue pour aider les équipes de prospection commerciale à créer des campagnes de courriels à froid pertinentes à grande échelle. Elle automatise la recherche sur les prospects, évalue la qualité des données, génère des variantes de courriels personnalisés et valide les résultats avant la livraison.
Exigences
Personnaliser manuellement des courriels à froid prend beaucoup de temps, surtout lorsqu’il faut traiter des centaines de prospects. Les automatisations existantes produisent souvent des messages génériques ou s’appuient sur des informations incomplètes. Le défi était de construire un système capable d’automatiser la recherche et la personnalisation tout en maintenant la qualité des données, la fiabilité et la cohérence.
Implémentation
J’ai développé un pipeline backend en plusieurs étapes qui prend en charge l’ingestion des prospects, la recherche automatisée, la notation de la qualité, la génération de courriels et la validation. Chaque prospect passe par une série d’états suivis, ce qui permet au système de repérer les échecs, de relancer les opérations infructueuses et d’empêcher la livraison de résultats incomplets.
Ma contribution
J’étais responsable de l’architecture backend, de la conception de la base de données, de l’orchestration des workflows, des intégrations d’API externes et de la logique de recherche. J’ai mis en place la notation des recherches, la gestion des échecs, les mécanismes de reprise et les contrôles de qualité. J’ai également travaillé sur la surveillance et l’amélioration du pipeline à partir des problèmes découverts lors de livraisons réelles.
Décisions techniques
J’ai utilisé PostgreSQL pour persister les états des workflows et suivre chaque prospect tout au long du pipeline. La notation des recherches aidait à distinguer les informations utiles des résultats incomplets, tandis que les contrôles de validation empêchaient les sorties de faible qualité de progresser. Les mécanismes de reprise et le suivi des tâches en échec définitif facilitaient l’analyse et la récupération sans perdre le travail déjà terminé.
Défis
L’un des principaux défis était de gérer les réponses imprévisibles des fournisseurs de recherche externes. Certaines requêtes échouaient, tandis que d’autres renvoyaient des informations incomplètes ou incohérentes. Un autre défi était la gestion des échecs partiels entre plusieurs étapes du workflow, particulièrement lors du traitement de lots plus importants.
Ce que j’ai appris
Passer d’un pilote de 100 prospects à une livraison de 500 prospects m’a montré à quel point les petits problèmes de fiabilité deviennent rapidement plus visibles à grande échelle. J’ai appris l’importance de suivre les états de chaque workflow, de valider les données avant de les utiliser et de concevoir des mécanismes de récupération pour les échecs partiels. J’ai aussi appris qu’une requête API réussie ne signifie pas nécessairement un résultat réussi, et que surveiller la qualité des données est aussi important que surveiller l’exécution.
Résultat
Dossier a été testé lors d’un pilote externe portant sur 100 prospects documentés, suivi d’une livraison plus importante de 500 prospects. La deuxième livraison a révélé des difficultés liées à la cohérence des données, au comportement des reprises et à la visibilité opérationnelle. Ces expériences ont permis de repérer les améliorations nécessaires à la fiabilité et au traitement de volumes plus importants.
Ce que j’améliorerais
J’améliorerais la visibilité opérationnelle en ajoutant un tableau de bord centralisé pour suivre les états des prospects, les raisons des échecs et les temps de traitement. J’explorerais aussi des stratégies de reprise plus adaptatives, des mesures plus solides de la qualité des recherches et un meilleur suivi des coûts des API externes. Ces améliorations rendraient le système plus facile à maintenir et plus prévisible lors de livraisons importantes.