How We Built crownmakers.com — Architecture, Stack, and Engineering Decisions

# J'ai construit un site international en une semaine avec Claude. Voici ce que ça m'a vraiment appris.

*Christophe Mannino — Avril 2026*

---

## L'envie de départ : tester en vrai, pas en démo

Il y a quelques mois, j'avais une question simple mais honnête : **est-ce qu'une stack headless moderne — Next.js 14 + Strapi 5 — tient vraiment ses promesses pour déployer un site multilingue rapidement ?**

Pas dans un tutoriel YouTube. Pas dans un projet d'école. Dans un vrai projet, avec un vrai domaine, une vraie infra, de vrais utilisateurs.

Le projet : refondre crownmakers.com, le site vitrine de mon activité — cloud hosting, solutions e-commerce, dropshipping. Un site qui devait fonctionner en français et en anglais, être rapide partout en Europe, respecter le RGPD, et que l'équipe marketing puisse mettre à jour sans toucher au code.

J'avais une deuxième question en parallèle, peut-être plus intéressante encore : **jusqu'où Claude peut aller comme co-pilote sur ce genre de projet ?**

La réponse m'a surpris. Pas là où je l'attendais.

---

## La stack choisie : un pari assumé

**Next.js 14 en export statique.** Pas de SSR à l'exécution, pas de Node.js à maintenir en production. Le site est un ensemble de fichiers HTML/CSS/JS servis depuis un bucket S3. Zéro cold start, zéro crash serveur, taux de cache CDN proche de 100 %.

**Strapi 5.** CMS headless open source, self-hosted, sur une VM Scaleway à Paris. La donnée reste en France (RGPD), l'API REST est consommée au build time par Next.js, et le token API ne touche jamais le navigateur.

**Cloudflare** devant tout. WAF, CDN global, HTTPS automatique, Brotli, HTTP/3.

**GitHub Actions** pour le CI/CD : push sur main → build → sync S3 → purge cache Cloudflare.

Une stack classique, bien documentée, sans magic. C'est voulu.

## Ce que Claude a fait — et bien fait

Je ne vais pas prétendre avoir tout codé à la main. Claude a produit l'essentiel du code, et ce qui m'a frappé, c'est la **cohérence architecturale** du résultat.

Pas juste des snippets copiés-collés. Une vraie structure :

- Les types TypeScript corrects pour toutes les entités Strapi (`StrapiPage`, `StrapiService`, `StrapiFeature`)

- Le client API isolé dans `lib/strapi.ts`, avec gestion du cache et séparation claire build-time / runtime

- Les composants React proprement découplés, qui acceptent leurs données en props plutôt que de les fetcher eux-mêmes

- La gestion du consentement cookies (Google Consent Mode v2) intégrée dès le départ, pas ajoutée en après-coup

- Le Schema.org JSON-LD sur chaque page, la sitemap générée au build, les balises hreflang pour le multilingue

Et surtout : la **documentation produite automatiquement**. Le `README.md`, le `GETTING_STARTED.md`, les User Stories avec critères d'acceptation techniques et cas de tests — tout ça est sorti du même processus. Sur un projet solo, la documentation est toujours ce qu'on sacrifie en premier. Là, elle existait dès le premier jour.

Le multilingue mérite une mention particulière. L'internationalisation avec `next-intl` en mode export statique est techniquement épineuse — le middleware de détection de locale ne fonctionne pas sans serveur. Claude a géré ça proprement : `localePrefix: 'as-needed'`, `setRequestLocale()` dans chaque composant serveur, routes localisées (`/hosting` vs `/fr/hebergement`). Ça aurait pu me coûter une journée de débogage.

---

## La vraie surprise : l'infra et le déploiement

Voilà ce dont personne ne parle quand on évoque "coder avec l'IA".

Le code frontend, c'est la partie visible. Mais un site en production, c'est aussi :

- Un repository GitHub créé, configuré avec les bons secrets, la bonne branche par défaut, les bonnes clés SSH

- Un workflow GitHub Actions qui construit, synchronise vers S3, et purge le cache Cloudflare à chaque push

- Une VM Scaleway provisionnée, avec Strapi 5 + PostgreSQL 15 déployés dans des containers Docker

- Un script Python (`crownmakers_manager.py`) pour gérer le cycle de vie de l'infra depuis le terminal : déployer, voir les logs, vérifier le statut

**Claude a produit tout ça.**

Le script de déploiement complet. La configuration du workflow CI/CD. Les commandes pour provisionner la VM. La configuration Nginx en reverse proxy devant Strapi. L'Infrastructure as Code, même partiel, était là.

Ce n'est pas quelque chose que j'avais anticipé. Je pensais arriver à ce niveau et reprendre la main "manuellement". Ça ne s'est pas passé comme ça.

## Les vrais obstacles — et ce qu'on en apprend

Je veux être honnête sur ce qui n'a pas été fluide, parce que c'est là que l'expérience devient instructive.

**Le token Strapi exposé côté client.** C'est le bug classique de Next.js que tout le monde fait une fois : exposer une variable d'environnement côté navigateur en la préfixant `NEXT_PUBLIC_`. Claude l'a fait. Ce n'est pas un bug de Claude — c'est un piège inhérent au framework, documenté, que des développeurs humains font aussi. Mais c'est arrivé, on l'a corrigé, et le post-mortem documente exactement pourquoi. C'est presque un bon exemple du flux de travail idéal : l'erreur arrive, on la traite, on la documente, on passe à autre chose.

**La cohérence sur la durée.** Sur une session courte, la cohérence est excellente. Sur plusieurs sessions étalées dans le temps — avec des aller-retours entre composants, des refactorings successifs, des ajouts de features — maintenir le contexte demande une discipline active. Il faut savoir ce qu'on a déjà produit, nommer les fichiers précisément, relire avant de modifier. Ce n'est pas un défaut rédhibitoire — c'est une contrainte à intégrer dans son flux de travail.

**Les décisions d'architecture à fort impact.** Le choix entre export statique et SSR, entre self-hosting Strapi et Strapi Cloud, entre Scaleway et AWS — ces décisions ont des implications durables. Claude propose, argumente, documente les trade-offs. Mais la décision finale reste humaine, et elle doit l'être. Ce n'est pas une limite — c'est une responsabilité à ne pas déléguer.

---

## Le bilan : ce que ça change vraiment

Pas "l'IA remplace le développeur".

Ce que ça change, c'est le **périmètre de ce qu'un architecte expérimenté peut faire seul en une semaine**.

Avant, construire seul un site avec cette stack — frontend complet, CMS headless, CI/CD, infra provisionnée, multilingue, SEO, RGPD — prenait plusieurs semaines. Pas parce que les concepts sont compliqués, mais parce que le volume de code à produire, de configuration à écrire, de documentation à rédiger est simplement énorme.

Ce projet a été fait en une semaine de travail effectif.

La valeur n'est pas dans la génération de code brut. Elle est dans la **vitesse d'expérimentation** : tester une stack qu'on ne connaît pas encore complètement, avoir le filet de sécurité d'une documentation générée, itérer vite sur l'architecture sans sacrifier la qualité structurelle.

Ce que ça ne remplace pas : le jugement sur les décisions stratégiques, la connaissance du contexte métier, la capacité à identifier ce qui va casser en production avant que ça casse.

---

## Pour les curieux : la stack complète

| Composant | Choix |

|-----------|-------|

| Frontend | Next.js 14 + TypeScript |

| CMS | Strapi 5 + PostgreSQL 15 |

| Hébergement frontend | Scaleway Object Storage (fr-par) |

| Hébergement CMS | Scaleway DEV1-M (Paris) |

| CDN / WAF | Cloudflare |

| CI/CD | GitHub Actions |

| Email transactionnel | SendGrid |

| Analytics | GA4 + GTM + Consent Mode v2 |

| Heatmaps | Microsoft Clarity |

Le site est live sur [www.crownmakers.com](https://www.crownmakers.com)

---

*Cet article a été rédigé avec Claude (Anthropic). Les choix d'architecture, le code et les décisions techniques sont les miens. Claude a participé à la rédaction, à la structuration et à la relecture.*

---

## Post LinkedIn (lien en commentaire)

---

**J'avais deux questions.**

La première : est-ce qu'une stack Next.js + Strapi tient vraiment ses promesses pour un site international ?

La deuxième, plus intéressante : jusqu'où Claude peut aller comme co-pilote sur un vrai projet ?

Pas un tutoriel. Un vrai site, un vrai domaine, une vraie infra.

Résultat en une semaine :

→ Frontend Next.js 14 TypeScript, export statique

→ CMS Strapi 5 self-hosted sur VM Scaleway à Paris

→ Multilingue FR/EN avec routes localisées

→ CI/CD GitHub Actions → S3 → Cloudflare

→ RGPD, Schema.org, SEO complet

Le code, les composants, la doc, les User Stories avec critères d'acceptation — Claude a produit tout ça avec une cohérence architecturale qui m'a surpris.

Mais la vraie surprise était ailleurs.

**Ce dont personne ne parle : l'infra.**

Le repo GitHub configuré. Le workflow CI/CD. La VM provisionnée. Le script de déploiement Python. L'Infrastructure as Code.

Je pensais reprendre la main à ce niveau. Ça ne s'est pas passé comme ça.

Il y a eu des obstacles — un token API exposé côté client (bug classique Next.js, humain autant que machine), la gestion du contexte sur plusieurs sessions. Des décisions d'archi que j'ai gardées pour moi, parce qu'elles doivent rester humaines.

Ce que ça change vraiment : pas "l'IA remplace le dev". Mais ce qu'un architecte expérimenté peut faire seul en une semaine — ça a changé.

J'ai écrit l'article complet avec l'architecture détaillée, les choix techniques et les vraies limites.

Lien en commentaire 👇

\#NextJS \#Strapi \#HeadlessCMS \#CloudArchitecture \#Scaleway \#Cloudflare \#InfraAsCode \#ClaudeAI \#WebDevelopment \#RGPD