Dev indie avec l'IA : créer, publier et monétiser

La question « l'IA va-t-elle me prendre mon travail ? » ne colle plus à ce dont il s'agit ici. En suivant 49,610 freelances et 2.26 millions de contrats sur Upwork de janvier 2021 à mars 2026, Siddiq et Zhang (UCLA Anderson) ont mesuré non pas la disparition du travail, mais un changement dans la façon dont on est choisi : le poids des signaux de capital humain — certifications vérifiées, parcours, portfolio, évaluations clients — recule de 7.8%, celui du prix progresse de 1.1%, et sur les 4 derniers trimestres l'écart se creuse encore (-10.1% et +1.8%). Au même moment, un mouvement inverse est à l'œuvre du côté de l'offre : aux États-Unis, la part de freelances chez les travailleurs du savoir qualifiés est passée de 28% à 38% en un an, et 58% des salariés envisagent de basculer. Cet article croise cinq sources vérifiées jusqu'à leur éditeur d'origine et met en évidence deux paradoxes : chez les salariés l'expérience sert de bouclier (Stanford : emploi inférieur d'environ 19% chez les 22 à 25 ans exposés à l'IA, aucun écart comparable chez les expérimentés) alors que chez les freelances la baisse est la plus forte chez les plus expérimentés ; et le travail n'a pas disparu, c'est le segment intermédiaire qui a disparu, puisque les offres facilement automatisables reculent de 21% pendant que les missions restantes deviennent plus complexes et mieux payées. Les objections sérieuses (les taux d'intérêt, le marché figé) et les réserves posées par les chercheurs eux-mêmes sont exposées telles quelles, et le chapitre des tactiques est explicitement signalé comme hypothétique.

L'échec le plus fréquent en développement solo, c'est « je l'ai fait mais personne ne l'utilise ». Or le vrai goulot d'étranglement n'est pas la capacité à construire mais l'acquisition. « Si on fait quelque chose de bien, les gens viennent » est une illusion : réunir ses prospects avant même de construire avec le Build in Public, aller chercher les 10 premiers à la main autour de soi (ces « choses qui ne passent pas à l'échelle »), se faire trouver par les 100 premiers en contribuant là où ils sont (communautés, réseaux), puis créer un flux continu via SEO / AEO / LLMO — cet article réunit, du point de vue du développeur solo, la façon de faire tourner cet ordre en s'appuyant sur l'IA pour la préparation.

La plus grande cause d'échec du développement solo, c'est « trop peaufiner ». À force d'empiler les fonctions, ça se complexifie, et le projet disparaît sans jamais être publié. Le seul moyen d'y échapper : se limiter à une seule fonction et publier au plus vite le produit minimal qui transmet sa valeur — le MVP. Cet article explique, du point de vue du développeur solo qui prend l'IA pour coéquipière : la juste conception du MVP, le jugement de périmètre pour couper des fonctions, les deux voies pour construire au plus vite avec l'IA (vibe coding sans écrire de code / pratique en éditeur IA), la reconnaissance du « terminé », et le chemin jusqu'à publier et faire utiliser par une personne.

