Blog

Etude de cas - Paris Musées

emeline.peysson
22/10/2019
Face aux enjeux et aux mutations digitales de ces dernières années, Paris Musées voit sa relation avec son public se modifier. C’est dans ce contexte que l’institution publique a lancé en 2016, un portail des collections inédit regroupant les 14 musées municipaux de la ville de Paris avec comme objectif premier de donner plus de visibilité à ses œuvres. Retour sur ce projet innovant.
Etude de cas Paris Musées

 

Face aux enjeux et aux mutations digitales de ces dernières années, Paris Musées voit sa relation avec son public se modifier. C’est dans ce contexte que l’institution publique a lancé en 2016, un portail des collections inédit regroupant les 14 musées municipaux de la ville de Paris avec comme objectif premier de donner plus de visibilité à ses œuvres.

 

Une stratégie digitale adaptée au milieu culturel

Chercheurs, grand public, professionnels d’art… Paris Musées a fait appel à Axess Open Web Services afin de renforcer sa stratégie de communication auprès de ses publics et ainsi répondre à quatre objectifs :
-    Créer un portail commun pour les 14 musées municipaux de Paris en y intégrant une passerelle unique vers leurs différents sites web.
-    Accroître la visibilité de ses collections comprenant 1 million d’œuvres et permettre une navigation fluide via internet.
-    Inciter l’internaute à parcourir le portail grâce à des thématiques illustrés par les œuvres des collections.
-    Communiquer et mettre en valeur ses expositions sur son portail tout en valorisant sa programmation d'activités culturelles dans les musées grâce à une refonte du site internet réalisée en janvier 2019.

« Nous avons choisi Axess Open Web Services pour leur compréhension de notre problématique et leurs références dans le domaine institutionnel, mais également pour leur approche technique et ergonomique. » explique Philippe Rivière, Chef du Service numérique de Paris Musées.

Drupal : un CMS puissant pour un projet d’envergure

L’ensemble des sites internet de Paris Musées fonctionnant déjà sous Drupal, le choix de ce CMS était fortement conseillé : « Une fois le cahier des charges validé, tout est allé très vite. Le plus gros du travail a été mené dans les flux des données et la numérisation des œuvres » nous confie Philippe Rivière.
Ouvrant une infinité de portes, le site web a été fait sur-mesure : il est notamment responsive, multilingue et doté d’un espace utilisateur. Qui plus est, une base de plusieurs millions d’items a été traitée afin de pouvoir proposer tout un ensemble de fonctionnalités : rechercher, filtrer, affiner et trier est très facile, sachant que le site propose également de personnaliser sa navigation avec des nouveautés et des suggestions en fonction de ses goûts personnels.

Vers une ouverture des données : l’Open data

Paris Musées a aussi la volonté de présenter en ligne un contenu ouvert et homogène grâce à l’utilisation d’une API (Application Programming Interface ou Interface de programmation en français).
L’API fait office de passerelle et récupère les informations dont elle a besoin dans une base de données unique (le portail des collections) pour ensuite les réinjecter dans les différents sites internet de Paris Musées (exemple : Musée Cernuschi, Petit Palais) et leurs applications mobiles ("Pas à Pas" du Musée Carnavalet).
Aujourd’hui à vocation interne, cette API sera ouverte à l’internaute début 2020 afin qu’il ait accès librement à toutes les données textuelles disponibles sur le portail des collections.

Des retombées non négligeables

Après la sortie de son site web « Paris Musées collections » en 2016, l’image de l’institution s’est renforcée avec pas moins de 14 retombées presse papier (Le Quotidien de l’art, Femme Actuelle, Direct Matin…), 39 retombées web (Le Parisien, Aujourd’hui Paris…) et 3 reportages télévisés (France 2, France 3 et BFM Business).
Le site a même été accompagné d’une campagne de communication sur Instagram où 10 instagrameurs ont réinterprété de façon créative et décalée les chefs d’œuvre qui étaient diffusés en ligne. Les créations ont ensuite été exposées dans la gare Saint-Lazare à Paris pendant près de 3 mois. Résultat : pas moins de 33 retombées en France (M6, France inter, Les Inrocks…) et 56 à l’internationales (The Telegrap, Mashable, Lonely Planet…).

Aujourd’hui, Paris Musées c’est :
-    Plus de 310 000 œuvres en ligne
-    Plus de 11 000 archives
-    Près de 11 000 ressources bibliographiques
-    Environ 40 000 visiteurs uniques par mois sur le site internet

Des améliorations continues

Trois ans plus tard, Paris Musées et Axess Open Web Services travaillent toujours ensemble afin d’améliorer sans cesse le parcours utilisateur tant d’un point de vue ergonomique que technique : « L’avantage d’Axess Open Web Services c’est son organisation projet, sa réactivité, sa réelle disponibilité au niveau des ateliers et son immersion complète dans la culture de notre institution. Cela leur permet de comprendre parfaitement nos enjeux et nos contraintes » indique Philippe Rivière.

Télécharger l'étude de cas

 

Le saviez-vous ?

Paris Musées est une institution publique administrative créée en janvier 2013. Elle rassemble les 12 musées municipaux de la ville de Paris et 2 sites archéologiques.
http://www.parismusees.paris.fr/fr
http://parismuseescollections.paris.fr/fr

Gérer proprement vos modules

jcisio
29/09/2013
Dans cet article, je présente une approche pour ranger les fonctions dans votre module en utilisant la programmation orientée objet (OOP). Cela n'a par contre rien à voir avec Drupal 8.

Dans cet article, je présente une approche pour ranger les fonctions dans votre module en utilisant la programmation orientée objet (OOP). Cela n'a par contre rien à voir avec Drupal 8.

Traditionnellement, dans un module, toutes les fonctions sont préfixées par le nom du module et présente dans le fichier ton_module.module. Ça fait un gros fichier ! Même si Dries a dit qu'il ne voyait pas de problème avec un fichier .module de 100 Ko, aujourd'hui on a la tendance de faire des petits fichiers ton_module.*.inc, chacun a une responsabilité unique. Pour utiliser une fonction dans ces fichier :

  • soit on met une require_once au début du fichier .module ;
  • soit on chaque fois on a besoin d'une fonction, on commence par module_load_include() ;
  • soit on charge le fichier automatiquement (le cas avec hook_menu(), hook_theme() etc.).

Si vous travaillez avec Drupal depuis un peu de temps, vous devriez connaître tout cela. Mais si on veut aller plus loin, on peut mettre les fonctions dans des classes sous forme des méthodes statiques. Les avantages sont :

  • autoload de toutes les classes ;
  • et l'utilisation propre de l'espace de nom.

Pour l'autoload, vous pouvez mettre classiquement les fichiers dans le .info dans les lignes files[] = ..., ou bien vous écrivez votre propre class loader si vous êtes trop paresseux pour modifier les fichiers .info, sinon vous pouvez en récupérer un avec Google.

Pour l'espace de nom, ce n'est pas forcément la vraie nouvelle fonctionalité du PHP 5.3 (car il arrive que vous utilisez encore la version 5.2), mais le nom de classe. Vous n'avez pas besoin de préfixer les méthodes dans vos classes. Votre intélligent IDE (vim l'est aussi) pourra avoir des suggestions plus pertinentes. Exemple : vous travaillez sur un projet "vous", avec 20 modules "vous_module1", "vous_module2"..., dans chaque module vous avez des fonctions vous_module1_fonction1, vous_module1_fonction2... et vous tapez "vous" votre IDE va suggérer 10 fonctions qui sont tous dans le premier module vous_module1. Pas très pertinent. Avec les classes séparées, votre IDE présente d'abord des classes, puis les méthodes quand vous complétez le nom de classe. Plus pratique !

Les méthodes enveloppées dans des classes ne pollue pas le scope global, elles aident aussi pour le refactoring ou le protypage ou le test. Mais l'article est trop long, donc j'arrête. Quand même, avant, pour l'info, ce paradigme est utilisé récemment dans Drupal 7 avec la classe FieldInfo (par yched et al.) et c'est très bien. Il n'y a alors pas de raison pour ne pas l'utiliser.

PS : un article sans code, mais allo quoi.

ton_module.inc

function ton_module_faire_1() {} function ton_module_faire_2() {}

sera :

TonModule.php

class TonModule { public static function faire_1() {} public static function faire_2() {} }