Documentation et mémoire IA : pourquoi vos agents ne doivent pas repartir de zéro

La plupart des équipes abordent encore l'IA par le prompt.

Elles apprennent à mieux formuler une demande, à ajouter plus de détails, à découper une tâche, à demander une réponse structurée. Tout cela aide. Mais dès que l'on travaille avec des agents IA sur des projets réels, le prompt n'est plus le sujet principal.

Le vrai sujet devient le contexte.

Un agent IA utile doit comprendre ce que l'équipe essaie de faire, ce qui a déjà été décidé, quelles contraintes doivent être respectées, quels chemins ont déjà été explorés, quelles préférences ont émergé, et quelles erreurs ne doivent pas être répétées. Ce contexte ne peut pas vivre uniquement dans une conversation temporaire.

Cet article est ancré au 30 avril 2026.

Il repose sur deux fondations complémentaires :

• la documentation, qui donne une source de vérité partagée ;
• la mémoire de l'agent, qui donne une continuité de travail entre les sessions.

La documentation empêche l'IA d'inventer le projet. La mémoire l'empêche de l'oublier.

Pourquoi ce sujet devient critique avec les agents IA

Tant que l'IA sert seulement à reformuler un texte ou résumer une réunion, un contexte imparfait reste tolérable. Le risque est limité : une réponse générique, un résumé un peu plat, une recommandation à vérifier.

Avec les agents IA, la surface change.

Un agent peut lire des documents, parcourir un backlog, analyser un dépôt, proposer des changements, ouvrir des tickets, préparer une pull request, appeler des tools, ou contribuer à un workflow de delivery. Il ne se contente plus de répondre ; il participe à l'exécution.

Dans ce contexte, l'amnésie devient coûteuse.

Un agent qui repart de zéro à chaque conversation peut :

• reproposer une approche déjà refusée ;
• ignorer une contrainte métier connue de l'équipe ;
• oublier une convention de code ou de delivery ;
• contredire une décision d'architecture ;
• utiliser une documentation obsolète comme si elle était fiable ;
• confondre une préférence personnelle avec une règle d'équipe ;
• perdre du temps à redécouvrir ce qui a déjà été compris.

Ce n'est pas seulement un problème de confort. C'est un problème de qualité, de confiance et de gouvernance.

La recherche autour du RAG a montré très tôt que les grands modèles gagnent en factualité quand ils peuvent s'appuyer sur une mémoire externe explicite, plutôt que sur leurs seuls paramètres. Le papier fondateur "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" explique déjà cette tension : les modèles pré-entraînés contiennent de la connaissance, mais ont des limites lorsqu'il faut accéder précisément à des informations, les mettre à jour et fournir une provenance.

Pour les équipes, la leçon est simple : plus le travail est spécifique, plus l'IA doit être reliée à des sources vivantes.

Documentation et mémoire ne sont pas la même chose

On mélange souvent documentation, contexte, historique, mémoire et base de connaissance. C'est compréhensible, mais dangereux.

Ces couches ne jouent pas le même rôle.

La documentation est faite pour être partagée, relue, gouvernée et citée. Elle doit être compréhensible par un humain qui arrive dans le projet dans trois mois.

La mémoire d'un agent est différente. Elle sert à préserver ce que l'agent a appris dans la pratique : comment vous aimez travailler, quelles hypothèses ont été corrigées, quels raccourcis sont risqués dans votre codebase, quels sujets reviennent souvent, quelles formulations vous font perdre du temps.

Une bonne mémoire ne remplace pas la documentation. Elle réduit la friction entre les documents, l'historique et le travail du moment.

La documentation donne une source de vérité à l'IA

Une IA ne sait pas naturellement ce qui est vrai dans votre projet.

Elle peut connaître des patterns généraux, des bonnes pratiques, des APIs publiques, des frameworks, des méthodes de gestion de projet. Mais elle ne connaît pas vos arbitrages. Elle ne sait pas pourquoi vous avez choisi une architecture imparfaite mais volontaire. Elle ne sait pas quelle contrainte client a obligé l'équipe à garder un flux plus complexe. Elle ne sait pas qu'une option élégante a déjà été testée et abandonnée.

Cette connaissance doit être écrite quelque part.

Pour un agent IA, une documentation utile n'est pas une bibliothèque décorative. C'est une surface de travail.

Elle doit contenir :

