Comment créer un dashboard fintech avec Next.js, pas à pas

Ce guide montre comment créer un dashboard fintech ou de finances personnelles avec Next.js, en anglais et en arabe, à partir du template Financial Dashboard d’Aniq UI. Vous allez le lancer, y mettre votre marque, remplacer les données d’exemple par les vôtres et le mettre en ligne, en sachant clairement quelles parties vous connectez vous-même.

Ce dernier point compte, alors le voici d’emblée : le template est un front end. Il n’a ni base de données, ni back end, ni vraie connexion. Chaque solde, chaque carte et chaque transaction affichés à l’écran sont des données d’exemple écrites dans le code. Ce que vous obtenez, c’est une interface terminée et fonctionnelle, prête pour votre API. Les étapes ci-dessous indiquent où cette API se branche et ce qu’il faut vérifier à chaque stade.

Avant de commencer : les décisions à prendre

Une interface financière est facile à démarrer et difficile à terminer si les grandes questions restent ouvertes. Répondez-y d’abord, sur papier.

• D’où viennent les données ? Le template n’en contient aucune. Il vous faut une API à vous, ou un service que vous utilisez déjà, qui renvoie des soldes, des cartes et des transactions. Décidez qui la construit et quand, car les écrans en dépendront.
• Comment les gens se connectent-ils ? La connexion fournie est un substitut qui tourne dans le navigateur. Choisissez la vraie méthode (vos propres comptes, un fournisseur d’identité ou autre chose) et qui gère la session côté serveur.
• Quelles actions doivent vraiment fonctionner dès le premier jour ? Rechercher et exporter des transactions fonctionne déjà dans le navigateur. Ajouter une transaction, ajouter une carte et envoyer un virement n’enregistrent encore rien. Dressez la liste de celles que vous garderez et de celles que vous masquerez.
• Quelles langues et quel sens de lecture ? L’anglais et l’arabe sont fournis, et les pages en arabe s’affichent de droite à gauche. Une troisième langue est possible mais demande quelques modifications, décidez-en donc tôt.
• Quelles règles s’appliquent aux données d’argent ? Manipuler des soldes et des données de carte peut entraîner des exigences légales, de sécurité et de partenaires qui dépendent de l’endroit où vous opérez. Le template ne tranche pas ces questions à votre place. Parlez à votre partenaire de paiement ou bancaire et, le cas échéant, à votre régulateur avant que des données réelles n’arrivent sur les écrans.
• Où sera-t-il hébergé ? Vercel, un serveur Node.js ou un hôte Docker conviennent tous. Choisissez-en un avant d’acheter un nom de domaine.

Le cahier des charges

Kestrel Budget est une application de budget pour des freelances dont les revenus arrivent par à-coups. Les clients lisent en anglais ou en arabe. L’équipe demande ceci :

• Un écran qui affiche le solde, les cartes de paiement et les dernières transactions dès que quelqu’un se connecte.
• Une page de transactions où un freelance peut rechercher, filtrer par date et exporter un fichier pour son comptable.
• Des graphiques qui comparent les revenus aux dépenses et répartissent les dépenses par catégorie, puisque les mois d’un freelance varient beaucoup.
• Une page de cartes où un client peut verrouiller une carte et voir ses détails.
• L’anglais et l’arabe, avec la version arabe mise en page de droite à gauche.
• Le nom, le logo et la couleur de marque de l’entreprise, en mode clair et en mode sombre.
• Une vraie connexion et de vraies données issues de l’API de Kestrel avant que le moindre client le voie.

Comment le template répond au cahier des charges

