GLPI 10 arrive en fin de vie : migrer vers GLPI 11 maintenant ou attendre GLPI 12 ?

En bref

• GLPI 10 ne sera plus maintenu après la sortie de GLPI 12.0.0 : la 10.0.28, publiée le 30 septembre 2026, est la dernière version de la branche.
• GLPI 11 est la cible la plus sûre à court terme : version stable depuis septembre 2025, procédure de migration documentée, outils de conversion des plugins Formcreator et Generic Objects.
• GLPI 12 est encore en release candidate, avec une sortie stable annoncée pour octobre 2026. Attendre n'a de sens que pour une instance interne, peu personnalisée, avec une migration planifiée à court terme.
• Le chantier principal est souvent ailleurs que dans la base de données : prérequis (PHP 8.2, MySQL 8.0 ou MariaDB 10.6, dossier public) et plugins.
• Viser la dernière version corrective (11.0.10 à la date de publication) : les versions 11.0.x récentes ont corrigé plusieurs failles critiques.

Ce qui a changé le 30 septembre 2026

Le projet GLPI a publié simultanément les versions 11.0.10 et 10.0.28, qui corrigent plusieurs failles de sécurité, dont un contournement d'autorisation dans les actions massives et une élévation de privilèges par clonage d'utilisateur qui touchent les deux branches. L'annonce précise que la 10.0.28 sera la dernière version de la branche 10.0.

En parallèle, GLPI 12 a atteint le stade de release candidate le 7 septembre 2026 : plus de nouvelles fonctionnalités, uniquement des corrections et des traductions, avec une version stable annoncée pour octobre. Parmi les nouveautés mises en avant : refonte de la base de connaissances, gestionnaire de sessions, mode « sudo », refonte des OLA, renforcement de la sécurité et de l'accessibilité.

Conséquence : une instance GLPI 10 qui reste en production après la sortie de GLPI 12 ne recevra plus aucun correctif, y compris de sécurité. Pour un outil qui centralise les tickets, l'inventaire du parc et souvent des comptes à privilèges, ce n'est pas un risque acceptable.

Ce que GLPI 11 apporte

GLPI 11 est sorti en version stable le 30 septembre 2025. Les principales nouveautés annoncées par le projet :

• Actifs personnalisés : création de types d'actifs sur mesure, avec leurs propres champs et comportements, qui remplacent le plugin Generic Objects.
• Formulaires natifs : un nouvel éditeur de formulaires pour les techniciens et les utilisateurs, qui reprend le rôle du plugin Formcreator.
• Portail libre-service repensé, pour que les utilisateurs trouvent plus facilement les services disponibles.
• Authentification à deux facteurs.
• Webhooks, pour déclencher des appels HTTP vers d'autres applications.

Ces évolutions changent la nature du projet : il ne s'agit pas d'une simple mise à jour de version, mais de la reprise de deux plugins très répandus par le cœur de l'application.

GLPI 11 maintenant ou GLPI 12 ensuite : la grille de décision

Situation	Recommandation
Instance exposée sur Internet ou portail ouvert à de nombreux utilisateurs	Migrer vers GLPI 11 sans attendre
Usage important de Formcreator ou de Generic Objects	Migrer vers GLPI 11 : les commandes de conversion sont documentées pour le passage de 10 à 11
Serveur déjà en PHP 8.2+ et MySQL 8.0+ / MariaDB 10.6+	Migrer vers GLPI 11 : l'effort d'infrastructure est déjà fait
Instance interne, peu de plugins, migration planifiable dans le trimestre	Possible d'attendre GLPI 12, puis de cibler une version corrective 12.0.x plutôt que la 12.0.0
Projet de refonte de la base de connaissances ou des OLA déjà prévu	Migrer vers GLPI 11 d'abord, puis évaluer GLPI 12 sur ces modules une fois stabilisé
Aucune capacité à mener un projet avant plusieurs mois	Appliquer au minimum la 10.0.28 et lancer la préparation de l'infrastructure dès maintenant

À la date de publication, la documentation officielle ne précise pas si une mise à jour directe de GLPI 10 vers GLPI 12 sera prise en charge, ni si les commandes de conversion de Formcreator et Generic Objects y seront conservées. Tant que ce point n'est pas documenté, passer par GLPI 11 reste le chemin le moins risqué pour les instances qui utilisent ces plugins.

