Intégrations : faire entrer ses commandes sans les retaper
Quatre façons de faire entrer une commande dans une plateforme COD : boutique connectée, feuille de calcul, webhook ou API. Laquelle choisir, et quoi vérifier ensuite.
L'essentiel
- Qu'est-ce que c'est ?
- Une intégration relie la source de vos commandes à votre espace de gestion : la commande arrive seule, avec le nom du client, son téléphone, sa ville et les articles. Sur CODFamilia, quatre voies existent — une boutique connectée, une feuille de calcul, un webhook, ou l'API — et toutes aboutissent au même endroit : un lead prêt à être appelé.
- Pour qui ?
- Tout vendeur qui reçoit plus de quelques commandes par jour, quelle que soit la façon dont il les récolte : boutique YouCan, page d'atterrissage avec formulaire, messages privés reportés dans un tableur, ou application maison. Le choix de la voie dépend moins du volume que de l'outil déjà en place.
- Comment ça marche ?
- La source transmet la commande, la plateforme en lit les champs, les compare à ce qu'elle attend — un SKU connu, un téléphone marocain valide, une ville reconnue, un total cohérent — puis crée un lead. Si quelque chose ne colle pas, la commande devient un « lead endommagé » à corriger, jamais une commande perdue.
- À quoi ça sert ?
- Pour deux raisons mesurables : le temps et l'exactitude. Chaque minute passée à recopier une commande est une minute qui n'a pas servi à appeler un client, et une adresse ou un chiffre recopié à la main est une adresse ou un chiffre qui finit parfois faux — donc un colis qui revient.
- Comment s'en servir ?
- On choisit la voie la plus proche de l'existant : une boutique YouCan se connecte en quelques clics, un formulaire qui écrit dans une feuille de calcul se branche sur cette feuille, un site maison envoie ses commandes par webhook ou par l'API. Les pages ci-dessous détaillent chaque voie, procédure comprise.
Une intégration est le chemin par lequel une commande passe de l'endroit où elle a été prise — boutique en ligne, formulaire, feuille de calcul — jusqu'à la file de confirmation de la plateforme, sans qu'une personne la retape.
Ce que coûte vraiment la ressaisie des commandes
Recopier une commande prend entre une et deux minutes : ouvrir la notification de la boutique, lire le nom, le téléphone, la ville, l'article, puis les écrire ailleurs. À trente commandes par jour, c'est une heure de travail qui ne produit rien — une heure qui n'a servi ni à appeler un client, ni à régler un retour, ni à relancer un colis bloqué.
Le second coût est plus sournois. Un numéro de téléphone recopié à la main est faux de temps en temps : un chiffre inversé, un zéro oublié, une ligne décalée dans le tableur. Le lead semble parfait, l'agent appelle, personne ne répond, et la commande part en « injoignable » alors que le client attendait son colis. Le même phénomène touche l'adresse et le total : un total mal recopié donne une discussion avec le livreur, puis un refus.
C'est la raison d'être d'une intégration : elle ne rend pas le travail plus rapide par principe, elle supprime une source d'erreurs dont on ne voit jamais la trace. Un numéro transmis par la boutique est le numéro que le client a écrit lui-même. S'il est faux, il est faux à la source — et cela, au moins, se corrige à l'appel.
Les quatre façons de faire entrer une commande
Les quatre voies ne se classent pas de la pire à la meilleure : elles répondent à des situations différentes. Le bon critère est simple — quelle est la source réelle de vos commandes aujourd'hui, et qui peut toucher à du code chez vous.
| Voie d'entrée | Convient à | Ce qu'elle demande |
|---|---|---|
| Boutique connectée | Un vendeur qui a déjà une boutique en ligne | Quelques clics d'autorisation, puis des SKU identiques des deux côtés |
| Feuille de calcul | Un formulaire, une page d'atterrissage, des commandes notées à la main | Une feuille partagée et des colonnes reliées une fois |
| Webhook entrant | Un site ou un outil capable d'appeler une adresse à chaque commande | Une URL à coller dans l'outil d'origine, un secret partagé |
| API | Une boutique sur mesure, une application mobile, un outil interne | Quelqu'un qui écrit du code et une clé API |
La correspondance des champs, l'étape qu'on ne peut pas sauter
Une commande qui arrive d'ailleurs n'a aucune raison de porter les mêmes noms de champs que la plateforme. Une boutique appelle « full_name » ce qu'une autre appelle « nom_client » et une feuille « Client ». Avant de pouvoir devenir un lead, la commande doit donc être lue : chaque champ reçu est relié une fois au champ correspondant de la plateforme, et ce réglage est ensuite réutilisé pour toutes les commandes suivantes.
La plateforme propose cette correspondance toute seule, en comparant les noms reçus à une liste de mots connus en français comme en anglais, et en écartant les faux amis — « Product name » ne doit pas devenir le nom du client, « Total quantity » ne doit pas devenir le prix total. La proposition se corrige d'un clic. Cinq champs doivent impérativement être reliés, les autres sont facultatifs.
- Nom du client — Obligatoire. Sans nom, l'agent ne sait pas qui il appelle.
- Téléphone — Obligatoire, et contrôlé : un numéro qui n'est pas un mobile marocain valide bloque le lead.
- SKU du produit — Obligatoire. C'est le seul lien entre l'article de votre boutique et le produit du catalogue.
- Prix total client — Obligatoire : c'est le montant que le livreur doit encaisser.
- Ville et adresse — Facultatifs au moment de l'import, mais une ville absente ou inconnue sera tranchée pendant l'appel de confirmation.
Doublons, leads endommagés et commandes qui n'arrivent nulle part
Trois incidents reviennent chez tous les vendeurs qui branchent une source de commandes. Les connaître à l'avance évite d'accuser l'intégration d'avoir perdu une vente qu'elle a en réalité mise de côté.
- La même commande reçue deux fois — Une boutique qui réessaie un envoi, une relecture qui repasse sur une commande déjà vue : l'identifiant de la commande d'origine est mémorisé, et un deuxième passage ne crée rien. Une ligne de feuille est reconnue par le contenu de ses colonnes reliées, ce qui produit le même effet.
- Deux commandes du même client — Même téléphone et même produit à quelques heures d'intervalle : ce n'est pas le même envoi reçu deux fois, c'est peut-être une vraie deuxième commande, ou un client qui a cliqué deux fois. Le lead est signalé comme doublon probable et attend un œil humain plutôt que d'être supprimé.
- Le lead endommagé — SKU inconnu, ville non reconnue, total incohérent, téléphone invalide : la commande entre quand même, dans une liste à part, avec le motif précis. Elle se corrige et devient un lead normal. C'est le mécanisme qui garantit qu'une intégration ne fait jamais disparaître une commande.
- La commande restée en attente — Elle existe, mais la correspondance des champs n'était pas encore enregistrée. L'écran de la connexion indique combien de commandes attendent, et le simple fait de relier les colonnes les libère.
La commande de vérification, à passer le jour du branchement
Une intégration qui « semble » marcher ne prouve rien tant qu'une commande ne l'a pas traversée en entier. La vérification prend cinq minutes et se fait une seule fois, le jour du branchement.
- Passer une commande réelle — Depuis la boutique, le formulaire ou la feuille, avec votre propre téléphone et une adresse que vous connaissez.
- Regarder l'écran de la connexion — Il doit afficher la dernière commande reçue, avec l'heure. S'il n'affiche rien, le problème est en amont : l'adresse du webhook, la clé, ou le partage de la feuille.
- Ouvrir le lead — Vérifier les quatre champs qui coûtent de l'argent quand ils sont faux : le téléphone, la ville, le total à encaisser et le bon article.
- Vérifier le SKU — Si le lead est parti dans les leads endommagés avec un SKU inconnu, c'est que la référence de votre boutique n'est pas celle du catalogue. Un SKU se corrige dans la boutique, pas dans la commande.
- Annuler le lead de test — Puis laisser passer la première vraie commande et refaire le même contrôle sur elle : c'est celle-là qui compte.
Questions fréquentes sur les intégrations
Faut-il savoir programmer pour brancher ses commandes ?
Quelle voie choisir quand on débute ?
Mes anciennes commandes vont-elles toutes remonter d'un coup ?
Que se passe-t-il si ma boutique envoie deux fois la même commande ?
Peut-on utiliser plusieurs sources en même temps ?
Une commande peut-elle être perdue en route ?
Les statuts repartent-ils vers ma boutique ?
Et pour les transporteurs ?
À lire aussi
- Connecter une boutique YouCan à sa gestion des commandes Relier une boutique YouCan à une plateforme COD : autorisation, commandes en temps réel, rôle du SKU, et quoi…
- Importer ses commandes COD depuis une feuille Google Sheets La feuille de calcul comme source de commandes : partage, colonnes à relier, lignes transformées en leads, li…
- Webhooks : envoyer ses commandes et recevoir les statuts Un webhook prévient un système dès qu'un événement se produit : envoyer ses commandes à une plateforme COD, r…
- L'API REST : piloter ses commandes COD depuis son code Créer et suivre des commandes en paiement à la livraison depuis son propre code : clé API, lecture du catalog…
Brancher sa source de commandes, puis ne plus y penser
Boutique, feuille de calcul, webhook ou API : les commandes arrivent seules dans la file de confirmation, avec un catalogue de 1 produits et une livraison dans 65 villes.
S'inscrire