Lovable détaille ses règles de sécurité pour la finance : journaux d'audit sur 13 semaines et EU inference

Lovable, service de création d'applications métier par prompts, a publié un guide destiné aux directeurs marketing du secteur financier. L'idée est simple : un prototype de campagne peut désormais être assemblé en quelques heures, mais la validation par la conformité et la sécurité prend des semaines. Le document décrit où passe la frontière de responsabilité entre la plateforme et le client, quelles données il est interdit de charger dans Lovable et comment vérifier une application avant sa publication. Il s'agit d'un texte éditeur, mais il contient assez de précisions concrètes pour servir de base à une checklist interne.

Plateforme et application : deux niveaux de protection

Lovable répartit la sécurité en deux couches. La couche plateforme comprend le chiffrement, l'isolation des espaces de travail, l'identification d'entreprise, les journaux d'audit, ainsi que la détection, la prévention et le nettoyage des données personnelles (PII). Elle sert à l'équipe sécurité pour évaluer Lovable en tant que fournisseur. La couche application regroupe les contrôles automatiques de ce que l'utilisateur a lui-même construit : droits d'accès à la base de données non sécurisés, clés qui ont fuité, dépendances vulnérables, failles dans le code.

Avant de construire, l'entreprise propose de répondre à cinq questions : quelles données (publiques, internes, personnelles, investissement confidentielles), quelle est l'audience, que fait l'application (affiche, modifie des enregistrements, envoie des messages, formule des recommandations), quel est le coût d'une erreur, et qui possède l'application et peut la désactiver. Risque faible : un planificateur de campagnes interne sur données synthétiques, un prototype de page d'événement. Risque élevé : un portail investisseurs, du marketing personnalisé pour des fonds, une intégration avec un CRM, des outils manipulant des évaluations non publiées. Le guide souligne à part que « interne » ne signifie pas « sûr » si l'application contient des informations non publiques importantes (MNPI).

La limite essentielle est la section 3.8 de l'accord de traitement des données (DPA) pour Business et Enterprise. Elle interdit de transmettre des données sensibles : numéros de comptes financiers, identifiants délivrés par l'État, données biométriques, informations médicales protégées. Ni le contrôle d'accès ni EU inference ne lèvent cette interdiction.

Connecteurs, données et géographie du traitement

Les connecteurs constituent la partie la plus délicate. Il en existe quatre types, et le choix détermine qui voit les données :

• Chat connector : contexte personnel pendant la construction (par exemple, un brief depuis Google Drive). Il n'arrive pas dans l'application publiée, mais les collègues peuvent voir les données d'un projet partagé.
• App + chat connector : un seul compte partagé pour la construction et pour le fonctionnement de l'application ; les utilisateurs voient les données dans la limite des droits de ce compte.
• App user connector : chacun travaille avec son propre compte ; par exemple, un gestionnaire ne voit que ses propres comptes.
• Custom connectors et MCP : le comportement dépend du type de connexion choisi.

Mise en garde supplémentaire : si l'application copie des enregistrements dans sa propre base, les droits du système source ne suivent pas ces copies. L'accès aux copies stockées doit être décrit et testé à nouveau. Selon le document, les droits doivent être appliqués côté backend ou dans la base de données, et non en masquant des boutons et des pages.

Concernant l'entraînement des modèles : le contenu des clients Business et Enterprise (prompts, fichiers, code, résultats) est exclu de l'entraînement par défaut. Sur Free et Pro, les données peuvent être utilisées tant que l'utilisateur ne s'y oppose pas. EU inference est disponible sur Enterprise et dirige les requêtes vers des modèles sur des points de terminaison européens ; s'il n'y en a aucun d'adapté, la requête se termine par une erreur au lieu d'être envoyée dans une autre région.

Les réserves sont importantes : les périmètres des fournisseurs diffèrent, une partie des fonctions est indisponible, certains outils agentiques traitent malgré tout les données aux États-Unis, et ce réglage ne modifie pas le lieu de stockage des données de l'application. La région du backend Lovable Cloud se choisit séparément.

Logs, offres et checklist avant publication

Les journaux d'audit Enterprise enregistrent les modifications des membres, des rôles, des paramètres, des connexions et des publications : qui, quand, quoi et sur quelle ressource. Ils sont conservés 13 semaines, soit environ 90 jours ; au-delà, il faut les exporter. Les actions à l'intérieur de l'application elle-même, comme le téléchargement d'un document par un investisseur ou la validation d'un envoi, n'apparaissent pas dans ces logs : le développeur doit prévoir lui-même ces événements.

Côté offres : Pro offre des domaines personnalisés et des design systems ; Business ajoute le SSO, l'accès par rôles, des modèles de design et l'absence d'entraînement sur les données par défaut ; Enterprise apporte les journaux d'audit, SCIM et des analyses de sécurité planifiées. La consommation de crédits doit être budgétée à la fois pour la construction et pour l'exploitation : le backend, l'IA et une partie des connecteurs en consomment aussi.

L'ordre d'action pratique pour une équipe se présente ainsi. Commencez par classer le projet selon les cinq questions et comparez les données au DPA. Construisez sur des données synthétiques.

Pour une application destinée à cinq personnes, choisissez l'audience personnalisée sur Business et Enterprise, ou Invite only sur Free et Pro. Vérifiez les deux extrémités : une personne extérieure ne doit pas pouvoir ouvrir le dashboard, et un invité ne doit voir que ses propres enregistrements. Pour les actions à conséquences, ajoutez une étape de confirmation.

Conservez les secrets uniquement dans le stockage Secrets, jamais dans le frontend. Corrigez les vulnérabilités détectées par le scanner, testez avec différents comptes et désignez un propriétaire capable de désactiver l'application. La plateforme fournit les outils, mais la responsabilité des données et des droits reste la vôtre.