Comment exploiter plusieurs entreprises à 10 k$ de revenus mensuels avec une stack à 20 $ par mois

• Stratégie de bootstrapping permettant d’exploiter plusieurs entreprises SaaS générant plus de 10 k$ de MRR avec moins de 20 $ par mois de coûts d’infrastructure, en s’appuyant sur un VPS unique, le langage Go, SQLite et un GPU local
• Au lieu d’AWS ou d’une orchestration cloud complexe, tous les services tournent sur un seul VPS à 5 à 10 $, afin de se concentrer sur le traitement des requêtes plutôt que sur la gestion de l’infrastructure
• Choix de Go comme langage backend pour obtenir un processus de déploiement extrêmement simple, avec compilation en binaire unique sans gestion de dépendances, puis déploiement direct sur le serveur
• Exécution de VLLM sur un GPU local (RTX 3090) pour ramener à zéro le coût du traitement batch IA, tout en réservant les modèles de pointe via OpenRouter aux seules fonctionnalités en contact direct avec l’utilisateur
• Même sans capital-risque, maintenir les coûts presque à zéro permet d’obtenir une runway pratiquement infinie et de disposer d’assez de temps pour trouver l’adéquation produit-marché

---

Stratégie de serveurs lean

• En 2026, la manière « standard » de lancer une web app consiste à provisionner sur AWS un cluster EKS, une instance RDS et une NAT Gateway, ce qui entraîne plus de 300 $ de dépenses mensuelles même sans le moindre utilisateur
• L’alternative consiste à louer un VPS à 5 à 10 $ par mois chez Linode ou DigitalOcean et à tout faire tourner sur un serveur unique
• 1 Go de RAM peut suffire si elle est bien utilisée, et en cas de marge insuffisante, un swapfile peut prendre le relais
• Avec un seul serveur, il est possible de savoir exactement où se trouvent les logs, pourquoi un crash est survenu et comment redémarrer le service
• La raison de préférer un VPS à AWS tient à des coûts prévisibles et à une architecture simple

Pourquoi choisir Go

• Python ou Ruby consomment déjà la moitié de la RAM rien qu’avec le démarrage de l’interpréteur et la gestion des workers gunicorn
• Go offre de bien meilleures performances pour les charges web, un système de types strict et, en 2026, c’est un langage que les LLM comprennent très facilement pour le raisonnement
• L’avantage central de Go est la simplicité du déploiement : toute l’application est compilée en un unique binaire lié statiquement, construit sur un laptop puis envoyé sur le serveur avec scp pour être exécuté
• Pas besoin de l’enfer des dépendances avec pip install ni d’environnements virtuels, et il est possible de construire un serveur web de niveau production sans framework obèse
• Avec la seule bibliothèque standard de Go, on peut écrire un serveur capable de traiter des dizaines de milliers de requêtes par seconde

IA locale : ramener à zéro le coût des traitements batch

• Si vous avez une carte graphique chez vous, vous disposez déjà de crédits IA illimités
• Lors de la création de eh-trade.ca, il fallait mener une vaste recherche boursière qualitative en analysant les rapports trimestriels de milliers d’entreprises, ce qui aurait pu coûter plusieurs centaines de dollars via l’API OpenAI
• À la place, VLLM a été exécuté sur une RTX 3090 (24 Go de VRAM) achetée 900 $ sur Facebook Marketplace, supprimant la nécessité de payer un fournisseur IA
• Parcours de montée en puissance pour l’IA locale :
  • Commencer avec Ollama : configuration en une ligne de commande (ollama run qwen3:32b), test immédiat de différents modèles et excellent outil pour itérer sur les prompts
  • Passer en production avec VLLM : Ollama devient un goulot d’étranglement sous requêtes concurrentes, tandis que VLLM est radicalement plus rapide grâce à PagedAttention. En envoyant simultanément 8 à 16 requêtes asynchrones, le traitement batch s’effectue en mémoire GPU pour un temps proche de celui d’une seule requête
  • Transformer Lab : quand il faut faire du pré-entraînement ou du fine-tuning, cela peut être réalisé facilement sur du matériel local
