Ship Fast, Stay Safe : un prototypage IA qui survit en production

De la démo vibe-coded à la production — la discipline au milieu. Basé sur le webinaire Supabase avec Zimo (Brthrs Agency), Harry (Imaginary Space) et Victor (Performanze).

Il y a un gif avec lequel Zimo de Brthrs Agency a ouvert sa démo. Un train, roulant à pleine vitesse — mais pas sur des rails. Juste traversant le terrain ouvert, fonctionnel et chaotique. C'est à quoi ressemblent la plupart des prototypes vibe-coded après six semaines en production.

La vague des builds IA est réelle. Des délais qui signifiaient autrefois six mois et une vraie équipe d'ingénierie signifient maintenant un après-midi et un compte Lovable. Ce n'est pas du hype — c'est la réalité opérationnelle pour les agences, fondateurs et CTOs de ce webinaire. Mais la vitesse sans architecture n'est que de la dette qui s'accumule silencieusement jusqu'à ce que quelque chose casse devant un client.

Le même motif apparaît dans le service client alimenté par IA. Déployer Fin ou n'importe quel agent IA sur une base de connaissances fragmentée produit le même résultat — démarrage rapide, plateau précoce, frustration croissante. Les outils sont différents. Le mode d'échec est identique.

Voici ce que font différemment les gens qui livrent réellement des systèmes IA en production.

La règle 80/20 dont personne ne parle

Le cadre de Zimo était direct : « Je passe 80 % de mon temps à planifier. Les 20 % restants à implémenter. »

C'est l'inverse de la manière dont la plupart des fondateurs abordent les outils IA. Ils ouvrent Lovable, tapent une demande de fonctionnalité, et acceptent le résultat. Le résultat est ce qu'il appelle « l'intelligence moyenne » — le modèle fait du pattern-matching contre ses données d'entraînement et vous donne la version la plus générique de ce que vous avez demandé.

L'accélérateur est l'ingénierie de contexte, pas l'art du prompting. La distinction compte. Le prompting, c'est la formulation. L'ingénierie de contexte, c'est charger l'IA avec le bon environnement — intention utilisateur, documentation technique, contraintes métier — avant qu'elle touche une seule ligne de code.

Son workflow spécifique : extraire la documentation Supabase pertinente avant la planification, faire rechercher au modèle la bonne approche d'implémentation, générer un plan structuré, puis faire une deuxième passe en disant « vous êtes un ingénieur junior chargé d'implémenter ce plan — revoyez la documentation et rapportez chaque question que vous avez. » Cette boucle attrape les problèmes architecturaux avant qu'ils ne deviennent des problèmes de production.

L'insight clé : la documentation est du contexte. La doc Supabase est lisible par des humains, mais aussi par des IA. L'alimenter dans la phase de planification signifie que le résultat reflète les vraies meilleures pratiques, pas des moyennes statistiques.

« Lent c'est fluide, fluide c'est rapide. Ça prend longtemps de réfléchir à ce qu'on veut vraiment construire — mais si on donne tout ça comme contexte à l'IA, on peut aller très vite en implémentation. »

Lovable en a depuis fait le défaut. Le Plan Mode (février 2026) vous montre un plan de construction structuré avant que le moindre code ne soit généré. Le Chat Mode (juin 2026) va plus loin — vous démarrez chaque nouveau projet dans une conversation de planification, et Lovable pose des questions clarificatrices sur votre audience cible, vos fonctionnalités et vos contraintes techniques avant de toucher une ligne de code. Les erreurs d'IA qui coûtent le plus de crédits remontent presque toujours à un prompt vague. L'outil vous incite maintenant à corriger ça dès le départ.

Les projets qui bloquent sont presque toujours ceux qui ont sauté l'étape de planification. Lovable a maintenant intégré cette friction par design.

La sécurité n'est pas un problème pour plus tard

Chaque panelist y est revenu indépendamment : le travail de sécurité fait après le lancement est dix fois plus difficile que la sécurité intégrée dans le plan.

