eSIM grand public et eSIM IoT : comprendre SGP.22, SGP.32 et les autres architectures GSMA

L’eSIM du smartphone d’un voyageur et celle d’un compteur électrique installé à distance peuvent toutes deux stocker des profils d’opérateurs mobiles téléchargeables. Elles n’utilisent pas nécessairement la même architecture de provisioning ni le même modèle opérationnel.

L’eSIM grand public a été conçue pour des appareils disposant d’un écran, d’un système d’exploitation, d’un accès Internet et d’une personne disponible pour approuver l’installation. Les déploiements IoT peuvent concerner des milliers d’appareils sans surveillance, avec une énergie limitée, une connectivité intermittente, sans caméra et sans moyen pratique de scanner un code QR.

La GSMA a donc développé différentes architectures de provisioning SIM à distance adaptées à différents environnements :

• SGP.01 et SGP.02 définissent l’architecture M2M établie ;
• SGP.21 et SGP.22 définissent l’architecture grand public, largement utilisée par les smartphones et d’autres appareils grand public ;
• SGP.31 et SGP.32 définissent l’architecture IoT plus récente pour les appareils soumis à des contraintes de réseau ou d’interface utilisateur ;
• SGP.41 définit l’architecture et les exigences du provisioning de profils en usine, ou IFPP.

Ces numéros comptent, mais ils ne doivent pas être le point de départ d’une décision commerciale. L’architecture appropriée dépend de l’appareil, du modèle de déploiement, de la connectivité disponible, du degré d’intervention de l’utilisateur, de la durée de vie prévue et de l’acteur chargé de gérer les profils.

Points essentiels

• Les architectures eSIM grand public, M2M et IoT répondent à des problèmes opérationnels différents. Ce ne sont pas simplement différents noms d’un même workflow.
• SGP.21 décrit l’architecture et les exigences de l’eSIM grand public. SGP.22 fournit la spécification technique correspondante.
• SGP.31 décrit l’architecture et les exigences de l’eSIM IoT plus récente. SGP.32 fournit sa spécification de mise en œuvre technique.
• L’eSIM grand public utilise couramment un SM-DP+, un Local Profile Assistant et, éventuellement, un SM-DS. L’utilisateur ou l’appareil participe généralement directement au téléchargement du profil.
• L’architecture IoT SGP.31/32 ajoute un IoT Profile Assistant et un eSIM IoT Remote Manager afin de prendre en charge les appareils sans interface utilisateur locale adaptée et ceux dont la connectivité est contrainte.
• L’architecture IoT peut utiliser une infrastructure SM-DP+, mais cela ne signifie pas que chaque service eSIM grand public convient automatiquement aux parcs SGP.32.
• L’architecture M2M établie utilise notamment un SM-DP et un SM-SR, et son pilotage repose fortement sur les serveurs. Elle reste pertinente pour les déploiements automobiles et industriels existants.
• SGP.32 ne met pas à niveau à distance tous les appareils M2M ou grand public déjà déployés. La prise en charge doit exister dans l’eUICC, le logiciel de l’appareil, le chemin de connectivité et les systèmes de gestion.
• Un parc peut devoir prendre en charge plusieurs architectures pendant une longue période de migration.
• Une bonne plateforme commerciale distingue le provisioning des profils, la connectivité réseau et la gestion du cycle de vie du parc, au lieu de les traiter comme une seule fonction appelée « eSIM ».

Pourquoi l’eSIM a-t-elle besoin de plusieurs architectures ?

Le provisioning SIM à distance doit tenir compte des réalités de l’appareil cible.

Un smartphone dispose normalement :

• d’un écran et d’un menu de réglages ;
• d’un utilisateur pouvant donner son consentement ;
• du Wi-Fi ou d’une autre connexion Internet ;
• d’un système d’exploitation avec une interface eSIM ;
• d’une énergie et d’une puissance de calcul suffisantes pour une installation interactive ;
• d’une caméra, d’une application ou d’un gestionnaire de liens.

Un capteur connecté peut ne posséder aucun de ces éléments. Il peut être installé sous terre, à l’intérieur d’une machine scellée ou dans plusieurs pays. Il peut ne se réveiller que périodiquement, communiquer via une technologie radio contrainte et devoir fonctionner dix ans sans intervention manuelle.

Un constructeur automobile a encore d’autres exigences. Les véhicules peuvent être produits dans un pays, expédiés dans le monde entier, associés à différents fournisseurs de services et devoir assurer les appels d’urgence, les diagnostics et les services connectés pendant un long cycle de vie.

Une seule architecture ne peut pas optimiser de manière égale toutes ces conditions.

Aperçu des spécifications GSMA

Ce tableau est volontairement simplifié. Chaque spécification contient des rôles, interfaces, procédures de sécurité et fonctions de cycle de vie détaillés. Les entreprises doivent confirmer la version applicable et sa mise en œuvre avec leurs fournisseurs d’eUICC, d’appareils, de connectivité et de plateforme.

Que signifient les numéros des documents GSMA ?

