Skip to content

CLAUDE.md

Latest commit

 

History

History
72 lines (51 loc) · 3.78 KB

CLAUDE.md

File metadata and controls

72 lines (51 loc) · 3.78 KB

CLAUDE.md — Efficience IT Website

Projet

Clone/reproduction de https://www.itefficience.com en Next.js.

Stack

  • Framework : Next.js 15 (React 19, TypeScript, Tailwind CSS 4)
  • Dev : npm run dev
  • Build : npm run build
  • Lint : npm run lint

Préférences

  • PRs courtes : une PR = un changement ciblé
  • Pas de mention de Claude : ne jamais ajouter Co-Authored-By, Generated with Claude, ni aucune référence à Claude dans les commits, PRs, code ou contenu
  • Push / PR : autorisé sans demander confirmation
  • Jamais merger dans main : ne jamais utiliser gh pr merge ou merger dans main, sous aucun prétexte
  • Pas de npm run build : ne pas lancer de build, ça coupe le serveur de dev
  • Pas de commentaires : ne jamais ajouter de commentaires dans le code
  • Pas de tiret cadratin : ne jamais utiliser le caractère — (em dash), ni dans le code, ni dans les articles
  • Pas de commentaires GitHub : ne jamais commenter sur GitHub (issues, PRs, commits), sous aucun prétexte
  • PRs concises : titres de PR courts, descriptions brèves (quelques bullet points max), pas de pavés
  • Commits et PRs opaques : le repo est public. Utiliser des messages de commit génériques et courts qui ne révèlent pas la stratégie (ex: update, fix, refactor). Ne jamais mentionner de mots-clés SEO, de noms de clients, de stratégie marketing ou de détails techniques sensibles dans les commits, titres de PR ou descriptions de PR.
  • Vérification orthographique avant commit : avant chaque commit, vérifier les fautes de français (orthographe, grammaire, conjugaison) dans les fichiers modifiés

SEO — Articles de blog

  • Le <title> doit être identique au <h1> de l'article
  • Utiliser des <h2> et <h3> pour structurer le contenu
  • Ne jamais utiliser <h4>, <h5>, <h6>
  • Viser entre 1000 et 2000 mots par article

Liens internes (vers d'autres articles du blog)

  • ~1 lien interne tous les 200-300 mots : 3-5 pour un article de 1000 mots, 7-10 pour 1500-2000 mots
  • Privilégier les liens dans le corps du texte, ancrés sur un mot-clé descriptif (pas "cliquez ici")
  • Un lien dans le corps de l'article vaut 10x plus qu'un lien en bas de page dans une liste
  • Tisser des liens entre articles pour faire monter l'autorité des anciennes pages

Liens externes (vers des sources tierces)

  • ~1-2 liens externes tous les 500 mots, max 5 pour un article long (1500+ mots)
  • Uniquement vers des sources à haute autorité : doc officielle Symfony, GitHub, article de référence
  • Jamais vers un concurrent direct
  • L'objectif : montrer qu'on s'appuie sur des sources sérieuses, pas faire fuir le lecteur

Articles techniques Symfony

  • Un lien vers la doc Symfony officielle du composant traité est quasi obligatoire
  • Un lien interne vers un article connexe (archi hexagonale, Messenger, etc.) pour le maillage long terme

SEO — Décisions volontaires

  • Les pages /domain/* ne sont pas dans le sitemap (volontaire)
  • Le sitemap du live contient des pages hors périmètre (checkout, login, etc.) — on ne les reproduit pas, c'est voulu

Prompts d'audit (.docs/reference/)

Le dossier .docs/reference/ contient les prompts d'audit. Le fichier mega-audit-seo-ux.md regroupe tout : SEO, UX/UI, design, copywriting, orthographe, accessibilité, performance. Le fichier tracking.md documente l'implémentation GA4. Quand l'utilisateur donne un retour ou une correction, proposer de l'inscrire dans le prompt correspondant.

Hors périmètre

Ces fonctionnalités du site original ne seront pas reproduites :

  • Authentification (login, signup, reset password)
  • E-commerce (checkout, PayPal, confirmation de commande)
  • Compte utilisateur
  • Recherche (/search)
  • Pages auteurs (/author/*)
  • Pages membres / profils (/profile/*)