Comment créer un dashboard admin avec assistant IA en Next.js

À la fin de ce guide, vous aurez un panneau d’administration interne avec un assistant IA qui tourne sur votre ordinateur et qui est prêt pour un serveur. C’est un dashboard Next.js avec sa propre API derrière, et vous le construisez à partir du template Admin Dashboard Template 2 d’Aniq UI au lieu de partir d’un dossier vide.

Les étapes valent pour un panneau d’administration SaaS, un back-office de petite entreprise ou n’importe quel outil interne où une équipe a besoin de listes, de rôles et d’un moyen de poser des questions sur ses propres données. Pour rester concret, nous suivons une entreprise fictive pendant tout le travail, du premier téléchargement jusqu’à une adresse en ligne, et nous nous arrêtons à chaque endroit où les choses tournent mal d’habitude.

Avant de commencer : les décisions à prendre

La plupart des difficultés d’un outil interne viennent de choix faits trop tard. Réglez ces six points avant d’ouvrir un terminal, et le reste du guide ira plus vite.

• Qui se connecte, et que peut faire chaque personne ? Écrivez d’abord la liste des rôles sur papier. Le template en fournit cinq (Super Admin, Admin, Manager, Editor, Viewer) et vous pouvez les remodeler, mais c’est plus simple avec un plan.
• Quels sont vos enregistrements ? Le template contient des utilisateurs, des projets, des tâches et des paramètres d’application. Si votre activité tourne autour d’autre chose, comme des commandes ou des tickets, décidez dès maintenant si vous renommez l’existant ou si vous ajoutez un nouveau module à l’API.
• Quelles langues ? L’anglais et l’arabe sont fournis. Une troisième langue est possible mais demande plus de travail, alors sachez avant de commencer si vous en avez besoin.
• Qui paie l’IA ? Soit l’entreprise garde une clé de fournisseur sur le serveur, soit chaque personne apporte la sienne. Ce choix change votre facture et votre politique de confidentialité, et l’étape 8 traite les deux cas.
• Où va-t-il tourner ? Sur un petit serveur avec Docker, ou sur Vercel pour le dashboard avec l’API sur un hôte Docker. Choisissez la forme tôt pour régler les bonnes adresses une seule fois.
• Quelle base de données ? SQLite est le choix par défaut et ne demande aucune installation. MySQL est un changement de configuration. Un hébergeur sans disque persistant est la raison habituelle de choisir MySQL.

Le cahier des charges

Larkspur Software est une petite agence qui crée des applications web pour d’autres entreprises. Le bureau a besoin d’un seul endroit pour gérer son travail. Voici ce que demande l’équipe :

• Une connexion pour le personnel, avec différents niveaux d’accès : le propriétaire voit tout, les développeurs modifient les projets, les prestataires externes lisent seulement.
• Une liste de tous les projets clients, avec leur statut, leur environnement (staging ou production) et leur version actuelle.
• Une liste des comptes clients, avec un moyen rapide de trouver ceux qui n’ont jamais vérifié leur e-mail.
• Un assistant qui répond à des questions simples comme « quels projets sont bloqués ? » et affiche la réponse sous forme de tableau ou de graphique.
• L’anglais et l’arabe, parce que deux équipes clientes lisent l’arabe.
• Un premier essai sur un ordinateur portable, puis un petit serveur sur le domaine de l’agence.
• Un contrôle sur qui peut utiliser l’assistant, puisqu’il peut modifier des enregistrements et que le fournisseur d’IA facture à l’usage.

Comment le template couvre ce cahier des charges

Besoin	Où ça se trouve	Ce que vous utilisez
Personnel avec des accès différents	Dashboard et API	Écrans Admin Management et Admin Roles ; permissions nommées comme projects.edit
Suivi des projets clients	Dashboard et API	Écran Projects avec statut, environnement, version et nom en anglais et en arabe
Comptes clients	Dashboard et API	Écrans Users et Deleted users, filtres, actions de vérification et de restauration
Questions en langage courant	Dashboard et API	Écran AI Assistant, avec une clé de fournisseur à fournir par vous
Anglais et arabe	Dashboard	Adresses /en et /ar, fichiers de messages dans messages/
Portable, puis un serveur	Docker et configuration	Docker Compose, fichiers .env, un serveur web devant
Contrôle de l’assistant	API	La permission ai_chat.use sur un rôle

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

