Contrat d’intégration des DLR SMS A2P : champs, états et évolutions
Guide pratique pour convenir du format des DLR entre fournisseurs SMS, préserver les codes d’origine, corréler les événements et tester les évolutions sans interpréter un rapport comme une preuve automatique de réception sur le téléphone.
Pourquoi la sémantique d’un DLR peut varier
Un rapport de livraison (DLR, pour Delivery Report) est un événement communiqué par un système de la chaîne de messagerie. Sa signification opérationnelle dépend de son émetteur, de l’étape qu’il représente et de la manière dont le fournisseur définit ses états. Ainsi, deux systèmes peuvent employer des libellés similaires sans que leurs rapports constituent des preuves équivalentes.
Avant l’intégration, identifiez chaque maillon concerné — par exemple, la plateforme d’envoi et le fournisseur qui renvoie le rapport — et demandez sa documentation technique à jour. Ne présumez pas qu’un état, un code ou un horodatage a la même signification dans tous les systèmes. Les informations disponibles ici ne permettent pas de définir une liste universelle d’états ni leurs équivalences.
- Convenez de l’événement communiqué par chaque fournisseur et de l’étape du parcours qu’il est censé représenter.
- Consignez la définition de l’état selon la documentation du fournisseur, et pas seulement son libellé.
- Clarifiez la signification des horodatages et le fuseau horaire utilisé.
Définir un schéma commun avant de connecter les systèmes
Le contrat de données doit distinguer les champs obligatoires, facultatifs et conditionnés à la disponibilité chez le fournisseur. Pour chaque champ, précisez le nom, le type, le format, la signification, les règles en cas d’absence et des exemples convenus. Ne transformez pas une convention locale en exigence universelle : validez chaque point avec les participants à l’intégration.
Comme base de discussion, envisagez un identifiant d’événement, l’identifiant du message connu de l’émetteur, l’état normalisé, le code et le texte d’origine, le système source et les horodatages disponibles. Ajoutez des identifiants de corrélation lorsqu’il existe des traductions entre systèmes. Les informations disponibles n’établissent pas que tous ces champs existent ou suivent un format standard dans tous les DLR.
- Ne rendez obligatoire que ce que tous les participants peuvent produire et valider.
- Définissez si un champ absent doit être omis, représenté par une valeur nulle ou signalé par un autre mécanisme.
- Précisez le format et le fuseau horaire de chaque horodatage ; ne déduisez pas l’heure de réception d’un autre horodatage sans règle documentée.
- Incluez dans le contrat des exemples valides et invalides.
Conserver l’état normalisé et la réponse d’origine
La normalisation facilite le traitement commun, mais peut masquer des différences importantes si elle remplace entièrement la réponse du fournisseur. Enregistrez séparément l’état interne normalisé et l’état, le code et le texte reçus à l’origine. Conservez également le nom ou l’identifiant du système source ainsi que la version du mappage appliqué.
Tenez à jour une table de correspondance explicite, révisée avec chaque fournisseur. Si un code n’est pas documenté ou ne peut pas être mappé de manière fiable, classez-le comme inconnu ou à analyser ; ne le convertissez pas automatiquement en succès ou en échec. Sur le plan opérationnel, la normalisation doit être réversible : l’équipe doit pouvoir consulter la valeur reçue et la règle ayant produit sa classification.
- Ne supprimez pas le code d’origine lors du calcul des indicateurs ou de la mise à jour des états internes.
- Documentez chaque équivalence en précisant sa source, son périmètre et sa date de révision.
- Prévoyez une catégorie « inconnu » et un processus d’examen des nouvelles valeurs.
- Évitez de regrouper des états distincts, sauf si le fournisseur confirme qu’ils représentent la même situation.
Corréler chaque événement avec le bon envoi
Un identifiant de message peut varier d’un système à l’autre. Le contrat doit expliquer quel identifiant est généré par chaque participant, où il est renvoyé et comment il est associé à l’identifiant connu de l’application qui a envoyé le message. En cas de traduction, enregistrez la relation entre les valeurs au lieu de supposer qu’elles sont interchangeables.
Définissez la clé, ou la combinaison de clés, utilisée par votre intégration pour retrouver l’envoi associé. Précisez la marche à suivre en cas d’identifiant manquant, sans correspondance ou de correspondances multiples. N’attribuez pas un DLR sur la seule base d’une similitude entre des données qui n’a pas été convenue comme critère valide.
- Documentez le parcours des identifiants, de l’envoi au rapport.
- Testez les correspondances valides ainsi que les identifiants absents, inconnus et répétés.
- Conservez les valeurs source et cible de chaque traduction.
- Envoyez les événements sans correspondance dans une file ou un processus d’investigation, sans leur attribuer arbitrairement un envoi.
Gérer les doublons, les retards et les événements non reconnus
Convenez de la manière d’identifier et de traiter les événements répétés, tardifs ou reçus dans un ordre différent de celui attendu. Les informations techniques disponibles ne définissent aucune règle universelle de déduplication ou de séquencement applicable à tous les fournisseurs. Le contrat doit donc préciser les données permettant de reconnaître un doublon, la durée de conservation des informations nécessaires et la résolution des événements contradictoires.
Ne remplacez pas un état antérieur au seul motif qu’un autre événement est arrivé plus tard : l’ordre de réception ne reflète pas nécessairement l’ordre réel des événements. Déterminez avec chaque fournisseur quels horodatages sont pertinents et quelle règle de priorité, le cas échéant, est documentée. En l’absence de règle vérifiable, conservez l’historique et soumettez les cas ambigus à examen.
- Définissez le critère permettant d’identifier un doublon et les conséquences de sa réception répétée.
- Enregistrez séparément l’heure de réception locale et les horodatages communiqués, s’ils sont disponibles.
- Précisez le traitement des états tardifs, inconnus, contradictoires et sans correspondance.
- Rendez traçable la logique de mise à jour et évitez de supprimer l’historique d’origine.
Tester le contrat à l’aide de cas d’acceptation convenus
Préparez des tests communs avec des exemples approuvés par les participants. Ils visent à vérifier le format reçu, la validation des champs, le mappage des états et la corrélation ; ils ne démontrent pas à eux seuls qu’un téléphone a reçu le message. La liste des codes et des résultats attendus doit s’appuyer sur la documentation et l’accord technique des fournisseurs concernés.
Effectuez les tests dans un environnement adapté et consignez l’entrée, le résultat attendu, le résultat observé et la décision. Si le format réel diffère du contrat ou qu’un état n’est pas documenté, suspendez l’acceptation de cette variante jusqu’à la résolution de l’écart.
- Événement valide contenant tous les champs convenus.
- Champ facultatif absent et champ obligatoire absent, avec le comportement attendu documenté pour chacun.
- État connu, code d’origine préservé et mappage attendu.
- Code ou état inconnu, sans classification automatique comme succès.
- Événement répété, tardif, reçu dans le désordre et sans identifiant permettant la corrélation.
- Format comportant des champs ajoutés, omis ou renommés, ou dont le type diffère, selon les limites définies dans le contrat.
Gérer les versions du contrat et maîtriser les évolutions
Traitez le format et le mappage comme un contrat partagé, et non comme une hypothèse implicite dans le code. Identifiez chaque version, conservez l’historique des modifications et indiquez quels systèmes l’acceptent. Avant de déployer une modification, déterminez si elle concerne la structure, le type d’un champ, la sémantique d’un état ou la corrélation.
Convenez avec chaque participant d’un processus de notification, d’examen et de test. Ne déclarez pas une modification compatible au seul motif que le message reste syntaxiquement valide : un libellé inchangé peut prendre un autre sens, et un champ ajouté peut affecter les consommateurs qui valident strictement le format. La compatibilité doit être vérifiée au regard des règles propres à l’intégration.
- Attribuez une version identifiable au contrat et aux tables de correspondance.
- Évaluez séparément les évolutions de format et les évolutions sémantiques.
- Exécutez les cas d’acceptation convenus avant d’activer une nouvelle version.
- Définissez comment notifier, accepter ou refuser les changements incompatibles.
Un DLR communiqué ne prouve pas à lui seul la réception sur le terminal
Interprétez le DLR dans les limites documentées par son émetteur. Un état communiqué par un maillon indique ce que ce système rapporte ; il ne doit pas être présenté automatiquement comme une confirmation indépendante que le message est apparu sur le terminal ou a été reçu par son utilisateur. Les informations disponibles ne permettent pas d’affirmer qu’un état particulier garantit cette réception.
Dans les rapports opérationnels, distinguez les événements reçus de toute vérification indépendante disponible et indiquez les limites de celle-ci. N’utilisez pas le DLR comme preuve de consentement, d’identité ou de lecture du message. Si une décision métier dépend de la réception effective, définissez à l’avance les éléments considérés comme suffisants et consultez la documentation des systèmes concernés.
- Présentez l’état comme communiqué par sa source, sans lui donner une portée plus large que celle étayée par la documentation.
- Distinguez la réception du DLR, l’état normalisé et les éléments de preuve indépendants disponibles.
- Faites apparaître les cas inconnus ou ambigus dans les indicateurs et les rapports, au lieu de les forcer dans une catégorie définitive.
Questions fréquentes
Existe-t-il une liste universelle d’états DLR que tous les fournisseurs doivent utiliser ?
Les informations techniques disponibles pour ce guide ne permettent pas d’établir une liste universelle ni des équivalences entre fournisseurs. Demandez la documentation de chaque participant et convenez explicitement des états et des codes qui seront mappés.
Dois-je remplacer le code d’origine par un état normalisé ?
Non. Conservez le code, le texte et la source d’origine à côté de l’état normalisé et de la règle de mappage appliquée. Vous pourrez ainsi examiner les écarts et réviser le mappage si la documentation évolue.
Que faire d’un DLR en double ou sans correspondance ?
Définissez dans le contrat la manière d’identifier et d’enregistrer les doublons. Pour un événement sans correspondance, conservez les données reçues et soumettez le cas à investigation ; ne l’associez pas à un envoi sur la base d’une correspondance non convenue.
Un DLR confirme-t-il que le SMS est arrivé sur le téléphone ?
Pas nécessairement. Le DLR communique l’état rapporté par un système de la chaîne et sa portée dépend de la définition de l’émetteur. Ne le présentez pas comme une preuve indépendante de réception sur le terminal en l’absence d’éléments documentés à l’appui.
Que faut-il tester avant d’accepter une modification de format ?
Vérifiez les champs obligatoires et facultatifs, les types et formats convenus, la conservation des valeurs d’origine, le mappage des états, la corrélation et le traitement des valeurs inconnues, répétées ou tardives. Les participants doivent avoir documenté les résultats attendus.
Sources consultées
- SMPP v3.4 Issue 1.2SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA Networks resourcesGSMA