Les normes eSIM de la GSMA sont réparties entre des documents liés.

Documents d’architecture et d’exigences

Ils décrivent les rôles, cas d’usage, principes et exigences d’une architecture.

• SGP.01 couvre l’architecture et les exigences M2M.
• SGP.21 couvre l’architecture et les exigences grand public.
• SGP.31 couvre l’architecture et les exigences IoT.
• SGP.41 couvre l’architecture et les exigences du provisioning de profils en usine.

Spécifications techniques

Elles définissent les procédures techniques détaillées, les interfaces, les messages et les fonctions de sécurité nécessaires à des implémentations interopérables.

• SGP.02 est la spécification technique de l’architecture M2M.
• SGP.22 est la spécification technique du provisioning SIM à distance grand public.
• SGP.32 est la spécification technique de l’architecture eSIM IoT.

Les raccourcis « eSIM SGP.22 » ou « eSIM SGP.32 » sont pratiques, mais aucun de ces numéros ne désigne un format physique de SIM différent. Ces documents décrivent les architectures de provisioning à distance et les comportements techniques autour d’une eUICC et d’un écosystème de profils compatibles.

Comment fonctionne l’architecture eSIM grand public ?

L’architecture grand public est le modèle le plus familier aux utilisateurs de smartphones. Le client achète un forfait et l’ajoute depuis les réglages de l’appareil, un code QR, une application opérateur, une notification, un lien d’activation ou un processus de transfert pris en charge par le système d’exploitation.

SGP.21 définit l’architecture et les exigences. SGP.22 fournit la spécification technique.

Principaux composants grand public

eUICC

L’eUICC est le composant protégé qui stocke et gère les profils opérateur. Elle peut stocker plusieurs profils, mais la conception de l’appareil détermine combien peuvent être activés simultanément.

Profil eSIM

Le profil contient l’abonnement opérateur et les données d’authentification protégées nécessaires à l’authentification réseau et à la configuration du service.

SM-DP+

Le Subscription Manager Data Preparation Plus prépare, protège et délivre les profils aux appareils grand public éligibles.

Local Profile Assistant

Le Local Profile Assistant, ou LPA, fonctionne côté appareil. Il permet le téléchargement et la gestion des profils et sert d’intermédiaire entre le SM-DP+ et l’eUICC.

Sur un smartphone, le LPA est normalement intégré aux réglages cellulaires et aux fonctions eSIM sécurisées du système d’exploitation. L’utilisateur peut voir une application ou une boutique sous une marque commerciale, mais les opérations protégées sur les profils restent contrôlées par la plateforme de l’appareil.

SM-DS

Le Subscription Manager Discovery Service facultatif peut aider un appareil à découvrir qu’un profil est disponible. Il permet des parcours qui ne reposent pas entièrement sur la saisie manuelle d’une adresse SM-DP+ ou la lecture d’un code QR classique.

Parcours typique de provisioning grand public

1. Le client achète ou demande un forfait mobile.
2. L’opérateur ou le fournisseur prépare ou attribue un profil via le SM-DP+.
3. L’appareil reçoit les informations d’activation ou découvre le profil disponible.
4. L’utilisateur approuve l’installation lorsque cela est requis.
5. Le LPA établit l’interaction nécessaire avec le SM-DP+.
6. Le profil est téléchargé et installé de manière sécurisée sur l’eUICC.
7. L’utilisateur ou le système active le profil sur l’appareil.
8. Le modem l’utilise pour s’enregistrer sur un réseau autorisé.

L’architecture grand public fonctionne bien lorsqu’un utilisateur peut répondre aux sollicitations, confirmer son consentement, sélectionner la bonne ligne et fournir une connexion Internet pour télécharger le profil.

Cas les mieux adaptés à l’eSIM grand public

• eSIM de voyage pour smartphones ;
• abonnements mobiles principaux ;
• tablettes et ordinateurs portables dotés d’une interface eSIM adaptée ;
• montres connectées associées à un compte grand public ;
• applications dans lesquelles le propriétaire de l’appareil choisit activement un fournisseur ;
• équipements en petit nombre avec une interface accessible et pouvant être gérés individuellement.

Atouts de l’architecture grand public

• prise en charge mature sur de nombreux smartphones et systèmes d’exploitation ;
• parcours familiers par code QR et activation numérique ;
• choix et consentement du client intégrés au modèle opérationnel ;
• écosystème SM-DP+ commun ;
• distribution directe au détail et par application ;
• stockage de plusieurs abonnements sur les appareils compatibles.

Limites pour les parcs IoT

Le modèle grand public peut devenir difficile à exploiter lorsque les appareils sont sans surveillance ou dépourvus d’interface utilisateur adaptée.

Le gestionnaire d’un parc peut être dans l’impossibilité de :

• scanner un code QR par appareil ;
• approuver une demande sur chaque écran ;
• maintenir chaque appareil connecté en permanence pendant le provisioning ;
• récupérer physiquement un appareil après un téléchargement échoué ;
• dépendre d’une interface de système d’exploitation grand public ;
• coordonner manuellement des milliers de changements de profil.

