Cas d'usage · Risque tiers

API de diligence fournisseurs

Résolvez chaque fournisseur vers un identifiant officiel, récupérez sa fiche registre, criblez sa raison sociale et ses dirigeants contre les listes de sanctions, vérifiez l'absence de procédure collective, et continuez à surveiller après le référencement — dans n'importe quel pays couvert par l'API, depuis une seule API REST.

Publié le 15 septembre 2026

Le problème

Les équipes achats référencent un fournisseur une fois — un formulaire, quelques pièces, parfois une vérification registre manuelle — puis passent au suivant. Le fournisseur qui paraissait solide à l'entrée peut changer : un dirigeant démissionne, l'entreprise entre en procédure collective, une filiale apparaît sur une liste de sanctions dix-huit mois plus tard. Personne ne relance le contrôle initial, parce qu'il n'a jamais été construit pour être rejoué. Les équipes finance vivent le même écart autrement : une facture réglée à un fournisseur déjà en procédure collective, ou virée à une entité qui n'existe plus légalement, est de l'argent qui ne revient pas.

La loi française relative au devoir de vigilance et la directive européenne CSDDD (Corporate Sustainability Due Diligence Directive) demandent une même base : confirmer que la contrepartie existe et est active, la cribler pour une exposition aux sanctions, et savoir si elle est en difficulté financière — au référencement et à nouveau ensuite. Prometiam n'est pas un conseil juridique sur le point de savoir si une relation fournisseur donnée satisfait l'une ou l'autre obligation ; c'est la couche identité, statut, sanctions et procédures collectives que le dossier de diligence doit montrer avoir été vérifiée.

Le principe

Cinq appels, tous exécutables par lot, pour faire avancer toute une base fournisseurs d'un coup plutôt qu'une ligne à la fois :

  1. Résoudre. POST /companies/lookup accepte jusqu'à 100 fournisseurs par appel — par company_number, siren, nif, vat, ou un name approximatif avec match_score — et renvoie un identifiant officiel par ligne.
  2. Vérifier. GET /companies/{id}?include=risk_flags,insolvency,lei récupère la fiche complète : status, dissolution_date, dirigeants là où le registre les tient, l'indicateur AEAT espagnol, et le LEI éventuel.
  3. Cribler. POST /sanctions/screen vérifie la raison sociale et chaque dirigeant contre les listes de sanctions et de contrôle des exportations américaines — jusqu'à 50 noms, avec un threshold que vous fixez. Bêta, périmètre Professional.
  4. Vérifier les procédures collectives. POST /insolvency/check couvre seize marchés en un appel, jusqu'à 100 éléments ; pour un fournisseur français, GET /insolvency/search?country=FR répond directement.
  5. Continuer la surveillance. POST /monitor pousse des alertes webhook pour tous les pays servis sauf la France et le Chili ; un balayage quotidien GET /company-events/search fait le même travail par sondage pour l'Espagne, la France et le Royaume-Uni.
# 1. Résoudre chaque fournisseur vers un identifiant officiel — jusqu'à 100 par appel
curl -X POST "https://api.prometiam.com/functions/v1/risk-api/companies/lookup" \
  -H "Authorization: Bearer rk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      { "country": "FR", "siren": "552032534" },
      { "country": "ES", "company_number": "A46103834" }
    ]
  }'

# 2. Récupérer la fiche : status, dissolution_date, dirigeants, l'indicateur
#    AEAT (Espagne uniquement) et le bloc LEI
curl "https://api.prometiam.com/functions/v1/risk-api/companies/812044?include=risk_flags,insolvency,lei" \
  -H "Authorization: Bearer rk_live_..."

# 3. Cribler la raison sociale et chaque dirigeant — offre Professional, bêta
curl -X POST "https://api.prometiam.com/functions/v1/risk-api/sanctions/screen" \
  -H "Authorization: Bearer rk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "names": ["ACME TRADING SAS"], "threshold": 85 }'

# 4. Procédures collectives françaises — lecture directe ou par lot
curl "https://api.prometiam.com/functions/v1/risk-api/insolvency/search?country=FR&company_number=552032534" \
  -H "Authorization: Bearer rk_live_..."
