Pendant des décennies, les systèmes distribués se sont appuyés sur l’élégance de l’absence d’état, à la fois comme principe de conception et comme stratégie de mise à l’échelle : une abstraction claire dans laquelle chaque requête arrive indépendamment de la précédente, est traitée de manière isolée et ne laisse aucune trace. Les systèmes sans état oublient et, ce faisant, gagnent en liberté : la liberté d’évoluer horizontalement sans coordination, la liberté de tomber en panne sans conséquence, la liberté de s’affranchir de la charge opérationnelle liée à la mémoire. C’était un bon modèle et, pour certaines applications, il nous a bien servis.
Les systèmes d’IA, cependant, révèlent le caractère illusoire de ce modèle.

Ce que nous appelons aujourd’hui « inférence sans état » ne l’est que dans sa mise en œuvre, et non dans son fonctionnement, car l’état n’a pas disparu : il a simplement été déplacé. La conversation, le raisonnement et le sens dépendent du contexte antérieur ; ce contexte doit donc persister quelque part. Aujourd’hui, nous l’intégrons à chaque requête, encodé sous forme de jetons, rejoué sans cesse et reconstitué échange après échange, comme si le système relisait toute la conversation depuis le début chaque fois qu’il prend la parole. L’architecture se prétend sans état, mais, dans la pratique, elle se comporte comme si l’état était partout — parce que c’est bien le cas.
Le contexte, dépouillé de cette appellation plus douce, n’est rien d’autre qu’un état en mouvement.
Chaque requête charrie avec elle tout un historique qui, à mesure que les conversations s’allongent, devient de plus en plus lourd. La taille des charges utiles augmente, les transferts réseau s’intensifient, la latence d’inférence s’accroît et des ressources de calcul sont sans cesse mobilisées pour analyser des informations que le modèle a déjà vues. Des fenêtres de contexte plus grandes et du matériel plus rapide retardent les conséquences, tandis que des techniques d’ingénierie ingénieuses, telles que la mise en cache KV et la compression des prompts, en atténuent les effets. Pourtant, aucune de ces solutions ne remédie à l’inefficacité fondamentale qui consiste à rejouer la mémoire plutôt qu’à la maintenir. Le système se souvient par répétition plutôt que par conception, et toute répétition a un coût.
Le coût d’une conversation cohérente
Ce coût se manifeste d’abord en matière de bande passante, puis de puissance de calcul et, enfin, de latence, créant une pression discrète mais persistante sur le passage à l’échelle. L’absence d’état facilitait autrefois ce dernier, car rien ne devait être conservé entre les appels. Pourtant, les charges de travail liées à l’IA inversent cet avantage, puisque c’est précisément la préservation de la continuité qui les rend utiles. Un système qui oublie le passé ne peut ni poursuivre un raisonnement, ni maintenir la cohérence d’une conversation, ni s’appuyer sur les connaissances acquises précédemment au cours d’une session. En pratique, nous avons construit un comportement avec état sur une infrastructure sans état, et les tensions commencent à se faire sentir.
La réponse prévisible consiste à recourir à l’affinité de session.
Si le contexte doit persister, il est plus efficace de le conserver à proximité de l’endroit où il a été utilisé pour la dernière fois, afin de pouvoir réutiliser les représentations mises en cache et d’éviter le transfert et la reconstitution répétés de l’historique conversationnel. Les sessions deviennent « persistantes », non par choix philosophique, mais par nécessité opérationnelle, car le déplacement de l’état devient coûteux. La latence s’améliore, le gaspillage de ressources de calcul diminue et l’illusion d’une architecture sans état s’estompe davantage à mesure que la mémoire devient une dépendance explicite des performances.
Pourtant, les sessions persistantes introduisent leurs propres contraintes. L’équilibrage de charge perd en souplesse, le basculement devient plus complexe et la mobilité distribuée est limitée par l’emplacement de la mémoire. Les systèmes conçus pour bénéficier de la liberté offerte par l’absence d’état se retrouvent confrontés à la gravité d’une architecture avec état. La réponse naturelle consiste à externaliser l’état en plaçant la mémoire de session dans des espaces de stockage partagés, des systèmes de recherche d’informations ou des bases de données contextuelles, afin de permettre à n’importe quel nœud d’inférence de reprendre la conversation sans avoir à en rejouer tout l’historique. Cette approche rétablit la souplesse du routage et la capacité de mise à l’échelle horizontale, mais elle transforme la mémoire en un composant architectural qui doit être géré avec la même rigueur que les données : cohérence, ordonnancement, intégrité et sécurité revêtent désormais une importance qu’ils n’avaient pas lorsque le contexte était simplement intégré à une invite.
À ce stade, une question plus profonde se pose, qui dépasse l’optimisation pour toucher à la philosophie de conception : devons-nous vraiment continuer à conserver l’intégralité de la conversation ?
Nous évoluons vers un état sélectif
L’approche actuelle considère le contexte comme une transcription qui ne cesse de s’allonger, un flux continu de jetons intégralement rejoué. Pourtant, les machines ne sont pas soumises aux limites de la conversation humaine. Nous observons déjà les prémices d’une évolution vers une mémoire sélective, où la synthèse remplace l’historique brut, la récupération d’informations remplace la répétition et la mémoire structurée distingue les connaissances durables des échanges éphémères. Au lieu de traîner avec eux l’intégralité du passé, les systèmes commencent à ne conserver que ce qui reste pertinent, en construisant une mémoire à plusieurs niveaux dans laquelle le contexte immédiat, les synthèses condensées et les connaissances persistantes remplissent chacun un rôle distinct. L’architecture passe ainsi d’une mémorisation exhaustive à une mémorisation intelligente.
C’est là la véritable transition en cours.
Le secteur a commencé par adopter le calcul sans état, car les ressources de calcul étaient rares et la mémoire pouvait être abandonnée à moindre coût. L’IA inverse cette relation, faisant du contexte et de la continuité des préoccupations architecturales de premier plan. L’état n’a jamais véritablement disparu ; il a simplement été transporté, rejoué et dissimulé au sein de conceptions sans état. À mesure que les systèmes d’IA gagneront en maturité, ce camouflage s’estompera et les architectures évolueront vers une gestion délibérée de la mémoire plutôt que vers un transport perpétuel du contexte.
Les sessions resteront persistantes, car la continuité a de la valeur. Le contexte restera indissociable, car le sens dépend de la mémoire. La fiction de l’absence d’état continuera de s’effriter, remplacée par des systèmes qui sauront explicitement quoi mémoriser, où le conserver et quand le libérer, car l’avenir de l’IA évolutive n’appartiendra pas aux systèmes qui transportent leur état partout, mais à ceux qui le gèrent judicieusement.
À propos de l’auteur

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés

Les paquets empoisonnés sont en train de tuer notre industrie
L’open source ne dispose pas d’un registre central recensant les paquets malveillants, alors même que l’IA et l’automatisation accélèrent les attaques contre la chaîne d’approvisionnement. L’écosystème a besoin d’un moyen fiable de signaler et de suivre les compromissions.

Top 10 des risques liés à la mise en production d’applications d’IA : manque de sécurité et de conformité réglementaire
L’IA étend la conformité au-delà de la sécurisation des chemins d’accès et des espaces de stockage pour englober la gouvernance du comportement à l’exécution — accès aux modèles, contexte de récupération, résultats et actions des agents —, de sorte que les contrôles doivent être rapprochés de l’inférence.

Top 10 de la livraison d’applications d’IA : politiques de livraison incompatibles
Les divergences de politiques deviennent des sources de pannes pour l’IA : des mécanismes de basculement, des délais d’expiration, des limites et des contrôles de sécurité incohérents entraînent des défaillances silencieuses, des résultats partiels et des résultats différents selon le point de terminaison.

Top 10 de la mise à disposition d’applications d’IA : orientation du trafic non optimisée
L’IA remet en cause les principes traditionnels de répartition du trafic : les backends ne sont pas interchangeables, les coûts varient et les agents multiplient les requêtes de manière imprévisible. Le routage doit donc tenir compte du modèle, de l’état des GPU et de la localisation des données.

Top 10 de la livraison d’applications d’IA : contrôles du trafic insuffisants
Les limites de débit et les mécanismes de régulation traditionnels ne tiennent pas compte de l’étendue réelle des répercussions. Les charges de travail d’IA se répartissent entre les modèles, les bases de données vectorielles et les services, provoquant des pics de latence, des défaillances en cascade et des nouvelles tentatives.

La gestion des fenêtres de contexte en IA n’a rien de magique. C’est une question d’architecture.
Découvrez pourquoi les créateurs d’applications d’IA doivent gérer le contexte, la mémoire et l’infrastructure, tout en faisant évoluer les processus de livraison et la sécurité afin d’éviter la dérive, la latence et les attaques par injection de prompts.