01 Backend
Elixir + Phoenix Framework
BEAM/OTP fournit fault-tolerance et concurrence par défaut. Pas besoin de Redis ou de queue séparée pour la plupart des cas. Code maintenable même en équipe solo.
Notre stack : Elixir/Phoenix LiveView avec PostgreSQL natif.
Pas Next.js, pas Supabase, pas Lovable pour la prod. Position opinionated, défendue par mon propre SaaS Wytt qui tourne dessus avec des utilisateurs payants.
Ce que je code, par couche
Quatre choix techniques que je défends sur chaque MVP livré.
02 Frontend
Phoenix LiveView
Réactivité full-stack via WebSocket sans framework JavaScript séparé. Une seule stack à maîtriser, un seul repo, zero duplication d'état entre client et serveur.
03 Base de données
PostgreSQL natif (sans Supabase)
Sécurité au niveau code via Ecto et plug auth manuel, pas via des policies RLS configurées par prompts IA. Pas de couche d'abstraction tierce qui peut casser.
04 Déploiement
Fly.io ou Cloudflare
BEAM hot-reload + Fly.io = déploiements sans downtime. Cloudflare Workers pour les fronts statiques quand c'est pertinent.
Ce que je ne code pas
Trois patterns que les outils vibe coding (Lovable, Bolt, V0) génèrent par défaut. Tous documentés dans des incidents publics.
01
Next.js + Supabase par défaut
Stack la plus représentée dans les CVE vibe coding (CVE-2025-48757, NIST NVD, CVSS 9.3, mai 2025). Lovable + Bolt génèrent du Next.js + Supabase par défaut. RLS configurés par IA sont régulièrement cassables.
Source officielle → 02
RLS Supabase comme couche de sécurité unique
170 apps Supabase scannées sur 1645 avaient des RLS défaillants. Veracode 2025 GenAI Report : 45% des completions LLM introduisent une vulnérabilité OWASP, dont 86% pour XSS et 72% pour Java.
Source officielle → 03
Lovable / Bolt pour la prod
Escape.tech a scanné 5 600 apps vibe-codées : 2 000+ vulnérabilités, 400+ secrets exposés, 175 fuites PII. La majorité tournait sur Next.js + Supabase.
Source officielle →Quand cette stack n'est pas le bon choix
Une stack opinionated, c'est une stack avec des limites. Voici les cas où elle ne s'applique pas.
Tu veux du React Native mobile natif
Pas ma cible. Ary livre des MVPs web et PWA. Pour une app mobile native, je t'oriente vers un spécialiste React Native ou Flutter.
Tu veux pouvoir embaucher en France facilement
Le marché Elixir en France est plus serré que le marché Node.js. Réponse honnête : oui, mais tu vises 1 dev Elixir senior, pas 5 juniors. Et la communauté grandit (Numeum baromètre 2026).
Tu veux du templating frontend lourd (SSR/SSG complexe)
Phoenix sert ça nativement avec LiveView et heex. Mais si tu fais du e-commerce avec catalogue produit lourd, un Next.js + headless commerce est sans doute mieux. Je te le dirai à l'appel de cadrage.
Preuve par dogfooding
Wytt tourne sur cette stack.
Mon propre SaaS d'orchestration SEO tourne en production sur Elixir/Phoenix LiveView avec PostgreSQL natif. Pipeline de 10 workers parallèles, dashboard temps réel, des utilisateurs payants. Je vends ce que je pratique.
Avec Ary, ton MVP coûte 5 000 à 25 000 € livré en 4 semaines, par un fondateur identifiable qui code sur la même stack que celle de son propre SaaS.
Questions sur la stack
Tu codes vraiment en Elixir/Phoenix toi-même ?
Oui, avec Cursor + Claude Code en pilotage IA, et un dev senior Elixir de confiance qui relit les parties critiques (auth, paiement, sécurité). Mon SaaS Wytt tourne en production sur cette stack avec des utilisateurs payants. C'est la preuve par dogfooding. Voir ma page À propos.
Pourquoi pas Ruby on Rails ou Django ?
Rails et Django restent excellents. Mais Elixir/Phoenix LiveView offre la réactivité temps réel sans framework JS séparé, et la BEAM offre une tolérance aux pannes que les VM Ruby et Python n'ont pas. Sur un MVP qui doit tenir en prod sans devops dédié, c'est un avantage net.
Et si je veux migrer ma stack après la livraison ?
Tu peux. Le code est à toi, propriété 100%, dès le jour 1. La structure du code est standard Phoenix, donc n'importe quel dev Elixir peut reprendre. Pour migrer vers une autre stack, c'est un rebuild classique. Aucun lock-in propriétaire chez moi.
Cette stack a-t-elle des limites ?
Oui, comme toute stack. Si tu vises un mobile natif iOS/Android, du machine learning entraîné maison, ou une vidéo streaming temps réel haute volumétrie, ce n'est pas le bon choix. Pour les MVPs SaaS B2B web (90 % de mes projets), c'est la stack la plus productive.
Tu veux discuter de ton projet ?
Décris ton projet en 3 lignes. Je te dis si ta feature est faisable sur Elixir/Phoenix, ou si une autre stack te servirait mieux.
Créons ton MVPAucun engagement.