Lovable permet aux clients entreprise de traiter les requêtes d'IA en Europe

Lovable a lancé l'EU inference, un paramètre destiné aux clients corporate qui dirige les requêtes vers les modèles d'IA pris en charge sur des endpoints européens. Il s'applique dans deux cas : quand une équipe construit un produit dans Lovable, et quand l'application publiée fait appel à un modèle depuis ses fonctions d'IA. L'annonce date du 12 octobre 2026. Elle ne donne pas la liste précise des modèles, des pays ni des conditions.

Deux circuits par lesquels les données partent vers le modèle

Une plateforme de génération d'applications gère deux flux de données distincts. Le premier apparaît pendant le développement : prompts, fragments de code, descriptions de logique métier et fichiers importés sont envoyés au modèle. Le second naît à la publication. Si l'application embarque un assistant conversationnel, un classifieur de demandes ou une recherche dans des documents, la saisie de l'utilisateur transite aussi par le modèle, et il s'agit souvent de données clients.

Le second circuit est le plus sensible pour la conformité. Le développeur peut contrôler ce qu'il écrit dans un prompt lors de la construction. Il ne peut pas contrôler ce que saisissent des milliers d'utilisateurs finaux. Lovable affirme couvrir les deux circuits, et c'est ce qui distingue cette nouveauté d'un simple sélecteur de région pour le builder.

Pourquoi la question du lieu de traitement est devenue incontournable

Lovable est basée à Stockholm, et les clients européens constituent pour l'entreprise un marché naturel. Leurs questionnaires d'achat comportent depuis longtemps une ligne dédiée : où les données sont-elles traitées ? Stockage et traitement ne sont pourtant pas la même chose. Une base peut se trouver à Francfort pendant que la requête vers le modèle part vers un endpoint situé outre-Atlantique. Au regard du RGPD, un tel transfert exige une base juridique distincte, que les juristes et les équipes de sécurité doivent ensuite expliquer.

Les grands fournisseurs cloud de modèles proposent déjà des endpoints régionaux : le socle technique de ce routage existe donc. Lovable le rend accessible dans son propre produit, sans que l'équipe ait à assembler elle-même une couche intermédiaire de clés et de proxys.

Ce que l'on sait de l'annonce :

• Public : les équipes enterprise.
• Mécanisme : routage des requêtes vers des endpoints européens.
• Périmètre : le développement dans Lovable et les fonctions d'IA des applications publiées.
• Limite : uniquement les modèles pris en charge.
• Non précisé : la liste des modèles, les pays d'hébergement, les prix, les latences, les SLA.

Ce que l'annonce laisse dans l'ombre

Le mot « pris en charge » est le plus important de l'annonce. Chez les fournisseurs de modèles, les endpoints européens reçoivent souvent les nouvelles versions plus tard que les endpoints globaux. Une équipe qui active l'EU inference peut donc constater que certains modèles sont indisponibles ou en retard d'une version.

La question du comportement en cas de panne se pose aussi. Si l'endpoint européen est indisponible, la requête doit-elle échouer avec une erreur ou basculer vers une autre région ? Pour la conformité, seule la première option est correcte ; pour la disponibilité, la seconde est plus commode. L'annonce ne dit pas comment cela fonctionne.

Il faut aussi tenir compte de la journalisation et de la conservation. Le traitement régional ne répond pas, à lui seul, aux questions de savoir qui conserve les prompts, pendant combien de temps et quels sous-traitants ultérieurs interviennent.

Ce qu'il faut vérifier avant l'activation

Une équipe qui prévoit de basculer ses fonctions d'IA vers un traitement européen a intérêt à demander plusieurs éléments à Lovable :

• La liste à jour des modèles et des régions pour lesquels l'EU inference est disponible.
• La description du comportement en cas d'indisponibilité de l'endpoint européen.
• Les conditions de conservation et de journalisation des prompts et des réponses, ainsi que la liste des sous-traitants ultérieurs.
• L'accord de traitement des données (DPA) à jour, tenant compte de la nouvelle option.

Une fois l'option activée, mieux vaut vérifier le résultat en pratique. Il s'agit d'exécuter des requêtes de test depuis l'application publiée et de s'assurer, à l'aide de la documentation et des logs, que le trafic part bien vers la région voulue. Si le registre des traitements de données personnelles s'appuie sur cette fonction, il faut aussi le mettre à jour : une autorisation au niveau de la plateforme ne remplace pas la documentation interne.