API de Risk Scoring : intégrer la due diligence dans votre ERP/CRM (guide développeurs)

Quand un acheteur crée un nouveau fournisseur dans votre ERP, ou qu'un commercial ouvre un compte client dans votre CRM, une décision de risque se joue silencieusement. La faire reposer sur une vérification manuelle en aval, c'est accepter des trous de vigilance. L'enjeu pour une équipe technique française n'est plus « faut-il vérifier ? » mais « comment câbler la due diligence directement dans le flux applicatif », de façon fiable, traçable et conforme au RGPD. Ce guide s'adresse aux développeurs et architectes qui veulent brancher une API de risk scoring sur leur SI : cas d'usage concrets, patterns d'intégration REST, idempotence, gestion des quotas, webhooks d'alerte et gouvernance des données.

Pourquoi câbler le risk scoring dans le SI plutôt qu'à côté

La plupart des organisations font déjà de la vérification de tiers, mais dans un outil séparé : un onglet navigateur, un tableur, un portail. Le résultat est prévisible — la vérification devient une étape optionnelle, oubliée sous la pression opérationnelle, et surtout jamais rejouée dans le temps. Intégrer le scoring par API répond à trois besoins que l'ERP/CRM seul ne couvre pas.

• Déclencher au bon moment. Le contrôle s'exécute exactement quand l'information est saisie : création d'un compte fournisseur, ajout d'un nouveau bénéficiaire de virement, ouverture d'un dossier client.
• Rester à jour. Un tiers « propre » à l'onboarding peut basculer en procédure collective six mois plus tard. Seul un flux continu, alimenté par des webhooks, capte ce changement.
• Prouver la diligence. Chaque appel API horodaté et journalisé constitue une trace exploitable en cas de contrôle interne, d'audit ou de demande d'un régulateur.

Sur ce dernier point, le devoir de vigilance qui pèse sur beaucoup d'acteurs français — professionnels du chiffre, secteur financier, donneurs d'ordre soumis au dispositif anticorruption — suppose une vigilance constante et documentée, pas un instantané. L'API est le moyen technique de matérialiser cette continuité. Pour l'arbitrage de fond entre contrôle ponctuel et surveillance permanente, voir notre analyse dédiée au monitoring continu des tiers face à la vérification ponctuelle.

Trois cas d'usage français concrets

1. Screening à la création d'un fournisseur dans l'ERP

Un utilisateur enregistre un nouveau fournisseur avec son SIREN. Un hook applicatif (déclencheur base de données, extension côté ERP, ou middleware) appelle l'API de scoring de façon synchrone ou quasi synchrone. Le SI reçoit en retour un statut de risque et des signaux structurés, qu'il stocke sur la fiche tiers. Selon la note, le workflow d'achat peut être libre, mis en attente de validation, ou bloqué jusqu'à revue humaine. L'idée n'est pas que l'API rende un verdict à la place du compliance officer, mais qu'elle oriente la fiche vers le bon circuit. Ce mécanisme s'articule naturellement avec un process d'onboarding fournisseur KYB structuré.

2. Mise à jour et réconciliation sur le SIREN

Les identifiants légaux évoluent : un établissement ferme, une entreprise change de dénomination, un dirigeant est remplacé. Un job périodique parcourt les tiers actifs, réinterroge l'API sur chaque SIREN et met à jour les attributs (état administratif, statut de diffusion, dirigeants). C'est aussi l'occasion de détecter les incohérences — un SIREN cessé toujours facturé, une raison sociale qui ne correspond plus. Pour comprendre ce qui se cache derrière ces identifiants, le guide de vérification d'une entreprise française via SIREN, SIRET et RNE pose les fondations.

3. Webhook d'alerte sur défaillance BODACC

C'est le pattern le plus créateur de valeur. Vous abonnez vos tiers surveillés à un flux d'événements. Lorsqu'une annonce paraît — ouverture de procédure collective, jugement de liquidation, privilège inscrit — l'API vous notifie par webhook. Votre SI peut alors geler automatiquement un encours, alerter le credit manager ou repositionner la limite de crédit du client. Le détail des signaux à surveiller est couvert dans notre guide complet des procédures collectives et du BODACC.

