Escalade des incidents A2P SMS entre fournisseurs : responsabilités et éléments de preuve
Un guide pratique pour coordonner les investigations sur les SMS A2P entre plusieurs fournisseurs, consigner les observations et éviter d’attribuer une cause sans éléments suffisants.
Pourquoi un incident peut traverser plusieurs frontières opérationnelles
Dans une chaîne de gros, un message peut passer par plusieurs entreprises ou systèmes avant d’atteindre sa destination. Les éléments disponibles pour ce guide ne permettent pas de déterminer ce que voit chaque participant, comment les journaux sont corrélés entre opérateurs ni quel système est à l’origine d’un incident. Par conséquent, le signalement d’un client ne suffit pas, à lui seul, à attribuer une cause.
Par précaution opérationnelle, il peut être utile de distinguer les données observées directement des informations reçues d’autres parties. Cette organisation aide à décrire ce qui est connu et ce qui n’a pas été confirmé, mais ne constitue pas une procédure fondée ici sur une norme technique.
- Décrivez les informations que vous avez observées directement et celles que vous avez reçues d’une autre partie.
- Ne supposez pas que tous les participants utilisent les mêmes références, états ou plages horaires.
- Indiquez les éléments qui restent à confirmer, plutôt que de présenter une explication provisoire comme une cause.
Désignez un responsable du dossier et des contacts pour chaque segment
À titre de proposition d’organisation interne, vous pouvez désigner une personne ou une équipe chargée de rassembler les informations du dossier et de coordonner les communications. Cela ne signifie pas qu’elle contrôle les systèmes de tiers ni qu’elle peut déterminer à elle seule où un problème a pris naissance.
Les éléments disponibles ne précisent pas comment les responsabilités doivent être réparties entre fournisseurs, ni quels sont les canaux, délais ou critères d’escalade. Si ces modalités sont convenues en interne ou entre les parties, il est préférable de les identifier comme des accords, et non de les présenter comme une règle universelle.
- Si cela est utile à votre organisation, attribuez une référence interne au dossier.
- Identifiez les contacts et les canaux convenus par les parties.
- Ne présentez pas les priorités ni les délais de mise à jour comme des exigences universelles.
- Distinguez la coordination du dossier de l’investigation technique menée par chaque fournisseur.
Rassemblez les données utiles avant l’escalade
Les éléments disponibles ne permettent pas de déterminer quelles données sont indispensables ou suffisantes pour corréler un message entre fournisseurs. À titre de suggestion pratique, une demande peut décrire les informations disponibles dans vos propres systèmes et demander à l’autre partie de quelles données elle a besoin pour examiner ses journaux.
Indiquez la source et le contexte de chaque donnée, et précisez les heures et les fuseaux horaires lorsque cela est pertinent. Lorsque vous communiquez des informations sur des destinataires ou des expéditeurs, utilisez uniquement les données nécessaires et les canaux approuvés par votre organisation.
- Référence interne du dossier et autres références disponibles.
- Destinataire et expéditeur concernés par la demande, avec un traitement approprié des données.
- Date, heure, fuseau horaire et système d’origine de chaque donnée temporelle.
- État reçu, nom exact du champ ou de l’événement, et source qui l’a signalé.
- Route ou configuration, si ces éléments figurent dans les journaux consultés.
- Description précise de l’impact observé et de l’étendue connue, sans extrapolation.
Distinguez les observations, les informations reçues et les hypothèses
À titre de pratique de documentation suggérée, vous pouvez séparer les journaux de votre propre système, les déclarations reçues des fournisseurs et les explications qui n’ont pas encore été confirmées. Cette distinction permet de clarifier la source de chaque affirmation ; les éléments disponibles ne l’établissent pas comme une exigence technique ou officielle.
Conservez le contexte des données et des communications pertinentes pour l’investigation. Si une interprétation est proposée, identifiez-la comme telle et précisez quelles informations manquent pour la confirmer.
- Observation propre : indiquez le système et le journal consultés.
- Information d’un fournisseur : précisez qui l’a communiquée et à quel moment.
- Hypothèse : présentez-la comme provisoire et indiquez ce qui reste à vérifier.
- N’attribuez pas une cause uniquement parce que deux événements coïncident dans le temps.
Convenez des priorités, des mises à jour et de l’escalade
Les éléments fournis ne définissent ni délais de réponse, ni priorités, ni étapes d’escalade, ni critères universels pour les attribuer. Si les parties ont besoin de telles modalités, elles peuvent les convenir selon leur relation et préciser qu’il s’agit d’accords entre elles.
Décrivez l’impact observé et l’étendue connue. Ne promettez pas de résolution ni de délai qui n’a pas été confirmé par les parties responsables.
- Si des priorités sont définies, consignez les critères convenus.
- Convenez avec les parties du format et de la fréquence des mises à jour.
- Consignez toute escalade supplémentaire ainsi que le motif communiqué.
- Utilisez une référence cohérente pour les communications liées, si les parties le peuvent.
Interprétez les états et les DLR avec prudence
Les éléments disponibles ne comprennent aucune spécification technique pertinente permettant de déterminer la signification d’un DLR dans une implémentation donnée ni le segment qui le génère. Au vu des informations fournies, il n’est pas possible d’affirmer qu’un DLR confirme la réception ou la lecture du SMS sur le terminal.
Avant de décrire un état, demandez la documentation applicable à l’implémentation et au système qui le communique. Si ces informations ne sont pas disponibles, limitez votre résumé à l’état reçu, à sa source et à son contexte, et précisez explicitement ce qui n’a pas pu être vérifié.
- Conservez le texte de l’état et notez qui l’a communiqué.
- Ne présentez pas un DLR comme preuve de réception ou de lecture sur le terminal sans documentation applicable à l’appui.
- Ne supposez pas que des états similaires ont la même signification dans des systèmes différents.
- Distinguez l’état reçu des éléments vérifiés séparément.
Consignez la chronologie du dossier
À titre de suggestion de gestion, vous pouvez rassembler dans un dossier les informations pertinentes de l’investigation, en indiquant leur source et le moment où elles ont été reçues. Les éléments fournis ne définissent pas d’exigences d’audit, de conservation des journaux ni de délais de rétention pour les incidents A2P entre fournisseurs.
Si une route ou une configuration est modifiée pendant une investigation, décrivez le changement et l’objectif communiqué. N’attribuez pas une évolution ultérieure du résultat à cette modification sans éléments permettant d’établir ce lien.
- Notez les communications et les décisions que vous jugez utiles pour reconstituer le dossier.
- Indiquez, lorsque ces informations sont disponibles, la source et l’heure des données consignées.
- Décrivez les changements de route ou de configuration ainsi que le motif indiqué.
- Respectez les politiques internes et les accords applicables en matière d’accès et de conservation.
Clôturez le dossier et consignez les points en suspens
Lors de la clôture d’un dossier, vous pouvez résumer ce qui a été observé, quelles explications ont été confirmées par les parties et quelles questions restent sans réponse. Les éléments fournis ne définissent ni catégories officielles de clôture ni critères techniques permettant de déterminer une cause.
Si des mesures de suivi sont convenues, indiquez qui les a communiquées et ce qui reste à faire. Ne transformez pas une explication provisoire en règle générale pour de futurs incidents.
- Résumez les observations et les sources qui les étayent.
- Indiquez les éléments qui n’ont pas pu être confirmés.
- Consignez les actions de suivi convenues par les parties.
- Distinguez les conclusions du dossier des hypothèses qui restent à vérifier.
Questions fréquentes
Un DLR prouve-t-il que le SMS est arrivé sur le téléphone ?
Les éléments techniques fournis ne permettent pas de déterminer ce que confirme un DLR dans une implémentation donnée. N’affirmez pas qu’il prouve la réception ou la lecture sur le terminal sans documentation applicable à l’appui.
Quelles données est-il utile d’inclure dans une demande adressée à un fournisseur ?
Vous pouvez préciser les références, les données pertinentes concernant le destinataire et l’expéditeur, les heures et les fuseaux horaires, l’état reçu et sa source, ainsi que l’impact observé. Les éléments disponibles ne définissent pas d’ensemble minimal universel ; ne partagez que les données nécessaires par des canaux approuvés.
Qui doit coordonner un incident impliquant plusieurs fournisseurs ?
Votre organisation peut désigner une personne chargée de coordonner les informations et les communications. Les éléments fournis ne définissent pas de répartition universelle des responsabilités entre fournisseurs ; coordonner le dossier n’implique ni de contrôler les systèmes de tiers ni de déterminer seul la cause.
Que faire si les fournisseurs donnent des versions différentes ?
À titre de mesure d’organisation, consignez séparément les différentes versions et leurs sources, demandez à chaque partie quelles informations elle juge nécessaires pour examiner le dossier et signalez explicitement la divergence si elle ne peut être résolue. Les éléments disponibles ne fournissent pas de procédure officielle pour la trancher.
Sources consultées
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA