La question paraît absurde, elle ne l’est pas. Les organisations vérifient la conformité de leurs systèmes d’IA au moment du déploiement, comme s’il s’agissait d’un état acquis. Sur les traitements longs, c’est un processus qui se dégrade, silencieusement et sans alerte.

Leyton CognitX · Septembre 2026

Une question que peu d’organisations peuvent trancher

Le scénario est banal. Un agent est chargé d’un traitement long, validation d’un référentiel de données, revue d’un portefeuille de contrats, instruction d’un ensemble de dossiers. Au démarrage, on lui a donné des règles : ne jamais transmettre telle catégorie d’information, signaler tout cas relevant d’une exception, appliquer tel seuil de validation. Le traitement dure plusieurs jours et des milliers d’enregistrements défilent. Au troisième jour, ces règles ne figurent plus dans sa mémoire active. Le système ne s’arrête pas, ne signale rien et continue de produire des résultats d’apparence normale, en ayant cessé d’appliquer des contraintes que personne n’a retirées.

La plupart des organisations sont aujourd’hui incapables de dire si cela s’est produit chez elles, parce qu’elles ont vérifié la conformité de leurs systèmes au moment de la mise en service et qu’elles surveillent ensuite des indicateurs d’infrastructure, disponibilité, latence, taux d’erreur, qui restent parfaitement au vert pendant que le respect des règles s’érode. La question du titre n’est donc pas rhétorique : elle désigne un angle mort structurel, et l’écart entre conformité déclarée et conformité effective est précisément ce que révèlent les audits menés a posteriori.

Pourquoi la conformité se dégrade en cours d’exécution

Le mécanisme n’a rien de mystérieux. Un agent raisonne à partir d’une mémoire de travail de taille finie, qui contient tout à la fois : les instructions initiales, l’historique de la tâche, les résultats des outils appelés et les documents récupérés en cours de route. Sur un traitement de quelques échanges, cet espace est largement suffisant. Sur un traitement long, la mémoire se remplit linéairement à mesure que les observations et les résultats d’outils s’accumulent, jusqu’à ce que le contenu le plus ancien soit tronqué ou évincé. Or le contenu le plus ancien, ce sont précisément les règles données au départ.

Les travaux de recherche publiés depuis un an décrivent ce phénomène sous deux effets conjoints : l’inflation de la mémoire, qui consomme l’espace disponible et force la troncature, et la dégradation contextuelle, qui fait perdre à l’agent la capacité de mobiliser des contraintes pourtant énoncées. Ces travaux relèvent que les agents perdent alors la focalisation sur leurs contraintes, se contredisent et répètent des erreurs déjà commises. Les référentiels d’architecture publiés par les grands fournisseurs d’infrastructure ont intégré ce risque et recommandent désormais de suivre le taux d’occupation de la mémoire de travail comme un indicateur de supervision à part entière, avec des seuils d’alerte, en relevant qu’un agent en saturation présente toutes les apparences du bon fonctionnement tout en ayant perdu le contexte nécessaire pour raisonner correctement.

Pourquoi agrandir les fenêtres ne résout pas le problème

La réponse spontanée consiste à invoquer l’augmentation continue des tailles de contexte. Elle est insuffisante, pour trois raisons. La première est arithmétique : la consommation croît avec la durée du traitement, si bien qu’un agrandissement repousse l’échéance sans supprimer le mécanisme. La seconde tient à la manière dont les modèles exploitent leur contexte : la recherche documente de longue date une sous-pondération systématique de l’information située au milieu des contextes longs, de sorte qu’une règle techniquement présente peut rester sans effet sur le comportement. La troisième est la plus gênante : du point de vue du résultat produit, une règle présente mais ignorée est strictement indiscernable d’une règle absente. Aucune inspection du contexte ne permet donc de conclure à la conformité.

Une seconde réponse spontanée consiste à doter l’agent d’une mémoire persistante qui rejouerait l’historique ou le récupérerait à la demande. Les travaux récents signalent que ces approches introduisent une croissance non bornée du contexte et exposent à un rappel bruité ainsi qu’à l’empoisonnement de la mémoire, c’est-à-dire à l’introduction durable d’informations erronées. Le remède déplace le problème plutôt qu’il ne le supprime.

La réponse : le contrôle hors contexte

Nous en tirons un principe simple, qui répond directement à la question posée par le titre. Une contrainte qui doit valoir pendant toute la durée d’un traitement ne peut pas vivre dans le contexte de l’agent, parce que tout ce qui s’y trouve entre en concurrence pour un espace et une attention limités. Formulée dans le contexte, une règle n’est pas un contrôle : c’est une suggestion dont la persistance dépend de la longueur de la tâche. Le contrôle doit donc s’exercer depuis l’extérieur du contexte.

