Intégration API pour les entreprises en France et en Belgique

Source des données, sens des flux et responsabilité de l’acceptation

L’objectif d’une intégration n’est pas simplement d’ouvrir une connexion entre deux applications : il faut déterminer quel système fait référence pour chaque information. Le nom du produit peut être géré dans le catalogue, le stock disponible dans l’ERP et le statut de livraison chez le transporteur. Ces sources mettent à jour les mêmes données à des moments différents. Établir une connexion bidirectionnelle sans préciser, pour chaque champ, la source de référence, le sens du transfert et le délai acceptable peut amplifier les incohérences.

Nous commençons par cartographier les flux de données. La réception, la confirmation, l’expédition et la facturation d’une commande sont des événements distincts. Quelles étapes de cette chaîne une annulation ou un retour partiel modifie-t-il ? Comment une correction effectuée dans le système source doit-elle être répercutée dans le système cible ? L’automatisation ne supprime pas les situations qui nécessitent une décision humaine ; elle peut les orienter vers une file de vérification visible.

Votre équipe opérationnelle doit pouvoir repérer les transferts en échec. Une réponse positive ne suffit pas à prouver que l’enregistrement a été correctement traité par le système destinataire. L’identifiant de l’opération, le numéro du document cible et les résultats du rapprochement sont examinés ensemble. Lors de la création d’un site e-commerce ou de l’ajout d’une intégration à une infrastructure existante, la responsabilité des données est définie avec la même attention.

Correspondance des catalogues et des commandes sur les marketplaces

Pour connecter une marketplace, nous examinons l’accès à son API vendeur, les droits du compte et les limites d’utilisation en vigueur. Citer Amazon ou les plateformes turques Trendyol, Hepsiburada, N11 et Pazarama ne signifie pas que toutes les données peuvent être transférées. Les catégories et les attributs obligatoires peuvent varier d’un canal à l’autre. La création d’une fiche produit unique ne repose donc pas sur l’hypothèse qu’elle aura partout la même signification.

Correspondance du catalogue et des stocks

Une table de correspondance est préparée entre les références de stock, les codes-barres et les identifiants de variantes. Si les conditionnements ou les couleurs d’un produit sont mal associés, la mise à jour du stock sera appliquée à la mauvaise offre. Les produits supprimés, les offres désactivées et les catégories refusées apparaissent comme des situations distinctes. Pour les règles de prix propres à chaque canal, les hypothèses de commission, de fiscalité et d’arrondi sont validées par votre entreprise.

Commandes et statuts du canal

Une commande peut être reçue plusieurs fois avec le même identifiant externe. L’enregistrement du transfert conserve cet identifiant : une nouvelle récupération des données ne doit pas créer une deuxième commande. Une expédition partielle, une demande d’annulation et un retour ne sont pas réduits à un simple indicateur « terminé ». Lorsque la marketplace refuse une facture ou des informations de suivi, votre équipe opérationnelle doit pouvoir identifier l’étape à laquelle le traitement s’est arrêté.

Pour un catalogue standard, l’interface d’un prestataire d’intégration existant peut suffire. Une interconnexion sur mesure est envisagée lorsque l’entreprise prend ses décisions dans son propre logiciel métier ou applique des règles différentes selon les entrepôts et les revendeurs. La prise en charge d’un canal n’est pas confirmée avant examen de la documentation du fournisseur et de l’accès aux tests. Le périmètre du projet est défini par les opérations autorisées, plutôt que par le seul nom du système.

Distinguer l’étiquette d’expédition du statut de livraison

La création d’une expédition et la remise du colis au transporteur sont deux événements distincts. La génération d’une étiquette ne signifie pas que la commande a été livrée. Le nombre de colis, le poids, le poids volumétrique exprimé en desi dans le contexte turc, l’adresse et le type de service sont convertis en une demande d’expédition. L’identifiant externe de l’enregistrement et le résultat de la création sont conservés pour éviter de générer une deuxième expédition si la même commande est retraitée.

