← Retour à la vue RH Suivi · Suites de la réunion RH du 25/06/2026
Strateine · Suivi de réunion

Suites de la réunion RH — demande, solution, logique

Ce qui a été demandé en réunion, la solution livrée dans l'application, et le pourquoi de chaque choix. Court mais suffisant pour comprendre le raisonnement.

Réunion du 25/06/2026 Cible d'utilisation ~6-7 juillet Ordre : rh.html V1 → n8n → vraies données
01

Demandes → Solutions → Logique

Six points issus de la réunion. Les deux derniers (warnings & dossiers en souffrance) sont livrés ce 01/07.

#Demande RHSolution apportéeLogique (pourquoi ce choix)
1 Renommer « date butoir » en « estimé » Renommage complet UI + code (rh.html, guide-rh.html). planning.html garde « date butoir » (= échéance). « Estimé » dit ce que la donnée est (une prévision de charge), pas une contrainte de date — évite la confusion avec l'échéance réelle.
2 Masquer / afficher chaque type de temps sur la frise Filtre segmenté Estimé Planifié Réel qui masque chaque couche de la frise jour. Les 3 temps superposés surchargent la lecture : on laisse l'utilisateur isoler la couche qu'il veut comparer.
3 Voir les dossiers hors portefeuille (temps réel sur un dossier non détenu) Case dédiée (décochée par défaut, mode Réel uniquement), lignes en lecture seule, tag « hors portefeuille ». Le réel « suit la personne » même après réaffectation ; il faut le voir sans polluer le portefeuille théorique ni proposer de réaffectation dessus.
4 Visualiser d'un coup d'œil où en est chaque dossier (repère vs fait) Frise-jour : enveloppe estimé (orange, repère, hors totaux) + le planifié (bleu, jours à venir) remplacé par le réel (vert) une fois le travail fait ; filtre pour masquer chaque couche (cf. point 2). Cohérent avec la décision « planifié → réel » (statu quo, option C) : le réel consomme le planifié → on suit l'avancement (estimé repère vs réel), sans comparer planifié et réel sur le même jour (ce qu'aurait imposé l'option A, écartée).
5 Warning « réel << estimé » par ligne, avec remontée hiérarchique Badges de ligne par rôle (cliquables → ouvrent l'onglet souffrance filtré sur le collab) : Bilan en souffrance → badge sur le Chargé de mission (il le fait) + Chef de mission (remontée) ; TVA → badge sur le Collaborateur. Plus un badge par dossier dans le détail déplié. Chacun voit la souffrance de son travail sur sa ligne ; le Bilan remonte en plus au Chef de mission, responsable de la mission.
6 Dossiers en souffrance : vision globale, filtrable par collaborateur, TVA et Bilan Onglet dédié « Dossiers en souffrance » : 2 colonnes Bilan / Tenue / TVA séparées, tri du pire au moins pire, filtre par collab, légende explicite. Une vue de pilotage cabinet, séparée du travail mensuel, pour repérer vite les dérives et agir avant qu'il ne soit trop tard.
7 Vue semaine (en plus du mois) Onglet « Semaine » (Lun→Ven) = même tableau + détail que le mois, focalisé sur une semaine. Libellé de période cliquable pour choisir un mois ou une semaine ; choisir une semaine bascule en vue Semaine. Charge suit le toggle Réel/Théorique. Piloter la charge à la maille hebdo (repérer les surcharges d'une semaine précise) sans changer d'outil ni de logique.
8 Capacité réelle par personne (tous ne sont pas à 35 h) + retirer le temps administratif + alerte de surcharge Capacité = heures hebdomadaires du collaborateur (saisies dans OpenProject, 35 h par défaut) ÷ 5 × jours ouvrés du mois, moins 15 % de temps administratif. Rappel « 35 h/sem · −15 % » sous la capacité. Badge ⛔ Dépassement capacité : +X h dès que le prévu dépasse la capacité. Appliqué au tableau, à la heatmap et à la simulation. Un temps partiel doit « rougir » plus vite qu'un plein temps ; les 15 % d'admin ne sont jamais du temps productif. Rendre la capacité juste par personne.
9 Filtrer les destinataires par poste à la réaffectation Le menu « destinataire » ne propose que les collègues qui occupent déjà le poste des dossiers cochés (case décochable pour revoir tout le monde). On réaffecte un « Chargé de mission Bilan » à quelqu'un qui tient déjà ce rôle, pas à n'importe qui → moins d'erreurs de casting.
10 Simulation avant/après d'une réaffectation Bouton « Simuler l'impact (année) » (bloc brouillon) : ouvre une page de comparaison avec les heatmap-année Avant / Après pour les seuls collègues concernés — sans rien modifier tant qu'on n'a pas confirmé. Les mois modifiés sont surlignés dans l'en-tête.
👉 À REGARDER — 4 présentations au choix : ouvrir la maquette de simulation. Dites laquelle vous préférez, on fige ensuite.
Voir l'effet d'une réaffectation sur toute l'année avant de valider : est-ce que ça soulage vraiment le surchargé sans noyer le repreneur ?
02

Logique de la « souffrance » (détail des points 5-6)

Le warning doit prévenir (agir tant qu'il reste du temps), pas seulement constater. D'où ces règles :

  • Fenêtre = 12 derniers mois d'échéances jusqu'à aujourd'hui. Pas l'année civile, mais les échéances réelles des tâches : cela capte à la fois la TVA courante et la campagne bilan en cours — le bilan d'un exercice se fait l'année suivant sa clôture (ex. clôture 12/2025 → bilan produit en 2026). Les échéances encodant déjà la clôture, la contrainte compta est respectée.
  • Seules les tâches à échéance passée sont évaluées, sinon tout le travail pas-encore-fait paraîtrait « en retard ».
  • Comparaison par tâche : Σ réel / Σ estimé, Bilan et TVA séparés (rythmes très différents : campagne ponctuelle vs tenue récurrente).
  • Seuils : réel < 50 % = Retard (pas assez avancé) · > 120 % = Trop large (dépassement / mal calibré).
  • Plancher 4 h d'estimé échu : en-dessous, trop peu de matière pour juger (mention affichée pour ne pas dérouter).
  • Tout part de la tenue : si la TVA d'un dossier est en retard, une puce discrète ⚠ tenue en retard s'affiche sur la ligne Bilan (même si le bilan semble OK). Un bilan s'appuie sur une tenue à jour → tenue en retard = bilan à risque. Déclenché sur le retard seulement, cas rares.
Évolution possible (non activée) : remonter le nombre de « bilans à risque tenue » directement sur la ligne repliée du Chef / Chargé (badge séparé), pour que l'alerte saute aux yeux sans déplier. Laissé de côté pour rester sobre ; réactivable si besoin.
Limite actuelle (données PoC) : presque aucun temps réel n'est saisi hors du jeu de démo → la vue non filtrée affiche beaucoup de « retard » (réel = 0). En production, avec les vraies saisies, le signal sera pertinent. Un jeu de démo sème un mix propre sur 2 collaborateurs (voir la vue en filtrant par collab).
03

Lot V1 rh.html — terminé

Tous les points de la réunion sont livrés (reste à valider par vous dans le navigateur).

👉 À arbitrer par vous — la présentation de la page de simulation. Plusieurs mises en forme sont proposées : ouvrir la maquette (4 présentations au choix). Dites laquelle vous préférez, on fige la version définitive.

Exploratoire (non prioritaire) : théorique net du déjà-fait ; fiabilité des estimés (= qualité de donnée, hors code).

04

Comment tester (pas à pas)

Ouvrir la vue RH et faire Ctrl+F5 (recharge complète). On est sur des données de démo : on peut cliquer partout sans rien casser.

Astuce lecture : dans la heatmap, plus une case est rouge, plus le collaborateur est en dépassement ce mois-là. Une bonne réaffectation fait passer du rouge au bleu chez le surchargé sans créer de rouge chez le repreneur.
05

Décidé / confirmé en réunion

Pas de report du reliquat (linéaire ; tâche terminée → estimé restant disparaît ; warning plutôt que report).

Chronologie Wrike conservée (dates butoirs par tâche).

Réel conservé / planifié remis à zéro à la réaffectation.

Planifié → réel : statu quo (option C, tranché 01/07) — le réel consomme la tranche planifiée du même jour. On mesure le budget (estimé vs réel), pas l'adhérence jour par jour → aucune modif.

Plus tard (post-bascule) : blocages Sophie (salle / formation) → planning collab, idéalement bidirectionnel Outlook ; push « dossiers en souffrance » vers le planning collab.