SGP.32 : la norme eSIM IoT expliquée

Par Aurélie, M2M Network.

En bref : SGP.32 est la spécification technique publiée par la GSMA pour l’eSIM des objets connectés (eSIM IoT). Elle permet de télécharger, d’activer et de supprimer à distance les profils d’opérateurs sur des objets sans écran ou à la connectivité limitée, sous le contrôle d’un gestionnaire de profils appelé eIM, que l’exploitant de la flotte peut opérer lui-même ou confier à un prestataire. Elle s’appuie sur l’architecture SGP.31 et reprend les briques du modèle grand public (SGP.22) plutôt que celles du modèle M2M historique (SGP.02).

Ce guide s’adresse aux intégrateurs et aux fabricants d’objets. Il situe SGP.32 par rapport aux deux autres normes, décrit ses composants, ce qu’elle change pour l’exploitation d’un parc et son calendrier d’adoption.

SGP.02, SGP.22, SGP.32 : trois normes eSIM pour trois usages

La GSMA, l’association mondiale des opérateurs mobiles, a publié trois familles de spécifications de provisionnement à distance des cartes SIM (Remote SIM Provisioning). Chacune associe un document d’architecture et une spécification technique. Les versions ci-dessous sont celles des index publiés par la GSMA en octobre 2026.

SGP.02 (M2M)SGP.22 (grand public)SGP.32 (IoT)
Document d’architectureSGP.01SGP.21SGP.31
Première publicationDécembre 2013Architecture en décembre 2015, spécification v2.0 en octobre 2016Architecture en avril 2022, spécification en 2023
Version active la plus récente4.3 (25 janvier 2023)3.1 (décembre 2023) et 2.7 (avril 2026)1.3 (22 mai 2026)
Qui déclencheUne plateforme côté réseau (modèle « push »)L’utilisateur sur l’appareil (modèle « pull »)Le gestionnaire de la flotte (eIM), par envoi ou à l’interrogation de l’objet
ServeursSM-DP et SM-SRSM-DP+ et SM-DSSM-DP+, SM-DS et eIM
Côté objetPas d’interface ; commandes reçues par SMS ou HTTPSLPA ; code d’activation saisi ou scanné, confirmation par l’utilisateurIPA, dans l’objet (IPAd) ou dans la puce (IPAe)
CibleAutomobile, industrie, grands déploiementsSmartphones, tablettes, objets portésObjets à connectivité contrainte ou sans interface

SGP.02 : le modèle M2M piloté par le réseau

SGP.02 est la plus ancienne : sa version 1.0 date du 19 décembre 2013. Elle vise les appareils M2M difficiles à joindre (« not easily reachable » dans le texte). Deux rôles se partagent le travail côté serveur. Le SM-DP prépare les profils et gère leur téléchargement sécurisé. Le SM-SR exécute les opérations de gestion de la puce (activer, désactiver, supprimer un profil) et lui transmet les commandes par SMS ou par HTTPS ; il partage avec elle les clés de gestion.

La GSMA rappelle que ce modèle a surtout servi l’automobile et l’industrie, pour de grands déploiements qui demandent un investissement et une intégration importants. Pour changer d’opérateur, le SM-DP du nouvel opérateur doit se raccorder au SM-SR en place (interface ES3), et changer de SM-SR fait l’objet d’une procédure dédiée. SGP.02 reste active : sa version 4.3, du 25 janvier 2023, figure toujours comme en vigueur.

SGP.22 : le modèle grand public, code QR et LPA

SGP.22 a été conçue pour les smartphones, tablettes et objets portés. Le téléchargement part de l’appareil (modèle « pull ») : un logiciel appelé LPA (Local Profile Assistant) récupère le profil auprès du SM-DP+ de l’opérateur à partir d’un code d’activation, que la norme impose de pouvoir saisir à la main ou scanner sous forme de code QR. Le nom de l’opérateur est affiché à l’utilisateur, qui doit confirmer avant le téléchargement.

Cette architecture ne comporte pas de SM-SR : le SM-DP+ établit directement un canal sécurisé de bout en bout avec la puce. Elle suppose en revanche une interface, un utilisateur et une action sur chaque appareil, ce qui ne convient pas à un parc de capteurs sans écran.

SGP.31 et SGP.32 : l’architecture eSIM IoT