Cela ne signifie pas que l’architecture grand public ne puisse jamais servir à un appareil de type IoT. Un routeur doté d’un écran, d’une interface web et appartenant à un parc de taille maîtrisable peut l’utiliser. La réalité opérationnelle est plus importante que l’étiquette du produit.

Comment fonctionne l’architecture eSIM M2M établie ?

L’architecture M2M a été conçue pour les appareils gérés à distance, notamment dans les environnements automobiles et industriels. Ses principaux documents GSMA sont SGP.01 et SGP.02.

Contrairement au modèle grand public, elle ne suppose pas qu’un utilisateur final choisisse un forfait et interagisse avec un LPA sur l’appareil.

Principaux composants M2M

SM-DP

La fonction Subscription Manager Data Preparation prépare et protège les profils opérateur en vue de leur livraison.

SM-SR

La fonction Subscription Manager Secure Routing gère la communication sécurisée avec l’eUICC et permet les opérations à distance sur le cycle de vie des profils.

eUICC M2M

L’eUICC prend en charge les procédures M2M de provisioning à distance pertinentes et reçoit des commandes via cette architecture.

Modèle opérationnel général M2M

L’architecture est fortement pilotée par les serveurs. Les systèmes de gestion lancent le téléchargement, l’activation, la désactivation et la suppression des profils sans dépendre d’un utilisateur présent à côté de l’appareil.

Ce modèle convient aux équipements installés à distance et contrôlés dans le cadre d’accords d’entreprise. Il a servi pendant de nombreuses années à d’importants déploiements de véhicules connectés et d’équipements industriels.

Atouts de l’architecture M2M

• conçue pour des appareils contrôlés de manière centralisée ;
• pas d’interface utilisateur grand public nécessaire ;
• établie dans les programmes automobiles et industriels de longue durée ;
• gestion à distance du cycle de vie ;
• adaptée aux chaînes de fourniture d’entreprise soumises à une gouvernance stricte.

Difficultés opérationnelles

Le SM-SR joue un rôle central dans le modèle M2M. Les relations commerciales et techniques autour de ce composant peuvent rendre les changements de fournisseur plus complexes que les acheteurs ne l’imaginent initialement.

Les difficultés peuvent comprendre :

• une intégration complexe entre plusieurs parties ;
• de longs programmes d’intégration initiale et de certification ;
• une dépendance à la chaîne de gestion des abonnements retenue ;
• des modalités complexes de propriété et de migration ;
• une adéquation limitée aux déploiements plus petits ou plus flexibles ;
• des frictions commerciales lors d’un changement de fournisseur de connectivité.

L’architecture M2M établie reste valable pour les déploiements conçus autour d’elle. Un nouveau projet IoT doit néanmoins la comparer à SGP.31/32 plutôt que supposer que l’« eSIM M2M » est la seule option gérée à distance.

Comment fonctionne l’architecture IoT SGP.31/32 ?

La GSMA a développé l’architecture IoT plus récente pour les eUICC des appareils IoT soumis à des contraintes de réseau et/ou d’interface utilisateur.

SGP.31 définit l’architecture et les exigences. SGP.32 fournit la description technique du provisioning et de la gestion à distance, de l’architecture eUICC, des interfaces et des fonctions de sécurité.

Cette conception associe des principes utiles des architectures précédentes :

• une gestion à distance adaptée aux parcs ;
• la possibilité d’utiliser l’infrastructure SM-DP+ de l’écosystème grand public ;
• des fonctions côté appareil adaptées aux équipements IoT contraints ;
• une gestion ne nécessitant pas qu’une personne utilise un écran local.

Principaux composants IoT

SM-DP+

L’architecture IoT utilise un SM-DP+ pour préparer et délivrer les profils. Cela peut réduire la nécessité d’un écosystème de préparation des profils entièrement distinct.

Cela ne signifie pas que toute intégration SM-DP+ fournisse automatiquement un service SGP.32 complet. L’appareil IoT, l’eUICC, les rôles de gestion, les interfaces et les procédures de sécurité doivent prendre en charge l’architecture concernée.

IoT Profile Assistant

L’IoT Profile Assistant, ou IPA, apporte une assistance côté appareil pour les opérations sur les profils dans l’architecture IoT.

Cette fonction peut être implémentée à différents endroits :

• IPAd, lorsque l’IPA est implémenté dans l’appareil IoT ;
• IPAe, lorsque l’IPA est implémenté dans l’eUICC.

L’option appropriée dépend des ressources de l’appareil, du contrôle du logiciel, de l’implémentation de l’eUICC et de la conception du déploiement.

eSIM IoT Remote Manager

L’eSIM IoT Remote Manager, ou eIM, prend en charge les interactions de gestion à distance avec les appareils IoT et leurs IPA.

L’eIM permet à un processus autorisé de gestion de parc de déclencher et de coordonner les opérations du cycle de vie des profils sans qu’un utilisateur ait à scanner un code QR sur chaque appareil. Ses paquets signés peuvent prendre en charge les déclenchements de téléchargement de profil, les opérations de gestion de l’état des profils, les opérations de configuration de l’eIM, les demandes de données IPA ou eUICC et les accusés de réception.

