Retour d’expérience avec Météo – France

1- Pourquoi avez-vous choisi GLPi pour gérer votre parc informatique ?

Les premières études pour la mise en oeuvre d’une gestion de parc à Météo-France remontent à 1999. Notre organisation territoriale est répartie sur la métropole et l’outremer. La gestion du parc informatique est décentralisée sous la responsabilité d’équipes informatiques locales dans les régions ou services centraux. Avant la mise en place d’une DSI en 2000, ces équipes avaient une certaine autonomie de budget et surtout d’organisation. Chacun assurait donc la gestion de son parc, plus ou moins bien, en utilisant diverses solutions : tableau Excel, base Access, Winpark, GLPi, etc. Il était bien évidemment impossible de disposer d’un état du parc pour l’ensemble de l’établissement.

A partir de 1999, les premiers groupes de travail ont donc cherché à recenser les pratiques et les besoins en termes de gestion de parc pour l’ensemble des services. Les objectifs étaient les suivants : établir un état des lieux de l’existant, identifier les fonctionnalités indispensables d’une gestion de parc, préciser qu’elles seraient les interactions éventuelles avec d’autres applications et enfin, évaluer l’offre logicielle du marché. Le choix de la solution logicielle s’est fait tardivement car nous avons eu des difficultés à préciser nos réels besoins en termes de gestion de parc informatique. En 2008, mon prédécesseur a réalisé une étude complète sur l’offre logicielle et a mis en exergue la solution GLPi / OCS qui commençait à monter en puissance, qui était intéressante et, a priori, simple à mettre en œuvre.

En outre l’outil GLPi était déjà utilisé localement dans plusieurs services. En choisissant ce logiciel pour créer notre gestion de parc informatique, nous pouvions bénéficier de l’expérience en interne et faire adhérer les diverses équipes à un projet national en évitant les inévitables résistances au changement. Le comité de pilotage a donc tranché en juillet 2008 et a décidé de mettre en œuvre l’architecture GLPi / OCS au sein de Météo-France. Ce choix pouvait être justifié par les arguments suivants : d’un côté par le faible coût d’investissement au démarrage et l’adhésion des différents acteurs sur le logiciel, et de l’autre par la possibilité de gagner en maturité sur nos besoins en termes de gestion de parc tout en assurant la pérennité de nos données grâce au format ouvert de la base. Depuis 2009, je suis en charge de ce projet. J’avais pour objectifs de mettre en place GLPi / OCS et de livrer une base de gestion de parc informatique centralisée opérationnelle fin 2010.

2- Pouvez vous nous faire part des points positifs/négatifs qui ressortent de l’utilisation du produit ?

Quand on n’a pas l’habitude d’utiliser un outil, inévitablement il y a un temps d’adaptation. Au départ on ne retrouve pas forcément ses marques, et les fonctionnalités ne sont pas toujours les mêmes d’un logiciel à l’autre. Lorsque j’ai vraiment pris en main l’application, je l’ai trouvé très adaptée à une utilisation « administrateur » informatique. L’interface et les fonctionnalités présentes m’ont paru très intéressantes.

La démarche « Open Source » est très différente de la démarche « éditeur payant ». Cela a un impact important, aussi bien dans le déroulement d’un projet que dans la maîtrise en production. Dans un outil « Éditeur payant », on dispose généralement d’une documentation complète. Le logiciel est acheté avec sa liste de fonctionnalités, il est mis en oeuvre, éventuellement avec un paramétrage complémentaire, les nouvelles fonctionnalités ne sont disponibles qu’avec la version suivante. En revanche, l’organisation interne doit immédiatement s’adapter au nouveau logiciel.

Avec un outil Open Source, la démarche est plus complexe et demande une forte implication en interne. Il ne suffit pas de télécharger le logiciel et de l’installer. Il faut prendre l’habitude de travailler dans ce type d’environnement libre. Il faut s’imprégner complètement de la philosophie de l’outil, prendre contact avec les développeurs, suivre les discussions sur les forums, s’impliquer dans la documentation, participer aux évolutions, être force de proposition. La démarche est donc différente, le coût peut se trouver répercuté en ressources humaines ou en prestations externes.
Par opposition à la logique éditeur, il est possible de faire évoluer les structures internes au rythme des possibilités de l’entreprise et non pas à celui de la logique commerciale. Ce projet a été très enrichissant, il nous a permis de rencontrer des experts issus du monde libre et d’échanger avec eux sur les différentes fonctionnalités. Cependant, cette mise en place d’application demande un investissement humain pour l’entreprise qui n’est pas négligeable.

