Fiabilisez les échanges entre CRM et ERP : identifiants stables, reprise après erreur, détection des doublons et rapprochement des opérations.
Le CRM envoie une commande à l’ERP. La connexion coupe avant que le CRM reçoive la confirmation. Faut-il renvoyer la demande ? Sans mécanisme prévu, une nouvelle tentative peut créer une deuxième commande alors que la première a bien été enregistrée.
Ce scénario fictif permet de poser une question précise à un intégrateur : comment distinguer une opération à reprendre d’une opération déjà réalisée ? La réponse doit couvrir le parcours entier, jusqu’à la vérification dans les deux outils.
Identifier l’opération métier
Attribuez une référence stable à la commande avant de l’envoyer. Une tentative réseau est un événement technique ; la commande reste la même lorsque cette tentative est répétée. Conservez cette distinction dans le journal de suivi.
Le nom du client et le montant ne constituent pas un identifiant fiable. Deux commandes légitimes peuvent avoir le même montant. Un client peut aussi changer de nom ou partager une adresse email avec un service entier.
Déterminez quel système fait référence pour chaque donnée. Le CRM peut gérer le contact commercial et l’ERP la commande facturable. Si les deux peuvent modifier le même champ, définissez la règle de conflit avant d’activer une synchronisation dans les deux sens.
Vérifier ce que l’API garantit
Certaines API acceptent une clé d’idempotence qui permet de reconnaître des tentatives répétées. Stripe documente ce mécanisme, notamment le traitement des mêmes clés et des paramètres associés. Cette référence illustre le principe ; elle ne prouve pas que votre CRM ou votre ERP propose la même garantie.
Lisez la documentation de l’API concernée : durée de conservation des clés, opérations couvertes et comportement après erreur. Une clé conservée quelques heures ne protège pas forcément une reprise exécutée plusieurs jours plus tard.
Quand la cible ne propose aucun mécanisme adapté, examinez l’existence d’une référence externe unique et d’une recherche par cette référence. Une simple vérification « existe déjà ? » suivie d’une création peut encore échouer si deux traitements démarrent ensemble. La contrainte d’unicité doit être appliquée au point qui accepte réellement l’écriture, lorsque l’outil le permet.
Conserver un état de traitement explicite
Un tableau de suivi doit distinguer les opérations prêtes, envoyées, confirmées et celles dont le résultat reste inconnu. L’état « inconnu » mérite une procédure de rapprochement ; le traiter comme un échec certain peut provoquer une nouvelle création.
| Situation | Réaction à prévoir |
|---|---|
| Donnée obligatoire absente | Bloquer et demander une correction |
| Refus d’autorisation | Signaler le problème d’accès |
| Indisponibilité temporaire | Réessayer selon les règles de l’API |
| Délai dépassé après l’envoi | Vérifier le résultat avant de recréer |
| Confirmation reçue | Enregistrer la référence de la cible |
| Traitement manuel demandé | Suspendre les reprises automatiques concurrentes |
Définissez aussi qui peut relancer une opération. Une relance manuelle pendant une reprise automatique peut reproduire le problème que l’intégration devait résoudre.
Tester les coupures et les répétitions
La recette doit inclure un envoi normal, puis le même envoi répété. Vérifiez le nombre d’objets créés, mais aussi les notifications, réservations de stock et autres effets associés. Une commande unique accompagnée de deux notifications peut déjà perturber l’équipe.
Simulez ensuite une confirmation perdue et deux tentatives simultanées. Ajoutez une modification du contenu entre les tentatives : réutiliser la même clé pour une demande différente doit avoir un comportement défini.
Écrivez ces résultats attendus dans vos critères d’acceptation. Le prestataire pourra montrer comment chaque cas est traité, au lieu de limiter la démonstration à une synchronisation réussie.
Prévoir un rapprochement périodique
Même avec des reprises automatiques, comparez les références et les états entre les deux systèmes. Déterminez quelles différences sont normales, par exemple un délai de validation, et lesquelles exigent une investigation.
Gardez le journal technique assez précis pour retrouver une opération, avec des identifiants et des horodatages. Évitez d’y copier inutilement tout le dossier client. Les personnes qui analysent l’incident doivent disposer des accès appropriés aux détails nécessaires.
Le coût du connecteur dépend de ces exigences de reprise autant que du nombre de champs échangés. Pour préparer une intégration dans un logiciel sur mesure, présentez à Sky Vaults les deux applications, le sens des échanges et l’opération métier à fiabiliser.