Données matters, clients et conflits à l'intérieur de la privilege boundary

Un associé veut accepter un nouveau client : un industriel de taille moyenne qui poursuit un fournisseur. Avant que quiconque signe une lettre de mission, le cabinet doit répondre à une question faussement simple : avons-nous, à un moment quelconque, dans un bureau quelconque, représenté ce fournisseur, sa maison mère, une filiale, un administrateur, ou une partie adverse qui pourrait être aidée ou lésée par ce nouveau dossier ?

Cette seule question, le conflicts check, oblige un cabinet d'avocats à modéliser ses données d'une façon qu'aucun distributeur, banque ou éditeur SaaS n'a jamais eu à adopter. Cette leçon explique pourquoi.

Ce qu'est réellement un « matter »

Dans les cabinets d'avocats, le travail s'organise autour du matter : une unité de travail juridique distincte pour un client. Un même client peut avoir des centaines de matters (un contentieux, une fusion, un dépôt de brevet, une revue contractuelle de routine).

Les entités centrales sont faciles à nommer :

• Client : la partie que le cabinet représente.
• Matter : la mission précise.
• Party : toutes les personnes liées à un matter (parties adverses, co-défendeurs, témoins, sociétés liées, dirigeants personnes physiques).

La complexité tient à la dernière. Un conflicts check ne compare pas client à client. Il compare chaque party du nouveau matter à chaque party que le cabinet a jamais touchée.

Pourquoi le conflicts check fait voler en éclats le modèle de données habituel

La plupart des entreprises se demandent « qui sont mes clients ? ». Un cabinet d'avocats doit se demander « qui sont toutes les personnes auxquelles nous avons jamais été opposés, pour le compte de qui que ce soit ? »

Les règles déontologiques l'exigent. Aux États-Unis, les ABA Model Rules of Professional Conduct (règles 1.7 et 1.9) interdisent de représenter un client dont les intérêts sont adverses à ceux d'un client actuel ou ancien sans consentement éclairé. Des obligations similaires existent sous la SRA en Angleterre et au pays de Galles, et chez la plupart des autres régulateurs du barreau.

Cela signifie que la base de données conflits est de fait permanente et exhaustive. Vous ne pouvez pas supprimer un ancien client. Vous ne pouvez pas ignorer la partie adverse d'un dossier perdu il y a dix ans. Chaque nom est un conflit futur potentiel.

Le cabinet entretient donc un graphe croissant de parties et de relations, et l'interroge à chaque nouvelle mission. C'est l'inverse de l'instinct « ne garder que le nécessaire » qui gouverne l'hygiène des données moderne.

Entity resolution : le vrai problème technique

Le plus difficile, c'est que les noms sont sales. « Acme Corp », « Acme Corporation », « ACME Corp. (Delaware) » et « Acme Holdings » désignent peut-être, ou pas, la même entité. Un conflit peut se cacher dans n'importe lequel.

L'entity resolution (aussi appelée record linkage ou déduplication) consiste à décider quand deux enregistrements renvoient à la même chose dans le monde réel. Dans un système de conflits, ce n'est pas un sujet académique. Rater une correspondance et le cabinet peut accepter un conflit disqualifiant. Sur-matcher et chaque vérification se noie dans des faux positifs que les associés ignorent, ce qui est précisément par là que passent les vrais conflits.

Une passe de matching simplifiée ressemble à ceci :

# À titre d'illustration uniquement : matching flou de noms pour un pré-screening de conflits
from rapidfuzz import fuzz

def is_possible_match(name_a, name_b, threshold=88):
    score = fuzz.token_sort_ratio(
        name_a.lower().strip(),
        name_b.lower().strip()
    )
    return score >= threshold

is_possible_match("Acme Corporation", "ACME Corp.")  # -> True (à signaler pour revue humaine)

Le résultat n'est jamais une décision. C'est une liste signalée qu'un analyste conflits revoit à la main. Dans les cabinets d'avocats, l'humain dans la boucle n'est pas optionnel : c'est le contrôle.

Une bonne entity resolution a aussi besoin d'organigrammes de groupes. Si votre client est adverse à une petite filiale, vous êtes peut-être adverse à tout le groupe. Les cabinets achètent souvent des données de hiérarchie capitalistique sous licence, ou les maintiennent manuellement, car « qui détient qui » change en permanence au gré des acquisitions.

Ethical walls : segmenter les données volontairement

