Se connecter

Essayer gratuitement

Infrastructure

Sur quoi repose BulkGate, comment les messages atteignent les réseaux des opérateurs, comment nous protégeons le trafic et ce que cela signifie pour une intégration qui doit tenir aux heures de pointe.

Trois sites

Le service fonctionne sur plusieurs serveurs répartis sur trois sites géographiques. Il ne s'agit pas d'une machine avec une réserve, mais d'un fonctionnement simultané — si l'un des sites tombe en panne, les autres prennent le relais du trafic automatiquement et sans aucune intervention de votre part. Rien ne change pour votre intégration : portal.bulkgate.com continue de répondre et les requêtes partent de la même manière.

Ce que la bascule automatique ne couvre pas, c'est le chemin jusqu'à nous — une panne chez votre fournisseur de connectivité, chez un transporteur ou n'importe où sur le trajet entre votre serveur et le nôtre. C'est à cela que sert le serveur de secours.

L'infrastructure est conçue pour résister aux pannes et elle est protégée contre les attaques DDoS par WEDOS Global Protection. Le trafic n'atteint pas directement nos serveurs — il passe par leur réseau anycast de plus de 120 nœuds, où le nœud le plus proche le prend en charge. Une attaque est répartie et filtrée de leur côté avant même de nous atteindre ; nos serveurs ne traitent que les requêtes légitimes qui passent. L'anycast raccourcit aussi le trajet de votre requête, car c'est le nœud le plus proche de vous qui la reçoit.

WEDOS conserve lui aussi les journaux, la configuration et les analyses au sein de l'UE, si bien que même la protection DDoS ne fait pas sortir les données de l'Union — voir Serveurs dans l'UE.

L'état actuel du service est disponible sur bulkgate.status.online.

Serveurs dans l'UE

Tous nos serveurs fonctionnent dans l'Union européenne. Vos données ne quittent donc pas l'UE et vous n'avez pas à gérer de transferts vers des pays tiers ni de clauses contractuelles types.

La manière dont nous traitons les données personnelles est décrite dans les Conditions de traitement des données personnelles et dans la Politique de confidentialité.

Connexions aux opérateurs

Nous remettons les messages via des connexions directes aux opérateurs en Europe, en Asie, en Afrique ainsi qu'en Amérique du Nord, centrale et du Sud.

Ce que signifie 0-hop

Une connexion directe est une connexion 0-hop — personne d'autre ne se trouve entre nous et le SMSC de l'opérateur. Le message passe de notre passerelle directement dans le réseau de destination. C'est la meilleure qualité de livraison possible ; il n'existe pas de meilleur chemin vers le numéro de destination, car il n'en existe pas de plus court.

Chaque intermédiaire sur le trajet est un endroit où quelque chose peut mal tourner :

ce qui se passe sur un trajet via des intermédiaires	avec le 0-hop
Le message attend dans la file d'attente d'un autre agrégateur.	Disparu, le chemin est direct.
Les rapports de livraison arrivent en retard ou sont inexacts.	Le statut vient de l'opérateur lui-même.
Le message se perd en route et personne ne peut dire où.	Le trajet n'a que deux extrémités.
Chaque maillon prend sa marge.	Un prix sans intermédiaires.

C'est pourquoi nous établissons des connexions directes partout où nous le pouvons. Pour les gros volumes et les messages urgents — codes OTP, confirmations de commande — c'est là que la différence se voit le plus.

Aujourd'hui, nous disposons du 0-hop vers plus de 50 pays, et ce nombre ne cesse de croître.

Là où nous n'avons pas de 0-hop, le premier choix est un fournisseur local dans le pays concerné — un seul intermédiaire qui connaît le marché local, et non une chaîne d'agrégateurs. Ce n'est que lorsqu'il n'en existe même pas un seul que nous livrons via des hubs SMS ; nous les gardons comme solution de secours pour un minimum de destinations, et non comme trajet habituel.

RCS via une connexion directe à Google

Les connexions directes ne s'arrêtent pas au SMS. RCS Business Messaging fonctionne sur la plateforme de Google. Nous disposons d'une connexion directe à celle-ci ainsi que de nos propres accords avec les opérateurs — les deux sont nécessaires : Google approuve l'agent et le contenu, l'opérateur laisse entrer le trafic dans son réseau. Sans l'un ou l'autre, un message RCS n'atteint jamais le destinataire.

Ce que le RCS apporte par rapport au SMS :