• les objectifs actifs du projet ;
• les contraintes métier et techniques ;
• les décisions importantes et leur justification ;
• les conventions de code, de nommage, de revue et de delivery ;
• les runbooks et procédures répétables ;
• les critères de validation ;
• les risques connus ;
• les responsabilités et zones d'ownership ;
• les liens entre specs, tickets, livrables et décisions.

Quand ces éléments sont absents, l'agent comble les trous.

Et comme un modèle de langage est très bon pour produire une réponse plausible, le danger n'est pas toujours une erreur évidente. Le danger est une réponse qui sonne juste mais qui ignore le vrai contexte.

La documentation doit être vivante, pas parfaite

Le piège classique consiste à penser qu'une bonne documentation est une documentation exhaustive.

En pratique, une documentation exhaustive mais morte est souvent moins utile qu'une documentation plus courte, mieux structurée et régulièrement revue. Pour l'IA comme pour les humains, le problème n'est pas seulement d'avoir des documents. C'est de savoir lesquels sont fiables.

Une page obsolète peut faire plus de dégâts qu'une page absente.

Avec des agents IA, ce problème s'amplifie. Un humain peut parfois sentir qu'une page n'a pas l'air à jour. Un agent, lui, peut très bien récupérer un fragment ancien, le traiter comme une vérité, puis construire une réponse entière dessus.

C'est pour cela que les pratiques documentaires deviennent aussi importantes que la génération elle-même :

• dater les documents ;
• identifier un propriétaire ;
• distinguer brouillon, en revue, approuvé et obsolète ;
• relier une décision à ses conséquences ;
• utiliser des titres et sections prévisibles ;
• éviter les pages fourre-tout ;
• supprimer ou archiver ce qui n'est plus vrai ;
• garder les documents proches du travail réel.

Microsoft décrit le RAG comme une architecture qui repose sur des contenus indexés et récupérés pour fournir des données d'ancrage aux réponses génératives. Mais la qualité du résultat dépend de la qualité du contenu, de son découpage, de la recherche et du ranking. Autrement dit : si la base documentaire est confuse, le RAG ne devient pas magique. Il devient une façon plus rapide de retrouver de la confusion.

Pourquoi la documentation se périme (et comment les agents la tiennent à jour)

Une documentation périmée n’est pas un problème de discipline, c’est un problème de physique. Une page est écrite une fois, au moment où l’équipe comprend quelque chose ; le système continue de changer ; rien n’oblige la page à changer avec lui. L’écart s’ouvre en silence, et on le découvre au pire moment — quand quelqu’un, ou un agent, agit sur l’ancienne version.

Quatre mécanismes produisent la plupart des pages périmées :

• La distance avec le travail. Un wiki à trois clics des cartes et du code n’est sur le chemin de personne. Une documentation qui vit à côté du travail — sur le projet, reliée depuis la carte — est lue, donc corrigée.
• Ni propriétaire, ni date. Une page sans responsable nommé et sans date de relecture visible n’a personne à qui s’adresser et aucun signal qu’elle est vieille. Les deux coûtent peu et changent immédiatement le comportement du lecteur.
• Aucun déclencheur. Le code a des tests et une CI ; la documentation n’a rien qui échoue quand elle dérive. La solution est de lui donner des déclencheurs : une décision enregistrée sur une carte, un changement fusionné, une mission close devraient chacun demander « quelle page est-ce que ça rend fausse ? ».
• Une culture de l’écriture seule. Les équipes récompensent l’écriture de pages, jamais l’élagage. Une page fourre-tout vraie à 60 % est pire qu’une page courte entièrement vraie, parce que le lecteur ne sait pas lesquels 60 %.

C’est là que les agents gagnent leur place. Un agent qui exécute des missions sur le projet voit le changement se produire : il peut signaler la page qu’un changement fusionné contredit, proposer la modification avec la preuve, et marquer la page comme relue une fois qu’un humain a validé. La boucle que les humains oublient — changer, remarquer, mettre à jour — devient une mission avec une trace. Et parce que l’agent lit la même documentation pour travailler, il a un intérêt direct à sa fraîcheur : une page périmée lui coûte une mauvaise réponse.

Les pratiques ci-dessus (dates, propriétaires, états, suppression) restent nécessaires. Ce que les agents ajoutent, c’est la partie qui n’a jamais passé à l’échelle : remarquer.

La mémoire empêche l'agent de recommencer à zéro

La documentation répond à la question : "Qu'est-ce qui est vrai pour l'équipe ?"

La mémoire répond à une autre question : "Qu'est-ce que l'agent a déjà appris en travaillant avec nous ?"

Sans mémoire, même un agent connecté à une bonne documentation reste limité.

Il peut lire une spec. Il peut consulter une décision. Il peut récupérer un runbook. Mais il ne se souvient pas forcément que, la semaine dernière, vous lui avez demandé trois fois d'éviter un certain style de solution. Il ne sait pas qu'une proposition a été rejetée parce qu'elle était trop lourde pour le stade du produit. Il ne conserve pas naturellement le fil des corrections que vous lui avez données.

Résultat : vous repassez votre temps à réexpliquer.

La mémoire agent sert à capturer les apprentissages qui ne méritent pas toujours une page de documentation officielle, mais qui changent fortement la qualité de l'assistance :

• "L'équipe préfère des PR petites et faciles à relire."
• "Pour ce projet, éviter les abstractions prématurées."
• "Les changements de permissions doivent toujours être traités comme sensibles."
• "Cette API externe a une documentation incomplète ; vérifier les comportements en test."
• "Les décisions produit doivent être reliées à une mission active."
• "L'utilisateur préfère un résumé court puis les détails si nécessaire."

OpenAI documente cette idée avec les mémoires sauvegardées et la référence à l'historique de chat : certaines informations peuvent être utilisées pour rendre les réponses futures plus personnalisées, avec des contrôles pour les consulter, les supprimer ou les désactiver. Anthropic, côté Claude Code, distingue aussi les instructions persistantes écrites par l'équipe et l'auto-mémoire que l'agent accumule à partir des corrections et préférences.

Le point important n'est pas une implémentation particulière. Le point important est le modèle mental : un agent sérieux a besoin de continuité.

Les trois types de mémoire utiles pour une équipe

Pour travailler proprement, il est utile de distinguer plusieurs formes de mémoire.

1. La mémoire sémantique

Elle stocke des faits stables.

Exemples :

• le nom d'un produit ;
• les domaines métier ;
• les conventions principales ;
• les préférences de l'équipe ;
• les règles récurrentes.

Cette mémoire ressemble à une couche de connaissances compactes. Elle est utile pour éviter de répéter les mêmes informations générales.

2. La mémoire épisodique

Elle stocke des événements ou expériences passées.

Exemples :

• une tentative d'implémentation qui a échoué ;
• une conversation où une approche a été refusée ;
• un incident résolu ;
• une décision temporaire prise avant documentation ;
• un bug récurrent déjà investigué.

Cette mémoire est capitale pour les agents qui travaillent sur des tâches longues. Sans elle, ils peuvent reproduire les mêmes explorations coûteuses.

3. La mémoire procédurale

Elle stocke des façons de faire.

Exemples :

• comment lancer les tests ;
• comment préparer une release ;
• comment écrire un ticket ;
• comment structurer une note de décision ;
• quelles étapes suivre avant de toucher une zone sensible.

Cette mémoire rejoint parfois la documentation. La différence est que la mémoire procédurale peut être plus personnalisée, plus proche de l'usage réel, et mise à jour par l'expérience.

LangChain fait une distinction proche entre mémoire court terme et mémoire long terme : la mémoire court terme reste liée à une conversation ou un thread, tandis que la mémoire long terme persiste entre les conversations et peut être rappelée plus tard. Cette séparation est saine : tout ne doit pas être retenu, et tout ce qui est retenu ne doit pas vivre au même endroit.

Le danger d'une mémoire non gouvernée

Dire que la mémoire est importante ne veut pas dire qu'il faut tout mémoriser.

Une mémoire agent non gouvernée peut devenir un problème aussi sérieux qu'une documentation obsolète. Elle peut conserver des préférences dépassées, mélanger des projets, retenir une correction locale comme une règle globale, exposer des informations sensibles, ou influencer les réponses sans que personne ne sache pourquoi.

La mémoire doit donc être traitée comme une capacité produit et organisationnelle, pas comme un simple cache technique.

Une bonne mémoire d'agent doit être :

• visible : l'utilisateur ou l'équipe doit pouvoir savoir ce qui est mémorisé ;
• modifiable : une mémoire incorrecte doit pouvoir être corrigée ;
• supprimable : l'oubli est une fonction essentielle ;
• scopée : une mémoire personnelle, projet et organisation ne doivent pas se mélanger ;
• datée : certaines préférences vieillissent ;
• attribuable : il faut comprendre d'où vient une règle ou une préférence ;
• hiérarchisée : une décision approuvée doit primer sur une préférence déduite ;
• sécurisée : secrets, données personnelles et informations sensibles doivent être filtrés.

