SGP.22 vs SGP.32 - ce que le changement de norme eSIM signifie pour la connectivité en voyage

Objectif : Offrir aux acheteurs d'eSIM de voyage et aux opérateurs de voyage/MVNO une carte des normes entre l'approvisionnement à distance des SIM pour consommateurs et pour IoT - afin que les discussions sur "la prochaine norme eSIM" ne brouillent pas deux chemins différents.

Public : Les professionnels qui expédient ou achètent de la connectivité de voyage pour consommateurs (et toute personne évaluant du matériel IoT/voyage connexe), pas les membres du comité GSMA.

Si vous achetez une eSIM de voyage, scannez un code QR et atterrissez avec des données, vous êtes déjà dans une architecture GSMA Remote SIM Provisioning (RSP) - même si vous ne voyez jamais les numéros de spécification. Ces numéros comptent.SGP.22 est la norme technique RSP pour consommateurs derrière les flux de smartphones et d'eSIM de voyage.SGP.32 est la norme technique RSP pour IoT pour les appareils sans interface, contraints et à l'échelle de flotte. Ils partagent certains éléments de base. Ils résolvent différents problèmes.

Cette distinction est facile à brouiller dans les présentations marketing. C'est aussi la différence entre un voyageur installant un profil temporaire sur un téléphone et une entreprise orchestrant la connectivité à travers des milliers de capteurs qui ne verront jamais un écran. Pour les marques de voyage, les MVNO et toute personne construisant sur des piles eSIM pour consommateurs, savoir où SGP.22 se termine et où SGP.32 commence est essentiel - non pas parce que les voyageurs ont besoin de PDF GSMA, mais parce que la conversation de l'industrie mélange souvent les chemins pour consommateurs et IoT.

Cet article cartographie les architectures, les acteurs, les différences de cycle de vie et les implications pratiques pour la connectivité en voyage - sans traiter SGP.32 comme une mise à niveau immédiate pour l'itinérance des consommateurs.

Pourquoi l'industrie avait besoin de plus d'une « norme » eSIM #

L'eSIM n'est pas un seul protocole. C'est une famille de spécifications GSMA qui définissent comment les profils opérateurs sont préparés, livrés, installés, activés, désactivés et supprimés en toute sécurité sur un eUICC (la plateforme SIM intégrée).

L'index public des spécifications de la GSMA rend la séparation explicite : le RSP consommateur se trouve sous SGP.21 (architecture) et SGP.22 (technique) ; le RSP IoT se trouve sous SGP.31 (architecture et exigences) et SGP.32 (technique). Les versions actives pour les consommateurs continuent à travers SGP.22 v2.x et v3.x ; les versions IoT continuent à travers SGP.31/SGP.32 v1.x, y compris les révisions plus récentes de 2024 à 2026 sur la page des spécifications eSIM de la GSMA (Spécifications eSIM Consommateur et IoT de la GSMA).

Avant SGP.32, l'approvisionnement à distance IoT et M2M se faisait principalement dans un modèle machine-à-machine antérieur (SGP.02), avec une séparation à double serveur de SM-DP (préparation des données) et SM-SR (routage sécurisé). Ce modèle permettait la gestion à distance des profils pour les cas d'utilisation industriels et automobiles, mais il apportait également des frictions opérationnelles : déclencheurs orientés SMS, couplage commercial plus étroit SM-SR/SM-DP, et une mauvaise adéquation pour les appareils LPWAN très contraints. Les explications des opérateurs et des plateformes IoT citent systématiquement ces contraintes comme la raison pour laquelle la GSMA a construit une architecture IoT dédiée plutôt que d'imposer le RSP consommateur à chaque modem (Eseye sur SGP.31/32; 1oT sur SGP.02 vs SGP.22 vs SGP.32).

Version courte : un seul facteur de forme physique (eSIM/eUICC), plusieurs philosophies d'approvisionnement.

SGP.22 en termes simples : RSP consommateur pour les appareils avec un humain dans la boucle #

SGP.22 est la description technique de la GSMA pour l'approvisionnement à distance des SIM pour les appareils consommateurs. Son objectif est sans ambiguïté : une solution technique pour l'approvisionnement et la gestion à distance de l'eUICC dans les appareils consommateurs, visant l'interopérabilité à travers les déploiements opérateurs - y compris les plateformes SM-DP+ et les fournisseurs eUICC.

Acteurs principaux dans le modèle consommateur #

Rôles des acteurs #

