Migration de Bubble vers le code : Quand, Pourquoi et Combien ça coûte

Un guide pour les équipes quittant Bubble, conçu autour de Claude Code et Codex. Ce guide s’adresse aux fondateurs et PDG qui ont bâti une entreprise sur Bubble et commencent à ressentir les lacunes de la plateforme.

TLDR

La migration est une décision commerciale avant d’être une décision technique. Une véritable application Bubble, avec des clients payants et des workflows, prend quelques mois à reconstruire correctement. Les équipes qui ont effectué cette transition estiment qu’il faut de trois à cinq mois par application, et elles ne gonflent pas l’estimation.

En termes de budget, la plupart des équipes se situent entre 15 000 $ et 25 000 $ pour une refonte complète, selon les fonctionnalités et la complexité des données. Si vous préférez le faire vous-même, cela coûte du temps à votre équipe plutôt que de l’argent.

L’avantage de la migration est que vous possédez le code, l’application devient plus rapide, et vous devenez finançable et acquérable d’une manière qu’une application Bubble ne l’est jamais tout à fait. Ce que vous assumez, ce sont les choses que Bubble faisait discrètement pour vous, comme les correctifs de sécurité, les sauvegardes et la disponibilité, qui sont désormais de votre ressort.

Mais avec Claude Code et Codex, une équipe beaucoup plus petite peut reconstruire ce qui prenait auparavant six mois à une équipe complète.

Devez-vous migrer de Bubble vers du code personnalisé ?

Bubble est bon dans beaucoup de choses. Il peut concrétiser votre idée auprès d’utilisateurs payants sans équipe de développement, mais il y a un plafond, et des signes indiquent que vous l’avez atteint.

• Les performances de l’application diminuent à mesure que le nombre d’utilisateurs augmente
• De petits changements peuvent casser des choses que vous n’avez pas touchées
• Vous avez besoin de quelque chose que Bubble ne peut pas faire, comme un traitement en arrière-plan intensif
• Votre équipe passe un tiers à la moitié de son temps à corriger des bugs au lieu d’améliorer les choses
• Les coûts des unités de travail augmentent, et l’augmentation de l’utilisation aggrave la situation au lieu de l’améliorer

Mais l’erreur que les gens commettent ici est de traiter la migration comme un tout ou rien. Ce n’est pas le cas.

Vous avez plusieurs options avant de reconstruire complètement votre application Bubble. Vous pouvez reconstruire uniquement la partie qui est réellement défectueuse, et laisser le reste sur Bubble.

L’un de nos clients avait une application Bubble bien gérée qui nécessitait un service WebSocket pour gérer une flotte de réfrigérateurs connectés. Nous n’avons pas recommandé une migration complète.

Un composant backend personnalisé qui connectait le matériel à l’application existante était tout ce dont ils avaient besoin. Tout le reste est resté dans Bubble.

C’est le genre de décision qui vaut la peine d’être prise avant de commencer à migrer votre application Bubble. Nous aidons les équipes avec un audit de migration avant de s’engager dans une refonte. Si vous évaluez si un agent correspond à votre processus avant de décider d’une migration, commencez par comprendre ce qu’est réellement un agent IA.

S’il y a une chose que Bubble ne peut pas faire, vous pouvez toujours construire cette fonctionnalité avec du code et utiliser Bubble pour tout le reste.

Si les performances et les coûts posent problème, mais que l’application fonctionne, planifiez une refonte complète par phases.

Si vous avez atteint le plafond partout, comme pour la levée de fonds, ou si vous voulez posséder le code source, planifiez une migration complète.

Cependant, si vous êtes toujours en phase de recherche de product-market fit ou si l’application change chaque semaine, restez sur Bubble. Migrer maintenant est prématuré.

Ce que le code personnalisé vous offre et que Bubble ne peut pas

Une erreur courante est de présenter le déménagement comme un moyen de fuir les problèmes de Bubble. C’est correct, mais incomplet.

