Solo, vingt features, AGPL : deux mois à coder Maintenant avec Claude

Le résultat avant l’histoire

Maintenant, c’est un binaire Go de quelques mégaoctets qui tourne à 17 Mo de RAM en idle. Tu le drop dans un container, il auto-discover tes containers Docker, Swarm et Kubernetes, surveille tes endpoints HTTP et TCP, tes jobs cron via heartbeats, tes certificats TLS, les ressources de chaque service, détecte les images qui ont une mise à jour disponible, repère les configurations réseau dangereuses — ports DB exposés, bindings 0.0.0.0, containers privilégiés — expose une status page publique, balance les alertes via webhook, Discord, et en édition Pro Slack, Teams, email. Il embarque un serveur MCP avec OAuth2 pour qu’un assistant IA puisse interroger ton infra directement. Il stocke tout dans SQLite en WAL, sans dépendance externe. Pas de Postgres, pas de Redis, pas de queue. Le frontend Vue 3 + TypeScript + Tailwind est embarqué dans le binaire via embed.FS. Une seule image Docker, un seul process, zéro orchestration.

J’ai construit ça seul. AGPL-3.0 en open-core, édition Pro à 29€/mois pour les agences et freelances qui gèrent du parc client, dual-licensing avec un CLA pour les contributeurs externes. License signée Ed25519, distribuée via une variable d’env. Site vitrine sur Hugo + PocketBase qui sert le checkout Stripe et la vérification de license. Documentation complète. Et tout ça, je l’ai fait avec Claude Code en boucle continue.

C’est là que la plupart des articles “j’ai construit X avec une IA” décrochent. Ils racontent l’enthousiasme, les screenshots, le “look ma, no hands”. Ce post fait l’inverse. Je vais te dire ce que ça a vraiment changé, ce qui m’a fait perdre du temps, et pourquoi le code n’est probablement pas la partie la plus intéressante de l’histoire.

Le timing

J’ai démarré en mars 2026, même si j’avais commencé à réfléchir à l’idée en amont. Donc deux mois, deux mois et demi de boulot sérieux pour arriver à ce que je viens de décrire — vingt features, dual-licensing, site, doc, MCP server.

Ce qui n’aurait pas été possible si je découvrais Claude Code en même temps que je codais Maintenant. Ça fait à peu près un an et demi que je bosse avec Claude Code au quotidien — sur d’autres projets, sur des refactorings clients, sur des explorations qui ont fini en classeur. Les skills custom, les réflexes de vérification, l’instinct de quand cadrer serré et quand laisser respirer : tout ça pré-existait à Maintenant. Le produit a été construit sur la pratique accumulée, pas découvert pendant la construction.

C’est une distinction qui compte parce qu’elle change ce que cet article peut promettre. Si tu démarres aujourd’hui avec Claude Code et que tu vises vingt features en deux mois, tu vas te casser les dents. Pas parce que l’outil ne le permet pas — il le permet — mais parce que la pratique de l’outil est elle-même un investissement, et que les deux mois courts ne marchent que sur dix-huit mois longs en amont.

Pourquoi Maintenant existe

Les gens qui hostent du Docker sérieusement se retrouvent toujours avec la même pile : Uptime Kuma pour les uptime checks, Portainer ou Dozzle pour les containers, un script cron pour les certificats TLS, un Grafana à moitié configuré pour les métriques, et une status page sur un Notion public. Cinq onglets, cinq bases de données, cinq logiques d’alertes qui ne se parlent pas.

Maintenant remplace les cinq. Pas parce qu’il fait chacun mieux que le spécialiste — Grafana sera toujours plus puissant pour les métriques. Mais parce que la friction de jongler entre cinq outils coûte plus cher que le delta de qualité sur chacun. Quand tu observes un problème, tu veux voir l’état du container, ses logs récents, le check HTTP qui tape dessus, le certificat de l’endpoint et la conso CPU dans la même page. Pas en swipant entre cinq dashboards.

Le principe est strict : observer, jamais agir. Maintenant ne redémarre rien, ne pull rien, ne touche rien. C’est un témoin. Ça simplifie le code, ça simplifie le modèle de sécurité, ça simplifie la confiance qu’un client doit placer dans le truc qu’il déploie. Read-only c’est non négociable.

C’est un produit qui a une raison d’exister indépendamment de qui l’a codé ou avec quoi. Ça compte pour la suite.

Ce que Claude a vraiment accéléré

