Un nom de domaine sans hébergement ou plan MX : la solution avec Google Apps

Un nom de domaine sans hébergement ou plan MX : la solution avec Google Apps

Ce billet est le troisième de la série . Nous avons vu comment utiliser Gmail dans deux cas déjà :

  • Le cas où on fait gérer les mails d’un nom de domaine par OVH (hébergement ou plan MX) et on utilise Gmail dans sa version gratuite pour lire et expédier des mails venant de, ou provenant de, l’une de ces adresses créées sur OVH. C’était l’objet du premier article de cette série, Utiliser sa boîte gmail avec des mails d’un hébergement OVH ;
  • Un cas où l’on gère les mails d’un nom de domaine par OVH et où l’on a un compte Google Apps (son nom est devenu récemment G Suite) et l’on utilise un alias de nom de domaine pour faire gérer certaines adresses du domaine directement par Google. C’est ce dont il était question dans l’article Transférer la gestion des emails d’un domaine de google apps à OVH

Nous allons maintenant voir un troisième cas : le cas où on a un compte Google Apps ET des noms de domaine sans hébergement et sans plan MX chez OVH.

Le contexte

Sur OVH, j’ai un nom de domaine, potentiel-web.com, qui n’a pas son propre hébergement. Je ne peux donc pas y créer d’adresse mail.

Mais comme j’ai un compte Google Apps, je peux créer des adresses mail pour ce domaine et Google les gère !

Etape 1 : régler les enregistrements MX du domaine

Dans l’espace client OVH, menu Domaines / le domaine qu’on veut régler, aller dans l’onglet « zones DNS ».

Au dessus de la liste des zones DNS, remplacer « tous » dans le filtre par « MX ». On ne voit plus que les enregistrements MX pour le domaine et ses sous-domaines éventuels.

Modifier ou ajouter des enregistrements MX pour avoir :

MX Adresse du serveur Priorité
ASPMX.L.GOOGLE.COM. 1
ALT1.ASPMX.L.GOOGLE.COM. 5
ALT2.ASPMX.L.GOOGLE.COM. 5
ASPMX2.GOOGLEMAIL.COM. 10
ASPMX3.GOOGLEMAIL.COM. 10

Ces 5 enregistrements MX disent à tout internet « si tu reçois un mail de ce domaine, voici le serveur qui doit le prendre en charge« .

Il semble également préférable de faire les modifications suivantes dans les zones DNS sur le compte OVH :

  • supprimer le champ SPF pour le domaine (qui contient « v=spf1 include:mx.ovh.com ~all ») ;
  • ajouter un champ TXT pour le domaine avec le contenu « v=spf1 include:_spf.google.com ~all ».

Les deux dernières modifications disent à tout internet « ce mail émis par un serveur google est authentifié par google ». Ca limite le risque de voir ce mail classé en spam.

Il faut attendre 24h pour que ces 7 modifications soient diffusées : on peut regarder sur whatsmydns.net la vitesse de propagation. C’est instructif !

Il vaut donc mieux attendre ces 24h avant de faire la suite de ce tutoriel.

Créer un domaine dans la console Google Apps

Dans la console d’administration google apps, menu Domaines cliquer sur le bouton « ajouter un domaine ou un alias de domaine ».

J’ai ainsi créé potentiel-web.com. Je clique ensuite sur le lien « configurer les enregistrements MX pour Google »

Google Apps (G Suite) Créer un alias de domaine - 2

Google Apps (G Suite) Créer un alias de domaine – 2

Comme j’ai déjà fait l’opération sur mon compte OVH, il me suffit de descendre tout en bas e la page qui s’ouvre et cliquer sur « j’ai effectué cette procédure ». Google vérifie puis la ligne correspondante au domaine devient « actif »

Google Apps (G Suite) Vérifier un alias de domaine 2

Google Apps (G Suite) Vérifier un alias de domaine 2

 

