Fenêtres de silence pour les SMS A2P : heures locales et traçabilité

Qu’est-ce qu’une fenêtre de silence et pourquoi l’heure locale compte

Une fenêtre de silence est une période pendant laquelle une règle interdit ou reporte certains envois. Elle peut découler d’exigences applicables, d’une politique interne ou d’une préférence enregistrée par le destinataire. Les éléments disponibles ne permettent pas d’établir un horaire universel applicable sans vérifier le marché, le type de message et la règle concernée.

L’heure du serveur indique quand une plateforme traite une demande ; elle ne détermine pas à elle seule l’heure du destinataire. Si la règle se fonde sur l’heure locale, le système doit déterminer cette heure pour la destination avant de décider d’envoyer, de retenir ou de supprimer le message. Certains outils décrivent leurs heures de silence selon le fuseau horaire local du contact, mais cela ne constitue pas une exigence générale applicable à tous les services.

• Distinguez l’heure de réception, l’heure système et l’heure locale utilisée pour évaluer la règle.
• Ne considérez pas une plage horaire recommandée par un outil comme une obligation applicable à tous les marchés.
• Définissez les types de messages soumis à chaque règle et documentez la source de cette décision.

Distinguer les exigences, les politiques internes et les préférences

Avant de configurer des horaires, classez chaque règle selon son origine. Une exigence applicable peut découler des règles du marché ; une politique interne peut prévoir des contrôles plus stricts ; une préférence du destinataire peut correspondre à un choix enregistré. Ne les regroupez pas sous une étiquette générique d’« heures de silence » : chacune peut avoir un champ d’application, une priorité et des conditions différents.

Vérifiez les exigences à l’aide de sources adaptées à chaque marché et catégorie de trafic. Les sources générales ne suffisent pas à déduire les horaires, les exceptions ou les durées de conservation. Cet article propose des conseils opérationnels ; il ne constitue ni un avis juridique ni une liste d’exigences par pays.

• Pour chaque règle, consignez son champ d’application, le type de trafic, le marché et la source de validation.
• Définissez explicitement l’ordre de priorité lorsque se recoupent une restriction applicable, une politique interne et une préférence.
• Précisez qui peut approuver les modifications et comment les règles sont réexaminées lorsque les conditions d’exploitation évoluent.

Déterminer et maintenir l’heure locale

Ne déduisez pas le fuseau horaire actuel uniquement du numéro de téléphone. La recommandation E.164 concerne le plan international de numérotation, mais les éléments disponibles ne démontrent pas que le numéro identifie de façon fiable le fuseau horaire actuel d’une personne. Un destinataire peut changer de lieu ou utiliser un numéro qui ne reflète pas l’endroit où il se trouve.

Choisissez et documentez une source de fuseau horaire adaptée à votre cas d’usage, son niveau de fiabilité et la conduite à tenir si l’information est absente ou ambiguë. Tenez à jour les règles de fuseau horaire et d’heure saisonnière au moyen d’une source technique contrôlée ; ne remplacez pas des règles actualisées par des décalages horaires fixes codés en dur.

Si vous ne pouvez pas déterminer l’heure locale avec une fiabilité suffisante, appliquez une solution de repli prudente définie par votre politique : par exemple, retenir le message pour examen ou ne pas l’envoyer avant de pouvoir évaluer la règle. Le choix dépend des obligations et des risques propres au cas concerné.

• Enregistrez le fuseau horaire utilisé avec la décision, et pas seulement l’heure du serveur.
• Définissez la conduite à tenir lorsque les données de destination sont absentes, ambiguës ou obsolètes.
• Testez les changements d’heure saisonniers et les changements de fuseau à l’aide d’une source de règles maintenue à jour.

Concevoir le flux : valider, retenir, reprogrammer ou annuler

Un flux opérationnel clair évite que la fenêtre soit appliquée différemment selon le composant qui traite le message. À la réception d’une demande, vérifiez son objet et sa durée de validité, consultez la règle pertinente et calculez l’heure locale. Décidez ensuite d’envoyer le message, de le retenir jusqu’à une heure autorisée, de le reprogrammer ou de l’annuler.

La reprogrammation n’est appropriée que si le message reste valable au moment de son envoi et si la règle applicable l’autorise. Ne transformez pas une file d’attente en mécanisme qui envoie automatiquement un contenu devenu obsolète. Si les préférences ou les règles changent pendant que le message est en attente, réévaluez-le avant l’envoi.

• Réception : déterminer l’objet du message et, le cas échéant, sa durée de validité.
• Validation : consulter les préférences et les règles applicables à la destination et au type de trafic.
• Décision : envoyer, retenir, reprogrammer ou annuler en indiquant explicitement le motif.
• Nouvelle évaluation : vérifier à nouveau la règle et la durée de validité avant de libérer les messages retenus.

