Produit & fonctionnalités

Vaks PM · Périmètre fonctionnel & fonctionnalités · Juin 2026

Vue d'ensemble

Vaks PM est une application web multi-utilisateurs de gestion de projet (PM, Project Management) conçue pour les organisations de 200 utilisateurs ou plus et bâtie pour fonctionner entièrement sur une infrastructure que l'organisation contrôle (on-premise : hébergée sur ses propres serveurs plutôt que sur un service en ligne exploité par un éditeur). Elle couvre tout le cycle de vie d'un portefeuille de projets : planification, exécution (tableaux Kanban et planification Gantt), suivi du temps et de la charge, collaboration, gestion des compétences, finance et reporting. Chaque capacité est exposée à travers une seule API REST (interface de programmation d'application de type Representational State Transfer) que le front web consomme lui-même, de sorte que toute fonction du produit peut aussi être pilotée depuis un script.

Principes directeurs

Glossaire

Acronymes employés tout au long de ce guide, définis ici une fois pour référence.

Tâches & Kanban

Les tâches sont l'unité de travail centrale. Elles s'organisent sur des tableaux Kanban (tableaux de cartes disposées en colonnes par statut, par exemple À faire, En cours, Terminé) et dans des listes de tâches à plat. Une tâche porte un titre et une description, une date de début et une date d'échéance, une estimation (en heures ou en jours), une priorité, une compétence requise optionnelle, des assignés, des étiquettes colorées et un indicateur de jalon optionnel.

Comment ça fonctionne au niveau opérateur : les tableaux et les étiquettes sont rattachés à un projet. Déplacer une carte émet un seul mouvement positionné sur le serveur, qui diffuse le changement en temps réel à toutes les personnes consultant le projet (voir Collaboration). Les étiquettes sont des balises colorées réutilisables sur l'ensemble des tâches du projet.

Personnalisation livré

Un modèle de données figé oblige tôt ou tard à contourner l'outil (un statut « En revue technique » simulé par une étiquette, un champ métier casé dans la description). Vaks PM laisse une organisation étendre son vocabulaire de tâches et de projets sans toucher au code : des champs personnalisés pour capturer une donnée métier propre, et des statuts personnalisés pour affiner une phase sans en changer le moteur.

Champs personnalisés

Un champ personnalisé est une donnée additionnelle définie par l'organisation et attachée aux tâches ou aux projets — par exemple un numéro de bon de commande, une criticité métier, ou une équipe cliente. Chaque définition porte un type (texte, nombre, date, liste déroulante ou case à cocher) et peut être restreinte à certains projets plutôt qu'appliquée à toute l'organisation ; sans restriction, elle s'applique partout. Les champs sont toujours optionnels : aucun champ personnalisé ne peut aujourd'hui bloquer la création d'une tâche ou d'un projet.

Le catalogue de champs se gère sous espace admin → Personnalisation → Champs personnalisés, derrière une politique d'écriture configurable (par défaut réservée aux administrateurs). Une fois définis, les champs apparaissent sur le détail de la tâche ou dans la fiche projet, aux côtés des champs natifs.

Statuts personnalisés (sous-statuts)

Les cinq phases d'une tâche (À faire, En cours, En attente, En revue, Terminé) restent le moteur du produit — reporting, automatisations, auto-planification et cycle de vie des agents IA s'appuient tous dessus sans exception. Un sous-statut ajoute une granularité à l'intérieur d'une phase, sans jamais la remplacer : par exemple Revue technique et Revue client comme deux sous-statuts de la phase En revue.

Un sous-statut est rattaché à une phase précise et, comme les champs personnalisés, peut être restreint à certains projets. Sur le tableau Kanban, les sous-statuts actifs d'une colonne apparaissent comme des compartiments à l'intérieur de la colonne de leur phase ; déposer une carte dans un compartiment fixe le statut et le sous-statut en un seul geste. Depuis le détail de tâche, le sélecteur de sous-statut ne propose que ceux de la phase courante — changer de phase se fait toujours par le statut.

Un sous-statut peut désigner des destinataires à notifier à l'entrée (des utilisateurs, des équipes, ou les deux) : dès qu'une tâche y entre, ils reçoivent un courriel et, si configuré, une carte Teams, avec un délai de grâce d'une heure par tâche pour éviter le bruit sur des allers-retours rapides.

Planification & Gantt

La vue Gantt est un diagramme de planification qui dessine chaque tâche comme une barre temporelle le long d'un axe de dates, avec les dépendances entre tâches représentées par des flèches. Elle prend en charge les quatre types de dépendance standard et calcule le chemin critique du projet.

Chaque lien peut porter un décalage (lag) en jours, et les jalons marquent des points de contrôle de durée nulle. Le moteur de planification exécute un calcul complet de méthode du chemin critique (CPM) : une passe avant pour trouver le début au plus tôt de chaque tâche, puis une passe arrière pour trouver son début au plus tard. Cela produit le mou total par tâche (de combien elle peut glisser sans retarder le projet) et signale comme critiques les tâches sans aucun mou. Les liens peuvent être créés et supprimés directement sur la frise, et une vérification côté serveur rejette tout lien qui créerait un cycle.

Temps & reporting

Le suivi du temps enregistre la durée réelle du travail par rapport à l'estimation, et le reporting transforme ces enregistrements en information exploitable.

Exports. Chaque rapport peut être exporté en CSV (tabulaire en texte brut), en XLSX (un classeur Excel multi-feuilles stylé avec en-tête figé, zébrures et filtre automatique), ou en PDF mis en forme (un document imprimable et brandé avec cartes de KPI, tables paginées et graphiques rendus côté serveur : une courbe burndown, un donut d'échéances et des barres horizontales). Le rendu PDF est entièrement côté serveur, sans navigateur headless.

Charge & planification

La gestion de la charge répond à la question « qui en fait trop, qui a de la marge » en comparant la capacité de chaque personne au travail qui lui est assigné, jour par jour. Elle repose sur trois concepts :

• Horaires de travail : une capacité hebdomadaire par personne (heures pour chaque jour du lundi au dimanche, plus un taux d'occupation). Un horaire par défaut (8 h, du lundi au vendredi) est créé automatiquement à la première utilisation et peut être édité par personne.
• Allocations : un engagement d'une personne sur une tâche sur une plage de dates, exprimé en heures par jour. Les allocations sont ce qui remplit la capacité.
• Absences : des plages d'absence typées et datées (congé, maladie, et similaires). La capacité tombe à zéro sur toute une plage d'absence.

La vue charge est une grille personnes par jours qui agrège la capacité face aux heures allouées et applique un code couleur à chaque cellule (libre / ok / avertissement / surchargé). Une allocation peut être glissée sur une autre personne pour la réassigner.

Jours fériés par pays

Le produit fournit un catalogue de jours fériés indexé par code pays ISO (par exemple FR, US). Une organisation définit un pays par défaut, avec des surcharges optionnelles par utilisateur. Un jour férié, la capacité journalière est nulle, et l'interface affiche des avertissements lorsqu'une date de début ou d'échéance de tâche tombe l'un d'eux.

Auto-planification

L'auto-planification dérive les allocations automatiquement pour tout le périmètre d'un projet, afin qu'un manager n'ait pas à placer chaque engagement à la main. Elle combine quatre mécanismes :

L'auto-planification est idempotente (la relancer sur le même périmètre produit le même plan), elle gèle le passé (elle ne touche jamais aux allocations déjà commencées), et elle offre un aperçu avant application pour que le plan puisse être revu et ajusté. Les heures restantes d'une tâche sont réparties entre ses assignés au prorata de la capacité libre de chacun, et non divisées à parts égales.

Répartir une tâche entre plusieurs personnes (auto-split)

À l'échelle d'une seule tâche plutôt que de tout un projet, l'auto-split étale automatiquement les heures restantes d'une tâche en allocations sur sa fenêtre de dates, sans avoir à les poser une par une. Sur une tâche à un seul assigné, ces heures sont simplement étalées sur cette personne. Sur une tâche à plusieurs assignés, le chef de projet choisit en plus comment les répartir entre eux, selon une stratégie :

Chaque personne est remplie à sa propre capacité journalière (avec un plafond optionnel). Si même une répartition sur la totalité des assignés ne suffit pas à tenir l'échéance de la tâche, l'outil le signale et estime le nombre de personnes supplémentaires qu'il faudrait mobiliser plutôt que de produire un plan silencieusement intenable.

Collaboration

• Commentaires & @mentions : commentaires en fil sur les tâches ; mentionner une personne avec @ la notifie.
• Pièces jointes : fichiers attachés aux tâches et aux commentaires, stockés dans le magasin objet S3 auto-hébergé via des URL pré-signées à durée de vie courte, de sorte que les octets des fichiers ne transitent jamais par le serveur d'application.
• Temps réel : les changements se propagent en direct entre les clients via un canal WebSocket (une connexion temps réel bidirectionnelle entre navigateur et serveur), une room par projet, authentifiée par le JWT de l'utilisateur à la connexion.

Documents de projet livré

Au-delà des pièces jointes accrochées à une tâche ou à un commentaire, chaque projet dispose d'un espace documentaire propre : un endroit pour ranger les livrables, comptes-rendus, transcripts ou toute pièce qui documente le projet dans son ensemble plutôt qu'une tâche précise. Les fichiers vivent dans des dossiers librement créés par les membres du projet — pas de catégories imposées par le produit — et sont stockés dans le même magasin objet S3 auto-hébergé que les pièces jointes.

Gouvernance volontairement ouverte : tout membre ayant accès au projet peut créer des dossiers, y déposer des fichiers et en supprimer, sans permission dédiée au-delà de l'accès au projet lui-même. Supprimer un dossier ne supprime jamais son contenu : les fichiers et sous-dossiers qu'il contenait remontent au dossier parent.

Contexte lisible par les agents IA

Un document peut être marqué comme contexte IA. Les documents ainsi marqués sont exposés, en lecture seule, dans le contexte de travail qu'un agent consulte avant de traiter une tâche (voir Agents IA) — un agent peut lire le contenu texte d'un document de contexte (jusqu'à 64 Ko) au même titre que le brief du projet et les critères d'acceptation de sa tâche, sans qu'aucun fichier ne soit copié ailleurs. C'est un mécanisme distinct et complémentaire du contexte SharePoint pour les agents : celui-ci lit les documents propres à Vaks PM, l'autre lit ceux de l'équipe Microsoft Teams provisionnée pour le projet.

Clients & équipes

Accès projet au niveau de l'équipe. Affecter une équipe à un projet accorde à chaque membre de cette équipe un niveau d'accès hérité sur le projet (Contributeur par défaut) via une seule entrée d'accès d'équipe, en plus des membres ajoutés directement. Cela maintient l'appartenance au projet en phase avec la structure d'équipes de l'organisation.

Sponsors & annonces livré

Un projet a souvent des parties prenantes qui ont besoin d'être tenues informées sans être assignées à une tâche ni gérer le projet au quotidien : un sponsor côté client, un comité de pilotage. Vaks PM leur réserve un statut et un canal de communication dédiés, distincts des rôles RBAC habituels.

Le tag sponsor

N'importe quel membre d'un projet peut être marqué sponsor. C'est une étiquette d'audience, pas un rôle : elle n'accorde aucun droit supplémentaire et est orthogonale à la permission de la personne sur le projet (le même schéma que le tag « lead » d'une équipe). Un chef de projet bascule le tag depuis l'onglet accès de la fiche projet.

Annoncer un changement

Une annonce est un message ponctuel adressé à une audience du projet — par exemple prévenir les sponsors d'un changement de périmètre. Le contenu (titre et corps) est libre, mais il voyage dans une enveloppe fixée par le serveur : un sujet de courriel préformaté, une ligne d'attribution automatique (« Envoyé par X », ou « … via l'assistant IA » si le message est passé par le connecteur IA), le corps échappé pour empêcher toute mise en forme trompeuse, et aucune URL cliquable. Il n'y a qu'un seul bouton d'action possible, celui que le serveur ajoute — jamais un lien fourni par l'auteur.

L'audience n'est jamais une liste d'adresses saisie à la main : elle est résolue côté serveur par rôle sur le projet (chef de projet, membres, suiveurs, sponsors), ce qui écarte tout risque d'envoyer une communication interne à une adresse externe par erreur de frappe. L'auteur est automatiquement exclu de sa propre annonce. Un délai de deux minutes s'applique par auteur et par projet pour empêcher une rafale accidentelle.

Le fil sponsor

Au-delà des annonces ponctuelles, un projet peut notifier ses sponsors automatiquement sur une poignée d'événements choisis, indépendamment des règles d'automatisations générales :

Le fil sponsor se règle depuis l'onglet accès de la fiche projet et emprunte le même chokepoint que toutes les autres alertes : période de calme, heures de silence et interrupteur d'arrêt s'appliquent normalement.

Compétences

La capacité de gestion des compétences enregistre quelles compétences possèdent les personnes, ce que les projets requièrent, et ce que les équipes couvrent, alimentant les décisions de staffing et de charge. Elle s'articule autour d'un catalogue de compétences par organisation.

Catalogue & packs

Le catalogue est peuplé à partir de packs modulaires, des ensembles curatés regroupés par technologie ou par domaine (par exemple AWS, Azure, GCP, backend, frontend, mobile, data/IA, devops, sécurité, méthodologie, gestion de projet, RH, marketing). Un administrateur applique les packs pertinents pour l'organisation. Les packs peuvent être resynchronisés ou retirés, et appliquer un pack ne ressuscite jamais une compétence qu'un administrateur a supprimée, sauf forçage explicite. Des packs personnalisés peuvent aussi être enregistrés via l'API, rattachés à l'organisation, sans redéploiement.

Niveaux, exigences & couverture

• Par utilisateur : les compétences et niveaux de maîtrise de chaque personne.
• Par projet : les compétences qu'un projet requiert.
• Par équipe : les compétences qu'une équipe couvre. Les compétences assignables sur un projet correspondent par défaut à l'union des compétences de ses équipes affectées, avec repli sur le catalogue complet si aucune équipe n'est affectée.

Demandes de compétence & analyse d'écart

• Demandes de compétence : un chef de projet peut signaler à un lead d'équipe qu'une compétence manque (types : affectation, formation, recrutement externe ; statuts OPEN / ACK / RESOLVED / REJECTED). Le lead est notifié par courriel et un webhook est émis.
• Analyse d'écart : le système évalue si les personnes affectées disposent réellement de capacité libre pour couvrir les compétences requises d'un projet sur sa planification, et non simplement si la compétence existe quelque part. Face à un écart, deux actions concrètes : ouvrir une demande de compétence, ou planifier ce split — assigner directement les personnes qualifiées manquantes et poser leurs allocations via l'auto-split (stratégie gloutonne, pour mobiliser le moins de monde possible).

Finance

La capacité finance transforme le temps saisi et les coûts en suivi de budget et de marge, projet par projet et à l'échelle du portefeuille.

• Indicateur de facturabilité : la facturabilité est définie au niveau du projet (Project.billable), de sorte que tout le travail d'un projet est cohéremment facturable ou non.
• Résolution de taux à trois niveaux : pour toute personne sur un projet, le taux de coût/facturation applicable est résolu dans l'ordre, un taux de projet explicite d'abord, puis le taux par défaut de l'utilisateur, puis le défaut du projet. La source retenue est indiquée dans l'interface pour que le chiffre soit toujours explicable.
• Budgets & marge : chaque projet a un budget. Le produit calcule une marge réelle (à partir des coûts de main-d'œuvre et hors main-d'œuvre réels) et une marge prévisionnelle (à partir des allocations planifiées et du chiffre d'affaires prévisionnel), pour qu'un projet puisse être piloté avant et après coup.
• Coûts hors main-d'œuvre : licences, matériel, cloud, sous-traitance et dépenses similaires sont enregistrés sur un projet.
• Export de facturation : un export de timesheet ligne à ligne (tickets externes inclus) adapté à la facturation, disponible en CSV et XLSX derrière une permission finance.

Tickets externes

Les tickets externes permettent de saisir du temps sur des éléments de travail qui vivent dans un autre outil, un système de ticketing comme Jira ou ServiceNow, sans quitter Vaks PM. Ils sont délibérément réservés à la timesheet : on peut saisir du temps sur un ticket externe, mais il n'apparaît jamais sur les tableaux, dans le Gantt, dans la charge ou dans les rapports, et il ne peut pas porter d'allocations, de dépendances ou de sous-tâches manuelles.

Comment ça fonctionne : les tickets d'un outil donné sont regroupés dans des projets conteneurs masqués (un par outil, optionnellement par client), de sorte qu'ils n'encombrent jamais la liste réelle des projets. Un ticket stocké est identifié par un triplet générique : sa source (l'outil), sa clé (l'identifiant lisible du ticket, comme INC0010023) et une URL optionnelle de retour vers la source. Le même ticket est enregistré une seule fois (de façon idempotente) puis apparaît comme une ligne sur laquelle l'utilisateur peut saisir des heures. Pour récupérer les tickets depuis un système en service, voir Connecteurs externes.

Authentification unique (SSO) OIDC SAML

Le SSO permet aux utilisateurs de se connecter avec leur identité d'entreprise existante au lieu d'un mot de passe détenu par Vaks PM. Le fournisseur d'identité réalise l'authentification, y compris toute politique de multi-facteur et d'accès conditionnel qu'il applique, et renvoie une assertion signée que l'application reconnaît. Deux protocoles sont pris en charge : OIDC (la méthode recommandée, utilisée avec Microsoft Entra ID) et SAML 2.0 (pour les environnements standardisés sur SAML).

Ce qu'il fournit

• Provisionnement à la volée (JIT, Just-in-Time) : un compte est créé automatiquement à la première connexion réussie (configurable ; il peut au contraire être exigé qu'il préexiste).
• Mappage des rôles : les groupes (ou rôles applicatifs) asserts par le fournisseur d'identité sont mappés vers des rôles Vaks PM, de sorte que les droits d'accès suivent l'annuaire. Le mappage est réévalué à chaque connexion, et une connexion qui ne renvoie aucun groupe ne rétrograde jamais un utilisateur, pour éviter tout verrouillage.
• Rapprochement de compte : les utilisateurs récurrents sont rapprochés sur un identifiant stable (l'object ID Entra) plutôt que sur l'email, de sorte qu'une entrée d'annuaire renommée ou recréée ne puisse pas reprendre un compte existant.
• Accès de secours (break-glass) : des comptes administrateur locaux désignés peuvent toujours se connecter avec un mot de passe et un MFA forcé, de sorte que l'organisation ne soit jamais verrouillée si le fournisseur d'identité est indisponible.

État initial & activation

Une instance neuve fonctionne sur des comptes locaux ; le SSO est configuré ensuite sous espace admin → Authentification unique. Pour OIDC avec Microsoft Entra ID, la marche à suivre est :

1. Enregistrer une application dans Entra et noter son URI de redirection (l'adresse vers laquelle Entra renvoie l'utilisateur après authentification).
2. Créer un secret client dans Entra et le copier (affiché une seule fois) — ou, en alternative, enregistrer un certificat pour s'authentifier sans secret partagé (voir l'encadré ci-dessous).
3. Configurer les claims, les permissions API et les groupes (ou rôles applicatifs) qui piloteront le mappage des rôles.
4. Créer le fournisseur dans Vaks PM avec l'URL de découverte Entra, l'identifiant client et le secret client (ou le certificat) ; définir les règles de mappage des rôles et le comportement JIT.
5. Tester la connexion, puis activer le fournisseur.

Provisionnement automatisé (SCIM) RFC 7644

Le SCIM permet au fournisseur d'identité de maintenir automatiquement les comptes Vaks PM synchronisés, afin que les administrateurs ne créent ni ne désactivent les utilisateurs à la main. L'annuaire pousse les changements vers un endpoint Vaks PM chaque fois qu'un utilisateur arrive, change ou part. Il est généralement couplé à OIDC pour que l'authentification et le cycle de vie soient tous deux pilotés par l'annuaire.

• Utilisateurs : création, mises à jour d'attributs, suspension et réactivation. Suspendre un utilisateur dans l'annuaire désactive le compte ici, révoque ses sessions et libère son siège de licence ; un re-provisionnement le réactive.
• Groupes → équipes : les groupes d'annuaire sont synchronisés vers les équipes Vaks PM, y compris leur composition.
• Attributs entreprise : les attributs utilisateur standard SCIM et ceux de l'extension entreprise sont mappés vers les champs correspondants.

Activation : l'espace admin génère un jeton secret SCIM et l'URL SCIM du tenant ; dans l'annuaire, une configuration de provisionnement utilise cette URL et ce jeton, avec les utilisateurs et groupes concernés affectés. Un agent de provisionnement sur site est pris en charge pour les instances qui ne sont pas joignables publiquement.

Notifications par courriel livré

Vaks PM envoie des notifications par courriel brandées lorsque des événements pertinents surviennent. L'envoi est asynchrone : les messages sont mis en file et envoyés par le worker de fond, de sorte qu'un relais de messagerie lent ne bloque jamais l'application.

Événements couverts

• Affectation : un utilisateur est assigné à une tâche.
• Changement de statut : une tâche à laquelle un utilisateur participe change de statut.
• @mentions : un utilisateur est mentionné dans un commentaire.
• Rappels d'échéance : envoyés un nombre de jours configurable avant l'échéance d'une tâche.
• Digest : un résumé quotidien ou hebdomadaire à une heure choisie.
• Alertes opérationnelles : par exemple les demandes de compétence et les alertes d'audit.

Configuration

Une action Envoyer un courriel de test et une action Aperçu du modèle valident la configuration sans attendre un événement réel, et un journal de livraison enregistre chaque message et son résultat. Les notifications sont optionnelles : sans relais SMTP configuré, l'application fonctionne normalement, et seules les notifications sortantes sont indisponibles.

Automatisations livré

Les automatisations sont des règles de surveillance livrées avec le produit : elles observent en continu les tâches, le planning, la charge, la timesheet, le budget, les compétences et les agents IA, et alertent les bonnes personnes quand une situation dérive. Il n'y a pas de constructeur de règles à la Zapier : l'administrateur ne compose rien, il active ou désactive des règles prêtes à l'emploi et en règle les seuils. Le but est explicite — pas de canevas vide à remplir, mais un jeu de garde-fous qui fonctionne dès la première journée.

La très grande majorité des règles sont de la notification pure : elles ne changent aucun statut, ne réassignent aucune tâche, ne suppriment rien. Ce qu'elles produisent, c'est un signal adressé à quelqu'un qui peut agir. Une poignée de règles explicitement identifiées — détaillées dans Actions automatiques plus bas — font exception et écrivent réellement, mais toujours de façon étroite, réversible et tracée : jamais de suppression, jamais de réassignation de personne.

Comment une règle se déclenche

Trois cadences coexistent, et chaque règle appartient à l'une d'elles :

• Horaire — évaluée à chaque heure. Réservée à ce qui doit être vu vite (budget d'un agent IA, livrable qui attend une revue).
• Quotidienne — évaluée une fois par jour, à une heure choisie par l'organisation (Heure d'exécution quotidienne, 7 h UTC par défaut). L'essentiel du catalogue vit ici.
• Hebdomadaire — évaluée un jour et une heure choisis (vendredi 16 h UTC par défaut), et portant toujours sur la semaine écoulée, jamais sur la semaine en cours.

Trois règles ne suivent aucune horloge : elles réagissent à l'événement, dans la seconde qui suit l'action qui les concerne (création d'une tâche, saisie d'un congé, application d'un auto-plan).

Ce qui protège de l'inondation d'alertes

Une règle qui répète la même alerte tous les jours cesse d'être lue. Quatre mécanismes s'y opposent :

Catalogue des règles

Les règles dont le défaut est Off ne sont pas moins fiables : elles sont simplement plus sensibles au contexte (ce qui est du bruit chez un client est un signal chez un autre), et méritent donc un choix explicite.

Hygiène des tâches quotidien

Échéances & planning

Charge & capacité

Timesheet hebdomadaire

Ces trois règles partagent le même rendez-vous hebdomadaire (le jour et l'heure réglés pour le rappel de timesheet) et portent sur la semaine ISO écoulée.

Finance quotidien

Compétences à l'événement

Agents IA horaire

Actions automatiques (mutations)

Toutes les règles précédentes se contentent d'alerter. Trois règles, et elles seules, agissent sur une tâche à la place d'un humain — toujours de façon étroite et réversible, jamais en supprimant ni en réassignant une personne :

Une action automatique passe toujours par le même service métier qu'une action humaine équivalente (elle ne touche jamais la base directement), porte un acteur système distinct d'un humain et d'un agent IA, et est enregistrée dans le journal d'audit sous une action dédiée. Ces trois règles sont désactivées par défaut : une organisation les active explicitement une fois qu'elle a validé le comportement des règles de notification équivalentes.

Tâches récurrentes

Une tâche récurrente se répète selon une fréquence choisie (par exemple chaque semaine, ou le premier jour ouvré du mois) : à chaque échéance, une nouvelle occurrence est créée automatiquement à partir du même gabarit, sans qu'un chef de projet n'ait à la recréer à la main. La configuration se fait depuis le détail d'une tâche — fréquence et jour de la semaine ou du mois — et ne s'applique ni aux sous-tâches ni aux tickets externes.

Suivre une tâche ou un projet

Le destinataire naturel d'une alerte est celui que la règle désigne — l'assigné, le chef de projet, le lead. Cela laisse de côté quelqu'un qui a besoin de savoir sans être responsable : un sponsor, un architecte, un lead technique consulté sur un sujet précis.

Le bouton Suivre, sur une tâche ou un projet, répond à ce besoin. Un suiveur est un abonné passif : il reçoit toutes les alertes d'automatisation portant sur ce qu'il suit, ainsi que les changements de statut et les nouveaux commentaires — sans être assigné, sans droits supplémentaires, et sans rien devoir à personne. Le suivi s'arrête d'un clic, et la page de compte liste ce que l'on suit.

Où sortent les alertes

Chaque alerte emprunte trois canaux, indépendants les uns des autres :

• Courriel — un message brandé et localisé dans la langue du destinataire, via la même chaîne que les autres notifications. L'interrupteur d'arrêt des courriels coupe ce canal seul.
• Webhook — un événement automation.alert poussé sur les webhooks abonnés, avec la règle concernée comme discriminant. Au format teams, l'alerte arrive comme une carte lisible dans le canal du projet ou de l'équipe : c'est la voie recommandée pour les organisations qui vivent dans Teams et ne veulent pas d'un canal de plus.
• Journal d'audit — toute action automatique est tracée avec un acteur système, distinct d'un humain comme d'un agent IA. Une alerte est donc toujours explicable après coup : qui l'a reçue, pourquoi, et quand.

Ces canaux ne se remplacent pas : couper les courriels ne coupe ni les cartes Teams ni la trace d'audit.

Administration

Tout se règle dans Admin › Automatisations, organisé en cartes par famille (hygiène des tâches, échéances, charge, timesheet, budget, projets, agents). Chaque règle y expose son interrupteur et ses seuils ; les valeurs hors bornes sont refusées à la saisie plutôt qu'appliquées silencieusement. Les réglages globaux — interrupteur d'arrêt, heure d'exécution quotidienne, jour et heure du rendez-vous hebdomadaire — vivent en tête de section.

Une action Exécuter maintenant lance une évaluation immédiate sans attendre l'heure prévue et renvoie le décompte de ce qui a été envoyé, mis en attente, différé ou plafonné. Elle ignore les horloges mais respecte l'interrupteur d'arrêt et les périodes de calme — c'est donc un outil de vérification honnête, pas un moyen de forcer un renvoi. Le réglage des automatisations demande le droit d'administration de l'organisation ; les alertes des agents IA sont visibles par le propriétaire de l'agent et les administrateurs IA.

Webhooks livré

Un webhook est un appel HTTP sortant que Vaks PM effectue vers une URL au choix de l'administrateur lorsqu'un événement survient. C'est le mécanisme pour pousser les changements vers un autre système (un outil de ticketing, un canal de discussion, une plateforme d'automatisation) en quasi temps réel.

Événements & formats

Un webhook s'abonne aux événements qu'il souhaite, parmi :

• Tâches : cycle de vie standard (créée, mise à jour, supprimée, déplacée, assignée, désassignée, terminée) et cycle de vie agent (réclamée, relâchée, revue demandée, changements demandés, approuvée — voir Agents IA), plus les livrables associés (soumis, révisé).
• Commentaires : créé.
• Projets : créé, mis à jour, activé (le passage à Actif, distinct d'une simple mise à jour — c'est ce déclencheur qu'utilisent en interne les fournisseurs Collaboration spaces pour créer l'espace du projet) et annonce (voir Sponsors & annonces).
• Demandes de compétence : créée, accusée réception, résolue, rejetée, relancée.

Trois événements système supplémentaires existent en dehors de ce mécanisme de souscription par projet/équipe : une alerte d'audit (voir Journal d'audit), un échec de sauvegarde, et une alerte d'automatisation (voir Automatisations) — ces trois-là s'abonnent au niveau organisation. Le format de payload est soit raw (l'événement JSON natif) soit teams (une Adaptive Card Microsoft Teams / Power Automate), de sorte qu'un canal puisse recevoir directement des cartes lisibles.

Sécurité & signature

• Chaque livraison est signée avec HMAC-SHA256 sur le corps de la requête à l'aide d'un secret propre au webhook, de sorte que le destinataire puisse vérifier l'authenticité et l'intégrité. La signature, le nom de l'événement, un identifiant de livraison et un horodatage voyagent dans les en-têtes de requête (X-Vaks-Signature, X-Vaks-Event, X-Vaks-Delivery, X-Vaks-Timestamp). Le secret peut être tourné à tout moment.
• Contrôles anti-abus : une liste d'autorisation des domaines sortants, une protection contre les requêtes vers des adresses réseau internes, et une désactivation automatique d'un endpoint après des échecs répétés.
• La livraison est réessayée plusieurs fois avec un back-off exponentiel, et une livraison échouée peut aussi être rejouée manuellement.

Périmètres

Un webhook peut couvrir toute l'organisation, ou être rattaché à un seul projet ou à une seule équipe. Avec une politique en libre-service, un chef de projet ou un lead d'équipe peut gérer les webhooks de son propre projet sans droits d'admin complets. L'interface d'administration liste les endpoints, les crée et les édite, tourne les secrets, envoie un événement de test, et affiche un journal de livraison avec le payload, les en-têtes et la réponse de chaque tentative ainsi qu'un rejeu manuel.

Clés API livré

Les clés API accordent un accès programmatique à l'API REST publique (la même API que celle utilisée par l'app web, sous /api/v1). Elles permettent aux scripts, intégrations et systèmes partenaires d'appeler Vaks PM sans session de navigateur. Il en existe deux types :

Modèle de sécurité

• Le secret est affiché une seule fois, à la création, et n'est jamais stocké en clair. Seul un hash est conservé, avec un préfixe affichable pour identifier la clé par la suite.
• Surface publique uniquement : une clé ne peut appeler que les routes explicitement publiées sur l'API publique, et est rejetée sur les routes internes et d'app privée par conception.
• L'expiration est obligatoire, plafonnée à deux ans, il n'y a donc pas de clés permanentes. Un rappel par courriel est envoyé 14 jours avant l'expiration d'une clé (à l'utilisateur propriétaire, ou aux administrateurs globaux pour une clé d'organisation).
• Limitation de débit : chaque clé dispose de son propre budget de requêtes par fenêtre de temps (limites distinctes et configurables au niveau IP, PAT et clé d'organisation), appliquée à l'échelle du cluster. Une clé peut aussi être révoquée à tout moment.

Connecteurs externes configuration admin disponible

Un connecteur externe relie Vaks PM à un système de ticketing tiers, par exemple ServiceNow ou Jira, afin que les personnes puissent enregistrer du temps sur des tickets qui vivent dans cet autre outil, depuis leur timesheet hebdomadaire (voir Tickets externes). Un connecteur est un pont en lecture seule : Vaks PM récupère une liste de tickets et les référence, et ne modifie jamais rien dans le système source.

Les connecteurs se configurent sous espace admin → Intégrations → Connecteurs externes. Chaque connecteur s'authentifie avec un compte de service dédié dont les identifiants sont chiffrés au repos (AES-256-GCM) et ne sont plus jamais affichés une fois enregistrés. La conception est agnostique du fournisseur : le même flux de timesheet, la même idempotence et les mêmes projets conteneurs s'appliquent à tout outil, et chaque fournisseur déclare ses propres champs de configuration.

Fournisseur exemple : ServiceNow

Le connecteur ServiceNow lit les tickets via la ServiceNow Table API en utilisant un compte de service (authentification Basic), avec des recherches restreintes à l'utilisateur courant. Ses champs de configuration sont l'URL de l'instance, le nom d'utilisateur et le mot de passe du compte de service, les tables de tickets à exposer (incident, sc_task, change_task, problem, ou la table de base task), et un filtre de base optionnel (une requête encodée ServiceNow ajoutée à chaque recherche pour restreindre les résultats, par exemple active=true). Une action Test effectue un appel authentifié léger et signale le succès, un échec d'authentification, ou une instance injoignable.

Collaboration spaces Premium

Lorsqu'un projet devient actif, Vaks PM peut créer automatiquement un espace de collaboration via l'un de trois fournisseurs en self-service — Microsoft Teams, Slack ou Google Chat — configurés indépendamment, chacun dans sa propre carte admin. Le provisionnement est idempotent : ré-activer un projet ne crée jamais un second espace. Un outil externe qui gère son propre espace peut aussi déclarer le lien en retour, via une clé d'API à périmètre étroit, sans avoir besoin de configurer l'un de ces fournisseurs.

Microsoft Teams est le plus riche des trois : un nom construit à partir d'un modèle, un ensemble configurable de canaux, et (seul des trois) l'archivage à la clôture — quand le projet se clôture l'équipe est archivée (lecture seule, réversible), et désarchivée à la ré-activation. Slack et Google Chat créent leur espace et invitent les membres de la même façon, mais ne sont aujourd'hui pas archivés automatiquement à la clôture. C'est une fonctionnalité premium (droit de licence teams-provisioning, partagé par les trois fournisseurs), entièrement optionnelle par organisation.

Étapes d'activation (Microsoft Teams)

1. Enregistrer une application Entra dédiée à Vaks PM (mono-tenant convient ; pas d'URI de redirection, car cela utilise le flux client-credentials). Créer un secret client (ou un certificat, en alternative sans secret — voir SSO) et noter le tenant ID et le client ID.
2. Accorder les permissions d'application Graph. L'ensemble au moindre privilège est Team.Create, TeamMember.ReadWrite.All, Channel.Create, TeamSettings.ReadWrite.All et (recommandé) User.Read.All ; puis faire cliquer un Administrateur global sur Accorder le consentement administrateur.
3. Configurer dans Vaks PM sous espace admin → Intégrations → Collaboration spaces, sur la carte Microsoft Teams : les tenant/client IDs et le secret, le motif de nom d'équipe, les canaux, la visibilité, le périmètre de composition (équipes affectées, membres du projet, ou les deux), et s'il faut archiver à la clôture.
4. Tester la connexion, s'assurer que le projet cible a au moins un membre lié à Entra, puis passer un projet en actif ou utiliser Provisionner maintenant.

Slack et Google Chat sont plus simples : un bot token (Slack) ou un compte de service impersonnant un utilisateur Workspace (Google Chat) suffisent — pas d'exigence de membre lié à l'annuaire, puisqu'aucun des deux n'a besoin d'un propriétaire comme une équipe Teams.

Connecteur IA (MCP) Premium livré

Le connecteur IA expose un serveur Model Context Protocol (MCP) : tout assistant IA compatible (par exemple Claude, ChatGPT ou Microsoft Copilot Studio) peut s'y connecter pour lire et, si autorisé, agir sur les projets de l'organisation, au nom de l'utilisateur connecté et strictement dans le cadre de ses permissions. Le produit n'héberge aucune IA en propre ; l'intelligence vit dans le client, et Vaks PM fournit les données et les actions. Il n'y a aucune clé IA à gérer.

Connexion déléguée

Un utilisateur ajoute l'URL du serveur MCP de l'organisation (https://<organization>/mcp) dans son client IA. Le client détecte l'authentification automatiquement et ouvre une page de connexion dans le navigateur, où l'utilisateur se connecte avec son compte habituel (local ou SSO), puis approuve un écran de consentement résumant ce que l'IA pourra faire. L'authentification utilise OAuth 2.1 avec PKCE (Proof Key for Code Exchange), fédérée vers l'identité existante. Le jeton d'accès émis est à durée de vie courte et rafraîchi automatiquement. Les clients qui ne peuvent pas s'auto-enregistrer (par exemple Copilot Studio) utilisent un client OAuth pré-enregistré créé dans l'espace admin.

Activation par l'admin : trois bascules indépendantes

L'écran de consentement reflète ces bascules. Le connecteur est désactivé par défaut et optionnel par organisation ; les bascules sont indépendantes et réversibles. Les écritures finance requièrent les trois conditions réunies (écritures activées, finance exposée, et l'utilisateur détenant la permission finance). Les utilisateurs de l'app web ne sont jamais affectés par la bascule finance ; elle s'applique uniquement aux jetons.

Agents IA livré

Un agent IA (agent d'intelligence artificielle : un travailleur logiciel automatisé piloté par un grand modèle de langage) est traité comme un acteur de première classe dans Vaks PM, au même titre que les utilisateurs humains. Un agent peut se voir confier du travail, réclamer des tâches, produire des livrables et déclarer son coût — mais il est gouverné bien plus strictement qu'une personne. Cette section explique ce qu'est un agent, comment l'intégration fonctionne de bout en bout, et comment un administrateur provisionne, gouverne et gère les agents. Elle s'appuie sur le connecteur IA (MCP) (le transport qu'un agent utilise pour atteindre le produit) et sur le modèle RBAC.

Identités & provisioning

Un agent est une identité dédiée (ce n'est pas un identifiant partagé ni un compte humain). Il porte un nom d'affichage, un e-mail interne synthétique de la forme agent-<nom>@agents.invalid, un propriétaire obligatoire, un niveau de confiance, un ensemble de capacités (voir plus bas) et un profil optionnel de modèle/coût. Les agents sont créés de trois manières :

Chaque agent s'authentifie avec son propre PAT (Personal Access Token, jeton d'accès personnel), distinct de tout jeton utilisateur, avec une expiration obligatoire (90 jours par défaut, 2 ans maximum) et affiché une seule fois à la création. Le provisioning exige toujours un propriétaire : un connecteur d'annuaire qui ne peut pas en fournir un retombe sur un propriétaire par défaut configuré. Les agents sont uniquement suspendus, jamais supprimés silencieusement.

Obtenir un jeton sans secret à distribuer Premium

Émettre un PAT manuellement reste la voie par défaut et fonctionne toujours ; elle devient lourde au-delà de quelques dizaines d'agents, chacun avec un secret à distribuer et à faire tourner. Deux mécanismes s'y ajoutent pour éliminer ce fardeau, sous la licence agent-federation :

Dans les deux cas, un jeton obtenu n'accorde jamais de droits par lui-même : les portes habituelles s'appliquent toujours (propriétaire humain actif, agent non suspendu, capacités déclarées). Le détail des deux mécanismes, plateforme par plateforme, vit dans le guide Authentification des agents.

Ce qu'un agent peut faire — capacités & permissions

Les droits effectifs d'un agent sont l'intersection de trois limites : les permissions RBAC de son rôle, les portées (scopes) de son jeton, et ses capacités déclarées. Une permission doit apparaître dans les trois pour que l'agent puisse l'utiliser. Les capacités sont, par construction, incapables d'accorder les actions les plus sensibles — un agent ne peut jamais obtenir de permissions finance, gestion client, administration ou saisie de temps. De plus, un jeton d'agent n'agit que sur la surface d'API publique : il est rejeté sur l'application d'administration privée, même si le compte sous-jacent est privilégié. Le résultat net est qu'un agent opère dans un sous-ensemble strict de ce qu'un contributeur humain prudent pourrait faire.

Comment travaillent les agents — tirer, réclamer, livrer, réviser

Les agents suivent un modèle en « pull » (tirer) plutôt qu'en poussée. Un agent se connecte au serveur MCP de l'organisation avec son PAT, puis traite une tâche selon un cycle de vie appliqué côté serveur :

Les statuts de tâche concernés sont À faire → Réclamée → En cours → En revue → Approuvée → Terminée, plus Changements demandés. Le journal vivant est alimenté uniquement par les livrables approuvés, de sorte qu'une production non révisée ne peut jamais contaminer le contexte futur d'un agent.

Gouvernance — activation, policies, budgets & vérification

Les agents sont désactivés par défaut et contraints à plusieurs niveaux indépendants :

• Projets ouverts aux agents : un projet doit être explicitement ouvert aux agents et porter un brief écrit avant qu'un agent puisse y réclamer du travail. Les projets non ouverts aux agents ne sont pas affectés.
• Policies : des règles déclaratives, configurées sous Utilisateurs & Identité → Policies agents, sont évaluées à chaque transition d'état. Une règle peut exiger une revue, refuser l'action, ou notifier, selon des conditions telles qu'une étiquette, le niveau de confiance de l'agent, l'estimation de la tâche ou la transition elle-même. Un réglage de backpressure de revue plafonne le nombre d'éléments en attente de revue humaine par projet, pour que les agents ne prennent pas de l'avance sur les réviseurs.
• Budgets : des plafonds de coût dans la devise de l'organisation sont appliqués au moment de la réclamation — par agent (jour et mois), par projet, et par tâche. Dépasser un plafond refuse la réclamation avec un motif clair plutôt que de dépenser silencieusement au-delà.
• Vérification des livrables : chaque livrable est évalué par une porte déterministe qui classe la force de la preuve qui le soutient. Le sujet est détaillé dans la section suivante.

Vérification des livrables & preuve d'intégration continue

Quand un agent annonce « c'est fait, mes tests passent », rien n'oblige à le croire sur parole. Vaks PM classe chaque livrable selon la force de la preuve qui le soutient, sur une échelle allant de la simple déclaration de l'agent à la revue humaine :

La méthode exigée pour un livrable donné n'est pas choisie par l'agent : elle est dérivée de l'enjeu de la tâche croisé avec le niveau de confiance de l'agent. Une tâche à faible enjeu confiée à un agent éprouvé se contente d'une auto-attestation ; une tâche critique exige une revue humaine quel que soit l'agent. Si le terrain ne permet pas de produire la méthode requise — un dépôt sans CI, par exemple — l'exigence retombe sur la revue humaine. Il n'y a jamais de blocage sans issue.

La preuve d'intégration continue, concrètement

C'est le seul niveau de preuve mécanique qu'un agent ne peut pas fabriquer, et il repose sur un principe simple : Vaks PM ne se connecte jamais à votre chaîne d'intégration continue. Il n'a aucun accès sortant, ne détient aucun identifiant chez votre hébergeur de code, et n'interroge rien. C'est votre CI qui pousse son résultat vers Vaks PM, et la seule chose que le serveur fait activement est de vérifier une signature calculée avec un secret partagé convenu à l'avance.

Le rapprochement entre un résultat de CI et une tâche se fait par le SHA du commit — l'empreinte unique d'un enregistrement dans le dépôt de code. Votre CI ne connaît ni vos projets ni vos tâches : elle dit seulement « le commit abc123 a fini, verdict succès ». De son côté, l'agent, qui sait sur quelle tâche il travaille, déclare le SHA du commit qu'il a produit en soumettant son livrable. Vaks PM apparie les deux. Les deux flux arrivent dans n'importe quel ordre — la CI signe souvent avant que l'agent n'ait fini de rédiger son livrable — c'est pourquoi les résultats reçus sont conservés 24 heures en attente d'appariement.

Un connecteur de CI se configure sous Intégrations → Vérification CI, à raison d'un par organisation et par outil. Le secret partagé y est saisi une fois et chiffré au repos ; l'interface ne le réaffiche jamais. Deux formats sont pris en charge :

Chaque résultat reçu est consigné dans le journal d'audit, tout comme les rejets : une signature invalide est traitée comme une tentative de falsification, pas comme une erreur bénigne. Le connecteur affiche le diagnostic du dernier événement reçu, ce qui permet de vérifier un branchement sans fouiller les journaux.

Observation seule ou application stricte

La porte de vérification tourne par défaut en observation seule : elle mesure la force de la preuve fournie face à ce qui était exigé, journalise l'écart, mais ne bloque ni n'approuve rien de sa propre autorité. C'est délibéré — cela permet de collecter des données de calibration réelles avant de serrer. Un projet peut ensuite basculer en application stricte, où une preuve insuffisante escalade au lieu de passer. Le réglage se fait par projet, dans l'onglet IA de ses paramètres, et un projet qui ne tranche pas hérite du défaut de l'organisation : on peut ainsi serrer sur un projet outillé tout en restant en observation partout ailleurs.

Coût & facturation

Un agent n'a pas de feuille de temps ; sa consommation se mesure en usage du modèle, pas en heures. Après avoir travaillé, un agent déclare le coût réel de chaque exécution (le nombre de jetons — tokens — d'entrée et de sortie, un token étant l'unité dans laquelle les modèles de langage comptent le texte). Le coût interne est dérivé de taux configurables par 1000 tokens d'entrée et de sortie, et le montant facturé à un client, le cas échéant, d'un taux de vente distinct par 1000 tokens. Ces chiffres alimentent la vue de résultat (profit & perte) du projet, les rapports projet et portefeuille, et les exports CSV, tableur et PDF, de sorte que le coût et le revenu des agents apparaissent aux côtés du travail humain.

Gérer les agents — espaces admin & le rôle « Administrateur IA »

Trois espaces d'administration couvrent le quotidien : Agents (identités, propriétaires, confiance, capacités et jetons, sous Utilisateurs & Identité), Annuaires d'agents (connecteurs externes, sous Intégrations), et Policies agents (règles de gouvernance et backpressure, sous Utilisateurs & Identité). Par défaut, ces espaces exigent des droits d'administrateur complets.

Pour les organisations qui veulent déléguer la gestion des agents sans distribuer l'administration complète, un octroi « Administrateur IA » est disponible. Ce n'est pas un rôle distinct — l'utilisateur conserve son rôle d'organisation existant — mais un octroi orthogonal et cumulable qui ajoute la seule permission « gérer les agents » par-dessus le rôle que la personne détient déjà (par exemple un chef d'équipe ou un simple membre). Un administrateur l'active sur le profil d'un utilisateur (sous Utilisateurs & Identité → Utilisateurs). Un utilisateur qui ne détient que cet octroi atteint l'espace d'administration en mode restreint : les trois espaces d'agents ci-dessus sont visibles et utilisables, et rien d'autre — pas de réglages, pas de gestion des membres, pas de journal d'audit.

État initial & activation

À partir d'une installation vierge, activer les agents de bout en bout comporte les étapes suivantes :

1. Créer une identité d'agent et lui affecter un propriétaire humain (Utilisateurs & Identité → Agents), ou connecter un annuaire d'agents pour en importer une.
2. Définir ses capacités au minimum requis par le travail, et générer son jeton d'accès (le noter — il n'est affiché qu'une fois).
3. Ouvrir un projet aux agents et lui donner un brief ; définir éventuellement des budgets de projet et de tâche.
4. Configurer les policies (exiger une revue, backpressure) selon l'appétence au risque de l'organisation.
5. Donner à l'agent l'accès via le connecteur IA. Comme les agents agissent par MCP, le connecteur doit être activé et la licence de l'organisation doit accorder le droit mcp ; les actions d'écriture des agents requièrent en plus la bascule d'écriture du connecteur. Voir connecteur IA (MCP).

Journal d'audit & SIEM livré

Le journal d'audit enregistre qui a fait quoi, quand et d'où : une piste en ajout seul (append-only) pour la revue de sécurité, la conformité et la réponse aux incidents. Il peut être lu dans l'espace admin, exporté, transmis à un SIEM, archivé et vérifié contre l'altération.

Modèle de capture

• Chaque mutation authentifiée (création / mise à jour / suppression) est capturée automatiquement, avec l'action, l'acteur, la ressource concernée et un libellé lisible qui survit à la suppression ultérieure de la ressource. Pour les tâches et les projets, une différence avant/après est enregistrée.
• Les événements de sécurité critiques sont capturés explicitement avec un contexte supplémentaire : succès et échec de connexion (avec raison et adresse IP), événements MFA, changements de mot de passe, rejeu d'un jeton révoqué, création et révocation de clé API, création / suspension / suppression / changement de rôle d'utilisateur, et changements de paramètres (avec un diff).
• Les valeurs sensibles sont caviardées (mots de passe, jetons, secrets) avant stockage.

Lecture, export & transmission

• Dans espace admin → Sécurité & conformité → Journal d'audit : filtrer par action, sévérité, résultat, acteur, plage de dates et texte libre ; déplier toute entrée ; et exporter. Les formats d'export sont JSON Lines et CEF (Common Event Format, adapté aux SIEM).
• Récupération programmatique (pull) : un endpoint API en lecture seule (rattaché à une permission audit:read) permet à un SIEM ou un système d'archivage de récupérer le journal selon une planification, avec une clé API d'organisation.
• Envoi syslog (push) : le journal peut être poussé vers un SIEM en temps réel via syslog (RFC 5424) sur TCP, optionnellement sur TLS, avec une sévérité minimale configurable, un bouton de test de connexion, et une prise en charge du TLS mutuel pour les collecteurs qui l'exigent.

Rétention, archive & intégrité

• Rétention : les entrées plus anciennes qu'un nombre de jours configurable (par défaut 365) sont purgées par une tâche planifiée. C'est le seul chemin de suppression.
• Archive froide : optionnellement, les entrées sont écrites comme archives compressées dans le magasin objet avant la purge, dans un ordre fail-safe. Si l'archivage échoue, la purge est sautée pour que rien ne soit perdu.
• Preuve d'altération : une ancre d'intégrité quotidienne chaîne un hash des enregistrements de la veille ; une action verify recalcule la chaîne et indique si le journal stocké a été altéré.
• Alerte de force brute : des échecs de connexion répétés dans une fenêtre lèvent une alerte (courriel aux administrateurs, un webhook et une entrée d'audit), avec un temps de refroidissement pour éviter les déluges.

RGPD : anonymisation & portabilité

Vaks PM prend en charge le droit à l'effacement du RGPD (Article 17) et le droit à la portabilité (Article 20). Un administrateur peut anonymiser les données personnelles d'un utilisateur, d'un client ou d'un contact, et tout utilisateur peut exporter une copie de ses propres données.

Pseudonymiser, jamais supprimer

L'anonymisation ne supprime jamais un enregistrement. Elle écrase les champs qui identifient une personne avec une valeur neutre dérivée de l'identifiant interne (par exemple nom → Anonymised user <id>, email → anon-<id>@anonymized.invalid). C'est irréversible : le nom et l'email d'origine n'existent ensuite nulle part. Les enregistrements et leurs liens sont conservés pour que les saisies de temps, la finance et la piste d'audit s'additionnent toujours, mais plus rien ne pointe vers une personne identifiable. C'est l'approche reconnue lorsqu'une suppression complète romprait des obligations légales ou comptables.

L'anonymisation est idempotente (la relancer ne fait rien) et le dernier administrateur global restant ne peut pas être anonymisé. Chaque anonymisation et chaque export sont eux-mêmes enregistrés dans le journal d'audit, par id uniquement. L'export de données pour la portabilité est une copie JSON (profil, saisies de temps, allocations, commentaires, compétences, métadonnées des pièces jointes) téléchargée par l'utilisateur depuis ses paramètres de sécurité, ou par un administrateur au nom d'un utilisateur ; les secrets ne sont jamais inclus.

Licence & sièges

Vaks PM utilise un modèle de sièges explicite. Un siège est un utilisateur licencié ; le nombre d'utilisateurs licenciés est le nombre de sièges, et l'espace admin affiche les sièges utilisés par rapport au droit.

• Les utilisateurs licenciés obtiennent un accès complet au produit selon leur rôle.
• Les comptes admin-seul sans siège peuvent toujours accéder au portail d'administration (pour gérer l'instance) mais ne se voient pas accorder de siège de travail, et ne consomment aucun siège.
• Les sièges sont accordés et révoqués par un administrateur. Lorsque le provisionnement est piloté par l'annuaire, un utilisateur nouvellement provisionné peut être laissé en attente de siège plutôt que rejeté, de sorte que la synchronisation d'annuaire n'échoue jamais sur une limite de sièges.

Les capacités premium (par exemple le connecteur IA et le provisionnement Microsoft Teams) sont en outre conditionnées par des droits de licence nommés, indépendants du nombre de sièges, de sorte qu'une fonctionnalité n'est disponible que lorsque le droit est présent et que sa bascule admin est activée.

RBAC & permissions

L'accès est régi par un contrôle d'accès basé sur les rôles appliqué sur le serveur, pour chaque route REST et chaque événement temps réel, jamais uniquement dans le navigateur. Il existe neuf rôles système, rattachés soit à toute l'organisation (ORG) soit à un seul projet (PROJECT).

Les permissions elles-mêmes sont des scopes nommés que portent les rôles (et les clés API). Les scopes les plus pertinents pour un administrateur :

La sécurité des comptes inclut le hachage de mot de passe Argon2, une politique de mot de passe configurable, un verrouillage après des échecs répétés, le MFA basé sur TOTP, la rotation des jetons de rafraîchissement, et la capture de l'adresse IP et de l'identifiant de navigateur de chaque session. Pour les contrôles au niveau du déploiement (exposition réseau, TLS, secrets, chiffrement au repos), voir Sécurité.

Voir aussi : Accueil de la documentation · Architecture · Déploiement Docker Swarm · Déploiement Kubernetes · Sécurité · Exploitation · Session démo