Entrevue avec GLPI

Posté par  (site web personnel) . Modéré par tuiu pol. Licence CC By‑SA.
21
14
nov.
2011
Technologie

Jean‐Mathieu Doléans a accepté de se prêter au jeu des questions pour LinuxFr.org sur le projet GLPI. GLPI est un outil de gestion de parc informatique et de centre d’assistance. Il a la particularité, entre autres, de très bien fonctionner avec FusionInventory… dont LinuxFr.org s’est aussi entretenu avec ses auteurs.

LinuxFr.org : T’es qui toi ?

T’es dur là, et mon psy ne m’aide pas à répondre à cette question existentielle, malgré ma lourde contribution à son train de vie indécent.

Plus sérieusement, je me nomme Jean‐Mathieu Doléans, et suis le co‐fondateur du projet GLPI et le président de l’association Indepnet qui porte ce projet. J’ai également une passion pour les TIC et les logiciels libres depuis de nombreuses années.
Dans le civil, je suis chargé de mission TIC dans une collectivité territoriale.

LinuxFr.org : C’est quoi GLPI ? Qu’est‐ce que ça fait, et comment ?

GLPI signifie Gestion Libre de Parc Informatique. C’est une solution de gestion de parc informatique et de centre de services. Elle se présente sous la forme d’une application 100 % Web et permet de gérer l’ensemble des problématiques de gestion de parcs informatiques : de la gestion des composantes matérielles ou logicielles d’un parc informatique, à la gestion financière et administrative, en passant par la gestion de l’assistance aux utilisateurs.

LinuxFr.org : C’est sous quelle(s) licence(s) ?

GLPI est publié sous licence GPL v2.

LinuxFr.org : C’est développé autour de quelles « technos » ?

Les technos utilisées par GLPI sont très répandues : PHP, HTML, JavaScript. GLPI s’appuie sur le SGBD MySQL (pour le moment uniquement). Il fonctionne très bien sur une architecture de type LAMP.

LinuxFr.org : Ça se compare à quoi de libre ou proprio ?

GLPI peut être comparé à des solutions libres comme OTRS, OneOrZero ou Request Tracker, pour la partie centre d’assistance. Pour la partie gestion de parc, il y a IDSI, H-Inventory et Open‐AudIT.

Pour ce qui est des solutions propriétaires, on peut citer Landpark, LANDesk, Kaseya…

LinuxFr.org : Quelles sont les tueries de ce logiciel ?

Plus globalement, je dirais que la grande force de GLPI c’est sa communauté importante et dynamique. Elle explique d’ailleurs la longévité du projet et sa forte évolution fonctionnelle. GLPI s’est enrichi en interaction forte et constante avec ses utilisateurs.

De façon plus précise, le premier + est son couplage de la gestion de parc informatique et du centre d’assistance. Cette gestion intégrée est un vrai plus au quotidien.

Le second + est sa gestion multi‐entité. En gros, GLPI permet de faire de la gestion de parc multi‐client ou multi-structure avec une seule instance. Chaque sous‐structure (une « entité ») est cloisonnée, mais une vision consolidée du parc est accessible à un niveau supérieur. C’est quasiment indispensable dans les grandes structures ou organisations complexes.

Un exemple peut‐être ? Le parc informatique utilisé par les établissements scolaires de l’Académie d’Amiens est composé de matériel financé par les départements et la Région. Le besoin était de fournir à chaque acteur une vision et une gestion du parc informatique (local pour l’établissement, départemental pour les Conseils Généraux, régional pour la Région et académique pour le Rectorat). Le Rectorat de l’Académie d’Amiens a déployé GLPI de façon centralisée, mais grâce à la gestion multi‐entité, chaque acteur sait gérer son parc et son centre de services de façon autonome, tout en offrant une vision consolidée pour les acteurs de niveau supérieur.

Le troisième + est son intégration des bonnes pratiques ITIL au niveau du centre d’assistance. GLPI gère les demandes, les incidents, les problèmes, les SLA et bientôt les changements.

Le quatrième + est constitué par ses outils facilitateurs : collecteurs de courriels pour la création automatique de tickets, moteurs de règles et d’actions complexes pour l’importation des éléments d’inventaires, des utilisateurs à partir d’annuaires, système d’actions automatiques pour les SLA (escalade, requalification, gestion de priorité, etc.).

Le cinquième + (et je m’arrête là) est le catalogue des greffons de GLPI. De nombreux greffons sont disponibles et permettent à GLPI d’interagir avec d’autres applications (Snort, Cacti, OCS NG, Centreon, FusionInventory, etc.) ou de répondre à des besoins spécifiques (gestion de certificats, de badges, interface pour terminaux mobiles et tablettes, etc.).

LinuxFr.org : Y a‐t‐il des velléités d’utiliser des systèmes de suivi comme Bugzilla, Flyspray, Mantis et consorts, en lieu et place du centre de services intégré ?

