Contrat de données opérationnelles A2P SMS : champs et sémantique

À quoi sert un contrat de données opérationnelles ?

Dans le trafic A2P SMS — des messages envoyés depuis une application ou un système vers une personne — plusieurs organisations peuvent enregistrer le même message à différents moments et employer des vocabulaires différents. Un contrat de données opérationnelles réduit les ambiguïtés en précisant la signification de chaque champ, la partie qui le renseigne et la manière dont les événements sont liés entre eux.

Il ne s’agit ni d’une norme universelle ni d’une garantie de livraison. C’est un accord entre les parties pour échanger et rapprocher des informations. Il doit distinguer les décisions propres à l’accord des exigences d’une interface ou d’une spécification technique applicable. Les références normatives, comme SMPP ou HTTP, doivent être consultées directement avant de leur attribuer des exigences précises.

• Convenez du schéma avant d’intégrer ou de modifier l’échange de données.
• Documentez les définitions, les formats, les vocabulaires et les responsabilités associés aux champs.
• Traitez l’interprétation des statuts comme un accord explicite, et non comme une équivalence supposée entre systèmes.

Acteurs et limites des responsabilités

Une chaîne peut inclure l’entreprise à l’origine du trafic, une plateforme de messagerie, un ou plusieurs fournisseurs et un opérateur mobile. Le parcours concret et la participation de chaque entité dépendent de l’accord et de la configuration du service ; il ne faut pas présumer que la chaîne est identique dans tous les cas.

Pour chaque donnée, précisez qui la génère, qui la transmet, qui peut la transformer et qui est responsable de son interprétation. Par exemple, l’expéditeur peut déclarer le type de trafic ; une plateforme peut attribuer un identifiant interne ; et un fournisseur peut communiquer un statut reçu d’un autre système. Il s’agit de répartitions possibles dans la conception, pas de responsabilités universelles.

La séparation des responsabilités aide à examiner les écarts : une partie peut confirmer qu’elle a accepté une demande sans affirmer que le réseau l’a livrée, tandis qu’une autre peut signaler un résultat ultérieur, dans les limites des informations dont elle dispose.

• Attribuez un responsable à chaque champ et à chaque transition de statut.
• Indiquez où s’arrête la responsabilité de chaque partie en matière d’information.
• Prévoyez un contact et une procédure de rapprochement en cas d’écart, sans supposer que toutes les parties observent les mêmes événements.

Champs minimaux et signification

Le jeu de données minimal dépend de l’objectif : exploitation, assistance, rapprochement ou analyse. Il est préférable de commencer par les données nécessaires pour relier une demande aux événements ultérieurs, puis d’ajouter uniquement les champs que les parties peuvent produire et utiliser selon une définition précise.

Documentez au minimum un identifiant de message par système et, le cas échéant, les identifiants permettant la corrélation entre systèmes. Incluez la destination au format convenu, l’expéditeur, la classification déclarée du trafic — par exemple OTP, transactionnel ou marketing — et, si elle est connue, la route déclarée. Ne présentez pas une route déclarée comme une preuve indépendante du parcours réellement suivi.

Il est également utile d’inclure le statut, sa source, l’horodatage de l’événement et le code d’erreur, le cas échéant. Si l’opérateur de destination est communiqué, indiquez comment il a été déterminé et à quel moment. Ne renseignez pas un opérateur inconnu par déduction. Définissez aussi la version des conditions ou de l’accord opérationnel applicable, avec son identifiant et la date ou la période de validité convenue.

• Identifiants : identifiant du message dans le système expéditeur et références de corrélation disponibles.
• Contexte : destination, expéditeur, classification du trafic, route déclarée et opérateur, si connu.
• Événement : statut, source du statut, date et heure, code d’erreur et version des conditions.
• Pour chaque champ, précisez le type, le format, le caractère obligatoire, le vocabulaire et la signification.

Statuts : acceptation, envoi, DLR et résultat inconnu

Ne réduisez pas tout le cycle à un champ générique unique de « statut ». Définissez les étapes que l’accord doit distinguer : par exemple, demande acceptée par une interface, tentative d’envoi signalée par une partie, rapport de livraison reçu ou résultat encore inconnu. Les noms exacts et les transitions doivent être convenus pour chaque intégration.

Un DLR est un rapport de statut reçu d’une source déterminée. Consignez qui l’a émis ou transmis et ce qu’il signifie dans ce contexte. À lui seul, il ne constitue pas une vérification indépendante indiquant que le message est apparu sur le terminal ou a été lu par son destinataire.

Conservez un statut inconnu lorsque les informations sont insuffisantes pour conclure. Ne transformez pas automatiquement l’absence de DLR en échec, ni un statut favorable signalé en garantie de réception. Si deux sources divergent, conservez les deux événements et documentez celui que chaque processus utilise, ainsi que la raison de ce choix.

