Données d'entraînement IA : trois approches pour ne pas perdre la main face au droit américain

# Données d'entraînement IA : trois approches pour ne pas perdre la main face au droit américain

Depuis l'entrée en vigueur de la révision du RGPD en 2025 — intégrant les nouvelles obligations spécifiques à l'IA Act — la question n'est plus théorique : qui contrôle réellement les données que vous injectez dans un modèle ? Si votre pipeline d'entraînement repose sur une infrastructure américaine, la réponse juridique et technique est rarement celle que vous espérez. Ce comparatif s'adresse aux DSI et RSSI qui doivent trancher concrètement : quelle architecture choisir pour rester dans les clous du droit européen sans sacrifier la capacité opérationnelle ?

Trois approches structurantes émergent sur le marché européen. Elles ne sont pas équivalentes. Voici comment elles se distinguent sur quatre critères qui comptent vraiment.

Les trois approches en présence

Approche A — Délégation à l'acteur dominant américain : vous utilisez les pipelines d'entraînement et de fine-tuning proposés par les grandes plateformes cloud US, avec contractualisation RGPD via leurs clauses standard (DPA, SCCs).

Approche B — Souveraineté hybride sur infrastructure européenne qualifiée : vous déployez un orchestrateur open source (LLM runner, pipeline MLOps) sur une infrastructure certifiée SecNumCloud ou équivalent nationale, avec un modèle de base européen ou open-weight auditable.

Approche C — Traitement sur site, modèle embarqué : vos données ne quittent jamais votre périmètre. Le modèle tourne en local ou en edge privé, avec des cycles de mise à jour maîtrisés en interne.

Critère 1 — Architecture de la donnée d'entraînement : où circule réellement l'information ?

Approche A : Les données transitent vers des datacenters américains, même lorsque la région choisie est "Europe West". La couche d'orchestration, les API de fine-tuning et les logs d'entraînement restent sous juridiction de l'entité mère américaine. Le Cloud Act de 2018 n'a pas été abrogé. En 2026, aucune décision d'adéquation ne couvre spécifiquement les données utilisées pour entraîner des modèles — le Privacy Shield IA n'existe pas. L'exposition juridique est structurelle, pas contractuelle.

Approche B : L'infrastructure est physiquement et juridiquement européenne. La certification SecNumCloud (France) ou ses équivalents allemand (C5 BSI) et néerlandais garantissent que ni l'hébergeur ni ses actionnaires ne sont soumis à une législation extraterritoriale US. Les données d'entraînement restent dans le périmètre auditable. Le risque résiduel : la chaîne de dépendances logicielles (frameworks, bibliothèques) peut encore inclure des composants américains. C'est gérable, mais ça se documente.

Approche C : Le vecteur d'exposition est quasi nul sur la donnée brute. En revanche, la mise à jour du modèle et l'ingestion de nouveaux jeux d'entraînement nécessitent un processus MLOps interne mature. C'est l'approche la plus souveraine sur le plan architectural, mais elle exige une équipe data/ML en interne ou un prestataire européen dédié.

Critère 2 — Conformité RGPD réformé et IA Act : qui est responsable de quoi ?

La réforme 2025 du RGPD introduit une obligation explicite de traçabilité des données d'entraînement pour tout système IA qualifié de "haut risque" au sens de l'IA Act. Concrètement : vous devez être capable de produire un registre des datasets utilisés, des traitements appliqués, et des mécanismes de suppression à la demande. Cela change radicalement l'équation.

Approche A : La responsabilité est partagée entre vous (responsable de traitement) et le fournisseur américain (sous-traitant). Dans les faits, le fournisseur ne vous donnera pas accès aux logs d'entraînement granulaires de ses propres modèles. Si vous faites du fine-tuning sur un modèle fondation américain, vous ne pouvez pas certifier ce que contient la couche de pré-entraînement. C'est une lacune de conformité documentée que les autorités de contrôle européennes commencent à sanctionner.

Approche B : Vous avez accès à l'ensemble de la chaîne. Si vous utilisez un modèle open-weight — Falcon, Llama dans ses déclinaisons européennes, ou les modèles issus de l'initiative BLOOM/BigScience — vous pouvez auditer le dataset d'origine. L'infrastructure qualifiée ajoute une couche de traçabilité contractuelle et technique. Le DPO peut produire le registre exigé. C'est aujourd'hui l'approche la plus directement alignée avec les exigences des autorités de contrôle.

Approche C : Conformité maximale, mais attention : si le modèle embarqué a été pré-entraîné par un acteur tiers (américain ou autre), la lacune sur la traçabilité du dataset originel reste identique à l'approche B. La souveraineté de l'infrastructure ne dispense pas de la traçabilité du modèle lui-même.

