WordPress → Astro avec Claude Code : retour technique

Le point de départ

Le site WordPress de Nobori avait fait son temps. La dernière mise à jour de sécurité datait de 8 mois. Le thème n’était plus compatible avec les dernières versions de PHP. Plus maintenu, lent, pas responsive sur mobile, impossible à déployer automatiquement. Il ne reflétait plus ce que nous faisons (conseiller des DSI sur le Cloud, la Data, l’IA et la Cybersécurité) et chaque modification nécessitait de se connecter à un back-office que personne n’avait envie d’ouvrir

L’objectif était clair : un site statique moderne, rapide, maintenable par des non-techniques via un CMS headless, déployable automatiquement à chaque commit. Un site qui serve de vitrine crédible pour un cabinet qui conseille ses clients sur leurs choix technologiques

La contrainte principale : environ 80 heures cumulées sur 5 semaines, en parallèle de l’activité cabinet. Pas un sprint dédié, pas d’équipe frontend, pas de budget agence. C’est cette contrainte qui m’a poussé vers Claude Code, non pas comme gadget, mais comme multiplicateur de capacité sur un périmètre que je maîtrisais architecturalement mais que je n’aurais jamais eu le temps de coder seul

Le résultat : 80+ pages, 28 articles, un pipeline CI/CD complet, un CMS éditorial, le tout hébergé sur Cloudflare Pages

Pour le contexte business de cette décision, voir notre article dirigeant.

Mais un résultat ne dit rien de la méthode. Ce qui a rendu ce projet possible, ce n’est pas l’IA en soi, c’est la façon de travailler avec elle

À qui s’adresse ce REX : CTO, lead dev, architecte, ou DSI qui évalue l’IA codante pour ses équipes. Le contexte est un projet greenfield (site vitrine en reconstruction) avec un décideur unique. Ce n’est pas un guide de transformation IT à l’échelle d’un SI ETI : les ratios de gain observés ici (10x subjectif sur tâches cadrées) ne se transposent pas mécaniquement à du legacy, du métier critique, ou des équipes pluridisciplinaires. Lire comme un cas favorable, pas comme une promesse généralisable. Pour un DSI d’ETI qui évalue l’outil pour ses devs, voir la section finale.

Mon setup avec Claude Code : le workflow qui change tout

Le choix de Claude Code plutôt que Cursor ou Copilot

La question n’est pas quel outil est “meilleur”. C’est quel mode d’interaction correspond au travail à faire

Cursor et Copilot sont des IDE augmentés. Ils excellent dans l’autocomplétion, la suggestion ligne par ligne, l’assistance contextuelle sur un fichier ouvert. C’est utile quand on code activement et qu’on veut aller plus vite sur l’implémentation

Claude Code fonctionne différemment. C’est un agent terminal qui a une vision globale du projet. Il lit l’arborescence complète, comprend les dépendances entre fichiers, et peut modifier plusieurs fichiers en une seule passe. Quand je lui demande de créer un nouveau composant de landing page, il ne modifie pas un seul fichier : il met à jour le schema Zod, crée le composant Astro, l’enregistré dans le registry, et vérifie que le build passe. En une interaction

Pour un projet de refonte complète (où les décisions touchent la structure, le routing, le modèle de données, le déploiement), cette vision globale fait une différence fondamentale. Je ne travaille pas fichier par fichier, je travaille par feature. Claude Code est le seul outil que j’ai trouvé qui fonctionne à ce niveau d’abstraction

L’autre avantage, moins évident : le terminal force la discipline. Pas de clic, pas de glisser-déposer. Chaque interaction est un prompt explicite. Ca oblige à formuler ce qu’on veut, et cette formulation est en soi un acte de conception

Les frameworks qui m’ont inspiré

Je n’ai pas inventé mon workflow en partant de zéro. Trois frameworks open-source m’ont donné les briques

BMAD (Breakthrough Method for Agile AI-Driven Development) propose des personas IA spécialisées définies en Markdown : un analyste, un architecte, un développeur, un testeur. Chaque persona a des instructions différentes, un périmètre différent, des outputs différents. Ce que j’en ai retenu : séparer réflexion et exécution. Ne jamais demander à l’IA de coder avant d’avoir une spec validée. Le persona architecte pense, le persona développeur implémente. Pas les deux en même temps

