Personnel, services et temps de travail

L’administration du personnel saisit un contrat une seule fois. La planification et le collaborateur en obtiennent automatiquement la vue actuelle dont chacun a besoin.

Le profil du collaborateur, l’emploi, la version du contrat, l’affectation, l’attestation de compétence, la délégation et le profil de règles doivent constituer des objets distincts dépendant du temps. L’entrée et la sortie, les modifications du taux d’activité, plusieurs sites et plusieurs contrats simultanés peuvent être représentés.

Les numéros de personnel et les identifiants externes de systèmes de paie sont des attributs avec une provenance ; ils ne remplacent pas un UUID. Le rattachement à l’identité de la plateforme suit un processus contrôlé. Aucun regroupement automatique sur la base d’une adresse e-mail identique ou de noms similaires.

Les qualifications comprennent le type, la référence du justificatif, l’organisme émetteur, l’intervalle de validité et la personne de contrôle. Statut : soumis → vérifié → valide ; rejeté, expiré et révoqué restent différenciables. Seuls les responsables métier compétents confirment les compétences.

Les profils contractuels et réglementaires comprennent le fuseau horaire, la base du temps de travail prévu, le calendrier, le taux d’activité, le type de compte de vacances, les services autorisés, les règles de repos et de travail, l’effectif minimal et les objectifs souples, avec unités et sources. Les règles peuvent concerner une personne, un contrat, un site et une période. Les conflits ou l’absence de règle de priorité doivent être visibles et bloquants.

Les versions de règles suivent les étapes brouillon → vérifié sur le plan métier → validé → remplacé. Les modifications rétroactives créent une nouvelle version et un aperçu de leurs effets ; les validations historiques conservent l’état des règles qui s’appliquait alors.

La disponibilité temporelle cumulée d’une personne doit pouvoir être vérifiée entre contrats, dans la mesure où ces emplois sont gérés dans cette organisation. Les activités externes sont prises en compte uniquement au moyen d’indications de disponibilité nécessaires au métier et recueillies légalement ; le produit ne prétend pas connaître les données d’autres employeurs.

Les besoins de couverture validés, le contrôle de capacité et le port commun de contrôle de capacité doivent fournir le cœur commun de vérification des capacités et qualifications. Il traite les besoins approuvés, les compétences disponibles, les blocages confirmés et l’état connu du plan publié, protège transactionnellement la révision de périmètre et de période, et ne valide pas un contrôle dont les bases de besoins manquent. Les modifications issues de B/C/D actualisent la même révision ; les bases des décisions passées restent conservées.

Gérer séparément la formation initiale et continue, les compétences par tâche, l’autorisation de service par site et l’expérience. Le type de service, son autorisation et l’étendue de l’affectation définissent les services et lieux autorisés ; les modèles M06-D référencent le type de service. L’expérience effective de service utilise le contrat source M06-G défini en amont, mais n’accorde aucune autorisation. Le point d’accès commun de vérification de l’admissibilité aux services traite les instantanés actuels des sources autorisées ; les blocages de protection provisoires actifs de C sont aussi contraignants que les blocages confirmés.

Responsabilité

Le libre-service permet de consulter ses propres informations validées et de soumettre des justificatifs. Les RH gèrent les contrats. Les responsables métier approuvent les compétences. Les personnes qui approuvent les règles doivent être autorisées pour le périmètre concerné. Un administrateur RH ne peut pas s’attribuer une compétence clinique.

Automatisation et IA

Alerte d’expiration des justificatifs et des contrats avec responsabilité et escalade. L’IA peut proposer des champs à partir de documents téléversés avec autorisation ; l’original, les valeurs extraites et la confirmation humaine restent liés. Aucune reconnaissance automatique d’une qualification. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

Chaque collaborateur peut demander ses vacances lui-même et comprendre l’effet de la demande et de la décision sur son solde disponible.

Le compte de vacances, ses écritures, la demande, la décision et l’annulation de vacances retracent les droits, le report, les corrections approuvées, la réservation et la consommation. Les soldes sont reproductibles à partir d’écritures versionnées ; aucun champ de total n’est écrasé sans journalisation.

La vue personnelle distingue le droit acquis ou calculé à l’avance selon les règles, les vacances déjà approuvées, les demandes enregistrées, les vacances prises et le solde restant. Les projections futures doivent être identifiées comme telles. Un même événement ne doit jamais générer deux écritures de solde.