Il ne faut pas confondre l’eIM avec un SM-DP+. L’eIM contribue à l’orchestration et à la gestion à distance, tandis que le SM-DP+ prépare et délivre les profils.

L’eIM est central dans les opérations de parc orchestrées à distance, mais chaque téléchargement de profil SGP.32 ne doit pas nécessairement commencer par une instruction eIM. La spécification prend également en charge les procédures initiées par l’IPA, notamment l’utilisation d’informations SM-DP+ configurées et de mécanismes de découverte lorsqu’ils sont implémentés.

eUICC IoT

L’eUICC doit prendre en charge l’architecture IoT et les procédures techniques applicables. La présence d’un composant sécurisé intégré ne rend pas automatiquement un appareil compatible SGP.32.

Workflow simplifié SGP.32 géré à distance

1. Un processus d’entreprise ou de service IoT identifie un appareil nécessitant une opération sur son profil.
2. L’environnement de gestion autorisé utilise un eIM pour communiquer l’action requise.
3. L’IPA de l’appareil participe à la procédure.
4. Le profil est obtenu auprès d’un SM-DP+ par une procédure de téléchargement direct ou indirect prise en charge.
5. Le profil est installé et géré sur l’eUICC IoT.
6. L’appareil utilise le profil sélectionné pour se connecter selon les politiques réseau et de service applicables.

Dans un téléchargement direct, l’IPA communique avec le SM-DP+. Dans un téléchargement indirect, l’eIM participe à l’obtention et au transfert du paquet de profil protégé via les interfaces définies. SGP.32 comprend également des mécanismes de découverte, de retour arrière de profil, de profil de secours et de gestion des erreurs.

La séquence exacte dépend du cas d’usage, de la connectivité disponible, de l’implémentation de l’IPA et de la configuration technique. L’intérêt pour l’entreprise réside dans la possibilité de gérer l’opération à l’échelle du parc sans interface grand public sur chaque appareil.

Que signifie « appareil IoT contraint » ?

Les contraintes ne se limitent pas aux dimensions physiques.

Contrainte d’interface utilisateur

L’appareil peut être dépourvu :

• d’écran ;
• de clavier ou d’écran tactile ;
• de caméra pour lire un code QR ;
• d’opérateur local ;
• d’accès pratique, en raison d’un boîtier scellé ou inaccessible.

Contrainte de réseau

L’appareil peut présenter :

• une connectivité intermittente ;
• une bande passante limitée ;
• une latence élevée ;
• des protocoles restreints ;
• de longs intervalles de veille ;
• une connectivité longue portée à faible consommation ;
• une couverture disponible seulement à certains moments de son cycle opérationnel.

Contrainte de ressources

L’appareil peut aussi disposer de ressources limitées en matière de :

• puissance de calcul ;
• mémoire ;
• budget énergétique ;
• complexité applicative ;
• possibilités de mise à jour du firmware.

Tous les appareils contraints ne présentent pas l’ensemble de ces caractéristiques. L’architecture doit être évaluée au regard du matériel réel et des conditions d’exploitation.

SGP.22 grand public et SGP.32 IoT

Le tableau ne tranche pas tous les cas particuliers. Certains routeurs se comportent comme des appareils grand public. Certains équipements industriels disposent d’un système d’exploitation puissant et d’une interface locale. Certains objets portés sont gérés via un téléphone associé plutôt que directement.

Le choix de l’architecture doit suivre le cycle de vie réel, et non une catégorie marketing.

SGP.32 et l’architecture M2M établie

SGP.32 est souvent présentée comme le successeur du modèle M2M antérieur. Cette description indique utilement une direction, mais elle peut induire en erreur sur le plan opérationnel.

Les déploiements M2M existants ne disparaîtront pas immédiatement. Les véhicules, compteurs et appareils industriels peuvent rester actifs dix ans ou davantage. Leurs eUICC et logiciels ont été conçus pour SGP.01/02 et ne peuvent pas nécessairement être convertis à distance vers une autre architecture.

Principales différences

Ce que SGP.32 peut améliorer

Pour les nouveaux déploiements appropriés, l’architecture peut offrir :

• une approche plus évolutive pour les équipements IoT contraints ;
• une dépendance réduite aux interactions grand public ;
• l’utilisation de l’écosystème SM-DP+ plus large ;
• une orchestration à l’échelle du parc via les fonctions eIM ;
• davantage de flexibilité dans la conception des chaînes de fourniture de connectivité ;
• un meilleur alignement entre fabricants d’appareils, fournisseurs de services IoT et fournisseurs de connectivité.

Il s’agit de possibilités architecturales, et non de résultats commerciaux garantis. La conception des contrats, la qualité de mise en œuvre, l’interopérabilité et les droits de sortie restent déterminants.

Qu’est-ce que le provisioning de profils en usine ?