La mémoire n'est pas une boîte noire où l'on jette des souvenirs. C'est une couche de contexte avec des droits, des limites et une hygiène.

Documentation officielle vs mémoire de travail

Un bon système distingue ce qui fait autorité de ce qui aide à travailler.

La documentation officielle doit contenir ce que l'équipe accepte comme source de vérité :

• décisions d'architecture ;
• règles de sécurité ;
• spécifications validées ;
• contrats API ;
• procédures opérationnelles ;
• objectifs et contraintes du projet.

La mémoire de travail peut contenir des éléments plus souples :

• préférences de collaboration ;
• retours fréquents ;
• observations récurrentes ;
• hypothèses à vérifier ;
• tentatives passées ;
• conventions implicites en attente de formalisation.

La règle pratique est simple : si une information doit survivre à l'agent, à l'utilisateur et à l'outil, elle doit finir dans la documentation.

La mémoire peut signaler : "Ce point revient souvent, il faudrait le formaliser." Mais elle ne doit pas devenir le seul endroit où vit une règle critique.

Pourquoi la confiance dépend du contexte

Les équipes n'ont pas seulement besoin d'IA plus puissantes. Elles ont besoin d'IA plus vérifiables.

Le sujet de la confiance revient partout dans les usages professionnels.

Dans une analyse publiée en février 2026, Stack Overflow relie explicitement la confiance à des réponses exactes, fiables et enracinées dans un contexte pertinent.

Cela rejoint une intuition très concrète : on ne fait pas confiance à une IA parce qu'elle parle bien. On lui fait confiance quand on comprend :

• quelles sources elle a utilisées ;
• quelles hypothèses elle fait ;
• ce qu'elle ne sait pas ;
• pourquoi elle propose une action ;
• comment vérifier sa réponse ;
• quelle mémoire ou préférence influence son comportement.

La documentation aide à citer et vérifier. La mémoire aide à adapter et poursuivre. Les deux doivent rester inspectables.

Le bon modèle : contexte, mémoire, action, revue

Pour les équipes qui veulent vraiment travailler avec des agents IA, le bon modèle n'est pas "un prompt plus long".

C'est une boucle complète :

1. Contexte : l'agent récupère les documents, tickets, décisions et données pertinentes.
2. Mémoire : il tient compte des apprentissages utiles issus des sessions précédentes.
3. Action : il produit une proposition, un changement, une analyse ou une tâche.
4. Revue : l'humain valide, corrige, rejette ou précise.
5. Mise à jour : ce qui est stable rejoint la documentation ; ce qui est opératoire peut rejoindre la mémoire.

Cette boucle transforme la documentation en système vivant.

Une correction donnée à l'agent ne doit pas disparaître si elle est importante. Une décision prise en conversation ne doit pas rester prisonnière d'un chat. Une préférence temporaire ne doit pas être promue en règle permanente sans validation.

La qualité vient du tri.

Ce qu'il faut documenter pour bien travailler avec l'IA

Si vous voulez améliorer rapidement la qualité de vos agents, commencez par documenter les zones qui réduisent le plus l'ambiguïté.

Le contexte projet

Un document court qui répond à :

• quel problème résout le projet ;
• pour quels utilisateurs ;
• quels objectifs sont prioritaires ;
• ce qui est hors périmètre ;
• quelles contraintes sont non négociables.

Les décisions

Chaque décision importante devrait préciser :

• ce qui a été décidé ;
• pourquoi ;
• quelles alternatives ont été écartées ;
• quels risques sont acceptés ;
• quand la décision doit être revue.

Les Architecture Decision Records restent un très bon format pour cela, mais l'idée vaut aussi pour les décisions produit, go-to-market ou organisationnelles.

Les règles d'exécution

Un agent doit savoir comment travailler dans votre système :

• comment créer ou modifier une tâche ;
• quand demander une approbation ;
• quelles zones sont sensibles ;
• quels tests lancer ;
• quel niveau d'autonomie est acceptable ;
• comment signaler une incertitude.

Les définitions de qualité

Documentez ce qui rend un résultat acceptable :