Les prérequis à vérifier avant tout

Élément	GLPI 10.0	GLPI 11.0
PHP	7.4 minimum	8.2 minimum
MySQL	5.7 minimum	8.0 minimum
MariaDB	10.2 minimum	10.6 minimum
Extensions PHP supplémentaires	—	bcmath, mbstring, openssl
Serveur web	racine sur le dossier public à partir de la 10.0.7	racine du site (DocumentRoot) sur le dossier public, avec réécriture d'URL vers index.php

Source : documentation d'installation officielle de GLPI.

Dans la pratique, ce tableau est souvent le vrai chantier : une montée de PHP ou de MySQL touche le système d'exploitation, parfois d'autres applications hébergées sur le même serveur, et doit être validée par les équipes infrastructure et sécurité. C'est aussi le bon moment pour revoir l'hébergement, les sauvegardes et l'exposition du serveur, avec notre offre cloud et infrastructures.

Une méthode en cinq phases

1. Inventorier l'existant

Avant d'écrire la moindre commande, il faut savoir ce que l'on migre :

• version exacte de GLPI, de PHP et du serveur de base de données ;
• liste des plugins actifs, avec leur version et leur compatibilité annoncée avec GLPI 11 ;
• nombre de formulaires Formcreator, de types Generic Objects et de champs Fields en production ;
• règles métier, notifications, niveaux de service (SLA), intégrations par API, connecteurs d'inventaire (agents GLPI) ;
• personnalisations du code, qui sont les premières à casser lors d'une montée de version majeure.

Lancer php bin/console db:check dès cette phase permet de détecter les incohérences de schéma qui bloqueraient la migration.

2. Préparer l'infrastructure cible

Mettre en place PHP 8.2 ou plus, MySQL 8.0 ou MariaDB 10.6 au minimum, les extensions requises, et configurer le serveur web pour que la racine du site pointe sur le dossier public. Idéalement sur un nouveau serveur, ce qui garde l'ancien intact comme solution de repli.

3. Répéter la migration sur une copie

La migration se répète au moins une fois sur une copie de la base de production :

1. Sauvegarder la base, le dossier d'installation, le dossier config (qui contient les clés de chiffrement), le dossier files et les plugins.
2. Mettre à jour les plugins concernés vers les versions minimales exigées : Generic Objects 2.14.14 et Formcreator 2.13.10.
3. Déployer GLPI 11, restaurer config, files et les plugins, puis lancer php bin/console db:update.
4. Exécuter les conversions dans l'ordre documenté, en tant qu'utilisateur du serveur web.
5. Réactiver les plugins : lors d'une mise à jour majeure, leur exécution est suspendue et doit être relancée avec php bin/console plugin:resume_execution.

Plugin GLPI 10	Devenir dans GLPI 11	Action
Generic Objects	Intégré au cœur (actifs personnalisés)	php bin/console migration:genericobject_plugin_to_core, puis suppression du plugin
Fields	Reste un plugin	Le garder installé et activé, notamment s'il est utilisé avec Formcreator
Formcreator	Intégré au cœur (formulaires natifs)	php bin/console migration:formcreator_plugin_to_core, puis suppression du plugin

Source : procédure officielle « Migration spécifique des plugins de GLPI 10 vers GLPI 11 ». Lors d'une migration vers une nouvelle instance, les fichiers de files/_plugins/[nom du plugin] doivent aussi être copiés.

4. Recetter avec les métiers

La répétition ne vaut que si quelqu'un vérifie le résultat. Une recette utile couvre au minimum :

• chaque formulaire converti, soumis de bout en bout par un utilisateur réel ;
• les notifications et les règles d'affectation des tickets ;
• les calculs de SLA sur des tickets en cours ;
• les actifs personnalisés issus de Generic Objects et leurs champs ;
• la remontée d'inventaire par les agents et les intégrations par API ;
• les droits des profils, en particulier après l'activation de l'authentification à deux facteurs.

5. Basculer, avec un plan de retour arrière

