Cabinets d'avocats · Les vérifications de conflits et AML comme data pipelines, pas seulement comme étapes de conformité

La scène : 9h47, ouverture d'un nouveau dossier

Un associé envoie un e-mail à l'équipe intake : nouveau client, une entreprise industrielle mid-market cherche à se faire représenter sur une acquisition. Avant que quiconque n'ouvre un dossier, deux systèmes doivent tourner : une vérification de conflits (cet engagement met-il le cabinet en opposition à un client existant, ou crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée-t-il un conflit commercial) et un screening AML (anti-money laundering, le régime réglementaire qui impose aux cabinets de vérifier avec qui ils traitent réellement).

Ces deux contrôles ressemblent à des cases de conformité à cocher. En dessous, ce sont des data pipelines : une requête sur une base de données, mise en correspondance avec des données de référence, rafraîchie à une certaine cadence, renvoyant des résultats qu'un humain doit ensuite interpréter. Si le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → est périmé, mal apparié ou mal cadré, le contrôle passe alors qu'il ne devrait pas. C'est ainsi que des cabinets se retrouvent disqualifiés d'un dossier, ou pire, à représenter une entité sous sanctions.

Cette leçon traite les conflits et l'AML d'abord comme des problèmes de data engineering, et ensuite seulement comme des process juridiques.

Ce qu'interroge réellement une vérification de conflits

Une base de conflits n'est pas une application distincte greffée sur le cabinet. C'est une vue construite à partir du practice management system (PMS), le logiciel de référence pour les dossiers, les clients et les parties facturées (exemples : Intapp, Elite 3E, Aderant).

Chaque recherche sur un nouveau dossier s'exécute contre :

• Les noms du client et des parties liées : le nouveau client, sa société mère, ses filiales, ses dirigeants, et les contreparties de l'opération.
• L'historique des dossiers : tous les dossiers jamais ouverts par le cabinet, y compris ceux où le cabinet est intervenu en position adverse.
• Les conflits liés aux timekeepers : les avocats ayant travaillé sur des dossiers connexes, y compris dans des cabinets précédents (les conflits liés aux lateral hires sont une source de risque majeure).

La logique de recherche compte énormément. Un système de conflits qui fait du matching exact de chaînes de caractères passera à côté de « Smith Industrials Ltd » quand la nouvelle partie est enregistrée comme « Smith Industrials Limited » ou « Smith Industrials (UK) ». Les cabinets utilisent le fuzzy matching (des algorithmes qui attrapent les quasi-correspondances, fautes d'orthographe et variantes de noms) et l'entity resolution (relier des enregistrements qui désignent la même société réelle malgré des noms différents dans des systèmes différents).

Exemple : si la société mère ultime de la cible d'acquisition est une société que le cabinet a représentée il y a trois ans sous une autre raison sociale, une recherche naïve la manque complètement. Un pipeline bien construit résout les deux noms vers le même identifiant d'entité avant de lancer la recherche.

Le screening AML : un autre pipeline, des flux externes

Les contrôles AML puisent dans une source de données différente : des flux tiers de watchlists et de sanctions, pas l'historique propre du cabinet. Les listes pertinentes incluent :

• La liste des Specially Designated Nationals de l'OFAC (l'Office of Foreign Assets Control du Trésor américain, la liste de sanctions des personnes et entités exclues des transactions américaines).
• La liste consolidée de sanctions de l'UE et la liste OFSI du Royaume-Uni (Office of Financial Sanctions Implementation).
• Les bases PEP (Politically Exposed Persons, les personnes occupant des fonctions publiques importantes, screenées pour le risque de corruption).

Les cabinets interrogent rarement ces listes directement. Ils s'abonnent à un fournisseur (exemples : LexisNexis, Refinitiv World-Check, Dow Jones Risk & Compliance) qui agrège, nettoie et met à jour ces flux, puis se branche sur le workflow d'intake du cabinet via APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →.

La fraîcheur des données est ici tout l'enjeu. Les listes de sanctions changent en permanence, l'OFAC met à jour sa liste SDN plusieurs fois par mois, parfois du jour au lendemain en réaction à des événements géopolitiques. Si le flux du fournisseur se synchronise chaque semaine, il existe une fenêtre pendant laquelle une partie nouvellement sanctionnée passe le screening. La liste officielle de l'OFAC est gratuite et publique : sanctionssearch.ofac.treas.gov.

Le Client Due Diligence (CDD), le processus plus large de vérification de la propriété effective, est l'endroit où le pipeline se complique. La propriété effective (qui contrôle réellement une entité ou en tire profit, pas seulement le nom figurant sur le papier) impose souvent de remonter des structures écrans. Aux États-Unis, le Corporate Transparency Act (adopté en 2021, obligations déclaratives échelonnées sur 2024-2025) a créé un registre des bénéficiaires effectifs via le FinCEN (Financial Crimes Enforcement Network) visant précisément ce problème, même si son périmètre et son application ont fait l'objet d'évolutions juridiques et réglementaires continues : les cabinets ne doivent donc pas le considérer comme un substitut à leur propre diligence.

Où les hits sont détectés, et où ils passent à travers

Un hit est détecté quand :

• L'entity resolution relie correctement la nouvelle partie à une variante de nom déjà présente dans le PMS.
• Le flux du fournisseur AML est synchronisé quotidiennement ou en quasi temps réel et couvre les bonnes juridictions.
• Le périmètre de recherche inclut les parties liées (dirigeants, bénéficiaires effectifs ultimes, chaînes mère/filiales), pas seulement le client nommé.