Certains appareils ont besoin d’un profil approprié pendant la fabrication, les tests ou la distribution initiale. La spécification SGP.41 de la GSMA définit l’architecture et les exigences du provisioning de profils en usine, ou IFPP.

L’IFPP concerne une étape différente de la gestion habituelle des profils sur le terrain. Il peut aider les fabricants à provisionner la connectivité pendant la production, plutôt qu’à insérer une carte SIM personnalisée séparément ou à imposer à l’appareil fini de n’effectuer son premier téléchargement de profil qu’après son déploiement.

Les avantages potentiels comprennent :

• une simplification des variantes de fabrication ;
• l’attribution automatisée des profils pendant la production ;
• des tests de connectivité plus précoces ;
• moins de manipulation de SIM physiques ;
• la prise en charge des appareils ayant besoin de connectivité dès leur mise sous tension.

Le provisioning en usine ne doit pas être considéré comme une stratégie couvrant toute la durée de vie. L’appareil peut encore avoir besoin d’une gestion à distance de ses profils et de sa connectivité après sa sortie d’usine.

Choisir une architecture selon le cas d’usage

eSIM de voyage pour smartphones

Choix probable : architecture grand public.

Le client possède un téléphone compatible, peut approuver l’installation et utiliser un code QR, un lien d’activation ou une application. Les priorités commerciales sont la livraison immédiate, des instructions claires, la couverture, la tarification et l’assistance.

Smartphones de collaborateurs gérés par une entreprise

Choix probable : architecture grand public associée à la gestion des appareils d’entreprise et aux processus de l’opérateur.

Les téléphones restent des appareils de catégorie grand public même lorsqu’une entreprise les achète et les administre. Les contrôles d’entreprise ne les transforment pas automatiquement en appareils IoT SGP.32.

Routeurs gérés

Choix possible : architecture grand public ou IoT, selon le routeur.

Un routeur doté d’une interface web et d’un processus d’installation accessible peut utiliser l’eSIM grand public. Un grand parc sans surveillance peut bénéficier d’une architecture IoT. Les acheteurs doivent vérifier la prise en charge exacte du modem, de l’eUICC, du firmware et de la gestion, plutôt que considérer la mention « compatible eSIM » comme suffisante.

Télématique des véhicules

Choix possible : M2M établi pour les programmes existants, SGP.32 pour les nouvelles conceptions adaptées.

Les programmes automobiles ont de longs cycles de vie, des exigences de sécurité et des chaînes de fournisseurs complexes. La migration exige une planification rigoureuse du matériel et de la plateforme.

Compteurs intelligents et capteurs environnementaux

Choix probable pour les nouveaux appareils contraints : architecture IoT.

Ces appareils peuvent être sans écran, fonctionner avec une énergie limitée et rester déployés pendant des années. Une gestion à distance du parc est plus adaptée qu’une installation individuelle par code QR.

Terminaux de paiement et bornes

Choix possible : architecture grand public ou IoT.

La décision dépend de la capacité du terminal à proposer une interface locale contrôlée, de la disponibilité de personnel sur le terrain et du nombre d’appareils nécessitant des changements de profil coordonnés.

Équipements connectés dès l’usine

Choix possible : IFPP pour le provisioning initial, associé à une gestion du cycle de vie M2M ou IoT.

Le processus en usine peut établir la connectivité initiale, tandis que l’architecture déployée régit les changements ultérieurs.

Questions à résoudre avant de choisir SGP.22 ou SGP.32

1. L’appareil possède-t-il une interface locale utilisable ?
2. Une personne sera-t-elle présente pendant le provisioning initial ?
3. L’appareil peut-il scanner, ouvrir ou recevoir des informations d’activation grand public ?
4. Un accès Internet fiable est-il disponible avant l’installation du nouveau profil ?
5. Combien d’appareils faut-il gérer ?
6. Les changements de profil seront-ils individuels ou à l’échelle du parc ?
7. Combien de temps les appareils resteront-ils en service ?
8. Le firmware de l’appareil et l’eUICC peuvent-ils prendre en charge l’architecture requise ?
9. L’IPA est-il implémenté dans l’appareil ou dans l’eUICC ?
10. Qui exploitera ou fournira l’eIM ?
11. Quelles plateformes SM-DP+ et quels fournisseurs de profils sont compatibles ?
12. Quelle connectivité d’amorçage ou de secours est disponible ?
13. Que se passe-t-il si le téléchargement d’un profil est interrompu ?
14. L’appareil peut-il se rétablir sans accès physique ?
15. Quelle partie est autorisée à demander et à approuver les changements de profil ?
16. Comment le parc migrera-t-il vers un autre fournisseur de connectivité ?
17. Quels certificats, processus de conformité et contrôles de production s’appliquent ?
18. Quels événements du cycle de vie la plateforme de gestion peut-elle réellement observer ?

Pourquoi la connectivité d’amorçage compte

Le téléchargement d’un profil à distance nécessite un chemin de communication. Un nouveau profil ne peut pas aider l’appareil à contacter un service de provisioning tant qu’il n’a pas été téléchargé.

