Votre agence Next.js à Bruxelles — Sites institutionnels UE, trilingues FR/EN/NL et portails fintech belges

#Votre agence Next.js à Bruxelles — Sites institutionnels UE, trilingues FR/EN/NL et portails fintech belges

Un portail bruxellois doit tenir trois langues à parité, une obligation d'accessibilité qui s'étend désormais au secteur privé, et une bibliothèque documentaire que l'on doit pouvoir fouiller en néerlandais comme en français. Nehos conçoit ces plateformes sur une architecture découplée, avec un rendu Next.js devant un CMS structuré, et remet en fin de projet le code, la documentation d'exploitation et des éditeurs formés.

#Trois contraintes qui se cumulent, et qu'aucun thème ne résout

Un site bruxellois sérieux doit tenir simultanément trois exigences qui, prises séparément, sont banales, et dont la combinaison élimine la quasi-totalité des solutions standard.

La première est le multilinguisme à parité. Pas un site français avec un sélecteur de langue, mais trois versions de statut équivalent — français, néerlandais, anglais — parfois quatre avec l'allemand pour les organisations qui adressent l'ensemble des communautés belges. La Région de Bruxelles-Capitale est officiellement bilingue, l'environnement de travail du quartier européen est anglophone, et un contenu qui n'existe que dans une langue est perçu comme une prise de position. Techniquement, cela impose que la langue soit une dimension du modèle de contenu et du routage, pas une couche de traduction posée par-dessus.

La deuxième est l'accessibilité, devenue une obligation à double détente. Le secteur public relève de la directive européenne de 2016 sur l'accessibilité des sites web, transposée en Belgique par la loi du 19 juillet 2018. Depuis juin 2025, l'Acte européen sur l'accessibilité étend des obligations comparables à des acteurs privés : services bancaires aux consommateurs, commerce électronique, transport de voyageurs, livres numériques, communications électroniques. Une fintech belge grand public est aujourd'hui dans le périmètre, ce que beaucoup de directions découvrent tardivement. La référence de contrôle est la norme harmonisée européenne, qui traduit les critères WCAG en exigences vérifiables.

La troisième est la charge documentaire. Une fédération, un institut de recherche ou une organisation internationale bruxelloise publie des rapports, des positions, des réponses à consultation, des archives de séminaires — des milliers de documents dont la valeur tient à la possibilité de les retrouver. Un CMS monolithique classique encaisse mal ce volume dès qu'on y ajoute trois langues, des taxonomies croisées et des restrictions d'accès par rôle. C'est précisément là qu'une architecture découplée, avec un rendu Next.js devant un CMS structuré, cesse d'être une préférence technique pour devenir la réponse adaptée au problème.

#Les décisions d'architecture qui font réellement la différence

#Le multilingue traité au niveau du routage

Dans l'App Router de Next.js, le multilingue n'est plus fourni par une configuration intégrée comme au temps du Pages Router : il se construit avec un segment de locale explicite dans l'arborescence et un middleware de négociation. C'est une bonne nouvelle, parce que cela oblige à décider. Chaque langue obtient ses propres URL, ses propres métadonnées, son propre plan de site, et les relations alternates sont déclarées de façon réciproque avec une version par défaut. Une erreur classique consiste à déclarer des alternates asymétriques, ce qui produit des versions concurrentes sur les mêmes requêtes. Sur un site trilingue, ce détail décide de la moitié de la visibilité.

#La parité éditoriale dans le modèle de contenu

Nous modélisons les champs localisés au niveau du contenu, de sorte qu'une page existe comme entité unique avec trois états linguistiques, chacun ayant son propre statut de publication. Les équipes voient immédiatement ce qui est traduit, ce qui est obsolète et ce qui manque. Sans cela, la version néerlandaise dérive silencieusement de la version française en dix-huit mois, et personne ne s'en aperçoit avant qu'un membre néerlandophone ne le signale.

#La recherche documentaire, et le piège du néerlandais

