Comment j’utilise l’IA pour WordPress (sans lui faire confiance)

Fin avril, j’ai cassé Google.

Naaaaan, je déconne, pas tout Google. Juste la partie qui crawle wpformation.com. Pendant quatre jours, le robot du moteur de recherche s’est cogné contre mon sitemap.xml renvoyé en HTTP 404 par mon propre serveur. Le coupable : un bloc de sécurité que j’avais demandé à Claude Code d’ajouter dans le middleware Next.js, sans liste blanche sur les routes critiques. Un envoi en production trop confiant. Un déploiement trop rapide. Quatre jours d’indexation cassée.

C’est typiquement le genre d’incident qui produit deux réactions opposées. La première : "Tu vois bien, l’IA c’est de la merde, mieux vaut tout faire à la main." La seconde : "Pas de bol, la prochaine fois Claude fera mieux." Les deux sont à côté de la plaque.

Le vrai enseignement, ce n’est ni "abandonne l’IA" ni "fais-lui confiance". C’est : tu peux travailler avec l’IA tous les jours, à condition de ne jamais la laisser conduire seule. Six mois que j’utilise Claude tous les jours : pour le frontend Next.js de wpformation.com, pour préparer des articles, pour auditer mes mu-plugins WordPress, pour répondre à des prospects. Et 6 mois que j’applique 10 règles éthiques que je ne négocie jamais.

Ce n’est pas un tutoriel. Je n’expliquerai pas comment installer Claude Code et faire tourner mon pipeline éditorial, ni comment connecter Claude à WordPress via un serveur MCP, ni quels sont les meilleurs plugins IA WordPress en 2026. Ces articles existent déjà sur le site, je te renvoie dessus.

Ce qui suit, c’est ma posture éthique. Mes garde-fous. Mes règles de technicien WordPress qui pratique l’IA chaque jour et ne lâche jamais le volant… Dix règles que j’ai validées sur le terrain, à coup de bourdes évitées et d’incidents réparés.

Deux camps se trompent. Moi, je ne suis dans aucun.

Sur l’intelligence artificielle, deux postures dominent le débat français en ce moment. La première : ceux qui croient qu’elle va tout faire. Ils délèguent le code, l’écriture, la stratégie, la relation client. Ils signent ce qu’ils n’ont pas relu. La seconde : ceux qui la rejettent en bloc. Ils refusent même d’essayer. Ils confondent vigilance et hostilité.

Les deux se trompent…

L’IA est un outil. Pas un employé, pas un dieu, pas un imposteur. Un outil. Que tu utilises avec discipline ou pas du tout. Ma position : technicien WordPress qui pratique l’IA chaque jour. Pas une ligne ne part en production sans que je l’aie lue. Pas un chiffre cité sans que j’aie ouvert la source. Pas une recommandation suivie sans qu’elle ait passé le test du "tu es sûr ? Double-check tes affirmations !".

Voici les dix règles que j’applique au quotidien. Aucune n’est négociable.

Règle 1 : Je ne valide jamais ce que je n’ai pas relu

L’IA propose. Moi je décide. Chaque ligne de code qui part en production sur Vercel, chaque phrase publiée sur le blog, chaque chiffre cité dans un devis OPCO passe par mes yeux avant validation. Le jugement éditorial reste humain. Toujours.

Un exemple récent. Il y a deux jours, un agent de reprise hebdomadaire (un script Claude qui résume mes chantiers en cours) m’a sorti une recommandation propre, bien formatée, avec ce slug d’URL : /wordpress-claude-ia/. Il préconisait de poser une balise canonical dessus. Le hic : ce slug n’existe pas. Le vrai hub de ma catégorie s’appelle /wordpress-ia/. L’agent avait halluciné l’URL avec un détail crédible en plus. Si j’avais signé sans vérifier, j’aurais posé un canonical entre deux pages qui ne se voient pas, cassé le référencement d’une catégorie qui marche bien, et passé une journée à comprendre pourquoi.

Anecdote méta en écrivant cet article même : Lors de sa mission de maillage interne, Claude m’a sorti quatre URLs hallucinées vers d’autres articles du site. Slugs crédibles, formatage propre, ancres descriptives. Mais 404 garanties. Sans relecture approfondie, j’aurais publié un article sur les hallucinations IA contenant des liens hallucinés. Elle est bien bonne, celle-là.

