# EvoX Système d'évolution intelligente et pratique de recherche IA Native — Support de cours

Durée : 1 · Pages du support : 16

## Navigation de lecture

- [Leçon 6｜Thème : Évolution continue au niveau système : Genesis et la sédimentation du monde logiciel](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Leçon 6｜Thème : Évolution continue au niveau système : Genesis et la sédimentation du monde logiciel

<a id="lecture-page-1"></a>

### Évolution continue au niveau système : Genesis et la sédimentation du monde logiciel

*Page 1*

> **Objectif de la page :** Apprendre comment Genesis, grâce à la collaboration multi-Agents et à des mécanismes de validation rigoureux, permet au code d'un projet de s'accumuler et d'évoluer en continu tout au long de son cycle de vie.

> **Objectif de la page**
>
> Comment un projet ne se contente pas d'achever une fois l'écriture du code, mais permet à celui-ci de s'accumuler et d'évoluer en continu pendant tout son cycle de vie. Deux fils conducteurs principaux : premièrement, le modèle d'ingénierie constitué par la collaboration multi-Agents et la décomposition récursive des tâches ; deuxièmement, le mécanisme par lequel la compilation, les tests et la validation transforment les modifications valides en histoire du projet.

**Points clés de l'enseignement**

- 1. Commencer par préciser la signification de « l'évolution continue ». Le logiciel n'est pas un produit figé une fois écrit, mais une entité constamment modifiée, complétée et refactorisée au fil du temps. Genesis vise précisément à fournir un mode d'organisation exécutable pour cette évolution à long terme, et non une technique de génération de code ponctuelle. 2. La collaboration multi-Agents résout la question du « qui se répartit le travail ». Face à un projet réel, l'ampleur des tâches dépasse souvent la capacité de traitement en une seule fois ; il faut donc une répartition des rôles et un processus de collaboration pour que les responsabilités de chaque étape soient claires et traçables. 3. La décomposition récursive des tâches résout la question du « comment s'y prendre ». Il s'agit de décomposer un objectif relativement vaste en petites tâches exécutables, couche par couche, jusqu'à ce que chaque sous-tâche soit suffisamment concrète pour être réalisée et vérifiée indépendamment. Cela réduit la difficulté de chaque étape et permet d'évaluer séparément le résultat de chacune. 4. La validation rigoureuse résout la question du « pourquoi cela compte ». La réussite de la compilation, des tests et de la validation constitue trois niveaux de contrôle de plus en plus stricts. Seules les modifications franchissant ces niveaux ont le droit d'être inscrites dans l'histoire du projet.
- Les modifications non validées sont rejetées ou retravaillées. La collaboration et la décomposition produisent un grand nombre de modifications candidates ; la validation se charge de les filtrer ; les résultats filtrés se déposent dans l'histoire du projet, laquelle devient à son tour le point de départ de la prochaine vague d'évolution. C'est le circuit complet de « l'évolution continue au niveau système ».

**Vérification de la compréhension**

Demander aux étudiants d'exprimer dans leurs propres mots la relation d'ordre entre « décomposition — validation — sédimentation », et de répondre : si une modification passe la compilation mais échoue aux tests, dans quel état se trouve-t-elle dans le mécanisme décrit sur cette page ? L'enseignant vérifie ainsi si l'étudiant a réellement compris le rôle des niveaux de validation, et non simplement mémorisé les termes.

> **Indication de transition**
>
> Cette page établit le cadre général ; la suite abordera des pratiques et des exemples plus concrets. Après avoir confirmé que les étudiants peuvent reformuler ce circuit, poursuivre l'approfondissement des étapes spécifiques.

<a id="lecture-page-2"></a>

### Les limites des capacités des grands modèles et la nécessité de l'évolution au niveau système

*Page 2*

> **Objectif de la page :** Comprendre les limites actuelles des grands modèles dans le développement de systèmes complexes et la nécessité de construire des systèmes en évolution continue.

> **Objectif de la page**
>
> Comprendre les limites des grands modèles dans le développement de systèmes complexes, et pourquoi il est indispensable d'intégrer les composants intelligents dans une boucle systémique capable d'évoluer en continu à travers les cycles de vie.

> **Ordre de présentation**
>
> Le grand modèle est un composant intelligent puissant, mais ce n'est pas un système capable de s'auto-maintenir. Il possède déjà des capacités utilisables en compréhension, génération, raisonnement et appel d'outils, et peut servir de proposeur d'hypothèses et de producteur de code de haute qualité ; mais il lui manque les états, les objectifs et les mécanismes de rétroaction nécessaires à une évolution continue à travers les cycles de vie.
>
> Compréhension, génération, raisonnement, appel d'outils, aboutissant finalement à un instantané statique, avec un état remis à zéro à la fin de la session. À droite, le grand modèle est intégré comme petit module dans la boucle d'évolution au niveau système : proposition, évaluation, sélection, sédimentation. Le grand modèle se charge de la proposition ; le modèle substitut sert à réduire le coût d'évaluation ; l'étape de sélection gère les compromis multi-objectifs ; la sédimentation forme une mémoire inter-sessions ; l'intelligence collective maintient la diversité des candidats et revient à la proposition suivante.
>
> Limite d'état — la fenêtre de contexte est limitée, la mémoire persistante inter-sessions est absente, les projets à long cycle ne peuvent pas se maintenir ; limite d'objectif — les problèmes réels impliquent souvent des conflits multi-objectifs et des compromis de préférences, le modèle a du mal à fournir de manière autonome des critères d'arbitrage défendables ; limite de rétroaction — absence de mécanismes exécutables d'évaluation, de sélection et d'élimination, les solutions générées ne peuvent pas être objectivement validées et retenues par itération.
>
> L'amélioration des capacités du modèle n'équivaut pas à l'amélioration des capacités du système. La capacité est un instantané, l'environnement est un processus. Ce n'est qu'en intégrant le grand modèle dans la boucle d'évolution « génération—évaluation—sélection—sédimentation », en maintenant la diversité par l'intelligence collective, en comprimant le coût d'évaluation par le modèle substitut, et en préservant l'expérience valide par la sélection et la sédimentation, que l'intelligence peut maintenir son adaptation dans un environnement dynamique. C'est aussi le point d'ancrage d'EvoX.

**Points clés de l'enseignement**

- Le grand modèle possède de puissantes capacités de compréhension et de génération, mais ne peut pas faire évoluer un système de manière autonome. Les systèmes complexes du monde réel nécessitent une capacité d'évolution continue à travers les cycles de vie ; un instantané statique ne suffit pas à faire face aux changements de l'environnement. Les composants intelligents doivent être associés à des mécanismes d'évolution pour s'adapter à un environnement dynamique ; les mécanismes clés incluent la boucle d'évolution, l'intelligence collective et le modèle substitut. Limite d'état, limite d'objectif, limite de rétroaction.

**Traitement des exercices**

Pour la question sur les concepts fondamentaux, il faut choisir « comprendre les limites actuelles des grands modèles dans le développement de systèmes complexes et la nécessité de construire des systèmes en évolution continue ».

Pour les autres questions vrai/faux, privilégier les options « pouvant être expliquées par des preuves ou des exemples » ; se fier uniquement à l'intuition, sauter la récitation du matériel, ou modifier simultanément tous les facteurs pour comparer, ne répondent pas aux exigences de cette page.

En cas de bonne réponse, on peut confirmer que l'étudiant sait relier les concepts de cette page et justifier son raisonnement ; en cas d'erreur, l'inviter à revenir dans l'exposé pour trouver les preuves ou exemples clés, en se concentrant sur les trois types de limites et la boucle « proposition—évaluation—sélection—sédimentation ».

Commencer par expliquer que l'idée centrale est « le grand modèle possède de puissantes capacités de compréhension et de génération mais ne peut pas faire évoluer un système de manière autonome », puis illustrer par des exemples pourquoi les systèmes complexes nécessitent une capacité d'évolution continue à travers les cycles de vie.

**Vérification de la compréhension**

Demander aux étudiants d'expliquer dans leurs propres mots « pourquoi l'amélioration des capacités du modèle n'équivaut pas à l'amélioration des capacités du système », et d'identifier au moins deux des trois types de limites : état, objectif, rétroaction. Si l'étudiant peut clairement expliquer la relation entre la capacité monolithique et l'évolution en boucle, passer à la page suivante ; sinon, revenir au diagramme comparatif pour reprendre les deux trajectoires, gauche et droite.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer la relation centrale « le grand modèle est un composant, la boucle d'évolution est le système », passer au contenu suivant sur l'évolution continue au niveau système, Genesis et la sédimentation du monde logiciel.

<a id="lecture-page-3"></a>

### Extension des frontières de l'évolution : des paramètres numériques aux systèmes logiciels

*Page 3*

> **Objectif de la page :** Maîtriser comment les grands modèles étendent l'objet de l'évolution des paramètres numériques traditionnels aux programmes, structures de modèles et états de système.

> **Objectif de la page**
>
> Maîtriser comment les grands modèles étendent l'objet de l'évolution des paramètres numériques traditionnels aux programmes, structures de modèles et états de système, et comprendre les conditions motrices de cette extension des frontières ainsi que les changements d'évaluation.

> **Ordre de présentation**
>
> L'objet est généralement un vecteur de paramètres numériques de faible dimension et prédéfini, comme les hyperparamètres, les poids, les variables continues ; l'espace de recherche est délimité par une structure et un encodage prédéfinis manuellement.
>
> Avec l'expansion de l'échelle de calcul et de la base d'ingénierie, la recherche d'objets de haute dimension, discrets et structurés passe d'infaisable à traitable ; les frontières de recherche s'étendent en synchronie avec la puissance de calcul et la chaîne d'outils.
>
> Disposant de capacités de compréhension de code, de raisonnement contextuel et de génération de candidats, il peut directement construire, modifier et évaluer des objets au niveau programme, réduisant la dépendance aux opérateurs d'encodage et de mutation conçus manuellement.
>
> Si la méthode de génération de candidats reste fixée manuellement, le système ne fera que répéter les schémas établis ; intégrer la méthode de génération de candidats elle-même dans l'objet d'évolution, comme les stratégies de mutation et les réglages de paramètres de l'évolution différentielle, est précisément la manifestation de cette extension des frontières.
>
> De bas en haut : paramètres numériques → structure de modèle → mécanisme algorithmique → programme et état d'ingénierie logicielle ; vers le haut, la dimension de l'espace de recherche et la complexité sémantique augmentent ; à droite, le soutien des capacités du grand modèle ; en haut, les contraintes de validation exécutable et de coût d'ingénierie.
>
> Plus le niveau est élevé, plus les contraintes sémantiques sont fortes, plus la chaîne d'évaluation est longue ; les candidats doivent être exécutables et vérifiables ; l'évaluation de la fitness passe d'une fonction scalaire à un jugement conjoint des résultats d'exécution et des contraintes d'ingénierie.
>
> Il ne s'agit pas de remplacer l'optimisation de paramètres, mais d'intégrer l'optimisation de paramètres dans un cycle d'évolution de programme et de système plus vaste, formant un continuum allant du réglage local à l'amélioration au niveau système.

**Points clés de l'enseignement**

- L'expansion de l'échelle de calcul entraîne des frontières de recherche plus larges. Le grand modèle peut comprendre le code et le contexte et construire des candidats complexes. L'objet de l'évolution s'étend des paramètres numériques aux programmes et états d'ingénierie logicielle, en passant par les structures de modèles et les mécanismes algorithmiques. Premièrement, l'expansion de la puissance de calcul et de la base d'ingénierie ; deuxièmement, les capacités du grand modèle en compréhension de code, raisonnement contextuel et génération de candidats.

**Couverture des mots-clés**

- Paramètres numériques, structure de modèle, mécanisme algorithmique, programme et état d'ingénierie logicielle, frontières de recherche, compréhension de code, raisonnement contextuel, construction de candidats, validation exécutable, coût d'ingénierie, évaluation de la fitness, continuum. Traitement des exercices et rétroaction : Le grand modèle étend l'objet de l'évolution des paramètres numériques traditionnels aux programmes, structures de modèles et états de système. En cas de réponse erronée, inviter à revenir à la phrase conceptuelle et réessayer. Le grand modèle peut comprendre le code et le contexte d'exécution, et construire et modifier sur cette base des candidats complexes au niveau programme.
- Les options erronées limitent souvent le grand modèle aux paramètres numériques encodés manuellement. Pour les exercices 3, 4 et 5, la bonne direction n'est pas la récitation, l'intuition ou la modification simultanée de tous les facteurs, mais l'explication des conclusions pertinentes par des preuves ou des exemples. La rétroaction peut souligner : pouvoir relier les concepts de cette page et justifier son raisonnement constitue une véritable maîtrise. L'équipe commence par ne régler que les hyperparamètres numériques tels que le taux d'apprentissage, la taille de lot, le nombre de couches du réseau.
- Ensuite, on demande au grand modèle de lire les scripts d'entraînement et les journaux d'exécution, de réécrire directement l'implémentation de l'optimiseur, le pipeline de données et le flux de contrôle algorithmique, puis de soumettre les candidats à l'exécution en temps réel et de renvoyer les métriques pour la prochaine vague d'évolution au niveau programme. On peut demander : quelle est l'idée centrale ? Quelles sont les deux conditions motrices de l'extension ? Points de réponse : l'évolution traditionnelle a pour objet des vecteurs de paramètres numériques de faible dimension, l'espace de recherche étant limité par des préréglages manuels.
- L'expansion de la puissance de calcul et de la base d'ingénierie rend traitable la recherche de haute dimension, discrète et structurée.
- Le grand modèle peut construire et réécrire des objets au niveau programme, de sorte que l'objet de l'évolution s'étend couche par couche aux structures de modèles, mécanismes algorithmiques et programmes ou états d'ingénierie logicielle. Demander ensuite : comment le grand modèle participe-t-il à la construction et à l'évaluation des candidats au niveau programme ? Points de réponse : lire les scripts et le contexte d'exécution, réécrire l'optimiseur ou le flux de contrôle pour générer des candidats exécutables.
- L'exécution en temps réel vérifie si le programme peut s'exécuter, puis compare avec les contraintes d'ingénierie telles que les ressources et le budget temps ; les métriques renvoyées alimentent la prochaine vague d'évolution.

**Vérification de la compréhension**

Demander aux étudiants de reformuler dans leurs propres mots la chaîne d'extension des niveaux, et de compléter avec les capacités du grand modèle à droite et les contraintes de validation et de coût en haut. On peut demander en approfondissement : « Pourquoi, plus le niveau est élevé, plus l'évaluation de la fitness ressemble à un jugement conjoint des résultats d'exécution et des contraintes d'ingénierie ? » Confirmer que les étudiants peuvent citer des raisons telles que l'exécutabilité, la vérifiabilité et l'allongement de la chaîne d'évaluation.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer l'optimisation de paramètres de l'évolution au niveau programme ou système, passer à la page suivante sur la collaboration multi-agents et la sédimentation par validation.

<a id="lecture-page-4"></a>

### Défis complexes du monde réel : compromis multi-objectifs et maintien de la diversité

*Page 4*

> **Objectif de la page :** Comprendre l'importance des objectifs complexes et interdépendants dans les problèmes du monde réel et de la conservation de solutions candidates diversifiées.

**Points clés de l'enseignement**

- En multi-objectif, il n'existe pas d'ordre total naturel. Face à un ensemble de candidats, demander d'abord « selon quelles préférences compare-t-on », puis discuter des mérites ; sinon, on risque de prendre des préférences personnelles pour des conclusions objectives.
- Ne conserver que l'optimum actuel conduit à une convergence prématurée de la population et à l'effondrement des modes. On peut utiliser des mécanismes tels que la distance de crowding, les niches, les archives externes, pour disperser les candidats dans différentes régions du front et couvrir davantage d'intervalles de compromis.
- L'algorithme se charge de générer des options utilisables et différenciées, l'expert du domaine se charge d'évaluer et d'arbitrer selon les préférences et contraintes. Ne pas confondre « générer des candidats » et « décider à la place des humains ».

Objectif de la page

Comprendre la nature des objectifs mutuellement contraignants dans les problèmes du monde réel, et expliquer pourquoi le système doit conserver un ensemble de solutions candidates différenciées plutôt que de converger vers une « réponse optimale » unique.

Ordre de présentation

Les problèmes réels ont rarement une solution optimale unique. Plusieurs objectifs se contraignent mutuellement ; l'amélioration d'un indicateur se fait généralement au détriment d'autres indicateurs. Par conséquent, le système doit conserver un ensemble de solutions candidates non dominées et différenciées, rendre les relations de compromis explicitement visibles, et laisser la décision au jugement humain.

Les points gris représentent les solutions possibles, les points colorés les candidats mutuellement non dominés, qui constituent ensemble le front. Dans le schéma, A privilégie la résistance, B l'équilibre, C l'efficacité, D une traînée extrêmement faible. Le front de Pareto ne peut être qu'approché, jamais éliminé.

3. Développer quatre constats clés. Premièrement, le conflit d'objectifs est structurel, ce n'est pas un problème de réglage de paramètres : entre le rapport portance/traînée, la résistance structurelle, le coût, la fabricabilité, etc., il n'existe pas d'optimum simultané. Deuxièmement, en multi-objectif il n'y a pas d'ordre total : deux solutions quelconques peuvent être mutuellement non dominées, « le meilleur » ne peut être défini qu'avec une direction de préférence ; face à un ensemble de candidats, demander d'abord « selon quelles préférences compare-t-on », puis discuter des mérites. Troisièmement, la rétroaction sparse est la norme : l'évaluation en ingénierie réelle dépend de simulations coûteuses ou de mesures physiques, la rétroaction est rare, bruitée, le gradient indisponible, la recherche par escalade sur un point unique peine à progresser efficacement ; les algorithmes évolutionnaires, en maintenant une population, explorent simultanément plusieurs directions avec peu d'évaluations.

Ne rechercher que l'optimum actuel conduit à une convergence prématurée de la population et à l'effondrement des modes, faisant finalement perdre tout un intervalle de compromis inexploré ; on peut utiliser des mécanismes tels que la distance de crowding, les niches, les archives externes, pour disperser les candidats dans différentes régions du front.

L'algorithme se charge de « générer un ensemble d'options utilisables et différenciées », l'expert du domaine se charge de « l'évaluation et de l'arbitrage selon les préférences et contraintes ». Le groupe de solutions candidates ne décide pas à la place des humains, il met sur la table des options comparables.

Dans la conception de profils d'aile supercritiques, l'efficacité aérodynamique, les caractéristiques de divergence de traînée, la résistance structurelle et le coût de fabrication se contraignent mutuellement. La valeur d'EvoX ne réside pas dans la fourniture d'un « profil optimal » unique, mais dans la production d'une famille de profils candidats couvrant différents intervalles de compromis, pour que les ingénieurs choisissent selon les conditions de vol spécifiques et les contraintes de fabrication.

Points clés de l'enseignement

Définir « le meilleur » par la direction de préférence ; maintenir activement la diversité ; distinguer génération et arbitrage. En multi-objectif, il n'y a pas d'ordre total naturel ; ne conserver que l'optimum actuel conduit à l'effondrement de la population ; l'algorithme génère des candidats différenciés, l'expert effectue le jugement final selon les préférences et contraintes. Les deux petites figures à droite du schéma montrent intuitivement la différence entre convergence sur un point et distribution diversifiée : la première s'effondre en un amas, la seconde s'étale en front.

Traitement des exercices

L'absence d'ordre total signifie que la direction de préférence doit participer à la définition ; la rétroaction sparse rend la recherche sur un point unique difficile car l'évaluation est coûteuse, bruitée, le gradient indisponible ; la valeur de la dispersion des candidats est de laisser le choix et la connaissance du domaine aux experts ; ne poursuivre que l'optimum actuel conduit à une convergence prématurée et à l'effondrement des modes ; dans la conception de profils d'aile supercritiques, le positionnement d'EvoX est de produire une famille de profils candidats couvrant différents intervalles de compromis. En cas d'erreur, guider l'étudiant vers les trois mots-clés « direction de préférence », « rétroaction sparse », « la diversité est un atout ».

Guide d'étude de cas

Dans le scénario du taxi aérien urbain, on peut identifier les conflits entre autonomie et charge utile, entre bruit et efficacité aérodynamique, entre redondance de sécurité et coût de fabrication. Ces objectifs se contraignent mutuellement, il n'existe donc pas de conception unique simultanément optimale, seulement un front de Pareto de solutions mutuellement non dominées. EvoX peut traiter l'autonomie, la charge utile, le bruit, la redondance de sécurité, le coût, etc. comme multi-objectifs, exécuter une recherche par population, et produire des solutions candidates réparties dans différentes régions du front, mutuellement non dominées ; les experts du domaine effectuent ensuite, selon le scénario d'exploitation, les contraintes réglementaires et les conditions de fabrication, des simulations haute fidélité ou des mesures physiques sur les solutions candidates, et réalisent l'évaluation et l'arbitrage final selon la direction de préférence.

Vérification de la compréhension

Demander aux étudiants de donner dans leurs propres mots un exemple quotidien multi-objectif, comme le compromis entre performance, prix, poids et autonomie lors de l'achat d'un ordinateur portable, et de répondre « selon quelles préférences compare-t-on ». Si l'étudiant peut expliquer que le même ensemble de candidats donne des choix raisonnables différents selon les préférences, cela montre qu'il a compris le cœur de cette page.

Indication de transition

Après avoir confirmé que les étudiants peuvent distinguer « générer des candidats » et « décider à la place des humains », passer à la page suivante sur l'amélioration des méthodes de calcul ou des méthodes elles-mêmes. Cette page répond à « pourquoi le compromis multi-objectifs et la diversité des candidats sont nécessaires » ; la suite répondra séparément à « comment calculer plus vite » et « comment améliorer la méthode elle-même ».

<a id="lecture-page-5"></a>

### Calcul tensoriel et architecture unifiée pour l'exploration parallèle

*Page 5*

> **Objectif de la page :** Comprendre comment EvoX utilise le calcul tensoriel par lots pour soutenir une exploration évolutionnaire parallèle intensive.

> **Objectif de la page**
>
> Comprendre comment EvoX utilise le calcul tensoriel par lots pour soutenir une exploration évolutionnaire parallèle intensive, et saisir les deux axes complémentaires que sont le graphe de calcul tensoriel et l'architecture unifiée ouverte et découplée.
>
> Ordre de présentation suggéré :
>
> Lorsque la population passe de quelques dizaines à des milliers, le problème central du calcul évolutionnaire n'est plus « peut-on trouver une bonne solution », mais « peut-on évaluer suffisamment de candidats dans un temps limité ». La diversité dépend du débit ; maintenir la diversité est essentiellement une question de puissance de calcul.
>
> Le calcul tensoriel se charge de « faire aller vite », l'architecture unifiée de « pouvoir changer ».
>
> La boucle CPU série traditionnelle exécute « évaluation—enregistrement—mise à jour » individu par individu, ce qui entraîne trois types de coûts : surcharge d'ordonnancement élevée, fragmentation des opérateurs, sous-utilisation du GPU ; l'approche tensorielle organise l'ensemble de la maintenance de population, de l'évaluation par lots et de la mise à jour d'état en opérations tensorielles par lots, permettant le calcul parallèle de candidats d'une même génération voire de plusieurs générations. Par exemple, avec N solutions candidates, le mode série les traite une par une en boucle, le mode tensoriel organise la population en un tenseur, réalisant en une fois l'évaluation par lots et la mise à jour d'état parallèle, réduisant ainsi la surcharge d'ordonnancement et augmentant le taux d'occupation du GPU.
>
> Réécrire la boucle ne suffit pas : si l'algorithme, le problème et la logique d'ordonnancement sont couplés, changer d'algorithme ou de tâche nécessite une réécriture. L'architecture unifiée découple l'algorithme, le problème, le flux de travail et l'ordonnancement Runtime, et, associée à l'ordonnancement de puissance hétérogène gérant CPU/GPU au niveau des tâches par lots, permet à un même mécanisme parallèle d'être réutilisé dans des scénarios d'évolution de méthodes tels que MetaDE, AutoPSO.
>
> À gauche, la boucle CPU série traditionnelle, individu par individu, faible occupation GPU ; à droite, le calcul tensoriel par lots sur GPU, tenseur de population → évaluation par lots → mise à jour d'état parallèle ; en bas, la base unifiée ouverte et découplée, comprenant algorithme, problème, flux de travail, ordonnancement Runtime.

**Points clés de l'enseignement**

- EvoX ne se contente pas de résoudre des problèmes, il intègre la méthode de génération de solutions candidates elle-même dans l'objet de l'évolution. Dans MetaDE, l'algorithme externe fait évoluer la configuration et les stratégies de l'algorithme interne ; AutoPSO et EvoGO combinent davantage de composants et apprennent la méthode de génération de candidats à partir de la rétroaction historique, passant du « réglage de paramètres » à la « modification de la structure algorithmique ». Ce type d'évolution à double niveau exige naturellement qu'un grand nombre de tâches internes soient évaluées par lots et mises à jour en état. Il change la forme d'organisation du calcul, transformant tout le chemin « population—évaluation—mise à jour » en opérations tensorielles par lots, plutôt que de remplacer un opérateur ou de modifier l'encodage. Si le profilage de performance montre « trop de petits opérateurs, faible taux d'occupation GPU, part d'ordonnancement CPU élevée », cela indique généralement que le système fonctionne encore en boucle série individu par individu, ce qui est le signal d'entrée pour introduire le graphe de calcul tensoriel. Ne faire que de la tensorisation, changer d'algorithme ou de tâche nécessite une réécriture.
- Ne faire que de l'architecture unifiée, sans parallélisme par lots, ne permet toujours pas d'aller vite.

**Traitement des exercices**

Le changement central de la tensorisation est de réécrire la maintenance de population, l'évaluation par lots et la mise à jour d'état en opérations tensorielles par lots ; les principaux coûts de la boucle CPU série traditionnelle sont la surcharge d'ordonnancement élevée, la fragmentation des opérateurs et la sous-utilisation du GPU ; l'architecture unifiée ouverte et découplée vise à rendre le mécanisme parallèle réutilisable pour différents algorithmes et tâches ; avec N candidats d'une même génération, le bénéfice clé est de réaliser en une fois l'évaluation par lots et la mise à jour d'état parallèle ; la base apportée par le GPU et les grands modèles fait passer le calcul par lots d'une optimisation locale à une capacité fondamentale d'exploration évolutionnaire au niveau système. La rétroaction des réponses doit guider les étudiants vers les deux mots-clés « parallélisme par lots » et « réutilisation découplée », en évitant les distracteurs tels que « compresser la population », « évaluation approximative », « flux de travail fixe ».

L'exercice de cas demande de migrer l'évolution différentielle d'un mode série mono-machine vers une base parallèle par lots. Points de réponse de la question 1 : le mode série individu par individu entraîne une surcharge d'ordonnancement élevée, une fragmentation des opérateurs et une sous-utilisation du GPU ; la tensorisation atténue ces problèmes en organisant la population en tenseur, en fusionnant l'évaluation par lots et la mise à jour d'état, tout en préservant la sémantique de mutation, croisement et sélection. Points de réponse de la question 2 : l'architecture unifiée se décompose et se découple en couche algorithme, couche problème, couche flux de travail, couche ordonnancement Runtime ;
la couche algorithme ne décrit que la sémantique de génération et de mise à jour des candidats, la couche problème encapsule l'interface d'évaluation par lots, la couche flux de travail orchestre les tâches internes et externes, la couche ordonnancement Runtime gère l'ordonnancement de puissance hétérogène et la gestion des tâches par lots, permettant ainsi à une même base d'être réutilisée dans des scénarios d'évolution de méthodes tels que MetaDE, AutoPSO.

**Vérification de la compréhension**

On peut demander aux étudiants d'expliquer dans leurs propres mots « ce que résout le graphe de calcul tensoriel, ce que résout l'architecture unifiée », et d'illustrer par un exemple pourquoi les deux doivent être associés.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer « aller vite » et « pouvoir changer », passer à la page suivante sur les cas concrets ou les mécanismes d'ingénierie de l'évolution continue au niveau système.

<a id="lecture-page-6"></a>

### L'évolution de l'algorithme lui-même : de la résolution de réponses à l'amélioration de méthodes

*Page 6*

> **Objectif de la page :** Comprendre le principe fondamental de l'intégration de la méthode de génération de candidats dans l'objet d'optimisation pour permettre l'auto-évolution de l'algorithme.

**Points clés de l'enseignement**

- Le niveau interne cherche des réponses, le niveau externe modifie la méthode. Si l'on voit « stratégies, paramètres, opérateurs, composants placés dans la recherche », c'est de l'évolution de méthode ; si l'on voit « seules les solutions candidates changent, les règles de génération restent invariables », c'est un algorithme évolutionnaire traditionnel.
- Le signal de préférence entre d'abord dans l'évaluation des réponses, puis passe par une agrégation inter-tâches et un test de stabilité, avant d'être autorisé à entrer dans la sélection de méthode. Sauter cette étape ferait courir le niveau externe après un résultat flatteur mais non reproductible.
- Quelle est la taille de l'espace des méthodes ? Combien de fois faut-il exécuter les tâches internes à chaque tour ? Avec quel ensemble de tâches indépendantes valider que l'amélioration externe se généralise vraiment ? Si ces trois comptes ne sont pas clairs, la recherche à double niveau dégénère facilement en un réglage de paramètres aléatoire plus coûteux.

Objectif de la page

Les algorithmes évolutionnaires traditionnels recherchent sous un mécanisme de génération fixe, l'objet optimisé étant toujours la solution candidate ; l'évolution de méthode intègre la méthode de génération de solutions candidates elle-même dans l'objet de recherche, accomplissant le passage de « résoudre des réponses » à « améliorer des méthodes ».

Ordre de présentation

1. Comparer d'abord la différence entre algorithme évolutionnaire traditionnel et évolution de méthode, en soulignant le déplacement de « l'objet optimisé ».

2. Introduire la définition de l'évolution de méthode, et expliquer qu'EvoX avance sur cette voie en intégrant la méthode de génération de candidats elle-même dans l'objet d'évolution.

Le niveau interne cherche des réponses, le niveau externe modifie la méthode.

4. Positionner où placer l'optimisation des préférences, en insistant sur le fait que les deux types d'objectifs ne doivent pas être confondus.

5. Citer MetaDE, AutoPSO et EvoGO comme formes typiques.

6. Conclure sur les bénéfices et les coûts, et traiter exercices et cas.

Points clés de l'enseignement

Les règles de « comment produire des réponses » telles que la sélection, le croisement, la mutation sont préalablement écrites par l'homme, la recherche ne se déplace que dans l'espace des réponses. Avec l'ouverture de l'échelle de calcul, le mécanisme de génération fixe devient au contraire un plafond.

L'algorithme ne produit pas seulement de meilleures réponses, il améliore en continu par la recherche externe les stratégies, paramètres et composants qui produisent les réponses. EvoX s'inscrit dans cette voie, par exemple en intégrant les stratégies de mutation et les réglages de paramètres de l'évolution différentielle dans l'objet d'évolution.

Le niveau interne résout un problème spécifique avec la méthode courante, produisant des solutions candidates ; le niveau externe, sur la base de la qualité des solutions, des signaux de préférence, de la stabilité ou du coût, compare, sélectionne et met à jour la méthode utilisée au tour suivant. L'objet remonté dans l'espace de recherche n'est pas une solution particulière, mais le mécanisme de génération de candidats lui-même, qui devient donc un objet évaluable, sélectionnable et mettable à jour.

La couche supérieure est « la méthode d'évolution produisant des solutions candidates », comprenant stratégies/paramètres/composants d'opérateurs, recherche évolutionnaire externe, méthode de génération améliorée ; la couche inférieure est « la résolution du problème spécifique », comprenant la méthode courante, les solutions candidates, l'évaluation de la qualité des solutions. Les deux boucles représentent respectivement le retour des résultats externes vers l'interne et la rétroaction de la qualité des solutions/préférences/coûts pilotant les deux niveaux. Au tableau, on peut d'abord dessiner les deux niveaux supérieur et inférieur, puis marquer par des flèches « mise à jour de la méthode de génération » et « signal de rétroaction ».

Peut participer à la rétroaction du niveau supérieur, mais il faut séparer « évaluer la réponse actuelle » et « améliorer la méthode de génération de réponses ». Lire « cette solution est plus plaisante » directement comme « cette stratégie est meilleure », c'est usurper la qualité de la méthode par la préférence des réponses ; le niveau externe serait alors guidé par le bruit d'un résultat unique. Le signal de préférence entre d'abord dans l'évaluation des réponses, puis passe par une agrégation inter-tâches et un test de stabilité, avant d'être autorisé à entrer dans la sélection de méthode.

MetaDE fait évoluer au niveau externe les stratégies de mutation et les paramètres de l'évolution différentielle, le niveau interne résolvant les tâches normalement ; AutoPSO et EvoGO combinent davantage de composants d'essaim particulaire et apprennent la méthode de génération de candidats à partir de la rétroaction historique, réalisant le saut du « réglage de paramètres » à la « modification de la structure algorithmique ».

Le bénéfice est de pousser la conception d'algorithmes d'un réglage manuel ponctuel vers une auto-adaptation durable. Trois coûts : l'expansion de l'espace de recherche, l'espace des méthodes étant bien plus grand que l'espace des solutions ; l'augmentation du coût d'évaluation, chaque ensemble de méthodes candidates devant exécuter les tâches internes, dépendant généralement d'une évaluation parallèle par lots sur GPU pour être amorti ; l'augmentation de la complexité de validation, la généralisation réelle de l'amélioration externe nécessitant une conception de validation indépendante.

Indices d'exercices et guide de réponses

1. Par rapport à un algorithme évolutionnaire traditionnel, quelle est la différence la plus essentielle de l'évolution de méthode en termes d'« objet optimisé » ? La bonne direction est : intégrer dans l'objet de recherche les stratégies, paramètres et composants d'opérateurs qui déterminent « comment produire des réponses ». Si l'étudiant choisit « population plus grande » ou « suppression de l'évaluation de fitness », lui rappeler le déplacement de l'objet d'optimisation : ce n'est plus seulement la réponse qui est optimisée, mais le mécanisme qui produit les réponses.

Qualité des solutions, signaux de préférence, stabilité ou coût — des rétroactions provenant de la performance des tâches internes. Si l'étudiant choisit par erreur « bruit aléatoire » ou « spécification manuelle par l'ingénieur », le guider à se demander : sur quelle base le niveau externe juge-t-il qu'une stratégie est meilleure qu'une autre ? Ce « sur quelle base » est le signal de rétroaction.

Faire participer le signal de préférence à la rétroaction du niveau supérieur, mais traiter « évaluer la réponse actuelle » et « améliorer la méthode de génération » comme deux types d'objectifs distincts. Si l'étudiant prend la préférence des réponses pour la qualité de la méthode, lui rappeler : la préférence doit passer par une agrégation inter-tâches et un test de stabilité pour passer de « préférence de réponse » à « critère de méthode ».

Expansion de l'espace des méthodes, coût d'évaluation interne pour chaque méthode, et difficulté de validation accrue. On peut résumer en trois pressions : espace, puissance de calcul, validation ; l'évolution de méthode élève l'objet de recherche d'un niveau, et le coût monte avec.

5. Concernant MetaDE et AutoPSO, quelle affirmation est exacte ? La bonne direction est : MetaDE utilise le niveau externe pour faire évoluer les stratégies de mutation et les paramètres de l'évolution différentielle, le niveau interne restant responsable de la résolution des candidats pour des tâches spécifiques. AutoPSO et EvoGO vont plus loin vers la combinaison de composants et l'amélioration au niveau structurel, la direction étant de passer du réglage de paramètres à la modification de structure.

Traitement du cas

Le scénario est une équipe optimisant la disposition de puces sur un cluster GPU, disposant déjà d'un solveur par évolution différentielle, mais dont les stratégies de mutation et paramètres dépendent de l'expérience humaine, avec des performances fluctuantes marquées ; il est prévu d'introduire une optimisation à double niveau de type MetaDE, en guidant la recherche par les préférences utilisateur.

L'entrée du niveau interne est la méthode courante (stratégie de mutation et configuration de paramètres) et une instance de problème de disposition spécifique, la sortie étant la disposition candidate et sa qualité de solution. L'entrée du niveau externe est le résumé statistique de la performance des tâches internes, la sortie étant la stratégie et la configuration de paramètres mises à jour. Le signal de rétroaction doit être agrégé à travers les tâches et les exécutions répétées, par exemple moyenne multi-tâches, quantiles ou indicateurs de stabilité, et non extrait d'une seule exécution. La raison est que la qualité d'une solution unique dépend fortement de l'instance spécifique et du hasard ; elle mesure « si cette réponse-ci est bonne », et non « si cette méthode-ci est bonne » ; utiliser directement un résultat unique pour piloter le niveau externe ferait dominer celui-ci par les différences d'instance et le bruit.

Le niveau interne peut utiliser une fonction d'évaluation pondérée par les préférences pour filtrer les dispositions candidates ; le niveau externe doit d'abord convertir en un critère de comparaison stable inter-tâches, par exemple un score pondéré des indicateurs de longueur de fil et de congestion avec sa variance, avant de l'utiliser pour choisir la configuration de méthode, évitant de prendre une préférence de réponse unique pour la qualité de la méthode.

L'expansion de l'espace de recherche peut être contrôlée par regroupement de paramètres, recherche hiérarchique, du grossier au fin ; l'augmentation du coût d'évaluation peut être réduite par évaluation parallèle par lots sur GPU, évaluation substitut sur petit échantillon et mécanisme d'arrêt précoce ; l'augmentation de la complexité de validation nécessite de conserver un ensemble de tâches de validation indépendant et de répéter les exécutions, pour vérifier si l'amélioration externe se généralise réellement.

Vérification de la compréhension et transition

Le niveau interne cherche des réponses, le niveau externe modifie la méthode. Si l'on voit « stratégies, paramètres, opérateurs, composants placés dans la recherche », c'est de l'évolution de méthode ; si l'on voit « seules les solutions candidates changent, les règles de génération restent invariables », c'est un algorithme évolutionnaire traditionnel. Après avoir confirmé que les étudiants peuvent expliquer « l'objet optimisé a changé » et « la préférence ne peut pas usurper directement la qualité de la méthode », passer aux exemples, applications ou synthèse de la page suivante.

<a id="lecture-page-7"></a>

### MetaDE et AutoPSO : architecture à double niveau de l'évolution de méthode

*Page 7*

> **Objectif de la page :** Maîtriser comment MetaDE et AutoPSO réalisent l'auto-évolution des variantes d'algorithmes et des paramètres par optimisation à double niveau interne/externe.

> **Objectif de la page**
>
> Comprendre comment MetaDE et AutoPSO réalisent l'auto-évolution de la configuration et de la structure algorithmiques par une architecture d'optimisation à double niveau interne/externe, et maîtriser sa structure de coûts et ses compromis d'ingénierie.

> **Ordre de présentation**
>
> L'algorithme ne se contente plus de trouver des solutions, il doit aussi améliorer « sa propre façon de trouver des solutions ».
>
> 2. Présenter l'abstraction générique de l'architecture à double niveau interne/externe, en soulignant que le niveau externe recherche l'espace des algorithmes, le niveau interne résout la tâche cible, et la performance interne est renvoyée comme signal de fitness formant une boucle fermée.
>
> 3. Présenter séparément les deux voies d'implémentation MetaDE et AutoPSO, en expliquant que la première gère la couche de configuration, la seconde la couche structure/composants.
>
> 4. Analyser l'effet multiplicateur des coûts de l'optimisation à double niveau, en introduisant les compromis d'ingénierie tels que l'allocation budgétaire, l'évaluation approximative, l'arrêt précoce, la parallélisation.
>
> Passer de la conception manuelle d'un algorithme unique à la conception d'un espace d'algorithmes évolutifs et d'un mécanisme d'évaluation.

**Points clés de l'enseignement**

- L'évolution de méthode (Meta-Evolution) prend « la méthode qui produit les candidats » elle-même comme objet d'optimisation. Le niveau externe recherche des configurations d'algorithmes, des combinaisons de composants ou des stratégies, et non des solutions de tâche. Le niveau externe se charge de rechercher l'espace des algorithmes (hyperparamètres, stratégies, combinaisons de composants, etc., c'est-à-dire « la définition de l'algorithme »).
- Le niveau interne utilise l'algorithme candidat pour réellement résoudre la tâche cible, obtenant une performance mesurable.
- La performance interne est agrégée en fitness et renvoyée au niveau externe, qui élimine les configurations médiocres, conserve et mute les configurations de qualité, formant une boucle d'amélioration continue. Conserver l'évolution différentielle comme solveur interne, confier la configuration de DE elle-même à la recherche externe — stratégies de mutation, taux de croisement, facteurs d'échelle, etc., ajustés adaptativement selon le problème et la phase d'optimisation. Cela répond à « comment régler cette configuration à la phase actuelle de la tâche », relevant de l'évolution de méthode au niveau configuration. Considérer les paramètres clés et les mécanismes d'apprentissage de PSO comme des composants combinables — poids d'inertie, facteurs d'apprentissage, et différentes combinaisons de mécanismes d'apprentissage individuel et collectif, recherchés et combinés automatiquement par le niveau externe pour produire des variantes de PSO adaptées à différents problèmes. Cela transforme « choisir un algorithme » en « rechercher une structure d'algorithme », réalisant le saut de l'auto-adaptation des paramètres à l'auto-génération des mécanismes. MetaDE penche vers l'auto-réglage au niveau configuration et hyperparamètres, AutoPSO vers la combinaison automatique au niveau structure et composants, couvrant ensemble la plage d'évolution de l'auto-adaptation des paramètres à l'auto-génération des mécanismes. Le coût clé de l'optimisation à double niveau réside dans l'effet multiplicateur — chaque évaluation d'un algorithme candidat au niveau externe nécessite souvent plusieurs exécutions internes (évaluations répétées pour le hasard, validation conjointe multi-tâches, etc.), le budget de calcul étant significativement amplifié. Le calcul réel équivaut approximativement à « nombre d'algorithmes candidats au niveau externe × nombre d'exécutions internes par candidat ». Allocation budgétaire, évaluation approximative, arrêt précoce, parallélisation. L'exécution efficace dépend du parallélisme tensoriel, de l'ordonnancement Runtime et de la composabilité des algorithmes.
- La parallélisation peut atténuer le temps horloge, mais ne réduit pas le calcul total. Ce que le chercheur livre n'est plus un algorithme fixe, mais un espace de recherche et des règles de rétroaction permettant à l'algorithme de s'améliorer continuellement.

**Vérification de la compréhension**

On peut poser les questions successivement et donner les points de réponse :

1. Quel est l'objet direct de la recherche du niveau externe ?

La configuration, la structure et les combinaisons de composants de l'algorithme lui-même. L'essence de l'évolution de méthode est de prendre l'algorithme lui-même comme objet d'optimisation ; le niveau externe recherche configurations et structures dans l'espace des algorithmes, et non directement des solutions de tâche. Bien distinguer les deux niveaux : le niveau interne recherche directement des solutions ; le niveau externe recherche « quel algorithme utiliser, comment le configurer ».

2. Dans MetaDE, quel ensemble d'objets le niveau externe fait-il principalement évoluer ?

Les stratégies de mutation, le taux de croisement et les facteurs d'échelle de l'évolution différentielle. MetaDE permet à la configuration de DE de s'adapter selon le problème et la phase, relevant de l'évolution de méthode au niveau configuration/hyperparamètres, et non de la structure d'autres algorithmes.

3. Concernant la répartition entre AutoPSO et MetaDE, quelle description est la plus exacte ?

AutoPSO se concentre sur la combinaison automatique des paramètres et mécanismes d'apprentissage, transformant « choisir un algorithme » en « rechercher une structure d'algorithme » ; MetaDE se concentre sur l'évolution au niveau configuration. Les deux sont complémentaires : MetaDE couvre la couche configuration et hyperparamètres, AutoPSO la couche structure et composants, constituant ensemble la plage d'évolution de l'auto-adaptation des paramètres à l'auto-génération des mécanismes, et devant tous deux passer par l'évaluation interne.

4. Concernant la structure de coûts de l'optimisation à double niveau, quelle affirmation est correcte ?

Chaque évaluation d'un algorithme candidat au niveau externe nécessite souvent plusieurs exécutions internes, le budget étant significativement amplifié, nécessitant allocation budgétaire, évaluation approximative ou arrêt précoce. Le coût principal de l'architecture à double niveau est l'effet multiplicateur ; la parallélisation ne peut qu'atténuer, non éliminer la surcharge totale.

5. Après adoption de l'architecture à double niveau d'évolution de méthode, quelle est la transformation cognitive du rôle de chercheur ?

Passer de la conception manuelle d'un algorithme unique à la conception d'un espace où l'algorithme peut évoluer et d'un mécanisme d'évaluation. Ce qui est livré n'est plus un algorithme fixe, mais « un espace d'algorithmes évolutifs + des règles d'évaluation de fitness » ; la recherche externe et la résolution interne forment ainsi une boucle d'amélioration continue. Bien qu'on ne fixe plus manuellement un algorithme unique, le travail central devient la conception de l'espace de recherche et du mécanisme d'évaluation, la responsabilité étant au contraire plus lourde.

**Traitement des exercices**

Le cas « construire un service d'évolution à double niveau pour des tâches en changement continu » peut être utilisé après l'exposé de l'architecture et des coûts, en laissant les étudiants répondre d'abord individuellement, puis discuter collectivement.

Expliquer ce dont le niveau interne et le niveau externe sont respectivement responsables, et comment circule le signal.

Le niveau externe recherche des algorithmes candidats dans l'espace des algorithmes — il peut faire évoluer les stratégies de mutation, le taux de croisement, les facteurs d'échelle de DE (voie MetaDE), ou combiner automatiquement les composants de PSO tels que poids d'inertie, facteurs d'apprentissage et mécanismes d'apprentissage (voie AutoPSO). Le niveau interne exécute chaque algorithme candidat sur la tâche cible du jour et l'évalue, produisant une performance comparable ; la performance interne est agrégée en fitness et renvoyée au niveau externe, qui élimine les candidats médiocres, conserve et mute les configurations de qualité, itérant continuellement, formant une boucle fermée « le niveau externe recherche l'espace des algorithmes, le niveau interne résout la tâche cible, la rétroaction de performance pilote l'amélioration ».

Face à la pression budgétaire « une évaluation externe nécessite plusieurs exécutions internes », donner au moins deux mesures de compromis et expliquer leur coût ou risque.

① Allocation budgétaire — fixer des quotas de calcul séparés pour l'externe et l'interne et limiter les répétitions internes, au prix d'une variance d'évaluation accrue et d'un risque de mauvais choix ; ② Évaluation approximative — estimer la fitness par sous-ensemble de données ou exécution courte, au prix d'un signal bruité et d'une possible sous-estimation des meilleurs candidats ; ③ Arrêt précoce — interrompre les exécutions internes des candidats manifestement médiocres, au prix d'une élimination prématurée possible de configurations à démarrage lent mais performantes plus tard ; ④ Parallélisme tensoriel et ordonnancement Runtime — exécutions internes concurrentes par lots, atténuant significativement le temps horloge mais ne réduisant pas le calcul total, et limité par la mémoire GPU et la surcharge d'ordonnancement. La réponse doit expliquer la correspondance entre chaque mesure et son coût ou risque, et refléter l'estimation multiplicative « échelle de recherche externe × nombre d'exécutions internes par évaluation ».

Langage de rétroaction :

Correct. Cette réponse sait relier les concepts de cette page et justifier son raisonnement.

Veuillez revenir à l'exposé de cette page, trouver les preuves ou exemples clés avant de juger.

Attention à distinguer les « niveaux » — le niveau interne recherche directement des solutions, le niveau externe recherche « quel algorithme utiliser, comment le configurer » ; l'objet de MetaDE est la configuration de l'évolution différentielle elle-même, et non la structure d'autres algorithmes ; le coût principal de l'architecture à double niveau est l'effet multiplicateur, la parallélisation ne peut qu'atténuer, non éliminer la surcharge totale ; bien qu'on ne fixe plus manuellement un algorithme unique, le travail central du chercheur devient la conception de l'espace de recherche et du mécanisme d'évaluation, la responsabilité étant au contraire plus lourde.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer dans leurs propres mots « évolution au niveau configuration » et « évolution au niveau structure/composants », et énoncer la boucle de signaux interne/externe et l'effet multiplicateur budgétaire, passer aux exemples, applications ou synthèse de la page suivante.

<a id="lecture-page-8"></a>

### Cas pratique multi-objectif : conception de profil d'aile supercritique

*Page 8*

> **Objectif de la page :** Apprendre à utiliser EvoX pour traiter des contraintes d'ingénierie complexes et générer des solutions de compromis diversifiées dans la conception de profils d'aile.

> **Objectif de la page**
>
> Comprendre pourquoi la conception de profils d'aile supercritiques est un problème multi-objectif, et maîtriser comment utiliser EvoX pour générer des solutions de compromis diversifiées sous contraintes d'ingénierie strictes.

> **Ordre de présentation**
>
> La conception de profils d'aile supercritiques est une pratique multi-objectif d'EvoX en ingénierie réelle. Les paramètres de forme du profil — courbure, épaisseur, bord de fuite — sont couplés entre eux ; modifier la forme affecte simultanément plusieurs indicateurs aérodynamiques.
>
> Améliorer un indicateur se fait souvent au détriment d'un autre, il ne s'agit donc pas d'une optimisation mono-objectif mais d'un compromis multi-objectif.
>
> Les exigences de portance, d'angle d'attaque, d'épaisseur, etc. délimitent le domaine de conception faisable ; la recherche doit se dérouler sous contraintes satisfaites pour garantir que les solutions candidates soient utilisables en ingénierie.
>
> EvoX génère un ensemble diversifié de solutions candidates équilibrant les différents indicateurs, et non une solution optimale unique ; le groupe de candidats permet aux experts du domaine de comparer les différents bénéfices et coûts et d'arbitrer.
>
> Ce cas transforme un problème réel complexe en un processus explorable et évaluable, cherchant des solutions de compromis explicables dans les conflits entre contraintes et objectifs.

**Points clés de l'enseignement**

- Les changements de forme du profil d'aile supercritique affectent plusieurs indicateurs aérodynamiques, les objectifs étant souvent en conflit, nécessitant un compromis multi-objectif. La conception doit satisfaire plusieurs contraintes strictes de portance, angle d'attaque et épaisseur ; la recherche doit se dérouler dans le domaine de conception faisable. Générer des solutions candidates diversifiées, aidant les experts à évaluer les différents bénéfices et coûts et à arbitrer. D'abord explorer en continu dans l'espace des paramètres de profil (courbure, épaisseur, bord de fuite), puis approcher le front de compromis multi-objectif (indicateur A et indicateur B), aboutissant finalement à un groupe de solutions candidates. Profil d'aile supercritique, compromis multi-objectif, domaine de conception faisable, groupe de solutions candidates, EvoX.

> **Indices d'exercices**
>
> - La racine du problème multi-objectif, le rôle des contraintes, la sortie pratique d'EvoX, la signification des candidats diversifiés, la valeur de la méthode. La bonne compréhension doit porter sur : les paramètres de forme affectant simultanément plusieurs indicateurs, causant des conflits d'objectifs.
> - Les contraintes délimitent le domaine de conception faisable.
> - La sortie est un groupe diversifié de solutions candidates.
> - Différents candidats représentent différents bénéfices et coûts.
> - La valeur de la méthode est de transformer un problème réel complexe en un processus explorable et évaluable.

**Traitement des exercices**

Si l'étudiant choisit par erreur « il suffit d'optimiser la portance » ou « trouver la solution optimale unique », lui rappeler le couplage des paramètres de forme et les conflits d'objectifs.

Si l'étudiant choisit par erreur « les contraintes peuvent être relâchées à volonté » ou « sans rapport avec la faisabilité en ingénierie », lui rappeler que les contraintes délimitent le domaine de conception faisable et ne peuvent être relâchées à volonté.

Si l'étudiant choisit par erreur « un profil optimal unique » ou « une forme aléatoire », lui rappeler que la sortie doit être un groupe diversifié de solutions candidates équilibrant les différents indicateurs.

Correct, cette réponse sait relier les concepts de cette page et justifier son raisonnement.

Veuillez revenir à l'exposé de cette page, trouver les preuves ou exemples clés avant de juger.

**Activité en classe**

Parce que les changements de paramètres de forme affectent simultanément plusieurs indicateurs aérodynamiques, améliorer un indicateur se fait souvent au détriment d'un autre, nécessitant un compromis multi-objectif ; les contraintes délimitent le domaine de conception faisable, garantissant la faisabilité en ingénierie des solutions candidates.

**Vérification de la compréhension**

Comment EvoX, dans la conception de profils d'aile supercritiques, génère sous contraintes strictes un groupe diversifié de solutions candidates pour que les experts évaluent bénéfices et coûts. L'enseignant complète selon la réponse les mots-clés manquants : conflit d'objectifs, domaine de conception faisable, groupe de solutions candidates, compromis multi-objectif.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer optimisation mono-objectif et compromis multi-objectif, et expliquer l'usage du groupe de solutions candidates, passer aux exemples, applications ou synthèse de la page suivante.

<a id="lecture-page-9"></a>

### Défis à travers les cycles de vie : épuisement du contexte et persistance au niveau projet

*Page 9*

> **Objectif de la page :** Comprendre la contradiction entre les limites de contexte des grands modèles et les projets d'ingénierie réels durant des mois ou des années.

**Points clés de l'enseignement**

- Le contexte unique est un établi, le dépôt du projet est la mémoire à long terme. Ne pas laisser l'état de population, les configurations échouées et les raisons de décision uniquement dans la fenêtre de session ; avant de fermer la session, les écrire dans des artefacts au niveau projet, et à la prochaine session, les lire d'abord avant de continuer.
- La persistance héritable exige des artefacts versionnables, interrogeables, explicables : code, tests, enregistrements d'expériences, journal de décisions, indicateurs d'évaluation et conclusions de validation doivent pouvoir répondre à pourquoi ce choix, quels échecs passés, quels conflits subsistent.
- Les Agents de niveau supérieur décomposent les objectifs, les Agents de niveau inférieur implémentent et testent. Avant chaque fin de session, établir un point de contrôle : mettre à jour le journal de décisions et les indicateurs d'évaluation ; au démarrage d'une nouvelle session, hériter d'abord du point de contrôle, puis décider des actions locales, franchissant ainsi plusieurs cycles de vie limités.

> **Objectif de la page**
>
> Comprendre la contradiction entre les limites de contexte des Agents grands modèles et les projets d'ingénierie réels durant des mois voire des années, et établir la nécessité de la persistance au niveau projet. Jugement central : la fenêtre de contexte unique C_max est une ressource limitée, le cycle de vie du projet T_projet peut durer des mois voire des années, donc T_projet ≫ C_max. La vraie difficulté n'est pas l'insuffisance de la capacité de raisonnement ponctuelle, mais l'impossibilité pour l'expérience de traverser le cycle de vie de l'Agent.
>
> Ordre de présentation
>
> Le contexte d'un Agent unique ne peut contenir que l'objectif courant, les observations locales et le raisonnement récent ; à la fermeture de la session, l'état est effacé, les conclusions temporaires et l'expérience ne sont plus disponibles. Sans persistance, les sessions suivantes ne peuvent que répéter l'exploration.
>
> Persistance au niveau projet. Externaliser les configurations échouées, les processus de compromis, les solutions candidates et les conclusions de validation en artefacts persistants au niveau projet, incluant code, tests, enregistrements d'expériences, journal de décisions, indicateurs d'évaluation et conclusions de validation. Les Agents suivants n'ont pas besoin de repartir de zéro, mais lisent l'expérience antérieure, jugent quelles directions sont déjà validées, quels conflits non résolus, quels indicateurs atteints.
>
> L'objet de l'évolution n'est plus seulement un paramètre numérique ou une solution candidate ponctuelle, mais un monde logiciel persistant, versionnable, héritable. Chaque session produit de nouveaux artefacts qui modifient l'état de ce monde, la session suivante continue d'évoluer sur le monde mis à jour, le processus d'optimisation devenant ainsi une évolution continue au niveau projet.
>
> Plusieurs Agents à cycle de vie limité peuvent travailler en collaboration ; les exécutants supérieurs comprennent l'objectif et décomposent les tâches, les exécutants inférieurs réalisent l'implémentation locale et les tests, en poursuivant la décomposition récursive si nécessaire. Avant fermeture, écrire l'état clé ; au démarrage d'un nouvel Agent, lire d'abord la mémoire du projet, puis décider des actions locales.
>
> Les projets à long cycle ont souvent des conflits d'objectifs, par exemple performance, coût, robustesse difficiles à optimiser simultanément ; la rétroaction peut aussi être sparse, une expérience nécessitant des heures voire des jours d'attente. Le journal de décisions persistant et les indicateurs d'évaluation peuvent transformer la rétroaction sparse en expérience héritable, évitant aux Agents suivants de répéter les mêmes erreurs.
>
> Points clés de l'enseignement
>
> Le contexte unique est un établi, le dépôt du projet est la mémoire à long terme. Ne pas laisser l'état de population, les configurations échouées et les raisons de décision uniquement dans la fenêtre de session ; avant de fermer la session, les écrire dans des artefacts au niveau projet, et à la prochaine session, les lire d'abord avant de continuer.
>
> La persistance n'est pas une accumulation de journaux. La persistance héritable exige des artefacts versionnables, interrogeables, explicables : code, tests, enregistrements d'expériences, journal de décisions, indicateurs d'évaluation et conclusions de validation doivent pouvoir répondre à pourquoi ce choix, quels échecs passés, quels conflits subsistent.
>
> Avant chaque fin de session, mettre à jour le journal de décisions et les indicateurs d'évaluation ; au démarrage d'une nouvelle session, hériter d'abord du point de contrôle, puis décider des actions locales, franchissant ainsi plusieurs cycles de vie limités.
>
> L'évolution continue au niveau projet, c'est-à-dire transférer le processus de génération de candidats, d'évaluation de candidats, d'enregistrement des compromis et des conclusions de validation, du contexte d'un Agent unique vers des artefacts persistants au niveau projet, permettant au projet d'itérer en continu à travers plusieurs cycles de vie d'Agents.
>
> Indices d'exercices
>
> Il faut choisir « la fenêtre de contexte est limitée, et à la fermeture de la session l'état et l'expérience ne sont plus fiables ». En rétroaction, souligner : la limite dure réside dans la longueur limitée et l'effacement de l'état à la fermeture de la session, et non dans la taille des paramètres, le degré de parallélisme ou la fonction objectif.
>
> Il faut choisir « code, tests, enregistrements d'expériences, journal de décisions, indicateurs d'évaluation et conclusions de validation ». En rétroaction, expliquer que ces artefacts constituent ensemble la mémoire du projet.
>
> Il faut choisir « passer d'un paramètre numérique/solution candidate ponctuel à un monde logiciel persistant, versionnable, héritable ». En rétroaction, distinguer le changement de paradigme d'entraînement du changement de frontière de l'objet d'évolution.
>
> Il faut choisir « le niveau supérieur comprend l'objectif et décompose les tâches, le niveau inférieur réalise l'implémentation locale et les tests, avec décomposition récursive si nécessaire ». En rétroaction, souligner que la continuité inter-cycles de vie est garantie par la persistance au niveau projet.
>
> Il faut choisir « après chaque fermeture de session, l'état de population, les configurations échouées et les raisons de décision sont perdus, les Agents suivants répètent l'exploration ». En rétroaction, expliquer que l'absence de persistance ne résout pas automatiquement les conflits d'objectifs ni n'élargit le contexte.
>
> En cas de bonne réponse, on peut confirmer « sait relier les concepts de cette page et justifier son raisonnement » ; en cas d'erreur, inviter l'étudiant à revenir à l'exposé de cette page, trouver les preuves ou exemples clés avant de juger.
>
> Traitement des exercices
>
> L'objectif comprend l'efficacité aérodynamique, la résistance structurelle et le coût de fabrication, les trois étant en conflit, la rétroaction de simulation sparse, et l'équipe souhaite une collaboration continue de plusieurs Agents à cycle de vie court. La première question demande d'expliquer pourquoi la mémoire du projet ne peut pas être placée uniquement dans un contexte unique, et de lister au moins trois catégories d'artefacts à persister. Points de réponse : la fenêtre de contexte unique est limitée et l'état est effacé à la fermeture de la session, alors que le projet s'étend sur des mois, T_projet ≫ C_max ; ne dépendre que du contexte unique ferait perdre l'état de population, les résultats de simulation, les configurations échouées, les conflits d'indicateurs et les raisons de décision ; la persistance doit inclure au moins le code et les scripts d'entraînement de modèles substituts, les enregistrements de tests et d'indicateurs d'évaluation, les enregistrements d'expériences et configurations échouées, le journal de décisions et les raisons de compromis, les solutions candidates et les conclusions de validation.
>
> Au démarrage de la session, lire d'abord le journal de décisions, les indicateurs d'évaluation, les enregistrements d'expériences et les solutions candidates, restaurer l'état de population et les conflits non résolus ; pendant la session, écrire les nouveaux modèles substituts, résultats de simulation, évaluations de candidats et analyses de compromis ; avant fermeture, mettre à jour le journal de décisions, enregistrer les configurations échouées du tour, les conflits d'indicateurs, les raisons d'abandon et les suggestions suivantes, et soumettre en versioning ; les sessions suivantes héritent des configurations échouées et des raisons de décision en lisant ces artefacts, évitant la répétition de l'exploration.

**Vérification de la compréhension**

Demander aux étudiants de résumer dans leurs propres mots « pourquoi la mémoire du projet ne peut pas être conservée uniquement dans le contexte d'un Agent unique », et de citer au moins trois catégories d'objets persistants au niveau projet. Indication de transition : après avoir confirmé que les étudiants peuvent énoncer la relation centrale de cette page — T_projet ≫ C_max, la persistance au niveau projet externalisant l'expérience en un monde logiciel héritable — passer aux exemples, applications ou synthèse de la page suivante.

<a id="lecture-page-10"></a>

### Architecture Genesis et paradigme de sédimentation du monde logiciel

*Page 10*

> **Objectif de la page :** Maîtriser comment Genesis permet au code d'un projet de s'accumuler et d'évoluer en continu à travers les cycles de vie.

> **Objectif de la page**
>
> Aider les étudiants à comprendre comment Genesis réancre l'intelligence, du processus de session volatil, vers un monde logiciel accumulable, permettant au code du projet et aux résultats d'ingénierie de s'accumuler, évoluer et s'hériter en continu à travers une fenêtre de contexte unique et un cycle de vie unique.

> **Ordre de présentation**
>
> Commencer par poser le critère de jugement « la session est volatile, le dépôt est la mémoire à long terme », puis dérouler successivement la différence essentielle du paradigme de sédimentation, la répartition des quatre catégories d'actifs sédimentables, la condition de stabilité des interfaces, la boucle de sédimentation et le gardien de validation, l'héritage inter-cycles de vie, et conclure en une phrase sur la frontière de répartition entre EvoX et Genesis.

**Points clés de l'enseignement**

- 1. Pour juger si un travail a une valeur de sédimentation, poser une seule question — la personne suivante peut-elle le reproduire sans venir poser aucune question ? Si non, ce n'est pas encore un actif. Le flux de travail conversationnel s'évapore avec la fin du contexte, la production reste dans « cette session-ci ».
- Le monde logiciel, ayant pour médium le dépôt, le versioning et les artefacts, possède naturellement l'accumulabilité. Genesis formalise précisément ce médium comme couche de mémoire à long terme du système d'évolution ; ce qu'il retient n'est pas la conversation, mais les résultats d'ingénierie validés. Le code gère « ce qui peut s'exécuter », la méthode gère « comment choisir », l'état gère « où on en est », la preuve gère « pourquoi croire ». Le code porte la capacité exécutable, c'est le processus de résolution directement exécutable et reproductible.
- La méthode porte les décisions d'algorithme et de stratégie, par exemple les choix de configuration et les modes de combinaison de composants de l'évolution à double niveau.
- L'état porte le contexte du projet et la mémoire d'exécution, enregistrant la progression actuelle, les contraintes et les frontières connues.
- La preuve porte les enregistrements d'expériences et les conclusions de validation, répondant à pourquoi les résultats sont crédibles. S'il manque l'un des quatre, la sédimentation est non reproductible ou non héritable : avec du code sans preuve, les conclusions ne peuvent être crues.
- Avec de la méthode sans état, l'héritier ne sait pas où continuer. Les quatre catégories d'actifs doivent donc être solidifiées en ensemble, et non dispersées. 3. La condition préalable de la sédimentation est la stabilité des interfaces. Ce n'est que lorsque les frontières de modules et les contrats sont relativement stables que les nouvelles productions deviennent des actifs.
- Sinon, chaque modification entraîne l'implémentation environnante, et la sédimentation se transforme rapidement en dette de maintenance. Cela est conditionné mutuellement avec la conception de base ouverte et découplée de Genesis : des interfaces stables rendent la sédimentation héritable en sécurité, le découplage rend l'héritage sans réécriture de l'histoire. Solidifier le contrat avant la sédimentation vaut souvent plus que d'écrire plusieurs documents supplémentaires. Exploration → production → validation stricte → solidification en actif → héritage direct à la prochaine vague d'évolution. La validation est le gardien de la sédimentation — les productions non vérifiées n'entrent pas dans la couche d'actifs, évitant de solidifier bruit, phénomènes accidentels et conclusions erronées en « expérience » de projet. Sans gardien, le dépôt devient de plus en plus long et de moins en moins crédible. 5. La clé de l'héritage inter-cycles de vie est le découplage des actifs d'avec les instances d'exécution spécifiques, permettant aux nouvelles sessions, nouveaux Agents, nouvelles tâches de restaurer la cognition au niveau projet en « lisant le dépôt », sans dépendre de la relecture des conversations historiques. Le coût d'héritage passe de « raconter à nouveau tout le projet » à « extraire et charger », et la cognition du projet n'est plus limitée par la capacité d'une fenêtre de contexte. Genesis se charge de « quoi sédimenter, sous quelle forme, comment être hérité ».
- La collaboration multi-Agents et la décomposition récursive des tâches se chargent de « comment produire ».
- Les mécanismes de validation et d'héritage historique se chargent de « comment une production est jugée crédible ». Les trois ensemble constituent la capacité complète d'évolution continue au niveau projet — s'il manque un maillon, le projet ne fait que répéter sur place.

**Couverture des mots-clés**

- Genesis, évolution continue au niveau projet, architecture système EvoX, code／méthode／état／preuve, gardien de validation, héritage inter-cycles de vie. Cette page organise le contenu selon le « schéma de l'architecture à trois couches et de la boucle de sédimentation de Genesis », de haut en bas à gauche : couche d'actifs (code·méthode·état·preuve), mécanisme de sédimentation (versioning·passerelle de validation·récupération et héritage) et EvoX Runtime (parallélisme tensoriel·puissance hétérogène·modules algorithmiques).
- Le diagramme circulaire à droite présente la boucle fermée exploration, production, validation, solidification, réutilisation, ré-évolution, avec la mention « les actifs s'épaississent à mesure que les cycles de vie s'accumulent ». La page comporte également trois rappels : ne pas prendre la session pour la mémoire, les quatre catégories d'actifs sont indispensables, des interfaces instables transforment la sédimentation en dette. Pendant l'exposé, on peut s'aider de ce schéma pour guider les étudiants à reformuler la boucle en suivant les flèches, puis indiquer que la validation se situe après la production et avant la solidification.

> **Indices d'exercices**
>
> - La page comporte cinq questions à choix multiple et un cas. La question 1 porte sur le monde logiciel accumulable (dépôt, versioning et artefacts) ; si l'étudiant choisit par erreur la fenêtre de contexte, lui rappeler le point de départ « à la fin de la session, il ne reste rien ».
> - La question 2 porte sur la correspondance des responsabilités des quatre catégories d'actifs, la bonne réponse étant que le code porte la capacité exécutable.
> - La question 3 porte sur la frontière entre actif et dette de maintenance, la bonne réponse étant « les frontières de modules et les contrats sont relativement stables », en soulignant que l'essentiel n'est ni la quantité produite ni la nouveauté des outils.
> - La question 4 porte sur le gardien dans la boucle, la bonne réponse étant la validation stricte.
> - La question 5 porte sur l'héritage inter-cycles de vie, la bonne réponse étant « les actifs sont découplés des instances d'exécution, une nouvelle session peut restaurer la cognition du projet en lisant le dépôt ». En cas de bonne réponse, confirmer que l'étudiant sait relier les concepts de cette page et justifier son raisonnement ; en cas d'erreur, l'inviter à revenir à l'exposé pour trouver les preuves ou exemples clés avant de juger. Après l'exploration multi-objectif du profil d'aile supercritique, l'équipe conserve la configuration à double niveau MetaDE exécutable et les scripts d'entraînement du modèle substitut, la définition des indicateurs d'évaluation, l'état intermédiaire couvrant l'intervalle des paramètres de profil et les contraintes géométriques, ainsi que les conclusions de validation du tour. La première question demande d'organiser les actifs selon les quatre catégories code, méthode, état, preuve, et d'expliquer le rôle de gardien de la validation — seules les productions ayant passé une validation stricte sont autorisées à entrer dans la couche d'actifs, les quatre catégories devant être solidifiées en ensemble, faute de quoi elles sont non reproductibles ou non héritables. La deuxième question demande de comparer « relecture des conversations historiques » et « lecture du dépôt » : la première dépend de la fenêtre de contexte, son coût croît linéairement avec le projet, et une fois la conversation tronquée la cognition est perdue.
> - La seconde réduit le coût d'héritage à l'extraction et au chargement, les résultats étant versionnables, reproductibles, auditables, le coût des essais-erreurs répétés du tour se sédimentant ainsi en point de départ de réutilisation du tour suivant.

**Activité en classe**

Demander aux étudiants de reformuler le contenu de cette page avec un exemple proche de leur expérience, et d'expliquer la relation entre cet exemple et le critère de jugement « la personne suivante peut-elle le reproduire sans venir te poser de question ».

**Vérification de la compréhension**

Demander à un étudiant choisi au hasard de résumer dans ses propres mots les points clés de cette page ; l'enseignant complète selon la réponse les mots-clés manquants, en confirmant surtout que l'étudiant peut énoncer simultanément « la répartition des quatre catégories d'actifs » et « la validation est le gardien de la sédimentation ».

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer la relation centrale de cette page — la sédimentation se produit sur des contrats stables, contrôlée par la validation, finalement héritée par lecture du dépôt — passer à l'application ou à la synthèse de la page suivante.

<a id="lecture-page-11"></a>

### Modèle d'ingénierie de la collaboration multi-Agents et de la décomposition récursive des tâches

*Page 11*

> **Objectif de la page :** Comprendre comment des Agents à cycle de vie limité collaborent pour mener à bien le développement et la décomposition de tâches d'un projet complexe.

**Points clés de l'enseignement**

- Lors de la décomposition des tâches, demander d'abord « que doit livrer cette couche comme éléments vérifiables », plutôt que de penser d'abord « à quel Agent confier ». Une fois les livrables (jeux de données, interfaces, points de contrôle, rapports d'évaluation) clairement définis, les frontières de responsabilité et la hiérarchie émergent naturellement.
- Le point d'arrêt de la décomposition récursive n'est pas « décomposer au plus fin », mais « décomposer jusqu'à exécutable, vérifiable, et bouclable dans un seul contexte d'un Agent ». Une décomposition trop grossière dépasse la capacité du niveau inférieur, une décomposition trop fine entraîne des coûts de coordination et de passation supplémentaires.
- Le chevauchement des responsabilités fait que plusieurs Agents réimplémentent la même chose et produisent des résultats contradictoires. Solidifier les frontières par des définitions d'interfaces et des critères de validation explicites, et convenir de ce que le niveau inférieur peut décider lui-même et de ce qui doit être remonté au niveau parent pour arbitrage.

Objectif de la page

Lorsque la capacité de contexte et de traitement d'un exécutant unique ne suffit pas à porter l'ensemble de l'objectif d'ingénierie, comment dégrader un grand problème en un ensemble de petits problèmes livrables, et rendre les résultats de collaboration de chaque niveau vérifiables et récupérables.

Ordre de présentation

Commencer par le thème « dégrader un grand problème en un ensemble de petits problèmes livrables », puis dérouler la structure à trois niveaux, expliquer ensuite les motivations et les conditions d'arrêt de la décomposition récursive, et terminer sur la relation de passation bidirectionnelle de l'arbre des tâches et les trois conseils d'ingénierie. Pendant l'exposé, on peut s'aider du schéma pour pointer les nœuds niveau par niveau, aidant les étudiants à faire correspondre la répartition abstraite à l'arbre des tâches concret.

Points clés de l'enseignement

1. Structure à trois niveaux et responsabilités respectives. L'exécutant supérieur est orienté vers l'objectif global, répond à « quoi faire », et produit des sous-tâches délégables, des conditions de contrainte et des critères de validation ; l'exécutant intermédiaire reprend les sous-tâches encore trop grandes pour poursuivre la décomposition récursive, convergeant un grand objectif lâche vers une hiérarchie de tâches stable ; l'exécutant inférieur réalise l'implémentation locale et les tests dans les limites de sa responsabilité, produit des résultats vérifiables et les livre vers le haut, formant une boucle locale. Dans le schéma, l'Agent supérieur se divise en modules de tâches A, B, C ; le module B, encore trop lourd, est décomposé en sous-tâches B1, B2 ; les quatre nœuds feuilles aboutissent finalement chacun à l'implémentation locale et aux tests d'un Agent inférieur.

Le niveau supérieur se place au nœud racine, produit des tâches délégables et des critères de validation, et non l'implémentation en personne.

2. Pourquoi la décomposition récursive est indispensable. La fenêtre de contexte, les outils appelables et la taille de tâche traitable en une fois d'un exécutant sont limités. Si un exécutant unique porte à long terme tout le contexte du projet, le coût croît avec l'échelle, et des dérives d'objectif, une pollution d'état et une dilution des informations clés apparaissent facilement. La décomposition récursive répartit cette pression sur chaque niveau : chaque exécutant n'a besoin de comprendre que l'objectif et les contraintes de son propre niveau, l'objectif complexe est dégradé couche par couche en unités de travail exécutables et livrables, et la cohérence d'ensemble est garantie par la hiérarchie des tâches.

Arbre des tâches et passation bidirectionnelle. Les tâches parentes et enfants forment un arbre de tâches récursif. Vers le bas circule la délégation de tâches — objectif, contraintes de frontière et critères de validation ; vers le haut circule la récupération des résultats — productions, preuves de validation et problèmes non résolus. La collaboration ne tient réellement que si trois choses sont réunies : la hiérarchie des tâches est claire, les frontières de responsabilité sont mutuellement exclusives, et les produits de passation (définitions d'interfaces, jeux de données, cas de test, points de contrôle) sont explicitement convenus. S'il manque l'un d'eux, plusieurs exécutants dégénèrent en travail répété et résultats contradictoires.

La profondeur de décomposition, la granularité de délégation et la stratégie de récupération des résultats peuvent également être continuellement évaluées et ajustées. Lorsqu'une sous-tâche est reprise plusieurs fois, ce type de rétroaction influence à son tour la façon de décomposer au prochain tour, le processus de collaboration entre alors dans un cycle d'auto-amélioration.

5. Conseils d'ingénierie. La condition d'arrêt de la décomposition récursive n'est pas « décomposer au plus fin », mais « décomposer jusqu'à exécutable, vérifiable, et bouclable dans un seul contexte d'un exécutant ». Une décomposition trop grossière dépasse la capacité de traitement du niveau inférieur, une décomposition trop fine entraîne une surcharge de coordination et de passation importante. On peut d'abord fixer les livrables, puis décider qui les fait ; des frontières floues sont souvent le plus grand coût de la collaboration.

Traitement des exercices

Cette page comporte un ensemble de questions conceptuelles vrai/faux ; il est recommandé de demander aux étudiants d'indiquer leur justification après avoir répondu, et non seulement l'option.

La bonne réponse est « comprendre l'objectif global et le décomposer en sous-tâches délégables et critères de validation ». En cas d'erreur, indiquer le positionnement du nœud racine — ce qui est produit, ce sont des tâches et des critères de validation, pas le code lui-même.

La bonne réponse est « lorsque la sous-tâche reste trop complexe et dépasse la portée de traitement d'un seul ». Souligner que la récursion n'est pas une action inconditionnelle ; son déclencheur est qu'une sous-tâche reste trop grande pour être achevée et validée en un seul traitement.

Que se passerait-il s'il n'y avait que la délégation descendante ? Et s'il n'y avait que la récupération des résultats ? En déduire que la collaboration doit être bidirectionnelle.

La bonne réponse est « répartir le contexte et la pression de traitement sur chaque niveau, réduisant la charge de contexte d'un point unique et le risque de dérive d'objectif ». Le mot clé est « répartir », et non « garantir le succès en une fois ».

La bonne réponse est « laisser les nœuds feuilles conserver des unités de travail exécutables et livrables, et définir explicitement les interfaces et productions de test ». On peut en profiter pour réviser : des frontières floues ou la suppression de niveaux entraînent réimplémentation et conflits de résultats.

Activité en classe

Le cas d'étude « livraison collaborative d'un système de contrôle qualité par chatbot intelligent » convient comme activité de groupe. Demander d'abord aux étudiants de dessiner l'arbre de tâches récursif : le nœud racine se charge de la compréhension de l'objectif global et produit trois sous-tâches A, B, C et leurs critères de validation ; le module B est décomposé par le niveau intermédiaire en B1, B2, avec définition explicite des interfaces ; les nœuds feuilles sont les quatre unités de travail A, B1, B2, C. Demander ensuite à chaque groupe de lister les produits de passation dans les deux sens, par exemple spécifications d'interface de données et jeu de données de dialogue nettoyé, dictionnaire de caractéristiques et normes d'annotation, points de contrôle de modèle et rapports de validation, indicateurs d'évaluation et configuration de déploiement, et d'expliquer pourquoi les nœuds feuilles satisfont la condition d'arrêt.

Face à la question approfondie où B1 découvre un conflit entre « normes d'annotation » et « indicateurs d'évaluation », on peut guider les étudiants à induire les principes de traitement : le conflit remonte pour arbitrage, sans modifier soi-même les critères de validation ; les interfaces et normes maintiennent une source unique, gérée uniformément par le niveau supérieur ; avant arbitrage, la boucle locale reste vérifiable ; le résultat de l'arbitrage met à jour en retour l'arbre des tâches et les entrées des sous-tâches concernées ; tout le processus enregistre le conflit, la base d'arbitrage et la conclusion finale pour traçabilité.

Vérification de la compréhension

Ce dont le niveau supérieur est responsable, sous quelles conditions la récursion continue, quelles informations circulent dans les deux sens. Si l'étudiant peut énoncer simultanément la condition d'arrêt et « d'abord fixer les livrables puis la répartition », on peut considérer cette page maîtrisée.

Indication de transition

Après avoir confirmé que les étudiants peuvent distinguer « décomposer les tâches » et « implémenter en personne », et expliquer clairement la passation bidirectionnelle de l'arbre des tâches, passer à la page suivante sur les mécanismes de validation et de sédimentation, afin d'articuler le modèle de répartition de cette page avec les étapes ultérieures de compilation, test et validation.

<a id="lecture-page-12"></a>

### Mécanismes de validation stricte et d'héritage historique

*Page 12*

> **Objectif de la page :** Maîtriser comment, par la compilation, les tests et la passerelle de validation, les modifications valides se sédimentent dans l'histoire du projet.

> **Ordre de présentation**
>
> Commencer par une phrase pour préciser : « Face à tout système d'"auto-génération et auto-amélioration", poser d'abord trois questions : quel est le statut par défaut des productions de l'Agent (candidat ?), quelles validations doivent-elles passer pour être adoptées (validation ?), et une fois adoptées, base de qui deviennent-elles (baseline ?). Séparer ces trois choses et la logique d'ensemble du mécanisme reste claire. », puis, en s'appuyant sur les exemples, schémas ou mots-clés de la page, expliquer pourquoi c'est important.

**Points clés de l'enseignement**

- Quel est le statut par défaut des productions de l'Agent (candidat ?), quelles validations doivent-elles passer pour être adoptées (validation ?), et une fois adoptées, base de qui deviennent-elles (baseline ?). Séparer ces trois choses et la logique d'ensemble du mécanisme reste claire.
- Compilation → tests → vérification de comportement → validation de niveau supérieur, c'est une pente descendante « du coût faible au coût élevé » : moins c'est cher, plus c'est en amont ; plus c'est cher, plus c'est en aval. Retenir « filtrer d'abord le bon marché, examiner ensuite le coûteux », et l'on ne gaspille pas la revue de niveau supérieur sur une masse de candidats indésirables.
- Réussir la validation ne signifie pas être réellement meilleur. En cas de couverture de test insuffisante ou d'absence de vérification de comportement, la passerelle laisse passer des modifications nuisibles. Prendre deux habitudes : compléter les cas de régression et les définitions de tolérance pour les comportements clés.
- Conserver à tout moment des indicateurs observables et des contrôles par échantillonnage manuel, comme dernière ligne de défense lorsque les normes sont incomplètes.

Mécanismes de validation stricte et d'héritage historique

11

AI999

Genesis et la sédimentation du monde logiciel

Sur quelle base une modification générée automatiquement par un Agent peut-elle être inscrite dans la branche principale du projet ? Les mécanismes de validation stricte et d'héritage historique découplent complètement génération et adoption — tout code soumis par un Agent n'est qu'une modification candidate (candidate patch), qui doit d'abord passer un ensemble de portes de validation pour avoir le droit d'être reconnue comme partie de l'histoire du projet.

Modification candidate → quatre portes de validation → branche principale / rejet en分流 File de modifications candidates Agent soumet · non fiable par défaut Candidat A à vérifier Candidat B à vérifier Candidat C à vérifier Candidat D à vérifier ① Porte de compilation Syntaxe et interfaces constructibles · coût le plus faible, élimination la plus rapide ② Porte de test Tests unitaires / d'intégration tous verts · couverture des contrats existants ③ Porte de vérification de comportement Cohérence sémantique · tolérances numériques et équivalence ④ Validation de niveau supérieur Performance · accélération · maintenabilité Rejet · zone d'archives d'échecs · conservé comme échantillons négatifs et matériel de diagnostic · stockage isolé, sans pollution de la branche principale · le rejet lui-même est un filtrage de bruit · évite de réexplorer la même impasse Historique des versions de la branche principale (accumulation monotone) Baseline v3 · héritable, traçable Baseline v2 Baseline v1 Rétroaction d'héritage historique : la baseline adoptée devient le point de départ d'exécution des Agents suivants Principe du statut candidat par défaut La sortie de l'Agent est par défaut considérée comme entrée non fiable : elle est strictement isolée des versions adoptées en termes de permissions, stockage et références, ne peut ni lire ni écrire directement la branche principale, ni être utilisée comme dépendance stable par d'autres modules.

Le seul but de ce principe est d'empêcher « la génération d'entrer directement dans le dépôt ». Ce n'est qu'après avoir passé toutes les portes que la modification candidate obtient un statut équivalent à la branche principale. Filtrage progressif à quatre niveaux : coût croissant, échec le plus tôt possible Compilation : constructibilité au niveau syntaxe et interfaces. Coût le plus faible, élimination la plus rapide, bloquant d'abord les modifications manifestement non valides. Tests : tests unitaires et d'intégration réussis, couvrant les contrats existants. Vérification de comportement : cohérence sémantique et comportementale, incluant tolérances numériques, équivalence et comparaison de régression, spécialement pour prévenir « les tests passent mais le comportement dérive ». Validation de niveau supérieur : décision finale orientée vers les objectifs de tâche et les contraintes d'ingénierie, incluant performance, accélération, maintenabilité.

Les portes sont ordonnées du coût faible au coût élevé, faisant que la grande majorité des modifications invalides sont tronquées aux étapes bon marché, réservant la revue coûteuse du niveau supérieur à un petit nombre de candidats de haute qualité — c'est précisément l'économie de « l'échec le plus tôt possible ». La valeur du rejet et l'héritage historique Les tentatives non validées n'entrent pas dans la branche principale, mais peuvent être conservées comme archives d'échecs / échantillons négatifs, pour le diagnostic, la déduplication et la prévention de la réexploration — le rejet lui-même est un filtrage de bruit. Les modifications validées deviennent une nouvelle version de baseline, sur laquelle les exécutants suivants continuent d'évoluer, formant une chaîne d'évolution à accumulation monotone, plutôt que de repartir de zéro à chaque tour. En tant que règle de fusion et contrat de qualité de la collaboration multi-Agents et de la décomposition récursive des tâches, la passerelle de validation définit « qui peut écrire dans l'histoire », déterminant ainsi si le résultat de la collaboration converge ou entropise.

Dans les scénarios à fortes contraintes de correction telles que la refactorisation de compilateurs et la mise à niveau de logiciels scientifiques, ce mécanisme montre une fiabilité très élevée et apporte des accélérations d'exécution considérables. Frontières de défaillance La complétude des critères de validation elle-même devient un nouveau goulot d'étranglement : en cas de couverture de test insuffisante ou d'absence de vérification de comportement, la passerelle laisse passer des modifications « validées mais en réalité nuisibles ». Il faut donc recourir à des indicateurs observables et des contrôles par échantillonnage manuel, et renforcer en continu les cas de régression et les définitions de tolérance.

Dans un mécanisme de validation stricte, quel est le statut par défaut du code soumis par un Agent ?

Un produit fini utilisable, dont la disponibilité est jugée par le soumissionnaire lui-même

Une version officielle directement fusionnable dans la branche principale

Une modification candidate à vérifier, strictement isolée des versions adoptées en permissions, stockage et références

Un sous-produit uniquement destiné à l'enregistrement de journaux, ne participant à aucun processus

Le statut candidat par défaut considère la sortie de l'Agent comme entrée non fiable, strictement isolée de la branche principale, empêchant institutionnellement « la génération d'entrer directement dans le dépôt ».

Une sortie non vérifiée ne doit pas avoir le même statut qu'une version adoptée.

Correct. Cette réponse sait relier les concepts de cette page et justifier son raisonnement.

Veuillez revenir à l'exposé de cette page, trouver les preuves ou exemples clés avant de juger.

Dans quel ordre les quatre portes de validation sont-elles disposées, et quelle est l'intention de conception ?

Du coût le plus élevé au plus faible, priorisant l'investissement des ressources dans la revue coûteuse du niveau supérieur

Par ordre de soumission des candidats, premier arrivé premier vérifié

Dans un ordre aléatoire, pour augmenter la diversité de validation

Compilation → tests → vérification de comportement → validation de niveau supérieur, faisant tronquer la grande majorité des modifications invalides aux étapes bon marché

Les portes bon marché se chargent de l'élimination à grande échelle, les portes coûteuses ne font face qu'à un petit nombre de candidats de haute qualité.

Réfléchir à quel niveau est le plus cher, lequel est le plus rapide. L'ordre des portes doit faire que la revue coûteuse rencontre le moins possible de candidats indésirables.

Quel type de problème la vérification de comportement (troisième porte) prévient-elle principalement ?

Un nombre insuffisant de cas de test unitaires

« Les tests passent mais le comportement dérive », c'est-à-dire une incohérence sémantique ou numérique entre l'ancienne et la nouvelle implémentation

Une erreur de syntaxe empêchant toute compilation

Une occupation excessive de l'espace de stockage par l'historique des versions de la branche principale

La vérification de comportement utilise tolérances numériques, équivalence et comparaison de régression pour vérifier la cohérence sémantique, interceptant les dérives de comportement non couvertes par les tests.

La couche compilation gère « peut-on construire », la couche test « le contrat est-il satisfait », la vérification de comportement se concentre sur des dérives sémantiques plus dissimulées.

Comment comprendre la valeur d'une modification candidate rejetée par une porte ?

Elle doit être complètement supprimée, pour ne pas occuper de stockage et perturber les jugements ultérieurs

Elle doit être directement écrite dans la branche principale, comme contre-exemple conservé

Elle peut être conservée comme archive d'échecs / échantillon négatif, pour le diagnostic, la déduplication et la prévention de la réexploration

Elle doit être resoumise sans modification de façon répétée, jusqu'à passer automatiquement

Les tentatives échouées sont isolées de la ligne principale, mais restent utilisables comme échantillons négatifs — le rejet lui-même est un filtrage de bruit.

La distinction clé est de savoir si elle est autorisée à polluer la branche principale, et si elle peut être transformée en information de diagnostic réutilisable.

Quelle situation est la plus susceptible de faire que la passerelle de validation laisse passer une modification « validée mais en réalité nuisible » ?

Une couverture de test insuffisante ou une vérification de comportement absente, rendant les critères de validation eux-mêmes incomplets

La validation de niveau supérieur évalue simultanément performance, accélération et maintenabilité

Plusieurs Agents différents soumettent simultanément dans la file de modifications candidates

Les archives d'échecs sont conservées à long terme pour diagnostic

La passerelle ne peut bloquer que les problèmes qu'elle peut détecter ; lorsque les critères de validation sont incomplets, il faut recourir à des indicateurs observables et des contrôles par échantillonnage manuel.

Le risque ne vient souvent pas du soumissionnaire, mais des angles morts de couverture des critères de validation eux-mêmes.

Validation d'un patch de réécriture du noyau de compilateur

Lire le scénario et répondre aux deux questions suivantes.

Une équipe refactorise le noyau d'un compilateur par collaboration multi-Agents. L'Agent X soumet un patch de réécriture du noyau, affirmant pouvoir améliorer d'environ 1,4 fois la vitesse d'exécution d'un benchmark. Le système traite ce patch selon les « mécanismes de validation stricte et d'héritage historique » : le patch entre d'abord dans la file de modifications candidates, puis passe successivement compilation, tests, vérification de comportement et validation de niveau supérieur ; en cas de succès, il est réécrit dans la branche principale et devient le point de départ de la génération suivante d'Agents, sinon il entre dans la zone d'archives d'échecs isolée.

1. Expliquer dans l'ordre quels contrôles ce patch doit passer successivement, et pourquoi la validation de niveau supérieur est placée en dernier.

Compilation → tests → vérification de comportement → validation de niveau supérieur. La compilation vérifie la constructibilité au niveau syntaxe et interfaces, coût le plus faible, élimination la plus rapide ; les tests vérifient que les tests unitaires/d'intégration sont tous verts, couvrant les contrats existants ; la vérification de comportement compare la cohérence sémantique entre l'ancienne et la nouvelle implémentation, incluant tolérances numériques, équivalence et comparaison de régression ; la validation de niveau supérieur rend la décision finale orientée vers les objectifs de tâche et les contraintes d'ingénierie, jugeant performance, accélération et maintenabilité. Placer la validation de niveau supérieur en dernier parce qu'elle est la plus coûteuse et nécessite l'intervention humaine ou d'une revue de haut niveau ; ce n'est qu'après que les niveaux précédents ont tronqué la grande majorité des candidats invalides que cette ressource coûteuse peut être concentrée sur un petit nombre de candidats de haute qualité, réalisant « coût croissant, échec le plus tôt possible ».

Sur certaines entrées, les sorties numériques de la nouvelle implémentation dépassent la tolérance convenue par rapport à l'ancienne. Comment le système doit-il le traiter ? A-t-il encore de la valeur ? Que se passerait-il si la vérification de comportement était supprimée ?

Ce patch ne doit pas être écrit dans la branche principale, il doit être rejeté et transféré dans la zone d'archives d'échecs isolée ; comme il a passé les étapes de compilation et de test, cela montre justement qu'il appartient au type dangereux « les tests passent mais le comportement dérive ». Il a encore de la valeur : il peut être conservé comme échantillon négatif, pour diagnostiquer la source des différences, éviter que les Agents suivants ne répètent la même impasse, et inciter l'équipe à compléter les cas de régression ou à revoir la définition de tolérance. Si la vérification de comportement était supprimée, ce type de patch entrerait directement dans la validation de niveau supérieur voire serait réécrit dans la branche principale avec des tests tous verts, introduisant une dérive de comportement dans la baseline historique ; c'est précisément la frontière de défaillance de ce mécanisme — la passerelle ne peut bloquer que les problèmes qu'elle peut détecter, d'où la nécessité d'indicateurs observables et de contrôles par échantillonnage manuel.

Candidat, validation, baseline

Quel est le statut par défaut des productions de l'Agent (candidat ?), quelles validations doivent-elles passer pour être adoptées (validation ?), et une fois adoptées, base de qui deviennent-elles (baseline ?). Séparer ces trois choses et la logique d'ensemble du mécanisme reste claire.

Mémoriser l'ordre des portes comme une pente descendante

Compilation → tests → vérification de comportement → validation de niveau supérieur, c'est une pente descendante « du coût faible au coût élevé » : moins c'est cher, plus c'est en amont ; plus c'est cher, plus c'est en aval. Retenir « filtrer d'abord le bon marché, examiner ensuite le coûteux », et l'on ne gaspille pas la revue de niveau supérieur sur une masse de candidats indésirables.

La passerelle ne peut bloquer que les problèmes qu'elle peut détecter

Réussir la validation ne signifie pas être réellement meilleur. En cas de couverture de test insuffisante ou d'absence de vérification de comportement, la passerelle laisse passer des modifications nuisibles. Prendre deux habitudes : compléter les cas de régression et les définitions de tolérance pour les comportements clés ; conserver à tout moment des indicateurs observables et des contrôles par échantillonnage manuel, comme dernière ligne de défense lorsque les normes sont incomplètes.

step-1

Maîtriser comment, par la compilation, les tests et la passerelle de validation, les modifications valides se sédimentent dans l'histoire du projet.

lesson_6

lesson_6_slide_11

Issu du brouillon EvoClass

> **Objectif de la page**
>
> Maîtriser le mécanisme par lequel la compilation, les tests et la validation sédimentent les modifications valides dans l'histoire du projet

**Points clés de l'enseignement**

- Mécanismes de validation stricte et d'héritage historique
- Le code soumis par un Agent n'est qu'une modification candidate ; il ne peut entrer dans une version de projet adoptée qu'après compilation, tests, vérification de comportement et validation de niveau supérieur. Les tentatives échouées peuvent être rejetées, tandis que les résultats validés deviennent la base historique des exécutants suivants. Dans la refactorisation de compilateurs et la mise à niveau de logiciels scientifiques, ce mécanisme montre une fiabilité et des accélérations d'exécution très élevées.

**Points clés de l'enseignement**

- Mécanismes de validation stricte et d'héritage historique
- Le code soumis par un Agent n'est qu'une modification candidate ; il ne peut entrer dans une version de projet adoptée qu'après compilation, tests, vérification de comportement et validation de niveau supérieur. Les tentatives échouées peuvent être rejetées, tandis que les résultats validés deviennent la base historique des exécutants suivants. Dans la refactorisation de compilateurs et la mise à niveau de logiciels scientifiques, ce mécanisme montre une fiabilité et des accélérations d'exécution très élevées. Mécanismes de validation stricte et d'héritage historique
- Le code soumis par un Agent n'est qu'une modification candidate ; il ne peut entrer dans une version de projet adoptée qu'après compilation, tests, vérification de comportement et validation de niveau supérieur. lesson_id_distribution 86818163433546df25555ab4cb1c2d59fc1effedc37a25c4e84b74b7d294e704

**Source du matériel**

Issu du brouillon EvoClass

> **Indices de matériel**
>
> - Maîtriser le mécanisme par lequel la compilation, les tests et la validation sédimentent les modifications valides dans l'histoire du projet
> - Mécanismes de validation stricte et d'héritage historique
> - Le code soumis par un Agent n'est qu'une modification candidate ; il ne peut entrer dans une version de projet adoptée qu'après compilation, tests, vérification de comportement et validation de niveau supérieur. Les tentatives échouées peuvent être rejetées, tandis que les résultats validés deviennent la base historique des exécutants suivants. Dans la refactorisation de compilateurs et la mise à niveau de logiciels scientifiques, ce mécanisme montre une fiabilité et des accélérations d'exécution très élevées.
> - Le code soumis par un Agent n'est qu'une modification candidate ; il ne peut entrer dans une version de projet adoptée qu'après compilation, tests, vérification de comportement et validation de niveau supérieur.

**Activité en classe**

Reformuler le contenu de cette page avec un exemple proche de l'expérience des étudiants, et leur demander d'expliquer la relation entre cet exemple et « Face à tout système d'"auto-génération et auto-amélioration", poser d'abord trois questions : quel est le statut par défaut des productions de l'Agent (candidat ?), quelles validations doivent-elles passer pour être adoptées (validation ?), et une fois adoptées, base de qui deviennent-elles (baseline ?). Séparer ces trois choses et la logique d'ensemble du mécanisme reste claire. »

> **Objectifs correspondants**
>
> - Comprendre le modèle d'ingénierie de la collaboration multi-Agents et de la décomposition récursive des tâches
> - Maîtriser le mécanisme par lequel la compilation, les tests et la validation sédimentent les modifications valides dans l'histoire du projet

**Vérification de la compréhension**

Demander à un étudiant choisi au hasard de résumer dans ses propres mots les points clés de cette page ; l'enseignant complète selon la réponse les mots-clés manquants.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer la relation centrale de cette page, passer aux exemples, applications ou synthèse de la page suivante.

<a id="lecture-page-13"></a>

### Activité en classe : simulation de la collaboration multi-Agents et de la passerelle de validation automatisée

*Page 13*

> **Objectif de la page :** Approfondir la compréhension du développement collaboratif multi-Agents et du mécanisme de validation automatisée par une simulation.

> **Objectif de la page**
>
> Par un exercice de simulation en classe, comprendre la répartition des tâches dans le développement collaboratif multi-Agents, la convergence des modifications candidates, et comment la passerelle de validation automatisée intercepte les modifications non conformes ; l'essentiel est de faire tourner la boucle d'ingénierie « développement collaboratif—validation automatique—héritage historique », et non de faire discuter les Agents jusqu'à la bonne réponse.

> **Ordre de présentation**
>
> Répartir les groupes de classe en Agent de planification/décomposition, Agent d'implémentation, Agent de génération de tests, Agent de revue/coordination. Une même tâche peut produire plusieurs modifications candidates, arbitrées uniformément par la passerelle de validation.
>
> Décomposition des tâches, implémentation parallèle, validation automatique, héritage historique. La décomposition des tâches doit découper l'objectif en sous-tâches vérifiables indépendamment, par exemple « vérification d'interface—correction d'algorithme—test de régression » ; à l'étape d'implémentation parallèle, plusieurs Agents d'implémentation soumettent des patchs candidats, l'Agent de test génère des cas limites ; à l'étape de validation automatique, exécuter les tests automatisés, les vérifications statiques et de contrat, la passerelle jugeant selon des critères exécutables ; à l'étape d'héritage historique, les modifications validées sont fusionnées dans la baseline historique, les modifications rejetées conservent la raison d'échec et les informations de reproduction, pour nouvelle tentative.
>
> À gauche, la décomposition récursive des tâches ; au centre, les modifications candidates multi-Agents ; à droite, les tests automatisés et la passerelle de validation. Les candidats convergent vers la passerelle ; en cas de succès, fusion dans la baseline historique ; en cas de rejet, renvoi avec rétroaction reproductible, la rétroaction revenant aux étapes d'implémentation et de test.
>
> Les critères doivent être exécutables, et non rester à « cela semble correct ». L'accent est mis sur l'interception des modifications ne satisfaisant pas les conventions d'interface, introduisant des régressions, ne couvrant pas les conditions limites ou violant les contraintes de qualité. Une rétroaction utilisable doit au moins contenir le cas d'échec, le journal, les étapes de reproduction, le comportement attendu et les contraintes concernées.
>
> Les modifications validées entrent dans la baseline, les Agents suivants n'ont pas besoin de repartir de zéro ; les modifications rejetées deviennent des exemples négatifs interrogeables, évitant de répéter les erreurs. Lors de l'évaluation, il faut s'intéresser à la reproductibilité des règles de validation, à l'actionnabilité de la rétroaction, et aux risques différents d'interception erronée et de non-interception.

**Points clés de l'enseignement**

- Avant la validation, écrire d'abord les tests exécutables, les assertions de contrat et les cas limites.
- Une règle non reproductible ne peut pas intercepter de manière stable. Les candidats rejetés doivent être accompagnés du journal d'échec, des commandes de reproduction, du comportement attendu et des contraintes concernées, pour que l'Agent suivant puisse directement localiser et corriger. Une granularité de décomposition trop fine augmente les coûts de fusion et de validation, trop grossière fait que les modifications candidates se recouvrent mutuellement.
- Privilégier une décomposition en sous-tâches testables et validables séparément.

> **Indices de matériel**
>
> - Décomposition récursive des tâches, modifications candidates multi-Agents, tests automatisés et passerelle de validation. Le schéma indique également « convergence des candidats », « reflux de rétroaction », « succès vers la baseline, rejet vers une rétroaction reproductible », adapté pour expliquer la boucle en pointant le schéma. On peut demander aux étudiants de concevoir, autour du cas « le service de paiement plante sur des entrées négatives ou des chaînes trop longues », un ensemble de règles de passerelle de validation exécutables, couvrant au moins l'interface, la régression, les limites et les contraintes de qualité. Orientations de référence : la couche interface exige que le champ montant rejette les nombres négatifs et les chaînes trop longues, renvoie un code d'erreur unifié et fasse des assertions de contrat.
> - La couche régression exige que tous les cas existants de paiement réussi, remboursement, rapprochement passent sans nouvel échec.
> - La couche limites inclut les cas 0, négatif, montant maximal autorisé, chaîne trop longue, chaîne vide et caractères spéciaux, avec assertion de non-plantage et d'erreur explicable.
> - Les contraintes de qualité incluent le passage des vérifications statiques, une couverture des chemins critiques non inférieure au seuil convenu, l'absence d'alerte de haute gravité. Toutes les règles doivent être exprimées par des tests ou scripts exécutables, et reproductibles en intégration continue.

> **Indices d'exercices**
>
> - Une interception erronée gaspille le travail de candidats corrects et réduit l'efficacité de la collaboration, et peut inciter l'équipe à relâcher les normes.
> - Une non-interception fait entrer les défauts dans la baseline historique, les Agents suivants travaillant sur une baseline erronée, amplifiant le risque de régression. Les moyens de réduction incluent la conservation des preuves d'échec, la revue par échantillonnage des résultats d'interception, la sédimentation des nouveaux cas d'échec en ensemble de régression, et une combinaison de cas limites, de vérifications de contrat et de validation en gris pour contrôler le risque.

**Vérification de la compréhension**

Demander à un étudiant choisi au hasard de résumer dans ses propres mots les points clés de cette page, en vérifiant s'il peut énoncer les trois points clés « critères exécutables », « rétroaction actionnable », « décomposition selon des frontières vérifiables indépendamment ». S'il peut illustrer avec le cas du service de paiement, considérer la maîtrise acquise ; s'il ne répond que « laisser les Agents discuter automatiquement », le renvoyer aux normes de la passerelle de validation et au processus de la boucle.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent expliquer clairement la relation entre collaboration multi-Agents, validation automatique et héritage historique, passer à l'application, aux exemples ou à la synthèse de la page suivante.

<a id="lecture-page-14"></a>

### Mode de travail IA Native et point d'entrée pratique

*Page 14*

> **Objectif de la page :** Comprendre comment lancer rapidement des expériences EvoX dans des outils IA via une entrée simple et une configuration.

**Points clés de l'enseignement**

- Retenir cette ligne de répartition : le point d'entrée IA Native se charge de l'installation, de la configuration de base et de la vérification d'environnement ; vous vous chargez de la définition du problème, du choix de direction et des critères d'évaluation. Investir le temps économisé dans ces derniers sera vraiment bénéfique pour la recherche, sinon on ne fait que déplacer l'attente de l'étape de configuration à l'étape de reprise.
- La valeur d'une instruction en une phrase est de vous faire entrer rapidement dans l'expérience, et non de sauter les vérifications. Après l'installation, confirmer activement la version, les dépendances et la visibilité GPU, considérer l'état rapporté par l'outil comme un indice et non une conclusion, pour que les expériences suivantes aient un point de référence fiable.
- Avant la reproduction inter-machines, vérifier point par point : la liste des dépendances et versions est-elle cohérente, le modèle GPU et le nombre de dispositifs disponibles sont-ils identiques, les graines aléatoires et les hyperparamètres clés sont-ils fixés. Après validation des trois points, augmenter l'échelle de l'expérience, évitant un coût de diagnostic ultérieur bien supérieur au coût de configuration initial.

Objectif de la page**

Ce que le mode de travail IA Native change réellement, et où sont ses limites. Après l'étude, on doit pouvoir énoncer trois points : le point d'interaction passe de la consultation manuelle de documentation, l'installation de dépendances, la configuration d'environnement, l'écriture de squelette, à un lancement d'expérience en une phrase dans un outil IA ; l'installation, la configuration de base et la vérification d'environnement sont prises en charge par l'outil qui rapporte l'état ; la définition du problème, le choix de direction et les critères d'évaluation restent à la charge du chercheur.

Points clés de l'enseignement**

1. Le déplacement du point d'entrée est la caractéristique définitoire. Le chemin traditionnel est « consulter la documentation → installer les dépendances → configurer l'environnement → écrire le squelette → seulement alors commencer la première expérience », chaque maillon pouvant être source d'erreur, et chaque changement nécessitant de reconstruire le contexte. Le chemin IA Native est « instruction en une phrase → l'outil prend en charge l'installation et la configuration → vérification d'environnement réussie → entrée dans l'expérience ». Ce qui change est la façon dont l'humain commence à travailler, et non l'objet optimisé lui-même.

2. La nature de la friction est un transfert, non une disparition. La vraie charge ne vient souvent pas de la difficulté d'une opération isolée, mais des changements de contexte fréquents : le chercheur devrait se concentrer sur la modélisation du problème, la conception d'expériences et l'interprétation des résultats, mais est constamment interrompu par des conflits de version, des dépendances manquantes et des chemins d'environnement. Le point d'entrée pratique transfère toute la chaîne d'ingénierie, ramenant l'attention à la recherche elle-même.

Réaliser l'installation et la configuration de base d'EvoX en une seule instruction. Par exemple, saisir « installer EvoX et terminer la configuration de base », l'outil exécute et renvoie le résultat, le chercheur entre alors dans l'expérience. Noter que ce n'est qu'un point de départ, pas un point d'arrivée — le « configuration terminée » rapporté par l'outil est un état à vérifier, non une conclusion directement adoptable.

4. Plus le chemin est court, plus la distance entre l'idée et l'expérience exécutable est petite ; l'idée peut être validée le jour même, les hypothèses échouées rapidement éliminées. C'est particulièrement net pour les sujets d'évolution de méthode nécessitant de construire à plusieurs reprises des structures expérimentales internes/externes : le temps peut être consacré à la conception de stratégies, aux critères d'évaluation et à l'attribution des résultats, plutôt qu'à réparer l'environnement à répétition.

Le point d'entrée pratique réduit le coût de prise en main et de configuration, mais ne remplace pas le jugement du chercheur sur la valeur du problème, la direction de recherche et les indicateurs d'évaluation. Lire « gagner du temps » comme « économiser du jugement » est le biais le plus courant de cette page. Le temps gagné ne profite réellement à la recherche que s'il est investi dans le jugement, sinon on ne fait que déplacer l'attente de l'étape de configuration à l'étape de reprise.

Indices de matériel**

La rangée supérieure en gris représente les quatre étapes du chemin traditionnel, avec la mention « friction concentrée » en dessous ; la rangée centrale en bleu représente les quatre étapes du chemin IA Native, dont « instruction en une phrase » est mise en évidence, avec la mention « friction transférée » en dessous ; le bloc orange en bas est « frontière de positionnement ». Pendant l'exposé, on peut demander directement : quel segment a été retiré du schéma, quel segment reste ? Guider les apprenants à découvrir — ce qui est transféré est l'installation, la configuration de base et la vérification d'environnement ; ce qui est conservé est le problème, la direction et les critères d'évaluation.

Traitement des exercices**

Les cinq questions à choix multiple associées sont à traiter après l'exposé, en donnant pour chaque question un critère de jugement en une phrase, pour l'auto-vérification des apprenants.

Le bon jugement est « le point d'interaction par défaut passe de la consultation manuelle de documentation, la configuration d'environnement, l'écriture de squelette, à un lancement direct d'expérience par instruction concise dans un outil IA ». Si l'étudiant choisit la stratégie de recherche, la migration cloud ou le remplacement d'architecture réseau, il confond « changement de point d'entrée » et « changement d'algorithme » ; revenir à cette page pour souligner : ce point décrit comment l'humain commence à travailler.

Le bon jugement est « l'outil réalise en une seule instruction l'installation, la configuration de base et la vérification d'environnement et rapporte l'état, le chercheur entre alors dans l'expérience ». S'il pense que l'outil garantit qu'il n'y a plus besoin de vérifier la version et la visibilité GPU, ou qu'il détermine automatiquement le problème de recherche et les indicateurs d'évaluation, il élargit la portée — l'outil ne couvre que le segment d'ingénierie installation et configuration de base.

Le bon jugement est « réduire le coût de prise en main et de configuration, mais ne pas remplacer le jugement du chercheur sur la définition du problème, la direction de recherche et les critères d'évaluation ». Lire « gagner du temps » comme « économiser du jugement », ou penser que cela n'a de valeur que pour les débutants, nécessite de revenir à la conclusion sur les frontières pour se repositionner.

Le bon jugement est « la valeur vient du transfert de la friction d'ingénierie et du raccourcissement du cycle d'itération, la condition étant que le chercheur puisse encore vérifier les résultats de configuration et la reproductibilité des expériences ». Ici, il faut distinguer « réduire les opérations manuelles » et « réduire le jugement manuel ».

La question 5 est une projection des conséquences de l'absence de vérification, le bon jugement est « environnement non reproductible, différences entre expériences difficiles à localiser, stabilité des résultats non garantie ». En rétroaction, souligner : le problème n'est pas la limite de capacité de l'outil, mais l'absence d'étape de vérification ; une configuration non vérifiée laisse des risques pour la reproduction et la localisation des pannes.

Activité en classe**

La discussion de cas peut se dérouler autour de « réussir en trois jours une expérience d'évolution de méthode EvoX ». La première question demande d'expliquer quel coût est réduit et quelle responsabilité est conservée : ce qui est réduit est le coût de friction d'ingénierie, ce qui est conservé est la décision de modélisation du problème et de la direction, la détermination des critères d'évaluation, et la vérification de la configuration. La deuxième question porte sur la reproduction multi-machines ; on peut guider les apprenants à donner au moins deux pratiques vérifiables : sauvegarder la version réellement installée par l'outil et la liste des dépendances et les comparer point par point entre machines ; vérifier le modèle GPU, la mémoire et le nombre de dispositifs visibles de chaque machine, en fixant les numéros de dispositif si nécessaire ; fixer les graines aléatoires et la taille de lot et autres réglages clés, relancer d'abord la tâche de référence sous la même configuration, confirmer que les résultats restent dans la plage de fluctuation attendue, puis augmenter l'échelle de l'expérience.

Vérification de la compréhension**

« Si l'installation est entièrement confiée à l'outil, que devez-vous confirmer en priorité le lendemain ? » Pouvoir citer la vérification de la version, des dépendances et de la visibilité GPU suffit pour considérer la maîtrise acquise.

Indication de transition**

Après avoir confirmé que les apprenants peuvent énoncer la ligne de répartition « l'outil se charge de la préparation d'ingénierie, le chercheur se charge du jugement de recherche », passer aux exemples, applications ou synthèse de la page suivante.

<a id="lecture-page-15"></a>

### Le goût essentiel du chercheur : répartition homme-machine et pensée critique

*Page 15*

> **Objectif de la page :** Comprendre le goût scientifique irremplaçable et le jugement critique du chercheur dans le processus d'évolution assistée par IA.

> **Objectif de la page**
>
> Comprendre le goût scientifique irremplaçable et le jugement critique du chercheur dans le processus d'évolution assistée par IA. Question centrale : lorsque l'IA réduit considérablement le coût de « l'implémentation des réponses », vers quoi se déplace la valeur de la recherche ?

**Points clés de l'enseignement**

- L'IA / EvoX peut rapidement achever l'implémentation de code, les exécutions d'expériences par lots, la génération de candidats, la recherche de paramètres et l'enregistrement de rétroaction ; le coût d'ingénierie n'est plus le goulot d'étranglement central. Le chercheur décide quel problème mérite d'être étudié, quel résultat a du sens, quelle preuve suffit à étayer une conclusion. L'IA étend l'espace d'implémentation et de recherche.
- Le chercheur contrôle la définition du problème, les conflits d'objectifs, les frontières des contraintes et les critères de validation. Considérer la sortie de l'IA comme une hypothèse à vérifier, examiner si l'hypothèse tient, si les preuves sont suffisantes, si les conditions limites sont prises en compte, si les résultats négatifs sont ignorés, évitant d'être induit en erreur par des réponses fluides mais non vérifiées. En exploration ouverte et rétroaction sparse, le choix de direction ne peut être externalisé à l'IA.
- Le jugement final et la responsabilité de la recherche restent au chercheur. À gauche, l'IA / EvoX, correspondant à la génération de candidats, l'exécution d'expériences, l'espace de recherche, l'enregistrement de rétroaction.
- À droite, le chercheur, correspondant à poser les questions, évaluer les preuves, arbitrer les compromis, réfléchir à la direction.
- Au centre, « Code is cheap. Taste matters ». En dessous, « Boucle de rétroaction : point de contrôle critique » indique qu'il ne s'agit pas d'un flux unidirectionnel, mais d'un cycle où la production de l'IA revient vers l'humain, qui redéfinit ensuite problèmes et normes. Dans une tâche d'optimisation multi-objectif EvoX, l'IA génère rapidement un grand nombre de solutions candidates et de code expérimental. Le chercheur doit juger : la fonction objectif reflète-t-elle les besoins réels ? La baseline est-elle équitable ? Les indicateurs omettent-ils des contraintes clés ? Si l'on ne regarde que le score, on peut choisir une solution apparemment optimale mais non conforme aux besoins réels. Ici, « Code is cheap. Taste matters » se manifeste ainsi : l'IA se charge de l'implémentation rapide et de la recherche, le chercheur examine la définition du problème et les critères de preuve, jugeant quels résultats ont réellement du sens.

**Traitement des exercices**

Le goût scientifique irremplaçable et le jugement critique du chercheur, ainsi que la répartition où l'IA se charge de l'implémentation et l'humain du jugement. Les options erronées se caractérisent typiquement par le saut des concepts, le saut de la récitation du matériel, la conclusion à partir de la seule intuition, ou la modification simultanée de tous les facteurs pour comparer les résultats. La réponse au cas en classe doit aboutir à : considérer la sortie de l'IA comme une hypothèse à vérifier, examiner la fonction objectif, la baseline et les indicateurs ; et préciser que le choix de direction et la responsabilité de la recherche ne peuvent être externalisés.

**Vérification de la compréhension**

Demander aux étudiants de distinguer dans leurs propres mots « coût d'implémentation » et « valeur de jugement », et de donner chacun un maillon pouvant être confié à l'IA et un maillon devant rester au chercheur. Après avoir clarifié la relation entre les deux, passer à la page suivante.

<a id="lecture-page-16"></a>

### Synthèse du cours : construire l'infrastructure d'un monde logiciel en évolution continue

*Page 16*

> **Objectif de la page :** Synthétiser le contenu central du cours et clarifier la vision d'une infrastructure intelligente ouverte, évolutive et à sédimentation continue.

**Points clés de l'enseignement**

- Solutions candidates, méthode de génération de candidats (comme les configurations interne/externe de MetaDE), actifs au niveau projet, sont trois niveaux différents. Avant de concevoir ou de répondre, préciser d'abord « quel niveau j'optimise actuellement », ce qui évite de confondre évolution de méthode et évolution continue au niveau projet.
- Seules les productions ayant passé une validation stricte sont autorisées à entrer dans la bibliothèque d'expérience et à être héritées. Une fois qu'un résultat non validé est hérité par une tâche en aval, l'erreur s'am