Une conception IoT doit donc prévoir une stratégie de connectivité initiale. Selon l’implémentation, celle-ci peut faire appel à :

• un profil initial ou d’amorçage ;
• une connectivité en usine ou locale ;
• un accès Wi-Fi ou filaire ;
• un autre profil actif ;
• un réseau contrôlé de mise en service ;
• une connectivité fournie dans le cadre du processus de déploiement de l’appareil.

Le dispositif d’amorçage doit être évalué en termes de couverture, de coût, de durée de vie et de dépendance au fournisseur. Un profil qui expire trop tôt ou ne fonctionne que dans le pays de fabrication peut empêcher le provisioning ultérieur.

La résilience compte également. Si le profil cible ne se télécharge pas ou ne se connecte pas, l’appareil peut devoir conserver un chemin de secours fonctionnel afin de permettre une nouvelle opération.

La compatibilité d’un appareil ne se résume pas à un logo eSIM

Un appareil « compatible eSIM » peut ne prendre en charge qu’une architecture ou un workflow particulier.

Pour un déploiement fiable, vérifiez :

• la prise en charge du matériel eUICC et du système d’exploitation ;
• l’architecture GSMA et la version de spécification prises en charge ;
• l’implémentation du LPA ou de l’IPA ;
• la compatibilité eIM lorsqu’elle est requise ;
• l’interopérabilité SM-DP+ ;
• la prise en charge du modem et des bandes radio ;
• le comportement d’amorçage et de secours ;
• la capacité de mise à jour distante du firmware ;
• les limites de stockage et d’activation des profils ;
• le rétablissement après une coupure d’alimentation ou de réseau ;
• les preuves de conformité et de certification.

Un routeur eSIM grand public acceptant un code QR n’est pas automatiquement un routeur SGP.32. Une eUICC intégrée n’est pas automatiquement gérable par tous les services de provisioning à distance.

Exigences opérationnelles d’une plateforme eSIM IoT

Le téléchargement des profils n’est qu’une partie de la gestion d’un parc IoT.

Une plateforme opérationnelle peut devoir fournir :

• un inventaire des appareils et des eUICC ;
• la correspondance entre appareil, EID, profil, ICCID et équipement du client ;
• des opérations groupées avec des contrôles d’approbation ;
• une planification et des déploiements progressifs ;
• des états, des nouvelles tentatives et une classification des échecs ;
• une politique de connectivité et une visibilité réseau ;
• le suivi de la consommation et des alertes ;
• la suspension et la réactivation ;
• un historique d’audit ;
• des rôles d’accès pour les organisations clientes ;
• l’intégration par API et webhooks ;
• la gestion de l’amorçage et du secours ;
• des procédures sécurisées de transfert entre fournisseurs et de sortie.

Le système doit distinguer l’état du profil de celui du réseau. « Profil activé » ne prouve pas qu’un capteur s’est rattaché à un réseau, a atteint son point de terminaison applicatif ou a transmis des données utilisables.

Questions commerciales et contractuelles

Les décisions d’architecture créent des dépendances commerciales à long terme.

Les contrats doivent préciser :

• la propriété des eUICC, profils et identifiants ;
• le contrôle de l’eIM, du SM-DP+, du SM-SR ou des comptes de gestion associés ;
• les droits de transfert des profils ou appareils vers un autre fournisseur ;
• la responsabilité de la connectivité d’amorçage ;
• les niveaux de service des opérations de provisioning ;
• la prise en charge des versions de spécification déployées ;
• le renouvellement des certificats et les responsabilités de cycle de vie ;
• l’accès aux données et leur conservation ;
• l’escalade des incidents ;
• les coûts des téléchargements, changements de profil, activations, du stockage et de l’utilisation des API ;
• le traitement des appareils après la fin du contrat.

Le prix par mégaoctet le plus bas peut perdre tout intérêt si le parc ne peut pas changer de fournisseur ou se rétablir après une transition de profil échouée.

Migration et coexistence

Les grandes organisations doivent prévoir la coexistence des architectures.

Une entreprise peut exploiter simultanément :

• d’anciens appareils automobiles utilisant SGP.01/02 ;
• des smartphones utilisant SGP.21/22 ;
• de nouveaux capteurs conçus pour SGP.31/32 ;
• des appareils provisionnés en usine entrant en service via l’IFPP.

Remplacer tous les appareils en même temps est rarement économique. La couche de gestion doit donc tenir un inventaire clair de l’architecture, des capacités eUICC, du fournisseur de profils et des opérations de cycle de vie disponibles pour chaque population d’appareils.

Une démarche de migration raisonnable

1. Segmenter le parc installé par appareil, modem, eUICC et architecture.
2. Identifier les appareils capables de prendre en charge une nouvelle méthode de provisioning et ceux qui doivent être remplacés.
3. Définir les exigences des futurs appareils en nommant explicitement l’architecture GSMA cible.
4. Tester l’interopérabilité avec la combinaison réelle d’eUICC, d’IPA, d’eIM et de SM-DP+.
5. Valider les scénarios d’amorçage, de retour arrière et de perte de connectivité.
6. Réaliser un pilote contrôlé dans des pays et sur des réseaux représentatifs.
7. Migrer progressivement avec des critères de réussite mesurables.
8. Conserver une voie opérationnelle pour les appareils existants pendant toute leur durée de vie restante.

