Les correspondances clients incertaines exigent un circuit défini
Renvoyer une demande ne clarifie pas une correspondance client incertaine. L’intégration doit relier la clarification à un résultat cible confirmé.
Lorsqu’une intégration ne peut pas identifier avec fiabilité le client d’une opération, ce cas doit rester traitable. Il lui faut un rôle responsable, les informations nécessaires et un retour contrôlé vers le traitement. Un journal d’erreurs et l’instruction de renvoyer plus tard ne résolvent pas une identité métier incertaine.
Microsoft décrit aussi des interventions manuelles avec un motif d’échec traçable dans les flux à plusieurs étapes. Notre exemple attend avant d’écrire dans la cible.
Un cas ouvert doit aboutir à un résultat visible
Dans cet exemple entièrement fictif, la demande de projet R-28 doit créer un brouillon de projet dans l’ERP. Aucune correspondance confirmée n’existe pour le client CRM C-508. La personne responsable établit que le compte client ERP existant K-410 doit être utilisé. Le tableau décrit le déroulement souhaité.
État | Sens dans l’exemple | Ce qui reste à faire |
|---|---|---|
| Correspondance client incertaine ; aucun brouillon cible n’est créé. | Vérifier l’identité et confirmer la correspondance. |
| Une correspondance a été vérifiée par le métier. | Vérifier les droits actuels et l’utilisation possible du compte client avant l’écriture. |
| Le transfert est en cours de traitement. | Confirmer le résultat cible. |
| Le brouillon de projet confirmé | Le transfert convenu est terminé. |
Un nom dans une liste ne doit pas déterminer seul le choix du client. Le traitement doit réunir le motif, la version source vérifiée, l’ancienne correspondance, celle retenue et la justification de la décision. Seul le rôle autorisé peut accéder à ces cas.
Tenir compte de l’état actuel lors de la correction
Les données ou les droits peuvent changer entre affichage et confirmation. Avant de reprendre, vérifiez l’autorisation actuelle et si le compte choisi peut toujours être utilisé. OWASP exige un contrôle d’autorisation à chaque requête. Un écran de traitement déjà ouvert ne remplace pas ce contrôle.
Deux personnes travaillant simultanément ne doivent pas non plus enregistrer des décisions contradictoires sans détection. Des prérequis modifiés ou un cas déjà résolu doivent être détectés à la confirmation. Si les conditions ne conviennent plus, l’opération reste ouverte pour une nouvelle clarification.
Une répétition ne doit pas créer un second brouillon
Toutes les tentatives restent liées à la même demande de projet. Une protection supplémentaire dans la cible est nécessaire : par exemple une création idempotente qui ne produit aucun brouillon supplémentaire lors d’une répétition identique, ou une référence externe unique imposée dans la cible avec une consultation fiable du résultat. L’identifiant d’opération seul n’empêche pas les doublons.
Si la réponse manque après l’écriture, clarifiez d’abord le résultat de l’opération existante. AWS rappelle qu’un délai d’attente dépassé n’exclut pas des effets déjà produits. Tant que le résultat est inconnu, il ne doit pas être considéré comme un échec certain puis remplacé par une nouvelle demande arbitraire.
Réserver le traitement manuel aux cas nécessaires
Une correspondance non ambiguë et vérifiée peut être traitée automatiquement. Une validation humaine n’est pas nécessaire pour chaque enregistrement. Pour les autres cas, responsabilité, délai de réaction convenu et escalade doivent être visibles ; une liste croissante sans responsable ne résout rien.
Notre exemple s’arrête avant la création du projet. Si un élément a déjà été créé pour le mauvais client, une correction métier distincte doit tenir compte des liens qui en résultent.
Sources
À lire aussi
Tous les articles
Interfaces & intégration avec ASES
ERP, CRM et boutique bien connectés