Ma stack IA pour développer des produits sans me ruiner

Est-ce qu’on peut vraiment construire des applications aujourd’hui avec de l’IA ET seulement 20 balles par mois ?

Je développe actuellement deux projets : Hakanai (pour les blogs statiques) et surtout Writizzy, qui vient de passer la barre des 550 utilisateurs en 6 mois. Mais tout cumulé, je ne dégage pas plus de 250 euros par mois et j’ai pour principe de ne pas dépenser plus que ce que gagne.

Donc j’ai une grosse contrainte, le budget. J’essaie de construire mes applications sans cramer des tokens à la vitesse de la lumière. Et je voulais vous partager comment je m’y prends.

C'est quoi Writizzy ?

Petit rappel pour situer le projet : Writizzy, c'est un équivalent à Medium ou Substack. Une plateforme pour écrire, envoyer des newsletters et monétiser son contenu. Je pense que c’est vital d’avoir des espaces d’expression hors des GAFAM (et hors US). C’est le logiciel qui fait tourner le blog que vous êtes en train de lire.

Côté code, on a trois gros morceaux :

• Une API en Kotlin.
• Une App admin en Nuxt.
• Une App "blog" (qui sert les contenus) en Nuxt également.

Pour bosser, j’utilise majoritairement Claude. Pourquoi ? Parce que ça reste le modèle le mieux noté sur les benchmarks de code.

Mais je suis proche de changer. Je vous en dis plus à la fin.

Le Context Engineering : Borner l'IA

L’idée pour travailler efficacement, c’est de donner le contexte nécessaire et suffisant au LLM pour limiter son espace de solutions. On veut lui donner des guidelines et des moyens de vérifier lui-même qu’il reste dans les clous. Si vous ne faites pas ça, ne vous étonnez pas que l’IA hallucine des API ou utilise des vieilles versions de doc. C’est normal.

Le fichier Claude.md

C’est le point d'entrée. On y trouve l’objectif du projet, la structure générale pour éviter que l'IA ne parcoure tout le code au pif, et surtout la liste des specs.

Cette liste est fondamentale dans mon process de dév, j’y reviens après. Elle sert également d’index pour Claude.

A noter que j’ai d’autres fichiers claude.md dans des sous répertoires, ces fichiers sont chargés par Claude s’il rentre dedans. J’en ai un par application (app, blog, et api). Ca me sert pour lister les technos à disposition mais j’ai tendance à plutôt utiliser les rules de plus en plus.

Les Rules (.claude/rules)

Ce sont des règles qui peuvent chargées conditionnellement. Par exemple ici, si Claude entre dans le répertoire /app, il charge les règles Nuxt.

Dans ce fichier de rules je définis les patterns que je souhaite voir utiliser, par exemple :
obligation d'utiliser Nuxt UI, de passer un coup de typecheck ou de eslint avant de finir, etc.

Ces règles, je les ai construites empiriquement. C’est a dire que le fichier était vide à l’origine, puis j’ai ajouté des rêgles en fonction des erreurs que je voyais revenir. Plus récemment j’essaie de limiter les explorations de Claude donc je lui demande systématiquement s’il a vu des patterns qu’il faut document dans les rules pour éviter de dépenser des tonnes de tokens en exploration. En plus j’aime pas trop qu’il devine en fonction du code qu’il rencontre.
Exemple de question que je lui ai posé récemment :

je cherche à améliorer les rules que j'ai déjà mis en place. Je trouve que tu as du lire beaucoup de fichiers pour comprendre le contexte et les patterns. Pourquoi ? Fais moi une synthèse des patterns que tu cherchais à connaitre pour voir si on peut en faire des rules

En fait la construction de ces fichiers de rules c’est une sorte de harnais de sécurité. Mais il faut aussi comprendre que ce n’est une garantie car les LLMs vont régulièrement ignorer des rêgles. Donc il faut renforcer les moyens de contrôle : tests, linter, CIn quality gate etc…

Je note d’ailleurs qu’il est plus facile pour ceux qui ont l’habitude de développer avec des bonnes pratiques de bosser correctement avec l’IA. Ces pratiques servent de garde-fous mais pour de nombreuses boites, c'était un peu de la poudre aux yeux mais pas très efficaces en pratique. Et justement, dans les boîtes où ces méthodes ne sont pas matures, l’IA ne décolle pas. On se demande bien pourquoi... Ou pas…

La commande "Analyst"

Une commande c’est une sorte de pré-prompt. J’utilise une commande analyst pour le brainstorming. Je lui demande d’être un spécialiste du blogging, de l'IndieWeb et de la décentralisation. Je lui demande de challenger mes besoins, de détecter les incohérences et surtout d’écrire les specs.

La Spec avant le code

Plus haut je parlais des specs qui sont listées dans le fichier claude.md.

