To Code or Not to Code ? Serait-ce la question ?

Seul devant mon terminal, trois assistants à portée de prompt. L’un génère, l’autre corrige, le troisième surveille. Moi ? Je coordonne. En quatre heures, un plugin WordPress sur mesure. Magie ? Non. Méthode. Alors, coder… est-ce encore la vraie question ?

Cet article a été mis à jour le 26 août 2025 ; il prend 8 minutes à lire et comporte 1960 mots.

Chapitre 1 : L’énigme du formulaire fantôme

L’i­dée était simple, mais pas banale : insé­rer auto­ma­ti­que­ment un for­mu­laire d’ins­crip­tion dans un article Word­Press, mais pas n’im­porte où – plus ou moins à 60 % de la lon­gueur du conte­nu. Au cœur même de l’ar­ticle, pour cap­ter l’at­ten­tion du lec­teur au bon moment, quand il est suf­fi­sam­ment accro­ché pour envi­sa­ger de s’a­bon­ner, mais pas encore arri­vé à la fin où son atten­tion se disperse.

Un pla­ce­ment stra­té­gique, chi­rur­gi­cal presque. Ni trop tôt (le lec­teur n’a pas encore accro­ché), ni trop tard (il a déjà quit­té la page ou passe à une autre). Cette zone mys­té­rieuse des 60%, ce sweet spot que tout mar­ke­teur rêve d’atteindre.

J’a­vais pas­sé une bonne heure à fouiller les réper­toires de plu­gins Word­Press. Les solu­tions étaient soit trop géné­riques (un short­code à pla­cer manuel­le­ment – quelle cor­vée !), soit trop rigides (popup agres­sive au bout de 30 secondes), soit com­plè­te­ment à côté de la plaque (déclen­che­ment au scroll, mais impos­sible de défi­nir une posi­tion pré­cise dans le contenu).

Bon, soyons hon­nêtes : il existe bien Thrive Leads qui fait plus ou moins ça. Mais à 300€ par an pour Thrive Suite, dont je n’u­ti­li­se­rai qu’un seul élé­ment… c’est un peu uti­li­ser un 38 tonnes pour démé­na­ger un stu­dio. Une usine à gaz alors que je n’ai besoin que d’un rouage, et encore, il n’est pas exac­te­ment comme je le veux.

Bref, rien ne cor­res­pon­dait pré­ci­sé­ment à mon besoin. Et puis, il y avait ces petits détails qui font la dif­fé­rence : l’en­voi en AJAX vers Mail­jet (parce que per­sonne n’a envie d’at­tendre qu’une page se recharge pour savoir si son email a été pris en compte), et sur­tout, le mas­quage défi­ni­tif post-sou­mis­sion via local­Sto­rage. Une fois ins­crit, plus jamais embê­té par ce for­mu­laire sur ce navi­ga­teur. Élé­gant et respectueux.

Ce posi­tion­ne­ment pré­cis du for­mu­laire, cou­plé à un envoi AJAX fluide et à une mémoire locale intel­li­gente, for­mait le cahier des charges de mon micro-plu­gin. Un puzzle tech­nique pas si simple, finalement.

Chapitre 2 : Constituer l’équipe (et distribuer les rôles)

Plu­tôt que de me lan­cer seul dans le code, comme un cow-boy soli­taire face à son édi­teur, j’ai déci­dé de m’ap­puyer sur une équipe un peu par­ti­cu­lière. Pas de réunions inter­mi­nables, pas de mails à ral­longe, juste des algo­rithmes dis­ci­pli­nés et complémentaires.

Pre­mière escale : chatGPT, mon conseiller stra­té­gique. Avec lui, j’af­fine le besoin, je for­mule un prompt clair, pré­cis et effi­cace. Parce qu’un bon départ, ça change tout, et qu’un prompt mal fice­lé, c’est la garan­tie d’un code ban­cal. On passe vingt minutes à décou­per le pro­blème, iden­ti­fier les contraintes tech­niques, pré­voir les cas limites. chatGPT pose des ques­tions per­ti­nentes : « Et si l’ar­ticle fait moins de 300 mots ? Et si Mail­jet est en panne ? Et si l’u­ti­li­sa­teur a désac­ti­vé localStorage ? »

