12 février 2026 · 19 min read

LTI dans les détails

LTI est un standard qui permet de partager du contenu avec un LMS

#LTI #e-learning #standard #LMS

LTI (Learning Tools Interoperability) est un standard développé par 1EdTech (anciennement IMS Global). Il répond à un problème concret : comment intégrer un outil externe dans un LMS de manière transparente pour l’apprenant ?

Prenons un exemple. Une organisation spécialisée dans l’apprentissage des langues propose des vidéos, des QCM et des exercices audio. Une université équipée d’un LMS, Moodle par exemple, souhaite intégrer ces contenus dans certaines UE. L’outil est également intéressé par ce marché, universités, lycées, collèges mais comment s’y intégrer facilement ?

Trois options s’offrent à lui :

C’est cette troisième option que LTI rend possible.

Histoire

La première version largement adoptée, LTI 1.1, repose sur un mécanisme simple : un POST signé OAuth 1.0a. Quand un apprenant clique sur un lien LTI dans le LMS, celui-ci envoie une requête HTTP POST à l’outil avec les informations de contexte (identité de l’utilisateur, cours, rôle) signées avec une clé partagée. L’outil fait confiance à ce message et affiche directement le contenu approprié — l’apprenant n’a pas à se reconnecter.

LTI 1.1 introduit également le service Basic Outcomes : l’outil peut renvoyer une note numérique au carnet de notes du LMS. C’est minimal mais suffisant pour de nombreux cas d’usage.

Les limites de LTI 1.1 sont celles d’OAuth 1.0a : sécurité vieillissante, configuration manuelle fastidieuse entre chaque paire LMS/outil, et des services trop limités pour les usages modernes.

Les prérequis techniques

Deux notions essentielles

Sécuriser les échanges - OpenID Connect (OIDC)

Pour sécuriser les échanges, LTI 1.3 s’appuie sur deux standards du web : OAuth 2.0 et OpenID Connect (OIDC).

Les concepts de base

Les Acteurs du protocole

Terme OIDCRôle dans LTI 1.3Description
OpenID Provider (OP)La Plateforme (LMS)Le fournisseur d’identité (Moodle, Canvas). Il authentifie l’utilisateur et émet les jetons.
Relying Party (RP)L’Outil (Tool)L’application tierce qui demande l’authentification et “fait confiance” au LMS.

Pour le protocole LTI on parle donc de plateforme pour désigner le LMS et d’outils pour désigner les applications tierces. C’est issu de la terminologie OIDC.

Le Jeton d’identité (id_token)

Le id_token est un objet JWT(JSON Web Token) signé par le LMS. Il contient des Claims (affirmations) que l’outil doit extraire et vérifier :

Vous trouverez plus d’informations sur ces paramètres dans rfc7519 et LTI Impl

4. Les paramètres du flux

Pour que l’échange fonctionne, l’outil et le LMS s’échangent ces informations :

Ressources utiles :

Sécurité cryptographique : RSA et JWKS

La sécurité repose sur l’échange de clés publiques.

Registration & Deployment

La plateforme et l’outil doivent se reconnaître mutuellement. Cette étape s’appelle la registration. C’est une opération manuelle, réalisée une seule fois par un administrateur. Elle consiste à échanger les URLs de configuration et les clés publiques entre les deux systèmes. En effet, créer un outil LTI c’est à dire, vouloir fournir du contenu à tout types d’LMS compatible LTI c’est avant tout créer une Api avec quelques endpoints respectant le flow LTI. Le LMS doit connaitre l’url des ces endpoints. l’outil doit donc fournir au LMS :

Le LMS doit fournir à l’outil :

Le LMS peut également fourni à l’outil des informations personnalisée spécifiques. Un identifiant interne, un niveau pédagogique, un groupe de travail etc..

LTI propose un mécanisme de substitution de variables et propose de nombreuse variables que le LMS la remplacera dynamiquement par sa valeur réelle au moment du lancement. Ce sont des paramètre personnalisé préfixés du symbole $. La liste complète des variables est disponible dans l’Appendice B de la spec LTI. Toutefois, le LMS peut ne pas être compatible avec toutes les variables si c’est le cas la variable sera renvoyée à l’outil tel quel, elle n’aura pas de valeur.

Exemple de registration avec le LMS MOODLE

