Migrer de LTI 1.1 à LTI 1.3 : guide pratique pour les équipes outil

Si vous avez construit un outil e-learning qui s’intègre à un LMS, une échéance se rapproche discrètement. LTI 1.1, ainsi que 1.0 et 1.2, ont été officiellement abandonnés par 1EdTech, l’organisme qui maintient le standard. Les grandes plateformes ont clarifié leur position : LTI 1.3 devient le minimum pour tout outil qui échange des données personnelles ou sensibles d’étudiants. Si votre intégration fonctionne encore en 1.1, c’est désormais une migration avec une horloge, pas un sujet hypothétique pour plus tard.

La bonne nouvelle est que le chemin est connu et documenté. La mauvaise est que 1.3 n’est pas une simple montée de version. C’est un autre modèle de sécurité. Le traiter comme une petite mise à jour mène aux lancements cassés et aux notes manquantes en production. Voici les changements réels, les étapes dans l’ordre et les pièges concrets.

Ce qui a réellement changé entre 1.1 et 1.3

Pendant longtemps, les nouvelles versions de LTI ajoutaient seulement des fonctions. La version 1.3 rompt ce modèle : le format du message et tout le modèle de sécurité changent, d’où la nécessité d’une vraie migration.

LTI 1.1 authentifiait les messages avec une signature de style OAuth 1.0a : un consumer key et un secret partagés, connus des deux côtés, signaient les requêtes en HMAC-SHA1. Cela fonctionnait, mais un secret partagé crée de vrais risques de rejeu et de substitution lorsqu’il fuit.

LTI 1.3 remplace cela par une pile moderne : OpenID Connect pour la négociation de connexion, JSON Web Tokens (JWT) signés par clés asymétriques pour l’intégrité des messages, et jetons porteurs OAuth 2.0 pour les appels de services. Au lieu de partager un secret, la plateforme signe avec une clé privée et publie la clé publique correspondante à une URL. Votre outil la récupère et vérifie qu’un lancement vient bien de la plateforme.

Cela se propage partout. En 1.1, un lancement est un ensemble plat de paramètres POST et une signature. En 1.3, c’est un JWT signé dont les données sont organisées en claims. La configuration ne se limite plus à une URL, une clé et un secret : vous échangez URLs et identifiants à l’enregistrement, et la plateforme attribue client_id et deployment_id. La remise de notes, les listes de cours et le deep linking deviennent des services LTI Advantage disponibles seulement en 1.3. Avant chaque appel, votre outil obtient un jeton OAuth 2.0 avec une assertion JWT signée. Vous n’éditez donc pas un fichier de configuration : vous implémentez OIDC, validation JWT, gestion des clés et OAuth 2.0.

La migration, étape par étape

L’ordre compte. Chaque étape suppose que la précédente est terminée et vérifiée.

Étape 1 : confirmer la prise en charge de 1.3 et choisir l’hébergement

Vérifiez que les LMS utilisés par vos clients prennent en charge LTI 1.3 : Canvas, Moodle, Brightspace et Blackboard le font désormais. Décidez ensuite si votre outil 1.3 vit sur le même domaine que la version 1.1 ou sur un autre. Certaines plateformes mettent automatiquement à jour les liens de cours existants si la version 1.3 utilise le même nom de domaine pleinement qualifié. Avec un nouveau domaine, il faudra peut-être migrer les liens afin de conserver les colonnes de notes. Décidez tôt : changer ensuite impose de refaire la configuration.

Étape 2 : implémenter l’initialisation de connexion OIDC

Un lancement LTI 1.3 commence par une connexion OpenID Connect initiée par un tiers, pour protéger contre les requêtes intersites forgées. La plateforme appelle d’abord l’endpoint de connexion OIDC de votre outil. Votre outil redirige vers l’endpoint d’autorisation de la plateforme avec une valeur state, généralement stockée dans un cookie, et un nonce.

Exposez cet endpoint. Le state créé ici sera vérifié à l’étape suivante pour confirmer que le lancement de retour est bien celui que vous avez initié.

Étape 3 : recevoir le lancement et valider le JWT

La plateforme crée l’id_token, le JWT contenant les données de lancement, puis envoie un formulaire POST à votre URI de redirection. À son arrivée, votre outil fait trois choses dans cet ordre.

D’abord, vérifiez que le state retourné correspond à celui stocké ; sinon rejetez le lancement. Ensuite, décodez et validez la signature JWT. Un JWT a trois parties Base64 séparées par des points : un en-tête avec l’identifiant de clé et l’algorithme, une charge utile avec les claims, et une signature. Récupérez la clé publique de la plateforme depuis son URL de jeu de clés grâce à l’identifiant de l’en-tête, puis vérifiez la signature. Enfin, validez l’émetteur, l’audience (client_id), le nonce et l’expiration. Ce n’est qu’après cela que vous faites confiance au lancement et lisez l’utilisateur, le cours et la ressource.

Étape 4 : réimplémenter les services avec LTI Advantage

Si votre outil renvoie des notes, lit la liste du cours ou permet de choisir du contenu, ces fonctions deviennent des services LTI Advantage. Avant chaque appel, votre outil demande un jeton d’accès OAuth 2.0 à l’endpoint de jetons en envoyant une assertion client JWT signée. Il reçoit un jeton porteur qui sert à appeler le service.

