Évolutions des intégrations HTTP et SMPP pour les SMS A2P : valider la compatibilité avant le déploiement

Quels changements justifient une régression et quelles sont ses limites

Un test de régression d’intégration vérifie qu’un changement n’a pas modifié le contrat technique entre une application et son interface SMS. Il est recommandé d’en effectuer un lorsque l’application cliente, le connecteur, la configuration du transport ou l’interprétation des réponses et des états évolue. HTTP et SMPP sont des interfaces différentes : un test concluant sur l’une ne valide pas automatiquement l’autre.

Le périmètre doit être explicite. Une réponse HTTP satisfaisante confirme le résultat de la requête selon la sémantique HTTP, pas la livraison du SMS à l’appareil. De même, établir une session SMPP ou recevoir une réponse à une opération d’envoi ne démontre pas, à lui seul, que le destinataire a reçu le message. La livraison et la signification des états ultérieurs dépendent des éléments de preuve disponibles et de la documentation applicable.

• À inclure : compatibilité des requêtes, champs, encodage convenu, interprétation des réponses, corrélation des identifiants et gestion des déconnexions.
• À traiter séparément : acceptation technique, progression ultérieure du message et réception confirmée sur un terminal.
• Ne remplacez pas une évaluation de l’acheminement, de la couverture ou de la qualité de livraison par un test d’intégration.

Contrat technique : champs, encodage, expéditeur, références et sémantique

Avant de rédiger les tests, transformez la documentation en vigueur de l’API ou du fournisseur SMPP en un contrat vérifiable. La documentation générique ne permet pas de supposer quels champs sont obligatoires, comment l’expéditeur est exprimé, quels encodages sont pris en charge, quel est le format d’un identifiant ni quels états sont renvoyés. Consignez chaque règle avec sa source et confirmez tout point ambigu auprès de la spécification ou du fournisseur concerné.

Pour chaque champ, indiquez s’il est obligatoire ou facultatif, son format, les limites documentées, sa valeur par défaut le cas échéant et le comportement attendu s’il est absent ou invalide. Pour l’encodage, définissez les cas de texte autorisés par le contrat et la manière dont vous vérifierez que le contenu reçu par l’interface conserve le sens attendu. Ne présumez pas que deux connecteurs interprètent les caractères, les expéditeurs ou les références de la même manière.

Définissez aussi la sémantique des réponses : ce que signifient l’acceptation ou le rejet dans cette interface, quel identifiant est renvoyé et comment il est associé à l’état ultérieur. Pour SMPP, utilisez la spécification de la version convenue et l’implémentation faisant l’objet du contrat pour interpréter les opérations, réponses, champs et états ; ne déduisez pas les détails d’une intégration à partir de la documentation d’une autre.

• Tenez un tableau par interface indiquant le champ, la règle documentée, la validation et le résultat attendu.
• Distinguez l’identifiant de requête de l’identifiant de message si le contrat les différencie ; documentez leur portée et leur utilisation.
• Conservez des exemples représentatifs et sûrs, sans données personnelles réelles ni identifiants d’accès, afin de pouvoir répéter les tests.

Cas de test HTTP et SMPP : acceptation, rejet et reprise

Constituez une batterie de tests pour chaque interface. Pour HTTP, vérifiez les requêtes valides ainsi que les entrées que le contrat définit comme invalides ; contrôlez que l’application interprète correctement la réponse et conserve les informations de corrélation nécessaires. Les codes d’état HTTP décrivent le résultat de l’interaction HTTP conformément à la RFC 9110, mais leur signification pour l’envoi de SMS doit être définie par le contrat de l’API.

Pour SMPP, testez séparément la connexion et les opérations d’envoi définies pour la version et le fournisseur utilisés. Vérifiez la réponse du protocole et la gestion des rejets documentés. La spécification SMPP v3.4 sert de référence pour les opérations et réponses de cette version, mais les résultats concrets à attendre dépendent du contrat applicable.

Ajoutez des scénarios de délai d’attente, de déconnexion et de reprise, sans imposer un comportement universel. Définissez d’abord ce que le contrat prévoit pour les nouvelles tentatives, les requêtes dont le résultat est inconnu et la reconnexion. En l’absence de règle documentée, consignez le point comme une décision en suspens plutôt que de transformer une supposition en critère de validation.

• Testez l’acceptation technique avec des données de test autorisées et un destinataire contrôlé.
• Incluez les rejets attendus et vérifiez que le système ne les enregistre pas comme des acceptations.
• Simulez des délais d’attente et des déconnexions dans un environnement contrôlé ; vérifiez le comportement convenu et conservez les éléments de preuve.
• Ne renvoyez pas automatiquement un message dont le résultat est incertain, sauf si le contrat et la conception de l’application définissent comment éviter les conséquences indésirables.

Callbacks et états corrélés : ce que démontre un DLR

Si l’intégration utilise des callbacks ou des notifications d’état, testez le parcours complet entre l’acceptation initiale et l’événement ultérieur défini par le contrat. Vérifiez que la notification peut être associée au bon envoi à l’aide des identifiants documentés et que l’application distingue l’absence d’événement, la réception d’un événement et l’état final signalé.

