Ce que les IA devraient vraiment savoir : et si elles arrêtaient de tout oublier ?

UNE IA QUI OUBLIE TOUT : LE PROBLÈME DES SYSTÈMES ACTUELS

Quand tu poses une question à une intelligence artificielle aujourd’hui, elle fouille dans ses documents, construit une réponse, et puis… pouf . Tout disparaît. Demain, si tu reposes la même question sous une autre forme, elle recommence tout à zéro, comme si c’était la première fois. Ce n’est pas juste une question de coût ou de rapidité. C’est une question de compréhension qui ne s’accumule jamais.

Prenons l’exemple d’un assureur qui travaille sur des contrats d’assurance habitation. Un jour, tu lui demandes : « Quel est le seuil d’inspection des toits ? ». Il te répond « 15 ans » en te montrant la clause exacte. Puis tu changes un mot dans ta question : « Quel est le seuil d’inspection des toits pour une nouvelle affaire ? ». Et là… surprise . Il te répond « 20 ans » sans comprendre qu’il y a une exception pour les nouvelles affaires. Pourquoi ? Parce que son système de Recherche augmentée (RAG) ne garde aucune trace de ce qu’il a déjà compris. Chaque question est traitée comme si c’était la première fois.

Le problème n’est pas dans la technologie elle-même. Le RAG fonctionne très bien pour trouver des informations dans des documents. Le problème, c’est l’architecture. Il n’y a aucun endroit dans un système RAG classique où la compréhension peut s’accumuler. Aucun mécanisme pour que l’IA retienne ce qu’elle a appris d’une question à l’autre. Résultat : chaque réponse est un travail de Sisyphe, sans progrès durable.

LE CHERCHEUR QUI OUBLIE SES NOTES : L’ANALOGIE QUI TOUT EXPLIQUE

Imagine un chercheur dans un bureau avec une armoire remplie de dossiers. Tu lui poses une question : « Quelle est la politique de remboursement des frais de déplacement ? ». Il ouvre l’armoire, sort quatre dossiers, lit les passages pertinents, et te donne une réponse détaillée. Puis il range les dossiers, jette ses notes, et oublie tout. Le lendemain, tu lui reposes la même question, et il recommence exactement le même processus.

C’est exactement ce que fait un système RAG classique. Chaque question déclenche une nouvelle recherche, une nouvelle analyse, un nouveau coût en temps et en argent. Mais un bon chercheur ne fonctionne pas comme ça. Quand il lit un dossier, il prend des notes, il synthétise les informations, et il les organise pour les retrouver plus facilement ensuite. Il construit une mémoire durable de ce qu’il a appris.

Ce que propose cette nouvelle architecture, c’est de transformer l’IA en ce chercheur méthodique. Au lieu de tout recommencer à chaque question, elle construit une base de connaissances qui s’enrichit avec le temps. Elle ne se contente plus de récupérer des informations : elle comprend et elle mémorise.

TROIS COUCHES POUR UNE MÉMOIRE QUI DURE : L’ARCHITECTURE RÉVOLUTIONNAIRE

Cette nouvelle approche ne remplace pas le RAG. Elle lui ajoute une couche de mémoire persistante. Imagine trois étages dans un immeuble :

• 1. La couche des preuves (Evidence Layer) : C’est le sous-sol. C’est là que sont stockés les documents originaux, intacts et non modifiés. Si tu veux la clause exacte d’un contrat, c’est ici que tu la trouves. Cette couche est optimisée pour la recherche précise, comme un moteur de recherche ultra-rapide.
• 2. La couche de la connaissance (Knowledge Layer) : C’est le rez-de-chaussée. C’est là que l’IA construit sa compréhension du domaine. Elle ne stocke pas les documents bruts, mais des pages structurées qui expliquent les concepts, les décisions, les contradictions et les relations entre les idées. Ces pages sont générées à partir des documents, mais elles sont interprétations durables, pas des copies temporaires.
• 3. L’orchestrateur (Orchestrator) : C’est le concierge. C’est lui qui décide où envoyer chaque question. Une question sur une clause précise ? Il l’envoie à la couche des preuves. Une question sur le pourquoi d’une décision ? Il l’envoie à la couche de la connaissance. Il connaît les règles du jeu et guide les autres couches en conséquence.

La règle d’or de cette architecture ? Une page de connaissance n’est jamais une source. Elle est toujours traçable à une source. Si tu ne peux pas remonter à la clause exacte qui a inspiré une page, alors cette page est dangereuse. Elle devient une affirmation sans preuve, un château de cartes prêt à s’effondrer.