Fonctionnalités en temps réel (WebSockets)

Vous pouvez créer des tableaux de bord en direct, de l’édition collaborative et des notifications instantanées. Les utilisateurs voient les mises à jour immédiatement sans rafraîchir la page, ce qui rend l’application réactive et moderne.

Accès direct aux modèles AI/ML

Vous pouvez intégrer des modèles d’IA directement dans votre produit au lieu de dépendre de plugins tiers restrictifs. Cela vous donne un contrôle total sur le choix du modèle, les performances, les capacités et les coûts.

Véritables applications mobiles natives

Créez de véritables applications iOS et Android avec des performances natives, des intégrations d’appareils et une expérience utilisateur soignée, plutôt que de créer une application web encapsulée.

Traitement en arrière-plan

Vous pouvez exécuter des tâches longues et gourmandes en calcul de manière fiable en arrière-plan sans être contraint par les quotas d’utilisation.

Optimisation des performances en moins d’une seconde

Vous pouvez optimiser les requêtes de base de données, la mise en cache et l’architecture de l’application pour améliorer l’expérience utilisateur.

Contrôle total de l’infrastructure

Choisissez votre fournisseur de cloud, votre stratégie de déploiement et votre approche de mise à l’échelle tout en respectant vos exigences en matière de sécurité, de conformité et de coûts.

Pas de tarification par action

Maintenez des coûts prévisibles en payant pour l’infrastructure que vous utilisez plutôt que d’être facturé pour chaque exécution de workflow ou action utilisateur.

Comment la même chose est faite dans Bubble vs dans le code

Ajout de tables et de champs

Bubble : Créez un type de données dans l’onglet Data et ajoutez des champs.

Code : Définissez un schéma de base de données, et un agent IA génère la migration.

Recherche ou interrogation de données

Bubble : Utilisez “Do a search for” avec des contraintes.

Code : Écrivez une requête en utilisant SQL ou un ORM, l’agent IA générant la majeure partie de l’implémentation.

Règles métier et workflows

Bubble : Construisez des workflows en faisant glisser des actions sur le canevas de workflow.

Code : Définissez des fonctions qui s’exécutent en réponse à des événements, l’agent IA implémentant la logique.

Logique conditionnelle

Bubble : Ajoutez des conditions “Only when” aux actions.

Code : Utilisez des instructions if standard et d’autres constructions de programmation.

Authentification utilisateur

Bubble : L’authentification est intégrée et fonctionne immédiatement.

Code : Choisissez un fournisseur d’authentification et intégrez-le à votre application.

Téléchargement de fichiers

Bubble : Les fichiers sont téléchargés et stockés automatiquement.

Code : Configurez le stockage d’objets et implémentez vous-même le flux de téléchargement.

Intégration d’API tierces

Bubble : Connectez des API à l’aide de l’API Connector sans écrire de code.

Code : Effectuez des appels d’API directs, vous donnant un contrôle complet sur les requêtes, l’authentification et la gestion des erreurs.

Envoi d’e-mails

Bubble : Utilisez une action intégrée ou un plugin.

Code : Intégrez un service d’e-mail et configurez les paramètres de délivrabilité tels que SPF et DKIM.

Tâches planifiées

Bubble : Utilisez “Schedule API Workflow”.

Code : Exécutez des tâches planifiées avec des tâches cron ou des workers en arrière-plan.

Contrôle d’accès

Bubble : Configurez les règles de confidentialité (Privacy Rules).

Code : Implémentez la sécurité au niveau des lignes et l’autorisation côté serveur.

Déploiement des modifications

Bubble : Cliquez sur Preview ou Deploy.

Code : Commitez les modifications sur Git, laissez CI exécuter les tests et déployez via un pipeline de publication.

Débogage

Bubble : Parcourez les workflows à l’aide du débogueur.

