Ma stack pour des produits qui durent : Next.js + Go

Quand un projet doit durer, je choisis mes outils pour ce qu'ils seront dans trois ans, pas seulement pour le confort du premier mois. Côté interface, Next.js coche presque toutes les cases : rendu côté serveur pour le SEO, React Server Components pour n'envoyer au navigateur que le strict nécessaire, et un écosystème énorme qui garantit qu'on trouvera toujours des développeurs et des réponses. C'est ma base par défaut pour tout ce qui touche au web côté utilisateur.

Pour le back-end qui doit encaisser de la charge ou tenir des traitements lourds, je me tourne vers Go. Le langage est volontairement simple : peu de magie, du code lisible que je relirai sans peine dans deux ans. Surtout, sa gestion native de la concurrence avec les goroutines permet de traiter des milliers de requêtes simultanées sans architecture exotique, et les binaires compilés démarrent en quelques millisecondes — idéal pour des conteneurs légers et une facture d'hébergement maîtrisée.

Concrètement, je sépare les responsabilités. Next.js gère l'affichage, l'authentification côté session et les écrans ; Go expose une API claire pour la logique métier sensible, les jobs en arrière-plan et les intégrations tierces. Les deux dialoguent via des contrats explicites, souvent typés de bout en bout. Quand le front et le back évoluent à des rythmes différents — ce qui arrive vite — cette frontière nette évite que toucher un bouton casse un calcul critique.

Ce duo n'est pas un dogme : sur un projet plus modeste, l'API intégrée de Next.js suffit largement et ajouter Go serait de la sur-ingénierie. Je sors Go quand le besoin est réel : volumétrie, temps réel exigeant, traitements coûteux. L'idée directrice reste la même sur tous mes projets — des fondations sobres, prévisibles et bien documentées, pour qu'on construise dessus pendant des années plutôt que de tout réécrire au bout de dix-huit mois.