Mettre en place un flux de surveillance continue

Comment maintenir vos résultats de vérification à jour au fil des changements des listes, avec notre API ou des fichiers delta, sans submerger les réviseurs de mises à jour de routine.

La vérification contrôle une partie une seule fois. La surveillance continue la contrôle de nouveau chaque fois que les listes changent et ne déclenche une alerte que lorsqu’un élément nouveau est important. Nous n’exploitons pas de service de surveillance pour nos clients : ce guide explique comment en bâtir un à partir de notre API ou de nos fichiers en vrac.

À venir : indiquer si nous prévoyons offrir un service hébergé de surveillance ou d’alertes, et à quel moment. Rien sur cette page ne doit être interprété comme une telle offre.

Vérification et surveillance continue

La surveillance continue répète trois étapes : repérer que les données ont changé, revérifier les parties susceptibles d’être touchées, puis comparer les nouveaux résultats aux décisions que vous avez déjà prises. La troisième étape est la plus difficile : un bon système de surveillance déclenche une alerte pour une nouvelle inscription, et non pour chaque mise à jour de routine des données.

Construire votre état des alertes

Concevoir d’abord le modèle d’alertes

Partez de vos obligations : quelles listes, quels programmes et quels territoires comptent pour vous. Conservez ensuite une décision par paire formée de votre partie et de notre fiche, identifiée par l’id de notre fiche (et par le merged_entity lorsqu’il y en a un), afin que la prochaine exécution distingue les nouvelles correspondances de celles déjà connues.

Deux décisions par alerte

Résolution : cette fiche correspond-elle à la même partie que la vôtre? Confirmée, non-correspondance ou en suspens. Un changement de nom ou de date de naissance de notre côté peut la rouvrir.
Pertinence : l’inscription est-elle importante pour vous? Elle se décide à partir de topics, list_type, programme et du registre. Un nouveau programme ou un nouveau registre pour une partie connue peut rendre pertinente une correspondance déjà écartée.

Ce qu’il faut conserver pour chaque correspondance

Champ	Raison
Votre ID de partie	Relie l’alerte à la fiche de votre client.
`id` de la fiche	L’entrée du registre qui a donné la correspondance. Servez-vous-en pour revérifier la fiche.
`merged_entity` et ses `referents`	La partie à travers les registres, et les fiches à partir desquelles elle a été constituée.
`score` et `features`	Pourquoi la correspondance a été établie, pour l’audit et pour repérer une dérive des scores.
Résolution	Votre décision : confirmée, non-correspondance ou en suspens.
Pertinence	Indique si l’inscription est importante au regard de vos obligations.
`datasets`	Les registres qui inscrivaient la partie au moment de la décision.
`topics` et `programme`	Le type d’inscription et le programme visé.
Collection `version`	Issu de `/api/catalog` : la version des données utilisée pour la vérification.
`checked_at`	Le moment où la vérification a été effectuée.

La nouvelle alerte dépend de vos obligations

Une institution canadienne assujettie à la Special Economic Measures Act et à la Justice for Victims of Corrupt Foreign Officials Act se préoccupe d’abord des inscriptions canadiennes; celle qui a une exposition aux États-Unis s’intéresse aussi à OFAC. Consignez les registres et les programmes visés pour chaque secteur d’activité, et ne générez une nouvelle alerte que lorsqu’un changement les touche. Les noms de registres proviennent de datasets; filtrez avec include_dataset.

Quand alerter de nouveau au sujet d’une partie connue

La résolution a peut-être changé : les noms, la date de naissance ou la nationalité de la fiche ont changé, ou le score a varié au-delà de votre tolérance.
La pertinence a peut-être changé : nouveau topics, nouveau programme ou nouveau registre dans datasets ou dans l’entité fusionnée.
Les deux : la partie a fait l’objet d’une radiation de la liste (la fiche ne répond plus) ou une nouvelle fiche la concernant est apparue.

La vérification d’une fiche conservée se fait en un seul GET /api/entity/<id>?nested=false.

Fusions et scissions

Lorsque nous associons des fiches d’une même partie, elles reçoivent un ID d’entité fusionnée commun; lorsque nous les dissocions, cet ID change. Dans les deux cas, une ancienne alerte peut sembler nouvelle. Pour y remédier :

Associez vos décisions à l’ID de la fiche, et pas seulement à l’ID fusionné.
Lorsqu’un nouveau résultat partage un ID fusionné avec une fiche que vous avez déjà réglée, affichez la décision antérieure à la personne chargée de la révision.
Lorsqu’une fiche conservée répond 308, suivez-la jusqu’à l’entité fusionnée et reportez votre décision après révision.
Attendez-vous à ce que le score varie lorsque des fiches sont reliées : une vue fusionnée peut contenir davantage de noms et de dates.
Revérifiez périodiquement les identifiants de fiches conservés; voir Garder à jour vos identifiants conservés.

Comment les données changent

Trois sources de changement

Le publicateur : un registre ajoute, modifie ou retire des entrées.
Notre traitement : nous améliorons la façon dont un registre est lu (types, dates, pays, programmes), ce qui modifie des fiches sans changement à la source.
Le couplage : des fiches sont reliées à une entité fusionnée ou en sont dissociées.

Le problème du bruit

Seul le premier type de changement constitue habituellement une nouvelle. Les deuxième et troisième peuvent toucher de nombreuses fiches à la fois. Comparez les valeurs qui comptent pour vos décisions (noms, date de naissance, nationalité, sujets, programme, registre), et non la fiche entière, avant de déclencher une alerte.

