API données entreprise : l'entrée décide du champ, et le champ décide du prix

Une API données entreprise, c'est un service que vous appelez avec un identifiant d'organisation et qui répond par une fiche structurée : raison sociale, domaine, secteur, effectif, localisation, et tout ce que le fournisseur maintient en plus. L'endpoint est la partie facile. Ce qui décide si votre intégration produit un tableau exploitable, c'est l'identifiant que vous pouvez fournir pour chaque ligne, et les champs que cet identifiant est réellement capable de résoudre.

La plupart des revues d'intégration ne posent jamais cette question. On compare les schémas de réponse, la latence et le prix par appel, puis on met en production. Trois semaines plus tard, le tableau est vide à 40 pour cent et personne ne sait dire pourquoi, parce que le trou n'a jamais été dans le code.

Ce guide couvre ce qu'une API données entreprise renvoie couche par couche, les trois clés d'entrée et ce que chacune peut résoudre, la réalité champ par champ derrière un pourcentage de couverture unique, la donnée registre que les fournisseurs orientés États-Unis laissent de côté, les deux modèles de facturation et ce qu'ils coûtent sur une vraie liste, ce qui casse en production, et les cas où l'API est simplement la mauvaise surface.

Ce qu'une API données entreprise renvoie, couche par couche

La réponse d'une API données entreprise n'est pas un objet plat où toutes les clés auraient la même fiabilité. Elle arrive en quatre couches, et elles ne se comportent pas du tout pareil une fois mises sous charge.

Les attributs d'identité. Raison sociale, nom commercial, domaine, pays, numéro d'immatriculation. On est proche du fait. Ça bouge rarement, c'est en général vérifiable contre une source publique, et un écart ici est un bug de résolution, pas un problème de qualité de donnée.

Les attributs firmographiques. Secteur, tranche d'effectif, tranche de chiffre d'affaires, année de création, ville du siège. Ce sont des estimations présentées comme des valeurs. L'effectif en particulier est une photo de ce que le fournisseur a observé en dernier, et deux fournisseurs peuvent légitimement diverger d'un facteur deux sur la même organisation parce qu'ils comptent différemment les prestataires, les filiales et les profils inactifs.

Les attributs de relation. Maison mère, filiales, entreprises similaires, les gens qui y travaillent. Ce sont des données dérivées : elles portent le taux d'erreur de ce qui les a construites, plus celui des fiches sous-jacentes.

Les attributs de signal. Recrutements en cours, levées de fonds, technologies utilisées, actualités récentes. C'est la seule couche où la fraîcheur compte plus que l'exactitude, parce qu'un signal juste livré six semaines trop tard n'a aucune valeur commerciale.

Traitez ces quatre couches comme quatre décisions distinctes. Les stocker dans une même table avec un score de confiance unique, c'est exactement comme ça qu'une estimation firmographique finit utilisée comme s'il s'agissait d'un numéro d'immatriculation.

Les trois clés d'entrée, et ce que chacune peut résoudre

Toute recherche d'entreprise part de l'une des trois clés. Le choix est fait pour vous par ce que votre CRM stocke déjà, et il contraint le résultat bien plus que le fournisseur que vous retenez.

Le domaine. La clé la plus forte, et de loin, parce qu'un domaine est quasi unique et lisible par une machine. Un domaine, une organisation, dans la quasi-totalité des cas. Les exceptions existent mais restent bornées : sous-domaines pays, holdings qui exploitent plusieurs marques sous un même domaine, agences qui hébergent les sites de leurs clients. Si vous pouvez fournir un domaine pour chaque ligne, faites-le et arrêtez d'optimiser le reste.

Le nom d'entreprise. La clé la plus faible, et celle que contiennent la plupart des listes. Les noms d'entreprise ne sont pas uniques, ils sont saisis par des humains, et ils entrent en collision d'un pays à l'autre. Une recherche par nom qui renvoie quelque chose avec une confiance élevée, c'est le mode d'échec propre à cette catégorie : vous récupérez une fiche plausible pour une autre organisation, et rien en aval ne le signalera. Si le nom est tout ce que vous avez, résolvez-le d'abord vers un domaine ou un numéro d'immatriculation, puis enrichissez à partir de cette clé résolue.