Nous avons maintenant une étude de cas documentée de ce qui arrive quand ce n'est pas le cas. Le CVE-2025-48757, divulgué mi-2025, a exposé plus de 170 apps Lovable en production en raison de politiques RLS manquantes. La clé anonyme Supabase est intégrée dans le JavaScript côté client par design — sans RLS, quiconque ouvre les outils de développement du navigateur peut interroger votre base de données entière directement. Emails, enregistrements de paiement, clés API, données personnelles — tout accessible sans authentification. Une évaluation Q1 2026 de plus de 200 apps vibe-coded a trouvé que 91,5 % contenaient au moins une vulnérabilité traçable au code généré par IA. « Le S de vibe coding, c'est security » est devenu la blague sur chaque forum de développeurs. L'incident n'est pas un argument contre l'utilisation de Lovable — c'est un argument pour traiter la checklist de sécurité comme non négociable avant qu'une app ne touche de vrais utilisateurs.

L'OWASP Top 10 reste la référence de base. Avant les outils IA, 80 % des applications livraient une forme de vulnérabilité de contrôle d'accès basé sur les rôles. Ce chiffre ne s'est pas amélioré avec l'IA — il est devenu plus difficile à repérer parce que le code a l'air correct jusqu'à ce qu'on l'interroge de manière adversariale.

Trois choses revenaient constamment :

Les politiques RLS sont votre dernière ligne de défense. La Row Level Security de Supabase n'est pas un nice-to-have — c'est le mécanisme qui empêche votre agent IA de retourner accidentellement des données client auxquelles il ne devrait pas avoir accès. Lovable configure des politiques RLS de base automatiquement, mais vous devez les réviser et les resserrer avant la mise en ligne. C'est bien plus facile de changer les politiques avant que de vraies données n'existent.

Ne stockez jamais de secrets dans le code frontend. Celui-ci est basique mais attrape plus de projets vibe-coded que n'importe quel autre problème. Clés API, secrets Stripe, tout ce qui est sensible — ça appartient aux fonctions serveur, pas à vos composants React où n'importe quel inspecteur de navigateur peut le lire. Les secrets dans le code frontend doivent être considérés comme compromis.

L'injection de prompt est un vecteur d'attaque spécifique à l'IA que la plupart des gens manquent. Si vous construisez un chatbot ou une interface IA — que ce soit dans une app Lovable ou un déploiement Fin — essayez activement de le casser. Trouvez des listes de prompts adversariaux, collez-les dedans, et observez ce que votre IA retourne. La question n'est pas seulement si votre base de données est sécurisée — c'est si votre IA peut être manipulée pour extraire des données ou prendre des actions qu'elle ne devrait pas.

« Ce n'est pas que le vibe coding est intrinsèquement peu sûr. C'est d'avoir le réflexe de se souvenir de vérifier — et pas juste de vibe coder et d'oublier la sécurité. »

Les revues de sécurité assistées par IA sont maintenant assez accessibles pour qu'il n'y ait aucune excuse de les sauter. Lovable lance maintenant un scan de sécurité de base automatiquement à chaque publication — couvrant les politiques RLS, les configs de base de données et les mauvaises configurations connues en environ 10–15 secondes. Un scan approfondi est disponible sur demande, analysant votre codebase entière en environ 3 minutes. Les admins d'espace de travail sur les plans Business et Enterprise peuvent bloquer la publication sur les découvertes critiques. Le Security Advisor de Supabase remonte les problèmes au niveau base de données directement dans le dashboard. Aucun de ces outils ne remplace le pentest pour des systèmes de production sérieux — mais ils ont considérablement relevé le plancher depuis le CVE.

Le basculement selfware

Le cadre de Victor chez Performanze a introduit un concept qui mérite qu'on s'y arrête : le selfware — du logiciel construit autour des workflows, données et opérations propres à une entreprise, au lieu d'être adapté à partir d'un SaaS générique.

Le pitch pour les clients est simple. Vous utilisez un menu dans Salesforce. Vous payez pour le produit complet, verrouillés dans leur roadmap, exclus des fonctionnalités qu'ils réservent aux niveaux enterprise. Avec l'environnement de build IA actuel, il existe une alternative viable : posséder votre stack, posséder vos données, posséder la roadmap.

