Pour cette septième « interview », j’ai le plaisir de recevoir Ghislain Phu, j’ai surnommé « le Mike Horn de la ligne de code ».

Pur développeur, mais aussi utilisateur de WordPress, c’est suite à ce tweet que j’ai supplié @poupi de bien vouloir nous accorder une interview, et je peux déjà vous dire que je ne regrette pas de l’avoir fait.

Mister WP

Bonjour Ghislain ! Peux-tu te présenter à nos lecteurs ?

The Mike Horn of the line of code.

Bonjour et merci pour cette invitation qui me va droit au cœur !

Je m’appelle Ghislain, j’ai 26 ans, je vis actuellement à Calais, et je partage ma vie entre deux de mes passions qui sont la randonnée au long cours et le développement Web que j’exerce en tant que Freelance depuis 2011.

Randonnées, développement Web.

Les lecteurs auront compris pourquoi je t’ai surnommé « le Mike Horn de la ligne de code ». 😀

Mais ce n’est pas uniquement parce que tu fais de la rando. Alors, dis-nous, comment as-tu découvert le Web ?

Je crois que c’était en 1999. À l’époque, le matériel micro-informatique (je vous jure qu’on disait comme ça !) coûtait encore un bras et nous n’avions pas la chance d’avoir d’ordinateur à la maison.

Je venais de déménager et habitant beaucoup trop loin de l’école pour rentrer chez moi le midi, les parents de mon meilleur ami avaient gentiment proposé de m’accueillir à leur table deux jours par semaine. Enfin… À leur table et surtout derrière leur ordinateur équipé d’une connexion Internet 56K 😀

J’étais trop jeune pour comprendre ce qu’était le Web et Internet. Je connaissais bien le Minitel et le téléphone… Internet devait être situé quelque part entre les deux.

Un jour, on m’a demandé d’envoyer un e-mail. Un peu gêné de ne pas savoir comment faire, j’ai demandé de l’aide. On m’a créé un compte sur CaraMail, choisi un magnifique pseudo digne des années 90 et initié à l’art mystique de l’envoi d’e-mails. Le premier tout juste parti, j’ai compris que je n’avais rien compris :

  • Mais… Comment on paye ?
  • Payer quoi ?
  • Bah… Pour envoyer des e-mails ?
  • Mais c’est gratuit !

Et c’est là que ça a fait tilt !

Internet n’était ni le téléphone, ni le Minitel, mais un truc (toujours pas très clair dans ma tête) permettant d’échanger de l’information avec n’importe qui, n’importe où, et n’importe quand.

C’est aussi là que j’ai commencé à paniquer et à me dire que si c’était gratuit, Internet allait forcément finir par fermer. Mais ce n’était pas très grave, puisque rusé comme je l’étais, j’avais prévu le coup et acheté deux boîtes de disquettes 3″½ pour sauvegarder toutes les pages intéressantes avant sa fermeture ! (malin !)

En 2006, notre première Box est arrivée. Après avoir englouti mon repas en trois secondes (si impatient d’ouvrir le colis), et passé les vingt minutes suivantes à quatre pattes les doigts dans la gorge pour essayer d’extraire une branche de thym que j’avais avalé de travers, j’ai installé la bête et découvert les joies de l’Internet à la maison.

J’ai redécouvert CaraMail et me suis lié d’amitié avec des inconnus qui m’ont amené au Jeu de Rôle par forums interposés. J’ai ensuite eu envie d’ouvrir mon propre forum, et grâce au Site du Zéro et à Wikipédia, j’ai pu faire partie de cette petite élite de personnes capables de mettre un lien sur une image ET de la centrer grâce à un langage obscur appelé HTML.

De fil en aiguille, j’ai finalement compris ce qu’était le Web, ce qu’était Internet, et qu’ils mettaient toute la connaissance du monde à notre portée. J’ai découvert la programmation, et compris que la magie n’avait rien à voir avec tout ça ; que les ordinateurs n’étaient que des tas de puces bêtes à manger du foin et que l’on pouvait leur murmurer des mots doux à l’oreille pour leur faire faire tout un tas trucs très cool !

