Un des pièges les plus frustrants des outils d'enrichissement en masse : tu lances un traitement sur 800 produits, tu fermes ton onglet par réflexe pour aller déjeuner, et à ton retour... rien ne s'est passé. Le traitement s'est arrêté net parce qu'il tournait dans ton navigateur. pshly.ai a été conçu pour éviter exactement ce scénario : chaque traitement groupé s'exécute côté serveur, indépendamment de ta connexion.
Pourquoi le traitement côté client est un problème
Beaucoup d'outils SaaS traitent les opérations en masse directement dans le navigateur de l'utilisateur : une boucle JavaScript qui appelle l'API produit par produit tant que l'onglet reste ouvert. Ça fonctionne pour de petits volumes, mais dès que tu dépasses quelques dizaines de produits, le moindre rafraîchissement de page, la moindre perte de connexion Wi-Fi, ou simplement la fermeture accidentelle de l'onglet interrompt tout le traitement — parfois en plein milieu, avec des produits à moitié enrichis.
Comment fonctionne un job côté serveur
Chez pshly.ai, dès que tu lances un enrichissement en masse — que ce soit sur les descriptions, les métachamps, les images ou les collections — l'opération est enregistrée comme un job en base de données et exécutée par des workers serveur. Ton navigateur ne fait plus que consulter l'état du job, il ne le pilote plus. Tu peux fermer l'onglet, éteindre ton ordinateur, changer de réseau : le job continue de traiter tes produits un par un jusqu'à la fin.
Progression en temps réel
Quand tu rouvres ton tableau de bord, tu retrouves une barre de progression qui reflète l'état réel du job côté serveur, pas une estimation locale. Elle affiche le nombre de produits traités, restants, et le taux de réussite. Sur un job de 500 produits, tu vois par exemple 340/500 traités avec 12 échecs identifiés, mis à jour en continu sans avoir à rafraîchir la page manuellement.
Journaux de job pour comprendre chaque échec
Chaque job garde un journal détaillé, produit par produit. Si un enrichissement échoue — une image introuvable, une réponse IA rejetée, une contrainte Shopify non respectée — le journal indique exactement quel produit a échoué et pourquoi. Tu n'as jamais à deviner ce qui s'est mal passé sur les 12 produits en échec au milieu de 500 réussites.
Retry automatique et gestion des erreurs transitoires
Certaines erreurs sont transitoires : une limite de taux API atteinte, un timeout réseau ponctuel. Le système applique un retry automatique avec backoff pour ces cas, avant de marquer un produit comme réellement en échec. Cela réduit sensiblement le taux d'échec final sur les gros volumes, sans intervention de ta part.
Dédoublonnage des item-ids
Si tu relances un job sur une sélection qui recoupe partiellement un job déjà en cours ou terminé, pshly.ai déduplique automatiquement les item-ids. Un même produit n'est jamais traité deux fois par erreur au sein d'une même file, ce qui évite à la fois une consommation de crédits inutile et des résultats incohérents en cas de traitements qui se chevauchent.
Une file d'attente qui absorbe la charge
Quand plusieurs jobs sont lancés en parallèle — par exemple un enrichissement de métachamps sur une collection et une génération d'images sur une autre — ils entrent dans une file d'attente commune. Le système répartit la charge sans bloquer ton interface, et sans qu'un job monopolise toutes les ressources au détriment des autres. Tu peux ainsi lancer plusieurs traitements successifs sans attendre que le précédent se termine pour démarrer le suivant.
Ce que ça change concrètement
En pratique, cela veut dire que tu peux lancer un enrichissement sur 2000 produits un vendredi soir avant de partir, et retrouver le lundi matin un job terminé, avec un journal complet des succès et des échecs à traiter. Aucun outil qui dépend du navigateur ne peut offrir cette garantie. Pour plus de détails techniques sur le fonctionnement des jobs groupés, consulte la documentation du workflow groupé.
Ce qu'un traitement complet apporte en pratique
Chez G&F Verpakkingen, le premier grand nettoyage a pris la forme de trois traitements groupés successifs : titres, meta descriptions et métachamps pour 512 produits. Au total, plus de 3 500 champs qui auraient sinon été remplis à la main — environ 120 heures de travail. Les traitements tournaient en arrière-plan pendant que l'équipe poursuivait ses autres tâches ; seule la relecture demandait une attention réelle. Dans les semaines suivant la publication, le trafic organique a augmenté de 34 %. L'enjeu n'est pas que l'IA tape plus vite, mais que le délai d'une amélioration à l'échelle du catalogue passe de mois à jours.
Comment découper un grand traitement
Au-delà de mille produits, un ordre fixe fonctionne le mieux : d'abord les titres, puis les handles, puis les meta descriptions, puis les métachamps. Chaque étape s'appuie sur la précédente, si bien que le handle suit toujours le titre définitif. Lancez chaque étape sur une sélection de cinquante produits, contrôlez la relecture, puis seulement mettez le catalogue complet en file d'attente. Vous repérez ainsi les anomalies de vos données sources avant de dépenser des crédits sur des milliers de produits.
Teste ce fonctionnement dès maintenant : démarre gratuitement et lance ton premier traitement groupé sans craindre de fermer ton navigateur.