Code : Inspectez les logs, exécutez des tests automatisés et reproduisez les problèmes localement.

Contrôle de version

Bubble : Fiez-vous aux points de sauvegarde et à l’historique des versions de Bubble.

Code : Utilisez Git pour un historique de version complet, le branching, les revues de code et des retours en arrière fiables.

Où les migrations Bubble échouent

Presque toutes les erreurs coûteuses lors d’une migration Bubble proviennent d’un changement de mentalité nécessaire.

Les workflows visuels deviennent du code

Dans Bubble, vous faisiez glisser des étapes de workflow. Dans le code, la logique réside dans des fonctions qui s’exécutent lorsque quelque chose se produit : un utilisateur clique, une API est déclenchée ou un minuteur se déclenche.

La logique est la même. Le “où est-ce que je le vois” est complètement différent, et c’est la première chose qui déroute les gens.

Votre base de données Bubble devient une vraie base de données

Les types de données de Bubble deviennent des tables. Les champs deviennent des colonnes.

Vous devez maintenant créer des règles. Un champ censé contenir un nombre rejettera du texte. Bubble était facile. Postgres ne l’est pas, et la rigueur est à la fois une fonctionnalité et, pendant la migration, une zone où de nombreuses erreurs se produisent.

Les règles de confidentialité (Privacy Rules) deviennent quelque chose que vous devez construire

Dans Bubble, les règles de confidentialité décidaient qui pouvait voir quoi. Dans le code personnalisé, rien n’est protégé tant que vous n’avez pas écrit la protection. L’état par défaut d’une nouvelle application est ouvert. Chaque règle que vous aviez dans Bubble doit être reconstruite. Si vous l’ignorez, vous risquez une violation de données.

Vous avez besoin de services différents pour le frontend et le backend

Bubble regroupait le frontend, le backend, la base de données et l’hébergement dans un seul éditeur. Avec le code personnalisé, ce sont des services distincts. Cela semble signifier plus de gestion, et c’est le cas, mais c’est aussi exactement ce qui permet à deux agents IA de travailler simultanément sur différentes parties.

Les plugins deviennent des packages et des API

Le plugin Bubble que vous avez installé en un clic devient une bibliothèque ou une API que vous appelez directement. Cela signifie plus de contrôle et plus de fiabilité, mais une configuration légèrement plus complexe.

Préparation à la migration de votre application Bubble

Il n’y a pas de bouton “migration d’application en un clic” dans Bubble. Vous ne pouvez pas exporter votre HTML ou vos workflows. Ce que vous pouvez exporter, ce sont vos données, et même cela présente des défis.

L’onglet Data vous permet de télécharger chaque type de données au format CSV. Parce que vous avez un accès éditeur, cela contourne les règles de confidentialité, vous voyez donc tout.

L’API Data renvoie 100 enregistrements par requête, ce qui signifie que vous avez besoin d’une pagination basée sur un curseur pour tout récupérer.

Ensuite, il y a le problème des fichiers et des images. Lorsque vous exportez un CSV, vos fichiers et images n’y sont pas. Ce qu’il contient, ce sont les URL pointant vers l’endroit où Bubble héberge ces fichiers. Si vous migrez sans transférer vos fichiers, ces URL deviendront inactives et les actifs disparaîtront.

Les workflows et l’interface utilisateur doivent être créés à partir de zéro car aucune de vos logiques n’est exportée. Quelqu’un doit écrire ce que fait chaque workflow.

C’est fastidieux, et une grande partie de votre temps sera consacrée à cela. Mais le document que vous produisez est votre spécification. C’est exactement ce à partir de quoi les agents IA construiront.

Et auditez vos règles de confidentialité maintenant, avant de perdre l’accès à celles-ci. Notez chacune d’elles car elles définissent l’ensemble de votre modèle d’autorisation. Si elles sont incomplètes, votre nouvelle application manquera de règles de sécurité que vous ne saviez pas que vous aviez.