Il y a trois façons honnêtes d’obtenir un panneau d’administration avec un assistant IA, et chacune convient à une équipe différente.

Développer from scratch. Vous obtenez exactement la structure voulue et rien de plus. Vous devez aussi construire la connexion, les rôles avec mise à jour en direct, les listes filtrées, une interface de chat qui affiche des tableaux et des graphiques, et l’API qui se trouve derrière. Cela convient aux équipes qui ont un produit atypique et beaucoup de temps d’ingénierie. Pour tous les autres, cela veut dire passer longtemps sur des écrans dont tout panneau d’administration a besoin.

Un outil hébergé. Un service low-code ou d’outils internes vous donne vite un écran qui fonctionne et s’occupe de l’hébergement. En échange, vous travaillez dans son jeu de composants et son modèle tarifaire, et partir plus tard oblige en général à tout reconstruire. Vérifiez ce qu’il facture par utilisateur, ce que vous pouvez exporter et s’il gère les mises en page de droite à gauche avant de vous engager.

Un template avec le code source. Vous partez d’écrans terminés, d’une API qui fonctionne et d’un assistant, et le code est à vous. Vous payez le template une fois, vous l’hébergez vous-même et vous changez ce que vous voulez. Le prix à payer, c’est qu’il faut être à l’aise avec Next.js, puis avec NestJS si vous étendez l’API. La licence n’autorise ni la publication ni la revente du code source, mais elle couvre un nombre illimité de projets, y compris ceux de clients.

Larkspur a des développeurs dans l’équipe et veut garder les données de ses clients sur son propre serveur, elle choisit donc le template. Si personne dans votre équipe n’écrit de code, un outil hébergé est le choix le plus réaliste.

Un exemple de plan de lancement, semaine par semaine

Voici un calendrier type pour Larkspur, pas une référence. Votre rythme sera différent.

• Semaine 1, le faire tourner. Téléchargez le ZIP, lancez-le avec Docker, parcourez chaque écran et essayez les deux comptes d’exemple. Tranchez les six questions ci-dessus.
• Semaine 2, se l’approprier. Appliquez votre marque, reconstruisez les rôles, créez les vrais comptes du personnel et supprimez les administrateurs d’exemple.
• Semaine 3, charger le travail. Saisissez les vrais projets et comptes clients, ajoutez les clés de fournisseur et laissez deux ou trois personnes utiliser l’assistant avec de vraies questions.
• Semaine 4, renforcer et publier. Définissez les valeurs d’environnement de production, déployez sur le serveur, vérifiez l’adresse de santé et passez en revue la liste de contrôle de lancement vers la fin de cet article.

Pas à pas

1. Choisir le package

Le template existe en trois packages. Le package Full Stack contient le dashboard et l’API NestJS. Le package Admin Dashboard est le dashboard seul, qui fonctionne avec un petit serveur factice intégré et garde les enregistrements d’exemple dans votre navigateur. Le package Backend API est l’API seule.

Larkspur veut de vraies données et un vrai assistant, elle prend donc Full Stack. Si vous voulez d’abord seulement dessiner des écrans, le package Admin Dashboard suffit, et vous pourrez le brancher à une API plus tard. Si vous avez déjà un front-end et qu’il vous faut seulement le serveur, le package Backend API vous donne les routes, la logique des rôles et les outils de l’assistant.

À vérifier : après le téléchargement, votre compte doit afficher un ZIP portant le nom du package acheté. Ce qui tourne mal d’habitude : acheter le package dashboard en pensant qu’il contient une API. Le dashboard seul ne peut rien stocker en dehors du navigateur.

2. Le lancer en local avec Docker

Installez Docker Desktop (ou Docker Engine sous Linux) et rien d’autre. Suivez ensuite ces sous-étapes.

2a. Télécharger. Ouvrez My templates dans votre compte Aniq UI et téléchargez le ZIP Full Stack.

Regardez quel package est sélectionné sur la page de téléchargement, car les noms de dossiers des étapes suivantes en dépendent.

