J’ai créé des compétences Claude Code réutilisables pour livrer des sites plus vite

Des choses comme :

• les métadonnées SEO
• le prérendu
• la mesure d’audience
• les images de partage social
• les en-têtes CSP
• l'optimisation Lighthouse
• le soin apporté au mobile
• la génération du sitemap
• robots.txt
• la configuration de déploiement
• IndexNow
• la mise en cache
• la préparation de l'environnement

Les composants React eux-mêmes sont désormais souvent la partie facile.

Ce qui ralentit encore tout, c'est l'infrastructure opérationnelle.

Après quelques projets assistés par IA avec Claude Code, j'ai réalisé que je résolvais sans cesse les mêmes problèmes. Pas seulement visuellement, mais opérationnellement.

Alors, au lieu d'écrire des prompts plus longs, j'ai commencé à construire des skills Claude Code réutilisables.

Le résultat est devenu un dépôt open source de workflows orientés production : senternet-site-skills sur GitHub. Le dépôt contient des skills réutilisables et axées production pour le SEO, le prérendu, l'optimisation mobile, le partage social, la configuration CSP, le réglage Lighthouse, la mise en place de la mesure d'audience, les workflows de déploiement, et davantage.

Le problème du « vibe coding »

J'aime vraiment le développement assisté par IA. Beaucoup.

Claude Code est incroyablement puissant pour itérer vite, générer du frontend, réorganiser des mises en page, écrire du code utilitaire, intégrer des API et échafauder du contenu.

Mais une fois l'excitation initiale retombée, un schéma apparaît : l'IA génère des pages plus vite que vous ne pouvez les rendre opérationnelles.

Vous finissez par passer énormément de temps à corriger :

• des problèmes de SEO
• des incohérences de déploiement
• des métadonnées cassées
• un mauvais comportement sur mobile
• une mesure d'audience absente
• des régressions de performance
• des problèmes d'aperçu social
• une configuration de production incomplète

Ironiquement, ce sont souvent les tâches les moins enthousiasmantes à refaire à la main. Cela en faisait des candidates parfaites pour des skills réutilisables.

Des prompts géants aux workflows réutilisables

Au début, j'ai essayé de régler cela avec des prompts de plus en plus longs. Du genre :

« Assure-toi que cette page est responsive, optimisée pour le SEO, qu'elle utilise le prérendu, dispose des bonnes métadonnées, du support de partage social, des en-têtes CSP, de l'intégration analytique et de réglages de déploiement sûrs pour la production… »

Cette approche est vite devenue peu fiable.

Claude se concentrait fortement sur une instruction tout en en ignorant discrètement une autre. Parfois il implémentait des fonctionnalités à moitié. D'autres fois il cassait ce qui marchait en essayant d'« aider ».

Le déclic est venu quand j'ai cessé de traiter les prompts comme des conversations pour les traiter comme de l'infrastructure.

Au lieu de prompts géants, j'ai créé des skills réutilisables et ciblées :

• senternet-site-metatags
• senternet-site-prerender
• senternet-site-mobile-optimize
• senternet-site-share-images
• senternet-site-csp
• senternet-site-lighthouse
• senternet-site-indexnow
• senternet-site-firebase

Chaque skill avait des responsabilités étroitement délimitées, des attentes déterministes, des garde-fous opérationnels et une logique d'implémentation réutilisable. Les résultats sont devenus nettement plus stables.

L'idée la plus importante : la cohérence opérationnelle

L'IA est étonnamment douée pour générer des composants. Elle est bien moins bonne pour maintenir de façon cohérente l'infrastructure de production à travers plusieurs projets.

Les humains se souviennent naturellement de choses comme :

• « A-t-on mis les balises OpenGraph ? »
• « Est-ce qu’on prérend cette route ? »
• « A-t-on configuré robots.txt ? »
• « Cette image sociale va-t-elle être recadrée correctement ? »
• « Les scores Lighthouse sont-ils toujours acceptables ? »
• « La mesure d'audience a-t-elle été ajoutée au layout de production ? »

L'IA oublie souvent ces détails entièrement si on ne la guide pas explicitement. C'est là que les skills réutilisables deviennent puissantes. Plutôt que de dépendre de la mémoire ou de prompts répétés, les standards opérationnels sont encodés dans des workflows réutilisables.

Le but n'était pas l'automatisation totale. C'était de réduire le travail oublié.

Le concept d’« uber-skill »

L'un des schémas les plus utiles a fini par être ce que j'ai appelé les « uber-skills ». Au lieu de traiter une tâche isolée, ces workflows orchestrent plusieurs étapes de configuration ensemble. Par exemple :

• détecter ce qui est déjà configuré
• sauter ce qui est déjà fait
• repérer les fonctionnalités de production manquantes
• n'appliquer que des améliorations incrémentales
• éviter les réécritures destructrices

Ce dernier point est devenu particulièrement important. L'un des plus gros modes d'échec des outils de code par IA est de demander une modification et de récupérer un refactoring accidentel de tout le projet. Les skills ont nettement contenu ce comportement.

Ce qui s'est réellement amélioré

Les plus grands gains n'ont pas été d'écrire du code plus vite, de générer de plus jolis composants ou de moins taper. Les plus grands gains ont été :

• moins de régressions
• moins de détails de déploiement oubliés
• moins d’erreurs de SEO
• moins de tâches de configuration répétitives
• une préparation à la production plus cohérente
• moins de fatigue décisionnelle

Autrement dit : l'IA est devenue plus utile une fois le workflow devenu plus structuré.

Usage réel

Ces workflows ont fini par faire partie du processus de production de projets comme :

• StockCar (stockcar.app)
• BeeReady (beeready.buzz)

Les deux projets ont profité de l'application répétée des mêmes standards opérationnels : gestion des métadonnées, optimisation mobile, workflows d'images de partage, structure SEO, cohérence de déploiement et optimisation des performances. Sans skills réutilisables, je me retrouvais à re-résoudre les mêmes problèmes d'infrastructure sur chaque projet.

Là où le développement assisté par IA peine encore

Même avec des skills réutilisables, les limites sont nettes. Claude Code peut encore :

• sur-refactoriser du code qui fonctionnait
• halluciner des décisions d'architecture
• casser des mises en page responsives
• inventer des abstractions inutiles
• appliquer partiellement les instructions
• manquer de subtiles incohérences d'expérience

Le fignolage du frontend demande encore du jugement humain, et beaucoup. Mais des workflows structurés réduisent le chaos de façon spectaculaire.

Mon point de vue actuel

Je pense de plus en plus que l'avenir du développement assisté par IA ressemble moins à du prompting qu'à de l'ingénierie opérationnelle. Ceux qui obtiendront les meilleurs résultats ne seront probablement pas ceux qui écrivent les prompts les plus longs, retirent toutes les contraintes ou courent après des agents pleinement autonomes.

Ce seront ceux qui bâtissent des workflows réutilisables, des systèmes contraints, un outillage composable, une infrastructure déterministe et des garde-fous opérationnels. Le vrai levier vient d'encoder la cohérence. Pas seulement de générer du code.

Pour finir

Les outils de code par IA sont déjà extrêmement capables. Mais il reste un écart énorme entre générer une démo et livrer de façon répétée des sites prêts pour la production.

Pour moi, les skills Claude Code réutilisables sont devenues un moyen de combler cet écart. Non pas en remplaçant la discipline d'ingénierie, mais en rendant plus facile de l'appliquer avec constance.

← Tous les articlesSuivant: Pourquoi je crée de petits logiciels locaux qui ne font qu’une chose →