Une machine, quatre couches : les services qui tournent, le dépôt qui les contient, la forme des données dans OpenProject, et ce que chaque personne voit selon son rôle.
état relevé le 31 juillet 2026 · aucune donnée réelle sur cette pageTout tient sur un seul serveur. Le navigateur d'un collaborateur ne parle jamais directement à OpenProject : il passe par nginx, puis par le service d'authentification, qui ajoute le jeton d'accès côté serveur. Aucun mot de passe ni jeton ne circule dans le navigateur.
/var/www/planning. Redirige /auth/, /api/ et /ops/ vers le service d'auth.
| Service | Où | Rôle | État |
|---|---|---|---|
| nginx | :80 — hôte | Sert les pages, relaie l'API. Racine /var/www/planning, faite de liens vers le dépôt. |
en production |
| planning-auth | :3001 — systemd | Connexion, sessions, droits, relais vers OpenProject, moteur de la console de bascule. | en production |
| OpenProject 16 | :8080 — Docker | La source unique des données. Y compris le rôle, le poste et l'équipe de chacun, stockés en groupes. | en production |
| n8n | :5678 — Docker | Prévu pour les notifications automatiques. Contient zéro scénario : le conteneur tourne, il ne fait rien. | pas déployé |
À ne pas confondre. La documentation décrit une automatisation « prévenir le suivant quand une tâche est clôturée ». Elle est conçue mais jamais installée : aucun scénario n'existe dans n8n, aucun webhook n'est configuré. À construire seulement si l'usage le justifie.
| Chemin | Destination | À quoi ça sert |
|---|---|---|
| /insee/ | api.insee.fr | Retrouver le nom d'une société depuis son SIREN, à la création d'un client. |
| git push | GitHub (dépôt privé) | Sauvegarde du code et de la documentation, à chaque fin de tour de travail. |
Hors du dépôt, jamais versionnées, et c'est ce qui rend une reconstruction impossible sans elles.
| Fichier | Contient |
|---|---|
| /etc/planning-auth.env | Le jeton de service utilisé par le service d'auth pour lire OpenProject. |
| poc-setup/.secrets | Le jeton administrateur OpenProject utilisé par les scripts. |
| poc-setup/.auth-store.json | Les comptes applicatifs : empreinte du mot de passe et jeton OpenProject de chacun. |
Piège vérifié. Les jetons d'API vivent dans la base OpenProject. Restaurer une sauvegarde antérieure à un changement de clé fait répondre « accès refusé » à toute l'application, sans que rien ne soit réellement cassé.
Un seul dossier fait référence : /opt/cabinet-planning. Tout le reste — la racine web,
les chemins d'usage — n'en est qu'un raccourci. Modifier le dépôt modifie donc la production
directement, sans étape de déploiement.
| Page | Ce qu'elle fait |
|---|---|
| planning | L'écran principal : calendrier, tâches à planifier, saisie du temps. La plus grosse page de loin. |
| rh | Vue de la charge et de la capacité, par collaborateur et par équipe. Réaffectation de dossiers. |
| creation-mission | Créer un client et sa mission comptable de l'année ; désigner les trois titulaires. |
| admin-users | Gérer les comptes : rôle, poste, équipe, fiche du collaborateur. |
| login | Connexion et changement de mot de passe obligatoire à la première entrée. |
| support | Signaler un problème ; les tickets deviennent des tâches dans OpenProject. |
| console-bascule | Les opérations lourdes en 7 étapes : rotation de clé, purge, import, anonymisation. |
Cinq autres pages sont des guides et présentations (dont le guide de la vue RH), et quatre sont des maquettes conservées comme références de design, pas branchées aux données.
| Famille | Nb | Rôle |
|---|---|---|
| Installer OpenProject | 10 | Créer les types de tâches, champs, statuts, groupes, catalogue, projet support. |
| Importer depuis Wrike | 8 | Lire les Excel, régénérer les missions par les règles, vérifier après coup. |
| Purger et anonymiser | 10 | Remettre la base à zéro, effacer les données réelles, masquer les noms. |
| Sauvegarder, restaurer, mettre à jour | 8 | Instantanés avec inventaire, restauration vérifiée, rotation de clé. |
| Tester | 39 | 9 suites Python, 4 suites JS, et 26 scénarios qui pilotent un vrai navigateur. |
| Installer et entretenir | 7 | Déploiement nginx, service d'auth, jeux de démonstration, rappels. |
Règle tenue. Toute modification de la base ou de la production passe par un script versionné et rejouable — jamais par une commande tapée une fois. C'est ce qui permet de refaire, et de comprendre après coup ce qui a été fait.
Un seul fichier calcule les missions comptables : les 11 tâches du Bilan, les échéances de TVA selon le régime, les dates dérivées du mois de clôture. Il est utilisé à la fois par la page de création de mission et par l'import de masse — donc l'import produit exactement ce qu'une saisie à la main aurait produit.
Dans OpenProject, un projet = un client. Sous chaque client, une mission par exercice, et sous la mission, les tâches. Rien d'autre : pas de dépendances entre tâches, pas de date de début, une seule échéance par tâche.
| N° | Type | Rôle |
|---|---|---|
| 10 | Compta | La mission de l'exercice — le conteneur parent. |
| 8 | Bilan | Les 11 tâches de la chaîne annuelle. |
| 9 | TVA | Une échéance de déclaration. |
| 11 | Ticket support | Un signalement venu de la page support. |
Les types 1 à 7 sont ceux livrés par défaut avec OpenProject (Tâche, Bug, Epic…) : présents, non utilisés.
| Projet | Contenu |
|---|---|
| catalogue-taches | Le catalogue des tâches de service, par poste — 86 modèles. |
| gestion-interne | Les tâches internes du cabinet. |
| support | Les tickets remontés par les collaborateurs. |
Ils survivent à toutes les purges : les effacer casserait la barre « à planifier » des postes de service et la page support.
18 champs ajoutés à OpenProject, répartis sur trois objets. Ceux de la fiche du collaborateur sont créés vides : rien n'y sera saisi avant validation.
| Porté par | Champs |
|---|---|
| Le client | N° interne (1) |
| La mission ou la tâche | Chef de mission · Chargé de mission Bilan · Collaborateur comptable · Temps Bilan h/an · Temps tenue h/an · Forme juridique · Mois de clôture · Régime TVA · Holding LMNP · Poste · Service (11) |
| Le collaborateur | Heures hebdomadaires · Date d'entrée · Adresse mail personnelle · Lien bibliothèque · Identifiant espace de fichiers · N° de sécurité sociale (6) |
14 statuts existent ; deux seulement comptent comme « fermé » : Clôturé et Annulé. C'est cette notion de fermeture qui pilote les compteurs d'avancement et l'affichage des tâches faites.
Contrainte à connaître. Le circuit de validation d'OpenProject interdit de rouvrir une tâche clôturée par l'API. Toute vérification qui clôturerait une tâche doit donc être menée sans rien modifier.
Décision structurante : le rôle, le poste et l'équipe d'une personne ne sont pas stockés dans un fichier à part, mais dans des groupes OpenProject. Un changement fait dans la page de gestion des comptes est donc pris en compte à la connexion suivante, sans redéploiement.
| Groupe | Nb | Porte |
|---|---|---|
| Rôle : … | 5 | Le rôle applicatif, qui décide des droits et de la vue affichée. |
| <nom du poste> | 7 | Le poste comptable ou de service — un axe indépendant du rôle. |
| Équipe … | 11 | L'équipe, une par manageur. Le manageur est déduit de l'appartenance au groupe des manageurs. |
Piège coûteux, corrigé. OpenProject ne renvoie que 20 groupes par défaut, et rend les plus récents d'abord : les plus anciens disparaissent silencieusement de la liste. Trois postes comptables se sont ainsi retrouvés sans affectation pendant deux jours. Toute lecture de liste réclame désormais une taille de page explicite.
Deux axes indépendants, et c'est la clé du modèle : le rôle décide de ce qu'on a le droit de faire, le poste décide de ce qu'on voit dans son planning.
La matrice ci-dessous est éditable dans l'application, pas figée dans le code. Les valeurs montrées sont celles en vigueur.
| Capacité | Collab | Secrétariat | Manageur | RH | Admin |
|---|---|---|---|---|---|
| Voir et saisir son planning | oui | — | oui | oui | oui |
| Voir et planifier le planning des autres | — | — | oui | oui | oui |
| Saisir ou valider le temps réel d'un autre | — | — | — | oui | oui |
| Créer la mission de l'année suivante | oui | oui | oui | oui | oui |
| Créer un client, une mission, les mettre à jour | — | oui | oui | oui | oui |
| Consulter la charge (vue RH) | — | — | oui | oui | oui |
| Réaffecter des dossiers | — | — | — | oui | oui |
| Gérer les comptes | — | — | — | oui | oui |
| Promouvoir quelqu'un en RH ou Admin | — | — | — | — | oui |
| Modifier un RH ou Admin existant | — | — | — | — | oui |
| Opérations lourdes : purge, remise à zéro | — | — | — | — | oui |
Trois barrières, pas une. L'écran masque ce qui n'est pas permis ; le service refuse les écritures non autorisées même si l'on contourne l'écran ; OpenProject applique enfin ses propres droits. Une seule des trois qui tombe ne suffit pas à ouvrir la porte.
3 postes comptables
| Chef de mission |
| Chargé de mission Bilan |
| Collaborateur comptable |
Planning alimenté par les tâches Bilan et TVA des dossiers dont la personne est titulaire.
4 postes de service
| Juridique |
| Patrimoine |
| Secrétariat |
| Informatique |
Planning alimenté par leur propre catalogue de tâches de service.
Quand une personne cumule deux postes, le poste comptable l'emporte : c'est lui qui décide de la vue servie.
Aucun collaborateur n'est administrateur d'OpenProject. Le serait-il, il pourrait tout supprimer depuis l'interface d'OpenProject, hors de tout garde-fou de l'application. Conséquence : quand une RH doit lister les comptes — ce qu'OpenProject réserve à ses administrateurs — c'est le service qui fait la lecture avec son propre jeton, et seulement pour les quelques opérations autorisées à son rôle.