Projets

Cadrage du sujet du jour

La journée a été consacrée à l’arbitrage d’une stratégie de synthèse de textes et conversations très longues pour un usage exploitable dans une chaîne d’IA documentaire et d’assistance d’entreprise. Le travail ne s’est pas limité à comparer des modèles : il a consisté à structurer une approche réaliste, soutenable en coût, et compatible avec une logique de mémoire durable.

Choix de modèles selon l’usage

Un premier tri a permis de distinguer clairement les modèles selon leur rôle :

• Pour la qualité de synthèse sur très gros volumes :
  • Gemini 2.5 Pro pour sa grande fenêtre de contexte
  • GPT-5.2 Thinking / GPT-5.4 pour la fidélité, la structuration et la qualité de restitution
  • Claude Opus 4.6 pour la lisibilité et la nuance rédactionnelle
• Pour une extraction économique :
  • Gemini 2.5 Flash-Lite comme option la plus frugale
  • Gemini 2.5 Flash comme compromis coût / performance
  • DeepSeek V3.x et Qwen 2.5 72B retenus comme alternatives crédibles pour l’extraction structurée par blocs

Décision d’architecture

L’arbitrage principal du jour est le suivant : éviter le résumé global monolithique au profit d’un pipeline en plusieurs étapes :

1. découpage en blocs,
2. extraction structurée par bloc,
3. fusion et déduplication,
4. passe finale de consolidation.

La consigne a été reformulée en conséquence : demander au modèle une extraction d’idées fortes plutôt qu’un résumé narratif. Les catégories retenues sont notamment : idées principales, décisions, contraintes, faits clés, actions et questions ouvertes, avec une sortie JSON stricte.

Maîtrise des coûts et mémoire utile

Un second axe important a porté sur la réduction des coûts de mémorisation continue :

• ne pas résumer systématiquement tous les échanges ;
• filtrer d’abord les messages pour ne conserver que les éléments durables ;
• privilégier l’extraction des messages utilisateur ;
• déclencher la mémoire sur événements significatifs ;
• séparer contexte récent brut, mémoire durable compacte et archives complètes accessibles via RAG.

Le pipeline cible repose donc sur une chaîne sobre : règles locales → fragments candidats → déduplication → appel LLM minimal → stockage atomique.

Prolongement du chantier

Ce travail prolonge directement la consolidation d’OpenWebUI et de la chaîne documentaire du mois : l’enjeu n’est plus seulement de disposer d’une interface ou d’un RAG, mais de fiabiliser la manière dont l’information conversationnelle utile est extraite, capitalisée et réutilisée. À l’échelle annuelle, cela renforce la construction d’un socle d’IA d’entreprise souverain, capable de transformer des échanges bruts en connaissance exploitable, sans dérive de coût ni perte de contrôle.

Données OpenWebUI rendues exploitables

La journée a surtout porté sur la mise sous contrôle des données internes d’OpenWebUI afin de mieux piloter une chaîne documentaire exploitable en environnement self-hosted. Un premier bloc a consisté à clarifier la structure JSON stockée dans chat et à produire des requêtes SQL réellement utilisables pour :

• extraire les messages depuis chat->'messages'
• reconstruire des paires question/réponse
• générer un transcript complet par conversation
• ajouter des indicateurs de longueur, de taille en octets et un filtre sur les dernières 24h

Le travail a aussi permis de fiabiliser plusieurs détails techniques importants : usage de json_array_elements(...) car la colonne est en json, conversion des timestamps Unix via to_timestamp(...) sur chat_message.updated_at, et affichage propre du contenu JSON avec content #>> '{}'.

Contrôle de cohérence des fichiers et chunks

Un second axe important a concerné la détection d’incohérences entre document_chunk, file et knowledge. L’analyse a permis de distinguer clairement :

• les fichiers rattachés à une knowledge base via meta.data.knowledge_id
• les collections techniques de type file-<uuid>
• les cas potentiellement orphelins ou incomplets

Dans un contexte multi-bases, le choix pragmatique retenu a été de faire la comparaison dans n8n plutôt que de forcer un rapprochement SQL local. Les tests menés montrent qu’il n’y a vraisemblablement pas d’orphelins sur le critère document_chunk.vmetadata->>'file_id' vs file.id, ce qui réoriente le diagnostic vers d’autres causes possibles : métadonnées incomplètes, chunks sans file_id ou incohérences applicatives.

n8n et mémoire OpenWebUI : vers une exploitation plus robuste