2b. Décompresser et ouvrir le dossier. Décompressez l’archive et ouvrez un terminal dans le dossier dashboard-2-full-stack (sous Windows, décompressez-la d’abord avec l’Explorateur de fichiers).

Regardez le contenu du dossier : vous devriez voir back-end, front-end et docker-compose.yml côte à côte.

2c. Démarrer les deux applications.

docker compose up --build

Au premier démarrage, Docker construit deux images et remplit la base de données, prévoyez donc quelques minutes. Les démarrages suivants prennent quelques secondes.

Regardez le terminal : il affiche d’abord la progression de la construction, et le dashboard attend que l’API se déclare en bonne santé.

2d. L’ouvrir. Allez sur localhost:3030 et utilisez le compte admin@example.com avec le mot de passe Admin@123. L’arabe se trouve sur /ar. L’API répond sur localhost:8000/api/health dès que sa base de données est prête.

Ce qu’il faut vérifier : l’adresse de santé doit répondre et le dashboard doit afficher des données sur son premier écran. Ce qui tourne mal d’habitude : un port déjà utilisé. Si un autre programme occupe le 3030 ou le 8000, créez un fichier nommé .env à côté de docker-compose.yml et définissez DASHBOARD_PORT=3040 (ou API_PORT pour l’API), puis relancez la même commande. Un démarrage qui semble bloqué est normalement en train de charger les données d’exemple.

Pour arrêter les applications, appuyez sur Ctrl+C. Vos données restent dans un volume Docker. Attention à docker compose down -v : le -v supprime le volume, et le démarrage suivant ramène des données d’exemple neuves.

3. Connaître les autres façons de le lancer

Vous ne les utiliserez pas toutes, mais chacune répond à une situation réelle.

Le dashboard seul. Avec le package Admin Dashboard, vous construisez une image et démarrez un conteneur. Sans adresse d’API définie, il fonctionne sur son serveur factice et n’a pas besoin de back-end.

Regardez le nom du dossier dans le terminal : ce package s’extrait dans un dossier différent de celui du Full Stack.

Regardez la sortie de la construction : les dépendances et la compilation se font toutes deux dans l’image, donc la première construction demande une connexion à internet.

L’API seule. Avec le package Backend API, vous construisez une image et la lancez avec un volume qui contient le fichier de base de données. Le premier lancement remplit cette base avec les enregistrements et les comptes d’exemple. Toutes les routes se trouvent sous /api, et vous les vérifiez avec l’adresse de santé.

Regardez les fichiers du dossier, parmi lesquels un Dockerfile, package.json et .env.example.

Regardez l’image en cours de construction : l’image de l’API est distincte de celle du dashboard.

Regardez le contrôle de santé à la fin : une API qui fonctionne répond avec le statut ok.

Sans Docker. Installez Node.js 22.9 ou plus récent et lancez corepack enable une fois. Démarrez l’API en premier, car le dashboard lit toutes ses données chez elle. Dans back-end, copiez les paramètres d’exemple, créez la base de données avec yarn seed, puis lancez yarn dev. Dans front-end, copiez les paramètres d’exemple et démarrez-le de la même façon.

Regardez le premier terminal, celui qui exécute l’API.

Regardez le second terminal, qui exécute le dashboard face à l’API du premier.

La même méthode vaut pour les packages à une seule application.

Regardez le peu qu’il faut ici : sans fichier .env, c’est le serveur factice qui répond.

Regardez le terminal de l’API qui reste ouvert pendant que vous l’utilisez.

Ce qui tourne mal d’habitude : un Node.js plus ancien que la 22.9, qui fait échouer yarn dev à la lecture de .env ; un Yarn qui répond en version 1.22 parce que Corepack est désactivé ; et un dashboard qui affiche des données d’exemple alors que vous vouliez utiliser votre API, parce que l’adresse de l’API manquait au moment de la construction.

4. Explorer les données d’exemple avant de rien changer

Le jeu de départ charge de quoi faire une petite entreprise : une douzaine d’administrateurs, cinq rôles portant 25 permissions, 15 utilisateurs, 15 projets, 10 tâches et 13 paramètres d’application, plus quelques utilisateurs et projets supprimés pour s’exercer à la restauration. Parcourez la barre latérale de haut en bas, jusqu’à la page qui liste tous les composants d’interface.

