Quand l'IA américaine entre dans le SI d'une ETI : retour sur une conformité qui faillit mal tourner

# Quand l'IA américaine entre dans le SI d'une ETI : retour sur une conformité qui faillit mal tourner

C'est une histoire qui se répète en ce moment dans des dizaines de PME et ETI européennes. Une direction générale enthousiaste, un outil IA présenté comme « révolutionnaire » lors d'un salon, un pilote lancé trop vite — et une DSI qui ramasse les morceaux six mois plus tard. Celle que je vais vous raconter s'est déroulée dans une ETI industrielle française d'environ 800 salariés. Elle est anonymisée, mais elle est réelle. Et elle devrait vous tenir éveillé.

Le contexte : un pilote « inoffensif » qui ne l'était pas

Établissement du secteur de la mécanique de précision, cette ETI travaille pour des donneurs d'ordre dans la défense civile et l'aéronautique. Son niveau de maturité cyber est correct — RSSI en poste depuis trois ans, politique de gestion des accès à jour, démarche NIS2 engagée. Pas une entreprise naïve.

Pourtant, début 2025, un responsable de business unit déploie — avec l'accord tacite de la direction — un outil d'assistance à la rédaction documentaire basé sur un modèle de langage opéré par un acteur américain dominant. L'usage initial semble anodin : reformulation de comptes-rendus de réunion, aide à la rédaction de cahiers des charges fournisseurs. Quelques licences, un abonnement signé directement par la BU, sans passer par la DSI.

C'est le premier signal d'alarme. Pas le dernier.

Ce que personne n'avait lu dans les CGU

Lorsque la RSSI est informée de l'existence du pilote — par hasard, lors d'un audit interne — elle commence par relire les conditions générales d'utilisation de l'outil. Ce qu'elle y trouve mérite qu'on s'y arrête longuement.

Premièrement, les données saisies dans l'interface — y compris les documents chargés pour contextualiser les requêtes — peuvent être utilisées pour améliorer les modèles, sauf désactivation explicite d'une option enfouie dans les paramètres avancés du compte entreprise. Option que personne n'avait désactivée.

Deuxièmement, l'infrastructure qui traite ces données est hébergée dans des datacenters soumis au droit américain, et plus précisément au Cloud Act de 2018. Ce texte autorise les autorités fédérales américaines à exiger d'un opérateur américain la communication de données stockées ou traitées par lui, y compris hors du territoire des États-Unis, sans que l'entreprise cliente européenne en soit nécessairement informée. Ce n'est pas une hypothèse théorique. C'est le droit en vigueur.

Troisièmement, dans les documents chargés par les collaborateurs figuraient des éléments de spécifications techniques liés à des contrats en cours. Des données qui, dans le contexte sectoriel de cette ETI, auraient pu relever de la qualification d'informations sensibles au sens de la réglementation française sur la protection du patrimoine économique.

Je ne dis pas que ces données ont été compromise. Je dis qu'elles auraient pu l'être, légalement, sans recours possible.

Le problème RGPD qu'on n'avait pas vu venir

Parallèlement à l'analyse contractuelle, la RSSI mandate une revue de conformité RGPD sur le traitement en question. Et là, le tableau se complique encore.

L'outil en question traite des données à caractère personnel : les noms des collaborateurs apparaissent dans les comptes-rendus reformatés, parfois des coordonnées clients, parfois des informations sur des sous-traitants identifiables. Or aucun registre de traitement n'avait été mis à jour, aucune analyse d'impact (PIA) n'avait été conduite, et aucune clause contractuelle spécifique n'avait été négociée avec le fournisseur américain pour encadrer ce traitement en qualité de sous-traitant au sens de l'article 28 du RGPD.

En d'autres termes : l'ETI était en infraction caractérisée. Pas par malveillance. Par précipitation et par un manque total de processus de validation des outils IA en amont du déploiement.