Besoin	Où ça se trouve	Ce que vous utilisez
Solde, cartes, dernières opérations	Site web (l’application Next.js)	Page Overview (vue d’ensemble) sur /en/dashboard
Rechercher, filtrer, exporter	Site web	Page Transactions avec plage de dates, boîte de dialogue de filtres et export CSV
Revenus et dépenses, catégories	Site web	Page Analytics avec des graphiques Recharts téléchargeables en PNG
Contrôles de carte	Site web ; l’enregistrement demande votre API	Page Your Cards avec verrouiller, supprimer et afficher le numéro
Anglais et arabe	Site web	Adresses /en et /ar, fichiers dans messages/
Marque et thèmes	Site web	Fichiers de messages, logo.svg, DEFAULT_THEME_COLOR
Vraies données et vraie connexion	Votre propre API (non incluse)	Fichiers de données d’exemple à côté de chaque widget ; le code de connexion que vous remplacez

Template, développement from scratch ou outil hébergé

Trois voies mènent à un dashboard financier, et la bonne dépend de votre équipe.

From scratch. Vous contrôlez chaque détail, mais vous devez aussi concevoir et construire la mise en page, les graphiques, les tableaux, les cartes déplaçables, les thèmes clair et sombre et la version de droite à gauche avant d’arriver à ce qui est propre à votre produit. C’est un choix raisonnable si l’interface elle-même est votre avantage concurrentiel.

Un dashboard hébergé ou un outil de BI. Ces outils se connectent à des sources de données et dessinent des graphiques rapidement, et vous n’avez pas à gérer l’hébergement. En contrepartie, le résultat ressemble à l’outil plutôt qu’à votre produit, les clients en voient généralement les limites de marque et de mise en page, et une expérience en arabe de droite à gauche peut ne pas être prise en charge. Vérifiez ses tarifs, ses options d’intégration et ses exports avant de vous y fier.

Un template avec le code source. Vous obtenez l’interface terminée, vous possédez le code et vous l’hébergez où vous voulez. Le coût, c’est le travail que vous avez vu dans les décisions ci-dessus : vous fournissez l’API, la connexion et le travail de conformité. Pour une équipe qui a un back end ou le budget pour en construire un, ce partage est efficace, car ce qui reste est justement ce que vous seul pouvez faire.

Kestrel a un seul développeur et un projet de petite API, donc il choisit le template. Une équipe sans développeur devrait plutôt regarder une solution hébergée.

Un exemple de plan de lancement, semaine par semaine

Ce calendrier est un exemple pour Kestrel, pas une promesse sur la durée de votre projet.

• Semaine 1, lancer et examiner. Démarrez le template, parcourez chaque page dans les deux langues et les deux thèmes, et arrêtez les décisions ci-dessus.
• Semaine 2, marque et allègement. Changez le nom, le logo et la couleur, traduisez les nouveaux textes et masquez les pages et les boutons que vous ne construirez pas.
• Semaine 3, branchez les premières données. Remplacez l’utilisateur connecté et les transactions par de vrais appels d’API. Laissez le reste en données d’exemple pour l’instant.
• Semaine 4, branchez le reste et connectez-vous pour de vrai. Cartes, chiffres d’analyse et vraie connexion, avec la session vérifiée côté serveur.
• Semaine 5, tests et mise en ligne. Build de production, tests sur téléphone et sur ordinateur, liste de contrôle de lancement, déploiement.

Pas à pas

1. Décidez ce que vous connectez vous-même

Avant d’ouvrir le code, notez les trois choses que le template vous laisse : qui est connecté, d’où viennent les chiffres, et ce qui se passe quand un client appuie sur un bouton qui modifie quelque chose. Pour Kestrel, cela donne un service de connexion, une API qui renvoie des soldes, des cartes et des transactions, et des endpoints pour les actions (ajouter une transaction, enregistrer des réglages).

Le template vous donne les écrans, les graphiques, les formulaires et leurs contrôles. Vous lui donnez les données. Ce partage est utile, car vous pouvez construire l’API à votre rythme pendant que l’interface a déjà l’air terminée.

À vérifier : vous avez une courte liste écrite, intitulée « ce que je connecte », avec un responsable et un ordre approximatif. Ce qui tourne souvent mal : les équipes croient que l’écran de connexion est un vrai login et découvrent l’écart trop tard.