Hébergement de médias et de fichiers

Chaque fois qu’un utilisateur téléchargeait une photo de profil ou un PDF sur votre application Bubble, Bubble la stockait sur AWS et renvoyait une URL. Dans le code personnalisé, vous choisissez S3 ou Cloudflare R2, et devez créer le pipeline pour cela.

La migration elle-même a un ordre d’opérations spécifique, et se tromper entraînera une perte de données permanente.

Tout d’abord, exportez vos données, en vous rappelant que vous obtenez des URL, pas des fichiers. Ensuite, exécutez un script qui télécharge chaque fichier de chaque URL avant que l’hébergement Bubble ne disparaisse. Ensuite, téléchargez tout vers votre nouveau stockage. Et enfin, réécrivez chaque URL stockée dans votre base de données pour qu’elle pointe vers le nouvel emplacement.

1. 1 Exporter les données (URLs, pas fichiers) →
2. 2 Télécharger chaque fichier →
3. 3 Re-uploader vers le nouveau stockage →
4. 4 Réécrire les URLs stockées

Certaines URL Bubble sont signées et expirent, vous devez donc décider quels fichiers sont publics et quels sont privés. Et Bubble utilisait un CDN pour servir les fichiers rapidement dans le monde entier, tout en appliquant des règles de taille de fichier et d’accès. Tout cela est maintenant à vous de configurer.

Rien de tout cela n’est difficile isolément. Le problème est de ne pas savoir que cela existait avant qu’un utilisateur ne signale que ses fichiers ont disparu.

Nettoyage des données

Quelqu’un qui n’a jamais migré une application auparavant ne considérera pas cela comme un défi majeur.

La base de données de Bubble est simple. Les champs peuvent être vides alors qu’ils ne devraient pas l’être. Un champ peut contenir un nombre pour 9 000 enregistrements et du texte pour les 12 autres. Les relations entre les éléments sont stockées par référence et se désynchronisent au fil des années d’utilisation réelle. Rien de tout cela n’a causé de problèmes évidents dans Bubble, car Bubble n’imposait pas de rigueur.

Ensuite, vous passez à Supabase ou Xano, et l’importation échoue. Parce que vos données violent les règles.

Valeurs nulles là où une valeur est requise. Références orphelines pointant vers des enregistrements supprimés. E-mails en double dans un champ censé être unique. Dates stockées dans trois formats différents.

Vos Option sets sont exportés sous forme d’ID ou de texte d’affichage, et non de clés étrangères, ce qui rend difficile de les lier aux données relationnelles appropriées.

Bubble exportera les “choses” liées sous forme d’ID de référence, et non sous forme de relations lisibles que vous voyez dans l’éditeur, et la reconstruction de la façon dont tout se connecte demande beaucoup de travail.

Le temps que vous passerez à nettoyer, dédupliquer et réconcilier les données Bubble exportées dépassera toujours le temps passé à écrire l’importation elle-même.

Gestion de l’authentification utilisateur et migration des comptes

Bubble ne vous permettra pas d’exporter les hachages de mots de passe de vos utilisateurs. C’est une bonne chose que ceux-ci soient difficiles à extraire. Mais cela signifie que vous ne pouvez pas simplement déplacer les mots de passe de vos utilisateurs vers un nouveau système et faire en sorte que tout le monde se connecte comme si rien n’avait changé.

La première solution est une réinitialisation forcée du mot de passe. Tout le monde migre en même temps. Lors du basculement, chaque utilisateur doit réinitialiser son mot de passe, et vous lui envoyez un lien de réinitialisation par e-mail. L’avantage est un basculement propre, simple et tout-en-un. Pour les entreprises que nous avons aidées à migrer, nous choisissons une période de faible trafic, comme un week-end.

