La démo et la production : deux réalités différentes
Vous avez vu des démonstrations d'outils IA qui modifient un site en 2 minutes. Injectent du contenu, génèrent une page, ajoutent une section. C'est réel et impressionnant. Ce que ces démos ne montrent jamais : le site utilisé est un WordPress tout propre, fraîchement installé, sans historique, sans plugins, sans thème enfant modifié depuis 3 ans.
Le site de votre client, lui, a 47 plugins actifs. Certains chargés par le développeur précédent dont vous n'avez plus le contact. Un thème acheté sur ThemeForest en 2019, modifié directement dans les fichiers du thème parent par un prestataire qui ne savait pas ce qu'était un thème enfant. Un plugin de cache configuré en mode agressif. Wordfence en mode paranoia. Et une installation WooCommerce avec 6 extensions tierces dont 2 sans mises à jour depuis 18 mois.
C'est la norme, pas l'exception. La plupart des sites WordPress en production ressemblent à ça. Et c'est pour ça que chaque intervention prend plus de temps que ce que les outils IA laissent entendre.
Les conflits de plugins : la source de 80% des problèmes inexpliqués
Un conflit de plugins, c'est quand deux plugins chargent du code qui se contredit. Parfois c'est immédiat et visible (page blanche, erreur PHP), parfois c'est subtil et n'affecte que certaines configurations ou certains navigateurs. Le diagnostic prend du temps parce qu'il n'y a pas de message d'erreur évident.
wp_footer qui devait injecter du contenu dynamique (stock en temps réel, prix selon le rôle utilisateur, chatbot) ne se déclenche plus. Le contenu injecté n'apparaît pas en production alors qu'il fonctionne en staging sans cache. Diagnostic non évident pour quelqu'un qui ne connaît pas l'interaction cache/WP.
woocommerce_checkout_fields ou woocommerce_cart_totals_coupon_html. Si deux plugins modifient le même hook avec la même priorité, le dernier à se charger gagne, et le comportement de l'autre est silencieusement écrasé. Le checkout affiche des champs inattendus, ou un coupon ne s'affiche plus.
rewrite_rules de WordPress. Une activation ou désactivation de plugin sans régénération des permaliens laisse des URLs cassées. Erreur 404 inexpliquée sur certaines pages, pas toutes. L'outil IA qui "corrige" le contenu ne sait pas que le problème vient des règles de réécriture.
Le staging qui ne ressemble pas au prod
Le staging est censé être une copie conforme de la production pour tester les modifications avant de les déployer. En pratique, les staging de la plupart des hébergements gérés (WP Engine, Kinsta, Siteground) ont des différences qui rendent le test partiel.
Staging sans CDN Cloudflare actif, sans le vrai certificat SSL, avec des plugins désactivés "le temps des tests", des variables d'environnement différentes, un domaine différent qui casse les liens absolus en base de données. Tester sur un staging non représentatif, c'est valider dans une salle blanche ce qui sera déployé dans un atelier.
Ce qui fonctionne sur un staging approximatif et casse en prod : les webhooks qui vérifient le domaine d'origine, les règles Cloudflare qui bloquent certaines requêtes, les scripts qui testent si SSL est activé avant de charger, les plugins de membres qui vérifient le domaine de la licence. Ce sont des erreurs silencieuses : aucun message d'erreur PHP, juste une fonctionnalité qui disparaît en prod sans explication visible.
Ce que seul un dev WP expérimenté comprend dans ce contexte
L'outil IA qui modifie du code WordPress fonctionne correctement sur le code en isolation. Il ne sait pas qu'un plugin de membership filtre the_content avec une priorité de 1 et va écraser le contenu généré. Il ne voit pas que wp_enqueue_scripts est déjà surchargé trois fois dans functions.php et que l'ordre de chargement des scripts n'est pas ce qu'il devrait être. Il ne détecte pas que le hook qu'il vient d'ajouter entre en conflit avec un hook existant dans un plugin d'optimisation.
Ce que sait faire un développeur WordPress expérimenté sur ce type de site : lire un functions.php de 800 lignes et identifier les patterns problématiques, utiliser Query Monitor pour visualiser tous les hooks actifs et leur priorité, désactiver les plugins par groupe pour isoler un conflit, comprendre pourquoi le staging diffère de la prod et adapter les tests en conséquence.
Sur un site en production avec des années d'historique, la compétence clé n'est pas d'écrire du code, c'est de comprendre le système dans son état actuel. Ce diagnostic, aucun outil IA ne peut le faire sans contexte sur l'environnement spécifique du site.
Conclusion : pourquoi l'estimation dépend du nombre de plugins actifs
Quand vous estimez une intervention sur un WordPress inconnu, la première chose à vérifier n'est pas la complexité de la fonctionnalité à ajouter : c'est le nombre de plugins actifs, l'ancienneté du site, et la qualité du staging disponible. Ces trois paramètres déterminent le risque de conflit et le temps de diagnostic.
Moins de 15 plugins, thème enfant propre, staging représentatif : une intervention de 2h prend 2h. 40+ plugins, thème parent modifié, staging sans CDN : la même intervention peut prendre une journée. Pas parce que le développeur est moins efficace, mais parce que la complexité accumulée du site crée des obstacles que les outils IA ne voient pas depuis l'extérieur.
C'est une réalité que seuls les gens qui font du dev WordPress en production comprennent vraiment. Et c'est une partie de ce que vous payez quand vous travaillez avec un développeur qui connaît cet environnement.