Lovable réduit de 5 % les impasses grâce aux fichiers de connaissances et au RAG

Un agent d'IA libre semble plus puissant qu'un agent contrôlé : qu'il planifie lui-même, appelle des outils, crée des sous-tâches et travaille jusqu'à la victoire. Chez Lovable, on a testé cette idée sur un produit qui permet de créer des applications via un chat, et l'effet a été inverse. Les agents s'enfonçaient dans des terriers techniques, accumulaient les erreurs et ne parvenaient pas à terminer leur travail de façon prévisible.

L'équipe a temporairement supprimé presque tout le code agentique complexe. À la place d'une boucle ouverte, elle a conservé une séquence claire : requête de l'utilisateur, modifications des fichiers, vérification du résultat dans un aperçu en direct, puis requête suivante. L'autonomie a ensuite été réintroduite progressivement, avec une infrastructure qui permet de repérer rapidement une erreur et d'essayer en toute sécurité une autre voie.

D'abord, restreindre la tâche

Lovable s'est dès le départ concentrée sur les nouvelles applications et a choisi une stack technologique unique. L'utilisateur apporte une idée, le service crée le code et l'exécute dans un environnement connu à l'avance. C'est bien plus simple que de travailler avec n'importe quel dépôt existant, où l'on peut rencontrer des dépendances, des versions et des méthodes de build arbitraires.

Imaginons un agent chargé d'ajouter un formulaire de paiement. Dans un projet quelconque, il doit d'abord comprendre l'architecture, le gestionnaire de paquets, les règles de gestion des secrets et le schéma de déploiement. Dans une stack contrôlée, la plupart de ces décisions sont déjà prises. L'agent n'a plus qu'à résoudre la tâche concrète, et la plateforme sait comment vérifier le résultat.

La leçon pratique n'est pas que tout le monde ait besoin d'un seul framework. La règle la plus utile est ailleurs : la liberté de l'agent doit correspondre à la capacité du modèle à repérer et corriger ses propres erreurs. Si le modèle utilise encore les outils de manière instable, un processus court et contrôlé peut donner un meilleur produit qu'une autonomie en plusieurs étapes.

Les instructions se sont avérées plus utiles qu'un modèle affiné précocement

L'équipe s'attendait à affiner des modèles sur l'historique des sessions utilisateurs. En pratique, de simples fichiers texte ont fonctionné plus vite. Les ingénieurs étudiaient les applications cassées, identifiaient les causes récurrentes et consignaient de courtes règles. Par exemple : n'utiliser que les icônes réellement présentes dans la bibliothèque choisie et, en cas de doute, prendre une icône générique.

Avant chaque nouvelle génération, la recherche sélectionnait les règles pertinentes et les ajoutait au contexte du modèle. C'est en somme l'association désormais familière d'une base d'instructions et du RAG. Un échec analysé commençait à aider les utilisateurs suivants, sans nouveau cycle d'entraînement. Selon Lovable elle-même, une première version du système de recherche de problèmes et de solutions a réduit de 5 % la part des utilisateurs bloqués en cours de travail. Il s'agit d'une métrique interne à l'entreprise, on ne peut donc pas la considérer comme un résultat universel.

Pour une équipe produit, cette approche est aussi pratique sur le plan organisationnel. Une règle peut être lue, discutée, modifiée et rattachée à une erreur précise. Mais la base de connaissances demande de l'entretien : des instructions contradictoires ou obsolètes peuvent dégrader le résultat aussi facilement que de bonnes instructions l'améliorent.

La vitesse dépend de la vérification, pas seulement du modèle

Lovable maintient l'environnement du projet en marche, met à jour l'aperçu sans build de production complet et exécute des vérifications TypeScript incrémentales distinctes. L'erreur revient plus vite à l'agent, qui peut préparer une correction pendant que l'application continue de tourner. Plus tard, la plateforme a appris à sauvegarder l'état de l'environnement et à en créer des branches, avec les fichiers, les processus et la base de données.

C'est ici que se trouve l'enseignement le plus concret. Lors du développement d'un agent, mesurez non seulement la vitesse de la première réponse, mais le cycle entier : modification, vérification, détection de l'échec et correction. Commencez par un ensemble restreint d'actions, rassemblez les erreurs récurrentes dans des instructions vérifiables et n'ajoutez de l'autonomie que là où existent un signal rapide sur le résultat et un retour arrière sûr. Lovable n'a pas prouvé avoir trouvé l'architecture définitive. Mais son histoire montre bien pourquoi un agent fiable n'est pas un seul modèle puissant, mais un modèle au sein d'un système correctement borné et observable.