Stabilisation et extension d’une plateforme RH multi-tenant

Notre client édite une plateforme RH utilisée par des entreprises françaises de taille intermédiaire pour la gestion des absences, les dossiers du personnel et la préparation de la paie. Le produit est une application Ruby on Rails multi-tenant, avec PostgreSQL et des traitements asynchrones Sidekiq, hébergée sur AWS dans la région eu-west-3 (Paris) et portée par une petite équipe d’ingénieurs seniors.

Les clients grands comptes arrivaient plus vite que l’équipe ne pouvait les absorber. Chaque nouveau prospect apportait ses questionnaires de sécurité, ses exigences d’authentification unique et ses demandes d’intégration avec des systèmes de paie.

Les ingénieurs qui portaient la feuille de route produit portaient aussi la production. La réponse aux incidents interrompait chaque sprint, le backlog de bugs s’allongeait, et des traitements asynchrones manipulant des données de paie échouaient parfois en silence — le type de défaillance qu’un produit RH ne peut pas se permettre. Dans le même temps, deux opportunités grands comptes étaient au point mort, faute de SSO SAML et d’un export de paie.

Recruter davantage d’ingénieurs seniors à Paris était lent et coûteux, et n’aurait de toute façon laissé personne d’astreinte la nuit.

Nous avons commencé par une transition de six semaines : lecture du code, binômage avec les ingénieurs du client et rédaction de runbooks pour les modes de défaillance qu’ils connaissaient par cœur. Nous avons instrumenté l’application avec Sentry et Datadog APM, ajouté une journalisation structurée et placé chaque file Sidekiq sous monitoring explicite, avec gestion des messages en échec (dead-letter) et relances idempotentes pour tout traitement touchant aux données de paie.

À partir de là, la production est devenue notre responsabilité dans le cadre d’un contrat « Infogérance & maintenance (SLA) » : monitoring 24/7, classification des incidents P1–P4, correction de bugs et mises à jour de sécurité. Avant de modifier quoi que ce soit dans les chaînes de calcul de la paie, nous les avons entourées de tests de caractérisation. La CI s’exécute sur GitHub Actions, avec un environnement de staging qui reproduit la forme des données de production au moyen de jeux de données anonymisés.

En parallèle, nos ingénieurs ont livré les fonctionnalités qui bloquaient le pipeline commercial : une authentification unique SAML 2.0 et OIDC, construite comme un service d’authentification dédié en amont du monolithe ; une API REST versionnée avec livraison de webhooks ; et un connecteur d’export de paie produisant des fichiers que les clients de l’éditeur chargent dans leurs moteurs de paie. Chaque intégration a été livrée avec isolation des tenants et limitation de débit dès la première version.