La finalité de ces outils est différente. Selon moi, ces outils sont plus liés à une activité de développement logiciels qu’à la gestion complète d’un centre d’assistance ou de services qui comprennent plus de fonctionnalités (gestion des demandes, gestion des incidents, base de connaissances, portail libre‐service pour l’utilisateur final, réservation de ressources, gestion des accords de niveau de service, etc.).

LinuxFr.org : Y a‐t‐il de vrais bénéfices à intégrer la « bureaucratie » ITIL dans un logiciel libre ? N’est‐ce pas un peu passé de mode et réservé à des DSI férus de procédures normalisées ?

GLPI est compatible ITIL, ça veut pas dire qu’il ne fait que du « ITIL ». La compatibilité de GLPI avec les bonnes pratiques ITIL était une demande de nos utilisateurs de type « grandes structures ». Nous avons mis du temps (trop au goût de certains) à y répondre, car nous ne voulions pas mettre en difficulté nos utilisateurs historiques en cédant à une mode. Nous avons donc pris le temps d’étudier ITIL, rédigé pas mal de spécifications, beaucoup débattu en interne et réfléchi à l’implémentation qui nous semblait la plus viable et cohérente d’ITIL dans GLPI.
On peut donc utiliser librement GLPI sans avoir conscience de l’existence d’ITIL ou, au contraire, respecter à la lettre les pratiques ITIL en s’appuyant sur GLPI.

LinuxFr.org : Au niveau des greffons, arrivez‐vous à obtenir un écosystème cohérent avec des greffons tous compatibles et sans collision, n’insérant pas de failles de sécurité ?

Nous tentons d’appliquer une règle simple et facilement compréhensible de tous. Si le besoin est générique et commun au plus grand nombre, la fonctionnalité sera inscrite sur la feuille de route du cœur de GLPI. Si c’est un besoin spécifique, alors il faut développer un greffon. Parfois, le greffon évolue et les fonctionnalités qu’il propose s’élargissent au point de couvrir un besoin générique. Dans ce cas, l’intégration du greffon dans le cœur est envisagée.

Les greffons sont des projets qui ont leur vie propre, ils restent donc compatibles avec les différentes versions de GLPI, si leurs auteurs les maintiennent et les font évoluer dans ce sens.
Pour ce qui est de la fiabilité des greffons, nous n’avons malheureusement pas, pour le moment, les moyens humains de les valider ou certifier. Il peut donc y avoir de grandes différences de qualité entre les greffons.

LinuxFr.org : Y a‐t‐il un business model autour ?

La structure de développement officielle du projet GLPI est l’association Indepnet. En tant qu’association à but non lucratif, nous n’effectuons aucune prestation à caractère commercial. Les nombreuses demandes de prestations de support, de formation, etc., nous ont amené à constituer un réseau de partenaires aptes à répondre à ce type de besoins.

Nous souhaitons privilégier un partenariat qualitatif qui soit profitable au projet et aux utilisateurs. Nous avons donc mis en place un système de partenariat garant d’un vrai niveau d’implication des parties et d’un soutien actif (humain et financier) au projet.

L’échange est gagnant‐gagnant, puisqu’en soutenant le projet, les partenaires s’assurent de son développement, de sa pérennité et, par conséquent, de nouvelles prestations.

Le pari n’était pas gagné d’avance, car cela va à l’encontre du mode classique de partenariat/affiliation. Certaines boîtes nous ont carrément demandé de l’argent pour être partenaires, d’autres étaient scandalisées que nous leur demandions de s’engager à soutenir le projet, notamment financièrement, car le logiciel libre, c’est gratuit…

Nous avons tout de même réussi, et aujourd’hui nous avons des partenaires qui réalisent une partie de leur chiffre d’affaires en offrant des prestations autour de GLPI, et qui respectent et soutiennent réellement le projet et sa communauté.

LinuxFr.org : Peut‐on comparer cela à une sorte de consortium ? Le succès d’une telle organisation n’est‐il pas dépendant du succès de celui‐ci ? Une entreprise contribuera‐t‐elle si et seulement si les autres contribuent ? Ou bien conservera‐t‐elle dans ses tiroirs les avantages concurrentiels jusqu’à obsolescence ?

Je ne suis pas sûr de bien saisir la deuxième question…

Non, ce n’est pas un consortium, l’association est toujours la structure officielle de développement et, en ce sens, elle assure que le projet reste communautaire. Les partenaires respectent ce fait. Pour ce qui est de la problématique de la contribution, nos partenaires signent une convention dans laquelle ils s’engagent à soutenir le projet, mais aussi à reverser les développements réalisés au cours de prestations. Le véritable avantage concurrentiel se situe, à mon avis, au niveau de la courbe d’expérience acquise par chaque partenaire, plus que sur une hypothétique contribution non reversée.

