Produit
Un seul fil,
du tiers à l’approbation.
Chaque étape du parcours crée un enregistrement identifié et journalisé, rattaché au précédent. Le passage du commercial au juridique est une transition enregistrée, pas un courriel.
MODULE 02 · MODULE 04 · MODULE 12 · CON-000001
01
Le parcours, pas à pas
COUNTERPARTY
Counterparty — le tiers
Le référentiel maître des tiers du groupe : fournisseur, agence, talent, propriétaire d’hôtel, opérateur, partenaire média. Un tiers renseigné de son numéro d’immatriculation ne peut pas être créé deux fois dans le même groupe ; sans ce numéro, le schéma n’empêche pas deux fiches du même tiers.
DEAL
Deal — l’affaire
L’affaire commerciale, rattachée à exactement une ligne métier à sa création. Un moteur de règles déterministes valide le type d’opération contre un catalogue versionné et calcule le niveau de risque initial ; il n’infère rien qui ne lui ait été déclaré. Les montants restent vides tant qu’un porteur du rôle financier ne les a pas saisis ; sur le chemin de mise à jour, ce rôle doit de surcroît être tenu par une personne.
MATTER
Matter — la matière juridique
Dès que la négociation dépasse le stade commercial, la matière juridique est ouverte de façon idempotente : une par affaire, jamais deux. C’est le point d’ancrage du périmètre juridique — le contrat s’y rattache.
CONTRACT
Contract — le contrat
Le référentiel unique des décisions contractuelles du groupe. Chaque contrat porte une référence stable (CON-000001) et progresse selon des transitions strictes, du brouillon à l’exécution — pas de raccourci d’état. Cette référence désigne l’enregistrement de la décision, non le document : LCOS ne détient ni le corps du contrat, ni sa signature électronique.
APPROVAL
Approval — l’approbation
Le passage à l’état approuvé exige une approbation couvrant l’intégralité des rôles requis par le niveau de risque du contrat : du binôme commercial-juridique jusqu’au conseil externe et à la direction pour les niveaux critiques. Une décision rendue est immuable ; réévaluer, c’est ouvrir une nouvelle approbation.
02
La lecture aussi a des règles
Chaque lecture nomme les rôles qu’elle admet et refuse tout le reste. Ainsi : l’affaire, le dossier et le tiers se lisent sous les rôles commercial et juridique ; le journal d’audit sous les rôles administrateur, juridique et direction ; la revue de pare-feu sous les rôles éditorial, commercial et direction ; la demande d’approbation sous les rôles direction, juridique, commercial et financier. La portée d’une lecture admise est celle du locataire — chaque filtre porte l’identifiant du locataire —, et deux lectures la resserrent encore, sans jamais l’élargir. La revue de pare-feu, lue sous le seul rôle commercial, se borne aux affaires dont le lecteur est le responsable commercial inscrit ; qu’il porte aussi le rôle éditorial ou celui de direction, et la restriction tombe. La demande d’approbation, lue sous le rôle commercial ou financier, se borne aux demandes qui appellent l’un des rôles du lecteur ou qu’il a lui-même formées ; au-delà, la demande lui est rapportée comme inexistante, et son motif ne lui est jamais révélé. Le modèle de données rattache donc bien une affaire, une demande et un dossier à une personne — le responsable commercial, l’auteur de la demande, le juriste assigné —, et ces deux lectures-là s’en servent. Il n’existe en revanche aucune alerte : ni modèle, ni champ, ni route. Le rôle de lecteur externe est déclaré à l’énumération des rôles et n’entre dans aucune liste admise : toutes les lectures le refusent tant que la relation de portée n’existe pas. Les montants ne sont saisis que sous le rôle financier, et restent vides autrement.
La séparation des tâches s’applique jusqu’au bout : un approbateur ne peut pas approuver une demande qu’il a lui-même initiée, et aucun agent automatisé ne porte une décision d’approbation.
COUNSEL_REVIEW_REQUIRED
Un verrou que seul un conseil habilité peut lever
Un contrat peut porter le marqueur COUNSEL_REVIEW_REQUIRED — loi applicable dépendante de la juridiction, qualification fiscale non tranchée, clause qui sort du cadre déjà validé. Disons le construit plutôt que l’intention : ce marqueur est reçu à la création du contrat, de la personne qui l’ouvre. Aucune détection ne l’appose, et le système ne prétend pas juger seul qu’une question dépasse une règle validée.
Ce qu’il tient, en revanche, c’est le verrou. Tant que le marqueur subsiste, la porte d’exécution refuse la transition du contrat sous ce même code. Il ne se lève que par une revue enregistrée d’un conseil habilité, avec son identité, sa date et sa référence, sous un rôle juridique humain : aucun agent automatisé ne peut le lever. Le système préfère dire « à faire vérifier » plutôt que de laisser passer une qualification incertaine.
03
Le produit, photographié
Ces écrans sont ceux de l’interface d’administration elle-même, branchée sur l’API réelle du produit et chargée d’un jeu de démonstration dédié — un jeu produit en appelant les points d’entrée du logiciel, non écrit à la main dans les tables : les références, les dossiers ouverts automatiquement et les événements d’audit que ces écrans montrent sont ceux que le logiciel produit lui-même. Rien n’est reconstitué pour la vitrine : une interface refaite pour la photographie serait une preuve fausse.