Regardez comment la barre latérale regroupe les écrans, car vous renommerez et élaguerez ce menu plus tard.

Regardez le haut de la vue d’ensemble : chiffres clés, graphiques, calendrier et tâches rapides partagent un même écran, et les widgets peuvent être réorganisés.

Déconnectez-vous ensuite et reconnectez-vous avec john.smith@admin.com et le mot de passe admin123. Ce compte a le rôle Viewer. Il peut lire toutes les listes mais ne peut rien créer, modifier ni supprimer, et il ne peut pas ouvrir l’assistant. Voir cette différence tôt vous montre comment se comporte le système de permissions, ce qui compte pour l’étape 6.

À vérifier : vous savez expliquer en une phrase chacun ce que peuvent faire Super Admin et Viewer. Ce qui tourne mal d’habitude : on modifie d’abord les enregistrements d’exemple, puis on oublie lesquels sont de vraies données. Laissez les données d’exemple intactes jusqu’à ce que vous soyez prêt à les remplacer en bloc.

5. Mettre le nom de l’agence dessus

Toute l’image de marque se trouve dans le dossier du dashboard (front-end dans le package Full Stack). Lancez yarn dev dedans pendant vos modifications et la page se recharge à chaque enregistrement. Quatre endroits comptent le plus :

• src/config/brand.config.ts contient BRAND_CONFIG : le nom, l’entreprise, les métadonnées de la page et les détails de l’application installée, en anglais et en arabe.
• public/assets/images/logo-for-lightmode.png et logo-for-darkmode.png sont les deux logos. Remplacez les fichiers en gardant les noms.
• src/styles/theme-variables.css définit chaque couleur une fois pour le mode clair et une fois pour le mode sombre. La couleur de la marque est --primaryColor.
• messages/<namespace>/en.json et ar.json contiennent chaque mot affiché à l’écran. Modifiez les deux langues ensemble.

Larkspur change le nom, remplace les deux logos et choisit une nouvelle couleur principale. Cela suffit pour que le dashboard lui ressemble. Les composants lisent les couleurs par des variables comme bg-[var(--surface)], donc tout composant ajouté plus tard garde les deux thèmes s’il fait de même.

Regardez la page des composants : c’est le moyen le plus rapide de voir votre nouvelle couleur sur tous les types de contrôles à la fois.

À vérifier : basculez entre clair et sombre dans l’en-tête, puis ouvrez la page des composants dans les deux. Ce qui tourne mal d’habitude : un logo avec une couleur de fond incrustée qui rend mal dans un des thèmes. Exportez les deux logos avec un fond transparent.

6. Configurer le personnel et les rôles

Le jeu de départ fournit cinq rôles : Super Admin, Admin, Manager, Editor et Viewer. Une personne peut avoir plus d’un rôle et reçoit alors les permissions combinées de tous. Les permissions s’écrivent module.action, par exemple users.view, projects.edit ou settings.edit, et il y en a 25 réparties entre administrateurs, rôles, utilisateurs, projets, paramètres et l’assistant.

Larkspur répartit son équipe ainsi : le propriétaire reste Super Admin, les deux chefs de projet deviennent Manager, les développeurs deviennent Editor et les prestataires externes deviennent Viewer. Procédez en trois passes :

1. Ouvrez Admin Roles et lisez ce que chaque rôle accorde. Renommez ou élaguez jusqu’à ce que les rôles correspondent au plan sur papier.
2. Ouvrez Admin Management et créez chaque vraie personne, puis attribuez-lui ses rôles.
3. Connectez-vous en tant qu’une personne par rôle et essayez les actions que ce rôle doit et ne doit pas pouvoir faire.

Si vous modifiez un rôle pendant que quelqu’un est connecté, ses menus et ses boutons se mettent à jour sans rechargement, car l’API prévient son dashboard par WebSocket.

Regardez les pastilles de rôle sur chaque compte : elles montrent d’un coup d’œil qui détient quel rôle.

Regardez comment les permissions sont groupées par module, ce qui permet d’accorder « voir » sans « modifier ».

Avant tout, changez les mots de passe des administrateurs d’exemple dans Settings, Security, ou supprimez ces comptes. Le jeu de départ les crée avec des mots de passe imprimés dans la documentation publique, et les guides du template le répètent à raison.

