Ces cas d’usage répondent à des intentions différentes. Chaque page détaille son périmètre, ses limites et les guides qui permettent de préparer le projet.
1. Commandes à risque
Objectif. Le cas d’usage Commandes à risque répond à un besoin précis : Prioriser les commandes inhabituelles pour une vérification humaine. Cette automatisation devient pertinente lorsque le volume rend le traitement manuel lent, irrégulier ou difficile à contrôler.
Donnée de départ. Le cadrage vérifie en priorité commandes, montants et historique client. Sans une source identifiable, un format stable et un responsable de la donnée, le scénario doit rester en préparation plutôt que d’exécuter une action incertaine.
Contrôle et limite. Aide à la décision uniquement, aucun refus automatique. Le risque à surveiller est de bloquer une commande légitime. Une file d’exceptions, un journal des actions et une validation explicite sont ajoutés lorsque la conséquence ne peut pas être annulée facilement.
Mesure. Le résultat se suit notamment avec commandes vérifiées manuellement. La valeur avant automatisation est relevée pour éviter d’attribuer au système un gain qui viendrait d’un changement de volume ou d’organisation.
2. Adresses vérifiées avant expédition
Objectif. Le cas d’usage Adresses vérifiées avant expédition répond à un besoin précis : Détecter les adresses incomplètes et demander une correction avant préparation. Cette automatisation devient pertinente lorsque le volume rend le traitement manuel lent, irrégulier ou difficile à contrôler.
Donnée de départ. Le cadrage vérifie en priorité statuts et motifs d’échec de paiement. Sans une source identifiable, un format stable et un responsable de la donnée, le scénario doit rester en préparation plutôt que d’exécuter une action incertaine.
Contrôle et limite. Un pays principal et un canal de contact. Le risque à surveiller est de relancer un paiement déjà régularisé. Une file d’exceptions, un journal des actions et une validation explicite sont ajoutés lorsque la conséquence ne peut pas être annulée facilement.
Mesure. Le résultat se suit notamment avec faux positifs bloquant de bons clients. La valeur avant automatisation est relevée pour éviter d’attribuer au système un gain qui viendrait d’un changement de volume ou d’organisation.
3. Paiements échoués récupérés
Objectif. Le cas d’usage Paiements échoués récupérés répond à un besoin précis : Relancer automatiquement les clients quand un paiement ou renouvellement échoue. Cette automatisation devient pertinente lorsque le volume rend le traitement manuel lent, irrégulier ou difficile à contrôler.
Donnée de départ. Le cadrage vérifie en priorité adresses, pays et contraintes de livraison. Sans une source identifiable, un format stable et un responsable de la donnée, le scénario doit rester en préparation plutôt que d’exécuter une action incertaine.
Contrôle et limite. Un PSP, trois messages. Le risque à surveiller est de modifier une commande en cours de préparation. Une file d’exceptions, un journal des actions et une validation explicite sont ajoutés lorsque la conséquence ne peut pas être annulée facilement.
Mesure. Le résultat se suit notamment avec paiements récupérés après relance. La valeur avant automatisation est relevée pour éviter d’attribuer au système un gain qui viendrait d’un changement de volume ou d’organisation.
4. Contrôle des remises anormales
Objectif. Le cas d’usage Contrôle des remises anormales répond à un besoin précis : Repérer codes cumulés, remises excessives et commandes sous seuil de marge. Cette automatisation devient pertinente lorsque le volume rend le traitement manuel lent, irrégulier ou difficile à contrôler.
Donnée de départ. Le cadrage vérifie en priorité codes promotionnels et règles de cumul. Sans une source identifiable, un format stable et un responsable de la donnée, le scénario doit rester en préparation plutôt que d’exécuter une action incertaine.
Contrôle et limite. Un canal et dix règles. Le risque à surveiller est de prendre automatiquement une décision financière sensible. Une file d’exceptions, un journal des actions et une validation explicite sont ajoutés lorsque la conséquence ne peut pas être annulée facilement.
Mesure. Le résultat se suit notamment avec remises excessives détectées. La valeur avant automatisation est relevée pour éviter d’attribuer au système un gain qui viendrait d’un changement de volume ou d’organisation.
5. Détection des commandes en doublon
Objectif. Le cas d’usage Détection des commandes en doublon répond à un besoin précis : Repérer les doubles achats involontaires avant préparation. Cette automatisation devient pertinente lorsque le volume rend le traitement manuel lent, irrégulier ou difficile à contrôler.
Donnée de départ. Le cadrage vérifie en priorité signaux de doublon ou de comportement inhabituel. Sans une source identifiable, un format stable et un responsable de la donnée, le scénario doit rester en préparation plutôt que d’exécuter une action incertaine.
Contrôle et limite. Fenêtre de 24 h et un canal. Le risque à surveiller est de bloquer une commande légitime. Une file d’exceptions, un journal des actions et une validation explicite sont ajoutés lorsque la conséquence ne peut pas être annulée facilement.
Mesure. Le résultat se suit notamment avec incidents évités avant préparation. La valeur avant automatisation est relevée pour éviter d’attribuer au système un gain qui viendrait d’un changement de volume ou d’organisation.