La demande prend en charge les journées entières, les demi-journées ou heures autorisées par contrat, plusieurs périodes, plusieurs contrats, les commentaires à visibilité limitée et la représentation. Les week-ends, jours fériés, temps partiels, horaires irréguliers et changements d’année sont évalués selon le profil valide.

Statut : brouillon → soumis → en cours d’examen → approuvé | rejeté ; les demandes soumises peuvent être retirées. Les demandes approuvées sont modifiées exclusivement via un processus distinct et motivé d’annulation ou de modification. La décision initiale reste conservée.

L’approbation vérifie de manière atomique le solde actuel, les demandes qui se chevauchent, les conséquences sur la capacité et les qualifications et la version des règles. Si une décision nécessaire à la planification manque, la demande reste ouverte. Une demande n’est jamais approuvée du seul fait de l’expiration d’un délai.

Les vacances approuvées sont transmises à la planification comme indisponibilité impérative. Un nouveau calcul du solveur ou un manque de personnel à court terme ne doit pas les annuler silencieusement. Les modifications ultérieures nécessaires exigent un processus distinct autorisé sur le plan métier.

L’entrée, la sortie, les changements de taux d’activité, les reports et les expirations suivent des règles versionnées et validées par les responsables métier. Une règle manquante ou un solde incertain entraîne une vérification par le personnel compétent, et non une estimation par l’IA.

Responsabilité

Le collaborateur traite ses propres brouillons et demandes et consulte son solde. Les approbateurs nommés voient uniquement les données de capacité et de compte nécessaires. Les écritures correctives nécessitent des droits distincts et une validation indépendante selon le profil de risque. Les collègues voient au maximum l’absence autorisée, sans les motifs de demande ni les soldes.

Automatisation et IA

Précontrôle de l’exhaustivité, des conflits et du solde ; rappels et escalade vers un remplaçant ; proposition de périodes alternatives selon la capacité validée. L’IA peut convertir « trois jours la première semaine de juillet » en un brouillon de dates à confirmer. En cas d’ambiguïté, elle demande des précisions ; aucune décision automatique sur les droits ou l’approbation. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

Les collaborateurs gèrent eux-mêmes leur disponibilité. La planification identifie immédiatement les indisponibilités contraignantes et les souhaits à prendre en compte dans la mesure du possible.

Les règles de disponibilité, exceptions, souhaits et décisions de disponibilité distinguent explicitement : un souhait souple, par exemple avoir congé, une indisponibilité déclarée encore à vérifier, un statut de protection provisoirement contraignant, un blocage impératif confirmé et une disponibilité contractuelle fixe. Une saisie personnelle quelconque n’acquiert pas automatiquement le rang d’un blocage légal. Pour la déclaration « Service de nuit impossible », le processus contraignant de protection et de clarification des restrictions fixes de service s’applique dès la réception confirmée par le serveur ; une clarification manquante n’autorise aucune affectation de nuit.

Les collaborateurs doivent pouvoir saisir, modifier ou soumettre à modification eux-mêmes leur disponibilité ponctuelle et récurrente, leurs souhaits de congé, leurs services préférés et leurs périodes bloquées. Une incapacité de travail aiguë relève du processus M06-F et ne peut pas être traitée comme un souhait de congé rejeté.

Les plages horaires prennent en charge des jours, intervalles partiels, répétitions, exceptions, limites temporelles et le fuseau personnel. La vue serveur les traduit sans ambiguïté dans le fuseau de planification. Les heures locales ambiguës ou inexistantes nécessitent une résolution explicite.

Statut du souhait : brouillon → soumis → pris en compte | partiellement pris en compte | non pris en compte | retiré. Statut de l’indisponibilité : signalée → protégée provisoirement si nécessaire → vérifiée → confirmée | levée ou refusée avec motif ; la modification d’une indisponibilité confirmée reste traçable séparément. Une indisponibilité objectivement impérative reste protégée selon le processus réglementaire applicable, même sans approbation du souhait.

Les délais de saisie et de modification ainsi que l’approbation compétente sont versionnés pour chaque période de planification. Après publication du plan, une demande de modification montre les services concernés ; elle n’écrase pas automatiquement leur attribution.

Les priorités et les pondérations des souhaits sont définies de manière transparente. La personne voit lesquels de ses propres souhaits ont été pris en compte et une explication compréhensible fondée sur des règles. Aucun motif privé d’autrui ni classement comparatif nominatif n’est divulgué.