Ce qui tourne mal d’habitude : supprimer le Super Admin avant qu’un autre administrateur puisse gérer les rôles, ou donner le rôle Admin à tout le monde parce que c’est plus simple. Commencez strict et assouplissez quand quelqu’un le demande.

7. Charger les projets et les comptes clients

Ouvrez Projects et remplacez les lignes d’exemple par le vrai travail de Larkspur. Un projet porte un nom et une description en anglais et en arabe, un statut (in-progress, ready ou blocked), un environnement, une version et une image facultative. La suppression est une suppression logique : les projets supprimés passent dans leur propre écran et peuvent être restaurés.

Les utilisateurs fonctionnent de la même façon. Vous pouvez restreindre la liste par nom d’utilisateur, e-mail, téléphone, nom ou date d’inscription, et le haut de la page compte les comptes vérifiés, non vérifiés et supprimés. Pour Larkspur, c’est l’écran du personnel client qui a reçu une invitation sans jamais la confirmer. La route de renvoi de vérification répond par un succès mais n’envoie aucun e-mail, alors branchez votre propre service d’e-mail avant de compter dessus.

Regardez les compteurs au-dessus du tableau et les pastilles de statut sur chaque ligne.

Si votre propre produit a d’autres enregistrements, l’API est du REST simple sous /api, vous pouvez donc ajouter des modules à côté de ceux qui existent. Connectez-vous avec POST /api/auth/login pour obtenir le jeton dont tous les autres appels ont besoin, et envoyez-le comme bearer token. Les listes acceptent page et page_count, plafonnés à 100 par page.

À vérifier : créez un projet en anglais et en arabe, rechargez, et confirmez que les deux noms apparaissent quand vous changez de langue. Ce qui tourne mal d’habitude : ne remplir que le nom anglais, ce qui laisse un libellé vide dans la liste arabe.

8. Activer l’assistant IA

L’assistant a son propre écran. Vous tapez une question en anglais ou en arabe et la réponse est construite à partir des données du dashboard, dessinée avec les mêmes cartes de statistiques, tableaux, listes, graphiques en anneau et graphiques que le reste du panneau. Il peut aussi agir : ajouter, modifier, supprimer ou rétablir des utilisateurs, et ajuster les paramètres de l’application. Il ne le fait que dans les limites des permissions de la personne qui pose la question.

Il fonctionne avec Google Gemini, OpenAI ou DeepSeek, choisis dans un sélecteur de modèle. Les conversations sont enregistrées par administrateur dans une barre latérale d’historique. Vous avez deux façons de fournir une clé :

• Mettez la clé du fournisseur dans back-end/.env et redémarrez l’API (avec Docker Compose, relancez docker compose up). Tous ceux qui ont accès utilisent alors votre clé.
• Laissez le serveur sans clé. L’assistant demande alors sa propre clé à chaque personne, et elle reste dans son navigateur.

Larkspur commence avec la seconde option, pour que l’usage de personne ne finisse par accident sur la facture de l’agence. La documentation indique que Gemini fonctionne avec des clés gratuites, alors qu’OpenAI exige que la facturation soit activée sur la clé. Une clé gratuite peut épuiser son quota, et l’assistant le signale ; choisissez un autre modèle ou attendez.

Contrôlez l’accès avec la permission ai_chat.use. Comme l’assistant peut écrire, ne l’accordez qu’aux rôles à qui vous confieriez ces écritures. Les prestataires externes au rôle Viewer n’en reçoivent aucune.

Regardez comment la réponse mêle un résumé écrit et un graphique construit à partir des propres chiffres du dashboard.

Deux extras facultatifs existent. Un bucket Cloudflare R2 permet d’envoyer des photos de profil et des images en pièce jointe ; sans lui, les envois répondent qu’ils ne sont pas configurés et tout le reste fonctionne. Une clé MCP de votre choix active le endpoint MCP de l’API ; sans elle, ce endpoint refuse toutes les requêtes.

À vérifier : posez trois questions dont vous connaissez déjà la réponse, comme le nombre de projets bloqués, et comparez. Ce qui tourne mal d’habitude : la boîte de dialogue qui demande une clé d’API, qui signifie seulement que le serveur n’a pas de clé pour le modèle choisi. Collez la vôtre, ou ajoutez la clé du fournisseur au fichier du serveur et redémarrez.

