Différences

Ci-dessous, les différences entre deux révisions de la page.

--- bloc2:prog:web:deploiement [2023/04/06 16:42] – [Remonter le code de l’application via un client ftp] admin
+++ bloc2:prog:web:deploiement [2023/04/06 18:43] (Version actuelle) – [Procédure de déploiement d’une application web] admin
@@ Ligne 1: / Ligne 1: @@
-====== Procédure de déploiement d’une application web ======
+====== Déploiement d’une application web ======
 ===== Choisir un nom de domaine =====
 Pour commencer, on pourra consulter cette page de [[https://www.afnic.fr/noms-de-domaine/tout-savoir/|l'Afnic]]
@@ Ligne 42: / Ligne 42: @@
 ===== Remonter le code de l’application via un client ftp =====
 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 chiffrage (**SFTP** par ex.).
+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.
 ===== Mettre en place la base de données =====
+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.
 ===== Adapter les fichiers de configuration de l’application =====
+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.
 ===== Tester l’application =====
+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**).
 ===== Référencement =====
+Dans le cas d’une application pour laquelle le référencement est une nécessité, on suppose que le travail en [[https://fr.wikipedia.org/wiki/Optimisation_pour_les_moteurs_de_recherche|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.
 ===== Cyber sécurité =====
+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 [[https://www.sans.org/cloud-security/securing-web-application-technologies/?msc=cloud-security-lp|checklist SWAT]]).
+Pour vérifier la robustesse de l’application, il faudra alors intégrer une séquence de test d’intrusion ([[https://fr.wikipedia.org/wiki/Test_d'intrusion|Pen Testing]]) qui pourra, le cas échéant, laisser apparaitre telle ou telle insuffisance.