• eUICC: Plateforme sécurisée qui stocke les profils (identifiants opérateurs et composants associés)
• LPA (Assistant de Profil Local): Assistant sur l'appareil (ou partiellement sur eUICC) qui gère le téléchargement, l'activation/désactivation/suppression locale, et la gestion des profils par l'utilisateur
• SM-DP+: Gestionnaire d'Abonnement - Préparation des Données + : prépare, protège et livre les Paquets de Profils Liés
• SM-DS: Gestionnaire d'Abonnement - Service de Découverte : chemin de découverte optionnel lorsque l'appareil doit trouver le bon SM-DP+ sans code QR/d'activation
• Opérateur / émetteur de profil: Détient l'abonnement commercial derrière le profil

Dans le flux que les voyageurs reconnaissent :

1. Achetez un forfait voyage et recevez un code d'activation (souvent sous forme de QR).
2. Le dispositif LPA contacte le SM-DP+.
3. Le paquet de profil chiffré est téléchargé et installé sur l'eUICC.
4. L'utilisateur active le profil (et peut ensuite le désactiver ou le supprimer).

Ceci est un modèle initié par l'utilisateur / orienté par extraction. Une personne est présente, l'appareil dispose d'une interface utilisateur, et le consentement est une action d'installation explicite. C'est pourquoi le paiement des eSIM de voyage, les partenariats avec les compagnies aériennes/fintech, et l'activation via application correspondent tous au RSP consommateur de classe SGP.22 - pas à l'orchestration de flotte IoT.

Le transport HTTPS/TLS convient aux smartphones. Il est plus lourd que ce que de nombreux cycles de service IoT peuvent se permettre, mais raisonnable pour un téléphone qui maintient déjà une connectivité IP et une pile de sécurité complète.

SGP.32 en termes simples : RSP IoT pour les appareils qui ne peuvent pas appuyer sur « Ajouter eSIM » #

SGP.32 est la spécification technique pour l'architecture eSIM IoT de la GSMA définie dans SGP.31. La GSMA la décrit comme couvrant l'approvisionnement et la gestion à distance de l'eUICC dans les appareils IoT qui sont contraints par le réseau et/ou par l'interface utilisateur, ainsi que l'architecture eUICC, les interfaces et les fonctions de sécurité pour ce modèle.

Acteurs principaux dans le modèle IoT #

Rôles des acteurs #

