Checklist de mise en production des connexions SMS A2P HTTP et SMPP

Que signifie être prêt pour la production ?

Une connexion HTTP ou SMPP opérationnelle confirme uniquement qu’un certain niveau de communication avec le système distant existe. Elle ne prouve pas que le fournisseur a accepté chaque message, qu’un rapport de remise a été reçu ni que le SMS est arrivé sur l’appareil.

Il est préférable de distinguer l’acceptation de la connexion, l’acceptation de chaque envoi et les preuves de remise. Définissez le résultat attendu à chaque étape et la source qui le fournit. Un DLR est un rapport reçu ; à lui seul, il ne constitue pas une vérification indépendante sur le téléphone.

Avant d’ouvrir le trafic, convenez de son périmètre : destinations, expéditeurs, types de messages, volumes prévus, horaires, responsables et conditions d’autorisation et de conformité applicables. L’acceptation technique ne remplace pas la vérification des autorisations, du consentement ni des règles locales.

• Documentez ce qui constitue un test de connectivité réussi et ce qui constitue un test de remise.
• Convenez avec votre interlocuteur des paramètres d’intégration et des résultats attendus ; ne présumez pas de valeurs qui ne sont pas documentées.
• Excluez des critères d’acceptation toute garantie de remise qui n’est pas étayée par des preuves et des conditions convenues.

Préparer l’environnement et séparer les tests du trafic réel

Dans la mesure où l’architecture et le fournisseur le permettent, séparez les environnements, identifiants, destinations et expéditeurs de test de ceux de production. Si la séparation technique n’est pas complète, documentez les mesures de protection empêchant les tests d’atteindre de vrais destinataires.

Stockez les identifiants à l’aide de mécanismes d’accès restreint et évitez de les inclure dans les journaux, les tickets ou les exemples partagés. Accordez les droits uniquement aux personnes qui en ont besoin et définissez la marche à suivre en cas d’exposition d’un identifiant.

Utilisez uniquement des destinations et des contenus autorisés pour les tests. Avant tout envoi, vérifiez le périmètre et l’approbation du trafic, notamment pour les messages marketing, les OTP ou les communications transactionnelles.

• Inventoriez les identifiants, hôtes, ports, expéditeurs, destinations et responsables de chaque environnement.
• Vérifiez que les messages de test sont identifiés et ne sont pas mélangés aux rapports du trafic de production.
• Déterminez qui peut activer le trafic et qui peut l’interrompre.

Valider l’intégration HTTP

Vérifiez l’authentification et le transport conformément à la documentation convenue avec le fournisseur. Assurez-vous que l’application distingue une réponse HTTP du résultat opérationnel du message : recevoir une réponse ne suffit pas à conclure que le message a été remis.

Définissez les délais d’attente de connexion et de réponse en fonction de l’implémentation et du contrat technique. À l’expiration du délai, le résultat peut être incertain : le système distant a peut-être traité la requête même si l’application n’a pas reçu la réponse. Ne relancez pas automatiquement une requête sans politique prenant en compte les doublons et l’idempotence.

Classez les erreurs selon les réponses documentées par votre interlocuteur. Distinguez les problèmes qui peuvent être résolus en corrigeant la requête ou la configuration de ceux qui pourraient être temporaires. Les informations disponibles ne définissent ni codes, ni tentatives de relance, ni sémantique universelle pour les API SMS : convenez de ces comportements avant le lancement en production.

Si des tentatives de relance sont prévues, définissez des limites, des délais et des conditions d’arrêt. Assurez-vous qu’une relance ne multiplie pas les envois en cas de réponse ambiguë et que le mécanisme de déduplication, s’il existe, est décrit et testé.

• Testez des identifiants valides et invalides sans exposer de secrets dans les journaux.
• Vérifiez les réponses de réussite et d’erreur à l’aide d’exemples documentés par le fournisseur.
• Simulez des délais d’attente dépassés et vérifiez comment identifier une requête dont le résultat est incertain.
• Testez la politique de relance et le traitement des doublons avant d’activer les renvois automatiques.

Valider la session SMPP

SMPP v3.4 est une spécification pertinente pour ce type de connexion, mais les valeurs opérationnelles concrètes doivent être convenues avec votre interlocuteur. Avant d’ouvrir le trafic, confirmez les paramètres de connexion et la configuration de session effectivement applicables à votre liaison.

Vérifiez que le type de bind et les paramètres de session correspondent à l’usage convenu. Définissez comment détecter les sessions inactives, surveiller leur état et gérer une déconnexion ou une fermeture contrôlée. Ne présumez ni des intervalles, ni des valeurs de fenêtre, ni des réponses : ils doivent découler de la spécification applicable et de l’accord technique.

Assurez-vous que l’application distingue une session connectée d’une session autorisée à transmettre dans les limites convenues. Testez la reprise après une perte de connexion sans supposer que les messages en attente ont été traités ou supprimés.

• Validez les paramètres de connexion et les identifiants avec votre interlocuteur.
• Convenez du comportement du bind, du contrôle d’activité et de la fermeture de session.
• Confirmez comment les envois en attente sont réconciliés après une déconnexion.
• Consignez les erreurs de protocole et leur corrélation avec la session concernée.