Les conflits entre contrat, vacances approuvées, blocages et souhaits nécessitent des règles de priorité définies. Le statut « disponible » ne peut pas annuler des vacances approuvées. Les répétitions sont évaluées dans des périodes de planification finies ; une expansion illimitée ne doit pas bloquer le service.

Les préférences personnelles de service comprennent la date ou le jour de la semaine, le type de service, l’ordre de préférence, éventuellement le site, la durée de validité et les exceptions. Les exceptions datées priment sur les schémas récurrents ; les indisponibilités impératives priment sur tous les souhaits. « De préférence pas de nuit » et « Impossible de nuit » sont des types de saisie distincts, avec des conséquences différentes. Une indisponibilité de nuit active n’est pas levée par une expérience du travail de nuit, une ancienne préférence ou un manque de personnel.

Responsabilité

Les collaborateurs gèrent leurs propres données ; la planification les vérifie dans son périmètre. Les motifs privés sont facultatifs ou saisissables uniquement en cas de nécessité métier, et sont protégés séparément. Le système n’impose aucun texte médical libre pour déclarer un blocage.

Automatisation et IA

Les règles récurrentes évitent les saisies mensuelles. Rappel avant l’échéance, affichage des conflits lors de la saisie. L’IA peut structurer un souhait exprimé oralement et expliquer sa différence avec un blocage impératif ; le collaborateur confirme le type et la période. Le solveur reçoit des données structurées vérifiées, et non un texte de souhait librement interprété. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

Les besoins, compétences et disponibilités donnent lieu à une proposition de planning admissible ; la personne responsable de la planification vérifie et publie des modifications compréhensibles.

La période de planification, le modèle de service, le service, l’affectation au service, la révision du planning, l’état des règles et le calcul décrivent le planning et les bases de décision. Les besoins en effectifs approuvés et la révision commune des capacités proviennent de M06-A ; D ne dispose pas d’une seconde base de besoins concurrente. Les effectifs minimaux et la composition des qualifications sont définis par intervalle de temps, et pas seulement comme nombre de personnes par jour.

Statut : brouillon → calculé → vérifié → publié → remplacé/clôturé. Le résultat d’un solveur est une proposition versionnée. Les modifications des plans publiés créent une nouvelle révision à valider avec un écart identifiable et une notification aux personnes concernées.

Le calcul de planification séparé reçoit des données structurées minimales et, autant que possible, pseudonymes. Il fournit les affectations, les versions des règles et objectifs, la configuration d’exécution, la graine si elle est prise en charge, le statut du résultat et des conflits vérifiables. « Optimal », « admissible dans le délai », « impossible à résoudre » et « aucun résultat » sont distingués.

Le cœur métier vérifie à nouveau chaque affectation proposée ou saisie manuellement selon les règles impératives. Les résultats de calcul manipulés, périmés ou non conformes sont refusés. Le solveur et l’interface utilisateur ne peuvent accorder aucune dérogation.

Les souhaits, la répartition équitable des services pénibles, la continuité et un faible nombre de modifications sont gérés comme objectifs souples approuvés avec une pondération traçable. L’équité est vérifiée selon des critères et des périodes définis ; les motifs privés liés à la santé ou les caractéristiques protégées ne constituent pas un objectif d’optimisation improvisé.

Avant publication, le système vérifie toute la période concernée, les périodes de repos transversales, les autres contrats de la même personne, la validité des compétences, les vacances, les blocages et les révisions actuelles. Une violation de règle impérative bloque la publication. Une impossibilité de résolution produit un besoin de couverture précisément décrit, sans affaiblissement silencieux des règles.

La publication garantit une révision cohérente du plan et des affectations dans une transaction. Le processus commun de modification pour les échanges et remplacements doit proposer des modifications multiples atomiques avec les révisions attendues des services, des affectations et des règles.

Les aperçus doivent montrer les personnes et services modifiés ainsi que les notifications générées. L’envoi d’une notification push n’est pas un accusé de réception. Les prises de connaissance requises possèdent leur propre statut et leur propre escalade.

Responsabilité

La planification gère les secteurs attribués ; la publication nécessite une action distincte. Le collaborateur voit ses propres services et la vue d’équipe approuvée. Le service de résolution ne dispose d’aucun droit de publication ni d’accès aux documents RH.

Automatisation et IA

