Intégration de la livraison au CRM : quelles données transitent et comment configurer l'échange

Ce qui casse quand le CRM et la livraison vivent chacun de son côté

Le CRM gère la relation client : c'est là que vivent les affaires, les contacts, les engagements sur les délais et le paiement. Le système de gestion des livraisons gère l'exécution : qui part, dans quel ordre, et par quoi la prestation est attestée. Tant que ces deux circuits ne sont pas reliés, un humain se tient entre les deux et recopie les données à la main — et le prix de cette recopie ne se compte pas seulement en temps passé.

Les conséquences habituelles de cette rupture ressemblent à ceci :

• Double saisie et coquilles. Une adresse tapée une seconde fois est une adresse qui a toutes ses chances d'être fausse. L'intervenant part au mauvais endroit, et le problème se règle une fois sur le terrain.
• Statuts en retard. Le commercial ne voit pas ce qu'il advient de la commande et répond au client « je me renseigne » au lieu de donner une réponse précise. Chacune de ces vérifications est un appel au dispatcheur.
• Commandes perdues. L'affaire est passée à l'étape « transmise à la livraison », mais n'est jamais arrivée jusqu'au dispatcheur : personne ne l'a remarqué avant l'appel du client.
• Reporting qui ne tombe pas juste. Le CRM annonce un nombre d'expéditions, le système opérationnel un autre, et seul un collaborateur à la très bonne mémoire des détails sait expliquer l'écart.

L'intégration supprime cette couche manuelle : la commande apparaît chez le dispatcheur au moment où l'affaire atteint l'étape prévue, et le résultat de l'exécution revient dans la fiche client sans que personne ait à le raconter. Tout le reste — notifications, analytique, confort des interfaces — se construit par-dessus cet échange de base. C'est pourquoi il vaut mieux concevoir l'intégration en partant de la question « quels faits doivent circuler, et dans quel sens » plutôt que de « sur quels boutons faut-il appuyer ».

Quelles données circulent entre le CRM et le système de livraison

L'échange est presque toujours bidirectionnel, et il est utile de le décrire par deux listes courtes : ce qui sort du CRM et ce qui revient. Du CRM vers le système de livraison, on transmet en général :

• la demande ou la commande : numéro, type de prestation, contenu, commentaire du commercial ;
• l'adresse d'exécution avec les précisions d'accès — bâtiment, étage, badge, qui appeler sur place ;
• les coordonnées du destinataire et le créneau horaire convenu ;
• le montant et le mode de paiement, si l'intervenant encaisse ;
• l'indicateur d'urgence ou de priorité — pour que le dispatcheur voie ce qui ne peut pas attendre demain.

En retour, du système de livraison vers le CRM, ce sont les faits d'exécution qui remontent :

• l'intervenant affecté et l'heure d'arrivée estimée ;
• les statuts : pris en charge, en route, sur place, réalisé, non réalisé ;
• le motif de non-réalisation choisi dans une liste fermée — refus, injoignable, adresse introuvable, report à la demande du client ;
• les justificatifs : rapport photo, signature du destinataire, heure et lieu du pointage ;
• l'encaissement effectué sur place, s'il a été réalisé par l'intervenant.

Il faut par ailleurs s'accorder sur les référentiels clients et adresses. S'ils sont alimentés des deux côtés, les doublons apparaîtront dès le premier mois : « Dupont Services » et « Services Dupont » deviendront deux fiches à l'historique distinct, et le moindre rapport par client devra être reconstitué à la main. Plus simple : désigner un système propriétaire du référentiel et l'autre consommateur.

Une astuce pratique qui épargne des semaines d'échanges de mails : avant de commencer, listez les champs dans un tableau à quatre colonnes — nom dans le CRM, nom dans le système de livraison, sens de l'échange, que faire quand la valeur est vide. Ce document d'une page constitue, en pratique, le cahier des charges de l'intégration.

Les modes d'échange : API, webhooks et export par fichier

Techniquement, plusieurs voies permettent de relier les systèmes. Le choix ne dépend pas de la mode, mais du degré de fraîcheur exigé des données et des possibilités offertes par votre CRM.

• Échange par API. Les systèmes s'appellent directement l'un l'autre. C'est l'option la plus souple : n'importe quel jeu de champs peut circuler et la logique reste entièrement sous contrôle. En contrepartie, elle demande du paramétrage et une idée claire de la méthode appelée à chaque événement.
• Webhooks. Le CRM signale de lui-même le passage de l'affaire à l'étape voulue, et le système de livraison signale chaque changement de statut. Les données se mettent à jour presque instantanément et sans interrogations répétées, mais il faut prévoir les nouvelles tentatives dès le départ : si le destinataire était indisponible, l'événement ne doit pas disparaître sans laisser de trace.
• Export par fichier. Les commandes partent par lots selon un calendrier, depuis un tableur par exemple. C'est le démarrage le plus rapide : aucun développement n'est nécessaire, et cela convient quand les commandes sont bouclées pour le matin et bougent peu dans la journée.
• Connecteur intermédiaire. Un service passerelle dédié réconcilie les formats et conserve les correspondances et les règles. Il se justifie quand la source n'est pas unique : une partie des demandes vient du CRM, une autre du système comptable, une autre encore du formulaire du site.