Beaucoup de développeurs solo se bloquent à « je sais construire, mais comment gagner de l'argent et à quel prix vendre ». Cet article réunit, du point de vue du développeur solo : le choix du modèle de monétisation (gratuit / paiement unique / abonnement / freemium / publicité / dons), la tarification à la valeur — qui part non des coûts ou des concurrents mais de « la valeur que le client obtient » —, l'offre à 3 paliers Gratuit → Pro → Business avec la règle d'or de la remise annuelle, la façon de décrocher son premier client payant, et enfin la rentabilité qui intègre le coût de l'IA (tokens d'API, etc.). Un article qui approfondit la phase « faire grandir » du hub « Feuille de route du développement solo avec l'IA ».

Maintenant que l'IA dispose de « mains pour écrire du code », une seule personne peut créer un produit et le lancer. Mais l'information est éparpillée étape par étape et l'on ne sait pas par où commencer. Cet article est la carte d'ensemble (feuille de route) qui va de l'idée → conception → implémentation → mise en ligne → monétisation : un article vaisseau amiral (hub) qui organise le développement solo en 5 phases (décider → préparer → construire → publier → faire grandir), indique pour chaque étape quoi faire et quels outils utiliser, et renvoie vers un guide dédié là où un approfondissement est nécessaire. De plus, il guide sur deux voies — la 🌱 voie débutant qui n'écrit presque pas de code, et la 🔧 voie pratique qui écrit du code dans un éditeur IA — pour qu'en suivant celle qui vous correspond, vous atteigniez une chose qui fonctionne sans détour. Spec-driven, générateurs d'applications IA, Claude Code / Cursor, intégration de fonctions IA (API / RAG / passerelle), déploiement, acquisition SEO/AEO, monétisation, gestion des coûts et les 5 pièges du développement solo avec l'IA : tout est réuni sur une seule page, avec des liens vers les guides pratiques existants.

Vous avez construit sur OpenAI, puis voulu essayer Claude et comparer Gemini — et perdu des heures à cause des SDK, formats et gestions d'erreurs différents par fournisseur. Une passerelle LLM (passerelle IA / proxy LLM) est un relais que vous glissez entre votre application et les fournisseurs : elle expose une seule API compatible OpenAI pour atteindre tous les modèles et prend en charge les tâches transversales — bascule, suivi des coûts, clés virtuelles, mise en cache, limitation de débit et observabilité. Ce guide couvre pourquoi vous en avez besoin, ce qu'une passerelle est vraiment, les trois types (proxy auto-hébergé = LiteLLM / hébergé = OpenRouter / SDK = Vercel AI SDK), comment choisir parmi LiteLLM, OpenRouter et le Vercel AI SDK, le code de configuration minimal qui ne remplace que le point de terminaison, et les limites — un saut de latence, la passerelle comme nouveau point de défaillance, les frais (OpenRouter facture 5,5 % sur les achats), la perte de fonctionnalités et la confidentialité.

Le sélecteur « Mode d'autorisation » de Claude Code détermine la fréquence à laquelle Claude demande une autorisation avant de modifier un fichier ou d'exécuter une commande. Ce guide compare les 6 modes (Manuel, Accepter les modifications, Plan, Auto, Ignorer les permissions, dontAsk), explique comment basculer avec Shift+Tab et comment choisir le bon mode en toute sécurité.

Le curseur « Effort » de Claude Code, de « Plus rapide » à « Plus intelligent », règle la quantité de travail consacrée à chaque réponse. L'API compte 5 niveaux (low–max), et Ultracode est un interrupteur à part, utilisable à n'importe quel niveau. Ce guide explique chaque palier, la compatibilité des modèles et comment le configurer.

Les hooks de Claude Code sont des commandes shell définies par l'utilisateur qui s'exécutent automatiquement à des points précis du cycle de vie de Claude Code, rendant « cela doit toujours se produire » réel et déterministe sans dépendre du jugement du LLM. Les événements classiques sont au nombre de neuf — SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Notification, Stop, SubagentStop, SessionEnd, PreCompact — dont PreToolUse et d'autres peuvent bloquer (en empêchant les éditions de fichiers protégés ou les commandes dangereuses). Vous les configurez dans settings.json sous la clé "hooks" sous la forme nom d'événement -> matcher -> type + command. Le contrat d'E/S : un hook reçoit du JSON sur stdin (session_id, tool_input, etc.) et renvoie via un code de sortie 0 (succès) / 2 (bloquer, avec stderr transmis à Claude) ou du JSON structuré (continue, decision:block, permissionDecision : deny/allow/ask). Le principe clé est « les hooks peuvent resserrer mais pas assouplir les restrictions » (le refus l'emporte toujours, bloque même sous bypassPermissions ; un mod de plugin peut passer outre dans certains cas). Cas d'usage classiques : formatage automatique après les éditions (PostToolUse + Edit|Write), protection des fichiers critiques, blocage des commandes dangereuses, réinjection de contexte (SessionStart), notifications/journal d'audit, et tester avant de s'arrêter (Stop). Côté sécurité, les hooks exécutent des commandes shell arbitraires avec vos privilèges, donc ne configurez que ceux de confiance et validez/mettez les entrées entre guillemets ; dans les sessions interactives, les hooks des fichiers de paramètres ne s'exécutent pas tant que vous n'avez pas fait confiance au dossier (une fonction de sécurité), et les modifications directes de ces fichiers sont normalement prises en compte automatiquement. Sur la base de la documentation officielle, ancré sur les neuf événements classiques et le contrat d'E/S.

