Nous avons reconstruit toute notre plateforme avec Next.js 16, React 19, TypeScript et App Router. Voici pourquoi, et ce que nous en avons gagné.
en
no
frNatasun a toujours été repousser les limites. Nous étions parmi les premiers utilisateurs de Next.js il y a quelques années, et nous sommes en voyage depuis — de WordPress à Laravel, de Pages Router à App Router, et maintenant à Next.js 16.
Ce n'est pas juste une mise à jour. C'est une reconstruction complète. Chaque fichier, chaque composant, chaque ligne de code — réécrit à partir de zéro.
Voici pourquoi nous l'avons fait, ce qui a changé, et pourquoi nous croyons que c'était le bon choix.
Notre pile précédente n'était pas mauvaise. C'était Next.js 13 avec Pages Router, MUI v5, Redux pour la gestion d'état, et JavaScript partout. Ça marchait. Mais c'était devenu quelque chose de lourd.
L'état vivait dans plus de 20 tranches Redux. Notre authentification était cousue entre Auth0, Cognito et Firebase — trois systèmes différents qui se parlaient à peine. Nous avions des fichiers JavaScript dans tout le code sans sécurité de types. Le rendu côté serveur était lent parce que tout passait par des appels axios à notre propre API avant d'atteindre la base de données.
Le résultat ? Des chargements de pages lents, un bundle gonflé, et une base de code douloureuse à travailler avec. Chaque nouvelle fonctionnalité ressemblait à marcher dans la boue.
Nous savions que nous pouvions faire mieux.
Next.js 16 avec App Router nous a donné quelque chose que nous avions desperately: des Composants Serveur.
Avec les Composants Serveur, la plupart de nos pages sont rendues sur le serveur — pas dans le navigateur. Cela signifie des bundles JavaScript plus petits, des premières peintures plus rapides, et un meilleur SEO dès le départ. Fini les waterfalls côté client. Fini l'attente de 20 tranches Redux pour s'hydrater avant que la page ne paraisse correcte.
Les Server Actions ont changé la façon dont nous gérons les mutations. Au lieu de créer des routes API et de les appeler avec axios, nous appelons des fonctions directement. Le framework gère le reste — sérialisation, gestion des erreurs, revalidation.
Et le streaming ? Nos pages se chargent maintenant progressivement. Les utilisateurs voient le contenu au fur et à mesure qu'il arrive, pas tout d'un coup une fois que tout a fini de se charger.
Nous avons réécrit chaque fichier de JavaScript en TypeScript avec le mode strict activé. Pas de types any. Pas d'échappatoires.
Cela peut sembler beaucoup de travail — et ça l'était — mais le retour a été immédiat. Nous attrapons les bugs au moment de la compilation, pas en production. Notre IDE sait exactement ce que chaque fonction retourne, à quoi ressemble chaque réponse d'API, et ce que chaque composant attend comme props.
Pour une plateforme aussi complexe que Natasun — avec une place de marché, un système de chat, un CMS de blog, des portefeuilles de projets et un tableau d'emplois — la sécurité de types n'est pas un luxe. C'est une nécessité.
L'un des plus grands changements architecturaux était la façon dont nous récupérons les données. Notre ancienne pile utilisait axios pour appeler nos propres routes API, qui interrogeaient ensuite la base de données. C'est un saut réseau supplémentaire pour chaque seule requête de données.
Maintenant, les Composants Serveur interrogent la base de données directement via Prisma. Pas d'axios. Pas de routes API entre les deux. Juste une ligne droite du composant à la base de données.
Prisma 6 nous a donné de meilleures performances, une sécurité de types améliorée, et un schéma qui reflète réellement clairement notre modèle de données. Avec plus de 30 modèles — utilisateurs, publications, produits, commandes, factures, projets, emplois, commentaires et plus — avoir un ORM bien typé est essentiel.
Notre ancienne configuration d'authentification était un désordre. Auth0 était configuré. Cognito était configuré. Firebase était configuré. Trois fournisseurs, trois patterns différents, trois ensembles de bugs.
Nous avons tout remplacé par Auth.js v5 — un système d'authentification unique et propre qui prend en charge Google, GitHub, X (Twitter), LinkedIn et e-mail/mot de passe. Il utilise Prisma pour le stockage des sessions, JWT pour les tokens, et Cloudflare Turnstile pour le CAPTCHA.
La liaison de comptes fonctionne parfaitement maintenant. Un utilisateur peut s'inscrire avec Google, connecter GitHub, et plus tard se connecter avec l'un ou l'autre. Le système comprend simplement.
Nous n'avons pas seulement reconstruit les fonctionnalités existantes — nous en avons ajouté de nouvelles entièrement. La plus grande addition est notre place de marché numérique.
Les vendeurs peuvent lister des produits avec des images, catégories, tags et tarifs. Les acheteurs peuvent parcourir, ajouter au panier, et payer avec PayPal, cartes de crédit ou crypto USDT. Les commandes sont suivies avec des workflows de statut complets. Les factures sont générées automatiquement. Les avis et notes aident les acheteurs à prendre des décisions.
Tout cela fonctionne sur la même pile Prisma + Next.js. Pas de plateforme e-commerce tierce. Pas d'intégrations Shopify. Notre place de marché, notre code, nos règles.
Natasun s'adresse à un public mondial. Nous supportons l'anglais, le norvégien et le français — avec d'autres langues à venir.
Chaque contenu est stocké comme un objet JSON avec des clés de langue. Les URLs ont le préfixe de la locale (/no/blog, /fr/about-us). Les moteurs de recherche indexent chaque langue séparément. Et notre système i18n gère tout, des traductions d'interface au formatage des dates à l'affichage des devises.
Cela n'était pas facile à construire, mais c'était essentiel. Nos utilisateurs ne devraient pas avoir à parler anglais pour utiliser notre plateforme.
Chaque page publique de Natasun génère maintenant des données structurées complètes. Nous parlons de balisage Schema.org pour les articles de blog, les annonces d'emploi, les produits, les projets et les données d'organisation.
Les balises méta OpenGraph et Twitter Card sont générées pour chaque page. Les liens alternatifs hreflang indiquent aux moteurs de recherche toutes les versions linguistiques. Les sitemaps dynamiques et les flux RSS maintiennent les moteurs de recherche à jour.
Ce n'est pas un SEO réfléchi après coup. C'est du SEO intégré dans l'architecture.
Voici un aperçu rapide de ce qui a changé :
Chaque changement était délibéré. Nous n'avons pas échangé des bibliothèques pour le plaisir — nous avons choisi des outils plus rapides, plus faciles à maintenir, et mieux adaptés à nos besoins.
Cette reconstruction est la fondation. Nous itérons maintenant rapidement dessus.
Bientôt : livraison de téléchargements numériques, plans d'abonnement, outils de collaboration de projet améliorés, meilleures analyses pour les membres, et améliorations API pour les intégrations tierces.
Nous construisons Natasun pour être la plateforme où les créateurs numériques, développeurs et artistes veulent vraiment travailler. Et avec Next.js 16, nous avons enfin la fondation pour que cela se produise.
Des idées ? Un bug trouvé ? Vous voulez contribuer ? Contactez-nous ou ouvrez un ticket sur notre GitHub.