2. Lancez-le sur votre ordinateur

Installez Docker Desktop, puis suivez ces sous-étapes.

2a. Téléchargez. Dans votre compte Aniq UI, ouvrez Mes templates et téléchargez le ZIP.

Regardez où se trouve le bouton de téléchargement sur la page Mes templates.

2b. Décompressez et ouvrez le dossier. Décompressez l’archive et ouvrez un terminal dans le dossier dashboard-template-1.

Regardez le chemin affiché dans le terminal : toutes les commandes suivantes se lancent depuis ce dossier.

2c. Construisez l’image, puis démarrez un conteneur.

docker build -t financial-dashboard .
docker run -p 3030:3030 financial-dashboard

Comptez quelques minutes pour le premier build, avec un accès à internet, car les dépendances et le build de l’application se font tous deux dans l’image.

Regardez le journal du build, qui se termine quand l’image est prête à être lancée.

2d. Ouvrez-le. Allez sur localhost:3030/en/login et connectez-vous avec admin@dashboard.com et le mot de passe Admin@123. Si le port 3030 est occupé, changez le premier numéro de l’option -p et laissez le second tel quel, par exemple docker run -p 3041:3030 financial-dashboard.

Vous préférez Node.js ? Installez la version 20.9 ou plus récente, lancez corepack enable une seule fois, puis yarn install et yarn dev. Le projet fixe Yarn 4, utilisez donc Yarn plutôt que npm.

Ce qu’il faut vérifier : la vue d’ensemble s’ouvre avec un solde, une pile de cartes et une liste de transactions. Ce qui tourne souvent mal : Docker n’est pas démarré (lancez Docker Desktop et attendez que le moteur soit prêt), un port est déjà pris, ou Yarn répond avec la version 1.22 parce que Corepack n’est pas activé. Pour arrêter le conteneur, appuyez sur Ctrl+C, ou utilisez docker stop avec l’ID donné par docker ps. Les modifications n’atteignent pas une image déjà construite, reconstruisez-la donc après avoir changé un fichier.

Regardez comment la page est organisée en bento de widgets : cartes, transactions, statistiques, une carte du monde et un graphique de portefeuille.

3. Parcourez chaque page

Le template fournit ces pages, chacune sous /en et /ar :

• Overview (vue d’ensemble) : l’écran d’arrivée après la connexion, avec un formulaire de virement rapide, le solde au-dessus d’une pile de cartes de paiement, une liste de suivi d’actions, les transactions les plus récentes, un graphique de statistiques, une carte des virements et un graphique de portefeuille.
• Analytics (analyses) : quatre chiffres clés, puis des graphiques de revenus et de coûts, de dépenses par catégorie et d’activité sur la semaine, avec un tableau des transactions récentes en dessous.
• Transactions : l’historique complet, avec recherche, filtres, tri, pagination et un bouton d’export.
• Your Cards (vos cartes) : la liste des cartes avec les détails de la carte sélectionnée.
• Settings (réglages) : profil, sécurité, notifications et préférences.
• UI Components (composants d’interface) : chaque élément réutilisable, présenté avec des exemples en direct.

Regardez la barre latérale, qui est la carte de tout ce que vous allez personnaliser, traduire et connecter.

Décidez quelles pages vous gardez. Kestrel les garde toutes, mais un outil de budget sans produit de cartes pourrait supprimer la page des cartes et son lien dans la barre latérale.

Regardez la rangée de chiffres en haut et le panneau de détails de la carte sélectionnée.

Regardez les onglets de la page des composants : les nouveaux écrans que vous construirez plus tard peuvent réutiliser n’importe lequel de ces éléments. Ajoutez ?tab= et l’identifiant d’un onglet, comme tables, pour ouvrir directement un onglet.

4. Aux couleurs de Kestrel

Lancez yarn dev pendant que vous modifiez, et la page se recharge à chaque enregistrement. Voici les endroits à changer :

