IA générative et données financières : ce que vos équipes font vraiment tourner dans le cloud

IA générative et données financières : ce que vos équipes font vraiment tourner dans le cloud

Votre DAF a demandé à ChatGPT de synthétiser le dernier rapport de clôture trimestrielle. Votre contrôleur de gestion utilise Copilot pour automatiser ses réconciliations bancaires. Votre équipe comptable a branché un assistant IA sur l'export de votre ERP. Tout cela s'est probablement passé sans ticket IT, sans validation juridique, et sans que vous en sachiez grand-chose. Bienvenue dans le vrai problème de l'IA générative en entreprise : ce n'est pas celui que vous pensiez gérer.

Le risque n'est pas où on l'attendait

Pendant deux ans, les directions informatiques ont concentré leurs efforts sur la gouvernance des grands projets IA : déploiement de LLM internes, sécurisation des pipelines de données, validation des modèles. Pendant ce temps, le vrai vecteur d'exposition s'est installé discrètement dans les habitudes de travail quotidiennes.

Le phénomène du *shadow AI* — par analogie avec le shadow IT des années 2010 — est aujourd'hui documenté par plusieurs cabinets d'audit européens. Des collaborateurs métier, sans intention malveillante, transmettent des données financières sensibles à des modèles de langage hébergés hors de l'Union européenne. Bilans intermédiaires, tableaux de flux de trésorerie, données de paie, prévisions budgétaires non publiées : tout cela transite vers des serveurs dont la localisation exacte, et surtout le régime juridique applicable, restent flous pour la majorité des utilisateurs.

Le problème n'est pas nouveau dans sa forme. Il l'est dans son ampleur et dans son invisibilité.

Ce que le cadre réglementaire change concrètement en 2026

L'entrée en application progressive du règlement européen sur l'IA, combinée aux exigences renforcées du DORA pour le secteur financier et aux obligations RGPD qui n'ont pas attendu, crée un environnement juridique dans lequel l'ignorance ne protège plus.

Sur le plan du RGPD d'abord : dès lors que des données financières concernent des personnes physiques identifiables — et c'est souvent le cas dans les PME et ETI, où un tableau de paie ou une note de frais suffit — leur transmission à un service tiers constitue un transfert de données. Ce transfert doit être encadré par des garanties adéquates. Utiliser l'interface web grand public d'un modèle américain ne constitue pas une garantie adéquate. Ce point n'est pas une interprétation agressive : c'est la lecture directe du règlement.

Sur le plan du secret des affaires ensuite : les données financières non publiées constituent dans la plupart des cas des informations commerciales sensibles protégées par la directive européenne sur le secret des affaires, transposée dans le droit national de chaque État membre. Une fuite — même involontaire, même non exploitée — peut avoir des conséquences contractuelles et réputationnelles sévères, notamment vis-à-vis d'investisseurs ou de partenaires liés par des clauses de confidentialité.

Enfin, et c'est souvent le point le moins bien compris par les directions métier : plusieurs fournisseurs de LLM ont modifié leurs conditions d'utilisation pour se réserver le droit d'utiliser les données soumises via certaines interfaces à des fins d'amélioration des modèles, sauf opt-out explicite au niveau entreprise. Ce n'est pas systématique, et les offres enterprise incluent généralement des protections contractuelles, mais les usages individuels non encadrés ne bénéficient pas de ces garanties.

Pourquoi les DSI se retrouvent en porte-à-faux

Il serait trop simple de réduire ce sujet à un problème de sensibilisation des utilisateurs. La réalité est plus inconfortable : les outils IA grand public sont devenus tellement efficaces, tellement intégrés dans les suites bureautiques, que les freiner revient à demander à vos collaborateurs de travailler avec un handicap que leurs concurrents n'ont pas.

Le vrai dilemme du DSI en 2026, c'est celui-là : comment préserver la compétitivité opérationnelle liée à l'IA sans exposer des données qui, si elles fuitent ou si elles sont utilisées de façon non conforme, peuvent coûter bien plus que le gain de productivité réalisé ?

La réponse binaire — tout interdire ou tout autoriser — ne tient pas. L'interdiction se heurte à l'impossibilité pratique de contrôler des usages qui passent par des appareils personnels, des connexions mobiles, des extensions de navigateur. L'autorisation sans cadre revient à déléguer la gestion du risque à des collaborateurs qui n'ont ni les outils ni la formation pour l'assumer.

Ce que le traitement souverain change — et ce qu'il ne change pas

La notion de souveraineté numérique a été tellement instrumentalisée commercialement ces dernières années qu'elle mérite d'être reposée clairement. Dans le contexte de l'IA générative et des données financières, elle recouvre deux réalités distinctes qu'il faut distinguer.