LES DÉCISIONS : LE CŒUR BATTANT DE LA MÉMOIRE

Dans la couche de connaissance, l’élément le plus important est l’objet décision. Une décision, c’est bien plus qu’une simple règle. C’est un document structuré qui contient :

• Le libellé de la règle (« Inspecter le toit si plus de 15 ans dans la zone H3 »)
• La portée de la règle (« Applicable uniquement aux nouveaux contrats dans la zone H3 »)
• La date d’effet (« En vigueur depuis le 1er novembre 2025 »)
• Le propriétaire responsable (« D. Lindqvist, responsable de la souscription habitation »)
• La justification (« Parce que entre 15 et 20 ans, le risque de déplacement du toit est 3,4 fois plus élevé dans la bande de vent sévère »)
• La source de la justification (« Email entre l’analyste et le responsable, INS-SYN-018 »)

Pourquoi est-ce si important ? Parce que les règles seules ne suffisent pas. Ce qui compte, c’est le pourquoi derrière la règle. Dans notre exemple, si l’IA ne garde que « 15 ans », elle oubliera le contexte crucial : cette règle ne s’applique qu’à une zone géographique précise. Et un jour, quelqu’un pourrait appliquer cette règle à tort à tout le portefeuille d’assurances, déclenchant des milliers d’inspections inutiles et des plaintes de clients.

Le système doit donc préserver non seulement les règles, mais aussi les raisons qui les sous-tendent. C’est ça, la différence entre une IA qui répond mécaniquement et une IA qui comprend vraiment son domaine.

LES CONTRADICTIONS : QUAND LES DOCUMENTS SE DISPUTENT

Dans un vrai corpus de documents maintenu par plusieurs équipes, les contradictions sont la norme, pas l’exception. Deux équipes écrivent deux documents, tous deux valides, et ils ne sont pas d’accord. Par exemple :

• Un document dit : « Les frais de traçage et d’accès sont couverts par défaut dans Hearthmere, jusqu’à 5 000 €. » (INS-SYN-012, novembre 2025)
• Un autre document dit : « Le traçage et l’accès sont une garantie optionnelle (HS-TA-01). Si elle n’apparaît pas sur le contrat, les coûts ne sont pas remboursables. » (INS-SYN-008, janvier 2026)

Les deux documents sont en vigueur en même temps. Aucun ne remplace l’autre. Ils ont été écrits par des équipes différentes, à des dates différentes. Que faire ?

La réponse est simple : ne pas choisir. Le système doit présenter les deux positions, avec leurs sources, et indiquer clairement que la question n’est pas résolue. Il ne doit pas préférer le document le plus récent, car la récence n’est pas un critère d’applicabilité. C’est ça, la différence entre un système qui ment par omission et un système qui dit honnêtement : « Je ne sais pas, voici les deux versions. »

Cette approche est radicalement différente de ce que font la plupart des systèmes actuels. La plupart des IA choisiraient une réponse par défaut, souvent la plus récente, sans avertir l’utilisateur. Ici, la transparence est totale. Le système ne cache pas les contradictions : il les expose et les gère.

LE MODÈLE DE DONNÉES : COMMENT STRUCTURER LA MÉMOIRE

Pour que cette architecture fonctionne, il faut un modèle de données rigoureux. Voici les principaux objets et leurs relations :

• Concepts : Les idées clés du domaine. Par exemple, « zone H3 », « inspection de toit », « traçage et accès ». Chaque concept a un identifiant unique, un titre, et une liste d’alias (pour gérer les synonymes comme « ACV » ou « valeur amortie »).
• Sources : Les documents originaux, intacts. Chaque source a un identifiant, un titre, et un contenu vectoriel (une représentation numérique qui permet de faire des recherches sémantiques).
• Décisions : Les règles structurées avec leur justification, comme expliqué précédemment.
• Contradictions : Les paires de déclarations contradictoires, avec leurs sources, leurs dates d’effet, et une explication sur pourquoi elles ne sont pas résolues.
• Processus : Les procédures opérationnelles, comme « comment traiter une nouvelle demande d’assurance ».

Chaque objet a un identifiant unique et peut être référencé par d’autres. Par exemple, une décision peut pointer vers une source pour sa justification, ou une contradiction peut lister les deux déclarations en conflit.

Ce modèle permet de construire une base de connaissances qui est à la fois structurée et traçable. Chaque information peut être remontée à sa source, et chaque décision peut être comprise dans son contexte.