Ce principe se décline concrètement à trois niveaux, du moins robuste au plus robuste. Le premier est la réinjection : la règle n’est pas énoncée une fois au démarrage mais réaffirmée à chaque point de contrôle du traitement, ce qui la remet dans la mémoire active au moment où elle doit s’appliquer. Le deuxième, nettement plus solide, est l’application externalisée : la contrainte est rendue exécutoire par la couche d’outillage plutôt que par le modèle, sous forme de permissions, de listes d’autorisation et de validateurs qui refusent matériellement l’action non conforme. Un agent qui ne dispose pas du droit d’accéder à une catégorie de données ne peut pas l’oublier, puisqu’il n’a jamais eu la possibilité de le faire. Le troisième est la vérification en contexte neuf : un composant distinct contrôle les sorties au regard des contraintes, sans jamais hériter du contexte de celui qui les a produites, ce qui garantit que le vérificateur ne partage pas les oublis du producteur.

Ces trois niveaux se complètent plutôt qu’ils ne se substituent. Ils ont en commun de transformer la conformité en propriété vérifiable à tout instant du traitement, et non en état constaté au démarrage. C’est cette transformation, davantage que le choix des outils, qui répond à la question du troisième jour.

Ce que ce principe ne résout pas

Deux limites méritent d’être posées. La première est que l’externalisation a un coût, en conception comme en exécution : multiplier les points de contrôle et les vérifications en contexte neuf allonge les traitements et augmente la consommation de calcul, dans une période où le coût par traitement agentique est déjà orienté à la hausse. Le dimensionnement doit donc rester proportionné à l’impact réel des actions concernées, ce qui suppose de distinguer les contraintes dont la violation est réversible de celles dont elle ne l’est pas. La seconde est que toutes les contraintes ne sont pas externalisables : une exigence de jugement, de ton ou de pertinence ne se traduit pas en permission technique. Pour celles-là, la réinjection et la vérification restent les seuls leviers, et leur fiabilité demeure inférieure à celle d’un contrôle exécutoire. Reconnaître cette asymétrie évite de croire le problème entièrement résolu.

Ce que les organisations doivent faire

1. Recenser les traitements longs : passer en revue les traitements agentiques en production et identifier ceux dont la durée ou le volume dépassent largement le cadre d’une interaction courte. Ce sont eux qui sont exposés, et ils sont souvent ceux auxquels on a confié les tâches les plus sensibles, précisément parce qu’elles sont longues et répétitives.
2. Exiger la preuve de persistance : demander aux équipes de démontrer, pour chaque contrainte critique, comment elle est appliquée au troisième jour et non au premier. Une réponse qui se réfère aux instructions initiales indique que la contrainte vit dans le contexte, donc qu’elle n’est pas garantie.
3. Externaliser ce qui peut l’être : rendre exécutoires par l’outillage toutes les contraintes qui peuvent l’être, en particulier celles qui portent sur l’accès aux données et sur les actions irréversibles. C’est le seul niveau qui résiste à la longueur des traitements.
4. Superviser la conformité, pas seulement le système : ajouter le taux d’occupation de la mémoire de travail et le respect des contraintes aux indicateurs supervisés, au même titre que la disponibilité et la latence. Une supervision qui ne mesure que l’infrastructure restera au vert pendant toute la durée de la dérive.

Perspectives

La question posée par ce titre deviendra plus pressante à mesure que les traitements agentiques s’allongeront, ce qui est la direction prise par le marché. Elle rejoint un déplacement que nos publications précédentes décrivaient sous le nom d’infrastructure de confiance : un agent ne passe pas en production parce qu’il raisonne bien, mais parce que l’organisation peut démontrer ce qu’il fait et ce qu’il ne fait pas. Cette démonstration supposait déjà des identités, des journaux et une supervision proportionnée. Elle suppose désormais quelque chose de plus exigeant : que les contraintes survivent à la durée. Dans les déploiements que nos équipes accompagnent, cette exigence est le meilleur révélateur de la maturité réelle d’une architecture, parce qu’elle sépare les systèmes conçus pour être gouvernés de ceux à qui l’on a simplement donné des consignes.

Sources

Les travaux de recherche et données cités dans cet article proviennent des sources suivantes. / The research and data cited in this article are drawn from the following sources.

[1] F. Bousetouane (University of Chicago), « AI Agents Need Memory Control Over More Context », arXiv:2601.11653, 2026. https://arxiv.org/pdf/2601.11653

[2] « Memory Management and Contextual Consistency for Long-Running Low-Code Agents », arXiv:2509.25250. https://arxiv.org/pdf/2509.25250

[3] « Agile V: A Compliance-Ready Framework for AI-Augmented Engineering », arXiv:2602.20684, 2026. https://arxiv.org/pdf/2602.20684

[4] Amazon Web Services, Well-Architected Agentic AI Lens, « AGENTREL08-BP04: Track agent memory utilization metrics », 2026. https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentrel08-bp04.html

[5] Gartner (communiqué de presse), « Gartner Predicts AI Inference Costs Per Agentic Workflow Will Increase More Than Fivefold Through 2028 », 17 août 2026. https://www.gartner.com/en/newsroom/press-releases/2026-08-17-gartner-predicts-ai-inference-costs-per-agentic-workflow-will-increase-more-than-fivefold-through-2028

[6] McKinsey & Company, « State of AI trust in 2026: Shifting to the agentic era », mars 2026. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era