Première chose à clarifier : je suis dev Go senior, CTO fractionnel, et je fais du web depuis vingt-cinq ans — j’hébergeais déjà des sites en PHP et Flash sur des serveurs dédiés LAMP quand le mot “DevOps” n’existait pas. Je ne suis pas en train d’apprendre à coder avec un LLM. Donc quand je dis “Claude m’a accéléré”, je ne parle pas de “il a écrit le code que je ne savais pas écrire”. Je parle de bande passante.

Le frontend, par exemple. Mon stack quotidien c’est Go, du backend, des protocoles réseau, du système. Vue 3 avec TypeScript et Tailwind, c’est pas mon terrain naturel. Je peux le faire, mais lentement, en doutant des conventions, en perdant du temps à chercher si on fait ça avec <script setup> ou avec une Composition API explicite. Avec Claude qui connaît la stack mieux que moi, j’attaque un nouveau composant comme si j’avais un dev front à mes côtés. Pas pour qu’il décide à ma place — je décide de l’architecture, de l’UX, des conventions visuelles — mais pour qu’il porte la charge cognitive du framework. Le résultat : un dashboard temps réel avec uPlot pour les charts, PWA, SSE en streaming, qui aurait été un projet à part entière en solo classique.

Le scaffolding de modules nouveaux, pareil. Le serveur MCP avec son OAuth2 PKCE et sa rotation de refresh tokens, le scan OSV.dev pour les CVE avec scoring de risque, les insights réseau qui inspectent les manifests OCI pour mapper les images aux écosystèmes logiciels. Ce sont des features qui demandent chacune deux à cinq jours pleins en mode classique : lire les specs, comprendre les API, écrire le code, tester. Avec Claude, je passe les deux à cinq jours à valider, raffiner, intégrer correctement dans l’architecture existante. Le passage du blanc à un premier draft fonctionnel se fait en une après-midi. C’est pas juste plus rapide — c’est qualitativement différent. La friction de démarrer un module disparaît, donc je commence des trucs que j’aurais reportés indéfiniment.

Les refactorings de masse. Au moment où Maintenant a passé les dix services internes, l’architecture initiale a craqué. Je me suis retrouvé avec un main.go à six cents lignes qui instanciait tout dans le mauvais ordre, des dépendances circulaires latentes, un bus d’événements typé à coups de interface{}. Refactorer ça à la main, c’est trois semaines à pleurer, à casser cinq choses à chaque commit, à ajouter des tests qui n’existaient pas. Avec un skill go-refactoring que j’ai écrit pour Claude — qui encode mes conventions de typage d’événements, d’extraction de l’App container, de dependency injection, de couverture de tests — j’ai fait le refactoring en quatre jours, avec une couverture qui est passée de honteuse à respectable, et zéro régression en prod.

Tout ce qui n’est pas du code. La doc qui suit le code de près au lieu de dériver. Les pitchs cold-email pour les YouTubers et journalistes tech, qui demandent à chaque fois une reformulation contextualisée et qui sont la corvée que tout solo dev procrastine. Le copy LinkedIn, en français cassuel direct, avec le lien dans le premier commentaire et pas dans le post pour ne pas se faire shadow-ban par l’algo. Les drafts d’articles, exactement comme celui-ci. Le copy de la landing Pro. Les CGV, le DPA, les mentions légales. Toute cette charge qui historiquement fait qu’un solo dev finit avec un super produit et une comm anémique.

C’est là que le levier devient déraisonnable. Le code reste fait par moi, sous mon contrôle, avec mes choix d’architecture. Mais les vingt-huit autres choses qui font qu’un produit existe vraiment — la doc, le site, la com, l’outreach, la facturation, la légalité — sont d’un coup possibles à un niveau qui était hors de portée pour un humain seul.

Ce qui m’a fait perdre du temps

Si je m’arrêtais là cet article serait vendable et faux. Voilà la partie honnête.

Les hallucinations de features. Plusieurs fois Claude a généré du contenu — pour LinkedIn, pour la doc, pour un pitch — qui mentionnait des canaux d’alerte que Maintenant n’a pas. Telegram, Gotify, Ntfy. Aucun n’existe dans le produit. Ils existent dans Uptime Kuma, dans la culture self-hosted, donc statistiquement ils émergent quand on parle de monitoring. Si je n’avais pas relu, j’aurais publié des claims faux qui auraient torpillé ma crédibilité. Le coût n’est pas dans la correction — c’est dans la vigilance permanente. Chaque sortie, je dois retourner au README de Maintenant et vérifier. Ce coût de vérification est constant et il ne diminue pas avec le temps.

La sur-ingénierie quand le scope n’est pas borné. Quand je regarde mes données d’usage Claude Code — 263 commits sur 90 sessions, environ 440 heures cumulées — le pattern de friction le plus fréquent n’est pas l’hallucination factuelle, qui ne sort que 2 fois sur cette période. C’est le “wrong approach” (31 incidents) et le “misunderstood request” (25). Soit un ratio de 56-pour-2 entre dérive de scope et hallucination. La conclusion est nette : mes specs étaient claires, Claude dérivait quand même vers de la sur-ingénierie. Une refacto qui voulait factoriser deux trucs qui n’avaient rien à voir, une couche d’abstraction supplémentaire pour “préparer le futur”, un fichier baseline gitignored force-add parce qu’un tasks.md le mentionnait — et un rebase à faire pour rollback. Le risque dominant n’est pas que le LLM invente des trucs faux, c’est qu’il fasse des trucs justes mais non demandés. La parade est mécanique : “tu touches à X, tu ne modifies pas Y, et tu ne factorises rien qui ne soit pas explicitement demandé”, en début de chaque tâche.

Le mauvais diagnostic avant vérification. Pattern voisin, mécanique différente. Claude propose un root cause, déclare que c’est fixé, et il faut le forcer à reproduire le bug avant qu’il propose un fix. Ce n’est pas une question de capacité — sur les sessions où je le pousse à reproduire concrètement, lire les logs, tester la requête avant de proposer une correction, il trouve juste. C’est un défaut d’instinct : par défaut, le modèle saute à la conclusion. La parade est dans le prompt par défaut : “reproduce le bug avant de proposer un fix”, et toujours ancrer l’environnement et la couche au début d’un debug. C’est une discipline de cadrage, pas une limite du modèle.

Le détour SaaS. À un moment de doute commercial, j’ai exploré l’idée de proposer Maintenant en mode SaaS avec un agent côté client. C’est une architecture séduisante pour un LLM — elle ouvre plein de directions techniques. Sauf que pour ma cible, qui est précisément des sysadmins et CTO sensibles à la souveraineté des données, le SaaS détruit le pitch. J’ai perdu une semaine à explorer ça avant de revenir à self-hosted only. Le LLM ne pouvait pas savoir tout seul que cette direction était mauvaise stratégiquement — c’est un coût sur moi pour ne pas l’avoir cadré dès le départ.

Le coût des skills custom. Tous les avantages que je décris au-dessus, ils n’existent pas en sortie de boîte. Ils existent parce que j’ai écrit des skills qui encodent mes conventions, mes règles, mes anti-patterns. go-refactoring, mobile-first-audit pour le frontend Vue/Tailwind, linkedin-post-generator pour le ton casuel français, linkedin-lead-capture pour analyser les commentaires sur mes posts, linkedin-trend-research pour le radar éditorial. Et par-dessus, j’ai implémenté Maintenant en suivant le workflow GitHub Speckit — du spec-driven development qui force à formuler le besoin, le plan, et le découpage en tâches atomiques avant d’écrire la moindre ligne. Sans cette discipline, les sorties partent dans tous les sens. Avec, elles convergent. Mais écrire les skills prend du temps. Les maintenir aussi. Et adopter Speckit demande de la rigueur sur le moment où on serait tenté d’aller “vite”. C’est un investissement réel, pas un free lunch.

Le compromis entre vélocité et compréhension. Certains modules que Claude m’a aidé à scaffold rapidement, je les comprends moins bien que si je les avais écrits ligne par ligne. C’est une dette technique différente de la dette classique : je pourrais relire et m’approprier, mais à chaque fois que je n’ai pas pris ce temps, je suis moins outillé pour intervenir vite quand un bug remonte. Sur les modules critiques, je relis. Sur les modules périphériques, je laisse. C’est un arbitrage conscient mais ça a un coût.

Le vrai retournement : tout ce qui n’est pas du code

Si je devais isoler la chose qui a le plus changé entre coder Maintenant avec Claude versus le coder seul, ce ne serait pas la vitesse de production de code. C’est le ratio entre temps de dev et temps de tout-le-reste.

Historiquement, un dev solo passe quatre-vingt pour cent de son temps sur le code et néglige le reste. La doc est obsolète, le site vitrine est moche, le copy LinkedIn n’existe pas, les pitchs YouTube ne se font jamais, les CGV viennent d’un template trouvé sur un blog. Le produit est techniquement solide et commercialement invisible.

Avec un LLM bien orchestré, ce ratio s’inverse. Le code reste central mais il occupe moins d’espace mental absolu. La doc se met à jour en quasi temps réel parce que rédiger 200 mots prend deux minutes. Le site vitrine est itéré chaque semaine. Le copy LinkedIn devient une routine du matin. Les pitchs cold-email aux YouTubers — DB Tech, Christian Lempa, Techno Tim, NetworkChuck — partent en série au lieu de mariner six mois dans un draft. Les CGV sont relues, le DPA existe, la mention légale est à jour. Le produit prend la forme qu’il aurait dû avoir tout le temps.

Et ça, ce n’est pas du code. C’est un changement organisationnel. Le solo dev de 2026 qui sait orchestrer un LLM peut tenir une surface produit qui en 2022 demandait une équipe de trois ou quatre personnes — un dev, un rédacteur technique, un commercial à temps partiel, un community manager.

C’est la phrase qu’il faut retenir : le LLM ne lift pas un junior à un niveau senior, il lift un senior à un niveau d’équipe. La compétence individuelle reste le plafond. Mais le coût des activités annexes — qui historiquement consommaient l’énergie du dev — s’effondre. Donc la même compétence peut couvrir beaucoup plus de surface produit.

Ce que je retiens, pratiquement

Si tu veux faire pareil — pas forcément un produit de monitoring, n’importe quel projet ambitieux en solo — voilà ce qui marche pour moi.

Écris des skills custom dès le début. Pas après six mois quand tu en as marre de re-prompter les mêmes conventions. Dès la troisième fois que tu corriges la même chose, c’est un skill. Les miens font entre deux cents et mille mots, ils encodent les anti-patterns, les règles d’archi, le ton, les références. Ils transforment Claude de “stagiaire intelligent mais sans contexte” en “collègue qui connaît votre codebase”.

Sépare les phases. Pour les features non triviales, j’utilise le workflow GitHub Speckit — un cadre de spec-driven development qui force à produire le spec, le plan d’implémentation et le découpage en tâches atomiques avant d’écrire du code. La phase de pensée est explicite et critiquable avant que le LLM ne commence à scaffolder. C’est ce qui évite les dérives, parce que tu attrapes les mauvaises directions au stade du markdown plutôt qu’au stade des deux mille lignes à reverter.

Interromps fermement et tôt. Le coût d’un revert tardif est dix fois supérieur au coût d’un “stop, tu débordes” précoce. Quand Claude commence à toucher à des choses non demandées, à factoriser sans qu’on lui ait demandé, à claim qu’un truc marche sans avoir vérifié — n’hésite jamais. Coupe, recadre, force la reprise. La différence entre une session qui finit propre et une session qui finit en dette technique, c’est presque toujours la latence d’interruption. Plus tu attends, plus le rollback coûte cher.

Vérifie tout ce qui est claim factuel. Chaque feature mentionnée dans un post, un pitch, une doc — retour au README. Chaque chiffre — vérifie. Chaque comparaison concurrentielle — vérifie. Le LLM est un excellent générateur de plausibilité ; il ne distingue pas le vrai du plausible. C’est ton job.

Garde la décision stratégique pour toi. Le LLM peut explorer des directions, peser des trade-offs techniques, proposer des architectures. Il ne peut pas décider de ton positionnement marché, de ton modèle de licensing, de ta cible commerciale, de tes prix. Ces décisions-là, prends-les seul ou avec d’autres humains qui connaissent ton contexte. Sinon tu finis avec une semaine perdue sur un détour SaaS.

Investis dans le tout-sauf-code. C’est là que le levier est le plus fort et c’est là que les solo devs ont historiquement le plus de retard. La doc, la com, l’outreach, le légal, la facturation. Si tu ne fais que coder mieux, tu rates les neuf dixièmes du gain.

Le bilan

Maintenant existe. Il a des stars sur GitHub, des pulls Docker, des utilisateurs qui ouvrent des issues et des discussions sur le repo. Le Pro tier a des conversions. Le produit n’est pas une démo de “look ce que j’ai fait avec une IA” — c’est un truc que les gens utilisent en prod sur leurs serveurs dédiés et leur infra client.

Et il existe seulement parce que j’ai pu, en solo, tenir une surface produit qui aurait demandé une petite équipe il y a trois ans. C’est ça la vraie histoire. Pas l’IA qui code. La compétence d’orchestration qui démultiplie un dev senior.

Le code ne disparaît pas. Le craft ne disparaît pas. La rigueur architecturale, la discipline de test, la lecture critique de chaque sortie, la connaissance du domaine — tout ça reste indispensable, et même plus qu’avant parce que sans ces gardes-fou un LLM produit du joli plausible qui finit en prod et te coule. Mais le ratio entre “ce que tu sais faire” et “ce que tu peux livrer” a changé radicalement. Et pour un solo dev avec une vision claire, c’est probablement la meilleure période depuis l’invention du framework web.

Maintenant est en AGPL-3.0, dispo sur maintenant.dev — un binaire Docker, zéro dépendance externe, pensé pour les pros qui hostent du parc client en prod.