Registration avec Moodle

  1. Ce lien est fournit par l’organisation qui gère l’outil soit par email, soit via une interface d’administration.
  2. L’identifiant du client (Client ID) doit être fourni à l’outil. Cet identifiant est généré par le LMS. Idem soit par mail, soit via une interface d’administration.
  3. L’url pour obtenir le jwks_url doit également être fournie. Cette URL permet à l’outil de récupérer la clé publique du LMS pour vérifier les signatures des JWT. C’est l’outil qui doit fournir cette url également.
  4. L’outil doit également fournir une url permettant d’établir un login (nous détaillerons ce point à l’étape 1 de la section suivante)
  5. Il s’agit de paramètre que souhaite transmettre le LMS à l’outil lors du lancement. Ici le LMS et l’outil se sont mis d’accord d’envoyer le niveau pédagogique de l’utilisateur, la date de début de l’exercice ainsi que la date de fin. Le niveau est un paramètre personnalisé fixe qui n’existe pas dans la spec LTI. La date de début et de fin sont des variables de substitution elles seront remplacées par leur valeur réelle au moment du lancement.

A ce stade là l’outil a été préconfiguré. A présent, il peut être utilisé en tant qu’activité dans un cours. LTI appelle cette insertion un déploiement. l’outil est donc configuré une seule fois avec les paramètres nécessaires. et déployé plusieurs fois dans un même cours ou dans des cours différents.

Note : LTI permet également le dynamic registration des outils. Il s’agit d’un mécanisme automatisé où l’outil peut s’enregistrer lui-même auprès du LMS en fournissant les informations nécessaires via une requête HTTP.

Le flux de lancement LTI 1.3

Quand un apprenant clique sur une activité LTI dans son LMS, un échange en 4 étapes se déclenche entre le navigateur, la plateforme et l’outil afin de s’authentifier.

Étape 1 — Third-Party Initiated Login

Le principe d’LTI c’est de s’intégrer dans le LMS directement, ce qui pose bien sûr le problème de l’authentification puisqu’il faut que l’apprenant puisse accéder à l’outil sans devoir se reconnecter. Il semble difficile de fonctionner avec un flux classique, à savoir l’utilisateur se connecte directement sur l’outil (ex: Kahoot.com), c’est ce que souhaite éviter LTI. Pour cela, LTI s’appuie sur le mécanisme du Third Party Initiated Login (openID spec). Ce flux permet à une entité tierce (ici, le LMS) d’initier une demande d’authentification auprès de l’outil, en lui disant : ‘Prépare-toi, je t’envoie un utilisateur, voici les indices pour l’identifier’. Dans la spécification LTI, 1edTech explique avoir fait ce choix afin de sécuriser le flux contre des attaques de type Login Cross-Site Request Forgery (CSRF). Le LMS joue le rôle de fournisseur d’identité, c’est lui qui connait l’utilisateur et pas l’outil tiers (qui n’a jamais vu l’utilisateur avant). C’est le LMS qui initie le flux d’authentification en redirigeant le navigateur de l’apprenant vers l’endpoint OIDC de l’outil avec les paramètres nécessaires pour identifier la session utilisateur.

ParamètreDescription
issL’identifiant (IRI) de la plateforme
login_hintToken opaque identifiant la session utilisateur côté LMS
target_link_uriL’URL de la ressource à afficher dans l’outil

Exemple avec Moodle

iss=http://localhost
target_link_uri=http://localhost:8000/lti/launch/
login_hint=2
lti_message_hint={"cmid":2,"launchid":"ltilaunch1_21589944"}
client_id=Sfc6HFnwHAx4Tuv
lti_deployment_id=1

Étape 2 — Authentication Request

L’outil génère deux valeurs aléatoires pour sécuriser l’échange :

L’outil redirige ensuite le navigateur vers l’endpoint d’authentification de la plateforme avec :

response_type = id_token
scope         = openid
client_id     = l'identifiant de l'outil
redirect_uri  = l'URL de l'outil où recevoir le JWT
login_hint    = renvoyé tel quel, non modifié
lti_message_hint = renvoyé tel quel, non modifié
state         = généré par l'outil
nonce         = généré par l'outil

Exemple de paramètres avec le LMS Moodle

