Connecter son ERP à TikTok Shop avec l’API officielle : méthode

Relier un ERP à TikTok Shop ne consiste pas à exporter un fichier de produits une fois par semaine. Une vente peut modifier le stock en quelques secondes, déclencher une préparation, exiger un numéro de suivi, puis générer une annulation ou un retour. Sans circulation fiable de ces informations, le canal social crée vite des écarts de stock, des commandes oubliées et une comptabilité difficile à rapprocher.

L’API officielle de TikTok Shop est le canal technique à privilégier pour automatiser ces échanges. Elle permet, selon les droits accordés à l’application et le marché concerné, de dialoguer avec les ressources de boutique : produits, variantes, inventaire, commandes, expéditions, annulations, retours ou éléments financiers. Elle ne remplace ni l’ERP ni les règles commerciales du vendeur.

Le bon projet commence donc par une décision simple : quel système fait foi pour le prix, le stock, la commande et le remboursement ? Ce guide donne une méthode utilisable avec un ERP du marché ou développé en interne, des repères de budget et les obligations françaises à traiter avant la mise en production.

01 Ce que l’API TikTok Shop peut réellement automatiser

L’ERP doit rester le référentiel principal dès qu’il centralise déjà les achats, les entrepôts, les factures et les expéditions. TikTok Shop devient alors un canal de vente. L’intégration envoie vers la boutique les fiches autorisées, les prix et les quantités vendables ; elle ramène vers l’ERP les commandes et leurs évolutions. Cette séparation évite qu’un gestionnaire corrige un stock dans deux outils sans savoir lequel prévaut.

L’accès s’effectue depuis l’environnement partenaire ou vendeur de TikTok Shop, avec une application identifiée et une autorisation explicite de la boutique. Les opérations disponibles dépendent notamment du pays de vente, du type de compte, des catégories de produits, des autorisations demandées et des règles alors affichées dans la documentation officielle. Ne basez jamais un développement sur un tutoriel ancien ou sur des endpoints récupérés par observation du navigateur.

Les flux à prévoir dès le cahier des charges

Le flux catalogue est souvent le plus visible, mais le flux commande est le plus critique. Une variante vendue — taille, couleur, lot ou format — doit correspondre à une référence de stock non ambiguë dans l’ERP. L’expédition doit ensuite remonter avec le transporteur, le numéro de suivi et le statut attendu. Enfin, annulations, colis non distribués, retours et remboursements doivent corriger les stocks et les écritures sans intervention manuelle systématique.

02 Intégration directe ou connecteur : choisir l’architecture adaptée

Une intégration directe signifie que votre équipe, votre intégrateur ou votre éditeur développe un service qui appelle l’API officielle et dialogue avec l’ERP. Elle donne la maîtrise des règles de réservation, des taxes, des entrepôts et de la qualité des données. En contrepartie, vous devez assurer les mises à jour de l’API, la surveillance, les reprises sur incident et la sécurité des secrets d’accès.

Un connecteur, une place de marché d’intégrations ou une plateforme d’automatisation peut accélérer le démarrage. Il convient bien si vos flux sont standard : un entrepôt, un prix par SKU, une préparation simple et peu d’exceptions. Avant de le choisir, vérifiez que l’outil prend bien en charge TikTok Shop pour la France et vos flux précis ; la mention « compatible TikTok » ne garantit ni les retours, ni les bundles, ni les avoirs, ni la synchronisation multi-entrepôts.

Évitez la solution intermédiaire fragile : un script qui lit des e-mails de commande, un robot qui reproduit des clics ou une extraction non autorisée. Ces procédés ne disposent pas de garanties d’authentification, cassent à la moindre évolution d’interface et peuvent contrevenir aux conditions de la plateforme. L’API officielle apporte des autorisations traçables, des versions documentées et des mécanismes de notification.

03 Préparer les données ERP avant d’ouvrir les accès API

La plupart des échecs viennent d’un référentiel articles imparfait, pas de l’API. Avant toute connexion, chaque variante vendable doit avoir un SKU unique, stable et connu du stock. « T-shirt bleu » n’est pas une référence exploitable : il faut distinguer, par exemple, le bleu en taille M du bleu en taille L. Ne réutilisez pas un ancien SKU pour un nouveau produit, même si l’ancien est épuisé.

Définissez aussi l’origine de chaque champ. Le prix public consommateur, les promotions, la TVA, les délais de préparation, le poids et les dimensions de colis ne relèvent pas forcément du même service. Lorsque l’ERP ne porte pas une donnée obligatoire à la mise en vente, créez un enrichissement contrôlé dans un PIM ou dans une table dédiée, plutôt que de la saisir librement dans TikTok Shop.

La table de correspondance à documenter

Conservez une table de mapping versionnée. Elle relie l’identifiant interne de l’ERP à l’identifiant de produit et de variante attribué par TikTok Shop. Elle contient également les règles d’arrondi, les unités, les codes de statut et la date de dernière synchronisation. Ce document devient indispensable lorsqu’une fiche est recréée, qu’un produit est archivé ou qu’un incident exige de rejouer un flux.

Prévoyez une marge de stock pour absorber les écarts de synchronisation, les préparations en cours et les ventes réalisées sur d’autres canaux. Une réserve de 1 à 3 unités par SKU, ou de 2 % à 5 % sur les références à fort volume, est un point de départ prudent à ajuster à votre vitesse réelle de préparation. La bonne marge n’est pas celle qui maximise l’affichage de stock : c’est celle qui évite les annulations.

