GLPI 12 : sur GLPI 10, migrez maintenant ; sur GLPI 11, préparez sans vous presser

Teclib' a publié GLPI 12 le 7 octobre 2026, et cette sortie fait sortir GLPI 10 du support officiel. La bonne décision dépend donc moins des nouveautés que de trois choses : la version sur laquelle tourne votre instance, vos plugins et ce que vos rapports SLA lisent dans la base.

En bref

GLPI 12 est disponible depuis le 7 octobre 2026. Le support officiel de Teclib' couvre les deux dernières versions majeures : GLPI 12 et GLPI 11. Une instance GLPI 10 continue de fonctionner, mais elle ne reçoit plus de correctifs de sécurité, alors que l'éditeur publie des versions de sécurité environ toutes les deux semaines. Sur GLPI 10, il faut lancer le projet de migration maintenant, en visant directement GLPI 12 si vos plugins le permettent. Sur GLPI 11 à jour, rien ne presse : le bon moment arrive quand vos plugins sont compatibles et que vos rapports ont été testés en préproduction.

GLPI 10 sans correctifs : un retard qui grandit toutes les deux semaines

Le 30 septembre 2026, Teclib' a annoncé que GLPI 10.0.28 serait la dernière version de la branche 10. Avec la sortie de GLPI 12, la fenêtre de support passe à GLPI 12 et 11. GLPI 10 en sort, sauf pour les clients qui ont souscrit une assistance étendue GLPI Network.

Le risque est concret. En septembre 2026, deux salves de correctifs ont été publiées à deux semaines d'intervalle (10.0.27 le 16 septembre, 10.0.28 le 30 septembre). D'après le décompte d'IT-Connect, les cinq failles corrigées dans 10.0.28 touchaient aussi GLPI 11. Les prochaines failles trouvées dans le code commun seront corrigées sur GLPI 11 et 12, mais plus sur GLPI 10. Chaque nouvelle version de sécurité creusera donc l'écart.

figure 1 support versions glpi

Pour une organisation dont le périmètre ISO 27001 inclut l'outil de support, la question remonte aussi en audit. Le contrôle 8.8 de l'annexe A de la norme (version 2022) porte sur la gestion des vulnérabilités techniques. Un outil qui ne reçoit plus de correctifs devient un écart à justifier.

Ce que GLPI 12 change vraiment pour un centre de services

Teclib' présente GLPI 12 comme une version de modernisation plutôt qu'une rupture fonctionnelle. Quatre changements touchent directement l'exploitation.

La base de connaissances est réécrite. Les catégories disparaissent : chacune devient un article qui contient ses anciens contenus. Point critique : ces articles restent invisibles tant qu'un administrateur ne leur a pas réattribué des droits. Le lendemain de la migration, vos techniciens et vos utilisateurs peuvent ne plus trouver aucune procédure si cette étape n'a pas été planifiée.

