Messages SMS A2P au statut incertain : rapprocher les éléments sans renvoi prématuré

Que signifie le statut incertain d’un message ?

« Incertain » peut désigner une catégorie interne signalant que les éléments de preuve disponibles ne permettent pas de déterminer le résultat selon les critères définis pour une intégration. Les informations fournies ici ne justifient pas de définition technique universelle de ce statut.

Il convient de distinguer les faits connus, comme une tentative d’envoi ou une réponse d’une interface, des conclusions qui ne sont pas démontrées. Ne supposez pas qu’une acceptation signifie une livraison, ni qu’une absence de réponse prouve un échec.

La signification de chaque statut et les éléments de preuve qui l’étayent dépendent de l’interface et de la documentation applicable. En l’absence de documentation pertinente, il est impossible d’établir des règles générales concernant les réponses d’API, les sessions SMPP ou les rapports de livraison (DLR).

• Consignez séparément les faits observés et l’interprétation interne qui leur est attribuée.
• Ne transformez pas une absence de réponse en affirmation sur ce qui s’est passé dans le système distant.
• Définissez toute catégorie opérationnelle en fonction de la documentation disponible et de l’accord spécifique.

Rassembler les éléments de preuve et conserver les informations disponibles

L’examen peut commencer par le rassemblement des journaux déjà disponibles dans l’application, l’interface et la plateforme de messagerie. Notez le système dont provient chaque donnée ainsi que son horodatage. Il s’agit de suggestions d’organisation interne, et non d’une description du fonctionnement d’une technologie particulière.

Ne supposez pas que les identifiants de différents systèmes sont équivalents ni qu’ils permettent de corréler automatiquement les événements. Pour établir une relation entre eux, consultez la documentation de l’intégration concernée.

Si l’équipe crée une classification interne ou normalise les statuts, elle peut également conserver la valeur reçue et documenter la règle interne appliquée. Les éléments de preuve fournis ne déterminent pas la manière dont la corrélation ou le traitement des événements doivent être mis en œuvre.

• À titre de contrôle interne suggéré, consignez les références disponibles, les horodatages et le système d’origine.
• Documentez les limites de corrélation au lieu d’attribuer un élément de preuve à un envoi sans fondement.
• Si le processus de votre équipe le permet, préservez la distinction entre la donnée reçue et son interprétation interne.

Définir des critères internes qui dépendent de l’interface

Une équipe peut définir des critères internes pour classer les cas et décider quand les examiner. En l’absence de documentation technique suffisante, ces critères doivent être présentés comme des contrôles propres à l’équipe, et non comme une machine à états universelle ou un comportement attendu de tous les fournisseurs.

Documentez les informations disponibles qui conduisent à chaque décision interne ainsi que la manière dont sont examinés les cas où les données sont incomplètes ou contradictoires. Les éléments de preuve fournis ne permettent pas de préciser le comportement des événements dupliqués ou tardifs, ni d’établir des transitions techniques générales.

Si deux journaux semblent incompatibles, consignez la divergence comme telle et consultez la documentation applicable. Ne choisissez pas automatiquement un statut au motif qu’il est plus récent ou plus favorable.

• Identifiez comme internes les catégories et les règles qui ne sont pas définies par la documentation de l’interface.
• Adaptez chaque critère aux informations réellement disponibles pour l’intégration.
• Consignez les divergences et évitez de les résoudre par des suppositions.

Appliquer des règles de clôture prudentes

La clôture d’un cas est une décision opérationnelle qui doit s’appuyer sur les critères définis pour l’intégration. Les éléments de preuve disponibles n’établissent ni délai commun ni liste universelle de statuts finaux.

Ces sources ne permettent pas de confirmer directement ce que signifie un DLR au statut « livré » sur chaque plateforme. Ne le présentez donc pas comme une preuve universelle de réception sur le terminal et n’attribuez pas la même sémantique à toutes les plateformes.

Lors de la clôture d’un cas, distinguez le statut signalé par le système de toute conclusion supplémentaire concernant la réception. N’affirmez que la réception est vérifiée que si l’intégration fournit des éléments de preuve adéquats et que leurs limites sont connues.

• Définissez les critères de clôture selon la documentation et les accords applicables.
• Décrivez un DLR comme un statut signalé ; ne généralisez pas sur ce qu’il prouve.
• Consignez les incertitudes qui subsistent au moment de clôturer le cas.

Choisir entre attendre, consulter, clôturer ou faire remonter le cas

