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. La situation d’un tiers peut évoluer après l’onboarding. Selon le contrat de l’API, combinez recontrôles planifiés, polling ou webhooks ; aucun mécanisme ne dispense de vérifier la fraîcheur et la disponibilité de chaque source.
• Tracer la diligence. Un journal d’appel n’est utile que s’il conserve le tiers, la finalité, l’horodatage, le résultat, les sources effectivement consultées et leurs limites. Il contribue à la piste d’audit sans prouver, à lui seul, que la vigilance était suffisante.

La fréquence et la profondeur du contrôle dépendent du texte applicable, du secteur et du niveau de risque. Une API peut matérialiser une politique de recontrôle, mais elle ne crée pas une obligation générale de surveillance continue. Pour choisir entre contrôle ponctuel et suivi, voir notre analyse du 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

RiskSonnar ne propose pas encore de webhooks dans cette version : ce besoin passe alors par le recontrôle périodique décrit au cas 2. Si le contrat d’une API expose un abonnement couvrant l’événement recherché, un webhook peut déclencher une revue sans attendre le prochain traitement par lot. Vérifiez explicitement le type d’événement, la source, la latence annoncée et la politique de livraison. Le SI peut alors ouvrir une tâche ou suspendre une action selon une règle validée ; un gel automatique d’encours ne doit pas découler d’un signal non confirmé. Le détail des signaux judiciaires 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 ou un retry client peut créer plusieurs analyses du même tiers. Utilisez une clé d’idempotence seulement si le contrat OpenAPI documente l’en-tête et sa durée de rétention ; sinon, dédupliquez côté ERP avec un identifiant d’opération et stockez l’identifiant de job retourné. Les retries doivent respecter la sémantique de la méthode, Retry-After lorsqu’il est fourni et une limite stricte. Certains 4xx, comme 408 ou 429, peuvent être rejoués selon le contrat ; il ne faut donc pas appliquer une règle « jamais sur les 4xx » sans lire la documentation.

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

Si l’API utilisée propose des webhooks (ce n’est pas encore le cas de RiskSonnar dans cette version), exposez un endpoint HTTPS protégé pour consommer les alertes. Appliquez le mécanisme d’authentification ou de signature effectivement documenté par le fournisseur ; ne présumez pas qu’un secret partagé existe. Accusez réception selon le délai contractuel, traitez en arrière-plan et dédupliquez à partir de l’identifiant d’événement lorsqu’il est fourni. La politique de retry et le caractère « au moins une fois » doivent être confirmés dans le contrat de livraison.

Tableau des endpoints types et de leur usage

Ce tableau est volontairement générique. Au 11 septembre 2026, le contrat public RiskSonnar est le fichier OpenAPI ; il expose notamment des routes sous /api/v1/scan et /api/v1/scan-batch. Des routes de webhooks y figurent, mais les webhooks ne sont pas encore proposés dans cette version. Les chemins simplifiés du tableau ne sont pas des endpoints promis : le fichier OpenAPI publié prévaut pour les schémas, l’authentification et les codes d’erreur.

Exemple de flux de bout en bout

Voici un enchaînement illustratif du parcours « création fournisseur → surveillance ». Remplacez chaque chemin par celui du contrat OpenAPI déployé et n’activez une étape que si la capacité correspondante y est documentée :

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 ; 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) est relevée au recontrôle suivant : il n’y a pas encore de webhooks dans cette version.
6. À chaque changement relevé, 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é. Déterminez et documentez la base légale adaptée au traitement ; obligation légale et intérêt légitime ne sont ni automatiques ni interchangeables. Définissez la finalité avant l’intégration et analysez les droits des personnes concernées.
• 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).
• Rôles RGPD. Qualifiez au cas par cas responsable de traitement, sous-traitant ou responsables conjoints. Si le fournisseur agit comme sous-traitant, encadrez la relation conformément à l’article 28 et vérifiez hébergement et transferts.

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 ».
• Si l’API propose des webhooks, testez-les 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 ?

Si l’API documente une clé d’idempotence, utilisez-la selon sa portée et sa durée de rétention. Sinon, dédupliquez dans votre SI et réutilisez l’identifiant de job connu. Limitez les retries, respectez Retry-After et ne rejouez une requête non idempotente que lorsque le contrat le permet.

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) 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 sont-ils disponibles dans cette version ?

Non. Les webhooks ne sont pas encore disponibles dans cette version. Utilisez le contrat OpenAPI publié pour connaître les capacités disponibles.

Conclusion

Brancher une API de risk scoring sur un ERP/CRM peut rendre les contrôles plus réguliers et plus traçables, à condition de respecter le contrat réellement publié. Disponibilité d’une source, fraîcheur, idempotence, signatures, retries et couverture des événements doivent être vérifiés explicitement. La conformité RGPD dépend ensuite de la finalité, des rôles, des durées et des mesures de sécurité retenues ; elle n’est pas acquise par la seule intégration technique.

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.