Démonstration & évaluation

Vaks PM · Données de démonstration & évaluation · juin 2026

Vue d'ensemble

Vaks PM est une application web multi-utilisateurs de gestion de projet (PM, de l'anglais project management) qui s'exécute entièrement sur une infrastructure contrôlée par l'organisation (on-premise, c'est-à-dire hébergée chez le client). Pour permettre à quelqu'un de l'évaluer sans saisir de données à la main, le produit est livré avec un seed : un jeu de données d'amorçage qui remplit une base de données avec le portrait crédible d'une entreprise en activité, à savoir équipes, personnel, catalogue de compétences, clients et un portefeuille de projets en cours avec leurs tâches, plannings, saisies de temps et charge de travail.

La démonstration entière vit à l'intérieur d'un unique tenant (locataire) dédié, c'est-à-dire une organisation isolée servie par l'instance, où chaque tenant possède sa propre base de données. Grâce à cette isolation, deux opérations couvrent l'ensemble du cycle de vie :

• Seed (initialisation) : remplir l'organisation de démonstration avec le jeu de données d'exemple et un compte administrateur connu.
• Reset (réinitialisation) : vider ou supprimer l'organisation de démonstration ensuite, sans toucher à quoi que ce soit d'autre sur l'instance.

Le seed est idempotent (il peut être exécuté à répétition sans créer de doublons : chaque exécution purge puis reconstruit), de sorte qu'une démonstration peut être rafraîchie à tout moment et réinitialisée sans risque pour les autres données.

Prérequis

Le seed ne déploie pas l'application ; il se contente de remplir la base de données d'une instance déjà en service. Le point de départ attendu est :

