Le GLPI 12 est encore en développement, mais il est déjà possible de suivre certains des changements en cours de travail dans le dépôt officiel.
Il ne s'agit pas seulement d'une nouvelle interface ou de changements visuels. Le projet traverse une modernisation importante de sa structure, notamment au niveau du frontend, de l'organisation des composants et de la réduction des dépendances anciennes.
Comme il n'existe pas encore de version stable, tout ce que nous présentons dans ce contenu doit être considéré comme une analyse de l'état actuel du développement. Les fonctionnalités, les prérequis et même les décisions techniques peuvent encore changer.
Modernisation de l'interface
L'un des principaux changements en cours concerne le frontend du GLPI.
Aujourd'hui, le système possède encore des composants construits à différents moments du projet. Certaines zones utilisent des pages PHP traditionnelles, d'autres utilisent déjà Twig, du JavaScript moderne et Vue.js.
Dans le GLPI 12, la tendance est d'élargir cette modernisation et de standardiser davantage l'interface.
Parmi les travaux que nous avons déjà pu observer figurent :
une utilisation accrue de Vue.js ;
le remplacement progressif des anciens composants ;
la réduction de la dépendance à jQuery ;
la modernisation des sélecteurs ;
la révision des composants d'upload ;
la standardisation des champs et des formulaires ;
des améliorations de la navigation ;
la migration du processus de compilation vers Vite.
Vite devrait faciliter le développement et la maintenance des composants du frontend. Pour l'utilisateur final, cependant, le principal gain devrait être une interface plus cohérente et avec des comportements plus standardisés.
Néanmoins, cette migration est en cours de développement et ne doit pas être considérée comme terminée avant la publication de la version stable.
Une interface plus standardisée
Quiconque administre le GLPI depuis un certain temps sait que certains modules ont des comportements différents entre eux.
Cela s'explique par le fait que certaines parties de l'interface ont été créées à des époques différentes et avec des technologies différentes.
Le GLPI 12 devrait réduire ce problème grâce à la réutilisation des composants.
Cela peut apporter des améliorations dans des domaines comme :
la sélection des entités ;
les arborescences hiérarchiques ;
les champs de formulaires ;
les pièces jointes ;
les menus ;
les filtres ;
les messages de validation ;
les cases à cocher ;
les éditeurs ;
les recherches.
En pratique, le système tend à devenir plus prévisible pour les utilisateurs et plus simple à maintenir pour ceux qui développent des plugins ou des intégrations.
Base de connaissances
La Base de connaissances subit également des changements.
Le travail concerne l'éditeur de contenu, la gestion des fichiers, la navigation entre les articles et l'organisation des informations.
Il s'agit d'un domaine important pour les entreprises qui utilisent le GLPI non seulement pour les tickets, mais aussi comme :
base de procédures ;
portail interne de documentation ;
centre de libre-service ;
dépôt de solutions ;
support pour les équipes d'assistance.
Comme cette fonctionnalité est encore en cours de test, des ajustements restent à faire concernant l'interface, les traductions, la performance et le comportement des catégories.
Il n'est donc pas encore possible d'affirmer exactement comment la Base de connaissances sera livrée dans la version finale.
Actifs personnalisés
Les actifs personnalisés ont été l'une des principales nouveautés du GLPI 11.
Cette fonctionnalité permet de créer de nouveaux types d'actifs sans avoir à modifier directement le code source du GLPI.
Une entreprise peut utiliser cette fonctionnalité pour contrôler, par exemple :
des machines industrielles ;
des équipements médicaux ;
des véhicules ;
du mobilier ;
des outils ;
des équipements de laboratoire ;
tout autre objet spécifique à l'opération.
Dans le GLPI 12, l'objectif est que ces actifs soient de plus en plus intégrés au reste de la plateforme.
Parmi les points qui doivent continuer à évoluer figurent :
les recherches ;
les permissions ;
les relations ;
les entités ;
les historiques ;
les formulaires ;
les règles ;
l'API ;
les importations.
Cette évolution est importante car elle permet d'utiliser le GLPI au-delà de l'inventaire traditionnel des ordinateurs, écrans, imprimantes et équipements réseau.
Modernisation interne
Tous les changements ne seront pas visibles à l'écran.
Une part importante du travail sur le GLPI 12 se déroule au niveau de la structure interne du système.
Parmi les points observés figurent :
la refactorisation du code PHP ;
la réduction du code hérité ;
une utilisation accrue des templates Twig ;
la création de composants réutilisables ;
le remplacement des anciennes bibliothèques ;
des améliorations des tests automatisés ;
la révision du frontend ;
des améliorations du système de traductions ;
l'évolution des APIs ;
la compatibilité avec les versions les plus récentes de PHP ;
la révision de la compatibilité avec les bases de données supportées.
Ce type de changement n'attire généralement pas autant l'attention qu'un nouvel écran, mais il est essentiel pour maintenir le projet durable.
Moins il y a de dépendance au code ancien, plus il est facile de corriger les problèmes, d'implémenter de nouvelles fonctionnalités et de maintenir la compatibilité des plugins.
La documentation technique actuelle du GLPI montre déjà cette transition vers une architecture plus modulaire, basée sur des contrôleurs, des templates, des APIs et des composants modernes.
APIs et intégrations
Un autre point qui doit être suivi avec attention est l'évolution des APIs.
Aujourd'hui, de nombreux environnements utilisent le GLPI intégré avec :
des systèmes RH ;
des ERP ;
des outils de supervision ;
des solutions de BI ;
Active Directory et LDAP ;
des plateformes d'automatisation ;
n8n ;
des systèmes internes ;
des portails externes ;
des solutions d'inventaire.
Un changement de version majeure peut modifier les endpoints, les permissions, les champs ou les formats de retour.
C'est pourquoi ceux qui disposent d'intégrations critiques doivent tester principalement :
l'authentification ;
la création et la mise à jour des tickets ;
la lecture des actifs ;
les recherches ;
l'envoi de documents ;
les relations entre objets ;
les permissions des utilisateurs de l'API ;
le retour des endpoints.
Il n'est pas prudent de considérer qu'une intégration qui fonctionne sur le GLPI 11 continuera à fonctionner de la même manière sur le GLPI 12 sans validation.
Sécurité
La sécurité continue d'être travaillée au sein du projet.
Des discussions et des implémentations existent déjà concernant des contrôles supplémentaires pour les opérations sensibles, la révision des permissions et la réauthentification pour certaines actions.
Malgré cela, il est important de ne pas attendre le GLPI 12 pour maintenir l'environnement sécurisé.
Les correctifs de sécurité continuent d'être publiés dans les versions de maintenance du GLPI 11. Les environnements de production doivent donc rester à jour.
Les recommandations de base restent également valables :
ne pas modifier le core ;
maintenir les plugins à jour ;
supprimer les plugins abandonnés ;
revoir les permissions ;
protéger les fichiers de configuration ;
utiliser HTTPS ;
maintenir PHP et la base de données à jour ;
exécuter correctement les actions automatiques ;
revoir les utilisateurs de l'API ;
maintenir une sauvegarde de la base de données et des fichiers.
Compatibilité des plugins
Ce sera probablement l'un des principaux points d'attention lors de la migration.
Une nouvelle version majeure peut modifier les classes, les méthodes, les hooks, les composants JavaScript, les templates et les structures utilisées par les plugins.
Avant de mettre à jour, il sera nécessaire de valider :
si le plugin dispose d'une version compatible ;
si le projet continue d'être maintenu ;
quelles versions de PHP sont supportées ;
s'il existe des modifications dans la base de données ;
s'il y a eu un changement dans les hooks ;
si le frontend du plugin continue de fonctionner ;
si les permissions restent correctes ;
si les actions automatiques fonctionnent ;
s'il existe un processus officiel de migration.
Les plugins abandonnés ou qui modifient directement le comportement du core représentent un risque plus élevé.
Ceux qui ont de nombreux plugins installés doivent commencer les tests avant le lancement de la version stable.
Personnalisations du core
Si l'environnement comporte des modifications directement dans les fichiers du GLPI, la mise à jour sera plus compliquée.
Ces modifications peuvent être écrasées pendant la mise à niveau ou simplement cesser de fonctionner.
L'idéal est que les personnalisations soient réalisées à l'aide de :
plugins ;
APIs ;
webhooks ;
intégrations externes ;
ressources officielles de personnalisation.
Avant de tester le GLPI 12, il est important de recenser toutes les modifications existantes dans l'environnement.
Cela inclut :
fichiers PHP modifiés ;
templates modifiés ;
CSS personnalisé ;
JavaScript personnalisé ;
modifications manuelles de la base de données ;
triggers ;
views ;
intégrations ;
plugins propres.
Sans ce recensement, il devient difficile de distinguer un problème du GLPI d'un problème causé par une ancienne personnalisation.
Le GLPI 12 peut-il déjà être utilisé en production ?
Non.
La version actuelle doit être utilisée uniquement en laboratoire.
Elle peut être utilisée pour :
découvrir la nouvelle interface ;
tester des plugins ;
valider des intégrations ;
analyser des changements techniques ;
vérifier d'éventuelles incompatibilités ;
tester des flux de traitement ;
préparer l'équipe à la migration.
Comme elle est encore en développement, il est possible d'observer :
des erreurs ;
des régressions ;
des modifications de la base de données ;
des fonctionnalités incomplètes ;
des changements d'interface ;
des incompatibilités avec des plugins ;
des problèmes de traduction ;
des changements sans préavis.
Nous ne recommandons pas non plus de connecter une version de développement directement à la base de données de production.
Le test doit être réalisé avec une copie isolée de la base de données et des fichiers.
Nous suivons et testons le GLPI 12
Chez Nextools et chez JMBA Soluções, nous suivons déjà le développement du GLPI 12 et effectuons des tests avec les versions disponibles.
Notre objectif est d'identifier à l'avance les impacts sur :
les plugins ;
les intégrations ;
la base de données ;
l'infrastructure ;
l'authentification ;
les APIs ;
les personnalisations ;
le processus de mise à jour.
Pour faciliter ces tests, nous mettons à disposition une image Docker avec la version de développement du GLPI 12.
Pour télécharger :
docker pull jmbasolucoes/glpi:12-dev
L'image est destinée exclusivement aux tests.
Elle ne doit pas être utilisée en production.
Avec elle, il est possible de déployer rapidement un environnement pour :
évaluer l'interface ;
tester des plugins ;
valider LDAP et SSO ;
tester des intégrations ;
analyser l'inventaire ;
revoir des formulaires ;
vérifier des règles ;
identifier des incompatibilités.
Avant de tester une mise à jour, utilisez toujours une copie de l'environnement.
Ne connectez pas cette image à la base de données de production.
Exemple d'environnement Docker
Ci-dessous se trouve un exemple simple pour déployer le GLPI 12 avec une base de données exclusive pour le laboratoire :
services:
glpi:
image: jmbasolucoes/glpi:12-dev
container_name: glpi-12-dev
restart: unless-stopped
ports:
- "8080:80"
environment:
TZ: America/Sao_Paulo
volumes:
- ./files:/var/lib/glpi
- ./config:/etc/glpi
- ./plugins:/usr/share/glpi/plugins
- ./marketplace:/usr/share/glpi/marketplace
depends_on:
- db
db:
image: mariadb:11.4
container_name: glpi-12-dev-db
restart: unless-stopped
environment:
TZ: America/Sao_Paulo
MARIADB_DATABASE: glpi
MARIADB_USER: glpi
MARIADB_PASSWORD: altere_esta_senha
MARIADB_ROOT_PASSWORD: altere_a_senha_root
volumes:
- ./database:/var/lib/mysql
Pour démarrer :
docker compose up -d
Ensuite, accédez à :
http://localhost:8080
Ce compose n'est qu'un exemple de laboratoire et doit être ajusté en fonction de l'environnement.
Comment se préparer au GLPI 12
Il n'est pas nécessaire d'attendre la version stable pour commencer la préparation.
La première étape consiste à organiser l'environnement actuel.
Mettez à jour le GLPI 11
Avant de penser au GLPI 12, maintenez le GLPI 11 à jour.
Migrer à partir d'une ancienne version augmente le nombre de changements et complique l'identification des problèmes.
Faites un inventaire des plugins
Listez tous les plugins installés et enregistrez :
version ;
développeur ;
finalité ;
criticité ;
statut de maintenance ;
dépendances ;
compatibilité.
Un plugin installé et non utilisé doit être supprimé.
Documentez les intégrations
Enregistrez :
endpoint ;
méthode d'authentification ;
utilisateur utilisé ;
champs envoyés ;
champs reçus ;
fréquence ;
dépendances ;
traitement des erreurs.
Créez un environnement de préproduction
L'environnement de test doit reproduire autant que possible la production :
PHP ;
base de données ;
plugins ;
configurations ;
authentification ;
règles ;
notifications ;
cron ;
intégrations.
Créez un plan de validation
Il ne suffit pas d'ouvrir le GLPI et de vérifier que l'écran s'est chargé.
Il est nécessaire de tester les principaux processus :
ouverture de tickets ;
règles d'attribution ;
SLA ;
notifications ;
formulaires ;
approbations ;
tâches ;
inventaire ;
LDAP ;
SSO ;
actions automatiques ;
API ;
rapports ;
dashboards ;
permissions ;
entités.
Ce que nous attendons vraiment du GLPI 12
D'après ce que nous avons pu observer jusqu'à présent, le GLPI 12 ne sera pas un simple changement de version.
Le projet prépare une base plus moderne pour les années à venir.
Les principaux points sont :
modernisation du frontend ;
utilisation accrue de Vue.js ;
réduction des anciennes dépendances ;
standardisation de l'interface ;
évolution des actifs personnalisés ;
améliorations de la Base de connaissances ;
révision des APIs ;
améliorations internes de sécurité ;
maintenance plus simple du code ;
meilleure structure pour les futures fonctionnalités.
Il n'est pas encore possible d'affirmer quelles fonctionnalités seront présentes dans la première version stable.
Il n'est pas non plus possible de garantir que tout ce qui apparaît aujourd'hui dans le développement sera livré exactement de la même manière.
Le moment est venu de suivre, tester et identifier les impacts.
Ceux qui ont un environnement simple auront probablement un processus de migration plus tranquille.
Ceux qui ont de nombreux plugins, intégrations et modifications propres doivent commencer la validation à l'avance.
Pour démarrer les tests :
docker pull jmbasolucoes/glpi:12-devDans nos prochains contenus, nous partagerons les tests que nous réalisons, les différences par rapport au GLPI 11 et les problèmes rencontrés au cours de cette préparation.
Vous testez déjà le GLPI 12 ? Dites-nous ce qui a fonctionné, ce qui a échoué et quels changements vous avez rencontrés.
Avertissement : ce contenu prend en compte l'état de développement du GLPI 12 en juillet 2026. S'agissant d'une version pas encore stable, les fonctionnalités, prérequis, structure et comportement peuvent changer.