9. Vérifier l’arabe et les autres détails de langue

Ouvrez /ar. La page définit lang="ar" et dir="rtl" avant de s’afficher, donc la barre latérale passe à droite et les tableaux et les menus se lisent de droite à gauche. L’API répond aussi en arabe quand une requête envoie Accept-Language: ar, et les projets, les paramètres et les pays portent les deux langues dans la base de données.

Tout ce que vous ajoutez doit utiliser des classes Tailwind logiques comme ms-2, pe-4, start-0 et text-start au lieu de ml-*, pr-*, left-* ou text-left, sinon la page arabe s’affiche mal. Si une troisième langue devient un jour nécessaire, vous ajoutez son code dans trois listes de langues, vous copiez chaque fichier en.json sous le nouveau code et vous l’ajoutez au menu des langues. L’API continue de répondre en anglais pour une nouvelle langue tant que vous n’ajoutez pas ses traductions dans back-end/src/i18n/.

À vérifier : parcourez en arabe chaque écran que vous avez modifié, assistant compris. Ce qui tourne mal d’habitude : un texte ajouté seulement à en.json, de sorte que la page arabe affiche une clé manquante.

10. Mettre en ligne sur un serveur

Le même docker-compose.yml qui a tourné sur le portable tourne aussi sur un serveur. Donnez au dashboard et à l’API chacun un domaine derrière Caddy ou Nginx, qui ajoute le HTTPS, et dirigez le premier domaine vers le port 3030 (le dashboard) et le second vers le port 8000 (l’API).

Créez .env à côté de docker-compose.yml et définissez DASHBOARD_URL et API_URL avec les deux adresses publiques. Le dashboard intègre l’adresse de l’API dans son code compilé, et l’API reprend ces mêmes deux lignes pour CORS_ORIGIN et FRONTEND_URL. Mettez vos clés d’IA et TRUST_PROXY=1 dans back-end/.env. Démarrez ensuite en arrière-plan :

docker compose up --build -d

En production, l’API refuse de démarrer avec le JWT_SECRET d’exemple ou un CORS_ORIGIN vide. Avec Docker, elle génère un secret pour vous et le conserve dans le volume de données, ou vous pouvez créer le vôtre :

node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"

Quand tout est lancé, ouvrez https://api.your-domain.com/api/health (avec votre propre domaine) et cherchez "status":"ok". Si vous préférez, le dashboard seul peut aller sur Vercel depuis un dépôt Git privé : définissez ENABLE_EXPERIMENTAL_COREPACK à 1, puis NEXT_PUBLIC_API_BASE_URL, NEXT_PUBLIC_WEBSOCKET_BASE_URL et NEXT_PUBLIC_BASE_URL. Redéployez après avoir changé n’importe quelle valeur NEXT_PUBLIC_*, car elle est compilée au moment de la construction. Laissez NEXT_PUBLIC_DEMO_MODE désactivé, sauf si le site est une démo publique.

La base de données par défaut est SQLite, conservée dans le volume /data. MySQL est un changement de configuration : créez une base vide, définissez DB_TYPE et la connexion dans back-end/.env, puis chargez les données de départ. Choisissez MySQL si votre hébergeur n’a pas de disque persistant. Si vous lancez l’API sans Docker en production, yarn seed:prod crée les tables une fois ; ne l’exécutez qu’une seule fois, car une seconde exécution remet les paramètres de l’application et les permissions des rôles intégrés à leurs valeurs d’exemple.

À vérifier : connectez-vous depuis un autre ordinateur, changez un rôle et regardez une seconde session connectée se mettre à jour. Cela prouve que l’adresse du WebSocket est correcte. Ce qui tourne mal d’habitude : des pages vides avec une ligne CORS dans la console du navigateur. L’API ne répond qu’aux navigateurs venant des adresses de CORS_ORIGIN, ajoutez donc l’adresse réelle du dashboard à cet endroit et dans FRONTEND_URL.

Au quotidien

Une fois Larkspur en ligne, le travail se réduit à de petites routines répétables.

