Vos données ne sont pas leur plateforme
Bertrand 4 novembre 2025

Vos données ne sont pas leur plateforme

15 min de lecture

Chaque fois que votre équipe de service client envoie une requête à une plateforme IA tierce, vous envoyez vos données clients, votre langage opérationnel, votre expertise métier et votre intelligence concurrentielle à un serveur que vous ne contrôlez pas. La réponse revient. Les données restent.

Ce n’est pas un argument de vie privée. C’est un argument d’architecture.

Le problème de la plateforme louée

Le parcours standard d’adoption IA pour une PME européenne en 2025 ressemble à ceci : s’inscrire à un service IA géré, lui donner vos données d’entreprise, le laisser apprendre vos schémas, dépendre de ses sorties. L’installation prend une semaine. La dépendance prend un trimestre.

Le RGPD — spécifiquement l’article 28, qui régit les obligations du sous-traitant — exige un cadre contractuel entre le responsable du traitement (vous) et le sous-traitant (la plateforme). La plupart des entreprises cochent cette case. Peu d’entreprises comprennent ce qui arrive à la valeur dérivée de leurs données une fois que la plateforme les traite.

La distinction compte. Vos données clients, isolées, sont à vous. Les schémas extraits de vos données clients, combinés aux schémas de dix mille autres entreprises, deviennent un signal d’entraînement. Ce signal d’entraînement améliore le modèle général de la plateforme. Le modèle général est ensuite revendu — à vous et à vos concurrents — comme une fonctionnalité.

Vous subventionnez un produit qui sera utilisé contre vous. Avec vos propres données.

Ce que souveraineté des données signifie concrètement

La souveraineté des données ne consiste pas à garder les données dans un coffre. C’est contrôler la chaîne d’extraction de valeur. Trois niveaux.

Niveau un : souveraineté de stockage. Vous savez où vos données résident physiquement. C’est le socle du RGPD. Les articles 44 à 49 régissent les transferts internationaux de données. La plupart des entreprises de l’UE ont traité ce point — ou pensent l’avoir fait. Les orientations du CEPD sur les fournisseurs de services cloud ont ajouté de la précision : connaître le pays ne suffit pas. Vous devez connaître les centres de données spécifiques, les sous-traitants, et les conditions dans lesquelles les données peuvent être consultées par des entités tierces.

Niveau deux : souveraineté de traitement. Vous contrôlez comment vos données sont traitées. Cela va au-delà de la limitation des finalités de l’article 5 du RGPD. La souveraineté de traitement signifie que quand vos données sont utilisées pour entraîner, fine-tuner ou ajuster un modèle, les améliorations résultantes du modèle sont attribuables et contrôlables. La plupart des plateformes IA gérées n’offrent pas ce niveau de transparence. Le traitement se fait dans une boîte noire. L’extraction de valeur est opaque.

Niveau trois : souveraineté des insights. Les schémas, prédictions et décisions dérivés de vos données restent à vous. Pas comme une revendication juridique — comme une architecture technique. Les insights générés à partir de vos données opérationnelles alimentent vos systèmes, pas un modèle généraliste qui sert vos concurrents.

La plupart des entreprises opèrent au niveau un et supposent avoir résolu le problème. Ce n’est pas le cas.

L’architecture de l’indépendance

Intégrer la souveraineté des données dans un déploiement IA n’est pas philosophique. C’est architectural. Quatre décisions techniques.

Décision un : où le modèle s’exécute. Un modèle qui s’exécute sur votre infrastructure (ou sur une infrastructure cloud dédiée avec des garanties contractuelles) traite vos données sans les transmettre à une plateforme partagée. Il ne s’agit pas de construire votre propre GPT. Il s’agit de déployer des modèles fine-tunés — des modèles à poids ouverts comme Mistral, Llama ou Qwen — sur une infrastructure que vous contrôlez. Le coût de calcul est plus élevé qu’une API gérée. La souveraineté est absolue.

Pour la plupart des PME, le compromis pratique est une instance dédiée d’un modèle géré avec des garanties contractuelles que vos données ne sont pas utilisées pour l’entraînement, ne sont pas combinées avec les données d’autres clients, et sont supprimées après traitement. Anthropic, OpenAI et Mistral offrent tous de telles garanties — mais vous devez lire le contrat spécifique, pas la page marketing. La fiche modèle (un document sur lequel j’écrirai séparément) en dit plus sur ce que le modèle fait réellement que le pitch commercial.

Décision deux : où le fine-tuning a lieu. Si vous fine-tunez un modèle sur vos données métier — vos transcriptions de support client, vos spécifications produit, vos procédures opérationnelles — le modèle adapté qui en résulte contient votre intelligence concurrentielle dans ses poids. Ce modèle doit résider sur une infrastructure que vous contrôlez. Fine-tuner sur une plateforme louée signifie que votre expertise métier est intégrée dans un système que vous ne possédez pas. Si la plateforme change ses conditions, augmente ses prix ou arrête le service, votre modèle fine-tuné part avec.

Décision trois : où vivent les vecteurs. Les architectures RAG (generation augmentée par récupération) utilisent des bases de données vectorielles pour stocker les embeddings de vos documents. Ces embeddings sont une représentation compressée de votre base de connaissances. Ils devraient résider sur une infrastructure que vous contrôlez — pas sur un service vectoriel géré qui mélange vos embeddings avec ceux d’autres clients. Héberger votre propre base de données vectorielle (Qdrant, Milvus, pgvector dans une instance PostgreSQL gérée) coûte entre 50 € et 300 € par mois pour une charge de travail PME typique. C’est le coût de posséder votre architecture de connaissances.

Décision quatre : où la boucle de rétroaction se ferme. Quand les utilisateurs interagissent avec votre outil IA, leurs retours — corrections, préférences, suggestions rejetées — sont les données les plus précieuses du système. Elles disent où le modèle échoue sur vos tâches spécifiques. Cette boucle de rétroaction doit se fermer dans vos systèmes. Si les retours vont vers une plateforme gérée, la plateforme apprend des corrections de vos utilisateurs. Vous avez payé le déploiement. Ils récoltent l’apprentissage.

La dimension de l’article 22 du RGPD

L’article 22 du RGPD donne aux individus le droit de ne pas être soumis à des décisions fondées exclusivement sur un traitement automatisé. C’est habituellement discuté comme une exigence de conformité. C’est aussi une exigence architecturale.

Si votre outil IA prend des décisions qui affectent des individus — évaluation du crédit, tri de recrutement, éligibilité à un service — l’article 22 exige une supervision humaine effective. « Effective » est le mot opératif. L’action de mise en application de l’autorité de protection des données de Hambourg en 2025 (une amende de 492 000 € pour prise de décision de crédit automatisée sans supervision humaine effective) a démontré que « effective » signifie que l’examinateur humain doit avoir la capacité technique et l’autorité opérationnelle de passer outre la décision automatisée. Un processus d’examen qui consiste à tamponner ne se qualifie pas.

Quand cette prise de décision automatisée s’exécute sur une plateforme tierce, l’architecture technique pour une supervision humaine effective devient plus complexe. L’examinateur humain a besoin d’accéder au raisonnement du modèle (ou au moins à ses signaux de confiance), aux données d’entrée et aux décisions alternatives que le modèle a considérées. Si ceux-ci sont générés sur une plateforme louée, le processus d’examen dépend des fonctionnalités d’explicabilité de la plateforme — qui peuvent être limitées, changer sans préavis, et ne pas satisfaire la définition d’« effective » de l’autorité de protection des données.

Sur votre propre infrastructure, vous contrôlez la couche d’explicabilité. Vous décidez ce que l’examinateur humain voit, quels mécanismes de dérogation existent, et comment les décisions sont journalisées.

Les canaux propriétaires : le parallèle avec le contenu

L’argument de la souveraineté des données a un parallèle avec le contenu qui est tout aussi important et tout aussi sous-estimé.

La plupart des entreprises produisent du contenu sur des plateformes louées : posts LinkedIn, stories Instagram, articles Medium. La plateforme contrôle la distribution. L’algorithme détermine la portée. Les conditions d’utilisation définissent ce que vous pouvez dire. Votre audience est à un changement d’algorithme de la disparition.

Les canaux propriétaires — votre site web, votre liste email, vos relations clients directes — sont l’équivalent contenu de la souveraineté des données. Vous contrôlez la distribution. Vous possédez la relation. L’audience vous appartient, pas à la plateforme.

Chez Bluewaves, chaque contenu que nous produisons vit d’abord sur notre propre domaine. Il peut être syndiqué ailleurs, mais la version canonique vit sur une infrastructure que nous contrôlons. Chaque relation abonné est directe — aucun algorithme entre nous et le lecteur. Chaque donnée de performance alimente notre analytique, pas le tableau de bord d’une plateforme qui peut être abandonné sans préavis.

Le même principe s’applique au déploiement IA. Votre outil IA devrait s’exécuter sur des canaux que vous possédez, servir des utilisateurs avec lesquels vous avez une relation directe, et générer des données qui alimentent vos systèmes. Louer la portée est tentant parce que c’est rapide. Posséder la portée est plus difficile parce que cela nécessite de l’infrastructure. Mais la portée louée est louée, et le propriétaire peut changer les conditions à tout moment.

La comparaison des coûts que personne ne fait honnêtement

Les plateformes IA gérées facturent à l’usage : par token, par requête, par appel API. Le coût marginal semble faible. À l’échelle, il se compose.

Une entreprise de 200 personnes exécutant un outil IA de service client qui traite 500 requêtes par jour à une moyenne de 2 000 tokens par requête traite 1 million de tokens par jour. Aux prix actuels des API gérées (environ 3 à 15 $ par million de tokens d’entrée selon le modèle et le fournisseur), cela fait 90 à 450 $ par mois pour l’inférence seule. Abordable.

Mais ajoutez les coûts de fine-tuning, l’hébergement de la base de données vectorielle, le monitoring, et le coût implicite des données qui vont vers un tiers, et la comparaison change. Un déploiement dédié sur un cluster Kubernetes géré avec un modèle à poids ouverts coûte 400 à 1 200 € par mois pour la même charge de travail — avec une souveraineté totale des données, pas de facturation au token, et aucune dépendance aux décisions de tarification d’un fournisseur.

Le coût initial est plus élevé. Le coût continu est plus bas. Le coût stratégique — le coût de la dépendance envers une plateforme qui contrôle votre pipeline de données — est nul.

La plupart des entreprises ne font jamais cette comparaison parce que l’API gérée est plus rapide à mettre en place. La vitesse de mise en place n’est pas un avantage stratégique. La vitesse de mise en place est une commodité tactique qui devient un passif stratégique.

La dimension BCE

La Revue de stabilité financière de la BCE de novembre 2025 a noté que « le risque de concentration chez les fournisseurs de services cloud et IA représente une préoccupation systémique pour la stabilité financière de l’UE ». Le rapport a spécifiquement signalé la dépendance des institutions financières de l’UE envers un petit nombre de fournisseurs d’infrastructure IA basés aux États-Unis.

C’est la version macro du même argument. Quand des milliers d’entreprises dépendent des mêmes trois plateformes IA, un changement de prix, une interruption de service ou un changement de politique les affecte toutes simultanément. Le risque de concentration au niveau de l’entreprise individuelle est de la dépendance. Le risque de concentration au niveau de l’UE est une vulnérabilité systémique.

Pour une PME individuelle, la réponse n’est pas de construire son propre cloud. C’est de s’assurer que son architecture IA est portable — que vous pouvez déplacer vos modèles, vos données et vos flux de travail vers un autre fournisseur (ou vers votre propre infrastructure) sans tout reconstruire. La portabilité est l’expression architecturale de la souveraineté.

Les modèles à poids ouverts sont portables par définition. Un modèle que vous avez fine-tuné sur Mistral peut s’exécuter sur n’importe quelle infrastructure qui supporte le format du modèle. Un modèle que vous avez fine-tuné sur une plateforme gérée peut être exportable ou non — vérifiez le contrat.

Votre base de données vectorielle est portable si elle utilise des formats et des protocoles ouverts. Votre pipeline RAG est portable s’il est construit sur des composants open-source. Vos données de rétroaction sont portables si elles sont stockées dans un format que vous contrôlez.

La portabilité n’est pas une fonctionnalité. C’est une décision architecturale prise avant la première ligne de code.

Ce que cela signifie opérationnellement

Pour une PME européenne de 50 à 500 employés, la souveraineté des données dans le déploiement IA signifie :

Utilisez les API gérées pour l’expérimentation, pas pour la production. Testez les modèles, évaluez les capacités, prototypez les cas d’usage sur des plateformes gérées. Quand le cas d’usage est validé, construisez le déploiement en production sur une infrastructure que vous contrôlez. Le pilote tourne sur leur plateforme. Le produit tourne sur la vôtre.

Fine-tunez sur votre infrastructure. Si votre outil IA a besoin de connaissances spécifiques au domaine, fine-tunez un modèle à poids ouverts sur vos données, sur votre infrastructure. Le modèle résultant est le vôtre — les poids, les adaptations, l’intelligence concurrentielle intégrée dans ces adaptations.

Possédez la boucle de rétroaction. Chaque interaction utilisateur avec votre outil IA génère des données. Corrections, préférences, schémas d’usage, modes de défaillance — ces données valent plus que les données d’entraînement originales parce qu’elles représentent ce dont vos utilisateurs spécifiques ont réellement besoin. Stockez-les dans vos systèmes. Utilisez-les pour améliorer votre modèle. Ne les envoyez pas à une plateforme gérée où elles deviennent partie de leur signal d’entraînement général.

Construisez pour la portabilité. Utilisez des formats ouverts, des protocoles ouverts, des modèles ouverts. Quand vous pouvez changer de fournisseur en une semaine plutôt qu’en un trimestre, vous avez la souveraineté. Quand le changement prend six mois de réingénierie, vous êtes un locataire, pas un propriétaire.