• définition du terminé ;
• critères de revue ;
• exigences de sécurité ;
• contraintes d'accessibilité ;
• standards de performance ;
• règles de ton ou de communication.

Les runbooks

Les runbooks sont très utiles pour les agents, car ils transforment une procédure fragile en séquence explicite.

Un bon runbook dit :

• quand l'utiliser ;
• quelles préconditions vérifier ;
• quelles étapes suivre ;
• quels résultats attendre ;
• quoi faire en cas d'échec ;
• qui alerter si le risque augmente.

Ce qu'il faut mémoriser

La mémoire doit rester plus sélective.

Tout ne mérite pas d'être mémorisé. Un bon système de mémoire cherche moins à tout conserver qu'à retenir ce qui augmente durablement la qualité des prochaines réponses.

Mémorisez plutôt :

• les préférences stables de l'équipe ;
• les corrections qui se répètent ;
• les erreurs déjà commises par l'agent ;
• les patterns locaux non évidents ;
• les contraintes fréquentes mais pas encore documentées ;
• les workflows préférés par type de tâche ;
• les zones où l'agent doit demander confirmation.

Évitez de mémoriser :

• des secrets ;
• des informations personnelles inutiles ;
• des détails temporaires ;
• des hypothèses non vérifiées ;
• des règles qui contredisent la documentation ;
• de longs blocs de texte qui devraient vivre dans un document.

OpenAI le rappelle dans sa FAQ : la mémoire est pensée pour des préférences et détails de haut niveau, pas pour stocker des templates exacts ou de gros blocs verbatim. C'est une bonne règle générale pour les équipes aussi.

La documentation devient l'interface des agents

Une manière utile de penser ce changement est de considérer la documentation comme une interface.

Avant, la documentation était souvent un lieu de stockage. On écrivait après coup, pour transmettre ou se protéger de l'oubli.

Avec les agents IA, la documentation devient une interface entre :

• les humains et les humains ;
• les humains et les agents ;
• les agents et les outils ;
• les décisions et l'exécution ;
• le présent du projet et sa mémoire longue.

Cela change la façon d'écrire.

Un document destiné à être lu par une IA doit être clair, structuré, daté, relié et peu ambigu. Les sections doivent être nommées simplement. Les décisions doivent être séparées des hypothèses. Les exceptions doivent être explicites. Les liens doivent pointer vers les sources utiles.

Ce n'est pas écrire pour les machines au détriment des humains. C'est souvent l'inverse : une documentation assez claire pour une IA est généralement plus claire pour un nouvel arrivant.

Le lien avec RAG, MCP et les agents

Trois tendances se rejoignent ici.

Le RAG permet aux modèles de récupérer des passages pertinents dans une base documentaire pour ancrer leurs réponses.

Le MCP et les APIs d'agents permettent de connecter les modèles à des ressources, tools et systèmes de travail réels.

La mémoire long terme permet aux agents de conserver une continuité au-delà de la fenêtre de contexte immédiate.

Ces trois couches ne se remplacent pas.

• RAG sans documentation propre : l'agent retrouve du bruit.
• MCP sans gouvernance : l'agent peut agir sans assez de contrôle.
• Mémoire sans source de vérité : l'agent personnalise sur des bases fragiles.
• Documentation sans mémoire : l'agent lit, mais recommence trop souvent de zéro.

Le système devient fiable quand ces couches se renforcent au lieu de se confondre.

Une checklist pour auditer votre maturité

Posez ces questions à votre équipe.

Documentation

• Avons-nous une page de contexte claire pour chaque projet important ?
• Nos décisions critiques sont-elles écrites avec leur justification ?
• Les documents importants ont-ils un propriétaire ?
• Sait-on distinguer un brouillon d'un document approuvé ?
• Les documents obsolètes sont-ils archivés ou signalés ?
• Les agents peuvent-ils retrouver les documents pertinents sans fouiller partout ?

Mémoire

• L'agent conserve-t-il les préférences stables utiles ?
• Peut-on voir ce qu'il a mémorisé ?
• Peut-on corriger ou supprimer une mémoire ?
• Les mémoires sont-elles séparées par utilisateur, projet ou équipe ?
• Les souvenirs temporaires expirent-ils ou sont-ils revus ?
• Les corrections répétées deviennent-elles des règles ou docs formalisées ?

Gouvernance