Planification par règles, replanification incrémentale en cas de modification de la disponibilité, explication des conflits et notifications. L’IA peut rendre l’explication déjà calculée plus compréhensible ; la cause contraignante et les chiffres proviennent du vérificateur de règles. La planification manuelle reste possible en cas de défaillance de l’IA ou du solveur et est soumise aux mêmes contrôles. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

Les collaborateurs trouvent eux-mêmes une solution autorisée pour un échange de service ou proposent leur aide pour les services ouverts, sans que la planification doive transférer les indications plusieurs fois.

L’offre d’échange, l’accord, le service vacant, la candidature et la décision distinguent l’échange réciproque, la cession proposée d’un service et la candidature à un service vacant. Une disponibilité déclarée n’est pas encore une affectation engageante.

Statut de l’échange : brouillon → proposé → accepté par les deux parties → vérification → approuvé/exécuté | refusé | expiré | retiré. Pour les services ouverts : ouvert → candidatures → sélection/vérification → attribué définitivement | clôturé. Un retrait après exécution nécessite une nouvelle modification.

Les deux personnes concernées acceptent la paire de services concrète et la révision. Une modification d’un service, d’une personne ou de la période invalide les anciens accords. La validation requise par la direction suit le profil d’exploitation versionné.

L’exécution définitive doit vérifier les deux affectations, leurs temps de travail et de repos, les compétences, les chevauchements et la couverture minimale selon l’état actuel, et les modifier dans une transaction. Toutes les affectations concernées sont enregistrées avec audit et outbox, ou aucune ne l’est.

Plusieurs offres ou candidatures ne doivent pas engager plusieurs fois une même personne ou un même service vacant. Une confirmation définitive invalide les offres concurrentes avec un statut et une notification traçables.

Les propositions prennent uniquement en compte les personnes disposant de la compétence requise et d’une visibilité publiée pour les contacts ou les offres. Les collaborateurs ne voient ni les motifs privés d’indisponibilité ni les dossiers complets du personnel des partenaires d’échange potentiels.

Responsabilité

Un collaborateur propose uniquement ses propres services échangeables et confirme uniquement pour lui-même. Une représentation temporaire doit autoriser explicitement l’action concernée et reste identifiable. La planification décide dans le périmètre attribué ; personne ne valide son propre échange.

Automatisation et IA

Propositions de partenaires et de services vérifiées par règles, nouvelle vérification automatique, rappel avant l’expiration de l’offre et clôture des offres terminées. L’IA explique les alternatives autorisées à partir des données accessibles. Aucune candidature engageante ni affectation automatique au nom du collaborateur. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

Une indisponibilité signalée est immédiatement visible par les bons responsables et déclenche une recherche contrôlée de remplacement ainsi que la transmission des tâches ouvertes.

Le signalement d’absence, l’information confidentielle sur l’absence, le service concerné, le cas de remplacement et la décision d’affectation distinguent la période d’absence, les informations confidentielles, les services concernés et la décision de remplacement. Statut : signalée → réception confirmée → traitée par le responsable compétent → clôturée ; le statut de remplacement est indépendant : besoin ouvert → en cours de traitement → pourvu | non pourvu/escaladé.

Un collaborateur doit pouvoir déclarer et actualiser sa propre absence de dernière minute ; une personne autorisée à le représenter peut documenter une déclaration téléphonique avec l’heure réelle de déclaration et la personne qui l’a saisie. Le traitement d’une déclaration ne constitue pas une évaluation médicale de la capacité de travail.

La vue d’exploitation montre immédiatement les services publiés et les exigences de couverture minimale ou de compétence pouvant être concernés. Une indisponibilité confirmée n’est pas ignorée au motif qu’aucun remplacement n’est encore disponible. Les informations non confirmées conservent un statut de contrôle visible.

Le service responsable confirme la prise en charge ; en l’absence d’accusé de réception, le dossier est transmis à un remplaçant après un délai versionné. L’envoi d’une notification push ne clôt pas le dossier. En l’absence de connexion, l’application indique le canal de signalement opérationnel validé et ne doit pas présenter un brouillon local comme une annonce de maladie transmise.

Les propositions de remplacement doivent respecter les compétences, les temps de repos, les autres services et les absences confirmées. Une nouvelle affectation utilise le contrat de planification de D, avec une vérification à jour, les accords nécessaires et une validation. Aucun cas de remplacement ne débloque automatiquement des vacances ou ne modifie des indisponibilités fixes.

