NexTool Solutions

La migration de GLPI 10 vers GLPI 11 échoue presque jamais sur la commande de mise à jour de la base - elle échoue sur ce qui vient avant et après. Ce guide consolide le plan que nous appliquons en maintenance des environnements clients : là où les choses cassent vraiment, comment blinder chaque étape et comment revenir en arrière si quelque chose tourne mal.

Avant tout : pourquoi la migration exige une méthode

Migrer de la 10 à la 11 modifie le schéma de base de données de façon irréversible et remplace toute la couche de présentation (désormais sur Symfony et Twig). Ce n'est pas un « on remplace les fichiers et on démarre ». Les deux facteurs qui causent le plus d'indisponibilité non planifiée sont les plugins incompatibles laissés actifs pendant la mise à jour et la version de PHP du serveur. Traitez la migration comme un petit projet, avec une fenêtre et un plan de retour arrière, pas comme un correctif à chaud. Prévoyez aussi d'avertir les utilisateurs que l'interface de la 11 est différente de celle de la 10 - une bonne part des tickets post-migration, ce sont des personnes perdues dans la nouvelle mise en page, pas de vrais bugs.

Checklist de pré-migration

• Sauvegarde complète de la base (mysqldump) et des répertoires de configuration et de données.
• Être sur la dernière mineure de GLPI 10 (10.0.x la plus récente) avant de passer à la 11.
• PHP 8.1+ installé et actif dans la bonne version de CLI et de FPM.
• Un inventaire des plugins avec le statut de compatibilité de chacun sous GLPI 11.
• Un environnement de recette avec une copie réelle de la base pour répéter la migration.

Plugins : ce qui change dans GLPI 11

1. Sauvegarde complète (et testée)

Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde, c'est un espoir. Générez-la et validez au moins la taille du fichier :

# Base de données
mysqldump -u root -p --single-transaction glpi > /backup/glpi_pre_migration.sql

# Fichiers (configuration, données et plugins)
tar -czf /backup/glpi_files_pre_migration.tar.gz /var/www/glpi /etc/glpi /var/lib/glpi

2. Désactiver les plugins incompatibles

Dans GLPI 10, allez dans Configuration > Plugins et désactivez tous ceux sans version pour la 11. Supprimez les répertoires des incompatibles. Cette étape n'est pas optionnelle : c'est la cause n°1 d'échec à la commande de mise à jour.

3. Mettre à jour les fichiers de GLPI

cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.0/glpi-11.0.0.tgz
tar -xzf glpi-11.0.0.tgz

# Remplacer les fichiers en préservant configuration, données et plugins
rsync -av --delete /tmp/glpi/ /var/www/glpi/ --exclude plugins/ --exclude marketplace/
chown -R www-data:www-data /var/www/glpi

Téléchargez toujours la dernière version stable de la ligne 11.x, pas forcément la 11.0.0.

4. Lancer la migration de la base

php /var/www/glpi/bin/console db:update --no-interaction

Cette commande applique toutes les migrations de schéma. Suivez toute la sortie - toute erreur doit être résolue avant de continuer, jamais ignorée.

5. Vider le cache et les sessions

php /var/www/glpi/bin/console cache:clear
rm -rf /var/lib/glpi/_sessions/*

6. Vérification post-migration

• La connexion fonctionne et la version sous Configuration > Général affiche 11.x.
• Tickets, actifs et utilisateurs sont présents avec les totaux attendus.
• L'ouverture d'un nouveau ticket fonctionne de bout en bout.
• Journaux sans erreurs récurrentes après quelques minutes d'usage.
• Réactivez et mettez à jour les plugins compatibles un par un, en testant entre chaque.

Ce que nous avons appris en maintenance

En pratique, la migration échoue rarement sur db:update lui-même. Elle échoue ensuite : un plugin incompatible resté actif qui fait tomber l'interface avec une erreur 500, le PHP de FPM pointant vers une version que GLPI 11 n'accepte pas (alors que le CLI est déjà en 8.1), ou le client qui a sauté une mineure de la 10 et arrive à la commande de mise à jour avec un schéma qui ne colle pas. C'est pourquoi notre plan met d'abord à jour vers la dernière 10.0.x, valide, puis seulement passe à la 11 - en réactivant les plugins un par un, jamais tous d'un coup, car lorsque quelque chose casse il faut savoir exactement quel plugin en est responsable.

Le piège le plus courant

L'erreur classique est de croire que les formulaires de FormCreator migrent seuls vers les formulaires natifs de GLPI 11. Ils ne migrent pas : le plugin disparaît, mais les formulaires qu'il créait doivent être recréés manuellement dans le nouveau cœur. Inventoriez les formulaires FormCreator avant de retirer le plugin, sinon vous découvrirez la perte en production, avec un utilisateur se plaignant que le formulaire a disparu. La deuxième erreur la plus fréquente est de lancer db:update avec un plugin incompatible encore actif : le console tente de charger le plugin, tombe sur une API qui n'existe plus et s'interrompt au milieu de la migration.

Retour arrière : quand ça tourne mal

Comme le changement de schéma est irréversible, le retour arrière n'est pas un « annuler » - c'est restaurer l'état précédent. C'est pourquoi la sauvegarde testée de l'étape 1 est non négociable :

# Restaurer les fichiers
tar -xzf /backup/glpi_files_pre_migration.tar.gz -C /

# Restaurer la base
mysql -u root -p glpi < /backup/glpi_pre_migration.sql

Répéter cette restauration en recette avant la vraie fenêtre, c'est ce qui sépare une frayeur d'un incident.

Prochaine étape

Après la migration, explorez les formulaires natifs et les autres nouveautés de GLPI 11, puis réintroduisez les plugins essentiels. Pour étendre le cœur sans accumuler des plugins qui cassent à la prochaine majeure, NexTool regroupe des dizaines de modules dans un seul plugin, avec des versions pour 10 et 11. Besoin d'aide pour la migration ? Contactez l'équipe.

Révisé par l'équipe NexTool Solutions.