La bascule se fait sur une fenêtre annoncée aux utilisateurs, application en maintenance, avec une sauvegarde fraîche juste avant. Le plan de retour arrière doit être écrit à l'avance : restauration de la base et des fichiers sur l'ancienne version. La documentation officielle rappelle qu'une sauvegarde ne doit jamais être importée dans une version différente de GLPI sans passer par les scripts de migration.

Exemple de calendrier (fictif)

Exemple fictif, à visée illustrative. Une DSI de 1 500 utilisateurs, GLPI 10 sur un serveur en PHP 7.4, une quarantaine de formulaires Formcreator et deux types Generic Objects.

Semaine	Activité
1	Inventaire, db:check, liste des plugins et de leur compatibilité
2 à 3	Nouveau serveur en PHP 8.2 et MariaDB 10.6, configuration du dossier public
4	Première répétition sur copie, conversions Generic Objects et Formcreator
5 à 6	Recette avec le service desk et deux services métiers, corrections
7	Seconde répétition, mesure de la durée réelle de la migration
8	Bascule un soir de faible activité, support renforcé le lendemain

Les erreurs les plus fréquentes

• Mettre à jour GLPI avant les plugins : les conversions exigent des versions minimales de Generic Objects et de Formcreator.
• Oublier le dossier config : il contient les clés de chiffrement ; sans lui, certaines données chiffrées deviennent illisibles.
• Laisser la racine du site sur le dossier d'installation au lieu du dossier public.
• Ne pas relancer les plugins après la mise à jour majeure, puis conclure à tort qu'ils sont incompatibles.
• Recetter uniquement côté technicien : les formulaires convertis doivent être testés par les utilisateurs qui les remplissent.
• S'arrêter à la 11.0.0 : les versions correctives suivantes ont corrigé des failles critiques, dont une exécution de code à distance via l'import de formulaires et un contournement de l'authentification multifacteur (corrigés en 11.0.8).

Après la migration : en profiter pour progresser

Une migration réussie remet l'outil à niveau ; elle peut aussi remettre le service à niveau. C'est le bon moment pour simplifier un catalogue de services devenu touffu, revoir les formulaires avec le nouvel éditeur, ou connecter la base de connaissances à un assistant conversationnel comme NovAssist, qui s'appuie sur vos bases documentaires et sur GLPI.

Questions fréquentes

Peut-on rester sur GLPI 10 après la sortie de GLPI 12 ?
Techniquement oui, mais la 10.0.28 est annoncée comme la dernière version de la branche : aucune faille découverte ensuite ne sera corrigée.

La migration de GLPI 10 vers GLPI 11 est-elle réversible ?
Oui, à condition d'avoir sauvegardé la base et tous les dossiers avant l'opération, et de restaurer l'ensemble sur l'ancienne version. Une restauration partielle ou dans une autre version n'est pas supportée.

Les formulaires Formcreator sont-ils conservés ?
Ils sont convertis en formulaires natifs par la commande de migration dédiée. Chaque formulaire doit néanmoins être recetté, car les comportements avancés peuvent différer.

Combien de temps dure une migration ?
La mise à jour de la base elle-même dépend du volume et se mesure lors de la répétition. L'essentiel du temps d'un projet va à la préparation de l'infrastructure et à la recette.

Par où commencer

Trois questions suffisent pour cadrer le projet : votre serveur respecte-t-il déjà les prérequis de GLPI 11, combien de formulaires et d'actifs dépendent de plugins, et qui recettera côté métiers. Les équipes Novagios accompagnent ces projets du diagnostic à la bascule : IT Service Management, intégration et automatisation des outils connectés à GLPI, et services managés pour l'exploitation après migration.

---

Sources

• GLPI Project, « Two new GLPI versions are available » (30 septembre 2026) — 11.0.10, 10.0.28 et fin de la branche 10.0.
• GLPI Project, « GLPI 12 Release Candidate is Here » (7 septembre 2026).
• GLPI Project, « GLPI 11 is out! » (30 septembre 2025).
• GLPI Project, « GLPI 11.0.8 & 10.0.26 — Security releases now available » (24 juin 2026).
• Documentation d'installation GLPI, pages « Prerequisites » et « Update » (glpi-install.readthedocs.io).
• Documentation GLPI, « Migration spécifique des plugins de GLPI 10 vers GLPI 11 » et « Comment mettre à jour GLPI » (help.glpi-project.org).