UnmetRadar : moteur d'étude de marché auditable

_contexte

UnmetRadar est le moteur backend d'un outil d'étude de marché qui évalue si une idée d'entreprise mérite d'être développée et qui, tout aussi important, refuse de donner une réponse assurée lorsque les preuves sont trop minces. Les scores individuels s'abstiennent plutôt que de deviner, les preuves contradictoires sont rapportées à côté des preuves concordantes, et une correction humaine est enregistrée comme un amendement attribué au lieu d'écraser silencieusement le rapport précédent. Le travail a commencé en juillet 2026. Le système fonctionne aujourd'hui comme outil en ligne de commande et worker d'arrière-plan : il n'y a pas encore d'interface, les preuves sont encore enregistrées à la main, et il n'a jamais été déployé ni utilisé par un client.

_mon-rôle

Je construis le système seul : le schéma PostgreSQL et ses migrations relues, le modèle de sécurité au niveau des lignes qui isole les données de chaque client, le pipeline de traitements durable, la couche d'orchestration autour des appels aux modèles, et une suite de tests qui s'exécute contre une vraie base de données plutôt que contre un mock.

_ce-que-j-ai-construit

• Un schéma PostgreSQL d'environ 150 tables avec 44 migrations relues à la main, des contraintes au niveau de la base et une sécurité au niveau des lignes forcée pour l'isolation des clients.
• Un monolithe modulaire à frontières explicites : onze modules métier derrière un point d'entrée public unique, avec des règles d'import vérifiées automatiquement plutôt que laissées à la convention.
• Un pipeline de traitements durable et une couche d'orchestration pour des étapes de workflow IA bornées, chaque appel de modèle passant par un adaptateur maison, une vérification d'autorisation et un registre de coûts.
• Un harnais de test et d'évaluation : suites exécutées contre une vraie base de données en conteneurs, et matrices d'évaluation multi-modèles couvrant la traçabilité, la gestion des contradictions et la résistance à l'injection de prompt.

_points-techniques

• Isolation multi-client prouvée plutôt qu'affirmée : la sécurité au niveau des lignes est forcée sur 142 tables, et un test démarre une véritable instance PostgreSQL sous un rôle qui ne peut pas la contourner, si bien qu'une nouvelle table ne peut pas partir en production sans protection.
• Des règles d'architecture elles-mêmes testées : à côté du code conforme, des fichiers en infraction écrits à la main vérifient que chaque règle de frontière échoue bien lorsqu'elle doit échouer.
• Les sorties de modèle et les contenus récupérés sont traités partout comme des entrées non fiables : réponses validées par schéma, client de récupération dédié renvoyant des codes d'échec typés pour les cas de DNS rebinding et de redirection, et campagnes d'évaluation adversariale croisant plusieurs modèles.