API d'enrichissement de données B2B : fonctionnement et données renvoyées

Une API d'enrichissement de données est un service web qui prend un identifiant que vous avez déjà (un email, un domaine, une URL LinkedIn, un nom d'entreprise) et vous renvoie des champs structurés sur la personne ou l'entreprise, en JSON. Elle fonctionne en trois temps : vous envoyez un identifiant, vous récupérez des champs, vous les écrivez là où vous travaillez. C'est tout le principe.

Cette page couvre les deux côtés du sujet. D'abord, à quoi ressemble un vrai appel sur l'API REST de Derrick et ce qu'il coûte par enregistrement. Ensuite, ce qui vaut pour n'importe quel fournisseur : la mécanique, le temps réel face au batch, et les vérifications à faire avant de choisir une API d'enrichissement de données pour votre stack. Elle s'adresse aux développeurs back-end, aux tech leads et aux growth engineers, avec une voie no-code pour les équipes qui n'ont pas de développeur disponible.

Qu'est-ce qu'une API d'enrichissement de données ?

Une API d'enrichissement B2B est un service web qui prend en entrée un identifiant partiel (une adresse email, un nom de domaine, une URL de profil LinkedIn, un nom d'entreprise) et retourne un jeu de données structuré sur le contact ou l'organisation correspondante.

Toute API d'enrichissement de données suit les mêmes trois étapes :

1. Envoyer un identifiant. Votre code fait une requête HTTP authentifiée avec la valeur que vous avez : un email professionnel, un site web, une URL LinkedIn.
2. Récupérer des champs. L'API répond en JSON : nom, poste, entreprise, effectif, secteur, technologies, téléphone ou email selon l'endpoint.
3. Les écrire là où vous travaillez. Vous mappez ces champs dans votre CRM, votre base de données, votre tableur ou l'étape suivante de votre pipeline.

L'enrichissement par API se distingue de la recherche manuelle sur deux points : la vitesse (des millisecondes au lieu d'heures) et l'échelle (des milliers d'enregistrements par jour au lieu de quelques dizaines). Pour un développeur qui construit un pipeline de qualification de leads ou un onboarding intelligent, c'est une brique de base. La mécanique interne (files d'attente, sources, cache, correspondance) est détaillée dans notre guide sur le fonctionnement d'une API d'enrichissement de données.

L'API d'enrichissement de données Derrick : une vraie requête et sa réponse

Derrick est un outil d'enrichissement B2B que vous utilisez dans son app web, dans Google Sheets, dans Claude ou tout client MCP, et via une API REST. L'API expose les mêmes actions que l'app : trouver un email professionnel, trouver un numéro de mobile, enrichir un profil LinkedIn, enrichir une entreprise, détecter les technologies d'un site, et d'autres. La documentation listait 35 endpoints quand nous l'avons consultée le 14 octobre 2026.

Concrètement :

• Récupérez votre clé dans l'app. Ouvrez l'app web Derrick, allez sur la page API & MCP et copiez votre clé. L'accès API est inclus à partir du plan PLUS.
• Une URL de base, une méthode. Chaque endpoint est un POST vers https://app1.derrick-app.com/api/v1/{endpoint} avec un corps JSON.
• Un en-tête pour l'authentification. Passez la clé dans l'en-tête x-api-key. Gardez-la côté serveur.
• La référence complète. Les entrées, le coût en crédits et un exemple de réponse pour chaque endpoint sont dans la documentation de l'API Derrick.

Voici un vrai appel, construit comme la documentation le construit, vers l'endpoint Website Technologies (un appel d'enrichissement par domaine : vous envoyez un site, vous récupérez sa stack) :

curl --request POST \
  --url https://app1.derrick-app.com/api/v1/find_tech \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  -d '{"data": {"website_url": "<website_url>"}}'

Exemple de réponse, tel que publié dans la documentation de cet endpoint (la liste des technologies est raccourcie ici) :

{
  "success": true,
  "data": {
    "cms": "Webflow",
    "urlStatus": 200,
    "technologies": "Webflow, jsDelivr, jQuery CDN, Google Tag Manager, Cloudflare, ..."
  },
  "credits": {
    "used": 2,
    "remaining": "..."
  }
}