LinuxFr.org : Le cloud est‐il une offre viable, un business‐model possible pour GLPI ?

C’est une question qu’il faudrait poser à nos partenaires. ;)
Maintenant, oui, cloud ou pas cloud, il y a certainement une demande pour une offre en mode SaaS.

LinuxFr.org : Quels sont les déploiements publics ou privés (dont vous pouvez parler) les plus significatifs ?

Le plus grand déploiement recensé de GLPI concerne la C.N.A.M.T.S. (La Caisse nationale de l’assurance maladie des travailleurs salariés). GLPI y est utilisé (couplé à OCS pour la remontée d’inventaire) pour gérer un parc de plus de 130 000 machines, et pour gérer un centre de services pour environ 25 000 utilisateurs et près de 500 tickets/jour.

Pour le reste la page « références » sur le site de GLPI témoigne d’un nombre important de déploiements dans des types très différents de structures de statuts et de tailles très variés (ministères, PME, régions, mairies, associations, grandes entreprises, universités…), et dans différents pays.

LinuxFr.org : Vous êtes combien de contributeurs ?

Il y a plusieurs équipes de contributeurs au projet GLPI. L’équipe de développement comprend environ une dizaine de personnes, et celle de traduction en représente environ 150, pour une cinquantaine de langues.

L’équipe de développement des greffons GLPI comprend une cinquantaine de personnes. L’équipe des rédacteurs de la documentation est pour l’instant très/trop limitée et correspond à 4 personnes.

Enfin, sur le forum d’entraide communautaire, il y a près de 18 000 inscrits. Tout cela fait un peu de monde, mais la maison est grande !

LinuxFr.org : Comment est né le projet ? Comment a‐t‐il évolué ? Quels sont les faits marquants ?

L’ancêtre fonctionnel de GLPI est IRMA, logiciel libre initialement développé par Christian Bauer. Ce dernier s’était inspiré d’un autre logiciel, IRM, pour re‐développer une application qui répondait mieux à ses besoins. IRMA avait été réalisée pour répondre à une demande précise, et l’auteur souhaitait conserver le nom, mais ne voulait plus maintenir, ni faire évoluer l’application.

En 2003, Bazile, un membre de l’association Indepnet, découvrit IRMA et souhaita l’adapter aux besoins de la Communauté d’agglomération de Montpellier. Convaincu de l’intérêt de l’application, j’ai proposé à Bazile que nous reprenions le développement de cette application dans le cadre de l’association. Le projet fut baptisée GLPI, et quelques mois plus tard, la première version était disponible en téléchargement.

Pour la petite histoire, IRM a été abandonné en 2007, et les auteurs conseillent désormais d’utiliser GLPI.

Au fil des sorties de version, le code a été totalement réécrit et amélioré, même s’il reste beaucoup à faire. Il est clair qu’il est plus facile de développer une application à partir de rien que de la faire évoluer en assurant systématiquement à nos utilisateurs une reprise de l’existant.

Les étapes importantes du projet ont été l’apparition des premiers greffons qui ont permis aux utilisateurs d’adapter GLPI à leurs besoins spécifiques, l’arrivée de la CNAMTS en tant que gros utilisateur/contributeur, et dont deux brillants éléments (Rémi et Nelly) ont intégré l’équipe de développement du projet, la mise en place de la gestion multi‐entité qui a permis à de grosses structures d’adopter GLPI, et enfin l’intégration des bonnes pratiques ITIL au niveau du centre de services qui a facilité l’adoption de GLPI par les DSI.

LinuxFr.org : Quels problèmes avez‐vous rencontrés ?

Les problèmes rencontrés sont inhérents à la plupart des projets libres. Comment constituer, faire vivre et grandir la communauté ? Comment organiser, structurer et fiabiliser le développement ? Comment assurer l’internationalisation de l’application ? Comment constituer une feuille de route (roadmap) qui satisfasse les utilisateurs actuels et en attirent de nouveaux ? Comment avoir encore un peu d’énergie à consacrer à sa famille, lorsqu’on a répondu à toutes ces questions ?

LinuxFr.org : Quelle est votre feuille de route ?

La feuille de route complète est disponible sur le site du projet.

Dans les grandes lignes tout de même :
La prochaine version (0.83) intégrera encore plus de fonctionnalités liées à ITIL : gestion des problèmes, gabarits pour la création de tickets, et de nombreuses améliorations pour la gestion du centre de services. Elle proposera également d’autres fonctionnalités dans les autres modules.

Dans les gros chantiers à venir par la suite, on trouve des avancées fonctionnelles : gestion des changements (ITIL), refonte complète de la gestion des réseaux, améliorations des statistiques et rapports, du système de notifications ou de l’interfaçage avec des annuaires LDAP…