• Accueillir une personne. Créez l’administrateur dans Admin Management, attribuez-lui un rôle et envoyez-lui l’adresse. Ne partagez pas le compte Super Admin.
• Le départ. Supprimez le compte administrateur le jour même. Comme les rôles se mettent à jour en direct, vous pouvez aussi retirer un rôle à quelqu’un qui est encore connecté et ses boutons disparaissent sans rechargement.
• Changer ce qu’un rôle peut faire. Modifiez-le sur l’écran Admin Roles et prévenez l’équipe. Testez avec un vrai compte de ce rôle.
• Réparer les erreurs. Les utilisateurs et les projets sont supprimés de façon logique. Ouvrez l’écran Deleted correspondant pour en rétablir un.
• Sauvegardes. Avec SQLite dans Docker, les données vivent dans un seul volume. Sauvegardez ce volume à un rythme adapté à la fréquence des changements. Avec MySQL, utilisez l’outil de sauvegarde de votre hébergeur de base de données.
• Mises à jour. Après avoir modifié le code, reconstruisez les images, car un conteneur en cours d’exécution est un instantané du code au moment de la construction.
• Surveiller l’assistant. Vérifiez de temps en temps qui possède ai_chat.use.

Ce que coûte son fonctionnement

Le template est un achat unique à partir de $99, et le package compte : le package Full Stack utilisé dans ce guide coûte plus cher que le prix d’entrée, et la page du produit les liste tous. La licence couvre un nombre illimité de projets, travaux pour des clients compris, à condition de ne pas partager le code source publiquement.

Au-delà, vous payez ce que vous ajoutez :

• L’hébergement du dashboard et de l’API. Un serveur compatible Docker fait tourner les deux ; Vercel peut héberger le dashboard seul.
• L’usage de l’IA, si vous mettez une clé de fournisseur sur le serveur. Google, OpenAI et DeepSeek facturent selon leurs propres pages de tarifs. Si chaque personne apporte sa clé, la facture est la sienne.
• Un bucket Cloudflare R2, si vous voulez l’envoi d’images, et une clé WeatherAPI.com si vous voulez la météo dans le message d’accueil. Les deux sont facultatifs.
• Un nom de domaine et, si vous l’utilisez, un service d’e-mail pour les e-mails de vérification.

Ce qui est gratuit : le développement local avec SQLite, les données d’exemple, l’API factice intégrée au package dashboard et chaque fonction facultative que vous laissez désactivée.

Que personnaliser ensuite

• Des rôles qui correspondent à votre entreprise. Renommez les cinq rôles et élaguez leurs permissions jusqu’à ce que chacun n’accorde que ce que demande le poste.
• Vos propres enregistrements. Ajoutez un module à l’API NestJS pour quelque chose que Larkspur suit et qui n’est pas un projet, comme des factures ou des tickets de support, et un écran assorti. Chaque domaine de l’API a son propre module, un nouveau s’insère donc à côté des autres.
• De nouveaux outils pour l’assistant. L’assistant passe par un registre MCP conçu pour être étendu, vous pouvez donc lui apprendre des questions propres à vos données.
• Une troisième langue. Copiez les fichiers de messages, ajoutez le code aux trois listes de langues et ajoutez les traductions de l’API.
• Un code de production plus propre. Une fois que votre propre API est la source de données définitive, le script yarn remove:mock supprime le serveur factice intégré et yarn remove:demo retire l’interrupteur de démo publique. Faites un commit d’abord, car les deux réécrivent des fichiers.

Liste de contrôle de lancement

• Administrateurs d’exemple supprimés ou mots de passe changés.
• Votre propre JWT_SECRET défini, ou celui généré par Docker confirmé dans le volume de données.
• CORS_ORIGIN et FRONTEND_URL contiennent l’adresse réelle du dashboard.
• NEXT_PUBLIC_API_BASE_URL pointe vers l’API avec /api, et le dashboard a été construit après sa définition.
• HTTPS devant le dashboard et l’API.
• L’adresse de santé répond "status":"ok".
• Chaque rôle testé avec un vrai compte.
• ai_chat.use accordé uniquement là où c’est voulu, et clés de fournisseur placées là où vous l’avez décidé.
• Arabe vérifié sur chaque écran modifié.
• Sauvegarde du volume de données ou de la base de données planifiée.
• Mode démo désactivé.