L’IMPORTANCE DES ALIAS : NE PAS SE PERDRE DANS LES SYNONYMES

Un des pièges les plus courants dans la gestion de la connaissance, c’est la fragmentation due aux synonymes. Par exemple :

• « base de règlement en espèces »
• « valeur amortie »
• « ACV » (Actual Cash Value)

Sans gestion des alias, chaque terme devient une page séparée dans le wiki. Résultat : le système se fragmente en une multitude de pages qui devraient être liées. Pour éviter ça, l’architecture propose une fonction de résolution de concepts qui :

1. Cherche d’abord un identifiant exact (par exemple, « acv »)
2. Si ce n’est pas trouvé, cherche dans les titres et les alias des concepts existants
3. Si plusieurs concepts correspondent, utilise la similarité sémantique (dans une version avancée) ou une étape d’arbitrage par IA pour résoudre l’ambiguïté

Dans la version de démonstration, le système s’arrête à la correspondance d’alias. Dans une version de production, il ajouterait une étape d’embedding et une validation par modèle de langage pour gérer les cas ambigus.

LA COUCHE DES PREUVES : OÙ TOUT COMMENCE

La couche des preuves est le socle de l’architecture. C’est ici que sont stockés les documents originaux, sous forme de fichiers PDF intacts et de métadonnées d’ingestion. Chaque document est décomposé en fragments (chunks) qui sont ensuite vectorisés (transformés en nombres pour permettre des recherches sémantiques).

Les métadonnées d’ingestion sont cruciales. Elles contiennent :

• L’identifiant du document
• L’identifiant du workspace (l’espace de travail)
• Le numéro de fragment
• Le vecteur de contenu (une liste de nombres représentant le sens du fragment)
• La date d’ingestion et la version du modèle utilisé

Ces métadonnées permettent de suivre l’historique de chaque fragment et de garantir que le système peut toujours retrouver la source exacte d’une information. Même si un bug d’ingestion survient, les documents originaux sont conservés grâce à la gestion des versions et à la suppression différée (les fichiers sont gardés 30 jours avant d’être définitivement effacés).

Le stockage est organisé en deux dossiers principaux :

• raw-sources/{workspace-id}/{document-id}/ : Contient le fichier PDF original et les métadonnées d’ingestion.
• wiki-export/{workspace-id}/ : Contient les pages Markdown générées (Concepts, Décisions, Contradictions, Sources, etc.).

LA RECHERCHE VECTORIELLE : TROUVER LE SENS, PAS JUSTE LES MOTS

Quand un utilisateur pose une question, le système doit trouver les fragments les plus pertinents dans la couche des preuves. Pour ça, il utilise deux types de recherche :

1. Recherche lexicale (BM25) : C’est la recherche classique, comme sur Google. Elle cherche les mots exacts dans les documents.
2. Recherche vectorielle : Elle utilise les vecteurs de contenu pour trouver des fragments sémantiquement proches, même si les mots ne sont pas identiques. Par exemple, elle peut faire le lien entre « inspection de toit » et « contrôle de couverture ».

La recherche vectorielle est implémentée avec Azure AI Search, qui permet de faire des requêtes hybrides (lexicales + vectorielles) en une seule opération. Voici un exemple de code Python qui montre comment ça fonctionne :

from azure.search.documents.models import VectorizedQuery

vector_query = VectorizedQuery(
    vector=self.model.embed(query),
    knearestneighbors=max(top_k, 10),
    fields="content_vector",
)

results = self.client.search(
    search_text=query,                      # recherche lexicale
    vectorqueries=[vectorquery],          # recherche vectorielle
    filter=f"workspaceid eq '{self.workspaceid}'",  # filtrage par espace de travail
    select=["id", "sourceid", "title", "content", "chunknumber"],
    top=top_k,
)

Ce code montre comment le système combine les deux types de recherche pour trouver les fragments les plus pertinents. Le paramètre knearestneighbors permet de contrôler le nombre de résultats à retourner, avec un minimum de 10 pour garantir une bonne couverture.

LA SÉCURITÉ : PROTÉGER LES DONNÉES COMME UNE FORTERESSE

Dans une architecture où les données sont sensibles (comme des contrats d’assurance ou des informations clients), la sécurité est cruciale. Voici les mesures mises en place :

