L'actualité en pratique
Claude for Legal et Astra for Law : ce que ces deux offres disent de leur propre architecture
Deux éditeurs de modèles entrent dans le droit à quatre mois d'intervalle. Leur point commun tient en une phrase, et c'est celui qui compte.
Pour les cabinets d'avocats et les directions juridiques qui évaluent leurs options en matière d'intelligence artificielle.
Le 12 mai 2026, Anthropic a publié Claude for Legal. Le 17 septembre, OpenAI a annoncé Astra for Law. Les deux annonces ont été largement commentées, et la question qu'elles posent à qui exerce hors des États-Unis n'est pas celle qui a occupé la presse spécialisée.
Ce qui a été annoncé, exactement
Claude for Legal est une suite open source publiée sous licence Apache 2.0. Elle réunit douze extensions par domaine de pratique et plus de vingt connecteurs vers les logiciels du marché : gestion documentaire, salles de données, revue documentaire, recherche. Chaque extension démarre par un entretien qui apprend la pratique de l'équipe avant de produire quoi que ce soit. La suite est gratuite ; ce qui se paie est l'abonnement au modèle qui la fait tourner.
Astra for Law est une configuration de GPT-6 Astra pour le travail juridique, assortie d'un index de recherche couvrant la jurisprudence, les lois, les règlements, les règles de procédure et les décisions administratives des États-Unis, sur plus de 230 millions d'adresses. L'accès passe d'abord par un programme réservé à des cabinets sélectionnés, l'interface de programmation devant suivre. Vingt-six extensions partenaires accompagnent le lancement.
Les deux offres sont sérieuses, et les chiffres publiés par OpenAI le montrent : sur le Legal Research Bench de Vals AI, un jeu de 200 questions de recherche juridique en droit américain, Astra for Law obtient 54% de réponses correctes contre 38,7% pour le même modèle avec la seule recherche web. Ce n'est pas un effet d'annonce.
Ce que ces offres apportent réellement
Ces deux offres résolvent un problème réel. Un modèle généraliste interrogé sur une question de droit produit des réponses plausibles et des références qui ne le sont pas toujours. Adosser le modèle à un corpus vérifié change la nature de l'exercice : la référence citée existe, elle dit ce qu'on lui fait dire, et le praticien peut la vérifier.
Le second apport est l'intégration. Les extensions de Claude for Legal se branchent sur les systèmes de gestion documentaire, les outils de signature et les plateformes de revue. Les partenaires d'Astra for Law couvrent le même terrain. Dans les deux cas, l'idée est la même : travailler là où les dossiers se trouvent déjà, plutôt que d'exiger qu'on les déplace.
La question du droit applicable
Les deux offres ne se situent pas au même endroit sur cette question, et la distinction mérite d'être faite.
L'index d'Astra for Law couvre le droit des États-Unis. L'offre est destinée en priorité au marché américain, et elle le dit. Hors de cette juridiction, l'apport principal, qui est l'ancrage sur des sources vérifiées, ne s'applique pas au droit que le praticien exerce.
Claude for Legal procède autrement. Les extensions sont des fichiers de texte adaptables, sans juridiction inscrite dans leur conception, et l'accès aux sources passe par des connecteurs ouverts. Plusieurs couvrent d'autres droits que l'américain : l'un d'eux donne accès à plus de 31 millions de documents provenant de plus de 160 juridictions, dont le droit consolidé de l'Union européenne et la jurisprudence des cours suprêmes et constitutionnelles.
L'ancrage sur les sources d'un droit donné n'est donc pas, en soi, ce qui distingue ces offres d'une couche d'orchestration. Ce qui les distingue est ailleurs.
Ce qu'un éditeur de modèle ne peut pas faire
Claude for Legal fonctionne avec les modèles d'Anthropic. Astra for Law fonctionne avec ceux d'OpenAI. C'est une évidence, mais elle a une conséquence que l'on mesure rarement : le contrôle de la production est confié au modèle qui l'a produite.
Quand une de ces offres vérifie une analyse, propose une relecture ou signale une faiblesse dans un raisonnement, c'est la même famille de modèles qui rédige et qui contrôle. Le contrôle partage les biais de la rédaction, ses angles morts, et ses erreurs caractéristiques.
Aucun éditeur n'a de raison de faire autrement : il construirait contre son propre produit.
Cette contrainte a un second effet, plus lent. Qui bâtit ses processus sur l'une de ces offres lie la qualité de son travail à la trajectoire d'un fournisseur. Si un autre modèle devient meilleur dans six mois, il faudra soit attendre, soit tout reconstruire.
Création, challenge, contrôle
MAX n'est pas un modèle. C'est une couche qui en gouverne plusieurs, et qui fait passer chaque production par trois opérations distinctes, confiées à des systèmes différents.
La création. Un modèle rédige, à partir du dossier, des positions déjà retenues et de la terminologie en usage. C'est l'opération que tout le monde connaît, et c'est la seule que la plupart des outils réalisent.
Le challenge. Un second modèle, qui n'a pas rédigé, reprend la production et la conteste. Il cherche ce que le premier n'a pas vu : l'hypothèse posée sans être vérifiée, la qualification retenue sans être discutée, la clause dont la rédaction ouvre une lecture que personne n'a voulue. Ce modèle ne partage ni les données d'entraînement du premier, ni ses biais, ni ses angles morts. C'est précisément pour cela qu'il voit autre chose.
Le contrôle. La production est confrontée aux sources de droit officielles du droit qui s'applique à la demande. Les références citées existent-elles, disent-elles ce qu'on leur fait dire, l'état du texte invoqué est-il celui qui vaut à la date en cause. Cette opération ne relève pas du jugement d'un modèle mais d'une vérification contre une source.
Le droit applicable est celui de la demande, pas celui du fournisseur. Une question de droit français se vérifie contre les sources françaises, une question de droit italien contre les sources italiennes, une question de droit anglais contre les siennes.
Les trois opérations sont séparées parce qu'elles n'ont pas la même nature. Créer demande de produire. Challenger demande de contredire. Contrôler demande de vérifier. Un système qui confond les trois fait faire à un même modèle un travail et sa critique.
Le principe des quatre yeux appliqué aux modèles
Ce principe est connu de tous ceux qui exercent dans un secteur régulé. En banque, un engagement au-delà d'un certain seuil demande deux signatures. En audit, le dossier d'un associé est revu par un autre associé. En conformité, celui qui détecte une alerte n'est pas celui qui la clôt.
La raison n'est pas la défiance. C'est qu'un contrôleur qui partage la perspective du contrôlé ne voit pas ce que celui-ci n'a pas vu.
Ce principe n'a été que rarement transposé aux systèmes d'intelligence artificielle, et jamais comme principe d'architecture, pour une raison structurelle : il suppose deux modèles indépendants l'un de l'autre, donc une architecture qui n'appartient à aucun éditeur.
C'est ce qui sépare une couche d'orchestration d'une offre construite sur un modèle unique. La première peut confier la création et le challenge à des systèmes qui ne se ressemblent pas. La seconde, quelle que soit la qualité de son modèle, fait relire une production par celui qui l'a écrite.
Les trois questions à poser avant de choisir
Trois questions se posent avant de choisir, et aucune ne porte sur les performances annoncées.
La première : sur quelles sources la production est-elle vérifiée ? Un index de 230 millions d'adresses ne vaut rien s'il ne contient pas le droit que vous pratiquez.
La deuxième : qui contrôle ce qui a été produit ? Si c'est le modèle qui l'a rédigé, le contrôle partage ses angles morts. C'est la question que pose le principe des quatre yeux, et elle se pose ici comme ailleurs.
La troisième : que se passe-t-il quand un meilleur modèle arrive ? La réponse détermine si votre équipement vieillit ou s'améliore.
Ces trois questions s'adressent à tout fournisseur, nous compris. Qui les pose obtient de chacun une réponse vérifiable, ou constate qu'il n'en obtient pas.