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.
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:
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 ?
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:
On restreint donc explicitement ses permissions et on applique le principe de moindre privilège, le système peut demander des autorisations temporaires adéquates à sa tâche pour éviter d'avoir un système surpuissant tout le temps.
On l'enferme dans un environnement de type DEV qui lui appartient mais ont il ne peut s'échapper. Cela suppose une pratique très mature de la CID. Par exemple l'agent peut pousser des commits sur un unique branche qui est utilisée dans son seul environnement et ignorée par les autres environnements.
# Pas très clair
Posté par Michaël (site web personnel) . En réponse au journal Réflexions sur la conception d’un système cognitif local orienté architecture et contrôle. Évalué à 2. 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)