L’action dépend des outils documentés pour l’intégration et des critères convenus par l’équipe. Les éléments de preuve fournis ne confirment pas qu’une fonction de consultation existe pour tous les fournisseurs ou toutes les interfaces.

À titre de contrôle interne suggéré, l’équipe peut définir quand laisser un cas ouvert, quand utiliser une fonction documentée de consultation et quand faire remonter une divergence. Si elle ne peut pas déterminer le résultat, elle peut le marquer comme indéterminé selon son propre processus.

Lors de la transmission d’un cas à un fournisseur, utilisez les informations nécessaires pour décrire la divergence et respectez les règles applicables en matière de protection des données. Ces recommandations sont des consignes d’organisation, et non des capacités techniques confirmées.

• Attendre : option de processus interne si le cas reste dans les limites du critère convenu.
• Consulter : uniquement si la documentation de l’interface décrit une fonction de consultation applicable.
• Faire remonter le cas : option interne en cas de divergence ou d’informations insuffisantes nécessitant un examen.
• Clôturer comme indéterminé : décision interne lorsque le processus convenu ne permet pas de conclure autrement.

Éviter les renvois automatiques, surtout pour les flux OTP

Les éléments de preuve disponibles ne permettent pas de déterminer quels mécanismes de déduplication, de consultation ou de nouvelle tentative les différentes plateformes proposent. Un délai d’attente dépassé, l’absence d’un DLR ou un statut en attente ne doivent donc pas être considérés ici comme une preuve suffisante d’échec ni comme un signal technique universel justifiant un renvoi.

À titre de contrôle interne suggéré, séparez l’examen de l’envoi initial de la décision d’en lancer un autre. Avant toute nouvelle tentative, appliquez la politique de réessai documentée pour l’application et l’intégration ; ne supposez pas que le système reconnaîtra une demande répétée comme une seule et même opération.

Pour les flux OTP, respectez les règles applicables en matière de métier, de sécurité, de confidentialité et de consentement. Indiquez clairement le statut connu, sans présenter une nouvelle tentative comme une garantie de livraison.

• N’attribuez pas de capacités de déduplication ou d’idempotence à une interface sans documentation qui le confirme.
• Appliquez les contrôles de nouvelle tentative définis pour l’application et l’intégration.
• Dans les communications OTP, évitez de présenter une nouvelle tentative comme une garantie de résultat.

Cadre pratique de décision

Ce cadre est une aide interne, et non une spécification d’API ni une description universelle des statuts proposés par les fournisseurs. Adaptez-le à la documentation et aux accords applicables.

Avant de l’utiliser, vérifiez quelles informations l’interface fournit et quelles conclusions elles permettent de tirer. S’il est impossible d’identifier la source ou le lien entre les journaux, consignez cette limite.

• Réponse d’acceptation sans information ultérieure : interprétez la réponse uniquement selon la documentation applicable ; toute attente ou consultation relève d’une décision de processus interne.
• Absence de réponse à la demande : consignez le fait observé ; ne concluez pas automatiquement si la demande a été acceptée ni ce qui s’est passé ensuite.
• DLR reçu : conservez le statut signalé et consultez sa définition ; n’en faites pas une affirmation universelle de réception sur le terminal.
• DLR sans corrélation fiable : ne l’attribuez pas à un envoi sans fondement documenté.
• Informations incompatibles : conservez les données disponibles et suivez le processus interne d’examen ou de remontée.
• Éléments de preuve insuffisants : classez le cas selon le processus interne, sans affirmer un résultat qui n’est pas démontré.

Examiner l’incertitude et les décisions

Un indicateur des cas incertains n’est interprétable que si l’équipe définit les cas qu’il inclut, la période observée et la manière dont les évolutions ultérieures sont consignées. Les éléments de preuve disponibles ne fournissent ni référence de performance ni chiffre à utiliser.

Un processus interne peut examiner les cas ouverts, les divergences, les limites de corrélation et les décisions de renvoi. Maintenez une distinction entre les catégories fondées sur les statuts signalés et les affirmations de réception vérifiée.

Cet examen peut aider à repérer des lacunes dans la documentation ou les processus. N’attribuez pas à un indicateur des conclusions que les données ne permettent pas d’étayer.

• Définissez la période et les critères utilisés pour identifier les cas incertains.
• Consignez les divergences et les limites des informations disponibles.
• Examinez les décisions de renvoi selon la politique interne applicable.
• Distinguez les statuts signalés de toute réception vérifiée.