Une stack complète pour un projet vibecoding

Une stack complète couvre la construction du produit et son exploitation : code, données, déploiement, sauvegardes, erreurs et mesure. Ce guide s’adresse à un projet qui a dépassé la toute première maquette. Pour démarrer plus court, consultez Choisir la stack de son premier projet. Pour comparer des produits un par un, utilisez la boîte à outils du débutant.

Les assemblages ci-dessous sont illustratifs. Vibarche ne les a pas testés et ne les présente pas comme une stack personnelle. Aucun prix n’a été relevé lors de cette revue.

Du besoin au produit exploitable

Décrivez l’utilisateur, son problème et le parcours que la première version doit réussir.
Choisissez un éditeur et un assistant adaptés au dépôt. Un modèle exécuté en local demande une machine compatible ; ses capacités dépendent du modèle retenu.
Versionnez le code avec Git. Une forge hébergée ou auto-hébergée ajoute la collaboration, mais aussi des comptes et des sauvegardes à gérer.
Ajoutez une base si le parcours conserve des comptes ou des données métier. Définissez le schéma, les permissions, les migrations, la sauvegarde et la restauration.
Branchez un prestataire de paiement seulement si le produit encaisse. Stripe documente la réception d’événements serveur et la vérification de leur signature.
Déployez hors de la machine de développement. Une plateforme gérée prend en charge une partie de l’infrastructure. Docker Compose et Coolify laissent davantage de responsabilités à l’équipe qui contrôle le serveur.
Ajoutez un suivi d’erreurs pour diagnostiquer les incidents. GlitchTip documente le suivi d’erreurs et de disponibilité, en service hébergé ou sur un serveur contrôlé par l’équipe.
Mesurez quelques événements liés à une question produit. Umami et Matomo documentent des versions auto-hébergeables ; l’installation d’un outil ne règle pas à elle seule les obligations relatives aux données.
Ajoutez les e-mails, le stockage de fichiers et les tâches planifiées quand le parcours les réclame.

Les composants à comparer

Besoin	Service géré possible	Option auto-hébergée documentée	Vérification prioritaire
Maquettes	Outil de conception hébergé	Penpot	Export, accès et sauvegarde des fichiers
Assistance au code	Assistant hébergé	Continue relié à Ollama	Capacités du modèle, mémoire disponible, données envoyées au fournisseur
Historique du code	Forge Git hébergée	Forgejo	Accès, mises à jour et sauvegarde des dépôts
Base de données	PostgreSQL géré ou Supabase géré	PostgreSQL ou Supabase auto-hébergé	Permissions, migrations, sauvegarde et restauration
Paiement	Prestataire externe tel que Stripe	Aucune solution auto-hébergée proposée dans ce guide	Signatures des webhooks, échecs, remboursements et environnement de test
Déploiement	Vercel, Railway ou autre plateforme compatible	Docker Compose, éventuellement piloté par Coolify	Variables par environnement, volumes, accès serveur et retour arrière
Erreurs et disponibilité	Service de monitoring géré	GlitchTip	Alertes, rétention, accès aux rapports et sauvegarde
Analytics	Service d’analytics hébergé	Umami ou Matomo On-Premise	Événements utiles, conservation et information des visiteurs

Une option auto-hébergée n’est pas la copie exacte d’un service géré. Supabase indique par exemple que son offre auto-hébergée ne comprend pas certaines fonctions de la plateforme gérée. L’équipe prend alors en charge le serveur, le durcissement, PostgreSQL, les sauvegardes, la reprise après incident, la supervision et la disponibilité.

Parcours géré

Gardez le code dans Git, puis choisissez un hébergeur pour l’application et un service pour la base. Vercel et Railway documentent des parcours différents ; vérifiez les contraintes du framework et des processus serveur avant de retenir l’un d’eux. Ajoutez le paiement, le suivi d’erreurs et l’analytics uniquement lorsque le produit en a besoin.

Ce chemin réduit l’administration directe du serveur, sans supprimer les décisions sur les permissions, les exports, les coûts variables et les données confiées aux fournisseurs.

Parcours auto-hébergé

Un assemblage possible utilise Penpot pour les maquettes, Continue avec Ollama pour l’assistance au code, Forgejo pour la forge et PostgreSQL pour les données. Docker Compose décrit les services ; Coolify peut déployer des conteneurs sur un serveur connecté. GlitchTip, Umami ou Matomo ajoutent le suivi et la mesure.

Ce chemin n’a pas été exécuté ici. Chaque composant demande des mises à jour, des accès contrôlés, de la supervision et une procédure de restauration. Le paiement, les e-mails et le nom de domaine peuvent encore dépendre de prestataires externes.

Licences et limites commerciales

PostgreSQL publie son code sous la PostgreSQL License, que le projet décrit comme une licence open source permissive. Cette information concerne PostgreSQL, pas les autres briques de la stack.

Pour chaque composant, vérifiez séparément :

la licence du code installé ;
la licence des modèles et de leurs poids éventuels ;
les conditions de l’offre cloud ;
les droits de redistribution ou de revente nécessaires au projet.

Le fait qu’un produit puisse être auto-hébergé ne suffit pas à conclure que toutes ses éditions, marques, extensions ou offres commerciales ont les mêmes droits. Cette page ne donne pas d’avis juridique.

Coûts, sauvegardes et sorties

Inventoriez les services réellement retenus : domaine, calcul, base, stockage, e-mails, paiement, monitoring et analytics. Pour chaque ligne, relevez la page tarifaire officielle, sa date, la région, les quotas et les conséquences d’un dépassement. Aucun montant n’est publié ici, car aucun panier cohérent ni aucune région n’ont été vérifiés.

Préparez aussi la sortie. Le code, les données et la configuration doivent pouvoir être exportés. PostgreSQL documente pg_dump et pg_restore, mais les commandes et une restauration réelle n’ont pas été exécutées pour cet article. Une sauvegarde non restaurée reste une hypothèse.

Vérifications avant la mise en production

Le parcours principal fonctionne avec des données de test.
Aucun secret de production ne se trouve dans le navigateur, le dépôt ou un prompt.
Les migrations et les droits d’accès sont relus.
Une restauration a été réellement vérifiée pour les services administrés par l’équipe.
Les événements de paiement reçus côté serveur sont authentifiés avant de modifier l’accès d’un compte.
Les journaux et alertes permettent d’enquêter sans collecter de données inutiles.
Chaque composant a un responsable pour les mises à jour et les incidents.

Ajoutez une brique à la fois. Une stack complète n’est pas celle qui contient le plus d’outils, mais celle dont chaque composant répond à un besoin identifié et peut être maintenu.

Sources

Sources officielles consultées le 19 octobre 2026 :