ce que vous obtenez	en quoi c'est différent
Expéditeur vérifié	Nom de marque, logo et couleur au lieu d'un numéro, avec un badge de vérification directement dans l'application Messages.
Contenu enrichi	Du texte avec des boutons de suggestion, un fichier, une carte ou un carrousel de cartes.
Interaction	Le destinataire répond par un bouton au lieu de taper — le clic vous revient sous forme d'événement.
Statuts dignes d'une messagerie	Remis et lu, pas seulement envoyé.
Le SMS en secours	Si le destinataire n'a pas le RCS ou si le message n'est pas remis dans le délai fixé, il passe au canal suivant de la cascade.

Les types de messages et leur facturation sont décrits dans Types de messages RCS ; la configuration de l'agent dans Paramètres du chat RBM.

Viber en tant que partenaire officiel

Pour Viber, nous sommes un partenaire officiel, et non un revendeur — vous nous trouverez dans leur annuaire des partenaires de messagerie. Les messages partent donc par le trajet approuvé directement dans le réseau de Viber et nous enregistrons votre expéditeur directement auprès d'eux.

Ce que cela signifie en pratique :

ce que vous obtenez	en quoi c'est différent
Expéditeur enregistré	Le nom de votre marque au lieu d'un numéro, avec un profil vérifié. Comment l'enregistrer
Plus riche que le SMS	Du texte, une image et un bouton avec un lien dans un seul message — sans limite de 160 caractères. Voir Viber – promotionnel.
Modèles transactionnels	Les modèles approuvés sont facturés au tarif transactionnel, plus bas. Voir Viber – transactionnel.
Vous ne payez que ce qui est remis	Viber ne facture que les messages dans les états DELIVERED et SEEN ; le reste est recrédité sur votre compte une fois expiré. Voir Statuts Viber.
Le SMS en secours	Si Viber ne remet pas le message dans le délai fixé, il passe au canal suivant de la cascade.

Les types de messages et les sessions sont décrits dans Types de messages Viber.

SMPP pour les gros volumes

En plus de l'API HTTP, nous proposons aux grands clients une connexion SMPP — le protocole sur lequel fonctionnent les réseaux SMS eux-mêmes. Elle est rentable lorsque les volumes sont durablement élevés et que vous avez besoin de garder une session ouverte au lieu d'envoyer des requêtes HTTP individuelles.

Le SMPP se configure au cas par cas ; contactez-nous et nous passerons en revue vos volumes et vos paramètres.

Priorisation des messages

Tous les messages ne peuvent pas attendre de la même façon. Un code que l'utilisateur attend, les yeux rivés sur un formulaire, doit partir immédiatement ; une campagne vers cent mille numéros ne souffrira pas d'une seconde de plus. Nous répartissons donc le trafic dans des files d'attente distinctes et les traitons dans cet ordre :

priorité	ce qui en fait partie
1. OTP	Codes à usage unique. L'utilisateur les attend en temps réel.
2. Transactionnel	Confirmation de commande, avis de livraison, alerte — un message pour un destinataire.
3. Transactionnel en masse	Les mêmes messages envoyés en lot à plusieurs numéros à la fois.
4. Petites campagnes	Un envoi promotionnel à un nombre réduit de destinataires.
5. Campagnes moyennes	Un envoi promotionnel de taille moyenne.
6. Grandes campagnes	Un envoi promotionnel à grande échelle.

Les files d'attente ne se doublent pas : une grande campagne déjà en cours ne retardera pas un code OTP qui arrive en plein milieu.

Important

Nous exigeons des clients qu'ils séparent le trafic transactionnel et le trafic promotionnel. Ce n'est pas une recommandation — toute la priorisation repose là-dessus. Envoyez chaque type de message par l'endpoint qui lui correspond : un message transactionnel par l'endpoint transactionnel, un envoi promotionnel par l'endpoint promotionnel. Une campagne d'un seul élément à la place d'un message transactionnel attend inutilement dans la file des campagnes ; une campagne poussée par l'endpoint transactionnel retarde des messages que quelqu'un attend en temps réel, et elle est en plus strictement interdite.

Protection contre le phishing et le SMS pumping

Nous évaluons le trafic en continu pour détecter deux phénomènes qui nuisent autant aux expéditeurs qu'aux destinataires.

Phishing. Chaque message est comparé aux schémas de campagnes frauduleuses connues — à la fois l'identifiant d'expéditeur et le texte, et séparément pour chaque pays de destination. Le contrôle tient aussi compte des imitations : il repère un nom ou une formulation délibérément modifiés de quelques caractères pour échapper à une comparaison littérale. Cela protège votre marque contre l'usurpation et votre identifiant d'expéditeur contre une atteinte à sa réputation auprès de l'opérateur.