3- Pourquoi avoir choisi cette technologie sachant qu’elle vous demanderait beaucoup d’investissement ?

Le fait qu’il n’y ait pas de licence et de coût immédiat nous a motivé pour retenir cet outil. On a l’habitude d’utiliser des outils du monde libre, mais pas forcément de s’investir comme on l’a fait sur GLPi en essayant de le faire évoluer pour nos besoins tout en cherchant à en faire profiter la communauté GLPi pour les versions suivantes. Jusqu’à présent, on utilisait effectivement des outils libres, on pouvait éventuellement améliorer le paramétrage en interne … Mais notre implication n’allait pas au-delà.

Adepte des outils du monde libre et soucieux de faire les bons choix techniques, une partie de ma communication au niveau du comité de pilotage a été de montrer que nos besoins de développements sur GLPi pouvaient aussi profiter à la communauté du libre. La difficulté est que nous n’avions pas d’expérience dans ce domaine et nous ne savions pas forcément comment procéder afin que les développements puissent être reversés. Ce projet a nécessité une organisation spécifique au sein de Météo-France en termes d’équipe pour suivre les projets, mais aussi en termes d’échanges avec le prestataire et les différents développeurs. Au final le logiciel libre n’est évidemment pas gratuit : cela demande des ressources, une implication forte, une imprégnation des modèles Open Source, et un coût interne d’organisation et de suivi.

4- Le développement réalisé au sein de Météo-France vous a-t-il donné un produit adapté à votre demande, plus qu’un produit qui serait issu d’une licence propriétaire ?

Nous mettons souvent plus de temps pour choisir une solution sous licence propriétaire dans la mesure où il faut s’assurer que toutes les fonctionnalités nécessaires existent afin que l’investissement de départ soit valorisé. Pour la mise en oeuvre de notre gestion de parc, nous avons eu une démarche spécifique en choisissant de construire la solution par étapes successives. Nous avons mis en place une gestion de parc en commençant par réaliser un inventaire de notre parc informatique. Ensuite, nous avons cherché à valoriser cet inventaire en ajoutant la gestion du parc (livraison, suivi du matériel sur son cycle de vie, réforme) et nous avons donc mis en oeuvre, au fur et à mesure, les fonctionnalités existantes, puis développé de nouvelles fonctionnalités au rythme de nos nouveaux besoins. C’est une autre démarche mais la solution libre permet de gérer cela plus facilement. Nous avons préféré démarrer modestement, puis ajouter des fonctionnalités au fur et à mesure de notre montée en compétence et de nos besoins. Dans cette logique, la solution GLPi a totalement répondu à nos attentes.

5- Comment en termes d’organisation, avez-vous réussi à faire correspondre les temps de développements pour GLPi et vos impératifs projets ?

Cela n’a pas été simple car nous avions une démarche de développement plus classique avec une logique de développements souvent réalisés en interne, pour un besoin spécifique d’entreprise, avec des contraintes temporelles importantes. Nous nous sommes vite rendus à l’évidence que la logique du développement libre ne répond pas aux mêmes exigences. Nous aurions pu faire une version GLPi Météo-France, et ça nous aurait demandé moins d’investissement car il n’y aurait pas eu d’aller-retour avec la partie projet GLPi. En revanche, nous aurions eu une version incompatible avec les futures évolutions, à moins de reprendre les développements et de les adapter. Nous avons choisi de travailler avec la communauté et c’est pour cette raison que le temps estimé est parfois plus grand du fait des allers-retours avec les développeurs. Toute évolution, si l’on souhaite la rendre générique et disponible dans les prochaines versions, doit être acceptée par les membres du projet libre et être ajoutée à la roadmap.

Dans ces conditions, le prestataire ou l’entreprise elle-même, doit être capable de travailler avec les développeurs du projet, et souvent raccrocher aux développements souhaités des besoins connexes soumis au projet GLPi sur ses forums. Dans ces conditions, le résultat est souvent bien plus complet que la demande initiale. Ce fut le cas, par exemple, sur la gestion de l’unicité des champs. La livraison finale est largement plus complète que ce que nous avions défini dans le descriptif de la prestation. Si nous avions réellement du financer tout ce projet, je ne suis pas sûr que le coût aurait été le même.
Dans cette logique, travailler avec Teclib’ fut un grand avantage car leurs développeurs sont en relation directe avec les membres du projet GLPi. Leur organisation interne s’adapte parfaitement à la logique de l’Open Source.

6- Qu’est ce qui a motivé vos choix pour l’entreprise Teclib’ ?

