L'IA Juridique Open Source en 2026

Pendant deux ans, la conversation sur l'IA juridique dans les comités de direction des cabinets a été binaire : « Signons-nous un contrat avec [prestataire X] ? » Ce cadrage supposait que l'IA juridique en production nécessitait un logiciel d'entreprise soutenu par capital-risque avec une infrastructure spécialisée. Ce cadrage a toujours été partiellement incorrect, mais jusqu'en 2026 les alternatives open source nécessitaient un investissement d'ingénierie substantiel — pipelines de découpage, bases de données vectorielles, parseurs de citations, bibliothèques d'invites, accès basé sur les rôles, pistes d'audit. Peu de cabinets en avaient l'appétit.

Mike — aux côtés d'un écosystème de composants open source complémentaires, discret mais rapidement mature — élimine cette taxe d'ingénierie. La pile complète existe désormais. Les autres ingrédients d'un déploiement d'IA juridique privée ont mûri en parallèle :

• Familles de modèles open-weight compétitifs avec la frontière commerciale — Llama 4, Mistral Large, Qwen, DeepSeek, Gemma — exécutables dans le propre cluster GPU d'un cabinet ou via des endpoints privés
• Hébergement de modèles privés auprès de fournisseurs offrant des engagements contractuels de non-entraînement (Anthropic et OpenAI proposent désormais des niveaux enterprise avec opt-out d'entraînement contractuel et capacité dédiée)
• Outils d'ingestion de documents et de citation conditionnés sous forme de bibliothèques open réutilisables
• Interfaces d'IA privée généraliste comme Open WebUI, qui ont établi les patterns UX que Mike affine pour le domaine juridique

Pris ensemble, ce qui était un projet d'ingénierie sur mesure en 2024 est désormais un exercice de configuration en 2026.

En examinant le véritable ensemble de fonctionnalités de Mike — pas le marketing, le logiciel fonctionnel — trois choix de conception méritent l'attention de tout cabinet évaluant un déploiement privé :

Citations verbatim. Chaque réponse est ancrée à une page et un extrait précis d'un document spécifique. Ce n'est pas une fonctionnalité de finition ; c'est la seule architecture qui répond au standard de défendabilité contre les fautes professionnelles. Tout outil qui permet au modèle de paraphraser ou résumer sans citation traçable est inadapté au travail juridique réel.

Projets cloisonnés par dossier. L'unité d'organisation est le dossier, pas le compte utilisateur. Les documents, conversations, workflows et accès naissent et meurent ensemble avec l'engagement. Cela reflète la façon dont les cabinets pensent réellement aux cloisonnements informationnels.

Workflows réutilisables comme objets de premier ordre. Le pattern « enregistrer une invite comme workflow qu'un junior peut exécuter en un clic » est ce qui sépare un chatbot d'une plateforme de productivité. L'implémentation de Mike ici est conceptuellement claire.

Ce sont des bonnes pratiques, pas des fonctionnalités exclusives à Mike. Tout déploiement d'IA juridique privée en 2026 devrait être évalué selon ces critères.

La lecture du code de Mike révèle un périmètre délibéré. Mike est une plateforme, pas un produit clé en main. Plus précisément :

• Il n'y a pas de support commercial. Lorsque l'assistant renvoie une citation erronée à 4h du matin la veille d'un closing, vous appelez votre équipe IT — il n'y a pas de hotline fournisseur.
• Il n'y a pas de SLA. La disponibilité, les temps de réponse, les correctifs de sécurité, la gestion de la dépréciation des fournisseurs de modèles — tout cela relève de la responsabilité de votre cabinet.
• La licence AGPL-3.0 nécessite une attention particulière. Tout cabinet qui modifie Mike et l'utilise dans le cadre d'un service offert à des tiers doit publier ces modifications. Pour la plupart des cabinets l'utilisant en interne, ce n'est pas un problème, mais cela requiert une revue juridique.
• L'intégration avec le DMS, la facturation, la vérification des conflits et la gestion des dossiers est votre projet. Mike fournit la plateforme ; votre équipe écrit les connecteurs.
• L'adoption n'est pas automatique. Les associés seniors qui souhaitent analyser un pack de diligence de 200 pages ne se soucient pas que la technologie sous-jacente soit open source. Ils se soucient de faire confiance aux résultats et que cela s'intègre dans leur workflow. Ce travail est humain, pas technique.

Ce n'est pas une critique de Mike. Les auteurs du projet sont explicites : c'est un code source fonctionnel, pas un service géré. La critique, s'il en est une, porte sur le cadrage selon lequel « l'open source remplace le logiciel propriétaire » — parce que pour la plupart des cabinets, ce qu'ils achètent réellement en payant Harvey ou Legora n'est pas le logiciel.

Lorsqu'un cabinet signe un contrat annuel à six chiffres avec un prestataire commercial d'IA juridique, la répartition de valeur est typiquement :

• 15 % — la plateforme logicielle elle-même
• 20 % — les coûts API de modèles absorbés par le prestataire
• 25 % — disponibilité, sécurité, conformité, pistes d'audit
• 25 % — formation, gestion du changement, succès client
• 15 % — transfert de risque (lorsque quelque chose tourne mal, il y a une contrepartie)

Mike élimine les premiers 15 %. C'est réel, mais c'est aussi les 15 % les plus faciles à remplacer.

Les 85 % restants — la couche opérationnelle, la couche humaine, la couche de confiance — sont là où les cabinets peinent. Et c'est là que la révolution open source ne remplace rien. Elle ne fait que déplacer le coût du prestataire vers le cabinet.

Pour les cabinets dotés d'une solide capacité IT interne et d'un véritable appétit pour opérer une plateforme IA en production, ce déplacement est libérateur. Pour tous les autres, il crée une opportunité que des partenaires peuvent combler — des intégrateurs indépendants dotés de l'expertise en IA juridique pour déployer, personnaliser, former et maintenir une plateforme privée pour le compte du cabinet.

Indépendamment de la plateforme choisie par un cabinet — Mike, une construction sur mesure ou une alternative gérée — voici les bonnes pratiques opérationnelles qui déterminent la réussite d'un déploiement :

1. Sorties avec citation obligatoire. Pas de paraphrase sans citation verbatim vers la source. Le plancher pour la défendabilité contre les fautes professionnelles.
2. Cloisonnements informationnels au niveau du dossier. Les documents et conversations d'un dossier ne doivent jamais se retrouver dans les invites d'un autre, même au sein du même cabinet.
3. Revue du fournisseur de modèles. Lisez les conditions réelles de traitement des données. « Pas d'entraînement » signifie des choses différentes selon les contrats. Les petits caractères sur la journalisation, la rétention et la réponse aux incidents comptent.
4. Option de modèle open-weight pour les dossiers les plus sensibles. Certains dossiers doivent être traités sur une infrastructure GPU locale sans aucun appel API externe. Planifiez l'architecture pour qu'une partie du travail puisse être routée vers l'inférence locale.
5. Bibliothèque de workflows comme actif institutionnel. Traitez la bibliothèque d'invites et de workflows du cabinet comme vous traitez la banque de précédents — versionnée, sélectionnée, attribuée, révisée. Les invites des associés seniors sont du capital intellectuel.
6. Pistes d'audit comme exigence de premier ordre. Chaque invite, chaque résultat, chaque document cité — journalisé avec l'utilisateur, le dossier, l'horodatage. Les demandes en discovery et les enquêtes du barreau ne font pas de pause pour une mise à niveau.
7. Protocoles de revue des sorties. Définissez quelles sorties IA nécessitent une revue humaine et à quel niveau d'ancienneté. Les mémoires rédigés par IA quittant le cabinet sans revue par un associé senior est inacceptable.
8. Divulgation de l'utilisation de l'IA aux clients. De plus en plus exigée par les barreaux et de plus en plus attendue par les clients sophistiqués. Établissez la politique maintenant.
9. Formation à tous les niveaux d'ancienneté. Les associés seniors ont besoin d'une formation différente de celle des collaborateurs juniors, qui ont besoin d'une formation différente de celle des parajuristes.
10. Curation continue des modèles. Les modèles changent. Les capacités s'améliorent, les coûts évoluent, les fournisseurs déprécient. Quelqu'un doit être le stratège en modèles IA du cabinet de façon continue.

Ce ne sont pas des exigences de Mike. Ce sont des exigences de l'IA privée. Tout cabinet opérant toute plateforme d'IA juridique en 2026 — open source ou commerciale — doit planifier pour ces dix points.

Pour la plupart des cabinets, la décision pratique en 2026 n'est pas « open source vs. SaaS » mais « quel dosage d'auto-déploiement et de partenariat est judicieux ? »

Un triage utile :

• Auto-déploiement complet si votre cabinet dispose de personnel IT dédié à l'aise avec Linux, Docker, Postgres, Python, les bases de données vectorielles et les rotations d'astreinte ; si vous avez une capacité d'ingénierie legal-tech en interne ; et si vous pouvez absorber plusieurs mois de développement de la plateforme avant que le premier dossier y soit traité.
• SaaS uniquement si votre cabinet compte moins de 50 avocats, n'a pas de personnel IT, et que les dossiers que vous traitez ne soulèvent pas de problèmes de résidence des données ou de risque d'entraînement qui rendraient un cloud mutualisé inacceptable.
• Déploiement par partenaire pour la majorité — les cabinets qui veulent les avantages de confidentialité et de contrôle d'un déploiement privé mais refusent raisonnablement d'en assumer la charge opérationnelle. Un intégrateur indépendant déploie la plateforme, configure les fournisseurs de modèles, construit la bibliothèque de workflows du cabinet, forme l'équipe et maintient le système en contrat.

La troisième option est la nouveauté. Jusqu'à ce que Mike et ses pairs existent, le déploiement par partenaire était contraint par l'absence de plateformes open source crédibles à déployer. Cette contrainte a été levée.

Lawra s'est positionnée pour ce moment.

Notre ligne de service Sovereign Suite adopte l'approche du déploiement par partenaire : nous déployons une plateforme complète d'IA juridique privée — Mike, là où c'est la bonne solution, ou une architecture sur mesure là où ce n'est pas le cas — dans votre cloud privé ou sur site. Nous intégrons votre DMS. Nous construisons votre bibliothèque de workflows. Nous formons votre équipe. Nous opérons la plateforme en contrat si vous le souhaitez.

Nous sommes délibérément agnostiques en matière de plateforme. Pour certains cabinets, Mike est la bonne réponse. Pour d'autres, la bonne réponse est une construction sur mesure sur des modèles open-weight exécutés sur le propre cluster GPU du cabinet. Pour d'autres encore, un endpoint géré d'Anthropic ou d'OpenAI sous contrat enterprise est le bon équilibre entre risque, coût et simplicité opérationnelle.

La question n'est pas « quelle est la meilleure plateforme ? » — c'est « quelle est la meilleure plateforme pour les dossiers, l'infrastructure et la posture de risque de votre cabinet ? » Nous n'avons aucune relation fournisseur qui biaiserait la recommandation.

L'ère de l'IA juridique open source a commencé en 2026, mais l'ère opérationnelle — la période durant laquelle les cabinets font réellement tourner ces plateformes en production — a à peine débuté. Les 24 prochains mois produiront une vague de consolidation des bonnes pratiques, de guidance réglementaire, de doctrine sur les fautes professionnelles et de règlements des barreaux. Les cabinets qui déploient de façon réfléchie maintenant façonneront ce consensus émergent. Ceux qui attendent l'hériteront.

Le lancement de Mike n'a pas changé la réponse. Il a changé la question. La question était autrefois « un cabinet peut-il opérer sa propre plateforme d'IA juridique ? » La réponse est maintenant évidente : oui. La nouvelle question est « devrait-on le faire, et comment ? » — et celle-là, chaque cabinet doit y répondre pour lui-même.

Nous sommes heureux de vous aider à y répondre.