Décidez qui a le dernier mot.
Le prix vient-il de la boutique ou de l’ERP ? Le stock affiché inclut-il les réservations ? Quand une adresse client change, quel système doit écraser l’autre ? La réponse varie selon l’entreprise ; elle ne doit jamais dépendre d’une règle implicite cachée dans du code.
Écrivez une matrice courte : donnée, système maître, sens du flux, fréquence et personne responsable. Prenez les cas qui font mal : prix négociés, stock à zéro, annulation, remboursement, nouveau client sans identifiant. Si personne ne peut arbitrer une contradiction, le connecteur la reproduira plus vite.
Un nouvel essai ne doit pas créer un nouvel événement métier.
Les réseaux coupent, les serveurs ralentissent, les réponses se perdent. Réessayer est normal. Créer deux commandes, deux factures ou deux e-mails ne l’est pas. Pour chaque action sensible, prévoyez un identifiant stable que les deux côtés peuvent reconnaître. Si la même opération arrive deux fois, le résultat doit être le même, ou le second envoi doit être refusé proprement.
Demandez à voir le scénario exact dans la recette : couper la réponse après l’enregistrement, relancer, puis vérifier l’état du site et de l’ERP. Ce test vaut davantage qu’une démonstration où tout circule dans l’ordre.
Une erreur silencieuse devient une tâche humaine cachée.
Une ligne « échec 500 » dans un journal technique n’aide pas la personne qui prépare les commandes. Il faut savoir quelle opération est bloquée, depuis quand, si elle sera rejouée automatiquement et à qui demander une décision. Un tableau de suivi simple suffit souvent : en attente, traité, à reprendre, rejeté avec motif.
Les alertes doivent être proportionnées. Un ralentissement de quelques secondes n’a pas la même gravité qu’un paiement encaissé sans commande transmise. Définissez le seuil, le canal et la personne de permanence avant la mise en ligne.
- La même commande est reçue deux fois.
- Le système distant ne répond plus pendant une heure.
- Un prix ou un stock change pendant le panier.
- Une correction manuelle doit être rejouée sans doublon.
Ce qui doit apparaître dans un devis de connecteur.
Un devis utile nomme les systèmes et leurs versions, les données échangées, les règles métier, la fréquence des flux, les cas d’erreur, les journaux consultables, les tests, la documentation et la période de surveillance après lancement. Il dit aussi ce qui n’est pas inclus : nettoyage de données, modification de l’ERP, historique ancien ou nouveaux transporteurs, par exemple.
Le prix dépend surtout de ces décisions et de la qualité des API disponibles. Chez Dollen, le cadrage de développement et de connecteurs commence à 1 200 € HT ; le développement est chiffré après examen du périmètre. La première étape peut donc être un schéma des flux et une liste des exceptions, avant toute ligne de code.
Notre guide du connecteur e-commerce détaille la méthode de cadrage. La réalisation Reflectiv montre un projet réel de commerce connecté, sans prétendre que son architecture convient telle quelle à votre activité.