Le conflicts check est un problème de données, pas un formulaire

Dix-huit mois après le début d'une acquisition transfrontalière, un cabinet d'avocats de taille intermédiaire découvre qu'il représente l'acquéreur alors qu'un autre bureau, dans un autre pays, avait conseillé le fondateur de la cible sur une question de succession personnelle trois ans plus tôt. Personne n'a menti. Personne n'a bâclé son travail. Le nom du fondateur était orthographié différemment dans les deux dossiers : l'un utilisait un nom de naissance, l'autre un nom d'épouse avec trait d'union. Le conflicts check du cabinet, exécuté à l'ouverture du dossier, n'a rien trouvé. La mission est aujourd'hui exposée à un risque de récusation, et la relation client est abîmée quelle qu'en soit l'issue.

Ce n'est pas un cas limite rare. C'est le résultat prévisible d'un conflicts check traité comme un exercice de remplissage de formulaire au lieu de ce qu'il est réellement : un problème de résolution d'entités et de matching de données.

Pourquoi les formulaires d'intake échouent

Un conflicts check (« conflict of interest check ») pose une question simple : accepter ce nouveau client ou ce nouveau dossier 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 de devoirs avec quelqu'un que le cabinet représente déjà, a représenté, ou à qui il est opposé ? Des organismes professionnels comme l'American Bar Association (Model Rule 1.7 et 1.9) et, au Royaume-Uni, la Solicitors Regulation Authority (SRA) exigent des cabinets qu'ils identifient activement ces conflits, et pas seulement qu'ils réagissent lorsqu'ils apparaissent.

Le workflow standard : un avocat en charge de l'intake remplit un formulaire avec le nom du client, les contreparties et une description du dossier. Le tout est passé dans une base clients. Le problème est structurel, pas procédural :

• Variantes de noms. Les entités juridiques ont des filiales, des noms commerciaux et des noms antérieurs après fusion. Les personnes ont des noms de naissance, des translittérations (un nom chinois ou arabe romanisé de trois façons différentes) et des surnoms utilisés dans la correspondance informelle.
• Descriptions de dossiers en texte libre. « Conseil en financement » et « conseil en restructuration de dette » peuvent décrire la même relation sous-jacente sans jamais correspondre au niveau des chaînes de caractères.
• Systèmes en silos. Beaucoup de cabinets, en particulier les cabinets d'audit et d'avocats issus de fusions, exploitent des systèmes de practice management distincts par bureau ou par entité acquise : une correspondance à Londres ne touche jamais un enregistrement à Singapour.
• Jugement humain sous pression de temps. Dans un grand cabinet, les avocats en charge de l'intake parcourent des centaines de correspondances et sont incités à aller vite, pas à creuser des correspondances partielles ambiguës.

Aucun de ces points n'est un défaut de « discipline de process ». Ce sont des défauts de qualité et d'architecture des données : mauvaise résolution d'identité, texte non structuré, systèmes fragmentés.

Le modèle de données sous un vrai système de conflicts

Les cabinets qui détectent les conflits de façon fiable construisent trois structures de données liées, pas une seule liste de clients.

1. Données d'entités. Chaque partie (personne ou organisation) reçoit un enregistrement canonique avec un identifiant unique, indépendant de tout dossier particulier. Les entités corporate sont rattachées à leurs structures mères et filiales, souvent à partir de registres commerciaux ou de fournisseurs comme OpenCorporates, la plus grande base ouverte de données d'enregistrement d'entreprises. Les personnes physiques sont rattachées à leurs alias connus et à leur historique de rôles (dirigeant, bénéficiaire effectif, témoin).

2. Données de relation. Pas seulement « client » mais la nature de la relation : partie adverse, avocat adverse, témoin, bénéficiaire effectif, garant. Un conflit peut naître du fait d'avoir conseillé la contrepartie de quelqu'un, et pas seulement la partie elle-même.

3. Données de dossier. Des métadonnées structurées par mission : domaine de pratique, juridiction, parties adverses, entités liées, et un vocabulaire contrôlé pour le type de dossier (pas de texte libre). C'est ce qui rend le croisement possible à l'échelle.

Le conflicts check devient alors une requête sur un graphe, non une recherche par mots-clés : un nœud de la liste d'entités du nouveau dossier se connecte-t-il, directement ou via une filiale ou un alias antérieur, à un nœud déjà présent dans le graphe de relations du cabinet ?

Une logique de matching simplifiée

new_matter.parties = [entity_resolve(name) for name in intake_form.names]

for party in new_matter.parties:
    related = get_linked_entities(party, depth=2)  # filiales, alias, rôles connus
    for entity in related:
        if entity in firm_relationship_graph:
            flag_for_review(entity, relationship_type, matter_id)

