IA juridique sous RGPD : le retour douloureux d'une ETI qui avait dit oui trop vite

# IA juridique sous RGPD : le retour douloureux d'une ETI qui avait dit oui trop vite

Mi-2025, une ETI industrielle de 800 salariés, spécialisée dans la mécanique de précision et implantée sur trois sites en France et en Belgique, déploie un outil d'IA juridique pour assister son service contrats. L'objectif est légitime : accélérer la revue des accords de sous-traitance, détecter les clauses à risque, préparer les négociations. Douze mois plus tard, la direction juridique et la DSI se retrouvent face à un auditeur externe mandaté par leur principal client allemand — un équipementier automobile soumis lui-même à des obligations de conformité renforcées. Ce que l'auditeur découvre remet en cause l'ensemble du dispositif.

Ce retour terrain n'est pas un cas isolé. Il illustre une trajectoire que beaucoup d'ETI européennes sont en train de suivre sans en mesurer les conséquences.

Ce qui s'est passé concrètement

L'outil retenu à l'époque est une solution américaine, commercialisée en SaaS, avec une interface soignée et une promesse claire : conformité RGPD assurée, données hébergées en Europe. La DSI valide sur la base de la documentation contractuelle. Le DPO, sollicité tardivement, signe un avis réservé mais ne bloque pas.

Premier problème identifié lors de l'audit : le sous-traitant de second rang chargé de l'entraînement et du fine-tuning du modèle est établi aux États-Unis. Les contrats soumis à l'outil — certains couvrant des données personnelles de salariés, de clients, de partenaires — ont donc transité dans une chaîne de traitement dont une partie échappe au cadre juridique européen. Le Data Processing Agreement signé avec l'éditeur ne mentionne ce sous-traitant que dans une annexe technique, rédigée en anglais, mise à jour unilatéralement par l'éditeur sans notification proactive.

Deuxième problème : aucun registre des traitements n'avait été mis à jour pour intégrer cet usage. Le service juridique avait commencé à alimenter l'outil avec des contrats contenant des données personnelles — noms de signataires, coordonnées, parfois éléments salariaux dans les accords de prestation — sans que cela soit formalisé comme un traitement distinct soumis à l'article 30 du RGPD.

Troisième problème, le plus structurel : personne dans l'organisation n'était en mesure de répondre à la question centrale de l'auditeur — *où sont les données une fois le traitement effectué, et pendant combien de temps ?* La politique de rétention de l'éditeur, là encore modifiable sans préavis dans les CGU, prévoyait une conservation des prompts et des outputs à des fins d'amélioration du modèle, sauf opt-out explicite que l'ETI n'avait pas activé.

Ce que l'audit a imposé de reconstruire

L'ETI a dû suspendre l'usage de l'outil pendant plusieurs semaines, le temps de conduire un audit interne accéléré. Voici ce que cette séquence a révélé sur le plan organisationnel — et ce sont ces enseignements qui sont directement transférables.

La chaîne de validation initiale était borgne. La DSI avait évalué l'outil sur des critères techniques et contractuels de surface. Le DPO avait été consulté mais pas intégré au processus de qualification des risques. La direction juridique, principale utilisatrice, n'avait reçu aucune formation sur les implications de soumettre des documents sensibles à un modèle tiers. Trois acteurs, trois angles morts.

Le contrat ne valait pas gouvernance. Avoir un DPA signé avec l'éditeur principal ne suffit pas dès lors que la chaîne de sous-traitance technique est opaque. En 2026, avec la montée en puissance des modèles spécialisés et des pipelines RAG multicouches, la question *qui traite réellement la donnée et à quel endroit* est devenue une question d'ingénierie autant que de droit. La DSI ne peut plus déléguer cette vérification au service achats.

L'absence de compétence interne avait créé une dépendance totale. Lorsque l'auditeur a posé ses questions techniques, l'ETI n'avait personne capable d'y répondre sans solliciter l'éditeur. Ce point est central : quand vous ne comprenez pas comment fonctionne l'outil que vous utilisez, vous ne pouvez pas le défendre face à un tiers exigeant.

Ce que ça change pour la gouvernance interne

L'ETI a engagé une refonte de sa démarche sur trois axes, tous à portée d'une organisation de taille intermédiaire.

Axe 1 — Créer un comité de qualification des outils IA. Pas un comité de plus pour faire bonne figure : une instance légère, réunissant DSI, DPO et responsable juridique, dont le rôle est de qualifier systématiquement tout outil IA avant déploiement selon une grille commune. Cette grille couvre a minima : la localisation réelle du traitement (pas celle annoncée en marketing), l'identité et la localisation des sous-traitants de second rang, les conditions de rétention et d'utilisation des données, et les droits contractuels en cas de modification unilatérale des CGU.

Axe 2 — Monter une compétence interne minimale sur l'architecture des modèles. Il ne s'agit pas de former des data scientists. Il s'agit de former au moins un profil technique — un architecte SI ou un responsable infrastructure — à comprendre ce qu'est un pipeline RAG, comment une requête circule dans un système LLM, où peuvent se loger des risques de fuite ou de rétention de données. Cette compétence doit être interne, non externalisée à un prestataire américain qui a intérêt à vendre sa propre solution.

Deux acteurs européens ont été évalués lors de la phase de reconstruction : Doctrine pour la partie veille et analyse contractuelle (éditeur français, données hébergées en France, modèle auditable sur demande) et Aleph Alpha pour les capacités de traitement documentaire souverain (éditeur allemand, infrastructure européenne certifiée). L'ETI n'a pas encore finalisé son choix, mais le simple fait de disposer d'alternatives crédibles a changé le rapport de force avec son éditeur américain initial, qui a soudainement accepté de renégocier plusieurs clauses.

Axe 3 — Intégrer la revue de conformité IA dans le cycle de vie des contrats fournisseurs. L'ETI a instauré une clause de revue annuelle pour tous ses contrats SaaS à composante IA. À chaque renouvellement, le DPO et la DSI co-signent une attestation de conformité ou déclenchent une procédure de remédiation. Ce n'est pas une lourdeur : c'est une protection contractuelle que les entreprises européennes peuvent opposer à leurs éditeurs.

Ce que le DSI doit retenir

Le cas de cette ETI illustre un glissement qui touche aujourd'hui une large partie du marché européen. Les outils d'IA juridique — comme les outils d'IA RH, financière ou commerciale — sont vendus avec des promesses de conformité qui reposent sur des architectures que l'acheteur n'a pas les moyens de vérifier sans compétence interne dédiée.

Le prisme souverainiste n'est pas ici un choix idéologique : c'est une réponse pragmatique à un risque contractuel et réglementaire réel. Un éditeur soumis au droit américain peut être contraint de communiquer des données à des autorités étrangères sans vous en informer. Un éditeur européen soumis au RGPD est au moins tenu par les mêmes règles que vous.

La question n'est pas *est-ce que mon outil IA est conforme aujourd'hui*. La question est *est-ce que je suis en mesure de le prouver demain matin si un client, un auditeur ou une autorité de contrôle me le demande*.

Pour la majorité des ETI européennes ayant déployé des outils d'IA américains sans audit approfondi, la réponse honnête est non.