L'URL LinkedIn de l'entreprise. Déterministe comme un domaine, et elle ouvre une autre tranche de données : la description de la page, l'effectif que l'entreprise publie sur elle-même, le secteur qu'elle déclare, et les personnes qui y sont rattachées. C'est la bonne clé quand votre liste vient de la prospection sociale plutôt que d'un export CRM.

Une quatrième clé existe en Europe et on l'oublie systématiquement : le numéro d'immatriculation. En France, c'est le SIREN ou le SIRET, et c'est la seule clé de cette liste qui fasse légalement foi au lieu d'être observée commercialement. On y revient en partie 05.

Quel champ vient de quelle entrée

Voici le tableau qui devrait figurer dans chaque document d'intégration et qui n'y est presque jamais. Il croise ce que vous pouvez envoyer avec ce que vous pouvez raisonnablement espérer en retour.

Lisez une ligne et une décision en tombe. Si votre pipeline a besoin des dirigeants et des adresses de siège pour des comptes français, aucune quantité d'enrichissement par domaine ne vous y amènera, et aucun comparatif de fournisseurs ne vous le dira. Il vous faut la clé registre. À l'inverse, si vous voulez la technologie qu'un prospect utilise, seul le domaine l'adresse, parce que cette réponse se produit en inspectant le site et non en consultant un référentiel.

Derrick expose ces opérations séparément plutôt qu'en un appel opaque, et c'est ce qui rend la correspondance visible : Enrich Companies à 1 crédit par entreprise depuis une page LinkedIn, Search Companies à 1 crédit par entreprise pour résoudre un nom en URL LinkedIn, Website Technologies à 2 crédits par site depuis un domaine, et Company Hiring Signal à 1 crédit par entreprise. Les deux premières et le signal de recrutement sont accessibles sur le plan gratuit ; Website Technologies est une fonctionnalité premium. Vous pouvez donc mesurer votre propre taux de résolution sur l'essentiel de la correspondance avant d'écrire une ligne de code d'intégration.

La couverture n'est pas un chiffre unique, lisez-la champ par champ

Un fournisseur qui affiche 95 pour cent de couverture vous parle de son champ le plus facile, sur son propre dénominateur. Les deux moitiés de cette phrase comptent.

Le dénominateur d'abord. La couverture mesurée sur les lignes soumises est le seul chiffre qui corresponde à votre facture et à votre tableau. La couverture mesurée sur les lignes matchées exclut toutes celles que le fournisseur n'a pas su résoudre, c'est-à-dire précisément la population qui vous inquiète. Les deux chiffres peuvent différer de trente points sur le même run, et les deux sont techniquement vrais.

Le champ ensuite. La raison sociale et le domaine se résolvent à des taux proches du taux de match lui-même. L'effectif et le secteur suivent en général à quelques points, parce qu'ils viennent de la même fiche. L'adresse du siège, les dirigeants et tout ce qui exige une source légale s'effondrent dès qu'on sort du marché d'origine du fournisseur. Les technologies et les signaux de recrutement ne sont comparables à rien de tout ça, parce que ce sont des recherches et non des consultations : elles aboutissent ou non, et un échec n'est pas forcément une erreur.

Le test pratique prend un après-midi. Prenez 200 vraies lignes de la liste que vous comptez réellement enrichir, pas un échantillon choisi. Passez-les. Puis comptez, par champ, combien sont remplies, combien sont remplies ET justes sur un contrôle de vingt, et combien vous ont été facturées. Ça vous donne trois chiffres par champ, et ce sont les seuls qui devraient apparaître dans la décision d'intégration. Notre page sur le taux de couverture face au taux d'exactitude déroule l'arithmétique en détail.

La couche registre que la plupart des API données entreprise ignorent

La donnée entreprise commerciale est observée. La donnée registre est déclarée à un État et engage juridiquement. Ce ne sont pas des sources concurrentes, elles répondent à des questions différentes, et les confondre coûte cher.

En France, la clé registre est le SIREN, neuf chiffres qui identifient l'entité juridique, et le SIRET, quatorze chiffres qui identifient un établissement de cette entité. Y sont rattachés la raison sociale exactement telle que déposée, l'adresse du siège, la date d'immatriculation, la forme juridique, la tranche d'effectif déclarée, les dirigeants, et le code NAF d'activité. Rien de tout cela n'est une estimation. Tout cela est ce que l'entreprise a elle-même déclaré, ce qui est une autre nature de vérité que ce qu'un crawler a déduit.