La GSMA a publié l’architecture et les exigences de l’eSIM IoT (SGP.31) en avril 2022, puis la spécification technique (SGP.32) en 2023. Le but : provisionner à distance des objets dits contraints en réseau (faible débit, parfois sans TCP ni même IP), en interface (peu ou pas d’écran), ou les deux. SGP.31 se construit sur l’architecture grand public SGP.21 : on y retrouve le SM-DP+ et le SM-DS, mais pas le SM-SR. Ses éléments sont les suivants :

  • eIM (eSIM IoT Remote Manager) : le gestionnaire de profils d’un objet ou d’une flotte. Il déclenche les téléchargements et envoie à la puce des opérations signées : activer, désactiver, supprimer ou lister les profils. Il peut être autonome ou intégré à une plateforme de gestion d’objets.
  • IPA (IoT Profile Assistant) : l’équivalent du LPA, sans interface utilisateur. Il relaie les ordres de l’eIM vers la puce, télécharge le profil et transmet les notifications. Il se trouve dans l’objet (IPAd) ou dans l’eUICC (IPAe), et un seul est actif à la fois.
  • SM-DP+ : la plateforme qui prépare le profil de l’opérateur et le chiffre pour une puce donnée, comme dans le modèle grand public.
  • SM-DS : un service de découverte qui signale qu’un profil attend une puce ; c’est l’une des trois façons de déclencher un téléchargement, avec le code d’activation et le SM-DP+ par défaut.
  • eUICC : la puce, qui n’accepte les opérations de gestion que si elles sont signées par un eIM qui lui est associé. L’eUICC peut aussi être intégré au processeur ; la norme lui impose alors les mêmes tests (voir notre article sur l’iSIM).

Des transports adaptés aux objets contraints

SGP.32 n’impose pas de protocole entre l’eIM et l’IPA, seulement l’intégrité et la confidentialité des messages. Elle suggère HTTPS quand TCP est disponible, et CoAP sur UDP protégé par DTLS pour les objets contraints ; une annexe décrit le transport par LwM2M. Si l’objet dispose déjà d’un canal vers son serveur, ce canal peut porter les messages eSIM. Les principes de SGP.31 prévoient aussi un provisionnement sans SMS, des transports non IP et des opérations exécutées plus tard, quand l’objet sort de veille (modes PSM ou eDRX). Ils visent explicitement les réseaux LPWA, comme le LTE-M et le NB-IoT.

Des garde-fous en cas d’échec

Changer de profil sur un objet qu’on ne peut pas aller voir comporte un risque : le perdre si le nouveau profil ne se connecte pas. SGP.31 impose donc à la puce un mécanisme de retour arrière (rollback) : si l’eIM l’a demandé et que l’objet ne parvient pas à le joindre avec le profil fraîchement activé, la puce réactive le profil précédent. Un mécanisme de repli (fallback), optionnel, active un profil désigné à l’avance quand le profil en service perd le réseau.

Ce que SGP.32 change pour une flotte

La GSMA résume l’apport ainsi : SGP.32 donne aux entreprises la possibilité de changer de profil de connectivité sur le terrain, pour réagir à un changement réglementaire, une fin de contrat ou un problème de réseau, sans accéder physiquement aux objets. Les principes de SGP.31 prévoient explicitement que l’entité qui gère la flotte (propriétaire des objets, entreprise, fournisseur de service mobile ou prestataire IoT) puisse automatiser ces opérations.

Changer d’opérateur sur un parc SGP.32, étape par étape

  1. Le nouvel opérateur prépare les profils sur son SM-DP+ pour les puces concernées, identifiées par leur EID.
  2. L’eIM demande à chaque objet de télécharger son profil, au moyen d’un code d’activation, du SM-DS ou d’un SM-DP+ par défaut.
  3. L’IPA télécharge le profil chiffré, directement auprès du SM-DP+ ou par l’intermédiaire de l’eIM, et l’installe dans la puce.
  4. L’eIM envoie une opération signée d’activation du nouveau profil, en demandant le retour arrière en cas d’échec.
  5. L’objet vérifie qu’il joint l’eIM avec le nouveau profil ; sinon, la puce revient au profil précédent.
  6. Les notifications remontent vers les SM-DP+ concernés, puis l’eIM peut faire supprimer l’ancien profil.

L’opération se mène par campagne, sans technicien. Les limites sont ailleurs : le nouvel opérateur doit accepter de fournir des profils pour ces puces, et l’eIM doit rester sous votre contrôle ou celui d’un prestataire dont vous pouvez sortir. Cette brique s’ajoute aux autres outils de gestion de flotte M2M.

Calendrier d’adoption de SGP.32