scope=openid
response_type=id_token
response_mode=form_post
prompt=none
client_id=Sfc6HFnwHAx4Tuv
redirect_uri=http://localhost:8000/lti/launch/
state=state-1afed909-2dfb-4bc0-b219-0c58c70928c0
nonce=f53b7089cb7d4ffd8e6e1d7be2fa3e659a621d14301d11f1aad18cb87ec90090
login_hint=2
lti_message_hint={"cmid":2,"launchid":"ltilaunch1_322075607"}

Étape 3 — Authentication Response

La plateforme reçoit la requête d’authentification et valide à son tour :

Si tout est valide, la plateforme génère le JWT signé (id token) contenant tous les claims LTI et le POST vers la redirect_uri de l’outil :

state       = renvoyé tel quel (l'outil doit le vérifier)
id_token    = le JWT signé contenant les claims LTI

Étape 4 — Validation et affichage

L’outil reçoit le POST avec le state et l’id_token. Il procède à la validation finale :

  1. Vérifier que le state correspond bien à celui généré à l’étape 2
  2. Récupérer la clé publique de la plateforme depuis son URL JWKS, en utilisant le kid présent dans le header du JWT
  3. Vérifier la signature du JWT avec cette clé publique
  4. Vérifier les claims standards : iss, aud, exp, nonce

Si toutes les vérifications passent, l’outil extrait les claims LTI du JWT et affiche la ressource appropriée à l’apprenant — sans que celui-ci ait eu à se connecter ou à changer d’environnement.

Exemple d’id token (LMS MOODLE)

{
  "nonce": "41c2a310007440a891bbb6b594b32076338f196b2ffb11f1b2bd8cb87ec90090",
  "iat": 1775289137,
  "exp": 1775289197,
  "iss": "http://localhost",
  "aud": "Sfc6HFnwHAx4Tuv",
  "https://purl.imsglobal.org/spec/lti/claim/deployment_id": "1",
  "https://purl.imsglobal.org/spec/lti/claim/target_link_uri": "http://localhost:8000/lti/launch/",
  "sub": "2",
  "https://purl.imsglobal.org/spec/lti/claim/lis": {
    "person_sourcedid": "",
    "course_section_sourcedid": ""
  },
  "https://purl.imsglobal.org/spec/lti/claim/roles": [
    "http://purl.imsglobal.org/vocab/lis/v2/institution/person#Administrator",
    "http://purl.imsglobal.org/vocab/lis/v2/membership#Instructor",
    "http://purl.imsglobal.org/vocab/lis/v2/system/person#Administrator"
  ],
  "https://purl.imsglobal.org/spec/lti/claim/context": {
    "id": "2",
    "label": "pyLTI",
    "title": "PYTHON LTI",
    "type": [
      "CourseSection"
    ]
  },
  "https://purl.imsglobal.org/spec/lti/claim/message_type": "LtiResourceLinkRequest",
  "https://purl.imsglobal.org/spec/lti/claim/resource_link": {
    "title": "Hello Django LTI",
    "description": "",
    "id": "1"
  },
  "https://purl.imsglobal.org/spec/lti/claim/launch_presentation": {
    "locale": "fr",
    "document_target": "frame",
    "return_url": "http://localhost/mod/lti/return.php?course=2&launch_container=5&instanceid=1&sesskey=rAAVq7Hhe2"
  },
  "https://purl.imsglobal.org/spec/lti/claim/ext": {
    "lms": "moodle-2"
  },
  "https://purl.imsglobal.org/spec/lti/claim/tool_platform": {
    "product_family_code": "moodle",
    "version": "2025100603.11",
    "guid": "aa85caf65877b6e8f2e5cfd314c9805e",
    "name": "local",
    "description": "localhost"
  },
  "https://purl.imsglobal.org/spec/lti/claim/version": "1.3.0"
}

Ce token est anonyme il n’y a pas les informations de l’utilisateur. C’est l’administrateur du LMS qui décide d’envoyer ou pas les informations personnelles. Dans le cas ou il choisit de les envoyer, elles apparaîtront dans l’id token).

Exemple d’un token nominatif