Le message « You've hit your session limit · resets 3:45pm » de Claude Code n'est ni une erreur ni un bug : c'est ainsi que fonctionnent les limites d'usage de l'abonnement. La référence officielle en liste quatre variantes : session (la fenêtre glissante de 5 heures), weekly (la fenêtre hebdomadaire), et Opus et Sonnet (plafonds propres à une famille de modèles) ; comme les limites de session et hebdomadaire sont communes à tous les modèles, changer de modèle ne rétablit pas l'accès. Cet article explique le sens de chaque message et l'évolution du texte depuis l'ancien « Claude usage limit reached », ce qui épuise le quota et quoi faire au moment du plafond : changer de modèle avec /model pour un plafond Opus/Sonnet, attendre la réinitialisation (automatique depuis la v2.1.234), utiliser des crédits d'usage avec /usage-credits ou basculer sur l'API à l'usage. Il montre aussi comment voir ce qu'il reste avec /usage et les messages ressemblants qui ne sont pas votre limite.

À l'ère où c'est l'IA qui écrit le code, la compétence à plus forte valeur se déplace de « écrire du code » vers « écrire la spécification » — et la pratique qui incarne ce changement est le développement piloté par la spécification (Spec-Driven Development, SDD). Le SDD place la spécification au centre du projet comme source de vérité, et un agent IA en déduit la conception, le découpage et l'implémentation au lieu de coder immédiatement. L'essentiel est que chaque étape laisse un document (souvent en Markdown) que l'étape suivante lit. Ce guide pour débutants explique ce qu'est le SDD (la spécification fait foi ; le code en est un dérivé), pourquoi il s'impose maintenant (il prévient le « mur des trois mois » de dette technique et de dérive des besoins du vibe coding dès l'étape de conception), les quatre étapes de base (Specify → Plan → Tasks → Implement), les principaux outils (GitHub Spec Kit avec plus de 140 000 étoiles et plus de 30 agents pris en charge, AWS Kiro avec son flux Requirements → Design → Tasks et son routeur Auto, ainsi que BMAD, OpenSpec, Tessl, Google Antigravity et Cursor), quand l'utiliser plutôt que le vibe coding (un hybride : le vibe pour explorer, le piloté par la spécification pour livrer, avec une revue humaine obligatoire), et comment l'essayer dès aujourd'hui. À l'ère de l'IA, ceux qui montent sont ceux qui savent définir précisément quoi construire, pas ceux qui écrivent le code le plus vite.

Sortir est difficile, parler aux gens est éprouvant, vous ne travaillez pas en ce moment — même ainsi, la possibilité de transformer « depuis chez soi, sans rencontrer personne, à son propre rythme » en revenu s'est réellement élargie avec l'IA. Ce guide expose, aussi honnêtement et doucement que possible, le premier pas pour une personne en situation de hikikomori (un reclus qui se retire du monde) ou NEET afin de gagner sa vie depuis chez elle, à partir de zéro, grâce à l'IA. Il promet d'emblée de ne pas dire « tout le monde peut facilement gagner des milliers par mois » (souvent un mensonge ou un appât commercial) et écrit ouvertement la difficulté réelle, le temps et les précautions. Il couvre pourquoi IA x travail à domicile convient (réalisable sans face-à-face, facile à démarrer de zéro, à son propre rythme — l'IA abaisse le mur comme un partenaire), les trois vérités honnêtes (vous ne gagnerez pas tout de suite, un premier objectif est vos premiers euros ; l'IA amplifie l'effort, ce n'est pas de la magie, tout multiplié par zéro fait zéro ; ce sont ceux qui continuent, pas les plus intelligents, qui obtiennent des résultats), des façons de gagner sans parler à personne (rédaction, transcription/sous-titres, éléments visuels par IA, mise en ordre de données, vérification de traductions, produits numériques — en choisir un d'abord), le premier pas aujourd'hui (toucher une IA gratuite, choisir un domaine, faire un échantillon d'entraînement — faire avant de gagner), comment empiler de petites victoires (portfolio, une mission peu payée, accumuler les évaluations, augmenter tarif/volume — collectionner des victoires, pas des montants, le premier travail vaut le plus), comment tenir et protéger son moral (ne pas se comparer, découper en petit, se reposer est permis, abandonner le perfectionnisme, ne pas porter cela seul — accompagnement vers l'emploi et services d'écoute), et des précautions sur les arnaques, le risque de tout laisser à l'IA, et les impôts/personnes à charge (éviter les offres « payez d'abord », sur les plateformes de crowdsourcing légitimes, l'inscription et la mise en vente sont en principe gratuites, vérifier les informations officielles). Ce n'est pas « tout le monde, facilement », mais un pas que vous pouvez faire existe vraiment — retrouvez « moi aussi, je peux le faire », un pas à la fois.