Créer un alias d’email dans Google Apps

Dans la console d’administration google apps, menu utilisateur, cliquer sur mon nom puis sur « compte »

Je vois alors une liste d’alias. Je peux en ajouter (par exemple contact@potentiel-web.com »).

A ce stade Gmail lit automatiquement tous les mails adressés à l’alias d’email créé. Mais il faut maintenant paramétrer Gmail pour qu’il accepte d’expédier ces mails en tant que l’alias. 

Paramétrer pour expédier « en tant que » cet alias

Dans Gmail, paramètres, onglet comptes, cliquer sur « ajouter une autre adresse mail » dans le champs correspondant à « Envoyer des e-mails en tant que : ». La fenêtre suivante s’ouvre (lorsqu’on crée, l’adresse mail est un champ qu’on peut modifier) :

Gmail gérer un alias d'adresse mail 2

Gmail gérer un alias d’adresse mail 2

 

On remplit avec l’adresse mail correspondant à l’alias d’e-mail créé précédemment puis on clique sur le bouton « Etape suivante ».

Ca y est, c’est fini ! Gmail lit les mails adressés à contact@potentiel-web.com et en expédie sous ce nom alors qu’OVH gère le nom de domaine mais pas les mails.

Et maintenant ?

Cette série est en principe terminée. J’ai exploré les 3 cas d’utilisation de Gmail.

Transférer la gestion des emails d’un domaine de google apps à OVH

Transférer la gestion des emails d’un domaine de google apps à OVH

Je gérais les mails du domaine parcours-performance.com avec mon compte google apps. Mais c’était un peu compliqué d’ajouter de nouvelles adresses. J’ai donc supprimé les enregistrements MX du domaine qui transféraient la gestion des mails de ce domaine et OVH les gère de nouveau. J’explique ici comment j’ai procédé, avec l’aide du SAV de Google.

Le contexte

Mon compte google for work (G Suite maintenant) dispose d’un seul utilisateur, dont l’adresse mail pour accéder au compte Google était (ce n’est pas la véritable adresse !) « moi@parcours-performance.com ». Cette adresse mail étant mon adresse professionnelle principale, il n’était pas question de la supprimer.

Les mails du domaine « parcours-performance.com » étaient gérés par Google car j’avais réglé les enregistrements MX d’OVH ainsi :

Domaine TTL Type Cible
parcours-performance.com. 0 MX 5 alt1.aspmx.l.google.com.
parcours-performance.com. 0 MX 5 alt2.aspmx.l.google.com.
parcours-performance.com. 0 MX 1 aspmx.l.google.com.
parcours-performance.com. 0 MX 10 aspmx2.googlemail.com.
parcours-performance.com. 0 MX 10 aspmx3.googlemail.com.

Dans Google Apps, j’avais créé deux adresses mail : « moi@parcours-performance.com » et « contact@parcours-performance.com » et j’avais complètement oublié comment.

Dans l’espace client OVH, je pouvais créer de nouvelles adresses sur le domaine parcours-performance.com mais elles ne fonctionnaient pas puisque ce n’était plus OVH qui gérait les mails…

Avec l’aide du SAV de Google (très bien, gratuit pour les abonnés de G Suite), j’ai transféré la gestion des mails à OVH et demandé à gmail de gérer les mails correspondants.

Les actions à mener pour transférer la gestion des mails

Activer la double distribution de Google

Ce document d’aide de Google en explique le principe.

Dans la console d’administration google apps, menu Domaines, cliquer sur le bouton « ajouter un domaine ou un alias de domaine ». J’ai créé whatever.parcours-performance.com.

Google Apps (G Suite) Créer un alias de domaine

Google Apps (G Suite) Créer un alias de domaine

Ensuite je clique sur le lien « configurer les enregistrements MX pour Google » pour avoir les instructions.

Dans un autre onglet, je me connecte à l’espace client OVH, menu « domaines » et j’ajoute (ou modifie) les enregistrements MX de cet alias de domaine pour que :