• Filtrage par espace de travail : Chaque requête est filtrée par l’identifiant de l’espace de travail, pour s’assurer que les utilisateurs ne voient que les documents auxquels ils ont accès.
• Clé partagée désactivée : La propriété allowSharedKeyAccess: false dans Azure Storage empêche l’accès aux chaînes de connexion, réduisant ainsi les risques de fuite de données.
• Partitionnement des données : Dans Cosmos DB, les données sont partitionnées par /workspace_id, ce qui permet une isolation stricte entre les différents espaces de travail.
• Rôles Azure RBAC : Les permissions sont gérées via des rôles Azure Role-Based Access Control (RBAC). Par exemple, un rôle « contributeur de données » est attribué à une identité Azure, avec des permissions strictement limitées.

Voici un exemple de définition d’un rôle Cosmos DB en Bicep (le langage d’infrastructure d’Azure) :

resource cosmosDataRole 'Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments@2024-11-15' = {
  parent: cosmos
  name: guid(cosmos.id, identity.id, 'data-contributor')
  properties: {
    principalId: identity.properties.principalId
    roleDefinitionId: '${cosmos.id}/sqlRoleDefinitions/00000000-0000-0000-0000-000000000002'
    scope: cosmos.id
  }
}

Ce code crée un rôle qui donne à une identité Azure le droit de contribuer aux données dans une base Cosmos DB, avec un identifiant unique généré à partir des identifiants de la base et de l’identité.

LA COUCHE DE CONNAISSANCE : GÉNÉRER DES PAGES QUI RESTENT

La couche de connaissance est le cœur de la mémoire persistante. Elle est composée de pages structurées (Concepts, Décisions, Contradictions, etc.) qui sont générées à partir des documents de la couche des preuves. Ces pages sont ensuite stockées dans un format lisible par les humains (Markdown) et accessibles via une API.

Les pages sont générées par un processus d’ingestion qui :

1. Lit les documents de la couche des preuves
2. Extrait les informations pertinentes (concepts, décisions, contradictions)
3. Génère des pages Markdown structurées
4. Stocke ces pages dans le système de fichiers ou dans une base de données

Ces pages ne sont pas des copies des documents originaux. Ce sont des interprétations durables qui synthétisent les informations. Par exemple, une page de décision sur le seuil d’inspection des toits ne contiendra pas le texte brut du contrat, mais une reformulation claire de la règle, avec sa portée, sa justification, et son propriétaire responsable.

L’avantage de cette approche ? L’utilisateur peut naviguer dans la base de connaissances comme dans un wiki, mais le système sous-jacent garantit que chaque information est traçable à sa source. C’est comme avoir un plan de métro pour les idées : tu vois les connexions entre les concepts, mais tu peux toujours remonter à l’arrêt d’origine.

L’ORCHESTRATEUR : LE CERVEAU QUI DÉCIDE OÙ ALLER

L’orchestrateur est le composant qui fait le lien entre les différentes couches. Il reçoit une question, analyse son type, et décide où l’envoyer. Par exemple :

• Une question sur une clause précise (« Quelle est la clause 7.3 ? ») → couche des preuves
• Une question sur une décision (« Pourquoi le seuil est-il de 15 ans ? ») → couche de connaissance
• Une question sur une contradiction (« Est-ce que le traçage et l’accès sont couverts ? ») → couche de connaissance (pour voir les deux positions)

L’orchestrateur utilise un modèle de langage pour analyser la question et déterminer le mode de réponse approprié. Les modes possibles sont :

• wiki : Recherche dans la couche de connaissance (concepts, décisions, contradictions)
• evidence : Recherche dans la couche des preuves (documents originaux)
• hybrid : Combinaison des deux

Voici un exemple de requête API qui montre comment utiliser ces modes :

curl -X POST http://localhost:8000/query -H 'Content-Type: application/json' -d '{
  "question": "Quel est le seuil d\'inspection des toits ?",
  "mode": "hybrid"
}'

Dans cet exemple, le système combine une recherche dans les preuves (pour trouver la clause exacte) et dans la connaissance (pour comprendre le contexte et la justification).

LA GESTION DES CONTRADICTIONS : NE PAS CACHER LES DÉSACCORDS

Quand le système détecte une contradiction, il ne la supprime pas et ne choisit pas un camp. Il la stocke dans un registre dédié et l’expose clairement à l’utilisateur. Voici un exemple de réponse à une question qui a une contradiction non résolue :

