Chaque phase de cette refonte, avant l'internationalisation, a été livrée sans aucune nouvelle dépendance. Un écouteur de scroll, une recherche par sous-chaîne, une animation CSS — des problèmes petits et simples pour lesquels une bibliothèque aurait été disproportionnée. Alors quand la Phase 4 (routage des langues EN → FR → AR) est arrivée, le réflexe a été le même : est-ce que je peux coder ça moi-même aussi ?
Le problème et les contraintes
Le routage multilingue pour un site Next.js App Router nécessite trois choses qui fonctionnent ensemble : un routage par préfixe d'URL qui coexiste avec chaque URL anglaise existante, inchangée (de vrais liens externes — mon CV, mon profil LinkedIn, mes emails de candidature — pointent déjà vers les URLs actuelles sans préfixe), une négociation de langue, et un rendu statique qui reste correct sur chaque route une fois qu'une deuxième puis une troisième langue existent. Rien de tout cela n'est exposé comme primitive native de l'App Router.
Note
C'est ce détail qui a changé ma réponse. Chaque décision précédente de « pas de dépendance » dans ce projet visait à éviter une abstraction inutile au-dessus de quelque chose de véritablement simple. Le routage multilingue n'est pas simple de la même façon — l'alternative réaliste à une bibliothèque n'est pas « quelques lignes de plus », c'est réimplémenter une version plus petite et moins testée de ce qu'une bibliothèque fournit déjà.
La décision
J'ai utilisé next-intl pour le routage des langues, les dictionnaires de
messages, et la navigation consciente de la langue, avec localePrefix: "as-needed" — l'anglais reste sans préfixe à /, /about, etc. ; le
français et l'arabe obtiennent des préfixes /fr et /ar. Ce dernier point
a été déterminant face à localePrefix: "always", qui aurait déplacé la
page d'accueil anglaise vers /en et cassé chaque lien existant. Le
raisonnement complet est dans l'ADR
0003.
Ce que ça a réellement coûté
Ajouter une vraie dépendance n'a pas été gratuit. L'installation a rencontré
un conflit de dépendances pairs — la version initialement fixée ne déclarait
une compatibilité que jusqu'à Next.js 15, une version majeure derrière le
Next.js 16.2.10 de ce projet. Un cache .next/ obsolète des routes typées,
datant d'avant que la structure de routes ne passe sous app/[locale]/...,
a produit une erreur de type déroutante à la tentative suivante. Puis un
écart d'API propre à une version précise : l'aide que j'avais utilisée dans
i18n/request.ts n'était en fait pas exportée par la version fixée.
Decision
Aucun de ces problèmes n'était un bug de next-intl — c'étaient des conséquences d'avoir fixé une version par familiarité générale avec la bibliothèque plutôt que de vérifier le registre npm par rapport à la version de Next.js réellement installée d'abord. Une fois le registre vérifié directement et la version passée à celle qui déclare explicitement le support de Next 16, le conflit de dépendances pairs et l'erreur de prérendu Turbopack qu'il causait silencieusement ont tous deux disparu avec le même correctif.
Ce que je ferais différemment
Vérifier la plage de dépendances pairs sur le registre avant de fixer une version, pas après l'échec de l'installation — surtout pour une dépendance qui touche directement le pipeline de build du framework (un plugin Next.js) plutôt que de simplement s'exécuter au runtime. Le compte-rendu complet de l'incident, avec les messages d'erreur exacts et les correctifs, est dans le journal de maintenance de ce projet.