Dans les coulisses de l’architecture des aperçus instantanés Fly.io de Coderblock

Un aperçu de développement utile ne doit pas seulement vous montrer à quoi une application pourrait ressembler. Il doit vous permettre de réellement l’utiliser pendant sa création : naviguer entre les pages, créer un compte, enregistrer des données, importer des fichiers, traiter des paiements et tester la logique backend.

C’est exactement ce que fait l’aperçu instantané de Coderblock.

Après avoir décrit une application — ou être parti de l’un des modèles disponibles — votre projet devient accessible à une adresse dédiée. Chaque modification suivante apparaît dans l’aperçu en quelques secondes grâce au hot reload.

Du point de vue de l’utilisateur, le processus est simple : décrivez une fonctionnalité et regardez-la prendre forme. Derrière cette simplicité se cache toutefois une architecture qui coordonne le code frontend, les services backend, l’authentification, les bases de données, le stockage, les secrets et le déploiement des aperçus.

Le chat est l’interface de contrôle

Avec Coderblock, le chat devient le point d’entrée de l’ensemble du processus de développement. Vous n’avez pas besoin de commencer par configurer l’infrastructure, des dépôts ou des services frontend et backend distincts. Décrivez en langage naturel ce que vous souhaitez créer, et l’agent transforme votre idée en application fonctionnelle.

Par exemple :

• « Crée une plateforme de réservation pour une salle de sport. »
• « Ajoute une connexion et permet aux membres de voir uniquement leurs propres réservations. »
• « Crée une vue d’administration avec un tableau des réservations. »
• « Permets aux clients de payer 9,99 € par mois. »
• « Fixe la barre de navigation sur mobile. »

Une seule demande peut donc entraîner des modifications à plusieurs niveaux de la stack. Le frontend généré utilise React, Vite, TypeScript et Tailwind CSS. Pour une application web standard, le backend s’exécute sur un projet Supabase dédié comprenant Postgres, Supabase Auth, Storage et les Deno Edge Functions.

Cela signifie que l’aperçu n’est pas une simple représentation visuelle du prompt. C’est une véritable application full-stack. Un formulaire peut enregistrer des données dans Postgres. Une page protégée peut utiliser la session de l’utilisateur authentifié. Un import peut enregistrer des fichiers dans Storage. La logique backend peut s’exécuter au moyen des Edge Functions.

Pour les projets Enterprise Web Platform, Coderblock utilise à la place un backend Python avec FastAPI et Neon Postgres. Le principe reste le même : décrivez le comportement souhaité, laissez l’agent l’implémenter, puis vérifiez immédiatement le résultat dans l’aperçu.

---

De la demande à l’aperçu grâce au hot reload

Le cycle de développement peut être présenté comme un processus en cinq étapes.

1. Décrivez ce que vous souhaitez créer

La demande peut porter sur un simple détail d’interface ou sur une fonctionnalité couvrant l’ensemble du système. « Change la couleur du bouton » correspond principalement à une modification visuelle. « Ajoute des comptes d’équipe avec des espaces de travail privés » est très différent : cela peut nécessiter des modifications de l’interface, de l’authentification, de la base de données, des autorisations et de la logique applicative.

Avec Coderblock, vous n’avez pas à convertir cette demande en une liste de routes, de migrations, de gestionnaires de session et de politiques d’accès. Décrivez le résultat que vous souhaitez obtenir. L’agent se charge des détails nécessaires pour y parvenir.

2. L’application est mise à jour de bout en bout

Lorsqu’une fonctionnalité l’exige, l’IA apporte des modifications coordonnées aux différentes couches de l’application.

Si des données persistantes sont nécessaires, elle peut concevoir et exécuter la migration de schéma Postgres correspondante. Si une authentification est requise, elle peut connecter l’interface à Supabase Auth et appliquer des politiques Row Level Security basées sur l’utilisateur actuel.

Chaque application comprend également une table de profils et une structure de base pour la gestion des rôles. L’agent dispose ainsi d’un socle cohérent pour créer des fonctionnalités telles que des tableaux de bord personnels, des espaces privés et des vues d’administration, sans avoir à réinventer le système d’authentification à chaque fois.

3. Le backend reste intégré à l’application

Un aperçu rapide n’est réellement utile que si tout ce qui se trouve derrière l’interface continue de fonctionner. C’est pourquoi Coderblock maintient la connexion de l’application à sa base de données, à son système d’authentification, à son stockage et à ses fonctions backend. Depuis l’onglet Backend, vous pouvez consulter les tables du projet, les utilisateurs authentifiés, le stockage et les fonctions disponibles.

L’avantage est que chaque itération s’appuie sur la précédente.

Ajouter une table ne revient pas à créer une simulation temporaire : cela modifie le modèle de données de l’application. La demande suivante peut alors s’appuyer sur cette même structure pour ajouter des filtres, des tableaux de bord, des relations ou des autorisations.

4. L’aperçu se met à jour en temps réel

Le projet est déployé à son adresse d’aperçu dédiée, sous la forme <app>.coderblock.dev. Lorsque l’application change, le hot reload déploie rapidement les mises à jour et les rend visibles dans l’environnement en cours d’exécution.

L’objectif n’est pas seulement la rapidité. Il s’agit aussi de préserver la continuité tout au long du processus.

Vous n’avez pas besoin de créer une nouvelle démonstration à chaque itération ni de passer d’un environnement à l’autre. Vous pouvez naviguer en continu entre le chat, l’aperçu et le backend, tout en travaillant toujours sur la même application.

La couche d’aperçu Fly.io fait partie de ce processus de déploiement, mais l’expérience reste simple : chaque projet dispose d’un environnement de développement accessible, les mises à jour sont déployées rapidement et l’aperçu reste connecté aux services full-stack de l’application.

Vous n’avez pas à configurer de serveurs d’aperçu ni de pipelines de déploiement avant de tester ce que vous venez de créer.

5. Testez, corrigez, continuez

C’est ici que la véritable valeur de l’aperçu entre en jeu. Vous pouvez parcourir l’application, vérifier son comportement responsive, créer des comptes, envoyer des formulaires, contrôler les autorisations et tester les comportements associés aux différents rôles.

Si quelque chose ne fonctionne pas comme prévu, vous n’avez pas besoin de retourner dans le code pour déterminer ce qu’il faut modifier. Il vous suffit de décrire l’ajustement suivant.

Décrire → générer → prévisualiser → tester → affiner

C’est précisément pour cette raison que la rapidité de Coderblock ne repose pas uniquement sur la génération de code. L’ensemble du processus de développement reste intégré au même workflow.

Les secrets restent en dehors du code

Un environnement de développement rapide ne doit jamais vous obliger à sacrifier la sécurité.

Lorsqu’une intégration nécessite un secret, Coderblock le gère au moyen d’une invite dédiée aux variables d’environnement. La valeur est stockée dans le coffre de secrets côté serveur du projet, sans être insérée dans le code généré ni dans la conversation habituelle.

Stripe illustre parfaitement cette approche.

Dans le mode géré par défaut, l’agent recueille les informations nécessaires, comme le pays et le nom de l’entreprise, puis crée un compte Stripe géré pour le projet. Vous n’avez pas à gérer directement les clés API, et Coderblock s’occupe également de la configuration des webhooks.

La configuration des paiements et la vérification KYC peuvent ensuite être finalisées à l’aide du lien d’onboarding hébergé par Stripe.

En mode BYOK, l’agent demande STRIPE_SECRET_KEY de manière sécurisée, la stocke côté serveur et configure automatiquement le webhook. Dans les deux cas, Coderblock peut créer les produits et les tarifs Stripe nécessaires, configurer le paiement et connecter les différents composants à l’application. Vous pouvez effectuer des tests avant d’activer les paiements réels.

L’aperçu et la production sont deux choses différentes

L’aperçu sert à créer et à expérimenter. La production sert à publier. Il s’agit de deux étapes distinctes, et Coderblock les maintient séparées.

Lorsque l’application est prête, vous pouvez sélectionner Publier pour la déployer sur <app>.coderblock.app. SSL est inclus, et les versions suivantes bénéficient de mises à jour à chaud rapides.

Cela évite qu’une modification expérimentale effectuée dans le chat devienne automatiquement une version de production. Vous pouvez également connecter un domaine personnalisé depuis Paramètres → Domaines en suivant les instructions de configuration des enregistrements DNS. Vous pouvez aussi acheter directement le domaine par l’intermédiaire de Coderblock. Dans ce cas, le DNS et SSL sont configurés automatiquement.

Le parcours est donc clair :

Chat → Aperçu → Test → Publication

Le chat pilote le développement, l’aperçu vous permet de voir et de tester le résultat, le backend garantit que l’application est réellement fonctionnelle, et la publication met en ligne la version approuvée.

Une architecture conçue pour l’itération

La véritable valeur d’un système d’aperçu instantané ne réside pas dans un composant d’infrastructure particulier. Elle repose sur la capacité de l’ensemble du système à suivre le rythme du processus créatif. Avec Coderblock, le frontend, la base de données, l’authentification, le stockage, les fonctions, les secrets et l’environnement d’aperçu font tous partie du même workflow. Vous pouvez partir d’une simple phrase, obtenir une application full-stack fonctionnelle, la tester immédiatement, puis continuer à la modifier au fil de la conversation.

Sans configurer manuellement des serveurs. Sans passer constamment d’un outil à l’autre. Sans transformer chaque modification en un nouveau déploiement.

L’infrastructure reste en grande partie invisible. Vous pouvez vous concentrer sur l’essentiel : créer, tester et itérer.