• Définissez chaque statut par une description, son émetteur et les transitions autorisées.
• Distinguez le statut signalé de l’évaluation interne qu’une partie fait du cas.
• Conservez les événements d’origine pour pouvoir reconstituer la séquence et résoudre les écarts.

Horodatages et ordre des événements

Un horodatage doit permettre de comprendre quand l’événement s’est produit ou a été enregistré, ainsi que le fuseau horaire concerné. Convenez du format, de la précision disponible et indiquez si la date correspond au moment de l’événement, à la réception du rapport ou à son enregistrement dans le système.

Ne déduisez pas l’ordre des événements uniquement de leur heure d’arrivée sur une plateforme : ils peuvent être reçus dans un ordre différent de celui que leur attribue chaque partie. Conservez les identifiants d’événement ou les séquences lorsqu’ils sont disponibles, et consignez séparément les horodatages d’origine et de réception si cela est nécessaire au rapprochement.

Si une source ne fournit pas de fuseau horaire ou une précision suffisante, indiquez-le. Ne complétez pas ces données comme si elles avaient été observées.

• Convenez du format de date et d’heure, du fuseau horaire et de la précision.
• Distinguez l’heure de l’événement, l’heure de réception et l’heure de traitement.
• Définissez comment ordonner les événements lorsque les horodatages coïncident ou sont incomplets.

Provenance des données et niveau de preuve

Une même valeur peut avoir un poids différent selon la partie qui l’a déclarée et la manière dont elle a été obtenue. Ajoutez des métadonnées de provenance lorsqu’elles facilitent l’interprétation de l’enregistrement : système d’origine, partie qui transmet la donnée, moment de l’observation et nature de la donnée — déclarée, issue d’un événement reçu ou observée de manière indépendante.

Par exemple, une plateforme peut déclarer une route, tandis qu’un statut peut provenir du rapport d’un fournisseur. Le contrat doit éviter que la transformation ou l’agrégation des données efface cette distinction. En l’absence de vérification indépendante, indiquez-le au lieu de le laisser entendre.

Définissez également les éléments de preuve acceptés pour chaque usage : assistance, rapprochement ou analyse. Une valeur utile pour une investigation ne suffit pas nécessairement à trancher un litige commercial.

• Indiquez la provenance de la donnée et la partie qui l’a communiquée.
• Distinguez l’observation directe, la déclaration et l’événement reçu.
• Ne transformez pas un statut transmis en une affirmation plus forte que ne le permettent les informations de la source.

Valeurs nulles, vocabulaires et codes d’erreur

Un champ vide peut signifier que la valeur est inconnue, qu’elle n’a pas été collectée, qu’elle ne s’applique pas ou qu’elle n’a pas été reçue. Le contrat doit distinguer ces cas au lieu de laisser chaque système les interpréter à sa manière. Si le format d’échange ne permet pas de représenter ces différences, documentez une convention commune et ses limites.

Définissez des vocabulaires contrôlés pour les catégories et les statuts, et convenez de la manière de traiter les valeurs propres à un fournisseur. Conservez le code d’origine en parallèle d’une catégorie normalisée si une comparaison entre parties est nécessaire. La normalisation ne doit pas effacer la valeur qui permet d’examiner l’événement dans le système source.

Avant d’ajouter des codes, des statuts ou des expéditeurs à une liste convenue, précisez qui peut les proposer, comment ils sont documentés et à partir de quand ils s’appliquent. Ne réutilisez pas une ancienne valeur avec une nouvelle signification.

• Distinguez explicitement les valeurs inconnues, absentes, non applicables et non reçues.
• Conservez la valeur d’origine et, si les parties en conviennent, ajoutez une valeur normalisée.
• Publiez des définitions et des exemples pour les codes propriétaires, sans les présenter comme universels.

Gestion des versions et évolution du schéma

Chaque échange devrait permettre d’identifier la version du schéma et celle des conditions opérationnelles appliquées. Convenez de la manière de communiquer cette version et de son lien avec la période du trafic, sans supposer que le nom d’une interface suffit à identifier les règles.

Définissez à l’avance un processus de changement : qui propose les modifications, qui les approuve, comment elles sont testées et quand elles entrent en vigueur. L’adoption d’un champ facultatif supplémentaire peut être plus simple que celle d’un changement qui modifie la signification d’un statut ou rend une donnée obligatoire ; évaluez l’impact avec les consommateurs concernés.

Pendant une transition, indiquez quelles versions peuvent coexister, comment identifier les enregistrements et pendant combien de temps la compatibilité est conservée, si les parties conviennent d’une durée. Évitez de modifier la sémantique sans changer la version ou sans communiquer le changement sans ambiguïté.

• Versionnez le schéma et consignez la version des conditions applicables.
• Classez les changements selon leur impact sur les producteurs, les consommateurs et les processus de rapprochement.
• Convenez des approbations, des tests, de la date d’entrée en vigueur et du traitement des versions antérieures.