Héberger un projet IA en France : OVH, Scaleway ou hyperscaler

Quelles données passent par le modèle

Avant de choisir un hébergement, posez une question simple : qu'est-ce qui part réellement dans le modèle d'IA ? Un agent qui résume des emails internes ne manipule pas les mêmes informations qu'un agent qui lit des dossiers patients ou des données de production industrielle. Listez les champs envoyés au modèle, pas seulement les données stockées dans votre base : un prompt mal conçu peut inclure un nom, une adresse ou un numéro de contrat sans que personne ne s'en rende compte.

Cette étape de diagnostic précède toujours le choix technique. Tant que vous ne savez pas ce qui circule, discuter d'hébergement revient à choisir une serrure avant de savoir ce qu'il y a derrière la porte.

Comment dresser cette liste des champs envoyés

La méthode la plus fiable consiste à reprendre le prompt exact envoyé au modèle, tel qu'il part réellement, et à surligner chaque champ variable qu'il contient : identité, coordonnées, référence de dossier, contenu d'un document joint. Beaucoup d'équipes découvrent à ce moment-là qu'un contexte pensé pour aider le modèle, comme l'historique complet d'une conversation ou le contenu d'une pièce jointe, transporte plus d'informations personnelles que le simple formulaire visible par l'utilisateur. Cette liste, une fois établie, sert de base à toutes les questions suivantes sur le stockage, le traitement et le droit applicable.

Où elles sont stockées, où elles sont traitées

Le stockage et le traitement ne se passent pas toujours au même endroit. Une base de données peut rester dans une région européenne pendant que l'appel au modèle de langage transite par un centre de calcul situé ailleurs. Demandez à chaque fournisseur où sont physiquement les serveurs qui stockent vos données, et où se trouvent ceux qui exécutent l'inférence.

Les questions précises à poser à un fournisseur

Une conversation commerciale reste rarement précise si on ne pose pas la question sous une forme fermée. Il vaut mieux demander directement dans quel pays se trouvent les serveurs de stockage, dans quel pays se trouvent les serveurs qui exécutent le modèle, si ces deux localisations peuvent changer sans préavis selon la charge du service, et si un sous-traitant intervient à un moment de la chaîne, auquel cas sa propre localisation compte aussi. Une réponse vague ou reportée à plus tard sur l'une de ces quatre questions mérite d'être creusée avant de signer.

Sous quel droit tombe votre fournisseur

Le lieu d'un serveur ne dit pas tout : le droit qui s'applique à l'entreprise qui l'exploite compte aussi. Une société soumise au droit américain, même avec des centres de données en Europe, reste concernée par le CLOUD Act, la loi fédérale qui permet à la justice américaine de demander l'accès à des données détenues par un fournisseur relevant de sa juridiction, quel que soit l'endroit où elles sont stockées dans le monde. C'est un fait juridique à intégrer au choix, quel que soit le fournisseur, au même titre que le RGPD encadre les transferts hors de l'Union européenne par des décisions d'adéquation ou des clauses contractuelles types, selon son chapitre V.

Pourquoi cette distinction change concrètement le projet

Cette distinction entre lieu du serveur et droit applicable au fournisseur n'est pas un point théorique réservé aux juristes. Pour un projet qui traite des dossiers patients, des données de ressources humaines ou des plans industriels, elle détermine si une autorité étrangère peut légalement demander l'accès aux données, indépendamment de leur emplacement physique. Pour un chatbot public qui répond à des questions génériques, la même question pèse beaucoup moins lourd. C'est précisément pour cette raison que le diagnostic initial doit qualifier la sensibilité des données avant de choisir un hébergeur, plutôt que l'inverse.

Le fournisseur entraîne-t-il ses modèles sur vos échanges

Posez la question directement et vérifiez la réponse dans le contrat, pas seulement sur la page marketing : vos prompts et vos documents servent-ils à réentraîner le modèle du fournisseur ? Certains contrats l'excluent explicitement pour les usages professionnels, d'autres restent flous ou réservent ce droit par défaut. Chez Kabaun Studio, cette clause est une condition non négociable avant tout déploiement : aucun entraînement de modèle sur les échanges du client, quel que soit le fournisseur retenu.