C'est le point technique le plus sous-estimé des projets bruxellois. Le néerlandais agglutine : un lecteur cherchera un mot composé que votre corpus n'écrit qu'en deux morceaux, ou l'inverse. Un moteur de recherche configuré avec un analyseur générique renverra zéro résultat sur des requêtes parfaitement légitimes, et l'utilisateur en conclura que la bibliothèque est vide. Il faut un analyseur avec décomposition des composés, des règles de stemming par langue, une gestion propre des élisions et des accents en français, et un index séparé par langue plutôt qu'un index unique multilingue. Cela demande une demi-journée de configuration et change complètement la perception du portail.

#Le rendu, pensé pour des réseaux contraints

Une part de votre audience se connecte depuis des réseaux institutionnels filtrés, avec des proxys agressifs et des politiques de sécurité strictes. Nous privilégions donc la génération statique avec revalidation incrémentale, de sorte que la page utile arrive en HTML complet dès la première réponse, sans dépendre d'une cascade d'appels côté client. Les indicateurs que nous suivons sont ceux qui comptent réellement pour l'utilisateur : l'affichage du contenu principal, la réactivité aux interactions et la stabilité visuelle au chargement. Sur les pages d'entrée, nous visons un affichage du contenu principal sous 1,2 seconde.

#Portails authentifiés et identité belge

Les espaces membres de fédérations et les portails clients de fintechs partagent les mêmes exigences : gestion fine des rôles, cloisonnement des documents, journalisation des accès, expiration de session maîtrisée. En Belgique, la question de l'identité se pose vite : l'usage d'une identité numérique nationale largement adoptée est souvent attendu par les utilisateurs, et le règlement européen sur l'identité numérique ouvre la voie à des portefeuilles interopérables que les États membres doivent proposer. Nous concevons la couche d'authentification pour que l'ajout d'un fournisseur d'identité ne soit pas une refonte, mais un branchement.

#Sécurité et exploitation pour un acteur supervisé

Pour une fintech sous supervision de la FSMA et de la Banque nationale de Belgique, le site public fait partie du périmètre TIC. Cela implique des en-têtes de sécurité correctement posés, une politique de contenu restrictive, une gestion des dépendances documentée, des traces exploitables en cas d'incident et une capacité de retour arrière rapide. Ces éléments doivent pouvoir être décrits dans votre registre d'information sur les prestataires tiers : nous fournissons la documentation dans un format directement réutilisable, plutôt qu'un simple accès à une console.

#L'accessibilité telle qu'elle est réellement contrôlée

L'écart le plus fréquent entre une déclaration d'accessibilité et la réalité tient à la méthode de vérification. Les outils automatisés détectent une partie des problèmes : contrastes insuffisants, images sans alternative, champs de formulaire sans étiquette, structure de titres incohérente. Nous les intégrons à la chaîne d'intégration continue pour qu'aucune régression ne passe. Mais l'essentiel se joue ailleurs : l'ordre de tabulation dans un menu à plusieurs niveaux, le comportement d'une fenêtre modale qui doit rendre le focus, l'annonce d'un chargement asynchrone, l'usage d'un tableau de données complexe au lecteur d'écran. Ces points ne se testent qu'à la main.

Nous menons donc une recette d'accessibilité au clavier seul et au lecteur d'écran avant chaque livraison majeure, et nous produisons un rapport listant les critères, leur état et, pour ceux qui ne sont pas atteints, la raison et l'échéance. Ce document alimente directement votre déclaration d'accessibilité, qui est elle-même une obligation et non un supplément de communication.

Un mot sur les documents. Sur un site institutionnel bruxellois, l'accessibilité échoue le plus souvent non pas sur les pages, mais sur les PDF publiés : documents scannés sans couche texte, tableaux sans structure, absence de langue déclarée. Nous traitons ce sujet dans le cadrage, parce qu'il conditionne des arbitrages éditoriaux — publier une version web des documents clés est souvent plus rapide que de remettre en accessibilité un historique de PDF.

#Le déroulé d'une refonte

Le projet commence par un atelier de cadrage sur place, où nous passons autant de temps sur l'inventaire de contenu que sur les maquettes. Combien de pages, combien de documents, quelles langues réellement maintenues, quelles URL doivent survivre. Cet inventaire détermine le coût plus sûrement que le nombre d'écrans.