Mais grave ! Ça faisait rêver !

Et tu m’as tué avec tes 2 boîtes de disquettes ! 😀

Maintenant que tu as capté ce qu’est Internet et que ça fait partie de notre quotidien à tous, comment occupes-tu ton temps, en dehors de la rando bien sûr ?

Je consacre environ les trois quarts de l’année à mon métier de développeur que j’adore et que j’exerce en freelance, ce qui me permet de gérer mon temps comme je le souhaite et de passer le reste de l’année à randonner pour voir un peu de paysage (essentiellement montagnard).

Techniquement, je suis développeur Web back-end spécialisé en PHP, mais je me considère avant tout comme « un développeur ». Front-end, back-end, PHP ou JavaScript, peu importent les outils, nous faisons tous le même métier !

J’ai essentiellement travaillé dans le domaine de la radio, mais depuis deux ans, j’emploie également une partie de mon temps à la formation de développeurs juniors chez moji, qui est un opérateur Internet avec qui je collabore depuis ses débuts.

Tu nous indiquais passer trois quarts de l’année dans le code. Est-ce que cela signifie que tu prends de longues périodes de congés pour te permettre de partir retrouver la nature ? Si c’est le cas, comment tes clients et ton associé peuvent-ils se passer de tes compétences ? (moi aussi j’aime faire de longues pauses pour voyager, cela n’est pas toujours très facile à gérer avec les clients)

Effectivement, c’est le cas ! Mais avant de répondre à la question, il y a une anecdote que j’aimerais raconter 🙂

La plupart de nos clients ont des besoins spécifiques en matière d’hébergement qui nous imposent souvent d’avoir un contrôle total sur les serveurs (matériel inclus). Comme les serveurs étaient éparpillés un peu partout et tous configurés différemment, c’était une vraie plaie à administrer au quotidien ; si bien qu’un jour, nous avons décidé d’investir dans nos propres serveurs pour regrouper tout ça.

Après avoir monté ces nouveaux serveurs dans un datacenter dans lequel nous avions un accès physique, nous avons migré toutes les anciennes machines avant que mon associé ne me donne carte blanche pour nettoyer et uniformiser l’ensemble. Grave erreur ! 😀

La technologie à la mode à l’époque était Puppet, et comme j’en avais entendu beaucoup de bien et que j’avais vraiment très envie de jouer avec, je me suis précipité sur Amazon pour acheter un livre que j’ai avalé d’une traite.

Au bout de quelques jours, la configuration était prête et tous les serveurs migrés et configurés grâce à Puppet.

Tout a très bien fonctionné pendant un temps, jusqu’à ce qu’un dimanche soir, alors que je dinais tranquillement en famille, je reçoive un appel de mon associé totalement paniqué parce qu’un serveur venait de crasher et qu’il ne comprenait strictement rien à la manière dont il avait été configuré. C’est là que nous avons compris que nous avions un problème bien plus grave qu’un simple crash.

Si pour une raison ou une autre, des membres du projet sur lequel vous travaillez devaient quitter l’équipe, combien en faudrait-il pour que le projet échoue ?

C’est ce que l’on appelle le Bus Factor. Et le nôtre était de 1 car nous avions fait l’erreur de confondre indépendance et autonomie.

Alors, comment font mes clients et mon associé pour se passer de mes services quand je pars ?

C’est simple : je me suis rendu remplaçable ! 😀

Je sais que dit comme ça, cela peut choquer ou même faire peur, mais lorsqu’on prend le temps d’y réfléchir, ce n’est pas si stupide au fond.

La première crainte que l’on peut avoir, c’est de se dire que si l’on est remplaçable, alors on sera remplacé. Et effectivement, ça peut arriver ! Mais remplacer quelqu’un demande du temps et de l’énergie, et tous ceux d’entrevous qui ont déjà effectué une refonte graphique doivent connaître l’adage « c’était mieux avant ! » qui prouve bel et bien à quel point les gens sont attachés à ce qu’ils connaissent.