• Le nom, le titre de l’onglet et la description : le bloc Metadata dans messages/common/en.json et ar.json.
• Le nom sur les pages de connexion et d’accueil : Login.title et Hero.title dans messages/auth/.
• Le logo : public/assets/images/icons/logo.svg. La barre latérale et le coin de chaque carte de paiement l’utilisent.
• La couleur de marque : DEFAULT_THEME_COLOR dans src/Demo/ThemeColorSwitcher/themes.ts. Quatre thèmes sont fournis : orange (par défaut), bleu, doré et argenté.
• Le favicon : src/app/favicon.ico. La mention du pied de page : src/app/[locale]/dashboard/layout.tsx.

Le logo d’exemple est gris clair, la barre latérale l’assombrit donc en mode clair pour qu’il reste visible. Si votre logo est déjà foncé, retirez brightness-50 des classes dans src/layouts/Sidebar/components/SidebarLogo.tsx. Kestrel choisit le thème bleu et règle DEFAULT_THEME_COLOR en conséquence ; pour une couleur entièrement personnalisée, changez les valeurs d’un thème dans ce même fichier et laissez son id dans la constante.

La couleur d’accent change en même temps le visuel des cartes, les mises en avant des graphiques, les boutons et l’élément actif du menu. Ces trois captures montrent la même vue d’ensemble en bleu, en doré et en graphite.

Regardez l’accent bleu sur la carte, sur les mises en avant des graphiques et sur l’élément actif de la barre latérale.

Regardez comment les mêmes éléments prennent le doré, alors que les fonds neutres restent identiques.

Regardez l’accent graphite, plus discret, qui convient à une marque plus classique.

Les modes clair et sombre sont tous deux terminés. Le dashboard démarre en mode sombre, le bouton soleil et lune permet de changer, et le navigateur retient le choix de chaque personne. Ce même choix, avec la langue, se trouve dans Settings, Preferences.

Regardez les onglets en haut des réglages : profil, sécurité, notifications et préférences.

Regardez la version claire de la vue d’ensemble, qui utilise les mêmes composants que la version sombre. Les fonds, les bordures et les couleurs de texte se trouvent dans src/styles/theme.css : les valeurs claires dans :root et les sombres dans .dark.

Ce qu’il faut vérifier : ouvrez le dashboard dans les deux modes après avoir changé la couleur de marque. Ce qui tourne souvent mal : une nouvelle couleur qui ne s’affiche pas. Avec le mode démo activé, un sélecteur de couleur flottant enregistre son choix dans le navigateur, et ce choix l’emporte sur le code. Effacez les données du site, ou laissez le mode démo désactivé.

5. Remplacez les données d’exemple, un widget à la fois

Chaque widget a son propre fichier de données d’exemple, rangé à côté de l’écran qui l’affiche. C’est voulu : vous pouvez brancher le tableau des transactions sur votre API cette semaine et laisser la carte du monde pour plus tard. Un ordre de travail réaliste pour Kestrel : l’utilisateur connecté, puis les transactions, puis les cartes, puis les chiffres d’analyse.

Sachez ce qui fonctionne déjà sans serveur, pour ne pas le reconstruire. La recherche, le tri et la pagination des transactions, la plage de dates et la boîte de dialogue de filtres fonctionnent dans le navigateur. Il en va de même pour les exports CSV et PNG, pour le réordonnancement par glisser-déposer des cartes de chiffres clés (le navigateur retient l’ordre), et pour le verrouillage ou la suppression d’une carte jusqu’au prochain rechargement.

Sachez aussi ce qui n’enregistre encore rien. Add Transaction, Add Card, le virement rapide, le virement express et Save Changes dans les réglages vérifient ce que le client saisit, puis s’arrêtent. Ce sont les endroits exacts où vont vos appels d’API. Les formulaires utilisent React Hook Form avec Zod, donc les contrôles de champs sont déjà écrits.