Chez des transporteurs turcs tels que Yurtiçi Kargo, Aras Kargo, MNG Kargo, PTT Kargo et Sürat Kargo, les conditions d’accès dépendent du compte et du contrat concernés. Nous examinons la documentation des services et les autorisations avant de commencer. Nous ne supposons pas que tous les transporteurs proposent les mêmes statuts de livraison ou les mêmes opérations de retour. Leurs statuts sont mis en correspondance avec ceux des commandes de votre entreprise ; un code inconnu n’est pas assimilé silencieusement à une livraison effectuée.

• Les numéros de suivi d’une commande comportant plusieurs colis sont conservés ensemble.
• L’annulation d’une étiquette et sa réimpression sont traitées séparément.
• L’expédition de retour est reliée à l’expédition initiale.
• Les erreurs d’adresse sont orientées vers une vérification opérationnelle.

Pour l’impression d’étiquettes par lots, nous déterminons si un enregistrement en échec doit ou non bloquer les autres commandes. En fin de journée, les expéditions créées peuvent être comparées à celles effectivement prises en charge par le transporteur. Lorsqu’une notification de suivi est transmise au client, sa date et sa source sont prises en compte : une notification tardive ne doit pas ramener la commande à un état antérieur.

Rapprochement des documents ERP et des comptes clients et fournisseurs

Pour une connexion à un ERP, nous examinons d’abord l’interface officielle proposée par le logiciel de comptabilité et les droits d’utilisation associés. Pour des logiciels utilisés en Turquie tels que Logo, Netsis, Nebim, DIA, AkinSoft ou Uyumsoft, les possibilités d’accès varient selon les versions et les modules. La présence du nom d’un logiciel dans une liste ne signifie pas que tous les flux envisagés sont techniquement réalisables. Pour les installations fonctionnant sur un serveur local, le besoin d’un service intermédiaire sécurisé peut être étudié.

La correspondance des comptes clients et fournisseurs, des références de stock, des champs fiscaux et des types de documents est établie avec les équipes comptables et opérationnelles. Si un même client possède plusieurs fiches, nous déterminons laquelle utiliser. Une simple ressemblance entre les noms ne suffit pas à établir automatiquement une identité. Les règles de date, de devise, de conversion des unités et d’arrondi sont testées sur des documents représentatifs.

Lorsque l’ERP accepte la création d’un enregistrement, l’identifiant du document est conservé. Une correction ultérieure nécessite-t-elle un nouveau document, une révision ou une contrepassation ? Cette décision est prise en tenant compte des méthodes prises en charge par le logiciel. L’écriture directe dans la base de données n’est pas considérée comme un raccourci acceptable sans l’accord de l’éditeur. Les opérations spécifiques de votre entreprise peuvent être exécutées dans un logiciel sur mesure, tout en conservant le système de référence pour les enregistrements officiels.

Le rapport de rapprochement joue un rôle important lors de la transition et dans l’exploitation quotidienne. Les commandes confirmées dans la source mais non acceptées par l’ERP, les écarts de montant et les fiches sans correspondance restent visibles. Après correction du problème, votre équipe opérationnelle peut effectuer un retraitement sécurisé ; aucune répétition à l’aveugle susceptible de créer un document en double n’est appliquée.

De l’envoi E-Fatura à l’acceptation du document en Turquie

L’intégration de la facturation électronique turque E-Fatura repose sur l’API et le circuit documentaire pris en charge par le prestataire d’intégration avec lequel vous travaillez. Le statut fiscal du destinataire, le type de document, les champs fiscaux et les informations du destinataire sont vérifiés avant l’envoi. Le logiciel ne présume pas des décisions qui doivent être validées par votre équipe comptable. Les obligations légales en vigueur et les scénarios documentaires doivent être confirmés avec votre expert-comptable ; l’intégration technique ne remplace pas une analyse juridique et ne garantit pas la conformité.