curl -X POST "https://api.prometiam.com/functions/v1/risk-api/insolvency/check" \
  -H "Authorization: Bearer rk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "items": [ { "country": "FR", "company_number": "552032534" } ] }'

# 5. Continuer la surveillance : un webhook pour l'Espagne, l'Irlande et la
#    Pologne, ou un balayage quotidien pour l'Espagne, la France et le R-U
curl -X POST "https://api.prometiam.com/functions/v1/risk-api/monitor" \
  -H "Authorization: Bearer rk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "company_id": 812044,
    "country": "ES",
    "webhook_url": "https://votre-erp.example.com/hooks/prometiam"
  }'

Un exemple concret

En pratique, cela tourne comme un traitement par lot sur votre base fournisseurs : extraire la liste, la découper en lots de 100, écrire une ligne de résultat par fournisseur.

import os, csv, requests

API = "https://api.prometiam.com/functions/v1/risk-api"
HEAD = {"Authorization": f"Bearer {os.environ['PROMETIAM_API_KEY']}"}
INSOLVENCY_COUNTRIES = {"FR", "DE", "GB", "AT", "CH", "NO", "FI", "US", "NL", "DK", "HR", "SE"}

def lots(items, taille=100):
    for i in range(0, len(items), taille):
        yield items[i:i + taille]

def controler_base(fournisseurs):
    # fournisseurs : [{"country": "FR", "siren": "552032534"}, ...]
    lignes = []
    for lot in lots(fournisseurs, 100):
        resolus = requests.post(f"{API}/companies/lookup", json={"items": lot}, headers=HEAD).json()["data"]
        for fournisseur, resultat in zip(lot, resolus):
            entreprise = resultat.get("company")
            ligne = {"pays_saisi": fournisseur["country"],
                     "id_saisi": fournisseur.get("company_number") or fournisseur.get("siren") or fournisseur.get("name"),
                     "status": resultat["status"], "company_id": None, "raison_sociale": None,
                     "statut_registre": None, "sanctions": None, "procedure_collective": None}
            if entreprise:
                ligne["company_id"], ligne["raison_sociale"], ligne["statut_registre"] = (
                    entreprise["id"], entreprise["company_name"], entreprise["status"])
                crible = requests.post(f"{API}/sanctions/screen", headers=HEAD,
                    json={"names": [entreprise["company_name"]], "threshold": 85}).json()["data"][0]
                ligne["sanctions"] = crible["status"]  # match | clear | error | timeout
                if fournisseur["country"] in INSOLVENCY_COUNTRIES:
                    ins = requests.post(f"{API}/insolvency/check", headers=HEAD, json={"items": [
                        {"country": fournisseur["country"], "company_number": entreprise["company_number"]}]}).json()["data"][0]
                    ligne["procedure_collective"] = ins["status"]  # found | none | error | timeout
                elif fournisseur["country"] == "ES":
                    avis = requests.get(f"{API}/search", headers=HEAD,
                        params={"vat": entreprise["company_number"], "country": "ES"}).json()["data"]
                    ligne["procedure_collective"] = "found" if avis else "none"
                # Irlande et Pologne : pas encore de couverture des procédures
                # collectives, la colonne reste vide
            lignes.append(ligne)
    return lignes

fournisseurs = [{"country": "FR", "siren": "552032534"}, {"country": "ES", "company_number": "A46103834"}]
lignes = controler_base(fournisseurs)
with open("resultats_fournisseurs.csv", "w", newline="") as f:
    w = csv.DictWriter(f, fieldnames=list(lignes[0].keys()))
    w.writeheader()
    w.writerows(lignes)

Une quarantaine de lignes. Le script résout un lot de 100 fournisseurs par appel, puis crible et vérifie les procédures collectives uniquement pour ceux effectivement trouvés — en routant vers l'endpoint qui couvre le pays du fournisseur, et en laissant la colonne vide pour l'Irlande et la Pologne plutôt que de renvoyer un faux "none".

Ce que renvoie l'API

La résolution renvoie un résultat par fournisseur, dans l'ordre d'envoi : un status found, not_found, error ou timeout ; l'objet company résolu ou null ; et un match_score quand la correspondance vient d'un nom plutôt que d'un identifiant exact. meta.found et meta.not_found donnent les totaux du lot.

