Enquêter sur les rejets de SMS A2P sans exposer de données ni tirer de conclusions hâtives
Un guide opérationnel pour cerner les rejets, sélectionner des échantillons utiles, corréler les journaux et documenter les hypothèses sans confondre indices et causes confirmées.
Un rejet est un état observé, pas un diagnostic complet
Un journal classé « Rejeté » indique que le système qui le signale a attribué cet état au message. À lui seul, il ne permet pas nécessairement d’identifier le composant à l’origine du rejet, l’étape à laquelle celui-ci s’est produit ni sa cause définitive. Le libellé et le code associé sont des indices à examiner, pas une explication concluante.
Il convient de distinguer trois niveaux : le résultat communiqué par une application ou une plateforme, la réponse enregistrée par le fournisseur ou la route, et la confirmation de réception sur l’appareil. Un DLR est un rapport d’état ; il ne doit pas être présenté automatiquement comme une vérification indépendante de l’apparition du message sur le terminal. Si les éléments disponibles ne permettent pas de confirmer cette dernière étape, consignez cette incertitude.
- Rejet technique : une réponse ou un état indique que l’envoi n’a pas été accepté ou n’a pas continué à une étape donnée. Vérifiez quel système a généré la réponse et à quelle requête elle correspond.
- Filtrage du contenu : cela peut constituer une hypothèse lorsque les journaux ou le fournisseur le signalent ; ne considérez pas cette hypothèse comme prouvée au seul motif qu’elle correspond à un message rejeté.
- Résultat incertain : si les journaux ne permettent pas de distinguer un rejet, un état en attente ou une confirmation de livraison, conservez cette distinction et ne transformez pas l’incertitude en cause.
Définissez la question et limitez l’extraction
Avant de consulter les journaux, précisez quelle décision l’enquête doit éclairer. Par exemple : déterminer si la hausse des rejets se concentre sur une destination, comparer un modèle de message concerné à un autre, légitime, ou vérifier si une réponse du fournisseur correspond à l’état de la plateforme. Une question précise évite de collecter des historiques complets qui n’apporteraient rien à l’analyse.
Définissez à l’avance la période, les destinations et expéditeurs concernés, les types de trafic inclus et les critères permettant de considérer un événement comme pertinent. Si vous comparez les données avant et après un changement, notez les dates et la nature du changement. N’attribuez pas de causalité au seul motif que deux faits se sont produits au cours de la même période.
- Commencez par une recherche ciblée sur les événements rejetés et élargissez-la uniquement si les éléments disponibles laissent une question sans réponse.
- Distinguez les OTP, le trafic transactionnel et le marketing légitime lorsque leurs flux, modèles ou conditions d’envoi diffèrent.
- Consignez l’identité du demandeur, l’objectif de l’enquête, la période couverte et les personnes autorisées à consulter les données.
Concevez un échantillon utile et expliquez sa sélection
Une liste de cas marquants peut aider à diagnostiquer un incident, mais elle ne prouve pas que le phénomène est fréquent. Pour examiner un problème, répartissez les journaux selon les dimensions pertinentes : destination, opérateur lorsque cette information est disponible, expéditeur, modèle ou type de trafic et période. Comparez des groupes équivalents et indiquez le nombre d’événements inclus dans chaque groupe.
Les éléments disponibles ne permettent pas de définir une taille d’échantillon universelle qui garantirait sa représentativité. Si vous avez besoin d’un échantillon descriptif, expliquez les critères de sélection et leurs limites. Vous pouvez compléter une sélection systématique par des cas concrets illustrant différentes réponses, mais désignez-les comme des exemples et non comme une mesure de fréquence.
- Définissez d’abord les groupes susceptibles d’expliquer la différence observée ; évitez de combiner des destinations ou des expéditeurs sans vérifier qu’ils sont comparables.
- Si vous cherchez à détecter un changement, incluez des événements issus de différents moments de la période et consignez la méthode de sélection.
- Conservez le dénominateur : indiquez le volume examiné par groupe lorsqu’il est disponible et n’extrapolez pas un petit échantillon à l’ensemble du trafic.
- Si la plateforme permet de filtrer par état et code de motif, utilisez ces filtres pour repérer les journaux ; le code reste un indice à vérifier.
Corrélez les événements à l’aide des champs nécessaires, sans inclure par défaut tout le contenu
Pour comparer les éléments disponibles, vous devez pouvoir relier l’événement de l’application au journal de la plateforme et, le cas échéant, à la réponse du fournisseur. Les champs disponibles varient selon l’intégration ; il n’est donc pas possible d’affirmer qu’un schéma minimal universel convient à tous les systèmes. Sélectionnez uniquement les identifiants et métadonnées nécessaires pour répondre à la question.
Pour commencer, vérifiez si vous pouvez établir une corrélation à l’aide d’un identifiant de message ou de requête et d’un horodatage. N’ajoutez que les attributs nécessaires pour segmenter le cas, tels que la destination, l’expéditeur, le type de trafic, l’état signalé, le code de motif et le système source. Vérifiez la signification de chaque champ dans la documentation de la plateforme ou du fournisseur.
- Évitez d’exporter le texte intégral du message s’il suffit de faire référence au modèle, à une catégorie ou à une version.
- S’il est nécessaire d’examiner le contenu, limitez l’accès au sous-ensemble justifié et évitez de l’inclure dans les rapports généraux.
- Ne considérez pas des noms de champs similaires comme équivalents : vérifiez s’ils désignent une requête, un envoi, une réponse ou un état ultérieur.
Limitez l’exposition des données et documentez les accès
Les journaux de messagerie peuvent contenir des données personnelles ou des informations sensibles pour l’activité. L’enquête doit recueillir uniquement les éléments strictement nécessaires à son objectif, limiter les personnes autorisées à consulter les données et documenter les critères de conservation et de suppression applicables au sein de l’organisation. La durée précise dépend des obligations et politiques pertinentes ; aucun délai unique ne peut être recommandé pour tous les cas.
Lorsque cela est possible, utilisez des identifiants de substitution dans les notes d’analyse et séparez les documents de travail des données permettant d’identifier une personne. Évitez de copier les journaux dans des canaux ou documents accessibles à un nombre excessif de personnes. Si une obligation légale ou contractuelle impose de conserver certaines informations, suivez la procédure applicable et consignez cette nécessité.
- Définissez l’objectif et les personnes autorisées avant de partager une extraction.
- Consignez les données exportées, les personnes qui les ont consultées et la date à laquelle leur conservation devra être réexaminée, conformément aux politiques et obligations applicables.
- Masquez ou supprimez les champs qui ne sont pas nécessaires pour corréler les événements et analyser le phénomène.
Recoupez les journaux et distinguez les hypothèses des faits
Suivez un événement de bout en bout, dans la mesure permise par vos systèmes : requête de l’application, acceptation ou réponse de la plateforme et état communiqué par le fournisseur. Vérifiez que les identifiants et les horaires correspondent au même envoi, et conservez les réponses originales avec le nom du système qui les a émises. Les différences entre les journaux peuvent révéler un manque d’observabilité, une divergence d’intégration ou une explication qui doit être vérifiée ; elles ne suffisent pas, à elles seules, à établir la cause.
Contactez le fournisseur en lui transmettant un ensemble restreint d’exemples pouvant être corrélés et en posant une question précise. Demandez-lui de clarifier la signification du code et l’étape à laquelle la réponse a été générée. Tant qu’aucune confirmation suffisante n’est disponible, décrivez le résultat comme une hypothèse ou une divergence observée, et non comme un fait démontré.
- Indice observé : « Dans l’échantillon, ces événements apparaissent comme rejetés sur la plateforme. »
- Hypothèse : « Le phénomène pourrait être lié à la réponse indiquée par le fournisseur ; son origine et sa signification restent à confirmer. »
- Conclusion confirmée : utilisez cette formulation uniquement lorsque des journaux cohérents et la validation pertinente étayent l’explication.
- Si le fournisseur ou la plateforme ne peut pas confirmer la réception sur le terminal, indiquez-le explicitement.
Documentez les vérifications, les limites et les actions
Un rapport utile permet à une autre personne de comprendre ce qui a été examiné et ce qui reste inconnu. Conservez la question, le périmètre, la méthode de sélection, les sources des journaux, les définitions des états et les résultats par groupe. Distinguez les observations, les hypothèses, les vérifications effectuées et les conclusions, et précisez quels éléments pourraient modifier l’interprétation.
Si l’analyse révèle un problème d’intégration ou une obligation de conformité, corrigez cet aspect et vérifiez le résultat au moyen des contrôles autorisés. Ne modifiez pas des messages légitimes dans le but de contourner des filtres. Si un filtrage est suspecté, demandez des explications au fournisseur et vérifiez la conformité ainsi que la configuration concernée avant de modifier le flux.
- Indiquez la période et les critères d’inclusion et d’exclusion, sans publier de contenu ni d’identifiants superflus.
- Notez littéralement les codes et les états, ainsi que le système qui les a signalés ; ne les interprétez pas comme des causes non confirmées.
- Consignez les actions convenues, les personnes responsables et les éléments requis pour clôturer l’enquête.
- Réévaluez l’échantillon si le phénomène change de destination, d’expéditeur, de type de trafic ou de période.
Questions fréquentes
Un état « Rejeté » permet-il d’identifier qui a bloqué le SMS ?
Pas nécessairement. Il indique l’état signalé par le système qui l’affiche. Le code de motif peut orienter l’enquête, mais sa signification doit être vérifiée et les journaux recoupés pour déterminer l’étape et la cause.
Un DLR confirme-t-il que le message est arrivé sur le téléphone ?
Il ne faut pas le supposer automatiquement. Un DLR est un rapport d’état ; les éléments disponibles ne confirment pas nécessairement de manière indépendante que le message a été reçu ou affiché sur le terminal. Consignez le système qui l’a émis et les incertitudes qui subsistent.
Quelle taille doit avoir l’échantillon ?
Aucune taille universelle ne convient à tous les cas. Définissez les groupes et les critères de sélection, conservez le volume examiné et évitez de généraliser à l’ensemble du trafic si l’échantillon est limité ou non représentatif.
Dois-je conserver le texte intégral de chaque message ?
Pas par défaut. Ne conservez le contenu que s’il est nécessaire pour répondre à la question, et limitez-en l’accès. Lorsqu’une référence au modèle ou une catégorie suffit, utilisez-la et réduisez au minimum les autres données.
Dois-je modifier le texte pour éviter un rejet ?
Ne modifiez pas des messages légitimes dans le but de contourner des filtres. Si vous suspectez un problème de filtrage, vérifiez cette hypothèse avec le fournisseur et examinez la conformité ainsi que l’intégration concernée.
Sources consultées
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA network resourcesGSMA
- Comprender los mensajes rechazadosSinch Support
- Estudio del servicio de mensajes cortos Aplicación a Persona (A2P)Instituto Federal de Telecomunicaciones (IFT)