API GLPI en Python : automatiser sans que vos scripts tombent la nuit

Depuis la version 11, GLPI propose deux API : l'historique, désormais appelée « legacy » dans la documentation officielle, et une nouvelle API de haut niveau fondée sur OAuth2. Pour les équipes qui utilisent l'API GLPI en Python, que ce soit pour créer des tickets, extraire des rapports ou synchroniser l'inventaire, le choix entre les deux n'est plus théorique.

Elle se double d'un problème plus terre à terre : des scripts qui fonctionnent le jour et s'arrêtent la nuit. Cet article explique d'où vient cette fragilité, comment glpi-rest, la première des six bibliothèques open source publiées par Novagios, la traite, et comment choisir entre les deux API.

L'essentiel en 30 secondes

• La cause la plus fréquente des scripts GLPI qui s'arrêtent : une session expirée, signalée par l'erreur ERROR_SESSION_TOKEN_INVALID.
• glpi-rest se reconnecte et rejoue la requête une seule fois, sans risque de boucle ; il est testé sur GLPI 10.0.26, 11.0.2 et 11.0.8.
• L'API v1 reste disponible dans GLPI 11 ; la v2 n'existe qu'à partir de GLPI 11. Si une partie de votre parc est encore en GLPI 10, la v1 reste le point commun.

Pourquoi l'API GLPI en Python fragilise vos automatisations

L'API historique de GLPI fonctionne par session. Un script appelle d'abord initSession, avec un identifiant et un mot de passe ou, mieux, un jeton utilisateur. GLPI lui renvoie un jeton de session, à joindre ensuite à chaque appel. C'est ce que décrit la documentation de l'API REST de GLPI.

Le jeton finit par expirer. GLPI répond alors par l'erreur ERROR_SESSION_TOKEN_INVALID, et la documentation demande au client de rouvrir une session. Un script écrit à la main ne le fait presque jamais : il plante, souvent pendant un traitement de nuit, et personne ne le voit avant le matin.

Ces automatisations sont pourtant au cœur du service desk. Un script crée chaque nuit les tickets de maintenance planifiée, un autre alimente le tableau de bord de la direction, un troisième rapproche l'inventaire GLPI de l'annuaire. Quand l'un d'eux s'arrête, les équipes découvrent le trou le lendemain : tickets manquants, indicateurs figés, parc désynchronisé. C'est l'exploitation du support qui en paie le prix.

Deux autres irritants s'ajoutent. Les critères de recherche se passent sous une forme indexée, criteria[0][field]=23, qu'il faut construire caractère par caractère. Et les réponses arrivent sous forme de dictionnaires sans type : une faute de frappe dans un nom de champ ne se révèle qu'en production.

Ce que fait glpi-rest, concrètement

glpi-rest est un client Python pour cette API. Il ne dépend que de la bibliothèque requests et fonctionne sous Linux, macOS et Windows, avec Python 3.10 à 3.13. La version 0.1.0 a été publiée sur PyPI le 11 octobre 2026, sous licence Apache 2.0.

Son apport principal est la reprise automatique de session. Quand un appel reçoit une erreur 401, la bibliothèque rouvre une session et rejoue exactement la même requête, corps compris. Cette relance est unique : un second échec fait remonter une exception explicite. Même avec un mot de passe faux, le client ne tourne jamais en rond.

Le reste du client vise la lisibilité. La recherche multicritère passe par des objets SearchCriterion au lieu de paramètres construits à la main. Les résultats reviennent dans un objet typé, avec le nombre total de résultats. Les erreurs prennent la forme d'exceptions distinctes, pour l'authentification, la session ou un objet introuvable :

from glpi_rest import GLPIClient, SearchCriterion

with GLPIClient(url, app_token=app_token, user_token=user_token) as glpi:
    ticket = glpi.get_item("Ticket", 42)
    nouveaux = glpi.search("Ticket", criteria=[SearchCriterion(field=12, value=1, searchtype="equals")])
    print(nouveaux.total_count, "tickets au statut nouveau")

Le bloc with encadre la session : elle démarre avec lui et se referme dans tous les cas, y compris quand le code lève une erreur.

Une sécurité réglée par défaut

Un script d'automatisation manipule des jetons qui donnent accès à tout votre parc et à vos tickets. Selon le journal des versions de glpi-rest, les réglages par défaut sont pensés pour la production : vérification TLS activée, délai d'expiration de 30 secondes sur chaque requête, jetons transmis dans les en-têtes HTTP.

Sur ce dernier point, la différence est concrète. Placé dans une adresse, un jeton se retrouve recopié dans les journaux des serveurs web et des proxys, ce qui n'arrive pas avec un en-tête. La bibliothèque n'envoie aucune télémétrie et ne contacte que le serveur GLPI que vous lui indiquez.

Le README recommande aussi un compte GLPI dédié, limité aux droits dont l'automatisation a besoin, plutôt qu'un compte super-administrateur. C'est une règle simple, qui réduit beaucoup l'impact d'un jeton divulgué.

API GLPI v1 ou v2 : que choisir en 2026 ?

