CS-01 / Dossier de projet
Construire une fondation React multitenant axée sur la sécurité
Comment un produit de conformité en préproduction, porté par son fondateur, a été structuré autour de frontières architecturales explicites, de l'isolation des locataires, d'une IA vérifiable et de critères de livraison fondés sur des preuves.
- Confidentialité
- Étude de cas anonymisée
- Statut des preuves
- Preuves approuvées
CS-02 / Contexte du produit
Contexte
Le produit aide les équipes de gestion immobilière et de facilities à collecter les justificatifs de conformité de leurs fournisseurs, à les comparer aux exigences définies par chaque client et à examiner le résultat. Le parcours prévu comprend le dépôt de documents, l'extraction assistée par IA, une évaluation déterministe, une validation humaine, des rappels et un historique d'audit.
Cette combinaison crée un problème exigeant d'architecture produit et frontend. L'interface doit rendre des justificatifs denses compréhensibles sans présenter la sortie d'une IA comme un fait. En parallèle, les données des organisations et leurs documents privés doivent rester isolés dans un système multitenant.
Moussa a piloté le cadrage produit, l'architecture React et l'implémentation de la fondation.
CS-03 / Contraintes
Contraintes
Le produit était construit par une petite équipe menée par son fondateur ; la complexité opérationnelle devait donc rester faible.
Chaque organisation nécessitait une frontière d'isolation stricte dans la logique applicative, les accès à la base et le stockage des documents.
Les résultats de l'IA devaient rester vérifiables et non fiables par défaut jusqu'à leur validation humaine.
Les services externes devaient pouvoir être remplacés sans coupler le domaine à un fournisseur.
L'architecture devait couvrir un parcours large sans devenir trop tôt un ensemble de microservices.
L'avancement devait être démontré par des preuves d'ingénierie répétables, et non par une étiquette de livraison optimiste.
CS-04 / Risques d’architecture
Les risques architecturaux
Le risque principal ne concernait pas un composant React isolé. Il consistait à laisser le périmètre produit, les règles d'isolation, les intégrations et le comportement de l'IA se diffuser dans l'application sans responsabilité claire.
Cela aurait rendu l'interface plus difficile à comprendre, augmenté le coût d'un changement de fournisseur et créé des occasions de perdre le contexte d'organisation entre les routes, les actions et les requêtes en base.
Le second risque concernait la confiance. Un parcours de conformité ne peut pas masquer l'incertitude derrière un écran de résultat soigné. Le justificatif original, les valeurs extraites, les contrôles déterministes et les décisions humaines doivent rester distincts.
CS-05 / Décisions et compromis
Décisions et mise en œuvre
Conserver une seule application déployable avec des frontières internes
Le choix s'est porté sur un monolithe modulaire : une application Next.js et une base principale, divisées en modules produit explicites. Cette approche limite la complexité de déploiement et de développement local tout en évitant que les fonctionnalités ne forment un code indifférencié.
La fondation implémentée sépare l'identité et les accès, les organisations, les fournisseurs et les exigences. Des couches plateforme et UI partagées soutiennent ces modules sans porter leurs règles métier.
Orienter les dépendances vers le domaine
Les règles métier restent derrière des services applicatifs et des interfaces de fournisseurs. Les adaptateurs d'infrastructure prennent en charge la persistance et les services externes.
Le produit dispose ainsi d'une voie réaliste pour remplacer un fournisseur, un stockage ou un service d'extraction. La distinction entre décisions métier et plomberie du framework devient également visible pendant les revues.
Traiter le contexte d'organisation comme une frontière de sécurité
L'appartenance à une organisation traverse le contexte applicatif authentifié et est renforcée par la sécurité au niveau des lignes de la base de données. Le stockage privé est conçu autour de la même frontière.
Le frontend bénéficie de ce modèle explicite : routes, opérations serveur, navigation et permissions peuvent être structurées autour de l'organisation active, au lieu de dépendre de filtres implicites.
Concevoir l'IA comme une couche de suggestion
L'architecture traite les données extraites par l'IA comme des entrées non fiables. Les sorties structurées doivent être validées, le justificatif original reste disponible, l'évaluation déterministe demeure séparée et une personne prend la décision finale.
Ce choix façonne aussi l'interface. Les écrans de revue doivent montrer les preuves, le niveau de confiance, les exceptions et les actions humaines, plutôt que de réduire le parcours à un score opaque.
Construire des tranches verticales complètes sur des composants partagés
La fondation fonctionnelle comprend la gestion des organisations et des membres, un annuaire de fournisseurs et des exigences configurables. Ces parcours utilisent un design system cohérent au lieu d'accumuler des contrôles propres à chaque route.
L'approche confronte les décisions d'architecture à de vrais parcours produit : navigation authentifiée, données limitées à l'organisation, formulaires, tableaux, validation, états vides et comportement responsive.
Fonder la préparation à la livraison sur des preuves
Les contraintes d'architecture, contrôles statiques, vérifications de base de données, scans d'accessibilité et résultats de build ont été consignés comme preuves de livraison. Une revue ultérieure a maintenu le blocage de la production tant que certaines vérifications hébergées et reproductibles indépendamment restaient incomplètes.
Cette distinction est essentielle : un jalon réussi constitue une preuve d'ingénierie utile, mais pas une mise en production.
CS-06 / Jalon documenté
Jalon d'ingénierie documenté
Lors d'un jalon Sprint 04 consigné :
le formatage, la vérification des types, le lint et le build de production ont réussi ;
le rapport d'architecture couvrait 123 modules et 287 dépendances, sans violation, avec deux tests de frontières ;
207 contrôles unitaires, 38 contrôles de composants et 49 contrôles de base de données ont réussi ;
six scans d'accessibilité non authentifiés n'ont signalé aucune violation automatisée.
Ces chiffres décrivent uniquement ce jalon documenté. Ils ne constituent ni des résultats clients, ni des garanties de niveau de service, ni une preuve que le produit était prêt pour la production. Une révision ultérieure a explicitement maintenu le blocage tant que des vérifications hébergées supplémentaires restaient incomplètes.
CS-07 / Résultat
Résultat
Le travail a produit une fondation cohérente pour les prochains parcours :
- les domaines produit ont une responsabilité et des règles de dépendance visibles ;
- l'isolation multitenant fait partie du modèle applicatif et de la base ;
- les parcours d'organisation, de membres, de fournisseurs et d'exigences mettent l'architecture à l'épreuve dans une interface fonctionnelle ;
- les comportements assistés par IA possèdent des limites explicites de validation et de revue humaine ;
- les fournisseurs externes disposent de points de remplacement définis au lieu de se diffuser dans la logique métier ;
- les décisions de livraison peuvent s'appuyer sur des preuves consignées et des critères encore ouverts.
Le résultat le plus important n'est pas un grand nombre de fonctionnalités. C'est une fondation où la sécurité, la confiance et la maintenabilité sont traitées comme des comportements produit dès le départ.
CS-08 / Portée de l’expérience
Ce que cette intervention démontre
Cette mission illustre le type de travail que Moussa apporte aux produits React difficiles : transformer des risques produit ambigus en décisions d'architecture, construire suffisamment de parcours réels pour mettre ces décisions à l'épreuve et limiter les déclarations de livraison à ce que les preuves permettent d'affirmer.