PeopleOS, un SaaS RH conçu de bout en bout

Le contexte

Les TPE et PME de 10 à 250 salariés gèrent leurs RH avec des outils qui n’ont pas été pensés pour elles : trop lourds, trop chers, ou éclatés entre un tableur, une boîte mail et un logiciel de paie. PeopleOS part d’une intention simple : centraliser le quotidien RH (dossiers salariés, congés, recrutement, onboarding, paie, temps de travail, entretiens) dans une interface qu’une responsable RH et un manager prennent en main sans formation.

Le projet est un concept : il n’y a pas de client derrière. C’est un terrain pour montrer comment je conçois un produit dense, pas seulement un écran d’accueil.

L’objectif

Un SaaS RH dessiné comme un produit fini, pas comme une maquette. Neuf modules côté RH, six écrans côté salarié, trois rôles qui changent réellement ce que l’interface montre, et une application écrite pour être branchée sur une vraie base sans qu’un écran change.

Ma réponse

Côté desktop, pour la RH et les managers : un tableau de bord (indicateurs, courbe d’effectifs, file « à traiter »), les employés (liste filtrable, fiche par onglets, formulaire de création), les congés (planning d’équipe en Gantt mensuel, file de validation avec détection des conflits d’absence), le recrutement (offres ouvertes, pipeline kanban par poste), l’onboarding (arrivées à venir, checklist par période, tâches en retard), la paie (variables du mois, suivi de clôture, anomalies qui bloquent l’export), le temps et la présence (grille hebdomadaire, anomalies signalées dans la cellule), les entretiens (campagnes, avancement de l’auto-évaluation à la signature) et les paramètres (organisation, matrice de permissions, intégrations).

Côté mobile, pour le salarié : l’accueil avec les soldes et les raccourcis, les congés et leur historique, un parcours « poser un congé » en trois étapes avec contrôle du solde, les fiches de paie, le profil et les documents, et pour les managers seulement, la file de validation de l’équipe.

Et une page design system qui documente les choix : palette, typographie, formes, composants, rôles, accessibilité, architecture.

Tout le front d’abord, avec des données simulées cohérentes entre elles : le même salarié apparaît dans le planning, la paie et les entretiens. La date de la démo est figée pour que l’application raconte toujours la même histoire.

Les décisions de design

Une seule couleur d’action

Toute la palette tient en un accent, trois niveaux de gris et trois états (validé, à surveiller, bloquant). Le bleu ne décore jamais : il signale ce sur quoi on peut agir. Sur un produit dense, c’est ce qui permet à l’œil de trouver le bouton sans le chercher.

La densité comme service rendu

Le corps de texte est à 13 px, les titres sont serrés. Un écran RH affiche beaucoup de données ; l’aérer serait confortable pour le designer et pénible pour l’utilisatrice qui doit tout voir sans défiler. La police système d’Apple donne la familiarité d’une application native sans rien télécharger.

L’interface change selon qui regarde

Trois rôles : RH, manager, salarié. Ce n’est pas un affichage conditionnel de surface. Une entrée de navigation disparaît, la colonne des salaires n’est pas rendue, un onglet de validation apparaît sur mobile. Le même principe sera appliqué en base de données quand elle arrivera.

Le mot porte l’information, la couleur la renforce

Une anomalie de paie affiche une icône et une phrase, pas seulement un fond orange. Un daltonien lit la même chose que les autres. Les verts et oranges des états sont volontairement foncés : les teintes vives classiques ne passent pas le seuil de contraste WCAG AA. L’accessibilité a été vérifiée à chaque écran plutôt qu’en fin de projet : contrastes AA partout, navigation clavier complète avec un focus visible jamais supprimé, cibles tactiles de 44 px sur mobile, libellés toujours visibles sur les formulaires.

Refuser demande un motif, valider non

Sur mobile, un manager valide une demande de congé d’un geste, mais un refus ouvre un champ obligatoire. L’asymétrie est volontaire : un refus sans explication est la première cause de contestation d’une décision RH. Dans le même esprit, l’export de paie reste grisé tant qu’un salarié a un mois incomplet ou des heures au-delà du plafond : l’interface empêche l’erreur plutôt que de la signaler après coup.

Une interface prête à être branchée

Le projet s’arrête volontairement au front. Mais il a été écrit comme s’il parlait déjà à une base de données : les écrans ne connaissent que des fonctions asynchrones, jamais les données elles-mêmes. Le jour où la base arrive, on réécrit l’intérieur d’une couche d’accès et aucun écran ne change.

Ce qui a été prévu sans être construit : la base et l’authentification (Supabase, modèle de données déjà typé, rôle lu par le serveur), les métiers délégués (la paie part vers Silae ou PayFit, la signature vers Yousign, les e-mails vers Resend : PeopleOS orchestre, il ne recalcule pas un bulletin de salaire), et les contraintes RGPD (hébergement européen et cloisonnement par rôle prévus dès le modèle, pas ajoutés après).

C’est la partie du projet qui montre qu’un designer front peut parler au développeur qui prendra la suite.