Rendez-vous remplaçables ! Car tant que vos collaborateurs apprécieront votre travail, ils reviendront vers vous ; parce qu’ils vous connaissent et qu’ils n’ont aucune raison d’aller voir ailleurs s’ils sont contents de vos services. En pratique, c’est assez simple à mettre en place et ça demande finalement assez peu d’efforts :

  1. Faites les choses simplement (KISS). Si vous êtes développeur, écrivez du code suffisamment clair, concis et logique pour que n’importe qui puisse le comprendre.
  2. Documentez ce que vous faites. Ça concerne évidemment le code, mais aussi tout ce qui tourne autour, à commencer par le projet lui-même : quel intérêt d’expliquer que la fonction open_the_door() ouvre la porte si l’on ne sait pas si le code qu’on est en train de lire pilote un frigo ou un coffre-fort ? Documentez tout ce dont votre code a besoin (variables d’environnement, extensions, serveur web, constantes, …) de sorte que même sans vous, tout puisse être réinstallé, corrigé ou adapté.
  3. Gardez une trace de tout ce que vous faites : modifications sur le code, modifications sur le serveur, échanges avec les clients, … et partagez-la avec votre équipe !
  4. Communiquez efficacement. Il y a une règle tacite chez nous qui est « tu n’as pas de raison de déranger quelqu’un si ce que tu fais n’a aucun impact sur son travail ». Si je suis le seul développeur sur un projet et que je repère un bug, je le corrige sans avertir qui que ce soit. Si nous sommes plusieurs, j’informe seulement ceux qui travaillent sur ce que je viens de modifier. Si c’est le client qui me rapporte le bug, je l’en informe aussi. Si c’est un autre collaborateur qui a été contacté par le client, j’informe les deux. Ça évite de spammer tout le monde, et comme toutes les actions sont archivées (cf. point précédent), si quelqu’un qui n’était pas concerné au moment de l’action l’est plus tard, il pourra retrouver tout ça dans l’historique.

Lorsque le Bus Factor passe au moins à 2, tout le reste devient vraiment plus simple ! Il ne reste plus qu’à préparer les sorties longtemps à l’avance et à prévoir un plan de secours : si je ne peux pas traverser les Pyrénées cet été ce n’est pas grave, je traverserai les Vosges en raquettes cet hiver 🙂

Mes amis (dont mon associé et quelques collègues développeurs) sont toujours là pour s’occuper des urgences en mon absence, mais dans l’ensemble, j’ai la chance d’avoir des clients plutôt compréhensifs et le cas ne s’est finalement présenté qu’une seule seule fois 🙂

Wow wow wow ! Je suis obligé de t’interrompre. On rend l’antenne à 10 heures et on n’aura pas le temps de terminer 😀

Chers lecteurs, si vous n’avez pas cliqué sur les liens placés par Poupi sur les mots « Bus Factor » et « KISS », il faudra apprendre à vivre avec 😉 

Question suivante !

Tu nous as bien fait marrer avec ton tweet sur WordPress. 🙂

Où situes-tu le leader des CMS dans ton métier de développeur ?

Je considère WordPress comme un outil parmi d’autres, mais force est de constater qu’une très grande partie des projets que je réalise l’utilisent.

C’est un outil qui plaît beaucoup, notamment pour sa zone d’administration qui est très simple à prendre en main. En mettant de côté les problématiques inhérentes au budget, je pense que c’est la principale raison pour laquelle mes clients me réclament majoritairement du WordPress : même sans y connaître quoi que ce soit, c’est très simple à gérer au quotidien.

Je crois que ce qu’ils aiment, c’est que WordPress leur permet de retrouver une autonomie dont ils ne disposaient pas sur d’autres CMS (voire même sur des outils développés sur-mesure).

