Construire Oramus avec Claude — chronique d'un Lab d'IA construit en mode chef d'orchestre

Construire son outil avec son outil. C’est l’exercice méta qu’a constitué la mise en chantier du site que vous êtes en train de lire — un Lab d’IA appliquée, construit en grande partie avec l’IA. Ce dossier est donc, par nature, plus personnel que les autres : il raconte une méthode de travail, des choix techniques, et les impasses traversées pour arriver au site actuel. Pas un récit héroïque. Plutôt un compte-rendu honnête de ce que ça coûte et de ce que ça apprend.

Oramus est l’entité que j’ai créée pour orchestrer ma transition d’un profil « généraliste WordPress » vers de l’intégration IA et du développement produit pour PME francophones. Il fallait un site, mais surtout un produit qui démontre le discours plutôt que de le réciter. Le Lab — un diagnostic IA en ligne qui identifie 3 à 5 cas d’usage concrets pour une PME en 30 secondes — joue ce rôle. Le site et le produit ont été construits en parallèle, sur plusieurs semaines de travail focalisé, en autonomie complète.

Le pari de départ

Trois contraintes structurantes posées avant la première ligne de code.

Pas de cofondateur technique, pas d’équipe. L’objectif était précisément de démontrer ce qu’on peut viser seul aujourd’hui sur une stack moderne, avec une utilisation maîtrisée de l’IA. Si l’expérience nécessitait du renfort externe pour aboutir, c’était sa propre invalidation.

Stacks que je connaissais moins. WordPress et Next.js, je les pratique depuis des années — pas de défi d’apprentissage. À l’inverse, Astro 5, Cloudflare D1, Cloudflare Workers AI, le déploiement Cloudflare Pages avec adapter SSR : autant de zones où je voulais lever mes propres lacunes en construisant un produit réel plutôt que des projets jouets. C’est généralement la meilleure méthode pour ancrer durablement une stack.

Un produit complet, pas un MVP minimal. Auth par magic link, quota mensuel par compte, rétention auto à 30 jours, protection anti-spam, archivage avec mail PDF, dark mode, RGPD à jour, sitemap dynamique, llms.txt. L’idée n’était pas de prouver que je sais sortir un truc qui tourne en deux jours — l’idée était de prouver que je sais sortir un truc qui ressemble à de la production réelle, avec les attributs qu’on attend d’une vraie infrastructure de service.

La méthode — trois usages de Claude, pas un

Une confusion fréquente dans les discussions sur le travail avec une IA, c’est de parler de « Claude » comme d’une entité unique. En réalité, j’ai utilisé Claude par trois canaux complémentaires, qui correspondent à trois moments du travail très différents.

Claude.ai (l’interface chat) sert à la conception. Quand je dois trancher entre deux architectures, identifier les angles morts d’une décision, ou faire le tour d’un sujet que je ne maîtrise qu’à moitié, j’ouvre un long fil de dialogue. Pas pour qu’il décide à ma place, mais pour faire affleurer plus vite les options que je n’aurais peut-être pas vues seul. La règle d’or que je me suis donnée : c’est moi qui décide, Claude qui suggère. Et je décide en connaissance des contraintes du projet, que lui ne voit qu’en partie.

Claude Code (le CLI agentique) sert à l’implémentation. Une fois que la décision est posée et que je sais ce que je veux, je passe à Claude Code pour produire et modifier le code source. Pas en mode « libère le clavier et regarde », mais en mode supervision continue : je lis chaque diff, j’accepte ou je corrige, je relance des passes ciblées. Pour ce projet, ça représente la majorité du temps passé — non pas parce que Claude Code fait tout, mais parce que c’est l’outil le plus efficace pour traverser rapidement des chantiers répétitifs (tests, typings, refactors stylistiques cohérents).

L’API Anthropic Claude est utilisée par le produit lui-même — pas par moi. C’est elle qui génère le contenu des diagnostics IA dans le Lab, via le modèle Claude Sonnet en mode streaming. C’est l’usage le plus simple sur le papier (un POST avec un prompt système et un user content), et le plus exigeant en pratique parce qu’il est exposé à l’utilisateur final et doit être fiable, rapide, et coût-maîtrisé.