{
  "answer": "La position n'est PAS RÉSOLUE. La base de connaissances contient une contradiction non résolue couvrant cette question, donc aucune réponse n'est donnée.",
  "warnings": [
    "CONTRADICTION NON RÉSOLUE (con-001) : Traçage et accès - Garantie standard ou optionnelle ? Le système ne choisira pas entre les sources en conflit. Propriétaire : Y. Tanaka (Produit)."
  ],
  "contradictions": [{
    "id": "con-001",
    "status": "unresolved",
    "accountable_owner": "Y. Tanaka (Produit)",
    "statements": [
      {"source_id": "INS-SYN-012", "locator": "Chapitre 7.3",
       "effective_date": "2025-11-01",
       "statement": "Les coûts de traçage et d'accès sont couverts par défaut dans Hearthmere, jusqu'à 5 000 €."},
      {"source_id": "INS-SYN-008", "locator": "HS-TA-01",
       "effective_date": "2026-01-01",
       "statement": "Le traçage et l'accès sont une garantie optionnelle (HS-TA-01). Si elle n'apparaît pas sur le contrat, les coûts ne sont pas remboursables."}
    ],
    "whynotresolved": "Les deux documents sont en vigueur. Aucun ne remplace l'autre. Ils ont été écrits par des équipes différentes. Le Catalogue des Garanties est le document le plus récent, mais la récence n'est pas un critère d'applicabilité."
  }]
}

Cette réponse montre clairement que le système ne prend pas de décision arbitraire. Il expose les deux positions, avec leurs sources et leurs dates d’effet, et indique pourquoi la contradiction n’est pas résolue. C’est une approche radicalement transparente, qui évite les erreurs coûteuses causées par des interprétations erronées.

L’EXPORT OBSIDIAN : TRANSFORMER LA CONNAISSANCE EN UN WIKI

Pour rendre la base de connaissances accessible aux humains, le système peut exporter les pages Markdown dans un format compatible avec Obsidian, un outil populaire pour gérer des wikis personnels. L’export crée une structure de dossiers organisée :

obsidian_vault/
  ├── Home.md
  ├── Open Questions.md
  ├── Concepts/          (19 pages)
  ├── Sources/           (21 pages)
  ├── Decisions/         (5 pages)
  ├── Comparisons/       (4 pages)
  ├── Contradictions/    (2 pages : con-001, con-002)
  └── Processes/         (2 pages)

Chaque page est un fichier Markdown qui peut être édité, annoté, et lié à d’autres pages. Par exemple, une page de décision sur le seuil d’inspection des toits peut contenir des liens vers les concepts « zone H3 » et « inspection de toit », ainsi que vers la source INS-SYN-018 qui contient la justification.

Cet export permet aux utilisateurs de naviguer dans la base de connaissances comme dans un wiki classique, tout en garantissant que chaque information reste traçable à sa source. C’est une interface conviviale pour une architecture technique complexe.

LES API : COMMENT INTERAGIR AVEC LE SYSTÈME

Le système expose plusieurs endpoints API pour interagir avec les différentes couches. Voici la liste complète :

GET  /health                  Vérifie que le système est en ligne
GET  /wiki                    Liste les objets, filtrables par type
GET  /wiki/contradictions     Affiche le registre des contradictions
GET  /wiki/{item_id}          Récupère un objet spécifique par son identifiant
POST /query                   Pose une question (avec mode, topk, asof)
POST /ingest/text             Ingest un texte brut
POST /ingest/file             Ingest un fichier (PDF, etc.)
POST /cost-estimate           Estime le coût d'une opération
POST /export/obsidian         Exporte la base de connaissances en Markdown
POST /export/obsidian.zip     Exporte la base de connaissances en archive ZIP

Chaque endpoint est conçu pour être simple et intuitif. Par exemple, pour poser une question, il suffit d’envoyer une requête POST avec un objet JSON contenant la question, le mode de réponse souhaité, et d’autres paramètres optionnels :

{
  "question": "Quel est le seuil d'inspection des toits pour une nouvelle affaire dans la zone H3 ?",
  "mode": "hybrid",
  "top_k": 5,
  "as_of": "2026-02-20"
}

Le paramètre as_of permet de demander la réponse en vigueur à une date précise, ce qui est crucial pour les systèmes où les règles évoluent dans le temps.

L’IMPLEMENTATION AZURE : UN GUIDE PRATIQUE POUR SE LANCER

Cette architecture est conçue pour être vendor-neutral, c’est-à-dire qu’elle peut fonctionner sur n’importe quelle plateforme cloud (Azure, AWS, GCP) ou même en local avec Postgres et pgvector. Mais pour faciliter le déploiement, une implémentation complète est fournie pour Azure, avec tous les services Azure utilisés :