Les OLA suivent chaque équipe. Jusqu'ici, l'OLA (l'engagement de délai interne entre équipes) était un compteur unique porté par le ticket. Le retard retombait sur la dernière équipe intervenue. Dans GLPI 12, chaque équipe qui intervient a sa propre échéance et son propre statut de retard. Contrepartie : Teclib' indique que les rapports personnalisés qui lisent les données d'OLA doivent être refaits.

La sécurité est durcie par défaut. GLPI 12 ajoute un gestionnaire de sessions, qui permet de couper une session ouverte en un clic. Les actions d'administration sensibles demandent une confirmation d'identité. Les requêtes du serveur GLPI vers le réseau interne sont bloquées sauf autorisation explicite. Ce dernier point coupe les webhooks, les flux RSS et les calendriers qui pointent vers des serveurs internes tant qu'ils ne sont pas déclarés.

Les prérequis montent. GLPI 12 demande PHP 8.3 et MariaDB 10.11 ou MySQL 8.0 au minimum. GLPI 10 fonctionnait avec PHP 7.4 et MariaDB 10.2 : la plupart des serveurs GLPI 10 devront donc être mis à jour avant l'application elle-même. Sur RHEL 9, la revue publiée par Würth Phoenix (blog NetEye) signale qu'une installation de GLPI 12 demande des dépôts externes pour PHP 8.3 et MariaDB.

Ce que GLPI 12 n'apporte pas compte aussi. La même revue note que le moteur de workflow et l'éditeur visuel de processus prévus dans la feuille de route ne font pas partie de cette version. Si votre projet attend ces fonctions, migrer ne les apportera pas.

La grille de décision : quatre situations, quatre calendriers

La version de départ décide du calendrier. Les nouveautés ne servent qu'à départager une fois cette question réglée.

GLPI 10 (ou plus ancien), hébergé chez vous. Risque principal : failles non corrigées, qui s'accumulent à chaque version de sécurité. Décision : lancer le projet maintenant. Viser GLPI 12 directement ; passer par GLPI 11 seulement si un plugin critique n'est pas encore porté. À faire avant de migrer : mettre à jour PHP et la base de données ; préparer la migration de FormCreator et Generic Objects vers le cœur ; inventorier les plugins internes.

GLPI 11 à jour. Risque principal : faible à court terme, la branche 11 restant supportée. Décision : préparer, sans fixer de date tant que les plugins et les rapports ne sont pas validés. À faire avant de migrer : monter une préproduction GLPI 12 ; tester la visibilité de la base de connaissances et les rapports d'OLA ; suivre les premières versions correctives 12.0.x.

Nouveau projet de centre de services. Risque principal : démarrer sur une version qui quittera le support plus tôt. Décision : démarrer sur GLPI 12. À faire avant de migrer : vérifier les prérequis du serveur cible ; ne retenir que des plugins déclarés compatibles avec GLPI 12.

GLPI Network Cloud. Risque principal : une mise à jour imposée sans recette interne. Décision : laisser Teclib' planifier ; préparer la recette de son côté. À faire avant de migrer : lister les processus et rapports à revérifier ; pour l'offre Private, demander la mise à jour au support Teclib'.

Trois précisions sur cette grille.

Le passage direct de 10 à 12 est possible. D'après Teclib', GLPI 12 contient toutes les migrations de base de données depuis la version 0.85.5 et les applique en une seule mise à jour. Installer GLPI 11 au préalable n'est donc pas obligatoire. En revanche, la migration des plugins FormCreator et Generic Objects vers les formulaires et actifs natifs reste à faire, comme pour un passage vers GLPI 11.

Sur GLPI 11, attendre une version corrective n'est pas de la frilosité. Après GLPI 11.0.0, Teclib' a publié une 11.0.1 qui corrigeait la plupart des problèmes signalés. Plus récemment, la 11.0.10 bloquait le chargement de certains plugins et a été remplacée dès le lendemain par la 11.0.11. Une préproduction qui rejoue vos processus courants protège de ce type de surprise.

Sur le cloud, la date ne dépend pas de vous. Teclib' indique que les montées de version majeure sur GLPI Network Cloud prennent plus de temps, généralement plusieurs mois. Ce temps sert à préparer la recette.

figure 2 grille decision glpi 12

Les points qui font échouer une migration vers GLPI 12

Teclib' liste huit points à contrôler avant la mise à jour. Cinq d'entre eux touchent directement le service rendu aux utilisateurs. Ce sont ceux à tester en premier.

La base de connaissances invisible. Prévoir la réattribution des droits dans la fenêtre de maintenance elle-même, avec un test par profil (technicien, utilisateur du portail, superviseur).
Les rapports SLA et OLA. Tout rapport ou tableau de bord qui lit les données d'OLA doit être refait. Si ces chiffres alimentent un comité de pilotage ou un engagement contractuel envers un client interne, c'est le point à valider avec le responsable du service, pas seulement avec l'administrateur.
Les flux vers le réseau interne. Webhooks, calendriers et flux RSS qui ciblent des adresses internes sont bloqués tant qu'ils ne sont pas autorisés. Recenser chaque intégration sortante avant la migration, pas après le premier incident.
Les plugins internes ou communautaires. Les plugins de GLPI Network sont déjà portés, d'après Teclib'. Pour les autres, il faut une version déclarée compatible avec GLPI 12 ou une décision explicite de s'en passer.
Le retour arrière. Une version majeure modifie le schéma de la base. Le seul retour possible est la restauration de la sauvegarde faite avant la mise à jour. Ce retour doit avoir été testé, avec sa durée mesurée.

Les trois autres points (supervision des actions automatiques, déclaration du reverse proxy, choix d'authentification pour l'inventaire) relèvent de l'administration système. Ils se règlent en préproduction.

Au Maroc : ce que la fin de support change pour un acheteur public ou une banque

Pour un établissement public, la question se pose souvent au moment d'un appel d'offres de maintenance. Un cahier des prescriptions spéciales qui demande « la dernière version de GLPI » sans la nommer laisse place à l'interprétation. Nommer la version cible (GLPI 12) et exiger des plugins déclarés compatibles avec cette version rend les offres comparables et la recette vérifiable.

Pour une banque, une assurance ou un opérateur dont le système de management de la sécurité de l'information couvre l'outil ITSM, la fin de support de GLPI 10 est un point de gestion des vulnérabilités. Elle mérite d'être inscrite au registre des risques avec un plan daté. L'articulation avec les obligations de la loi 05-20 sur la cybersécurité et les directives de la DGSSI est à vérifier avec votre responsable conformité : nous ne l'avons pas analysée ici.

Dans les deux cas, le calendrier budgétaire compte autant que le calendrier technique. Une migration de GLPI 10 décidée maintenant peut être engagée sur le budget en cours. Une migration repoussée laisse l'instance sans correctifs pendant toute la durée de la procédure d'achat.

Questions fréquentes

Peut-on rester sur GLPI 10 quelque temps ? L'application continue de fonctionner, mais elle ne reçoit plus de correctifs. Seuls les clients ayant souscrit une assistance étendue GLPI Network gardent un support de l'éditeur.

Faut-il passer par GLPI 11 pour aller vers GLPI 12 ? Non. Toute version à partir de la 0.85.5 peut être mise à jour directement vers GLPI 12. Le passage par GLPI 11 ne se justifie que si un plugin indispensable n'est pas encore disponible pour GLPI 12.

Nos intégrations par API vont-elles casser ? D'après Teclib', non dans la plupart des cas : l'API de haut niveau v3 fonctionne en parallèle des versions 1 et 2. Deux points restent à tester : ce qui lit les catégories de la base de connaissances, qui n'existent plus, et les webhooks vers des adresses internes.

Ce qu'Alton fait sur ce sujet

Alton est partenaire Silver GLPI Network de Teclib' au Maroc. Nous conduisons la migration vers GLPI 12 : diagnostic de l'instance et des plugins, préproduction, recette des processus et des rapports SLA, puis bascule avec retour arrière testé. Pour une instance GLPI 10, un premier diagnostic permet de choisir entre le passage direct vers GLPI 12 et une étape par GLPI 11.

Sources

Partager :LinkedIn Facebook WhatsApp