Deux détails font gagner du temps. Les transactions d’exemple sont datées par rapport à aujourd’hui, donc la plus récente est toujours d’actualité, et la page des transactions s’ouvre sur une fenêtre de 30 jours. Quand vous branchez de vraies données, vérifiez que vos dates tombent dans la plage d’ouverture de la page, sinon le tableau paraîtra vide.

Regardez les boutons de plage du graphique des revenus (jour, semaine, mois, année) : votre API devra répondre pour chaque plage, ou vous pouvez retirer celles que vous ne gérez pas.

Regardez les graphiques en mode clair : ils suivent la couleur de marque et le thème, et leurs libellés sont traduits.

Pour Kestrel, l’ordre de connexion ressemble à ceci, et vous pouvez en reprendre le schéma pour votre produit :

1. L’utilisateur. Un appel qui renvoie le nom et la photo de la personne connectée, pour que le menu de l’en-tête cesse d’afficher le profil factice.
2. Les transactions. Une lecture pour le tableau, qui respecte la plage de dates, plus les chiffres clés au-dessus.
3. Les cartes. Une lecture pour la liste et les détails de la carte sélectionnée, puis des écritures pour verrouiller et supprimer.
4. Analytics. La série des revenus et dépenses pour chaque plage, la répartition par catégorie et l’activité hebdomadaire.
5. Settings. L’enregistrement du profil et des préférences, pour que Save Changes serve enfin à quelque chose.

Une bonne façon de planifier l’API consiste à prévoir une lecture par widget, plus une écriture par action que vous gardez. Commencez par les lectures, car elles débloquent les écrans, puis ajoutez les écritures dans l’ordre où les clients en ont besoin. Les données d’exemple sont une description toute faite de la forme attendue par chaque écran.

Ce qu’il faut vérifier : après avoir remplacé un widget, rechargez dans les deux langues et avec un résultat vide, pour voir l’état vide. Ce qui tourne souvent mal : une API qui renvoie les montants sous forme de texte, ce qui casse le tri. Renvoyez des nombres et formatez-les dans la page.

6. Remplacez la connexion factice

Le compte utilisé à l’étape 2 est vérifié dans le navigateur, et ses identifiants figurent dans le code que chaque visiteur télécharge. Chaque page sous /dashboard renvoie vers /login toute personne non connectée, mais cette vérification s’exécute aussi dans le navigateur. Pour un produit financier, c’est un substitut, pas une protection.

Avant que de vrais clients ou de vraies données d’argent n’arrivent sur le site, branchez la connexion sur une API à vous et vérifiez la session côté serveur. Redux Toolkit garde l’utilisateur connecté dans l’application, et le menu de l’en-tête affiche l’utilisateur renvoyé par votre API (aujourd’hui, il affiche le compte factice, John Carter, défini dans src/config/demo-account.ts). La documentation du template contient le code à modifier et un exemple détaillé pour cela. Gardez les secrets sur votre serveur : une valeur NEXT_PUBLIC_ est lisible par tous les visiteurs.

Les boutons Apple et Google, Remember me et Forgot password ne font encore rien, demandez-vous donc si votre méthode de connexion en a besoin. Retirez ceux qui ne servent pas.

Ce qu’il faut vérifier : ouvrez une fenêtre privée et visitez directement une adresse du dashboard. Vous devriez arriver sur la page de connexion. Ce qui tourne souvent mal : la redirection côté navigateur fonctionne, la page semble donc protégée alors que les données derrière ne le sont pas. Protégez toujours l’API.

7. Vérifiez la version arabe

Ouvrez /ar. La mise en page définit lang="ar" et dir="rtl", donc la barre latérale passe sur le bord droit et chaque carte, tableau et menu est en miroir. Le texte arabe utilise Noto Sans Arabic et l’anglais utilise Inter. Ouvrir / envoie le visiteur sur /ar si son navigateur préfère l’arabe, et sur /en sinon.