Ne présumez pas que les callbacks ont les mêmes champs, le même ordre ou la même sémantique chez tous les fournisseurs. Vérifiez le format, l’authenticité, les répétitions et le traitement des événements tardifs dans la documentation de l’intégration. Si un aspect n’est pas spécifié, délimitez l’incertitude et convenez de la manière dont il sera observé en exploitation.

Un DLR signale un état au sein du système qui l’émet et le transmet ; à lui seul, il ne constitue pas nécessairement une vérification indépendante de la réception sur mobile. Dans les éléments de preuve du test de régression, indiquez clairement ce qui a été observé : réponse d’API, réponse SMPP, callback ou vérification indépendante du terminal, si cette dernière existe.

• Vérifiez que chaque événement est associé à la bonne référence conformément au contrat.
• Consignez la source et le moment d’observation de chaque état.
• Distinguez les états signalés par l’acheminement de la réception vérifiée de façon indépendante.

Comparer l’avant et l’après à l’aide de critères et de preuves

Exécutez le même ensemble de cas sur la version précédente et la nouvelle, dans des conditions comparables. Comparez les résultats par interface et par scénario, et pas seulement le pourcentage global de tests réussis. Une différence peut être attendue si le contrat a délibérément changé ; elle doit être documentée, approuvée et intégrée aux tests avant le déploiement.

Conservez la version de l’application et du connecteur, la configuration pertinente non secrète, le cas exécuté, la réponse observée et le résultat attendu. Stockez les données sensibles conformément aux politiques applicables et évitez d’inclure des identifiants d’accès ou des informations personnelles inutiles dans les journaux partagés.

Définissez les critères de validation avant l’exécution. Au minimum, les cas obligatoires du contrat doivent produire le résultat attendu et toute différence inexpliquée doit faire l’objet d’une investigation. Ne fixez pas de seuils de latence, de disponibilité ou de livraison sans spécification applicable et mesure adéquate.

• Classez chaque différence comme un changement prévu, une régression confirmée ou un résultat encore inexpliqué.
• Comparez les codes et les corps des réponses HTTP selon l’API ; comparez les réponses SMPP selon la version et l’implémentation convenues.
• Joignez suffisamment d’éléments de preuve pour pouvoir répéter le cas sans exposer de secrets.

Déploiement progressif et retour arrière sans confondre tests et production

Commencez par tester dans un environnement et avec des destinataires de test autorisés, dans la mesure où ils sont disponibles et documentés. Séparez les identifiants d’accès, la configuration et les éléments de preuve de test de ceux de production. En l’absence d’environnement de test adéquat, limitez toute validation à ce qui est approuvé pour la production et aux règles applicables en matière de consentement et de conformité.

Avant le déploiement, convenez de la personne qui décide de poursuivre ou d’interrompre le changement, des cas qui doivent être validés et des signaux qui imposent une investigation ou un retour arrière. Le retour arrière doit correspondre à une procédure testée pour l’application et le connecteur ; il n’existe pas de règle universelle d’infrastructure qui puisse être définie sans connaître le système.

Lors de tout déploiement progressif, identifiez clairement la version qui génère chaque requête et conservez une observabilité suffisante pour distinguer les erreurs d’intégration des résultats ultérieurs de livraison. N’interprétez pas une réponse technique satisfaisante comme une preuve de qualité de l’acheminement.

• Vérifiez qu’une version ou configuration précédente peut être restaurée et que la procédure de retour arrière a été validée.
• Définissez les responsables, les critères d’arrêt et les éléments de preuve minimaux avant de commencer le changement.
• Identifiez le trafic de test et séparez-le du trafic de production.

Liste de contrôle pour préserver la compatibilité

Une intégration reste compatible lorsque ses règles sont consultables, ses tests reproductibles et les changements intentionnels distincts des régressions. Revoyez le contrat lors de toute évolution d’une version d’API, d’une spécification SMPP, d’un connecteur ou d’une configuration affectant les champs, les réponses ou les états. La référence doit toujours être la documentation en vigueur de l’interface concernée.

Utilisez cette liste avant d’approuver un changement :

• La version et l’interface HTTP ou SMPP testées sont-elles documentées ?
• Chaque champ, encodage, expéditeur et identifiant est-il régi par une règle étayée par la documentation ?
• Des cas distincts couvrent-ils l’acceptation, le rejet, le délai d’attente, la déconnexion et la reprise ?
• Les callbacks et les états sont-ils corrélés conformément au contrat, et leur émetteur est-il identifié ?
• Les éléments de preuve distinguent-ils l’acceptation technique, le DLR et la réception vérifiée sur le terminal ?
• Les différences par rapport à la version précédente sont-elles expliquées et approuvées ?
• Les responsables, les critères d’arrêt et la procédure de retour arrière sont-ils définis ?
• Les tests et le trafic de production sont-ils séparés et conformes aux règles applicables ?