L'objection s'écrit d'elle-même — vous ne pouvez pas remplacer Salesforce. Victor est d'accord. Ce n'est pas la prétention. La prétention est que pour un nombre croissant de workflows, le rapport coût-bénéfice a changé. Vous n'achetez pas un concurrent de Salesforce. Vous achetez un outil qui fait exactement ce que fait votre entreprise, avec vos données dans Supabase, extensible à votre rythme.

Son exemple : une plateforme de ressources humaines avec des évaluations IA configurables, construite comme une alternative complète à un copilote d'entreprise générique, avec le contexte SharePoint et Outlook intégré. Les données du client restent dans des tables PostgreSQL qu'il contrôle. Les fonctionnalités livrent en quelques semaines. Pas d'escalade de licence.

Le choix d'infrastructure est central à ce modèle. Tout consolidé dans Supabase — données structurées dans PostgreSQL, embeddings dans le vector store, fichiers dans des buckets de stockage, auth prête à l'emploi. La consolidation n'est pas une préférence esthétique. C'est ce qui fait que les requêtes text-to-SQL et la récupération RAG fonctionnent réellement de manière cohérente.

« L'IA est un miroir de nous-mêmes. Si vous injectez un bon contexte, vous aurez de bons résultats. Si vous injectez un mauvais contexte, elle aura tendance à faire la moyenne — ou en dessous. »

La même logique s'applique aux agents IA dans le service client. Le taux de résolution de Fin n'est pas déterminé par la manière dont vous le configurez le jour un — il est déterminé par la qualité et la structure de la base de connaissances sous-jacente. L'architecture du contenu doit toujours venir avant la configuration de l'IA.

Ce qui change quand on construit pour de vrais utilisateurs

L'écart de production est surtout invisible jusqu'à ce qu'il ne le soit plus. Quelques modes d'échec spécifiques qui sont revenus :

Dégradation de la fenêtre de contexte. Au fil des conversations, la qualité des instructions du modèle baisse. C'est pourquoi l'équipe de Victor n'utilise pas le même modèle pour chaque tâche — les tâches de planification complexes reçoivent Opus, les opérations plus simples des modèles plus petits et moins chers. Connaître les limites de votre fenêtre de contexte est une pensée infrastructurelle de base que la plupart des vibe-coders sautent complètement.

Dérive des attentes à l'échelle. Un prototype qui performe bien pour un utilisateur se comporte différemment avec des centaines de requêtes concurrentes frappant une base de données mal indexée. L'advisor de performance de Supabase remonte ces problèmes avant le lancement. La plupart des gens ne le consultent pas.

Le problème de visibilité. Harry l'a bien dit : « Les clients voient un progrès visible rapide au début. Quand on passe au travail de sécurité backend, ils cessent de voir des résultats. Ils pensent que vous avez ralenti. » Être explicite sur ce qu'implique le travail non visible — et pourquoi il est non négociable — fait partie de la livraison.

Le principe sous tout ça

Le temps de build s'est compressé. Les exigences architecturales ne l'ont pas été. Les équipes qui gagnent en ce moment sont celles qui traitent l'IA comme un multiplicateur de force sur une réflexion soignée, pas comme un remplacement de celle-ci.

C'est le même principe qui façonne les deux côtés de ce que nous faisons chez dot2.solutions. Quand nous construisons des apps de production avec Lovable, la phase de planification — modèle de données, types d'utilisateurs, contraintes d'intégration, posture de sécurité — vient avant le premier prompt. Quand nous déployons Fin pour des équipes de service client, l'architecture des connaissances vient avant la configuration de l'IA. Un projet Lovable sans un modèle de données cohérent bloque de la même manière qu'un déploiement Fin sans une base de connaissances structurée. Il vaut aussi noter que depuis mai 2026, les nouveaux projets Lovable passent par défaut à TanStack Start avec SSR — la même stack que ce site, et le bon fondement pour tout ce qui doit être crawlable, rapide et prêt pour la production dès le premier jour.

Le contenu avant la configuration. L'architecture avant le code. Les outils ont changé radicalement. Cette partie, non.

Lecture connexe : le réality check SEO de Lovable, Intercom Fin vs chatbots IA personnalisés, et travailler avec un consultant Intercom en Suisse.