• Pour gérer cela, développement de laconic, un outil de recherche agentique optimisé pour une fenêtre de contexte de 8K, qui « page out » les parties inutiles d’une conversation comme le ferait le gestionnaire de mémoire virtuelle d’un OS, afin de ne garder dans le contexte actif du LLM que les faits essentiels
• llmhub : outil qui abstrait tous les LLM sous la forme provider/endpoint/apikey, pour gérer sans friction les entrées/sorties texte et image, en local comme dans le cloud

Accéder aux modèles de pointe via OpenRouter

• Tout ne peut pas être traité en local, et les interactions de chat à faible latence face à l’utilisateur nécessitent des modèles de raisonnement de pointe comme Claude 3.5 Sonnet ou GPT-4o
• Au lieu de gérer séparément les comptes de facturation, clés API et limites de débit d’Anthropic, Google et OpenAI, tout est unifié via OpenRouter
• Il suffit d’écrire une seule intégration compatible OpenAI pour accéder immédiatement à tous les grands modèles de pointe
• Prise en charge d’un routage de secours fluide : si l’API Anthropic tombe en panne, bascule automatique vers un modèle OpenAI équivalent, sans écran d’erreur pour l’utilisateur et sans logique complexe de retry

Un codage IA rentable avec GitHub Copilot

• Alors que de nouveaux modèles coûteux sortent chaque semaine, de nombreux développeurs dépensent plusieurs centaines de dollars par mois en abonnement Cursor et en clés API Anthropic
• À l’inverse, même avec Claude Opus 4.6 utilisé toute la journée, le coût mensuel dépasse rarement 60 $
• Le secret est d’exploiter le modèle tarifaire de Microsoft : acheter un abonnement GitHub Copilot en 2023 et le connecter à VS Code standard
• Astuce clé de Copilot : Microsoft facture à la requête et non au token, et une « requête » correspond à une saisie dans la boîte de chat. Même si l’agent analyse tout le codebase pendant 30 minutes et modifie des centaines de fichiers, cela ne coûte qu’environ 0,04 $
• Stratégie optimale : rédiger un prompt détaillé avec des critères de réussite stricts, lui demander de « continuer jusqu’à ce que toutes les erreurs soient corrigées », puis le lancer

Utiliser SQLite comme base de données universelle

• À chaque nouveau projet, sqlite3 est utilisé comme base de données principale
• Du point de vue de l’entreprise, on considère souvent qu’un serveur de base de données dans un processus séparé est indispensable, mais en pratique, un fichier SQLite local accessible via une interface C ou la mémoire est plusieurs ordres de grandeur plus rapide qu’un serveur Postgres distant impliquant un saut réseau TCP
• Malentendu fréquent sur la concurrence : l’idée selon laquelle SQLite verrouille toute la base à chaque écriture est fausse, et Write-Ahead Logging (WAL) permet de résoudre le problème
  • Avec PRAGMA journal_mode=WAL; et PRAGMA synchronous=NORMAL;, lectures et écritures ne se bloquent pas mutuellement
  • Un unique fichier .db sur un disque NVMe peut prendre en charge des milliers d’utilisateurs simultanés
• Pour simplifier l’implémentation de l’authentification utilisateur, développement de la bibliothèque maison smhanov/auth, qui s’intègre directement à la base utilisée et prend en charge l’inscription, les sessions, la réinitialisation de mot de passe et la connexion via Google/Facebook/X/SAML

Conclusion : construire une startup sans infrastructure complexe

• L’industrie tech affirme qu’il faut une orchestration complexe, des factures AWS mensuelles énormes et des millions de dollars de capital-risque pour bâtir une vraie entreprise, mais ce n’est pas le cas
• En combinant un VPS unique, des binaires compilés statiquement, des traitements batch IA sur GPU local et la vitesse brute de SQLite, il devient possible de lancer une startup évolutive en bootstrapping pour le prix de quelques cafés par mois
• Cela donne au projet une runway infinie, laissant le temps de se concentrer sur la résolution des problèmes utilisateurs plutôt que sur l’angoisse du burn rate