• L'agent sait-il quand demander une approbation ?
• Les actions sensibles sont-elles tracées ?
• Les sources utilisées sont-elles visibles ?
• Les humains restent-ils responsables des décisions finales ?
• Les données sensibles sont-elles exclues des mémoires ?
• Existe-t-il une revue régulière de la base documentaire ?

Si vous répondez non à la majorité de ces questions, le problème n'est probablement pas votre modèle IA. C'est votre système de contexte.

Ce que cela change pour les équipes

Les équipes qui tirent le meilleur parti de l'IA ne sont pas seulement celles qui utilisent le dernier modèle.

Ce sont celles qui organisent leur travail pour que l'IA puisse être utile sans deviner.

Elles documentent les décisions. Elles gardent les docs proches du delivery. Elles construisent des mémoires inspectables. Elles séparent les préférences personnelles des règles d'équipe. Elles font relire les documents importants. Elles acceptent que certains apprentissages restent en mémoire de travail avant d'être promus en documentation officielle.

Ce n'est pas de la bureaucratie. C'est l'infrastructure minimale d'une collaboration fiable avec des agents.

Le rapport DORA 2024 rappelle d'ailleurs que l'IA peut améliorer la productivité individuelle, le flow et la satisfaction, mais que les fondamentaux d'ingénierie restent déterminants. Atlassian observe de son côté que les développeurs perdent beaucoup de temps dans les frictions, notamment la dette technique et la documentation insuffisante. L'IA peut aider, mais seulement si elle est branchée sur un système de travail lisible.

Conclusion

La documentation et la mémoire sont souvent traitées comme des sujets secondaires.

Avec les agents IA, elles deviennent centrales.

La documentation donne à l'agent une source de vérité. La mémoire lui donne une continuité. La revue humaine lui donne une limite. La gouvernance relie l'ensemble.

Sans documentation, l'IA improvise.

Sans mémoire, elle oublie.

Sans revue, elle peut agir trop vite.

Le futur du travail avec l'IA ne dépendra donc pas seulement de modèles plus puissants. Il dépendra aussi de systèmes de contexte plus propres : des documents vivants, des mémoires gouvernées, des sources citées, des décisions traçables, et des agents capables d'apprendre sans devenir opaques.

La bonne question n'est plus seulement : "Quel modèle utilisons-nous ?"

La vraie question devient : "Quel système de mémoire et de documentation donnons-nous à nos agents pour qu'ils travaillent avec nous, et pas à côté de nous ?"

FAQ

Quelle est la différence entre documentation et mémoire pour un agent IA ?

La documentation est la source de vérité partagée, écrite pour durer et relue ; la mémoire est ce que l’agent retient d’une mission à l’autre (préférences, décisions, contexte de travail). La première se gouverne comme un document ; la seconde comme une donnée qui expire.

Comment éviter qu’un agent IA s’appuie sur une documentation périmée ?

Dater les pages, nommer un propriétaire, distinguer brouillon / en revue / approuvé / obsolète, et donner à l’agent des déclencheurs : un changement fusionné ou une décision enregistrée doit lui faire proposer la mise à jour de la page qu’ils contredisent.

Faut-il un RAG pour que les agents lisent la documentation ?

Un RAG rend la documentation interrogeable ; il ne la rend pas juste. Si la base est confuse, le RAG retrouve la confusion plus vite. La qualité du contenu, du découpage et de la fraîcheur compte avant l’architecture.

Références et lectures complémentaires

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Patrick Lewis et al., NeurIPS 2020.
• RAG and Generative AI avec Azure AI Search, Microsoft Learn.
• Memory FAQ, OpenAI Help Center.
• How Claude remembers your project, Anthropic Claude Code docs.
• Long-term memory, LangChain docs.
• A Survey on the Memory Mechanism of Large Language Model based Agents, arXiv 2024.
• Human-inspired Perspectives: A Survey on AI Long-term Memory, arXiv 2024.
• AI - 2025 Developer Survey, Stack Overflow.
• Mind the gap: Closing the AI trust gap for developers, Stack Overflow, février 2026.
• DORA Research: 2024 Accelerate State of DevOps Report, DORA.
• State of Developer Experience Report 2024, Atlassian.

Lectures complémentaires

• Pourquoi le contexte est crucial pour les assistants IA de projet
• Comment réunir docs, delivery et agents IA dans un même workflow
• Gestion de projet avec des agents IA en 2026
• Gestion des connaissances pour les équipes de développement
• Comprendre le Model Context Protocol