Parlons un peu de mon cycle de dev.. Je passe systématiquement par une spec avant le moindre morceau de code significatif.
(Amusant quand je repense à l’époque où j’ai lancé Malt, il n'y avait pas grand-chose d’écrit au début…)

Avec l’IA, la spec a deux intérêts majeurs :

1. Cadrer le résultat attendu. On définit d’abord la direction, les flow utilisateurs etc..
2. Économiser des tokens dans le futur : En listant les points d'accès techniques et les fichiers clés dans la spec, Claude n'a pas besoin de chercher partout.

En effet, quand Claude va retravailler sur une feature déjà existante, il va utiliser le fichier spec pour comprendre le fonctionnement et surtout facilement revenir sur les fichiers clés. Avec ces specs, il va économiser énormément de temps pour ça, et surtout ce sera plus précis que de le laisser deviner.

Une fois la spec validée, je créé un plan d’implémentation (enfin, Claude créé un plan). Pour ça, j’ai un skill qui lui impose mes pratiques : chaque étape doit être déployable, il doit utiliser des features flags si nécessaire etc...

L'art de gérer sa fenêtre de contexte

Ici faut que je revienne sur la notion de fenêtre de contexte parce que c’est important pour optimiser le budget mensuel. Ce qui coûte cher, ce sont les sessions interminables. À chaque échange, vous renvoyez tout l'historique. Au bout d'un moment, un simple "Ok" peut coûter des dizaines de milliers de tokens. Donc déjà, ça, ça coute cher.

Mais le second effet kiss cool, plus la fenêtre est pleine, plus l'IA devient "bête". J’essaie donc ne jamais dépasser 50% de remplissage. C’est tout l’intérêt des plans d’implémentation. L’idée c’est de découper en petites tâches autonomes et de changer de session régulièrement.

Skills vs MCP : Le combat de l'efficacité

J’ai un peu évoqué les skills avant. J’en fais un gros usage pour être plus efficace. Et il y a un vrai parallèle entre efficacité et cout donc il faut que j’en parle ici.

Un Skill, c’est une compétence chargée à la demande. Par exemple, mon skill Nuxt impose à Claude d'aller lire la doc en ligne (au format Markdown) plutôt que de se baser sur ses données d'entraînement périmées.

J’ai des skills pour différentes choses :

• des apis qui précisent mes patterns de design : api-design, db-migration, write-spec

C’est parfois un peu plus que “juste” préciser des patterns, par exemple le skill db-migration liste exactement les outils à utiliser (Flyway), l’emplacement des fichiers de migration, le format des fichiers. Et côté pattern on retrouve mes principes clés de stratégie de déploiement (rolling update etc…)

• bento, nuxt, nuxt-content, nuxt-ui pour préciser comment aller chercher la doc
• des skills qui expliquent comment utiliser un cli, par exemple sentry-fix-issues qui explique comment utiliser le cli sentry pour récupérer les infos, faire un diagnostique, et corriger

À côté, on a les MCP (Model Context Protocol). C’est puissant également, mais ça prend une place plus importante dans le contexte car chaque méthode du MCP est inclus dans la fenêtre de contexte. Là où un skill, c’est uniquement la description du skill qui est incluse.
Donc Je privilégie les Skills, sauf pour :

• MCP IntelliJ : Pour naviguer proprement dans le code et compiler.
• MCP Stripe : Pour debugger la configuration.
• Claude-mem : censé retenir les décisions clés entre les sessions (je teste encore, le gain n'est pas encore flagrant).

Et le design ?

Récemment, je suis passé sur Claude Design. C’est devenu mon outil de prédilection. Je briefe, je commente des zones, je modifie à la volée, et une fois le HTML propre, je le file à mon agent Claude pour l’implémentation. C’est bien au-dessus de ce que je faisais avant en simple prompting. Les résultats sont vraiment bluffants.

Bilan : Comment tenir le budget ?

Bref, avec tout ça j’arrive à m’en sortir pour 20€ par mois mais j’ai quand même quelques astuces supplémentaires :

• La compression des tokens : J'utilise des stratégies de compression (comme rtk) ou je créé mes propres tools pour n’envoyer aux llms que ce qui est nécessaire.
• Les IA en ligne : Si je veux brainstormer "gratuitement", je vais sur Gemini. Je suis moins fan en général mais ça peut servir de relais avant d’aller vraiment bosser avec l’analyste par exemple.

Mais surtout, j’ai une astuce incroyable… je clos ma session de travail quand Claude m’indique que j’ai dépassé mon quota. Tout simplement.

Quand c'est fini, je m'arrête. Je vais faire de la menuiserie, de la cuisine, j'écris un article (c’est exactement ce que je suis en train de faire là ^^).

Ca a l’air de rien mais cette discipline est en réalité salutaire. Je ne le vois pas uniquement comme une contrainte mais aussi comme une opportunité pour faire autre chose, réfléchir, consolider ce que j’ai appris etc… Ca rejoint ce que j’écrivais sur un article récent, c’est bien de gagner du temps, mais il faut savoir en profiter.

Prochaine étape : je teste des modèles locaux. L'idée est de déléguer les petites tâches d'implémentation à ma machine et de garder Claude uniquement pour la planification stratégique. C’est vraiment le début donc j’en parlerais plus tard.

Si le sujet vous branche, allez faire un tour sur le Slack DevWithAi (plus de 2200 membres). C'est une mine d'or.

Je suis loin d’être le plus avancé possible sur ces sujets et surtout je suis dans un contexte solo. Mais si vous avez vos propres tips à partager, n'hésitez pas en commentaire, ce sera lu avec attention.