La seconde est la migration progressive. Vous conservez le nouveau système d’authentification à côté de l’ancien. La première fois que chaque utilisateur se connecte après le basculement, le nouveau système vérifie ses identifiants par rapport à l’ancien système Bubble une fois, puis stocke le mot de passe. À partir de ce moment, ils sont entièrement migrés.

Pour la plupart des applications avec moins de quelques milliers d’utilisateurs, une réinitialisation forcée est plus simple et vaut la petite friction. Utilisez l’approche progressive lorsqu’une réinitialisation forcée vous coûterait des utilisateurs ou lorsque les temps d’arrêt sont coûteux.

Au-delà des mots de passe, vous devez toujours migrer tout le reste concernant vos utilisateurs. Profils, rôles, permissions, tout cela se déplace en tant que données.

Quelques autres choses à prévoir : toutes les sessions actives sont invalidées lors du basculement, donc tout le monde est déconnecté une fois ; les connexions sociales comme Google doivent être re-liées ; et toute configuration multi-facteurs doit être ré-enregistrée.

Vous pouvez choisir entre un fournisseur d’authentification géré comme Auth0 ou Clerk qui gère les parties difficiles moyennant des frais, ou une bibliothèque d’authentification que vous exécutez vous-même avec plus de contrôle et de responsabilité.

Je recommande toujours de payer pour un fournisseur géré, sauf si vous avez une raison spécifique de ne pas le faire. L’authentification est l’un de ces domaines où le coût d’une légère erreur est très élevé.

Sécurité des données

Dans Bubble, la sécurité se produisait la plupart du temps, que vous y pensiez ou non. Dans le code, l’état par défaut de votre application est non protégé, et chaque couche de sécurité est quelque chose que vous ajoutez délibérément.

Chaque règle de confidentialité Bubble doit être reconstruite en tant que véritable logique côté serveur, souvent avec une sécurité au niveau des lignes dans la base de données.

La gestion des secrets est l’étape suivante. Les secrets comme les clés API doivent se trouver dans des variables d’environnement côté serveur.

Lorsque le framework sur lequel vous avez construit publie une mise à jour de sécurité, c’est à vous de l’appliquer. Bubble le faisait pour vous en arrière-plan. En plus de cela, vous possédez désormais le chiffrement en transit et au repos, principalement géré par de bonnes valeurs par défaut et vos choix d’hébergement, mais il est maintenant de votre responsabilité de confirmer plutôt que de supposer, et la validation des entrées, car vos propres points d’API sont exposés au monde et doivent se défendre contre les mauvaises entrées.

La sécurité des données est l’une des raisons pour lesquelles le faire seul, sans l’aide de quelqu’un qui l’a déjà fait, peut mal tourner, discrètement et coûteusement.

Ce que Bubble faisait pour vous en silence

Il devrait être clair maintenant que Bubble faisait beaucoup de choses pour vous. Mais vous pouvez aussi faire la même chose tant que vous savez ce que vous devez faire par vous-même.

La raison de les lister n’est pas de vous effrayer. C’est pour que “nous devons configurer les sauvegardes” soit quelque chose que vous avez planifié.

Choisir la pile technologique

Vous pouvez choisir React, Next.js ou tout autre framework frontend. Tous les agents IA connaissent tous les frameworks.

Avec les agents IA qui écrivent la majeure partie du code, le coût d’un choix de pile donné est inférieur à ce qu’il était. Bien que les LLM aient tendance à favoriser et soient bons avec React et Next.js.

Que migrer en premier

Vous devriez toujours vous concentrer sur le backend. Votre base de données, votre authentification et votre API principale sont les fondations sur lesquelles tout est construit.

Les construire en premier vous permet de confirmer que vos données sont intactes. Si je dois recommander un LLM pour cela, choisissez Codex. Il est bon pour les opérations backend et gourmandes en données.

Se concentrer d’abord sur le frontend fonctionne lorsque l’interface utilisateur est le problème, et que vous pouvez connecter un nouveau frontend à l’API Data existante de Bubble. Vous pouvez commencer à remplacer l’application module par module pendant que Bubble sert de backend.