Une migration d’architecture ne doit jamais commencer par un changement de profils en masse sans procédure de rétablissement testée.

Idées reçues courantes

« Toutes les eSIM fonctionnent avec SGP.22 et SGP.32 »

Non. La compatibilité dépend de l’eUICC, du logiciel de l’appareil, des composants de provisioning et de l’architecture prise en charge.

« SGP.32 est simplement une eSIM grand public sans écran »

Non. Elle introduit un modèle de gestion propre à l’IoT avec l’IPA et l’eIM pour répondre aux besoins des appareils contraints et des opérations de parc.

« SGP.32 remplace immédiatement toutes les eSIM M2M »

Non. Les appareils M2M existants peuvent rester opérationnels pendant de nombreuses années et ne pas pouvoir être mis à niveau vers la nouvelle architecture.

« Utiliser un SM-DP+ signifie que toute la solution prend en charge SGP.32 »

Non. Le SM-DP+ n’est qu’une partie de l’architecture. L’appareil, l’eUICC, l’IPA, l’eIM et les interfaces doivent eux aussi prendre en charge les procédures requises.

« L’eSIM IoT fournit automatiquement une couverture multiréseau »

Non. Le provisioning à distance change la façon de gérer les profils. L’accès réseau dépend toujours du profil commercial, de l’opérateur et des accords d’itinérance.

« Un parc peut toujours changer de fournisseur à distance »

Seulement si la conception technique et contractuelle complète le permet. La connectivité d’amorçage, les autorisations, la maîtrise des systèmes de gestion, les profils compatibles et les procédures de rétablissement comptent tous.

« Tous les routeurs devraient utiliser SGP.32 »

Pas nécessairement. Un routeur géré par son utilisateur peut très bien fonctionner avec l’architecture grand public. Le choix approprié dépend de la taille du parc, de son accessibilité et de son cycle de vie.

La place de SIM24.biz dans le choix de l’architecture

SIM24.biz accompagne les entreprises qui construisent des offres de connectivité grand public, SIM physique et IoT sous leur propre marque.

Le point de départ commercial doit être le produit et le cycle de vie de l’appareil, et non un numéro de spécification choisi isolément. Une marque de voyage destinée aux smartphones n’a pas les mêmes exigences de provisioning qu’un fabricant déployant des traceurs scellés dans plusieurs pays.

SIM24.biz peut aider un partenaire à structurer le modèle de connectivité, de plateforme et d’exploitation nécessaire. La prise en charge exacte d’une architecture GSMA, d’un type d’eUICC, d’un composant de provisioning ou d’une fonction distante de cycle de vie doit être confirmée pour l’implémentation et la combinaison de fournisseurs retenues. À la date de ce brouillon, aucune affirmation publique n’est faite selon laquelle SIM24.biz exploite elle-même un eIM, un SM-DP+, un SM-SR ou une plateforme SGP.32 certifiée.

Cette distinction protège les deux parties. Elle évite de promettre qu’un produit grand public par code QR fournit une gestion complète de parc IoT, ou qu’une eUICC IoT peut utiliser n’importe quelle plateforme de profils sans travail de compatibilité.

Conclusion

L’eSIM grand public et l’eSIM IoT reposent sur la même idée générale : des profils d’opérateurs mobiles peuvent être provisionnés de manière sécurisée sur une eUICC compatible. Leurs environnements opérationnels sont fondamentalement différents.

L’architecture grand public SGP.21/22 suppose un appareil capable de participer à un processus interactif d’acquisition de profil. Elle utilise notamment le SM-DP+, le LPA et, éventuellement, le SM-DS, et convient bien aux smartphones, tablettes et appareils utilisés directement par une personne.

L’architecture IoT SGP.31/32 est conçue pour les appareils contraints par la connectivité, l’interface utilisateur ou les deux. Elle introduit l’IPA et l’eIM pour permettre une gestion distante orientée parc tout en utilisant une infrastructure de profils SM-DP+.

L’architecture M2M SGP.01/02 reste importante dans les déploiements automobiles et industriels établis. SGP.41 ajoute une option distincte pour le provisioning des profils pendant la fabrication.

Aucune de ces normes ne supprime le besoin de tester les appareils, de prévoir une connectivité d’amorçage, de conclure des accords réseau, d’exploiter le parc ou de disposer de contrats fournisseurs clairs. La bonne architecture est celle qui permet de provisionner, connecter, rétablir et migrer la population réelle d’appareils pendant toute sa durée de vie prévue.

Questions fréquentes

Quelle est la principale différence entre SGP.22 et SGP.32 ?