• Microsoft Foundry : La plateforme unifiée pour l’IA et les données (anciennement Azure AI Foundry)
• Azure AI Search : Le moteur de recherche vectorielle et lexicale
• Cosmos DB : La base de données NoSQL pour stocker la couche de connaissance
• FastAPI : Le framework Python pour construire l’application backend

Voici les étapes pour déployer l’application sur Azure :

1. Créer un groupe de ressources : Un conteneur logique pour tous les services Azure.
2. Déployer l’infrastructure : Utiliser Bicep (le langage d’infrastructure d’Azure) pour déployer tous les services nécessaires. Voici un exemple de commande :

az group create -n rg-wikirag-demo -l swedencentral
az deployment group create -g rg-wikirag-demo -f infra/main.bicep -p namePrefix=wikirag

Ce code crée un groupe de ressources nommé rg-wikirag-demo dans la région swedencentral, puis déploie l’infrastructure définie dans le fichier infra/main.bicep avec le préfixe wikirag.

1. Configurer les variables d’environnement : L’application a besoin de plusieurs variables pour fonctionner, comme l’identifiant du client Azure, les clés d’API, etc. Ces variables sont définies dans le fichier de configuration de l’application.
2. Déployer l’application : Une fois l’infrastructure en place, il suffit de déployer le code de l’application FastAPI. L’application est conçue pour être prête à l’emploi, avec une configuration minimale.

L’implémentation Azure inclut aussi des bonnes pratiques pour la production :

• Scalabilité : Configuration des réplicas pour éviter les démarrages à froid (1 réplica chaud pour la production, 0 pour la démo).
• Journalisation : Suivi des opérations et des erreurs pour le débogage.
• Monitoring : Tableaux de bord pour surveiller les performances et les coûts.

LA DÉMONSTRATION : OSTERMERE MUTUAL, UNE ASSURANCE SYNTHÉTIQUE

Pour montrer comment cette architecture fonctionne en pratique, une démonstration complète est fournie. Elle simule une compagnie d’assurance fictive appelée Ostermere Mutual, avec :

• 21 documents interconnectés
• 3 scénarios de démonstration

Les scénarios montrent comment le système gère des questions complexes, comme :

1. Question sur une décision : « Quel est le seuil d’inspection des toits ? » → Le système retourne la décision structurée avec sa justification.
2. Question sur une contradiction : « Est-ce que le traçage et l’accès sont couverts ? » → Le système expose les deux positions sans choisir.
3. Question avec contexte temporel : « Quel seuil s’appliquait à cette propriété le 20 février 2026 ? » → Le système retourne la version du document en vigueur à cette date.

Tout dans cette démonstration est synthétique. Ostermere Mutual n’existe pas. Les documents, les règles, les chiffres, tout est inventé pour l’exemple. L’objectif n’est pas de fournir des conseils en assurance, mais de montrer comment l’architecture gère la complexité, la contradiction, et le temps.

LES OUTILS DE L’ARCHITECTURE : UNE LISTE COMPLÈTE

Pour construire cette architecture, plusieurs outils et bibliothèques sont utilisés. Voici la liste complète, avec une brève description de leur rôle :

• search_evidence() : Recherche dans la couche des preuves (documents originaux).
• search_wiki() : Recherche dans la couche de connaissance (pages structurées).
• get_concept() : Récupère un concept par son identifiant ou ses alias.
• check_contradictions() : Vérifie si une question touche une contradiction non résolue.
• proposewikipatch() : Propose une modification à une page de la couche de connaissance (nécessite une validation).
• applyapprovedpatch() : Applique une modification validée à une page de la couche de connaissance.
• exportobsidianvault() : Exporte la base de connaissances en format Obsidian.

Ces outils sont exposés via l’API et peuvent être utilisés par l’orchestrateur ou directement par les utilisateurs avancés.

LE MODÈLE DE LANGAGE : COMMENT L’IA GÉNÈRE SES RÉPONSES

Le système utilise un modèle de langage (comme ceux d’OpenAI) pour générer les réponses. Mais au lieu de donner directement le modèle aux documents bruts, il lui fournit un contexte structuré généré par l’orchestrateur. Ce contexte contient :

• Les fragments pertinents de la couche des preuves
• Les pages pertinentes de la couche de connaissance
• Les avertissements sur les contradictions non résolues