Ça compte dans trois situations concrètes. Les workflows de contrat et de facturation ont besoin de la raison sociale et de l'adresse du siège, pas du nom commercial et du bureau trouvé sur un site. La conformité et l'onboarding fournisseur ont besoin du numéro d'immatriculation comme clé de jointure, parce que c'est le seul identifiant qui survive à un changement de marque. Et la définition de territoires ou de segments en France fonctionne bien mieux sur le code NAF que sur la taxonomie sectorielle d'un fournisseur, parce que le code NAF est ce que l'entreprise a déposé, pas ce qu'un classifieur a deviné.

Derrick couvre cette couche directement avec SIRET/SIREN/Name Enrichment, à 1 crédit par entreprise, disponible sur le plan gratuit : envoyez un SIRET, un SIREN ou un nom d'entreprise et récupérez identité, activité, dirigeants et données légales avec un score de confiance. Le même registre s'adresse dans l'autre sens avec Import Companies by NAF Code, qui transforme un code d'activité en liste complète des entreprises françaises correspondantes. Si vous construisez des listes sur le marché français, ce duo remplace un projet de scraping.

Deux remarques avant de brancher. La donnée registre vous dit ce qu'est l'entité, jamais à qui parler : il vous faut encore une couche personnes par-dessus. Et une fiche registre peut être à jour et inutile en même temps : une entreprise qui a déposé sa tranche d'effectif il y a deux ans est en règle juridiquement et périmée commercialement.

Ce que coûte une API données entreprise, à la tentative ou au résultat

Deux modèles de facturation existent et l'écart entre les deux n'est pas un détail. À la tentative, chaque appel est facturé, qu'il renvoie quelque chose ou non. Au résultat, seul ce qui se résout est facturé. Sur une liste où un tiers des lignes ne se résoudra jamais, cette seule ligne du contrat déplace la facture d'un tiers.

Déroulons sur 1 000 entreprises avec un taux de résolution de 70 pour cent, à 1 crédit par entreprise. À la tentative, vous payez 1 000 crédits et recevez 700 lignes exploitables, soit environ 1,43 crédit par ligne exploitable. Au résultat, vous payez 700 crédits pour les mêmes 700 lignes, à 1 crédit chacune. Même donnée, même fournisseur, 30 pour cent d'écart.

Le chiffre qui doit piloter la décision, c'est le coût par ligne exploitable, jamais le prix par appel. Un appel bon marché avec un taux de résolution faible perd contre un appel cher avec un taux élevé, et le prix par appel affiché masque totalement ce point.

La grille de crédits de Derrick va du plan gratuit à 100 crédits par mois pour 0 euro, puis MINI à 9 €, STANDARD à 20 €, PLUS à 47,5 €, PRO à 175 € et SCALE à 320 € par mois. L'accès API et MCP s'ouvre à partir d'un plan payant ; le palier en vigueur est sur la page tarifs, où le plancher revient à 0,0016 € par crédit. Les crédits non consommés sont reportés. Si nous publions toute la grille plutôt qu'un prix d'appel unique, c'est que le coût par ligne exploitable ne devient calculable qu'une fois qu'on voit à la fois le prix du crédit et le coût par opération. Le détail complet vit sur notre page tarification de l'API d'enrichissement.

Ce qui casse en production, et ce qu'il faut prévoir

Les intégrations d'enrichissement entreprise échouent rarement sur le chemin nominal. Elles échouent sur les quatre choses que personne n'a testées.

Les rafales. Un job nocturne qui enrichit tout un segment CRM va taper un plafond par minute que votre test de cinquante lignes n'a jamais touché. Construisez la file d'attente et le backoff avant la mise en production, pas après le premier run échoué. La mécanique est dans notre guide sur les limites de débit et la gestion des quotas.

Les retries qui facturent deux fois. Un timeout n'est pas un échec, c'est un résultat inconnu. Le rejouer aveuglément sur un contrat à la tentative vous facture deux fois une seule réponse. Rendez l'appel idempotent de votre côté en le clé-ant sur l'identifiant d'entrée et en mettant le résultat en cache, y compris les résultats vides.