Un hit est manqué quand :

• La logique de recherche repose uniquement sur le matching exact, et un nom présente une différence de translittération (fréquent avec des entités issues de juridictions à écriture non latine).
• Le flux AML est en retard sur la mise à jour de la liste de sanctions, fréquent avec des fournisseurs de second rang ou des synchronisations peu fréquentes.
• Le contrôle ne porte que sur le client nommé et saute les bénéficiaires effectifs situés deux ou trois niveaux plus haut dans la chaîne de détention.
• Les données de dossiers dans le PMS lui-même sont sales : doublons de fiches clients, conventions de nommage incohérentes, dossiers enregistrés sous l'abréviation d'un avocat plutôt que sous la dénomination sociale.

Ce dernier point relève de la data governancedata governanceLa data governance est l'ensemble des politiques, rôles et processus qui garantissent que les données sont exactes, sécurisées, bien définies et utilisées de façon responsable dans toute l'organisation.Voir la définition complète →, pas du droit. Des données pourries dans le PMS produisent des résultats de conflits pourris, quelle que soit la qualité de l'algorithme de recherche.

Une vue simplifiée du pipeline

New matter intake form
        │
        ▼
Entity extraction (client, parent, subs, counterparties, directors)
        │
        ├──> Conflicts query: fuzzy match against PMS matter/client history
        │         │
        │         └──> Human review of "possible matches" queue
        │
        └──> AML query: match against vendor-aggregated sanctions/PEP feeds
                  │
                  └──> Risk score + human review for any hit

Deux pipelines distincts, même déclencheur à l'intake, sources de données différentes, cadences de rafraîchissement différentes. Les deux ont besoin d'une étape de revue humaine parce que les faux positifs sont fréquents (un nom courant, une correspondance fortuite) et que les faux négatifs sont le vrai danger.

Pourquoi cela compte pour l'architecture data du cabinet

Les données de conflits et d'AML ne peuvent pas simplement alimenter un entrepôt analytique généraliste aux côtés des données de facturation et de temps. Deux contraintes structurelles :

Privilège et confidentialité. Un résultat de recherche de conflits révélant que « le cabinet a déjà représenté la société X » peut lui-même être sensible, en particulier sur des deals non annoncés. L'accès aux données de conflits est généralement restreint à l'équipe conflicts/OGC (Office of General Counsel) et aux associés en charge du dossier, pas ouvert à quiconque dispose d'un accès business intelligencebusiness intelligenceTechnologies et processus qui transforment des données brutes en insights actionnables via du reporting, des dashboards et de l'analyse, pour que les équipes décident sur des faits plutôt qu'à l'intuition.Voir la définition complète →.

Contrôle d'accès au niveau du dossier. La plupart des systèmes de données des cabinets, y compris le PMS et les systèmes de gestion documentaire (DMS, par ex. iManage, NetDocuments), appliquent des ethical walls (barrières informationnelles entre avocats travaillant sur des dossiers adverses). Une couche warehouse ou lakehouselakehouseUne architecture hybride qui combine la flexibilité d'un data lake et les capacités analytiques d'un data warehouse, sur une seule couche de stockage.Voir la définition complète → construite au-dessus de ces systèmes à des fins de reporting doit préserver ces mêmes frontières d'accès, pas les aplatir. Cela implique une sécurité au niveau des lignes liée aux identifiants de dossier et de client, répliquée fidèlement depuis le système source, et non réinventée dans le warehouse.

Les cabinets qui construisent des plateformes data modernes (un pattern lakehouse combinant stockage de données brutes et couches de requêtage structuré, avec des outils comme Databricks ou Snowflake) souhaitent de plus en plus disposer des métadonnées de conflits et d'AML pour le reporting de risque à l'échelle du cabinet, sans exposer le détail sensible sous-jacent. L'approche courante : agréger au niveau « vérification de conflits réalisée, niveau de risque attribué » plutôt que de répliquer le détail complet des correspondances de noms dans une couche de reporting généraliste.

🎬 [VIDEO: "What is Know Your Customer (KYC) and AML?" — youtube.com/results?search_query=what+is+kyc+aml+explained — une courte explication des concepts de screening qui sous-tendent les outils d'intake des cabinets, utile pour un public non technique]

À retenir

• Les vérifications de conflits interrogent l'historique du practice management du cabinet ; les contrôles AML interrogent des flux externes de sanctions et de PEP agrégés par des fournisseurs. Ce sont deux pipelines distincts avec des profils de risque distincts.
• La logique de recherche (fuzzy matching, entity resolution) détermine si les variantes de noms et les parties liées sont détectées. La recherche en matching exact seul est un angle mort connu.
• La fraîcheur des données est critique pour l'AML : les listes de sanctions comme la liste SDN de l'OFAC sont mises à jour fréquemment, et un flux fournisseur synchronisé chaque semaine crée une réelle fenêtre d'exposition.
• Des données sales dans le practice management system (fiches clients en doublon ou incohérentes) sapent les vérifications de conflits quelle que soit la qualité de l'algorithme de recherche.
• Toute couche warehouse ou lakehouse construite au-dessus de ces systèmes doit préserver le contrôle d'accès au niveau du dossier et les ethical walls, généralement en reportant un statut de risque agrégé plutôt qu'en répliquant le détail sensible des correspondances.