Les trois services courants sont Assignment and Grade Services (AGS) pour les notes, Names and Role Provisioning Services (NRPS) pour la liste du cours, et Deep Linking pour qu’un enseignant choisisse du contenu de votre outil. Chacun exige l’étape de jeton en amont. C’est souvent là que se trouve le plus gros du nouveau code.

Étape 5 : enregistrer votre outil auprès de la plateforme

L’enregistrement remplace l’ancien échange clé-secret. Vous fournissez le domaine, l’URI de connexion OIDC, les URI de redirection et l’URL de jeu de clés publiques de votre outil. La plateforme renvoie client_id, deployment_id, ses endpoints d’authentification et de jetons, ainsi que son URL de jeu de clés.

Conservez toutes ces valeurs. Un lancement 1.3 est identifié de façon unique par l’émetteur, le client_id et le deployment_id. Les trois sont nécessaires pour associer un lancement entrant à la bonne configuration, surtout si un outil sert plusieurs plateformes ou déploiements.

Étape 6 : tester d’abord en préproduction

Ne faites jamais cela d’abord en production. Installez l’intégration 1.3 dans l’environnement de test ou bêta, réalisez de vrais lancements, envoyez de vraies notes et vérifiez leur arrivée. Les recommandations de toutes les plateformes insistent : validez entièrement 1.3 en préproduction avant de toucher à la production.

Étape 7 : basculer, puis désactiver 1.1

Une fois la préproduction validée, déployez en production. Selon le choix d’hébergement de l’étape 1, les liens existants se mettront à jour automatiquement ou demanderont une migration. Après confirmation que 1.3 fonctionne, retirez la configuration 1.1. Faire tourner les deux versions du même outil en parallèle est déconseillé et parfois interdit sur un même domaine.

Les points de vigilance qui causent vraiment des incidents

Les notes peuvent disparaître temporairement du carnet. C’est très inquiétant pour les enseignants, mais souvent attendu plutôt qu’un bug. Après migration, certaines intégrations exigent qu’un étudiant ou un enseignant relance l’outil pour réassocier les comptes avant que les notes existantes réapparaissent. Elles ne sont pas perdues, mais sans avertissement vous recevrez des tickets paniqués. Communiquez-le avant.

Liens de devoirs dupliqués ou cassés. La migration laisse souvent les liens 1.1 qui ne pointent plus nulle part. Vous pouvez voir deux devoirs : la version 1.3 fonctionnelle et la version 1.1 morte. Prévoyez l’identification et le nettoyage des anciens liens et indiquez aux enseignants lesquels garder.

Les identifiants utilisateur peuvent changer. Malgré l’objectif de compatibilité du contenu, certains identifiants évoluent. L’ID reçu en 1.3 peut différer de celui stocké en 1.1. Si votre outil indexe les dossiers utilisateurs sur l’ID LTI, prévoyez une réassociation de l’ancienne et de la nouvelle identité au premier lancement 1.3, sinon l’historique sera orphelin.

Des écarts dans l’affichage des notes et retours. Certaines intégrations 1.3 ne se présentent pas comme leur équivalent 1.1 dans le LMS : des remises peuvent ne plus apparaître dans l’interface native ou des icônes de notes disparaître alors que les données sont correctes. Testez tout le parcours de correction de l’enseignant, pas seulement le lancement.

La gestion des clés devient une responsabilité continue. En 1.1, vous stockiez un secret. En 1.3, vous possédez une paire de clés, publiez un jeu de clés et devez faire tourner les clés tout en gardant l’endpoint disponible. Si l’URL du jeu de clés tombe, chaque lancement échoue à la validation de signature. Cette nouvelle surface d’exploitation doit être surveillée.

La revue de sécurité peut être la partie la plus lente. Beaucoup d’établissements envoient une nouvelle intégration 1.3 à leur équipe IT ou cybersécurité, qui peut devoir autoriser vos URLs. L’évaluation est souvent la partie la plus longue et elle échappe à votre contrôle. Commencez tôt avec les clients institutionnels afin qu’elle ne bloque pas le lancement.

Conclusion

LTI 1.3 demande davantage de travail que toute mise à niveau précédente parce qu’il remplace le socle de sécurité au lieu de l’étendre. Connexion OIDC, validation JWT, jetons OAuth 2.0 et gestion des clés sont du vrai travail d’implémentation, pas de la configuration. Mais l’abandon est réel et les plateformes l’appliquent : la question est quand, pas si.

Suivez le bon ordre, testez le flux complet en préproduction et surcommuniquez les changements de carnet et de liens aux enseignants concernés. Les équipes qui se brûlent traitent 1.3 comme une hausse de version et découvrent en production que le modèle de sécurité a changé sous leurs pieds.

Je construis et maintiens des plateformes e-learning et des intégrations LMS sur mesure pour les équipes edtech et L&D, y compris des implémentations LTI 1.3 et LTI Advantage. Si vous préparez une migration ou construisez une intégration, c’est exactement le type de travail que j’aide à mener.