Dans le panneau Administration, cliquez sur Ajouter dans la section Utilisateurs. Renseignez le prénom, nom, email et choisissez un rôle. Le mot de passe peut être laissé vide : un mot de passe temporaire sera généré automatiquement et affiché une seule fois.

Utilisateur : accès au Hub et favoris. Admin : accès complet incluant la gestion, le déploiement d'apps et ce guide. Il doit toujours rester au minimum un administrateur dans le système.

Dans la liste des utilisateurs, cliquez sur le bouton de réinitialisation (🔑) sur la ligne de l'utilisateur concerné. Un nouveau mot de passe temporaire sera généré et affiché. Transmettez-le à l'utilisateur par un canal sécurisé.

Cliquez sur le bouton ✕ sur la ligne de l'utilisateur. La suppression est immédiate et supprime aussi ses favoris. Il est impossible de supprimer son propre compte ou le dernier administrateur.

Dans Administration → Outils, cliquez sur Ajouter. Sélectionnez le type Lien externe. Renseignez le nom, une icône (emoji), une description, la catégorie et l'URL complète (ex: https://github.com). Le lien s'ouvrira dans un nouvel onglet.

Les outils sont regroupés par catégorie dans le Hub. Choisissez parmi : Développement, Monitoring, Communication, Productivité, Infrastructure, Autre. La catégorie est également utilisée pour le filtrage par recherche.

Cliquez sur ✕ dans la liste des outils. Cela supprime aussi l'outil des favoris de tous les utilisateurs. Pour les applications internes, utilisez le panneau dédié (voir section suivante).

Compressez votre application en ZIP. Pour Node.js, incluez le package.json mais pas le dossier node_modules (les dépendances seront installées automatiquement). Le point d'entrée doit être server.js, index.js ou défini dans package.json.

Node.js : application Express ou autre serveur Node. Next.js : détecté automatiquement via next.config.js, build lancé automatiquement. Statique : HTML/CSS/JS servi via http-server, aucune dépendance requise.

Dans Administration → Outils, cliquez Ajouter et choisissez App interne. Renseignez le nom, le slug (ex: mon-app → accessible sur /apps/mon-app), le runtime et uploadez le ZIP. Le déploiement est automatique.

Dans la liste des outils, les applications internes ont des boutons ▶ (démarrer) et ⏸ (arrêter). Le statut en ligne / arrêtée est visible sur chaque carte du Hub. PM2 assure le redémarrage automatique en cas de crash.

Les logs PM2 sont accessibles directement depuis l'interface (bouton 📋 dans la liste). Vous pouvez aussi les consulter en SSH avec : pm2 logs dcc-mon-app

Sur n'importe quelle carte d'outil dans le Hub, cliquez sur l'étoile ★ en haut à droite. Elle devient orange pour indiquer que l'outil est épinglé. L'action est synchronisée immédiatement avec le serveur.

La section Mes favoris dans le menu de gauche affiche uniquement vos outils épinglés. Le compteur dans la navigation se met à jour en temps réel.

Les favoris sont propres à chaque utilisateur. Ajouter ou retirer un favori n'affecte pas les autres membres de l'équipe. Si un outil est supprimé par un admin, il disparaît automatiquement des favoris de tous.

La connexion crée deux choses : une session Flask pour maintenir l'état côté serveur, et un token JWT signé avec la clé secrète de la VM. Ce token peut être transmis aux applications internes pour valider l'identité sans appel réseau externe.

Vos applications internes peuvent vérifier un token JWT en appelant POST /api/auth/verify-token avec le body {"token": "..."}. La réponse indique si le token est valide et retourne les infos de l'utilisateur.

Les tokens JWT sont valides 8 heures. Après expiration, l'utilisateur doit se reconnecter. La session Flask suit la même durée.

Les utilisateurs peuvent changer leur mot de passe via l'API : POST /api/auth/change-password avec old_password et new_password. Les admins peuvent réinitialiser le mot de passe de n'importe quel utilisateur depuis le panneau.

Tout tourne dans Docker, il n'y a ni service systemd applicatif ni PM2.
Redémarrer le portail : cd /opt/dccockpit && docker compose up -d --force-recreate
Logs du portail : docker logs -f dccockpit
État des conteneurs : docker ps
Nginx tourne sur l'hôte : sudo nginx -t && sudo systemctl reload nginx