La journée a également consolidé la couche d’orchestration avec n8n : agrégation SQL avant comparaison, regroupement d’items en JSON unique, production d’un results_text propre pour les prompts, parsing de réponses LLM JSON et synchronisation de branches via Merge en mode Combine.

En parallèle, le fonctionnement de la mémoire OpenWebUI a été clarifié, notamment la distinction entre Memory, Notes et Knowledge. L’analyse du code de la fonction Auto Memory a mis en évidence plusieurs défauts structurels sérieux, conduisant à une conclusion nette : l’idée est pertinente, mais le code montré n’est pas suffisamment fiable pour un usage de production sans correction et instrumentation par logs.

Dans la continuité des travaux mensuels d’optimisation d’OpenWebUI et de consolidation d’une IA documentaire souveraine, cette journée renforce la trajectoire annuelle : faire d’OpenWebUI une façade réellement maîtrisée, branchée sur des données vérifiables, des workflows traçables et une architecture documentaire gouvernable.

Conception et structuration d’un socle de publication dédié à une timeline technique multilingue, avec un modèle de données capable de porter des cartes datées, un contenu éditorial et une catégorisation bilingue. Le travail du jour a porté sur l’architecture des niveaux de lecture quotidien, mensuel et annuel, afin de produire un rendu cohérent à la fois en détail et en synthèse.

La mise en œuvre s’est appuyée sur une base PostgreSQL Azure structurée pour séparer clairement les contenus, les regroupements temporels et le référentiel de tags. Le schéma a intégré des contrôles de cohérence sur les dates, des identifiants adaptés à un usage éditorial et une gestion automatique des timestamps pour fiabiliser les mises à jour.

Un référentiel de tags français / anglais a également été normalisé pour homogénéiser la qualification des contenus et préparer une exploitation propre côté interface. Ce travail s’inscrit dans la dynamique du mois visant à transformer les réalisations techniques en contenus publiables, et prolonge la trajectoire annuelle de structuration d’une pile maîtrisée, durable et valorisable dans une logique de produit professionnel.

Le travail s'est poursuivi autour de la récupération documentaire SharePoint, avec une approche plus orientée usages réels. La question n'était plus seulement de synchroniser, mais aussi de simplifier l'accès aux contenus et leur exploitation dans des workflows. Les recherches sur les packages, connecteurs et stratégies de récupération ont prolongé les bases posées auparavant. Le sujet reste central pour alimenter une base de connaissance exploitable. Cette continuité confirme l'importance stratégique de Microsoft 365 dans l'architecture.

En mars, les travaux s'orientent vers la stabilisation et l'assemblage cohérent des briques déjà explorées. Le focus s'est porté sur l'exploitation pratique d'OpenWebUI, PostgreSQL, les embeddings et les traitements documentaires. L'objectif n'était plus seulement de comparer, mais de faire tenir l'ensemble dans un cadre fiable. Cela inclut les performances, la cohérence fonctionnelle et les limites des composants choisis. Le mois est consacré à une phase de consolidation active.

Mars montre aussi une volonté plus marquée de transformer les travaux réalisés en contenus publiables. La réflexion autour d'une timeline, d'un portfolio technique et d'une mise en récit des réalisations devient plus visible. L'enjeu est de présenter les sujets sous forme de réalisations, décisions, tests et intégrations concrètes. Le technique commence ici à être retravaillé comme actif de communication professionnelle.

Le mois a vu émerger plusieurs sujets pratiques autour d'OpenWebUI : qualité des réponses, prompt système, analytics, branding et intégration. Le travail a porté sur l'amélioration du comportement réel de l'outil en situation de production professionnelle. Cela montre un déplacement progressif vers les questions d'expérience, de pilotage et de valeur perçue. L'outil n'est plus seulement observé comme composant technique, mais aussi comme produit utilisableen contexte professionnel d'entreprise.

Renforcement du lien entre les choix d'architecture et une offre lisible orientée entreprise. Le sujet couvre l'hébergement maîtrisé, la confidentialité, l'IA documentaire et la valeur métier des assistants construits. Les éléments techniques sont progressivement rattachés à une proposition de service plus claire. On n'est plus seulement dans l'expérimentation technique, mais dans la transformation en offre crédible professionnelle d'entreprise. Cela donne au mois de mars une dimension plus produit et plus stratégique.

Le mois a aussi été marqué par des sujets d'exploitation plus techniques sur Azure, PostgreSQL et l'environnement de déploiement. Les travaux ont porté sur la base de données, les extensions, les migrations, le proxy inverse et les services managés pertinents. Les arbitrages coût, simplicité et robustesse ont pris une place centrale. L'objectif était de rendre l'écosystème plus stable et plus cohérent avec les usages visés. Cette consolidation a servi d'appui aux expérimentations IA et documentaires professionnelles.