• eUICC: eUICC compatible IoT qui stocke les profils et prend en charge les associations de gestion à distance IoT
• IPA (Assistant de Profil IoT): Assistant côté appareil ou eUICC qui exécute le travail d'approvisionnement/gestion sans interface utilisateur consommateur; peut être IPAd (sur l'appareil) ou IPAe (sur l'eUICC)
• eIM (Gestionnaire à distance eSIM IoT): Entité de cloud/orchestration qui émet des opérations de cycle de vie de profil pour un appareil ou une flotte
• SM-DP+: Réutilisé de l'écosystème consommateur pour la préparation et la livraison protégée des profils
• SM-DS: Rôle de découverte conservé là où pertinent
• Opérateur: Source de profil, comme dans le RSP consommateur

L'intention architecturale est cohérente dans les documents de la GSMA et les présentations de l'industrie : conserver ce qui fonctionnait déjà dans le RSP consommateur (notamment SM-DP+), et remplacer l'hypothèse humaine/LPA par un gestionnaire à distance et un assistant natif IoT (Explication des normes IoT Velocity; Comparaison 1oT).

Pourquoi l'IoT avait besoin d'un modèle différent #

Le RSP consommateur suppose :

• un écran ou une UX compagnon,
• une personne qui peut lancer le téléchargement,
• connectivité IP relativement stable pour les sessions TLS,
• décisions de cycle de vie par appareil, pilotées par l'utilisateur.

Les flottes IoT supposent souvent le contraire :

• pas d'interface utilisateur,
• connectivité intermittente ou à faible bande passante (y compris les scénarios LPWAN),
• vérifications asynchrones plutôt que des sessions toujours actives,
• activation/désactivation/suppression pilotée par des politiques sur de nombreux EID à la fois.

SGP.31/32 introduit donc une gestion d'état de profil orientée flotte et un eIM qui peut déclencher ou servir de proxy pour les téléchargements. Les analyses de l'industrie soulignent également les options de protocoles légers (par exemple CoAP/DTLS comme chemin alternatif pour les appareils contraints), la suppression de SMS comme dépendance essentielle pour les RSP IoT modernes, et le support pour la livraison de profil directe vs indirecte selon que l'appareil peut communiquer confortablement avec le SM-DP+ lui-même (Eseye; 1oT).

De manière critique, SGP.32 n'est pas une "mise à jour logicielle" rétrocompatible pour chaque eUICC SGP.02 déjà sur le terrain. Eseye et d'autres spécialistes IoT notent que les déploiements standards M2M restent généralement sur ce modèle jusqu'à la fin de vie ; le IoT en champ libre est là où SGP.32 est conçu pour devenir la norme par défaut.

SGP.22 vs SGP.32 : comparaison structurée #

Comparaison dimension par dimension #

Paire principale GSMA

• SGP.22 (RSP consommateur): architecture SGP.21 + technique SGP.22
• SGP.32 (RSP IoT): architecture/exigences SGP.31 + technique SGP.32

Conçu pour

• SGP.22 (RSP consommateur): Smartphones, tablettes, appareils portables, appareils grand public avec interface utilisateur
• SGP.32 (RSP IoT): Appareils IoT sans interface / à interface limitée / à réseau contraint et flottes

Humain dans la boucle ?

• SGP.22 (RSP consommateur): Oui - l'utilisateur initie ou confirme l'installation/le changement
• SGP.32 (RSP IoT): Non - eIM/IPA orchestrent les opérations à distance

Assistant local

• SGP.22 (RSP consommateur): LPA
• SGP.32 (RSP IoT): IPA (IPAd ou IPAe)

Orchestration à distance

• SGP.22 (RSP consommateur): Limité / pas le centre de conception
• SGP.32 (IoT RSP): eIM en tant que gestionnaire à distance de premier ordre

Serveur de profils

• SGP.22 (RSP consommateur): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (réutilisé)

Découverte

• SGP.22 (RSP consommateur): SM-DS (optionnel dans de nombreux flux)
• SGP.32 (IoT RSP): SM-DS conservé dans l'architecture

Modèle de déclenchement

• SGP.22 (RSP consommateur): Principalement par extraction (QR / code d'activation / application)
• SGP.32 (IoT RSP): Poussée et/ou extraction via eIM et modèles de check-in de l'appareil

Posture de transport

• SGP.22 (RSP consommateur): Pile IP consommateur centrée sur HTTPS/TLS
• SGP.32 (IoT RSP): Basé sur IP; options pour appareils contraints mises en avant (par exemple, chemins CoAP/DTLS dans les résumés industriels de la spécification)

Douleur du prédécesseur qu'il adresse

• SGP.22 (RSP consommateur): Échanges de SIM physiques et verrouillage opérateur sur le matériel consommateur
• SGP.32 (IoT RSP): Verrouillage opérationnel SGP.02, dépendance SMS, et mauvaise adéquation pour appareils contraints

Pertinence des eSIM de voyage

• SGP.22 (RSP consommateur): Direct - c'est la pile derrière les installations typiques d'eSIM de voyage sur téléphone
• SGP.32 (IoT RSP): Indirect - façonne les écosystèmes IoT/matériel de voyage adjacents, pas les flux QR de téléphone

Cycle de vie du profil : mêmes verbes, grammaire différente #

Les deux mondes parlent de téléchargement, installation, activation, désactivation et suppression. La grammaire diffère :

• Cycle de vie SGP.22 est local et centré sur l'utilisateur. Une fois installé, le voyageur (ou l'interface LPA) décide quand un profil est activé pour les données en itinérance, quand il est mis en pause, et quand il est supprimé.
• Cycle de vie SGP.32 est à distance et centré sur la politique. L'eIM peut émettre des opérations de gestion d'état de profil sur un EID ou plusieurs, et l'IPA les exécute lorsque l'appareil est joignable - important pour les appareils qui dorment la plupart de la journée.

C'est pourquoi le « changement de profil » signifie des choses commerciales différentes dans chaque monde. Dans le voyage consommateur, le changement est souvent un nouvel achat ou un deuxième profil installé que l'utilisateur sélectionne. Dans l'IoT, le changement est une opération de parc : changer de fournisseur de connectivité, répondre à la couverture, ou faire tourner les profils sans intervention physique.

Où s'inscrivent les anciennes spécifications IoT : SGP.02 et SGP.31 #

Un modèle mental clair :

1. SGP.02 - RSP M2M original avec SM-DP + SM-SR. Fondamental, toujours présent dans les parcs à long cycle de vie (notamment dans l'automobile et d'autres déploiements en usine), mais de plus en plus considéré comme obsolète pour les nouveaux projets IoT contraints (1oT).
2. SGP.22 - RSP consommateur qui a simplifié l'approvisionnement autour de SM-DP+ et LPA ; la voie grand public pour les téléphones et les eSIM de voyage.
3. SGP.31 / SGP.32 - RSP IoT qui réutilise SM-DP+ tout en ajoutant eIM + IPA pour la gestion de flotte sans interface.

SGP.32 n'est pas apparu parce que l'eSIM consommateur a « échoué ». Il est apparu parce que l'eSIM consommateur a réussi pour les humains-et ce succès ne résout toujours pas un capteur fixé à l'intérieur d'un conteneur d'expédition.

Implications pour les eSIM de voyage, l'itinérance des consommateurs et les piles MVNO #

La connectivité de voyage reste une histoire de RSP consommateur #

Pour les téléphones et la plupart des appareils des voyageurs, la norme opérative reste RSP consommateur de classe SGP.22. L'expérience produit qui intéresse les voyageurs - acheter avant le départ, installer via QR ou application, atterrir connecté - correspond aux flux LPA ↔ SM-DP+, pas aux commandes de flotte eIM.

Le commentaire industriel de la GSMA pour 2026 présente la connectivité de voyage comme un changement structurel dans l'itinérance internationale : les offres eSIM de voyage basées sur des applications sont plus transparentes et flexibles, et la distribution se rapproche de l'utilisateur final avant le début du voyage (GSMA : le déploiement de masse des eSIM passe de la prévision à la réalité). Ce changement commercial repose sur la maturité des RSP consommateurs et le support des appareils, pas sur le déploiement IoT eIM.

Ce que SGP.32 *change* pour les écosystèmes adjacents au voyage #

Même si les voyageurs ne touchent jamais SGP.32, la norme est importante aux marges du voyage :

• Les traceurs de bagages connectés, les véhicules de flotte, les capteurs logistiques et l'IoT des lieux ont de plus en plus besoin de gestion de profil à distance sans cérémonie QR.
• Les routeurs de voyage et certains « matériels eSIM » peuvent se situer dans un entre-deux désordonné : activation de style consommateur pour un propriétaire humain, mais besoins opérationnels qui ressemblent davantage à une flotte à grande échelle.
• Les opérateurs et les MVNO peuvent gérer à la fois des parcs SM-DP+ consommateurs et des parcs eIM IoT. Le partage de l'ADN SM-DP+ entre SGP.22 et SGP.32 est intentionnel ; cela ne signifie pas que les deux classes d'appareils partagent la même UX ou le même chemin de certification.

Multi-IMSI, piles MVNO et frontières véridiques #

Le Multi-IMSI (plusieurs identités sélectionnables au sein ou à côté d'un produit de connectivité) et le téléchargement de profil eUICC sont souvent discutés ensemble, mais ils ne sont pas le même mécanisme. Le Multi-IMSI peut améliorer le comportement d'attachement au réseau dans une offre commerciale ; le RSP eUICC (SGP.22 ou SGP.32) concerne l'installation et la gestion sécurisées de profils d'opérateurs complets sur l'eUICC. Les marques de voyage et les MVNO peuvent combiner les deux techniques commercialement, mais la clarté de l'architecture reste importante : les installations de voyage pour les consommateurs sur les téléphones sont jugées par l'interopérabilité SGP.22 et l'UX d'activation ; les parcs IoT sont jugés par l'opérabilité eIM/IPA et la résilience des réseaux contraints.

Une mise en garde utile du côté IoT s'applique également commercialement : la portabilité technique dans une spécification n'équivaut pas automatiquement à la portabilité commerciale dans un contrat. SGP.32 réduit certains schémas de verrouillage architectural associés à SGP.02, mais les conditions commerciales des fournisseurs déterminent toujours dans quelle mesure les flottes peuvent déplacer librement les associations eIM ou les relations SM-DP+ externes (1oT). Les acheteurs de voyages consommateurs font face à une leçon analogue à plus petite échelle - un RSP interopérable ne garantit pas, à lui seul, une qualité de couverture identique, une politique d'utilisation équitable ou une expérience de support identique chez tous les fournisseurs.

Calendrier du marché et signaux d'adoption (public, 2025-2026) #

Les documents publics de la GSMA en 2026 décrivent l'eSIM consommateur entrant dans une échelle opérationnelle plutôt qu'une preuve de concept. Selon le résumé de mai 2026 de la GSMA sur les chiffres de GSMA Intelligence, la pénétration mondiale des smartphones eSIM était d'environ 5% à fin 2025, avec un chemin déclaré vers environ 10 % d'ici fin 2026, et une croissance supplémentaire par la suite ; le même article cite environ trois opérateurs de réseau mobile sur quatre / 73 % offrant des eSIM pour smartphones commerciaux, tout en notant l'écart restant entre la disponibilité et l'activation par les consommateurs (article de la GSMA sur les eSIM grand public).

Du côté de l'IoT, le même commentaire de la GSMA met en avant SGP.32 comme un facilitateur structurel pour les variantes de produits mondiaux et le changement de profil sur le terrain - un langage qui correspond à la façon dont les plateformes IoT positionnent la norme. La maturité des spécifications est également visible dans les tableaux publics de la GSMA : SGP.31/SGP.32 continuent de progresser à travers les listes actives v1.2 et les nouvelles listes v1.3 en 2024-2026, aux côtés des spécifications de test associées (index des spécifications de la GSMA).

Interprétation sans exagération : l'eSIM de voyage pour les consommateurs est déjà un cas d'utilisation commerciale à grande échelle sur les rails SGP.22 ; SGP.32 est l'industrialisation parallèle de l'IoT RSP. Ils renforcent l'histoire plus large de l'eSIM sans se substituer l'un à l'autre.

Ce que les voyageurs et les marques doivent retenir #

Pour les voyageurs #

Vous n'avez pas besoin de choisir entre SGP.22 et SGP.32 lorsque vous achetez un forfait de voyage. Si vous installez une eSIM sur un téléphone via un code QR ou une application, vous êtes dans le monde RSP consommateur. Ce qui doit vous importer est pratique : compatibilité de l'appareil, fiabilité de l'installation avant le départ, couverture de la destination, conditions d'utilisation équitables et transparentes, et support en cas de problème à la porte d'embarquement.

Des fournisseurs comme Roamify se situent dans cette couche de voyage pour les consommateurs - forfaits de destination, installation numérique, et utilité de rester connecté à l'étranger - plutôt que dans la gestion de flotte eIM industrielle. L'histoire des normes derrière le QR est toujours en forme de SGP.22.

Pour les marques de voyage, les OTA, les fintechs et les MVNO consommateurs #

• Traitez l'interopérabilité SGP.22 et l'UX d'activation comme la base du produit.
• Ne commercialisez pas “SGP.32” comme une mise à niveau pour les voyageurs à moins que votre architecture matérielle/flotte réelle n'utilise l'IoT RSP.
• Si vous vendez ou marquez en blanc la connectivité pour des trackers, routeurs ou matériel de voyage B2B, évaluez séparément si la classe de l'appareil nécessite des flux LPA consommateurs, des flux eIM IoT, ou un hybride en plusieurs étapes.
• Investissez dans l'éducation : le commentaire de marché de la GSMA souligne toujours un écart entre la disponibilité des eSIM et la compréhension/activation par les consommateurs. Des instructions d'installation claires restent un différenciateur compétitif.

Pour les opérateurs et les plateformes de connectivité #

Faire fonctionner les RSP consommateurs et IoT côte à côte devient de plus en plus normal. L'héritage partagé SM-DP+ aide, mais la certification, l'accréditation de sécurité, les agents de l'appareil (LPA vs IPA), et les modèles d'exploitation commerciale restent distincts. Mélanger les vocabulaires dans les messages publics crée de fausses attentes pour les voyageurs et les acheteurs d'entreprise.

Conclusion : deux normes, une seule histoire eSIM - gardez les voies claires #

SGP.22 et SGP.32 ne sont pas des rivaux sur un même tableau de classement. Ce sont des réponses à deux réalités d'appareils :

• SGP.22 suppose qu'une personne est présente et peut télécharger un profil sur un appareil consommateur. C'est l'architecture derrière l'eSIM de voyage moderne sur les téléphones.
• SGP.32 suppose que l'appareil est seul - ou en veille - et a besoin d'une gestion à distance, capable de gérer une flotte via eIM et IPA, tout en réutilisant la livraison de profil SM-DP+. C'est l'architecture que la GSMA a construite pour l'IoT contraint après que les limites de SGP.02 soient devenues évidentes.

Pour la connectivité de voyage, la leçon stratégique est la précision. Le chemin RSP consommateur redéfinit déjà la façon dont les gens achètent l'itinérance. Le chemin RSP IoT redéfinit comment les machines restent connectées pendant des années. Les marques qui gardent ces voies claires expliqueront l'eSIM de manière plus crédible - et construiront des produits qui correspondent à la norme qu'elles expédient réellement.

Note de marque douce : Roamify est un fournisseur d'eSIM de voyage offrant des forfaits dans de nombreuses destinations avec activation numérique pour les téléphones compatibles. Cet article est une éducation sur les normes, pas une affirmation que Roamify met en œuvre la gestion de flotte IoT SGP.32.