Parfois un conflit existe mais le cabinet peut quand même prendre le dossier en isolant l'information. C'est un ethical wall (aussi appelé screen ou barrière à l'information) : un ensemble de contrôles empêchant les avocats d'un matter d'accéder aux données confidentielles d'un autre.

Exemple : le cabinet représente la société A dans un contentieux. Un avocat qui a travaillé dans un autre cabinet et brièvement conseillé la partie adverse le rejoint. Pour conserver la mission, le cabinet met cet avocat sous screen : aucun accès aux fichiers, aucune saisie de temps, aucune conversation de couloir sur le dossier.

En termes de données, un ethical wall est un contrôle d'accès au niveau de la ligne et du document, rattaché à des utilisateurs individuels, pas à des rôles ou à des départements. La plupart des logiciels d'entreprise supposent que l'accès suit la fonction. Un logiciel juridique doit gérer « ces trois personnes nommément désignées ne peuvent pas voir ce matter précis, pour toujours, même si leur intitulé de poste le leur permettrait ».

🎬 [VIDEO: "What Is a Conflict of Interest for Lawyers?" — youtube.com — une explication courte et en langage clair des conflits juridiques et du screening]

Privilege et confidentialité : pourquoi l'analytics dans le cloud se complique

C'est ici que la lecture « données » devient tranchante.

L'attorney-client privilege protège les communications confidentielles entre un avocat et son client contre toute divulgation, y compris devant un tribunal. La confidentialité (le devoir déontologique) est plus large et couvre en substance tout ce que le cabinet apprend sur un client. Les deux 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 →éent une privilege boundary : une ligne autour des données client que le cabinet ne doit pas laisser fuiter.

Cette frontière exclut des pratiques que d'autres secteurs considèrent comme routinières.

Mutualiser les données entre clients. Un distributeur mélange volontiers tous les comportements clients dans un entrepôt analytique unique. Un cabinet ne peut généralement pas mutualiser les données d'un matter avec celles d'un autre client à des fins d'analyse, car ce mélange peut en lui-même violer la confidentialité et, selon certaines lectures, faire perdre le privilege.

Traitement cloud par un tiers. Lorsque des données client transitent vers un service externe d'analytics ou d'IA, le cabinet doit s'assurer que le fournisseur ne peut ni les utiliser, ni les conserver, ni les exposer. Beaucoup de cabinets exigent des garanties contractuelles d'absence d'entraînement sur leurs données, d'isolation du tenant et de résidence des données précise. Certaines missions (clients publics, financiers, défense) interdisent purement et simplement le traitement cloud par exigence du client.

Outils d'IA générative. Un chatbot public qui journalise les prompts est un risque de confidentialité si un avocat y colle des faits relatifs à un client. Les barreaux ont publié des orientations ; voir l'ABA Formal Opinion 512 sur l'IA générative (2024) pour le raisonnement. En bref : l'avocat reste responsable de la confidentialité quel que soit l'outil utilisé.

Résultat pratique : les cabinets font souvent tourner leurs analytics et leur IA dans leur propre environnement contrôlé, pas sur des plateformes multi-tenant partagées, et ils appliquent aussi le modèle de l'ethical wall à leurs pipelines de données.

Comment les cabinets structurent réellement leurs données

Assemblez les pièces et un modèle exploitable apparaît.

Un graphe de conflits, pas une table clients. Les parties sont des nœuds. Les matters les relient. Les relations (maison mère, filiale, dirigeant, adverse, co-conseil) sont des arêtes. Un conflicts check est une requête de graphe : trouver tous les chemins entre les nouvelles parties et toute partie existante.

Métadonnées agressives, contenu prudent. Le cabinet peut suivre librement des métadonnées structurées (numéro de client, numéro de matter, noms des parties, dates, associé responsable) dans des systèmes interrogeables. Le contenu couvert par le privilege (le conseil lui-même, les documents, les échanges) reste derrière des contrôles d'accès plus stricts et segmenté par matter.

L'accès comme champ de premier ordre. Chaque document et chaque matter porte une liste d'accès. Les ethical walls sont appliqués dans le système, journalisés et auditables, car un régulateur ou un avocat adverse pourra exiger plus tard la preuve que le screen a tenu.

Une rétention qui lutte contre la suppression. Les données de conflits sont conservées indéfiniment. Mais le contenu des matters couverts par le privilege suit souvent des calendriers de rétention dictés par le risque de responsabilité professionnelle et les accords clients. Ces deux logiques (garder les noms pour toujours, éliminer la substance selon un calendrier) cohabitent dans le même cabinet.

Un contraste rapide illustre le propos :

Pourquoi cela compte pour quiconque travaille avec des données juridiques

Si vous construisez, achetez ou analysez des systèmes de données pour un cabinet, l'instinct « tout centraliser et faire de l'analytics par-dessus » est exactement le mauvais réflexe. La privilege boundary et les obligations en matière de conflits ne sont pas des préférences IT. Ce sont des devoirs déontologiques appliqués par les régulateurs du barreau, avec la disqualification, l'exposition en responsabilité professionnelle et l'atteinte à la réputation comme sanctions.

Les cabinets qui s'y prennent bien traitent les conflits comme un problème de graphe, l'entity resolution comme un processus supervisé par des humains, et les ethical walls comme un contrôle de données, pas comme une note de politique interne.

Points clés

• Le modèle de données d'un cabinet d'avocats s'articule autour des matters et des parties, et un conflicts check compare chaque partie d'un nouveau dossier à chaque partie que le cabinet a jamais touchée, ce qui rend la base permanente et exhaustive.
• L'entity resolution (rapprocher des noms sales et des organigrammes de groupes) est le défi technique central ; le matching automatisé ne fait que signaler des candidats, et c'est un analyste humain qui tranche.
• Les ethical walls exigent un contrôle d'accès au niveau d'individus nommément désignés par matter, pas l'accès par rôle que supposent la plupart des logiciels.
• La privilege boundary exclut la mutualisation de données entre clients et le traitement cloud ou IA publique sans restriction que d'autres secteurs tiennent pour acquis.
• La rétention tire dans deux directions : garder les noms des conflits pour toujours, mais éliminer le contenu couvert par le privilege selon un calendrier.