Il y a plusieurs raisons. Tout d’abord, les développeurs de Teclib’ étaient très impliqués dans le projet GLPi, ce qui nous a beaucoup rassuré. Ensuite, la société Teclib’ me semblait suffisamment dimensionnée par rapport aux développements sur lesquels elle est engagée. Le choix d’un prestataire est toujours difficile : on essaie de voir comment travaille la société, dans quel type de projet elle est impliquée. C’est d’ailleurs le problème majeur pour une entreprise lorsque l’on s’oriente vers un projet Open Source. Il est toujours difficile de mesurer le degré de pérennité d’un projet et de trouver des partenaires capables de mener une prestation sur du logiciel Open Source. L’affichage Open Source relève souvent du marketing, mais les compétences sur les logiciels sont souvent limitées.

7- Que retirez-vous de la collaboration avec Teclib’ ? En êtes-vous satisfait ?

Ce fut très enrichissant car c’est un monde de développeur que je connaissais mal. Même si dans ma culture informatique je suivais de très près l’environnement Open Source, je n’y participais pas en tant que tel, j’ai appris à appréhender tout ça. J’ai trouvé que la relation avec Teclib’ était très simple et très conviviale, très riche. J’ai eu affaire à des gens très compétents et très réactifs. C’est important pour les relations avec l’entreprise. Les développeurs sont impliqués dans de multiples projets et ont, à ce titre un agenda très chargé. Malgré cela, j’ai toujours eu des réponses très rapidement à mes questions. Que ce soit par téléphone ou par mail, nous avons eu de très bonnes relations, ce que j’ai apprécié. C’est plus riche qu’un simple numéro ou qu’une carte de visite. Cette expérience a été aussi riche techniquement qu’humainement.

8- Utilisez-vous d’autres outils issus du monde libre ?

Dans le domaine bureautique, nous utilisons Open Office sous Linux, mais aussi Firefox et Thunderbird sous Windows. Nous utilisons aussi des outils comme 7-Zip, Filezilla, PDFCreator, etc. Dans l’environnement serveur, une grande place est faite à PostgreSQL, Apache, PHP, Nagios, etc. Aujourd’hui nous essayons de trouver un équilibre entre les outils libres et propriétaires pour tirer partie au mieux de chaque environnement. Il est rare aujourd’hui de voir une entreprise basculer à 100% dans le libre. Cela se fait progressivement. Avant tout on cherchera à répondre au mieux au fonctionnement de l’entreprise que ce soit une solution éditeur (par exemple on aura parfois moins de ressources à consacrer à ce projet) ou une solution libre. L’important est d’avoir une vision homogène de nos projets et une maîtrise sur le format des données que l’on va produire quel que soit l’outil. Dans tous les cas, que le logiciel soit Open Source ou propriétaire, il faut s’assurer que l’on puisse toujours avoir accès à nos données et ceci dans un format pérenne exploitable.

Conclusion

Le projet de gestion de parc sera clos fin 2011, et d’ors et déjà, nous pouvons affirmer que la mise en oeuvre de la solution OCS/GLPi pour gérer le parc informatique de Météo-France est très positive. Nous disposons maintenant d’un outil centralisé performant qui nous offre une vision technique et administrative de notre matériel, qu’il soit en métropole ou en outremer. Il nous permet de gérer les matériels de la livraison à la réforme. Cette gestion d’inventaire est complétée par la gestion des contrats de maintenance et de location, de la gestion des matériels en prêt, d’une base de connaissance. Nous travaillons actuellement sur l’ajout de la gestion de la téléphonie avec l’arrivée prochaine de la ToIP.

Au travers des web services, nous allons enrichir GLPi d’un portail de consultation des inventaires pour des gestionnaires physiques et pouvoir traiter l’alimentation d’une base d’archivage du matériel réformé comme l’exige la réglementation comptable. Cette base d’archivage sera réalisée sur une plate forme GLPi.

En conséquence grâce à GLPi et aux développements réalisés en collaboration avec Teclib’, Météo-France est en mesure d’assurer la maîtrise de son parc informatique. Dans le cadre de ce projet Météo-France a franchi un nouveau cap dans l’Open Source en reversant les développements pour faire profiter la communauté GLPi de ces nouvelles fonctionnalités.

Nous remercions la communauté GLPi pour son accueil et sa collaboration ainsi que l’équipe Teclib’ avec qui nous avons concrétisé les avancées techniques.

Client : Météo France

Interlocuteur :
Bruno Mondin, chargé de projet.

Technologie : GLPi

Mission et challenge :
Réalisation d’évolutions dans l’outil libre de gestion de parc informatique GLPi

Les autres interviews :

Start typing and press Enter to search