Chaque réponse réussie a la même enveloppe : success, les données enrichies dans data (leurs champs dépendent de l'endpoint), et credits avec ce que l'appel a consommé et ce qu'il reste sur votre compte. Les erreurs reviennent sous la forme {"success": false, "error": "...", "errorType": "..."} avec ces codes, tirés de la documentation :

L'API n'est pas la seule voie programmatique. Le serveur MCP Derrick donne à Claude, ChatGPT ou tout client MCP les mêmes actions, avec la même clé et les mêmes plans. Pratique quand le « code » qui appelle l'enrichissement est un agent IA plutôt que votre back-end.

Combien coûte une API d'enrichissement de données : les crédits Derrick

Derrick facture en crédits, et chaque endpoint a son propre coût. Un enrichissement d'entreprise ou de profil coûte 1 crédit. Trouver un email professionnel coûte plus cher, parce que c'est la réponse qui a de la valeur, et il n'est facturé que si un email est trouvé. Même principe pour les numéros de mobile. Vous pouvez vérifier chaque coût sur la page de l'endpoint dans la documentation avant de l'appeler.

L'accès API commence avec le plan PLUS à 47,50 € par mois (25 000 crédits). Sur le plan SCALE, le prix du crédit descend à 0,0016 €. Le plan gratuit (100 crédits par mois, 0 €) fait tourner Enrich Leads et Enrich Companies dans l'app web et dans Google Sheets : vous mesurez votre taux de correspondance avant de payer l'accès API. Pour le détail des modèles de prix du marché (à l'appel, au crédit, au siège, au résultat trouvé), lisez notre guide sur la tarification d'une API d'enrichissement de données.

Comment fonctionne une API d'enrichissement de données B2B : les concepts clés

Authentification et gestion des clés API

Presque toutes les API d'enrichissement B2B utilisent une authentification par clé API. À l'inscription, vous obtenez une clé unique qui accompagne chaque requête, le plus souvent dans un en-tête HTTP. Certains fournisseurs utilisent le schéma Authorization: Bearer, d'autres un en-tête personnalisé. Derrick utilise x-api-key :

x-api-key: YOUR_API_KEY

Quel que soit l'en-tête, n'exposez jamais la clé côté client. Gardez-la dans des variables d'environnement côté serveur, et régénérez-la tout de suite si elle fuite.