Lisez le contrat, pas le marketing. Les conditions d’utilisation des plateformes IA ne sont pas des documents marketing — ce sont des instruments juridiques qui définissent ce qui arrive à vos données. Lisez-les. Spécifiquement : le fournisseur utilise-t-il vos données pour l’entraînement du modèle ? Dans quelles conditions ? Pouvez-vous exporter votre modèle fine-tuné ? Vos embeddings vectoriels ? Vos journaux d’utilisation ? Si la réponse est non, vous savez ce que vous achetez.

La décision construire-vs-acheter, recadrée

La décision conventionnelle construire-vs-acheter en IA se concentre sur la capacité : pouvez-vous construire un modèle aussi bon que le service géré ? La réponse, pour la plupart des PME, est non. Les modèles gérés sont entraînés sur plus de données, avec plus de puissance de calcul, par plus de chercheurs que n’importe quelle PME ne peut reproduire.

Mais la décision ne porte pas sur la capacité. Elle porte sur le contrôle.

Achetez la capacité. Possédez les données. C’est le compromis pratique que la plupart des discussions sur la souveraineté manquent.

Utilisez l’API du modèle géré pour l’inférence — pour générer des sorties, répondre aux questions, classer les entrées. La capacité du modèle est louée. Les données qui passent par le modèle ne le sont pas.

Possédez le pipeline de données : les entrées, les sorties, les retours, les corrections, les schémas d’usage. Stockez-les dans vos systèmes. Analysez-les avec vos outils. Utilisez-les pour évaluer, améliorer et éventuellement remplacer le modèle géré par une alternative fine-tunée à poids ouverts.

Possédez la base de données vectorielle : les embeddings de votre base de connaissances, vos documents, vos procédures opérationnelles. Ce sont vos connaissances organisationnelles sous forme compressée. Elles ne devraient pas résider sur une plateforme partagée.

Possédez le cadre d’évaluation : les benchmarks, les cas de test, les critères de qualité qui déterminent si les sorties du modèle sont suffisamment bonnes pour votre cas d’usage spécifique. Les benchmarks génériques de la plateforme gérée ne capturent pas vos exigences métier.

La séquence est : louer la capacité, posséder les données, construire l’indépendance. L’indépendance ne se fait pas au jour un. Elle se construit sur des mois, à mesure que vos données propres s’accumulent, que votre cadre d’évaluation mûrit, et que votre compréhension de ce dont vous avez besoin d’un modèle IA devient assez spécifique pour justifier un déploiement dédié.

L’API gérée est un point de départ. Elle ne devrait pas être l’architecture.

Le principe

Vos données ne sont pas une matière première neutre qui ne prend de la valeur que lorsqu’elle est traitée par une plateforme. Vos données sont votre avantage concurrentiel, votre intelligence opérationnelle, vos relations clients exprimées sous forme d’information. C’est le produit d’années de travail, de milliers d’interactions, de millions de décisions.

Quand vous les envoyez à une plateforme que vous ne contrôlez pas, vous échangez de la souveraineté contre de la commodité. La commodité est réelle. Le coût est caché — jusqu’à ce que la plateforme change ses prix, ses conditions ou son API, et que vous découvriez que le fondement de votre capacité IA appartient à quelqu’un d’autre.

Possédez vos données. Possédez vos modèles. Possédez vos canaux. Possédez l’infrastructure qui transforme votre savoir en avantage concurrentiel.

L’alternative est de construire votre maison sur un terrain loué et d’espérer que le propriétaire n’augmente jamais le loyer.

Le propriétaire augmente toujours le loyer.

Possédez vos données. Possédez vos modèles. Possédez vos canaux. L’architecture de l’indépendance est plus de travail au départ. C’est moins de travail au total. Et le travail produit quelque chose que la commodité louée ne produit jamais : un actif qui se compose.

Vos données, vos modèles, vos boucles de rétroaction — tout cela se compose. Chaque mois d’opération rend le mois suivant plus précieux. Chaque interaction utilisateur améliore l’interaction suivante. Chaque correction rend le système plus précis.

Sur une plateforme louée, la composition profite à la plateforme. Sur votre propre infrastructure, la composition vous profite.

Possédez l’effet composé. Le loyer n’en vaut jamais la peine.

Écrit par
Bertrand
Technologue Créatif

Entrepreneur en série titulaire d'un doctorat en IA, avec vingt-cinq ans à construire des systèmes à travers l'Europe. Il crée du code comme il surfe : en lisant les patterns, en trouvant le flux, en rendant le difficile facile.

← Toutes les notes