Le pipeline que vos clients veulent construire

Le scénario revient souvent : un client gère un catalogue de 200 à 2000 produits sur WooCommerce. Il a découvert que GPT-4 peut générer des descriptions de produits à la chaîne, alimenté par les données de son fournisseur. Il veut automatiser ça avec Make ou n8n : récupérer les fiches produit en CSV, les passer à l'API OpenAI, recevoir les descriptions enrichies, et les pousser directement dans WordPress.

Ce pipeline est faisable. On l'a mis en place plusieurs fois. Ce qui est systématiquement sous-estimé, c'est la partie WordPress en réception : comment les données arrivent, où elles vont, comment elles s'affichent, et ce qui se passe quand quelque chose ne correspond pas au format attendu.

Le vrai problème

Make ou n8n gèrent très bien l'orchestration et les appels API. Le goulot d'étranglement est presque toujours côté WordPress : la structure de données n'est pas prête à recevoir du contenu dynamique, les Custom Post Types n'existent pas, les champs ACF ne sont pas configurés, et l'API REST WP n'est pas exposée comme il faut.

Préparer WordPress avant de construire le flux

La première étape, avant même d'ouvrir Make, c'est de décider où le contenu généré va atterrir dans WordPress. Trois options selon le cas d'usage :

Option 1 : les champs natifs WooCommerce. Description courte, description longue, attributs : c'est la voie la plus simple. L'API REST WooCommerce expose ces champs directement. Le problème : si votre client veut stocker des données structurées (positioning, bénéfices clés, FAQ produit), les champs natifs ne suffisent pas.

Option 2 : des champs ACF sur les produits WooCommerce. Plus flexible, mais ACF ne s'expose pas dans l'API REST par défaut. Il faut activer l'option "Show in REST API" sur chaque groupe de champs, ou écrire un endpoint custom qui accepte les données et les enregistre via update_field().

Option 3 : un Custom Post Type dédié. Pour des contenus qui ne sont pas des produits au sens strict mais qui leur sont associés (guides, fiches techniques, comparatifs générés par IA) : un CPT propre avec son propre endpoint REST. Plus de travail initial, beaucoup plus de contrôle.

functions.php · exposer ACF dans REST 
// Exposer les champs ACF dans l'API REST WooCommerce
add_action( 'rest_api_init', function() {
  register_rest_field( 'product', 'ai_description', [
    'get_callback'  => fn( $obj ) => get_field( 'ai_description', $obj['id'] ),
    'update_callback' => fn( $val, $obj ) => update_field( 'ai_description', $val, $obj->ID ),
    'schema'         => [ 'type' => 'string' ],
  ]);
});

Les vrais problèmes sur les imports batch

Quand le flux tourne en production et traite 50 à 500 produits d'un coup, les problèmes qui n'existaient pas sur les tests unitaires apparaissent. Voici ceux qu'on rencontre le plus souvent :

01
Timeout sur les requêtes REST en masse
WordPress limite l'exécution PHP (souvent 30s sur les hébergements mutualisés). Un import de 200 produits via l'API REST en série dépasse facilement cette limite. Solution : traiter par lots de 20-30 produits avec des pauses, ou utiliser WP-CLI pour les imports batch en arrière-plan, sans passer par HTTP.
02
Le cache qui sert du contenu périmé
Vous venez de mettre à jour 100 descriptions produit via l'API. Le client vérifie, les pages affichent encore les anciennes versions. WP Rocket ou LiteSpeed Cache n'invalide pas automatiquement les pages produit mises à jour via REST. Il faut appeler wc_delete_product_transients() après chaque mise à jour, ou déclencher une purge de cache programmatique.
03
Les caractères spéciaux et l'encodage
GPT-4 peut retourner des guillemets typographiques, des tirets cadratins, des caractères Unicode rares. MySQL en utf8 (pas utf8mb4) rejette silencieusement certains caractères. Les apostrophes mal encodées cassent les requêtes SQL si le contenu n'est pas correctement échappé via wp_kses_post() avant insertion.
04
L'authentification REST qui expire
Make utilise un token d'application WordPress ou OAuth. Ces tokens peuvent expirer ou être révoqués lors d'une mise à jour de sécurité. Un flux qui tournait depuis 3 mois tombe en silencieux : les requêtes renvoient 401, Make marque les scénarios en erreur à 2h du matin, personne ne voit rien jusqu'à ce que le client remarque que ses fiches ne sont plus à jour.

Affichage dynamique : templates WooCommerce et logique conditionnelle

Générer et stocker les contenus IA, c'est la moitié du travail. L'autre moitié, c'est les afficher intelligemment. Si le contenu IA est dans un champ ACF ai_description, il ne s'affichera pas automatiquement sur la page produit. Il faut surcharger le template WooCommerce approprié.

La règle de base : copier woocommerce/templates/single-product/short-description.php dans votre thème enfant sous woocommerce/single-product/short-description.php, puis modifier le template pour qu'il affiche le champ ACF si rempli, et tombe en fallback sur la description native sinon. C'est un pattern propre qui reste maintenable lors des mises à jour WooCommerce.

Point de vigilance sur les mises à jour

Les templates surchargés dans le thème enfant ne se mettent pas à jour automatiquement avec WooCommerce. Après chaque mise à jour majeure de WooCommerce, vérifier si le template original a changé et adapter la surcharge en conséquence. C'est une tâche de maintenance récurrente, pas une configuration "one shot".

Conclusion : le flux IA est la partie simple

Construire un pipeline OpenAI avec Make prend une journée pour quelqu'un qui connaît l'outil. Préparer WordPress pour recevoir correctement le contenu, afficher les données dynamiquement, gérer les erreurs, maintenir les templates et surveiller les imports en production : c'est 3 à 5 jours de dev WP selon la complexité du catalogue.

La bonne façon d'estimer ce type de mission : séparer "build du flux IA" et "intégration WP/WooCommerce" en deux postes distincts. Le premier est souvent plus court que prévu. Le second est presque toujours plus long.