Les expérimentations se sont heurtées à des contraintes très concrètes de CPU, mémoire et temps de traitement. Le travail a consisté à tester ce qui tenait réellement sur la VM Windows server 2025 en matière d'embeddings, de modèles locaux et de charge globale. Les options trop lourdes ont été reconsidérées à l'aune de la performance observée. La viabilité self-hosted est devenue un critère aussi important que la qualité théorique. Cela a conduit à des choix plus réalistes et plus exploitables, notamment le passage à un hébergement sur VM Linux Ubuntu dans Azure gérant mieux les ressources (CPU, RAM et disques).

Au lieu d'évaluer OpenWebUI de manière abstraite, le travail a porté sur ses comportements réels dans un contexte de production professionnelle. Les sujets abordés incluent la gestion des collections, l'ajout de fichiers, l'usage des parsers externes et le couplage avec des services RAG. Les limites fonctionnelles ont été mieux identifiées. Cela a permis de distinguer ce qui devait rester dans l'outil et ce qui devait être déplacé à l'extérieur. Le rôle d'OpenWebUI s'est affiné comme couche d'interface plutôt que comme solution totale.

Le mois a marqué une transition entre architecture cible et mise en œuvre concrète. Le travail s'est concentré sur la manière de brancher un retrieval externe, de maîtriser l'index et de fiabiliser le comportement réel du système. Les questions de suppression, mise à jour, reconstruction d'index et cohérence des résultats ont pris plus d'importance. L'enjeu était de sortir d'un simple prototype pour aller vers un flux exploitable. Cette phase a renforcé la dimension opérationnelle du projet documentaire d'entreprise.

Approfondissement d'une architecture où l'indexation et la recherche sont gérées hors de l'interface de chat. Le travail a porté sur les bénéfices d'un contrôle plus fin sur les documents, les vecteurs et le cycle de vie des contenus. Cela a ouvert la voie à des fonctions avancées comme le reranking ou des logiques de recherche hybrides. L'approche permettait aussi de mieux séparer les responsabilités entre interface, moteur de recherche et pipeline d'ingestion. Cette orientation a clarifié la structure globale du système d'IA d'entreprise.

Évaluation des compromis entre qualité d'indexation, coût CPU, taille des vecteurs et faisabilité sur VM. Plusieurs approches ont été comparées pour l'extraction documentaire et les embeddings, avec une attention particulière à la stabilité. Le sujet n'était pas seulement théorique : il fallait identifier ce qui pouvait réellement tenir dans l'environnement. Cette phase a permis d'écarter certaines options trop lourdes. Elle a aussi préparé les choix plus pragmatiques des évolutions à venir.

Le travail a inclus la logique de synchronisation, le suivi des changements et la préparation d'une alimentation continue du moteur documentaire. Les delta queries et la gestion des bibliothèques ont été au cœur des réflexions. L'objectif était de bâtir un flux robuste entre Microsoft 365 et la base de connaissance. Ce chantier s'inscrit dans une logique d'orchestration documentaire professionnelle industrialisable.

Consolidation de n8n comme couche d'automatisation pour piloter les flux documentaires et les appels de services. Les travaux ont porté sur la structuration de sous-workflows, la circulation de la configuration et la composition de JSON techniques. L'approche visait à rendre les traitements réutilisables et lisibles. Cela a permis de préparer une industrialisation progressive des pipelines. n8n a commencé à prendre une place centrale dans l'assemblage des briques.

Définition d'un socle documentaire capable d'ingérer, indexer et restituer des contenus d'entreprise de façon exploitable. Le travail a porté sur la chaîne complète : extraction, découpage, embeddings, indexation vectorielle et retrieval. Plusieurs options ont été comparées pour garder un bon niveau de contrôle technique sans alourdir l'exploitation. L'objectif était de poser une architecture lisible, modulaire et durable. Cette phase a servi de base aux arbitrages réalisés les semaines suivantes.

Exploration du rôle exact d'OpenWebUI dans une architecture documentaire plus large. Le sujet n'est pas seulement l'interface, mais aussi la frontière entre ce qui devait rester natif et ce qui devait être externalisé. Les réflexions ont porté sur les collections, les embeddings, les parseurs et le comportement global du système. L'enjeu est de ne pas subir les limites de l'outil sur des cas plus ambitieux. Ce travail a préparé une approche plus découplée entre UI, indexation et recherche.