L’interface vers les modules de tâches et de transmission fournit uniquement la référence à l’absence, la validité et la responsabilité nécessaire. Les tâches métier non délégables sont transmises au niveau compétent ; elles ne sont pas attribuées aveuglément à un remplaçant quelconque. La transmission et le service de remplacement disposent de preuves d’achèvement distinctes.

Le retour, la prolongation et la correction d’une erreur produisent de nouvelles révisions traçables. Un service de remplacement n’est pas supprimé automatiquement au retour ; la planification concernée vérifie la modification.

Responsabilité

Signalement personnel ; la planification reçoit la période et le besoin. La cause confidentielle et les justificatifs sont réservés à une fonction RH spécifiquement autorisée. Les documents médicaux n’apparaissent ni dans le planning ni dans la transmission des tâches.

Automatisation et IA

Identifier les services concernés, vérifier les règles, proposer des candidats de remplacement adaptés, préparer l’escalade et les tâches de transmission autorisées. L’IA peut produire une vue d’ensemble de la transmission à partir des tâches autorisées ; elle ne prédit pas une maladie et n’évalue pas la crédibilité. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

Les collaborateurs documentent leur temps de travail réel en quelques étapes ; les écarts sont vérifiés de manière traçable, sans présenter les services planifiés comme du temps effectué.

La saisie de temps, la pause, la correction de temps, la feuille de temps, la validation de temps et la base de supplément comprennent le temps réel, les pauses, le lien avec le plan et les caractéristiques de temps exportables. La présence, le temps de travail, la disponibilité et les vacances sont évalués comme catégories distinctes uniquement selon le profil approuvé.

Le démarrage et l’arrêt sont possibles dans les canaux validés lorsque la politique de l’organisation est activée ; la saisie ultérieure approuvée reste disponible. Heure de saisie, période effective, source et auteur restent distincts. Aucun travail effectué n’est automatiquement affirmé sur la seule base d’un planning, d’une confirmation push ou d’une application ouverte.

Statut : brouillon → soumis → en vérification → validé | à corriger ; la correction d’un temps déjà validé crée une nouvelle révision avec motif et nouvelle validation. L’original et sa validation d’époque sont conservés.

Le serveur vérifie les saisies qui se chevauchent, les intervalles négatifs ou trop longs, les pauses, les catégories autorisées, les activités à cheval sur minuit, les contrats multiples, le fuseau horaire et le taux d’activité modifié. Les ajouts nécessaires au métier restent possibles et sont clairement identifiés comme tels.

Les bases de supplément comprennent la période et la catégorie autorisée avec la version des règles ; les montants monétaires et le calcul des salaires relèvent du système de paie externe. Les arrondis et les limites suivent le profil approuvé et sont traçables à l’aide d’exemples.

Le collaborateur peut consulter ses heures, les écarts entre prévu et réalisé, les commentaires de contrôle et l’état de validation, et demander une correction. Les modifications engageantes du temps par les supérieurs doivent être identifiables et ne peuvent être effectuées silencieusement au détriment du collaborateur.

Responsabilité

Saisir et corriger ses propres heures ; les responsables d’approbation compétents les vérifient. Aucune auto-approbation. Un changement de site ou de supérieur ne supprime pas automatiquement la possibilité de vérification historique nécessaire, mais requiert un droit de vérification explicitement limité dans le temps. La saisie du temps ne nécessite pas une surveillance permanente de la localisation.

Automatisation et IA

Rappels pour les saisies en suspens, détection des écarts par règles, proposition de rattachement à un service prévu. Le collaborateur confirme les faits réels. L’IA peut formuler un texte de correction, mais ne peut inventer du temps ni l’ajuster secrètement à une valeur cible. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

L’administration du personnel transmet une seule fois au système de paie les bases de temps entièrement vérifiées et peut traiter de manière ciblée les rejets ou corrections.

La période d’export salarial, l’état d’export figé, les correspondances d’export, le paquet d’export, la preuve de remise et la correction conservent des états immuables des données validées avec les révisions de contrat, de règles, de mapping et de validation.

Statut : ouvert → vérifié → verrouillé → export créé → transmis → confirmé | partiellement rejeté | rejeté. « Fichier généré » ne signifie ni transmission réussie ni acceptation par le système de paie.