L'étape critique est entity_resolve : rapprocher « J. Smith-Warner » de « Jane Smith » exige du fuzzy matching (distance d'édition, algorithmes phonétiques comme Soundex) plus des données externes (registres d'entreprises, listes de sanctions, registres de bénéficiaires effectifs) plutôt qu'une comparaison exacte de chaînes. Les cabinets acquièrent de plus en plus des licences d'outils de résolution d'identité conçus pour cela, proches de l'infrastructure « know your customer » (KYC) utilisée par les banques, adaptée au screening des conflits pour les activités juridiques et de conseil.

Contraintes de gouvernance et de confidentialité qui façonnent la conception

C'est là que les données de conflicts entrent en collision avec la réglementation sur la vie privée, et les cabinets de services professionnels occupent une position inhabituelle : ils doivent conserver et croiser des données personnelles et commerciales sensibles précisément pour respecter des règles déontologiques, tout en respectant le droit de la protection des données.

• Le RGPD (Règlement général sur la protection des données, UE/Royaume-Uni) exige une base légale pour le traitement des données personnelles. Le conflicts checking se justifie généralement par l'« obligation légale » ou l'« intérêt légitime », mais les cabinets doivent quand même le documenter, limiter la conservation et traiter avec soin les droits des personnes concernées, car une demande d'effacement complet pourrait elle-même détruire l'historique de conflits nécessaire à la conformité déontologique future. L'Information Commissioner's Office (ICO) britannique a publié des orientations sur cette tension pour les professions réglementées (ico.org.uk).
• Règles de transfert transfrontalier de données. Un cabinet mondial exploitant une base de conflicts centralisée doit s'assurer que les données personnelles des clients et des contreparties circulent licitement entre juridictions, question sensible depuis Schrems II pour les transferts UE-États-Unis.
• Confidentialité vs capacité de recherche. Les murailles de Chine (« information barriers ») requises lorsqu'un cabinet représente des intérêts adverses dans des dossiers non liés impliquent que le système de conflicts enregistre assez d'informations pour signaler une correspondance, sans exposer les détails confidentiels du dossier à l'avocat qui lance la vérification. On règle généralement cela en affichant un hit et un nom de contact pour le suivi, pas le dossier sous-jacent.

Les cabinets qui se trompent ici soit collectent trop (risque de confidentialité), soit relient trop peu (risque de conflit manqué). La tension de conception est réelle et sans raccourci.

Vérifications et audits à mener en pratique

Un système de conflicts n'est jamais « terminé ». Il exige des audits récurrents, comme une banque audite son screening anti-blanchiment (AML).

1. Revue du taux de correspondance. Échantillonnez des dossiers récemment clôturés et revérifiez-les manuellement contre la base actuelle. Les conflits connus (cas de test délibérément implantés) remontent-ils effectivement ? Les cabinets devraient passer des noms de test « red team », incluant des variantes orthographiques intentionnelles, chaque trimestre.
2. Audit de couverture de la résolution d'entités. Quel pourcentage des enregistrements clients dispose d'une société mère résolue, vérifiée contre un registre ? Les trous ici sont des trous de couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète →, pas des cas limites.
3. Contrôle de latence. Combien de temps entre l'ouverture d'un nouveau dossier et l'achèvement du conflicts check ? Une vérification qui prend trois semaines rate sa cible au stade de l'intake.
4. Cartographie des silos. Après chaque fusion ou recrutement latéral (un associé qui change de cabinet en emportant son portefeuille clients), confirmez que la liste clients acquise a été intégrée et résolue au niveau des entités dans le système central, et non laissée dans un tableur legacy.
5. Taux de faux positifs. Trop de correspondances de faible qualité provoquent une « alert fatigue » : les relecteurs se mettent à valider les signalements mécaniquement. Suivez le nombre de correspondances signalées qui sont levées sans escalade, et ajustez les seuils de matching en conséquence.

🎬 [VIDEO: « How Law Firms Use Data to Prevent Conflicts of Interest » - youtube.com - cherchez des chaînes récentes sur la technologie et les legal ops en cabinet traitant des systèmes de conflicts check et de la résolution d'entités en pratique]

Points clés

• Un conflit manqué est généralement un échec de matching de données (variantes de noms, systèmes en silos, texte libre), pas un défaut de jugement des équipes d'intake.
• Un conflicts checking fiable exige trois structures de données liées : des enregistrements d'entités canoniques, des types de relations et des métadonnées de dossier structurées, interrogées comme un graphe plutôt que par mots-clés.
• La résolution d'entités (fuzzy matching, rattachement aux registres d'entreprises, suivi des alias) est l'investissement technique au plus fort effet de levier qu'un cabinet puisse faire dans ce domaine.
• Le droit de la vie privée (RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → et règles équivalentes de confidentialité professionnelle) crée une tension réelle avec le conflicts checking : les cabinets doivent conserver et relier des données sensibles pour respecter leurs obligations déontologiques tout en limitant l'exposition et en respectant les droits des personnes.
• Traitez les systèmes de conflicts comme n'importe quel autre système de conformité : auditez les taux de correspondance, la couverture, la latence et les faux positifs de façon récurrente, en particulier après des fusions ou des recrutements latéraux.