Comment comparer une liste de sanctions

Tout programme de filtrage de sanctions finit par poser la même question : « est-ce que quelque chose a changé depuis la dernière fois que nous avons récupéré cette liste ? » La réponse naïve — comparer le fichier d'aujourd'hui à celui d'hier, ligne par ligne — échoue en pratique, pour des raisons qui n'ont rien à voir avec l'effort fourni et tout à voir avec la façon dont les autorités émettrices publient et révisent réellement leurs listes. Comparer correctement une liste de sanctions est une discipline spécifique et qui s'apprend, et se tromper produit deux modes d'échec opposés : des désignations nouvelles manquées, et des signalements de vrais positifs obsolètes sur des personnes ou entités retirées des mois auparavant.

Pourquoi une comparaison de texte naïve échoue

Les listes de sanctions ne sont pas des journaux en ajout seul. Entre deux instantanés quelconques, les enregistrements peuvent :

• Être ajoutés — une nouvelle désignation.
• Être retirés — un retrait de liste, une licence, ou un renversement judiciaire.
• Être modifiés sur place — une date de naissance corrigée, un alias nouvellement divulgué, une reclassification de programme — sans que la personne ou l'entité sous-jacente ne change en rien.
• Être renumérotés ou réidentifiés — la même entité du monde réel reçoit un nouvel identifiant d'enregistrement parce que l'autorité émettrice a migré ses systèmes, restructuré sa liste, ou fusionné deux anciennes listes en une seule.

Une comparaison de texte ligne par ligne confond ces quatre cas. Elle signale une modification comme une suppression suivie d'un ajout, manque entièrement un renumérotage (ou pire, le signale comme un retrait et un ajout récent pour une entité qui n'a en réalité jamais été retirée de la liste), et ne donne aucune indication sur les changements urgents.

Le problème de l'identifiant est le vrai problème

La partie la plus difficile de la comparaison n'est pas de détecter qu'un changement s'est produit — c'est de prouver que l'enregistrement A de l'instantané d'hier et l'enregistrement B de l'instantané d'aujourd'hui sont (ou ne sont pas) la même entité du monde réel. La plupart des autorités émettrices attribuent un identifiant persistant à chaque enregistrement, précisément pour que les utilisateurs en aval puissent le suivre à travers les révisions, mais cet identifiant n'est pas garanti de survivre à une migration de plateforme.

Le Royaume-Uni en est un exemple actuel. Les désignations de sanctions financières sont passées de l'ancienne Consolidated List de l'OFSI à l'UK Sanctions List publiée par le FCDO le 28 janvier 2026, et les personnes nouvellement désignées se voient désormais attribuer un « Unique ID » plutôt que l'ancien « OFSI Group ID » (directive GOV.UK). Un pipeline de filtrage qui aurait indexé son historique de correspondances sur l'OFSI Group ID, et qui n'aurait pas tenu compte du changement de schéma d'identifiant, risque de traiter chaque désignation britannique préexistante comme une entité nouvelle le jour où il réintègre la liste successeure — un faux signal exactement au moment où le régime sous-jacent n'a en réalité pas changé. L'erreur inverse est tout aussi réelle : faire correspondre silencieusement les anciens identifiants aux nouveaux sans vérifier la continuité du référent peut tout aussi facilement fusionner deux entités réellement distinctes.

Que comparer — quatre catégories, pas une seule

Traitez chaque actualisation de liste comme produisant quatre sorties distinctes, pas un seul panier « modifié » :

1. Vrais ajouts. Un enregistrement sans correspondance plausible dans l'instantané précédent. C'est le cas pour lequel tout le monde construit — c'est aussi le plus facile à traiter correctement, car il n'y a rien à réconcilier.
2. Retraits (radiations). Un enregistrement présent dans l'instantané précédent, absent de l'instantané actuel, sans enregistrement successeur. C'est la catégorie que les programmes de filtrage sous-construisent le plus souvent. Notre propre digest des mesures d'application de juin a couvert un exemple concret : l'OFAC a retiré un ensemble de désignations SDN liées à la Russie le 24 juin 2026, le même mois où il en a ajouté de nouvelles. Un pipeline qui n'intègre que les ajouts et ne traite jamais les radiations accumule des signalements de vrais positifs obsolètes — des clients ayant clarifié leur exposition aux sanctions des mois auparavant continuent de déclencher des alertes, ce qui érode la confiance dans l'ensemble du programme de filtrage et enterre les alertes qui sont encore réellement actives.
3. Modifications sur place. Même identifiant, même entité, champs modifiés — un alias corrigé, un identifiant ajouté, un changement d'étiquette de programme. Celles-ci nécessitent une comparaison au niveau du champ, pas au niveau de l'enregistrement, car l'importance varie : une correction d'alias est informative, mais une reclassification de programme (disons, d'une liste sectorielle à une désignation de blocage complète) peut changer ce qui est légalement exigé d'une contrepartie détenant ce nom dans son portefeuille.
4. Réattribution d'identifiant. Le cas britannique ci-dessus — l'entité est continue, mais son identifiant persistant a changé en raison d'un changement de plateforme ou de structure de liste en amont. Cette catégorie est invisible à la fois pour une comparaison naïve et pour une comparaison de correspondance d'identifiant pure ; elle nécessite de vérifier la continuité via des signaux secondaires (nom, autres identifiants, date de désignation) lorsque l'identifiant principal change.

Un schéma qui fonctionne

L'approche fiable traite chaque liste comme un corpus versionné, pas comme un fichier à écraser :

• Conservez chaque instantané historique, chacun horodaté avec sa date de référence et (lorsque l'autorité en publie un) son propre identifiant de version.
• Comparez au niveau du champ au sein d'un identifiant apparié, pas seulement au niveau de l'enregistrement, afin qu'une modification soit lisible comme « ce qui a changé » plutôt que comme une suppression-et-recréation.
• Lorsqu'un identifiant disparaît, vérifiez activement l'existence d'un successeur avant de l'enregistrer comme un retrait — une correspondance de nom et d'attributs par rapport au nouvel instantané, pas seulement une vérification d'absence.
• Enregistrez les retraits comme des événements de radiation à part entière avec un horodatage, pas comme des suppressions silencieuses — le retrait lui-même fait partie de la piste d'audit dont une équipe de conformité a besoin pour expliquer pourquoi un nom qui était auparavant une correspondance ne l'est plus.

Ce dernier point est le fil conducteur qui rattache tout ceci à ce qui compte réellement : une correspondance de filtrage n'est défendable qu'à la hauteur de sa traçabilité — quelle autorité, quelle liste, quelle version, à quelle date. La même discipline s'applique à l'inverse pour une non-correspondance qui était autrefois une correspondance. Si vous ne pouvez pas montrer quand et pourquoi un nom a cessé de correspondre, « nous ne filtrons plus contre cela » n'est pas une réponse qu'un régulateur acceptera sur la foi de votre parole.

Le voir en pratique

Notre chronologie des désignations récentes montre les ajouts au fur et à mesure qu'ils surviennent, par source, avec les dates. Plusieurs sources disposent également de leur propre vue de chronologie par source pour isoler l'activité d'une liste en particulier. Le catalogue de sources documente l'autorité émettrice, le format et la cadence de mise à jour de chaque liste — les faits de départ dont vous avez besoin avant de construire un pipeline de comparaison contre celle-ci. Et parcourir directement une source montre l'état actuel par rapport auquel vous comparez, un enregistrement à la fois.