Puis Gemi­ni CLI entre en scène, maître incon­tes­té du code. Contrai­re­ment à ce qu’on pour­rait croire, ce n’est pas le sta­giaire de l’é­quipe. Au contraire : véloce, effi­cace, et sur­tout éton­nam­ment juste dans ses choix tech­niques. Il prend en charge la géné­ra­tion ini­tiale du plu­gin avec une pré­ci­sion qui m’a sur­pris. En une quin­zaine de minutes d’in­te­rac­tion active (sur les 2h35 de temps total qu’il m’au­ra fal­lu pour bou­cler le pro­jet en inter­agis­sant avec lui), il me pond une pre­mière ver­sion non seule­ment fonc­tion­nelle, mais car­ré­ment bien foutue.

50 appels d’A­PI, 82% de taux de suc­cès, et sur­tout : 100% d’ac­cord de ma part sur les solu­tions pro­po­sées. Ces chiffres parlent d’eux-mêmes. La logique est là, la struc­ture aus­si, et même la sécu­ri­té de base est res­pec­tée. Du code qui res­pire et qui fonc­tionne du pre­mier coup.

Enfin, GitHub Copi­lot entre en jeu, mais plus pour du fine-tuning que pour des cor­rec­tions majeures. Son rôle ? Ajou­ter les petits plus qui font la dif­fé­rence : un select pour choi­sir la mai­ling list (j’en gère trois dif­fé­rentes selon mes pro­jets), quelques opti­mi­sa­tions sur les bonnes pra­tiques Word­Press, des conven­tions de nom­mage plus strictes. Il peau­fine plus qu’il ne cor­rige, trans­for­mant un bon code en code irréprochable.

Mon rôle dans tout ça ? Chef de pro­jet, archi­tecte, tes­teur et garde-fou. Je défi­nis le besoin, j’ar­bitre les choix tech­niques, je super­vise les tests et je valide la qua­li­té finale. J’ai aus­si pris en charge le conseil et la recherche de docu­men­ta­tion tech­nique pour mes assis­tants – par exemple, com­ment gérer l’A­PI Mail­jet sans Com­po­ser sur ser­veur mini­ma­liste (dis­tro nue), un point tech­nique non tri­vial qui deman­dait de fouiller la doc et com­prendre les sub­ti­li­tés de leur API REST.

Cette approche en mode « équipe aug­men­tée » a per­mis de réduire dras­ti­que­ment le temps de déve­lop­pe­ment tout en garan­tis­sant un résul­tat pro­fes­sion­nel. Pas de syn­drome de la page blanche, pas de blo­cage tech­nique qui traîne des heures. Juste un flux de tra­vail fluide et des com­pé­tences qui se complètent.

Chapitre 3 : Premiers tests et premières satisfactions

À 16h15, pre­mière ver­sion opé­ra­tion­nelle. Le plu­gin s’ins­talle, s’ac­tive, et… fonc­tionne par­fai­te­ment du pre­mier coup. Le for­mu­laire appa­raît exac­te­ment où il faut, l’A­JAX répond sans bron­cher, l’email arrive chez Mail­jet dans la seconde qui suit.

Un moment de sur­prise, presque de décep­tion : j’é­tais pré­pa­ré à débo­guer pen­dant des heures, armé de ma console JavaS­cript et de mes break­points, et là, rien. Gemi­ni CLI avait livré du code propre et fonc­tion­nel dès le pre­mier jet. Pas de « Uncaught TypeEr­ror », pas de « 403 For­bid­den », pas de mys­té­rieux bugs à tra­quer dans les méandres du code.

