Pourquoi les humains pensent qu’ils se souviennent de tout, et pourquoi SDLC Memory prouve le contraire

Author: Yauheni Kurbayeu
Published: Feb 22, 2026
LinkedIn

Il existe une illusion silencieuse au sein de toute organisation d’ingénierie. Nous croyons que nous nous souvenons.

• Nous croyons nous souvenir de la raison pour laquelle nous avons choisi cette architecture.
• De la raison pour laquelle cette contrainte existe.
• De la raison pour laquelle cet incident s’est réellement produit.
• De la raison pour laquelle nous avons séparé la logique UE de la logique US.
• De la raison pour laquelle nous avons reporté cette migration.

Mais les sciences cognitives disent quelque chose de très inconfortable.

Selon les recherches en psychologie cognitive sur la capacité de la mémoire de travail, notre mémoire de travail active peut généralement retenir environ quatre unités d’information significatives à un moment donné. Pas quarante. Pas quatre cents. Quatre. Tout le reste est reconstruit à partir de fragments, d’habitudes et de liant narratif. Et à moins que nous ne répétions ou externalisions l’information, elle se dégrade rapidement. Ce n’est pas une faiblesse de leadership. C’est la biologie.

Comparons maintenant cela aux agents IA modernes. Claude peut fonctionner avec 200K tokens, parfois même 1M. Codex prend en charge 400K. Cela semble énorme comparé à un cerveau humain qui jongle avec quatre contraintes actives.

Mais voici le twist.

Même cela ne suffit pas pour un SDLC vivant.

L’échelle de la véritable mémoire de delivery

Prenons une configuration tout à fait ordinaire : trois équipes, quinze ingénieurs, des sprints de deux semaines. Rien d’extrême. Aucune complexité hyperscale. Juste un produit SaaS sain qui évolue en production.

Si vous compressez le travail en résumés au niveau décisionnel, par exemple des tickets réduits à leur intention, des PR résumées par leur impact, des ADR capturées avec leurs alternatives, des incidents structurés avec leurs causes et leurs mitigations, vous générez tout de même une quantité surprenante de matière de raisonnement structurée.

En pratique, cela représente environ 150 tickets par mois à travers les équipes. Environ 200 à 250 pull requests. Une poignée d’ADR et de conversations d’architecture. Quelques incidents de production. Les résultats du sprint planning. Les décisions de review. Les acceptations de risque.

Lorsque vous condensez tout cela en artefacts canoniques et structurés — pas du bruit brut de Slack, pas des logs, mais une mémoire prête pour le raisonnement — vous arrivez à environ 200 000 tokens par mois.

Pas des tokens théoriques. Une véritable mémoire de delivery.

À l’échelle entreprise, avec 80 ingénieurs et une agitation architecturale constante entre équipes, ce chiffre monte à un à un million et demi de tokens par mois.

Comparez maintenant cela aux fenêtres de contexte.

Deux cent mille tokens tiennent à peine dans certains modèles modernes. Quatre cent mille vous donnent un peu plus d’air. Un million semble généreux.

Mais voici la réalité structurelle : un seul trimestre de mémoire de delivery dépasse déjà ce qui tient confortablement dans une seule fenêtre de session. Et les sessions se réinitialisent.

Une fenêtre de 400K vous achète du temps. Elle ne vous achète pas de continuité.

C’est la même limite que celle à laquelle les humains sont confrontés, simplement à une autre échelle.

Le vrai problème n’est pas le stockage

Fait intéressant, le stockage est trivial.

À votre échelle actuelle, une année complète de mémoire SDLC curée, y compris les embeddings et les relations de graphe, pourrait consommer moins de 70 Mo. Même à l’échelle entreprise, vous restez confortablement en dessous d’un demi-gigaoctet pour une mémoire structurée.

Le coût d’infrastructure est négligeable.

Ce qui coûte cher, c’est la continuité cognitive.

Quand la mémoire ne vit que dans la tête des gens, chaque changement de directeur réinitialise le contexte. Chaque incident répète des erreurs passées. Chaque débat d’architecture rejoue des arguments déjà tranchés six mois plus tôt. Les équipes redécouvrent des contraintes comme s’il s’agissait de nouvelles idées.

Vous n’avez pas un problème de mémoire parce qu’il vous manque de la documentation.

Vous avez un problème de mémoire parce qu’il vous manque une mémoire structurée, interrogeable et causalement liée.*