Ajoutons à cela la dimension NIS2. Cette ETI, compte tenu de sa taille et de son secteur d'activité, entre dans le périmètre des « entités importantes » au sens de la directive, transposée en France. À ce titre, elle a des obligations de gestion du risque lié à la chaîne d'approvisionnement numérique — et un outil IA externe non qualifié, non audité, constitue précisément ce type de risque. La RSSI se retrouve donc face à une triple exposition : Cloud Act, RGPD, NIS2.

Comment ils s'en sont sortis — et ce que ça a coûté

La réponse a pris plusieurs semaines. L'outil a été suspendu immédiatement, le temps de conduire une analyse complète. Les collaborateurs concernés ont été informés et formés. Le registre de traitement a été mis à jour. Une PIA a été conduite.

Ensuite, la DSI et la RSSI ont travaillé ensemble pour évaluer des alternatives. Je ne vais pas vous livrer une liste de solutions : ce n'est pas le sujet de cet article et chaque contexte est différent. Ce que je peux dire, c'est que des solutions européennes capables de traiter ce type de cas d'usage existent, que certaines peuvent être déployées en environnement on-premise ou en cloud souverain, et que le différentiel de performance avec les outils américains dominants s'est considérablement réduit depuis 2024.

La direction a fini par comprendre — tardivement — que le vrai coût n'était pas celui de la licence logicielle, mais celui du risque juridique, réputationnel et opérationnel qu'un tel déploiement faisait peser sur l'entreprise. Coût difficile à chiffrer a priori, mais bien réel a posteriori.

Ce que cette histoire dit de notre rapport collectif à l'IA américaine

Je veux être direct : ce cas n'est pas exceptionnel. Il est représentatif d'une dynamique que j'observe depuis plusieurs mois dans les entreprises européennes de taille intermédiaire. La pression à « faire de l'IA » vient d'en haut, les outils les plus visibles et les plus marketés sont américains, et les équipes IT se retrouvent à gérer l'urgence plutôt qu'à piloter la stratégie.

C'est un problème de gouvernance avant d'être un problème technique. Et c'est aussi un problème de culture : nous avons collectivement intégré l'idée que les outils américains sont la norme de référence, et les alternatives européennes des options de second rang qu'on envisage faute de mieux. Il faut renverser cette logique.

Déployer un outil IA opéré par un acteur soumis au Cloud Act dans un SI industriel sensible n'est pas un choix neutre. C'est un choix politique, économique et juridique — souvent fait sans en avoir conscience. Et c'est précisément pour ça qu'il est dangereux.

Ce que je retiens, et ce que vous devriez faire dès cette semaine

Pour les DSI et RSSI qui me lisent, voici ce que cette situation m'inspire comme réflexes immédiats :

Primo, auditez maintenant les outils IA en usage dans vos équipes — y compris ceux que vous n'avez pas déployés vous-mêmes. Le shadow IT IA est une réalité dans la quasi-totalité des entreprises de plus de 200 salariés en 2026.

Secundo, relisez les conditions contractuelles de chaque outil avec le prisme Cloud Act et RGPD article 28. Si vous n'avez pas de DPO disponible pour le faire, c'est aussi une information utile sur votre niveau de maturité.

Tertio, construisez une politique d'homologation des outils IA avant tout nouveau déploiement. Pas un tunnel bureaucratique de six mois — un processus léger, documenté, qui force les bonnes questions : Où sont les données ? Qui peut y accéder ? Quel droit s'applique ?

La souveraineté numérique ne se décrète pas depuis Bruxelles. Elle se construit, un SI à la fois, dans les arbitrages quotidiens que font les DSI et les RSSI européens. Cette ETI industrielle a failli payer cher une décision prise en cinq minutes. D'autres paieront effectivement, si on ne change pas nos réflexes.

*Retour terrain réalisé à partir d'une situation réelle, anonymisée à la demande des personnes concernées.*