Dans le cadre du travail d’intégration qui s’inscrit dans la liste des modules de validation de notre dernier semestre de Bachelor en ingénierie des médias, le corps professoral a choisi de nous faire vivre l’expérience de réalisation d’un produit média pour un client réel, le Musée suisse de l’appareil photographique.
Notre mandant désirait créer de la visibilité et de l’attrait pour le musée auprès du grand public de façon large dans le but d’amener des visiteurs payants au musée. L’audience était à définir ou à recommander. Après une visite concrète du musée et des discussions avec le mandant pour bien cerner son besoin, l’étape suivante de l’exercice était de réfléchir à des idées de solution en groupe ou individuellement, ces dernières
ont été présentées au comité de validation composé du mandant et des professeurs chargés du suivi de ce travail. Deux étapes d’élimination d’idées ont été réalisées avant d’en extraire deux projets à réaliser par
deux grandes équipes qui ne font pas partie forcément du noyau de base qui l’a émis.
L’idée de l’équipe dont j’ai fais partie porte le nom de Camera Quest. En scannant un code QR, le visiteur du musée sera accompagné durant sa visite par une nouvelle forme de guide audio, une web application. Il lui suffira de prendre en photo l’un des objets exposés pour voir afficher une description de l’objet et un enregistrement audio qui le présente.
Camera Quest a vu se réunir 15 étudiants-es pour travailler sur ce projet. Afin de créer une équipe de projet efficace et permettant de fournir des résultats tangibles rapidement. Au vu de notre nombre, nous savons décidé de travailler en utilisant la méthodologie Scrum en méthode Agile.
Membres de l’équipe
Gestion de projet
- Lionel Urfer – Product owner
- Sébastien Wagnières – Scrum master
Pôle design
- Alexandre Roulet
- Kevin Paiva Oliviera
- Jade Perroset
- Larry Lam
Pôle développement
- Nathan Fourel
- Thomas Robert
- Mikaël Ruffieux
- Robin Zweifel
- Louka Najjar
Pôle contenu
- Kiliak Crettaz
- Yousra Boumasmoud
- Camille Schaller
- Leyla Benkais
- Lionel Urfer
Gestion de projet
Organisation
La méthodologie Scrum n’ayant pas fait partie de notre plan de formation, le Product Owner et le Scrum Master ont assimilé et mis en place les bases de la méthode en l’espace de trois jours. Il a été choisi de découper l’équipe en 3 départements (Développement, Design et Contenu) de 4 à 6 membres et d’y attribuer à chacun un team leader. Cela permettait ainsi de rester efficace et réactif afin d’éviter de rencontrer des difficultés de coordination et de communication impactant ainsi sa rapidité et son agilité.
Noyau pédagogique
Celui-ci est constitué de trois professeurs de la HEIG-VD du filière Ingénierie des Médias. A l’externe de celui-ci, des professeurs de la filière désignés officient comme experts dans leur domaine de compétence dans l’évaluation du projet et comme support.
Mandant
Le Musée suisse de l’appareil photographique, Vevey

Déroulement


Durant les trois semaines et demie du projet ont été rythmées par plusieurs phases :
1. Phase de Kick-off
- Définition des profils par étudiant-e-s
- Division de l’équipe en 3 sous-groupes
- Réunion Kick-off
2. Création de 3 Sprints
Lors de la création du Product Backlog, les tâches essentielles furent planifiées et introduites parmi 3 différents Sprints. Dû à la courte durée du projet, il fut crucial de définir des sprints de courtes durées afin d’éviter tout détournement involontaire majeur de l’objectif final.
2.1. Sprint 1
Phase 1
Objectif d’effectuer l’analyse et la définition du périmètre de l’application par : la conception de plusieurs benchmarks, une étude de marché et un sondage utilisateur pour l’univers audio de celle-ci ; effectuer les choix et tests technologiques ; définition de la taxonomie et de l’ontologie de l’application.
Phase 2
Initiation de l’environnement de développement dont la modélisation de la base de données, la formation sur les technologies choisies, la conception d’un prototype de basse fidélité ainsi que la détermination du public cible de l’application.
2.2. Sprint 2
Début de l’initialisation du développement de l’application avec pour objectif : l’écriture de la ligne éditoriale et des premières oeuvres ; l’écriture, l’enregistrement et le montage du premier podcast de l’univers audio ; la création et du test d’une maquette haute-fidélité ; développement des fonctionnalités essentielles à l’application.
2.3. Sprint 3
Les objectifs de ce troisième et dernier sprint furent : la continuité et la finalisation du développement avec le déploiement de l’application ; la réalisation des podcasts pour l’ensemble des objets choisis ainsi que la traduction des textes ; la préparation de la remise des ensembles des livrables aux différentes parties prenantes ; ainsi que la conception de la présentation finale au mandant. Il est à souligner que dans le cadre de ce sprint, une réattribution de deux ressources du département design fut déployée dans le département développement. Ceci a été particulièrement bénéfique car ils ont fait office d’ambassadeur du département design au sein du département développement pour répondre aux éventuelles interrogations.
3. Sprint review et retrospective
Comme chaque sprint avait une durée particulièrement courte, il était essentiel d’effectuer à chaque fin de sprint un point global pour l’ensemble de la Scrum team. Cela permettait ainsi de terminer la semaine en ayant connaissance de l’ensemble du travail ayant été conclu durant le sprint, de féliciter l’ensemble des parties prenantes de la Scrum team pour en recommencer un nouveau de la bonne manière la semaine suivante.
4. Retour au noyau pédagogique
La gestion de projet rendait compte de l’avancée du projet au noyau pédagogique, composé pour rappel de trois professeurs de la HEIG-VD en Ingénierie des Médias.
5. Retour au mandant
Deux réunions ont eu lieu auprès du Musée suisse de l’appareil photographique afin de leur présenter le travail accompli :
- La première prit place lors de la première semaine du projet afin d’exposer au mandant le public cible défini ainsi que la direction que le projet prit.
- La deuxième prit place au début de la troisième semaine du projet en proposant au mandant un essai de la maquette fonctionnelle de l’application ainsi que l’une des versions de l’univers audio choisit.
6. Daily Scrum
Une réunion de 15 minutes s’est tenu chaque jour ouvré entre le Scrum Master, le Product Owner et les Team Leader de chaque département afin d’inspecter la progression du sprint en cours et de prendre connaissance des potentiels points bloquants.
7. Gestion des priorités
Créer une application de cette envergure en un délai aussi court fût optimiste et afin de satisfaire à la livraison du prototype fonctionnelle des décisions ont dû être prises. Pour n’en citer que quelques-unes : L’application fût conçue en seulement deux langues, le français et l’anglais, sur les trois premièrement définies (dont l’allemand). Il a cependant été choisi d’abandonner cette dernière dont la traduction des podcasts au vu du temps à disposition ; l’autre décision fût de prioritiser le développement sur la partie utilisateur de l’application au lieu de la partie administrateur (voir section du département développement).
Pôle design
Après s’être mis d’accord sur les éléments organisationnels du département, nous avons entamé une première phase durant laquelle tous les membres étaient impliqués pour définir les éléments de base dont nous avions besoin pour aller plus loin et qui sont les suivants :
- User journey map: Nous avons brainstormé sur plusieurs solutions en interne avant de faire une première esquisse et de la partager avec les autres équipes et valider la version finale.
- Benchmark: Nous avons effectué un exercice de recherche et de veille graphique pour alimenter notre inspiration avec bonnes et moins bonnes pratiques.
- Moodboard: Nous l’avons réalisé en se basant sur le public cible que le département « contenu » a déterminé.

La deuxième phase était principalement une phase de réalisation d’éléments à livrer au département développement. Voici les sous-étapes de cette dernière :
- Wireframe: Nous avons d’abord déterminé en détail la taxonomie et la liste des fonctionnalités par page. Ensuite, nous sommes passés à la phase de conception d’ontologie avant de réaliser l’architecture du site et de déterminer le zoning pour la validation du layout. Une fois toutes ces étapes validées, nous avons pu créer les wireframes pour avoir une représentation graphique du concept. La livraison des wireframes aux développeurs a été effectuée en plusieurs étapes au fur et à mesure de son avancement.
- Maquettage et prototype interactif: Dans le but de préparer un prototype interactif le plus parlant possible pour les tests utilisateurs et pour aider les développeurs, nous avons construit notre design system et réaliser des maquettes digitales de la partie admin et de l’application.
- Tests utilisateurs : Nous avons finalement réalisé des tests utilisateurs afin de tester le résultat et d’avoir un feedback concret et apporter les dernières modifications aux maquettes. Nous souhaitions effectuer davantage de tests avant d’arriver à ce stade, mais par manque de temps, nous avons dû raccourcir le programme.
Au fur et à mesure de notre avancement, nous nous sommes rendu compte des limitations de l’application, que nous avons partagé avec les autres départements et auxquels nous avons prévu une série de solutions physiques (pancartes, affiches, etc.) dont nous avons réalisé les visuels dans la dernière phase du projet.
Maquettes