La seule inter­ven­tion néces­saire : ajou­ter quelques fonc­tion­na­li­tés sup­plé­men­taires que j’a­vais oubliées dans mon brief ini­tial : une page d’ad­min pour ne pas avoir à coder les infos sen­sibles en dur dans le plu­gin, quelques options comme le choix de mettre le code en fin d’ar­ticle s’il fait moins de 300 mots… ensuite GitHub Copi­lot s’est char­gé d’a­jou­ter le select pour choi­sir entre dif­fé­rentes mai­ling lists, et de quelques amé­lio­ra­tions UX mineures. Le local­Sto­rage, cette mémoire dis­crète qui se sou­vient qu’un uti­li­sa­teur s’est déjà ins­crit pour ne plus jamais l’embêter sur ce device, fonc­tionne comme une hor­loge suisse.

Chapitre 4 : La chasse aux warnings (ou comment rendre un code propre)

17h30, le plu­gin fonc­tionne. Mais fonc­tionne-t-il bien ? Une fois le pre­mier jet obte­nu, il ne s’a­gis­sait pas de se conten­ter d’un simple « ça marche ». Le code géné­ré par Gemi­ni CLI, même amé­lio­ré par Copi­lot, méri­tait une passe cri­tique approfondie.

J’ac­tive l’ou­til Plu­gin Check (PCP), cette sen­ti­nelle impla­cable qui scrute chaque ligne de code à la recherche d’a­no­ma­lies. Résul­tat : une tren­taine d’a­lertes qui s’af­fichent comme autant de reproches. La plu­part mineures, certes, mais cha­cune méri­tait mon atten­tion. Prin­ci­pa­le­ment des variables non échap­pées d’ailleurs.

Point par point, GitHub Copi­lot opti­mise le code comme un orfèvre polit un bijou : sécu­ri­té ren­for­cée (sani­ti­sa­tion des don­nées, vali­da­tion des nonces), res­pect des stan­dards Word­Press (hooks appro­priés, conven­tions de nom­mage), inter­na­tio­na­li­sa­tion (parce qu’un plu­gin propre, c’est un plu­gin tra­dui­sible), meilleure orga­ni­sa­tion des fichiers (sépa­ra­tion claire entre PHP, CSS et JavaScript).

Le tout sans déna­tu­rer le code ini­tial, juste en le ren­dant plus robuste, plus main­te­nable, et prêt à être sou­mis au dépôt offi­ciel si l’en­vie m’en pre­nait (elle m’a pris très vite).

Cette phase de polis­sage, c’est celle qui sépare un bidouillage d’un plu­gin pro. Pas for­cé­ment visible pour l’u­ti­li­sa­teur final, mais essen­tiel pour la main­te­nance à long terme.

Chapitre 5 : Tests en conditions réelles (et petites sueurs froides)

18h45, code fina­li­sé. Res­tait la vali­da­tion ter­rain. Pour tes­ter le fonc­tion­ne­ment, j’ai déployé le plu­gin sur trois envi­ron­ne­ments dif­fé­rents : d’a­bord mon site de test (une ins­tal­la­tion Word­Press vanille, par­faite pour les pre­miers essais), puis mes deux blogs en pro­duc­tion, avec leurs thèmes per­son­na­li­sés, leurs autres plu­gins, leurs particularités.

Pre­mier site : tout fonc­tionne par­fai­te­ment. Le for­mu­laire s’in­sère exac­te­ment où il faut, l’A­JAX répond en moins d’une seconde, l’email arrive dans ma liste Mail­jet. Une petite satis­fac­tion, mais la méfiance reste de mise.

Deuxième et troi­sième sites : catas­trophe. Le for­mu­laire appa­raît bien, mais l’in­ter­face d’ad­mi­nis­tra­tion ren­voie une erreur 500. Puis une autre. Mais le for­mu­laire s’af­fi­chait cor­rec­te­ment, et le nou­vel abon­né appa­rais­sait dans ma console Mailjet.

Puis l’in­ter­face d’ad­mi­nis­tra­tion est reve­nue, mais là les enre­gis­tre­ments ne pas­saient plus…

À 19h30, après quelques cor­rec­tions, le plu­gin tour­nait par­fai­te­ment sur les trois sites. Test ultime : dés­ins­tal­la­tion et réins­tal­la­tion com­plète. Aucune trace, aucun rési­du. Propre. Prêt pour la prod. Il est d’ailleurs sur ce site, vous l’a­vez cer­tai­ne­ment vu, l’en­cart « Abon­nez vous »…