/opt/dccockpit/backend/ — code Flask et base de données
/opt/dccockpit/frontend/ — fichiers du portail web
/opt/dccockpit/apps/ — applications déployées
/opt/dccockpit/logs/ — tous les logs
/opt/dccockpit/nginx/locations/ — configs nginx auto-générées

La base du portail est dans le volume Docker dccockpit_dcc_db, vue depuis le conteneur en /data/db/dccockpit.db. Le fichier backend/instance/dccockpit.db est un vestige orphelin daté de février : ne le sauvegardez pas, il ne contient rien d'à jour.
Les sauvegardes sont automatiques — voir l'onglet Exploitation.

Pour le frontend, remplacez /opt/dccockpit/frontend/index.html et rechargez avec Ctrl+Shift+R — le cache navigateur est tenace. Pour le backend, modifiez les fichiers Python puis docker restart dccockpit. Sauvegardez toujours l'existant avant : cp index.html index.html.bak-$(date +%Y%m%d-%H%M).

Accessible aux administrateurs via État système dans le menu de gauche. Il affiche disque, mémoire, charge, conteneurs, tailles des bases et fraîcheur des sauvegardes.
Les données sont collectées toutes les 5 minutes par /opt/dccockpit/scripts/collect_status.py. Le bouton Actualiser déclenche une collecte immédiate.
Trois niveaux : vert normal, ambre à surveiller, rouge intervention requise. Un relevé de plus de 15 minutes bascule en ambre — signe que le collecteur ne tourne plus.

Cinq bases sauvegardées quotidiennement, rétention 30 jours, dans /opt/backups/ :
02:00 dc_kpi · 02:45 feeling_cards, workload, dccockpit · 03:30 dc_map

Restaurer une base PostgreSQL :
gunzip -c /opt/backups/<app>/<fichier>.sql.gz | docker exec -i <conteneur>-postgres psql -U <user> <base>
Restaurer le portail : décompresser le .db.gz et le copier avec docker cp vers /data/db/dccockpit.db, puis redémarrer le conteneur.

Docker Compose interprète les $ comme des variables, y compris dans les fichiers env_file. Un hash bcrypt en contient trois et arrive tronqué dans le conteneur.
Il faut doubler chaque $ : $2b$12$... devient $$2b$$12$$...
Concerne /opt/dcapps/dc-map/auth.env. À refaire à chaque régénération de mot de passe :
sed -i '/^DCMAP_.*_HASH=/ s/\$/$$/g' auth.env
Symptôme si oublié : le bon mot de passe est refusé, sans message d'erreur explicite.

Next remplace process.env.NOM_EXPLICITE par sa valeur au moment du build, y compris côté serveur. Une variable absente à la compilation devient undefined pour toujours, quoi qu'on mette ensuite dans l'environnement.
Toute valeur configurable après build — secrets, mots de passe — doit passer par une lecture indirecte :
const env = process.env as Record<string, string|undefined>; return env[nom];
Symptôme si oublié : l'application démarre normalement mais refuse toutes les authentifications, alors que docker exec <app> printenv affiche la bonne valeur.

La fonction seed_db() de backend/app.py recrée un compte admin@dccockpit.local avec un mot de passe trivial si la table users est vide. Ce compte a été supprimé le 05/08/2026.
Si vous réinitialisez ou restaurez une base vide, il réapparaîtra : supprimez-le ou changez son mot de passe immédiatement après.

Le cache de build Docker grossit à chaque docker compose build et peut atteindre plusieurs dizaines de gigaoctets. Il est désormais plafonné à 10 Go par /etc/docker/daemon.json.
Purge manuelle si nécessaire :
docker builder prune -a -f puis docker image prune -f
Ne jamais lancer docker system prune --volumes ni docker volume prune : les volumes contiennent les bases de données.

JWT_SECRET du Cockpit signe les jetons SSO ; les applications le connaissent sous le nom COCKPIT_JWT_SECRET. FLASK_SECRET_KEY signe les sessions du portail et n'est connue que du Cockpit — ne jamais les réunifier, sinon toute application pourrait forger une session administrateur.
Chaque application garde en plus son propre JWT_SECRET interne et KPI_SERVICE_SECRET pour les appels entre services.
Rotation : changer la valeur partout puis recréer tous les conteneurs. Les sessions en cours sont invalidées, les mots de passe ne sont pas affectés.