Voici un exemple de code Python qui montre comment appeler le modèle de langage avec Azure OpenAI :

from openai import OpenAI
from azure.identity import DefaultAzureCredential, getbearertoken_provider

credential = getbearertoken_provider(
    DefaultAzureCredential(),
    "https://cognitiveservices.azure.com/.default"
)

client = OpenAI(
    base_url="https://YOUR-RESOURCE.openai.azure.com/openai/v1/",
    api_key=credential
)

response = client.responses.create(
    model="YOUR-CHAT-DEPLOYMENT",
    input=prompt
)

Dans ce code, YOUR-RESOURCE est remplacé par le nom de votre ressource Azure OpenAI, et YOUR-CHAT-DEPLOYMENT par le nom de votre déploiement de modèle de chat. Le token d’API est récupéré automatiquement via Azure Identity, ce qui évite de stocker des clés en dur dans le code.

LA CONFIGURATION DE PRODUCTION : CE QU’IL FAUT SAVOIR

Pour déployer cette architecture en production, plusieurs considérations sont importantes :

• Scalabilité : L’application doit être configurée pour gérer la charge. Par exemple, le nombre de réplicas de l’application FastAPI peut être ajusté en fonction du trafic.
• Coûts : Azure AI Search et Cosmos DB ont des coûts liés à l’utilisation. Il faut surveiller les requêtes vectorielles et le stockage des données.
• Sécurité : Les identités Azure doivent être configurées avec les permissions minimales nécessaires. Les clés partagées doivent être désactivées.
• Sauvegardes : Les données critiques (documents originaux, base de connaissances) doivent être sauvegardées régulièrement.
• Mises à jour : Les modèles de langage et les services Azure évoluent. Il faut prévoir un processus de mise à jour des dépendances.

Voici un exemple de configuration de scalabilité en Bicep :

scale: {
  minReplicas: minReplicas  // 1 réplica chaud pour la production
  maxReplicas: 3            // jusqu'à 3 réplicas pour gérer la charge
}

Cette configuration permet à l’application de démarrer rapidement (grâce au réplica chaud) et de monter en charge si nécessaire.

LES PERFORMANCES : COMMENT MESURER L’IMPACT

Pour évaluer l’efficacité de cette architecture, plusieurs métriques peuvent être suivies :

• Temps de réponse : Le temps nécessaire pour répondre à une question. Avec la mémoire persistante, ce temps devrait diminuer au fil des questions similaires.
• Coût par requête : Le coût en tokens et en ressources pour répondre à une question. La mémoire persistante réduit ce coût en évitant de refaire le même travail.
• Taux de résolution des contradictions : Le pourcentage de contradictions qui sont finalement résolues (par exemple, par une décision de la direction).
• Satisfaction utilisateur : Des enquêtes ou des retours peuvent être collectés pour évaluer l’utilité perçue du système.

Une comparaison avec un système RAG classique montre l’avantage de cette architecture :

• RAG simple = Question × Transformation (Q × Tr)
• Hybride classique = Question × (Transformation wiki + Vectorisation × Transformation vectorielle) (Q × (Tw + V × Tv))
• Cette architecture = Décision × Temps × Mémoire (D × Td × M)

La formule D × Td × M représente l’accumulation de la compréhension au fil du temps. Chaque décision prise et mémorisée rend les questions suivantes plus faciles et moins coûteuses.

LES LIMITES ET LES DÉFIS : CE QU’IL FAUT ANTICIPER

Aucune architecture n’est parfaite. Voici les principaux défis à anticiper :

• Maintenance de la base de connaissances : Les pages de la couche de connaissance doivent être mises à jour quand les documents sources changent. Cela nécessite un processus d’ingestion régulier et une validation humaine.
• Gestion des ambiguïtés : Quand plusieurs concepts correspondent à une question, le système doit choisir le bon. Dans la version de démonstration, cela se fait par alias. En production, une étape d’embedding et une validation par IA sont nécessaires.
• Performance à grande échelle : Quand la base de connaissances devient très grande, les recherches peuvent devenir lentes. Des optimisations comme le partitionnement ou la mise en cache sont nécessaires.
• Sécurité des données : Les données sensibles doivent être protégées. Les bonnes pratiques Azure (RBAC, chiffrement, etc.) doivent être suivies.
• Adoption par les utilisateurs : Les utilisateurs doivent comprendre comment utiliser le système. Une formation et une documentation claire sont essentielles.

