Mathieu Bernard Réserver 30 min

Un SaaS de conformité réglementaire

Quand le savoir de six experts réglementaires est le vrai produit, le problème n’est pas technique : il est dans l’organisation de l’équipe.

Type
Mission client, anonymisée
Secteur
Conformité réglementaire, chimie
Équipe
11 personnes : 2 développeurs Java, 3 React, 6 experts réglementaires
Technique
Java, React
Livrables
Plateforme SaaS, moteur de conformité
Mon rôle
Diagnostic, organisation produit, stratégie de tests

Chez cet éditeur, le vrai produit n’est pas le logiciel. C’est le savoir de six experts réglementaires, capables de dire si une substance chimique peut être vendue dans tel pays, sous quelles conditions et avec quelle étiquette. Le logiciel sert à rendre ce savoir utilisable par les clients. Quand je suis arrivé sur le sujet, ce savoir circulait mal.

Le diagnostic

Le schéma était classique. Les experts rédigeaient des documents, les développeurs les traduisaient en code, et chaque évolution réglementaire déclenchait des allers-retours de plusieurs semaines. Pire, une règle mal comprise ne se voyait pas : elle produisait un résultat plausible, et faux. Dans ce métier, une erreur de ce type expose un client à une non-conformité, donc l’éditeur à perdre sa confiance.

Le problème n’était pas technique. Il était dans l’organisation : deux mondes qui se parlaient par documents interposés.

Une seule équipe, développeurs et experts

J’ai proposé de réunir tout le monde dans une même équipe produit de onze personnes : deux développeurs Java sur le cœur applicatif et le moteur de conformité, trois développeurs React sur les interfaces, et les six experts réglementaires. Mêmes rituels, même backlog, mêmes priorités. Un expert qui voit une règle évoluer en parle au développeur concerné le jour même.

Sur le plan technique, la décision structurante a été d’intégrer les règles métier et les données réglementaires directement dans la plateforme, comme des données que l’on peut relire, et non comme des conditions éparpillées dans le code. Une règle devient ainsi vérifiable par l’expert qui l’a formulée.

La qualité, là où l’erreur coûte cher

J’ai demandé que chaque cas réglementaire validé par un expert devienne un test. Avec le temps, ces cas forment un filet de sécurité : une modification qui change la réponse sur un cas connu est repérée avant la mise en production, pas par un client.

C’est probablement la mission où j’ai le moins parlé d’architecture et le plus d’organisation. Quand le savoir métier est le cœur du produit, la façon dont l’équipe est composée décide de la vitesse de l’éditeur.