Et quand as-tu découvert WordPress ?

C’était en 2009. J’étais à la fac et la formation que je suivais m’ennuyait beaucoup. Je me rendais aux cours comme un veau à l’abattoir, et rentrais chez moi le soir en courant, impatient de passer la nuit à me former sur tout ce que j’aurais aimé qu’on m’enseigne à l’université.

Une nuit, j’ai vu passer un tweet d’un petit gars (qui est depuis devenu mon associé) qui cherchait quelqu’un pour migrer sur WordPress le site Web de son association. Un truc un peu moche et développé un peu salement sur CodeIgniter.

Je n’avais jamais entendu parler de WordPress, mais ça me semblait amusant, et comme j’avais besoin de projets concrets pour mettre en pratique ce que j’avais appris durant mon temps libre, j’ai décidé d’accepter.

J’étais tellement content d’avoir trouvé un nouveau jouet sur lequel me faire les dents qu’après 48 heures sans dormir (dont au moins 10 à essayer de comprendre ce qu’était un hook 😀 ), le site était opérationnel… sur WordPress 2.8 !

Tu as déjà évoqué un peu cela sur Twitter, mais peux-tu nous expliquer ce que tu pourrais reprocher à WordPress ?

S’il y a une chose qui me hérisse particulièrement le poil, c’est bien la qualité du Core.

Qu’on se comprenne : j’adore WordPress ! C’est un projet fabuleux, et s’il a su se hisser en première place des CMS les plus utilisés, c’est parce qu’il dispose d’un nombre incroyable de qualités ainsi que d’une communauté réellement formidable. Et c’est justement parce que j’aime WordPress que je veux le voir évoluer dans le bon sens et ce qui va suivre risque d’être très critique.

Posons les choses : le code du Core est ignoble. Si l’un de mes développeurs juniors m’apportait du code de cette qualité, je le copierais sur clé USB pour avoir quelque chose à lui jeter au visage !

Pour une raison que j’ignore, il semble y avoir depuis plusieurs années une peur panique au sein des différentes équipes décisionnelles à l’idée de briser la rétro-compatibilité.

Il y a un exemple que j’aime bien parce qu’il me semble particulièrement symptomatique. C’est celui de myhacks.

“my-hacks.php” était un fichier qui à une époque très lointaine où les thèmes et les plugins n’existaient pas encore, permettait aux utilisateurs de bricoler le fonctionnement de WordPress à la manière d’un fichier functions.php. Avec l’apparition des thèmes et des plugins, myhacks a finalement été déprécié en 2005 dans la version 1.5 !

En novembre 2016, soit plus de 11 ans après, toutes les références à myhacks ont été supprimées du Core afin de s’en débarrasser définitivement… pendant deux jours ! Car oui, deux jours plus tard, le commit a été annulé pour la raison suivante :

Breaking sites isn’t something that should be encouraged. Even with 10 years of deprecation notices.

La rétrocompatibilité est une bonne chose, mais il faudra un jour ou l’autre s’en défaire et accepter de la briser partiellement pour aller de l’avant.

Il n’est pas normal qu’une recherche du mot-clé @deprecated dans les sources renvoie, aujourd’hui encore, des numéros de version datant de la branche 1 (2005). Il n’est pas non plus normal, en 2017, d’émuler des fonctions de PHP pour que WordPress puisse continuer d’être installé sur des versions de PHP bourrées de failles de sécurité puisqu’elles ne sont plus supportées depuis plus de 6 ans (5.2).

On ne pourra pas indéfiniment se traîner les casseroles du passé !

Ce que j’aimerais, c’est qu’on finisse un jour par prendre le temps de nettoyer le Core. Qu’on se dise « voilà, prenons le temps d’une version, virons le vieux code pourri et fermons les bugs qui traînent depuis dix ans ! ».

