Donner à une IA les clés d'un site en production, ça sonne comme une très mauvaise idée. C'est la première réaction de la plupart des gens à qui j'en parle, et honnêtement, c'est une réaction saine. Un assistant qui peut éditer des pages, déplacer des médias et toucher au SEO d'un site qui reçoit du vrai trafic, sans filet, c'est un accident qui attend de se produire.
Et pourtant j'ai construit exactement ça. Un pont entre un assistant IA et WordPress, qui laisse l'IA travailler sur le vrai site. Pas sur une copie, pas sur du copier-coller dans l'admin que je referais à la main derrière. Le vrai site. La différence avec « mauvaise idée », elle tient entièrement dans la façon dont on encadre l'accès. Mon point de départ, c'est simple : une IA qui opère un site de prod, on la traite comme n'importe quel accès à de la prod. Avec les mêmes précautions qu'on prendrait pour un stagiaire à qui on ouvre l'admin le premier jour, sauf que le stagiaire, lui, hésite avant de cliquer sur « supprimer ».
Pourquoi un pont, et pas juste l'IA qui copie-colle
Le réflexe naturel, quand on veut faire rédiger du contenu par une IA, c'est de lui demander le texte dans une fenêtre de chat puis de le coller soi-même dans WordPress. Ça marche, pour une page. Pour trente pages, c'est une corvée, et c'est là que les erreurs se glissent : une meta oubliée, un titre mal reporté, une mise en page qui dérive d'une page à l'autre.
Le pont change la nature du travail. L'IA ne produit plus un texte que je recopie, elle exécute des actions cadrées directement sur le site : lister et créer des pages et des articles, composer une mise en page avec le constructeur (Divi, dans mon cas), gérer la bibliothèque de médias, organiser les menus, remplir les titres, les meta descriptions et les données structurées, lancer des diagnostics, déclencher des sauvegardes. Chaque action est une opération précise, traçable, pas un bloc de texte que je dois interpréter.
Le gain n'est pas que ça va plus vite (ça va plus vite). C'est que le travail devient reproductible. Quand l'IA décline dix pages de services sur le même gabarit, les dix sortent cohérentes, parce que c'est la même opération répétée dix fois, pas dix copier-coller faits par un humain fatigué le vendredi soir.
Les garde-fous, c'est tout l'article
Si tu ne retiens qu'une chose, retiens celle-là : sans garde-fous, ce que je décris est irresponsable. Avec, c'est juste un outil de plus. Toute la valeur est dans le cadre, pas dans la capacité brute de l'IA à modifier des pages.
Premier garde-fou, le périmètre des accès. On ne commence jamais en écriture. La clé d'API que je donne à l'assistant démarre en lecture seule. L'IA peut tout voir, lister les pages, lire le contenu existant, auditer le SEO, repérer les liens morts, mais elle ne peut rien modifier. On reste comme ça le temps de vérifier qu'elle comprend bien le site, qu'elle ne part pas dans une mauvaise direction. L'écriture, on ne l'accorde qu'ensuite, en connaissance de cause. Cette étape paraît anodine et c'est pourtant celle qui sauve le plus de bêtises : la moitié des dégâts potentiels disparaissent simplement parce que l'IA n'a pas le droit d'écrire pendant qu'elle apprend.
Deuxième garde-fou, la sauvegarde avant toute opération destructive. Avant qu'une page soit écrasée, avant qu'un contenu soit remplacé, on prend une sauvegarde, et on garde le chemin du retour ouvert. Si le résultat ne va pas, on restaure l'état d'avant. Ce n'est pas une option qu'on active les jours de prudence, c'est le défaut. WordPress garde déjà des révisions de contenu, ce qui aide, mais je ne me repose pas dessus seul : une sauvegarde explicite avant l'opération, et un rollback testé, c'est ce qui me permet de dormir.
Troisième garde-fou, la validation humaine sur ce qui compte. L'IA propose, je garde la main. Pour une meta description ou l'harmonisation d'un espacement, je la laisse faire et je vérifie après. Pour tout ce qui touche à la structure, qui peut casser quelque chose ou qui est difficile à défaire, elle s'arrête et attend mon feu vert. Le partage est volontairement asymétrique : l'IA abat le volume, le jugement reste de mon côté. Je n'ai jamais voulu d'un système qui décide tout seul ce qui doit changer sur le site d'un client.
Quatrième garde-fou, l'accès lui-même est verrouillé. Les requêtes sont signées, et seules certaines IP sont autorisées à parler au site. Concrètement, même si une clé fuitait, elle ne servirait à rien depuis une machine non listée. C'est de l'hygiène de base pour n'importe quel accès machine-à-machine, et ça vaut a fortiori quand l'autre bout est un assistant qui exécute des actions en autonomie.
Aucun de ces quatre points n'est spectaculaire. Mis bout à bout, ils font la différence entre un outil que je confie à un site qui tourne et une démo que je n'oserais jamais brancher ailleurs que sur un bac à sable.
Ce que ça donne sur un vrai site
Je n'ai pas testé ça sur un projet jouet. Le cas réel, c'est un site client, sous WordPress et Divi 5. Un vrai site, avec de vraies pages, un vrai besoin d'être trouvé sur Google et des obligations légales à respecter.
Ce que j'ai fait piloter par l'IA : enrichir les pages existantes (les rendre plus complètes, plus claires), remplir le SEO page par page là où il était vide ou bâclé, et produire le contenu légal de base. Du travail utile, mais répétitif, le genre de tâche qu'on repousse parce qu'elle est ingrate. Décliner proprement les metas sur l'ensemble du site, vérifier que chaque page a un titre qui veut dire quelque chose, harmoniser des sections qui avaient divergé au fil des mois : l'IA est très bonne à ça, et elle ne s'ennuie pas, elle.
Là où je suis resté aux commandes, c'est sur les arbitrages. Quel ton pour le site, qu'est-ce qui mérite une page à part, est-ce que ce qui est écrit est juste et fidèle à ce que le client veut dire. Ces décisions-là, l'IA peut les proposer, elle ne doit pas les trancher seule.
Les trois choses que j'ai apprises
La première, c'est où l'IA brille vraiment. Le répétitif et le structuré. Décliner des pages sur un même modèle, remplir des champs SEO, harmoniser une mise en page, rédiger un premier jet de contenu propre. C'est mécanique, c'est fastidieux, et c'est précisément le genre de travail qui coûte des heures à un humain pour un résultat sans gloire. L'IA avale ça sans broncher. Si tu cherches où elle te fait gagner du temps, c'est là, pas dans les choix éditoriaux fins.
La deuxième, c'est que les garde-fous ne sont pas négociables. Je sais que je me répète, c'est volontaire. La sauvegarde avant écriture et le « lecture seule d'abord » tiennent lieu de fusibles, et sans eux l'expérience ne reste pas raisonnable bien longtemps. Le jour où tu les sautes parce que « c'est juste une petite modif », c'est le jour où tu apprends pourquoi ils existaient.
La troisième, c'est la plus importante, et elle va à contre-courant du discours ambiant. L'IA ne remplace pas le webmaster. Elle lui enlève la corvée. Tout le travail de jugement reste humain : décider quoi changer, vérifier que c'est juste, sentir ce qui sonne faux. Ce que l'IA supprime, c'est la partie ingrate, la saisie, la répétition, le remplissage. Ce qu'elle ne touche pas, c'est ce qui fait la valeur du métier. Vendre l'inverse, c'est mentir, et ça se voit assez vite sur le rendu.
Au fond, le truc intéressant n'est pas que l'IA sache éditer WordPress. C'est qu'elle t'oblige à écrire noir sur blanc ce qu'est une opération sûre sur ton site : ce qui se sauvegarde avant, ce qui demande une validation, ce qui ne doit jamais partir en autonomie. La plupart des sites n'ont jamais formalisé ça. Brancher une IA dessus, c'est l'occasion de le faire, et c'est probablement le vrai bénéfice, bien avant le temps gagné.
Si tu as un site WordPress et que cette approche t'intéresse pour le tien, parlons-en.