La localisation physique des données : les données restent-elles sur des serveurs situés en Union européenne, soumis au droit européen ? C'est un prérequis nécessaire, mais pas suffisant. Un serveur en Irlande hébergé par une filiale américaine reste potentiellement soumis au CLOUD Act américain, ce que plusieurs analyses juridiques ont confirmé depuis 2022.

La maîtrise du modèle : votre organisation exerce-t-elle un contrôle sur le modèle lui-même — ses paramètres, ses données d'entraînement, les données qui lui sont soumises ? C'est ce niveau de contrôle qui détermine réellement votre exposition.

Deux approches méritent d'être examinées sérieusement pour les DSI de PME et ETI, sans que l'une soit universellement supérieure à l'autre.

Première approche : le déploiement d'un modèle open source sur infrastructure maîtrisée. Des modèles comme Mistral — dont les poids sont disponibles en open source pour certaines versions — permettent un déploiement sur votre propre infrastructure ou chez un hébergeur européen de confiance. Le modèle tourne chez vous, les données ne sortent pas, et vous gardez la main sur les mises à jour. Le coût réel de cette approche ne se limite pas à l'infrastructure : il faut intégrer la maintenance, la mise à jour des modèles, et la gestion de la sécurité. Pour une ETI sans équipe ML dédiée, c'est un engagement sérieux.

Deuxième approche : les offres entreprise avec contractualisation forte sur l'hébergement et le non-usage des données. Scaleway (groupe Iliad) propose depuis plusieurs années des offres d'inférence IA avec hébergement explicitement localisé en France et des engagements contractuels sur la non-utilisation des données clients. C'est une solution intermédiaire : vous n'opérez pas le modèle vous-même, mais vous bénéficiez d'un cadre juridique plus robuste que les offres grand public des hyperscalers américains.

Aucune de ces deux options n'est une solution magique. La première exige des ressources techniques que beaucoup de PME n'ont pas en interne. La seconde repose sur la solidité des engagements contractuels et la confiance dans le fournisseur — deux choses qui méritent d'être vérifiées sérieusement avant signature.

Pistes concrètes pour avancer sans se perdre

Avant d'investir dans une infrastructure ou de signer un nouveau contrat, quelques démarches de bon sens méritent d'être conduites.

Cartographier avant de décider. Vous ne savez probablement pas précisément quels outils IA sont utilisés par vos équipes financières, ni quelles données leur sont soumises. Un audit rapide — questionnaire auprès des équipes, analyse des extensions installées sur les postes, revue des accès aux API externes — permet souvent de découvrir une réalité plus complexe qu'imaginé. C'est le préalable à toute décision rationnelle.

Différencier les données par niveau de sensibilité. Toutes les données financières ne méritent pas le même niveau de protection. Un guide de présentation des résultats annuels déjà publics n'a pas la même criticité qu'un tableau de prévisions à 18 mois ou une simulation de cession d'actifs. Définir des catégories claires permet de construire une politique d'usage de l'IA qui n'est pas uniforme et donc pas contournée systématiquement.

Travailler avec la direction juridique, pas après. Le sujet des transferts de données et des conditions contractuelles des fournisseurs IA n'est pas une question purement technique. Il engage la responsabilité de l'entreprise. Associer le DPO et le service juridique en amont — sur les conditions d'utilisation des outils déployés, pas seulement sur les incidents — est une démarche de protection autant que de conformité.

Ne pas confondre certification et garantie. Plusieurs fournisseurs mettent en avant des certifications SecNumCloud, HDS ou équivalents nationaux. Ces certifications sont des signaux utiles, mais elles certifient des pratiques de sécurité à un instant T, pas la conformité permanente de tous les usages qui en découlent. Elles ne remplacent pas la lecture attentive des clauses contractuelles.

La vraie question que les DSI doivent poser à leur comité de direction

Au fond, ce que révèle cette tension entre productivité par l'IA et protection des données financières, c'est une question de gouvernance que beaucoup d'entreprises ont évitée.

Qui est responsable lorsqu'un collaborateur soumet une prévision budgétaire non publiée à un outil IA non encadré ? La direction IT ? La direction financière ? Le collaborateur lui-même ? La réponse varie selon les entreprises, et dans beaucoup d'entre elles, elle n'a tout simplement pas été tranchée.

C'est peut-être cela, l'enjeu réel de 2026 : moins la sophistication des solutions techniques que la clarté des responsabilités internes. Les outils souverains n'ont de valeur que si les usages qui s'y déploient sont eux-mêmes encadrés par des règles connues et acceptées.

Les DSI qui ont le plus avancé sur ce sujet ne sont pas nécessairement ceux qui ont déployé les infrastructures les plus robustes. Ce sont souvent ceux qui ont réussi à faire de la politique d'usage de l'IA un sujet de direction générale, avec une gouvernance claire, des rôles définis et une revue régulière. La technologie vient ensuite.

Au risque de décevoir les vendeurs de solutions : la souveraineté des données financières commence dans les organigrammes, pas dans les datacenters.