Les résultats vides traités comme des erreurs. Une entreprise qui n'a réellement aucun effectif publié n'est pas une 500. Si votre pipeline rejoue chaque champ vide, vous paierez le même néant en boucle. Stockez le null et son horodatage, et rafraîchissez sur un calendrier.

Les écrasements silencieux. L'échec le plus coûteux de cette catégorie, c'est un run d'enrichissement qui écrase un champ vérifié par un humain avec une estimation machine. Écrivez dans des colonnes de staging, comparez, puis promouvez. Notre page sur l'architecture d'une API d'enrichissement déroule le motif file d'attente, cache et promotion de bout en bout, et webhooks et enrichissement couvre la version événementielle.

Quand l'API est la mauvaise surface

L'API est la bonne réponse pour un flux récurrent, automatisé, de système à système : un CRM qui enrichit à la création de la fiche, un rafraîchissement nocturne, un produit qui a besoin de donnée entreprise à l'inscription. Si ça vous décrit, intégrez.

C'est la mauvaise réponse plus souvent que les fournisseurs ne l'admettent. Si le vrai travail, c'est une liste qu'un humain construit et transmet à une équipe commerciale, l'API ajoute une dépendance d'ingénierie à une tâche qui n'en a jamais eu besoin. Derrick tourne depuis une sidebar dans Google Sheets : le même enrichissement se fait sur une colonne, sans code et sans déploiement, et la personne qui possède la liste possède le run.

Et si le travail est une question plutôt qu'une liste, aucune des deux surfaces ne convient. Posez-la dans un chat : Derrick MCP, inclus à partir d'un plan payant, branche le même enrichissement dans Claude, ChatGPT et tout client compatible MCP, pour que la recherche se fasse là où vous réfléchissez déjà. Notre guide build ou buy déroule la même décision pour l'intégration elle-même.

Choisissez la surface selon le cas d'usage, pas selon l'organigramme. Une liste à enrichir va dans Sheets. Une question dans un chat va au MCP. Un workflow récurrent et automatisé va à l'API. La plupart des équipes ont besoin de deux des trois, et en choisir une seule pour tout, c'est ce qui produit soit un tableur clandestin, soit une intégration jamais utilisée.

La checklist API données entreprise à passer cette semaine

Neuf questions, dans l'ordre. Répondez-y et le reste est du détail d'implémentation.

1. Quelle clé puis-je fournir pour 100 pour cent des lignes ? Domaine, nom, URL LinkedIn ou numéro d'immatriculation. Cette réponse contraint tout le reste.

2. Si la réponse est le nom, qu'est-ce qui le résout d'abord ? Résolvez le nom vers un domaine ou un numéro d'immatriculation dans une étape séparée et auditable. N'enrichissez jamais directement depuis un nom en faisant confiance au résultat.

3. De quels deux champs le workflow a-t-il réellement besoin ? Pas du schéma complet. Deux. Mesurez la couverture sur ceux-là et ignorez le reste de la réponse.

4. Quel est mon taux de résolution sur mes propres 200 lignes ? Mesuré avec les lignes soumises comme dénominateur, sur de la vraie donnée.

5. Ai-je besoin de donnée registre ? Si une étape en aval est contractuelle, juridique ou relève de la segmentation du marché français, oui, et aucune source commerciale ne s'y substitue.

6. Suis-je facturé à la tentative ou au résultat ? Puis calculez le coût par ligne exploitable, pas le prix par appel.

7. Que devient un match à faible confiance ? Si la réponse est qu'il est écrit dans le CRM quand même, corrigez ça avant la mise en production.

8. À quelle fréquence je rafraîchis, et quelle couche ? L'identité presque jamais, les firmographiques au trimestre, les signaux à la semaine sinon ils ne valent rien.

9. Ai-je vraiment besoin d'une intégration ? Posez la question honnêtement. Une liste mensuelle dont une personne est propriétaire, rarement.

Le mode d'échec de cette catégorie n'est pas un mauvais endpoint. C'est un bon endpoint alimenté par une clé faible, mesuré sur le dénominateur du fournisseur, et facturé à chaque tentative. Aucun de ces trois points n'est un problème technique, et c'est précisément pour ça que la revue technique ne les attrape jamais.