04 La procédure technique, de l’application au premier envoi

Le développement doit être conduit comme un projet d’échange de données, avec une recette métier, et non comme un simple branchement API. Désignez un responsable commercial, un responsable logistique, un référent comptable et un référent technique. Le premier valide les fiches et les prix ; le deuxième les expéditions ; le troisième le rapprochement ; le quatrième la sécurité, les erreurs et les mises à jour.

Les notifications, souvent appelées webhooks, évitent de demander en permanence si une commande a changé. Votre serveur reçoit l’événement sur une URL HTTPS, vérifie sa signature selon le mécanisme officiel, enregistre le message, répond rapidement puis confie le traitement à une file d’attente. Répondre après avoir créé la commande, décrémenté le stock et imprimé l’étiquette augmente le risque de délai et de doublon.

Prévoir les reprises sur erreur

Aucun échange réseau n’est infaillible. Conservez l’identifiant d’événement, l’identifiant de commande, l’heure de réception, le statut de traitement et le message d’erreur. En cas de limite de requêtes ou de panne temporaire, appliquez une temporisation progressive — par exemple une nouvelle tentative après 1 minute, puis 5, 15 et 60 minutes — plutôt que de relancer des centaines d’appels. Les limites effectives doivent toujours être lues dans la documentation et les réponses de l’API.

05 Fiabiliser stocks, commandes et sécurité au quotidien

Une intégration saine dispose d’un tableau de bord d’exception, pas seulement d’un voyant vert. Suivez les commandes non importées, les produits rejetés, les stocks négatifs, les expéditions non remontées, les remboursements sans écriture ERP et les appels échoués. Chaque alerte doit avoir un propriétaire et un délai de traitement. Pour un flux actif, une revue chaque matin et une alerte immédiate sur l’échec d’expédition sont raisonnables.

La réconciliation compare des totaux, mais aussi des lignes. Chaque jour, rapprochez le nombre de commandes, le total TTC, les annulations, les remboursements et les expéditions entre TikTok Shop, l’ERP et, si besoin, le logiciel comptable. Les montants versés par une plateforme ne sont pas automatiquement le chiffre d’affaires comptable : frais, commissions, promotions, taxes et remboursements doivent être analysés selon votre paramétrage et les pièces disponibles.

Sur le plan de la sécurité, limitez les comptes humains qui peuvent modifier l’application, les clés et les URL de notification. Activez l’authentification multifacteur lorsqu’elle est proposée, journalisez les changements de droits et faites tourner les secrets après le départ d’un prestataire ou au moindre doute. Les données de production doivent être séparées des jeux de test, anonymisés autant que possible.

06 RGPD, TVA et obligations vendeur en France

Une commande récupérée dans l’ERP contient généralement des données personnelles : nom, adresse de livraison, coordonnées de contact, historique de commande et parfois message client. Collectez uniquement les champs nécessaires à l’exécution de la vente, limitez les accès et fixez une durée de conservation. L’accès aux données n’autorise pas à les injecter automatiquement dans une liste de prospection : la finalité, l’information des personnes et la base légale doivent être examinées.

Documentez les rôles de chaque intervenant : vendeur, ERP, intégrateur, hébergeur, outil d’e-mail et transporteur. Le contrat avec un sous-traitant doit notamment encadrer les instructions, la sécurité, l’assistance et le sort des données. Si une violation de données personnelles présente un risque pour les personnes, le RGPD prévoit en principe une notification à l’autorité compétente dans les 72 heures après en avoir pris connaissance, sauf exception.

Pour une vente à distance à un consommateur, le délai de rétractation est habituellement de 14 jours à compter de la réception du bien, avec des exceptions légales, par exemple pour certains produits nettement personnalisés. Votre ERP doit distinguer la demande de retour, la réception physique, le contrôle du produit et le remboursement effectif. Cette granularité réduit les erreurs de stock et permet de justifier les mouvements auprès du service client et de la comptabilité.

07 Quand faire appel à un intégrateur et comment faire durer le projet

Un prestataire spécialisé devient pertinent si vous avez plusieurs entrepôts, des lots ou bundles, des commandes dépassant régulièrement 50 à 100 par jour, plusieurs pays, des règles de TVA complexes ou un ERP ancien sans API moderne. Il est également utile si votre équipe ne sait pas surveiller un service, gérer les jetons d’accès ou reprendre une file d’erreurs. Exigez une démonstration sur vos cas réels, notamment un retour et une rupture de stock.

Le livrable ne doit pas se limiter au code. Demandez une documentation de mapping, un schéma d’architecture, une procédure de mise en production, une procédure de secours, les journaux accessibles, des indicateurs d’écart et la liste des responsabilités. Convenez aussi d’un délai de correction : par exemple, prise en charge d’un blocage de commandes sous 4 heures ouvrées et correction d’une anomalie non bloquante sous 5 à 10 jours ouvrés, selon votre contrat.

Le critère de réussite n’est pas seulement le nombre de produits publiés. C’est la capacité à retrouver, pour une commande donnée, son article, son stock, son paiement, son expédition, son retour éventuel et son écriture de rapprochement. Si vous pouvez expliquer cet enchaînement en moins de cinq minutes sur une commande de test, votre connexion est probablement exploitable ; sinon, réduisez le périmètre et corrigez le flux avant d’augmenter les volumes.