J’ai pris l’habitude de tout traiter comme une hypothèse. Voici les 3 vérifications que je fais systématiquement avant de signer une recommandation IA :

1. Si Claude cite un slug ou une URL, je la teste à la main pour confirmer qu’elle existe. Un HTTP 200 ne suffit pas, attention au soft-404 (page qui répond "OK" mais qui affiche en réalité un message "Page introuvable").
2. Si Claude cite un fichier, je l’ouvre dans mon éditeur pour vérifier le contenu réel. Pas le résumé qu’il m’en fait.
3. Si Claude cite une fonction ou une commande, je fais une recherche dans le dépôt de code pour confirmer qu’elle est bien là où il le dit.

Trois secondes de vérification, parfois trente. Mais zéro publication sans relecture humaine.

L’IA propose. Mais c’est toujours moi qui valide.

Fabrice Ducarme

Règle 2 : Je double-check, systématiquement

Une affirmation de Claude, c’est une hypothèse. Pas une conclusion. Ce que je vérifie systématiquement avant d’agir sur une réponse IA :

• Les sources qu’il me cite : je les ouvre dans un onglet, je lis ce qu’elles disent vraiment.
• Les chiffres : je les recoupe avec une source primaire (le site officiel, l’API directe, le tableau de bord de l’outil).
• Les URLs : je clique. Une URL inventée n’attend que toi pour produire une 404.
• Les diagnostics "ça ne marche pas" : je les remets en cause. Un message d’erreur trop propre cache souvent un autre problème.

Et quand l’IA me dit que quelque chose ne marche pas ? Je vérifie deux fois avant de la croire. Particulièrement quand le diagnostic est trop propre pour être honnête.

Cas vécu en avril dernier. Mon point d’entrée de suivi LLMs (l’API qui me dit combien de fois ChatGPT, Perplexity et les autres viennent crawler wpformation.com) renvoyait HTTP 401. Pendant 17 jours, les audits successifs ont noté "401, secret périmé, on passe" sans aller voir plus loin. Conclusion répétée : "0 visite sur 30 jours". Faux. Le secret avait simplement été changé lors d’un incident Vercel le 20 avril. Le vrai secret se trouvait dans le fichier wp-config.php de mon serveur tout ce temps. J’ai récupéré le fichier en FTP, mis à jour mes identifiants en local, et retrouvé 17 jours de données analytiques que j’avais cru perdues.

Morale : un HTTP 401 n’est pas une fin de discussion. C’est le début d’une investigation. Les hallucinations existent. Les URLs inventées aussi. Les diagnostics paresseux qui se recopient d’audit en audit, encore plus…

Règle 3 : Je challenge l’IA. Je ne la flatte pas.

Un LLM est entraîné à plaire. Son penchant naturel, c’est l’acquiescement. Si tu lui dis "je pense que cette approche est meilleure", il va trouver trois raisons de te donner raison. C’est exactement ce dont tu n’as pas besoin quand tu travailles sur un site de production.

Voici les 3 formulations exactes que je tape dans Claude Code, mot pour mot, plusieurs fois par jour :

1. "As-tu vérifié tes sources, redonne les moi." Pour forcer la traçabilité de chaque affirmation. Si la réponse est vague, je creuse.
2. "Challenge-toi sur cette proposition." Pour activer son auto-critique. Un LLM contredit volontiers ses propres conclusions quand on l’invite explicitement à le faire.
3. "Je ne suis pas convaincu par ta proposition. Revérifie." Pour casser l’effet d’autorité de la première réponse. Souvent, la seconde réponse est bien meilleure.

Ces trois questions ne ressemblent pas aux "prompts magiques" qu’on lit sur LinkedIn. Elles sont banales. Personne ne les pose. Et pourtant, tout le monde devrait.

Mon prompt système contient aussi une consigne explicite : pas de flatterie. Pas de "Excellente question !". Pas de "Absolument !". Direct, factuel, contradictoire si nécessaire. Le résultat : un assistant qui me fait douter de mes idées au lieu de me les vendre. Un LLM complaisant te fait progresser deux fois moins vite qu’un LLM challengé.

Règle 4 : Je teste deux IA l’une contre l’autre

Claude contre ChatGPT. Claude contre Gemini. Parfois les trois sur la même question.