Mais une grosse partie du travail à réaliser concerne surtout les fondations (parties invisibles) du projet : refonte du système d’internationalisation, refonte du système d’historique… afin de permettre à GLPI d’évoluer plus facilement.

LinuxFr.org : Merci beaucoup !

Aller plus loin

  • # OTRS

    Posté par  (site web personnel) . Évalué à 4.

    Ici, dans les milieux universitaires, GLPI semble de plus en plus abandonné pour OTRS à cause d'une implémentation moyenne de ITIL (que l'on me dit), quelqu'un en sait plus ?

    • [^] # Re: OTRS

      Posté par  . Évalué à 3.

      Itil est en cours d'implémentation dans Glpi depuis plusieurs versions déjà, et les parties restantes sont prévues pour les prochaines version. N'étant pas expert sur le sujet, je laisse les gens du projet répondre, mais la roadmap est disponible et toujours très à jour !
      https://forge.indepnet.net/projects/glpi/roadmap

    • [^] # Re: OTRS

      Posté par  (site web personnel) . Évalué à 4.

      OTRS dispose d'un module nommé OTRS::ITSM pour la partie ITIL.
      Maintenant, ITIL reste un recueil de bonnes pratiques en production informatique, pas une religion.

  • # Champs personnalisés

    Posté par  (site web personnel) . Évalué à 2.

    GLPI, ça a l'air top moumoute.
    Mais je pige pas un truc : pourquoi on peut pas créer de champs personnalisés ?
    Chaque boite à sa propre façon de gérer ses machines. Alors les entrées complètement figées proposées pour les ordinateurs, c'est un truc que je ne comprends pas.

    Par exemple, là où je bosse, dans notre inventaire, on n'en a rien ç faire de la version de l'OS. C'est un champ que je voudrais ne pas voir quand je saisi de nouvelles machines. Par contre, pour chaque PC, on a trois numéros de série, chacun ayant un intitulé bien précis. Je voudrais donc créer des champs, au moins deux supplémentaires, avec cet intitulé. Et c'est pas possible ?

    GLPI est beaucoup trop figé pour être adopté par plein de boites différentes !

    • [^] # Re: Champs personnalisés

      Posté par  . Évalué à 1.

      3 numéros de série par ordinateur?? ils viennent de Mars tes ordinateurs ?

      • [^] # Re: Champs personnalisés

        Posté par  (site web personnel) . Évalué à 1.

        C'est ça, moinssez-moi. C'est la vérité qui fâche ?

        Un numéro pour le service compta, un pour la société externe qui fait la maintenance, et le dernier, c'est celui du constructeur.

        • [^] # Re: Champs personnalisés

          Posté par  . Évalué à 3.

          Un numéro pour le service compta => Numéro d'immobilisation
          un pour la société externe qui fait la maintenance => numéro d'inventaire
          le dernier, c'est celui du constructeur => Numéro de série

          Bref y a tout pour gérer ;)

    • [^] # Re: Champs personnalisés

      Posté par  (site web personnel) . Évalué à 1.

      Ce plugin peut sans doute t'aider :
      https://forge.indepnet.net/projects/customfields

      • [^] # Re: Champs personnalisés

        Posté par  (site web personnel) . Évalué à 0.

        Il pourrait m'aider si je voulais installer un GLPI d'il y a deux ans. Mais si je veux la dernière version stable, ben non, ce plugin ne fonctionne pas.

    • [^] # Re: Champs personnalisés

      Posté par  . Évalué à 4.

      Je comprend ta frustration mais je crois qu'elle est surtout engendrée par un aperçu trop bref de l'appli.

      Pour répondre à ta problématique, tu as à ta disposition pour un élément du parc les champs suivants :

      Pour l'objet :
      - Numéro de série de l'objet
      - Numéro d'inventaire de l'objet
      Dans l'onglet Gestion :
      - Numéro de commande
      - Numéro d'immobilisation
      - Numéro de facture
      - Numéro du BL

      Je crois que normalement cela devrait couvrir tes besoins...

      Enfin pour répondre à ta question portant sur les champs personnalisés, simplement parce que nous appliquons des règles métiers sur ces champs : calcul d'amortissement, TCO par exemple. Ou que ces champs peuvent être renseignés par des remontées d'inventaire d'agents (fusioninventory, OCSNG...), ou que ces mêmes champs peuvent faire l'objet d'actions automatiques également.

      Bref, c'est toujours la même histoire de compromis. Tu acceptes de perdre un peu de la totale personnalisation de la solution "maison" pour bénéficier d'un truc un peu "cadré" mais qui offre des automatismes et te simplifie la vie. C'est un choix à opérer en fonction de ses besoins, de ses contraintes et de ses moyens.

      Pour ce qui est de ta dernière affirmation, un peu péremptoire, je t'en laisse seul juge.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.