C’est beaucoup moins vendeur que l’API REST, le Customizer ou les emojis, mais je pense que les développeurs Core seraient heureux de repartir sur une base saine. Quant aux développeurs de plugins, ils apprécieraient beaucoup de ne plus perdre des heures à contourner des bugs connus, rapportés, et patchés (mais pas intégrés au core) depuis plus de dix ans 😉

Ce que tu nous expliques ici est super intéressant, en particulier en ce qui concerne les vieilles fonctions PHP 5.2 qui sont émulées dans le cœur de WordPress. J’ignorais tout ça et ton discours m’a complètement convaincu sur l’absolue nécessité d’effectuer un bon gros décrassage de tout ce code inutile.

À ta connaissance, les lead developers de WordPress ont-ils communiqué sur la volonté de nettoyer le cœur du CMS prochainement ? Ou est-ce qu’aux dernières nouvelles, ils continuaient de clamer, comme pour my-hacks.php, qu’il ne fallait pas casser les sites, même avec du code ayant plus de 10 ans ?

Pour le coup, je ne sais pas du tout. Si c’est le cas, j’ai dû passer à côté.

En faisant quelques recherches, je suis retombé sur le ticket #37827 qui m’a fait hurler de rire (mais ça doit être une sorte de mécanisme de défense pour ne pas fondre en larmes 😀 ) !

Explications : quelqu’un arrive avec une bonne idée et propose d’isoler certaines portions de code dans de nouveaux fichiers pour faire le ménage et préparer l’avenir. Alors les fichiers sont créés, le code est déplacé, et tout se passe bien jusqu’à ce qu’un Lead arrive et fasse remarquer que si un développeur de plugin a codé son truc n’importe comment, les changements apportés peuvent casser des choses. Alors on fait marche-arrière, on restaure des fichiers qui ne servent plus à rien, et on leur ajoute un avertissement indiquant que leur utilisation est dépréciée (un peu comme /wp-includes/registration-functions.php qui traîne là depuis 10 ans).

Je comprends l’idée sous-jacente, et je n’y suis pas totalement opposé. Mais quand 60% des sites WordPress continuent de tourner sur des versions de PHP obsolètes, on ne peut que constater que la stratégie qui consiste à supplier avec insistance les utilisateurs d’upgrader ne fonctionne pas.

Je pense que le rôle de l’équipe WordPress est de faire évoluer le CMS. Pas de réparer les erreurs des hébergeurs qui ne sont pas capables de faire un apt-get upgrade en 6 ans. Et pas non plus de réparer les erreurs des développeurs de plugins qui ont trop la flemme pour mettre à jour leur code une fois en 10 ans. Je pense que quelque part entre « la rétrocompatibilité à tout prix ! » et « fonçons tête baissée ! », il doit y avoir un juste milieu qui n’a malheureusement pas encore été trouvé.

Présenté comme ça, c’est vraiment du délire !

En fin d’article, fais-moi penser à te remercier pour le partage de connaissance (de ouf) que tu fais ici.

Pour revenir à une note plus positive, peux-tu nous raconter une réalisation WordPress qui t’a laissé un bon souvenir ?

Je dirais sans aucun doute que mon plus beau projet est aussi celui de mon plus ancien client.

Il s’agit d’une radio parisienne qui m’a contacté en 2011 afin de refaire leur site qui, à l’époque, tournait sur une solution sur-mesure développée en Ruby. Le code était très compliqué, la gestion au quotidien également, et après avoir découvert l’existence de WordPress, ils tenaient absolument à ce que leur nouveau site Web l’utilise.

À l’époque, il devait s’agir de la version 3.2 de WordPress (pas sûr).

La deadline était très courte, tout était à refaire et WordPress n’était pas du tout adapté à ce type de projet. Mais je l’ai pris comme un défi, et après avoir vécu les trois mois les plus intenses de toute ma vie, le projet a finalement pu être mis en production une semaine avant la deadline, à 3 heures du matin le jour de noël !