Les textes sont répartis par page dans messages/, chaque dossier contenant un en.json et un ar.json. Quand vous ajoutez du balisage, utilisez des classes logiques comme ms-2, pe-4 et text-start ; les classes physiques comme ml-2 cassent la page de droite à gauche. Testez aussi l’export CSV en arabe. Excel ouvre le fichier avec le texte arabe intact, et les montants commencent par + ou -.

Ce qu’il faut vérifier : chaque page que vous avez modifiée, dans /ar, avec des noms de longueur réelle et de longs nombres. Ce qui tourne souvent mal : du texte ajouté uniquement dans en.json, ce qui laisse une clé manquante en arabe.

8. Faites les vérifications avant lancement

Construisez la version de production et regardez-la comme un client le fera :

yarn build
yarn start

Ouvrez-la sur un téléphone autant que sur un ordinateur portable, dans les deux langues et les deux thèmes. Désactivez le mode démo : quand NEXT_PUBLIC_DEMO_MODE vaut true, la page de connexion affiche les identifiants de la démo, les remplit et ajoute un sélecteur de couleur flottant. Il est désactivé par défaut. Rappelez-vous aussi que la carte du monde de la vue d’ensemble récupère les contours des pays sur cdn.jsdelivr.net, et reste donc vide derrière un pare-feu qui bloque cette adresse.

Les commandes de développement et de production diffèrent sur un point utile : yarn start sert le dernier build, relancez donc yarn build après chaque modification. Quand des erreurs apparaissent que votre code n’explique pas, supprimez le dossier .next et reconstruisez.

Servez-vous de cette passe comme d’une courte répétition du jour du lancement. Parcourez tout le trajet du client une fois, lentement :

1. Ouvrez la page d’accueil et entrez dans le dashboard comme le ferait un nouveau client.
2. Cherchez dans les transactions, restreignez-les avec la plage de dates et exportez le fichier. Ouvrez-le dans un tableur.
3. Verrouillez et déverrouillez une carte, puis rechargez pour voir ce qui est conservé. Tout ce qui revient en arrière est un endroit pour votre API.
4. Passez à l’arabe et refaites le même parcours.
5. Réduisez la fenêtre à une largeur de téléphone et cherchez les chiffres ou les boutons coupés.

Notez chaque surprise. Chacune deviendra soit une correction, soit un bouton masqué, soit une ligne dans vos notes de support.

9. Mettez-le en ligne

Rien à configurer : pas de base de données, pas de secret, pas de variable obligatoire. Le déploiement est court. Vous avez trois voies :

• Vercel. Poussez le dossier dans un dépôt Git privé (la licence n’autorise pas un code source public), importez-le, gardez les réglages Next.js par défaut et ajoutez ENABLE_EXPERIMENTAL_COREPACK avec la valeur 1 pour que Vercel utilise la version de Yarn fixée. Ajoutez ensuite votre domaine.
• Un serveur Node.js. Utilisez Node.js 20.9 ou plus récent, puis installez, construisez et démarrez. Il écoute sur le port 3030, placez donc Nginx ou Caddy devant pour servir votre domaine en HTTPS, et maintenez yarn start actif avec un gestionnaire de processus. Sur un hébergeur qui impose le port, utilisez yarn start -p $PORT.
• Docker. Le Dockerfile inclus construit une petite image qui s’exécute avec un utilisateur sans droits d’administrateur.

Après toute modification d’une valeur NEXT_PUBLIC_, reconstruisez. Ces valeurs sont intégrées au moment du build de l’application.

Ce qu’il faut vérifier : chargez l’adresse en ligne, changez de langue, changez de thème et connectez-vous avec votre vraie méthode. Ce qui tourne souvent mal : un hébergeur qui impose son propre port alors que yarn start continue d’écouter sur le 3030.

Au quotidien

Après le lancement, l’essentiel du travail est modeste et répétable.