GSD (Get Shit Done) est un framework de spec-driven development qui adresse un problème que j’ai vécu dès les premières sessions : le “context rot”. Au bout de 20 minutes de conversation, l’IA oublie les contraintes posées au début, repropose des solutions déjà rejetées, ou dérive vers des tangentes. GSD impose des tâches atomiques, des contextes frais à chaque étape, et une vérification par objectifs plutôt que par checklist. Ce que j’en ai retenu : chaque tâche doit tenir dans une session courte, avec un objectif mesurable et un critère de succès explicite

gstack de Garry Tan introduit le concept de “gears cognitifs” : des slash commands qui switchent l’IA entre des modes distincts. Un gear pour le design, un gear pour l’implémentation, un gear pour la review. L’idée clé : ne pas demander à l’IA d’être tout en même temps. Un développeur qui code et review son propre code en même temps fait un mauvais travail sur les deux. C’est pareil pour l’IA

Le workflow que j’ai construit

En synthétisant ces trois approches, j’ai convergé vers un workflow en quatre temps

Persona architecte : spec d’abord. Avant de toucher une ligne de code, je switche Claude Code en mode design. Je lui donne le contexte (ce qui existe, ce qu’on veut, les contraintes), et je lui demande une spec : architecture des composants, modèle de données, dépendances, edge cases. On itère. Il challenge mes choix, je challenge les siens. Rien n’est codé tant que la spec n’est pas validée par les deux parties

Contextes frais, tâches atomiques. Une fois la spec validée, je la découpe en tâches courtes : une tâche par session Claude Code. Chaque session repart d’un contexte propre : le CLAUDE.md (qui donne le cadre permanent) plus la spec de la tâche spécifique. Pas de conversation de 45 minutes qui dérive. Pas de “pendant qu’on y est, on pourrait aussi…”. Une tâche, un livrable, une vérification

Gear review, pas gear build. Une fois l’implémentation terminée, je change de mode cognitif. Claude Code passe de développeur à reviewer. Même code, œil différent. Je lui demande explicitement : “Revois ce code comme si tu ne l’avais pas écrit. Cherche les bugs, les incohérences, les failles de sécurité, les violations de conventions.” Le résultat est systématiquement meilleur que si je lui demandais de coder et reviewer en une seule passe

Vérification par objectifs. Plutôt qu’une checklist (“as-tu fait X, Y, Z ?”), je pose la question : “Qu’est-ce qui doit être vrai pour que cette feature fonctionne en production ?” Ca force l’IA à raisonner sur les invariants plutôt qu’à cocher des cases. L’audit est continu, pas un événement ponctuel

Le CLAUDE.md comme contrat de collaboration

Le fichier CLAUDE.md est le cœur du workflow. Claude Code le lit automatiquement au début de chaque session. C’est l’équivalent d’un README d’onboarding, sauf qu’il est relu à chaque conversation, pas une seule fois le premier jour

Le nôtre fait plusieurs centaines de lignes. Il contient la stack technique (Astro 5.3, Tailwind 4.1, TypeScript strict), les commandes disponibles (npm run validate avant chaque push), la structure du projet (routes, layouts, composants, content collections), les décisions d’architecture documentées (pourquoi full statique, pourquoi Sveltia CMS, pourquoi deux branches), les pièges connus (isoDate sans guillemets en YAML, CSP et nouveaux domaines), et les conventions de nommage et de commit

Ce fichier a évolué organiquement. Chaque fois qu’un piège m’a fait perdre du temps, je l’ai documenté dans le CLAUDE.md. Chaque décision d’architecture qui revenait en question d’une session à l’autre a été gravée dans le fichier avec son raisonnement. Après quelques semaines, c’est devenu le document de référence du projet, utile pour l’IA, mais aussi pour moi

Pourquoi ce workflow plutôt que du “vibe coding”

Le “vibe coding” (ouvrir un terminal, prompter librement, itérer au feeling) produit du code jetable. Ca marche pour un prototype, un script ponctuel, une exploration. Pour un site en production qui doit être maintenu, déployé automatiquement, et modifié par d’autres personnes, c’est insuffisant

Le workflow structuré a un coût d’entrée : 15 minutes de cadrage par feature (spec, découpage, critères de succès). Mais ces 15 minutes économisent systématiquement 2 à 3 heures de corrections, de refactoring, et de debugging en aval