Quand elles divergent, je creuse. Une divergence entre deux modèles signale presque toujours une zone d’incertitude réelle : sujet récent, controverse, faits mal couverts dans les corpus d’entraînement. C’est là que je vais chercher la source primaire. Quand elles convergent, je vérifie quand même. Deux modèles qui se trompent ensemble, ça arrive plus souvent qu’on ne croit : ils ont été entraînés sur des textes similaires, ils héritent des mêmes biais, ils répètent les mêmes erreurs.

Aucun LLM n’a le monopole de la vérité. La confrontation, oui.

Concrètement, sur une recommandation de plugin WordPress, je demande d’abord à Claude. Puis je pose la même question à ChatGPT ou Gemini selon le sujet. Puis je confronte les deux à la fiche officielle WordPress.org via mon connecteur MCP wordpress-org. Trois sources, trois angles, une seule décision finale : la mienne.

Règle 5 : Tout passe par Git. Aucune exception.

Pas une ligne de code en production sans avoir été enregistrée dans Git.

Pourquoi Git, religieusement ? Parce que l’IA peut casser. Et Git me rattrape. Toujours.

Revenons à l’incident de fin avril. J’avais demandé à Claude d’ajouter un bloc de sécurité dans le middleware Next.js pour bloquer les requêtes vers des extensions de fichiers suspectes. Le code était propre. Les tests passaient. Envoi en production, déploiement, terminé. Sauf que la liste des extensions bloquées englobait sans liste blanche mes routes critiques : sitemap.xml, robots.txt, llms.txt, feed.xml. Quatre jours plus tard, Google avait arrêté de crawler mon sitemap. Quatre jours d’indexation cassée. Un incident SEO réel.

Mon protocole de rattrapage tient en trois étapes :

1. Annulation immédiate du commit fautif avec la commande git revert. Quinze secondes. La production redevient propre.
2. Création d’une branche dédiée pour retravailler la correction tranquillement, sans pression de production cassée.
3. Commit toutes les trente minutes tant que je manipule du code sensible. Pour pouvoir reculer à n’importe quel moment.

Sans Git, j’aurais passé une journée à reconstituer ce que j’avais cassé. Avec Git, j’ai bu un café.

Bref. À minima, une branche dédiée par fonctionnalité et un commit toutes les trente minutes. C’est le contrat. Travailler avec une IA sans Git, c’est comme conduire sans ceinture : tant que rien ne se passe, ça va. Quand ça arrive, c’est déjà trop tard.

Règle 6 : Je soigne mes fichiers système comme du code de production

Ces fichiers ne sont pas accessoires. Ils définissent le cadre dans lequel l’IA travaille.

J’ai 3 piliers que je versionne, que je relis chaque mois, et que je traite avec le même sérieux que mon composer.json ou mon next.config.js :

• CLAUDE.md : le cadre. C’est l’équivalent d’un brief que je redonne à Claude au démarrage de chaque session. Conventions du projet, ensemble d’outils techniques, charte graphique verrouillée, règles de style rédactionnel. Moins de 130 lignes, sinon l’IA ne lit pas tout.
• MEMORY.md : la mémoire longue. Un index des +50 leçons apprises/capitalisées sur les incidents passés. Moins de 80 lignes, sinon il faut les éclater par thématique.
• settings.json : les garde-fous techniques. Permissions, scripts déclenchés avant chaque action sensible, liste d’autorisations explicites.

Autour de ces trois piliers, j’ai construit un vrai système de mémoire : un dossier memory/ avec une cinquantaine de fichiers feedback-*.md et rules-*.md qui capturent chaque correction reçue, chaque incident, chaque décision contre-intuitive. À chaque fois qu’un truc casse, j’écris ce que j’aurais dû savoir avant. À la session suivante, Claude lit ce fichier au démarrage. Il ne refait plus la même erreur.

C’est plus de boulot à court terme. Mais c’est la seule façon, à moyen terme, de garder une IA qui s’améliore au lieu d’une IA qui radote.

Règle 7 : Je crée mes propres skills. J’éduque mon IA.

Cela fait longtemps que j’ai arrêté de recopier des skills génériques, trouvés ici et là ou sur LinkedIn. Que ce soit pour le SEO, pour l’optimisation, le maillage, etc… Claude ne connaît pas mon métier. Je le lui apprends.