Je recommande de travailler sur la migration module par module. Choisissez un seul module et construisez-le entièrement, base de données, API et interface utilisateur, de haut en bas.

De cette façon, vous apprendrez beaucoup sur les points où les choses ont mal tourné pour vous, car elles le feront, avant de vous être engagé à tout migrer.

Quel que soit votre choix, choisissez votre premier module selon la même logique : le moins de dépendances.

Cartographiez les autres modules qui en dépendent avant de commencer. Laissez le module le plus interconnecté pour le moment où les fondations seront solides.

Se lancer dans la tâche la plus difficile en premier vous causera des problèmes.

Construire le frontend et un système de design

Si vous commencez à construire des pages sans système, vous obtenez ce que tout le monde reconnaît comme une application générée par l’IA.

La solution est un système de design. Cela signifie vos couleurs, votre espacement et votre typographie. Ensuite, les composants sont construits à partir de ces tokens, les boutons, les cartes et les champs de saisie. Ensuite, les pages sont assemblées à partir des composants.

Si vous le construisez dans cet ordre, la cohérence est automatique. Mais si vous construisez les pages en premier, votre application n’aura jamais l’air cohérente.

Si vous avez des designs dans Figma, vous pouvez connecter Figma directement à Claude Code et Codex, afin que l’agent construise l’interface utilisateur.

Claude est meilleur que Codex en ce qui concerne le frontend. Demandez à l’agent de prendre une capture d’écran de ce qu’il a construit à l’aide de Playwright, et examinez-la. Cela améliore considérablement le résultat de l’interface utilisateur.

S’éloigner de l’apparence par défaut est principalement une question d’expérience, plutôt que d’accepter la première chose que l’agent IA construit. C’est là qu’avoir quelqu’un avec du goût fait la différence entre “ressemble à un modèle” et “ressemble à un produit”.

Construire le backend et la logique

La construction du backend est principalement un exercice de traduction à partir de la documentation que vous avez produite précédemment. Chaque workflow Bubble sera désormais un point d’API.

Tout d’abord, réimplémentez les règles de confidentialité (Privacy Rules). Chaque règle que vous avez auditée précédemment devient une logique côté serveur et une sécurité au niveau des lignes. Ne laissez pas l’agent vous assurer qu’il a “ajouté de la sécurité”. Vérifiez que chaque règle spécifique de votre audit existe et fonctionne. Les agents affirment parfois que quelque chose fonctionne alors que ce n’est pas le cas.

Deuxièmement, lancez la migration des données. Importez les données nettoyées dans le nouveau schéma, exécutez le processus de réhébergement des fichiers, puis validez que les nombres d’enregistrements correspondent. Comptez les enregistrements dans l’ancien système, comptez-les dans le nouveau, et confirmez qu’ils correspondent.

Et enfin, déplacez les tâches planifiées et en arrière-plan. Les workflows d’API planifiés de Bubble doivent être convertis en tâches cron ou en workers de file d’attente.

Mettre en place une base de code dans laquelle les agents LLM peuvent travailler

Vous allez probablement utiliser Claude Code ou Codex pour vous aider dans la migration. Si ce n’est pas le cas, je vous le recommande vivement, et vous devez faire quelques choses pour vous assurer que les agents sont efficaces.

CLAUDE.md est un fichier où vous écrivez des instructions et des règles pour Claude Code. Il sert de guide qui indique à Claude comment votre projet fonctionne, quelles normes de codage suivre et ce que vous voulez qu’il retienne de vos préférences.

Il se charge au début de chaque session et aide Claude à prendre de meilleures décisions concernant votre code. Séparez les règles spécifiques au domaine dans des fichiers distincts qui ne se chargent que lorsqu’elles sont pertinentes.