Sur ce projet, mon ressenti subjectif est que les tâches bien cadrées (spec claire, périmètre défini, critères de succès explicites) sortent environ 10 fois plus vite qu’en codage manuel, sans que je puisse le mesurer rigoureusement (pas de groupe contrôle, pas d’échantillon statistique, pas de benchmark externe). Sur les tâches mal spécifiées (vague, pas de contrainte, “fais au mieux”), le gain disparaît. Les études externes les plus sérieuses (DORA Report 2024, recherche GitHub sur l’impact de Copilot) suggèrent des gains plus modestes en moyenne (de l’ordre de quelques dizaines de pourcent de productivité médiane, avec une forte variance selon les profils et le type de tâche). Lire mon “10x” comme un cas favorable sur un périmètre spécifique, pas comme une promesse généralisable. L’IA n’est pas magique : elle amplifie la qualité du cadrage qu’on lui donne

Ce workflow fonctionne quel que soit le framework. Mais le choix de stack n’est pas neutre : il détermine ce que l’IA peut faire en une passe et ce qui nécessitera plusieurs itérations

Poser les fondations : choix de stack

Next.js aurait été le choix par défaut, c’est ce que la majorité des développeurs utilisent. Mais pour un site vitrine sans interactivité côté client, React est un overhead inutile. Astro envoie zéro JavaScript par défaut et ne charge du JS que là où on le demande explicitement

Le choix d’Astro s’est imposé pour trois raisons. D’abord, le mode statique natif : output: 'static' génère du HTML pur, sans runtime JavaScript côté client sauf là où on le décide explicitement. Pour un site vitrine, c’est exactement ce qu’il faut : rapide, sécurisé, pas de serveur à maintenir

Ensuite, le file-based routing : chaque fichier dans src/pages/ devient une route. blog/[slug].astro génère une page par article. Pas de configuration de routeur, pas de fichier de routes centralisé. La structure du dossier est la structure du site

Enfin, les content collections : Astro valide le contenu Markdown avec des schemas Zod au build. Si un article de blog n’a pas de titre ou si une date est mal formatée, le build échoue. Pas de page cassée en production, pas de données manquantes silencieuses

Tailwind CSS en version 4.1 avec la configuration CSS-first (@theme dans critical.css) plutôt que le tailwind.config.js classique. TypeScript en mode strict partout

La décision la plus importante a été le full statique, pas de SSR. Claude Code avait proposé une couche API server-side pour proxifier les webhooks des formulaires. C’est objectivement plus sécurisé : les URLs des webhooks restent côté serveur, invisible dans le HTML. Mais j’ai arbitré différemment : POST direct côté client aux webhooks. Pourquoi ? Parce que ca supprime le besoin d’un serveur Node.js en production. Pas de serveur = pas de maintenance serveur, pas de coûts d’hébergement, pas de point de défaillance. Le compromis (les URLs de webhooks sont visibles dans le HTML source) est acceptable pour un site vitrine sans données sensibles

C’est exactement le type de décision d’architecture que l’IA ne prend pas seule. Elle peut proposer les options, argumenter les pour et les contre, mais l’arbitrage final (quel compromis est acceptable pour ce contexte précis) reste humain

Astro gère le rendu. Mais 80+ pages avec trois types de contenu différents (équipe, blog, landing pages), ça ne s’organise pas tout seul

Structurer le contenu : trois niveaux d’abstraction

Le contenu du site suit trois stratégies distinctes selon sa nature. Ce n’est pas un choix esthétique, c’est un choix d’ingénierie dicté par les caractéristiques de chaque type de donnée

Niveau 1 : TypeScript statique pour les données structurées qui changent rarement. L’équipe (src/data/team.ts), les expertises (src/data/expertises/), la navigation (src/data/navigation.ts), les références clients. Ces données sont typées, avec autocomplétion dans l’IDE, validation à la compilation. Pas de runtime, pas de requête, pas de CMS. Claude Code avait proposé de mettre les données d’équipe en content collection Markdown, c’est le réflexe par défaut quand on utilise Astro. J’ai refusé : l’équipe change rarement, les données sont structurées (pas du texte libre), et TypeScript donne l’autocomplétion et le typage sans l’overhead d’un schema Zod séparé. Bonne solution technique, mauvais choix pour ce cas d’usage