{
  "nonce": "a5170c7866db4b699e82f8b30007bf43515ce0af302211f1b76d8cb87ec90090",
  "iat": 1775305937,
  "exp": 1775305997,
  "iss": "http://localhost",
  "aud": "Sfc6HFnwHAx4Tuv",
  "https://purl.imsglobal.org/spec/lti/claim/deployment_id": "1",
  "https://purl.imsglobal.org/spec/lti/claim/target_link_uri": "http://localhost:8000/lti/launch/",
  "sub": "2",
  "https://purl.imsglobal.org/spec/lti/claim/lis": {
    "person_sourcedid": "",
    "course_section_sourcedid": ""
  },
  "https://purl.imsglobal.org/spec/lti/claim/roles": [
    "http://purl.imsglobal.org/vocab/lis/v2/institution/person#Administrator",
    "http://purl.imsglobal.org/vocab/lis/v2/membership#Instructor",
    "http://purl.imsglobal.org/vocab/lis/v2/system/person#Administrator"
  ],
  "https://purl.imsglobal.org/spec/lti/claim/context": {
    "id": "2",
    "label": "pyLTI",
    "title": "PYTHON LTI",
    "type": [
      "CourseSection"
    ]
  },
  "https://purl.imsglobal.org/spec/lti/claim/message_type": "LtiResourceLinkRequest",
  "https://purl.imsglobal.org/spec/lti/claim/resource_link": {
    "title": "Hello Django LTI",
    "description": "",
    "id": "1"
  },
  "given_name": "Sébastien",
  "family_name": "Philippot",
  "name": "Sébastien Philippot",
  "https://purl.imsglobal.org/spec/lti/claim/ext": {
    "user_username": "admin",
    "lms": "moodle-2"
  },
  "email": "sebastien@philippot.co",
  "https://purl.imsglobal.org/spec/lti/claim/launch_presentation": {
    "locale": "fr",
    "document_target": "frame",
    "return_url": "http://localhost/mod/lti/return.php?course=2&launch_container=5&instanceid=1&sesskey=rAAVq7Hhe2"
  },
  "https://purl.imsglobal.org/spec/lti/claim/tool_platform": {
    "product_family_code": "moodle",
    "version": "2025100603.11",
    "guid": "aa85caf65877b6e8f2e5cfd314c9805e",
    "name": "local",
    "description": "localhost"
  },
  "https://purl.imsglobal.org/spec/lti/claim/version": "1.3.0"
}

La réponse à cette requête est le contenu souhaité(par exemple un QCM, un PDF, un serious Game etc..) vous trouverez plus d’informations ici

Manipuler les données LTI : les claims et les rôles

Toutes les données contextuelles sont présentes dans le l’id token sous forme de claims. Il en existe deux types :

C’est dans ce JWT que l’outil trouve tout ce dont il a besoin pour afficher la bonne ressource au bon utilisateur avec les bons droits.

Récupérer des informations sur l’utilisateur

Les informations sur l’utilisateur se trouvent à deux endroits dans le JWT : les claims OIDC standards et le claim LTI roles.

{
  "sub": "a6d5f3e1-4b2c-4d3e-8f1a-9b0c2d3e4f5a",
  "given_name": "Ada",
  "family_name": "Lovelace",
  "name": "Ada Lovelace",
  "email": "ada@localhost.fr",
  "https://purl.imsglobal.org/spec/lti/claim/roles": [
    "http://purl.imsglobal.org/vocab/lis/v2/membership#Learner"
  ]
}

sub est l’identifiant unique et stable de l’utilisateur au sein de cette plateforme (du LMS). C’est lui que l’outil peut persister en base de données. Il est garanti unique par plateforme.

name, email, given_name et family_name sont des claims OIDC optionnels. Leur présence dépend de la configuration du LMS et des droits accordés lors de la registration. Un LMS peut tout à fait ne pas les envoyer pour des raisons de confidentialité. ce qui permet d’être compatible RGPD et réponds à des besoins d’anonymisation.

Les rôles

Le claim roles est un tableau d’IRI qui définissent ce que l’utilisateur peut faire. LTI distingue trois niveaux de rôles :

Context roles : le rôle de l’utilisateur dans le cours.

IRIRôle
membership#LearnerApprenant
membership#InstructorEnseignant
membership#AdministratorAdministrateur

Institution roles — le rôle dans l’établissement :

IRIRôle
institution/person#StudentÉtudiant
institution/person#FacultyEnseignant-chercheur
institution/person#StaffPersonnel administratif

System roles — le rôle global sur la plateforme :