SGP.22 est la spécification technique de l’architecture eSIM grand public, couramment utilisée par des appareils interactifs tels que les smartphones. SGP.32 est la spécification technique de l’architecture IoT conçue pour les appareils IoT contraints par le réseau ou l’interface utilisateur et pour la gestion de parc.

Quelle est la différence entre SGP.21 et SGP.22 ?

SGP.21 définit l’architecture et les exigences grand public. SGP.22 fournit la spécification technique détaillée qui met en œuvre cette architecture.

Quelle est la différence entre SGP.31 et SGP.32 ?

SGP.31 définit l’architecture et les exigences du provisioning eSIM pour les appareils IoT contraints. SGP.32 précise les procédures techniques détaillées, les interfaces, l’architecture eUICC et les fonctions de sécurité.

Que sont l’IPA et l’eIM ?

L’IoT Profile Assistant est la fonction côté appareil qui prend en charge les opérations sur les profils dans l’architecture SGP.31/32. Il peut résider dans l’appareil sous la forme IPAd ou dans l’eUICC sous la forme IPAe. L’eSIM IoT Remote Manager prend en charge les interactions autorisées de gestion à distance avec l’IPA.

SGP.32 utilise-t-elle un SM-DP+ ?

Oui. L’architecture IoT utilise un SM-DP+ pour préparer et délivrer les profils. Une solution complète nécessite toujours un appareil IoT, une eUICC, un IPA, un eIM et des interfaces de gestion compatibles.

SGP.32 est-elle meilleure que SGP.22 ?

Elle est mieux adaptée à certains environnements IoT, sans être universellement meilleure. Une eSIM de voyage pour smartphone correspond normalement à l’architecture grand public. Un parc de capteurs sans surveillance peut correspondre à SGP.32.

SGP.32 remplace-t-elle SGP.01 et SGP.02 ?

Elle fournit une architecture plus récente pour les déploiements IoT appropriés, mais les appareils et plateformes M2M existants coexisteront pendant des années. La migration dépend du matériel, des logiciels, des contrats et des cycles de remplacement des appareils.

Un appareil eSIM grand public existant peut-il être mis à niveau vers SGP.32 ?

Pas automatiquement. L’appareil, l’eUICC et le logiciel doivent prendre en charge l’architecture IoT. Une simple mise à jour du firmware peut ne pas suffire.

SGP.32 peut-elle faire passer un appareil d’un opérateur mobile à un autre ?

Elle prend en charge le provisioning et la gestion des profils à distance, ce qui peut permettre de changer d’opérateur lorsque des profils compatibles, les autorisations, la connectivité et les accords commerciaux nécessaires existent. Elle ne contourne pas les restrictions de l’appareil, du contrat ou du réseau.

SGP.32 est-elle nécessaire pour chaque déploiement IoT ?

Non. Certains routeurs ou terminaux accessibles peuvent utiliser avec succès l’eSIM grand public. Les déploiements industriels existants peuvent utiliser l’architecture M2M. La décision dépend du modèle opérationnel réel.

Qu’est-ce que SGP.41 ?

SGP.41 définit l’architecture et les exigences du provisioning de profils en usine. Elle traite de la livraison des profils pendant la fabrication des appareils et complète la gestion du cycle de vie sur le terrain, sans la remplacer.

Choisissez une architecture eSIM adaptée à tout le cycle de vie de vos appareils

SIM24.biz aide les entreprises à concevoir des offres de connectivité grand public et IoT sous leur propre marque, à partir des appareils réels, des conditions d’exploitation et des besoins de gestion.

Échangez avec SIM24.biz sur le modèle de provisioning et de connectivité adapté à votre produit ou à votre parc.

Sources

1. GSMA, « eSIM Consumer and IoT Specifications » : https://www.gsma.com/solutions-and-impact/technologies/esim/esim-specification/
2. GSMA, « A Guide to eSIM Architectures » : https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/a-guide-to-esim-architectures/
3. GSMA, « SGP.21 v2.6, eSIM Consumer Architecture and Requirements » : https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-21-v2-6/
4. GSMA, « SGP.22 v2.7, eSIM Consumer Technical Specification » : https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-22-v2-7/
5. GSMA, « SGP.31 v1.3, eSIM IoT Architecture and Requirements » : https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-31-v1-3/
6. GSMA, « SGP.32 v1.3, eSIM IoT Technical Specification » : https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-32-v1-3/
7. GSMA, « M2M Specifications » : https://www.gsma.com/solutions-and-impact/technologies/esim/esim-m2m-specifications/
8. GSMA, « SGP.01 v4.3, Embedded SIM Remote Provisioning Architecture » : https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/uploads/2022/11/SGP.01-v4.3-1.pdf
9. GSMA, « SGP.02 v4.3, Remote Provisioning Architecture for Embedded UICC Technical Specification » : https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-02-remote-provisioning-architecture-for-embedded-uicc-technical-specification-v4-3/
10. GSMA, « SGP.41 v1.0, eSIM IFPP Architecture and Requirements » : https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/esim-ifpp-architecture-and-requirements/
11. Android Open Source Project, « Implement eSIM » : https://source.android.com/docs/core/connect/esim-overview