Pourquoi j'ai reconstruit mon portfolio en Next.js

Je suis designer et formateur qui construit pour le web, donc mon portfolio est deux choses à la fois : un lieu pour montrer mon travail, et une pièce de travail en soi. Quand j'ai décidé de le reconstruire, la voie évidente était un outil no-code (Webflow, Framer, un template Squarespace). J'ai choisi Next.js à la place. Voici le raisonnement honnête, y compris les parties que je reconsidérerais.

Pourquoi pas un outil no-code

Les outils no-code sont vraiment bons, et pour beaucoup de gens, c'est la bonne réponse. Je suis allé dans l'autre sens pour trois raisons.

Le contrôle. Mon site doit s'adapter à une configuration inhabituelle : trois audiences (design, formation, développement) qui ont chacune besoin de leur propre page, de leurs propres preuves, et de leur propre appel à l'action, plus un tunnel de ressources gratuites et un pipeline de contact. Plier un template pour faire tout ça est souvent plus difficile que de construire exactement ce qu'on veut.

La performance. Un portfolio est mon CV technique. Si je dis aux clients que je me soucie d'interfaces rapides et accessibles, le site doit le démontrer avec de vrais Core Web Vitals, pas un template lourd chargé de scripts que je ne contrôle pas. Next.js me donne la génération statique, l'optimisation d'images, et un contrôle fin sur ce qui est envoyé au navigateur.

Posséder les parties backend. Ce fut le facteur décisif. Mes formulaires de ressources gratuites et de contact passent par des routes API Next.js reliées à un service d'emailing. Le flux de capture de leads (quelqu'un saisit son email, reçoit la ressource, et je suis notifié) est quelque chose que je possède de bout en bout, pas un formulaire tiers avec des limites. Pouvoir livrer la route API en même temps que l'interface est ce que le no-code ne pouvait pas m'offrir proprement.

Ce qui a fonctionné

• Statique d'abord. La plupart des pages sont générées statiquement, donc rapides et peu coûteuses à servir, avec une seule route serverless pour l'email. Pour un portfolio, c'est le bon réglage par défaut.
• Une seule source de vérité pour les données. J'ai déplacé chaque statistique, certification et expérience dans un seul fichier de données pour qu'un même chiffre ne dise pas "1 000+" sur une page et autre chose ailleurs. (Leçon apprise à la dure.)
• Le site comme pièce de portfolio. Le construire moi-même signifie que le code source est un échantillon, et écrire cet article en fait partie.

Ce que je ferais différemment

L'honnêteté est plus utile qu'un tour d'honneur, alors voici ce que j'ai raté ou changerais :

1. J'ai livré sans les garde-fous. Pour avancer vite, j'ai laissé le build ignorer les erreurs TypeScript et de lint. C'est bon pour l'élan et dangereux pour la maintenance. Les régressions passent silencieusement. Si je recommençais, je garderais la vérification de types dans le build dès le premier jour et paierais la petite taxe en amont.

2. L'internationalisation méritait un vrai plan. Je travaille en arabe, en français et en anglais, et j'ai greffé le i18n plus tard au lieu de choisir une vraie stratégie de routage dès le départ. Adapter des traductions après coup est bien plus douloureux que de concevoir pour elles dès le premier jour. Si le multilingue compte pour vous, décidez-le avant de construire.

3. J'ai trop installé. Une bibliothèque de composants est pratique et discrètement lourde. J'ai importé bien plus que ce que j'utilisais. La prochaine fois, j'ajouterais des dépendances seulement quand un vrai besoin apparaît, et j'auditerais le bundle régulièrement.

4. Aucun test, puis des surprises. Sans vérifications automatisées, de petits changements ont parfois cassé des choses que je n'ai remarquées que plus tard. Même une poignée de tests de fumée (le nav s'affiche-t-il, le formulaire s'envoie-t-il, les statistiques montrent-elles de vrais chiffres) m'aurait épargné bien des soucis.

Devriez-vous utiliser Next.js pour un portfolio ?

Si vous êtes développeur, oui. Votre portfolio doit prouver que vous savez construire, et c'est la preuve la plus honnête qui soit. Si vous ne l'êtes pas, un bon outil no-code vous donnera un beau site plus vite, et c'est tout à fait valable ; un site en ligne bat un site parfait qui ne sort jamais. Le framework est un moyen, pas une fin en soi.

Ce à quoi je reviens toujours : l'outil que vous choisissez doit correspondre à l'histoire que vous racontez. Je dis à mes clients que je peux faire passer une idée du design à un produit livré, rapide et maintenable. Construire ce site moi-même, erreurs comprises, est la chose la plus crédible que je puisse leur présenter.

Curieux de la construction, ou envie d'un site similaire ? Je prends des projets web. Réservez un appel gratuit et je vous montrerai ce que je livrerais pour vous, ou consultez les projets de développement.