SMS pumping. Trafic généré artificiellement (AGT) — un attaquant fait passer des codes OTP par votre formulaire vers des numéros de tranches surtaxées et empoche une part de leur prix. C'est pourquoi nous surveillons la forme du trafic, et non son contenu. Dès que nous constatons un trafic qui ne correspond pas à ce que le compte envoie habituellement — une hausse soudaine ou des destinations inhabituelles — nous stoppons l'envoi et vous avertissons par e-mail et par SMS. L'attaque est coupée avant de devenir coûteuse ; le dommage se limite à ce qui est déjà parti.

Note

L'analyse est anonyme. Elle s'effectue automatiquement sur la forme du trafic, et non sur l'identité des destinataires — personne ne lit vos messages et aucun profil n'est établi à partir d'eux. Cela correspond à ce qui est décrit dans Serveurs dans l'UE.

Vous pouvez prévenir une attaque contre votre propre formulaire en définissant request_quota_identification et request_quota_number dans l'API OTP — le quota est lié au demandeur, généralement à son adresse IP. Le portail y ajoute des restrictions géographiques et des limites d'envoi quotidiennes ; leur configuration est décrite dans SMS OTP piratés : protégez-vous grâce aux limites de l'API BulkGate !.

Sécurité des communications et des données

Toutes les communications passent par HTTPS. L'API n'a pas de variante non chiffrée — une requête http:// est redirigée vers HTTPS, mais la redirection ne conserve pas le corps POST, si bien que le message n'est pas envoyé. Appelez toujours directement https:// et ne comptez jamais sur la redirection.

Nous acceptons TLS 1.2 et 1.3 ; les anciennes versions TLS 1.0 et 1.1 sont refusées par le serveur. Si votre intégration tourne sur un environnement plus ancien, assurez-vous que son client HTTP gère TLS 1.2 — sinon la connexion échoue avant même l'envoi de la requête. Il en va de même pour le serveur de secours.

Les communications avec les fournisseurs sont toujours chiffrées. Le chiffrement ne s'arrête pas à votre requête. La seconde partie du trajet est protégée de la même façon — que le message parte en 0-hop directement vers l'opérateur, via un fournisseur local ou via un hub.

Le portail est protégé par des en-têtes de sécurité. Il envoie au navigateur les suivants :

Content Security Policy — les scripts ne s'exécutent qu'avec un nonce à usage unique.
X-Content-Type-Options: nosniff — le navigateur ne doit pas deviner le type de contenu.
X-Frame-Options: SAMEORIGIN — la page ne peut pas être intégrée dans un cadre étranger, protection contre le clickjacking.
Referrer-Policy: strict-origin-when-cross-origin — un domaine étranger ne reçoit pas le chemin complet avec ses paramètres.
Feature-Policy — le microphone, la caméra et l'API de paiement sont désactivés dans le portail.

Les mots de passe ne sont PAS stockés en clair. Seul un hachage Argon2id est conservé — le mot de passe ne peut pas être retrouvé à partir de la base de données, même si quelqu'un s'en emparait. Les codes à usage unique sont traités de la même façon : un code OTP est conservé dans la base de données sous forme de hachage Argon2id, et non de nombre lisible, si bien que personne de notre côté ne peut le lire.

Les tokens API sont chiffrés dans la base de données. Un token est stocké chiffré (AES-256), et non sous forme de chaîne lisible.

Attention

Le token est le mot de passe de votre crédit. Ne le placez jamais dans du code qui s'exécute dans un navigateur ou dans une application mobile — n'importe qui peut l'y lire. Appelez l'API depuis votre propre serveur et conservez le token dans une configuration en dehors de votre dépôt.

Pourquoi les grands clients y tiennent

La différence entre les fournisseurs n'est pas de savoir s'ils envoient le message, mais par quel chemin. Chez nous, un message part d'abord en 0-hop directement dans le réseau de l'opérateur ; là où nous n'avons pas une telle connexion, via un fournisseur local dans le pays concerné ; et seulement dans un minimum de cas via un hub SMS. Plus un message passe haut dans cet ordre, plus il arrive tôt, plus son rapport de livraison est précis et moins il passe entre de mains — et à des centaines de milliers de messages par mois, cette différence se voit aussi bien dans les statistiques de livraison que sur la facture.

Le reste vient en plus : un fonctionnement sur trois sites avec bascule automatique, un serveur de secours en cas de panne sur le trajet, des serveurs dans l'UE sans transfert de données vers des pays tiers, des communications chiffrées sur les deux parties du trajet et le SMPP pour les volumes avec lesquels l'API HTTP commence à peiner. Au-dessus du trafic lui-même fonctionne la protection contre le phishing et le SMS pumping, qui stoppe une attaque contre votre formulaire avant qu'elle ne devienne coûteuse. Nous exploitons le service depuis 2012, vous pouvez donc bâtir dessus une intégration que vous n'aurez pas à réécrire dans un an.

Cette page vous a-t-elle été utile ?

Demander à l'IA Copié