Comment ajouter un panneau d'administration à une app créée avec Claude ou Cursor

Voici un schéma que j'ai vu des dizaines de fois cette année, et que j'ai moi-même vécu : vous ouvrez Claude ou Cursor, vous décrivez une app, et un week-end plus tard vous avez quelque chose de réel — une boutique en ligne, un outil de réservation, un site de contenu, un SaaS que vous repoussiez depuis des mois. L'IA a écrit le frontend, les routes, le schéma, tout.

Puis vient la partie que personne ne vous avait préparé à affronter : le panneau d'administration.

Pas le site public — ça, c'est fait. Je parle du back-office. Les écrans où vous approuvez un remboursement, modifiez un produit, vérifiez qui s'est inscrit cette semaine, corrigez un enregistrement saboté, jetez un œil aux chiffres d'hier. Si vous avez construit l'app avec un agent, vous n'avez probablement rien de tout ça. Vous avez la base créée par l'agent, une pile croissante de données réelles dedans, et aucun bon moyen de la regarder.

Cet article parle des options que vous avez réellement dans cette situation, et de celle à laquelle je reviens sans cesse.

Pourquoi les apps créées par IA n'ont pas de panneau d'administration

Quand un agent construit une app, il optimise pour ce que vous avez demandé : l'expérience utilisateur. Il génère volontiers des pages de connexion, des tableaux de bord pour vos clients, des parcours de paiement, et du CRUD soigné pour les parties que les utilisateurs touchent. Ce qu'il ne génère presque jamais, sauf demande explicite, c'est l'interface interne — les écrans qui servent à faire tourner l'activité. Ce n'est pas un échec de l'agent ; c'est la même chose qu'un humain qui développe vite. Le panneau d'administration est ennuyeux, invisible, facile à repousser. « Je le ferai plus tard » devient « plus tard » = six mois d'édition de la base à la main.

Pendant ce temps, votre base se remplit de ce qui compte : commandes, utilisateurs, remboursements, tickets, contenu. Chaque ligne est une décision qui attend — une commande à expédier, un remboursement à approuver, un brouillon à publier. Et le seul outil dont vous disposez pour agir, c'est une invite SQL ou un client brut qui vous montre status: "pending" sans aucun contexte.

Les quatre façons de régler ça (et leurs coûts)

J'ai vu les gens gérer l'absence de panneau de quatre façons. Elles fonctionnent toutes. Elles ont toutes un coût.

Option 1 : écrire les écrans CRUD à la main

La classique. Vous retroussez les manches et construisez un fichier de routes, un composant tableau, un composant formulaire, et vous recommencez pour chaque table qui compte. Vous l'avez probablement déjà fait une fois dans votre carrière — c'est ainsi que la plupart des outils internes ont été construits avant l'IA.

Avantages : contrôle total. Ça ressemble exactement à ce que vous voulez. « Gratuit » au sens où vous ne payez pas un éditeur.

Inconvénients : ça coûte votre temps, et le temps est précisément ce que vous vouliez économiser en utilisant un agent. Chaque table est un nouvel ensemble d'écrans. Chaque changement de schéma est une salve de modifications. Pour un développeur solo, c'est des jours de travail par app — alors que l'app elle-même a pris un week-end. Écrire un panneau à la main pour une app créée par IA, c'est la façon la plus chère de finir la partie la moins chère du projet.

Option 2 : utiliser le panneau intégré du framework

Django a Django Admin. Rails a ActiveAdmin. Laravel a Filament. Si votre agent a construit l'app dans un de ces frameworks, vous pouvez souvent activer un panneau généré en un après-midi.

Avantages : ça existe. C'est lié à vos modèles, donc ça connaît votre schéma. Aucune donnée ne quitte votre machine.

Inconvénients : c'est lié au framework. Dès que votre stack n'est pas Django/Rails/Laravel — et beaucoup d'apps créées par agent sont React + API + Postgres, ou un frontend statique avec un backend serverless — il n'y a rien à activer. Et les panneaux de framework sont faits pour les développeurs, pas pour les flux « approuver ce remboursement ». Vous finissez quand même par personnaliser.

Option 3 : adopter un SaaS d'administration cloud

Retool, Budibase, la version hébergée de NocoDB, Airtable — ce sont les outils qui promettent « des outils internes en quelques minutes ». Pointez-les vers vos données et ils génèrent une interface.

Avantages : rapide. Soigné. Adapté aux équipes.

Inconvénients : vous confiez les identifiants de votre base de production à un tiers, et vos données opérationnelles transitent par leurs serveurs. Pour un side project c'est agaçant ; pour tout ce qui a de vrais utilisateurs, c'est une conversation de conformité que vous ne voulez pas avoir. Et vous payez par siège ou par éditeur, pour toujours, pour quelque chose qui n'est fondamentalement qu'une interface CRUD — et si leur tarification change ou si le service disparaît, votre panneau disparaît avec.