Critère 3 — Gouvernance opérationnelle : qui décide des mises à jour, des retraits, des incidents ?

La gouvernance est le critère le plus sous-estimé dans les comparatifs techniques. En cas d'incident (fuite, biais avéré, injonction d'une autorité nationale), qui a la main ?

Approche A : Le fournisseur américain. Les mises à jour de modèles sont déployées unilatéralement. Vous avez été informés — parfois. Les conditions d'utilisation peuvent changer avec un préavis limité. En 2026, plusieurs ETI européennes ont découvert a posteriori que leurs données de fine-tuning avaient été utilisées pour améliorer le modèle fondation — une pratique que les DPA (Data Processing Agreements) standard des acteurs US autorisent dans certaines clauses opt-out mal documentées.

Approche B : Vous gouvernez le pipeline d'entraînement. Les mises à jour du modèle de base sont à votre initiative. Vous choisissez la cadence, les datasets de mise à jour, et vous maintenez un journal d'audit complet. Le fournisseur d'infrastructure européen n'a pas accès aux données ni aux modèles — seulement à la couche de compute.

Approche C : Gouvernance totale. La contrepartie : la charge de maintenir la pertinence du modèle dans le temps repose entièrement sur votre organisation. Sans processus de retraining structuré, le modèle vieillit et perd en utilité opérationnelle.

Critère 4 — Réversibilité et portabilité : pouvez-vous partir ?

C'est la question que peu de DSI posent avant de signer, et que tous regrettent de ne pas avoir posée.

Approche A : La portabilité est limitée. Vos données de fine-tuning vous appartiennent en théorie, mais les poids du modèle entraîné restent sur l'infrastructure du fournisseur. L'export est possible mais le format propriétaire rend la réutilisation sur une autre plateforme techniquement complexe. Le verrouillage est progressif et difficile à quantifier avant d'être réel.

**Approche B** : Si vous avez travaillé sur des formats ouverts (GGUF, ONNX, HuggingFace-compatible), les poids sont exportables et réutilisables. Deux acteurs européens ont structuré leur offre autour de cette portabilité comme argument commercial différenciant : **Aleph Alpha** (Heidelberg) sur le segment enterprise souverain, et **Scaleway** côté infrastructure, qui propose des environnements MLOps compatibles avec les standards ouverts de l'écosystème HuggingFace.

Approche C : Réversibilité maximale par définition. Le modèle est chez vous. Le risque de lock-in est quasi inexistant sur la donnée et les poids.

Tableau de synthèse

| Critère | Approche A (cloud US) | Approche B (infra EU qualifiée) | Approche C (on-premise) |

|---|---|---|---|

| Localisation effective des données | Juridiquement incertaine | Garantie et auditable | Totale |

| Conformité RGPD réformé / IA Act | Lacunes documentées | Alignée si modèle open-weight | Alignée sous conditions |

| Gouvernance des mises à jour | Fournisseur | DSI / équipe interne | DSI / équipe interne |

| Réversibilité | Faible à moyenne | Bonne si formats ouverts | Totale |

| Charge opérationnelle interne | Faible | Moyenne | Élevée |

Ce que ça implique concrètement pour votre prochaine décision

Si vous démarrez un projet IA impliquant des données clients, RH, ou métier sensibles en 2026, l'approche A n'est plus un choix par défaut acceptable — c'est un risque de conformité que vous devez documenter et assumer explicitement devant votre DPO et votre conseil. Les autorités de contrôle européennes ont commencé à auditer les pipelines d'entraînement, pas seulement les usages finaux.

L'approche B est aujourd'hui le point d'équilibre réaliste pour la majorité des ETI : elle combine conformité auditable, capacité opérationnelle et charge interne maîtrisable. Elle suppose de choisir un prestataire d'infrastructure dont la qualification est vérifiable — pas seulement revendiquée — et un modèle de base dont vous pouvez tracer la généalogie des données.

L'approche C reste pertinente pour les organisations qui traitent des données à sensibilité maximale (défense, santé, juridique) et qui ont les ressources MLOps pour assumer la charge. Elle n'est pas réservée aux grands groupes : des ETI de taille intermédiaire l'ont déployée avec des modèles embarqués de 7 à 13 milliards de paramètres sur des serveurs GPU dédiés.

La question n'est pas quelle approche est la meilleure en absolu. C'est : laquelle pouvez-vous défendre devant votre RSSI, votre DPO et une autorité de contrôle le jour où on vous la demande ?