Ensuite, structurez le dépôt de manière à ce que le frontend et le backend soient séparés, car cela rendra possibles les agents parallèles. Si les limites sont claires, deux agents peuvent travailler sans se marcher sur les pieds.

La documentation que vous avez créée précédemment devient maintenant vos exigences produit, décomposées en petites tranches verticales complètes.

Utilisez Git dès le premier jour. Il vous aidera à créer des branches et des commits, et à conserver l’historique complet. C’est votre filet de sécurité. Lorsqu’un agent apporte une modification que vous n’aimez pas, Git est le moyen de l’annuler proprement.

Les LLM s’améliorent chaque jour, mais ils font toujours des erreurs. Sans contrôle de version, vous mettez l’ensemble de votre projet en péril.

Claude Code est bon pour le travail de frontend et d’interface utilisateur. Codex est bon pour le travail de backend intensif en base de données. La séparation la plus simple se fait donc le long des tâches frontend-backend.

Et construisez avec un agent (Claude ou Codex), puis demandez à l’autre de faire une revue contradictoire du résultat. Le mode de revue de Codex est bon pour cela. Un agent écrit, l’autre le révise, et vous obtenez un meilleur code que celui que l’un ou l’autre produirait seul.

Gardez les contextes séparés. Ne donnez pas les mêmes informations aux deux agents. Concentrez chaque agent sur son domaine spécifique pour améliorer les performances. Un agent backend n’a pas besoin de connaître vos règles CSS.

Vous pouvez exécuter les deux agents simultanément en utilisant un terminal divisé en volets, avec tmux ou zellij, ou en pointant chaque agent vers un répertoire séparé, ou avec des git worktrees, qui permettent aux agents de travailler sans conflits de fusion.

Gardez une liste de tâches partagée et marquez explicitement les dépendances, afin qu’un agent ne commence pas un travail qui dépend de quelque chose que l’autre n’a pas terminé. Vérifiez constamment le statut Git. Examinez les modifications avant qu’elles ne soient commises. Et ne laissez jamais deux agents modifier les mêmes fichiers simultanément.

La qualité souffrira si les tâches ne sont pas clairement définies. Si vous donnez des tâches peu claires aux agents, ils pourraient assumer des rôles qui se chevauchent et finir par créer des parties qui ne fonctionnent pas bien ensemble. Donnez donc toujours des tâches spécifiques et bien définies.

Ajout de portes de qualité

Vous avez besoin d’un filet de sécurité qui s’exécute pour chaque modification effectuée par les agents LLM, sans que personne n’ait à se souvenir de le déclencher. C’est ce que sont ces portes.

Les hooks de pré-commit s’exécutent automatiquement avant que tout code ne soit commis. Des formateurs, des linters, des scanners de secrets pour qu’une clé API ne soit jamais commise par accident, et des tests de base.

Vous pouvez automatiser les vérifications de correction afin qu’elles se produisent avant que le code n’atteigne la revue. La configuration du linting et du formatage donne aux agents un style cohérent à suivre, ce qui maintient la base de code lisible même lorsque différents agents ont écrit différentes parties.

L’intégration continue garantit que votre code répond à la définition de “terminé” en s’assurant qu’il est exécutable. Si les tests doivent réussir avant le déploiement, le problème du “ça marche sur ma machine” est éliminé, car la CI exécutera les mêmes vérifications à chaque fois.

Testez toujours la sortie des agents avant de la pousser en production. La relecture est plus rapide que de tout réexécuter vous-même, et cela fonctionne même pour les sessions que vous ne regardiez pas. Mieux encore, demandez à un deuxième agent avec un nouveau contexte d’essayer de trouver des lacunes dans le travail du premier agent. L’agent qui a fait le travail ne devrait pas être celui qui le note.

Où les agents IA échouent