Où chercher cette clause dans un contrat

La page marketing d'un fournisseur affiche presque toujours un engagement rassurant sur la confidentialité. Le texte contractuel qui compte réellement se trouve ailleurs, souvent dans les conditions d'utilisation de l'API ou dans une annexe technique distincte de l'offre grand public du même fournisseur. Il n'est pas rare qu'un même fournisseur applique des règles différentes selon que vous utilisez son produit grand public ou son offre professionnelle facturée à l'usage. Vérifier laquelle des deux offres est réellement souscrite fait partie des vérifications à ne pas sauter.

Réversibilité : pouvez-vous repartir

Un dernier test avant de signer : si vous changez de fournisseur dans deux ans, combien de temps faut-il pour récupérer vos données dans un format exploitable, et combien de code faut-il réécrire parce que l'appel au modèle était branché en dur sur une API propriétaire ? Une architecture qui passe par une couche d'abstraction entre votre application et le modèle garde cette porte ouverte, comme dans notre approche de l'IA responsable.

Ce que cette couche d'abstraction change en pratique

Concrètement, cette couche d'abstraction consiste à ne jamais faire dépendre le reste de l'application des particularités d'une seule API de modèle. Le code qui prépare la question, celui qui traite la réponse, et celui qui l'affiche à l'utilisateur restent identiques quel que soit le modèle appelé derrière. Le jour où un projet change de fournisseur, pour des raisons de coût, de conformité ou de performance, seul ce point de connexion doit être réécrit, pas l'ensemble de l'application. C'est ce qui transforme un changement de fournisseur d'un chantier de plusieurs mois en une modification de quelques jours.

Trois familles de réponses, pas une hiérarchie

Un fournisseur cloud européen, soumis au droit d'un État membre, simplifie la question du droit applicable et répond souvent aux besoins de conformité les plus stricts. Il demande en général d'accepter un écosystème d'outils moins étendu que celui des plus grands acteurs mondiaux.

Un grand fournisseur américain proposant une région européenne garantit en général un stockage et un traitement réalisés dans l'Union européenne, avec des engagements contractuels sur les transferts, appuyés depuis 2023 sur une décision d'adéquation de la Commission européenne pour les flux vers les États-Unis. Il reste soumis au droit de son pays d'origine pour les questions qui dépassent le strict stockage européen, ce qui se pèse selon la sensibilité réelle de vos données.

Un modèle ouvert hébergé sur une architecture locale ou dédiée garde les données dans votre périmètre, ou celui d'un hébergeur que vous choisissez précisément, sans dépendre du contrat d'usage d'un modèle fermé. Pour les données les plus sensibles, certains organismes s'orientent vers des prestataires qualifiés SecNumCloud par l'ANSSI. Cette option demande en échange une équipe capable de maintenir l'infrastructure, ou un partenaire qui s'en charge.

Ce que chaque famille implique au quotidien

Ces trois familles ne se distinguent pas seulement par la théorie juridique, elles changent aussi le quotidien d'une équipe technique. Le fournisseur cloud européen simplifie les échanges avec un délégué à la protection des données ou un service juridique, mais peut demander d'adapter certains usages aux outils disponibles dans son catalogue. Le grand fournisseur américain avec région européenne offre en général le catalogue de modèles le plus large et l'intégration la plus rapide, au prix d'une vigilance contractuelle plus soutenue sur les clauses de transfert. Le modèle ouvert hébergé localement exige la charge la plus lourde en interne, mises à jour de sécurité, supervision de l'infrastructure, gestion de la montée en charge, mais retire toute ambiguïté sur l'emplacement des données.

Choisir selon la sensibilité des données, pas par principe

Aucune de ces trois familles n'est la bonne réponse en soi. Un chatbot qui répond aux questions fréquentes des visiteurs d'un site public n'a pas les mêmes exigences qu'un agent qui lit des dossiers RH ou des plans industriels. Le diagnostic initial sert précisément à qualifier cette sensibilité avant de recommander une architecture, pour éviter de payer une contrainte technique dont le projet n'a pas besoin, ou d'en négliger une qui l'exige.