Il n'y a pas de réponse universelle, mais un repère simple existe. Si le client attend son statut le jour même et que le commercial reçoit des appels du type « où en est ma commande », il faut un échange événementiel. Si le flux se constitue la veille et reste stable, l'export par fichier suffit, et il ne vaut la peine de le complexifier que le jour où apparaît un cas concret qu'il ne résout plus.

itlogist prend en charge les intégrations avec AmoCRM, Bitrix24, 1C et Excel : les commandes entrent en production depuis la source habituelle, sans ressaisie. Ce qui leur arrive ensuite — la répartition entre les intervenants, les tournées sur la carte en temps réel, l'application mobile de l'intervenant avec rapports photo et check-lists, l'espace client avec les statuts — est rassemblé sur la page Les fonctionnalités d'itlogist.

Source de vérité, clé de correspondance et traitement des erreurs

La plupart des problèmes d'intégration ne sont pas techniques, mais contractuels. Voici quatre questions dont les réponses déterminent si l'échange tournera sans surveillance quotidienne.

• La clé de correspondance. Sur quel champ la commande côté livraison est-elle rapprochée de l'affaire côté CRM : numéro d'affaire, identifiant interne, numéro de commande. La clé doit être unique, immuable et circuler dans les deux sens. Un rapprochement par téléphone ou par adresse s'écroule dès que le même client repasse commande.
• La source de vérité pour chaque champ. Qui fait autorité sur l'adresse, qui sur l'heure de livraison, qui sur le montant. Si le commercial a modifié le créneau dans le CRM et le dispatcheur dans le système de livraison, ce n'est pas celui qui a cliqué en dernier qui doit l'emporter, mais celui que la règle désigne.
• Un modèle de statuts unique. Les étapes du pipeline dans le CRM et les statuts d'exécution sont deux choses différentes. Il faut une table de correspondance explicite : quel statut opérationnel fait passer l'affaire à quelle étape, et quelles transitions sont interdites. Sans cela, l'affaire se mettra à reculer à chaque nouvelle tentative de livraison.
• Le comportement en cas d'erreur. Que se passe-t-il si l'adresse est vide, si le client est introuvable ou si le destinataire n'a pas répondu. Le scénario qui fonctionne : la commande n'est pas perdue en silence, elle rejoint une file d'attente de reprise ou une liste à traiter manuellement, et quelqu'un est responsable de cette liste.

Deux points encore, auxquels on pense trop tard. Le premier : un renvoi ne doit pas créer de doublon ; si l'événement arrive deux fois, la seconde tentative doit mettre à jour la commande existante, pas en créer une autre. Le second : les droits d'accès. Le compte d'intégration ne voit et ne modifie que ce qui est nécessaire à l'échange, et son accès n'est pas rattaché à un collaborateur précis qui partira un jour avec son mot de passe.

Ordre de déploiement : d'un seul scénario au flux complet

Mieux vaut ne pas lancer l'intégration sur toute sa largeur d'emblée. La séquence qui marche est la suivante, et elle tient d'ordinaire en quelques itérations courtes.

• Décrivez un scénario de bout en bout. Prenez le type de commande le plus fréquent et suivez-le depuis l'étape dans le CRM jusqu'au pointage de réalisation. Les cas particuliers — retours, refus partiels, seconds passages — s'ajoutent dans un deuxième temps.
• Validez la table de correspondance des champs. Ce fameux tableau à quatre colonnes. Tant qu'il n'est pas signé par les deux parties, il est trop tôt pour paramétrer.
• Mettez de l'ordre dans les données. Adresses normalisées, téléphones à jour, consignes d'accès. L'intégration accélère aussi la transmission des déchets : une mauvaise adresse arrivera simplement plus vite chez l'intervenant.
• Testez sur un flux d'essai. Une dizaine de commandes dans les deux sens, y compris volontairement erronées : sans adresse, en doublon, annulées après affectation.
• Supprimez la recopie manuelle. Dès que l'échange fonctionne, l'ancienne méthode doit être abandonnée. Deux circuits en parallèle finissent toujours par des données divergentes et une discussion sur celui qui a raison.
• Convenez du support. Qui surveille la file des erreurs, sous quel délai il réagit, ce qu'il fait quand l'un des systèmes devient indisponible.

Quelques indicateurs simples, relevés avant et après, permettent de vérifier le résultat : le temps écoulé entre le passage de l'affaire à l'étape voulue et l'apparition de la commande chez le dispatcheur, le nombre de commandes créées à la main, la fréquence à laquelle les commerciaux appellent le dispatching pour demander un statut. C'est ce dernier qui bouge généralement le premier — signe que l'information a commencé à circuler par le système et non plus par les gens.

Le ticket d'entrée est ici plus bas qu'on ne le croit : le démarrage prend 7 jours, sans engagement de durée, et la plateforme est pensée pour des équipes de 5 à 100 intervenants. Autrement dit, la liaison avec le CRM peut se tester sur le flux réel de commandes et se comparer au point de départ dès le bout d'un mois.