MX Adresse du serveur Priorité
ASPMX.L.GOOGLE.COM. 1
ALT1.ASPMX.L.GOOGLE.COM. 5
ALT2.ASPMX.L.GOOGLE.COM. 5
ASPMX2.GOOGLEMAIL.COM. 10
ASPMX3.GOOGLEMAIL.COM. 10

Lorsque c’est fait dans OVH, je retourne dans l’onglet Google Apps, et tout en bas de la page « configurer les enregistrements MX pour Google », je clique tout en bas sur « j’ai effectué cette procédure ». Google vérifie puis la ligne correspondante au domaine devient « actif »

Google Apps (G Suite) Vérifier un alias de domaine

Google Apps (G Suite) Vérifier un alias de domaine

 

Il vaut mieux attendre 24 h que les enregistrements MX se diffusent dans le monde. Une fois que c’est fait, tout mail adressé @whatever.parcours-performance.com sera géré par Google et non par OVH.

Pour l’adresse principale créer un alias d’adresse email dans google apps

Dans mon compte Google Apps (console d’administration google apps, menu utilisateurs), je clique sur le nom de mon compte. Ca ouvre une fenêtre avec des informations sur ce compte. En cliquant sur l’élément « compte », je vois les alias d’email que j’ai déjà.

A ce stade, « moi@parcours-performance.com » est défini parmi les alias dans Google Apps. Je n’y touche pas.

Ensuite, dans le compte OVH, je crée un compte « test.al@parcours-performance.com ». Toujours dans OVH, je crée une redirection de ce compte vers « test@whatever.parcours-performance.com » (noter que j’utilise l’alias de nom de domaine, pas le nom de domaine) :

A ce stade, si j’envoie un mail à « test.al@parcours-performance.com », je ne le reçois pas car je n’ai pas défini où il doit être lu.

Pour qu’il arrive automatiquement dans ma boîte mail GMail, il faut que je paramètre Gmail pour qu’il lise test@whatever.parcours-performance.com :

Dans gmail, Paramètres puis onglet comptes, cliquer sur « ajouter une autre adresse mail »

Google Apps Créer un alias d'adresse mail

Noter que j’indique l’alias de domaine pour l’adresse email.

Lorsque je clique sur le bouton « étape suivante », c’est fini. Gmail est maintenant capable de gérer cet alias d’email.

Maintenant si quelqu’un envoie un mail à l’adresse test.al@parcours-performance.com, gérée par OVH, elle est automatiquement redirigée dans ma boîte gmail. Pour moi c’est totalement transparent (je n’ai même pas à me souvenir du nom de l’alias) et je réponds en tant que test.al@parcours-performance.com par défaut.

Evidemment, ceci était un test pour vérifier le bon fonctionnement du système avec alias et je peux supprimer l’adresse test.al@parcours-performance.com dans l’espace OVH.  Il faut maintenant qu’OVH reprenne la gestion des mails du domaine Parcours-Performance.com.

Gérer mon adresse principale par OVH et non google

Dans mon espace client OVH, menu « Emails » du domaine (parcours-performance.com pour moi), enlever le filtrage qui transfère la gestion des mails à Google. Merci au support OVH de m’avoir expliqué celà !

Il suffit d’éditer le champ « filtrage antispam/antivirus et le régler sur « OVH sans protection ». On notera que si ce n’est pas Gmail qui est utilisé ensuite pour recevoir les mails, il vaut sans doute mieux mettre une protection antispam.

OVH enlever le filtre MX

Tout à l’heure, on avait regardé les alias d’emails dans le compte Google Apps. J’avais noté que deux adresse du domaine parcours-performance.com étaient définies comme des alias : « moi@parcours-performance.com » et « contact@parcours-performance.com ».

transfert de gestion des mails d'un domaine, de google for work à ovh