Erreurs courantes

Passer en production avec les administrateurs d’exemple

Chaque jeu de départ crée des administrateurs avec des mots de passe publiés. Changez-les ou supprimez-les avant que quiconque puisse atteindre le panneau, et définissez votre propre JWT_SECRET.

Modifier une valeur NEXT_PUBLIC et attendre un changement

Ces valeurs sont compilées dans le dashboard lors de sa construction. Reconstruisez (ou relancez yarn dev) après toute modification, et n’y mettez jamais de secret : tout le monde peut les lire dans le navigateur.

Effacer les données avec la mauvaise commande d’arrêt

docker compose down conserve vos données. Ajouter -v supprime le volume, et tout ce que vous avez créé part avec.

Les pages restent vides et la console mentionne CORS

L’API ne répond qu’aux navigateurs venant des adresses de CORS_ORIGIN. Si le dashboard tourne sur un nouveau domaine ou un nouveau port, ajoutez-le à cet endroit et dans FRONTEND_URL.

Donner l’assistant à tout le monde

L’assistant peut modifier des utilisateurs et des paramètres. Accordez ai_chat.use aux rôles qui doivent avoir ce pouvoir et à personne d’autre.

Passer à Docker le fichier d’environnement d’exemple

L’image de l’API s’exécute en mode production. Si vous la démarrez avec une copie du fichier d’environnement d’exemple, ce fichier impose le mode développement par-dessus la valeur de l’image. Passez plutôt chaque valeur nécessaire avec -e.

FAQ

Comment créer un panneau d’administration avec un assistant IA en Next.js ?

Partez d’un dashboard qui a déjà les rôles, les listes et l’écran de chat, puis branchez vos données et un fournisseur de modèles. Dans ce template, l’assistant lit la même API que le reste du panneau : vous ajoutez une clé et vos enregistrements au lieu d’écrire la plomberie du chat.

Ai-je besoin d’un back-end ?

Seulement pour de vraies données. Le package Admin Dashboard fonctionne sur un serveur factice dans le navigateur, ce qui suffit pour un travail de design. Pour un panneau en production, il faut une API, et le package Full Stack en inclut une en NestJS.

Quels fournisseurs d’IA l’assistant gère-t-il ?

Google Gemini, OpenAI et DeepSeek, choisis dans une liste de modèles. Chaque personne peut coller sa propre clé, ou vous pouvez définir une seule clé sur le serveur.

Gère-t-il l’arabe et le RTL ?

Oui. Chaque écran, assistant compris, existe en anglais et en arabe, et les pages arabes sont disposées de droite à gauche.

Puis-je l’utiliser pour des clients ?

Oui. La licence commerciale couvre un nombre illimité de projets, y compris le travail que vous réalisez pour un client et que vous lui remettez. Vous ne pouvez ni publier le code source ni le revendre comme template.

Puis-je changer ce que l’assistant est autorisé à faire ?

Vous décidez qui peut l’utiliser grâce à la permission ai_chat.use, et l’assistant n’agit que dans les limites des permissions de cette personne. L’ajout de nouveaux outils passe par son registre MCP dans l’API.

Puis-je l’essayer sans rien installer ?

Oui. La démo en ligne fait tourner le même dashboard. Sur votre propre machine, le package Admin Dashboard fonctionne avec ses données d’exemple intégrées, sans API ni clé d’IA.

Puis-je retirer les données d’exemple et le serveur factice ?

Oui. Deux scripts, yarn remove:mock et yarn remove:demo, retirent du code le serveur factice et l’interrupteur de démo publique. Faites un commit d’abord, car ils réécrivent des fichiers.

Essayez-le vous-même

Ouvrez la démo en ligne pour parcourir le dashboard et l’assistant. La page produit d’Admin Dashboard Template 2 liste les packages, et la documentation détaille chacune des étapes ci-dessus. D’autres options se trouvent dans la catégorie des templates de dashboard d’administration, et le guide des templates de dashboard d’administration par secteur vous aide si votre cas diffère de celui-ci.

Ce template fait aussi partie des dix du Next.js Templates Bundle, si vous prévoyez de créer plus d’un type de produit.