Épisode 1 sur 4 — Saison 1 : le pipeline Rylaz.
Sommaire
- Le problème de départ
- Premier essai : la solution évidente
- Le vrai point de friction
- Trois briques pour connecter WordPress à une IA
- Ce qui a coincé
- Le résultat mesuré
- Où ça peut casser
- Ce que ça change
Le problème de départ
Connecter WordPress à une IA, c’est exactement ce que je voulais faire sur ce site. Chaque article passait par le même chemin : ouvrir l’éditeur, écrire, formater, publier. À la main. À chaque fois.
En tant qu’admin système, j’automatise des déploiements serveur, des sauvegardes, des alertes depuis longtemps. Une question a fini par me travailler : pourquoi pas la publication de contenu aussi ?
L’idée était simple. Demander à une IA de rédiger un article. Qu’il atterrisse en brouillon dans WordPress, prêt à relire. Sans copier-coller.
Premier essai : la solution évidente
J’ai d’abord testé un connecteur clé en main, capable de piloter un site WordPress.com directement. Séduisant sur le papier — zéro configuration.
Sauf que rylaz.fr n’est pas sur WordPress.com. C’est un WordPress auto-hébergé classique, et le connecteur exigeait un abonnement Jetpack payant pour débloquer l’écriture à distance.
Rien d’insurmontable, mais pas ce que je cherchais. Je voulais du gratuit, et surtout, garder la main dessus.
Le vrai point de friction
Détail technique important : je n’ai aucun accès réseau direct entre mon environnement de travail avec l’IA et mon propre site.
La tentation, à ce stade, c’est de se dire que connecter WordPress à une IA passe forcément par un outil payant. C’est faux. Il fallait juste le bon intermédiaire.
La solution : n8n, un outil d’automatisation déjà en place pour d’autres tâches, qui a lui un accès réseau libre. n8n devient le relais. L’IA lui envoie une demande, n8n parle à WordPress via son API REST officielle, gratuite, et renvoie une confirmation.
Trois briques pour connecter WordPress à une IA
1. Un webhook. Un point d’entrée qui écoute une requête entrante. Comme une sonnette à la porte : quelqu’un sonne — envoie un titre et un contenu — et à l’intérieur, une action se déclenche automatiquement, sans que j’aie besoin de surveiller quoi que ce soit en permanence.
2. Une authentification par Application Password. Depuis WordPress 5.6, on peut générer un mot de passe dédié à un usage technique, différent du mot de passe de connexion habituel. Un peu comme un double de clé donné à un jardinier : il entre dans le jardin, pas dans la maison, et s’il le perd, on change cette clé-là, pas toute la serrure.
3. Un nœud WordPress dans n8n, qui reçoit titre, contenu et statut, puis crée l’article via l’API REST WordPress en un seul appel.
Ce qui a coincé
Le premier test a échoué avec une erreur d’autorisation générique, du genre qui ne dit rien sur la cause réelle. J’ai vérifié l’URL du site, le nom d’utilisateur, tout semblait correct. Le vrai coupable : l’Application Password généré par WordPress contient des espaces (xxxx xxxx xxxx xxxx xxxx xxxx), et je les avais retirés en copiant-collant, en pensant bien faire. Il faut les garder tels quels — une habitude de copier-coller « propre » qui casse tout, sur un système qui n’a jamais réclamé cette propreté.
Deuxième point de vigilance, plus par prudence que par échec réel : vérifier que les articles n’étaient pas construits avec Elementor, l’éditeur visuel utilisé sur la page d’accueil du site. Si ça avait été le cas, le contenu envoyé par API n’aurait eu aucun effet visuel — un brouillon créé, mais invisible. Vérification faite en interrogeant un article existant : le champ template était vide. Les articles utilisent l’éditeur standard, pas Elementor.
Le résultat mesuré
Premier test réel : un article « brouillon » créé de bout en bout, du webhook jusqu’à l’admin WordPress, en un peu plus de 2 secondes d’exécution.
Statut : brouillon. Jamais publié automatiquement. La validation humaine reste systématique, quel que soit le niveau de confiance dans le système.
Où ça peut casser
Réflexe d’admin système : toujours noter ce qui pourrait poser problème, avant que ça arrive.
- Si l’Application Password est révoqué (possible à tout moment depuis WordPress), le pipeline s’arrête net, avec une erreur d’autorisation claire. Pas de publication fantôme.
- Si un plugin de sécurité vient un jour bloquer les appels API, ça casse sans prévenir. À surveiller si le site évolue.
- Le statut par défaut reste « brouillon », volontairement. Aucune automatisation ne devrait avoir le droit de publier sans un humain qui valide.
Ce que ça change
Plus de copier-coller dans l’éditeur WordPress à chaque article. Le contenu arrive en brouillon, je relis, j’ajuste ce qui doit sonner plus « moi », je publie.
Le gain n’est pas dans la rédaction elle-même. Il est dans toute la friction technique qui existait autour — celle qu’on ne voit jamais tant qu’on ne l’a pas déjà rencontrée. C’est la première étape concrète de ce que je documente ici sur Rylaz : connecter ses outils avec une IA, sans dépendre de solutions payantes.
Cet article a été rédigé avec l’aide de Claude, publié via le pipeline d’automatisation n8n → WordPress décrit ci-dessus. Si tu veux comprendre comment reproduire ça sur ton propre site, suis la suite.