Suit une phase de conception qui produit un système de composants accessible par construction, validé sur les parcours critiques plutôt que sur des pages vitrines. Nous testons tôt les gabarits les plus contraignants — la fiche document, la page de recherche, le formulaire d'adhésion — parce que ce sont eux qui révèlent les impasses.

Le développement se fait par itérations avec un environnement de recette accessible en permanence à vos équipes, pour que la validation se fasse en continu et non dans une semaine de tension avant la mise en ligne. La migration de contenu est traitée comme un chantier à part entière, avec reprise automatisée quand la source le permet et plan de redirections construit à partir des URL réellement fréquentées.

Comptez 8 à 12 semaines sur un périmètre standard jusqu'à la bascule, suivies d'une période de surveillance rapprochée pendant laquelle nous restons en astreinte sur les redirections et les remontées d'accessibilité. Nous remettons le code, la documentation d'exploitation et la formation des éditeurs : votre équipe doit pouvoir publier sans nous dès le premier mois.

#Les pièges de la migration, par ordre de coût

Le plus cher est la perte d'historique d'URL. Une refonte qui change les adresses sans plan de redirections détruit des années de référencement et casse les liens entrants depuis les documents institutionnels, qui sont rarement mis à jour. Nous partons des logs et des données de recherche réelles, pas d'un export théorique.

Le deuxième est la traduction automatique généralisée. Elle donne l'illusion d'une couverture trilingue et produit des textes que les néerlandophones repèrent en deux phrases, avec un coût de crédibilité durable. Mieux vaut trois langues sur les pages essentielles et deux langues ailleurs, assumées explicitement.

Le troisième est le bandeau de consentement, presque toujours ajouté en fin de projet. Chargé avant le contenu, il dégrade la performance mesurée et, mal configuré, il dépose des traceurs avant tout consentement — ce que l'autorité belge de protection des données a rappelé à plusieurs reprises. Nous le traitons comme un composant du site, testé et mesuré comme les autres.

Le quatrième est le contenu lui-même. Une refonte réussie techniquement mais alimentée par le même corpus désordonné qu'auparavant déçoit tout le monde. Le tri éditorial doit démarrer avec le projet, pas après.

#Ce que vous obtenez

Une base de code que vos équipes peuvent reprendre, une bascule en 8 à 12 semaines sur un périmètre standard, une disponibilité constatée de 99,5 %, un affichage du contenu principal sous 1,2 seconde sur les pages d'entrée, et un rapport d'accessibilité qui documente l'état réel plutôt qu'une conformité déclarative.

#Pourquoi Nehos à Bruxelles

• Ateliers et recettes chez vous — nous nous déplaçons à Bruxelles pour les validations, y compris les sessions de test au clavier seul et au lecteur d'écran avec vos utilisateurs en situation de handicap.
• Le multilingue et l'accessibilité sont traités dès la conception, jamais rattrapés en fin de projet, parce que c'est la seule manière de ne pas les payer deux fois.
• Une bibliothèque de migrations déjà rencontrées — nos 47 experts ont accompagné plus de 200 projets jusqu'en production depuis 2014, dont des reprises d'historiques d'URL particulièrement hostiles.
• Hébergement souverain européen, avec documentation des flux de données pour vos obligations RGPD et pour votre registre des traitements.
• Pas de dépendance construite — code remis, documentation d'exploitation, éditeurs formés.
• Audit gratuit de 30 minutes pour cadrer le périmètre, estimer la charge et repérer les zones de risque de votre existant.

#Services complémentaires à Bruxelles

• refonte site B2B Next.js
• agence digitale Bruxelles
• agence IA Bruxelles
• agents IA pour organisations bruxelloises
• référencement GEO et AEO Bruxelles
• nos cas clients Next.js

Nos domaines d'intervention connexes : développement Next.js Bruxelles, site institutionnel UE Next.js, portail multilingue FR EN NL Bruxelles, WCAG 2.2 AA Next.js Belgique, fintech belge Next.js.

Vous trouverez ci-dessous les questions que nous posent le plus souvent les équipes bruxelloises avant de lancer une refonte. Si vous préparez un cahier des charges, envoyez-le : un retour argumenté sur les points qui vont poser problème vaut mieux qu'une proposition commerciale de plus.