Le défi du cycle de vie : épuisement du contexte et persistance au niveau projet

Même si les capacités de raisonnement d'un grand modèle Agent sont très puissantes, elles restent limitées par deux frontières : la fenêtre de contexte d'une seule session Cmax est limitée, et une fois la session fermée, l'état et l'expérience ne sont plus fiables ; or le cycle de vie réel d'un projet d'ingénierie ou de recherche Tprojet peut durer des mois voire des années, donc Tprojet ≫ Cmax. La contradiction centrale ne réside pas dans l'insuffisance des capacités de raisonnement ponctuelles, mais dans le fait que l'expérience ne peut pas traverser le cycle de vie de l'Agent : sans persistance, les échecs, arbitrages, solutions candidates et conclusions de validation de chaque expérience disparaissent avec la purge du contexte, et l'Agent suivant ne peut que répéter l'exploration.

Épuisement du contexte : la limite dure d'une session unique

La fenêtre de contexte d'un Agent est une ressource limitée. Elle peut contenir l'objectif de la tâche en cours, les observations locales et le raisonnement récent, mais dès que la session se ferme, l'état, les conclusions temporaires et l'expérience contenus dans la fenêtre ne sont plus disponibles. Pour un projet à long cycle, on ne peut pas conserver la mémoire du projet dans un contexte unique, car au début de la session suivante, le contexte est déjà remis à zéro ou ne contient qu'une infime quantité d'informations injectées de l'extérieur.

Persistance au niveau projet : extérioriser l'expérience dans le monde logiciel

La solution consiste en la Persistance au niveau projet: extérioriser les configurations échouées, les processus d'arbitrage, les solutions candidates et les conclusions de validation d'une expérience en artefacts persistants au niveau projet, tels que le code, les tests, le journal d'expériences, le journal de décisions, les indicateurs d'évaluation et les résultats de validation. Ainsi, l'Agent suivant n'a pas besoin de repartir de zéro : il peut lire l'expérience antérieure depuis le dépôt du projet et déterminer quelles directions sont déjà validées, quels conflits restent non résolus et quels indicateurs sont déjà atteints.

Extension des frontières de l'objet d'évolution

Dans la perspective de l'évolution des méthodes, l'objet d'évolution n'est plus seulement un paramètre numérique ponctuel ou une solution candidate, mais s'étend à unmonde logiciel persistant, versionnable et héritable. Chaque nouvelle session produit de nouveaux artefacts qui modifient l'état de ce monde, et la session suivante poursuit l'évolution sur ce monde mis à jour. Le processus d'optimisation passe alors d'une tâche ponctuelle à uneévolution continue au niveau projet.

Collaboration multi-Agent et décomposition récursive

Plusieurs Agents à cycle de vie limité peuvent collaborer : l'exécuteur de niveau supérieur comprend l'objectif et décompose les tâches, l'exécuteur de niveau inférieur réalise l'implémentation locale et les tests, et poursuit la décomposition récursive si nécessaire. La continuité entre cycles de vie est assurée par la persistance au niveau projet : chaque Agent écrit les états clés dans les artefacts du projet avant de se fermer, et le nouvel Agent lit d'abord la mémoire du projet avant de décider de la prochaine action locale.

Conflits d'objectifs et retours épars en ingénierie réelle

Les projets à long cycle présentent souvent des conflits d'objectifs, par exemple entre performance, coût et robustesse, qu'il est difficile d'optimiser simultanément ; les retours peuvent aussi être épars, car une expérience peut nécessiter plusieurs heures voire plusieurs jours d'attente. Sans persistance au niveau projet, ces conflits et retours épars ne peuvent pas être consignés de manière fiable, et l'Agent suivant répète les mêmes erreurs. Le journal de décisions et les indicateurs d'évaluation persistés constituent précisément le vecteur clé qui transforme les retours épars en expérience héritable.