La fiche entreprise ajoute status, dissolution_date, founding_date, le capital enregistré, et contacts — pour chaque dirigeant, full_name, role, appointment_date et is_current — plus, sur demande, l'indicateur AEAT espagnol (point-in-time) et la fiche LEI de l'entreprise.

Le criblage de sanctions renvoie un status match, clear, error ou timeout par nom, avec des hits portant match_score, source_list, program et listing_date. La vérification des procédures collectives renvoie un status found, none, error ou timeout, jusqu'à cinq notices classés du plus récent, et latest_filing_date. Un résultat none ou clear signifie qu'aucune correspondance n'a été trouvée dans les marchés couverts — pas la preuve que le fournisseur est solvable ou absent de toute liste ailleurs.

Capture du tableau de bord client : la fiche d'une entreprise avec identifiants et signauxCapture du tableau de bord client : la fiche d'une entreprise avec identifiants et signaux
La même fiche dans le tableau de bord : identifiants, siège social et signaux d'insolvabilité, de sanctions (bêta) et de registre sur une page. Exemple : une société du Royaume-Uni. Ouvrir dans le tableau de bord

Les limites, dites clairement

Les cinq étapes ci-dessus ne couvrent pas chaque pays de la même façon. Voici ce que chaque pays supporte réellement :

PaysDirigeants à criblerAvis d'insolvabilitéWebhookBalayage quotidien
EspagneOuiOui — POST /insolvency/check, rattachés par le NIF (aussi sur GET /search)OuiOui
FranceOuiOui — POST /insolvency/check et GET /insolvency/search?country=FRNonOui
Royaume-UniOuiOui — POST /insolvency/checkNonOui
IrlandeNon — niveau entreprisePas de couvertureOuiNon
PologneNon — niveau entreprisePas de couvertureOuiNon
NorvègeOuiOui — POST /insolvency/checkNonChangements du registre, depuis le 14 oct. 2026
FinlandeNon — fiches société uniquementOui — POST /insolvency/check, rattachés par l'identifiant d'entrepriseOuiOui — événements de changement du registre
SuèdeNon — fiches société uniquementOui — POST /insolvency/check, rattachés par l'organisationsnummerOuiOui — événements de changement du registre
BelgiqueNon — fiches société uniquementPas de couvertureOuiOui — événements de changement du registre
CroatieNon — fiches société uniquementOui — POST /insolvency/check, rattachés par le MBSOuiOui — événements de changement du registre
DanemarkNon — fiches société uniquementOui — POST /insolvency/check, rattachés par le numéro CVROuiOui — événements de changement du registre
EstonieNon — fiches société uniquementOui — POST /insolvency/check, rattachés par le code du registreOuiOui — événements de changement du registre
SlovaquieNon — fiches société uniquementPas de couvertureOuiOui — événements de changement du registre

La résolution et la fiche entreprise (étapes 1 et 2) fonctionnent pareil pour tous les pays couverts. Le criblage de sanctions tourne lui aussi sur tous — offre Professional, bêta.

  • Les bénéficiaires effectifs se limitent au registre britannique Persons with Significant Control. Un fournisseur avec un LEI ajoute les parents de niveau 2 du GLEIF via GET /lei/{lei}/relationships.
  • Les indicateurs de risque se limitent à l'Espagne : la liste AEAT des grands débiteurs est point-in-time, publiée environ six mois après le 31 décembre qu'elle décrit.
  • Le criblage PPE existe (bêta, Espagne uniquement, sans proches ni associés) mais reste un indicateur distinct, hors de ce parcours.
  • Prometiam ne renvoie ni note de crédit, ni état financier, ni donnée ESG. L'historique des attributions de marchés publics est un endpoint distinct pour l'Espagne, la France, le Royaume-Uni, l'Irlande, la Pologne et la Norvège (marchés publics).

Coût selon votre volume

POST /companies/lookup, GET /companies/{id} et POST /insolvency/check s'exécutent sur le même périmètre de base qu'une simple recherche d'entreprise, donc une base de 2 000 fournisseurs représente 2 000 + 2 000 + 4 000 = 8 000 crédits (1 par recherche, 1 par fiche, 2 par vérification d'insolvabilité) — plus que ce qu'inclut l'offre Starter (9,99 €/mois, 1 000 crédits, 60 req/min), il faut donc l'offre Professional.

