Outil web de briefing client et optimisation du site — Mad in Event
Développement d'un outil web de briefing client en plusieurs étapes, et optimisation technique du site de l'agence : référencement, performances et expérience utilisateur.
Contexte
Deux besoins techniques chez Mad in Event : recueillir les besoins d'un client de façon structurée plutôt que par échanges dispersés, et améliorer un site WordPress dont le référencement et les performances plafonnaient.
Démarche
Développement d'un outil web de briefing client en HTML, CSS et JavaScript : une interface en plusieurs étapes, avec formulaires et liens de contact.
Correction des bugs d'affichage et mise au point du responsive, avec tests sur plusieurs navigateurs.
Intégration et maintenance de pages sous WordPress avec Elementor.
Optimisation technique du site : balises, vitesse de chargement, maillage interne, restructuration des pages.
Analyse du trafic via Search Console et les outils analytics, pour orienter les corrections.
Résultats
Un outil de briefing fonctionnel et utilisé, un site restructuré et plus rapide, et une compréhension mesurée du lien entre performance technique, référencement et expérience utilisateur.
Le problème que l’outil devait résoudre
Il n’existait aucun outil de qualification en amont d’un rendez-vous. Un prospect appelait, un rendez-vous physique était fixé, et le brief se construisait oralement pendant cette rencontre.
En observant les dossiers, j’ai identifié une conséquence précise : une part importante des prospects arrivait en rendez-vous sans savoir précisément ce qu’elle voulait — ni budget arrêté, ni date ferme, ni nombre d’invités, ni objectif formulé. Le rendez-vous se consommait alors à faire émerger le besoin, et aucune proposition commerciale sérieuse ne pouvait être construite.
Pour une entreprise dont le dirigeant est aussi le seul commercial, chaque rendez-vous improductif se paie en temps qui n’existe pas ailleurs. Et la prise de rendez-vous elle-même ne reposait sur aucun outil : les prospects appelaient directement Matthieu Irles.
Il y avait un enjeu structurel derrière : la communication intervient tout à la fin du cycle de production événementiel. Concevoir un outil qui intervienne avant le brief, à l’entrée de la chaîne, était la seule manière de la déplacer de la fin vers le début du cycle.
La conception, et le choix d’une application autonome
La conception
L’outil prend la forme d’une application web dans laquelle le prospect répond à un questionnaire guidé, construit comme un parcours progressif plutôt que comme un formulaire unique, de manière à l’amener à formaliser l’intégralité de son besoin sans qu’il ait l’impression de remplir un dossier. La cible visée était principalement corporate.
La sortie est double, et c’est ce qui fait l’intérêt du dispositif. Côté agence : un brief complet, les coordonnées du prospect et son créneau de contact préféré, ce qui permet d’ouvrir le rendez-vous directement sur la proposition plutôt que sur la découverte. Côté prospect : un brief structuré et enrichi automatiquement, qu’il peut présenter en interne à sa propre direction — c’est-à-dire un document qui lui sert à obtenir son propre budget. Faire travailler l’outil pour le prospect était la condition pour qu’il accepte d’y consacrer dix minutes.
La technique, et comment je m’y suis pris
HTML, CSS et JavaScript, hébergée chez IONOS, et entièrement distincte du site de l’agence. Mad In Project n’est pas une extension de WordPress mais une application autonome. Ce choix était délibéré : greffer un parcours de questionnaire enrichi sur un thème WordPress existant aurait supposé de composer avec ses contraintes pour un bénéfice nul, puisque l’outil s’adresse à des prospects et non à des lecteurs du site.
Le développement a été mené avec l’assistance d’une intelligence artificielle, selon la même méthode que mes scripts Python : je spécifie, je fais produire, je lis, je corrige. C’est ce qui m’a permis de couvrir seul l’ensemble de la chaîne — interface, logique de parcours et traitement en sortie — alors que je n’ai pas de formation de développeur. Je ne présente pas ça comme une prouesse technique, mais comme une manière de travailler qui élargit réellement ce qu’un profil de communication peut entreprendre, à condition d’en accepter la contrepartie : on ne maîtrise bien que ce qu’on est capable de relire.
L’intégration de traitements par intelligence artificielle pour l’enrichissement du brief était un sujet sur lequel je n’avais aucune formation. Autoformation complète, ressources en ligne et tutoriels : personne dans l’entreprise ne pouvait m’accompagner sur ce terrain.
Où en est le projet
L’application n’est ni terminée, ni en ligne, ni en production, et aucun brief n’a été traité avec. Je le présente comme tel.
Ce qui existe : le diagnostic, la conception du parcours, une interface développée, et une documentation de passation. J’ai assuré la passation du projet à l’alternant qui me succède. Il en poursuit le développement.
Ce que j’en retire
Auto-évaluation
Ce projet m’a fait apprendre en dehors de tout cadre : le développement de l’interface, et surtout l’intégration de traitements par IA, sujet sur lequel je partais de zéro. C’est aussi celui qui m’a le plus fait réfléchir à ma façon de travailler avec un assistant de code — spécifier, faire produire, relire, corriger — et à ce que cette méthode permet et ne permet pas.
Auto-critique constructive
Ne pas avoir mené ce projet à son terme est le regret le plus net de mon année.
Trois causes se cumulent, et aucune ne relève de la difficulté technique. La disponibilité : un projet de fond ne se développe pas par tranches de deux heures arrachées entre deux urgences, et je n’ai jamais disposé d’une période protégée. La hiérarchie des priorités : entre un catalogue à sortir avant un salon et un outil qui produira ses effets dans six mois, l’arbitrage se fait toujours en faveur du premier — et cet arbitrage est rationnel du point de vue de l’entreprise. La troisième m’incombe entièrement : j’ai dimensionné le périmètre sur ce que le projet devait idéalement faire, et non sur le temps dont je disposais réellement.
L’enseignement est utilisable immédiatement : dans un contexte contraint, la question qui décide du sort d’un projet n’est pas « qu’est-ce que cet outil devrait faire ? » mais « quelle est la plus petite version de cet outil qui produirait déjà un effet ? ». Un questionnaire en cinq questions, mis en ligne au bout d’un mois et amélioré ensuite, aurait produit des briefs réels dès l’automne. Le parcours complet avec enrichissement automatique n’en a produit aucun. Le diagnostic était juste, la conception tenait ; c’est le dimensionnement qui était faux, et c’est exactement l’erreur qu’un environnement scolaire ne permet pas d’apprendre, parce qu’un projet pédagogique a des bornes de temps garanties que l’entreprise ne garantit jamais.
Compétences mobilisées
4 apprentissage(s) critique(s) rattaché(s) à cette réalisation.
Produire des analyses statistiques descriptives et les interpréter
ComprendreLe point de départ n’est pas une commande mais un diagnostic que j’ai posé en observant les dossiers : une part importante des prospects arrivait en rendez-vous sans budget arrêté, sans date ferme, sans nombre d’invités ni objectif formulé. Le rendez-vous se consommait alors à faire émerger le besoin, et aucune proposition sérieuse ne pouvait être construite. Pour une entreprise dont le dirigeant est aussi le seul commercial, chaque rendez-vous improductif se paie en temps qui n’existe pas ailleurs. J’ai relié ce constat à un problème structurel : la communication intervient à la fin du cycle de production, et un outil placé à l’entrée était la seule façon de la déplacer vers le début.
Proposer une recommandation marketing (cibles, objectifs, points de contact)
ConcevoirLa conception repose sur un parcours progressif plutôt que sur un formulaire unique, pour amener le prospect à formaliser son besoin sans avoir l’impression de remplir un dossier. La décision qui structure tout est celle de la double sortie : côté agence un brief complet avec coordonnées et créneau de contact, côté prospect un brief structuré et enrichi qu’il peut présenter à sa propre direction pour obtenir son budget. Faire travailler l’outil pour l’utilisateur était la condition pour qu’il accepte d’y consacrer dix minutes.
Développer à l’aide d’un framework de développement côté serveur
DévelopperJ’ai développé l’application en HTML, CSS et JavaScript, hébergée chez IONOS, délibérément autonome et non greffée sur le WordPress de l’agence — composer avec les contraintes d’un thème existant n’aurait apporté aucun bénéfice pour un outil qui s’adresse à des prospects, pas à des lecteurs du site. J’ai également intégré des traitements par intelligence artificielle pour l’enrichissement du brief, en autoformation complète. Ma méthode de travail avec un assistant de code est explicite : je spécifie, je fais produire, je lis, je corrige — en assumant que l’on ne maîtrise bien que ce que l’on est capable de relire.
Défendre un projet de manière convaincante
EntreprendreL’échec de ce projet est instructif et je l’expose comme tel : l’application n’est ni terminée, ni en ligne, et aucun brief n’a été traité avec. Trois causes, dont une qui m’incombe entièrement — j’ai dimensionné le périmètre sur ce que l’outil devait idéalement faire et non sur le temps dont je disposais. La règle que j’en tire est opérationnelle : dans un contexte contraint, la question n’est pas « qu’est-ce que cet outil devrait faire » mais « quelle est la plus petite version qui produirait déjà un effet ». J’ai assuré la passation documentée à mon successeur, qui en poursuit le développement.