Lovable a lancé les « App user connectors » : chaque personne qui utilise ton app publiée connecte son propre compte tiers (Google, Microsoft, Slack, Salesforce, HubSpot, Linear, Databricks, Snowflake), de sorte que l'app agit en son nom, avec ses permissions et uniquement avec ses données — au lieu d'un unique compte partagé.
Imagine que tu montes en une après-midi un assistant e-mail dopé à l'IA, tu le montres à un ami, ça marche à merveille... et soudain dix autres personnes veulent l'utiliser. C'est là qu'arrive le moment gênant : tout le monde va lire TA boîte de réception ? Parce que si ton app connecte un seul compte Google, c'est exactement ce qui se passe — un puits commun où les données de tout le monde se mélangent aux tiennes. C'est le mur invisible contre lequel se heurte presque tous ceux qui construisent des apps avec l'IA dès qu'ils veulent passer de « ça marche pour moi » à « des vraies gens l'utilisent ». Et c'est précisément ce mur que Lovable vient de faire tomber avec son nouveau lancement : les App user connectors.
Ce qui change exactement
L'idée est aussi simple à énoncer que difficile à bien construire : chaque personne qui utilise ton app publiée connecte son propre compte tiers, et l'app agit en son nom, avec ses permissions et uniquement avec ses données. Toi, en tant que créateur, tu configures le client une seule fois au niveau du workspace ; mais quand un nouvel utilisateur arrive pour la première fois, il s'authentifie séparément avec SON compte. À partir de là, l'app ne voit que ce que cet utilisateur a le droit de voir : sa boîte mail, son agenda, ses enregistrements dans le CRM. Rien ne se croise. C'est la différence entre une maison dotée d'une clé unique qui ouvre toutes les portes et un immeuble où chaque locataire a la sienne.
La liste des connecteurs n'a rien d'anodin
Les fournisseurs qui inaugurent la prise en charge racontent à eux seuls une histoire : Google, Microsoft, Slack, Salesforce, HubSpot, Linear, Databricks et Snowflake. Remarque que ce n'est pas une collection de jouets — ce sont les systèmes où vit le travail sérieux des entreprises : e-mail et agenda, messagerie d'équipe, les deux CRM qui se partagent le monde, et même deux plateformes de données lourdes comme Databricks et Snowflake. Quand un app-builder mainstream câble précisément ces huit-là, il dit haut et fort que les apps faites avec l'IA ne sont plus des prototypes du week-end : on s'attend à ce qu'elles touchent des données réelles de vrais clients, et c'est pour ça qu'elles doivent isoler chaque utilisateur comme le ferait n'importe quel SaaS payant.
Pourquoi c'est plus difficile qu'il n'y paraît
Le détail que presque personne ne voit jusqu'à ce qu'il lui explose au visage, c'est la sécurité du stockage de ces connexions. Multiplier une app par des centaines d'utilisateurs, ça veut dire garder des centaines de tokens d'accès, chacun étant une clé vers la vie numérique de quelqu'un. S'ils sont mal stockés, une faille ne fuit pas une donnée : elle fait fuiter l'e-mail ou le CRM de tous tes utilisateurs d'un coup. C'est pourquoi le pattern correct exige un coffre chiffré par utilisateur, un mécanisme qui reconnaît dans quel état se trouve chaque connexion (connectée, expirée, révoquée, non liée) et une manière propre de reconnecter quand un token expire. Que Lovable l'empaquette et le standardise relève la barre pour tout le secteur : ce qui était hier un luxe d'ingénierie devient l'attente minimale.
Ce que ça signifie pour qui construit avec l'IA dans NeuralOS
La leçon de fond dépasse un outil précis : une app cesse d'être un jouet le jour où elle peut donner à chaque utilisateur son propre espace isolé, avec ses propres clés. Et soyons honnêtes, sans esbroufe — c'est exactement le pattern qui vit déjà dans NeuralOS au cœur du moteur des Intégrations : vault chiffré par-tenant, multi-compte, et un résolveur d'état de lien qui sait si une connexion est vivante, expirée ou s'il faut la reconnecter, avec son flux d'ajout-de-compte et de reconnexion. Qu'un app-builder de premier plan sorte justement pour standardiser ce pattern confirme une seule chose : quand toute l'industrie pousse vers l'isolement par utilisateur, la bonne question n'est plus de savoir si c'est nécessaire, mais à quel point tu l'as bien résolu.