Tout le monde vante le codage par IA. Ils sont excellents pour générer du code rapidement, travailler sur de nombreux fichiers, gérer des tâches bien définies et suivre des conventions claires. Utilisez-les pour tout cela. Mais ne comptez pas sur eux pour la logique métier.

Ils peuvent avoir de petites erreurs, facilement négligées, et des tests mal conçus peuvent ne pas les identifier. Ils ont également tendance à affirmer que des mesures de protection sont en place, comme déclarer qu’une règle d’autorisation a été ajoutée alors qu’elle ne l’était pas, ou qu’une règle de confidentialité existe alors qu’il n’y en a aucune.

Si vous ne révisez pas et ne partagez pas de commentaires, ils préféreraient utiliser la bibliothèque pratique, pas la bonne, car un agent IA optimise pour accomplir la tâche plutôt que pour le meilleur choix à long terme.

Les agents IA vous aident à migrer les applications Bubble. Ils ne remplacent pas la connaissance de ce à quoi ressemble la correction. Une équipe qui comprend ce à quoi ressemble la “correction” travaille beaucoup plus vite. Une équipe qui ne comprend pas se retrouvera rapidement avec une application cassée et peu fiable.

Beaucoup de gens vous diront d’engager une agence à ce stade. Je dirai simplement que l’écart entre un agent IA rapide et savoir quand quelque chose ne va pas est la raison pour laquelle une aide expérimentée est rentable. Que ce soit nous ou quelqu’un d’autre, ne laissez pas les agents être ceux qui évaluent leur propre travail.

Qui le maintient après le lancement ?

Une fois que vous avez migré, vous devez maintenant le maintenir. Vous pouvez embaucher un ingénieur, retenir l’agence qui l’a construit, ou utiliser Claude ou Codex si le produit est simple. N’importe laquelle de ces options est acceptable.

Coût d’exécution d’une application Bubble vs code

Votre ancienne facture Bubble était simple. Plan Bubble, plus les dépassements d’unités de travail lorsque l’utilisation augmentait. Mais maintenant, votre nouvelle facture a quelques fournisseurs supplémentaires. Hébergement, une base de données, stockage d’objets pour les fichiers, un fournisseur d’authentification, un service de messagerie, la surveillance et un domaine.

Au début, vos coûts augmentent. Mais à mesure que votre application grandit, elle devient moins chère que Bubble, surtout pour les applications à forte utilisation. Le gain n’est pas seulement des coûts mensuels plus bas. Vous vous retrouvez avec une application plus rapide et un actif que vous possédez entièrement.

Où la migration de Bubble tourne mal

Cette liste semblera excessive jusqu’à ce que l’une de ces choses vous arrive.

• Croire qu’il existe un export en un clic de Bubble vers le code. Il n’y en a pas, et planifier autour de cela fait perdre des semaines.
• Oublier que les fichiers exportés ne sont que des URL, et perdre tous les actifs lorsque l’hébergement Bubble expire.
• Tirer une grande table via l’API Data en une seule requête et obtenir silencieusement seulement 100 enregistrements.
• Tenter de migrer des hachages de mots de passe que vous ne pouvez pas exporter, au lieu de planifier une stratégie de réinitialisation ou de migration progressive.
• Ne pas réimplémenter les règles de confidentialité (Privacy Rules), laissant les données de la nouvelle application grandes ouvertes.
• Entasser tout dans un seul et gigantesque CLAUDE.md.
• Donner aux agents des invites vagues comme “construire un tableau de bord”.
• Laisser les agents effectuer de grandes réécritures multi-fichiers en une seule fois. Faites de petits changements.
• Deux agents modifiant les mêmes fichiers en même temps.
• Faire confiance à un agent qui dit que quelque chose fonctionne au lieu de le vérifier vous-même.
• Ne pas passer une semaine au nettoyage des données.
• Oublier que vous êtes maintenant responsable des sauvegardes, des correctifs et de la disponibilité.
• Effectuer le basculement sans plan de retour en arrière.