On m’a demandé l’an dernier de développer une nouvelle version de ce site, et ce que j’ai trouvé particulièrement intéressant, c’est de constater à quel point WordPress avait pu évoluer en seulement quelques années. Alors que sur la première version, le CMS ne me servait que « d’interface d’administration par dessus du code maison », la nouvelle version avait pu, elle, être 100% intégrée à WordPress grâce à toutes les nouveautés qui étaient apparues entre temps (Custom Post Types, Custom Taxonomies, etc.).

Je comprends maintenant pourquoi tu connais si bien le cœur du CMS. Ce travail de développement intensif a du être très formateur !

Ce site de radio parisienne était développé en version 3.2 et tu as ensuite fait une refonte complète avec un WordPress plus moderne. Mais, est-ce qu’on doit comprendre que ce site n’a pas mis à jour le cœur du CMS pendant plusieurs années ? Comment cela se passait-il avec cet ancien développement ? Avez-vous rencontré des problèmes particuliers pour maintenir cela en production, par exemple, ajouter des correctifs pour suivre les mises à jour de PHP ou à l’inverse, conserver une ancienne version du langage, genre PHP 4 ?

Je te rassure, je suis courageux mais pas téméraire ! Toutes les upgrades de sécurité ont été faites 😀

Pour ce qui est de la partie serveur, tout s’est étrangement bien passé ! Comme la version de PHP présente dans les dépôts Debian me semblait déjà un peu dépassée à l’époque, le serveur a vécu la plus grande partie de sa vie sur la branche active (grâce à Dotdeb). Je ne sais pas si des efforts ont dû être faits du côté de WordPress en ce qui concerne la compatibilité ascendante (PHP7 a demandé quelques efforts, mais je ne crois pas que les versions 5.3 à 5.6 aient posé beaucoup de problèmes), mais je n’ai en tout cas rien senti passer de négatif de ce côté.

Du côté de WordPress, la montée en version a été un tout petit peu plus délicate…

Jusqu’à la 3.9, tout s’est très bien passé : à part quelques petits bugs d’affichage dans le Dashboard et une poignée d’avertissements lancés par mes plugins (corrigés au fil des versions), nous n’avons pas eu d’autres casses à signaler. Et puis, la 4.0 est arrivée ! Version majeure : beaucoup de stress. Alors, comme je manquais de temps, j’ai voulu faire les choses bien et attendre quelques jours pour pouvoir tenter l’upgrade dans mon coin avant de l’envoyer en production…

Perdu !

En me réveillant un matin, je découvre une dizaine d’appels en absence sur mon téléphone. Panique totale : la radio vient de lancer sa campagne annuelle de dons, mais la moitié des fonctionnalités du site sont HS ! Il n’est d’ailleurs même plus possible d’avertir les auditeurs puisque les éditeurs de texte présents dans le Dashboard ne fonctionnent plus non plus… Grosse angoisse.

Tout le monde est stressé, et même si je suis seul et à moitié endormi devant mon ordinateur, j’arrive à sentir le regard pesant de toute l’équipe qui prie en attendant que je trouve l’origine de la panne. Rien d’intéressant dans les logs, le serveur semble OK. Je pense immédiatement à un piratage, et coupe le réseau pour éviter une potentielle fuite de données. Je lance une comparaison entre les fichiers du serveur et ceux du backup de la veille : miracle, j’ai trouvé !

Intriguée par un message bizarre dans le Dashboard, l’une des administratrices du site aurait « sans faire exprès » lancé la mise à jour de WordPress (avant de se faire toute petite pour éviter d’être grillée et de se faire engueuler 😀 ). La mise à jour avait révélé un petit bug dans mon plugin principal qui avait tenté d’afficher du texte à l’activation et s’était fait désactiver par WordPress, désactivant ainsi en cascade tous les autres plugins dépendants de ce dernier (it’s not a bug, it’s a feature!). Plus de peur que de mal !