Pourquoi des fenêtres de contexte plus grandes ne nous sauveront pas

Augmenter les fenêtres de contexte ressemble à un progrès. Et c’est un progrès. Mais c’est une mise à l’échelle horizontale de la mauvaise couche.

Une grande fenêtre de contexte reste liée à la session. Elle reste transitoire. Elle continue de se réinitialiser.

Sans structure durable, l’agent oublie une fois la session terminée. Sans structure durable, les humains reconstruisent à partir de fragments.

Nous continuons d’essayer de résoudre la continuité avec des prompts plus grands.

Ce dont nous avons réellement besoin, c’est d’une mémoire en couches.

Le cerveau SDLC Hot / Warm / Cold

Si nous traitons le SDLC comme un système vivant, la mémoire doit se comporter comme un système nerveux.

La mémoire chaude (Hot memory) est ce qui se passe maintenant.

• Le sprint en cours.
• Les incidents ouverts.
• Les risques actifs.
• Les questions non résolues.
• Elle est fluide, mise à jour quotidiennement, et suffisamment petite pour être injectée dans une session d’agent.
• C’est votre ensemble de travail opérationnel.

La mémoire tiède (Warm memory) est le cerveau évolutif du produit.

• Les décisions architecturales.
• Les trade-offs. Les postmortems.
• Les contraintes de conformité.
• Les frontières de responsabilité.
• Les artefacts canoniques tels que Decisions, Questions, Risks, Actions, ADRs, ainsi que les relations entre eux.

Cette couche s’étend sur plusieurs mois. Elle évolue, mais ne disparaît pas. Elle n’est pas injectée en entier ; elle est récupérée de manière sélective.

La mémoire froide (Cold memory) est la preuve.

• Les threads Jira bruts.
• Les transcriptions Slack.
• Les diffs de PR.
• Les enregistrements.
• Les logs.
• La preuve immuable de ce qui s’est passé et pourquoi.
• Rarement injectée directement, mais toujours liée.

L’idée clé est simple.

Le Hot bouge. Le Warm stabilise. Le Cold préserve.

Les agents interrogent à travers les couches. Les humains raisonnent à travers les couches. Aucun des deux ne devrait dépendre uniquement du rappel.

La couche manquante : la provenance

La véritable puissance ne vient pas de la recherche vectorielle seule.

Elle vient des relations.

Beaucoup d’équipes supposent que le RAG résout la continuité. Cela aide, mais la similarité n’est pas une explication. Trouver un « ticket similaire » n’est pas la même chose que comprendre pourquoi une contrainte existe.

Toute décision significative doit savoir :

• Qui l’a prise.
• Quand.
• Sur la base de quelles preuves.
• Quelles alternatives ont été rejetées.
• Ce qu’elle impacte.
• Quels risques elle atténue.
• À quels incidents elle a ensuite contribué.
• Si elle a remplacé une décision antérieure.

C’est là que la structure en graphe devient essentielle.

• Une base de données vectorielle vous aide à trouver des « idées similaires ».
• Une base de données graphe vous aide à répondre à la question « pourquoi cela existe-t-il ? »

La recherche vectorielle récupère la pertinence. La traversée de graphe reconstruit la causalité.

Quand vous combinez les deux, vous cessez de chercher du texte et commencez à parcourir le raisonnement.

C’est à ce moment-là que le SDLC devient traçable.

Que se passe-t-il lorsque les équipes basculent vers des agents IA ?

Imaginez maintenant un futur qui n’est pas hypothétique, un futur proche que de nombreux leaders commencent déjà à percevoir. Alors que les agents IA deviennent de plus en plus capables, les enquêtes montrent que de larges proportions de développeurs et d’équipes d’ingénierie s’appuient déjà sur l’IA dans leurs workflows quotidiens, certaines estimations indiquant que plus de 80 % des ingénieurs utilisent régulièrement des outils d’IA pour les aider dans les tâches de développement et de programmation.

Certaines voix suggèrent même que dans quelques années, de nombreuses tâches traditionnelles du software engineering seront largement automatisées par des agents, laissant les humains davantage concentrés sur la planification, le design et la supervision plutôt que sur la saisie de code elle-même.

Dans ce scénario, où 50 à 80 % du travail quotidien de code et d’exécution est pris en charge par des agents IA, le problème de provenance devient dramatiquement plus aigu. Lorsque les ingénieurs humains écrivent moins de lignes de code et passent plus de temps à diriger des agents autonomes, le contexte décisionnel et sa justification deviennent encore plus essentiels :

