Dénomination de projet

Description

Avant de démarrer un nouveau projet, validez que le nom de domaine est disponible. Si le domaine est pris, choisissez un nom différent avant d'écrire du code.

Déclencheurs

nouveau projet
nom de projet
nom de domaine
saas
startup
lancement
produit
projet secondaire
dénomination
domaine disponible
objectif de revenus
idée métier

Instructions

Protocole de dénomination domaine-first

AVANT d'écrire du code, de créer des fichiers ou de configurer un projet :

Choisissez un nom — Sélectionnez un nom de projet court et mémorable
Vérifiez le domaine — Exécutez whois <name>.com via shell_execute (ou .io, .ai, etc.)
- Cherchez "No match" / "NOT FOUND" / "Domain not found" = disponible
- Si whois n'est pas installé, utilisez nslookup <name>.com — NXDOMAIN = probablement disponible
- En dernier recours, accédez à un registraire de domaines (p. ex. namecheap.com) et effectuez une recherche
Le domaine est pris ? Changez le nom. N'AVANCEZ PAS avec un nom dont le domaine est pris. Essayez des variantes :
- Ajoutez un préfixe/suffixe : get, use, try, app, hq, labs
- Combinez les mots différemment
- Utilisez des TLD alternatifs (.ai, .io, .dev, .so) seulement si .com est vraiment impossible
Répétez jusqu'à trouver un domaine disponible
Seulement ensuite créez le projet avec ce nom

Règles

Ne sautez jamais la vérification du domaine. Un projet sans domaine disponible ne peut pas être lancé.
Privilégiez .com — C'est l'attente par défaut. Utilisez des alternatives seulement en dernier recours.
Vérifiez au moins 3 variantes de nom avant d'abandonner .com
La vérification du domaine prend quelques secondes. Renommer un projet après l'avoir construit prend des heures.
Une fois qu'un nom disponible est trouvé, notez-le dans votre bloc-notes avant de continuer.

Anti-patterns

Commencer à coder avant de vérifier le domaine
Supposer qu'un domaine est disponible sans vérifier
Choisir un mot générique/courant comme nom (toujours pris)
Vérifier la disponibilité via une recherche Google (peu fiable)
Utiliser un domaine pris et prévoir de "régler ça plus tard"

Vérifier

Le livrable de cette phase existe sous la forme d'un artefact concret (document, ticket, tableau, repo) et son emplacement est partagé, non décrit
Chaque engagement a un propriétaire nommé, une date limite et une definition-of-done vérifiable par quelqu'un d'autre que l'auteur
Les risques sont énumérés avec probabilité/impact et une atténuation nommée, pas comme un point générique 'risques : TBD'
Les dépendances envers d'autres équipes/fournisseurs/agents sont explicites ; une approbation de chaque dépendance est enregistrée ou marquée 'en attente'
Les critères de succès pour la phase suivante sont numériques ou autrement vérifiables objectivement
Un critère d'annulation / kill-switch / 'nous arrêterons si X' est écrit avant le démarrage des travaux

project-naming