Épilogue : Quand la méthode devient plus importante que l’outil

Ce plu­gin n’est qu’un pré­texte. Un pré­texte à expé­ri­men­ter, à com­prendre, à docu­men­ter cette nou­velle façon de créer. Ce que je retiens de cette expé­rience de 3h40, c’est l’ef­fi­ca­ci­té redou­table d’un mode de pro­duc­tion hybride : poser clai­re­ment un besoin, défi­nir des contraintes, puis orches­trer les bons outils – Gemi­ni pour amor­cer, Copi­lot pour affi­ner – comme on consti­tue­rait une petite équipe projet.

Avec un cadrage clair en amont (mer­ci chatGPT) et une vision pro­duit assu­mée, on obtient un résul­tat propre, fonc­tion­nel, et suf­fi­sam­ment robuste pour un usage en pro­duc­tion… en quelques heures au lieu de quelques jours.

Le temps gagné ne se mesure pas uni­que­ment en heures de déve­lop­pe­ment évi­tées, mais en auto­no­mie tech­nique acquise, en réduc­tion de la charge men­tale, et sur­tout en capa­ci­tés réuti­li­sables. Demain, si j’ai besoin d’un autre plu­gin, ou d’une appli légère, je sais exac­te­ment com­ment pro­cé­der, quels outils mobi­li­ser, dans quel ordre, quels écueils éviter.

Ce n’est pas un simple gain de pro­duc­ti­vi­té : c’est une méthode de tra­vail qui s’ins­talle, une nou­velle façon d’a­bor­der le déve­lop­pe­ment. Pas pour rem­pla­cer l’hu­main, mais pour le libé­rer des tâches répé­ti­tives et lui per­mettre de se concen­trer sur l’es­sen­tiel : l’i­dée, la stra­té­gie, la vision d’ensemble.

Et ce plu­gin Word­Press ? Il tourne sur ce blog, insé­rant dis­crè­te­ment ses for­mu­laires à 60% des articles, col­lec­tant des emails avec la régu­la­ri­té d’un métro­nome. Mis­sion accomplie.

Vous vou­lez l’o­ri­gi­nal, pour l’a­dap­ter, le for­ker ou tout sim­ple­ment y jeter un œil ? Il est sur Github, il a son dépôt bien à lui : News­let­ter Optin Block.

Pour une pré­sen­ta­tion plus détaillée du plu­gin et pour son ins­tal­la­tion, j’ai rédi­gé un article sur mon autre blog, Tout sur Word­Press : News­let­ter Optin Block – pour opti­mi­ser l’ins­crip­tion depuis vos posts.

J’ai éga­le­ment sou­mis le plu­gin à Deep­Wi­ki qui l’a ana­ly­sé : https://​deep​wi​ki​.com/​p​c​e​s​c​a​t​o​/​n​e​w​s​l​e​t​t​e​r​-​o​p​t​i​n​-​b​l​o​ck/. Avec un point de vue tech­nique, l’or­ga­ni­sa­tion, les dépen­dances, la dis­tri­bu­tion… pour les curieux – et les afficionados.

Annexes

/form-injector-cf7/    
│     
├── form-injector-cf7.php # Fichier principal du plugin   
├── admin/    
│ └── settings-page.php # Interface admin (options API)   
├── includes/     
│ ├── injector.php # Logique d’injection dans the_content     
│ └── ajax-handler.js # Gestion localStorage + écoute CF7     
└── assets/   
 └── form-injector.js # JS frontend (insertion visible, classes)

Pas­cal CESCATO

Je ne me contente pas de refor­mu­ler des com­mu­ni­qués ou de dérou­ler des specs. Je teste, je creuse, je démonte quand il faut – parce qu’un sujet mal com­pris est un sujet mal écrit. J’écris avec les mains dans le cam­bouis, sans sim­pli­fier à outrance ni recra­cher du mar­ke­ting. Mon truc, c’est de rendre clair sans tra­hir, lisible sans lis­ser. Et non, je ne “fais pas du conte­nu”. Pas pour faire du conte­nu, en tout cas.