Choisir une approche

	Revérification avec l’API	Application de fichiers delta
Mise en place	Renvoyez périodiquement vos parties à `/api/match` selon un calendrier.	Chargez les fichiers en vrac une fois, puis appliquez `delta.json` après chaque version.
Ingénierie	Modeste : une tâche planifiée et une table de décisions.	Plus importante : une copie locale des données, le traitement des deltas et votre propre moteur de correspondance.
Filtrage de la portée	Filtres de collection, de `topics` et de registre à chaque requête.	Filtrez vous-même les fichiers ou les deltas.
Détecter les changements de pertinence	Chaque revérification tient compte des sujets et des programmes actuels.	Comparez les anciennes et les nouvelles versions des entités modifiées.
Délai	Aussi souvent que vous le planifiez, après chaque version.	Après chaque version, une fois les deltas publiés.
Condition préalable	Utilisation sous licence de l’API.	Une licence de données en vrac.

À venir : indications sur la taille de portefeuille à partir de laquelle la surveillance par deltas devient préférable à la revérification par l’API.

Surveillance continue avec l’API

Nouvelle vérification planifiée

Interrogez /api/catalog et notez le version de chaque collection.
Lorsque la version change, renvoyez vos parties à /api/match/<collection> par lots de 20, avec les mêmes filtres et le même seuil qu’auparavant.
Comparez chaque résultat à vos décisions enregistrées, en appliquant les règles ci-dessus.
Mettez en file d’attente, pour examen, les correspondances nouvelles ou modifiées, et enregistrez le nouveau checked_at ainsi que la version.

curl "https://api.crownintelligence.net/api/catalog"

import requests

BASE = "https://api.crownintelligence.net"
catalog = requests.get(f"{BASE}/api/catalog", timeout=30).json()
versions = {c["name"]: c["version"] for c in catalog["collections"]}
print(versions)  # store these; re-screen when a version changes

Réduire le bruit grâce à la portée

Envoyez les mêmes topics, include_dataset et exclude_dataset à chaque exécution, afin qu’une modification d’un registre que vous n’utilisez pas n’atteigne jamais l’examen. Pour lister les fiches recueillies récemment pour la première fois dans une collection, utilisez /api/search/<collection>?sort=first_seen avec un filtre.

Revérifier seulement ce qui a changé

Entre deux vérifications complètes, ajoutez changed_since à la requête de correspondance. Les candidats sont alors limités aux fiches recueillies pour la première fois à cette date ou heure, ou après, ou dont le contenu publié a changé dans une compilation en bloc depuis lors. Une partie qui ne correspond à rien de nouveau revient sans résultat; chaque résultat est donc une fiche nouvelle ou modifiée à comparer à vos décisions. Utilisez l’heure de votre exécution précédente, avec la même collection, les mêmes filtres et le même seuil.

curl -X POST "https://api.crownintelligence.net/api/match/sanctions?changed_since=2026-09-20" \
  -H "Content-Type: application/json" \
  -d '{"queries":{"c-1042":{"schema":"Person","properties":{"name":["Vladimir Putin"],"birthDate":["1952-10-07"]}}}}'

Format. Une date ou une heure ISO 8601, par exemple 2026-10-01 ou 2026-10-01T12:00:00Z. Une date seule correspond à minuit UTC. Toute autre valeur renvoie une erreur HTTP 400 accompagnée d’une explication. La valeur appliquée est reprise dans filters.changed_since.
Aussi dans la recherche. /api/search?changed_since= liste les fiches nouvelles et modifiées avec les filtres habituels.
Les retraits ne sont pas signalés. Une fiche retirée de son registre cesse simplement de correspondre. Pour connaître les retraits, lisez les lignes DEL des fichiers delta ou effectuez une vérification complète.
Conservez des vérifications complètes. Les changements sont comptés à partir des compilations en bloc, et jusqu’à 20 000 fiches modifiées sont prises en compte par requête (les fiches recueillies pour la première fois depuis la date sont toujours incluses). Après un long intervalle, ou une compilation ayant modifié plus de fiches que cette limite, effectuez une vérification complète.

Surveillance avec les fichiers delta

Flux de traitement

L’index de compilation de chaque collection, /downloads/collections/<collection>/index.json, énumère les fichiers de la compilation courante avec leurs sommes de contrôle. À partir de la deuxième compilation, delta.json énumère ce qui a changé depuis la compilation précédente, à raison d’une opération par ligne : ADD (nouvelle fiche), MOD (fiche modifiée) et DEL (fiche retirée). Appliquez-les dans l’ordre à votre copie, puis revérifiez les parties susceptibles de correspondre aux fiches ajoutées et modifiées. Voir Fichiers delta.

Réduire le bruit grâce à la comparaison

Pour chaque MOD, comparez l’ancienne et la nouvelle version des valeurs dont dépendent vos décisions, et ignorez le reste.

Effectuer périodiquement une vérification complète

Les deltas suivent nos données, et non votre portefeuille : une modification des renseignements de votre client, ou une compilation manquée, ne s’y trouve pas. Revérifiez l’ensemble de vos parties périodiquement, ainsi qu’à chaque modification des seuils ou des filtres.

Aide

Des questions sur la mise en place d’un flux de surveillance? Écrivez à [email protected] ou consultez Obtenir du soutien.

Dernière mise à jour : 2026-10-03