Les images ne sont pas générées

Si votre article a été publié avec succès mais que l’image à la une ou les images du corps n’apparaissent pas, parcourez cette page dans l’ordre. La cause la plus courante vit à l’étape 1 — c’est un problème d’environnement plutôt qu’un problème avec votre campagne.

Avant de commencer

Ouvrez Tools → Site Health dans WordPress. Structura ajoute trois sondes là qui s’allument quand les bloqueurs les plus courants de génération d’image sont présents :

MySQL packet size is sufficient for background tasks
WordPress cron is enabled
WordPress uploads directory is writable

Si l’une est marquée en rouge ou en jaune, corrigez-la d’abord — les étapes ci-dessous détaillent chaque correctif.

Étape 1 : le `max_allowed_packet` de MySQL est-il trop petit ?

C’est de loin la cause la plus courante que nous voyons sur l’hébergement mutualisé.

Ce qui se passe. Structura met les tâches de génération d’image en file d’attente avec Action Scheduler , qui stocke chaque tâche en file dans la table wp_actionscheduler_actions. Si les données sérialisées de la tâche sont plus grandes que le réglage max_allowed_packet de MySQL, la base de données rejette la ligne en silence. Pas d’erreur PHP, pas d’erreur dans l’admin. La tâche n’est simplement jamais créée — donc l’image n’est jamais générée.

Structura 1.17+ attrape cela au moment de la mise en file et fait remonter l’échec dans le détail de l’exécution de la campagne, sous l’étape Visuals. Le message ressemble à :

Featured image task could not be enqueued. Action Scheduler refused the write — this is usually a MySQL packet-size limit (max_allowed_packet) or a database-write failure on wp_actionscheduler_actions.

Comment le corriger. Vous devez augmenter max_allowed_packet à au moins 4 Mo (4194304). Comment vous le faites dépend de votre hébergeur :

Hébergement mutualisé (Hostinger, SiteGround, Bluehost, etc.) — ouvrez un ticket de support en leur demandant d’augmenter max_allowed_packet sur votre base de données à 4 Mo ou plus. La plupart des hébergeurs le feront en quelques heures ; c’est une demande courante.
WordPress géré (Kinsta, WP Engine, Pressable) — votre hébergeur a déjà mis une valeur raisonnable. Si Site Health le signale quand même, ouvrez un ticket de support et incluez une capture de la carte Site Health.
VPS / autogéré — ajoutez max_allowed_packet = 16M sous [mysqld] dans /etc/mysql/my.cnf (ou l’équivalent sur votre installation MySQL / MariaDB) et redémarrez le service de base de données.

Une fois le changement effectif, lancez à nouveau une campagne ou cliquez sur Générer image sur l’écran d’édition de n’importe quel article généré par Structura — l’image devrait maintenant s’enregistrer correctement.

Étape 2 : le cron WordPress est-il désactivé ?

Ce qui se passe. Si votre wp-config.php inclut define('DISABLE_WP_CRON', true); et qu’il n’y a pas de cron système qui appelle wp-cron.php, les tâches de génération d’image en arrière-plan sont mises en file mais ne tournent jamais.

Comment le corriger. Soit :

Retirer la constante DISABLE_WP_CRON de wp-config.php, soit
Ajouter un cron côté serveur qui appelle wp-cron.php toutes les minutes :


* * * * * wget -q -O - https://your-site.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

La plupart des hébergeurs gérés s’occupent de ça pour vous. Sur l’hébergement mutualisé, vous devrez peut-être définir le cron job vous-même dans votre panneau d’hébergement.

Étape 3 : le répertoire d’uploads est-il accessible en écriture ?

Ce qui se passe. Les images générées sont importées via le helper media_handle_sideload() de WordPress, qui écrit dans wp-content/uploads/YYYY/MM/. Si ce répertoire (ou son parent) n’est pas accessible en écriture par PHP, le sideload échoue. Site Health fait remonter le message d’erreur exact de WordPress.

Comment le corriger. Rendez le répertoire d’uploads accessible en écriture par le serveur web. Le correctif typique sur les hébergeurs Linux :


chown -R www-data:www-data wp-content/uploads
chmod -R 755 wp-content/uploads

Ajustez l’utilisateur (www-data, apache, nobody, etc.) pour correspondre à l’utilisateur du serveur web de votre hébergeur.

Étape 4 : le fournisseur d’image est-il correctement configuré ?

Si aucun des contrôles d’environnement ci-dessus n’a signalé un problème, le problème peut être côté fournisseur.

Ouvrez Structura → Paramètres → Moteur d’IA.
Confirmez que votre fournisseur d’image est connecté (case verte).
Si vous êtes sur le plan Free ou BYOK (apportez votre propre clé), confirmez que le fournisseur que vous avez sélectionné est capable de produire des images. Claude ne produit que du texte — si vous avez sélectionné Claude pour les images, Structura sautera la génération d’image en silence sur les plans BYOK (sur les plans gérés — Cloud et Cloud Pro — nous substituons un fournisseur capable d’images automatiquement).

Voir Paramètres d’IA pour une visite complète.

Étape 5 : toujours bloqué ?

Ouvrez l’exécution la plus récente de la campagne depuis le tableau de bord et regardez l’étape Visuals dans le détail de l’exécution. Le message d’erreur de l’étape nomme généralement l’échec exact — copiez-le dans un ticket de support ainsi que :

Votre niveau de plan
Votre fournisseur d’image configuré
Le nom de la campagne
L’ID de l’exécution de la campagne (visible dans l’URL du détail de l’exécution)
Une capture de Tools → Site Health

Contactez le support.