Pour des architectures multi-tenant, certaines plateformes (HubSpot ou Salesforce, pour leurs propres fonctions d'enrichissement) passent par OAuth 2.0 avec des jetons à durée de vie courte. Pour la plupart des API d'enrichissement dédiées, la clé statique reste la norme. Notre guide sur la sécurité et l'authentification des API détaille la rotation des clés et le chiffrement.

Les endpoints principaux d'une API d'enrichissement

La plupart des API d'enrichissement exposent les mêmes familles d'endpoints. Voici la carte générique, avec l'équivalent Derrick en face :

Certains fournisseurs ajoutent un endpoint bulk qui prend une liste en une requête. L'API Derrick traite un enregistrement par appel, jusqu'à 60 appels par minute ; pour un fichier entier, vous importez le CSV dans l'app web et vous l'enrichissez en une passe.

Format des réponses JSON

Les API d'enrichissement répondent en JSON. La structure varie selon le fournisseur, mais les parties utiles sont toujours les mêmes : un statut (trouvé ou non), les champs, et le coût de l'appel. Derrick les range dans une seule enveloppe (success, data, credits), visible dans l'exemple réel plus haut.

Certains fournisseurs renvoient aussi un score de correspondance qui indique à quel point ils sont sûrs que le profil renvoyé est bien la personne demandée. Si le vôtre en a un, servez-vous-en. Une mauvaise correspondance est pire qu'un champ vide : elle entre dans votre CRM et personne ne s'en aperçoit avant qu'une campagne rebondisse.

Rate limiting et codes d'erreur

La limite de débit est la contrainte à anticiper avant d'écrire l'intégration. Toute API d'enrichissement de données en a une, pour éviter les abus et garder le service disponible. Chez Derrick, c'est 60 requêtes par minute.

Comportement standard : quand vous dépassez la limite, l'API renvoie un HTTP 429 (Too Many Requests). Beaucoup d'API envoient aussi un en-tête Retry-After (secondes d'attente) ou un en-tête de quota restant. Quand il n'y en a pas, attendez et réessayez avec un backoff exponentiel. Voici une façon propre de le faire en Python avec l'API Derrick :

import time
import requests

API_BASE = "https://app1.derrick-app.com/api/v1/"

def derrick_call(endpoint, data, api_key, max_retries=4):
    for attempt in range(max_retries):
        response = requests.post(
            API_BASE + endpoint,
            json={"data": data},
            headers={"x-api-key": api_key},
        )

        if response.status_code == 200:
            return response.json()

        if response.status_code == 429:
            # 60 requêtes par minute : on attend, puis on réessaie
            time.sleep(5 * 2 ** attempt)
            continue

        # 400, 401, 402, 422... : on lève, on ne réessaie pas à l'aveugle
        response.raise_for_status()

    return None  # abandon après max_retries tentatives

Les stratégies complètes (token bucket, files d'attente, suivi du quota) sont dans notre guide sur les limites de débit et la gestion des quotas. Alternative no-code : Zapier et Make gèrent les relances et le rythme pour vous.

Les types de données renvoyées par une API d'enrichissement

L'endpoint d'enrichissement de contact (lead)

C'est le cas d'usage le plus courant pour les équipes sales et marketing. À partir d'une adresse email ou d'une URL LinkedIn, une API d'enrichissement de données peut renvoyer :

• Prénom, nom, poste
• Email professionnel vérifié
• Numéro de téléphone direct (mobile ou fixe)
• Profil LinkedIn et liens vers les réseaux sociaux
• Localisation
• Ancienneté dans le poste, poste précédent, dernière formation

La qualité des données de contact varie beaucoup d'un fournisseur à l'autre. Les API qui lisent des sources fraîches (profils LinkedIn en direct, bases tenues à jour) battent celles qui s'appuient sur des instantanés vieux de 6 à 18 mois. Les taux de correspondance champ par champ et les coûts réels sont détaillés dans notre guide sur l'API d'enrichissement de contact. Chez Derrick, les endpoints basés sur LinkedIn demandent que votre compte LinkedIn soit connecté via l'extension Chrome Derrick.

Données firmographiques (données entreprise)

Un enrichissement d'entreprise renvoie en général les attributs firmographiques dont vous avez besoin pour qualifier un compte :

Ces données sont la base de tout enrichissement CRM automatisé : elles permettent de scorer et de segmenter les comptes sans toucher chaque fiche. Quelle entrée renvoie quel champ, avec un exemple de réponse : c'est dans notre guide sur l'API d'enrichissement d'entreprise.

Données technographiques et appels d'API d'enrichissement par domaine

Une API d'enrichissement par domaine prend un site web et renvoie ce qu'elle peut y lire : les technologies détectées (CMS, analytics, CDN, hébergement, framework front-end), et sur certains endpoints les emails, téléphones et réseaux sociaux publiés sur le site. Pour un éditeur SaaS qui cible des entreprises selon leur stack, c'est une donnée de qualification solide. Chez Derrick, Website Technologies coûte 2 crédits par site, facturés même si rien n'est détecté, parce que « aucune stack trouvée » est la réponse.

Comment intégrer une API d'enrichissement B2B : guide étape par étape

Étape 1 : choisir votre stratégie d'enrichissement

Avant d'écrire une ligne de code contre une API d'enrichissement de données, décidez quand l'enrichissement tourne :

• Enrichissement en temps réel : déclenché par un événement (nouveau lead dans le CRM, formulaire soumis). Idéal pour de faibles volumes quand la latence compte.
• Enrichissement batch : traitement planifié d'une liste existante. Idéal pour de gros volumes quand quelques heures ne changent rien.
• Hybride : temps réel pour les nouvelles fiches, batch pour rafraîchir les anciennes.

Les compromis sont détaillés dans la partie temps réel ou batch plus bas. Résultat attendu : un schéma clair de ce qui déclenche chaque appel avant de commencer à construire.

Étape 2 : s'authentifier et tester le premier appel

Copiez votre clé API depuis la page API & MCP de l'app Derrick et lancez un appel de test avec curl (le même appel que plus haut, sur un site que vous connaissez) :

curl --request POST \
  --url https://app1.derrick-app.com/api/v1/find_tech \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  -d '{"data": {"website_url": "<un site que vous connaissez>"}}'

Un HTTP 200 avec "success": true veut dire que l'authentification fonctionne. Un 401 veut dire que la clé est fausse ou absente.

Résultat attendu : une réponse JSON valide que vous pouvez comparer à ce que vous savez déjà du site.

Étape 3 : parser et mapper la réponse

La réponse brute doit coller à votre propre schéma. Voici un mapper Python pour la forme de réponse ci-dessus, avec une garde sur les échecs :

def parse_tech_response(api_response: dict) -> dict | None:
    if not api_response or not api_response.get("success"):
        return None

    data = api_response.get("data", {})
    techs = data.get("technologies") or ""

    return {
        "cms": data.get("cms"),
        "technologies": [t.strip() for t in techs.split(",") if t.strip()],
        "credits_left": api_response.get("credits", {}).get("remaining"),
    }

Résultat attendu : un objet propre, prêt à être inséré dans votre base ou votre CRM.

Étape 4 : mettre en cache pour économiser vos crédits

Un domaine ne change pas toutes les heures. Mettre les réponses en cache vous évite de payer deux fois la même donnée. Repère : un TTL (durée de vie) de 30 jours pour les données firmographiques, 7 jours pour les données de contact, parce que les postes bougent plus vite.

Résultat attendu : sur les traitements en masse où les mêmes domaines reviennent souvent, une bonne partie des appels ne sort jamais de votre cache.

Étape 5 : gérer les erreurs et surveiller

Votre intégration doit prévoir quatre cas d'échec :

• Aucune donnée trouvée : loguez le statut et passez à la suite sans planter le workflow
• Limite de débit atteinte (HTTP 429) : backoff exponentiel
• Crédits épuisés (HTTP 402 chez Derrick) : alertez quelqu'un, ne réessayez pas
• Erreur serveur (HTTP 5xx) : réessayez avec un délai, alertez si ça persiste

Si vous préférez être rappelé plutôt que d'interroger l'API en boucle, voyez notre guide sur les webhooks et l'enrichissement déclenché par événement. Résultat attendu : un pipeline qui ne casse pas sur un enregistrement raté.

Enrichissement en temps réel ou batch : lequel pour votre pipeline ?

L'enrichissement en temps réel lance un appel quand un événement se produit. L'enrichissement batch traite une liste entière selon un calendrier. Choisissez le temps réel quand quelqu'un attend la réponse, le batch quand la donnée doit juste être juste demain matin.

La plupart des équipes finissent en hybride : temps réel sur les nouveaux leads entrants, batch sur la base existante une fois par mois ou par trimestre. Avec Derrick, le temps réel passe par l'API ou le serveur MCP, et le batch peut tourner via l'API à 60 appels par minute ou directement dans l'app web sur une liste importée.

Ce qu'il faut vérifier avant de choisir une API d'enrichissement de données

Les classements des « meilleurs » fournisseurs vieillissent vite et collent rarement à vos données. Une courte liste de vérifications marche mieux. Faites chacune sur vos propres fiches avant de signer quoi que ce soit.

1. La couverture sur votre marché. Une API d'enrichissement de données solide sur les entreprises tech américaines peut être faible sur les PME françaises ou sur l'industrie. Testez-la sur 100 à 200 fiches de votre vraie cible, pas sur le jeu de démo du fournisseur.
2. La fraîcheur. Demandez à quelle fréquence les profils sont mis à jour, et vérifiez-le vous-même : prenez 20 contacts qui ont changé de poste récemment et regardez ce qui revient.
3. Le taux de correspondance et la facturation des non-trouvés. 60 % de correspondance facturés à l'appel et 60 % facturés au résultat trouvé, ce n'est pas le même prix. Chez Derrick, Email Finder et Phone Finder ne facturent que s'ils trouvent quelque chose ; les autres endpoints facturent par enregistrement envoyé, et la documentation de chaque endpoint le précise.
4. La conformité. D'où viennent les données, existe-t-il un accord de traitement des données (DPA), pouvez-vous supprimer une personne sur demande ? Notre guide sur la sécurité d'une API d'enrichissement liste les questions à poser.
5. La latence et les limites de débit. En temps réel, mesurez le temps de réponse sur vos propres appels. En batch, la limite par minute décide de la durée d'un passage. Voir les limites de débit expliquées.
6. Les engagements de disponibilité. Si l'enrichissement est au cœur d'un workflow qui rapporte (routage des leads, inscription), lisez le SLA avant d'en dépendre. Notre guide SLA et disponibilité explique ce que veulent dire les chiffres.

Une dernière vérification qui fait gagner beaucoup de temps : pouvez-vous lancer le même enrichissement sans code d'abord ? Si l'outil a une app ou une interface tableur, vous mesurez la couverture et la fraîcheur en un après-midi, et vous n'écrivez l'intégration qu'une fois les chiffres validés.

Les principaux cas d'usage d'une API d'enrichissement B2B

Auto-remplissage de formulaires

Mike, développeur dans une startup SaaS, branche une API d'enrichissement de données sur le formulaire d'inscription. Quand un prospect tape son email professionnel, l'API renvoie le nom de l'entreprise, sa taille et son secteur, et les champs se remplissent tout seuls. Le formulaire raccourcit, et la fiche CRM est exploitable dès sa création.

Enrichissement CRM automatique

Emma, Sales Ops dans une scale-up, lance un enrichissement batch à chaque import de leads dans HubSpot. L'API remplit les champs manquants (taille de l'entreprise, secteur, téléphone direct) pour que ses SDR ne cherchent pas chaque lead à la main. Selon HubSpot, les équipes commerciales passent en moyenne 27 % de leur temps sur des tâches liées aux données que l'automatisation peut supprimer.

Lead scoring en temps réel

Mark, growth engineer, utilise une API d'enrichissement dans son moteur de scoring. Dès qu'un lead entre dans le pipeline, l'API renvoie les données firmographiques nécessaires au calcul d'un score ICP (profil client idéal). Les leads sont qualifiés avant même que l'équipe commerciale les voie.

Des agents IA qui enrichissent à la demande

De plus en plus d'appels d'enrichissement viennent d'un assistant IA plutôt que d'un script. Avec le serveur MCP Derrick, quelqu'un demande à Claude « trouve le CTO de cette entreprise et son email professionnel », et l'agent appelle les mêmes actions que l'API, avec le coût annoncé avant de lancer.

RGPD et conformité des données enrichies via API

Utiliser une API d'enrichissement B2B, c'est traiter des données personnelles (emails, noms, numéros de téléphone). Dans l'Union européenne, le RGPD s'applique pleinement, même quand les données viennent d'un fournisseur tiers.

Trois obligations à connaître :

1. La base légale. En B2B, la base la plus utilisée est l'intérêt légitime : prospecter des professionnels dans le cadre de leur activité. Documentez-la dans votre registre des traitements, et vérifiez qu'elle passe le test de mise en balance.

2. Limitation de la finalité et minimisation. N'enrichissez que les données nécessaires à la finalité déclarée. Pour de la prospection B2B, vous n'avez pas besoin de données personnelles sans lien avec le métier de la personne.

3. Le droit d'opposition. Toute personne dont vous avez enrichi le profil peut s'opposer au traitement. Votre infrastructure doit pouvoir retrouver et supprimer ces données sur demande.

Côté fournisseur, vérifiez que le fournisseur de l'API est lui-même conforme au RGPD et propose un accord de traitement des données (DPA). Les fournisseurs sérieux le publient dans leur documentation ou l'envoient sur demande.

Pour les équipes au Royaume-Uni, le cadre de l'ICO (Information Commissioner's Office) applique des principes proches depuis le Brexit.

Alternative no-code : enrichir sans API avec Zapier, Make et Derrick

Construire et maintenir une intégration API demande du temps de développeur. Pour les équipes sans développeur disponible, ou qui veulent aller vite, il existe une voie no-code qui donne les mêmes données.

Derrick est un outil d'enrichissement B2B que vous utilisez dans son app web, dans Google Sheets, dans Claude via MCP, et via son API. Comme il a une API, il se connecte à Zapier, Make et n8n, ce qui ouvre plus de 3 000 intégrations. Vous construisez le même pipeline d'enrichissement qu'avec une intégration REST, sans écrire de code :

• Nouveau lead dans HubSpot → Zapier déclenche Derrick → Derrick ajoute email, téléphone et données entreprise → les résultats repartent dans votre CRM
• Une liste importée dans l'app web Derrick (CSV) ou ouverte dans Google Sheets → Derrick enrichit plus de 50 attributs en masse → export vers votre pipeline

Pour un SDR ou un growth marketer qui veut les emails professionnels et les numéros d'une liste LinkedIn, l'app web Derrick est souvent plus rapide à mettre en place qu'une intégration API, et elle ne demande aucune compétence de développement. Quand le volume ou l'automatisation grandit, les mêmes actions vous attendent dans l'API.

Les erreurs courantes et comment les corriger

Problème 1 : accepter chaque correspondance sans la vérifier

Impact : des données fausses venues de l'API d'enrichissement de données s'accumulent dans votre CRM, abîment vos campagnes et faussent votre lead scoring.

Solution : si votre fournisseur renvoie un score de correspondance, filtrez sous un seuil que vous avez testé. Sinon, contrôlez un échantillon de chaque lot contre des fiches que vous connaissez, et stockez la date d'enrichissement à côté de la donnée.

Problème 2 : ignorer le rate limiting jusqu'au premier 429

Impact : le pipeline casse en production, des enrichissements se perdent, et l'équipe commerciale ne comprend pas pourquoi des données manquent.

Solution : ajoutez un backoff exponentiel dès le premier jour (voir le code plus haut) et cadencez vos traitements batch sous la limite (60 appels par minute chez Derrick).

Problème 3 : ne pas mettre en cache les réponses

Impact : des crédits dépensés à nouveau sur des domaines déjà enrichis. À grande échelle, la facture peut doubler.

Solution : stockez chaque réponse avec un horodatage et un TTL. Avant tout appel API, vérifiez si la donnée est en cache et encore valide.

Problème 4 : choisir un fournisseur sans vérifier la fraîcheur des données

Impact : un bon taux de correspondance sur le papier, des données périmées en pratique : anciens postes, emails morts, entreprises fermées.

Solution : faites un test sur 100 à 200 contacts dont vous connaissez déjà les données à jour. C'est la seule façon fiable de mesurer la qualité réelle.

Problème 5 : pas de DPA signé avec le fournisseur API

Impact : un manquement possible au RGPD. Vous êtes responsable du traitement même quand la donnée vient d'un tiers.

Solution : signez un accord de traitement des données avec chaque fournisseur API qui traite des données personnelles pour vous. Non négociable dans l'UE et au Royaume-Uni.

À retenir : par où commencer votre intégration

• Une API d'enrichissement de données fonctionne en trois temps : envoyer un identifiant, récupérer des champs, les écrire là où vous travaillez.
• Chez Derrick : un POST par appel vers /api/v1/{endpoint}, la clé dans x-api-key, une réponse avec success, data et credits, à partir de 1 crédit par enregistrement, accès API dès le plan PLUS.
• Les limites de débit sont inévitables : backoff sur les 429 et cadence des batchs sous la limite.
• Le cache est obligatoire à l'échelle : un TTL de 30 jours sur les données firmographiques réduit les dépenses en double.
• Choisissez un fournisseur sur vos propres données : couverture, fraîcheur, facturation des non-trouvés, conformité, latence, SLA.
• Le RGPD s'applique à vos workflows d'enrichissement : base légale documentée, minimisation, DPA signé.
• Pas de développeur ? L'app web Derrick, Google Sheets ou Zapier/Make vous donnent les mêmes données sans code.

Si vous avez du temps de développement, les cinq étapes d'intégration ci-dessus forment la feuille de route complète. Si vous voulez démarrer vite, lancez votre première liste dans l'app web Derrick, mesurez ce qui revient, et passez à l'API quand les chiffres tiennent. Vous voulez recevoir le prochain guide sur les API d'enrichissement à sa sortie ? La newsletter envoie une édition toutes les 2 semaines.