• Une instance Vaks PM opérationnelle, déployée soit sur une seule machine (idéal pour l'évaluation), soit dans une topologie multi-hôtes à haute disponibilité. Pour en mettre une en place au préalable, voir les guides de déploiement : déploiement Docker Swarm ou déploiement Kubernetes.
• Le service api qui s'exécute dans un conteneur. Les scripts de seed s'exécutent à l'intérieur de ce conteneur, où les paramètres de connexion à la base de données sont déjà disponibles.
• Un accès shell au conteneur api : directement avec docker exec sur une seule machine, ou via SSH (Secure Shell, un protocole d'administration à distance chiffré) vers l'hôte qui exécute le conteneur dans une installation multi-hôtes.

Dans quel mode suis-je, et que faut-il saisir exactement ?

Deux axes déterminent les étapes exactes. Ils sont indépendants — choisissez votre ligne dans chacun.

La démo utilise toujours les mêmes valeurs fixes : slug d'organisation demo, administrateur admin@vaks-demo.local, mot de passe Demo1234! (partagé par tous les comptes initialisés). Les comptes du seed arrivent prêts à l'emploi (chacun détient déjà un siège), donc la démo fonctionne dès son chargement — rien n'a à être attribué à la main.

Initialiser l'organisation de démonstration

Les scripts de seed sont livrés avec l'image api et sont présents dans /app/api/prisma/ à l'intérieur du conteneur. Deux d'entre eux sont exécutés directement :

Option A — seed au déploiement (depuis le manifeste, pooled)

La façon la plus propre d'avoir une démo prête à l'instant où l'instance démarre est de la déclarer dans le manifeste de déploiement (infra/cluster.json), pour que l'orchestrateur la provisionne et l'initialise pendant bash out/deploy-ssh.sh — aucune étape manuelle ensuite. Ajouter un tenant au tableau tenants portant un champ "seed" :

"tenants": [
  {
    "slug": "demo",
    "domain": "demo.<baseDomain>",
    "seed": "demo"
  }
]

Au déploiement, l'orchestrateur lance provision-tenant.js demo --seed demo, qui crée la base tenant <dbName>_demo, applique le schéma et charge le jeu de données de démo. Le champ "seed" est la seule valeur spécifique à la démo ; tous les autres champs sont une entrée de tenant ordinaire (voir Provisionner les tenants pour le schéma complet). Ce chemin est pour la tenancy mutualisée (pooled) — la démo s'atteint ensuite à demo.<baseDomain>. Pour ajouter une démo à une instance mutualisée déjà en marche, utiliser plutôt le chemin post-déploiement ci-dessous.

Option B — post-déploiement, tenancy mutualisée (une base de démo dédiée)

Lorsque plusieurs organisations partagent l'instance, la démonstration obtient sa propre base de données. Deux étapes : provisionner le tenant, puis initialiser sa base de données. C'est l'équivalent manuel de l'Option A, pour ajouter une démo après que l'instance est déjà en marche. Dans une installation multi-hôtes (HA), le conteneur api s'exécute généralement sur un hôte applicatif plutôt que sur l'hôte manager ; l'atteindre via SSH en utilisant les paramètres d'accès conservés dans le fichier d'environnement local.

Étape 1, provisionner le tenant de démonstration. Ceci crée la base de données <dbName>_demo, applique le schéma et amorce le compte administrateur :

source .env.local
# resolve the api container id on the application host
CID=$(ssh -i "$SSH_KEY" "$VM_USER@$APP_HOST" \
  "echo '$VM_PASS' | sudo -S docker ps -q -f name=vaks-pm_api | head -1")

ssh -i "$SSH_KEY" "$VM_USER@$APP_HOST" "echo '$VM_PASS' | sudo -S \
  docker exec $CID sh -c 'export DATABASE_URL=\$(cat /run/secrets/database_url) \
  && cd /app/api && node prisma/provision-tenant.js demo admin@vaks-demo.local'"

Étape 2, initialiser la base de données de démonstration. Faire pointer DATABASE_URL vers la base _demo, puis exécuter le seed :

ssh -i "$SSH_KEY" "$VM_USER@$APP_HOST" "echo '$VM_PASS' | sudo -S \
  docker exec $CID sh -c '
    BASE=\$(cat /run/secrets/database_url)
    export DATABASE_URL=\$(node -e \"const u=new URL(process.argv[1]);u.pathname=u.pathname+\\\"_demo\\\";console.log(u.toString())\" \"\$BASE\")
    cd /app/api && node prisma/seed-demo.js'"

Se connecter et vérifier

Tous les comptes initialisés partagent le mot de passe Demo1234!. L'administrateur créé au moment de l'initialisation est admin@vaks-demo.local.

La connexion se fait sur le sous-domaine du tenant de démonstration (par exemple demo.<baseDomain>) ; le point d'entrée partagé résout le tenant depuis l'en-tête Host de la requête. L'identifiant est toujours admin@vaks-demo.local / Demo1234! — l'e-mail est un identifiant de compte, pas le nom d'hôte. Une connexion réussie renvoie un jeton d'accès et les projets de la démonstration sont visibles. Une vérification rapide en ligne de commande :

# resolve the demo subdomain to the entry point and sign in → expect a token
curl -sk --resolve demo.<domain>:443:<entry-point-ip> \
  -X POST https://demo.<domain>/api/v1/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"admin@vaks-demo.local","password":"Demo1234!"}'

Contenu du jeu de données

Le seed simule une entreprise de services informatiques (IT, de l'anglais Information Technology) avec des équipes, du personnel et un portefeuille de projets réalistes. Il exerce les principaux domaines du produit afin qu'un évaluateur puisse explorer un tableau Kanban (tableau de tâches avec colonnes de statut), un diagramme de Gantt (planning avec dépendances et chemin critique), le suivi du temps, la charge de travail et la capacité, le catalogue de compétences, les clients et le cycle de vie complet d'un projet. Le contenu est en anglais et reste confiné au tenant de démonstration.

Tout effacer

Lorsque l'évaluation est terminée, reset-demo.js supprime le contenu de la démonstration. Il agit strictement sur l'organisation de démonstration ; aucune autre organisation de l'instance n'est affectée.

# soft reset: empty the org (content + users), keep the empty organization
docker exec <api-cid> sh -c 'export DATABASE_URL=… && cd /app/api && node prisma/reset-demo.js'

# hard reset: also remove the organization record
docker exec <api-cid> sh -c 'export DATABASE_URL=… && cd /app/api && node prisma/reset-demo.js --hard'

Pour ré-initialiser ensuite, réexécuter seed-demo.js ; il est idempotent.

Pour aller plus loin

Une fois la démonstration initialisée et un administrateur connecté, l'application est prête à être explorée. Pour comprendre ce que fait chaque domaine et comment mener une visite guidée pertinente (Kanban, Gantt, suivi du temps, charge de travail, compétences, clients, reporting et le reste), voir le guide produit. Pour l'exploitation de l'instance qui sous-tend la démonstration, voir exploitation et sécurité.

Voir aussi : Guide produit · Déploiement Docker Swarm · Déploiement Kubernetes · Exploitation · Sécurité · Accueil de la documentation