IRIRôle
system/person#AdministratorAdministrateur système
system/person#UserUtilisateur standard

Pour la liste complète des rôles, voir la vocabulaire officiel.

Récupérer des informations sur le cours

Les informations sur le contexte pédagogique sont portées par deux claims distincts qu’il est important de ne pas confondre.

{
  "https://purl.imsglobal.org/spec/lti/claim/context": {
    "id": "course-42",
    "label": "MATH101",
    "title": "Introduction aux mathématiques",
    "type": [
      "http://purl.imsglobal.org/vocab/lis/v2/course#CourseSection"
    ]
  },
  "https://purl.imsglobal.org/spec/lti/claim/resource_link": {
    "id": "200d101f-2c14-434a-a0f3-57c2a42369fd",
    "title": "Exercice chapitre 3",
    "description": "Exercices sur les suites numériques"
  }
}

Le claim context décrit le cours dans lequel se trouve l’activité. id est l’identifiant stable du cours côté LMS, label son code court (MATH101) et title son intitulé complet.

Le claim resource_link décrit l’activité précise sur laquelle l’apprenant a cliqué. id est l’identifiant unique de cette activité. Par exemple trois exercices différents chez Kahoot dans le même cours de mathématiques. Chacun aura son propre resource_link.id mais le même context.id.

Informations sur la plateforme

Le claim tool_platform expose des métadonnées sur le LMS qui a effectué le lancement. Il est optionnel mais utile quand l’outil doit adapter son comportement selon la plateforme.

{
  "https://purl.imsglobal.org/spec/lti/claim/tool_platform": {
    "guid": "aa85caf65877b6e8f2e5cfd314c9805e",
    "name": "local",
    "version": "2025100603.11",
    "product_family_code": "moodle"
  }
}

guid est l’identifiant unique de l’instance du LMS — deux établissements utilisant le même Moodle auront des guid différents. product_family_code permet de détecter le type de LMS (moodle, canvas, blackboard…) si l’outil a besoin de gérer des comportements spécifiques par plateforme.

Récupérer des informations sur le lancement

Le claim optionnel launch_presentation décrit comment la plateforme s’attend à afficher l’outil. C’est la plateforme qui dit à l’outil dans quel contexte il va s’afficher.

{
  "https://purl.imsglobal.org/spec/lti/claim/launch_presentation": {
    "document_target": "iframe",
    "width": 800,
    "height": 600,
    "locale": "fr-FR",
    "return_url": "https://moodle.monecole.fr/mod/lti/return.php?..."
  }
}

document_target indique dans quel type de fenêtre l’outil est affiché. Trois valeurs possibles : iframe (intégré dans la page du LMS), frame (dans un frame HTML) ou window (dans un nouvel onglet). C’est une information utile pour que l’outil adapte son interface — une interface dans une iframe n’a pas besoin d’un header de navigation complet.

width et height précisent les dimensions en pixels de l’espace alloué par le LMS. L’outil peut s’en servir pour adapter son rendu, même si en pratique le CSS responsive suffit souvent.

locale indique la langue de l’interface du LMS au format BCP47 — le même format que les Language Maps en xAPI. L’outil peut s’en servir pour afficher son interface dans la bonne langue sans avoir à demander à l’utilisateur.

return_url est l’URL vers laquelle l’outil peut rediriger l’utilisateur une fois l’activité terminée — typiquement pour le renvoyer vers le cours dans le LMS. La plateforme supporte quatre paramètres optionnels sur cette URL :

ParamètreUsage
lti_msgMessage de succès à afficher à l’utilisateur
lti_errormsgMessage d’erreur à afficher à l’utilisateur
lti_logMessage de succès à écrire dans les logs
lti_errorlogMessage d’erreur à écrire dans les logs

Par exemple, si l’outil veut indiquer que l’activité s’est bien terminée :

Récupérer des informations personnalisées

LTI permet à l’administrateur d’ajouter des paramètres personnalisés lors de la configuration de l’outil dans le LMS. Ces paramètres arrivent dans le JWT sous le claim custom :

{
  "https://purl.imsglobal.org/spec/lti/claim/custom": {
    "niveau": "terminale",
    "module": "algebre",
    "groupe": "TD-42"
  }
}