Option 4 : un panneau local branché sur la base que vous avez déjà

C'est l'approche autour de laquelle j'ai construit Basevolt, et celle que j'utilise pour chaque app que j'ai livrée avec un agent. C'est une app de bureau. Vous la connectez à la base que votre app utilise déjà — la même base PostgreSQL, SQLite, MySQL ou Cloudflare D1 créée par l'agent. Elle lit votre schéma tel quel, sans migration, sans export, et le transforme en panneau d'exploitation : grille, kanban, galerie, tableaux de bord, webhooks.

Avantages : vos données ne quittent jamais votre machine. Pas de tarif par siège, pas de compte cloud. Ça fonctionne avec la base que vous avez déjà — rien à migrer ni à reconstruire. Et comme elle s'appuie sur la même base que votre app, ce que vous voyez dans le panneau est exactement ce que vos utilisateurs voient dans l'app.

Inconvénients : c'est une app de bureau, donc mono-utilisateur par conception — si vous avez besoin de cinq personnes qui se connectent et modifient les mêmes enregistrements dans un navigateur, ce n'est pas ce produit. Et vous devez la connecter vous-même, ce qui prend environ une minute.

Ce qui m'a convaincu : laisser l'agent la configurer

Voici ce qui a fait fonctionner l'option 4 pour moi. Vous avez construit l'app avec un agent — pourquoi l'agent ne construirait-il pas aussi le panneau ?

Basevolt fait tourner un serveur MCP sur votre machine. Le même Claude ou Cursor qui a écrit votre app peut s'y connecter et configurer le panneau pour vous : types de champs, relations entre tables, vues qui correspondent à votre façon de travailler. Vous dites « monte-moi un back-office pour les commandes », et l'agent lit votre schéma et fait les clics que vous auriez faits à la main.

Si vous pensez « je peux déjà demander à l'agent d'écrire du code admin », voici la différence : l'agent qui configure Basevolt ne génère pas de code qui réimplémente votre base — il configure un panneau qui lit votre base. Pas de nouveau code à maintenir, pas de déploiement, rien qui puisse dériver du schéma réel. Quand votre schéma change, le panneau le reflète. C'est la différence entre générer une photo d'une maison et entrer dans la maison.

La mise en place (environ une heure, surtout l'agent)

Laissez-moi dérouler ce que ça donne concrètement, avec la boutique de l'exemple comme fil rouge.

Étape 1 — connectez la base créée par l'agent.

Téléchargez Basevolt, ajoutez une source de données, pointez-la vers la même base que votre app. Pour Postgres : hôte, port, base, utilisateur, mot de passe. Pour SQLite, vous choisissez le fichier .db. Elle lit le schéma tel quel — pas de migration, pas de fichier de config.

Étape 2 — activez MCP et laissez l'agent configurer le panneau.

Ouvrez les réglages de Basevolt, activez le serveur MCP, enregistrez-le dans Claude ou Cursor (l'app vous montre la config exacte pour chaque client). Puis dites à votre agent quelque chose comme :

Tire les données de la boutique dans Basevolt et monte-moi un back-office. Les clients doivent apparaître par nom, pas par ID. Les statuts doivent être lisibles. Je veux un board pour les commandes qui attendent ma décision.

L'agent lit votre schéma, relie les relations, type les champs, configure les vues. Ce qui me prenait une soirée de clics prend maintenant quelques minutes de travail de l'agent — et je vois chaque changement dans le panneau au fur et à mesure.

Étape 3 — faites tourner l'activité depuis le panneau.

Le lendemain matin, au lieu d'ouvrir une invite SQL, vous ouvrez le panneau. Les commandes qui attendent sont un board. Les remboursements en attente, une file. Les chiffres d'hier, un tableau de bord. Quand une décision vous attend — approuver, expédier, rembourser — vous cliquez sur un bouton, et les webhooks portent l'action vers votre API existante. C'est la boucle complète : l'agent a construit l'app, configuré le panneau, et vous l'exploitez.

Le compromis honnête

Je vais être franc sur les limites. Si vous construisez des outils internes pour une équipe — cinq personnes qui ont besoin de comptes, de permissions et d'un espace de travail partagé dans le navigateur — une app de bureau locale n'est pas la bonne réponse, et il faut regarder Retool ou NocoDB auto-hébergé. Et si votre app n'a vraiment aucune surface d'administration, comme un site statique sans base, il n'y a encore rien à quoi accrocher un panneau.

Mais pour le cas, de plus en plus courant, de « j'ai construit une app avec un agent et j'ai maintenant besoin de l'exploiter » — le développeur solo avec de vraies données et pas de back-office — un panneau local posé sur votre base existante est le chemin le plus rapide, et laisser le même agent qui a écrit l'app le configurer boucle la boucle. Le panneau d'administration est la partie de l'app que personne ne veut écrire. Avec cette approche, vous n'avez pas à l'écrire du tout.