Sur WPFormation, j’ai construit plus de 20 skills personnalisés (des "commandes slash" qui automatisent des tâches précises de mon quotidien). Quelques exemples concrets :

• /wp-article : pour prépublier un article en respectant mon pipeline éditorial en 10 phases.
• /audit-seo : pour scorer une page sur six sources (Google Search Console, GA4, Bing, audit on-page, citabilité IA, qualité GEO).
• /maillage-interne : pour détecter les liens cassés et planifier les hubs sémantiques.
• /backup : pour sauvegarder une copie de mes articles avant toute modification de plusieurs contenus à la fois.

Six agents spécialisés tournent en parallèle : un pour le serveur, un pour le frontend Next.js, un pour la rédaction, un pour le débogage WordPress, un pour le débogage cross-stack PHP + Next.js, un pour l’audit responsive. J’utilise aussi NotebookLM en complément, pour ma documentation d’architecture interne, ce qui me permet de demander "comment fonctionne mon cache ISR (rendu incrémental côté serveur) ?" et d’obtenir une réponse calée sur ma vraie configuration, pas sur la doc générique de Next.js.

Résultat : un Claude à jour, qui parle mon métier, qui ne se trompe plus sur mes conventions, et que je n’ai plus à briefer trois fois par session. J’ai déjà partagé certains de ces skills, par exemple le skill Spectra pour Claude Code qui automatise mes blocs Gutenberg personnalisés.

Règle 8 : Je sais ce que je veux avant de demander

Un prompt n’est pas une question floue. C’est comme un cahier des charges.

Quand je demande à Claude de préparer le sujet d’un article, je ne tape pas "écris-moi un article sur les plugins de cache". Je tape un brief structuré qui couvre les points suivants :

• Sujet précis et mot-clé focus en longue traîne (3 ou 4 mots).
• Catégorie WordPress unique pour éviter la cannibalisation.
• Angle d’opinion ou position défendue.
• Public visé (débutant, intermédiaire, expert) et longueur cible en mots.
• Contraintes rédactionnelles anti-IA (zéro tiret cadratin, guillemets droits uniquement, alternance tu/vous 70/30).
• Références à charger avant d’écrire, anecdotes personnelles à intégrer.
• Format des liens internes, méta titre et méta description souhaitées.

La réflexion vient avant. Pas après.

C’est ce travail amont qui fait toute la différence entre un brouillon que je dois réécrire à 80% et un brouillon que je peux pratiquement publier après une relecture de calibration. J’ai documenté ce pipeline en détail dans un article séparé : comment j’utilise Claude Code pour faire tourner WPFormation.

Ici, je reste sur la posture : un prompt vague produit un travail vague. Un prompt précis produit un livrable précis. Ce n’est pas une question d’outil, c’est une question de discipline.

Règle 9 : Je garde les compétences que l’IA pourrait remplacer

Je code encore à la main. J’écris encore sans assistance. Régulièrement. Volontairement.

Et si Claude tombe en panne demain matin ? Rien, si j’ai gardé mes compétences. Tout, si je les ai laissées s’atrophier. Le calcul est simple. Le choix est tranché. Sinon, dans 2 ans, je ne suis plus augmenté par l’IA. Je suis dépendant de l’IA.

Le jour où j’ai livré la page Migration headless WordPress de wpformation.com. Le matin, audit déclaratif : revue de code classique, 3 points à corriger identifiés. L’après-midi, audit en conditions réelles sur la production : requêtes à la main avec curl, vérifications manuelles dans Google Search Console, lecture du HTML rendu côté navigateur, contrôle visuel sur trois appareils différents. Bilan : 4 problèmes critiques supplémentaires, totalement invisibles depuis le code source seul.

1. Une cannibalisation entre deux pages services avec 2 522 impressions Google Search Console à 0% de clic.
2. Un duplicate de l’URL /maintenance-wordpress/ dans le sitemap.xml, dû à une collision entre un slug WordPress et une route Next.js statique.
3. Un schéma de données structurées Course.offers mal compilé, repéré uniquement en lisant le JSON-LD rendu côté client.
4. Un résidu de classe Tailwind oubliée sur une icône, qui ne ressortait dans aucun test automatique.