Architecture d'intégration : les patterns qui tiennent

Appels REST et modèle de données

Une API de scoring moderne s'expose en REST/JSON sur HTTPS, authentifiée par clé d'API ou jeton porteur transmis dans l'en-tête Authorization. Deux styles d'appel cohabitent :

• Synchrone pour les lookups légers (résolution d'un SIREN, statut administratif) : la réponse arrive dans la foulée, adaptée à un formulaire de saisie.
• Asynchrone pour une analyse approfondie qui agrège plusieurs sources : vous lancez un job (réponse 202 Accepted + identifiant), puis vous récupérez le résultat par polling sur un endpoint de statut, ou vous attendez un webhook. Ce découplage évite de bloquer l'interface pendant l'agrégation.

Idempotence : ne pas rejouer deux fois

Un réseau instable, un retry automatique côté client, un double-clic utilisateur : sans garde-fou, le même tiers est screené plusieurs fois et vous consommez du quota pour rien, voire vous créez des doublons de dossiers. La parade est une clé d'idempotence, un identifiant unique que votre client génère par opération métier (par exemple un hash du SIREN + contexte + fenêtre temporelle) et qu'il envoie dans un en-tête dédié. Le serveur, s'il reçoit deux fois la même clé, renvoie le résultat déjà calculé au lieu de relancer un traitement. Côté implémentation, prévoyez toujours des retries avec backoff exponentiel sur les erreurs 429 et 5xx, jamais sur les 4xx de validation.

Gestion des quotas et du débit

Toute API sérieuse applique un rate limiting. Traitez les réponses 429 Too Many Requests comme un signal normal, pas comme une erreur : respectez l'en-tête Retry-After quand il est présent, et lissez vos campagnes de re-screening massif avec une file d'attente plutôt qu'une rafale d'appels. Pour un re-scan de portefeuille, un traitement par lots nocturne, cadencé et reprenable après interruption, est nettement plus robuste qu'un envoi en parallèle non régulé.

Webhooks : réception fiable

Pour consommer les alertes, exposez un endpoint HTTPS public. Trois règles de survie : vérifiez la signature de chaque payload (secret partagé) pour rejeter les appels forgés ; répondez vite (2xx immédiat) puis traitez en tâche de fond, afin d'éviter les redéliveries pour cause de timeout ; soyez idempotent en réception, car un webhook peut être livré plusieurs fois. Persistez l'identifiant d'événement et ignorez les doublons.

Tableau des endpoints types et de leur usage

Les noms d'endpoints ci-dessus illustrent un schéma d'intégration courant ; reportez-vous toujours à la documentation de votre fournisseur pour les chemins exacts, les schémas de réponse et les codes d'erreur.

Exemple de flux de bout en bout

Voici un enchaînement représentatif du parcours « création fournisseur → surveillance » :

1. L'acheteur enregistre un fournisseur avec son SIREN dans l'ERP.
2. Un hook appelle GET /resolve/siren en synchrone : identité et état administratif remontent immédiatement sur la fiche.
3. En parallèle, le SI poste sur /screen avec une clé d'idempotence ; il reçoit un 202 et un job_id.
4. Le résultat est récupéré par polling ou webhook ; la note et les signaux sont stockés, et la fiche est routée (validation libre / revue / blocage).
5. Le tiers est abonné via /watch. Toute annonce ultérieure (procédure collective, changement de dirigeant) déclenche un webhook signé.
6. À réception, le SI met à jour la fiche, notifie le credit manager et, si configuré, ajuste l'encours autorisé.

Ce type d'orchestration se conçoit bien à partir d'une checklist KYC fournisseur en 10 étapes, qui définit quoi vérifier avant de coder le comment.

Gouvernance des données : RGPD et journalisation

Intégrer une API de risk scoring, c'est traiter des données à caractère personnel (dirigeants, bénéficiaires effectifs, parfois personnes physiques). Quelques principes non négociables pour une équipe technique française :

• Base légale et finalité. Le traitement s'appuie généralement sur l'obligation légale (dispositif de vigilance) ou l'intérêt légitime, strictement borné à la finalité de conformité — jamais de réutilisation détournée.
• Minimisation. N'appelez l'API qu'avec les données nécessaires (un SIREN plutôt qu'un dossier complet quand c'est suffisant) et ne stockez que ce qui sert la décision.
• Journalisation. Conservez une trace horodatée de chaque appel : qui a déclenché la vérification, sur quel tiers, quand, et quel résultat a été rendu. Cette piste d'audit sert autant la conformité RGPD (traçabilité) que la preuve de diligence.
• Durée de conservation. Définissez une politique de purge alignée sur vos obligations documentaires, et sécurisez les journaux comme des données sensibles (chiffrement, accès restreint).
• Sous-traitance. Le fournisseur d'API est un sous-traitant au sens du RGPD : encadrez la relation par contrat et vérifiez la localisation d'hébergement.

Ces exigences sont détaillées dans notre article sur le RGPD appliqué à la due diligence des tiers, à lire avant toute mise en production.

Bonnes pratiques d'implémentation en synthèse

• Isolez l'intégration derrière un service interne (adaptateur) plutôt que d'appeler l'API depuis partout : vous centralisez authentification, retries et journalisation.
• Traitez les scores comme une recommandation à intégrer dans un workflow humain de décision, pas comme un verrou automatique irréversible sur une entité nommée.
• Gérez proprement les cas dégradés : une source indisponible ne doit pas planter la fiche, mais afficher un statut « analyse partielle ».
• Testez les webhooks avec des rejeux et des doublons volontaires ; l'idempotence de réception est la première chose qui casse en production.

Pour la logique métier sous-jacente au calcul d'une note à partir de données publiques, notre article sur l'analyse financière automatisée et le score de risque éclaire ce que représente — et ne représente pas — un score.

Questions fréquentes

Une API de risk scoring peut-elle décider seule de bloquer un fournisseur ?

Techniquement oui, mais ce n'est pas recommandé sur des cas nominatifs sensibles. L'API produit un score et des signaux ; la décision de bloquer, suspendre ou libérer un tiers doit rester encadrée par une revue humaine, surtout au-delà d'un seuil de risque. RiskSonnar formule une recommandation, pas un verdict juridique définitif sur une entité donnée.

Comment éviter de consommer du quota inutilement lors des retries ?

Utilisez une clé d'idempotence par opération métier et des retries à backoff exponentiel limités aux erreurs 429 et 5xx. Le serveur renvoie alors le résultat déjà calculé au lieu de relancer un traitement, et vos campagnes de masse passent par une file cadencée plutôt qu'une rafale d'appels.

Faut-il appeler l'API en synchrone ou en asynchrone ?

Les deux, selon le besoin. Un lookup léger (résolution d'un SIREN à la saisie) gagne à être synchrone pour ne pas ralentir l'utilisateur. Une analyse approfondie multi-sources se traite en asynchrone (job + polling ou webhook) pour ne pas bloquer l'interface pendant l'agrégation.

Quelles données faut-il journaliser pour rester conforme ?

Au minimum : l'identité du déclencheur, le tiers concerné, l'horodatage, la finalité et le résultat rendu. Ces journaux servent la traçabilité RGPD et la preuve de diligence. Sécurisez-les comme des données sensibles et définissez une durée de conservation alignée sur vos obligations documentaires.

Les webhooks peuvent-ils être livrés en double ?

Oui, c'est le comportement normal des systèmes de livraison « at-least-once ». Votre endpoint doit vérifier la signature du payload, répondre vite, puis dédupliquer sur l'identifiant d'événement pour ne pas rejouer deux fois la même action métier.

Conclusion

Brancher une API de risk scoring sur son ERP/CRM transforme la due diligence d'une corvée ponctuelle en un réflexe systémique : contrôle au bon moment, mise à jour continue sur le SIREN, alerte immédiate sur défaillance BODACC, le tout traçable et conforme au RGPD. Les patterns techniques — appels REST, idempotence, gestion des quotas, webhooks signés — ne sont pas exotiques ; ils demandent simplement d'être posés dès la conception plutôt qu'après coup.

Si vous voulez tester la donnée avant d'écrire la moindre ligne d'intégration, commencez par vérifier un SIREN ou explorez l'approche de RiskSonnar côté produit.