Depuis la version 5.6, WordPress intègre tout ce dont un système externe a besoin pour publier : l'API REST et les mots de passe d'application. Vous créez un utilisateur dédié avec le rôle Auteur ou Éditeur, vous générez pour lui un mot de passe d'application et vous enregistrez les deux dans le système de blog. Ensuite, les articles apparaissent directement dans WordPress avec titre, texte, catégorie et image mise en avant, en brouillon ou publiés, sans extension supplémentaire et sans copier-coller.
La méthode habituelle : un texte est rédigé dans Word ou dans un outil d'IA, copié dans l'éditeur WordPress, la mise en forme se perd, les intertitres sont à refaire, l'image est téléversée à part, la catégorie oubliée. Une demi-heure par article, pour un résultat qui ne produit que des erreurs. Pourtant, WordPress dispose depuis des années d'une interface qui rend tout cela superflu.
Ce qu'est l'API REST de WordPress
L'API REST fait partie du noyau de WordPress depuis la version 4.7. Elle permet à des programmes de communiquer avec une installation WordPress via Internet : lire, créer et modifier des articles, téléverser des images dans la médiathèque, interroger les catégories. L'éditeur Gutenberg utilise lui-même cette interface quand vous enregistrez un article. Un système de blog externe fait la même chose, simplement sans personne devant le navigateur.
L'adresse de l'interface se trouve toujours sous votre domaine, par exemple https://ihre-firma.ch/wp-json/wp/v2/posts. Si vous ouvrez cette adresse dans le navigateur et que vous voyez la liste de vos articles au format JSON, l'API REST est active.
Ce que vous devez préparer
La connexion ne demande aucune programmation, mais quatre éléments de votre installation WordPress :
- HTTPS : les mots de passe d'application ne fonctionnent que via une connexion chiffrée. Pratiquement tous les sites en disposent aujourd'hui.
- Un utilisateur dédié pour le système de blog, par exemple « Rédaction » ou le nom du système. Pas l'accès administrateur.
- Le bon rôle : Auteur suffit si les articles doivent apparaître en brouillon ou sous un nom propre. Éditeur si le système doit aussi modifier les articles d'autres utilisateurs ou créer des catégories.
- Un mot de passe d'application : dans le profil utilisateur, sous « Mots de passe d'application », saisissez un nom, cliquez sur « Ajouter un mot de passe d'application » et copiez le mot de passe affiché, une seule fois. Il ne sera pas affiché une seconde fois.
Il reste une décision à prendre : dans quelle catégorie les articles doivent-ils aller ? Une catégorie existante comme « Conseils » ou une nouvelle. Le nom de la catégorie est enregistré dans le système de blog, pour qu'aucun article ne finisse dans « Non classé ».
Ce qui arrive dans WordPress à chaque publication
Avec BlogPilot, un article validé est transmis en une seule fois. Le tableau montre ce qui arrive où :
| Élément | Où cela arrive dans WordPress |
|---|---|
| Titre | Titre de l'article |
| Texte avec intertitres, listes, section FAQ | Contenu en HTML, affiché par le thème comme tout autre article |
| Liens internes vers vos pages | Dans le contenu, sous forme de liens normaux |
| Extrait | Extrait de l'article, que de nombreux thèmes affichent dans la vue d'ensemble |
| Catégorie | La catégorie enregistrée, plusieurs si nécessaire |
| Image mise en avant | Téléversée d'abord dans la médiathèque, puis définie comme image mise en avant |
| Permalien | Dérivé du titre, selon les règles de permaliens de votre installation |
| Statut | Brouillon ou publié, selon le paramètre de validation |
Tout ce que votre thème fait d'un article se produit ensuite automatiquement : affichage dans la vue d'ensemble du blog, date, auteur, fonction de commentaires, entrée dans le sitemap. WordPress ne sait pas d'où vient l'article, et n'a pas besoin de le savoir.
Pourquoi aucune extension n'est nécessaire, et pourquoi c'est un avantage
De nombreuses solutions d'IA pour WordPress se présentent sous forme d'extension. Cela signifie : du code tiers sur votre serveur, des mises à jour, des dépendances au thème, des conflits possibles avec d'autres extensions. La connexion via l'API REST n'exige rien de tout cela. Pas une ligne ne change sur votre site, il y a seulement un utilisateur supplémentaire. Si vous mettez un jour fin au contrat, vous supprimez le mot de passe d'application, et les articles restent où ils sont. Ce que cette différence change au quotidien est expliqué dans la comparaison Extensions IA pour WordPress ou système de blog externe.
Sécurité : ce que vous devez savoir
- Limiter les droits. L'utilisateur reçoit uniquement le rôle dont il a besoin. Un auteur ne peut pas installer de plugins, modifier les paramètres ni supprimer les articles d'autres personnes.
- Mot de passe d'application plutôt que mot de passe de connexion. Le mot de passe d'application ne vaut que pour l'interface, pas pour le back-office. Il se révoque d'un clic dans le profil.
- Uniquement via HTTPS. WordPress n'autorise tout simplement pas les mots de passe d'application via des connexions non chiffrées.
- Vérifier les plugins de sécurité. Certains plugins ou pare-feu d'hébergeur bloquent l'API REST pour les visiteurs non connectés ou interdisent les mots de passe d'application. Il faut alors prévoir une exception pour l'utilisateur de la rédaction. C'est la cause la plus fréquente lorsque la connexion échoue au premier test.
- Garder une trace. Chaque article apparaît sous l'utilisateur de la rédaction : vous voyez donc à tout moment dans le back-office ce qui a été créé via l'interface.
Brouillon ou publication directe
L'API REST propose les deux options, et le choix dépend de votre manière de travailler. Si vous voulez voir chaque article avant sa publication, vous le faites transmettre comme brouillon ou vous le validez au préalable par e-mail. Si vous faites confiance au processus, vous faites publier directement et vous pouvez toujours arrêter un article à tout moment. Chez BlogPilot, la validation a lieu avant la transmission, par e-mail ou d'un clic, de sorte que seul ce que vous avez vu arrive dans WordPress. L'article sur le processus de validation du blog décrit les variantes avec leurs avantages et leurs inconvénients.
Ce qui ne se fait pas automatiquement
Il y a des limites, soyons honnêtes, et elles se situent presque toutes en dehors du noyau de WordPress :
- Champs des plugins SEO. La méta-description et le mot-clé principal dans Yoast ou Rank Math ne font pas partie de l'API REST standard. Leur remplissage dépend du plugin et de sa configuration, et il est vérifié lors de la mise en place.
- Mises en page des page builders. Les articles arrivent en HTML propre. Si vous voulez reconstruire chaque article dans Elementor ou Divi, vous perdez l'avantage de l'automatisation.
- Champs personnalisés. Les champs propres à Advanced Custom Fields ou à des plugins similaires doivent être autorisés séparément.
Si le premier test échoue
| Symptôme | Cause probable |
|---|---|
| Erreur 401 ou 403 | Mot de passe d'application mal copié, droits insuffisants de l'utilisateur ou blocage par un plugin de sécurité |
| L'adresse /wp-json/ affiche une page d'erreur | API REST désactivée, permaliens réglés sur « Simple » ou pare-feu de l'hébergeur |
| Article présent, mais aucune image visible | Le thème n'affiche pas les images mises en avant ou le téléversement dans la médiathèque a été bloqué |
| Article dans la mauvaise catégorie | Le nom de la catégorie dans le système de blog ne correspond pas à celui de WordPress |
La plupart de ces points se règlent en quelques minutes. Si votre site ne fonctionne pas avec WordPress, d'autres voies mènent au but : la connexion à Wix, le blog Shopify ou un blog hébergé. La aide à la décision en cinq questions montre quelle variante convient à quel site.
Questions fréquentes
Dois-je installer un plugin pour que la connexion fonctionne ?
Non. L'API REST et les mots de passe d'application font partie du noyau de WordPress. Un plugin n'entre en jeu que si un plugin de sécurité bloque l'API REST et qu'une exception doit être configurée.
Le système de blog a-t-il alors accès à tout mon site ?
Non, si vous choisissez correctement le rôle. Un utilisateur avec le rôle Auteur peut créer et modifier ses propres articles, mais pas modifier de pages, de paramètres ni de plugins. Le mot de passe d'application peut être révoqué à tout moment dans le profil de l'utilisateur, sans changer le mot de passe de connexion.
Cela fonctionne-t-il aussi avec WordPress.com ou seulement avec un hébergement propre ?
Avec WordPress auto-hébergé, cela fonctionne en général sans restriction. Avec WordPress.com, cela dépend de l'offre choisie si l'API REST avec mots de passe d'application est autorisée. Cela se teste en quelques minutes, avant que vous vous engagiez.
Qu'advient-il de mon thème et de mon design ?
Rien. Les articles sont traités comme des articles créés à la main et s'affichent dans le design de votre thème. Les intertitres, les listes et la section FAQ arrivent en HTML normal, que votre thème affiche comme n'importe quel autre article.
Puis-je modifier les articles ensuite dans WordPress ?
Oui. Après la transmission, l'article appartient à WordPress : vous pouvez le modifier, le déplacer ou le supprimer dans l'éditeur comme n'importe quel autre. Il est plus judicieux d'apporter les corrections dans le système de blog avant la validation, afin que les deux côtés aient la même version.