- Projet
- Case study
Développement d'un SaaS RH en React TypeScript : comment j'ai construit une plateforme inclusive où le vrai défi n'était pas le code
Construire un SaaS multi-tenant pour des professionnels RH, avec des parcours de diagnostic interactifs, de la génération automatique de documents et une logique métier que je ne maîtrisais pas du tout au départ. Voilà le résumé de ce projet. Un cabinet de conseil spécialisé en Diversité, Équité et Inclusion avait besoin d'une plateforme RH capable d'accompagner ses clients dans la structuration de leurs politiques salariales. Ce retour d'expérience raconte comment ce projet fullstack React m'a autant challengé sur la compréhension métier que sur l'architecture technique.
Un cabinet DEI qui veut outiller ses clients
Le client est un cabinet de conseil en DEI qui accompagne des entreprises de toutes tailles, de la startup aux grands groupes, dans la construction de politiques inclusives. Audits, processus RH, sensibilisations... leur périmètre est large. Mais face à des exigences légales de plus en plus pressantes (CSRD, Directive européenne sur la transparence salariale) et une demande croissante des talents pour plus de diversité, ils avaient besoin de passer un cap.
L'idée : proposer un outil numérique à ses clients. Pas un simple formulaire en ligne, mais une vraie plateforme capable de guider les équipes RH à travers des parcours de diagnostic transparence salariale, des projets structurés comme la création de grilles salariales, et la génération automatique des rapports documentaires qui en découlent.
Entre contraintes légales et attentes des talents
Le timing n'était pas anodin. Les réglementations européennes poussent les entreprises à structurer et documenter leurs pratiques salariales. Les grands groupes, en particulier, ont besoin d'outils pour se mettre en conformité sans que ça devienne un chantier interminable. La cible étant internationale, le produit devait être disponible en français et en anglais dès le lancement.
C'est ce contexte réglementaire qui donne au produit sa raison d'être. On ne construit pas un outil RH "nice to have" - on répond à une obligation légale que beaucoup d'entreprises peinent à adresser de manière structurée.
La V0 vibe-codée avec Lovable, et pourquoi on a tout reconstruit
Avant mon intervention, le client avait déjà construit une V0 du produit lui-même, via Lovable, un outil de vibe coding, avec Supabase en backend. Cette V0 a été précieuse comme preuve de concept. Elle a permis de valider la vision produit et de cristalliser les parcours utilisateur.
Mais coder un produit SaaS destiné à des grands groupes, avec du multi-tenant, de la gestion de rôles, des composants interactifs complexes et de la génération documentaire... ça demande une base solide. L'intégralité du code a été reconstruite from scratch. Seul Supabase a été conservé comme choix technologique, parce que le client le maîtrisait et que l'outil répondait aux besoins d'authentification et de base de données.
Dans ce cas précis, la V0 vibe-codée a été un excellent outil de validation produit. Mais elle n'était pas conçue pour supporter un vrai SaaS en production, et on l'a traitée comme telle.
Faire du RH sans être RH, le vrai défi du projet
Si on m'avait demandé avant ce projet quel serait le plus gros challenge, j'aurais répondu "la technique" par réflexe. Multi-tenant, composants interactifs, génération de documents - des sujets classiques pour un dev expérimenté, rien d'insurmontable. En réalité, le vrai boss de fin, c'était le métier.
S'immerger dans la transparence salariale et les grilles de rémunération
Le monde des ressources humaines est dense. Transparence salariale, critères de pondération, grilles de rémunération, intervalles des emplois, points de grille... chaque concept a ses subtilités, ses implications légales et ses variations selon les entreprises. Et chacun de ces concepts devait être traduit en fonctionnalités logicielles compréhensibles par des utilisateurs non-techniques.
J'ai dû m'immerger dans ce domaine pour comprendre, pas juste ce que le client demandait, mais pourquoi il le demandait. Sans cette compréhension, impossible de concevoir des parcours utilisateur qui tiennent la route.
Poser les bonnes questions plutôt qu'écrire le bon code
"Faire du RH sans être RH" a nécessité un vrai effort d'apprentissage et une communication soutenue avec le client. J'ai vite compris que la qualité du produit final dépendait autant de ma capacité à poser les bonnes questions que de mes compétences techniques.
Un composant de tableau de pondération, par exemple, n'a aucun sens si on ne comprend pas la logique métier derrière les critères qu'on pondère. Un parcours de diagnostic perd toute valeur si les étapes ne reflètent pas la réalité du travail des équipes RH.
"Parfois ce qui est complexe dans un projet, c'est pas la technique mais comprendre le métier." - C'est la leçon numéro un de ce projet, et probablement celle que je retiens le plus.
Les arbitrages produit qui ont façonné la plateforme RH
Une fois le métier mieux compris, il fallait traduire les besoins en fonctionnalités concrètes. Plusieurs arbitrages ont structuré le produit.
Deux parcours, une seule logique - diagnostic et projet
Le produit s'articule autour de deux types de parcours. Le premier, le diagnostic, est un questionnaire interactif structuré en étapes thématiques (communication et transparence, gouvernance et principes, etc.). L'utilisateur répond par oui ou non, chaque étape contribue à un score global. Ça permet à une entreprise de situer où elle en est sur un sujet donné.
Le second, le parcours projet, reprend la même interface à deux panneaux mais remplace les questions par des tâches concrètes à réaliser. Et le pont entre les deux est fluide : un diagnostic terminé peut être converti en projet, pré-rempli en fonction des réponses données. C'est cette connexion diagnostic-vers-projet qui donne au produit sa cohérence. On ne diagnostique pas juste pour diagnostiquer, on diagnostique pour agir.
Un système de dépendances entre tâches pour fiabiliser la donnée
Chaque tâche dans un parcours projet peut avoir des prérequis. Concrètement, certaines tâches ne deviennent accessibles qu'une fois les tâches dont elles dépendent complétées. Ce n'est pas qu'une question d'UX ou de gamification - c'est une nécessité métier.
Pourquoi ? Parce que le parcours aboutit à la génération automatique de documents RH. Et pour générer un rapport complet et cohérent, il faut que toutes les données nécessaires soient en base au moment de la génération. Le système de dépendances garantit cette complétude. Pas de raccourci possible.
Collaboration multi-tenant, rôles et deadlines
Le produit cible des grandes entreprises. Qui dit grand groupe dit équipes multiples, dit collaboration. L'architecture SaaS multi-tenant permet à chaque entreprise de disposer de son propre espace, avec un système de rôles (Owner, Admin, Membre). Les tâches peuvent être attribuées à des collaborateurs spécifiques, avec des deadlines par projet, par étape et par tâche.
Un système de notes sur chaque tâche permet aux collaborateurs de communiquer : expliquer un blocage, donner du contexte, poser une question. Rien de révolutionnaire en soi, mais indispensable pour qu'un outil comme celui-ci soit réellement utilisé au quotidien dans une organisation.
Travailler en marque blanche avec un autre développeur
Le développement produit en marque blanche a son lot de particularités. Le projet a été réalisé via une agence : j'étais en charge du frontend React + TypeScript, un second développeur gérait l'API Laravel côté backend.
Le contrat d'interface front / API comme filet de sécurité
Quand deux développeurs travaillent sur deux couches distinctes d'une même application, la communication devient un enjeu critique. La séparation des responsabilités était claire : le frontend gère l'interface utilisateur, les parcours, les composants interactifs et l'internationalisation. L'API Laravel prend en charge les calculs complexes, la gestion des fichiers uploadés, la génération de documents et les process longs.
Mais une séparation claire sur le papier ne suffit pas. Il faut un contrat d'interface solide. Quels endpoints, quels formats de données, quelles réponses d'erreur. Sans ça, on passe son temps à débugger des incompréhensions plutôt qu'à construire des fonctionnalités.
Si c'était à refaire : j'investirais encore plus de temps en amont sur la documentation des interfaces API. Chaque heure passée à spécifier un contrat d'interface en sauve trois en debug plus tard.
Architecture React TypeScript Supabase - les choix techniques et leurs raisons
Passons à la partie que les devs attendent. Comment tout ça tient ensemble sous le capot ?
Supabase hérité de la V0, un choix assumé
Supabase était un choix hérité de la V0 Lovable. Le client le connaissait, le maîtrisait, et souhaitait le conserver. Côté technique, l'outil répondait bien aux besoins : authentification intégrée, base PostgreSQL, et surtout l'API auto-générée qui permet au frontend d'interagir directement avec la base de données via le package npm supabase.
Dans un contexte Supabase React projet comme celui-ci, l'API auto-générée est un vrai gain de temps pour les opérations CRUD classiques. Les Row Level Security policies de PostgreSQL gèrent le multi-tenant côté données.
Est-ce que j'aurais fait le même choix sur un projet greenfield ? Pas nécessairement. Mais dans ce contexte précis, hériter d'un choix technologique du client et capitaliser dessus était la décision pragmatique.
React Context plutôt qu'un state manager externe
Pas de Redux, pas de Zustand, pas de Jotai. React Context suffit. Le contexte applicatif ne présentait pas de cas suffisamment complexes ou globaux pour justifier une solution plus lourde. L'état est principalement local aux parcours et aux composants interactifs. Pas de state partagé massif entre des parties déconnectées de l'application.
C'est un arbitrage que je défends : ajouter un state manager externe "au cas où" est une forme de complexité prématurée. Si le jour vient où React Context montre ses limites, la migration vers une solution plus robuste reste faisable.
Laravel côté API, la complémentarité assumée
L'API Laravel a été développée par le second développeur, basée sur sa maîtrise de l'écosystème PHP. Elle gère tout ce que le frontend ne peut pas ou ne doit pas prendre en charge : les calculs complexes liés aux grilles salariales, l'upload et le traitement de fichiers CSV, et surtout la génération automatique de documents RH.
Le process de génération est élégant dans son principe : un template Google Drive est dupliqué et rempli dynamiquement avec les données collectées tout au long du parcours. Le format de sortie est DOCX. Un système de mapping interne fait correspondre les données de chaque tâche aux champs du template.
Cette séparation React frontend / Laravel API n'est pas la plus courante, mais elle avait du sens ici. Chaque développeur travaillait avec les outils qu'il maîtrisait le mieux, et la frontière claire entre les responsabilités limitait les zones de friction.
Les fonctionnalités clés et leur implémentation
L'interface à deux panneaux et les drawers interactifs
L'interface utilisateur repose sur un pattern constant : un panneau gauche avec la liste des étapes, un panneau droit avec le contenu de l'étape sélectionnée. Cette cohérence entre les parcours diagnostic et projet réduit la charge cognitive pour l'utilisateur.
Là où ça devient intéressant techniquement, c'est dans les drawers. Certaines tâches du parcours projet ouvrent un drawer pleine hauteur contenant des composants interactifs spécialisés. Et la variété de ces composants a été un vrai défi.
On parle de textarea pour la saisie d'informations destinées à la documentation finale, de listes de sélection multicritères, de tableaux de correspondance texte-valeur pour associer des critères à des pourcentages ou pondérations, et de composants très spécifiques comme les intervalles des emplois ou les points de grille.
Chaque composant devait être réutilisable, configurable, et capable de persister ses données correctement pour alimenter la génération documentaire en aval. Ça a nécessité la création d'une bibliothèque de composants bien pensée, avec des abstractions claires entre la logique de présentation et la logique de persistance.
Upload CSV avec auto-mapping des colonnes
L'un des composants les plus intéressants à développer. Les utilisateurs RH ont besoin d'importer des données existantes, typiquement des fichiers CSV contenant des emplois et des salaires. Le composant d'upload intègre un auto-mapping des colonnes basé sur les noms de colonnes du fichier importé.
Concrètement, si le fichier contient une colonne "Intitulé du poste", le système la mappe automatiquement au champ correspondant dans l'application. L'utilisateur peut ensuite ajuster manuellement si nécessaire. Ça paraît simple, mais gérer la variété des formats de fichiers, des encodages et des conventions de nommage dans un contexte multilingue demande une logique de matching robuste.
Génération automatique de documents RH en DOCX
C'est la fonctionnalité qui donne sa valeur finale au produit. Une fois toutes les étapes requises d'un parcours complétées, l'utilisateur déclenche la génération d'un rapport complet en DOCX. Le document est auto-généré à partir de toutes les données saisies tout au long du parcours.
Côté implémentation, c'est l'API Laravel qui orchestre le process. Le système de dépendances entre tâches prend ici tout son sens : il garantit que toutes les données nécessaires sont disponibles au moment de la génération. Pas de champ vide par surprise, pas de section incomplète dans le rapport final.
Internationalisation FR/EN pour les grands groupes
La cible internationale du produit imposait une internationalisation dès le premier jour. Le dossier i18n/ gère les traductions français/anglais pour l'ensemble de l'application. Ce n'est pas la partie la plus glamour du développement, mais c'est une de celles où les choix architecturaux en amont font gagner un temps considérable sur la durée.
Ce que ce projet fullstack React m'a appris
Le produit est aujourd'hui en production, utilisé par des clients réels. Les retours sont très positifs, aussi bien côté utilisateurs que côté client, qui est satisfait du résultat. Et surtout, malgré la richesse fonctionnelle (composants atypiques, relations complexes, conversion diagnostic vers projet), l'application est restée fluide, intuitive et simple à utiliser. C'est probablement le point de fierté principal.
Mais au-delà du livrable, voici ce que je retiens de ce développement SaaS RH React TypeScript :
La compréhension du domaine métier est un facteur de réussite souvent sous-estimé par les développeurs. La complexité technique se surmonte avec de la rigueur et de l'expérience. Mais si on ne comprend pas le "pourquoi" derrière chaque fonctionnalité, on construit un outil techniquement correct mais fonctionnellement à côté de la plaque.
Le travail en tandem avec un autre développeur sur des couches différentes demande de la discipline. Le contrat d'interface n'est pas un document bureaucratique, c'est le filet de sécurité du projet.
Et une V0 prototype, même imparfaite, a une valeur immense comme outil de communication entre le client et l'équipe de développement. Elle permet de parler du concret plutôt que de l'abstrait.
Conclusion
Ce projet de plateforme RH m'a confirmé une conviction : les projets les plus formateurs ne sont pas forcément ceux avec la stack la plus complexe, mais ceux qui nous poussent hors de notre zone de confort. Ici, c'est le domaine métier RH qui m'a fait grandir autant que le code.
Le produit continue d'évoluer. Le client prévoit d'élargir les parcours thématiques au-delà de la transparence salariale et des grilles de rémunération, une fois l'adoption confirmée par les premiers utilisateurs.
Si vous travaillez sur un projet SaaS dans un domaine métier que vous ne maîtrisez pas, mon conseil tient en une phrase : investissez autant de temps à comprendre le métier qu'à architecturer votre code. Le produit final vous remerciera.
Envie d'échanger sur ce projet ou sur vos propres retours d'expérience SaaS ? N'hésitez pas à me contacter.
Ce projet a été réalisé en marque blanche. Le nom du client et de la plateforme ne sont volontairement pas mentionnés, par respect des engagements de confidentialité. Les choix techniques et l'architecture décrits dans cet article sont fidèles au projet réel.
![2 ans et demi comme [[développeur en startup]] : retour d'expérience chez ncScale](/_next/image?url=https%3A%2F%2Fsupabase.clementmenczynski.fr%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fimages%2Fprojets%2Fncscale.webp&w=2048&q=75)