Automatisation e-commerce par l'IA avec étapes de revue

Automatisez le passage de relais, pas seulement le prompt

Un workflow de contenu récurrent doit indiquer quel produit a changé, quelle révision de la source a été utilisée, ce qui reste à faire et qui peut publier. Un prompt planifié accompagné d'un CSV ne peut pas répondre seul à ces questions. Traitez le prompt comme une étape d'une tâche dont l'état est stocké en dehors de la conversation.

Commencez par du contenu exportable et une file de revue hors ligne. Donnez à chaque tâche un enregistrement durable et une action suivante explicite. Laissez les mises à jour réelles des produits désactivées jusqu'à ce que l'adaptateur de destination et les contrôles d'approbation aient été exercés dans une boutique contrôlée. Vous pourrez ainsi construire la génération et la revue avant d'ajouter les droits de publication.

Donnez à chaque tâche une identité stable

Utilisez la révision de la source, l'identifiant du produit, la locale, la révision du glossaire et la révision du prompt pour identifier le travail attendu. Une nouvelle tentative de la même tâche ne doit pas créer une candidate sans lien ou appliquer deux fois le même import. Un changement de source ou de règles doit créer un nouveau travail relié de façon visible à l'ancienne candidate.

Ne basez pas l'identité des tâches sur le numéro de ligne : le tri d'un export modifie les positions. Conservez les prix et les unités dans l'instantané source, mais n'autorisez la sortie générée que pour les champs textuels approuvés. L'enregistrement suivant est un contrat applicatif illustratif à adapter à votre stockage de tâches.

{
  "productId": "SYNTHETIC-CATALOG-A",
  "locale": "de",
  "sourceRevision": "source-revision-required",
  "glossaryRevision": "glossary-revision-required",
  "promptRevision": "prompt-revision-required",
  "state": "queued",
  "approval": null,
  "importReceipt": null
}

Persistez des transitions d'état observables

Stockez la sortie candidate avant de passer à la validation. Enregistrez les problèmes de validation avant d'affecter un relecteur. Liez l'approbation à la candidate et aux révisions exactes de la source. Le publisher doit refuser les enregistrements dont le contenu a changé après approbation, même si une version antérieure avait été acceptée.

Utilisez un état en attente pour les résultats ambigus. Par exemple, une perte de connexion pendant un import ne prouve pas que la boutique a refusé l'écriture. Rapprochez les champs actuellement stockés avant de réessayer. Implémentez les états proposés ci-dessous dans votre couche d'orchestration, avec les contrôles de transition à côté de l'opération qui persiste chaque résultat.

Séparez le client de modèle de l'adaptateur de boutique

Donnez au worker de rédaction uniquement le sous-ensemble de source approuvé et les identifiants du modèle. Placez les identifiants de la boutique dans un adaptateur distinct avec une opération limitée, comme la préparation d'un patch de description. La réussite d'une requête d'IA ne doit pas pouvoir publier un produit par effet de bord.

Shopify documente un parcours de traduction qui utilise un contenu propre à la ressource et des digests ; WooCommerce documente un importateur CSV de produits. Donnez à chaque interface son propre mapper et son étape de vérification. Configurez les identifiants du modèle dans le client de rédaction et conservez les lectures de source ainsi que les écritures autorisées de boutique dans l'adaptateur de destination. Testez ces limites séparément avant de réunir le workflow.

Limitez les nouvelles tentatives et isolez les mauvais enregistrements

Réessayez les défaillances temporaires de transport selon une politique finie et avec des tentatives enregistrées. Répéter une réponse structurellement invalide sans changer la cause peut gaspiller l'utilisation et le temps du relecteur. Gardez distinctes les catégories de défaillance : authentification, modèle indisponible, génération incomplète, champs invalides et contenu rejeté nécessitent des interventions différentes.

Laissez les enregistrements réussis disponibles tout en maintenant les autres en attente. Conservez toutes les tentatives du produit concerné, y compris les candidates qui ont échoué à la validation. Un redémarrage du worker doit reprendre depuis l'état persisté, et non régénérer tout le catalogue. Testez aussi l'annulation : arrêter la génération ne doit pas laisser silencieusement un processus d'import actif.

Mesurez le travail accepté et son coût complet

Associez les enregistrements d'utilisation à la tâche et à la tentative, y compris les requêtes échouées lorsqu'une preuve de facturation existe. Suivez séparément la rédaction, la revue et les appels de révision. Traitez l'utilisation manquante comme inconnue ; l'absence d'un reçu ne transforme pas une requête en requête gratuite. Gardez le temps d'édition séparé du registre API au lieu de mélanger des mesures différentes dans un seul nombre.

Définissez le travail accepté selon vos critères de mise en production, par exemple une révision produit-locale approuvée. Ne divisez les coûts enregistrés par le travail accepté que lorsque le dénominateur est non nul et que l'échantillon est clairement délimité. Utilisez les informations actuelles de facturation du fournisseur ou de la passerelle et conservez la date et la source de facturation avec le rapport.

Rapprochez les imports et préparez l'annulation

Créez une proposition d'import contenant uniquement les changements approuvés et enregistrez les anciennes valeurs de ces champs. Comparez de nouveau la révision de la source immédiatement avant une écriture autorisée. Si un autre éditeur a modifié le produit, mettez en pause et demandez une nouvelle revue au lieu d'écraser son travail.

Après l'import, relisez les champs concernés et classez les écarts par produit et par locale. Une annulation ne doit restaurer que les changements de ce lot lorsque la boutique correspond encore à la révision importée ; sinon, elle nécessite une revue de conflit. Gardez les droits d'import indépendants du droit de générer du texte.

Vérifiez un petit workflow qui inclut les échecs

Utilisez des produits synthétiques pour tester une candidate acceptée, une violation de champ protégé et un conflit dû à une source modifiée. Redémarrez le worker entre la rédaction et l'approbation. Vérifiez que le travail approuvé subsiste et que le travail en attente ne peut pas entrer dans une proposition d'import. Ces contrôles exercent le contrat d'état plus directement que des tests répétés de formulation du prompt.

Testez ensuite l'adaptateur dans une boutique de staging avec une autorisation explicite. Conservez l'instantané source, la révision générée, l'approbation, le reçu d'import et la comparaison de relecture. Une simulation locale établit seulement le comportement de l'orchestration ; elle ne permet pas d'établir la qualité du modèle ni la réussite d'une intégration boutique.

Questions fréquentes