Architecture

La mémoire transforme les assistants d’entités réactives en entités persistantes, mais c’est aussi là que de nombreux systèmes pourrissent silencieusement. Les enquêtes soutiennent que la distinction entre mémoire à court terme et à long terme n’est plus suffisante pour la mémoire des agents modernes ; les SDKs OpenAI et LangGraph pointent vers une pile plus simple — mémoire de travail, état durable et récupération.

Un assistant IA de production n’est pas « un LLM avec un prompt ». C’est un système qui accepte l’intention, maintient un état, décide quand récupérer des informations ou agir, et expose suffisamment de détails d’exécution pour déboguer les échecs.

La plupart des systèmes de connaissances modernes optimisent la récupération (retrieval), et cela est compréhensible. La recherche est visible, facile à démontrer et semble magique lorsqu’elle fonctionne. Tapez une question, obtenez une réponse.

Le principe est simple : les connaissances compilées sont plus réutilisables que les fragments récupérés. RAG est devenu la réponse par défaut à une question simple : comment donner à un LLM (modèle de langage) l’accès à des connaissances externes ?

La gestion des connaissances personnelles (PKM), la génération augmentée par la récupération (RAG), les wikis, les systèmes de mémoire IA et désormais les flux de travail assistés par IA pratiques sont souvent discutés comme s’ils résoudaient le même problème. Ce n’est pas le cas. Ils traitent tous de la connaissance, mais ils opèrent à différents niveaux :

La plupart des tutoriels sur les « sorties structurées » des LLM manquent de sérieux. Ils vous apprennent à demander du JSON poliment, puis à espérer que le modèle se comporte correctement. Ce n’est pas de la validation. C’est de l’optimisme entre accolades.

Les assistants modernes oublient toujours tout lorsque vous fermez l’onglet, à moins qu’un élément ne persiste au-delà de la fenêtre de contexte. Les fournisseurs de mémoire d’agent sont des services ou des bibliothèques qui conservent des faits et des résumés entre les sessions — souvent intégrés en tant que plugins afin que le cadre reste léger tandis que la mémoire évolue.

Vous connaissez la routine. Vous ouvrez une conversation avec un agent IA, vous lui expliquez votre projet, partagez vos préférences, obtenez des résultats, puis fermez l’onglet. La semaine suivante, en revenant, c’est comme parler à un étranger : tout le contexte a disparu, chaque préférence a été oubliée, le projet doit être réexpliqué à partir de zéro.

OpenClaw semble simple dans les démos. En production, il devient un système.

Le véritable débat n’est pas de savoir si PostgreSQL peut effectuer des recherches de texte ou si Elasticsearch peut stocker des documents. Les deux peuvent le faire. La question intéressante est de savoir où la complexité de la recherche doit résider.

L’alerte est trop souvent décrite comme une fonctionnalité de surveillance. Cette formulation est commode, mais elle cache le vrai problème.

Les plateformes de chat ont évolué bien au-delà des simples outils de messagerie. Dans les systèmes modernes, elles fonctionnent comme des interfaces entre les processus automatisés et la prise de décision humaine.

Les intégrations Slack semblent trompeusement faciles car vous pouvez publier un message en une seule requête HTTP. La partie intéressante commence lorsque vous souhaitez que Slack soit interactif et fiable.

Discord devient une surface d’intégration sérieuse lorsque vous le traitez comme tel : un lieu où les systèmes publient des événements, les humains prennent des décisions et l’automatisation poursuit le flux de travail.

La plupart des conseils sur l’architecture des applications sont soit trop abstraits pour être appliqués, soit trop limités pour être évolutifs. Voici des compromis pratiques pour les systèmes de production, couvrant l’intégration, la structure du code et l’accès aux données.

La plupart des configurations locales d’IA commencent de la même manière : un modèle, un runtime et une interface de chat.