La documentation développeur de GLPI indique que l'API de haut niveau existe à partir de GLPI 11.0. Elle s'authentifie entièrement en OAuth2, avec des jetons d'accès valables une heure par défaut. La documentation précise que l'API historique reste disponible, et qu'elle offre parfois plus de fonctions, au prix d'une ergonomie moindre.

La page de l'API v1 la présente comme l'« ancienne version de l'API ». Aucune date de retrait n'y figure. Le choix dépend donc surtout de votre parc.

Si une partie de vos instances tourne encore en GLPI 10, seule la v1 fonctionne partout. C'est le cas de figure que couvre glpi-rest. Si tout votre parc est en GLPI 11 et que vous démarrez une nouvelle intégration, la v2 mérite d'être évaluée. Pour le calendrier de migration lui-même, voyez notre article GLPI 10 arrive en fin de vie : migrer vers GLPI 11 maintenant ou attendre GLPI 12 ?.

Un outil parmi d'autres, et comment il est vérifié

glpi-rest n'est pas le seul client Python pour GLPI. glpi_py, publié par Grupo Parawa en version 0.4.2 le 20 mars 2026, couvre davantage de types d'objets ; son propre README le reconnaît et le conseille si vous avez besoin de cette largeur. glpi-rest fait un autre pari : moins d'objets, mais un comportement prévisible quand la session tombe.

Pour vérifier ce comportement, la bibliothèque compte 27 tests sur une API simulée et une suite d'intégration validée contre de vrais serveurs GLPI 11.0.2, 11.0.8 et 10.0.26. Un contrôle hebdomadaire rejoue cette suite contre GLPI 10 et 11 pour repérer tout changement de l'API en amont.

glpi-rest est aussi le premier maillon d'une chaîne plus large : il extrait les tickets que les autres bibliothèques anonymisent, puis utilisent pour entraîner un modèle de tri. Nous présentons l'ensemble dans notre article sur les six bibliothèques Python open source.

Plan d'action pour fiabiliser vos scripts GLPI

1. Inventoriez vos automatisations : listez les scripts qui appellent l'API GLPI, leur fréquence et la version de GLPI visée.
2. Créez un compte technique dédié : des droits limités au strict besoin, un jeton utilisateur plutôt qu'un mot de passe.
3. Sortez les jetons du code : variables d'environnement ou coffre-fort de secrets, jamais dans le dépôt.
4. Remplacez les appels directs par un client qui gère l'expiration de session, comme glpi-rest.
5. Décidez de votre trajectoire API : v1 tant qu'il reste du GLPI 10, évaluation de la v2 une fois le parc entièrement en GLPI 11.

Notre offre d'intégration et d'automatisation peut vous accompagner sur ces cinq étapes, et notre pôle IT Service Management sur l'exploitation de GLPI au quotidien.

Limites de l'analyse

glpi-rest couvre l'API v1 et des opérations génériques : lecture, création, modification, suppression et recherche. Il ne gère pas l'API v2 en OAuth2, et sa version 0.1.0 est récente. Les tests cités sont ceux du projet lui-même ; ils sont reproductibles, mais aucun tiers ne les a encore audités. Enfin, la documentation de GLPI ne donne pas de date de retrait pour l'API v1 : la recommandation sur la trajectoire peut évoluer avec les prochaines versions de GLPI.

Questions fréquentes

Comment utiliser l'API GLPI en Python ?

Activez l'API REST dans Configuration > Générale > API, créez un client API et un jeton utilisateur, puis installez un client Python comme glpi-rest avec pip install glpi-rest. Le script ouvre une session, appelle les objets voulus, puis ferme la session.

Pourquoi mon script GLPI renvoie-t-il ERROR_SESSION_TOKEN_INVALID ?

Le jeton de session a expiré ou n'est plus valable. La documentation de GLPI demande de rouvrir une session avec initSession. glpi-rest le fait automatiquement, une seule fois, puis rejoue la requête.

Faut-il passer à l'API v2 de GLPI ?

Pas forcément. La v2 n'existe qu'à partir de GLPI 11 et l'API v1 reste disponible. Tant qu'une partie de votre parc est en GLPI 10, la v1 reste la seule option commune.

glpi-rest fonctionne-t-il avec GLPI 10 ?

Oui. Il a été testé contre un serveur GLPI 10.0.26 réel, ainsi que contre GLPI 11.0.2 et 11.0.8.

Sources

1. README de glpi-rest, octobre 2026.
2. Journal des versions de glpi-rest, version 0.1.0.
3. PyPI, glpi-rest, 11 octobre 2026.
4. GLPI, documentation de l'API REST (apirest.md), consultée le 15 octobre 2026.
5. GLPI, documentation REST API (V1), consultée le 16 octobre 2026.
6. GLPI, documentation RESTful API (V2), consultée le 16 octobre 2026.
7. GLPI, documentation développeur, High-Level API, consultée le 16 octobre 2026.
8. PyPI, glpi_py, version 0.4.2 du 20 mars 2026.

Vos automatisations GLPI s'arrêtent sans prévenir ? Demandez un diagnostic de vos scripts : nous les revoyons avec vous et proposons un plan de fiabilisation.