Journal des décisions de routage A2P SMS : guide opérationnel

Qu’est-ce qu’un journal de décisions de routage et à quels problèmes répond-il ?

Dans cet article, un « journal de décisions » désigne un modèle documentaire proposé pour expliquer pourquoi une décision de routage a été prise, quel trafic elle concerne et quelles informations ont été prises en compte. Ce modèle n’est pas présenté comme une norme technique ni comme une pratique établie par une source citée ici.

Une organisation peut choisir d’utiliser ce type de documentation pour aider ses équipes à retrouver le contexte d’une décision. Le format, les responsabilités et le processus adaptés dépendent de son fonctionnement interne ; les éléments proposés dans ce guide ne sont pas des exigences attribuées à une plateforme ou à un secteur.

Une fiche de décision ne prouve pas qu’un itinéraire conservera un résultat donné et ne remplace pas la vérification des exigences techniques, commerciales ou réglementaires applicables.

• Modèle proposé : documenter le motif d’une décision et le périmètre auquel elle se rapporte.
• Les éléments consignés peuvent aider à distinguer les observations des hypothèses.
• Le contenu doit être adapté par l’organisation à ses propres besoins et règles.

Différences entre politique exécutable, historique des modifications et journal de décisions

La politique exécutable désigne ici les conditions qu’un système applique, si une telle politique existe dans l’implémentation concernée. Son format et son fonctionnement varient ; les sources disponibles pour cet article ne permettent pas de décrire des champs, des journaux ou des contrôles propres à une plateforme.

L’historique des modifications désigne, dans ce modèle, un relevé des changements consignés lorsqu’un tel relevé est disponible. Le journal de décisions proposé sert à expliquer le raisonnement et le contexte associé. Ces notions peuvent être distinguées à des fins de documentation, mais les sources disponibles ne définissent pas de méthode de liaison ou de synchronisation entre elles.

Une organisation peut choisir d’utiliser des références internes pour éviter de recopier des règles dans une fiche explicative. Il s’agit d’une option documentaire proposée, et non d’une capacité ou d’une exigence technique vérifiée.

• Politique exécutable : les conditions appliquées par le système, le cas échéant.
• Historique des modifications : les changements consignés, s’ils sont disponibles.
• Journal de décisions : un modèle proposé pour expliquer le raisonnement et le contexte.

Champs possibles pour expliquer une décision

Les champs ci-dessous constituent une proposition de modèle organisationnel, pas une norme technique ni une exigence attribuée à un outil. Une organisation peut les adapter, les réduire ou ne pas les utiliser selon son contexte.

Pour expliquer le périmètre, une fiche peut préciser les éléments que l’organisation juge pertinents pour comprendre la décision. N’y consignez que des informations nécessaires et vérifiables ; les champs utiles dépendront de la décision concernée.

Il peut également être utile de distinguer les restrictions et les hypothèses des observations. Une condition observée pendant un test ne constitue pas automatiquement une condition garantie ni une règle permanente.

• Identifiant documentaire, si l’organisation en utilise un.
• Motif : le problème ou le besoin auquel la décision répond.
• Périmètre : le trafic concerné et le contexte que l’organisation juge pertinent.
• Restrictions, hypothèses et dépendances connues, le cas échéant.
• Observations prises en compte et limites connues de ces informations.
• Responsable ou fonction concernée, si l’organisation choisit de le consigner.
• Date de consignation ou condition de réexamen, si cela correspond au processus interne.

Comment présenter des observations sans en faire des garanties

Si une décision s’appuie sur des observations, une fiche peut préciser leur source et leur contexte lorsque ces informations sont disponibles et peuvent être partagées. Les sources fournies pour cet article ne permettent pas d’établir une méthode normalisée pour consigner des tests de routage.

Pour les états de livraison rapportés dans un système de messagerie, une fiche devrait préciser ce que signifie l’état selon la source qui l’a produit. Un état rapporté ne doit pas être présenté comme une preuve indépendante de réception sur un terminal sans élément permettant de l’établir.

Préférez des formulations limitées aux informations disponibles, par exemple : « Les observations consignées dans ce contexte indiquent… ». Évitez les affirmations absolues sur la livraison, la latence, la disponibilité ou les performances futures si les éléments disponibles ne les justifient pas.

• Indiquez la source et le contexte des observations, lorsqu’ils sont connus.
• Séparez les observations de leur interprétation et de la décision qui en découle.
• Précisez les limites connues des informations utilisées.
• Ne présentez pas un résultat passé comme une promesse de comportement futur.

