Ma fille assistait à un concert à Forest National, ce qui me laissait quelques heures à passer à Bruxelles.
Le plan était simple : trouver un cinéma, bien manger à proximité et organiser les deux de manière suffisamment efficace pour tenir compte de la voiture, du parking et de la marche.
Bruxelles offrait de nombreux regroupements possibles.
Ce qu’elle offrait beaucoup moins systématiquement, c’était de la clarté.
Le premier restaurant que j’ai envisagé disposait uniquement d’un site en français. Ce n’était pas un obstacle insurmontable. Je parle et je lis couramment le français.
Mais une question étonnamment persistante s’est tout de même imposée :
En tant que visiteur néerlandophone à Bruxelles, pourrais-je aussi obtenir quelques informations dans ma propre langue ?
Un restaurant de burgers situé près d’un cinéma semblait constituer une alternative pratique, mais les informations disponibles en ligne ne permettaient pas de comprendre facilement où se trouvait exactement le restaurant ni quelle page correspondait à cet établissement. J’ai ensuite consulté plusieurs autres sites. Certains étaient incomplets dans la langue sélectionnée. D’autres rendaient des informations de base plus difficiles à trouver qu’elles ne devraient l’être.
J’ai finalement choisi une brasserie où la majorité des informations était disponible dans la langue que j’avais sélectionnée. Quelques parties restaient non traduites, mais à ce stade, même cela ressemblait déjà à un progrès.
Le repas était bon.
Je ne me souviens plus du film que j’ai vu.
Je me souviens des sites web.
Le désagrément était limité. La question ne l’était pas.
Rien de dramatique ne s’est produit ce soir-là.
J’ai trouvé un endroit où manger. Je comprenais le français. Je suis arrivé au cinéma. Aucun système de réservation ne s’est effondré et aucun restaurant n’a refusé de me servir.
La friction était modeste.
C’est précisément ce qui la rendait intéressante.
Un client ne doit pas être totalement bloqué pour qu’un site commence à perdre de sa valeur. De petites incertitudes s’accumulent : une localisation peu claire, un menu non traduit, des horaires présents sur une page mais absents d’une autre, un bouton de réservation qui mène vers une destination inattendue ou un sélecteur de langue qui ne modifie que la moitié de la page.
Chaque problème peut sembler mineur pris séparément.
Ensemble, ils transforment une décision simple en travail.
Et j’avais un avantage. Je parle français.
Quelle est l’expérience d’une personne venue du Royaume-Uni, d’Allemagne, de Scandinavie, des États-Unis ou d’ailleurs ? Que trouve un expat anglophone lorsqu’il cherche un restaurant près d’une salle de concert ? Quel niveau de confiance peut avoir un touriste qui souhaite seulement obtenir quatre réponses élémentaires ?
- Où se trouve le restaurant ?
- Est-il ouvert ?
- Quel type de cuisine propose-t-il ?
- Comment réserver une table ?
Bruxelles est officiellement bilingue, en français et en néerlandais. Elle est également beaucoup plus internationale que ces deux langues ne le laissent penser. Des sources régionales et touristiques officielles décrivent une ville qui rassemble plus de 180 nationalités et où plus de 100 langues sont parlées.
Cela ne signifie pas que chaque restaurant indépendant doit maintenir un site parfait dans une douzaine de langues.
Cela signifie toutefois que le public potentiel est particulièrement diversifié.
La question commerciale est donc pratique plutôt que politique :
Un client potentiel comprend-il suffisamment l’offre pour choisir l’établissement en toute confiance ?
Ce soir-là, la réponse était moins cohérente que prévu.
Cet article ne traite pas de politique linguistique
Bruxelles ne manque pas de débats politiques sur les langues.
Celui-ci n’en fait pas partie.
Nous n’essayons pas de déterminer quelle langue devrait dominer la vie publique. Nous ne formulons pas d’affirmations juridiques sur ce que chaque restaurant privé est tenu de publier. Nous ne soutenons pas non plus que chaque petite entreprise a besoin d’un site entièrement localisé pour toutes les nationalités susceptibles de passer par la ville.
Le point de départ est beaucoup plus ordinaire.
Un site de restaurant existe pour aider les gens à décider s’ils souhaitent s’y rendre.
La langue est une partie de cette mission. La localisation, les horaires, les menus, les prix, les réservations, l’usage sur mobile et la confiance en font également partie.
Un visiteur francophone peut malgré tout quitter le site parce que la localisation est peu claire. Un client néerlandophone peut abandonner parce que la langue sélectionnée est incomplète. Un visiteur international peut ne jamais atteindre la page de réservation parce que le premier écran ne fournit aucune indication exploitable sur ce que propose le restaurant.
Le problème n’est pas simplement qu’une traduction manque.
Le problème est que le parcours numérique peut s’arrêter avant même que la visite physique ne commence.
Un regroupement physique ne constitue pas automatiquement un parcours numérique
Mon plan dépendait d’un regroupement pratique.
La salle de concert était fixée. Je voulais trouver un restaurant et un cinéma dans un rayon raisonnable. Le temps de conduite, le parking et la marche avaient de l’importance. La soirée ne fonctionnait que si les différentes étapes pouvaient être combinées sans détours inutiles.
Sur une carte, Bruxelles proposait plusieurs options.
En ligne, ces options étaient plus difficiles à évaluer.
Cette distinction est importante pour les entreprises locales. Un restaurant peut être très bien situé près d’un cinéma, d’une salle de concert, d’un hôtel, d’un centre commercial ou d’un quartier de bureaux. Cette proximité physique crée une opportunité.
Mais cette opportunité n’a de valeur que si les clients peuvent la reconnaître.
Un restaurant peut bénéficier d’une situation parfaite et néanmoins perdre la décision en ligne parce que :
- le site officiel est difficile à identifier ;
- les différents établissements sont présentés de manière incohérente ;
- les options linguistiques sont incomplètes ;
- le menu est caché dans un PDF peu pratique ;
- les horaires se contredisent d’une page à l’autre ;
- le parcours de réservation est peu clair ;
- la navigation mobile est frustrante ;
- les résultats de recherche affichent des informations dépassées ;
- le site n’explique jamais pourquoi cet emplacement convient au plan du visiteur.
L’entreprise voit peut-être un site fonctionnel.
Le visiteur ressent de l’incertitude.
C’est dans cet écart que commence le Brussels Project.
Une soirée ne constitue pas une étude de marché
Une expérience personnelle peut révéler une question utile.
Elle ne peut pas démontrer l’ampleur du problème.
Il serait facile de transformer une recherche frustrante en conclusion générale sur les restaurants bruxellois. Ce serait une recherche faible et une base injuste pour contacter des entreprises individuelles.
La prochaine étape n’est donc pas de publier une liste de mauvais élèves.
Elle consiste à enquêter de manière systématique.
Le Brussels Project est la tentative de Vayluna de comprendre comment les établissements horeca locaux se présentent en ligne, où leurs sites créent des frictions évitables et quelles améliorations pourraient réellement aider à la fois l’entreprise et le visiteur.
Les restaurants constituent le premier domaine d’attention parce que le parcours de décision est concret.
Un visiteur doit généralement comprendre l’offre, la localisation, les horaires, le menu, le niveau de prix et le processus de réservation. Le résultat est également observable : soit le site soutient une décision, soit il laisse des questions importantes sans réponse.
Bruxelles est le premier marché parce qu’elle rassemble des clients locaux, des navetteurs, des touristes, des expats, des visiteurs d’événements et des voyageurs d’affaires dans une région géographiquement compacte.
L’objectif n’est pas de créer un énième annuaire générique de restaurants.
C’est un projet opérationnel.
Nous développons un outil spécifique pour ce projet
Étudier manuellement des centaines ou des milliers d’entreprises deviendrait rapidement répétitif et incohérent.
Une personne peut examiner soigneusement quelques sites. À plus grande échelle, le travail devient difficile à organiser :
- trouver le bon site officiel ;
- enregistrer les langues disponibles ;
- vérifier si les traductions sont complètes ;
- localiser les menus, les horaires et les liens de réservation ;
- noter les problèmes techniques ou mobiles ;
- conserver des captures d’écran et des preuves ;
- distinguer les véritables opportunités des petites imperfections ;
- se souvenir des entreprises déjà examinées ;
- préparer un suivi pertinent sans tomber dans le spam générique.
C’est pourquoi le Brussels Project devient également le premier cas d’usage ciblé d’un outil interne : le Vayluna Prospect Engine.
L’outil est actuellement en cours de développement.
Son objectif n’est pas de produire une liste commerciale en appuyant sur un bouton. Il doit collecter, structurer et hiérarchiser des preuves afin qu’un opérateur humain puisse prendre une meilleure décision.
La première version est conçue autour d’un workflow pratique.
Ce que l’outil doit examiner
1. L’entreprise dispose-t-elle d’un site officiel utilisable ?
La première tâche consiste à identifier la bonne entreprise et sa présence officielle en ligne.
Cela semble évident jusqu’à ce qu’un restaurant possède plusieurs établissements, différents profils sociaux, des fiches d’annuaire obsolètes, un ancien domaine et des pages séparées pour la livraison, les réservations et le lieu lui-même.
L’outil doit enregistrer ce qu’il trouve sans prétendre que le premier résultat est automatiquement le bon.
2. Quelles langues sont réellement disponibles ?
Un simple sélecteur de langue ne prouve presque rien.
L’outil doit distinguer :
- une version entièrement traduite ;
- une version partiellement traduite ;
- une navigation traduite alors que le contenu reste inchangé ;
- un menu séparé disponible dans une autre langue ;
- des fragments traduits automatiquement ;
- l’absence totale d’option linguistique visible.
La question n’est pas de savoir si le site affiche une icône de drapeau.
Il faut déterminer si le visiteur peut accomplir le parcours pertinent dans la langue choisie.
3. Les informations pratiques sont-elles claires ?
Le système doit rechercher les informations dont un client a besoin pour agir :
- l’adresse et la localisation ;
- les jours et heures d’ouverture ;
- le menu ou le concept culinaire ;
- une indication du niveau de prix ;
- la méthode de réservation ;
- le numéro de téléphone et les coordonnées ;
- les informations d’accessibilité ou de parking lorsqu’elles sont pertinentes ;
- les différences entre plusieurs établissements.
L’absence d’information constitue un problème.
Des informations contradictoires peuvent être pires.
4. Le site fonctionne-t-il correctement sur mobile ?
De nombreuses recherches de restaurants ont lieu alors que la personne est déjà en déplacement, se gare, marche ou décide de sa prochaine destination.
Une expérience uniquement correcte sur ordinateur ne suffit donc pas.
L’outil doit aider à identifier les mises en page qui se cassent sur les petits écrans, les menus illisibles, les pop-ups gênants, les boutons trop petits, les pages lentes et les parcours de réservation difficiles à utiliser sur un téléphone.
5. Existe-t-il des problèmes techniques ou de recherche ?
Un restaurant n’a pas besoin d’une plateforme technique élaborée.
Il a besoin de pages qui peuvent être trouvées, ouvertes et comprises.
La première version de l’outil pourra signaler des problèmes tels que :
- des liens cassés ;
- des titres de pages manquants ;
- des descriptions absentes ou dupliquées ;
- des URL non sécurisées ou incohérentes ;
- des pages qui ne peuvent pas être correctement indexées ;
- d’anciens domaines qui apparaissent encore dans les résultats de recherche ;
- l’absence d’informations locales sur l’entreprise ;
- des problèmes évidents de chargement ou d’affichage.
Ces signaux ne justifient pas automatiquement une reconstruction complète.
Ils donnent une raison d’examiner le site plus attentivement.
6. Existe-t-il une véritable opportunité commerciale ?
Toutes les imperfections ne constituent pas une opportunité commerciale.
Un petit restaurant doté d’un simple site monopage peut déjà servir parfaitement ses clients. L’absence d’une page en anglais ne signifie pas automatiquement que le propriétaire en souhaite une. Un design daté peut être sans importance si le restaurant affiche complet en permanence.
L’engine doit donc aider à classer les opportunités plutôt qu’à simplement compter les défauts.
Une opportunité significative peut combiner plusieurs facteurs :
- l’entreprise semble active ;
- le site actuel crée une friction visible ;
- l’emplacement sert un public multilingue ou international ;
- le problème peut être clairement démontré ;
- l’amélioration est réaliste ;
- Vayluna peut proposer une solution proportionnée.
Le jugement final reste humain.
L’outil doit produire des preuves, pas des accusations
Il existe une différence importante entre ces deux messages :
Votre site est mauvais et doit être remplacé.
et :
Nous avons remarqué que l’option néerlandaise s’arrête avant les informations sur le menu et les réservations. Pour un établissement proche d’un grand lieu événementiel, cela peut créer une friction inutile pour une partie du public local.
Le premier relève d’une prospection générique.
Le second est une observation précise qui peut être vérifiée.
Le Brussels Project doit rendre ce deuxième type de communication possible.
Cela suppose de conserver les preuves : l’URL concernée, la langue sélectionnée, l’état de la page, l’information manquante et la date de l’observation. Les sites évoluent. Les résultats de recherche changent. Un problème visible aujourd’hui peut être corrigé le mois prochain.
Le projet ne doit pas présenter des observations temporaires comme des vérités permanentes.
Il doit également éviter de citer publiquement des entreprises uniquement pour créer des exemples spectaculaires. Les restaurants à l’origine de cet article restent anonymes parce que l’objectif est d’expliquer un schéma, pas de mettre des exploitants individuels dans l’embarras.
Lorsqu’une entreprise précise sera contactée plus tard, les preuves auront leur place dans cette conversation privée.
Pourquoi cela pourra devenir une partie de l’outreach
Un article utile peut faire davantage qu’attirer du trafic de recherche.
Il peut fournir du contexte.
Imaginez recevoir uniquement ce message :
Nous créons des sites multilingues pour les restaurants.
Il pourrait provenir de presque n’importe quelle agence.
Comparez-le avec un message qui explique :
- le problème exact trouvé sur le site ;
- pourquoi il compte pour cet emplacement et ce public ;
- comment le Brussels Project a commencé ;
- ce que l’étude plus large cherche à comprendre ;
- à quoi pourrait ressembler une correction réaliste.
L’article devient alors un support plutôt qu’un appât.
Un futur message pourrait, dans l’idée, dire :
Nous avons remarqué que votre site ne fournit actuellement pas en néerlandais les informations sur le menu et les réservations. Nous étudions la manière dont les établissements horeca bruxellois accueillent en ligne les visiteurs multilingues, et cet article explique pourquoi nous avons commencé. Nous pensons également que le problème de votre site pourrait être corrigé sans transformer le projet en reconstruction complète et inutile.
Cela reste de l’outreach.
Il ne faut pas prétendre le contraire.
Mais c’est plus utile qu’un e-mail de masse contenant un compliment recyclé, une urgence inventée et une vague promesse de « renforcer votre présence en ligne ».
L’objectif est de contacter moins d’entreprises avec des observations plus pertinentes.
La validation humaine reste partie intégrante du processus. L’outil peut aider à collecter les informations et à préparer des brouillons, mais les messages ne doivent pas être envoyés simplement parce qu’un score automatisé a dépassé un seuil.
Pourquoi les restaurants ne sont que le début
La première version se concentre sur les restaurants et l’horeca parce que le parcours client est facile à comprendre.
Le problème plus large ne se limite pas à l’alimentation.
Des lacunes similaires peuvent apparaître sur les sites de :
- hôtels indépendants ;
- lieux culturels ;
- commerces qui servent des touristes ;
- attractions locales ;
- entreprises de santé et de bien-être ;
- prestataires de services professionnels ;
- espaces événementiels ;
- entreprises disposant de plusieurs implantations bruxelloises.
Les mêmes questions fondamentales reviennent.
Les gens peuvent-ils trouver la bonne information ?
Peuvent-ils la comprendre ?
Peuvent-ils agir sur cette base ?
Le site reflète-t-il le public que l’entreprise sert réellement ?
Élargir trop tôt affaiblirait le projet. Un outil qui analyserait dès le départ tous les types d’entreprises locales produirait probablement des observations superficielles et génériques.
Le cas d’usage des restaurants nous offre un environnement plus étroit dans lequel développer le modèle de données, le scoring, le processus de revue et les standards d’outreach.
Le projet pourra s’élargir plus tard si la première version se révèle utile.
C’est aussi un test de la manière dont nous voulons utiliser l’IA
Le Brussels Project est directement lié à la manière dont Vayluna aborde le travail assisté par l’IA.
Dans How to Use AI to Build a Website or Online Store (Without Letting It Take Over), nous expliquions que l’IA devient surtout utile lorsqu’un humain définit l’objectif, le contexte et le niveau de qualité attendu.
Le même principe s’applique ici.
L’IA peut aider à :
- classifier le contenu d’un site ;
- comparer des versions linguistiques ;
- extraire des informations pratiques ;
- organiser des observations ;
- rédiger des résumés ;
- détecter des incohérences ;
- hiérarchiser des dossiers ;
- préparer un premier brouillon d’outreach.
Elle ne doit pas décider seule qu’une entreprise est déficiente, qu’un site doit être reconstruit ou qu’un message non sollicité doit être envoyé.
L’automatisation peut accélérer la recherche.
Elle ne peut pas rendre le jugement automatiquement équitable.
La valeur du Prospect Engine dépendra moins du nombre de sites qu’il peut traiter que de sa capacité à nous aider à identifier de véritables opportunités défendables sans perdre le contexte propre à chaque entreprise.
Où en est le Brussels Project aujourd’hui ?
Au moment où cet article est écrit, l’outil dédié est toujours en cours de développement.
Le premier travail consiste à définir les champs, les sources, les critères d’audit, le modèle de preuve et le processus de revue. La version initiale ne comprendra pas parfaitement chaque restaurant. Certains sites bloqueront l’inspection automatisée. Certaines structures linguistiques seront ambiguës. Certaines constatations nécessiteront une vérification manuelle.
C’est normal.
Une première version est utile lorsqu’elle crée un workflow reproductible et révèle les endroits où les hypothèses étaient erronées.
Le projet commencera de manière ciblée, avec des lots contrôlés et une revue humaine. Nous apprendrons quels signaux comptent, lesquels créent de faux positifs et quelles améliorations sont suffisamment réalistes pour être mentionnées à une entreprise.
Ce n’est qu’ensuite que l’outreach aura du sens.
Publier cette introduction avant que le système soit terminé peut sembler prématuré.
C’est également honnête.
Le Brussels Project n’a pas commencé par une présentation de produit soigneusement préparée. Il a commencé avec un parent qui essayait de combiner un dîner et un film pendant un concert.
La soirée a fonctionné.
Le parcours numérique n’a pas été aussi fluide qu’il aurait dû l’être.
Cela a suffi pour commencer à poser de meilleures questions.
Un site doit faciliter l’étape suivante
Le site d’une entreprise locale n’a pas besoin d’impressionner tout le monde.
Il doit aider la bonne personne à passer à l’étape suivante.
Pour un restaurant, cela peut signifier comprendre le menu, confirmer l’emplacement et réserver une table. Pour un visiteur à Bruxelles, la langue et la clarté ne sont pas des accessoires décoratifs. Elles participent à la manière dont l’entreprise paraît accessible au moment où une décision est prise.
Le Brussels Project testera la fréquence à laquelle ce parcours se rompt et si un outil spécifique peut nous aider à identifier les entreprises pour lesquelles une amélioration pratique ferait une véritable différence.
Les opportunités les plus importantes seront peut-être des reconstructions multilingues.
Ou elles seront beaucoup plus modestes : corriger une page de localisation, compléter une traduction, simplifier un parcours de réservation ou rendre un menu utilisable sur mobile.
Nous ne le savons pas encore.
C’est pour cela que nous développons l’outil.
Pas pour automatiser une conclusion.
Pour étudier correctement le problème.