Malgré ces défis, l’architecture offre un avantage majeur : elle transforme une IA qui oublie tout en une IA qui apprend et se souvient. C’est un changement de paradigme qui peut révolutionner la façon dont les entreprises utilisent l’IA pour gérer leur connaissance.

POUR QUI EST FAITE CETTE ARCHITECTURE ?

Cette architecture est conçue pour trois types d’utilisateurs :

• Les entreprises avec des corpus de documents complexes : Assurances, banques, cabinets d’avocats, administrations… Toute organisation qui doit gérer des règles, des contrats, des procédures, et où la compréhension durable est cruciale.
• Les développeurs qui veulent aller au-delà du RAG classique : Si tu as déjà utilisé RAG et que tu veux passer à l’étape suivante, cette architecture te montre comment ajouter une mémoire persistante à ton système.
• Les architectes cloud qui cherchent des bonnes pratiques : L’implémentation Azure fournit un exemple concret de déploiement, avec des services éprouvés et des configurations optimisées pour la production.

Si tu fais partie de l’un de ces groupes, cette architecture peut t’aider à construire une IA qui ne se contente pas de répondre aux questions : elle comprend et elle retient.

COMMENT DÉBUTER : UNE FEUILLE DE ROUTE PRATIQUE

Si tu veux tester cette architecture par toi-même, voici une feuille de route étape par étape :

1. Cloner le dépôt GitHub : Le code complet, l’infrastructure, et le jeu de données de démonstration sont disponibles sur github.com/mcekikj/persistent-knowledge-layer sous licence MIT.
2. Installer les dépendances : Python, Azure CLI, Bicep, et les outils nécessaires pour déployer l’infrastructure.
3. Configurer ton environnement Azure : Crée un groupe de ressources, configure les permissions, et déploie l’infrastructure avec la commande az deployment group create.
4. Déployer l’application : Une fois l’infrastructure en place, déploie le code de l’application FastAPI.
5. Tester avec le jeu de données de démonstration : Pose des questions, explore la base de connaissances, et vois comment le système gère les contradictions et le contexte temporel.
6. Adapter à ton propre corpus : Remplace le jeu de données de démonstration par tes propres documents, et configure l’application pour ton domaine spécifique.

Cette architecture n’est pas un produit clé en main. C’est un modèle que tu peux adapter à tes besoins. Le dépôt GitHub fournit tout ce dont tu as besoin pour démarrer, mais c’est à toi de le configurer pour ton cas d’usage spécifique.

LE FUTUR : VERS UNE IA QUI COMPREND VRAIMENT

Cette architecture est une première étape vers une IA qui ne se contente pas de récupérer des informations, mais qui comprend et retient. Les possibilités sont immenses :

• Assistants juridiques : Des IA qui comprennent les contrats, les lois, et les jurisprudences, et qui retiennent les évolutions législatives.
• Médecine : Des systèmes qui accumulent la connaissance médicale au fil du temps, avec les justifications derrière chaque recommandation.
• Recherche scientifique : Des IA qui synthétisent les publications scientifiques et retiennent les hypothèses, les résultats, et les contradictions.
• Gestion de projet : Des outils qui retiennent les décisions prises, les raisons, et les impacts sur le projet.

Le potentiel est énorme, mais le plus important, c’est que cette architecture répond à un besoin fondamental : l’IA doit arrêter de tout oublier. Chaque question ne doit plus être une répétition du passé. Chaque réponse doit enrichir la compréhension future.

EN RÉSUMÉ : CE QU’IL FAUT RETENIR

Voici les points clés à retenir de cette architecture révolutionnaire :

• Le problème : Les systèmes RAG actuels oublient tout après chaque question. Chaque réponse est un travail de Sisyphe.
• La solution : Ajouter une couche de mémoire persistante qui accumule la compréhension au fil du temps.
• L’architecture : Trois couches (preuves, connaissance, orchestrateur) qui travaillent ensemble.
• Les décisions : Stocker les règles avec leurs justifications, leurs portées, et leurs propriétaires.
• Les contradictions : Les exposer clairement, sans choisir de camp.
• L’implémentation : Une solution complète sur Azure, avec un guide de déploiement prêt à l’emploi.
• Le futur : Une IA qui comprend et retient, pas seulement qui récupère.

Cette architecture n’est pas une simple amélioration du RAG. C’est un changement de paradigme qui peut transformer la façon dont les entreprises utilisent l’IA pour gérer leur connaissance. Si tu veux que ton IA arrête de tout oublier, c’est par ici qu’il faut commencer.