Convenir des limites, des files d’attente et du contrôle de la pression

Ne déduisez pas la capacité d’une connexion du simple fait qu’elle accepte des messages de test. Avant d’activer le trafic, obtenez auprès de votre interlocuteur et à partir de la configuration contractuelle les limites applicables, par exemple le débit d’envoi ou le nombre de connexions simultanées autorisés. Sans ces données, il n’est pas possible de recommander un TPS universel.

Définissez le comportement des files d’attente lorsque l’application produit des messages plus vite que l’intégration ne peut les traiter. Établissez à quel moment l’émetteur doit ralentir, à quel moment les nouvelles tâches ne sont plus acceptées et comment éviter qu’une rafale ne transforme un problème temporaire en un arriéré difficile à résorber.

Procédez à des tests progressifs, dans les limites convenues. Si un test de charge n’est pas autorisé, ne le réalisez pas : demandez d’abord un plan et des conditions explicites.

• Consignez les limites convenues et l’endroit où elles s’appliquent : application, connexion ou fournisseur.
• Définissez les seuils de ralentissement ou d’arrêt de la production de messages.
• Vérifiez le comportement de la file d’attente et la reprise après une interruption.
• Évitez les tests de charge non autorisés ou fondés sur des limites supposées.

Traçabilité, états et DLR

Chaque message devrait pouvoir être suivi depuis la requête d’origine jusqu’aux réponses et mises à jour reçues. Définissez les identifiants conservés par chaque système et la façon dont sont mis en relation l’identifiant interne, la référence renvoyée par la plateforme et les événements ultérieurs.

Consignez les horodatages et les états avec suffisamment de contexte pour enquêter sur les incidents. Limitez les données personnelles et le contenu stocké au strict nécessaire, protégez les journaux et définissez qui peut les consulter et pendant combien de temps, conformément aux obligations applicables.

Si vous recevez des callbacks ou des DLR, testez leur authentification, leur corrélation et leur traitement, y compris les événements répétés ou tardifs si l’interface les prévoit. Un DLR reçu doit être présenté comme l’état communiqué par la source concernée ; il ne constitue pas une preuve indépendante qu’une personne a vu le message ou qu’il est arrivé sur un appareil précis.

• Corrélez la requête, la réponse initiale et les événements ultérieurs au moyen d’identifiants documentés.
• Consignez l’heure, l’état, la destination et le contexte technique nécessaire au diagnostic.
• Testez les callbacks et les DLR conformément au comportement documenté, sans leur attribuer un degré de certitude supérieur à celui qu’ils offrent.
• Définissez les contrôles d’accès et la durée de conservation des journaux.

Réaliser des tests contrôlés et évaluer les preuves

Commencez par tester le transport et la configuration à l’aide de cas approuvés. Ensuite, si vous disposez d’une autorisation et d’une destination de test appropriée, évaluez le cycle d’envoi et les rapports disponibles. Séparez les résultats de connectivité des résultats de remise.

Classez chaque observation : requête envoyée, acceptation communiquée par l’interface, DLR reçu et, lorsque c’est possible, réception vérifiée de manière indépendante sur une destination contrôlée. Ces catégories ne sont pas interchangeables. Un test portant sur quelques messages ne permet pas, à lui seul, de déduire le comportement pour toutes les destinations ou tous les volumes.

Documentez les résultats, l’heure, l’environnement, les paramètres utilisés et les limites. Si une réponse manque ou si les états sont incohérents, considérez le cas comme non concluant jusqu’à ce qu’il ait fait l’objet d’une enquête.

• Faites approuver au préalable les destinations, les expéditeurs et le contenu des tests.
• Vérifiez d’abord la connectivité, puis le flux des états des messages.
• Conservez suffisamment de preuves pour reproduire le diagnostic, sans stocker de secrets.
• Ne transformez pas un échantillon limité en garantie générale de remise.

Alertes, responsables et retour arrière

Avant le lancement, désignez les responsables de l’intégration, de l’exploitation et des échanges avec votre interlocuteur. Définissez comment détecter la perte de connectivité, l’augmentation des erreurs, l’accumulation des files d’attente et les incohérences d’état, à partir des signaux disponibles dans votre système.

Convenez de critères d’arrêt explicites : par exemple, des défaillances qui empêchent d’identifier le résultat des envois, l’exposition d’identifiants ou un écart par rapport aux limites convenues. Les seuils concrets doivent être adaptés aux données et aux accords de service, et non à des chiffres inventés.

Préparez un retour arrière avant d’activer le trafic : déterminez qui peut interrompre les nouveaux envois, comment traiter la file d’attente en attente, comment informer les équipes concernées et quelles conditions doivent être réunies pour reprendre. Arrêter la production de nouveaux messages ne résout pas automatiquement le statut de ceux déjà envoyés ; ces cas doivent être réconciliés.

• Désignez un responsable d’astreinte et un canal d’escalade.
• Définissez les signaux observables et les seuils convenus pour déclencher une alerte et arrêter le trafic.
• Testez la procédure d’interruption des nouveaux envois et de traitement du travail en attente.
• Documentez les conditions de reprise et la revue post-incident.