• Brancher un autre widget. Choisissez un widget, remplacez son fichier d’exemple par un appel à votre API, testez dans les deux langues et livrez-le séparément.
• Modifier un texte. Éditez la valeur dans le bon en.json et dans le ar.json correspondant, en gardant les clés telles quelles et en ne touchant pas à ce qui est entre accolades. Redémarrez yarn dev ou reconstruisez.
• Ajouter une langue. Ajoutez le code dans src/i18n/routing.ts, copiez en.json dans chacun des huit dossiers de messages/, traduisez les valeurs, et ajoutez la langue au menu dans src/components/LanguageSelector.tsx. Seul l’arabe est traité de droite à gauche, donc une autre langue de droite à gauche demande quelques modifications de plus.
• Changer l’accent. Modifiez une ligne, DEFAULT_THEME_COLOR, et reconstruisez.
• Répondre au support. Un client qui « perd » ses préférences a généralement effacé les données de son navigateur, car le navigateur retient l’ordre des chiffres clés et le choix du thème, navigateur par navigateur.
• Mettre à jour les dépendances. Les dépendances ont des versions exactes, avec un fichier de verrouillage dans le téléchargement. Changez une version volontairement, testez le build, et utilisez Yarn pour que le fichier de verrouillage garde la main.

Ce que coûte l’exploitation

Le template est un achat unique à partir de $99, avec un support à vie indiqué sur la page du produit. Faire tourner le front end lui-même ne coûte que l’hébergement.

La ligne la plus lourde, c’est ce que vous construisez derrière. Vous payez l’API, la base de données, le service de connexion et tout ce qui déplace ou lit de l’argent, chacun aux tarifs de son fournisseur. Vérifiez ce qu’exigent votre partenaire de paiement ou bancaire et votre régulateur avant d’afficher de vrais soldes. Le template n’inclut rien de tout cela.

Ce qui ne coûte rien : pas de base de données à licencier, pas de service obligatoire, et les données d’exemple fonctionnent hors ligne (hormis les formes de la carte et les polices téléchargées au moment du build).

Quoi personnaliser ensuite

• L’accent. Essayez les quatre thèmes (orange, bleu, doré, argenté) et choisissez celui qui va avec la marque. Les graphiques, les boutons et le visuel des cartes le suivent.
• Devise et catégories. Remplacez les catégories d’exemple par celles que les freelances utilisent vraiment, comme la réserve pour les impôts, les logiciels et les déplacements.
• La page d’accueil. La page à /en affiche le nom du produit, trois vignettes et un bouton Enter Dashboard. Réécrivez-la comme votre point d’entrée.
• Plus d’écrans. La page UI Components liste les éléments (tableaux, boîtes de dialogue, panneaux, onglets, sélecteurs de date), de sorte qu’une nouvelle page comme Invoices peut être assemblée avec eux dans le même style.
• Une troisième langue. Ajoutez le code dans src/i18n/routing.ts, copiez chaque en.json dans les huit dossiers de messages, et ajoutez-la au menu des langues.

Liste de contrôle de lancement

• Le compte factice supprimé et une vraie connexion branchée, avec la session vérifiée côté serveur.
• Chaque widget conservé lit votre API, et chaque bouton conservé enregistre quelque part.
• Les boutons que vous ne construirez pas sont masqués ou supprimés.
• NEXT_PUBLIC_DEMO_MODE est désactivé.
• Nom, logo, favicon, couleur et mention du pied de page changés.
• Tout nouveau texte existe à la fois dans en.json et dans ar.json.
• Chaque page modifiée vérifiée dans /ar, en mode clair et sombre, sur un téléphone.
• Build de production lancé avec yarn build et testé avant le déploiement.
• Domaine, HTTPS et réglages d’hébergement en place.
• Exigences de votre partenaire et de votre régulateur pour les données d’argent confirmées.

Erreurs courantes

Livrer la connexion factice

Le compte du template est public par conception. Quiconque ouvre le code source de la page peut le trouver. Remplacez-le avant le lancement.

Croire que les boutons enregistrent des données

Add Card, Add Transaction et Save Changes ne font rien côté serveur, puisqu’il n’y a pas de serveur. Branchez chacun de ceux que vous gardez et masquez ceux que vous ne construirez pas.