L’upgrade en 4.1 n’a pas posé de soucis particuliers, mais le term splitting de la 4.2 n’a pas très bien fonctionné chez nous et j’ai été obligé d’aller dépatouiller tout ça manuellement dans la base de données. Enfin, nous avons migré jusqu’à la 4.3 sur laquelle la première version du site a fini tranquillement ses jours en recevant simplement les patchs de sécurité.

Si je devais résumer, je dirais que dans l’ensemble, tout s’est relativement bien passé. Nous avons eu pas mal de petits problèmes à résoudre au fil des versions, et le code original a pris un sacré coup de vieux (j’en reviens toujours pas d’avoir écrit des trucs aussi moches !), mais ça aurait pu tellement plus mal tourner que je m’estime chanceux 🙂

Je ne sais pas si ça vient de mon code ou WordPress, mais la plupart des patchs que j’ai été obligé de développer en cinq ans l’ont été sur la partie JavaScript, qui ne représentait pourtant qu’une partie infime du projet.

Les librairies JavaScript type jQuery sont-elles aussi subtiles et délicates que celles de WordPress lorsqu’il s’agit de réformer leur code !? 🙂

Je suis dégoûté de lire ton anecdote sur la secrétaire qui a pété le WordPress en lançant agressivement une mise à jour majeure via le dashboard. 😀 

Ça m’est arrivé quelques fois avec mes clients !

Cela m’a même conduit à atteindre le point de non retour avec l’un d’eux, parce qu’il ne voulait pas capter que les mises à jour ne peuvent pas toujours se faire à l’arrache. Même si souvent (love WP) cela se passe bien.

Le mec (pas du métier) faisait ses petites maintenances tranquilles, clairement dans mon dos :

  • sans faire de backup,
  • update des plugins à l’aveugle, sur le site en prod.,
  • sans vérifier que les dernières versions de ses extensions étaient bien compatibles avec la dernière version de WordPress
  • et bien sûr, sans effectuer les tests d’usage des différentes zones du site, à postériori, histoire de s’assurer qu’on n’a rien cassé et pour éviter de se rendre compte qu’une section du site est en panne depuis +3 mois.

Toi, en tant que gars du métier, en plus de faire valider au client toutes les interventions que tu termines, tu vas prendre toutes les précautions citées ci-dessus. Justement parce que tu connais ton job, et les risques potentiels.

Le client qui ne connait que son tableau de bord WordPress, il y va gaiment sans s’inquiéter de casser quoi que ce soit, parce que « la dernière fois, ça a fonctionné du premier coup ». Ni vu ni connu, j’t’embrouille.

Au début, c’est mignon de voir le client te promettre qu’il ne recommencera plus (sic) après t’avoir appelé en urgence pour réparer 🙂 , une fois ou deux.

Par contre, lorsqu’on t’a fait le coup 10 fois en 3 ans, tu commences à te demander si on t’écoute !? Quel crédit on donne à tes précos ?

Et lorsqu’on finit par carrément t’accuser d’être responsable de fonctionnalités cassées du jour au lendemain, c’est le coup de grâce ! Comme si on avait que ça à faire, venir détériorer une installation de WordPress qu’on a peiné à mettre en place. Le tout, en douce, alors qu’on ne t’a plus commandé d’interventions depuis des mois.

« Tu as fait les mises à jour de tes plugins n’importe comment et sans m’avertir en plus. C’est toi qui as pété ton site mec ! Pas moi. ».

Tout le monde dira qu’il ne faut pas donner d’accès super-admin au client, mais lorsqu’il les demande, t’es bien obligé. Non ?

Et pourtant, ce n’est pas faute de faire de la prévention. Cependant, il faut bien avouer que le petit encadré qui t’invite à mettre à jour WP est assez sexy. D’ailleurs, souvent, les mises à jour se passent très/trop bien.

Allez, je la ferme. On va essayer de terminer ton interview 😉

Dis-nous. Si tu n’avais qu’un conseil à donner aux débutants WordPress qui souhaitent réellement se former efficacement, ça serait lequel ?

