PROSA — la maquette Figma et le site web
J'ai tenu la maquette et le site de PROSA, le jeu de plateau narratif du BUT3 MMI : trois versions dans Figma avant d'arrêter l'arborescence, puis l'intégration et la mise en ligne sur prosa.mmitoulon.fr. Un site qui tient debout, avec un défaut d'accessibilité que je sais nommer.
Contexte
PROSA, c'est un jeu de plateau narratif conçu par trente étudiants du BUT MMI. Le principe : un plateau physique doublé d'une couche en réalité augmentée, sur un univers construit à partir des mythes et légendes de Corte et de la Provence. Le sous-titre du jeu, « le serpent à sept têtes », donne le ton — post-apocalyptique, sombre, coopératif. Deux tables jouent ensemble, une à Toulon, une en Corse, et elles doivent s'allier pour affronter l'organisation Prosa.
Sur ce projet, je ne me suis pas occupé du jeu. Je me suis occupé de sa vitrine. Le plan de communication qu'on avait écrit en amont désignait une landing page à peu près à chaque page : c'est elle qui devait recevoir le trafic des réseaux, elle qui devait porter les QR codes imprimés, elle qui devait renvoyer vers la précommande. Un des objectifs SMART visait 1 200 visites par mois sur cette page pendant les 90 premiers jours, un autre 250 précommandes en 120 jours. Autrement dit, tout le dispositif de communication reposait sur une page qui n'existait pas encore. Il fallait quelqu'un pour la faire.
Les contraintes étaient simples et pas négociables. Zéro budget, donc pas de licence, pas de nom de domaine acheté, pas d'hébergement payant — le département hébergeait, on serait en sous-domaine de mmitoulon.fr. Un semestre pour tout faire, en parallèle du reste de la SAÉ. Et un public cible jeune, 11-15 ans en cœur de cible, 15 ans et plus juste derrière, ce qui veut dire consultation majoritairement au téléphone et zéro tolérance pour une page qui met trois secondes à s'afficher.
Il y avait aussi une contrainte moins écrite mais bien réelle : la direction artistique du jeu était déjà là, forte, très identifiée, avec un logo en Futura dont le O est remplacé par un cercle contenant une tête de serpent. Le site ne pouvait pas partir dans une autre direction. Il devait ressembler au jeu, pas à un site d'école qui parle d'un jeu.
Démarche
Poser l'arborescence avant de dessiner quoi que ce soit
La première question n'était pas « à quoi ça ressemble » mais « combien de pages ». Le plan de com parlait de landing page au singulier, donc j'ai commencé par là : une page unique, longue, qui déroule tout. Ça paraissait cohérent avec un objectif de conversion — moins de clics entre l'arrivée et le bouton de précommande.
Sauf que le projet avait deux publics à servir en même temps, et ils ne cherchent pas la même chose. Un joueur veut savoir comment on joue, ce qu'il y a dans la boîte, à quoi ressemble le plateau. Un enseignant, un partenaire ou un institutionnel veut savoir qui a fait ça, dans quel cadre, avec quel sérieux. Les mettre sur la même page, c'est forcer chacun à scroller à travers le contenu de l'autre. J'ai tranché pour trois pages : l'accueil qui oriente, « le jeu » qui vend, « le projet » qui rassure.
Trois maquettes avant d'arriver à la bonne
Dans Figma, j'ai gardé les trois versions côte à côte plutôt que d'écraser au fur et à mesure. C'est le seul moyen de comparer honnêtement.
La v1 est la one-page pure. Hero avec la baseline « Ne jouez pas une histoire, écrivez la vôtre », puis « Un projet, deux cultures... », puis « ... et trois lieux atypiques » en trois cartes colorées, puis « Origines & Coulisses », puis les personnages jouables, puis une FAQ. Elle marche, mais elle est interminable et la FAQ arrive après quatre écrans que personne ne lira jusqu'au bout.
La v2 ajoute une barre de navigation fixe, un formulaire de contact et un bloc « Notre retour sur le projet » avec des photos de l'équipe. C'est mieux structuré, mais je me suis rendu compte en la maquettant que j'étais en train de fabriquer trois pages empilées dans une seule. Le formulaire de contact, en particulier, m'obligeait à prévoir un traitement côté serveur que je n'avais ni le temps ni l'hébergement pour faire proprement.
La v3 est celle qui est partie en ligne. J'ai éclaté en trois pages, supprimé le formulaire au profit d'une adresse mail affichée, et remonté le bouton de précommande dans le header sous la forme d'un « REJOINS L'AVENTURE » toujours visible. Chaque page a le même hero plein écran : image du jeu ou de l'équipe, logo PROSA centré en grand, un titre, un bouton. Ça donne un rythme identique d'une page à l'autre et ça m'a permis de réutiliser exactement le même bloc trois fois à l'intégration.
Le mobile maquetté séparément, pas déduit
J'ai fait une maquette mobile dédiée dans Figma au lieu de me dire que ça se débrouillerait tout seul. Elle n'est pas une réduction du desktop : la navigation passe en liste verticale ACCUEIL / LE JEU / L'ÉQUIPE, les deux cartes d'orientation de l'accueil s'empilent, les blocs Corte et Toulon qui étaient côte à côte passent l'un sous l'autre, et la galerie de personnages devient un carrousel avec pastilles plutôt qu'une grille. Le QR code, lui, gagne en taille sur mobile — ce qui est absurde si on y réfléchit, personne ne scanne un QR code avec le téléphone qui l'affiche, mais il sert aussi de visuel de partage.
Maquetter le mobile à part change l'intégration. Quand tu sais à l'avance qu'un bloc à deux colonnes doit devenir une colonne, tu écris la version mobile d'abord et tu ajoutes la deuxième colonne au-dessus d'un point de rupture. Quand tu ne le sais pas, tu passes ta soirée à rattraper des débordements horizontaux.
L'intégration : un gabarit, trois remplissages
Le site est statique, trois pages, rendu côté client. J'ai construit un en-tête unique — logo à gauche, deux liens au centre, bouton d'appel à l'action à droite sur fond noir — et je l'ai répété à l'identique sur les trois pages. Même chose pour le pied de page avec les logos institutionnels et la mention de copyright. Tout le travail d'intégration s'est donc concentré sur ce qui change entre les pages, c'est-à-dire le contenu et l'ordre des blocs.
Le hero est le morceau le plus délicat : image en fond, assombrie pour que le logo blanc et le texte restent lisibles, hauteur calée sur la fenêtre. Sur la page « le jeu », le fond est une photo du plateau entouré des cartes du jeu, avec les noms visibles — TARASQUE, CENTRALE ÉLECTRIQUE, PORTAIL DE PROSA, SIGNA DORA. Sur « le projet », c'est une photo de séance de travail devant un tableau blanc. Le contraste entre les deux dit ce que fait chaque page sans qu'on ait besoin de l'écrire.
Les images, et l'endroit où j'ai cédé
Voilà le point que je préfère annoncer moi-même plutôt que de le laisser trouver : une grande partie du texte du site est incrustée dans les images. Si on extrait le texte réel des pages, on récupère à peine plus que « PROSA, le serpent à sept têtes », les intitulés de navigation, « Commence l'aventure dès maintenant », « SCAN MOI ! », l'adresse de contact et le copyright. Tout le reste est du pixel.
Pourquoi ? Parce que les blocs sortaient de Figma avec des compositions typographiques précises, et qu'exporter la frame était infiniment plus rapide que de la reconstruire en CSS. À chaque bloc, j'ai fait le même arbitrage, et à chaque fois j'ai choisi la vitesse. Mis bout à bout, ces arbitrages individuellement raisonnables ont produit un site qu'un lecteur d'écran ne peut pas lire, qu'un moteur de recherche ne peut pas indexer et dont on ne peut pas sélectionner une ligne. C'est un vrai défaut, pas un détail de finition.
La mise en ligne
Le site est déployé sur prosa.mmitoulon.fr, un sous-domaine du domaine du département. Ce n'est pas un choix esthétique : passer par le sous-domaine de l'IUT évitait l'achat d'un nom de domaine, donnait le certificat HTTPS et rattachait visiblement le projet à l'établissement, ce qui compte quand on démarche des collectivités et des écoles. En contrepartie, on hérite d'une adresse qui dit « projet étudiant » avant même que la page charge — pour la page « le projet » c'est un atout, pour une page de précommande c'est plus discutable.
Le site sert de plaque tournante vers le reste du dispositif : la campagne Ulule pour la précommande, l'Instagram @prosa.mmi, le Linktree linktr.ee/project.prosa et l'adresse contact@prosa.fr. C'est exactement le rôle que le plan de communication lui assignait — recevoir les clics des réseaux et des QR codes imprimés, puis les renvoyer vers la conversion.
Résultats
Le site est en ligne à l'adresse https://prosa.mmitoulon.fr. Trois pages livrées et fonctionnelles : l'accueil, « le jeu », « le projet ». Navigation identique partout, bouton de précommande présent dans l'en-tête des trois pages, pied de page avec les logos institutionnels des deux départements MMI.
La chaîne de liens sortants est en place et vérifiable : Ulule pour la précommande, l'Instagram @prosa.mmi, le Linktree linktr.ee/project.prosa, l'adresse contact@prosa.fr, et un renvoi vers la fiche formation BUT MMI de l'université de Toulon. Le QR code affiché sur la page « le jeu » sous le libellé « SCAN MOI ! » relie le dispositif imprimé au web, ce qui était une demande explicite du plan de communication.
Côté maquette, trois versions complètes existent dans Figma, plus une maquette mobile dédiée. Elles ne sont pas des brouillons jetés : elles documentent le raisonnement qui va de la page unique à l'arborescence en trois pages, et je peux les montrer côte à côte pour expliquer pourquoi j'ai changé d'avis.
Ce que je ne peux pas chiffrer, et je préfère le dire. Je n'ai pas de relevé d'audience à présenter : pas de chiffre de sessions, pas de taux de clic vers Ulule, pas de nombre de précommandes. Aucun outil de mesure n'était branché sur le site quand il est parti en ligne, et je n'ai pas récupéré les statistiques d'hébergement après coup. Les objectifs SMART du plan de communication — les 1 200 visites mensuelles, les 250 précommandes — sont donc restés des cibles écrites, jamais confrontées à un relevé. C'est le trou le plus embêtant de cette réalisation, parce que c'est précisément ce qui aurait permis de dire si le site a fait son travail ou non.
Autre point resté ouvert : au moment où j'écris, le lien Ulule du site renvoie sur l'accueil de la plateforme et non sur une page de campagne. Soit la campagne n'a pas été mise en ligne, soit le lien s'est cassé. Je ne sais pas laquelle des deux, et je n'irai pas inventer un montant collecté.
Ce que j’en retire
Auto-évaluation
Ce que je retiens en premier, c'est d'avoir compris à quoi sert vraiment une phase de maquette. Avant, je maquettais pour avoir une image à montrer. Là, la v1 et la v2 ont servi à éliminer des idées : c'est en dessinant la one-page que j'ai vu qu'elle était trop longue, et c'est en plaçant le formulaire de contact de la v2 que j'ai réalisé que je n'avais pas de quoi le traiter. Ces deux versions n'ont pas été perdues, elles ont évité deux erreurs à l'intégration. Un jour de maquette vaut trois jours de code jeté.
Le deuxième apprentissage porte sur le mobile. Je l'ai maquetté séparément au lieu de le déduire du desktop, et ça a complètement changé l'ordre dans lequel j'ai écrit les styles. Partir de la version étroite et ajouter les colonnes ensuite, c'est plus simple que l'inverse — je le savais en théorie depuis le BUT1, je l'ai vraiment intégré ici.
Le troisième, c'est le rapport entre une contrainte technique et une décision de communication. Le sous-domaine mmitoulon.fr n'était pas juste un raccourci gratuit d'hébergement. Il change ce que le site raconte de lui-même. Pour convaincre un collège ou un office de tourisme, il rassure. Pour vendre une boîte à un joueur de 16 ans, il fait scolaire. J'ai accepté le compromis parce que la cible institutionnelle pesait lourd dans le plan de communication, mais je l'ai accepté en connaissance de cause, pas par défaut.
Et puis j'ai aimé travailler sous une direction artistique déjà posée. Le logo en Futura avec le O remplacé par le cercle à tête de serpent est un très bon repère : il est reconnaissable en tout petit dans le header comme en très grand au centre d'un hero, et il m'a donné la palette et le niveau de contraste à tenir. Contrairement à ce que je pensais, la contrainte m'a fait gagner du temps au lieu de m'enfermer.
Auto-critique constructive
Le texte dans les images, c'est ma faute et je ne vais pas la faire porter au projet. À chaque bloc, j'ai eu le choix entre exporter la composition Figma en image en deux minutes ou la refaire en HTML et CSS en une heure, et j'ai choisi l'export à peu près à chaque fois. Pris isolément, l'arbitrage se défend quand on est en fin de semestre. Empilé sur toute la longueur du site, il produit une page qu'un lecteur d'écran traverse en silence, qu'un moteur de recherche ne peut pas indexer, et dont personne ne peut copier une phrase. Pour un projet dont un objectif affiché était le référencement naturel, c'est une contradiction directe entre ce qu'on avait écrit dans le plan de com et ce que j'ai livré.
Si je le refaisais, je poserais une règle simple avant de commencer : aucun texte en image, sauf logo. Les titres partent en HTML avec Futura chargée en webfont, les fonds restent des fonds. Ça coûte du temps au début et ça en fait gagner ensuite, parce que corriger une faute de frappe redevient une modification de texte au lieu d'un aller-retour dans Figma, export, réoptimisation, remplacement du fichier.
Le deuxième reproche que je me fais, c'est l'absence totale de mesure. Brancher un outil d'analyse d'audience prend un quart d'heure. Je ne l'ai pas fait, et le résultat c'est que j'arrive devant vous avec un site en ligne et pas une seule donnée pour dire s'il a servi à quelque chose. Sur un projet où toute l'équipe avait écrit des objectifs chiffrés, c'est le maillon manquant. J'ai construit l'outil sans construire le thermomètre.
Troisième point, les liens. Le renvoi vers Ulule pointe sur l'accueil de la plateforme, pas sur une page de campagne. Que la campagne n'ait pas été publiée ou que le lien se soit cassé, le résultat est le même côté visiteur : il clique sur « Précommander le jeu » et il atterrit nulle part. J'aurais dû mettre en place une vérification des liens sortants après la mise en ligne, ne serait-ce qu'une relecture manuelle par mois. Un site vitrine n'est pas fini le jour où il est déployé.
Enfin, j'aurais dû faire tester les trois pages par deux ou trois personnes de la cible réelle avant de publier, plutôt que de valider entre nous. On était tous dedans depuis des mois, on savait ce que voulaient dire les visuels. Un ado de 14 ans qui arrive de TikTok, lui, ne le sait pas.
Continuité et développement personnel
Ce site est la première chose que j'ai livrée en production avec l'idée qu'elle serait vue par des gens extérieurs à l'IUT — des parents, des enseignants, d'éventuels partenaires. Ça change le niveau d'exigence, et ça m'a surtout appris que le vrai travail commence après la mise en ligne. Un lien qui casse, une statistique qu'on n'a pas relevée, un contenu qu'on ne peut plus modifier sans rouvrir un fichier de design : ce sont des problèmes de maintenance, pas de création, et je ne les avais jamais rencontrés avant.
La leçon sur le texte en image, je l'ai appliquée immédiatement ailleurs. Sur les projets que j'ai menés depuis, je pars du principe que tout ce qui se lit doit exister en texte, quitte à passer plus de temps sur la mise en page. Le portfolio que vous consultez en ce moment est construit sur cette règle, en partie à cause de PROSA.
Le travail sur les trois maquettes m'a aussi donné une méthode que je réutilise : garder les versions abandonnées côte à côte au lieu de les écraser. Quand il faut expliquer un choix à un commanditaire ou à un jury, montrer ce qu'on a écarté vaut mieux que d'argumenter dans le vide sur ce qu'on a gardé.
Sur le plan des compétences, cette réalisation fait la jonction entre la partie stratégie de PROSA — la SAÉ 5.Strat-UX.01, où on avait défini les cibles, les piliers éditoriaux et les objectifs — et sa mise en œuvre technique. C'est le moment où le plan de communication cesse d'être un document et devient une adresse qu'on peut taper dans un navigateur. C'est aussi ce qui m'a convaincu que je ne veux pas choisir entre concevoir et développer : la valeur, pour moi, est dans le fait de tenir les deux bouts.
Visuels
Compétences mobilisées
6 apprentissage(s) critique(s) rattaché(s) à cette réalisation.
Concevoir un produit ou un service en termes d'usage et de fonctionnalité
ConcevoirJ'ai commencé par déterminer ce que le site devait faire, pas à quoi il devait ressembler. Le plan de communication parlait d'une landing page unique, orientée conversion, et j'ai maquetté cette hypothèse en premier — c'est la v1. En la construisant, j'ai identifié le problème d'usage : le site devait servir deux publics aux besoins incompatibles, un joueur qui cherche les mécaniques et le contenu de la boîte, et un prescripteur — enseignant, parent, partenaire, collectivité — qui cherche à savoir qui a fait ça et dans quel cadre. Sur une page unique, chacun doit traverser le contenu destiné à l'autre avant d'atteindre le sien. J'ai donc reconfiguré l'arborescence en trois pages avec un rôle fonctionnel distinct : l'accueil oriente et ne fait que ça, « le jeu » répond à l'usage joueur, « le projet » répond à l'usage prescripteur. La fonctionnalité de conversion, elle, a été extraite des pages pour être remontée dans l'en-tête permanent sous forme du bouton « REJOINS L'AVENTURE », de sorte qu'aucun visiteur ne dépende de sa position dans le scroll pour précommander.
Produire des pages Web fluides incluant un balisage sémantique efficace et des interactions simples
DévelopperJ'ai intégré les trois pages autour d'un gabarit commun : un en-tête identique répété partout — logo, deux liens de navigation, bouton d'appel à l'action sur fond noir — et un pied de page unique avec les logos institutionnels et la mention de copyright. Le seul contenu qui change d'une page à l'autre est le corps, ce qui rend la maintenance possible et garantit qu'un visiteur retrouve le bouton de précommande au même endroit sur les trois pages. Les interactions sont volontairement simples et je les assume comme telles : navigation entre les pages, défilement fluide, états de survol sur les cartes d'orientation, carrousels de photos sur le mobile. Là où cet AC n'est pas atteint, c'est sur le balisage sémantique, et je préfère le dire moi-même : une grande partie du texte est incrustée dans les images, si bien qu'en extrayant le texte réel du site on ne récupère guère plus que le titre, les intitulés de navigation, le libellé « SCAN MOI ! », l'adresse de contact et le copyright. Je peux nommer précisément la cause — l'export de frame Figma choisi contre la reconstruction en CSS, bloc après bloc, sous pression de calendrier — et la conséquence : illisible au lecteur d'écran, non indexable, non sélectionnable. C'est cette capacité à localiser exactement où la sémantique décroche et pourquoi qui constitue ma preuve, plus que le résultat livré.
Mettre en ligne une application Web en utilisant une solution d'hébergement standard
DévelopperLe site est en ligne et consultable à l'adresse https://prosa.mmitoulon.fr, ce qui est la seule preuve qui vaille pour cet AC : une URL qui répond. J'ai choisi de passer par un sous-domaine du domaine du département MMI plutôt que d'acheter un nom de domaine, et ce n'était pas seulement une question de budget nul. Le sous-domaine fournissait l'hébergement et le certificat HTTPS sans démarche d'achat, et il rattachait visiblement le projet à l'établissement, ce qui pesait dans un dispositif qui devait convaincre des collèges, des offices de tourisme et des collectivités. J'ai accepté en connaissance de cause le revers : une adresse qui annonce « projet étudiant » avant même le chargement de la page, ce qui rassure la cible institutionnelle mais dessert la page de précommande auprès d'un joueur. Le site déployé remplit ensuite le rôle de plaque tournante que lui assignait le plan de communication, en renvoyant vers la campagne Ulule, l'Instagram @prosa.mmi, le Linktree et l'adresse de contact.
Produire des pages et applications Web responsives
DévelopperJ'ai produit une maquette mobile dédiée dans Figma au lieu de laisser le desktop se réduire tout seul, et les décisions de réorganisation ont été prises dans la maquette avant d'être intégrées. Concrètement : la navigation horizontale du header devient une liste verticale ACCUEIL / LE JEU / L'ÉQUIPE, les deux cartes d'orientation de l'accueil s'empilent au lieu d'encadrer le bouton central, les blocs Corte et Toulon passent de deux colonnes à une, et la grille des personnages jouables se transforme en carrousel à pastilles parce qu'une grille de six vignettes est illisible en 375 pixels de large. Savoir à l'avance quels blocs changent de disposition m'a permis d'écrire les styles en partant de la version étroite et d'ajouter les colonnes au-delà d'un point de rupture, plutôt que de rattraper des débordements horizontaux après coup. Le choix du responsive n'était pas cosmétique ici : le cœur de cible du jeu a entre 11 et 15 ans et arrive par Instagram et TikTok, donc au téléphone. Un site qui aurait obligé à zoomer aurait annulé l'intérêt des QR codes imprimés et du trafic réseaux prévus au plan de communication.
Co-construire un produit ou service de manière itérative (ateliers de créativité, idéation, définition de l'expérience utilisateur, exploitation des résultats de test)
ConcevoirTrois maquettes complètes existent dans Figma, conservées côte à côte plutôt qu'écrasées les unes par les autres, et chacune a servi à éliminer une idée. La v1 est la page unique intégrale : elle m'a montré que la FAQ arrivait après quatre écrans que personne n'atteindrait. La v2 ajoute une navigation fixe, un formulaire de contact et un bloc de retours d'expérience de l'équipe : elle m'a fait voir que je fabriquais en réalité trois pages empilées dans une seule, et que le formulaire supposait un traitement serveur que l'hébergement ne me donnerait pas. La v3, celle qui est partie en ligne, tire les conclusions des deux précédentes — éclatement en trois pages, suppression du formulaire, remontée de l'appel à l'action dans le header, hero plein écran identique sur chaque page pour donner un rythme commun et pour me permettre de réutiliser le même bloc trois fois à l'intégration. Ce que je démontre ici n'est pas d'avoir fait trois versions, mais d'être capable de dire ce que chacune a servi à écarter. Les deux premières n'ont pas été perdues : elles ont évité deux erreurs qui auraient coûté bien plus cher une fois le code écrit.
Maîtriser l’hébergement et le déploiement d’applications
DévelopperDéployer sur un sous-domaine institutionnel n'a rien à voir avec déposer des fichiers sur un hébergement qu'on contrôle : je n'étais pas administrateur du domaine, donc j'ai dû cadrer ma demande à l'avance et livrer quelque chose de compatible avec l'existant plutôt que d'adapter le serveur à mon site. Ça m'a obligé à concevoir un site statique multi-pages, sans traitement côté serveur — c'est précisément ce qui a fait disparaître le formulaire de contact prévu à la maquette v2 au profit d'une adresse mail affichée en clair, parce que je n'avais aucune garantie de pouvoir traiter un envoi de formulaire. Ce genre d'arbitrage se prend au moment de la conception, pas au moment de la mise en ligne, sinon on découvre trop tard que la maquette validée n'est pas déployable. J'ai aussi mesuré après coup ce que je n'avais pas maîtrisé : aucun outil de mesure d'audience branché au déploiement, aucune vérification périodique des liens sortants, et un renvoi Ulule qui aujourd'hui pointe sur l'accueil de la plateforme au lieu d'une page de campagne. Un déploiement ne s'arrête pas à la première réponse HTTP du serveur, et c'est cette réalisation qui me l'a appris.