OTP et notifications urgentes : ne présumez pas d’exceptions

Le fait qu’un message contienne un OTP ou soit soumis à une contrainte de temps ne prouve pas, à lui seul, qu’il peut contourner une fenêtre de silence. Les éléments disponibles n’établissent aucune exception générale pour les OTP ou les autres notifications urgentes. Vérifiez les exigences et les politiques applicables avant de prévoir un traitement différent.

Concevez le flux en tenant compte de la durée de validité réelle du contenu. Si un code expire avant la fin de la fenêtre, l’envoyer plus tard risque d’être inutile ou déroutant. Déterminez à l’avance s’il faut l’annuler, proposer une autre solution autorisée ou demander une nouvelle opération. Ne renvoyez pas des codes expirés comme s’ils étaient encore valides et ne présentez pas une exception technique comme une dérogation aux règles.

• Définissez l’expiration et le comportement en cas de nouvelle tentative en coordination avec le service qui valide le code.
• Vérifiez si l’envoi différé reste utile et est autorisé pour cet usage et ce marché.
• Si une exception est documentée et approuvée, limitez son champ d’application et consignez son fondement.

Traçabilité : conserver la règle appliquée et le motif

À titre de contrôle interne, conservez suffisamment d’informations pour reconstituer les raisons pour lesquelles une demande a été envoyée, reportée ou annulée. Les éléments disponibles ne définissent ni un ensemble universel de champs obligatoires ni une durée de conservation ; établissez ces paramètres avec l’aide de conseils appropriés et en fonction des exigences applicables à votre organisation et à votre marché.

Consignez les décisions de manière cohérente et protégez les données personnelles associées. Évitez de conserver du contenu ou des identifiants au-delà de ce qui est nécessaire à des fins opérationnelles et d’audit. La durée de conservation doit respecter la politique et les obligations applicables, plutôt qu’une durée générique supposée.

• Champs opérationnels possibles : identifiant interne, type de message, fuseau horaire évalué, heure locale, heure programmée et résultat.
• Incluez la version ou l’identifiant de la règle appliquée, ainsi que le motif de toute exception ou annulation.
• Indiquez si l’heure a été calculée, si le message était en attente et quand il a été réévalué.
• Limitez l’accès aux journaux et fixez une durée de conservation conforme aux règles applicables.

Tester les cas limites avant d’activer les règles

Les tests doivent couvrir les changements de date et d’heure saisonniers, ainsi que les destinations soumises à des règles différentes. Vérifiez aussi ce qui se passe lorsqu’une personne modifie ses préférences après la mise en file d’attente du message. Un test concluant de l’horloge système ne valide pas automatiquement le calcul de l’heure locale.

Incluez des messages dont la durée de validité prend fin avant la prochaine fenêtre autorisée. Confirmez que le système les annule ou les traite selon le flux défini et qu’il ne les libère pas par une voie de contournement sans réévaluer la règle.

• Tester les instants qui précèdent et suivent immédiatement minuit, heure locale.
• Tester le début et la fin de l’heure saisonnière dans les destinations concernées.
• Tester les destinations pour lesquelles le fuseau horaire est indisponible ou ambigu.
• Modifier une préférence pendant que des messages sont retenus et vérifier qu’ils sont réévalués.
• Simuler une expiration avant l’heure autorisée et vérifier que le contenu obsolète n’est pas envoyé.

Liste de contrôle pour la mise en œuvre et l’audit

Avant d’activer des fenêtres de silence, confirmez que chaque règle a un champ d’application clair, une source vérifiée et un responsable. Vérifiez ensuite la détermination de l’heure locale, les comportements de mise en attente et d’annulation, ainsi que la réévaluation des messages en attente. Examinez régulièrement les journaux et les cas d’exception.

Les fenêtres de silence sont un contrôle de programmation, et non une garantie de livraison ou la preuve qu’un message respecte toutes les exigences. Distinguez les décisions de conformité, la logique d’envoi et l’observation ultérieure du résultat.

• La règle distingue-t-elle le marché, le type de trafic et l’origine de la politique ?
• L’heure locale provient-elle de données adaptées, et les règles temporelles sont-elles actualisées ?
• Le système définit-il la marche à suivre lorsque le fuseau horaire est incertain ?
• Les messages en attente sont-ils revalidés et annulés lorsqu’ils expirent ?
• Les exceptions ont-elles un champ d’application, une approbation et un motif documentés ?
• Les journaux sont-ils protégés et conservés conformément aux exigences confirmées ?
• Les tests couvrent-ils les changements d’heure, les modifications des préférences et les procédures d’annulation ?