Cette segmentation explicite a un avantage qui ne se voit pas au premier regard : elle force à savoir, à chaque moment, quel niveau de réflexion est mobilisé. Dialoguer pour décider n’est pas la même opération mentale que diriger un agent pour produire. Mélanger les deux mène à des décisions prises trop vite ou à des implémentations qui dérivent.

La stack — choix et arbitrages

Six briques structurent l’ensemble :

• Astro 5 pour le rendu — pré-rendu statique des pages éditoriales, SSR sur les pages dynamiques (Lab, compte, rapport). Bon compromis entre la rigueur d’un framework moderne et le coût bas d’un site largement statique.
• Cloudflare Pages pour l’hébergement — gratuit jusqu’à des volumes substantiels, CDN mondial inclus, déploiement continu via GitHub.
• Cloudflare D1 pour la base de données — SQLite serverless, ~5 €/mois pour notre profil de charge, suffit largement pour les users + sessions + diagnostics persistés 30 jours.
• Anthropic Claude API pour la génération IA — Claude Sonnet en streaming, contrôle fin sur le prompt système, sortie en JSON structuré que je parse et valide côté serveur avant affichage.
• DataForSEO pour l’analyse SEO du diagnostic enrichi — concurrents organiques, métriques de trafic estimé, le tout via leur API REST.
• Brevo pour les mails transactionnels — magic link de connexion et envoi de rapport PDF aux utilisateurs qui le demandent.

Le coût d’exploitation total tourne autour de 10 à 20 € / mois pour le hosting + DB, plus l’usage variable des APIs Anthropic et DataForSEO qui sont à la requête. C’est l’argument économique du sans-serveur quand on l’exécute correctement.

Le pipeline du Lab — ce qui se passe pendant les 30 secondes

Le geste utilisateur est trivial : on tape une URL, on clique. Le côté serveur fait beaucoup plus de choses qu’il n’en paraît.

1. Fetch de l’URL côté serveur — récupération du HTML de la page d’accueil. Si le site est protégé ou en SPA, l’utilisateur bascule sur le mode « coller le contenu » qui contourne le fetch.
2. Compression du contenu — extraction du signifiant (titre, H1, paragraphes textuels, navigation) en éliminant le bruit (scripts, styles, navigation footer répétée). On passe typiquement d’un HTML de 200 KB à un contenu structuré de 4 à 8 KB.
3. Détection de stack technique — regex sur le HTML pour identifier la stack (WordPress, Shopify, Wix, Webflow, Next.js, etc.). L’info est passée à Claude pour qu’il adapte ses recommandations au contexte technique.
4. Pour le mode enrichi uniquement : appel DataForSEO pour récupérer 25 concurrents organiques, filtrage en deux passes (liste de domaines généralistes à exclure, puis ratio de trafic plausible), sélection des 5 plus pertinents avec analyses détaillées.
5. Appel Anthropic Claude en streaming — prompt système qui définit le format de sortie JSON attendu, user content qui contient le contenu compressé + concurrents + stack. Le streaming est exposé au client via Server-Sent Events.
6. Affichage progressif — pendant les 30 à 50 secondes que dure le diagnostic, un stepper avec barre de progression et timer affiche ce qui se passe, avec des sous-labels qui défilent (« Lecture du contenu… », « Identification des signaux… », « Calcul des gains estimés… »). C’est ce qui fait que l’attente est tolérable.
7. Persistance en D1 pour les diagnostics enrichis, avec rétention auto à 30 jours et cleanup lazy. Affichage dans /lab/mon-compte.

Chaque étape a son histoire de bugs traversés. Trois valent d’être documentées.

Trois pièges qui ont coûté plus de temps que prévu

Le « Premature close » Anthropic streaming

Première intégration de l’API en streaming sur Cloudflare Pages, et erreur récurrente : Premature close côté client après quelques secondes. La connexion SSE se ferme avant que le streaming Claude n’ait terminé.

Cause identifiée après plusieurs heures de debug : l’usage initial de la SDK Anthropic mêlait client.messages.create({ stream: true }) (un async iterator moins robuste sur Cloudflare Workers) avec un consume direct. La correction canonique : client.messages.stream() qui retourne un objet Stream avec une méthode finalMessage() qui attend la complétion complète. Une fois ce pattern adopté, plus aucun premature close depuis.

