Tests d’acceptation lors d’un changement de fournisseur A2P SMS : comment valider avant la bascule
Un guide pour convenir de tests reproductibles de connectivité, de réponses, de callbacks et de statuts avant de migrer le trafic A2P. L’acceptation technique ne signifie pas que le SMS a été reçu sur le terminal.
Ce que valide un test d’acceptation et ce qui n’en fait pas partie
Un test d’acceptation vérifie si une intégration et son exploitation se comportent conformément aux exigences convenues pour un cas donné. Lors d’un changement de fournisseur A2P, il peut vérifier que le système envoie des requêtes, interprète les réponses, traite les callbacks et consigne les événements nécessaires.
L’acceptation technique ne prouve pas, à elle seule, que le SMS est arrivé sur le terminal du destinataire et ne garantit pas que les performances observées se maintiendront après la bascule. Une réponse HTTP satisfaisante confirme une réponse de cette interface, pas la réception finale du message. De même, un statut de livraison signalé doit être considéré comme une information du système qui l’a émis, et non comme une preuve indépendante de réception sur l’appareil.
- Définissez séparément ce que valide l’interface, ce que signale le fournisseur et quels éléments attestent la livraison.
- Documentez les limites du test : environnement, destinations, expéditeurs, types de messages, période d’observation et dépendances externes.
Définir le périmètre et les responsabilités
Avant d’exécuter les tests, convenez de ce qui est intégré ou migré. Précisez l’interface utilisée — HTTP ou SMPP —, les destinations et les expéditeurs concernés, les types de messages autorisés et le système responsable de chaque étape. Pour SMPP, la spécification SMPP v3.4 peut servir de référence technique pour convenir des paramètres et des réponses ; les détails concrets doivent être vérifiés par rapport à la version et au profil d’intégration convenus.
Ne partez pas du principe que tous les fournisseurs interprètent de la même façon chaque champ, statut ou comportement opérationnel. Préparez une matrice des exigences indiquant, pour chaque cas, la requête attendue, la réponse à consigner, l’entité qui la produit et les critères de réussite ou d’échec. Les critères et les conditions d’arrêt ou de retour arrière relèvent des décisions du projet, et non de seuils universels.
- Notez l’interface, la version ou le profil applicable, ainsi que la configuration testée.
- Délimitez les destinations, les expéditeurs et les catégories de trafic concernés ; indiquez explicitement les exclusions.
- Attribuez les responsabilités au client, au fournisseur et à tout système intermédiaire.
- Convenez à l’avance des critères d’acceptation, des incidents bloquants et des conditions de suspension ou de retour arrière.
Préparer l’environnement et les données de test
Utilisez un environnement et un trafic de test autorisés, dont le périmètre a été convenu entre les parties. Lorsqu’il est impossible de séparer entièrement l’infrastructure de production, documentez les composants partagés et la manière dont l’impact est limité. N’envoyez pas de messages à des numéros ou à des personnes sans autorisation.
N’incluez que les données nécessaires à l’exécution et au diagnostic de chaque cas. Définissez qui peut consulter les journaux, comment ils sont protégés et combien de temps ils sont conservés, conformément aux politiques et obligations applicables. Les références techniques générales ne définissent pas de procédure universelle d’isolation, de consentement ou de conservation : ces aspects doivent être confirmés au regard des règles en vigueur et avec les responsables concernés.
- Confirmez l’autorisation, les destinations de test et les expéditeurs avant d’envoyer du trafic.
- Utilisez des identifiants de test distincts de ceux de la production, si l’intégration le permet.
- Évitez d’inclure des données personnelles inutiles dans le contenu, les journaux ou les captures d’écran.
- Vérifiez que l’équipe sait comment interrompre les tests si le trafic sort du périmètre convenu.
Élaborer des cas positifs et négatifs
Un test utile ne se limite pas à envoyer un message valide. Il doit aussi vérifier le comportement de l’intégration face à des entrées incorrectes, des réponses inattendues ou des interruptions. La sémantique HTTP est définie par la RFC 9110, mais la signification d’une réponse dans le flux SMS dépend également du contrat et de la conception de l’intégration.
Pour chaque cas, consignez le résultat attendu et les éléments de preuve qui permettront de le comparer. N’inventez pas de codes d’erreur et ne supposez pas qu’un comportement est commun à tous les fournisseurs : confirmez les valeurs et règles applicables dans la documentation technique convenue.
- Cas valide : champs obligatoires présents et valeurs conformes au format convenu.
- Cas invalide : omission d’un champ obligatoire ou format non accepté, selon le contrat d’interface.
- Rejet : requête non acceptée par le fournisseur ; vérifiez que le client conserve et classe correctement la réponse.
- Délai d’attente dépassé ou interruption : vérifiez comment l’incertitude est consignée et quelle action ultérieure est autorisée ; évitez les nouvelles tentatives automatiques susceptibles de dupliquer les messages sans règle convenue.
- Limite de trafic : testez uniquement le volume et les conditions autorisés, avec des limites définies par le projet.
Vérifier les identifiants, les callbacks et la traçabilité
Vérifiez que chaque envoi peut être associé à sa réponse et aux événements ultérieurs faisant partie de l’intégration. Convenez de l’identifiant renvoyé ou généré par chaque système, du moment où il est consigné et de la manière dont il est lié aux callbacks. Ne partez pas du principe que les identifiants ont le même format ou la même portée d’une plateforme à l’autre.
Testez également les callbacks effectivement configurés : réception, authenticité selon le mécanisme convenu, traitement des doublons et consignation des échecs de traitement. Les comportements attendus doivent être définis par les spécifications et l’accord d’intégration ; il n’existe pas de règle universelle que l’on puisse déduire du seul nom de l’événement.
- Faites le lien entre la requête, la réponse et le callback à l’aide des identifiants disponibles et documentés.
- Consignez la date et l’heure, l’environnement, la destination de test, le résultat et la version de configuration nécessaires à la reproduction du cas.
- Vérifiez qu’un callback n’est pas associé à un autre envoi et que les événements répétés sont traités selon la règle convenue.
- Conservez les éléments de preuve techniques avec un accès et une durée de conservation adaptés, sans exposer de secrets ni de données inutiles.
Interpréter les statuts et les DLR avec prudence
Incluez dans la matrice les statuts convenus avec l’intégration et le fournisseur, mais ne considérez pas leurs libellés comme universels. Documentez le système à l’origine de chaque statut, sa signification dans ce système et les incertitudes qui subsistent. Si un événement n’arrive pas, arrive en retard ou ne correspond pas au résultat attendu, consignez-le comme un écart à examiner, et non comme une conclusion automatique concernant le terminal.
Un DLR ou un statut communiqué par un fournisseur ne correspond pas nécessairement à une vérification indépendante de la réception du message sur l’appareil du destinataire. Le test doit distinguer la cohérence du rapport de statut de tout élément supplémentaire attestant la réception, si un tel élément existe et est accessible.
- Comparez les statuts observés à la définition documentée pour cette intégration.
- Consignez les événements absents, tardifs, répétés ou difficiles à corréler.
- Ne transformez pas un statut signalé en garantie de réception sur le terminal.
Mesurer la disponibilité et la latence sans extrapoler
Si la disponibilité, la latence ou la cohérence doivent être évaluées, convenez de la période d’observation, des points de mesure, de la population de test et du mode de calcul de chaque indicateur. Distinguez le temps de réponse de l’interface des délais associés aux statuts ultérieurs : ils mesurent des étapes différentes.
Il n’existe pas de valeurs universelles de latence, de disponibilité, de taille d’échantillon ou de limite de trafic pouvant servir de critères d’acceptation pour tous les projets. Un échantillon réduit et limité à certaines destinations ne permet pas non plus de généraliser les performances futures. Définissez les seuils avec les parties en fonction de l’usage prévu et de l’accord applicable, et précisez ce qui n’est pas couvert par la mesure.
- Indiquez le point de départ et le point d’arrivée de chaque mesure.
- Consignez la période, le nombre et le périmètre des tests, sans présenter l’échantillon comme représentatif s’il ne l’est pas.
- Distinguez les résultats par interface, destination et type d’événement lorsque les données le permettent.
- Comparez les résultats uniquement aux critères approuvés avant leur observation.
Clore l’acceptation avec des éléments de preuve et une décision reproductible
Rassemblez les résultats dans un registre qu’une autre personne pourra examiner et reproduire. Pour chaque cas, indiquez la configuration pertinente, les données de test non sensibles, le résultat attendu, le résultat observé, la référence aux éléments de preuve, le responsable et l’incident associé. Séparez les observations des interprétations.
La décision finale doit préciser ce qui a été accepté, ce qui reste soumis à conditions et qui l’a autorisée. Si un test échoue ou ne peut pas être exécuté, documentez la limite et convenez de l’étape suivante avant la bascule. Définissez explicitement la procédure de suspension ou de retour arrière avec les responsables ; aucune condition technique universelle ne peut se substituer à cette décision.
- Conservez la matrice des cas et le registre des résultats dans un emplacement contrôlé.
- Classez les incidents selon leur impact convenu et attribuez un responsable ainsi qu’une date de suivi.
- Documentez les limites de couverture du test et les dépendances non vérifiées.
- Consignez l’approbation, les conditions en attente et la procédure convenue pour arrêter ou revenir en arrière.
Questions fréquentes
Une réponse HTTP satisfaisante confirme-t-elle que le SMS a été livré ?
Non. Elle confirme une réponse satisfaisante de l’interface selon la sémantique HTTP applicable. À elle seule, elle ne prouve pas que le message est arrivé sur le terminal.
Un DLR confirme-t-il que le destinataire a reçu le message sur son appareil ?
Il ne faut pas le supposer. Un DLR est un statut signalé par le système qui l’émet ; il ne correspond pas nécessairement à une vérification indépendante de la réception sur le terminal.
Quels seuils de latence ou de disponibilité dois-je utiliser pour approuver le fournisseur ?
Il n’existe pas de valeurs universelles adaptées à tous les cas. Définissez avec les parties la période, les points de mesure, le périmètre et les seuils en fonction de l’usage prévu et de l’accord applicable.
Que dois-je tester avant la bascule ?
Au minimum, convenez de cas couvrant les entrées valides et invalides, les réponses, les délais d’attente dépassés, les limites autorisées, la corrélation des identifiants, les callbacks et les statuts faisant partie de l’intégration. Ajoutez des critères d’acceptation et des conditions de suspension ou de retour arrière.
Les tests d’acceptation garantissent-ils les performances après la migration ?
Non. Ils décrivent le comportement observé dans un environnement, un périmètre et une période donnés. Ils ne garantissent pas les résultats futurs et ne permettent pas de généraliser au-delà des éléments de preuve recueillis.
Sources consultées
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- E.164: The international public telecommunication numbering planInternational Telecommunication Union
- GSMA networks resourcesGSMA