Architecture de Cernor

Un noyau stable. Des données gouvernées. Des LLM interchangeables.

Cernor n’est pas un simple écran posé devant un modèle de langage. Le logiciel prépare le contexte, impose les droits, choisit les sources, contrôle les preuves et transforme le résultat en réponse ou en action exploitable.

Hébergement en France Serveurs en France LLM français opéré en France Isolation par entreprise
Vue d’ensemble

Chaque couche a une responsabilité précise.

L’interface ne parle jamais directement aux données de l’entreprise ni au fournisseur LLM. Les échanges passent par des contrats contrôlés et des services séparés.

01 · EXPÉRIENCEWeb, PWA et voixVue d’ensemble, conversations, tableaux de bord, documents et dialogue mobile.
02 · SÉCURITÉAPI PHPAuthentification, compte, rôle, permissions, lectures contrôlées, actions confirmées et journalisation.
03 · ORCHESTRATIONNoyau Python protégéCompréhension, plan de recherche, sélection des outils, contrôle des preuves et contrat de réponse.
04 · RAISONNEMENTAppels LLMCompréhension et synthèse dans un format structuré, avec profondeur adaptée à la demande.
Hébergement en FranceServeurs applicatifs en FranceLLM français opéré en FranceBase cloisonnée par comptePreuves et incidents traçables
Le noyau Cernor

Protégé parce qu’il porte la méthode.

Le noyau Python est commun à toutes les entreprises. Il reste volontairement générique et stable : il ne contient pas une accumulation de règles propres à un métier ou à une question.

Contrat de compréhension

Avant toute recherche, le noyau formalise l’objectif, les références au contexte, les certitudes, les hypothèses, les informations nécessaires et le résultat attendu.

Outils génériques

Recherche d’entreprise, ouverture d’une source, interrogation de données, calcul, recherche publique, création de livrable et présentation structurée.

Contrôle après récupération

Les résultats sont vérifiés par rapport à la demande autonome. Un contenu voisin, publicitaire ou insuffisant n’est pas transformé en réponse.

Sortie structurée

Le noyau retourne un contrat JSON pouvant contenir prose, tuiles, tableaux, graphiques, chronologies, extraits et livrables.

PHP

La couche qui garde les frontières

  • Identité et droitsL’entreprise, l’utilisateur et le rôle sont imposés côté serveur.
  • Lectures contrôléesLe noyau demande un outil ; PHP applique les permissions et ne renvoie que les données autorisées.
  • Actions explicitesUne écriture externe reste préparée, prévisualisée et confirmée selon sa sensibilité.
  • TraçabilitéDemandes, appels d’outils, incidents et résultats restent rattachés à une référence.
La couche PHP

Le LLM ne reçoit jamais les clés de l’entreprise.

PHP constitue la porte d’entrée sécurisée. Il authentifie, borne le compte, applique les rôles, expose des lectures contrôlées et conserve la trace des opérations. Le noyau Python peut raisonner sur les informations autorisées sans contourner cette frontière.

JWTaccount_idRôlesPortées privéesRequêtes signéesAudit
LLM français opéré en France

Le modèle raisonne. Cernor garde le contrôle du travail.

Les traitements de raisonnement s’appuient sur un LLM français opéré en France. Sa puissance est utilisée là où elle est utile, sans lui confier l’identité, les permissions, la vérité des sources ni l’exécution silencieuse d’une action.

ENTRÉE

Un contexte préparé

Question originale, historique utile, modèle validé de l’entreprise, vocabulaire, préférences applicables et pièces jointes.

COMPRÉHENSION

Un plan explicite

Le LLM indique ce qu’il comprend, ce qui reste hypothétique et les informations dont il a besoin avant que Cernor ne lance les lectures.

RECHERCHE

Des outils bornés

Les familles de sources sont consultées selon le sujet. Le glossaire aide seulement à comprendre un acronyme ; il n’est jamais une preuve.

RÉPONSE

Un résultat vérifiable

La synthèse distingue les faits, les déductions et les limites, puis rattache les affirmations importantes à leurs éléments d’origine.

Tenant Brain

Le programme reste commun. La mémoire reste propre à l’entreprise.

À la création d’un compte, Cernor initialise un contexte versionné : activités, produits, clients, vocabulaire, sources officielles, décisions ouvertes, corrections, préférences et stratégies validées. Cette mémoire n’est ni une copie du code ni une preuve par elle-même.

Faits validésDatés, sourcés et révisables
Préférences utilisateurVisibles, modifiables et supprimables
Historique utileConversations, décisions et engagements
Apprentissages gouvernésRetours utiles, corrections et contre-exemples
Fiabilité opérationnelle

La robustesse ne dépend pas d’un seul appel.

Cernor combine des contrôles structurels, des tests permanents et une exploitation observable.

Corpus de non-régressionCompréhension, preuves, forme, permissions et latence sont testées sur des cas représentatifs.
Travaux persistantsLes analyses longues passent par une file durable, un signal de vie et un worker reprenable.
Incidents référencésUne erreur reçoit une référence exploitable par la supervision, avec étape et diagnostic technique protégés.
Sources conservéesProvenance, fraîcheur, permissions et charge utile originale permettent audit et retraitement.
Voir l’architecture en situation

Une démonstration vaut mieux qu’un schéma.

Partons d’une question réelle, d’un document et d’un indicateur. Vous verrez ce que Cernor comprend, ce qu’il consulte et pourquoi il retient sa réponse.