Le brouillon de facture, l’envoi au prestataire d’intégration, l’acceptation et la transmission au destinataire sont des états distincts. Renvoyer le même document dans l’attente d’une réponse peut entraîner une opération en double. L’identifiant du document est associé au résultat du prestataire ; en cas d’incertitude, son état est interrogé. L’interface d’administration ne doit pas afficher uniquement un message de réussite ou d’échec : elle doit indiquer à quelle étape le traitement est en attente.

L’annulation, la contestation et le retour partiel sont organisés selon les règles du type de document utilisé. Le statut commercial de la commande ne doit pas être confondu avec le statut juridique de la facture. L’accès aux documents, leur archivage et les personnes autorisées à consulter les fichiers sont définis dans le cadre des responsabilités de votre organisation. Lors de la recette, les montants, les taxes, les devises et les liens entre documents sont comparés à partir d’enregistrements représentatifs.

Vérifier le résultat d’un paiement de manière fiable

Dans une intégration de paiement, le retour du navigateur ou de l’application mobile vers un écran de confirmation ne constitue pas, à lui seul, une preuve d’encaissement. Le résultat est rapproché de la réponse vérifiée du prestataire et d’une interrogation de l’opération. L’identifiant de transaction, le montant, la devise et le lien avec la commande sont contrôlés. La vérification des notifications signées et le traitement idempotent des notifications répétées sont des principes fondamentaux de la conception.

Pour un terminal de paiement virtuel bancaire ou des prestataires turcs comme iyzico et PayTR, le compte marchand, le contrat et les droits d’utilisation sont des prérequis. La disponibilité d’options internationales telles que Stripe et PayPal est étudiée séparément selon le pays de l’entreprise et la structure de son compte ; nous ne les présentons pas comme accessibles à toutes les entreprises en Turquie. Le paiement en plusieurs fois, les abonnements et les remboursements sont inclus dans le périmètre selon les conditions réelles du prestataire.

Plutôt que de stocker les données de carte, nous étudions les méthodes de paiement hébergées ou reposant sur des jetons proposées par le prestataire. La relation entre le résultat de 3D Secure et la confirmation de la commande est explicitée. En cas d’expiration du délai d’attente, l’état de la première tentative doit être vérifié avant d’inviter l’utilisateur à payer de nouveau. Les remboursements partiels, les remboursements multiples et les remboursements en échec peuvent apparaître séparément dans l’interface d’administration des opérations.

La recette ne se limite pas aux paiements réussis. Les scénarios de carte refusée, d’authentification abandonnée, de notification tardive et de montant incorrect sont traités dans l’environnement de test. Celui-ci peut ne pas reproduire intégralement le système en production ; une vérification limitée en conditions réelles est donc planifiée avec un compte autorisé et dans un périmètre approuvé.

Gestion des erreurs dans les flux API, webhook et XML

Les API REST, les webhooks et les échanges de fichiers ont des comportements de transmission différents. Une réponse API renseigne sur une opération ; un webhook peut arriver en retard ou être renvoyé ; un fichier XML ne représente qu’un instantané au moment de sa création. Le choix de la méthode dépend de la fréquence de modification des données et des possibilités offertes par le système destinataire. Plutôt que de parler de transfert « instantané », nous définissons un intervalle de transfert mesurable et un délai acceptable.

La même stratégie de nouvelle tentative ne s’applique pas à toutes les erreurs. Un problème temporaire de connexion n’équivaut pas à une référence produit invalide. Renvoyer un enregistrement invalide sans le corriger ne fait qu’augmenter la charge. La file d’attente rend visibles l’identifiant de l’opération, le résultat de la tentative et la dernière erreur. La cadence d’envoi est ajustée pour respecter les limites de l’API ; une interruption du système destinataire n’est pas masquée comme une simple perte d’enregistrement.

Pour un transfert XML, nous contrôlons que le fichier est complet, ainsi que son encodage, le format des dates et la correspondance des produits. Un fichier vide ou tronqué ne justifie pas automatiquement la remise à zéro de tous les stocks. Les règles de suppression des données et de modification en masse sont définies séparément. Pour les systèmes internes sans documentation, un développement d’API sur mesure peut être étudié ; les droits d’accès et la responsabilité des données restent des prérequis.