La RUI fait circuler les identités, l’engagement réciproque trouve son API
La RUI, Référence Unique d’Identité, permet d’échanger une identité avec l’accord de l’autre partie ; l’engagement réciproque gagne son API et son parcours de saisie ; un service dédié aux documents voit le jour.
Journée charnière : le partage d’identité passe du concept à un parcours complet, demander une identité, l’approuver, la recevoir. L’engagement réciproque se dote de son API et de son parcours de saisie, et un service dédié aux documents ouvre la voie au coffre-fort.
La RUI, de la demande à l’identité reçue
La RUI, Référence Unique d’Identité, n’est plus une intention. Un code se transmet de vive voix, l’autre partie le saisit, approuve le partage, et son identité arrive, sans jamais passer par une recopie à la main. Le principe reste le consentement : le code seul ne donne pas accès au dossier, il ne fait que demander.
Côté comptes, le protocole est mis en œuvre avec les demandes et les invitations dans le même mouvement (PIM-251, PIM-252). Chaque demande fige le code RUI saisi, de sorte qu’une rotation de la RUI ne réécrit pas l’historique, et une demande née d’une invitation porte un code nul. Un renvoi vers un titulaire déjà sollicité ne crée plus de doublon silencieux, l’API signale alreadyPending, et le demandeur peut retirer une demande en attente, ce qui libère la paire et laisse la possibilité de recommencer. L’accès à la demande est tracé au journal d’audit.
Le BFF relaie le protocole (PIM-253) et l’OpenAPI le décrit : le code, alreadyPending, la réponse 200 sur une demande déjà en attente, et l’opération de retrait. L’instantané approuvé se lie ensuite au brouillon de contrat ou d’engagement réciproque (PIM-254) : les créneaux du parent employeur et du co-employeur sont remplis, sans écraser le lien de parenté déjà saisi.
Dans l’application, cette fonctionnalité devient visible (MOBI-166). Mon RUI apparaît sur les profils de l’assistante maternelle et du parent employeur, avec la copie, le partage, la régénération et la mise en pause. Une cloche avec badge ouvre un écran de demandes, pour approuver ou refuser (MOBI-168). Le code s’affiche depuis l’accueil (MOBI-171), un RUI peut être saisi hors parcours guidé (MOBI-172), et le bandeau d’accueil s’allège au profit de l’écran dédié (MOBI-173). Les parcours du contrat et de l’engagement réciproque savent désormais récupérer ou inviter, et le lien d’invitation se rattache au compte après l’inscription (MOBI-169).
L’engagement réciproque trouve son API
L’autre grand chantier du jour, c’est l’engagement réciproque. Il dispose désormais de son API de brouillon, avec la création, la lecture, la mise à jour et la suppression (PIM-241), exposée par le BFF et documentée dans l’OpenAPI (PIM-242). Un contrat ne peut porter qu’un seul engagement (PIM-249) : un second lien est refusé, et supprimer un brouillon de contrat détache l’engagement associé.
L’API se remplit au fil de la journée. L’enfant gagne sa date de naissance (PIM-272), conservée pour un enfant né et purgée, comme le nom de famille, s’il est déclaré à naître. L’accueil devient multiple, avec la date de début du contrat et les rythmes d’accueil (PIM-273) : la durée hebdomadaire exposée est la moyenne pondérée par les semaines d’accueil, et la mensualisation se dérive de chaque volume horaire. Les coordonnées suivent l’initiateur et distinguent le parent employeur du co-employeur (PIM-274). Le salaire change enfin de sens : le net devient le montant saisi, le brut est remonté par le taux de conversion, avec le taux propre au régime local Alsace-Moselle (PIM-275).
Le vocabulaire s’aligne au passage : « date d’effet » devient « date de début du contrat » dans l’API, le document généré et l’application. Un correctif d’infrastructure ferme aussi une plaie ouverte : le cache du service, survivant au montage du dossier de travail, provoquait une erreur 500 au premier appel sur la liste des engagements (PIM-276). Un test de bout en bout en lecture seule verrouille maintenant ce cas (PIM-277).
Le parcours de l’engagement prend sa forme
Côté mobile, le parcours de l’engagement réciproque se construit étape par étape : l’enfant, né ou à naître, avec sa date de naissance (MOBI-160) ; la date de début et les rythmes d’accueil, jusqu’à six volumes horaires et leur répartition en semaines (MOBI-161) ; la rémunération, avec un écran récapitulatif qui met le net mensuel en vedette (MOBI-162) ; et les parties de l’accueil, saisies à la main, récupérées par RUI ou invitées (MOBI-163). La liste des engagements gagne la suppression du brouillon et le rattachement automatique au contrat libre (MOBI-165), puis une tuile unique qui bascule entre l’engagement et son contrat lié (MOBI-167).
Un choix de conception se lit dans les commits : la civilité, Madame ou Monsieur, devient une donnée du profil de l’assistante maternelle et un champ requis de sa complétude. L’étape où l’assistante maternelle ressaisissait ses propres coordonnées disparaît donc du parcours, sa partie est reprise de son profil et enregistrée automatiquement (MOBI-190). Les deux parcours partagent la même logique de collecte d’identité, découpée en un écran de choix puis un écran par mode, avec la RUI qui affiche le code pendant l’attente et permet le retrait.
Un coffre-fort de documents voit le jour
Un nouveau service rejoint la constellation : ms-pimili-document (PIM-247), un socle avec ses propres accès assistante maternelle et parent employeur. MinIO et Gotenberg entrent dans la pile de la passerelle (PIM-246), et la chaîne de génération voit le jour (PIM-248) : un modèle versionné, rendu par Gotenberg, conservé dans MinIO sous forme d’instantané immuable. Une régénération produit un nouvel identifiant, et l’accès est borné aux comptes propriétaires. Les modèles de documents quittent le catalogue figé dans Git et vivent en base, éditables depuis l’administration Pimili avec prévisualisation du rendu (PIM-255).
Correctifs du brouillon de contrat
Deux comportements du contrat ont été rectifiés, avec leurs exigences. La déduction des heures d’absence pour maladie reste pertinente même quand l’enfant malade n’est pas accueilli (PIM-269, MOBI-182), et le choix « pas de 2e employeur » se distingue enfin de « non renseigné » (PIM-270, MOBI-188), sans quoi le contrat ne pouvait pas atteindre 100 %. Le parcours du contrat gagne un récapitulatif des informations saisies (MOBI-185), ses tests se réalignent sur l’ordre réel des étapes, quinze tests étaient rouges sur develop (MOBI-189), et les ombres dépréciées de React Native Web migrent vers boxShadow (MOBI-170).
Socle et outillage
La journée ferme aussi des sujets de fond. Le compte de démonstration de Christelle SALIGNY devient complet, foyer et co-employeur compris, pour tester la symétrie avec le côté assistante maternelle (PIM-256). Les conventions git sont versionnées dans les règles Cursor de tous les dépôts (PIM-263). Le catalogue d’exigences récupère les 43 tags orphelins qui faisaient échouer la vérification (PIM-271). Enfin les routes d’administration des vacances scolaires répondent désormais 401 avant toute validation, pour ne plus laisser filtrer d’information (PIM-208).
Captures
