Migration d’une API Lumen vers Laravel pour une plateforme e-learning

L’application concernée était une plateforme e-learning interne déjà utilisée dans un contexte professionnel. Elle permettait à des utilisateurs connectés d’accéder à des contenus de formation et de suivre des parcours existants.

Le chantier visait la couche backend, construite avec Lumen, afin de la reprendre sur une base Laravel 12 plus maintenable.

Dans une plateforme e-learning interne, une migration backend peut toucher l’accès aux ressources, les droits utilisateurs, les états d’avancement ou les messages d’erreur affichés par l’interface.

L’enjeu était donc de comprendre les usages avant de remplacer le socle technique. Cette étape permettait de distinguer ce qui pouvait être modernisé de ce qui devait rester stable pour les utilisateurs.

Ce que cela implique dans une migration

Le travail part des usages existants. Avant de remplacer le socle technique, il faut identifier les écrans concernés, les réponses attendues, les cas d’accès refusé, les états de progression et les points dépendants de LDAP.

Cette lecture fonctionnelle évite de traiter la migration comme un simple changement de framework.

Le backend exposait des endpoints pour se connecter, charger les contenus, afficher les états utiles et réagir aux erreurs. Les routes, paramètres, formats de réponse, codes d’erreur et comportements liés à l’authentification ont servi de points de référence pendant la migration.

Ce cadrage limite les écarts invisibles au moment du développement, mais visibles pour les utilisateurs : un champ renommé, une erreur retournée autrement ou un statut HTTP différent peut suffire à perturber un parcours.

Pourquoi ce point est sensible

La migration a été menée comme une reprise fonctionnelle autant que comme une réécriture technique. Le nouveau code devait être plus maintenable, tout en respectant ce que les écrans existants attendaient déjà.

Lumen avait été utilisé comme socle historique de l’API. En 2025, le choix a été de migrer vers Laravel 12, version alors récente du framework, afin de revenir vers un écosystème plus complet pour la maintenance applicative.

La migration a demandé de reprendre l’organisation du projet : les adresses appelées, la logique de traitement, les contrôles appliqués aux requêtes, la configuration et les dépendances.

Une migration n’est pas une copie de fichiers

Lumen et Laravel partagent une histoire technique, mais une migration propre demande de relire les responsabilités. Certains éléments sont déplacés, d’autres réécrits, d’autres simplement conservés avec une adaptation minimale.

L’objectif n’était pas d’ajouter des fonctionnalités visibles. Il était de rendre l’API plus maintenable sans modifier l’usage de la plateforme e-learning.

L’application s’appuyait sur une authentification LDAP. Ce point est central dans une plateforme e-learning interne : les utilisateurs se connectent avec les accès prévus par l’organisation, et les échecs restent compréhensibles.

La reprise de LDAP a donc été traitée comme une partie critique de la migration API, pas comme un simple branchement technique.

Les cas limites comptent

Une authentification interne gère les cas normaux, mais aussi les refus, comptes absents, erreurs d’annuaire, configurations d’environnement et différences entre recette et production.

Ces détails sont rarement visibles dans une capture d’écran. Ils déterminent pourtant la qualité d’usage le jour de la mise en production.

Les contrôles ont porté sur les parcours les plus sensibles : connexion, accès aux contenus, navigation, droits utilisateurs, appels API et comportements en cas d’erreur.

L’objectif n’était pas de constater que l’interface avait changé, mais au contraire de vérifier que les usages connus restaient cohérents avec le nouveau backend Laravel.

Tester ce qui existe déjà

Ces vérifications ont aidé à repérer les écarts entre l’ancien backend et le nouveau socle Laravel avant la mise en production.

Nous avons aussi pris en charge le déploiement sur les serveurs du client. Cette partie impose de composer avec un environnement existant : version de PHP, extensions disponibles, chemins, droits fichiers, variables d’environnement, configuration web et caches applicatifs.

Le déploiement a donc été préparé comme une phase du projet, avec les vérifications nécessaires avant et après mise en ligne.

Les contraintes serveur orientent les choix techniques

Une application peut fonctionner en environnement de développement et échouer sur un serveur si les contraintes d’hébergement n’ont pas été prises en compte. Dans une migration, ce risque augmente, car l’application change de socle tout en restant liée à une infrastructure existante.

La préparation du déploiement a servi à identifier ces points avant la mise en production.

Cette migration rappelle qu’un chantier backend peut avoir un impact produit important, même lorsque l’interface ne change pas.

Dans ce contexte, la valeur du projet tenait autant à la modernisation Laravel qu’à la continuité des accès, des parcours et du déploiement client.