Considérer que la réponse peut arriver avec retard. Afficher côté produit un statut intermédiaire (« Vérification en cours ») et un indicateur de progression (si possible). Ne verrouillez pas l’interface utilisateur : autorisez l’utilisateur à naviguer, mais signalez clairement l’état.

À la réception, convertir le résultat en un format produit standard : statut (validé / non validé / partiel), codes d’erreur fournis, champs extraits (nom, date de naissance, N° doc, date d’expiration), et métadonnées (qualité image, score de confiance).

Classifier le résultat en 3 catégories :

• Valide (OK) — aucune action requise.
• Non valide (rejet clair) — action utilisateur requise.
• Partiel / ambigu (ex. date illisible) — action guidée ou vérification manuelle. Prioriser les actions critiques (ex. document expiré = bloquant).

Conserver chaque résultat reçu avec horodatage, raison(s) de rejet et références de lot. Cela permet d’afficher un historique à l’utilisateur et d’analyser les causes récurrentes.

Présenter à l’utilisateur un résumé clair des champs extraits et mettre en évidence ceux non confirmés (ex. surligner la date de naissance si le service a un faible score de confiance). Si des champs discordent avec les données renseignées par l’utilisateur, proposer une option “Corriger ces champs” avant renvoi.

Si la réponse indique un problème technique du fournisseur (timeout, erreur 5xx, pas de résultat), basculer vers une file d’attente de tentative ou proposer une alternative (renvoi ultérieur, examen manuel). Informer l’utilisateur avec un message non technique et une estimation de délai.

Éviter le jargon technique. Exemple : “La photo est floue ou certaines informations sont illisibles.” Plutôt que “Erreur 422”. Toujours inclure pourquoi (court) et ce que l’utilisateur peut faire (concret).

Afficher la photo soumise avec annotations : zones floues, MRZ non lisible, document hors cadre. Les visuels aident l’utilisateur à comprendre rapidement.

Proposer 2 actions distinctes : “Reprendre une photo” (guide appareil) et “Téléverser un autre document”. Indiquer les exigences (formats acceptés, taille max, orientation).

Montrer un exemple correct vs incorrect (mini-avant/après) pour la prise de photo (bon cadrage, bonne luminosité, pas d’ombres).

Si plusieurs tentatives échouent, proposer un contact support (chat, ticket) ou une vérification manuelle. Indiquer les délais attendus pour la prise en charge humaine.

Après envoi d’une correction, afficher un message de confirmation avec numéro de suivi et une estimation du délai de nouvelle vérification.

Sur l’écran d’échec, afficher un bouton visible et une indication du type de correction requise (photo meilleure qualité, document différent, compléter champ manquant).

Si l’utilisateur reprend une photo, guider : positionner le document, enlever les reflets, éviter le contre-jour, tenir à distance recommandée. Offrir un mode “cadre automatique” qui recadre le document.

Avant d’envoyer au fournisseur, vérifier le format, la taille, l’orientation, le contraste minimum et la présence d’un visage si requis. Afficher des erreurs locales immédiatement (ex. “fichier trop volumineux - max 8MB”).

Afficher un aperçu après correction avec un résumé des modifications et un bouton “Confirmer et envoyer”. Inclure rappel des critères (luminosité, lisibilité).

Conserver les versions envoyées et afficher la plus récente en tête. Permettre à l’utilisateur de voir les précédentes soumissions et l’état associé.

Imposer une limite raisonnable de tentatives automatiques (ex. 5 tentatives par 24h) pour éviter abus. Après limite atteinte, basculer vers support humain ou vérification manuelle.

Envoyer une confirmation claire lorsque la nouvelle vérification est terminée (succès ou nouvel échec), avec actions possibles en cas d’échec répété.

Vérifier format (jpg/png/pdf), taille (< 8–10 MB), et dimensions minimales (ex. 800x600px). Rejeter et afficher message clair si non respecté.

Contraste, netteté et niveau de bruit : si la photo est floue ou trop sombre, prévenir l’utilisateur avec exemple et option de reprise.

Détecter présence d’éléments attendus : visage pour selfie + document, texte pour MRZ/numéro. En cas d’absence, demander recadrage ou un autre type de document.

Comparer sommairement les champs extraits localement (ou saisis) avec l’identifiant de l’utilisateur : nom, date de naissance approximative, sexe. Si différence importante, inviter à confirmer/corriger ces champs avant envoi.

Si l’utilisateur soumet une pièce expirée, bloquer le flux et afficher une erreur explicite (“Document expiré — fournir une pièce valide”).

Préparer un set d’erreurs prédéfinies et utilisables dans l’UI (ex. flou, mauvaise luminosité, document incomplet, pièce expirée, reflets). Ces messages doivent être courts + actionnables.

Si la validation locale est ambiguë ou le fournisseur indique un résultat partiel, proposer l’option “Vérification manuelle” et informer sur les délais.

Séparer les erreurs transitoires (timeouts, 5xx, surcharge) des erreurs permanentes (mauvaise pièce, données invalides). Les transitoires sont candidates au retry automatique ; les permanentes non.

• Tentative initiale : envoi immédiat.
• Si erreur transitoire : attendre puis réessayer en appliquant backoff exponentiel (p.ex. 2s, 4s, 8s).
• Ajouter un petit jitter (variation aléatoire) pour éviter pics simultanés.
• Plafonner le nombre de tentatives (p.ex. 4 tentatives) et la durée totale (p.ex. 2–5 minutes) avant d’arrêter et d’informer l’utilisateur.

Si le fournisseur est indisponible à grande échelle, placer la requête dans une file persistante et indiquer à l’utilisateur que la vérification est en attente, avec estimation du délai et option de notifier quand c’est repassé en ligne.

Après N tentatives automatiques sans succès, créer un ticket pour examen manuel : inclure image(s), métadonnées et tentative(s) précédentes. Informer l’utilisateur du délai prévu.

Toujours informer l’utilisateur de l’état : tentative en cours, multiple tentatives automatiques, file d’attente, ou basculement vers support. Ne pas masquer que l’échec est dû à un problème côté fournisseur si c’est le cas.

Instrumenter les tentatives, succès, échecs et temps de réponse. Définir alertes si taux d’échec transitoire dépasse un seuil (ex. 5% en 1h).