J’aimerais donner le même conseil que l’on m’a donné il y a plusieurs années : lisez les sources, jouez et expérimentez !

Le Codex est un bon point d’entrée et un très bon aide-mémoire, mais rien ne vaudra jamais un coup d’œil sur les sources ! Si vous en avez l’occasion, n’hésitez pas à supprimer le Codex de vos marque-pages et à le remplacer par la Code Reference qui offre l’avantage de vous montrer les sources.

Abonnez-vous au flux RSS du blog des développeurs pour suivre l’évolution de WordPress, et jetez régulièrement un œil à l’historique des modifications pour en découvrir davantage sur le fonctionnement interne du CMS. C’est très formateur 😉

Très bon conseil. Je ne cache pas le fait d’être toujours en apprentissage en ce qui concerne le développement basé sur WordPress, et j’ai beaucoup moins de difficulté à comprendre une fonction WP en lisant le code source de developer.wordpress.org plutôt que la traduction humaine du codex.wordpress.org.

Cette interview touche à sa fin. Où les lecteurs peuvent-ils te suivre par la suite ?

Je vous invite à me retrouver sur Twitter, mon blog personnel (où je publie au rythme incroyable d’un billet tous les 15 ans) ou encore dans la section commentaires présente sous ce billet 😉

Je viens d’ouvrir ton lien et de jeter un œil au développement de ton blog. Il est vraiment propre. Je me suis permis de cliquer “fork” sur Github pour jouer un peu avec ça plus tard, si je trouve le temps.

Tu sais quoi, « WordPress » c’est génial, mais à force de l’utiliser, le développement « from scratch » (celui qui nous faisait rêver lorsqu’on était ados), ben ça manque un peu… 🙂 même si c’est fucking long à réaliser tout seul !

Un dernier mot ?

Encore merci Mr WordPress pour ton invitation et à très bientôt !

Merci à toi pour ce retour d’expérience exceptionnel que je ne manquerai pas de partager autour de moi pour qu’il soit lu par le plus grand nombre.

J’encourage d’ailleurs chaque lecteur à te poser leurs questions ci-dessous comme tu nous l’as gentiment proposé en début d’interview.

Cher lecteur de Mister WP (oui toi, là, derrière l’écran),

Blog WordPress Dofollow 2017Si vous êtes arrivé jusque là, laissez un mot en commentaires ci-dessous.

Je vois mes stats. Vous êtes nombreux à lire les interviews d’experts, mais vous êtes assez timides en commentaires. Comme vous l’avez lu, Poupi a vraiment pris le temps de nous faire partager un retour d’expérience rare !

Ça serait cool de lui dire bonjour. 🙂

Si vous avez des questions, c’est encore mieux.

Merci, vous êtes choux 😉

Vos commentaires sont très appréciés ci-dessous !

Veuillez cependant respecter les bonnes pratiques de commentaires sur les blogs, sinon votre message s'autodétruira après 10 secondes entre mes mains.

  • Vous devez avoir lu l'article, sinon je m'en rendrais compte, et boom !
  • Vous ne pouvez renseigner aucun mot clé SEO dans le champ "nom" (pseudo, nom de société, pas de souci).
  • Vous pouvez renseigner votre "Site Web", vous aurez un lien dofollow, je suis gentil. Par contre, gardez à l'esprit qu'il s'agit d'un lien qui sert à vous identifier en tant qu'individu (site de votre société, votre blog perso, votre chef d'œuvre WordPress...). Je refuse donc : les sites de vos clients, les pages internes que vous peinez à booster, les MFAs sans intérêt, les serruriers, rachats de crédits et autres saloperies.
  • Vous devez avoir un avis sur le sujet abordé (même contradictoire) ou au moins poser une question pertinente. Si vous souhaitez juste me montrer votre gratitude éternelle, faites-le avec un retweet ou un partage Facebook. Donc pas de "merci très bel article" qui n'apporte rien.

À vos plumes !