• Le produit du travail cesse d’être l’artefact principal.
• Ce qui compte devient la raison pour laquelle un agent a choisi une implémentation donnée et la manière dont il l’a choisie, pas seulement ce qu’il a produit.

Même les études qui montrent que les outils d’IA augmentent la productivité individuelle ou d’équipe (avec des hausses allant souvent d’environ 20 à 60 % ou plus) soulignent également que les développeurs passent davantage de temps à superviser le travail, valider les outputs et corriger les problèmes générés par les agents — c’est-à-dire précisément ce type de raisonnement d’ordre supérieur qui ne peut pas être automatisé sans mémoire du contexte antérieur.

Les agents IA peuvent reconnaître des patterns et écrire du code, mais ils ne portent pas intrinsèquement les objectifs organisationnels, la stratégie produit ou les trade-offs des décisions passées, à moins que ceux-ci ne soient explicitement encodés dans une couche de provenance structurée.

Ce changement amplifie la nécessité de la couche Warm Provenance :

• Lorsque les agents créent du code de manière autonome, vous devez savoir ce qui a conduit à cette décision tout autant que ce que fait le code.
• Lorsque les agents remplacent les tâches répétitives, les humains se retrouvent avec la gestion des exceptions, la stratégie et l’orchestration — les aspects les plus difficiles à rappeler sans mémoire structurée.
• Lorsqu’un produit doit prouver sa conformité, expliquer une mitigation de risque ou reconstruire une intention des mois plus tard, le graphe de provenance devient la seule trace fiable.

Sans cela, les organisations risquent de construire des systèmes opaques que même leurs créateurs ne peuvent pas pleinement justifier.

Pourquoi cela compte encore plus à l’ère de l’IA

À mesure que l’IA réduit le coût d’exécution, la vitesse de delivery converge entre les organisations. La génération de code s’améliore partout. La création de tests s’accélère partout. La documentation se rédige toute seule.

Ce qui ne converge pas, c’est la discipline de la mémoire.

• Les équipes sans mémoire SDLC structurée redébattent des décisions passées.
• Elles réintroduisent des risques déjà atténués.
• Elles répètent des erreurs architecturales.
• Elles perdent le contexte à chaque rotation du leadership ou au départ d’un ingénieur clé.

Les équipes dotées d’une provenance en couches expliquent les décisions sous pression. Elles onboardent les ingénieurs et les agents IA dans le raisonnement plutôt que dans le folklore. Elles permettent aux agents IA d’opérer avec un véritable ancrage historique. Elles maintiennent la continuité de la gouvernance même lorsque les personnes changent.

La différence n’est pas l’outillage.

C’est la mémoire structurelle.

Pourquoi cela compte pour les leaders

Si vous gérez plusieurs équipes, en particulier dans un environnement SaaS fortement contraint par la conformité, vous simulez déjà ce système dans votre tête.

Vous vous souvenez de quelle dépendance est fragile. Vous vous souvenez de quel workflow d’agent a produit une release problématique. Vous vous souvenez de la raison pour laquelle la logique UE s’est comportée différemment lors du dernier rollout.

Mais votre cerveau n’est pas un stockage durable. C’est un moteur de raisonnement avec une minuscule fenêtre active.

La charge cognitive que vous ressentez n’est pas une faiblesse.

C’est une surcharge structurelle.

Vous maintenez environ 200 000 tokens par mois dans un processeur à quatre chunks.

Dans un futur où les agents IA réalisent la moitié ou plus du travail d’exécution, cette charge mémoire ne disparaît pas. Elle se déplace : de la mémorisation du code vers la mémorisation de l’intention, de la causalité et de la justification.

Réflexion finale

Les humains ne peuvent pas se souvenir de tout. Les agents ne peuvent pas se souvenir de tout. Même des fenêtres d’un million de tokens ne sont pas de la continuité.

Mais les organisations peuvent se souvenir de tout si elles traitent la mémoire comme une infrastructure, et non comme de la documentation.

L’exécution devient moins chère. La mémoire devient le différenciateur.

Dans un monde accéléré par l’IA, les équipes disposant de la mémoire structurée la plus forte ne feront pas que bouger plus vite.

Elles bougeront de manière cohérente et responsable. Ce seront les équipes capables d’expliquer non seulement ce qui a été fait, mais pourquoi cela a été fait, longtemps après que le code a été écrit.