C’est typiquement le genre de bug qu’on ne devine pas — la documentation est correcte, mais le décalage entre les deux patterns d’usage de l’API n’est pas explicité. Il faut tomber dedans, chercher, comprendre.

Le streaming local qui ne reproduit pas la prod

Pendant le développement en local, le streaming Anthropic ne fonctionne tout simplement pas correctement avec pnpm dev (qui utilise Miniflare, le simulateur de Workers fourni avec Wrangler). Le stream tronque, ou arrive d’un seul coup à la fin, ou se ferme prématurément.

Le décalage entre local et prod sur ce point a été suffisant pour justifier une règle : toute feature qui implique le streaming Claude est validée en prod, pas en local. C’est inconfortable au quotidien — il faut déployer pour tester — mais c’est la seule manière de ne pas perdre une demi-journée à debugger un bug qui n’existe qu’en local.

pnpm minimumReleaseAge et les packages quotidiens

J’ai posé une règle pnpm minimumReleaseAge: 24h au début du projet — pour ne jamais installer un package publié dans les 24 dernières heures, par sécurité contre les supply chain attacks. Bonne idée en théorie.

En pratique, certains packages — au premier rang desquels @cloudflare/workers-types — publient une version par jour. Toute installation pnpm add @cloudflare/workers-types plante avec l’erreur version too recent. Solution adoptée : toujours pin avec une version explicite légèrement antérieure, par exemple ~4.20260610.0 plutôt que latest. Ça résout, mais demande de connaître la convention de nommage des releases dudit package pour ne pas se tromper de format.

Ce que ce projet apprend

Trois choses tiennent à l’expérience.

Le rôle « chef d’orchestre » n’est pas un effet rhétorique. Il a un contenu opérationnel précis : tenir l’architecture, segmenter les décisions, et utiliser l’IA comme un exécutant efficient sur les zones où on a déjà la carte mentale. Un développeur qui n’a pas l’architecture en tête laissera l’IA dériver, va accepter des bouts de code incohérents avec le reste, et finira par un projet difficile à maintenir. Un développeur qui tient l’architecture peut, à l’inverse, gagner un temps considérable sur l’implémentation. Le différentiel ne vient pas de l’outil, il vient du conducteur.

Le « tout en quelques jours grâce à l’IA » est un mythe pour les projets sérieux. Ce site représente plusieurs semaines de travail focalisé. La productivité gagnée se voit ailleurs : dans la densité du livrable, pas dans la durée totale. À temps de travail équivalent, on livre maintenant un produit plus complet, mieux testé, plus rigoureux, plus durable. Mais la durée pour atteindre un niveau de qualité donné ne s’effondre pas d’un facteur dix. Elle baisse de 30 à 50 %, ce qui est déjà considérable, et explique pourquoi on peut viser des projets aujourd’hui qu’on n’aurait pas osés en solo il y a trois ans.

Tester en prod n’est plus un anti-pattern, c’est une nécessité. Quand l’infrastructure dépend de comportements spécifiques à Cloudflare Workers, et que les outils de simulation locaux ne reproduisent pas fidèlement la prod, accepter que certaines validations doivent se faire en environnement réel n’est pas un compromis — c’est la seule méthode efficace. Les feature flags, les déploiements de preview par PR, et une discipline de tests automatisés en CI compensent l’incertitude. Le confort du local-first qu’on a connu sur les stacks classiques (LAMP, Node monolithique) n’est plus systématique.

Le projet continue d’évoluer — les prochains chantiers incluent un audit côté observabilité (Sentry ou alternatif), une refonte de la page À propos, et l’ajout progressif de dossiers techniques comme celui-ci. Mais l’infrastructure posée tient sans modification structurelle : c’est ce qu’on attend d’un projet correctement orchestré, où les semaines passées au départ paient ensuite chaque mois en stabilité.

Et pour ceux qui se posent la question : oui, ce dossier-là aussi a été co-écrit avec Claude. C’est cohérent avec son sujet.