Pour qui

À qui cela s’adresse, et jusqu’où.

Cette page répond à trois questions, dans cet ordre : qui le logiciel laisse agir, sur quelles affaires, et où s’arrête ce qu’il tient. La troisième est celle qui décide. Un registre de décisions n’est pas un système documentaire, et il vaut mieux le dire avant qu’après.

Ce que le logiciel autorise, et ce qu’il refuse

Le logiciel connaît ces rôles, et ceux-là seulement. C’est une taxonomie d’autorisation, non une liste de destinataires : elle dit qui le logiciel laisse agir, non à qui nous nous adressons. Chaque lecture et chaque écriture nomme les rôles qu’elle admet, et refuse tout le reste par défaut.

direction
juridique
commercial
financier
éditorial
production
relations publiques
technique
administration
conseil externe
lecteur externe

L’affaire, le dossier et le tiers: Lecture admise sous les rôles commercial et juridique. La portée d’une lecture admise est celle du groupe : chaque filtre porte l’identifiant du groupe, et un accès d’un groupe à un autre est refusé, non silencieusement vidé.
Le journal d’audit: Lecture admise sous les rôles administration, juridique et direction. Elle rend les événements du groupe sans filtre, sans pagination et sans exportation, et s’arrête à cinq cents lignes servies dans l’ordre croissant de création : au-delà, les plus récentes ne sont pas atteignables par cette lecture. Nous préférons l’écrire que le laisser découvrir.
La revue de pare-feu éditorial: Lecture admise sous les rôles éditorial, commercial et direction ; décider d’une revue exige le rôle éditorial, à une exception près, que nous disons plutôt que de la taire : sur une revue BLOQUÉE, la direction peut trancher elle aussi. Lue sous le seul rôle commercial, la revue 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: Lecture admise sous les rôles direction, juridique, commercial et financier. Lue sous le rôle commercial ou financier, elle 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é.
La décision: Aucun agent automatisé ne rend une décision engageante : la qualité humaine du décideur est exigée avant tout écrit. Le rédacteur d’une approbation ne peut pas la décider, et la transaction est soldée sans mutation partielle. Une décision rendue est immuable ; réévaluer, c’est en ouvrir une autre.

Deux réserves, plutôt qu’un silence. Le rôle de lecteur externe est déclaré à l’énumération et n’entre dans aucune liste admise : toutes les lectures le refusent tant que la relation de portée n’existe pas — il se nomme donc comme tel, jamais comme un destinataire servi. Et il n’existe aucune alerte : ni modèle, ni champ, ni route. Ce qui se lit se lit parce qu’on l’a ouvert, jamais parce qu’on en a été averti.

Les quatre lignes métier, et ce que le code en fait

Ce sont quatre valeurs du modèle, non quatre rubriques de brochure : une affaire est rattachée à exactement une ligne à sa création, et cette ligne doit avoir été déclarée. Un moteur déterministe calcule à partir de ce qui lui est déclaré et valide le type d’opération contre un catalogue versionné ; il ne devine rien qui ne lui ait été dit. Un même tiers, lui, intervient sur plusieurs lignes.

LODGING: L’hébergement : les contrats d’exploitation, de gestion et de services de l’hôtel.
FOOD_AND_BEVERAGE: La restauration : concessions, exploitations déléguées, fournitures et prestataires de salle.
MEDIA_RIGHTS: Les droits média : la seule ligne dotée d’un pare-feu éditorial construit. Un conflit d’intérêts y est bloqué, non déconseillé — la revue s’ouvre sous le rôle éditorial, l’escalade sous les rôles éditorial et commercial, et l’affaire ne passe pas tant que la revue n’est pas résolue.
BRAND_FRANCHISE: La marque et la franchise : licences d’enseigne, contrats de franchise et de représentation.

Ce que le code ne fait pas pour ces lignes se nomme aussi : ni gabarit par ligne, ni seuil par ligne, ni registre de conformité par ligne. Aucun seuil de prix ou monétaire, aucune intelligence artificielle, aucune matrice de compatibilité. Le pare-feu éditorial lui-même est partiel : ses commandes explicites et le blocage de l’affaire sont construits, son automatisation est différée. Enfin, 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.

La portée, dite d’avance

LCOS tient le cycle et la décision : le tiers, l’affaire, la matière juridique, le contrat, l’approbation — qui a décidé, quand, et sous quelle règle. Il ne tient pas le document. Il ne rédige ni ne génère aucun document ; il ne tient ni bibliothèque de clauses, ni gabarit de contrat, ni comparaison de versions ; il ne signe pas et ne s’adosse à aucun prestataire de signature ; il ne conserve aucun fichier.

Ce n’est pas une prétention, c’est une borne qui se vérifie. Le schéma de données du produit ne porte aucun modèle de document, de clause, de version de contrat ni d’enveloppe de signature ; l’architecture le dit en toutes lettres : aucun port de signature et aucun port de stockage d’objets ne sont implémentés. Une référence de contrat y désigne l’enregistrement de la décision, jamais le corps du contrat. Ce que LCOS laisse au système documentaire, il le laisse entier.

La spécification compte quarante modules — elle se nomme, et le compte se refait. Le dépôt, lui, porte neuf modules applicatifs, qui s’énumèrent : tiers, affaires, dossiers, contrats, approbations, matrice d’approbation, pare-feu éditorial, journal d’audit, identité. Ces deux comptes ne se soustraient pas l’un de l’autre, et nous ne les soustrayons pas : un module du dépôt ne recouvre pas terme à terme un module de la spécification.

Les cinq étapes, une par une

Ce que cette page ne montre pas

Références et chiffres d’usage: Ce site ne présente aucune référence client, aucun témoignage, aucun logo de tiers et aucun chiffre d’usage. Nous n’en publierons pas tant que nous n’en aurons pas. Ce qui est établi, et que nous pouvons dire : aucune donnée réelle n’est entrée dans le système. C’est délibéré — une décision d’architecture interdit toute ingestion de donnée réelle tant que la sauvegarde, la restauration exercée et le contrôle d’intégrité du stockage ne sont pas tous trois prouvés. Deux de ces trois conditions le sont ; la troisième ne l’est pas. Nous n’ouvrons pas la porte à deux tiers.
Feuille de route: La suite est spécifiée ; elle n’est pas datée. La spécification maîtresse décrit quarante modules répartis en sept phases. La phase de fondation est partiellement construite : la chaîne du tiers à l’approbation, le socle et la matrice d’approbation le sont ; le pare-feu éditorial ne l’est qu’en partie, son automatisation étant différée, et la porte de résilience n’est pas franchie. Toutes les phases suivantes portent l’état « spécifié, non implémenté ». Nous ne publions pas de calendrier que nous n’avons pas arrêté.