Le criblage de sanctions est la seule étape limitée par le périmètre plutôt que par le volume : POST /sanctions/screen demande l'offre Professional (29,99 €/mois, 10 000 crédits, 120 req/min), quelle que soit la taille de la base — c'est aussi là que le criblage complet des sanctions et du contrôle des exportations s'active vraiment. Cribler les 2 000 noms ajoute 6 000 crédits (3 par nom), soit 14 000 avec les trois autres étapes : Professional couvre la base en deux mois et Scale (99,99 €/mois, 50 000 crédits, 300 req/min) en un, avec de la marge pour un recontrôle mensuel.

Chaque élément d'un lot compte pour une requête. Un lot plus grand que ce qu'il reste sur l'offre est refusé d'emblée avec 429 batch_exceeds_quota, et max_items_now dans la réponse indique combien tiennent à cet instant.

Questions fréquentes

Qu'est-ce qu'une diligence fournisseur complète ?
Au minimum : confirmer que l'entité existe et qu'elle est active, cribler sa raison sociale et ses dirigeants là où le registre les tient, et vérifier l'absence de procédure collective. La loi française sur le devoir de vigilance et la directive CSDDD demandent cette même base. Prometiam n'est pas un conseil juridique sur la conformité d'une relation donnée — l'API fournit les vérifications d'identité, de statut, de sanctions et de procédures collectives que le dossier doit montrer avoir été faites.

Puis-je lancer cela sur plusieurs milliers de fournisseurs en une fois ?
Oui. POST /companies/lookup et POST /insolvency/check acceptent chacun jusqu'à 100 éléments par appel, POST /sanctions/screen jusqu'à 50 noms. Chaque élément compte pour une requête ; un lot trop grand est refusé d'emblée avec 429 batch_exceeds_quota, et max_items_now indique combien tiennent à cet instant. Le criblage de sanctions demande en plus l'offre Professional ; les trois autres endpoints fonctionnent sur toutes les offres.

Cela couvre-t-il les bénéficiaires effectifs, pas seulement les dirigeants ?
Seulement pour le Royaume-Uni, via le registre Persons with Significant Control sur la fiche entreprise. L'Espagne, la France, le Royaume-Uni et la Norvège renvoient tous des dirigeants, mais un dirigeant n'est pas un bénéficiaire effectif. L'Irlande est couverte au niveau entreprise : pas de dirigeants, pour aucun des deux usages. Pour un fournisseur avec un identifiant LEI, GET /lei/{lei}/relationships ajoute les parents directs et ultimes de niveau 2 du GLEIF.

Quels pays ont réellement une couverture des procédures collectives pour un contrôle fournisseur ?
La France, le Royaume-Uni, la Norvège et la Finlande sont couverts, entreprises uniquement, via POST /insolvency/check — pour un fournisseur français, GET /insolvency/search?country=FR répond directement à la même question. Le Danemark, la Croatie, la Suède, l'Espagne, la Lettonie, l'Estonie et la Suisse sont couverts avec leur registre d'entreprise (les avis suisses sont rattachés à la fiche par l'UID lorsque l'avis le nomme) ; d'autres marchés le sont sans registre d'entreprise associé chez Prometiam : Allemagne, Autriche, États-Unis et Pays-Bas. Les procédures concursales espagnoles restent aussi consultables sur GET /search. L'Irlande et la Pologne n'ont pour l'instant aucune couverture des avis d'insolvabilité, sur aucun des deux endpoints, pas plus que la Belgique ou la Slovaquie (leur faillite apparaît dans le statut de l'entreprise).

Comment continuer à surveiller un fournisseur après son référencement ?
Deux façons. POST /monitor pousse un webhook signé sur les changements de statut, la dissolution et les nouvelles correspondances de sanctions, pour tous les pays servis sauf la France et le Chili. Pour l'Espagne, la France et le Royaume-Uni, un balayage quotidien GET /company-events/search capte capital_change, director_change, dissolution et le reste. La Norvège n'a que des événements de changement du registre, depuis le 14 octobre 2026 (sans bulletin) ; un fournisseur norvégien se surveille avec POST /monitor.

Voir aussi