DateÉtape
19 décembre 2013SGP.02 version 1.0, première spécification eSIM M2M
Décembre 2015 et octobre 2016SGP.21 version 1.0 puis SGP.22 version 2.0, modèle grand public
Avril 2022SGP.31 version 1.0 : architecture et exigences de l’eSIM IoT
25 janvier 2023SGP.02 version 4.3, toujours en vigueur
4 juillet 2023SGP.32 version 1.0.1, qui corrige des erreurs de la version 1.0
26 janvier 2024SGP.33-1 version 1.0, premier plan de test de la puce eSIM IoT
27 juin 2024SGP.32 version 1.2
27 janvier 2025Plans de test version 1.2 pour la puce (SGP.33-1), l’IPA (SGP.33-2) et l’eIM (SGP.33-3)
29 avril 2025Giesecke+Devrient annonce le premier eUICC IoT certifié dans le schéma de sécurité eSA de la GSMA et déclaré conforme
28 juillet 2025SGP.24 version 2.6.1 : procédure de conformité couvrant SGP.31 et SGP.32
4 décembre 2025Rapport de conformité eSIM 2025 de la GSMA : première vague de produits IoT conformes
22 mai 2026SGP.31 et SGP.32 version 1.3 (maintenance)

Depuis 2025, la norme dispose donc de plans de test complets et d’un processus de certification. Reste l’écosystème : un article de la GSMA publié en mai 2026 présente l’interopérabilité entre puces, logiciels et plateformes comme la préoccupation centrale, et un représentant d’IDEMIA y observe que la plupart des clients qu’il rencontre n’ont pas encore de stratégie pour cette technologie.

Points de vigilance pour un intégrateur

  • La puce. Exigez un eUICC déclaré conforme pour l’IoT : la GSMA demande une certification de sécurité du composant et du logiciel, l’audit du site de fabrication et des tests fonctionnels selon SGP.33-1. La puce indique elle-même si elle relève de l’eSIM IoT.
  • L’IPA. Vérifiez si le module ou le logiciel de l’objet embarque un IPA (IPAd) ou si la puce en fournit un (IPAe).
  • L’eIM. Décidez qui l’opère et à quel moment il est associé à la puce : chez le fabricant de la puce, à la production de l’objet ou sur le terrain. Une fois un eIM associé, c’est lui qui autorise les suivants. La déclaration de conformité d’un eIM existe, mais elle est facultative.
  • Les profils. Listez les opérateurs prêts à livrer des profils pour vos puces, sur chaque marché visé, et faites un essai de bout en bout avant l’industrialisation.
  • La sécurité. SGP.31 analyse les risques d’un eIM compromis ou malveillant : traitez-le comme un composant critique, au même titre que vos serveurs (voir notre guide sur la sécurité des appareils connectés).

Ce que propose M2M Network

M2M Network fournit des cartes SIM M2M en eSIM ou en SIM physique, sur le réseau d’Orange, de SFR ou de Bouygues Telecom au choix, ainsi que des SIM IoT multi-opérateurs, avec IP fixe, 5G ou APN privé en option. Pour un projet de flotte en eSIM, la norme prise en charge par vos modules (SGP.02, SGP.22 ou SGP.32) détermine l’offre adaptée : indiquez-la dans votre demande via le formulaire de contact. Les forfaits data courants se commandent sur la boutique M2M Network.

À lire aussi

Questions fréquentes

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

SGP.31 décrit l’architecture et les exigences de l’eSIM IoT : rôles, interfaces, principes. SGP.32 en est la spécification technique : messages, protocoles, sécurité. Les deux évoluent ensemble ; leur version 1.3 date du 22 mai 2026.

Qu’est-ce qu’un eIM ?

L’eIM (eSIM IoT Remote Manager) est le gestionnaire de profils défini par SGP.31 et SGP.32. Il déclenche le téléchargement des profils et envoie à la puce des opérations signées pour activer, désactiver ou supprimer un profil. Il peut être opéré par l’entreprise, un fournisseur de service mobile ou un prestataire IoT.

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

Pas formellement : la version 4.3 de SGP.02, publiée le 25 janvier 2023, figure toujours comme en vigueur dans l’index de la GSMA. SGP.32 offre une alternative plus simple à intégrer, construite sur le modèle grand public, pour les objets contraints ou sans interface.

Une eSIM SGP.22 peut-elle servir pour un objet connecté ?

Oui, si l’objet dispose d’une interface, éventuellement par un appareil compagnon comme un smartphone, pour saisir ou scanner le code d’activation et confirmer le téléchargement. Pour un capteur sans écran ni utilisateur, ce modèle ne convient pas : c’est le cas couvert par SGP.32.

Faut-il un écran ou des SMS pour utiliser SGP.32 ?

Non. SGP.32 vise des objets sans interface utilisateur, et SGP.31 prévoit un provisionnement possible sans SMS, y compris sur des transports non IP. Les échanges passent par HTTPS, par CoAP sur DTLS ou par le canal que l’objet utilise déjà avec son serveur.

Les puces SGP.32 sont-elles certifiées ?

Oui. La GSMA a intégré l’eSIM IoT à son programme de conformité et à son schéma de sécurité eSA. Giesecke+Devrient a annoncé le 29 avril 2025 le premier eUICC IoT certifié, et la GSMA évoquait en décembre 2025 une première vague de produits IoT conformes.

Sources