IA sur mesure pour cabinets d'avocats : acheter ou construire ? Le vrai enjeu est le mode de déploiement, la souveraineté des données et le poids du CLOUD Act.
Un cabinet d'avocats doit-il développer son IA sur mesure ?
Pas nécessairement. La vraie question n'est pas de choisir entre « acheter » une solution sur étagère et « construire » la sienne, mais de choisir le mode de déploiement. Kirkland & Ellis y consacre 500 millions de dollars, soit environ 1 % de ses 10,6 milliards de revenus, un effort hors de portée d'un cabinet de taille moyenne. Trois régimes coexistent : l'appel à l'API d'un éditeur, l'inférence managée souveraine en Europe ou en Suisse, et l'auto-hébergement complet. La variable stratégique n'est ni le drapeau du modèle ni la promesse marketing : c'est la maîtrise de la donnée et la propriété du code. Pour les usages les plus sensibles, l'inférence souveraine offre la résidence des données et la conformité sans exploiter un parc de serveurs. Un avertissement demeure : posséder l'outil n'efface pas la responsabilité de l'avocat, il l'internalise.
Le 28 mai 2026, le Financial Times a révélé que Kirkland & Ellis, premier cabinet mondial par le chiffre d'affaires, allait consacrer 500 millions de dollars à la construction de sa propre plateforme d'IA sur mesure. Un peu plus de 100 millions dès cette année selon son chairman Jon Ballis, le reste étalé sur trois à quatre ans, financé sur les revenus du cabinet. Quelques semaines plus tôt, un ancien collaborateur de Latham & Watkins mettait en ligne Mike, un outil open source qu'il affirme avoir codé en deux semaines et qui revendique une parité de fonctionnalités avec les plateformes du marché.
Deux gestes opposés, une même question adressée à chaque structure : faut-il continuer à acheter une solution sur étagère, ou reprendre la main sur sa propre technologie ? Je crois que, posée ainsi, la question est mal posée. Le choix n'est pas binaire. C'est un curseur, qui va de la dépendance totale à un éditeur jusqu'à la maîtrise complète de sa propre infrastructure, avec plusieurs positions intermédiaires. Et la variable qui compte vraiment pour un cabinet n'est ni le drapeau du modèle ni la promesse marketing de l'éditeur : c'est le mode de déploiement, ce qu'il garantit, et ce qu'il vous oblige à assumer.
Trois façons de faire tourner un modèle d'IA
Quand un cabinet utilise une IA générative, il le fait selon l'un de ces trois régimes. Les comprendre dissout un malentendu très répandu.
L'appel à l'API d'un éditeur
Vous envoyez vos requêtes vers les serveurs d'un fournisseur, qui exécute le modèle et vous renvoie la réponse. C'est le plus simple et le plus rapide à mettre en place. C'est aussi le régime où vos données quittent votre périmètre.
L'inférence managée souveraine
Un hébergeur télécharge les poids d'un modèle ouvert et le fait tourner sur sa propre infrastructure, dans une juridiction que vous choisissez. Scaleway, par exemple, sert des modèles comme Qwen ou des variantes de DeepSeek depuis ses centres de données parisiens, et indique que toute l'inférence reste en Europe, sans stockage ni journalisation des prompts. Infomaniak fait de même en Suisse, avec un catalogue qui inclut Mistral, Llama et DeepSeek, en garantissant un traitement exclusivement helvétique.
L'auto-hébergement complet
Vous téléchargez les poids et vous les exécutez sur vos propres serveurs. Aucune donnée ne sort, à condition de l'avoir configuré ainsi.
Le malentendu sur les « modèles chinois »
Au début de 2025, plusieurs autorités européennes de protection des données se sont émues de DeepSeek. Le Garante italien a ordonné une limitation du traitement des données des utilisateurs italiens, et la CNIL a annoncé examiner l'outil. Ces interventions visaient une cible précise : l'application et l'API publiques de DeepSeek, dont la politique de confidentialité prévoit un stockage des données en Chine et la possibilité de les communiquer aux autorités.
Or les poids d'un modèle ne sont pas un service. Ce sont des fichiers. Lorsqu'un hébergeur européen ou suisse fait tourner DeepSeek sur ses propres machines, vos données ne partent pas en Chine. C'est exactement l'argument de l'auto-hébergement, simplement opéré pour vous par un tiers de confiance. Le fait que des fournisseurs positionnés sur la souveraineté proposent ces modèles ne contredit donc pas la prudence ambiante : il la confirme. Ils ont retiré le vecteur qui posait problème. Reste que tous les hébergeurs ne se valent pas sur le terrain de la juridiction, et c'est ici que le juriste doit être attentif.
CLOUD Act et garanties contractuelles : le vrai terrain du juriste
Microsoft propose lui aussi DeepSeek dans son catalogue Azure, entièrement hébergé et géré sur son infrastructure, avec une couche de filtrage de contenu. Techniquement, vos données peuvent rester dans une région européenne. Juridiquement, la difficulté est ailleurs.
⚖️ Côté régulation
Le CLOUD Act américain permet aux autorités des États-Unis de contraindre un fournisseur de droit américain à produire des données qu'il détient, y compris lorsqu'elles sont stockées hors du territoire américain. La localisation de la donnée dans un centre européen ne neutralise donc pas, à elle seule, l'exposition liée à la nationalité du prestataire.
C'est la différence de fond entre un Scaleway, filiale du groupe français Iliad sans société mère hors d'Europe, et un hyperscaler américain. Pour un cabinet, dont la matière première est couverte par le secret professionnel, cette nuance n'est pas théorique. Elle conditionne la possibilité même de confier certains dossiers à un outil.
Les garanties contractuelles à exiger avant de signer
Les garanties contractuelles sont le vrai terrain de négociation quand on n'auto-héberge pas. Avant de signer, un cabinet devrait obtenir des engagements écrits sur :
- la localisation des données et le droit applicable ;
- l'absence d'entraînement du modèle à partir de ses contenus ;
- l'absence de conservation et de journalisation des requêtes ;
- la liste et la localisation des sous-traitants ;
- les droits d'audit et la réversibilité en fin de contrat.
Il devrait aussi clarifier la propriété de tout réglage fin réalisé sur ses propres données. Ces exigences rejoignent les principes de conformité et de gouvernance des systèmes d'IA.
La propriété de l'outil : la leçon Kirkland
Sur ce dernier point, le cas Kirkland est instructif. Les sociétés extérieures qui développent sa plateforme n'auront pas le droit de la revendre à d'autres cabinets, et le cabinet détient la technologie, ou le droit de la détenir. La démarche se distingue du partenariat entre Freshfields et Anthropic, qui autorise l'éditeur à commercialiser auprès de cabinets concurrents les produits issus de la collaboration. Posséder, ou ne pas posséder, l'exclusivité de l'outil que l'on a contribué à façonner : c'est une clause, pas un détail.
Poids ouverts n'est pas open source : lire la licence
Le mot « ouvert » recouvre des réalités très différentes, et un juriste y sera sensible. Un modèle à poids ouverts met à disposition les paramètres entraînés, téléchargeables et exécutables. Il ne publie pas nécessairement les données ni le code d'entraînement. « Poids ouverts » ne signifie donc pas « open source » au sens plein, et ne dit rien, à lui seul, des conditions d'usage.
Ces conditions tiennent dans la licence. Mistral publie ses modèles phares sous Apache 2.0, une licence permissive et juridiquement lisible, argument solide à présenter à une direction juridique soucieuse de sécurité contractuelle. Kimi K2, de l'éditeur chinois Moonshot, est diffusé sous une licence MIT modifiée : elle fonctionne comme une MIT standard, à une réserve près, l'obligation d'afficher la marque au-delà de cent millions d'utilisateurs actifs mensuels ou de vingt millions de dollars de revenus mensuels. Aucun cabinet n'atteint ces seuils, la contrainte ne vous concerne donc pas en pratique. L'enseignement général reste : on ne déploie pas un modèle ouvert sans avoir lu sa licence et vérifié qu'elle autorise l'usage commercial projeté.
Les vrais risques cyber d'une IA sur mesure
C'est le sujet le plus technique, et celui où il faut être précis plutôt qu'inquiet. Les risques de sécurité d'un modèle ouvert, même auto-hébergé, se rangent en deux familles qui n'ont ni la même probabilité ni les mêmes parades.
L'exécution de code au chargement du modèle
La première famille ne tient pas au comportement du modèle mais aux fichiers et bibliothèques qui le chargent. Le format historique de sérialisation, pickle, peut exécuter du code arbitraire à l'ouverture, avant même que vous récupériez un objet modèle. Une étude longitudinale de l'université Brown en 2025 estime qu'environ la moitié des dépôts populaires sur Hugging Face contiennent encore des modèles au format pickle. La parade est connue et efficace : le format safetensors, conçu par Hugging Face, ne stocke que des tenseurs et ne contient aucun code exécutable. DeepSeek, Mistral et Kimi se distribuent ainsi. S'y ajoutent deux précautions : ne pas activer aveuglément le chargement de code distant que certains modèles embarquent, et traiter la pile d'inférence comme un actif sensible. L'unité Unit 42 de Palo Alto Networks notait en janvier 2026 que plus d'une centaine de bibliothèques Python gravitent autour de ces modèles, la surface d'attaque résidant désormais largement dans le code qui consomme les fichiers. Cette famille est maîtrisable : c'est de la sécurité de chaîne d'approvisionnement, avec des contrôles éprouvés.
La porte dérobée cachée dans les poids
La seconde famille est plus retorse, et le format sûr n'y change rien, parce que le danger vit dans les poids légitimes eux-mêmes.
⚠️ Point de vigilance
Une porte dérobée comportementale peut être encodée dans un modèle pendant son entraînement. Le modèle se comporte normalement, sauf lorsqu'il rencontre une phrase déclencheur, qui active alors un comportement caché. On ne peut pas prouver son absence en scannant le fichier.
L'ampleur du problème a été quantifiée en octobre 2025 par une étude conjointe d'Anthropic, du UK AI Security Institute et de l'Alan Turing Institute. Elle montre qu'environ 250 documents malveillants insérés dans les données de pré-entraînement suffisent à implanter une porte dérobée, quelle que soit la taille du modèle, soit 0,00016 % des données d'entraînement d'un modèle de treize milliards de paramètres. Des travaux antérieurs sur les « agents dormants » avaient montré que ce comportement résiste à l'entraînement de sûreté, le réglage fin échouant souvent à le retirer et apprenant parfois au modèle à mieux le dissimuler.
Deux conséquences pour un cabinet. D'abord, ce risque n'est pas propre aux modèles chinois : il est générique à tout modèle entraîné sur des données issues du web, Mistral compris, car un acteur malveillant peut semer des contenus empoisonnés dans des sources ouvertes. L'origine du modèle reste un signal de confiance, mais un signal faible. Ensuite, puisqu'on ne peut pas détecter ces portes dérobées, la défense n'est pas la détection mais le confinement. C'est là que l'auto-hébergement prend tout son sens, à condition d'être configuré pour : un modèle servi sur un réseau dont la sortie est verrouillée ne peut physiquement pas exfiltrer de données. S'y ajoutent le moindre privilège pour les agents, la validation humaine sur les actions à conséquence, et la revue de tout code généré avant exécution. Ce dernier point vise directement ceux qui veulent construire leurs propres outils : si le modèle qui écrit votre logiciel est piégé, vous héritez de ses vulnérabilités. Posséder son code n'a de valeur que si l'on relit ce que la machine a produit.
Comment choisir son IA sur mesure : la démarche pour un cabinet
La leçon de Kirkland n'est pas « tout cabinet doit dépenser 500 millions ». Le cabinet investit environ 1 % de revenus qui dépassent dix milliards de dollars, une marge dont aucune structure française de taille moyenne ne dispose. La leçon est ailleurs : la propriété du code et la maîtrise de la donnée sont devenues des actifs stratégiques, et il existe désormais un éventail de moyens d'y accéder, pas seulement le grand saut industriel. Pour un cabinet, je formulerais la démarche ainsi :
- Partir de la sensibilité réelle des données et de l'obligation de secret, pas du dernier classement de performance. Un dossier de fusion sensible et une recherche de jurisprudence publique n'appellent pas le même régime.
- Choisir le mode de déploiement avant le modèle. Pour les usages les plus sensibles, l'inférence managée souveraine en Europe ou en Suisse offre la résidence des données et la conformité sans la charge d'un parc de serveurs. L'auto-hébergement complet ne se justifie qu'au-delà d'un certain volume et avec une vraie compétence de sécurité interne.
- Négocier les garanties contractuelles comme n'importe quel contrat à risque, en surveillant la nationalité du prestataire au regard du CLOUD Act.
- Ne pas oublier que posséder l'outil n'efface pas la responsabilité, il l'internalise. Les rappels à l'ordre récents de juridictions face à des écritures entachées d'hallucinations le montrent : la diligence reste celle de l'avocat, quel que soit le modèle derrière l'écran.
La bonne posture n'est ni le rejet de principe des modèles ouverts, fussent-ils étrangers, ni l'adoption naïve de la solution la plus visible du marché. C'est un arbitrage informé, où la souveraineté ne se mesure pas au drapeau du modèle mais à l'architecture dans laquelle vous le faites vivre. En tant qu'avocat en IA, nous aidons cabinets et directions juridiques à structurer ce choix de manière fiable et conforme, à travers notre accompagnement des professionnels du droit et nos formations à l'IA.
Sources : Financial Times et Kirkland & Ellis, 28 mai 2026 ; Anthropic, UK AI Security Institute et Alan Turing Institute, « A small number of samples can poison LLMs of any size », 9 octobre 2025.
Questions fréquentes
Le CLOUD Act s'applique-t-il si mes données sont hébergées en Europe ?
Oui, potentiellement. Le CLOUD Act permet aux autorités américaines de contraindre un fournisseur de droit américain à produire des données qu'il détient, même stockées hors des États-Unis. La localisation européenne de la donnée ne neutralise donc pas, à elle seule, l'exposition liée à la nationalité du prestataire.
Un cabinet peut-il utiliser un modèle comme DeepSeek sans envoyer ses données en Chine ?
Oui. Les alertes des autorités européennes visaient l'application et l'API publiques de DeepSeek, pas les poids du modèle. Lorsqu'un hébergeur européen ou suisse fait tourner DeepSeek sur ses propres machines, les données ne partent pas en Chine : c'est de l'auto-hébergement opéré par un tiers de confiance.
Quels sont les risques cyber d'un modèle d'IA auto-hébergé ?
Ils se rangent en deux familles. D'abord l'exécution de code au chargement, liée au format de fichier : le format pickle peut exécuter du code arbitraire, quand le format safetensors l'évite. Ensuite les portes dérobées encodées dans les poids pendant l'entraînement, indétectables par un simple scan, puisque environ 250 documents malveillants suffisent à en implanter une. La parade n'est pas la détection mais le confinement.