Les processus de mobilité interne prennent 3+ mois — les talents partent en premier. Un manager propose une mobilité dans une conversation de couloir, RH valide par email, le plan de transition est un schéma sur tableau blanc, et l'avenant est rédigé avec 3 semaines de retard. Résultat : 60 % des mobilités internes sont retardées de plus d'un mois, le manager actuel est pris de court, et l'employé perd confiance dans le processus — et commence à chercher à l'externe.

L'angle paie est douloureux aussi : les changements de salaire liés aux promotions sont communiqués tardivement à la paie, générant 1-2 mois de sous-paiement et des runs de régularisation.

La proposition de mobilité est créée depuis un formulaire structuré avec champs exacts : employee_id (lookup), target_role_title (texte), target_team_id (lookup), target_manager_id (lookup), target_site_code (select : PAR/LYON/MRS/TLS/Remote), effective_date (date), proposed_salary (nombre), proposed_grade (select : IC1-IC5/M1-M3/Dir), mobility_type (select : Promotion/Lateral-move/Geographic/Demotion), transition_required (booléen), current_manager_id (lookup, auto-rempli).

Le workflow est structuré en arbre de décision avec 2 branches (avec-transition, sans-transition) après l'Étape 3, et 7 étapes de bout en bout. Chaque action est ajoutée à la sous-table d'audit timeline_mobility.

• Étape 1 (Start — hiring manager ou RH) : le hiring manager ou RH crée la proposition avec employee_id, target_role_title et effective_date ; le copilote IA vérifie l'éligibilité contre la politique de mobilité (ancienneté >= 12 mois, performance >= note 3, pas de PIP actif).

• Étape 2 (Validation RH) : RH examine la proposition et valide le rôle, proposed_grade et la grille salariale ; le workflow vérifie le budget d'effectifs.

• Étape 3 (email — notifications aux parties prenantes) : le workflow envoie un email à current_manager_id et target_manager_id avec les détails de la proposition ; le manager actuel accuse réception et signale les bloquants. Sous-branche A (avec-transition) : si transition_required est vrai, route vers la branche plan de transition. Sous-branche B (sans-transition) : si transition_required est faux, route directement vers l'entretien pré-affectation.

• Étape 4A (Plan de transition — email) : le manager actuel construit un plan de transition avec l'employé (passation, transfert de connaissances, dernier jour dans le rôle actuel) suivi par le workflow ; le workflow envoie des emails de rappel pour chaque item de passation dû.

• Étape 4B (Entretien pré-affectation — email) : le workflow planifie l'entretien pré-affectation entre l'employé, le manager actuel et RH via email ; les retours sont capturés dans le dossier.

• Étape 5 (usePDF — avenant) : le workflow rédige l'avenant au contrat via usePDF avec target_role_title, proposed_grade, proposed_salary et effective_date ; RH et le représentant légal valident.

• Étape 6 (Signature employé) : l'avenant est envoyé à l'employé pour signature électronique eIDAS qualifiée ; le workflow suit le statut.

• Étape 7 (useArchive) : l'avenant signé est archivé chiffré via useArchive pour la durée légale de 50 ans, rattaché au dossier employé, indexé par employee_id, effective_date, mobility_type.

Les organisations qui déploient la mobilité interne Utilyx réduisent le délai mobilité-date d'effet de 3+ mois à moins de 3 semaines, éliminent les sous-paiements de paie sur les promotions via notification email automatique à la paie, et doublent leur taux de mobilité interne — améliorant directement la rétention des talents qui partiraient sinon.

Le copilote IA vérifie l'éligibilité et rédige l'avenant, le designer visuel no-code permet à RH d'ajuster la politique de mobilité, la chaîne de validation et le template de plan de transition, et la signature eIDAS rend l'avenant juridiquement opposable dès jour 1.