Je ne touche pas aux alias d’emails définis dans Google Apps pour l’instant.

Mais je vais créer dans l’espace OVH les deux mêmes adresses mail. Je crée les deux adresses dans OVH puis je les redirige respectivement vers moi@whatever.parcours-performance.com et contact@whatever.parcours-performance.com (noter que c’est toujours l’alias de nom de domaine que j’utilise.

OVH : rediriger une adresse mail ovh vers un alias de domaine

OVH : rediriger une adresse mail ovh vers un alias de domaine

On peut préférer que la redirection fasse conserver une copie du mail dans les boîtes OVH pour gérer les prochaines 24h et être certains que les mails ne se perdront pas.

A ce stade, comme mon Gmail récupérait déjà les adresses « moi@parcours-performance.com » et « contact@parcours-performance.com », il récupère sans difficulté les mails.

supprimer des alias du compte Google Apps

Pour faire cette opération, il faut IMPERATIVEMENT attendre 24h après la modification des enregistrements MX de parcours-performance.com d’une part, et de l’alias whatever.parcours-performance.com.

Lorsque les 24h depuis le changement le plus récent sont finies, on va supprimer les alias « moi@parcours-performance.com » et « contact@parcours-performance.com » dans notre compte Google Apps.

Et si on avait fait une redirection sur OVH qui conservait une copie des mails, on peut maintenant aller la modifier (il suffit de supprimer la redirection de « moi@parcours-performance.com » vers « moi@parcours-performance.com » et conserver celle qui va vers « moi@whatever.parcours-performance.com »

Et si je veux créer une nouvelle adresse mail ?

Deux options : si c’est une adresse très utilisée, pour laquelle il faut prévoir un gros espace disque, il est plus simple d’utiliser un alias de domaine, avec gestion des mails de ce domaine par google. Pour les autres cas, on paramètre simplement Gmail.

Par exemple, j’ai créé test-al2@parcours-performance.com dans OVH, avec redirection sans copie vers moi@whatever.parcours-performance.com.

Ensuite, je suis allée dans Gmail « paramètres, onglet compte » et j’ai choisi « ajouter une autre adresse mail ». Ca se passe ensuite exactement comme pour un compte gmail classique (cf le premier article de cette série, « Utiliser sa boîte gmail avec des mails d’un hébergement OVH« ), sauf que si le domaine de l’email fait partie des domaines enregistrés pour le compte Google Apps, il n’y a pas l’écran dans lequel on doit définir les paramètres SMTP. Et comme j’ai fait une redirection, je reçois le mail avec le code de confirmation directement dans ma boîte gmail.

Et maintenant ?

Il reste un cas particulier d’utilisation de google Apps (G Suite), c’est le cas où on a un domaine chez OVH mais pas d’hébergement et pas de « plan MX ». G Suite nous permet de créer des adresses mail sans supplément de coût, avec un paramétrage plutôt simple. Ce sera l’objet du troisième article de cette série .

wordpress multisite : gestion des utilisateurs

wordpress multisite : gestion des utilisateurs

Vous avez crée votre réseau de site WordPress avec la fonctionnalité multisites. Jusqu’à présent, il était possible d’avoir le même identifiant (même adresse mail) en tant qu’utilisateur de différents sites. Mais sur un multisite, si j’utilise le même identifiant pour créer des contenus dans plusieurs sites, ils auront tous les mêmes renseignements biographiques.

Pourquoi éviter d’avoir un seul identifiant ?

Pour des renseignements biographiques ciblés sur les thématiques du site

Par exemple sur ce site, knowledge.parcours-performance.com, j’utilise la même adresse mail comme administrateur que pour mon site parcours-performance.com et je n’y ai pas mis les mêmes renseignements biographiques. C’est logique puisque mon parcours « maker » n’intéresse pas les lecteurs de l’autre site et mon parcours « organisation et lean management » ne vous intéresse pas. En multisite, si je veux avoir des renseignements biographiques différents pour le même auteur, il faut des identifiants différents (donc des adresses mail différentes).

Car WordPress est fait comme ça…

WordPress gère les utilisateurs pour l’ensemble des sites du réseau avec un identifiant unique et une adresse mail unique. On ne peut donc pas se créer plusieurs fois…

Pour des raisons de sécurité

Les identifiants et mots de passe des super administrateurs donnent l’accès à toute la machinerie du site. Ils doivent donc être protégés, et jamais enregistrés sur l’ordinateur. Imaginez ce qui se passerait si votre nièce ou votre fils allait modifier des éléments du tableau de bord du réseau !

Pour éviter les erreurs

Social network (Flickr)

https://c5.staticflickr.com/9/8085/8562448300_2a5c7b1e59.jpg

Une erreur sur un site isolé est déjà très embêtante, alors sur un ensemble de sites…

Lorsqu’on met notre « casquette » d’éditeur, on peut rédiger et publier des contenus.

Lorsqu’on met notre « casquette » d’administrateur d’un site, on peut modifier la structure du site (avec quelques limites).

Et lorsqu’on est enregistré en tant que super administrateur, on a tous les droits : on peut ajouter des extensions sans même s’être préoccupé de leurs compatibilité multisite ou de leur sécurité, on peut faire des mises à jour sans avoir au préalable vérifié les impacts sur un site de développement, …, on peut casser plusieurs sites d’un clic !

Il est donc préférable d’avoir l’esprit tranquille lorsqu’on est éditeur : on ne peut rien faire de très grave. Lorsqu’on est administrateur, on doit déjà réfléchir à deux fois aux conséquences d’un clic. Et lorsqu’on est super administrateur, on doit être ultra-vigilant, presque paranoïaque, et systématiquement tester nos choix avant de les mettre en oeuvre.

Les bonnes pratiques adoptées sur mes sites multisites

Principe n°1 : une même personne peut avoir plusieurs rôles mais elle a un identifiant par rôle (et donc une adresse mail différente par rôle).

Principe n°2 : sur deux sites différents d’un même multisite, un même auteur (ou éditeur) a un identifiant différent et donc une adresse mail différente. Il/elle peut ainsi avoir des renseignements biographiques différents et choisir des couleurs de tableau de bord différentes pour limiter les erreurs.

Principe n°3 : une personne qui peut avoir accès à l’ensemble du multisite est super administrateur. Elle peut avoir les fonctions d’administrateur dans n’importe quel site sans changer d’identifiant. A l’inverse, une personne qui peut être administrateur d’un ou plusieurs sites ne dispose pas des droits de super-administrateur.

Nota : pour éviter de mémoriser un nombre délirant d’identifiants et mots de passe, il est possible d’utiliser une extension comme « user switching« , qui permet de changer de rôle simplement. On peut aussi explorer des gestionnaires de mot de passe comme LastPass ou KeePass, voire Dashlane.

Créer les bons utilisateurs aux bons endroits dans un multisite

Pour l’instant, je vais considérer que nous avons assez d’adresses mail distinctes, et que nous en recevons tous les messages au fur et à mesure. Dans un article à venir, j’en parlerai plus précisément.

Le contexte :

Je suis dans un multisite dont le site principal contient une centaine d’articles écrits par moi lorsque je n’étais que « administrateur » de ce site solo. Maintenant, ce même identifiant est devenu « super administrateur ».

D’autres sites sont venus s’ajouter dans le multisite et il faut que je reste l’auteure de ses contenus, mais avec un autre profil pour ne pas être obligée d’avoir des renseignements biographiques uniques.

Ce que je vais faire :

Je vais définir des adresses différentes pour tous les rôles suivants.

Pour le site principal (PRINCIPAL.com) :

rôle adresse mail correspondante
Super administrateur SUPER-ADMIN@PRINCIPAL.com
administrateur ADMIN@PRINCIPAL.com
éditeur (ou autre) EDITEUR@PRINCIPAL.com

pour les « sous » sites du réseau « SOUS.PRINCIPAL.com, on peut être administrateur avec l’identifiant du site principal mais si on produit des contenus on le fera sous l’identifiant de l’éditeur spécifique à ce sous site.

rôle adresse mail correspondante
éditeur (ou autre) EDITEUR-SOUS@PRINCIPAL.com

Mon site de test est composé de trois sites :

  1. le site principal, potentiel-web.com
  2. un site secondaire, test1.potentiel-web.com
  3. un site secondaire, test1.parcours-performance.com

Il va donc falloir que je crée les utilisateurs avec des mails ressemblant à ce qui suit :

Pour potentiel-web.com :

Super administrateur super-admin[a]potentiel-web.com
administrateur admin[a]potentiel-web.com
éditeur editeur[a]potentiel-web.com

Pour test1.potentiel-web.com

éditeur editeur-test1[a]potentiel-web.com

Pour test1.parcours-performance.com, j’utilise le nom de domaine principal, pas celui du site principal.

éditeur editeur-test1[a]parcours-performance.com

Comment je le fais :

Comme les deux sites ajoutés dans le réseau sont des sites tous neufs, il n’y aucun contenu dedans. Je n’ai donc pas à me préoccuper de transférer les contenus à un nouvel utilisateur. Mais pour le site principal, il faut que je puisse transférer le contenu du super administrateur actuel à un simple éditeur.

créer les utilisateurs dans l’administration du réseau

Pour tous les sites, principal ou pas, je vais dans « Mes sites » > « Admin du réseau » > « Utilisateurs » et j’y crée un à un les 7 comptes indiqués ci-dessous avec le bouton « ajouter ».

WordPress multisite : ajouter un utilisateur

Lorsque j’ai créé les trois premiers, la liste de mes utilisateurs devient comme ci-dessous. Pour des raisons évidentes de sécurité, ce sont des identifiants que je n’utiliserai pas, pas plus que les adresses mails indiquées. Et il faut noter que je suis connectée en tant que super administrateur avec un identifiant qui n’est pas affiché dans cette liste mais qui le sera pour vous.

WordPress multisite : liste des utilisateurs

Pour l’instant ces utilisateurs n’ont aucun rôle (et ils n’en auront jamais puisque les adresses mail n’existent pas, je ne pourrai donc jamais générer un mot de passe…).

Pour le super administrateur, je clique sur modifier puis je coche la case « Donner les privilèges de super-admin à cet utilisateur pour le réseau. ». superadminwhatever est maintenant devenu super administrateur !

Donner des rôles aux utilisateurs dans les différents sites

Les 2 autres utilisateurs ci-dessus doivent avoir des rôles dans le site primaire, potentiel-web.com.

Dans « Mes sites » > « Admin du réseau » > « Sites », j’ai la liste des sites du réseau. Lorsque je survole le nom d’un site, je vois apparaître des liens.

Je clique sur « modifier » en dessous du nom du site principal. Je vois alors un écran avec 4 onglets. Je vais dans « utilisateurs ».

Sous la liste des utilisateurs déjà affectés, il y a la possibilité d’ajouter un utilisateur existant. Je tape les premiers caractères d’un utilisateur et WordPress me propose un utilisateur. Je lui donne le rôle correspondant. Je fais ça pour l’éditeur et l’administrateur de chaque site.

transférer les contenus du super administrateur actuel à l’éditeur

Il faut avant avoir rempli le prénom et le nom de l’utilisateur, relié le compte à une photo (gravatar), et rempli les renseignements biographiques du compte éditeur.

Lorsqu’on supprime le super administrateur (il faut s’être reconnecté au préalable sous l’identifiant du nouveau superadministrateur), WordPress demande à qui on veut attribuer le contenu de cet utilisateur. On l’attribue à editeurwhatever et le tour est joué !

Et maintenant ?

Il faudra apprendre à gérer de nombreux identifiants et mots de passe…

Transformer un site WordPress existant en multisite

Transformer un site WordPress existant en multisite

Je souhaite transformer un site existant (https) en un site multisite WordPress. En principe, c’est exactement comme ce que j’ai fait avec le site de test dans le premier article de cette série. La seule différence, c’est que je ne peux pas me permettre d’erreur puisque le site est utilisé

Je fais comme indiqué dans le premier article de cette série , avec en plus des sauvagardes et la gestion des extensions existantes.

Sauvegarder les éléments du site existant

  1. En premier, faire une sauvegarde de la base de données du site et la conserver dans un endroit sûr.
  2. Avec Filezilla ou équivalent, faire une copie des fichiers .htaccess  (en .htaccessOLD) et wp-config.php  (en wp-configOLD.php).
  3. Dans le tableau de bord WordPress du site existant, aller dans le menu « extensions » puis choisir la vue « extensions activées ». Copier le tableau dans Word ou autre pour disposer d’une liste de toutes les extensions activées du site.

Transformer le site en site multisite WordPress

Ca fonctionne exactement comme dans l’article « Un site ‘multisite’ WordPress sur OVH mutualisé ».

(1) Dans wp-config.php , j’ajoute les deux lignes suivantes :

/* Multisite */
define('WP_ALLOW_MULTISITE', true);

Dans le tableau de bord WordPress, (2) je désactive toutes les extensions puis je vais dans le menu « outils » > « création du réseau ». Là je ne peux que choisir « sous-domaines », je met mes coordonnées d’administrateur comme nom de super-administrateur et je sauvegarde.

(3) Je modifie  wp-config.php pour que les lignes correspondant aux multisite soient maintenant (attention dans la ligne 6 surlignée, le nom du domaine doit être le bon) :

/* Multisite */
define('WP_ALLOW_MULTISITE', true);

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'monsite.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
/* HTTPS only for admin access */
define( 'FORCE_SSL_ADMIN', true );

define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');

(4) Je modifie .htaccess  qui contient maintenant (c’est un site en https) :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

# direct everything to https
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress

(5) Je me reconnecte au tableau de bord WordPress du site.

Je sélectionne toutes les extensions qui doivent être réactivées puis (6), je les active pour les reseau.

Je vérifie et tout va bien. Du point de vue de l’internaute, le site est comme avant. Evidemment, du point de vue de l’administrateur devenu super-administrateur, il y a quelques changements.

Et maintenant ?

Il faut que je voies quelles sont les différences entre ‘super-administrateur’ et ‘administrateur’ pour voir quels sont les points de vigilance à prévoir. Ce sera l’objet d’un autre article de cette série .

Connaissances et compétences d’un bon développeur web

Connaissances et compétences d’un bon développeur web

Je progresse en informatique et en développement web mais j’aimerais pouvoir mesurer où j’en suis et ce qu’il me reste à apprendre. J’entreprends donc de dresser la liste des connaissances et compétences d’un bon développeur web. Cette liste me servira ensuite pour définir mes prochaines actions d’amélioration.

Mes sources d’information et d’inspiration

Les critères « soft skills »

  1. Capacité à entrer en relation avec les autres (empathie, communication, …)
  2. Gestion du stress
  3. Gestion du temps
  4. Prendre du recul : pourquoi je fais ça, qu’est-ce que je fais au delà des tâches concrètes ? Ca peut-être « je résoud des problèmes complexes et intéressants », « je travaille dans un environnement intellectuellement stimulant », « je construis des choses qui me plaisent », …
  5. identifier ce qui apportera de la valeur au client (et donc aux clients du client)
  6. identifier le niveau d’expertise que peut atteindre le client pour créer un site toujours actuel (si possible souvent actualisé) sans recourir à des compétences trop coûteuses pour celà
  7. Définir ce que l’internaute voudra (conception de l’interface utilisateur)
  8. pas de peur d’échouer au point que ça bloque les approches créatives et nouvelles, mais assez pour faire des tests sérieux.

L’aptitude au code

Source : https://medium.com/@sgarcia.dev/

 

Maîtrise des « langages »

  1. Maîtriser la programmation (hors syntaxe)
    1. Maîtrise des concepts de l’informatique tels que Model – View – Controller, Programmation orientée objet, …)
    2. Savoir créer des algorithmes
  2. Maîtrise des outils actuels de base
    1. des langages sous-jacents tels que PHP (côté serveur), Javascript (côté client), SQL pour les bases de données ;
    2. du codage de pages web (html5, css3, ….) ;
    3. des outils de test : du code, des caractéristiques responsive, firebug ou chrome dev tools, des rendus sur des moteurs différents (Gecko tel que Firefox, WebKit tel que SafariChrome, Internet Explorer et Opera) ;
    4. Autres tels que utilisation de SVG.
  3. Maîtrise d’outils plus sophistiqués
    1. des outils d’automatisation tels que Sass & Less, Grunt & Gulp (ces deux derniers nécessitent de savoir faire fonctionner NodeJS) ;
    2. compréhension du DOM (document Object model) et d’AJAX
    3. utilisation de Ruby, angularJS, REACT (voir son utilisation avec l’API Rest de WordPress dans Building a better WordPress) & Redux
Monter en compétences

Source : https://pixabay.com/fr/ascenseur-berlin-ludwig-erhard-haus-1598431/

capacité à obtenir des résultats

  1. savoir créer un thème wordpress
  2. savoir créer une extension wordpress
  3. concevoir un site rapide, sûr
  4. créer un site crypté en SSL (https)
  5. gérer l’accessibilité, les cookies, si nécessaire prévoir une version pour les imprimantes (css)…
  6. administration du serveur (hébergement)
  7. API

Méthodes de travail

Connaissance du workflow le mieux adapté au cas présent.

  1. Savoir déployer un environnement de test puis le transférer à l’environnement de production
  2. choisir ses outils de développement et debogage – voir aussi https://atom.io/
  3. gérer les versions (git ou Subversion )
  4. gestion de projet

L’aptitude au design

Aptitude à identifier ses limites techniques, à estimer le temps requis et la faisabilité d’un choix d’interface.

Comprendre les bases du design telles que la typographie, les choix de couleurs, les conceptions de grilles sous un angle visuel (et pas technique).

L’idée est « d’en savoir assez pour savoir quand on n’en sait pas assez » (Tim Wright dans The 5 Most Important Skills a Web Developer Needs).

L’utilisation d’autres outils / concepts essentiels

  1. Maîtrise du SEO
  2. Savoir choisir et régler des extensions wordpress
  3. Savoir utiliser wordpress (de l’activation d’un thème ou d’une extension à la création d’un « multisite » ou réseau de site)
  4. Utiliser google analytics
  5. utiliser OVH
  6. utiliser google for webmasters tools
  7. savoir maintenir un site
  8. traiter l’information, la mettre en perspective, la rendre intéressante
  9. savoir créer un site marchand efficace
  10. Savoir créer un site multilingue

Comment s’évaluer ?

Comme point de départ et jalons intermédiaires, il faudra lire cet article sur le syndrome de l’imposteur… : Breaking Out of Imposter Syndrome and Isolation ;

Après avoir lu attentivement l’article My journey to becoming a web developer from scratch without a CS degree, 2 years later (and what I learned from it), j’ai identifié des actions à mener pour mieux voir ce que je sais / ne sais pas :

Je liste quelques pistes, que je vais explorer :

Et maintenant ?

Il n’y a plus qu’à chercher à m’évaluer et apprendre ce qui correspondra à la prochaine étape du développement de mes compétences informatiques !