Pour commencer, on pourra consulter cette page de l'Afnic

Un nom de domaine n’est jamais choisi au hasard. En même temps qu’un outil pratique, c’est un outil commercial. Par ailleurs, il doit se conformer à une charte.

Quelques principes énoncés par l’AFNIC :

• Privilégier des noms courts. Privilégier les mots courts d’autant plus que la consultation se fait sur téléphone mobile ;
• Ne pas craindre d’être créatif avec des noms de domaine courts inventés ;
• Éviter les tirets dans les noms de domaine, ils rallongent lecture et saisie ;
• Si le nom de domaine est long, utiliser une version avec des tirets pour les supports de communication, mais toujours prévoir un équivalent sans tirets ;
• Si le nom de domaine est long, penser à bien l’enregistrer sous plusieurs extensions ;
• Utiliser le .fr comme filtre linguistique pour permettre aux utilisateurs français de trouver le site sans problème.

Source : Astuces Afnic

L’AFNIC est l'office d'enregistrement désigné par l'État français pour la gestion des noms de domaine sous l’extension .fr. Il gère également les extensions ultramarines .re (Ile de la Réunion), .pm (Saint-Pierre et Miquelon), .tf (Terres australes et antarctiques Françaises), .wf (Wallis et Futuna), .yt (Mayotte) ainsi que quelques extensions nouvelles liées au territoire national .paris, .bzh, .ovh, etc.

La démarche pour déposer un nom de domaine s'effectue par le biais d'un bureau d'enregistrement. Ces derniers sont des intermédiaires entre le demandeur et l'AFNIC. Sur son site, l’AFNIC publie un annuaire des bureaux d’enregistrement.

Plusieurs types d’hébergements sont à considérer qu’il convient de choisir selon les exigences de l’application à héberger :

• Hébergement dédié : mise à disposition d’un serveur complet disponible pour vous seul. Performances, disponibilité et services sur mesures font de cette offre un service haut de gamme ;
• Hébergement mutualisé : mise à disposition d’un serveur dont les ressources sont partagées par plusieurs clients. Il s’agit d’une entrée de gamme qui convient à des besoins sans exigences fortes ;
• Hébergement hybride (VPS) : mise à disposition d’une machine virtuelle dédiée sur un serveur physique mutualisé. On dispose des possibilités de « sur-mesure » du modèle dédié du fait que l’on est seul utilisateur du serveur virtuel. On demeure, par contre, contraint par les performances et la disponibilité du modèle mutualisé puisque le serveur physique est partagé.

Une fois le contrat d’hébergement activé, selon l’offre retenue, il conviendra éventuellement de configurer l’ensemble des services mis à disposition (serveur web, serveur de base de données, langage hôte, etc.). Cela devra toujours se faire en envisageant par anticipation de possibles évolutions :

• Augmentation du volume de la base de données ;
• Cohabitation sur le même domaine de plusieurs applications distinctes (multisite);
• Tenue à jour des différents composants mis en jeu ;
• Possibilités de sauvegardes ;

Afin de ne pas mélanger les problèmes, il faudra commencer par vérifier que le SGBD répond bien aux attentes, indépendamment de l'application à déployer, en :

1. Créant une base de données de test contenant au moins deux tables reliées entre-elles ;
2. Alimentant un jeu d’essai minimal dans les tables ;
3. Créant un utilisateur disposant des droits essentiels sur la BdD de test ;

Vérifier que le serveur web répond bien à une sollicitation venue de l’extérieur hors de la présence de l’application. Plusieurs étapes progressives peuvent être envisagés :

1. Affichage d’une page par défaut (type site en construction) ;
2. Affichage d’une page de tests du langage hôte (type page php_info de php) ;
3. Accès à une base de données de test ;

Utiliser un client FTP (FileZilla ou équivalent) pour uploader le code de l’application au bon endroit dans l’arborescence du serveur WEB.

On préfèrera réaliser l'opération en utilisant un protocole de chiffrement (SFTP par ex.) pour ne pas exposer les communications qui peuvent contenir des informations sensibles.

Selon le cas, utiliser l’application elle-même ou un script SQL fourni avec elle pour mettre en place la base de données de production.

Dans de nombreux cas, il faudra envisager d'adapter le paramétrage de l’application, via ses fichiers de configuration, pour qu’elle opère dans les conditions propres à l'hébergement. Typiquement, il pourra s’agir de mettre à jour les informations du compte utilisateur à employer pour accéder à la BdD. Mais, à ce stade, le champ possible des adaptations à réaliser est tellement large qu’il ne sera pas question d’en dresser l’inventaire ici.

Une très bonne pratique consistera ici à avoir anticipé (presque) toutes les spécificités de la plateforme de production et à les avoir mises en œuvre à l’identique sur la plateforme de développement. De cette manière, il n’y aura (presque) aucune adaptation à réaliser dans la configuration au moment de sa mise en ligne.

Dès lors, on considèrera que l’application est en ligne dans des conditions lui permettant de subir une phase de tests fonctionnels conçus selon la structure des cas d’utilisations. Chaque cas d’utilisation sera testé au moyen d’une série de situations, qu’elles soient nominales ou alternatives (exceptions), la plus large possible (couverture).

Dans le cas d’une application pour laquelle le référencement est une nécessité, on suppose que le travail en SEO a été réalisé en amont. Il s’agira donc ici de vérifier après quelques semaines de fonctionnement le niveau de qualité de ce référencement.

Toute application mise en ligne s’ouvre à de potentiels actes malveillants. Le développement de l’application aura évidemment dû en tenir compte (voir la checklist SWAT).

Pour vérifier la robustesse de l’application, il faudra alors intégrer une séquence de test d’intrusion (Pen Testing) qui pourra, le cas échéant, laisser apparaitre telle ou telle insuffisance.