Laisser le mode démo activé

Le mode démo affiche des identifiants de démonstration sur la page de connexion. Gardez NEXT_PUBLIC_DEMO_MODE désactivé pour un vrai produit.

Oublier de reconstruire après un changement de réglage

Avec yarn start ou Docker, une valeur NEXT_PUBLIC_ modifiée ne fait rien tant que l’application n’est pas reconstruite.

Reprendre le comportement de la carte d’exemple pour de vraies données de carte

La page Your Cards a une commande pour afficher le numéro, et elle fonctionne sur des numéros d’exemple inventés. Avant que de vraies données de carte ne circulent vers le navigateur, demandez à votre fournisseur de cartes ou de paiement ce qu’il autorise, et concevez ce que l’écran affiche (souvent seulement les derniers chiffres) à partir de cette réponse.

Cacher le problème au lieu du bouton

Un bouton qui ne fait rien apprend aux clients à se méfier de la page. Si une action n’est pas encore construite, retirez-la de l’écran jusqu’à ce qu’elle le soit, plutôt que de la laisser échouer en silence.

Tester uniquement en anglais

Les nombres, les dates et les libellés longs se comportent différemment dans les mises en page de droite à gauche. Ouvrez chaque page modifiée dans /ar avant de la considérer comme terminée.

FAQ

Comment créer un dashboard fintech avec Next.js ?

Partez d’une interface terminée, puis branchez vos données. Ce template fournit les pages, les graphiques et les formulaires, et vous connectez une API pour les soldes, les cartes et les transactions, plus une vraie connexion.

Ai-je besoin d’un back end ?

Oui, pour tout ce qui est réel. Le template n’a ni back end ni base de données, donc un produit en production demande votre propre API. Les données d’exemple permettent de concevoir et de faire des démos sans elle.

Peut-il se connecter à une banque ou afficher de vrais comptes ?

Pas tout seul. Il affiche ce que renvoie votre API. Toute connexion bancaire, tout service de cartes ou fournisseur de paiement s’ajoute de votre côté, sur le serveur.

Prend-il en charge l’arabe et le RTL ?

Oui. Chaque libellé, légende de graphique, en-tête de tableau et message de formulaire existe en anglais et en arabe, et les pages arabes s’affichent de droite à gauche.

Quels graphiques utilise-t-il ?

Recharts dessine les graphiques en aires, en barres, en anneau et de type carte de chaleur, et chacun peut être téléchargé en PNG. Le tableau des transactions est construit avec TanStack Table.

Puis-je l’utiliser pour des clients ?

Oui. La licence commerciale couvre un nombre illimité de projets, y compris le travail livré à un client. Vous ne pouvez pas partager le code source publiquement ni le revendre comme template.

La connexion est-elle sécurisée d’origine ?

Non. C’est un substitut vérifié dans le navigateur, à remplacer par une connexion reliée à votre propre API avant que de vrais clients ne l’utilisent.

A-t-il un mode sombre et un mode clair ?

Oui. Les deux sont terminés, le dashboard démarre en sombre, et le navigateur retient le choix de chaque personne. La couleur d’accent de la marque est un réglage distinct.

Puis-je exporter des données depuis le dashboard ?

Oui. La page des transactions exporte un fichier CSV pour la plage de dates et les filtres choisis, et les graphiques peuvent être enregistrés en images PNG. Les deux fonctionnent dans le navigateur avec les données d’exemple.

Essayez-le vous-même

Ouvrez la démo en ligne pour voir chaque page. La page produit de Financial Dashboard donne les détails, et la documentation couvre chacune des étapes ci-dessus. Pour d’autres dashboards, parcourez la catégorie des templates de panneau d’administration, ou lisez comment les dashboards arabes et RTL sont gérés.

Ce template fait aussi partie des dix du Next.js Templates Bundle, si vous pensez construire plus d’un type de produit.