Version 6.0 du 08/10/2026 - Version détaillée

⬅ NOTES DE VERSION 6.0 📌 VERSION WORD ILLUSTREE

Table des matières

1. Préambule
2. Général
   1. EL01 : [Transition Graphique] Evolution du design de la navigation. Le menu devient un menu latéral à niveaux multiples. Le cheminement se fait sur le modèle suivant : Module > Type (“Général”,”Synthèse”,”Administration”) > Section > Page. [Pas de Mantis]
   2. EL02 : [Transition Graphique] La déconnexion se fera désormais en bas du menu latéral [Pas de Mantis]
   3. EL03 : [Transition Graphique] Nouveau design du paramétrage des rôles : liste des rôles à gauche, détail à droite (premier rôle ouvert par défaut). Les droits se choisissent par boutons, avec modification en masse par rubrique, page à sous-menus, groupe d’actions et table de champs [Pas de Mantis]
   4. EL04 : [Transition Graphique] Paramétrage des rôles : affichage du nombre d’utilisateurs du rôle, du nombre de menus accordés et d’une infographie des niveaux de droits ; chaque rubrique et page à sous-menus indique son nombre d’accès [Pas de Mantis]
   5. EL05 : [Transition Graphique] Ajout d’une barre de recherche dans chaque onglet du paramétrage des rôles pour trouver plus facilement un menu, une action objet (par groupe ou par action) ou un champ accessible (par table ou par champ) [Pas de Mantis]
   6. EL06 : [Transition Graphique] Écrans épinglés : une étoile sur chaque écran du menu l’ajoute à la rubrique « Épinglés » en tête du menu. Réordonnables par glisser-déposer, ils sont enregistrés par utilisateur, quel que soit le poste [Pas de Mantis]
   7. EL07 : [Transition Graphique] Recherche dans le menu : un champ en tête du menu latéral (raccourci clavier Ctrl+K) filtre les écrans accessibles au fil de la saisie, avec parcours des résultats au clavier (flèches, Entrée, Échap) ; le volet des sous-menus d’une rubrique dispose de son propre filtre et de boutons « Tout déplier » / « Tout replier » [Pas de Mantis]
   8. EL08 : [Transition Graphique] Menu latéral repliable en rail de pictogrammes et redimensionnable. Nouvel espace « Préférences » (pied du menu), avec l’option « Menu toujours ouvert » ; préférences enregistrées avec le compte, quel que soit le poste [Pas de Mantis]
   9. EL09 : [Transition Graphique] Couleurs du menu déduites de la couleur principale de la charte du client. Fil d’Ariane, recherche générale, sélecteur de profil et actions de page sont regroupés dans l’en-tête ; l’utilisateur connecté est affiché au pied du menu [Pas de Mantis]
   10. EL10 : [Transition Graphique] Paramétrage des rôles : filtre des rôles par nom, option « N’afficher que les accès accordés », blocs pliables avec « Tout déplier / Tout replier », et compteur des modifications en attente sur le bouton d’enregistrement [Pas de Mantis]
   11. EL11 : [Transition Graphique] Création d’un rôle : il s’ouvre dans la fiche, tous accès refusés, et se paramètre avant le premier enregistrement. La duplication reprend le nom suivi de « copie » ; un rôle encore attribué ne peut plus être supprimé [Pas de Mantis]
   12. EL12 : [Transition Graphique] Nouveau design de l’écran « Outils > Optimisation BD » : rubriques à gauche, détail à droite, filtre unique, traitements en blocs pliables avec durée et date de dernière exécution, barre de progression des calculs et état des services par pastille [Mantis #19837]
   13. EL13 : [Accessibilité] Amélioration de l’accessibilité des écrans pour les utilisateurs de lecteurs d’écran et de navigation au clavier (alternatives textuelles des images, noms accessibles des boutons et des cadres, titre de page propre à chaque écran, mise en page sans sauts de ligne répétés). [Pas de Mantis]
   14. EL14 : [Accessibilité] Le paramètre “Graphismes - Couleur de Style” signale désormais une couleur au contraste insuffisant pour le RGAA et propose d’appliquer d’un clic une couleur conforme de même teinte [Pas de Mantis]
   15. EL15 : [Accessibilité] Ajout d’un lien d’évitement permettant d’accéder directement au contenu de la page, et balisage de la navigation et du contenu principal pour les technologies d’assistance [Pas de Mantis]
   16. EL16 : [Accessibilité] Icônes vectorielles : nettes à tout niveau de zoom, colorées selon leur contexte et visibles en contraste élevé. Le paramètre « Graphismes - Jeu d’icones » est retiré ; les instances sur les anciennes icônes basculent à la mise à jour [Pas de Mantis]
   17. EL17 : [Accessibilité] Ajout d’un mode contraste élevé directement activable depuis la mire de connexion ou depuis les préférences utilisateur. [Pas de Mantis]
   18. CL01A : Correction d’un blocage de compte à la connexion des utilisateurs dont le mot de passe, enregistré dans un ancien format et contenant des accents, pouvait être rejeté à tort selon le jeu de caractères du serveur [Mantis #19533]
   19. CL01B : La réinitialisation d’un mot de passe par un gestionnaire impose désormais son renouvellement par l’utilisateur lors de sa connexion suivante [Mantis #19533]
   20. CL01C : Correction de l’indicateur visuel de robustesse du mot de passe (écran de changement/renouvellement) qui pouvait rester figé et ne reflétait pas la politique de complexité réellement appliquée [Mantis #19533]
   21. CL02 : Correction de l’affichage des montants et des nombres arrondis dans l’ensemble de l’application : au-delà d’environ dix millions, la valeur affichée pouvait être tronquée (par exemple “1,23” à la place de “12345678,90”) voire plafonnée ; le formatage est désormais exact quel que soit l’ordre de grandeur [Pas de Mantis]
   22. CL03 : Renforcement de la sécurité des requêtes d’accès aux données sur plusieurs écrans : les valeurs transmises par les formulaires et les adresses y sont désormais systématiquement contrôlées avant d’être utilisées. Aucun changement de comportement pour l’utilisateur [Pas de Mantis]
   23. CL04 : Renforcement de l’étanchéité entre clients en multi-tenant : sessions, droits, journaux, exports d’interfaces et traitements automatiques sont cloisonnés par client. À la mise à jour, les utilisateurs connectés devront se reconnecter une fois [Pas de Mantis]
   24. CL05 : [Accessibilité] Les textes clignotants des écrans d’extraction et des interfaces sortantes utilisaient une balise obsolète ; ils sont remplacés par une animation conforme [Pas de Mantis]
   25. CL06 : [Accessibilité] Au survol, le libellé et l’icône des boutons secondaires (« Nouveau », « Tout déplier », « Tout replier »…) passaient en blanc sur un fond gris clair, au contraste très insuffisant ; ils restent désormais sombres, et l’icône d’un bouton survolé prend toujours la couleur de son libellé [Pas de Mantis]
3. GRH
   1. EH01 : Ajout du genre dans l’écran “GRH > Outils/Risques > Synthèses” [Mantis #19681]
   2. EH02 : Ajout d’une clé de traduction spécifique “DATE_OBTENTION_PERMIS” pour la date d’obtention des permis civils [Mantis #19592]
   3. EH03 : Dans les listes de gestion (ex. “GRH > Visites médicales > Permis civils”), le tri d’une colonne agent, carrière ou stagiaire externe se fait par nom puis prénom (session : intitulé ; poste : intitulé), et le tri inversé porte sur tous les critères [Mantis #19619]
   4. EH04 : Transition graphique - Revue du design et de la disposition des informations de l’agent/de la carrière et de l’organisation des onglets des écrans de consultation du livret individuel (“GRH / Général > Livrets individuels > Détails des livrets individuels / agents” et “Libre-service / Général > Mon Livret individuel > Détails livret individuel”) [Mantis #19887]
   5. EH05 : Transition graphique - Livret individuel en consultation (GRH et Libre-service) : fil d’Ariane de la section et du sous-écran, boutons pour plier ou déplier toutes les sections ou tous les blocs, et affichage possible d’informations de l’agent ou de sa carrière (voir EO17) [Mantis #19887]
   6. EH06 : Les modifications de carrière, anciennement disponible depuis le bandeau agent dans les livrets individuels, seront désormais présents dans un bloc dédié dans le sous-écran “GRH / Général > Livrets individuels > Détails des livrets individuels / Situation administrative > Grades / Carrières” [Mantis #19887]
   7. EH07 : Les situations familiales et les enfants d’un agent sont désormais affichés par ordre chronologique inverse (la plus récente situation et le plus jeune enfant en premier), notamment dans “GRH / Général > Livrets individuels > Détails des livrets individuels / Identité > Civilité” [Pas de Mantis]
   8. CH01 : Import du fichier de certification IDE (GRH > Déclaratifs > CIR) : la confirmation et le contrôle du nom du fichier ne s’exécutaient pas, et l’import partait sans demande de confirmation ; ils sont rétablis, avec un message de confirmation propre à ce fichier (il évoquait jusqu’ici les fichiers de base paie). Un nom de fichier qui ne correspond pas au fichier attendu ne bloque pas l’import : une confirmation est demandée (« Importer quand même ? ») [Pas de Mantis]
   9. CH02 : Correction du formatage de l’adresse courriel/UPN/sAMAccountName généré automatiquement lors de la création d’un agent via l’écran “GRH > Livrets individuels > Liste des Agents”, en processus guidé ou non [Mantis #19646]
   10. CH03 : Dans l’écran “GRH > Livrets individuels > Détails des livrets individuels”, l’adresse courriel suggérée (absente de la base) est désormais signalée par une icône, comme l’identifiant de connexion [Mantis #19646]
4. Paie DGFIP
   1. EI01A : Prise en charge de l’import des fichiers PSC de l’organisme ALAN : les lignes de dispense transmises sans référence de contrat créent désormais une affiliation dispensée au lieu d’être rejetées [Mantis #19418]
   2. EI01B : Le motif de dispense utilisé par cet organisme est créé automatiquement au premier import lorsqu’il n’est pas encore paramétré, plutôt que de faire échouer l’ensemble des dispenses du fichier [Mantis #19418]
   3. EI01C : Les libellés de changement « Couv. annulée » et « Suspension d’activité professionnelle » sont désormais reconnus et ne remontent plus en anomalie [Mantis #19418]
   4. EI01D : L’arrivée d’une nouvelle période clôture le dossier en cours de l’agent même lorsque le contrat n’est pas renseigné sur la ligne importée [Mantis #19418]
   5. EI02 : Retenues pour arrêt des agents rémunérés par mouvement 45 : mouvements 40, 41 ou 42 en sens contraire selon la période des jours d’arrêt, retenue calculée sur 30 jours au prorata des taux de rémunération, sans retenir deux fois une même période [Mantis #17817]
   6. EI03 : Paie DGFIP > Paramétrage > Administrations : nouveau champ « Plafond » (Budget de l’État / Ressources propres), affiché si la LOLF est utilisée ; renseigné, il alimente le plafond d’emplois des mouvements 02 des agents de l’administration [Mantis #19793]
   7. CI01 : Correction du “Journal de Paie” (Paie/DGFIP > Synthèses) : les agents au dossier de paie clos disparaissaient du journal des mois suivants alors que des éléments de paie (rappels, régularisations) y étaient encore versés ; ils sont de nouveau repris, sans doublon [Pas de Mantis]
   8. CI02 : Correction des totaux du “Journal de Paie” et de la “Synthèse des bulletins” (Paie/DGFIP > Synthèses), faux dès que les cumuls étaient importants (centimes perdus, total tronqué au-delà de dix millions) : ils sont désormais calculés sans perte de précision [Pas de Mantis]
   9. CI03 : Les mouvements de carence “67” ne se génèreront plus pour des absences déjà traitées sur des dossiers de paie antérieurs [Mantis #19720]
   10. CI04 : Une résidence administrative saisie sur un mois de paie déjà passé ne générait aucun mouvement, et la rémunération liée à la zone n’était jamais régularisée : ces changements sont transmis avec leur date d’effet, dans la limite de rétroactivité paramétrée [Mantis #19747]
   11. CI05 : Plusieurs changements de résidence administrative dans un même mois de paie : seul le dernier était transmis (et un aller-retour ne l’était pas du tout) ; chaque changement donne désormais son propre mouvement, dans l’ordre chronologique [Mantis #19709]
   12. CI06 : Plusieurs indemnités de même code, montant et date d’effet saisies pour un agent étaient écartées comme doublons et aucune n’était payée : elles sont désormais transmises dès lors que leurs numéros d’ordre diffèrent [Mantis #19402]
   13. CI07 : Le mouvement “80” (identification définitive) porte désormais le N°S.S. définitif dans l’identification de l’agent des exports GEST et PDF, et n’est généré que si le “N°S.S.”, le “N°S.S. provisoire” et la “Date du N°S.S. définitif” sont renseignés [Mantis #19362]
   14. CI08 : Au retour d’un congé parental (absence sans traitement en régime 30), la reprise en régime 01 d’un agent en CDI ne transmettait pas la fin de situation : date de fin désormais zédifiée et code de fin de situation transmis à “ZZ” [Mantis #19314]
   15. CI09 : Correction du tableau des cotisations PSC d’un agent (Livret individuel > Paie > Affiliations PSC) : à la revalorisation d’une seule indemnité d’un contrat ou d’une option, les autres s’arrêtaient à tort la veille ; chacune reste en vigueur jusqu’à sa propre revalorisation [Mantis #19432]
   16. CI10 : Le mouvement “04” est désormais transmis à la réouverture d’un dossier de paie non apuré [Pas de Mantis]
   17. CI11 : Le comparatif GEEF / DGFIP affiche désormais l’indice d’un type de rémunération indiciaire avec indice [Pas de Mantis]
   18. CI12 : Le mouvement “45” ne se génère plus à chaque paie lorsque la rémunération permanente de l’agent est inchangée : un montant dont les centimes se terminent par 0 (ex. 1 422,50 €) était jugé, à tort, différent de la rémunération précalculée transmise par la DGFIP [Pas de Mantis]
   19. CI13 : Le champ “Code créancier social” du mouvement “PS” ne devrait plus être obligatoire à la saisie [Pas de Mantis - TNR SSAC]
   20. CI14 : Import PSC ALAN : les options souscrites sont désormais rattachées au dossier PSC de l’agent ; lors d’un changement ou d’un retrait d’option, ou d’un arrêt de couverture, l’option précédente est fermée. La référence de l’option créée est le code ALAN, sans le libellé qui le suit [Mantis #19931]
   21. CI15 : Les types de mouvements ne seront désormais plus en lecture seule lors de l’import du référentiel [Pas de Mantis - TNR]
   22. CI16 : Correction des index de paramétrage des champs “Destination”, “Plafond” et “Code chaire” du type de mouvement “02” [Pas de Mantis]
   23. CI17 : Imports de fichiers de la paie DGFIP (base paie, LR, J5, KA, BJ, primes, PSC, ventilations validées) : la confirmation et le contrôle du nom des fichiers ne s’exécutaient pas, et l’import partait sans demande de confirmation ; ils sont rétablis. Un nom de fichier qui ne correspond pas au fichier attendu ne bloque pas l’import : une confirmation est demandée (« Importer quand même ? »). Chaque bloc d’import d’un même écran est contrôlé indépendamment des autres, et les messages de confirmation des imports de primes et de ventilations validées sont corrigés [Pas de Mantis - TNR EFLA]
5. Temps de Travail
   1. ET01 : Nouveau paramètre « Temps de travail - Masquer SNF » (NON par défaut) : à OUI, les absences d’un type « Service non fait » apparaissent dans les plannings et les demandes avec le code et la couleur génériques, sans leur motif ; l’agent voit toujours ses propres motifs [Mantis #16606]
   2. ET02 : Nouvelle option « Masquer le compteur » sur les types d’absence (GRH / Administration > Statuts et Filières > Droits) : le type n’a plus de compteur et se demande sans contrôle de solde ; circuit de validation et dates limites inchangés [Mantis #19741]
   3. ET03 : Les listes de demandes (libre-service, planning de validation, demandes passées) affichent une colonne « Valideur(s) » : au survol, le circuit de validation étape par étape (statut, date de l’avis, valideur ou répondants attendus) [Mantis #19745]
   4. ET04 : L’accord de télétravail admettra dorénavant une liste “Récupération TT fixe sur absence” (Oui par défaut) : sur Non, une journée de télétravail fixe reste décomptée du compteur en cas d’absence (demandée ou médicale) ou de jour fermé [Mantis #19834]
   5. CT01A : Le solde d’une demande d’absence pouvait devenir négatif : après la validation de plusieurs demandes à la suite, y compris pour plusieurs agents en même temps, le recalcul des droits pouvait en ignorer une partie, et le droit restant restait surévalué jusqu’au recalcul suivant. Chaque validation est désormais prise en compte dans le recalcul. [Mantis #19810]
   6. CT01B : À l’enregistrement d’une demande d’absence (saisie, demi-journées, pointeuse, changement de type), le compteur du type demandé est recalculé (année de la demande et précédente) avant le contrôle du solde, après tout calcul des droits en cours. En cas de refus faute de solde, le formulaire réaffiche le solde à jour. [Mantis #19810]
   7. CT01C : Une demande d’absence à cheval sur plusieurs périodes de référence est contrôlée sur le compteur de chaque période, pour la part qui y tombe ; elle était jusqu’ici contrôlée en totalité sur le compteur de la première période. [Mantis #19810]
   8. CT01D : À la validation d’une demande d’absence par le responsable, avec ou sans circuit de validation, le compteur est recalculé de la même façon et la validation est refusée si la demande dépasse le droit restant (« Droit restant insuffisant : la demande ne peut pas être validée. »). Les demandes d’annulation ne sont pas concernées. [Mantis #19810]
   9. CT01E : Un type d’absence dont le compteur de l’année a été ramené à zéro, puis supprimé par le calcul des droits, ne laisse plus passer de demande : le dépôt comme la validation sont refusés faute de solde. Un type d’absence sans compteur (option « Masquer le compteur ») reste utilisable sans contrôle de solde. [Mantis #19810]
   10. CT01F : Le compteur n’est plus recalculé avant un contrôle de solde s’il vient de l’être (validité de 30 minutes, annulée par toute modification des droits de l’agent ou du paramétrage), ni pour un type d’absence sans compteur : dépôts et validations sont plus rapides. La modification d’une carrière ou d’une suspension relance aussi le recalcul de l’agent. [Mantis #19810]
6. GPEC
   1. EP01 : GPEC > Postes > Détails des Postes : le grade affiché pour un occupant est celui qu’il détenait à la fin de son affectation sur le poste (grade du jour si elle est en cours), à l’écran, dans la modification d’une affectation et dans les fiches de poste Word [Mantis #19568]
7. Entretiens
   1. EE01 : Dans le détail d’un entretien (Evaluations > Campagnes en cours et Historique, ainsi que l’écran des entretiens en libre-service), les étapes du circuit que l’utilisateur n’a pas le droit de consulter — confidentialité posée sur le circuit ou sur l’étape elle-même — ne se résument plus à la mention « Privée ». Elles se présentent désormais comme les autres étapes, avec leur libellé, leur état d’avancement et, au survol, le répondant principal et ses délégataires. Aucune action n’y est en revanche proposée : ni consultation du détail, ni édition PDF, ni modification — ces accès restent réservés aux répondants de l’étape, pour qui rien ne change. La règle déterminant qu’une étape est confidentielle est inchangée : seule sa présentation évolue [Mantis #19715]
   2. EE02 : Dans le paramétrage des processus d’entretien (Evaluations / Administration > Evaluations > Processus), l’évaluation des compétences d’une étape propose une quatrième option, « Limitée au poste avec niveaux », qui combine les deux options existantes : comme pour « Limitée au poste », ce sont les compétences du poste de l’agent (celles pour lesquelles un niveau requis est défini) qui sont proposées, sans ajout ni suppression possible ; comme pour « Ouverte », l’évaluateur choisit pour chacune l’un de ses niveaux possibles dans une liste déroulante, le commentaire de chaque niveau s’affichant sous son libellé. Une compétence laissée sans niveau est considérée comme non évaluée. Le tableau rappelle le niveau requis, le dernier niveau évalué et sa date ainsi que le niveau retenu à l’étape précédente, et un commentaire libre peut être saisi pour chaque compétence ; l’édition PDF de l’entretien reprend ces informations. Seuls les niveaux possibles d’une compétence du poste sont acceptés à l’enregistrement. Le paramètre est désormais accompagné d’une aide décrivant les quatre options. Pour l’option « Limitée au poste », une compétence évaluée à un niveau supérieur au niveau requis (par exemple recopié d’une étape évaluée par niveau) est désormais considérée comme atteinte, et ce niveau est conservé à l’enregistrement au lieu d’être effacé ; les autres options sont inchangées [Mantis #19839]
   3. CE01 : Dans la liste des enveloppes réponses d’une campagne (Evaluations > Campagnes, modification de masse), l’ajout à l’historique des entretiens est désormais réservé aux étapes terminées : une étape à faire, en cours ou non réalisée ne pouvait jusqu’ici être figée dans l’historique alors que son contenu était encore susceptible d’évoluer. Si la sélection en contient, l’utilisateur en est averti avant l’envoi ; côté serveur, ces enveloppes sont écartées, un message en indique le nombre, et les étapes terminées de la même sélection sont bien ajoutées. L’édition PDF d’une étape reste, elle, possible à tout moment, depuis le détail comme depuis la liste [Mantis #19802, #16194]
   4. CE02 : Dans le détail d’un entretien et son édition PDF, pour une étape dont l’évaluation des compétences est « Ouverte », la colonne du niveau attendu par le poste restait toujours vide, même lorsque le poste de l’agent disposait d’un recalibrage validé portant sur la compétence ; elle affiche désormais le niveau attendu issu du dernier recalibrage validé à la date de l’entretien, comme pour l’option « Limitée au poste » [Pas de Mantis]
8. Formation
   1. EF01 : Retrait de l’ancienne interface d’échange avec le LMS EducExpert (XML-RPC), obsolète et porteuse d’une vulnérabilité, avec ses écrans d’administration ; les intégrations e-learning actuelles (Disegno/Citrus, Moodle, APIS) sont inchangées [Pas de Mantis]
   2. EF02 : Écrans de pré-requis d’un modèle de stage et d’une session harmonisés : présentation et comportement identiques, combinaison des pré-requis d’emploi initialisée à « ET », intitulés des pré-requis médicaux visibles en consultation [Mantis #6612]
   3. EF03 : Pré-requis (UV, emplois, grades, affectations, aptitudes médicales) sur les postes de l’équipe pédagogique, du modèle de stage à la session. Mode « OUI+PREREQ » du libre-service formateurs : seuls les postes dont l’agent satisfait les pré-requis lui sont proposés [Mantis #6612]
   4. EF04 : Écran des coûts d’une session (vacations et indemnités des encadrants) : détail des heures de présence de chaque formateur par convention de prise en charge et taux horaire, si le paramètre “Sessions - Présences détaillés” n’est pas à NON [Mantis #19530]
   5. EF05 : Transition graphique - Evolution des jours de segmentation des sessions de stage en un tableau à double entrée (jour de la semaine et numéro de la semaine), avec la possibilité d’adapter la date de fin en fonction des jours de la semaine et fermés [Mantis #19383]
   6. EF06 : Les réponses libres saisies dans un questionnaire qualité conservent désormais les zéros non significatifs : une réponse saisie sous la forme « 007 » (matricule, code, numéro…) était auparavant enregistrée « 7 » [Mantis #19658]
   7. EF07 : Candidats stagiaires d’une session : avec le modèle de feuille de présence « CNPF », la colonne du grade est remplacée par la fonction de l’affectation en vigueur à la fin de la session, à l’écran comme dans l’export tableur [Mantis #19656]
   8. CF01 : Correction de l’affichage des pré-requis médicaux agrégés en consultation sur l’écran des pré-requis d’un modèle de stage : le bloc pouvait ne pas s’afficher [Mantis #6612]
   9. CF02 : Fiche de liaison logistique d’une session (atelier, restauration / hébergement) : deux éditions lancées simultanément par deux utilisateurs pouvaient mélanger les informations d’en-tête de leurs sessions ; chaque édition a désormais ses propres données [Pas de Mantis]
   10. CF03A : Correction du “Tableau de bord du centre” (Formation > Gestion des FMA), qui se rechargeait en boucle et devenait inutilisable dès que des FMA étaient définies ; seule une modification de l’utilisateur relance désormais la recherche [Mantis #19028]
   11. CF03B : Le “Tableau de bord du centre” (Formation > Gestion des FMA) restait vide pour les utilisateurs à périmètre départemental, ce périmètre n’étant plus reconnu ; corrigé, ainsi que l’écran d’indemnisation des FMA [Mantis #19028, #19884]
   12. CF04A : Rétablissement de la restriction au périmètre de l’utilisateur sur les écrans de validation des candidatures et des demandes de formation : consultation et décisions ne portent plus que sur les candidatures de son périmètre, comme sur les autres écrans [Pas de Mantis]
   13. CF04B : Candidatures de formateur d’une session : acceptation, refus, modification et suppression vérifient l’appartenance à la session et au périmètre de l’utilisateur (sauf « Candidatures - Visibilité ouverte » à OUI ou accès départemental complet) [Pas de Mantis]
   14. CF05 : Sur l’écran des candidats stagiaires d’une session, l’écran de changement du service de rattachement d’un candidat rappelait systématiquement le grade de l’agent au-dessus du formulaire, sans tenir compte du paramètre « Général - Affichage du grade ». Ce rappel respecte désormais le paramétrage, comme les autres identités courtes de l’application [Mantis #19656]
   15. CF06 : Écran « Logistique » d’une session en accès externe : les boutons « Enregistrer » et le bloc « Choix du forfait » ne s’affichent plus lorsque tous les candidats du service sont acceptés (logistique alors en lecture seule) [Mantis #19684]
   16. CF07 : Les repas d’un stagiaire en rattrapage figurent désormais sur la feuille de repas de la logistique. [Mantis #19870]
   17. CF08 : Sous Oracle, la liste des sessions du libre-service stagiaire ne s’affichait plus pour un agent ayant déjà candidaté, et des observations de plus de 4 000 caractères provoquaient la même panne : ces textes sont désormais lus de façon compatible [Pas de Mantis]
   18. CF09 : Paramètres « Doubles carrières - … » (Emplois, Diplômes, UV) : une valeur mal saisie provoquait une erreur à la délivrance des diplômes et à l’enregistrement d’un emploi ; les couples incomplets sont ignorés, le paramétrage restant à corriger [Mantis #19937]
   19. CF10 : Planification des sessions (Formation > Planification > Sessions) : l’affichage jour par jour d’un mois de 30 jours ou de février provoquait une erreur et l’écran ne s’affichait pas ; la période s’arrête désormais au dernier jour réel du mois [Mantis #19970]
9. Formation - Emargement
   1. EV01 : Nouveau bloc « Émargements » du Libre-Service : écrans « Sessions de stages » et « FMPA sur centre » listant les sessions et séances de l’agent, avec accès direct à l’émargement sans QR code ; accès paramétrable dans les droits des profils [Pas de Mantis]
10. Outils
    1. EO01 : Mise à jour de sécurité et de maintenance des bibliothèques tierces : montées de version corrigeant des vulnérabilités connues (notamment pac4j/OIDC, Spring, Apache Commons VFS, json-smart, Nimbus JOSE+JWT, Woodstox) et retrait de bibliothèques obsolètes ou inutilisées ; sans changement fonctionnel visible. [Pas de Mantis]
    2. EO02 : Retrait de l’ancienne interface d’échange par messagerie JMS (pont bidirectionnel avec le SIRH de gestion administrative), obsolète et non maintenue : le démon, les écrans de contrôle et les bibliothèques associées sont supprimés. Les interfaces d’échange actuelles (imports/exports de fichiers, interfaces REST) ne sont pas affectées. [Pas de Mantis]
    3. EO03 : Montée de version de la bibliothèque tierce de lecture et d’écriture des fichiers CSV (OpenCSV 1.8 → 5.12), utilisée par les imports et exports au format CSV (imports Sedit, paie DGFIP, organigramme, imputations…) : mise à jour de maintenance, sans changement fonctionnel visible. [Pas de Mantis]
    4. EO04 : Envois vers MédiSAP depuis les écrans désormais asynchrones (file d’attente) : la saisie n’attend plus et n’est plus bloquée si le service est indisponible. Notification en cas d’échec et bouton de ré-envoi (MédiSAP et eSedit) [Pas de Mantis]
    5. EO05 : Ajout, sur l’écran d’audit des courriels, d’un bouton permettant de replacer en une seule action tous les courriels en erreur en attente d’envoi, afin d’en retenter l’émission. [Pas de Mantis]
    6. EO06 : Requêteur : nouvel export Excel natif (.xlsx) des résultats, avec colonnes typées, en-têtes figés, filtre automatique, ligne de total et un onglet graphique quand la requête en déclare un (les zones circulaires y sont rendues en anneau). Les exports Excel et OpenOffice Calc existants restent inchangés. [Pas de Mantis]
    7. EO07 : Nettoyage interne du code : les 296 points d’entrée historiques des fonctions utilitaires, conservés en délégation lors des refactorisations précédentes, sont supprimés ; les appels qui les utilisaient encore ont été redirigés vers les fonctions cibles. Sans changement fonctionnel ni impact sur les écrans. [Pas de Mantis]
    8. EO08 : Nettoyage interne du code : fragments recopiés mutualisés et feuilles de style des documents Word générés sorties du code vers des ressources dédiées ; près de 5 800 lignes en moins, sans changement fonctionnel [Pas de Mantis]
    9. EO09 : Nettoyage interne du code : la logique déclarée dans les pages d’affichage est transférée dans du code applicatif dédié par module, sans changement fonctionnel ; équivalence des états du bilan de formation vérifiée par test automatisé [Pas de Mantis]
    10. EO10A : Refactorisation d’ensemble : les pages d’affichage historiques sont converties en composants applicatifs, écran par écran, sans changer aucune adresse (menu, favoris, raccourcis) ni, à droits identiques, les écrans et documents produits [Pas de Mantis]
    11. EO10B : Sécurité des écrans d’administration de référentiels : l’accès en lecture à un onglet est contrôlé côté serveur (« Accès refusé » sans droit), et un paramètre d’URL ne peut plus afficher un autre écran sous l’adresse d’un écran [Pas de Mantis]
    12. EO10C : En multi-clients, la composition des écrans d’administration est évaluée pour chaque client d’après ses propres paramètres de licence, et réévaluée dès la modification de l’un d’eux, sans redémarrage [Pas de Mantis]
    13. EO10D : Les écrans d’administration de référentiels proposent l’export Excel là où il manquait, les filtres et le découpage en pages y étant déjà actifs. [Pas de Mantis]
    14. EO10E : Corrections d’affichage et de droits révélées par la conversion des écrans : sous-écrans d’un modèle de stage, boutons de raccourci d’une pagelet de navigation, pagelet de pilotage d’une interface d’échange [Pas de Mantis]
    15. EO10F : Droits de l’écran « Outils > Optimisation BD » : consultation (informations), modification (calculs et traitements sans perte) et droit complet (traitements destructeurs) sont distingués. À vérifier à la montée de version : niveau de droit des comptes concernés [Pas de Mantis]
    16. EO10G : Fin de la refactorisation EO10A : toutes les pages historiques sont converties, sans changement d’adresse. Mise en page des documents bureautiques sortie en ressources, défauts de robustesse corrigés, écran d’erreur de l’outil généralisé [Pas de Mantis]
    17. EO11 : Bibliothèques tierces : correction des vulnérabilités connues (Jackson, Log4j), 23 bibliothèques mises à jour, quatre montées majeures, et 20 bibliothèques inutilisées retirées (de 127 à 107, de 106 à 94 Mo). Sans changement fonctionnel visible [Pas de Mantis]
    18. EO12 : Prérequis d’installation : le pilote JDBC Oracle n’est plus livré avec l’application. Clients Oracle : vérifier sa présence dans le répertoire « lib » de Tomcat avant la montée de version (déjà le cas sur une installation en fonctionnement) [Pas de Mantis]
    19. EO13 : Le moteur XSLT Apache Xalan est retiré au profit de celui du langage, documents identiques vérifiés. Clients imprimant un catalogue de formation : « Sécurité - Restriction XSLT » peut être remis à OUI [Pas de Mantis]
    20. EO14 : Les deux services web entrants disposent d’une définition OpenAPI 3.1 en ressource statique : eSedit entrant (“/openapi/wsDataSump.yaml”) et services intranet (“/openapi/wsIntranet.yaml”) ; fonctionnement inchangé [Pas de Mantis]
    21. EO15 : Fiabilisation de l’application automatique de la structure de la base aux montées de version : valeurs par défaut obsolètes retirées, traitements de fond différés jusqu’à la fin de l’application, suivi séparé par client [Pas de Mantis]
    22. EO16 : Refonte de l’écran « Outils > Notifications > Courriels » en deux volets : liste filtrable des notifications groupées par module à gauche, vue d’ensemble ou fiche complète (statut, modèle, récipiendaires, pièces jointes, requêtes) à droite [Pas de Mantis]
    23. EO17 : Nouveaux « Sur écran » « Livret individuel - Détails carrière » et « - Détails agent » (Outils > Droits > Requêtes LIF) pour afficher des informations de l’agent ou de sa carrière dans le livret individuel en consultation [Mantis #11925, #15760]
    24. EO18A : Requêteur, « Outils > Requêteur > Création de Requête » : champs techniques masqués par défaut (réaffichables), recherche sur les libellés des tables et des champs, saisie des conditions adaptée au type du champ (calendrier, liste, oui/non), signalement des tables non reliées et résumé en libellés métier à chaque étape. Requêtes existantes inchangées. [Pas de Mantis]
    25. EO18B : Requêteur : nouvelle étape « Sujets métier ». L’utilisateur choisit un sujet (67 livrés, selon les modules actifs), coche les champs, renseigne les filtres, et la requête est construite pour lui dans son périmètre de gestion. Elle reste une requête ordinaire, rouvrable dans l’assistant ; la date ou la période est demandée à chaque exécution. [Pas de Mantis]
    26. EO18C : Requêteur : une saisie demandée à l’exécution et citée plusieurs fois dans une requête (ex. une date de situation) n’est plus demandée qu’une fois et s’applique à toutes ses occurrences. [Pas de Mantis]
    27. CO01 : Correction des raccourcis « Administration » (clé à molette à côté d’une liste déroulante) : 41 adresses erronées corrigées ou retirées, dont un seul cas visible (générateurs de mouvements de la Paie DGFIP). Aucun droit ni écran modifié [Pas de Mantis]
    28. CO02 : MySQL/MariaDB : les tables créées automatiquement reprennent le jeu de caractères et la collation de la base, évitant les erreurs de mélange de collations ; les tables déjà créées différemment restent à convertir à la main [Pas de Mantis]
    29. CO03 : Interface d’export des membres du CESE : le pays du lieu de naissance provient désormais de la Nationalité (donnée reliée au référentiel), et non plus du champ « Pays de naissance » en saisie libre, pour un libellé toujours normalisé. [Mantis #18876]
    30. CO04 : Historique de l’écran « Outils > Audits > Audit des Sessions » : il restait vide car il lisait un ancien nom de journal ; il relit désormais les fichiers datés, et chaque client ne consulte que ses propres sessions [Pas de Mantis]
    31. CO05 : Interface d’export des membres du CESE : les rubriques à date de fin (bureau, collège/groupe, affectations) cessent d’être reprises dès le jour de leur date de fin, et non plus le lendemain. [Mantis #18875]
    32. CO06 : Interface d’export des membres du CESE : correction de l’encodage du fichier (désormais en UTF-8 conforme à sa déclaration), qui le rendait invalide en présence de caractères accentués. [Mantis #18875]
    33. CO07 : MySQL/MariaDB : l’application de la structure de la base ne s’interrompt plus quand une session de formation annulée porte un utilisateur supprimé depuis ; l’auteur de l’annulation n’est repris que pour les utilisateurs existants, comme sous Oracle [Pas de Mantis]
    34. CO08 : Correction de l’écran « Outils > Personnalisations > Champs supplémentaires » : la modification d’un champ existant (libellé, type, longueur…) renommait le dernier champ créé au lieu de mettre à jour le champ modifié. [Pas de Mantis]
    35. CO09 : « Outils > Personnalisations > Champs supplémentaires » : une valeur par défaut incompatible avec le type (texte pour un entier, date mal formée…) ou une longueur hors de 1 à 100 est refusée avec un message ; une telle valeur déjà saisie n’empêche plus la mise à jour de la structure au démarrage [Pas de Mantis]
    36. CO10 : Synchronisation des profils avec l’annuaire LDAP : les recherches sont désormais paginées, ce qui lève la limite de 1000 entrées d’Active Directory (au-delà, la liste était tronquée sans message et des comptes pouvaient être désactivés à tort). Si l’annuaire tronque malgré tout, aucun compte n’est désactivé et un avertissement est journalisé. [Pas de Mantis]
    37. CO11 : Synchronisation des utilisateurs vers l’annuaire LDAP : renseigner le paramètre « LDAP+ - Attribut : ORGANIGRAMME NIV 0 » faisait échouer la préparation des attributs de chaque agent. Ce niveau publie désormais le service de l’agent ; les niveaux 1 à 5 sont inchangés [Pas de Mantis]
11. Application mobile
    1. EM01 : L’API de l’application mobile dispose d’une définition OpenAPI 3.1 (“/grpc?getOpenApi”), consultable avec les outils standard (Swagger UI, Redoc…), à côté de la définition Protobuf ; comportement de l’API inchangé [Pas de Mantis]
    2. EM02A : Application mobile 2.1 : nouvel écran « Badgeage » pour l’agent lui-même, selon sa règle de badgeage (« Je badge » en e-badge, déclaration datée en mode déclaratif) ; l’entrée n’apparaît pas pour un agent non soumis au badgeage [Mantis #19750]
    3. EM02B : Le badgeage immédiat est horodaté à l’heure du serveur, jamais à celle du téléphone, comme sur une badgeuse, et il est enregistré validé. Une déclaration part « à valider » par le responsable, sauf pour un agent en déclaratif auto-validé. Les badgeages saisis depuis l’application portent la source « VIRTUALIA/MOBILE » (« VIRTUALIA/PC » depuis le portail) [Mantis #19750]
    4. EM02C : Badgeage mobile : calendrier semaine / mois avec une pastille par journée selon l’état de validation, détail des badgeages d’un jour, déclaration limitée au passé, suppression selon les mêmes règles que sur l’accueil [Mantis #19750]
    5. EM02D : Hors connexion, le badgeage et la déclaration sont désactivés : une action rejouée à la reconnexion serait horodatée à l’heure de sa reprise et non à celle du geste [Mantis #19750]
    6. EM02E : Une nouvelle ressource de l’API mobile renvoie, pour l’agent connecté et sur une période d’au plus 62 jours, ses journées badgées avec leur nombre de badgeages et leur état de validation le plus défavorable ; une période illisible ou trop longue est refusée [Mantis #19750]
    7. EM02F : Règles de badgeage (autorisation, saisie, suppression) communes à l’accueil et à l’application mobile, sans changement sur le portail ; l’application reçoit les mêmes libellés traduits [Mantis #19750]
    8. EM03 : Sur l’écran de connexion de l’application mobile, le client cible peut désormais être recherché en saisissant son nom, avec des suggestions sous le champ ; la liste complète reste accessible [Pas de Mantis]
    9. EM04 : Un agent ayant plusieurs carrières peut désormais en changer directement depuis le menu de l’application mobile [Pas de Mantis]
    10. EM05 : Dans l’application mobile, les listes affichent un aperçu des cartes pendant leur chargement, les actions bénéficient d’animations et d’un retour visuel au toucher, et les notifications de confirmation ont été redessinées pour rester lisibles en thème sombre [Pas de Mantis]
    11. CM01 : Dans l’application mobile, passer un participant d’une séance FMPA en « non validé » sans choisir de motif affichait une erreur, alors que la modification était bien enregistrée : l’application reçoit désormais une confirmation normale [Pas de Mantis]

---

Préambule

Important : Cette version 6.0 requiert un passage préalable par la version 5.20. Les sauts de version ne sont pas supportés et pourraient entraîner des dysfonctionnements. Veuillez vérifier que vous êtes en 5.20 ou 5.20.1 avant de mettre à jour vers la 6.0.

Dans le cadre de la mise à jour des librairies et leur conformité avec les correctifs de sécurité, cette version de GEEF / Virtualia, version 6.0, a été rendue compatible avec Tomcat 11 et intégrera des librairies Java 21.

Cette version de GEEF / Virtualia n’est plus compatible avec Tomcat 8, Tomcat 8.5 et Tomcat 9, le passage à Tomcat 10.1 est impératif, le passage à Tomcat 11 est possible avec quelques risques résiduels.

Cette version de GEEF / Virtualia n’est plus compatible avec Java 8. Elle est partiellement compatible Java 17, cependant nous recommandons le passage à Java 21 ou plus récent.

Vos environnements doivent être mis à jour vers Java 21 (ou plus) et Tomcat 10.1.x.

Les clients concernés par les éléments contenant le mot clé « Oracle » sont, par ordre alphabétique : le SDIS 68, le SDIS 78 et le SDMIS (SDIS 69). Ces SDIS ne sont pas concernés par les éléments contenant le mot clé « MySQL » ou « MariaDB ».

Les autres clients ne sont pas concernés par les éléments « Oracle » mais sont concernés par les éléments contenant le mot clé « MySQL ».

Général

EL01 : [Transition Graphique] Evolution du design de la navigation. Le menu devient un menu latéral à niveaux multiples. Le cheminement se fait sur le modèle suivant : Module > Type (“Général”,”Synthèse”,”Administration”) > Section > Page. [Pas de Mantis]

Voir la documentation sur la Refonte graphique.

EL02 : [Transition Graphique] La déconnexion se fera désormais en bas du menu latéral [Pas de Mantis]

Voir la documentation sur la Refonte graphique.

EL03 : [Transition Graphique] Nouveau design du paramétrage des rôles : liste des rôles à gauche, détail à droite (premier rôle ouvert par défaut). Les droits se choisissent par boutons, avec modification en masse par rubrique, page à sous-menus, groupe d’actions et table de champs [Pas de Mantis]

L’écran de paramétrage des rôles a un nouveau design. La liste des rôles sera situé sur la gauche de l’écran, et son détail devient directement accessible sur la partie droite. Le détail du premier rôle de la liste sera ouvert par défaut. Le choix des droits passe sous forme de boutons cliquables avec une modification en masse possible par rubrique de menu, par page à sous-menus, par groupe d’actions et par table de champs ; pour les actions objets, les boutons « L » et « M » de la modification en masse ne s’appliquent qu’aux actions disposant d’un niveau libellé exactement « Lecture » ou « Modification », les autres restant inchangées

Voir la documentation sur la Refonte graphique.

EL04 : [Transition Graphique] Paramétrage des rôles : affichage du nombre d’utilisateurs du rôle, du nombre de menus accordés et d’une infographie des niveaux de droits ; chaque rubrique et page à sous-menus indique son nombre d’accès [Pas de Mantis]

Ajout d’informations portant sur le nombre d’utilisateurs possédant le rôle, sur le nombre de menus ayant un droit d’accès différent de “Refusé” et une infographie sur les différents niveaux de droits accordés (niveau le plus bas, niveaux intermédiaires, niveau le plus haut) ; chaque rubrique de menu affiche son nombre d’accès accordés et chaque page à sous-menus son nombre de sous-menus, à côté de son titre

Voir la documentation sur la Refonte graphique.

EL05 : [Transition Graphique] Ajout d’une barre de recherche dans chaque onglet du paramétrage des rôles pour trouver plus facilement un menu, une action objet (par groupe ou par action) ou un champ accessible (par table ou par champ) [Pas de Mantis]

Voir la documentation sur la Refonte graphique.

EL06 : [Transition Graphique] Écrans épinglés : une étoile sur chaque écran du menu l’ajoute à la rubrique « Épinglés » en tête du menu. Réordonnables par glisser-déposer, ils sont enregistrés par utilisateur, quel que soit le poste [Pas de Mantis]

Écrans épinglés : chaque écran du menu porte une étoile permettant de l’ajouter à une rubrique « Épinglés » placée en tête du menu latéral, ou de l’en retirer ; l’écran en cours peut aussi être épinglé depuis l’en-tête de page. Les épinglés se réordonnent par glisser-déposer et sont enregistrés par utilisateur : ils sont retrouvés quel que soit le poste ou le navigateur, et seuls les écrans accessibles à l’utilisateur peuvent être épinglés

Voir la documentation sur la Refonte graphique.

EL07 : [Transition Graphique] Recherche dans le menu : un champ en tête du menu latéral (raccourci clavier Ctrl+K) filtre les écrans accessibles au fil de la saisie, avec parcours des résultats au clavier (flèches, Entrée, Échap) ; le volet des sous-menus d’une rubrique dispose de son propre filtre et de boutons « Tout déplier » / « Tout replier » [Pas de Mantis]

Voir la documentation sur la Refonte graphique.

EL08 : [Transition Graphique] Menu latéral repliable en rail de pictogrammes et redimensionnable. Nouvel espace « Préférences » (pied du menu), avec l’option « Menu toujours ouvert » ; préférences enregistrées avec le compte, quel que soit le poste [Pas de Mantis]

Le menu latéral est repliable en un rail de pictogrammes et sa largeur se règle en faisant glisser son bord droit (double-clic pour rétablir la largeur par défaut). Un espace « Préférences », ouvert par le bouton de réglages au pied du menu, regroupe les options personnelles d’affichage, avec pour commencer l’option « Menu toujours ouvert ». Active (par défaut), le menu ouvert se place à côté du contenu, qui se décale pour lui laisser la place : il est déployé à l’ouverture de la session, puis reste ouvert ou fermé tel que l’utilisateur l’a laissé, d’un écran à l’autre et jusqu’à sa déconnexion, y compris lorsque l’adresse d’un écran est saisie directement. Désactivée, le menu est replié en rail et se déploie par-dessus le contenu (clic sur une rubrique, recherche), le temps de choisir un écran ; ce déploiement n’est pas conservé d’un écran à l’autre. Ces préférences sont enregistrées avec le compte de l’utilisateur : elles sont retrouvées quel que soit le poste ou le navigateur, et sont communes à tous ses profils

Voir la documentation sur la Refonte graphique.

EL09 : [Transition Graphique] Couleurs du menu déduites de la couleur principale de la charte du client. Fil d’Ariane, recherche générale, sélecteur de profil et actions de page sont regroupés dans l’en-tête ; l’utilisateur connecté est affiché au pied du menu [Pas de Mantis]

Les couleurs du menu latéral et de son volet de sous-menus sont dérivées automatiquement de la couleur principale de la charte paramétrée pour le client : le volet reprend cette couleur et le menu une teinte légèrement plus soutenue, un assombrissement n’étant appliqué que lorsque la couleur est trop claire pour garantir la lisibilité des libellés. Le fil d’Ariane de l’écran en cours, la recherche générale (désormais ouverte par une loupe et affichée par-dessus l’écran, les résultats s’ouvrant toujours dans un nouvel onglet), le sélecteur de profil et les actions de page (nouvelle fenêtre, documentation, aide en ligne) sont regroupés dans l’en-tête de la zone de contenu ; l’utilisateur connecté (nom, initiales, détail au survol) est affiché au pied du menu. Sur mobile, le menu s’ouvre par un bouton dédié

Voir la documentation sur la Refonte graphique.

EL10 : [Transition Graphique] Paramétrage des rôles : filtre des rôles par nom, option « N’afficher que les accès accordés », blocs pliables avec « Tout déplier / Tout replier », et compteur des modifications en attente sur le bouton d’enregistrement [Pas de Mantis]

Paramétrage des rôles : la liste des rôles se filtre par nom ; l’onglet des accès menu propose une option « N’afficher que les accès accordés » ; les rubriques de menu, groupes d’actions et pages à sous-menus sont pliables, avec des boutons « Tout déplier » / « Tout replier » par onglet — les rubriques de menu et les groupes d’actions s’affichent repliés, sauf si l’utilisateur active l’option « Blocs dépliés à l’affichage d’un rôle », proposée directement dans la fiche du rôle, à droite des onglets ; le bouton d’enregistrement affiche le nombre de modifications en attente d’enregistrement

Voir la documentation sur la Refonte graphique.

EL11 : [Transition Graphique] Création d’un rôle : il s’ouvre dans la fiche, tous accès refusés, et se paramètre avant le premier enregistrement. La duplication reprend le nom suivi de « copie » ; un rôle encore attribué ne peut plus être supprimé [Pas de Mantis]

Création d’un rôle : le nouveau rôle s’ouvre directement dans la fiche, en mode « En cours de création », avec tous les accès refusés par défaut, et se paramètre entièrement avant son premier enregistrement (le nom est obligatoire). La duplication d’un rôle reprend son nom suivi de « copie ». La suppression d’un rôle encore attribué à des utilisateurs n’est plus proposée : le bouton est remplacé par une mention explicative, là où elle était auparavant possible

Voir la documentation sur la Refonte graphique.

EL12 : [Transition Graphique] Nouveau design de l’écran « Outils > Optimisation BD » : rubriques à gauche, détail à droite, filtre unique, traitements en blocs pliables avec durée et date de dernière exécution, barre de progression des calculs et état des services par pastille [Mantis #19837]

L’écran « Outils > Optimisation BD » a un nouveau design : les rubriques (État des tables de calcul, Fichiers à importer, Services et Actions) sont listées à gauche et leur détail s’affiche à droite, avec un filtre unique portant sur les rubriques et leurs lignes. Les traitements sont regroupés en blocs pliables ; chaque ligne indique la durée et la date de sa dernière exécution, désormais conservées d’un redémarrage à l’autre, et un calcul en cours affiche une barre de progression. Les paramètres de la progression FMPA sont modifiables depuis l’état des tables, les fichiers de référence sont présentés par famille et l’état des services est signalé par une pastille verte ou rouge.

Voir la documentation sur la Refonte graphique.

EL13 : [Accessibilité] Amélioration de l’accessibilité des écrans pour les utilisateurs de lecteurs d’écran et de navigation au clavier (alternatives textuelles des images, noms accessibles des boutons et des cadres, titre de page propre à chaque écran, mise en page sans sauts de ligne répétés). [Pas de Mantis]

Point technique ayant un impact sur le formatage technique des objets (invisible à l’écran, sauf avec un lecteur).

Exemple : texte alternatif sur le bouton d’accueil :

EL14 : [Accessibilité] Le paramètre “Graphismes - Couleur de Style” signale désormais une couleur au contraste insuffisant pour le RGAA et propose d’appliquer d’un clic une couleur conforme de même teinte [Pas de Mantis]

EL15 : [Accessibilité] Ajout d’un lien d’évitement permettant d’accéder directement au contenu de la page, et balisage de la navigation et du contenu principal pour les technologies d’assistance [Pas de Mantis]

Lien d’évitement affiché à la première tabulation :

EL16 : [Accessibilité] Icônes vectorielles : nettes à tout niveau de zoom, colorées selon leur contexte et visibles en contraste élevé. Le paramètre « Graphismes - Jeu d’icones » est retiré ; les instances sur les anciennes icônes basculent à la mise à jour [Pas de Mantis]

Les icônes de l’application deviennent vectorielles : elles restent nettes quel que soit le niveau de zoom, prennent la couleur de leur contexte (survol, désactivé, thème) et restent visibles en mode contraste élevé. Le jeu d’icônes vectoriel devient le seul proposé : le paramètre « Graphismes - Jeu d’icones » est retiré, et une instance encore réglée sur les anciennes icônes bitmap passe automatiquement aux icônes vectorielles à la mise à jour. Une nouvelle version des icônes est prise en compte par le navigateur dès sa livraison, sans icône vide ni vidage du cache

Icônes vectorielles agrandies (×3) : le tracé reste net :

EL17 : [Accessibilité] Ajout d’un mode contraste élevé directement activable depuis la mire de connexion ou depuis les préférences utilisateur. [Pas de Mantis]

Sur l’écran de connexion :

Dans l’espace « Préférences » :

Rendu d’un écran avec le contraste élevé (bordures des champs et des boutons, liens soulignés) :

CL01A : Correction d’un blocage de compte à la connexion des utilisateurs dont le mot de passe, enregistré dans un ancien format et contenant des accents, pouvait être rejeté à tort selon le jeu de caractères du serveur [Mantis #19533]

Correction d’un blocage de compte pouvant survenir à la connexion des utilisateurs dont le mot de passe était encore enregistré dans un ancien format (antérieur au format actuel) : lorsqu’il contenait des caractères accentués, il pouvait être rejeté à tort selon le jeu de caractères du serveur et, après plusieurs tentatives infructueuses, entraîner le blocage du compte ; la vérification de ces anciens formats tolère désormais les différents jeux de caractères

Lors de la réinitialisation du mot de passe, l’utilisateur pouvait bloquer son compte dans certains cas :

CL01B : La réinitialisation d’un mot de passe par un gestionnaire impose désormais son renouvellement par l’utilisateur lors de sa connexion suivante [Mantis #19533]

Écran de réinitialisation du mot de passe d’un autre utilisateur :

CL01C : Correction de l’indicateur visuel de robustesse du mot de passe (écran de changement/renouvellement) qui pouvait rester figé et ne reflétait pas la politique de complexité réellement appliquée [Mantis #19533]

CL02 : Correction de l’affichage des montants et des nombres arrondis dans l’ensemble de l’application : au-delà d’environ dix millions, la valeur affichée pouvait être tronquée (par exemple “1,23” à la place de “12345678,90”) voire plafonnée ; le formatage est désormais exact quel que soit l’ordre de grandeur [Pas de Mantis]

Exemple : prime de 2 000 000 000,00 € 

CL03 : Renforcement de la sécurité des requêtes d’accès aux données sur plusieurs écrans : les valeurs transmises par les formulaires et les adresses y sont désormais systématiquement contrôlées avant d’être utilisées. Aucun changement de comportement pour l’utilisateur [Pas de Mantis]

Point technique de renforcement de la sécurité.

CL04 : Renforcement de l’étanchéité entre clients en multi-tenant : sessions, droits, journaux, exports d’interfaces et traitements automatiques sont cloisonnés par client. À la mise à jour, les utilisateurs connectés devront se reconnecter une fois [Pas de Mantis]

Renforcement de l’étanchéité entre clients en mode multi-tenant. Une session ouverte chez un client ne peut plus être utilisée chez un autre. Les sessions, les droits et les journaux d’un client ne sont plus visibles depuis un autre. Les exports des interfaces sortantes sont désormais rangés et servis séparément pour chaque client, et leur téléchargement exige d’être connecté. Plusieurs traitements automatiques (envoi de SMS, intégrations, calculs planifiés) ne peuvent plus appliquer le paramétrage d’un autre client. En cas d’indisponibilité de la base centrale, aucun client n’est plus servi par erreur sur la base principale. À la mise à jour, les utilisateurs connectés devront se reconnecter une fois

Point technique concernant les hébergements SaaS.

CL05 : [Accessibilité] Les textes clignotants des écrans d’extraction et des interfaces sortantes utilisaient une balise obsolète ; ils sont remplacés par une animation conforme [Pas de Mantis]

Le texte clignotant utilisait des balises HTML désuètes, le texte redevient à nouveau clignotant avec un effet plus doux.

CL06 : [Accessibilité] Au survol, le libellé et l’icône des boutons secondaires (« Nouveau », « Tout déplier », « Tout replier »…) passaient en blanc sur un fond gris clair, au contraste très insuffisant ; ils restent désormais sombres, et l’icône d’un bouton survolé prend toujours la couleur de son libellé [Pas de Mantis]

Avant correction :

Après correction :

GRH

EH01 : Ajout du genre dans l’écran “GRH > Outils/Risques > Synthèses” [Mantis #19681]

Et export Excel :

EH02 : Ajout d’une clé de traduction spécifique “DATE_OBTENTION_PERMIS” pour la date d’obtention des permis civils [Mantis #19592]

EH03 : Dans les listes de gestion (ex. “GRH > Visites médicales > Permis civils”), le tri d’une colonne agent, carrière ou stagiaire externe se fait par nom puis prénom (session : intitulé ; poste : intitulé), et le tri inversé porte sur tous les critères [Mantis #19619]

Dans les listes de gestion (ex. “GRH > Visites médicales > Permis civils”), le clic sur l’en-tête d’une colonne désignant un agent, une carrière ou un stagiaire externe trie désormais par nom puis prénom (au lieu du numéro interne) ; même principe pour les colonnes de session de stage (tri par intitulé) et de poste budgétaire (tri par intitulé du poste). Le tri inversé (second clic) s’applique à tous les critères du tri, et non plus au seul dernier

EH04 : Transition graphique - Revue du design et de la disposition des informations de l’agent/de la carrière et de l’organisation des onglets des écrans de consultation du livret individuel (“GRH / Général > Livrets individuels > Détails des livrets individuels / agents” et “Libre-service / Général > Mon Livret individuel > Détails livret individuel”) [Mantis #19887]

EH05 : Transition graphique - Livret individuel en consultation (GRH et Libre-service) : fil d’Ariane de la section et du sous-écran, boutons pour plier ou déplier toutes les sections ou tous les blocs, et affichage possible d’informations de l’agent ou de sa carrière (voir EO17) [Mantis #19887]

Transition graphique - Ajout de nouvelles fonctionnalités dans les écrans de consultation du livret individuel (“GRH / Général > Livrets individuels > Détails des livrets individuels / agents” et “Libre-service / Général > Mon Livret individuel > Détails livret individuel”) : d’un fil d’Ariane reprenant la section et et le sous-écran consulté, des boutons pour plier ou déplier toutes les sections ou tous les blocs du sous-écran, et la possibilité d’afficher certaines informations de l’agent ou de sa carrière (voir changelog 5.22 * EO17)

Fil d’Ariane, filtre des rubriques et bouton « Tout replier » :

EH06 : Les modifications de carrière, anciennement disponible depuis le bandeau agent dans les livrets individuels, seront désormais présents dans un bloc dédié dans le sous-écran “GRH / Général > Livrets individuels > Détails des livrets individuels / Situation administrative > Grades / Carrières” [Mantis #19887]

En licence « Virtualia », il s’agit du bloc « Carrières », en licence « GEEF », il s’agit du bloc « Grades ».

EH07 : Les situations familiales et les enfants d’un agent sont désormais affichés par ordre chronologique inverse (la plus récente situation et le plus jeune enfant en premier), notamment dans “GRH / Général > Livrets individuels > Détails des livrets individuels / Identité > Civilité” [Pas de Mantis]

GRH > Livrets individuels > Détails des livrets individuels > Identité > Civilité : les situations familiales, de la plus récente à la plus ancienne :

Même écran : les enfants, du plus jeune au plus âgé :

CH01 : Import du fichier de certification IDE (GRH > Déclaratifs > CIR) : la confirmation et le contrôle du nom du fichier ne s’exécutaient pas, et l’import partait sans demande de confirmation ; ils sont rétablis, avec un message de confirmation propre à ce fichier (il évoquait jusqu’ici les fichiers de base paie). Un nom de fichier qui ne correspond pas au fichier attendu ne bloque pas l’import : une confirmation est demandée (« Importer quand même ? ») [Pas de Mantis]

GRH > Déclaratifs > CIR, import du fichier de certification IDE : un nom de fichier qui ne correspond pas au fichier attendu ne bloque pas l’import, une confirmation est demandée (« Importer quand même ? ») :

CH02 : Correction du formatage de l’adresse courriel/UPN/sAMAccountName généré automatiquement lors de la création d’un agent via l’écran “GRH > Livrets individuels > Liste des Agents”, en processus guidé ou non [Mantis #19646]

GRH > Livrets individuels > Détails des livrets individuels / Identité > Identification : pour un agent créé avec un nom et un prénom accentués, l’adresse courriel, l’identifiant userPrincipalName et le sAMAccountName générés automatiquement sont sans accent ni majuscule (« prenom.nom ») :

CH03 : Dans l’écran “GRH > Livrets individuels > Détails des livrets individuels”, l’adresse courriel suggérée (absente de la base) est désormais signalée par une icône, comme l’identifiant de connexion [Mantis #19646]

GRH > Livrets individuels > Détails des livrets individuels / Identité > Identification : l’adresse courriel suggérée, pas encore enregistrée, est signalée par une icône à côté du champ :

Paie DGFIP

EI01A : Prise en charge de l’import des fichiers PSC de l’organisme ALAN : les lignes de dispense transmises sans référence de contrat créent désormais une affiliation dispensée au lieu d’être rejetées [Mantis #19418]

Écran des affiliations PSC, avec l’import des fichiers de l’organisme et les colonnes de dispense :

EI01B : Le motif de dispense utilisé par cet organisme est créé automatiquement au premier import lorsqu’il n’est pas encore paramétré, plutôt que de faire échouer l’ensemble des dispenses du fichier [Mantis #19418]

Cet écran est automatiquement renseigné par l’interface.

EI01C : Les libellés de changement « Couv. annulée » et « Suspension d’activité professionnelle » sont désormais reconnus et ne remontent plus en anomalie [Mantis #19418]

Point technique, sans illustration.

EI01D : L’arrivée d’une nouvelle période clôture le dossier en cours de l’agent même lorsque le contrat n’est pas renseigné sur la ligne importée [Mantis #19418]

Une nouvelle ligne d’affiliation est créée et la précédente est fermée.

EI02 : Retenues pour arrêt des agents rémunérés par mouvement 45 : mouvements 40, 41 ou 42 en sens contraire selon la période des jours d’arrêt, retenue calculée sur 30 jours au prorata des taux de rémunération, sans retenir deux fois une même période [Mantis #17817]

Retenues pour arrêt (maladie…) des agents rémunérés par mouvement 45 : un mouvement 40 en sens contraire est généré pour les jours d’arrêt du mois de paie, un 41 pour ceux des mois antérieurs de l’année et un 42 pour ceux de l’année précédente (un arrêt à cheval sur deux mois produit un 40 et un 41) ; la retenue est calculée sur une base de 30 jours en additionnant les proratas de chaque taux de rémunération de la période, et une période déjà retenue lors d’une paie précédente n’est pas retenue une seconde fois

EI03 : Paie DGFIP > Paramétrage > Administrations : nouveau champ « Plafond » (Budget de l’État / Ressources propres), affiché si la LOLF est utilisée ; renseigné, il alimente le plafond d’emplois des mouvements 02 des agents de l’administration [Mantis #19793]

Paie DGFIP > Paramétrage > Administrations : nouveau champ « Plafond » (1 - Budget de l’État / 2 - Ressources propres), affiché uniquement si le paramètre « Paie DGFIP - Utiliser la LOLF dans la génération des mouvements » est à OUI. Lorsqu’il est renseigné, il alimente le plafond d’emplois des mouvements 02 des agents rattachés à l’administration, à la place de la valeur déduite de l’autorisation d’emploi LOLF

Paie DGFIP / Administration > Paie DGFIP > Administrations, modification d’une administration : nouveau champ « Plafond » (1 - Budget de l’État / 2 - Ressources propres), affiché quand la LOLF est utilisée :

CI01 : Correction du “Journal de Paie” (Paie/DGFIP > Synthèses) : les agents au dossier de paie clos disparaissaient du journal des mois suivants alors que des éléments de paie (rappels, régularisations) y étaient encore versés ; ils sont de nouveau repris, sans doublon [Pas de Mantis]

Correction du “Journal de Paie” (Paie/DGFIP > Synthèses) : les agents dont le dossier de paie est clos n’étaient plus repris dans le journal des mois suivant sa date de fin — ils en disparaissaient entièrement, montants compris — alors que des éléments de paie (rappels, régularisations, retenues) continuaient d’être versés sur ce dossier et devaient être ventilés comptablement ; le rattachement au dossier de paie ne dépend plus de sa date de fin, sans réintroduire de ligne ni de montant en double

Point technique, sans illustration.

CI02 : Correction des totaux du “Journal de Paie” et de la “Synthèse des bulletins” (Paie/DGFIP > Synthèses), faux dès que les cumuls étaient importants (centimes perdus, total tronqué au-delà de dix millions) : ils sont désormais calculés sans perte de précision [Pas de Mantis]

Correction des totaux du “Journal de Paie” et de la “Synthèse des bulletins” (Paie/DGFIP > Synthèses) : la ligne de total, les totaux par imputation et les totaux mensuels devenaient faux dès que les montants cumulés étaient importants — quelques centimes perdus sur des cumuls de l’ordre du million, et un total tronqué du type “1,23” au-delà de dix millions ; les cumuls sont désormais calculés et affichés sans perte de précision

Point technique, sans illustration.

CI03 : Les mouvements de carence “67” ne se génèreront plus pour des absences déjà traitées sur des dossiers de paie antérieurs [Mantis #19720]

Avant la correction, les mouvements 67 étaient générés sur les nouveaux dossiers de paie même si ces derniers avaient déjà été envoyés en paie. Ce n’est plus le cas.

CI04 : Une résidence administrative saisie sur un mois de paie déjà passé ne générait aucun mouvement, et la rémunération liée à la zone n’était jamais régularisée : ces changements sont transmis avec leur date d’effet, dans la limite de rétroactivité paramétrée [Mantis #19747]

Une résidence administrative saisie tardivement, sur un mois de paie déjà passé, ne donnait lieu à aucun mouvement : ni le changement rétroactif lui-même, ni le retour à la résidence suivante n’étaient transmis, et la rémunération liée à la zone de résidence n’était donc jamais régularisée ; ces changements sont désormais détectés et transmis avec leur date d’effet réelle, sans remonter au-delà de la situation déjà appliquée par la DGFIP ni de la date renseignée dans le paramètre « Paie DGFIP - Date limite de rétroactivité »

Exemple : une résidence administrative saisie en novembre avec effet au 1er septembre ne donnait lieu à aucun mouvement, la paie de septembre étant déjà passée. Le changement est désormais transmis à la DGFIP avec sa date d’effet du 1er septembre, suivi, le cas échéant, du retour à la résidence suivante à sa propre date : la rémunération liée à la zone de résidence est ainsi régularisée. La transmission ne remonte jamais avant la situation déjà appliquée par la DGFIP, ni avant la date du paramètre « Paie DGFIP - Date limite de rétroactivité ».

CI05 : Plusieurs changements de résidence administrative dans un même mois de paie : seul le dernier était transmis (et un aller-retour ne l’était pas du tout) ; chaque changement donne désormais son propre mouvement, dans l’ordre chronologique [Mantis #19709]

Lorsque plusieurs changements de résidence administrative se succédaient dans un même mois de paie, seul le dernier était transmis : les étapes intermédiaires étaient perdues, et un changement suivi d’un retour à la résidence d’origine dans le mois n’était pas transmis du tout, faute d’écart avec la situation connue de la DGFIP ; chaque changement donne désormais lieu à son propre mouvement, avec sa date d’effet et dans l’ordre chronologique

CI06 : Plusieurs indemnités de même code, montant et date d’effet saisies pour un agent étaient écartées comme doublons et aucune n’était payée : elles sont désormais transmises dès lors que leurs numéros d’ordre diffèrent [Mantis #19402]

Lorsque plusieurs indemnités de même code, de même montant et de même date d’effet étaient saisies pour un agent, aucune n’était transmise en paie : elles étaient considérées comme des doublons et toutes écartées de la génération des mouvements ; elles sont désormais payées dès lors qu’elles portent des numéros d’ordre différents, le numéro d’ordre suffisant à les distinguer côté DGFIP

CI07 : Le mouvement “80” (identification définitive) porte désormais le N°S.S. définitif dans l’identification de l’agent des exports GEST et PDF, et n’est généré que si le “N°S.S.”, le “N°S.S. provisoire” et la “Date du N°S.S. définitif” sont renseignés [Mantis #19362]

CI08 : Au retour d’un congé parental (absence sans traitement en régime 30), la reprise en régime 01 d’un agent en CDI ne transmettait pas la fin de situation : date de fin désormais zédifiée et code de fin de situation transmis à “ZZ” [Mantis #19314]

Au retour d’un congé parental (ou de toute absence sans traitement placée en régime de rémunération 30), le mouvement de reprise en régime 01 d’un agent en CDI (contrat sans date de fin prévue) ne transmettait ni date ni code de fin de situation : la DGFIP conservait ceux posés à l’entrée en congé (code “SE”), comme si l’agent était toujours en fin de situation ; la date de fin de situation est désormais zédifiée (“ZZZZZZZZZZ”) et le code de fin de situation transmis à “ZZ”

Exemple : à l’entrée en congé parental d’un agent en CDI, le mouvement transmet un code de fin de situation « SE ». À son retour, le mouvement de reprise en régime 01 ne transmettait rien sur la fin de situation, et la DGFIP considérait toujours l’agent comme en fin de situation. La reprise transmet désormais une date de fin de situation zédifiée (« ZZZZZZZZZZ ») et le code « ZZ », qui lèvent cette fin de situation.

CI09 : Correction du tableau des cotisations PSC d’un agent (Livret individuel > Paie > Affiliations PSC) : à la revalorisation d’une seule indemnité d’un contrat ou d’une option, les autres s’arrêtaient à tort la veille ; chacune reste en vigueur jusqu’à sa propre revalorisation [Mantis #19432]

Correction du tableau des cotisations PSC d’un agent (Livret individuel > Paie > Affiliations PSC) lorsqu’une seule indemnité d’un contrat ou d’une option PSC est revalorisée : les autres indemnités du barème, non revalorisées, s’arrêtaient à tort la veille de la revalorisation. Pour une affiliation débutant après cette date, seule l’indemnité revalorisée apparaissait ; pour une affiliation antérieure, les autres indemnités prenaient fin la veille de la revalorisation, sans suite. Chaque indemnité reste désormais en vigueur jusqu’à sa propre revalorisation

Tableau des cotisations PSC : chaque indemnité reste en vigueur jusqu’à sa propre revalorisation :

CI10 : Le mouvement “04” est désormais transmis à la réouverture d’un dossier de paie non apuré [Pas de Mantis]

Avant la correction, le mouvement 04 du RIB ne se générait pas en cas de réouverture d’un dossier de paie non apuré (retour d’un agent parti depuis moins de 3 ans).

CI11 : Le comparatif GEEF / DGFIP affiche désormais l’indice d’un type de rémunération indiciaire avec indice [Pas de Mantis]

Livret individuel > Paie > Paie DGFIP, comparatif GEEF / DGFIP : l’indice majoré affiché est celui du type de rémunération indiciaire en cours (420), et non plus celui du grade :

CI12 : Le mouvement “45” ne se génère plus à chaque paie lorsque la rémunération permanente de l’agent est inchangée : un montant dont les centimes se terminent par 0 (ex. 1 422,50 €) était jugé, à tort, différent de la rémunération précalculée transmise par la DGFIP [Pas de Mantis]

La rémunération permanente de l’agent est comparée, à chaque génération des mouvements, à la rémunération précalculée transmise par la DGFIP. Un montant dont les centimes se terminent par 0 (1 422,50 € par exemple) n’était pas écrit de la même façon des deux côtés : il était jugé différent, et un mouvement « 45 » était généré à chaque paie sans changement réel. Les deux montants sont désormais comparés à l’identique : le mouvement « 45 » n’est plus généré que si la rémunération a réellement changé.

CI13 : Le champ “Code créancier social” du mouvement “PS” ne devrait plus être obligatoire à la saisie [Pas de Mantis - TNR SSAC]

Livret individuel > Paie > Paie DGFIP, détail de la remise, mouvement « PSC Mutuelle (PS) » : le code créancier social n’est plus obligatoire à la saisie :

CI14 : Import PSC ALAN : les options souscrites sont désormais rattachées au dossier PSC de l’agent ; lors d’un changement ou d’un retrait d’option, ou d’un arrêt de couverture, l’option précédente est fermée. La référence de l’option créée est le code ALAN, sans le libellé qui le suit [Mantis #19931]

Lors de l’import d’un fichier PSC de l’organisme ALAN, l’option souscrite par l’agent était créée sans être rattachée à son dossier PSC. Elle y est désormais rattachée, à sa date de début ; un changement ou un retrait d’option, comme un arrêt de couverture, ferme l’option précédente. La référence de l’option créée est le code fourni par ALAN, sans le libellé qui le suit dans le fichier : une option déjà créée par un import précédent avec le code et le libellé est retrouvée et réutilisée.

CI15 : Les types de mouvements ne seront désormais plus en lecture seule lors de l’import du référentiel [Pas de Mantis - TNR]

Point technique, sans illustration.

CI16 : Correction des index de paramétrage des champs “Destination”, “Plafond” et “Code chaire” du type de mouvement “02” [Pas de Mantis]

Point technique, sans illustration.

CI17 : Imports de fichiers de la paie DGFIP (base paie, LR, J5, KA, BJ, primes, PSC, ventilations validées) : la confirmation et le contrôle du nom des fichiers ne s’exécutaient pas, et l’import partait sans demande de confirmation ; ils sont rétablis. Un nom de fichier qui ne correspond pas au fichier attendu ne bloque pas l’import : une confirmation est demandée (« Importer quand même ? »). Chaque bloc d’import d’un même écran est contrôlé indépendamment des autres, et les messages de confirmation des imports de primes et de ventilations validées sont corrigés [Pas de Mantis - TNR EFLA]

Imports de fichiers de la paie DGFIP : un nom de fichier qui ne correspond pas au fichier attendu ne bloque pas l’import, une confirmation est demandée (« Importer quand même ? ») :

Temps de Travail

ET01 : Nouveau paramètre « Temps de travail - Masquer SNF » (NON par défaut) : à OUI, les absences d’un type « Service non fait » apparaissent dans les plannings et les demandes avec le code et la couleur génériques, sans leur motif ; l’agent voit toujours ses propres motifs [Mantis #16606]

Nouveau paramètre « Temps de travail - Masquer SNF » (OUI/NON, « NON » par défaut) permettant de masquer, dans les plannings, le motif des absences posées sur un type d’absence marqué « Service non fait ». À « OUI », ces journées s’affichent avec le code et la couleur génériques des absences — comme pour un agent hors périmètre — et leur motif n’apparaît plus ni dans l’infobulle de survol de la journée, ni dans le détail de la journée, ni dans les tableaux de demandes, y compris le bloc de validation du planning collectif. L’agent concerné continue de voir le motif de ses propres absences.

Avec le paramètre à « OUI », l’absence apparaît comme une absence générique dans le planning, quel que soit l’accès de l’utilisateur.

ET02 : Nouvelle option « Masquer le compteur » sur les types d’absence (GRH / Administration > Statuts et Filières > Droits) : le type n’a plus de compteur et se demande sans contrôle de solde ; circuit de validation et dates limites inchangés [Mantis #19741]

Nouvelle option « Masquer le compteur » sur les types d’absence utilisables en demande (GRH / Administration > Statuts et Filières > Droits). Un type ainsi paramétré n’a plus de compteur : il est ignoré par le calcul des droits, quel que soit le quota annuel déclaré pour le statut, et aucun compteur n’est plus créé ni affiché pour lui. Les agents dont le statut est déclaré pour ce type peuvent alors déposer une demande d’absence sans contrôle de solde (sans limite), en libre-service comme depuis leur responsable ; le circuit de validation, les dates limites de consommation et l’obligation de solder un report restent inchangés.

ET03 : Les listes de demandes (libre-service, planning de validation, demandes passées) affichent une colonne « Valideur(s) » : au survol, le circuit de validation étape par étape (statut, date de l’avis, valideur ou répondants attendus) [Mantis #19745]

Les listes de demandes (libre-service, planning de validation des congés, demandes passées) affichent une nouvelle colonne « Valideur(s) ». Une icône par ligne présente au survol le détail du circuit de validation : une ligne par étape, avec son libellé, son statut, la date de l’avis et le nom du valideur — celui qui a statué lorsque l’avis est rendu, sinon le ou les répondants attendus de l’étape. Pour une étape confiée au valideur habituel, comme pour une demande sans circuit de validation, le nom affiché est celui du supérieur hiérarchique (N+1), destinataire de la notification ; l’infobulle le signale, d’autres gestionnaires pouvant également être habilités à valider. L’affichage de la liste n’est pas ralenti : ce détail n’est chargé qu’au survol de la ligne.

Absence avec circuits de validation depuis la liste des demandes

Absence avec circuits de validation depuis le planning

Demande sans circuit de validation

ET04 : L’accord de télétravail admettra dorénavant une liste “Récupération TT fixe sur absence” (Oui par défaut) : sur Non, une journée de télétravail fixe reste décomptée du compteur en cas d’absence (demandée ou médicale) ou de jour fermé [Mantis #19834]

Temps de Travail / Administration > Temps de travail > Télé-travail, modification d’un accord : nouvelle liste « Récupération TT fixe sur absence », avec son aide :

CT01A : Le solde d’une demande d’absence pouvait devenir négatif : après la validation de plusieurs demandes à la suite, y compris pour plusieurs agents en même temps, le recalcul des droits pouvait en ignorer une partie, et le droit restant restait surévalué jusqu’au recalcul suivant. Chaque validation est désormais prise en compte dans le recalcul. [Mantis #19810]

Point technique, sans illustration.

CT01B : À l’enregistrement d’une demande d’absence (saisie, demi-journées, pointeuse, changement de type), le compteur du type demandé est recalculé (année de la demande et précédente) avant le contrôle du solde, après tout calcul des droits en cours. En cas de refus faute de solde, le formulaire réaffiche le solde à jour. [Mantis #19810]

Exemple : un agent dispose de 2 jours de congé annuel restants, mais le dernier calcul de ses droits ne tient pas encore compte d’une demande validée entre-temps. À l’enregistrement d’une nouvelle demande de 2 jours, le compteur est d’abord recalculé : le solde réel (0 jour) est opposé à la demande, qui est refusée, et le formulaire réaffiche le solde à jour plutôt que l’ancien.

CT01C : Une demande d’absence à cheval sur plusieurs périodes de référence est contrôlée sur le compteur de chaque période, pour la part qui y tombe ; elle était jusqu’ici contrôlée en totalité sur le compteur de la première période. [Mantis #19810]

Point technique, sans illustration.

CT01D : À la validation d’une demande d’absence par le responsable, avec ou sans circuit de validation, le compteur est recalculé de la même façon et la validation est refusée si la demande dépasse le droit restant (« Droit restant insuffisant : la demande ne peut pas être validée. »). Les demandes d’annulation ne sont pas concernées. [Mantis #19810]

Point technique, sans illustration.

CT01E : Un type d’absence dont le compteur de l’année a été ramené à zéro, puis supprimé par le calcul des droits, ne laisse plus passer de demande : le dépôt comme la validation sont refusés faute de solde. Un type d’absence sans compteur (option « Masquer le compteur ») reste utilisable sans contrôle de solde. [Mantis #19810]

Point technique, sans illustration.

CT01F : Le compteur n’est plus recalculé avant un contrôle de solde s’il vient de l’être (validité de 30 minutes, annulée par toute modification des droits de l’agent ou du paramétrage), ni pour un type d’absence sans compteur : dépôts et validations sont plus rapides. La modification d’une carrière ou d’une suspension relance aussi le recalcul de l’agent. [Mantis #19810]

Point technique, sans illustration.

GPEC

EP01 : GPEC > Postes > Détails des Postes : le grade affiché pour un occupant est celui qu’il détenait à la fin de son affectation sur le poste (grade du jour si elle est en cours), à l’écran, dans la modification d’une affectation et dans les fiches de poste Word [Mantis #19568]

Dans la liste des agents occupant un poste (GPEC > Postes > Détails des Postes), le grade affiché pour un agent est désormais celui qu’il détenait à la date de fin de son affectation sur ce poste, et non plus son grade actuel ; pour une affectation toujours en cours (sans date de fin), le grade à la date du jour continue d’être affiché. Le même affichage s’applique au formulaire de modification d’une affectation et aux fiches de poste générées au format Word (dont celles où le bloc des occupants est inséré dans un commentaire par la balise [OCCUPANTS]).

Entretiens

EE01 : Dans le détail d’un entretien (Evaluations > Campagnes en cours et Historique, ainsi que l’écran des entretiens en libre-service), les étapes du circuit que l’utilisateur n’a pas le droit de consulter — confidentialité posée sur le circuit ou sur l’étape elle-même — ne se résument plus à la mention « Privée ». Elles se présentent désormais comme les autres étapes, avec leur libellé, leur état d’avancement et, au survol, le répondant principal et ses délégataires. Aucune action n’y est en revanche proposée : ni consultation du détail, ni édition PDF, ni modification — ces accès restent réservés aux répondants de l’étape, pour qui rien ne change. La règle déterminant qu’une étape est confidentielle est inchangée : seule sa présentation évolue [Mantis #19715]

Les étapes privées seront dorénavant « visibles » cependant, le détail et l’export PDF ne seront pas disponibles, sauf pour le répondant ou un délégataire.

EE02 : Dans le paramétrage des processus d’entretien (Evaluations / Administration > Evaluations > Processus), l’évaluation des compétences d’une étape propose une quatrième option, « Limitée au poste avec niveaux », qui combine les deux options existantes : comme pour « Limitée au poste », ce sont les compétences du poste de l’agent (celles pour lesquelles un niveau requis est défini) qui sont proposées, sans ajout ni suppression possible ; comme pour « Ouverte », l’évaluateur choisit pour chacune l’un de ses niveaux possibles dans une liste déroulante, le commentaire de chaque niveau s’affichant sous son libellé. Une compétence laissée sans niveau est considérée comme non évaluée. Le tableau rappelle le niveau requis, le dernier niveau évalué et sa date ainsi que le niveau retenu à l’étape précédente, et un commentaire libre peut être saisi pour chaque compétence ; l’édition PDF de l’entretien reprend ces informations. Seuls les niveaux possibles d’une compétence du poste sont acceptés à l’enregistrement. Le paramètre est désormais accompagné d’une aide décrivant les quatre options. Pour l’option « Limitée au poste », une compétence évaluée à un niveau supérieur au niveau requis (par exemple recopié d’une étape évaluée par niveau) est désormais considérée comme atteinte, et ce niveau est conservé à l’enregistrement au lieu d’être effacé ; les autres options sont inchangées [Mantis #19839]

Paramétrage de l’option dans le processus :

Affichage de l’évaluation dans une étape de l’entretien d’un agent :

CE01 : Dans la liste des enveloppes réponses d’une campagne (Evaluations > Campagnes, modification de masse), l’ajout à l’historique des entretiens est désormais réservé aux étapes terminées : une étape à faire, en cours ou non réalisée ne pouvait jusqu’ici être figée dans l’historique alors que son contenu était encore susceptible d’évoluer. Si la sélection en contient, l’utilisateur en est averti avant l’envoi ; côté serveur, ces enveloppes sont écartées, un message en indique le nombre, et les étapes terminées de la même sélection sont bien ajoutées. L’édition PDF d’une étape reste, elle, possible à tout moment, depuis le détail comme depuis la liste [Mantis #19802, #16194]

CE02 : Dans le détail d’un entretien et son édition PDF, pour une étape dont l’évaluation des compétences est « Ouverte », la colonne du niveau attendu par le poste restait toujours vide, même lorsque le poste de l’agent disposait d’un recalibrage validé portant sur la compétence ; elle affiche désormais le niveau attendu issu du dernier recalibrage validé à la date de l’entretien, comme pour l’option « Limitée au poste » [Pas de Mantis]

Entretiens > Campagnes, détail d’un entretien, bloc « Compétences » d’une étape dont l’évaluation des compétences est « Ouverte » : colonne « Attendu poste », alimentée par le dernier recalibrage validé du poste à la date de l’entretien :

Formation

EF01 : Retrait de l’ancienne interface d’échange avec le LMS EducExpert (XML-RPC), obsolète et porteuse d’une vulnérabilité, avec ses écrans d’administration ; les intégrations e-learning actuelles (Disegno/Citrus, Moodle, APIS) sont inchangées [Pas de Mantis]

Retrait de l’ancienne interface d’échange avec le LMS EducExpert (protocole XML-RPC), obsolète, non maintenue et porteuse d’une vulnérabilité de sécurité : les écrans d’administration et les données de correspondance propres à cette interface sont supprimés. Les intégrations e-learning actuelles (Disegno/Citrus en REST, Moodle, APIS) et le suivi des progressions restent inchangés.

Point technique : retrait d’une interface obsolète, sans écran de remplacement.

EF02 : Écrans de pré-requis d’un modèle de stage et d’une session harmonisés : présentation et comportement identiques, combinaison des pré-requis d’emploi initialisée à « ET », intitulés des pré-requis médicaux visibles en consultation [Mantis #6612]

Harmonisation des écrans de pré-requis d’un modèle de stage et d’une session de stage : leur présentation et leur comportement sont désormais strictement identiques. Le type de combinaison (« ET » / « OU ») des pré-requis d’emploi est initialisé par défaut sur « ET » sur les deux écrans, et les intitulés « Stagiaires » / « Intervenants » des pré-requis médicaux s’affichent aussi en consultation

EF03 : Pré-requis (UV, emplois, grades, affectations, aptitudes médicales) sur les postes de l’équipe pédagogique, du modèle de stage à la session. Mode « OUI+PREREQ » du libre-service formateurs : seuls les postes dont l’agent satisfait les pré-requis lui sont proposés [Mantis #6612]

Possibilité de définir des pré-requis (unités de valeur, emplois, grades, affectations, aptitudes médicales) sur les postes de l’équipe pédagogique, au niveau du modèle de stage comme de la session, avec report automatique du modèle vers la session à sa création. Un nouveau mode « OUI+PREREQ » du paramètre « Libre-service - Formateurs par équipe pédagogique » restreint alors, dans le libre-service candidatures formateurs, les postes proposés à l’agent à ceux dont il satisfait les pré-requis (les postes non éligibles sont masqués) ; dans ce mode, les pré-requis médicaux des intervenants se saisissent sur l’équipe pédagogique plutôt que sur le stage ou la session. L’écran des intervenants d’une session affiche également, pour chaque intervenant, un marqueur « PR » signalant qu’il ne satisfait pas les pré-requis de son poste (avec le détail des pré-requis non validés au survol et en fenêtre dédiée au clic)

Équipe pédagogique d’une session, avec les types de pré-requis par poste :

EF04 : Écran des coûts d’une session (vacations et indemnités des encadrants) : détail des heures de présence de chaque formateur par convention de prise en charge et taux horaire, si le paramètre “Sessions - Présences détaillés” n’est pas à NON [Mantis #19530]

Sur l’écran des coûts d’une session (onglet des vacations et indemnités des encadrants), le tableau des formateurs affiche désormais, sous chaque formateur, le détail de ses heures de présence regroupé par convention de prise en charge et par taux horaire (durée cumulée, taux et montant). Cet affichage complémentaire n’apparaît que lorsque le paramètre “Sessions - Présences détaillés” n’est pas sur “NON”

EF05 : Transition graphique - Evolution des jours de segmentation des sessions de stage en un tableau à double entrée (jour de la semaine et numéro de la semaine), avec la possibilité d’adapter la date de fin en fonction des jours de la semaine et fermés [Mantis #19383]

EF06 : Les réponses libres saisies dans un questionnaire qualité conservent désormais les zéros non significatifs : une réponse saisie sous la forme « 007 » (matricule, code, numéro…) était auparavant enregistrée « 7 » [Mantis #19658]

EF07 : Candidats stagiaires d’une session : avec le modèle de feuille de présence « CNPF », la colonne du grade est remplacée par la fonction de l’affectation en vigueur à la fin de la session, à l’écran comme dans l’export tableur [Mantis #19656]

Sur l’écran des candidats stagiaires d’une session (Formation > Sessions > Détails des Sessions > Candidats Stagiaires), la colonne du grade est remplacée par la fonction de l’affectation de l’agent lorsque le paramètre « Feuilles de présence - Modèle » vaut « CNPF ». Le remplacement vaut à l’écran comme dans l’export tableur, et la colonne reste triable. La fonction affichée est celle du référentiel des fonctions d’affectation, prise sur l’affectation en vigueur à la date de fin de la session ; pour tous les autres modèles de feuille de présence, la colonne du grade est inchangée

CF01 : Correction de l’affichage des pré-requis médicaux agrégés en consultation sur l’écran des pré-requis d’un modèle de stage : le bloc pouvait ne pas s’afficher [Mantis #6612]

Pré-requis d’un modèle de stage, avec le bloc des pré-requis médicaux agrégés :

CF02 : Fiche de liaison logistique d’une session (atelier, restauration / hébergement) : deux éditions lancées simultanément par deux utilisateurs pouvaient mélanger les informations d’en-tête de leurs sessions ; chaque édition a désormais ses propres données [Pas de Mantis]

Correction d’un risque de mélange d’informations sur la fiche de liaison logistique (fiche de liaison atelier et fiche restauration / hébergement) d’une session : les données rappelées en en-tête (intitulé de la session, lieu ou organisme, interlocuteur, dates, effectifs, observations) étaient conservées globalement et non par édition, si bien que deux éditions lancées simultanément par deux utilisateurs pouvaient afficher les informations de la session de l’autre. Chaque édition dispose désormais de ses propres données

Point technique, sans changement visible : chaque édition dispose désormais de ses propres données.

CF03A : Correction du “Tableau de bord du centre” (Formation > Gestion des FMA), qui se rechargeait en boucle et devenait inutilisable dès que des FMA étaient définies ; seule une modification de l’utilisateur relance désormais la recherche [Mantis #19028]

Correction du “Tableau de bord du centre” (Formation > Gestion des FMA) qui se rechargeait en boucle et devenait inutilisable — aucune sélection ni aucun clic possibles — dès lors que des FMA étaient définies : l’initialisation du filtre des FMA provoquait à tort une soumission automatique du formulaire à chaque chargement de la page. Seule une modification faite par l’utilisateur (année, service, FMA, agent…) relance désormais la recherche

CF03B : Le “Tableau de bord du centre” (Formation > Gestion des FMA) restait vide pour les utilisateurs à périmètre départemental, ce périmètre n’étant plus reconnu ; corrigé, ainsi que l’écran d’indemnisation des FMA [Mantis #19028, #19884]

Le “Tableau de bord du centre” (Formation > Gestion des FMA) restait vide — graphiques à zéro, quelle que soit l’année ou le service choisi — pour les utilisateurs disposant d’un périmètre départemental : ce périmètre n’était plus reconnu d’une page à l’autre, et les résultats étaient filtrés à tort sur une liste de services vide. L’écran d’indemnisation des FMA, qui s’appuie sur le même périmètre, en bénéficie également

Corrections multiples sur ce même écran qui restait vide.

CF04A : Rétablissement de la restriction au périmètre de l’utilisateur sur les écrans de validation des candidatures et des demandes de formation : consultation et décisions ne portent plus que sur les candidatures de son périmètre, comme sur les autres écrans [Pas de Mantis]

Rétablissement de la restriction au périmètre de l’utilisateur sur les écrans de validation des candidatures et des demandes de formation. Les listes des autres candidatures et des autres demandes d’un agent, le commentaire et les disponibilités d’une demande, ainsi que la prise de décision (montée ou descente de priorité, avis d’un niveau de validation, acceptation, transmission, rattrapage, remise en attente, rejet) ne portent désormais que sur les candidatures relevant du périmètre de l’utilisateur, selon la même règle que les autres écrans de candidatures — périmètre agent et/ou session, listes de grades et d’emplois, niveau d’accès validation. Cette restriction, présente à l’origine, avait été désactivée ; elle est rétablie à la demande. Les disponibilités choisies restaient par ailleurs affichées alors même que la candidature n’était pas consultable. Le décompte des candidatures d’une session et la proposition du prochain numéro de diplôme, qui ne comportent aucune donnée nominative, ne sont volontairement pas restreints

Point technique de renforcement de la sécurité.

CF04B : Candidatures de formateur d’une session : acceptation, refus, modification et suppression vérifient l’appartenance à la session et au périmètre de l’utilisateur (sauf « Candidatures - Visibilité ouverte » à OUI ou accès départemental complet) [Pas de Mantis]

Même restriction sur les candidatures de formateur d’une session : l’acceptation, le refus, le changement de type ou de qualification et la suppression vérifient désormais que la candidature traitée appartient bien à la session affichée, et qu’elle relève du périmètre de l’utilisateur. La vérification du périmètre est omise — et seul le rattachement à la session reste exigé — lorsque le paramètre « Candidatures - Visibilité ouverte » est sur « OUI » ou que l’utilisateur dispose de l’accès départemental complet

Point technique de renforcement de la sécurité.

CF05 : Sur l’écran des candidats stagiaires d’une session, l’écran de changement du service de rattachement d’un candidat rappelait systématiquement le grade de l’agent au-dessus du formulaire, sans tenir compte du paramètre « Général - Affichage du grade ». Ce rappel respecte désormais le paramétrage, comme les autres identités courtes de l’application [Mantis #19656]

CF06 : Écran « Logistique » d’une session en accès externe : les boutons « Enregistrer » et le bloc « Choix du forfait » ne s’affichent plus lorsque tous les candidats du service sont acceptés (logistique alors en lecture seule) [Mantis #19684]

Sur l’écran « Logistique » d’une session consulté par un accès externe (portail d’un service partenaire), la logistique d’un candidat déjà accepté est en lecture seule pour ce service, l’organisateur ayant alors la main. L’écran proposait pourtant des boutons « Enregistrer » (bloc « Choix du forfait » en tête de page et bas de page) même lorsque tous les candidats du service étaient acceptés et qu’aucune fiche n’était saisissable, ce qui laissait croire à un enregistrement impossible. Ces boutons et le bloc « Choix du forfait » ne s’affichent désormais, pour un accès externe, que lorsqu’au moins un candidat du service n’est pas encore accepté

Corrections multiples dans le déroulement de cet écran.

CF07 : Les repas d’un stagiaire en rattrapage figurent désormais sur la feuille de repas de la logistique. [Mantis #19870]

Correction dans ces éditions : les stagiaires en rattrapage seront désormais présentés.

CF08 : Sous Oracle, la liste des sessions du libre-service stagiaire ne s’affichait plus pour un agent ayant déjà candidaté, et des observations de plus de 4 000 caractères provoquaient la même panne : ces textes sont désormais lus de façon compatible [Pas de Mantis]

Sous Oracle, la liste des sessions du libre-service stagiaire ne s’affichait plus dès lors que l’agent avait déjà déposé une candidature : le commentaire de refus, texte long, faisait échouer la requête (« types de données incohérents »). Les observations des sessions, affichées par le libre-service stagiaire et formateur (y compris sur l’application mobile), pouvaient par ailleurs provoquer la même panne lorsqu’elles dépassaient 4 000 caractères. Ces textes sont désormais lus de façon compatible, limités à 3 900 caractères dans ces listes

Cet écran pouvant ne plus afficher de sessions sur une base Oracle.

CF09 : Paramètres « Doubles carrières - … » (Emplois, Diplômes, UV) : une valeur mal saisie provoquait une erreur à la délivrance des diplômes et à l’enregistrement d’un emploi ; les couples incomplets sont ignorés, le paramétrage restant à corriger [Mantis #19937]

Correction préventive de la lecture des paramètres « Doubles carrières - … » (Emplois, Diplômes, UV) : ces paramètres doivent contenir des couples de statuts de la forme SPP=SPV|PATS=SSSM. Une valeur mal saisie (statut seul, séparateur | doublé, couple incomplet) provoquait une erreur lors de la délivrance des diplômes avec l’attribution automatique des emplois, ainsi qu’à l’enregistrement d’un emploi sur le livret d’un agent en double carrière. Les couples incomplets sont désormais ignorés, et seuls les couples bien formés sont synchronisés. Le paramétrage reste à corriger : un couple mal saisi n’est pas synchronisé

Outils > Paramètres > Paramètres, bloc « Doubles » : paramètres « Doubles carrières - Diplômes / Emplois / UV », à renseigner avec des couples de statuts bien formés (ex. SPP=SPV) :

CF10 : Planification des sessions (Formation > Planification > Sessions) : l’affichage jour par jour d’un mois de 30 jours ou de février provoquait une erreur et l’écran ne s’affichait pas ; la période s’arrête désormais au dernier jour réel du mois [Mantis #19970]

Formation > Planification > Sessions, mois de septembre affiché « Par jour » : le calendrier s’affiche de nouveau pour un mois de 30 jours, jusqu’au dimanche qui suit le 30 :

Formation - Emargement

EV01 : Nouveau bloc « Émargements » du Libre-Service : écrans « Sessions de stages » et « FMPA sur centre » listant les sessions et séances de l’agent, avec accès direct à l’émargement sans QR code ; accès paramétrable dans les droits des profils [Pas de Mantis]

Ajout d’un bloc « Émargements » dans le menu Libre-Service, avec deux écrans : « Sessions de stages » (les sessions sur lesquelles l’agent est inscrit comme stagiaire accepté ou engagé comme formateur) et « FMPA sur centre » (les séances auxquelles il participe ou qu’il encadre). Chaque écran liste les sessions/séances de la plus récente à la plus ancienne, avec des filtres sur la période — et, pour les sessions, sur l’état de l’inscription et l’état de la session — puis permet d’accéder directement à son émargement sans passer par le QR code. Il ne s’agit que d’un raccourci de navigation : les règles d’accès et de signature sont inchangées, et une ligne dont l’émargement n’est pas ouvert (aucune journée planifiée, journées passées hors dérogation) s’affiche grisée avec le motif. L’accès à ces deux écrans se paramètre dans les droits des profils. Les signatures réalisées par l’agent depuis son propre compte sont désormais identifiées comme telles, distinctement du mode kiosque.

Nouvel écran « Libre-Service > Émargements > Sessions de stages », avec ses filtres :

Outils

EO01 : Mise à jour de sécurité et de maintenance des bibliothèques tierces : montées de version corrigeant des vulnérabilités connues (notamment pac4j/OIDC, Spring, Apache Commons VFS, json-smart, Nimbus JOSE+JWT, Woodstox) et retrait de bibliothèques obsolètes ou inutilisées ; sans changement fonctionnel visible. [Pas de Mantis]

Point technique de maintenance des bibliothèques, sans changement visible.

EO02 : Retrait de l’ancienne interface d’échange par messagerie JMS (pont bidirectionnel avec le SIRH de gestion administrative), obsolète et non maintenue : le démon, les écrans de contrôle et les bibliothèques associées sont supprimés. Les interfaces d’échange actuelles (imports/exports de fichiers, interfaces REST) ne sont pas affectées. [Pas de Mantis]

Point technique : retrait d’une interface obsolète, sans écran de remplacement.

EO03 : Montée de version de la bibliothèque tierce de lecture et d’écriture des fichiers CSV (OpenCSV 1.8 → 5.12), utilisée par les imports et exports au format CSV (imports Sedit, paie DGFIP, organigramme, imputations…) : mise à jour de maintenance, sans changement fonctionnel visible. [Pas de Mantis]

Point technique de maintenance des bibliothèques, sans changement visible.

EO04 : Envois vers MédiSAP depuis les écrans désormais asynchrones (file d’attente) : la saisie n’attend plus et n’est plus bloquée si le service est indisponible. Notification en cas d’échec et bouton de ré-envoi (MédiSAP et eSedit) [Pas de Mantis]

Les données transmises à MédiSAP lors des mises à jour dans les écrans (dossiers agents, tests physiques, emplois/spécialités, diplômes, permis) sont désormais envoyées de façon asynchrone via une file d’attente : la saisie n’attend plus l’appel réseau vers MédiSAP et n’est plus bloquée si le service est indisponible, l’envoi effectif étant réalisé périodiquement par le traitement de fond. En cas d’échec sur un lot d’envois, une notification est remontée dans la cloche, et un bouton de ré-envoi des éléments en erreur a été ajouté (pour MédiSAP comme pour l’interface sortante eSedit). L’envoi de masse depuis l’écran d’administration MédiSAP reste inchangé

EO05 : Ajout, sur l’écran d’audit des courriels, d’un bouton permettant de replacer en une seule action tous les courriels en erreur en attente d’envoi, afin d’en retenter l’émission. [Pas de Mantis]

EO06 : Requêteur : nouvel export Excel natif (.xlsx) des résultats, avec colonnes typées, en-têtes figés, filtre automatique, ligne de total et un onglet graphique quand la requête en déclare un (les zones circulaires y sont rendues en anneau). Les exports Excel et OpenOffice Calc existants restent inchangés. [Pas de Mantis]

EO07 : Nettoyage interne du code : les 296 points d’entrée historiques des fonctions utilitaires, conservés en délégation lors des refactorisations précédentes, sont supprimés ; les appels qui les utilisaient encore ont été redirigés vers les fonctions cibles. Sans changement fonctionnel ni impact sur les écrans. [Pas de Mantis]

Point technique de refactorisation interne, sans changement visible.

EO08 : Nettoyage interne du code : fragments recopiés mutualisés et feuilles de style des documents Word générés sorties du code vers des ressources dédiées ; près de 5 800 lignes en moins, sans changement fonctionnel [Pas de Mantis]

Nettoyage interne du code : les fragments recopiés à l’identique dans de nombreux fichiers ont été mutualisés dans des fonctions et des fragments partagés — traitement de fermeture en fin de requête des écrans, en-tête des écrans à onglets, socle commun des entités de paie, comparaison et empreinte des objets (désormais confiées aux fonctions standard du langage) et blocs d’affichage récurrents (suivi d’une candidature, corps des courriers de masse). En parallèle, les feuilles de style figées des documents Word générés — en-tête d’une feuille de présence et tables de styles communes à plusieurs feuilles d’impression — ont été sorties du code vers des ressources dédiées. Près de 5 800 lignes de code en moins, sans changement fonctionnel : écrans, documents produits et données restent identiques.

Point technique de refactorisation interne, sans changement visible.

EO09 : Nettoyage interne du code : la logique déclarée dans les pages d’affichage est transférée dans du code applicatif dédié par module, sans changement fonctionnel ; équivalence des états du bilan de formation vérifiée par test automatisé [Pas de Mantis]

Nettoyage interne du code : les fonctions et les objets qui étaient déclarés directement à l’intérieur des pages d’affichage ont été transférés dans du code applicatif dédié, regroupé par module — fiches réflexes, fiche de liaison logistique, aide aux balises des modèles de courriers, états du bilan de formation, ventilation des besoins collectifs sur l’organigramme, vue en arbre du modèle de données et choix d’une capture d’écran du manuel utilisateur. Les quatre états du bilan de formation partagent désormais un socle commun (calculs de totaux et éléments de tableau) et le code recopié à l’identique entre les deux variantes de la fiche réflexe n’existe plus qu’en un seul exemplaire ; une fonction devenue inutilisée a été supprimée. Sans changement fonctionnel : les écrans et les documents produits sont identiques, l’équivalence des tableaux du bilan de formation ayant été vérifiée par test automatisé avant/après.

Point technique de refactorisation interne, sans changement visible.

EO10A : Refactorisation d’ensemble : les pages d’affichage historiques sont converties en composants applicatifs, écran par écran, sans changer aucune adresse (menu, favoris, raccourcis) ni, à droits identiques, les écrans et documents produits [Pas de Mantis]

Refactorisation d’ensemble du code applicatif : les pages d’affichage historiques sont progressivement converties en composants applicatifs, écran par écran, et la configuration de déploiement allégée d’autant. Le chantier est mené sans changer aucune adresse : les liens du menu, les favoris et les raccourcis vers les écrans restent identiques, et à droits identiques les écrans, les données et les documents produits sont inchangés. Les blocs de la page d’accueil (« pagelets ») sont les premiers convertis, en conservant le chemin enregistré pour chacun d’eux : les pagelets configurées restent en place, y compris celles ajoutées à la main.

Point technique de refactorisation interne, sans changement visible.

EO10B : Sécurité des écrans d’administration de référentiels : l’accès en lecture à un onglet est contrôlé côté serveur (« Accès refusé » sans droit), et un paramètre d’URL ne peut plus afficher un autre écran sous l’adresse d’un écran [Pas de Mantis]

Sécurité des écrans d’administration de référentiels. D’une part, l’accès en lecture à un onglet est désormais contrôlé côté serveur : un onglet que le menu n’affichait déjà pas faute de droit, mais dont l’adresse restait atteignable directement, renvoie maintenant « Accès refusé ». D’autre part, l’adresse demandée fait foi : un paramètre d’URL ne peut plus faire afficher, sous l’adresse d’un écran, le contenu d’un autre écran d’administration.

Point technique de renforcement de la sécurité.

EO10C : En multi-clients, la composition des écrans d’administration est évaluée pour chaque client d’après ses propres paramètres de licence, et réévaluée dès la modification de l’un d’eux, sans redémarrage [Pas de Mantis]

En multi-clients, la composition des écrans d’administration (onglets proposés, tables de détail dépliées sous une fiche) est désormais évaluée pour chaque client d’après ses propres paramètres de licence — elle était calculée une seule fois, au premier chargement, puis partagée par tous les clients — et réévaluée dès la modification d’un de ces paramètres, sans redémarrage.

Point technique concernant les hébergements SaaS.

EO10D : Les écrans d’administration de référentiels proposent l’export Excel là où il manquait, les filtres et le découpage en pages y étant déjà actifs. [Pas de Mantis]

EO10E : Corrections d’affichage et de droits révélées par la conversion des écrans : sous-écrans d’un modèle de stage, boutons de raccourci d’une pagelet de navigation, pagelet de pilotage d’une interface d’échange [Pas de Mantis]

Corrections d’affichage et de droits révélées par la conversion des écrans. Les sous-écrans d’un modèle de stage refermaient la page deux fois, ce qui laissait le bloc « appliquer aux sessions à venir » coincé entre les deux fermetures. Dans une pagelet de navigation, un bouton de raccourci auquel l’utilisateur n’a pas droit interrompait la liste : il masquait aussi tous les boutons suivants du même bloc, il est maintenant simplement omis. Enfin la pagelet de pilotage d’une interface d’échange refermait sa page de façon incomplète, deux balises de tableau y manquaient, et un dossier d’échange illisible provoquait une erreur au lieu d’être signalé comme vide.

Point technique : corrections révélées par la refactorisation.

EO10F : Droits de l’écran « Outils > Optimisation BD » : consultation (informations), modification (calculs et traitements sans perte) et droit complet (traitements destructeurs) sont distingués. À vérifier à la montée de version : niveau de droit des comptes concernés [Pas de Mantis]

Mise en conformité des droits de l’écran « Outils > Optimisation BD », révélée par la conversion des écrans. L’écran ne vérifiait qu’une fois le droit de consultation, et ce niveau ouvrait ensuite toutes ses actions, y compris les plus lourdes de conséquences. Les trois niveaux de droit y sont désormais distingués. La consultation ne donne que les informations : état des tables calculées et date de leur dernier calcul, liste des référentiels livrés avec l’application, vérification des durées saisies, vérification des fichiers joints, état des services de fond — aucun bouton d’action n’y est proposé. La modification lance les calculs et les traitements sans perte de données : recalculs et mises à jour des vues, appels aux interfaces sortantes, contrôles de l’annuaire d’entreprise, intégration de l’annuaire d’adresses, chiffrement des pièces jointes, sauvegarde des fichiers joints, exports de référentiels, rechargement du dictionnaire de données, des libellés manquants et du menu, relance des services de fond. Le droit complet lance les seuls traitements destructeurs : application de la structure à la base, restauration des fichiers joints, suppression de toutes les sauvegardes, rechargement complet des libellés, rechargement de l’aide en ligne, et chargement d’un jeu de données de référence livré. Un bouton n’apparaît que si le niveau qu’il exige est acquis, et chaque action revérifie ce niveau côté serveur : l’adresse forgée ne contourne rien. À vérifier à la montée de version : un compte qui lançait ces traitements avec le seul droit de consultation doit être repassé en modification, et un compte qui restaurait les fichiers joints ou supprimait les sauvegardes doit recevoir le droit complet.

Point technique de mise en conformité des droits.

EO10G : Fin de la refactorisation EO10A : toutes les pages historiques sont converties, sans changement d’adresse. Mise en page des documents bureautiques sortie en ressources, défauts de robustesse corrigés, écran d’erreur de l’outil généralisé [Pas de Mantis]

Achèvement de la refactorisation engagée en EO10A : la totalité des pages d’affichage historiques est désormais convertie en composants applicatifs — il n’en subsiste aucune. Les derniers lots ont porté sur les documents bureautiques les plus volumineux (procès-verbaux de stage, listes de stagiaires et de formateurs, fiches de jury individuelles, fiches réflexes, convocations, demandes de mandatement, états d’indemnités des stagiaires et des formateurs, courriers de réservation de repas), dans leurs déclinaisons propres à chaque client : leur mise en page sort du code vers des ressources modifiables sans recompilation, les données et les calculs restant inchangés. Aucune adresse n’a changé : les liens du menu, les boutons d’édition, les favoris et les raccourcis restent identiques, et à droits identiques les documents produits sont les mêmes. La conversion a par ailleurs corrigé des défauts de robustesse propres à ces éditions : documents qui s’interrompaient en cours de production sur une donnée absente ou mal formée, pages blanches en fin de document, ruptures de page mal placées, mentions « null » à la place d’une valeur vide, et temps de production allongés par la relecture répétée des mêmes données. Enfin, l’écran d’erreur de l’outil s’applique désormais à l’ensemble de l’application : une erreur imprévue survenant sur un écran déjà converti affichait jusqu’ici la page d’erreur du serveur d’application, avec son détail technique ; elle affiche maintenant le message d’erreur habituel de l’outil, dans sa mise en page.

Point technique de refactorisation interne, sans changement visible.

EO11 : Bibliothèques tierces : correction des vulnérabilités connues (Jackson, Log4j), 23 bibliothèques mises à jour, quatre montées majeures, et 20 bibliothèques inutilisées retirées (de 127 à 107, de 106 à 94 Mo). Sans changement fonctionnel visible [Pas de Mantis]

Poursuite de la mise à jour de sécurité des bibliothèques tierces engagée en EO01, entretien du parc et allègement de la livraison. Côté sécurité, des montées de version corrigent les vulnérabilités connues (Jackson, pour la lecture et l’écriture des données au format JSON, et l’API Log4j) ; deux bibliothèques étaient par ailleurs déclarées sans être livrées, dont une vulnérable : l’analyseur XML Xerces, inutilisé au profit de celui fourni par le langage, est retiré, et la bibliothèque de téléversement de fichiers est déclarée dans la version réellement utilisée. Côté entretien, vingt-trois bibliothèques sont montées à la dernière version de leur ligne — parmi lesquelles pac4j pour l’authentification SSO, plusieurs composants Apache Commons, Guava, Gson, Bouncy Castle et SLF4J — le code étant adapté là où l’interface de programmation de la bibliothèque JSON a changé ; quatre montées ont été volontairement écartées, chacune étant contrainte par une autre bibliothèque qui exige la version en place. Côté montées majeures, quatre lots ont été traités séparément, chacun validé par son propre contrôle : le compilateur de minification JavaScript, épinglé de longue date parce que les versions récentes exigeaient un socle Java plus élevé que le nôtre, repasse à la version courante — le passage du produit à Java 21 a levé la contrainte ; les bibliothèques de pilotage de LibreOffice, utilisées pour la conversion de documents, sont alignées sur la version que le convertisseur réclame lui-même, alors que nous en livrions une plus ancienne ; le moteur de lecture et d’écriture XML en flux et son interface d’extension, indissociables, montent ensemble d’une version majeure ; et le client HTTP employé par l’envoi de SMS fait de même. D’autres montées majeures ont été écartées à dessein, chacune contrainte par une bibliothèque tierce qui exige encore la version en place ou dont la version suivante s’appuie sur une publication non stabilisée. Côté allègement, vingt bibliothèques sans aucun usage sont retirées : le parc livré passe de 127 à 107 bibliothèques et d’environ 106 à 94 Mo. On y trouve un client de stockage distribué, trois modules Spring et deux modules d’authentification SSO sans emploi, le socle Avalon dont le moteur de génération PDF ne dépend plus, des outils de génération de code qui n’avaient pas à être livrés, et plusieurs doublons de bibliothèques déjà embarquées ailleurs — il ne subsiste désormais aucune classe en double entre les bibliothèques livrées, ce qui supprime tout risque de conflit de chargement. Les descripteurs de build décrivent à nouveau exactement les bibliothèques livrées. Sans changement fonctionnel visible.

Point technique de maintenance des bibliothèques, sans changement visible.

EO12 : Prérequis d’installation : le pilote JDBC Oracle n’est plus livré avec l’application. Clients Oracle : vérifier sa présence dans le répertoire « lib » de Tomcat avant la montée de version (déjà le cas sur une installation en fonctionnement) [Pas de Mantis]

Prérequis d’installation, dans le prolongement de EO11 — le pilote JDBC Oracle n’est plus livré avec l’application. Il était embarqué dans le paquet applicatif alors que le serveur ne s’en sert jamais depuis cet emplacement : une source de données gérée par le conteneur est construite par le serveur lui-même, qui ne lit que son propre répertoire de bibliothèques. Pour les clients Oracle, le pilote JDBC Oracle doit donc impérativement se trouver dans le répertoire « lib » de Tomcat — c’est déjà le cas sur toute installation en fonctionnement, faute de quoi la source de données n’aurait jamais pu être créée : il n’y a rien à installer, seulement à le vérifier avant la montée de version. Pour les clients MySQL et MariaDB, le pilote Oracle qui figurait jusqu’ici dans les bibliothèques de l’application disparaît du paquet livré ; s’il subsiste après une mise à jour effectuée sans redéploiement complet, il peut être supprimé sans précaution particulière — il n’a jamais été utilisé. Le paquet livré ne contient désormais plus aucun pilote de base de données, quel que soit le SGBD : le pilote relève de la configuration du serveur, comme c’était déjà le cas pour MySQL et MariaDB. En contrepartie, l’écriture des champs texte longs — seul traitement qui recourait encore à une interface propriétaire du pilote Oracle — passe désormais par l’interface JDBC standard, compatible avec tous les pilotes et tous les SGBD.

Point technique concernant l’installation du serveur.

EO13 : Le moteur XSLT Apache Xalan est retiré au profit de celui du langage, documents identiques vérifiés. Clients imprimant un catalogue de formation : « Sécurité - Restriction XSLT » peut être remis à OUI [Pas de Mantis]

Poursuite de l’allègement engagé en EO11 : le moteur de transformation XSLT Apache Xalan et son module de sérialisation sont retirés de la livraison, au profit du moteur équivalent fourni par le langage. Ils étaient embarqués sans qu’aucun composant de l’application ni aucune autre bibliothèque ne les appelle, mais leur seule présence suffisait à les substituer au moteur du langage pour toutes les transformations XSLT : génération des documents PDF, et écriture des fichiers des interfaces d’échange XML. L’équivalence a été vérifiée modèle par modèle, les vingt-trois modèles de document livrés produisant le même document avec l’un comme avec l’autre moteur ; le contrôle correspondant est conservé dans le produit. Les catalogues de formation et les deux modèles de facture avaient été ajustés au préalable pour ne plus dépendre de constructions propres à ce moteur, sans changement dans les documents produits. Conséquence pour les clients qui impriment un catalogue de formation : le paramètre « Sécurité - Restriction XSLT » devait jusqu’ici être positionné à NON, le moteur retiré refusant sous cette restriction les instructions de mise en page des documents ; il peut désormais être remis à OUI. Le parc livré passe de 107 à 105 bibliothèques.

Point technique de maintenance des bibliothèques, sans changement visible.

EO14 : Les deux services web entrants disposent d’une définition OpenAPI 3.1 en ressource statique : eSedit entrant (“/openapi/wsDataSump.yaml”) et services intranet (“/openapi/wsIntranet.yaml”) ; fonctionnement inchangé [Pas de Mantis]

Les deux services web entrants disposent désormais d’une définition OpenAPI 3.1, servie en ressource statique : le WebService eSedit entrant (“/openapi/wsDataSump.yaml” — activation, clé d’accès, codes retour et structure du document XML attendu) et les services intranet (“/openapi/wsIntranet.yaml” — historique des emplois NexSIS, synchronisation des visites médicales, requêtes API et validations en attente, avec pour chaque ressource son activation, son mode d’authentification et ses schémas d’échange). Ces définitions documentent le fonctionnement existant, sans le modifier

Point technique : documentation des services web à destination des intégrateurs.

EO15 : Fiabilisation de l’application automatique de la structure de la base aux montées de version : valeurs par défaut obsolètes retirées, traitements de fond différés jusqu’à la fin de l’application, suivi séparé par client [Pas de Mantis]

Fiabilisation de l’application automatique de la structure de la base lors des montées de version. D’une part, lorsqu’un champ obligatoire assorti d’une valeur par défaut devient facultatif sans valeur par défaut, cette ancienne valeur par défaut est désormais retirée de la base : elle continuait jusqu’ici d’être enregistrée à chaque création de fiche ne renseignant pas le champ, alors que celui-ci était bien devenu facultatif. La vérification compare maintenant la valeur par défaut réellement présente en base, ce qui rattrape aussi, au premier passage, les champs déjà devenus facultatifs dont la valeur par défaut n’avait pas suivi. D’autre part, aucun traitement de mise à jour des données ne peut plus se lancer pendant l’application de la structure : au démarrage, la structure est désormais appliquée avant le lancement des traitements de fond ; les recalculs (progressions d’UV, taux de FMA, planning de formation) sont reportés à leur passage suivant, et les autres traitements de fond attendent la fin de l’application. Cela évite les verrous très longs observés lorsqu’un recalcul démarrait pendant le remplacement d’index par des clés étrangères. En multi-clients, l’application de la structure est suivie séparément pour chaque client : celle d’une base ne bloque plus, ni ne fait sauter, celle d’une autre. Enfin, le serveur MCP tient compte de ces mêmes informations : pendant une application de la structure, ses requêtes sont refusées immédiatement avec un message explicite, au lieu d’attendre la levée des verrous, et la description des champs d’une entité indique désormais si le champ est obligatoire et sa valeur par défaut éventuelle.

Point technique concernant les montées de version.

EO16 : Refonte de l’écran « Outils > Notifications > Courriels » en deux volets : liste filtrable des notifications groupées par module à gauche, vue d’ensemble ou fiche complète (statut, modèle, récipiendaires, pièces jointes, requêtes) à droite [Pas de Mantis]

Refonte de l’écran « Outils > Notifications > Courriels », sur le modèle des écrans « Outils > Droits > Rôles » et « Outils > Optimisation BD ». L’écran se présente désormais en deux volets : à gauche, la liste filtrable (et redimensionnable) des notifications, chacune avec sa pastille d’état, son libellé, son code et son modèle de courriel, qui reste visible pendant le défilement de la partie droite ; à droite, la vue d’ensemble ou la fiche de la notification choisie. Les notifications sont regroupées par module concerné (Général, Temps de travail, GPEC, Entretiens, Recrutement, Formation, Formation - Commercialisation…), les notifications personnalisées formant un groupe à part, placé en dernier. Les blocs de l’écran reprennent la présentation standard de l’application, dont le repli mémorisé pour chaque utilisateur. La vue d’ensemble présente un bloc par groupe (nombre de notifications et nombre de notifications actives), où le statut et le modèle de courriel restent modifiables directement, ainsi que le bouton « Désactiver tout ». La fiche d’une notification regroupe son libellé, son statut (choisi par boutons segmentés), son modèle de courriel, ses récipiendaires automatiques par emplacement (chacun supprimable par un bouton), l’ajout d’un récipiendaire, les documents joints et les requêtes associées ; ces éléments sont désormais toujours affichés, quel que soit le statut de la notification, y compris pour une notification encore jamais paramétrée (son paramétrage est alors créé, au statut « Désactivée », à l’ouverture de sa fiche par un utilisateur disposant du droit de modification, sans effet sur les envois). Une notification personnalisée se crée depuis le bouton « Nouveau » de la liste, et se supprime depuis sa fiche. Le libellé d’une notification se modifie désormais depuis sa fiche uniquement. Au passage, l’affichage est accéléré (la liste des modèles de courriels n’est plus relue pour chaque notification), l’écran est rendu plus accessible (alternatives textuelles des pastilles d’état, étiquettes des champs, blocs repliables utilisables au clavier) et une notification personnalisée supprimée disparaît immédiatement de la liste.

Vue d’ensemble :

Fiche d’une notification :

EO17 : Nouveaux « Sur écran » « Livret individuel - Détails carrière » et « - Détails agent » (Outils > Droits > Requêtes LIF) pour afficher des informations de l’agent ou de sa carrière dans le livret individuel en consultation [Mantis #11925, #15760]

Ajout des “Sur écran” “Livret individuel - Détails carrière” et “Livret individuel - Détails agent” permettant d’afficher des informations de l’agent ou de sa carrière dans les écrans de consultation du livret individuel (“GRH / Général > Livrets individuels > Détails des livrets individuels / agents” et “Libre-service / Général > Mon Livret individuel > Détails livret individuel”) dans l’écran “Outils / Général > Droits > Requêtes LIF”

EO18A : Requêteur, « Outils > Requêteur > Création de Requête » : champs techniques masqués par défaut (réaffichables), recherche sur les libellés des tables et des champs, saisie des conditions adaptée au type du champ (calendrier, liste, oui/non), signalement des tables non reliées et résumé en libellés métier à chaque étape. Requêtes existantes inchangées. [Pas de Mantis]

Outils > Requêteur > Création de Requête : recherche des tables sur leur libellé (ici « carri ») :

Sélection des champs : les champs techniques (clés, colonnes d’audit) sont masqués par défaut et peuvent être réaffichés ; recherche d’un champ par son libellé :

EO18B : Requêteur : nouvelle étape « Sujets métier ». L’utilisateur choisit un sujet (67 livrés, selon les modules actifs), coche les champs, renseigne les filtres, et la requête est construite pour lui dans son périmètre de gestion. Elle reste une requête ordinaire, rouvrable dans l’assistant ; la date ou la période est demandée à chaque exécution. [Pas de Mantis]

Nouvelle étape « Sujets métier » : les sujets sont regroupés par domaine, avec une recherche :

Un sujet choisi : champs à afficher à cocher, filtres facultatifs, puis « Construire la requête » :

EO18C : Requêteur : une saisie demandée à l’exécution et citée plusieurs fois dans une requête (ex. une date de situation) n’est plus demandée qu’une fois et s’applique à toutes ses occurrences. [Pas de Mantis]

À l’exécution d’une requête construite sur le sujet « Grade et affectation à une date », la date de situation, utilisée par plusieurs conditions, n’est demandée qu’une fois :

CO01 : Correction des raccourcis « Administration » (clé à molette à côté d’une liste déroulante) : 41 adresses erronées corrigées ou retirées, dont un seul cas visible (générateurs de mouvements de la Paie DGFIP). Aucun droit ni écran modifié [Pas de Mantis]

Correction des raccourcis « Administration » des écrans de saisie — le bouton en forme de clé à molette qui, à côté d’une liste déroulante, ouvre l’écran où se gère la donnée proposée. Le contrôle systématique de ces raccourcis a relevé 41 adresses erronées : adresse vide, adresse incomplète, ou adresse désignant un onglet qui ne gère pas la donnée concernée. Un seul cas était réellement visible : dans « Paie / DGFIP > Administration > Paie DGFIP > Générateurs », le raccourci placé à côté du numéro de schéma des générateurs de mouvements rouvrait dans un nouvel onglet l’écran sur lequel l’utilisateur se trouvait déjà — il est supprimé. Les quarante autres adresses ne produisaient aucun bouton, faute d’écran existant à l’adresse indiquée ou de saisie proposant la donnée : elles sont corrigées vers l’écran réel lorsqu’il en existe un (pré-requis de stage, cycle de travail d’un agent, lignes de détail d’un devis — ces dernières reçoivent au passage la mention « administrable par écran de liste » qui leur manquait, l’écran qui les déplie en étant bien un), et retirées lorsque la donnée n’est administrée par aucun écran (base de paie DGFIP, résultats de calcul de paie interne, cotisations de protection sociale, équivalences de droits, ordre personnalisé des boutons). Dans ce dernier cas, la mention « administrable par écran de liste » portée par ces données, qui annonçait un écran inexistant, est retirée également. Aucune donnée, aucun droit et aucun autre écran n’est modifié

Point technique de renforcement de la sécurité.

CO02 : MySQL/MariaDB : les tables créées automatiquement reprennent le jeu de caractères et la collation de la base, évitant les erreurs de mélange de collations ; les tables déjà créées différemment restent à convertir à la main [Pas de Mantis]

Correction de la création automatique des tables sous MySQL/MariaDB (application de la structure de la base) : le jeu de caractères des nouvelles tables était imposé par l’application et pouvait différer de celui du reste de la base selon la version du serveur (tables créées en utf8mb3 ou utf8mb4 dans une base qui ne l’est pas), ce qui provoquait des erreurs de mélange de collations dans certains écrans et obligeait à convertir les tables à la main. Les tables créées reprennent désormais le jeu de caractères et la collation des tables déjà présentes dans la base (à défaut, sur une base neuve, ceux par défaut de la base). Les tables déjà créées avec un jeu de caractères différent restent à convertir manuellement. Sans impact sous Oracle.

Point technique concernant les bases MySQL / MariaDB.

CO03 : Interface d’export des membres du CESE : le pays du lieu de naissance provient désormais de la Nationalité (donnée reliée au référentiel), et non plus du champ « Pays de naissance » en saisie libre, pour un libellé toujours normalisé. [Mantis #18876]

Point technique concernant le fichier produit par l’interface.

CO04 : Historique de l’écran « Outils > Audits > Audit des Sessions » : il restait vide car il lisait un ancien nom de journal ; il relit désormais les fichiers datés, et chaque client ne consulte que ses propres sessions [Pas de Mantis]

Correction de l’historique de l’écran « Outils > Audits > Audit des Sessions » : il indiquait toujours « Aucun fichier historique pour le moment », car il cherchait le journal des sessions sous son ancien nom alors que celui-ci est écrit depuis la version 3.39 dans des fichiers datés. L’historique relit désormais l’ensemble de ces fichiers, ce qui reconstitue aussi les sessions ouvertes avant un redémarrage du serveur et fermées après, et reconnaît les ouvertures de session quel que soit le jeu de caractères du serveur. En multi-clients, chaque client ne consulte que l’historique de ses propres sessions

CO05 : Interface d’export des membres du CESE : les rubriques à date de fin (bureau, collège/groupe, affectations) cessent d’être reprises dès le jour de leur date de fin, et non plus le lendemain. [Mantis #18875]

Point technique concernant le fichier produit par l’interface.

CO06 : Interface d’export des membres du CESE : correction de l’encodage du fichier (désormais en UTF-8 conforme à sa déclaration), qui le rendait invalide en présence de caractères accentués. [Mantis #18875]

Point technique concernant le fichier produit par l’interface.

CO07 : MySQL/MariaDB : l’application de la structure de la base ne s’interrompt plus quand une session de formation annulée porte un utilisateur supprimé depuis ; l’auteur de l’annulation n’est repris que pour les utilisateurs existants, comme sous Oracle [Pas de Mantis]

Point technique, sans illustration.

CO08 : Correction de l’écran « Outils > Personnalisations > Champs supplémentaires » : la modification d’un champ existant (libellé, type, longueur…) renommait le dernier champ créé au lieu de mettre à jour le champ modifié. [Pas de Mantis]

Outils > Personnalisations > Champs supplémentaires : modification du premier des deux champs créés (valeur maximale et unité) :

La modification est appliquée au champ modifié ; le dernier champ créé reste inchangé :

CO09 : « Outils > Personnalisations > Champs supplémentaires » : une valeur par défaut incompatible avec le type (texte pour un entier, date mal formée…) ou une longueur hors de 1 à 100 est refusée avec un message ; une telle valeur déjà saisie n’empêche plus la mise à jour de la structure au démarrage [Pas de Mantis]

Outils > Personnalisations > Champs supplémentaires : un champ entier enregistré avec une valeur par défaut non numérique est refusé, avec le message indiquant le format attendu :

Outils > Personnalisations > Champs supplémentaires, ajout d’un champ : l’infobulle de la valeur par défaut rappelle le format attendu selon le type :

CO10 : Synchronisation des profils avec l’annuaire LDAP : les recherches sont désormais paginées, ce qui lève la limite de 1000 entrées d’Active Directory (au-delà, la liste était tronquée sans message et des comptes pouvaient être désactivés à tort). Si l’annuaire tronque malgré tout, aucun compte n’est désactivé et un avertissement est journalisé. [Pas de Mantis]

Point technique, sans illustration.

CO11 : Synchronisation des utilisateurs vers l’annuaire LDAP : renseigner le paramètre « LDAP+ - Attribut : ORGANIGRAMME NIV 0 » faisait échouer la préparation des attributs de chaque agent. Ce niveau publie désormais le service de l’agent ; les niveaux 1 à 5 sont inchangés [Pas de Mantis]

Point technique, sans illustration.

Application mobile

EM01 : L’API de l’application mobile dispose d’une définition OpenAPI 3.1 (“/grpc?getOpenApi”), consultable avec les outils standard (Swagger UI, Redoc…), à côté de la définition Protobuf ; comportement de l’API inchangé [Pas de Mantis]

L’API de l’application mobile dispose désormais d’une définition OpenAPI 3.1 consultable avec les outils standard (Swagger UI, Redoc, générateurs de clients). Elle est servie par l’application elle-même sur la ressource “/grpc?getOpenApi”, au même titre que la définition Protobuf existante (“/grpc?getProto”) : opérations, paramètres, schémas de réponse, flux d’authentification par jeton, et schéma de chacun des messages déclarés dans le dictionnaire de données, complétés à la volée avec la version applicative. Le gabarit sans les schémas de messages reste consultable en ressource statique (“/openapi/grpc.yaml”). Sans changement de comportement de l’API

Point technique : documentation de l’API à destination des intégrateurs.

EM02A : Application mobile 2.1 : nouvel écran « Badgeage » pour l’agent lui-même, selon sa règle de badgeage (« Je badge » en e-badge, déclaration datée en mode déclaratif) ; l’entrée n’apparaît pas pour un agent non soumis au badgeage [Mantis #19750]

L’application mobile (version 2.1) propose désormais le badgeage de l’agent pour lui-même, dans un nouvel écran « Badgeage » du menu. L’accès ne dépend d’aucun droit d’écran : il suit la règle de badgeage en vigueur pour l’agent — bouton « Je badge » pour les modes e-badge, déclaration d’un badgeage à une date et une heure saisies (avec commentaire) pour les modes déclaratifs. L’entrée de menu n’apparaît pas pour un agent non soumis au badgeage

EM02B : Le badgeage immédiat est horodaté à l’heure du serveur, jamais à celle du téléphone, comme sur une badgeuse, et il est enregistré validé. Une déclaration part « à valider » par le responsable, sauf pour un agent en déclaratif auto-validé. Les badgeages saisis depuis l’application portent la source « VIRTUALIA/MOBILE » (« VIRTUALIA/PC » depuis le portail) [Mantis #19750]

EM02C : Badgeage mobile : calendrier semaine / mois avec une pastille par journée selon l’état de validation, détail des badgeages d’un jour, déclaration limitée au passé, suppression selon les mêmes règles que sur l’accueil [Mantis #19750]

L’écran s’ouvre sur un calendrier (bande de la semaine, dépliable en mois) : chaque journée badgée y porte une pastille colorée selon son état de validation le plus défavorable (rejeté, puis à valider, puis validé), ce qui permet de retrouver un rattrapage déclaré pour un jour passé et de suivre sa validation. Un appui sur un jour liste ses badgeages avec les informations de la validation des badgeages du portail : jour, heure, sens, état de validation, source et commentaires. Après une déclaration, l’écran se place sur le jour déclaré ; l’application ne propose de déclarer qu’à une date et une heure passées. La suppression, par balayage de la carte ou depuis son menu d’actions, suit les règles du bloc « Badgeage » de l’accueil : possible tant que le badgeage n’est pas validé, ou à tout moment pour un agent en déclaratif auto-validé

EM02D : Hors connexion, le badgeage et la déclaration sont désactivés : une action rejouée à la reconnexion serait horodatée à l’heure de sa reprise et non à celle du geste [Mantis #19750]

EM02E : Une nouvelle ressource de l’API mobile renvoie, pour l’agent connecté et sur une période d’au plus 62 jours, ses journées badgées avec leur nombre de badgeages et leur état de validation le plus défavorable ; une période illisible ou trop longue est refusée [Mantis #19750]

Point technique : nouvelle ressource de l’API mobile.

EM02F : Règles de badgeage (autorisation, saisie, suppression) communes à l’accueil et à l’application mobile, sans changement sur le portail ; l’application reçoit les mêmes libellés traduits [Mantis #19750]

Les règles de badgeage (autorisation, saisie, suppression) sont désormais communes au bloc « Badgeage » de l’accueil et à l’application mobile, sans changement de comportement sur le portail. Les libellés du badgeage (BTN_BADGER_SELF, BTN_BADGER_SELF_DECLARE, NO_BADGE_TODAY, COMM_BADGE, COMM_VALIDE_BDG…) sont transmis à l’application, qui affiche les mêmes traductions que le portail

EM03 : Sur l’écran de connexion de l’application mobile, le client cible peut désormais être recherché en saisissant son nom, avec des suggestions sous le champ ; la liste complète reste accessible [Pas de Mantis]

EM04 : Un agent ayant plusieurs carrières peut désormais en changer directement depuis le menu de l’application mobile [Pas de Mantis]

EM05 : Dans l’application mobile, les listes affichent un aperçu des cartes pendant leur chargement, les actions bénéficient d’animations et d’un retour visuel au toucher, et les notifications de confirmation ont été redessinées pour rester lisibles en thème sombre [Pas de Mantis]

CM01 : Dans l’application mobile, passer un participant d’une séance FMPA en « non validé » sans choisir de motif affichait une erreur, alors que la modification était bien enregistrée : l’application reçoit désormais une confirmation normale [Pas de Mantis]

Application mobile > Gestion des FMPA > participants d’une séquence : actions sur la carte d’un participant (« Marquer en “Valide” », « Marquer en “Echec” »…) :