Erreurs fréquentes dans le choix d'un hébergement IA

La première erreur consiste à choisir un hébergeur avant d'avoir qualifié la sensibilité réelle des données, en se fiant à une réputation générale plutôt qu'à un examen du projet précis. La deuxième consiste à s'arrêter au lieu du serveur sans vérifier le droit applicable à l'entreprise qui l'exploite, alors que les deux questions sont distinctes et se répondent séparément. La troisième consiste à ne pas relire la clause sur l'entraînement des modèles, en supposant qu'une politique de confidentialité générale couvre automatiquement les échanges professionnels. La quatrième consiste à négliger la réversibilité, en pensant qu'un changement de fournisseur ne concernera jamais le projet, jusqu'au jour où une hausse de tarif ou un changement de politique rend ce changement nécessaire.

Notre diagnostic IA qualifie ces critères avant toute recommandation d'hébergement, et débouche selon les cas sur un projet complet via nos méthodes de développement d'application ou sur un agent IA dimensionné à la sensibilité réelle des données traitées. Vous pouvez consulter des exemples de choix d'hébergement dans nos projets.

Une checklist avant de signer avec un hébergeur

Avant de signer un contrat d'hébergement pour un projet d'IA, une série de vérifications simples permet d'éviter la plupart des mauvaises surprises décrites plus haut. Avez-vous listé précisément les champs qui partent dans le prompt envoyé au modèle, au-delà des seules données stockées en base ? Savez-vous, pour ce fournisseur précis, dans quel pays se trouvent à la fois les serveurs de stockage et ceux qui exécutent le modèle ? Avez-vous identifié sous quel droit tombe l'entreprise qui exploite ces serveurs, indépendamment de leur emplacement géographique ? Avez-vous relu, dans le contrat et non sur la page marketing, la clause sur l'entraînement du modèle à partir de vos échanges ? Et enfin, votre architecture technique passe-t-elle par une couche d'abstraction qui permettrait de changer de fournisseur sans réécrire l'ensemble de l'application ?

Ces cinq vérifications ne remplacent pas un diagnostic complet, mais elles suffisent souvent à écarter les propositions les moins sérieuses avant même d'entrer dans une négociation contractuelle plus poussée. Un fournisseur qui répond clairement et par écrit à chacune de ces cinq questions mérite d'être considéré. Un fournisseur qui élude l'une d'elles, ou qui renvoie systématiquement vers une documentation générale plutôt que vers une réponse précise sur votre cas, mérite d'être interrogé plus longuement avant toute signature.

Sources

• CNIL, Transferts de données hors UE : le cadre général prévu par le RGPD
• CNIL, Chapitre V du RGPD : transferts vers des pays tiers
• CNIL, Adéquation des États-Unis : les premières questions-réponses
• ANSSI, Prestataires de services d'informatique en nuage (SecNumCloud)
• Assemblée nationale, question écrite sur le CLOUD Act et les données hébergées en Europe

Questions fréquentes

Mes données sont-elles automatiquement en sécurité si mon hébergeur est en France ?

Non. L'hébergement en France répond à une partie de la question, le droit applicable et la proximité, mais il faut aussi vérifier qui traite les données au moment de l'appel au modèle, et si ce traitement se fait ailleurs.

Un hyperscaler américain avec une région européenne respecte-t-il le RGPD ?

Une région européenne et des clauses contractuelles types permettent de respecter le RGPD pour le stockage et le traitement réalisés dans l'UE. La décision d'adéquation de 2023 encadre par ailleurs les transferts vers les États-Unis pour les entreprises adhérant au Data Privacy Framework. Les garanties varient selon le service utilisé, donc le contrat reste à vérifier.

Pourquoi un modèle ouvert hébergé localement change la question ?

Parce que les données ne quittent jamais l'infrastructure que vous contrôlez, ou celle d'un hébergeur que vous avez choisi précisément. La contrepartie est la maintenance de cette infrastructure, à assumer en interne ou via un partenaire.

À quelle étape du projet faut-il se poser ces questions ?

Dès le diagnostic, avant tout devis. Le choix d'hébergement découle de la sensibilité réelle des données traitées par le projet, pas l'inverse.