Si je ne savais plus utiliser curl, si je ne savais plus lire un sitemap, si je ne savais plus inspecter le HTML rendu pour repérer un schéma cassé, je n’aurais rien vu. Claude ne les avait pas vus non plus. C’est moi qui les ai trouvés, à la main, parce que je sais encore le faire.

L’expertise humaine reste précieuse précisément quand l’IA s’occupe du gros du travail. Pour creuser la frontière entre ce qu’on délègue et ce qu’on garde, je te recommande la lecture de les tâches que l’IA fait mieux qu’un humain.

Règle 10 : On progresse ensemble. Pas de délégation.

Claude Code garde la trace de nos sessions. Il apprend de ses erreurs. Et moi aussi.

Mon système de mémoire compte aujourd’hui plus de 50 fichiers feedback-*.md. Chacun documente un incident, une correction, une intuition. Quelques exemples concrets :

• Vérifier les étoiles GitHub avant de recommander un plugin. Parce qu’une fois, j’ai recommandé un dépôt à 1 étoile au lieu du vrai à 13 000 étoiles. Confusion d’orthographe, deux comptes différents, signature identique.
• Toujours coupler audit déclaratif et audit en conditions réelles le même jour. Parce que quatre problèmes critiques invisibles depuis le code ont été trouvés en production, sur la même journée.
• Ne jamais tenter de fixer le soft-404 via une liste statique de slugs dans le middleware. Parce que deux tentatives ont échoué, et la seconde aurait rejoué l’incident de quatre jours d’indexation cassée.
• Toujours pull wp-config.php en FTP avant de conclure "secret périmé". Parce qu’un endpoint qui répond 401 cache parfois une rotation de secret silencieuse.
• Ne pas recommander une nouvelle bibliothèque sans vérifier sa maintenance récente. Parce qu’une dépendance abandonnée devient une dette technique en six mois.

Ces règles, ce n’est pas Claude qui les a écrites. C’est moi, après chaque erreur. Mais c’est lui qui les relit au démarrage de chaque session. La progression est mutuelle, datée, traçable. Je ne progresse pas grâce à lui. Je progresse avec lui.

C’est une collaboration. Pas une délégation.

Pour les pros qui veulent déléguer leur WordPress à un humain augmenté plutôt qu’à une IA seule, mes prestations d’expert WordPress assument cette posture : moi devant, Claude derrière, jamais l’inverse.

Le vrai sujet, ce n’est pas : "est-ce que tu utilises l’IA" ?

Le vrai sujet, c’est comment ?

Spécialiste WordPress qui ne lâche jamais le volant. Voilà ma règle de base. Les dix autres en découlent.

Fabrice Ducarme

Six mois de pratique sur un site qui pèse, sur du code qui sert, sur des contenus qui se positionnent dans les résultats Google et qui se font citer par Perplexity. Voilà ce que j’ai retenu… Pas le meilleur des publications LinkedIn. Une posture éthique de technicien WordPress, validée par les bourdes que j’ai évitées et celles que j’ai dû réparer.

Sur le terrain, la plupart des stagiaires WordPress que je forme me posent la même question avant de toucher à Claude : "Par où je commence ?" Ma réponse n’a pas bougé depuis des mois.

Mon conseil pour ceux qui veulent s’y mettre sérieusement : ne pars pas de la techno. Pars de la discipline. Choisis d’abord les règles que tu ne négocieras jamais. Ensuite seulement, ouvre Claude Code.

Le manifesto en PDF

J’ai condensé ces dix règles dans un carousel PDF de 14 pages, en charte WPFormation. Tu peux le télécharger pour le partager dans tes équipes, l’imprimer, le réutiliser en formation. C’est le même document que celui que j’ai publié sur LinkedIn il y a quelques semaines, prêt à diffuser sans avoir à reconstituer la mise en page.

Pour creuser le sujet IA + WordPress sous d’autres angles, je te propose trois lectures complémentaires sur le site : le pack de 20 prompts WordPress + IA (la boîte à outils concrète que j’utilise au quotidien), le test gratuit de citabilité IA (pour mesurer combien les chatbots citent ton site) et comment j’utilise l’IA pour former à WordPress (côté pédagogie).

Bonne route. Garde tes deux mains sur le volant. Et suis le Claude Code !

Article original sur WPFormation