La clôture vérifie les validations manquantes, les intervalles de temps contradictoires, les identifiants externes de collaborateur ou de contrat non rattachés et les versions de correspondance. Les périodes de personne ou de contrat incomplètes ne peuvent pas être exportées silencieusement comme complètes. Les clôtures partielles prises en charge doivent être explicitement signalées et approuvées par les responsables métier.

L’export contient exclusivement les bases validées de temps, d’absence et de supplément selon le contrat partenaire. Aucune donnée de résident, diagnostic, certificat médical ou commentaire RH libre. La finalité, le destinataire, le chiffrement et la conservation minimale du fichier exporté sont définis.

Une répétition utilise la même identité de lot et le même instantané. Les destinataires sans idempotence technique nécessitent un processus manuel contrôlé de remise et de rapprochement ; une répétition automatique aveugle ne doit pas déclencher un double traitement.

Les corrections ultérieures génèrent un nouvel export correctif avec référence à l’original. Les fichiers d’export historiques, les accusés de réception et les validations restent inchangés. La réouverture d’une période exige une autorisation distincte, une justification et une nouvelle vérification des justificatifs concernés.

M06 est responsable de l’instantané métier et de la validation des correspondances ; l’interface réelle avec le partenaire utilise le contrat d’intégration M17. Un adaptateur CSV ou API générique sans spécification concrète du partenaire ni réception ne constitue pas encore une connexion de paie autorisée. Le jeu de caractères, le format décimal, le format horaire et les champs obligatoires suivent le contrat partenaire versionné, et non la langue de l’interface de l’utilisateur exportateur.

Responsabilité

Actions distinctes pour la clôture, l’export, le téléchargement, la livraison et la réouverture. Les droits d’export sont liés au destinataire et au périmètre ; le téléchargement est auditable. Le collaborateur voit son propre temps validé et les éventuelles corrections, sans le lot global.

Automatisation et IA

Contrôle d’exhaustivité, comparaison des écarts et des totaux, remise contrôlée, rappels en cas d’accusés manquants et rattachement des erreurs techniques à des dossiers de traitement. L’IA peut expliquer un message d’erreur autorisé ; les modifications de mapping, validations et corrections restent sous responsabilité humaine. Aucun montant généré par l’IA ni aucun envoi de sa propre initiative. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

Le contenu du contrat, sa signature et sa prise d’effet forment un processus commun avec l’administration du personnel.

Les contrats de travail référencent l’emploi et la version de contrat déjà gérés. Le taux d’activité, les changements de poste, les annexes, les clauses approuvées, les modèles et les versions antérieures restent accessibles ensemble dans le dossier du personnel. Aucun second référentiel de personnel n’est créé en parallèle de M06-A.

Le contrôle interne du contenu, l’invitation à signer, le contrôle complet des preuves et la prise d’effet réelle sont des étapes distinctes. Toutes les signatures requises de l’employeur et du salarié sont recueillies selon la règle de signature autorisée. Une signature encore manquante reste visible comme une conclusion en suspens.

Les collaborateurs reçoivent exclusivement leurs propres documents contractuels validés ; les RH interviennent dans leur périmètre de responsabilité. Les pouvoirs de signature sont vérifiés séparément. La langue du contrat et celle de l’interface utilisateur peuvent différer, tandis que l’original signé reste inchangé.

Une modification du taux d’activité ou du contenu pendant la signature nécessite une nouvelle vérification du document concerné. Les signatures déjà apposées ne sont pas transférées aux clauses modifiées. Les refus, les retraits et les accords remplacés restent traçables.

Les contrats papier suivent le même processus avec des scans vérifiés, les informations sur les signataires et le classement de l’original. La fonction commune de documents et de signature de M12 prend en charge les étapes de signature et les justificatifs ; M06 reste responsable du contrat de personnel et de sa prise d’effet.

Responsabilité

Les RH préparent, les personnes habilitées de l’employeur signent, les collaborateurs vérifient et signent leurs propres documents.

Automatisation et IA

L’IA peut résumer les modifications, signaler les informations manquantes et associer des clauses validées. Les modifications engageantes de clauses et leur acceptation nécessitent une décision responsable. Les fonctions IA nécessitent une activation souhaitée par l’établissement. Le traitement reste sur les propres serveurs d’Oronela en Suisse.

Connexion et mode hors ligne

Les brouillons peuvent être préparés dans le périmètre autorisé. La validation, la signature et la confirmation de prise d’effet s’effectuent en ligne.