Bonjour,
Je travaille depuis plusieurs mois sur un projet personnel nommé Dominus, que je qualifierais aujourd’hui non pas comme un logiciel fini, mais comme une exploration architecturale autour d’un système cognitif local.
Je précise d’emblée le cadre afin d’éviter les malentendus :
je ne cherche ni testeurs, ni utilisateurs, ni à promouvoir un produit.
Je souhaite uniquement confronter certains choix d’architecture système et logicielle à des personnes ayant de l’expérience dans ces domaines.
Dominus n’est pas un chatbot, un LLM cloud, un agent autonome incontrôlé, un projet orienté benchmarks ou performances ML.
Le LLM (quand il est utilisé) n’est pas le cœur du système, mais un composant de reformulation linguistique.
Intention du projet
L’objectif exploré est le suivant :
concevoir un système cognitif local-first, capable d’interagir avec un environnement informatique tout en conservant une conscience fonctionnelle de ses capacités, de ses limites, et de ce qu’il n’est pas autorisé à faire.
L’idée centrale est de séparer strictement la décision (logique, déterministe, contrôlée),de la formulation (langage naturel, adaptatif).
Architecture (vue conceptuelle)
De manière simplifiée, l’architecture repose sur un Decision Core déterministe (capacités, refus, garde-fous),un routeur d’intentions contrôlé,
un système de mémoire locale explicite (préférences, état, capacités connues),
un module de formulation linguistique (LLM non décisionnel),
des invariants de sécurité non modifiables par apprentissage.
Tout est pensé pour être local, traçable, réversible,
sans dépendance cloud obligatoire.
Invariants assumés
Quelques principes non négociables dans cette exploration :
aucun apprentissage implicite ou non confirmé,
aucune mémorisation d’opinions ou de croyances,
possibilité de réinitialisation complète par l’utilisateur, un système qui peut devenir volontairement limité, mais jamais dangereux.
Ce que je cherche comme retour.
Uniquement des retours architecturaux, par exemple :
la séparation décision / formulation vous paraît-elle saine ou fragile ?
voyez-vous des risques systémiques dans une approche “mémoire injectée” ?
quels invariants mériteraient selon vous d’être encore plus verrouillés ?
quels red flags d’architecte voyez-vous immédiatement ?
Je ne cherche pas de comparaisons avec des solutions existantes, de débats idéologiques sur l’IA,de conseils de frameworks ou de réécriture complète.
Merci d’avance à celles et ceux qui prendront le temps de répondre sérieusement.
# Clarifications nécessaires ?
Posté par raphj (site web personnel) . Évalué à 8 (+6/-0). Dernière modification le 17 janvier 2026 à 17:35.
Bienvenue sur LinuxFr.
J'ai l'impression que ton journal aurait plus sa place sur le forum.
Par ailleurs, peut-être que c'est parce que je ne baigne pas trop dans l'IA, mais je ne comprends pas grand chose de ton journal. Peut-être que je ne suis pas le seul et ça pourrait se mettre en travers de ton objectif d'avoir des retours.
Quelques questions pour essayer de clarifier.
À mon avis, il faut soigner la présentation de ton idée, autant sur le fond que sur la forme. Avec des beaux titres, des listes à puces, du formatage… Peut-être avoir des schémas, des exemples, des illustrations… peut-être aussi le contexte dans lequel s'inscrit ton projet, aussi : pourquoi ce qui existe déjà ne te convient pas / qu'est-ce que tu cherches à améliorer, qu'est-ce qui t'a poussé à te lancer dans cette exploration… Ça rendra la chose plus susceptible d'attirer l'intérêt, et ça permettra aussi de mieux comprendre ce que tu cherches à faire.
Tu mentionnes un logiciel, tu ne veux pas nous montrer ? Ça pourrait aussi aider à comprendre et commenter. En plus, comme ça, la description parait très vague, je ne suis même pas sûr de voir sur quelle architecture tu souhaiterais avoir un retour.
Aussi, quel rapport avec LinuxFr ? Le sujet des journaux est très libre, néanmoins tu as créé un compte ici et/pour poster cela, c'est peut-être qu'il y a un lien avec Linux ou le libre ?
[^] # Re: Clarifications nécessaires ?
Posté par BAud (site web personnel) . Évalué à 2 (+1/-1).
même remarque : comment faire un retour d'architecture sans un crobar à se mettre sous la dent ? (et je ne vais pas le faire moi-même)
Être obligé de deviner les boucles de rétroaction n'aide pas, d'autant qu'il faut déjà comprendre le découpage des fonctions et leurs interactions (pas forcément besoin d'un diagramme UML même si ça aiderait).
En outre, la réalisation de certaines fonctions me laisse dubitatif.
Par exemple, je n'ai pas compris comment on peut réaliser « aucune mémorisation d’opinions ou de croyances ».
idem pour répondre à la question « la séparation décision / formulation vous paraît-elle saine ou fragile ? », j'aurais tendance à dire : inexistante, elle n'est pas décrite
c'est de la conception de logiciel, donc c'est l'architecture logicielle, plus spécifiquement l'architecture fonctionnelle (concernant le code et non l'empilement des briques logicielles à utiliser)
[^] # Re: Clarifications nécessaires ?
Posté par raphj (site web personnel) . Évalué à 2 (+0/-0).
Oui oui, c'est juste que j'ai du mal à me la représenter avec le texte du journal.
# Attentes sur ce site
Posté par raphj (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 17 janvier 2026 à 17:53.
En vrai, LinuxFr n'est pas un service gratuit sans âme de revue d'architectures, si les gens veulent crier « FUCK L'IA ET LES TECH BROS TRUMPISTES DE LA SILICON VALLEY CEPENDANT, la poudre verte c'est mieux » ou suggérer une réécriture en Rust dans les commentaires de manière respectueuse des conditions d'utilisation du site, bah c'est la vie.
[^] # Re: Attentes sur ce site
Posté par Yves (site web personnel) . Évalué à 1 (+0/-0).
J’adore le commentaire 😁
Cependant, en vrai, j’ai trouvé utiles ces précisions qu’ils donne, afin de focaliser la réflexion.
Je n’ai pas tout compris au journal, mais en lisant ça, je m’imagine un logiciel contrôleur d’infra ou on dira par exemple “protège le serveur SSH contre le brute-force”, et là l’IA va aider à traduire ça en objectifs techniques du style configurer le pare-feu, mettre un honey-pod ou que sais-je… peut-être en s’aidant d’actions passées (mémorisées factuellement) et la manière dont elles ont été réalisées.
J’en déduis au passage que seul le Core peut donner les faits à l’IA, car cette dernière ne peut pas décider ce qui est un fait ou une opinion.
Voilà, je n’ai pas grand chose d’autre à dire, car comme dit ci-dessus, l’architecture est présentée de manière un peu succincte et qu’en plus, je n’y connais pas grand chose à l’IA…
Bon courage en tout cas, ça a l’air intéressant !
# J'ai déjà fais ça
Posté par Florian.J . Évalué à 3 (+3/-1). Dernière modification le 17 janvier 2026 à 20:50.
Je suis pas certain d'avoir bien compris le sens de la demande, mais ça ressemble à quelque chose que j'ai déjà implémenté.
Je pense que le point de départ serait un modèle "router" tel que:
https://huggingface.co/katanemo/Arch-Router-1.5B
En gros tu spécifies un contexte, une liste de choix et le modèle choisit le plus probable.
J'ai utilise à la base un autre type de modèle axé sur la classification de texte (j'ai commencé avant que Sam Altman popularise le principe du routeur):
https://huggingface.co/MoritzLaurer/bge-m3-zeroshot-v2.0
L'implémentation diffère, mais il suffit d’orienter le modèle avec des instructions et reproduire le même comportement.
Maintenant, sur les grand principes de l'implémentation, j'ai quelque chose qui ressemble à ça:
Python, parce que ce c'est pratique, tous les outils et toutes les bibliothèques seront disponibles simplement.
vllm pour l'inférence des llm, rapide et très performant. Mais si tu es seul utilisateur, peut être que llama.cpp peut suffire, surtout que l'écart de performance s'est réduit ces derniers temps (par contre llama.cpp est strictement orienté mono utilisateur). Sinon SGLang semble un bon choix mais je connais pas très bien.
SentenceTransformers pour la vectorisation de textes + chromadb pour le stockage (pour conserver du texte en mémoire et le retrouver). Simple à implémenter.
Redis en option si tu veux pouvoir implémenter le stockage persistant de certaines données avec un système de compte (instructions pour le llm en entrée par exemple).
Ray serve pour la gestion des différents services, mais un ensemble d'instance uvicorn pilotés par des scripts peuvent faire le boulot (surtout que gérer vllm depuis ray est un peu galère, je suis justement en train de me battre en ce moment pour passer de la version 0.7 à 0.13…).
Après tu pilotes tout ça avec un serveur reproduisant l'API OpenAI, ce qui te permet d'être compatible avec un maximum de client (c'est pas compliqué, mais ça peut être un peu chiant à faire).
Le serveur conserve pour chaque connexion un contexte, que tu viens compléter en utilisant les différents outils (par exemple injecter de la donné).
Enfin, l'architecture de l'exécution des requêtes (le passage d'un modèle à l'autre) est semblable à un parcours de graphe acyclique. Tu as pas exemple en entrée un choix entre différents outils, qui peut être à plusieurs niveaux, ce choix peut faire appel à d'autre outils, recherche des des bases de données, et terminer sur la génération d'une réponse.
Ce graphe peut être défini comme tu le souhaites, mais j'ai opté pour des fichiers YAML qui définissent un type d'outils, les instructions, différentes variables et d'autre fichiers liées par des noms.
Si tu comptes déployer un service avec de la répartition, chacun des sous-services devraient être implémenté dans des serveurs distincts.
Enfin, tu implémentes un service qui prends en entrée les requêtes utilisateur et parcourant le graphe pour générer la réponse (en gérant un contexte dans lequel les différents sous-service peuvent ajouter de la donné).
Si tu fais communiquer tout ça avec de l'HTTP, tu pourras faire de la répartition simplement (seuls les serveur de données comme chromadb vont être plus complexes à gérer).
Conseil: Ne pas de fier à un modèle spécifique car ça peut évoluer rapidement, il faut penser à la modularité dès le départ pour éviter d'avoir à tout réimplémenter plusieurs fois.
D'où mon choix d'une implémentation basée sur des fichiers YAML. Ca peut être critiqué, tu peux faire autrement, mais il est très important de bien séparer les instructions et les paramètres des modèles de l'implémentation.
Parce qu'il faut partir du principe que les paramètres des modèles sont temporaires et doivent pouvoir être réécrits à n'importe quel moment (un simple changement de formulation sur un llm pouvant améliorer la qualité des réponses !).
# Pas très clair
Posté par Michaël (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 21 janvier 2026 à 11:57.
C'est plus ou moins l'ambition de tous ceux qui font de l'Agentic AI et il y a déjà beaucoup de livres écrits sur le sujet. L'angle local first qui suggère d'utiliser des outils locaux ne change pas vraiment les idées principales de l'outil. Aujourd'hui on peut facilement faire tourner des LLMs très performants et des petits cluster Kubernetes sur des machines relativement abordables et il n'y a plus aucun obstacle à faire ce que tu décris — d'ailleurs tu es loin d'être le seul! :-)
Qu'est-ce que tu cherches à faire dans ces intéractions? C'est ce dont tu parles le moins et c'est un peu le nœud du problème.
Ton architecture comme tu la présentes est plus une liste de fonctionnalités ou de “cross functional requirements” (exigences trans-fonctionnelles?) écrits à la va-vite sur un coin de table qu'une architecture a proprement parler. Ce serait mon premier “red flag“ d'architecte.
Ensuite pour tes autres questions:
c'est assez difficile de dire quelque chose car on n'a pas trop idée de ce que tu veux faire (quelles sont les fonctions de ton système?) et tu es vraiment trop peu précis (Qu'est-ce que tu veux dire par reste systémique et mémoire injectée? Sinon oui tous les projets ont des risques qu'il faut modéliser et analyser, mais l'importance des risques dépend complètement du projet, ça n'a pratiquement aucun sens de poser une question aussi ouverte.)
Si on prend un exemple plus précis, par exemple une plate-forme de développement interne et ton systéme est un agent qui, de façon autonome va prendre des stories, les peaufiner et les implémenter, la marche à suivre est simplement de considérer que ton système ne peut pas fare l'objet de confiance:
(En gros comme un stagiaire xD)
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.