Exceptions, incertitudes et décisions provisoires

Si une décision repose sur des informations incomplètes, une organisation peut choisir de consigner les inconnues et les hypothèses retenues. Dans ce modèle proposé, elle peut également indiquer les circonstances qui conduiraient à réexaminer la décision. Ces éléments ne constituent pas un processus technique établi par les sources disponibles.

Une fiche peut décrire une exception de manière limitée et préciser, selon les besoins de l’organisation, son motif, son périmètre et les personnes ou fonctions concernées. Évitez d’inclure des données personnelles ou des informations sensibles qui ne sont pas nécessaires à la compréhension de la justification.

Les sources disponibles mentionnent un extrait d’une disposition colombienne faisant état d’une restriction liée à certains trafics A2P, à la numérotation E.164, à un code court A2P, à un Sender ID attribué et à un modèle de contenu approuvé. L’extrait fourni ne permet pas d’identifier précisément la disposition ni d’établir son contexte complet, son champ d’application ou sa durée de validité. Il ne suffit pas à guider une décision réglementaire : consultez le texte intégral et les orientations de l’autorité compétente.

• Signalez clairement les informations provisoires ou incertaines, si l’organisation choisit de les consigner.
• Distinguez les hypothèses des faits établis.
• Décrivez les limites de l’exception selon le contexte de l’organisation.
• Vérifiez les textes et conditions applicables auprès de sources réglementaires pertinentes.

Proposition de processus de documentation et de réexamen

Les étapes ci-dessous sont une proposition de processus organisationnel, et non une procédure technique vérifiée ou une pratique universelle. Chaque organisation peut les adapter à son mode de gouvernance et à ses exigences internes.

Une organisation pourrait demander à la personne proposant une décision de décrire le problème et le périmètre envisagé. Les fonctions concernées pourraient ensuite examiner les informations disponibles et les limites de la justification, selon les règles internes.

Si une décision est mise en œuvre, l’organisation peut choisir de conserver le lien entre sa documentation et les éléments internes associés. Elle peut aussi déterminer quand réexaminer cette documentation, par exemple si le contexte change ou si les informations ayant motivé la décision ne sont plus pertinentes. Les modalités et les outils restent propres à chaque organisation.

• Proposition : motif, périmètre et informations disponibles.
• Examen : fonctions consultées selon l’organisation et le contexte.
• Documentation : références internes, si elles existent et sont utilisées.
• Réexamen : modalités fixées par l’organisation en fonction de ses besoins.
• Mise à jour ou retrait : traitement décidé par le processus interne.

Exemple hypothétique de fiche de décision

L’exemple suivant illustre un modèle documentaire hypothétique. Il ne décrit aucun itinéraire, fournisseur, niveau de couverture ni résultat commercial réel et ne constitue pas une règle de routage.

Identifiant : DEC-001. Motif : examiner une option de routage pour un type de trafic autorisé. Périmètre : segment défini par les règles internes de l’organisation. Restrictions : celles que l’organisation juge applicables au cas examiné. Observations : informations issues de tests, si elles existent, avec leur source et leur contexte. Responsable : fonction désignée par l’organisation, si elle choisit de le consigner. Statut : provisoire, à titre d’exemple. Réexamen : selon les modalités définies par l’organisation.

Cette fiche hypothétique explique un contexte sans décrire la logique exécutable d’un système. Les champs et les modalités présentés ne sont ni une norme ni une capacité de plateforme vérifiée.

Liste de contrôle proposée pour la documentation

Cette liste est un aide-mémoire facultatif, pas une norme ou une exigence technique. Elle peut aider une organisation à vérifier si la fiche choisie expose clairement son motif, son contexte et les limites des informations disponibles.

Évitez de présenter des notes documentaires comme si elles garantissaient un résultat ou décrivaient nécessairement la configuration en vigueur. Les pratiques de conservation, de mise à jour et de retrait dépendent des règles de l’organisation.

• Le motif et le périmètre sont-ils compréhensibles pour les personnes concernées ?
• Les observations sont-elles distinguées des interprétations ?
• Les limites et les incertitudes connues sont-elles visibles ?
• L’organisation a-t-elle défini les responsabilités et les modalités de réexamen utiles à son contexte ?
• Les exceptions sont-elles décrites sans être présentées comme des règles générales ?
• La documentation est-elle distinguée de la logique exécutée par un système ?
• Les informations sensibles non nécessaires ont-elles été écartées ?