Niveau 2 : Content Collections Markdown + Zod pour le contenu éditorial qui évolue régulièrement. Les articles de blog, les cas clients. Chaque fichier .md dans src/content/blog/ est validé au build par un schema Zod défini dans src/content/config.ts. Le schema impose un titre, une date, une catégorie, une image, un excerpt. Les champs optionnels (FAQ, TL;DR, tags) enrichissent le SEO et le GEO sans être bloquants

Niveau 3 : YAML modulaire pour les landing pages. Les sections d’une landing page sont définies dans le frontmatter YAML du fichier Markdown, validées par un schema Zod à union discriminée, puis rendues par un registry de composants. Un fichier YAML = une page en production. C’est le niveau le plus abstrait et le plus puissant, détaillé dans la section suivante

Le CMS éditorial (Sveltia CMS) couvre les niveaux 2 et 3. C’est un fork moderne de Decap CMS, zero serveur, zero coût, compatible avec la même configuration. Il commit directement sur la branche main via l’API GitHub. Les non-techniques peuvent créer un article de blog sans ouvrir un terminal

Le niveau 3 mérite qu’on s’y arrête : c’est la pièce qui a rendu l’équipe marketing autonome

Le registry pattern : une page en un fichier YAML

Le besoin venait du marketing : pouvoir créer des pages d’audit, des landing pages campagne, des pages offre, sans mobiliser un développeur pour chaque nouvelle page

La solution technique est un registry pattern en trois couches

Couche 1 : définition en YAML. Chaque landing page est un fichier Markdown dont le frontmatter contient un tableau sections. Chaque section a un type (hero, features, metrics, form, faq, testimonials, cta…) et des propriétés spécifiques validées par Zod

Couche 2 : validation Zod à union discriminée. Le schema sectionSchema dans config.ts est un z.discriminatedUnion sur le champ type. Chaque type de section a son propre schema avec ses champs obligatoires et optionnels. Si le YAML est mal formé, le build échoue avec un message explicite

Couche 3 : registry de composants. Le fichier src/components/landing/registry.ts mappe chaque type de section à un composant Astro (LandingHero.astro, LandingFeatures.astro, etc.). La page dynamique src/pages/lp/[slug].astro itère sur les sections et rend le composant correspondant

Le résultat : pour ajouter une nouvelle landing page, il suffit de créer un fichier .md dans src/content/landing-pages/ avec les bonnes sections. Pour ajouter un nouveau type de section, il faut trois modifications (schema, composant, registry), toutes les trois que Claude Code peut faire en une seule passe

Créer du contenu est une chose. Le mettre en production de manière fiable en est une autre

Le pipeline de production : du commit au déploiement

Le pipeline repose sur deux branches et trois étapes automatisées

La branche main est le staging. C’est là que le CMS commit, et c’est là que je développe. Chaque push sur main déclenche un workflow GitHub Actions qui exécute npm run validate, la même séquence que le hook pre-push local : lint puis format:check puis build. Si le build échoue, la PR de déploiement n’est pas créée

La branche production est le site live. On n’y push jamais directement. Un workflow GitHub Actions crée automatiquement une PR main → production après chaque build réussi sur main. Un reviewer (moi, en pratique) valide la preview Cloudflare Pages, puis merge. Le merge déclenche le déploiement sur Cloudflare Pages et la création automatique d’un tag deploy-YYYY-MM-DD-HHMM

Ce pipeline a un avantage sous-estimé : il transforme chaque déploiement en acte délibéré. Le CMS peut commiter autant qu’il veut sur main, rien ne part en production sans une validation humaine explicite. C’est un filet de sécurité essentiel quand le contenu est créé par des non-techniques

Cloudflare Pages gère l’hébergement, le CDN mondial, le HTTPS automatique, et les previews par branche. Zero serveur à maintenir, zero coût pour notre volume

À ce stade, le site se construisait et se déployait automatiquement. On aurait pu s’arrêter là. Sauf qu’aucune des étapes précédentes ne s’était occupée d’un sujet que l’IA ne met jamais sur la table d’elle-même

Sécuriser : ce que Claude Code ne fait pas spontanément

La sécurité est le domaine où l’écart entre l’IA et l’humain est le plus marqué. Claude Code ne propose pas spontanément un audit de sécurité. Il ne vérifie pas les headers HTTP, il ne cherche pas les failles XSS, il ne challenge pas les dépendances tierces. La sécurité est une initiative humaine, pas une suggestion algorithmique

OWASP et surface d’attaque

J’ai demandé à Claude Code de faire un audit OWASP du code généré. Les résultats étaient instructifs. Le code initial des formulaires utilisait innerHTML pour afficher les messages de succès/erreur, un vecteur XSS classique. Remplacé par des manipulations DOM API (textContent, createElement). Les entrées utilisateur sont sanitisées (remplacement des caractères & < > " '). Un honeypot (champ caché invisible) et un rate limiting (cooldown de 30 secondes) protègent contre les soumissions automatisées

Supply chain

Le CMS Sveltia est chargé depuis unpkg.com via une balise <script>. Sans version fixée et sans intégrité SRI, c’est un vecteur d’attaque : si le package npm est compromis, le script injecté a accès au token OAuth GitHub de l’utilisateur authentifié. J’ai ajouté un hash SRI (integrity="sha384-...") pour verrouiller le contenu exact du script chargé. C’est le type de risque supply chain que l’IA ne signale pas d’elle-même

Headers de sécurité

Le fichier public/_headers de Cloudflare Pages définit les headers de sécurité : Content-Security-Policy (CSP) restrictive, Referrer-Policy: strict-origin, X-Frame-Options: DENY, Permissions-Policy qui désactive caméra, micro, géolocalisation. Le CSP est unifié pour le site public et l’admin CMS, nécessaire parce que Cloudflare Pages applique les headers /* à toutes les pages. Le compromis unsafe-eval est accepté pour Sveltia CMS, qui en a besoin pour fonctionner

Risques acceptables documentés

Certains risques sont acceptés et documentés plutôt qu’éliminés. Les URLs de webhooks sont visibles dans le HTML, acceptable pour un site vitrine, les webhooks n’exposent pas de données sensibles. Les données de formulaire transitent directement du client au webhook, sans proxy serveur, sans logging côté serveur. Ces compromis seraient inacceptables pour une application métier avec des données sensibles. Pour un site vitrine, ils sont raisonnables. Nommer explicitement ce qu’on accepte est aussi important que corriger ce qu’on refuse.

Recette pré-production

Avant le premier déploiement en production, j’ai établi un plan de recette structuré couvrant les 84 pages du site, organisé en 21 sections de test, avec 4 niveaux de sévérité (bloquant, majeur, mineur, cosmétique) et des critères go/no-go explicites. Claude Code a exécuté ce plan, mais c’est moi qui l’ai conçu et qui ai validé les résultats

Un site sécurisé avec zéro contenu reste un site vide. 28 articles, des cas clients, des FAQ, des pages d’expertise : produire ce volume seul aurait pris des mois sans méthode

Produire du contenu à l’échelle

Le site compte 28 articles de blog, des cas clients, des FAQ structurées pour le SEO, des pages d’expertise détaillées. Produire ce volume de contenu seul aurait pris des mois

Le workflow spec-driven s’applique aussi au contenu éditorial. Pour chaque article : brief éditorial (sujet, angle, audience cible, points clés, sources attendues), puis rédaction assistée par Claude Code, puis review éditoriale en deux passes : d’abord les erreurs critiques (faits incorrects, incohérences, affirmations non sourcées), puis les améliorations (style, structure, clarté)

Le sourçage est non négociable. Chaque affirmation factuelle doit citer sa source. Chaque chiffre doit être vérifiable. Sur les 28 articles, j’ai dû corriger des sources inventées dans 100% des cas. Claude Code cite des rapports qui n’existent pas, attribue des chiffres à des organismes qui ne les ont jamais publiés, et le fait avec une assurance qui rend la vérification d’autant plus importante. La review humaine du sourçage n’est pas optionnelle : c’est le garde-fou le plus critique du workflow éditorial

Le même workflow s’applique aux FAQ frontmatter (utilisées pour le schema JSON-LD en SEO), aux TL;DR (optimisés pour l’extraction par les LLM dans le cadre du GEO), et aux excerpts. Chaque pièce de contenu passe par le cycle spec, rédaction, review

Tout ce qui précède fonctionne. Ce qui suit, moins

Les limites honnêtes

L’honnêteté est ce qui sépare un retour d’expérience utile d’un article marketing. Voici ce qui n’a pas marché, ou pas aussi bien qu’espéré

Le context rot est réel

Au-delà de 30 minutes de conversation continue, Claude Code commence à oublier des contraintes posées au début de la session. Il repropose des solutions déjà rejetées. Il contredit des décisions d’architecture documentées dans le CLAUDE.md. Ce n’est pas un bug : c’est une limitation fondamentale des LLM à fenêtre de contexte finie

La parade : sessions courtes (20 minutes maximum), tâches atomiques (un livrable par session), et un CLAUDE.md exhaustif qui sert de mémoire persistante entre les sessions. Le context rot n’est pas éliminé, mais il est contenu

La sur-ingénierie comme réflexe

Claude Code a une tendance naturelle à l’abstraction prématurée. Demandez-lui un formulaire de contact, il proposera un système de validation par plugins avec un registre de validateurs, un bus d’événements, et un adapter pattern pour supporter plusieurs backends de soumission. Pour un formulaire contact avec 4 champs, HTML5 natif + 10 lignes de JavaScript suffisent

J’ai appris à être explicite sur le niveau de complexité attendu : “Pas de factory, pas d’adapter, pas d’abstraction. Code direct, lisible, maintenable. Si ca tient en un fichier, ca tient en un fichier.”

Quand il faut jeter et recommencer

Le cas le plus instructif a été le composant de cas clients en scrollytelling. Trois itérations complètes. Les deux premières ont été intégralement jetées, non parce que le code était mauvais, mais parce que le brief était insuffisant. Je n’avais pas défini clairement le comportement attendu au scroll, les breakpoints responsifs, ni l’interaction entre le texte et les métriques animées

La leçon : si l’implémentation ne converge pas après deux essais, le problème n’est pas dans le code : il est dans le brief. Revenir à la spec, pas réitérer l’implémentation

Chacune de ces limites a un point commun : elles auraient été moins coûteuses si je les avais anticipées

Ce que je referais différemment

Si je recommençais, quatre choses changeraient. D’abord, le CLAUDE.md dès le premier commit, pas après deux semaines de tâtonnements. Ensuite, des Golden Paths (chemins de référence pour les tâches récurrentes) définis plus tôt, pour éviter de réexpliquer le même workflow à chaque session. Des sessions de 20 minutes maximum plutôt que 30. Et un journal de décisions architecturales séparé du CLAUDE.md, pour ne pas surcharger le fichier de contexte

Un chantier qui ne s’arrête pas

Le site n’est pas “terminé”. Il itère chaque semaine : un nouvel article, un composant amélioré, une optimisation de performance, un ajustement SEO. C’est la nature d’un site vitrine pour un cabinet de conseil : le contenu reflète l’activité, et l’activité ne s’arrête pas

Les frameworks eux-mêmes bougent vite. BMAD, GSD et gstack n’existaient pas il y a six mois. Les pratiques de développement assisté par IA évoluent à un rythme que je n’ai jamais vu dans ma carrière. Ce retour d’expérience est une photo à date (mars 2026), pas une méthode figée. On continue à apprendre, à ajuster, à itérer

Si ce retour d’expérience vous donne envie d’essayer, trois choses feront la différence entre un side-project qui aboutit et un autre qui traîne

Recommandations

Prérequis

L’outil n’est pas la compétence. Claude Code ne remplace pas un jugement technique solide. Il faut être capable d’évaluer si une proposition architecturale est pertinente, si un compromis de sécurité est acceptable, si un pattern est adapté au contexte. Pas besoin d’être expert frontend, je ne le suis pas. Mais il faut savoir poser les bonnes questions et reconnaître les mauvaises réponses

Type de projet

Les projets greenfield (nouveau site, nouvelle application) et les refontes à périmètre clair sont les meilleurs candidats. Le cadrage est net, les contraintes sont identifiées, la spec peut être exhaustive. Les projets legacy complexes avec des dépendances implicites, de la logique métier non documentée, et des effets de bord sont moins adaptés : l’IA manque de contexte historique que personne n’a pris le temps d’écrire

Setup minimal

Trois éléments suffisent pour commencer : un CLAUDE.md structuré (stack, conventions, pièges connus), des conventions de commit documentées, et un workflow explicite spec puis plan puis build puis review. Un bon CLAUDE.md commence par 5 lignes : la stack, la commande de build, la commande de lint, la structure du dossier src/, et le workflow de déploiement. Le reste vient avec la pratique : ajoutez un piège chaque fois que vous en tombez dans un. Les slash commands, les personas, les gears cognitifs viendront naturellement

Quand ne pas utiliser

Quand le domaine métier est trop spécifique pour que l’IA ait des connaissances utiles. Quand la logique métier est réglementaire et que chaque ligne de code doit être traçable à une exigence normative. Quand le contexte historique est critique et non documenté. Dans ces cas, l’IA ralentit plus qu’elle n’accélère : le temps passé à corriger ses erreurs dépasse le temps gagné sur l’implémentation

Pour un DSI d’ETI qui évalue l’IA codante

Les recommandations précédentes sont calibrées pour un projet greenfield avec un décideur unique. Pour un DSI d’ETI (500-2000 personnes, équipe IT 10-30) qui évalue l’IA codante chez ses devs, le contexte est différent : SI hétérogène, dette technique, conformité, équipes pluridisciplinaires, intégration avec l’existant. Les questions à se poser avant de lancer un pilote :

• Quel périmètre greenfield existe dans votre roadmap pour piloter l’outil ? Outillage IT interne, intranet, dashboards métier non-critiques, automatisations de back-office, scripts de migration, prototypes d’interfaces. Éviter le cœur métier en premier pilote : même si l’envie est là, le rapport gain/risque est défavorable
• Quels seniors ou leads avec jugement architectural pour porter le pilote ? Pas un junior. Pas un dev moyen qui n’a jamais cadré une feature de A à Z. Il faut quelqu’un capable de challenger les propositions, d’arbitrer un compromis sécurité/vitesse, et de poser les bonnes questions sur la maintenabilité
• Comment cadrer la sécurité, la conformité et les conventions AVANT le pilote ? CLAUDE.md d’organisation (stack, conventions, garde-fous), périmètre des données autorisées à sortir vers le LLM, règles sur les secrets et les informations clients, golden paths pour les tâches récurrentes, gestion Git (review obligatoire, signatures, tags). Ces éléments se décident hors session
• Comment mesurer honnêtement le gain ? Lignes de code n’est pas une métrique. Le délai feature -> production, la stabilité en run (taux d’incidents), le taux de régressions, le temps de revue par PR sont les vrais indicateurs. Prévoir une mesure avant/après sur le périmètre pilote, pendant 2-3 mois minimum
• Quels risques spécifiques ETI ? Données clients fuitées vers le LLM (à cadrer contractuellement avec le fournisseur : Anthropic, OpenAI, Mistral…), licences IP des outputs (qui possède le code généré ? Conditions d’usage commercial), conformité (HDS, RGPD, secteur réglementé), dépendance fournisseur (que se passe-t-il si le pricing triple ?), intégration avec les outils existants (IDE d’entreprise, SSO, audit logs, gestion des secrets centralisée)

Pour le contexte business de cette décision et l’angle dirigeant, voir l’article dirigeant

Sources et méthodologie

• BMAD : Breakthrough Method for Agile AI-Driven Development
• GSD : Get Shit Done, framework de spec-driven development
• gstack : Garry Tan’s Claude Code setup avec gears cognitifs
• Claude Code : outil de développement assisté par IA (Anthropic)
• Astro : framework web statique (v5.3)
• Sveltia CMS : CMS headless open-source
• Cloudflare Pages : hébergement statique et CDN

Calibrage externe du gain de productivité (à lire pour contextualiser le “10x” subjectif de cet article) :

• DORA Report 2024 : étude annuelle DevOps Research and Assessment (Google Cloud) sur l’impact de l’IA sur la performance des équipes de développement. Conclut à des gains de productivité individuelle réels mais à des effets contrastés au niveau équipe et organisation
• Recherche GitHub sur Copilot : études “Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness” (2022) et travaux ultérieurs. Mesures de l’ordre de 25 à 55 % de gain sur des tâches de développement spécifiques (autocomplete, génération de code), avec une forte variance selon les profils, le langage et le type de tâche

Les observations et métriques presentees dans cet article sont issues de l’expérience directe de l’auteur sur le projet nobori-partners.fr (février-mars 2026), sans benchmark formel ni groupe de contrôle. Le ratio “10x” est une estimation subjective sur ce projet spécifique, pas un chiffre généralisable

---

Vous voulez évaluer le potentiel de l’IA sur vos projets ? Notre audit IA identifie les cas d’usage prioritaires et propose une feuille de route. Ou découvrez notre accompagnement coaching pour former vos équipes aux outils de code assisté par IA