Modèles fermés, modèles ouverts : qui contrôle réellement l'IA du cabinet ?

Un avocat utilisant un assistant d’IA doit d’abord s’interroger sur l’infrastructure qui exécute le modèle, avant même de vérifier la qualité des réponses. Le Conseil national des barreaux (CNB) encadre ces usages en rappelant des obligations légales comme le secret professionnel, le RGPD (Règlement général sur la protection des données) et la nécessité de vérifier les résultats. Pour les données sensibles, le CNB recommande d’envisager des solutions locales, comme l’installation d’un grand modèle de langage (LLM) sur une machine interne, par exemple avec les modèles Llama ou Mistral, afin de garantir la souveraineté et la confidentialité des données. Cette approche réduit les risques liés à la dépendance à des plateformes tierces.

Un modèle fermé est un service auquel on accède via une plateforme externe : l’utilisateur envoie une requête et reçoit une réponse traitée par l’infrastructure du fournisseur. Cela offre des avantages comme une plateforme dimensionnée, des mises à jour régulières et une amélioration continue, mais implique une délégation totale à l’opérateur. Le cabinet ne maîtrise ni les poids du modèle (paramètres techniques), ni les journaux, ni les sauvegardes. À l’inverse, un modèle à poids ouverts permet de télécharger et d’exécuter le modèle sur une infrastructure locale, offrant un contrôle accru sur les données et les processus. Ce choix redistribue la responsabilité : le cabinet gère l’exploitation mais assume aussi les risques techniques et opérationnels.

Les termes modèle ouvert, open source, poids ouverts et modèle local sont souvent utilisés de manière interchangeable, mais ils ne signifient pas la même chose. Cinq questions clés permettent de clarifier : 1) Les poids (paramètres du modèle) sont-ils téléchargeables ? 2) Le code logiciel nécessaire à l’exécution est-il disponible et sous quelle licence ? 3) Les données d’entraînement et la méthode sont-elles documentées ? 4) La licence autorise-t-elle les modifications et redistributions ? 5) Le cabinet a-t-il la capacité technique et juridique d’exécuter le modèle en autonomie ? Par exemple, Mistral propose des modèles sous licence Apache 2.0, qui permet l’usage et la modification, tandis que Llama impose des conditions spécifiques via sa licence communautaire.

Plusieurs familles de modèles sont souvent citées pour une exécution locale : Mistral, Llama, Qwen et DeepSeek. Chacune présente des caractéristiques distinctes. Mistral publie des modèles sous licence Apache 2.0 pour certaines versions, autorisant l’usage et la modification sous conditions. Llama, développé par Meta, propose des poids accessibles mais avec une licence communautaire restrictive. Qwen propose plusieurs versions adaptées à différents usages, mais leur pertinence pour des dossiers juridiques français doit être évaluée au cas par cas. DeepSeek illustre la nécessité de vérifier les conditions de distribution, car ses licences peuvent inclure des restrictions spécifiques. Aucune de ces solutions n’est universellement adaptée : le choix dépend des besoins techniques et juridiques du cabinet.

Un modèle exécuté localement permet de traiter des documents sensibles (contrats, courriels, archives) sans les transmettre à une plateforme distante. Le cabinet peut couper la connexion internet et vérifier que le traitement se poursuit, réduisant ainsi les points de confiance externes. Cependant, cette approche ne garantit pas automatiquement la sécurité : il faut maîtriser les comptes utilisateurs, les droits d’accès, les fichiers temporaires, les journaux, les sauvegardes et les interfaces d’administration. Le gain principal réside dans la réduction des risques liés à la dépendance à un tiers. Par exemple, un serveur local ne peut pas divulguer des données suite à une erreur de configuration chez un opérateur externe. Le modèle local permet aussi d’automatiser des tâches limitées comme l’extraction de dates ou la classification de pièces, sous supervision humaine.

La souveraineté ne se limite pas à l’emplacement géographique des serveurs. Le guide du CNB souligne que des critères comme la nationalité de l’entreprise détenant les serveurs, les législations applicables (y compris extraterritoriales), les sous-traitants et la gouvernance sont tout aussi importants. Par exemple, un serveur situé en France peut être exploité par une entreprise européenne dépendante d’un fournisseur extérieur, ou un service chiffré peut nécessiter un traitement en clair ailleurs. La souveraineté se définit comme la capacité à savoir, décider et vérifier qui accède aux données, dans quelles conditions, quelles versions du modèle sont utilisées, et comment le système peut être contrôlé ou interrompu. Un cloud professionnel bien documenté peut parfois offrir une souveraineté plus fiable qu’une machine locale mal administrée.

L’exécution locale d’un modèle à poids ouverts déplace les risques : le cabinet doit financer une machine adaptée, ses sauvegardes, ses mises à jour et sa maintenance. Il doit gérer les vulnérabilités logicielles, les dépendances et les pannes matérielles, ainsi que tester la qualité du modèle sur ses propres dossiers. Les performances affichées sur des benchmarks généraux ne reflètent pas forcément la précision sur des documents juridiques spécifiques. Par exemple, le modèle peut mal interpréter des dates ou des montants dans des contrats. Le risque est alors déplacé : avec un service fermé, le risque dépend du fournisseur ; avec un modèle local, il dépend de la capacité du cabinet à organiser, tester et réduire les risques d’exploitation. Cela exige une compétence technique interne ou un prestataire dédié.

Pour choisir une architecture adaptée, un cabinet doit d’abord classer ses usages et données selon leur sensibilité. Pour des informations publiques, un service fermé peut suffire, à condition de ne pas y introduire de données confidentielles. Pour des traitements internes sensibles, un environnement souverain et documenté (cloud ou local) peut être un compromis. Pour les dossiers couverts par le secret professionnel, l’exécution locale d’un modèle à poids ouverts est à privilégier, même si ce n’est pas toujours la solution proportionnée. L’architecture doit inclure des étapes clés comme l’anonymisation des données, le cloisonnement des accès, la journalisation des événements, les sauvegardes et les procédures de suppression. Le système doit aussi pouvoir répondre « source insuffisante » ou « vérification nécessaire » pour éviter de présenter une hypothèse comme un fait.