C’est utile quand l’outil a besoin d’informations métier spécifiques qui ne font pas partie de la spec LTI standard comme un identifiant interne, un niveau pédagogique, un groupe de travail. L’administrateur les renseigne dans la configuration de l’activité LTI côté LMS, et l’outil les retrouve dans ce claim à chaque lancement.

Les noms des clés custom sont toujours en minuscules et ne peuvent contenir que des lettres, chiffres et underscores. Une clé comme Mon Paramètre sera automatiquement convertie en mon_paramtre.

La gestion des cookies et LTI

Le lancement d’une activité LTI necessite plusieurs requêtes avec des paramètres à retenir tels que le nonce ou state. Ces paramètres sont générés par l’outil à l’étape 2 du flux de lancement et doivent être vérifiés à l’étape 4. Pour cela, l’outil doit pouvoir stocker ces paramètres entre les différentes requêtes. La solution la plus simple est d’utiliser des cookies de session. Cependant, cela peut poser des problèmes de compatibilité avec certains navigateurs( Safari, Chrome) qui bloquent les cookies tiers (third-party cookies) par défaut pour des raisons de confidentialité. Les cookies posés par un domaine différent de celui affiché dans la barre d’adresse sont bloqués. L’outil ne peut donc pas stocker son state dans un cookie.

Les solutions

Il existe trois approches, de la plus simple à la plus robuste :

1. SameSite=None; Secure — la solution rapide

Configurer les cookies de l’outil avec les attributs SameSite=None et Secure les rend explicitement autorisés en contexte cross-site. C’est la première solution documentée par 1EdTech.

Set-Cookie: state=abc123; SameSite=None; Secure

C’est simple mais ça a des limites. En effet, l’attribut Secure impose le HTTPS obligatoire, et certains navigateurs plus anciens ne reconnaissent pas SameSite=None et rejettent le cookie au lieu de l’ignorer.

2. Ouvrir dans une nouvelle fenêtre

Hors iframe, le domaine de l’outil devient le domaine principal et ses cookies sont autorisés sans restriction. C’est la solution de repli recommandée par 1EdTech pour les outils qui ne peuvent pas se mettre à jour rapidement. Elle dégrade l’expérience utilisateur mais reste fonctionnelle.

3. lti_storage_target et postMessage — la solution robuste

1EdTech a publié une extension de la spec qui permet à l’outil de stocker state et nonce dans le frame parent (le LMS) via des messages JavaScript postMessage, sans utiliser de cookies du tout. C’est la solution recommandée pour rester dans l’iframe de manière fiable sur tous les navigateurs modernes. Pour plus de détails, consultez la documentation de 1EdTech ici.

La plupart des bibliothèques LTI (PyLTI1p3Next, ltijs…) gèrent ces trois cas via une option enable_check_cookies() — elles testent d’abord si les cookies sont disponibles et basculent automatiquement sur postMessage si ce n’est pas le cas.

Conclusion

LTI est un standard permettant l’intégration d’outils externes dans les environnements d’apprentissage. Il offre une approche sécurisée et flexible pour le partage de données entre les systèmes. Plus besoin de package comme le propose Scorm, il n’y a que de la configuration à faire. Ce standard est flexible notamment avec la subsitution de variables et permet donc de s’adapter au contexte métier.

Ce que LTI accomplit, c’est la séparation nette des responsabilités. Le LMS reste maître de l’identité et du parcours. L’outil reste maître de son contenu et de son expérience. SCORM avait tenté de résoudre ce problème différemment, en demandant à l’outil de livrer son contenu packagé, donc de s’effacer (le contenu est importé dans le LMS). Avec LTI l’outil reste vivant, connecté, évolutif.

1EdTech fait d’LTI son socle, il se complète avec Caliper, Qti, Cartridge etc… C’est un standard fondamental dans l’écosystème 1Edtech mais aussi dans l’Edtech en général. De nombreux LMS sont compatible avec LTI.

Pour une organisation souhaitant proposer du contenu à des centres de formation, des universités ou des écoles LTI reste un très bon choix.

N’hésitez pas a lire les articles suivants de cette série qui traiteront de l’envoie des notes directement dans le LMS, de la possibilités de pouvoir choisir du contenu proposé par l’outil bref il reste encore de nombreuses fonctionnalités importantes à découvrir dans LTI AGS

Référence

La spécification complète est disponible sur imsglobal.org.

Partager