Intégrité du contenu des SMS A2P : guide pour détecter les modifications
Une proposition opérationnelle pour comparer le contenu à chaque étape de l’envoi, consigner les différences et distinguer ce qu’indiquent les systèmes de ce qui peut être confirmé sur l’appareil destinataire.
Acceptation, livraison et intégrité sont des indicateurs distincts
Comme cadre d’investigation, il est utile de distinguer trois questions : le système a-t-il accepté la demande ? Quel état de livraison la route a-t-elle communiqué ? Et quel contenu est réellement apparu sur l’appareil ? Chaque réponse nécessite des preuves différentes.
L’acceptation d’une demande peut indiquer, d’après les journaux propres à une étape, que celle-ci a reçu ou traité une requête. Un rapport d’état de livraison (DLR) est un indicateur communiqué par une étape ; les éléments disponibles ici ne permettent pas d’établir s’il confirme le texte affiché sur le terminal. Lorsque vous rendez compte de l’incident, explicitez cette incertitude.
N’attribuez pas une modification à l’application, à la passerelle ou à une étape ultérieure au seul motif qu’un état de livraison existe. Comme méthode d’investigation proposée, comparez les journaux disponibles et, si possible, une capture d’écran ou une transcription obtenue depuis l’appareil destinataire.
- À titre de bonne pratique de journalisation, conservez l’identifiant de la demande et la réponse de l’étape qui l’a reçue.
- Notez l’état communiqué, sa source et l’heure ; ne le présentez pas comme une vérification du texte visible.
- Si vous documentez des preuves côté destinataire, précisez comment elles ont été obtenues et si elles correspondent au message et à l’appareil concernés par l’investigation.
Suivez le contenu du modèle jusqu’à sa destination
Comme proposition opérationnelle, représentez le parcours réel du message dans votre intégration : modèle et données insérées, client qui prépare la demande, API ou connexion SMPP, passerelle, fournisseur ou route, puis éléments disponibles côté destinataire. Ne partez pas du principe que tous les déploiements comportent les mêmes étapes ni que vous pouvez toutes les inspecter.
À chaque point sous votre contrôle, vous pouvez consigner une référence à la version du modèle et une représentation du texte envoyé à l’étape suivante. Si une étape externe n’expose pas le contenu traité, consignez cette limite d’observabilité au lieu de tirer des conclusions par déduction.
Vous pouvez établir une correspondance entre vos identifiants internes et ceux renvoyés par chaque système. Le cas échéant, limitez l’accès à cette correspondance et évitez d’inclure des numéros complets, des codes à usage unique ou des données personnelles dans des journaux opérationnels qui n’en ont pas besoin.
- Dans le cadre d’un exercice de traçabilité, indiquez les limites de responsabilité et de visibilité de chaque composant.
- Envisagez de conserver des horodatages et des identifiants pour relier les événements.
- Consignez, si elles sont disponibles, la version du modèle et les modifications pertinentes de l’intégration.
- Documentez les données que vous ne recevez pas du fournisseur ou que vous ne pouvez pas vérifier sur le terminal.
Consignez des références et comparez les observations avec prudence
Comme proposition d’instrumentation, vous pourriez consigner une empreinte cryptographique du contenu exact aux points que vous contrôlez, avec une référence à l’événement. Une empreinte permet de comparer des représentations définies pour son calcul ; elle ne permet pas de reconstruire le message et ne prouve pas ce que le terminal a reçu. Si vous choisissez cette méthode, précisez de manière cohérente quels octets ou quelle représentation sont inclus.
Vous pourriez également consigner la longueur, l’alphabet ou le mode de codage et le nombre de segments indiqués par chaque composant, si ces données sont disponibles. Distinguez les valeurs calculées localement de celles communiquées par une passerelle ou un fournisseur. Les éléments disponibles ne permettent pas de vérifier ici comment ces valeurs sont calculées.
La normalisation peut masquer des différences. Pour une investigation, il est recommandé de conserver, lorsque cela est sûr et nécessaire, une représentation exacte et une autre normalisée à des fins de comparaison. Documentez les transformations appliquées ; ne supprimez pas automatiquement les espaces, les sauts de ligne, les accents ou les caractères invisibles.
- Si vous calculez une empreinte, consignez l’algorithme et la définition exacte du contenu comparé.
- Distinguez les valeurs calculées localement de celles déclarées par un autre système.
- Évaluez les limites de conservation et d’accès ; envisagez d’utiliser des références ou des empreintes lorsqu’il n’est pas indispensable de stocker le texte intégral.
- Évitez de consigner en clair des codes OTP ou des données personnelles, sauf nécessité justifiée et avec des contrôles adaptés.
Examinez les substitutions et les différences au moyen de tests contrôlés
Si deux étapes affichent des textes différents, comparez d’abord, comme méthode d’analyse proposée, la représentation exacte, puis une vue normalisée qui en facilite la lecture. Identifiez le premier point où apparaît la différence ; si une étape n’est pas journalisée, délimitez l’intervalle possible et n’affirmez pas que la modification s’est produite à cet endroit.
Vous pouvez préparer des tests synthétiques avec un contenu autorisé et contrôlé : texte simple, caractères accentués, signes, sauts de ligne et caractères hors du jeu habituellement utilisé dans le modèle. Modifiez une seule variable à la fois et conservez le résultat obtenu à chaque étape observable. Cela peut aider à comparer les différences visibles aux données de codage ou de segmentation communiquées, sans présumer de la façon dont elles sont générées.
Ne déduisez pas le comportement d’une route à partir d’un seul test. Répétez le cas avec de nouveaux identifiants et consignez les conditions. Un résultat synthétique décrit uniquement ce qui a été observé dans cette configuration et à ce moment-là ; il ne garantit pas le résultat pour l’ensemble du trafic de production.
- Utilisez des messages de test inoffensifs ; n’incluez pas de données réelles de clients ni de codes OTP actifs.
- Comparez caractère par caractère et consignez la transformation observée, pas celle que vous supposez.
- Notez les données relatives à l’alphabet, à la longueur et aux segments telles que chaque étape les communique, si elles sont disponibles.
- Si le contenu n’est observable que sur le téléphone, consignez ces éléments séparément des journaux des autres systèmes.
Délimitez le segment concerné à l’aide de tests reproductibles
Comme proposition de diagnostic, concevez une matrice qui fait varier méthodiquement la route, la destination, l’expéditeur et le type de contenu, dans la mesure où ces options sont disponibles et autorisées. Gardez les autres conditions constantes et consignez l’élément modifié entre les exécutions.
Commencez par reproduire le cas dans l’environnement d’intégration à l’aide des journaux disponibles. Ensuite, si nécessaire, réalisez un test contrôlé vers un appareil auquel vous avez légitimement accès. Comparez le contenu préparé par l’application avec ce qu’affiche le terminal et avec les éléments disponibles pour chaque système intermédiaire.
Une observation faite sur un téléphone ne doit pas être généralisée à tous les destinataires. De même, un test qui ne reproduit pas le problème n’exclut pas une différence intermittente ou dépendant d’une condition non contrôlée. Précisez exactement la portée de chaque conclusion.
- Utilisez une référence unique pour chaque exécution et conservez la configuration du test.
- Ne modifiez qu’un seul paramètre à la fois pour faciliter la comparaison.
- Séparez les tests synthétiques des messages réels et n’envoyez pas de tests à des destinataires sans autorisation.
- Consignez les résultats négatifs et les conditions dans lesquelles ils ont été obtenus.
Escaladez le problème en vous appuyant sur les preuves et communiquez les incertitudes
Selon le critère opérationnel proposé, faites remonter le cas lorsque vous disposez d’une différence reproductible, qu’un segment précis sans visibilité empêche l’investigation d’avancer ou que les états communiqués par les systèmes se contredisent. Incluez des identifiants pouvant être mis en correspondance, les heures, la route et la destination sous une forme appropriée, la version du modèle, un contenu de test non sensible et les journaux que vous pouvez partager en toute sécurité.
Demandez à votre interlocuteur quel contenu il peut observer et à quel point du flux. S’il ne dispose que d’un DLR ou d’un identifiant de livraison, demandez-lui de distinguer cet indicateur d’une vérification du contenu sur le terminal. Ne partez pas du principe qu’une partie peut inspecter des informations que son système n’expose pas.
Lorsque vous communiquez le résultat, classez chaque affirmation comme observée, déduite ou restant à confirmer. Par exemple, le journal de l’application peut étayer le contenu de la chaîne consignée par cette étape ; affirmer ce qui s’est affiché sur le terminal nécessite des preuves provenant de l’appareil. Attribuer une substitution à une étape nécessite des preuves permettant de situer le changement à cet endroit.
- Fournissez une séquence d’événements avec les heures et les identifiants, en évitant les données sensibles inutiles.
- Indiquez les preuves manquantes et la partie susceptible de les fournir.
- Proposez la prochaine étape vérifiable au lieu d’attribuer une cause sans preuve.
- Convenez avec le client de la manière de protéger les captures d’écran, les numéros et les données personnelles.
Liste de contrôle pour éviter les régressions
Avant de publier des modifications d’un modèle, d’une intégration ou d’une condition de routage, vous pouvez conserver des cas de test représentatifs et comparer les résultats aux points où vous disposez de visibilité. Vérifiez le contenu ainsi que les valeurs de longueur, de codage et de segmentation communiquées, si elles sont disponibles ; ne supposez pas qu’un seul champ confirme le texte final.
Après la modification, consignez la version déployée et exécutez des tests autorisés. Si l’observation s’arrête à un système intermédiaire, signalez cette limite ; si elle est vérifiée sur un appareil, précisez l’appareil et l’exécution concernés.
BulkSMSMarket développe une plateforme d’entreprise permettant de découvrir, comparer, acheter, vendre et gérer des capacités SMS A2P. Le site public décrit la découverte et la gestion de routes, la connectivité HTTP et SMPP, l’accès à des fournisseurs et les consultations HLR. Ces capacités ne vérifient pas, à elles seules, le texte qui apparaît sur un terminal.
- Conservez une référence à la version du modèle et de l’intégration.
- Comparez, le cas échéant, le contenu exact et sa version normalisée ; expliquez les transformations appliquées.
- Distinguez les valeurs de codage, de longueur et de segmentation selon l’étape et la source qui les communique.
- Confirmez quelles preuves proviennent des systèmes et lesquelles proviennent d’un appareil destinataire.
- Documentez les limites, les résultats et les modifications avant de généraliser une conclusion à d’autres destinations.
Questions fréquentes
Un DLR confirme-t-il que le message est arrivé avec le texte attendu ?
Les éléments disponibles pour cet article ne permettent pas de l’établir. Traitez le DLR comme un état communiqué par une étape, et non comme une preuve du texte affiché sur l’appareil. Pour confirmer le texte visible, il faudrait disposer d’éléments provenant du terminal et associés à cette exécution.
Que faut-il comparer lorsqu’on recherche une modification ?
Comme méthode d’investigation proposée, comparez la représentation exacte du contenu à chaque point observable et, en complément, une version normalisée dont les transformations sont documentées. Consignez séparément les données de codage, de longueur et de segmentation communiquées par chaque composant, si elles sont disponibles.
Une empreinte du contenu prouve-t-elle ce que le destinataire a reçu ?
Non. Une empreinte peut servir à comparer les représentations définies dans les systèmes où elle a été calculée. Elle ne révèle pas le texte d’origine et ne prouve pas, à elle seule, ce qui s’est affiché sur le terminal.
Comment localiser le segment où le contenu change ?
Comme méthode proposée, mettez les journaux en correspondance à l’aide des identifiants et des heures, comparez le texte à chaque étape sous votre contrôle et répétez des tests contrôlés en ne modifiant qu’une variable à la fois. S’il manque de la visibilité entre deux points, signalez cet intervalle comme non confirmé.
Quelles informations inclure dans une remontée de problème ?
À titre de recommandation opérationnelle, incluez des identifiants pouvant être mis en correspondance, les heures, les conditions de test, la version du modèle, les journaux disponibles et une description de la différence. Protégez les données personnelles et distinguez clairement ce qui a été observé, déduit et reste à vérifier.
Sources consultées
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA