Data enrichment : le guide d'achat complet (édition 2026)

Le match rate, c'est le chiffre qui ouvre toutes les démos vendor. C'est aussi le plus facile à gonfler. Un provider qui vous annonce 85% sur une liste de test peut taper 40% sur la vôtre, simplement parce que leur sweet spot c'est les acheteurs tech US et que vous chassez des founders PME français. Et même quand le match rate tient la route, il vous dit rien sur le coût de ces matches ni sur la fraîcheur de la data.

Ce qu'il faut tracker à la place : coût par match vérifié, fraîcheur (âge médian des records reçus) et conversion downstream (vos leads enrichis convertissent au même taux que ceux que vous choisissez à la main ?). Si vous regardez que le match rate, vous finirez à payer 0,40 € par email qui bounce sous 30 jours. À 3 providers, c'est une grosse fuite.

Comment Derrick le gère : on affiche le coût par match vérifié par provider en temps réel, et on facture uniquement sur les résultats validés. Le chiffre vanity du match rate est dans l'UI aussi, mais c'est pas ce sur quoi on optimise.

La logique waterfall, elle est vraie — chaîner 2-3 providers fait vraiment passer le match rate de ~50% à 80%+. Mais la courbe s'aplatit vite. Ajouter un 4ème source rapporte généralement 3 à 5 points. Le 5ème : 1 à 2 points. Le 6ème : quasi rien, en doublant votre coût par record et la complexité du debug quand un lookup foire.

Le sweet spot pour quasi tout le monde, c'est 3 à 4 providers choisis pour leur complémentarité, pas leur taille brute. Deux providers qui sourcent tous les deux de LinkedIn vous donnent 5% de lift. Un qui scrape LinkedIn + un qui agrège depuis les job boards vous donne 25%. La diversité des providers bat leur nombre, à chaque fois.

Comment Derrick le gère : notre waterfall par défaut chaîne 10 sources complémentaires, curées spécifiquement pour que chacune comble les trous des précédentes. Vous n'avez rien à choisir ni à classer — la logique waterfall est intégrée.

Celle-là, c'est celle que les founders se font le plus souvent. Ils prennent un seat Cognism en se disant que ça va générer du pipeline. Ce que ça fait vraiment, c'est amplifier le prospecting que vous faites déjà. Si votre ICP est mal défini, l'enrichissement va vous sortir 10 000 leads enrichis dont personne veut entendre parler. Si votre copy outbound marche pas, avoir des numéros de téléphone va pas la fixer.

La discipline, c'est : resserrer l'ICP jusqu'à le faire tenir en 2 phrases, faire en sorte que votre outreach pèche au moins 1 reply pour 50 envois sur listes froides, ensuite ajouter l'enrichissement pour scaler. Faire dans l'autre ordre, c'est la raison la plus commune pour laquelle les équipes brûlent 6 mois de crédits avant de comprendre que c'était le funnel le problème, pas la data.

Comment Derrick le gère : on vit nativement dans Google Sheets — là où votre travail ICP, vos listes et votre prep d'outreach se font déjà. Aucun nouvel outil à apprendre, pas d'exports CSV qui cassent le workflow. L'enrichissement s'insère dans le prospecting que vous avez déjà.

La data B2B décroît à environ 30% par an — les gens changent de boîte, les boîtes pivotent, les numéros de téléphone sont réassignés. Le CRM que vous avez enrichi en janvier est franchement moins bon en juin. Au mois 18, la moitié de vos contacts enrichis est stale.

Un programme d'enrichissement, c'est donc pas un projet — c'est une pratique d'hygiène continue. Il vous faut un calendrier : refresh des comptes top-tier tous les mois, mid-tier tous les trimestres, long-tail annuel. Il vous faut une règle d'alerte sur les bounces au-dessus du seuil. Il vous faut un owner (le plus souvent RevOps). Traiter l'enrichissement en mode install-and-forget, c'est ce qui fait pourrir la qualité data en silence jusqu'au jour où quelqu'un lance une campagne et 28% bounce.

Comment Derrick le gère : les jobs de refresh programmés tournent à la cadence que vous fixez (mensuel, trimestriel, on-demand), des alertes bounce vous notifient quand la deliverability chute, et les records stale sont auto-flaggés dans le Sheet pour que RevOps n'ait pas à les chasser à la main.

Celle-ci, c'est l'idée fausse la plus chère, et de loin. Les amendes RGPD dépassent 1 M€ pour usage abusif d'enrichissement B2B en Europe, et l'enforcement CCPA accélère en Californie. Le risque est pas théorique — des providers eux-mêmes se sont pris des amendes et ont été coupés, embarquant les flux data de leurs clients avec eux.

Avant qu'un provider passe en prod, il vous faut 3 choses par écrit : (1) leur base légale d'intérêt légitime au sens de l'article 6 RGPD, (2) un DPA signé, et (3) un process pour traiter les data-subject-access-requests sur les records enrichis. Aucune de ces 3 n'est compliquée. Les 3 sont régulièrement skippées. Le jour où un régulateur frappe à la porte, l'équipe qui les a skippées, c'est celle qui explique au legal pourquoi un refresh CRM rapide vient de devenir un procès d'un an.

Comment Derrick le gère : chaque provider de notre waterfall ship avec une base légale documentée, le DPA est signé à la création du compte, et les demandes DSAR sur les records enrichis sont traitées via un flow en 1 clic. La compliance est le défaut, pas une config à se rappeler.