# EvoX Système d'Évolution Intelligente et Pratique de Recherche AI Native — Support de Cours
Durée : 1 · Pages du support : 16
## Navigation de lecture
- [Leçon 7｜Thème : Paradigme de recherche AI Native et entrée en pratique avec EvoX](#lecture-lesson-1)
---
## Leçon 7｜Thème : Paradigme de recherche AI Native et entrée en pratique avec EvoX
### Paradigme de recherche AI Native et entrée en pratique avec EvoX
*Page 1*
> **Objectif de la page :** Maîtriser un parcours pratique pour aborder EvoX dans un environnement AI Native, et appréhender le principe fondamental de la recherche : « Code is cheap. Taste matters. »
> **Objectif de la page**
>
> C'est la page d'ouverture de la septième leçon, qui donne le ton à l'ensemble de l'unité « Paradigme de recherche AI Native et pratique EvoX ». L'apprenant doit établir deux constats : premièrement, le parcours pratique pour mener efficacement des expériences EvoX dans un environnement AI Native avec l'aide d'outils IA comme Codex ; deuxièmement, lorsque le code peut être généré automatiquement, la capacité véritablement irremplaçable du chercheur — le sens critique et la capacité à poser les bonnes questions, c'est-à-dire la phrase répétée sur cette page : Code is cheap. Taste matters.
> **Ordre de présentation**
>
> 1. Commencer par le contexte. Expliquer que dans le mode de travail AI Native, la rédaction de scripts d'expérimentation, la construction de pipelines d'optimisation EvoX, l'exécution d'expériences comparatives — ce « travail de force » — peut être largement pris en charge par des outils IA, sans que le chercheur ait à tout écrire ligne par ligne. Cela change directement le rythme de la recherche : on passe de « peut-on l'écrire » à « vaut-il la peine de le faire ».
>
> 2. Passer ensuite à la méthode. Pour mener des expériences EvoX avec des outils comme Codex, l'approche typique consiste à exposer clairement son intention expérimentale, la formulation du problème et les critères d'évaluation, à laisser l'outil générer un squelette de programme exécutable, tandis que le chercheur se concentre sur la vérification de la validité du design expérimental et de la crédibilité des résultats.
>
> 3. Terminer par le principe fondamental. Puisque le code devient bon marché, ce qui devient rare c'est le jugement : le sujet vaut-il la peine d'être traité, la baseline est-elle équitable, les métriques sont-elles pertinentes, les conclusions tiennent-elles debout. Le Taste détermine la direction de la recherche, la capacité à poser des questions détermine sa profondeur.
**Points clés de l'enseignement**
- Les outils IA réduisent le coût d'implémentation, pas le seuil de la recherche
- Le seuil s'est déplacé de la « maîtrise de la programmation » vers le « goût pour les problèmes ». Lorsqu'on utilise des outils comme Codex, le rôle humain est de poser de bonnes questions, de définir les critères d'évaluation et d'examiner les résultats générés, plutôt que d'accepter passivement les sorties. « Code is cheap. Taste matters. » ne nie pas les compétences d'ingénierie, mais rappelle que : à l'ère de la programmation automatisée, le sens critique et la capacité à poser des questions sont les véritables douves du chercheur.
**Vérification de compréhension**
Demander à un apprenant d'expliquer avec ses propres mots, si le code peut être généré automatiquement, où le temps du chercheur devrait être réinvesti dans les expériences EvoX. Une réponse satisfaisante doit pointer vers le choix des problèmes, la conception expérimentale, le jugement des résultats — des travaux de nature décisionnelle — et pas seulement « laisser l'IA écrire plus vite ».
> **Indication de transition**
>
> Après avoir confirmé que l'apprenant peut énoncer la relation fondamentale « baisse du coût d'implémentation, hausse de la valeur du jugement », passer aux pages suivantes pour dérouler les étapes pratiques et les exemples concrets d'EvoX.
### Paradigme de recherche AI Native et entrée en pratique avec EvoX
*Page 2*
> **Objectif de la page :** Comprendre le parcours global et les principes fondamentaux de la recherche pour aborder EvoX dans un environnement AI Native.
> **Objectif de la page**
>
> Relier le « paradigme de recherche AI Native » et « l'entrée en pratique avec EvoX » en un seul parcours — lorsque le coût d'implémentation baisse, le chercheur doit déplacer son attention de l'écriture de code vers la formulation de questions, la définition de l'évaluation, le jugement de la direction et la critique des résultats, en gardant à l'esprit le principe fondamental « Code is cheap. Taste matters. ».
> **Ordre de présentation**
>
> D'abord expliquer le changement de paradigme, puis lire le schéma d'architecture, ensuite préciser qu'EvoX n'est pas un outil algorithmique unique mais un système d'évolution intelligente exécutable, composable et durablement explorable ; enfin aboutir à l'entrée en pratique : passer de « choisir un algorithme » à « concevoir un processus ».
**Points clés de l'enseignement**
- Les grands modèles, les GPU, les Agents et les workflows automatisés deviennent l'infrastructure de recherche par défaut. Le code d'implémentation, les expériences en masse, l'élargissement de la recherche deviennent de plus en plus bon marché
- L'IA est responsable de l'implémentation des réponses, de l'accélération des expériences, de l'élargissement de la recherche
- L'humain est responsable de la direction, des contraintes, du goût et des décisions clés. L'attention humaine se déplace du « codage » vers « définir les standards, faire des arbitrages, examiner les résultats ». Partant de « problème réel · goût de la recherche », l'humain pose les questions, définit les standards, juge la direction
- Après transformation en exploration exécutable, l'infrastructure IA prend le relais, puis transmet à EvoX. En interne, EvoX comporte quatre étapes : définition du problème (conflits d'objectifs, contraintes), conception de l'évaluation (métriques, poids, seuils), processus évolutif (solutions candidates, itérations en masse), ordonnancement Runtime (puissance de calcul, concurrence, reproductibilité). La sortie produit des solutions multiples candidates, des résultats vérifiables, une évolution continue, formant une production scientifique critiquable et reproductible, et revient au point de départ par une boucle de rétroaction « critique et validation ». Héritant du courant du calcul évolutionnaire, il est orienté vers les problèmes multi-objectifs complexes, l'exploration ouverte et l'évolution continue au niveau système. Ce n'est pas un solveur unique, mais une base d'ingénierie exécutable, composable et durablement explorable : le produit d'une expérience peut être hérité par la suivante, le processus de recherche lui-même peut évoluer continuellement. Les quatre piliers restent la définition du problème, la conception de l'évaluation, le processus évolutif et l'ordonnancement Runtime. L'erreur typique est de considérer le point d'entrée comme « choisir un algorithme parmi plusieurs ». Le bon point de départ est d'identifier d'abord les conflits d'objectifs et les contraintes, de transformer le problème en un processus d'exploration exécutable, comparable et durablement évolutif. L'humain définit d'abord les conflits d'objectifs, les contraintes et les critères de validation
- L'IA génère et itère rapidement le code
- EvoX exécute en masse et compare les solutions candidates
- Il en résulte des résultats critiquables et vérifiables. Par exemple, pour une expérience d'optimisation multi-objectifs, il ne faut pas laisser l'IA écrire tout le code puis accepter directement les sorties, mais confier à la machine l'implémentation et l'exploration, et à l'humain la définition et le jugement. Code is cheap. Taste matters. Lorsque le code n'est plus rare, le goût pour les problèmes, les critères d'évaluation, le jugement d'arbitrage et la capacité de validation deviennent des compétences de recherche plus difficiles à remplacer.
**Traitement des exercices**
Cette page comporte 5 questions à choix multiples. La bonne réponse à la question 1 est « passer de l'écriture de code à la formulation de questions, la définition des critères d'évaluation et le jugement de la direction » ; point de rétroaction : l'implémentation et l'exploration en masse peuvent être confiées à l'IA, la responsabilité centrale de l'humain est de poser des questions, définir des standards et juger les résultats. La bonne réponse à la question 2 est « un système d'évolution intelligente et une base d'ingénierie exécutable, composable et durablement explorable » ; en cas d'erreur, rappeler de ne pas réduire EvoX à un algorithme particulier. La bonne réponse à la question 3 est « identifier d'abord les conflits d'objectifs et les contraintes, transformer le problème en un processus d'exploration exécutable » ; souligner que le point d'entrée n'est pas le choix d'algorithme ou le réglage de paramètres. La bonne réponse à la question 4 est « lorsque le code n'est plus rare, le goût pour les problèmes, les critères d'évaluation et le jugement de validation deviennent des capacités plus rares » ;
Cela ne nie pas l'implémentation et la vérification, mais souligne un déplacement de la rareté. La bonne réponse à la question 5 est « laisser l'IA écrire tout le code puis adopter directement ses résultats d'exécution, sans plus définir humainement les objectifs et les standards » ; cela entre en conflit avec la répartition « l'IA implémente et explore, l'humain définit et juge ».
Concevoir une expérience d'optimisation multi-objectifs avec EvoX. Le scénario exige d'optimiser simultanément le coût, la performance et la robustesse, trois indicateurs en conflit mutuel, sous contraintes de budget de calcul et de délai de livraison. La répartition homme-machine doit s'écrire ainsi : l'humain est responsable de la définition et du jugement — poser les questions, écrire explicitement les conflits d'objectifs et les contraintes, concevoir les métriques d'évaluation et les seuils de validation, et face aux résultats, effectuer le jugement de direction et la validation critique ; l'IA est responsable de l'implémentation et de l'exploration — générer et itérer rapidement le code, exécuter en masse les solutions candidates, élargir la recherche et accélérer les expériences. Les deux forment une boucle fermée « l'humain fixe la direction — l'IA élargit l'exploration — l'humain valide ».
Si les conflits d'objectifs ne sont pas explicitement définis, les critères d'évaluation vagues, les contraintes ignorées, les résultats seront difficiles à juger, à reproduire et à capitaliser ; il faut plutôt se concentrer sur la conception du processus, clarifier la définition du problème et la méthode d'évaluation, planifier la génération de solutions candidates, la comparaison par exécution en masse et l'ordonnancement Runtime, et intégrer chaque cycle de résultats dans la critique et la validation.
**Activité en classe**
Demander aux étudiants de choisir un problème familier, d'écrire en une phrase les conflits d'objectifs et les critères de validation, puis d'expliquer ce que l'IA et EvoX prennent en charge respectivement. Vérification de compréhension : demander aléatoirement à un étudiant de reformuler « pourquoi définir l'évaluation avant de toucher au code », et d'indiquer le rôle de la boucle de rétroaction dans le schéma d'architecture. Indication de transition : après avoir confirmé que les étudiants distinguent les capacités bon marché des capacités rares, passer à la page suivante avec exemples, applications ou résumé.
### Limites des capacités des grands modèles et systèmes à évolution continue
*Page 3*
> **Objectif de la page :** Comprendre l'écart entre la croissance des capacités des grands modèles et la construction de systèmes capables de s'adapter durablement au monde réel.
**Points clés de l'enseignement**
- Face à des affirmations comme « amélioration des capacités du modèle », poser deux questions : où se déposent les résultats effectifs de ce cycle ? Qui les hérite au cycle suivant ? Si l'on ne peut pas répondre, c'est seulement la capacité d'un appel unique qui s'améliore, pas la capacité d'adaptation à long terme du système.
- D'abord produire des candidats → puis vérifier en réel → déposer en base → hériter et ré-évoluer. L'ordre ne peut pas être inversé : sans candidats, pas de vérification ; sans vérification, pas de dépôt ; sans dépôt, pas de point de départ héritable.
- Deux malentendus fréquents : prendre « une bonne performance sur une tâche unique » pour « une capacité d'adaptation à long terme du système » ; prendre « un candidat non vérifié » pour « une conclusion établie ». La méthode d'auto-vérification consiste à voir si ce résultat a franchi la vérification réelle et s'il a été inscrit dans une version de projet héritable.
Objectif de la page**
La « croissance des capacités » d'un grand modèle et l'« adaptation à long terme » d'un système ne sont pas la même chose. L'apprenant doit comprendre pourquoi renforcer les capacités du modèle n'équivaut pas automatiquement à ce qu'un projet puisse évoluer continuellement dans le monde réel, et de quels maillons un système en boucle fermée au niveau système doit être constitué.
Ordre de présentation**
Il est recommandé de progresser dans l'ordre « composants de capacité → pourquoi cela ne suffit pas → boucle fermée en quatre étapes → relation composant-système → auto-vérification des erreurs ». D'abord clarifier ce que le grand modèle peut faire, puis créer l'écart cognitif (fort en une fois ≠ stable à long terme), ensuite donner la structure en boucle fermée comme solution, et enfin conclure avec le couple conceptuel « composant—système ».
Points clés de l'enseignement**
Un, les trois types de capacités offertes par les grands modèles. Il peut déjà assumer de manière stable une forte compréhension, génération et appel d'outils : analyser objectifs et contraintes en descriptions de tâches exécutables ; produire des hypothèses candidates, du code, des designs expérimentaux et de la documentation ; connecter des ressources externes comme la recherche, le calcul, la compilation et la simulation. Par conséquent, intégrer un grand modèle comme « composant intelligent » dans les processus de recherche et d'ingénierie est déjà une pratique réaliste. Mais il faut préciser : ces trois types de capacités répondent à « une tâche unique peut-elle être bien faite », pas à « une tâche à long terme peut-elle être continuellement bien faite ».
Deux, pourquoi une capacité forte en une fois ne suffit pas. Les projets d'ingénierie réels durent souvent des mois voire des années, et le contexte d'un Agent unique finit par s'épuiser. Si l'expérience ne peut pas se déposer, chaque cycle de travail repart de zéro, et la croissance des capacités ne se transforme pas automatiquement en capacité d'adaptation à long terme. On peut ici proposer : il faut étendre l'objet de l'évolution à un « monde logiciel » persistant, et s'appuyer sur une persistance au niveau du projet pour que l'expérience ne se perde pas à chaque expérience.
Des composants intelligents proposent des hypothèses, des modifications ou des implémentations, mais à ce stade ce ne sont que des candidats, pas des conclusions ; vérification réelle : les candidats doivent passer par l'environnement réel, la simulation ou l'expérimentation, et franchir les barrières de compilation, de tests, de vérification comportementale et de validation de niveau supérieur ; dépôt des résultats : seuls les résultats effectifs ayant passé la vérification sont inscrits dans la version de projet acceptée, devenant des actifs réutilisables ; ré-évolution : les travaux ultérieurs héritent des résultats déposés et continuent à proposer des candidats sur cette base. La formule est « produire d'abord les candidats → vérifier ensuite en réel → déposer en base → hériter et ré-évoluer ». Il faut souligner la dépendance logique : sans candidats, pas de vérification ; sans vérification, pas de dépôt ; sans dépôt, pas de point de départ héritable.
Quatre, prendre un système multi-Agent collaboratif comme Genesis comme exemple de boucle fermée. Les Agents participant au travail ont un cycle de vie limité ; l'exécutant supérieur comprend l'objectif et décompose récursivement les tâches, l'exécutant inférieur réalise l'implémentation et les tests locaux, et continue à récurser vers le bas si nécessaire ; les modifications candidates ne sont soumises qu'en tant que candidates et doivent passer la compilation, les tests, la vérification comportementale et la validation de niveau supérieur pour être acceptées ; les tentatives échouées sont rejetées, les résultats validés sont inscrits dans la version du projet et deviennent la base historique des exécutants suivants. Dans des scénarios comme la refactorisation de compilateurs et la mise à niveau de logiciels scientifiques, ce mécanisme montre une fiabilité et un facteur d'accélération d'exécution très élevés.
Le composant de capacité est responsable de produire des candidats de haute qualité en un point unique ; la boucle fermée du système est responsable de déterminer quels candidats méritent d'être conservés, comment les conserver, et comment ils seront hérités au cycle suivant. Sans boucle fermée, plus la capacité est forte, plus elle ne produira que des candidats non vérifiés ; sans composant fort, la boucle fermée manque de sources de candidats de qualité.
Six, erreurs courantes et méthodes d'auto-vérification. La méprise la plus fréquente est d'assimiler directement « amélioration des capacités du modèle » à « adaptation à long terme du système ». Le critère de jugement n'est pas la performance du modèle sur une tâche donnée, mais si les résultats effectifs peuvent être stablement déposés et hérités par le cycle suivant. On peut enseigner aux apprenants deux questions à poser : où se déposent les résultats effectifs de ce cycle ? Qui les hérite au cycle suivant ? Si l'on ne peut pas répondre, c'est seulement la capacité d'appel unique qui s'améliore. Un autre malentendu est de prendre « un candidat non vérifié » pour « une conclusion établie » ; la méthode d'auto-vérification consiste à voir s'il a franchi la vérification réelle et s'il a été inscrit dans une version de projet héritable.
Indices de matériel**
À gauche, la zone « capacités des grands modèles » listant compréhension, génération et appel d'outils ; à droite, la « boucle fermée du système à évolution continue », constituée des quatre nœuds : production de candidats, vérification réelle, dépôt des résultats, ré-évolution, avec au centre la mention « les composants de capacité doivent être organisés par le système ». Lors de la présentation, on peut parcourir la boucle fermée dans le sens des flèches, puis revenir à gauche pour expliquer que les composants n'ont de valeur à long terme que s'ils sont organisés par le système.
Indices d'exercices et orientations de réponses**
Le positionnement correct du grand modèle dans le processus (un composant intelligent organisable par le système, assumant compréhension, génération et appel d'outils) ; pourquoi la croissance des capacités n'équivaut pas à l'adaptation à long terme (le contexte d'une session unique s'épuise, et les résultats non vérifiés ne peuvent pas se déposer en actifs héritables) ; l'ordre correct des étapes de la boucle fermée (production de candidats → vérification réelle → dépôt des résultats → ré-évolution) ; le seuil pour qu'un code entre dans l'histoire du projet dans Genesis (passer la compilation, les tests et la vérification comportementale, et être validé par le niveau supérieur) ; ainsi que la formulation précise de la relation « composant—système ».
L'étude de cas demande de concevoir une boucle fermée au niveau système pour un laboratoire de calcul scientifique de long terme, et de fournir des mécanismes pour « les échecs réessayés à répétition » et « les nouveaux membres incapables d'hériter des conclusions antérieures ». Les points clés de la réponse sont : utiliser une passerelle de validation stricte et un enregistrement des décisions pour rejeter les candidats non validés et conserver les raisons d'échec, et utiliser une persistance au niveau du projet pour inscrire les résultats validés dans la version de projet acceptée ; en précisant également que — améliorer simplement les capacités du modèle ne fait qu'augmenter la qualité des candidats uniques, tandis que ces deux problèmes proviennent d'un manque de vérification, d'enregistrement et de dépôt.
Vérification de compréhension**
Pourquoi un modèle plus fort n'équivaut pas à un projet qui évolue mieux à long terme, et ce que résout chacune des quatre étapes de la boucle fermée. Si la réponse s'arrête à « le modèle est très fort », on peut suggérer de revenir aux deux questions « où se déposent les résultats effectifs, qui les hérite » pour compléter.
Indication de transition**
Après avoir confirmé que l'apprenant distingue « la qualité d'un candidat unique » de « la sélection, le dépôt et l'héritage au niveau système », passer à la page suivante d'application, d'exemple ou de pratique.
### Transformer un problème réel en processus d'exploration EvoX
*Page 4*
> **Objectif de la page :** Maîtriser la manière de délimiter les objets variables, les critères d'évaluation et les mécanismes de rétention face à un problème réel.
> **Objectif de la page**
>
> Maîtriser la manière de délimiter les objets variables, les critères d'évaluation et les mécanismes de rétention face à un problème réel, et comprendre l'ordre « d'abord la transformation du problème, ensuite le choix de l'algorithme ».
> **Ordre de présentation**
>
> Problème réel (besoin descriptible) → délimitation des objets variables (variables échantillonnables) → construction des critères d'évaluation (objectifs calculables) → mécanismes de rétention et de sélection (candidats héritables) → exploration itérative EvoX (chaque génération reproductible) → sortie de solutions candidates (conclusions mesurables).
>
> En cas de distorsion de l'évaluation, revenir à la construction des critères d'évaluation ; en cas d'effondrement de la diversité, revenir au mécanisme de rétention.
>
> 3. Développer ensuite les quatre conditions de validation, et illustrer la méthode de mapping avec la conception de profil d'aile supercritique.
>
> 4. Enfin, vérifier la compréhension par cinq questions vrai/faux et un cas de plaque de refroidissement de batterie.
**Points clés de l'enseignement**
- Transformer un problème réel en processus d'exploration EvoX, c'est, avant d'écrire toute configuration d'algorithme, réécrire une demande d'ingénierie ou de recherche floue en une définition de problème évolutif « échantillonnable, évaluable, conservable, vérifiable par itération ». EvoX prend en charge un pipeline d'exploration qui a besoin de savoir dans quel espace échantillonner, avec quels critères noter, quels résultats méritent d'être poursuivis. Ces informations ne peuvent venir que du problème lui-même. L'algorithme ne peut chercher des réponses que dans les limites de la définition ; il ne peut pas retrouver la bonne réponse dans un problème mal défini. Traduire la demande réelle en variables de décision, déterminer la forme de représentation, la dimension et les bornes, et distinguer les paramètres continus, les structures discrètes et même les objets de niveau programme. Des bornes trop étroites excluent la véritable solution optimale de l'espace de recherche
- Variables échantillonnables. Décomposer les objectifs flous en fonctions objectif calculables et contraintes, en précisant les indicateurs à maximiser, les contraintes dures et les compromis multi-objectifs. Lorsque le retour est sparse ou la simulation coûteuse, introduire un modèle substitut pour remplacer le calcul coûteux. Condition de validation : l'objectif est calculable, et pour une même entrée, le résultat est stable et reproductible. Définir comment les candidats sont sauvegardés, comparés et poursuivis, pour que le processus évolutif ait mémoire, direction et diversité, plutôt que des essais-erreurs one-shot sans lien entre eux. Condition de validation : les candidats sont héritables. Le résultat de la transformation doit être reproductible, mesurable et vérifiable par itération, chaque étape pouvant répondre à « ce changement est-il vraiment meilleur ». L'omission de variables conduit à une mauvaise compréhension de l'espace de solutions, la distorsion de l'évaluation fait dévier l'optimisation globale
- Ces deux types de biais ne peuvent être compensés ni par les opérateurs ultérieurs ni par plus d'itérations. Dans la conception de profil d'aile supercritique, les objets variables sont les paramètres de perturbation géométrique du profil de base
- Les critères d'évaluation sont des indicateurs multi-objectifs comme le rapport portance/traînée, la divergence de traînée, la robustesse, avec un modèle substitut pour contrôler le coût de simulation
- Le mécanisme de rétention produit un groupe de solutions candidates diversifiées équilibrant les différents indicateurs, remis aux experts du domaine pour un arbitrage. Pour un même problème réel, il suffit de changer un jeu de bornes de variables ou de critères d'évaluation pour que les conclusions de l'exploration soient complètement différentes.
**Couverture des mots-clés**
- Transformation du problème, délimitation des objets variables, variables échantillonnables, construction des critères d'évaluation, objectifs calculables, mécanismes de rétention et de sélection, candidats héritables, exploration itérative EvoX, chaque génération reproductible, distorsion de l'évaluation, effondrement de la diversité, modèle substitut, profil d'aile supercritique.
**Traitement des exercices**
La bonne réponse est « parce que la transformation détermine l'espace de recherche et les critères d'évaluation, l'algorithme ne peut chercher des réponses que dans les limites de cette définition ». Lors de la présentation, souligner que la transformation répond à « qu'est-ce qui peut changer » et « comment évaluer après le changement », que la limite supérieure de l'espace d'exploration et la direction d'optimisation en dépendent ; le coût d'échantillonnage ou le type d'opérateur ne sont pas les points clés.
La bonne réponse est « l'espace de recherche est trop étroit, la véritable solution optimale n'y est pas, les opérateurs et itérations ultérieurs ne peuvent pas compenser ». L'omission de variables est un biais de la phase de transformation ; la fonction d'évaluation, le mécanisme de rétention et les opérateurs ne créeront pas de dimensions non définies.
La bonne réponse est « utiliser un modèle substitut pour approximer l'évaluation à faible coût, tout en conservant explicitement les relations de compromis multi-objectifs et les contraintes dures ». Lorsque l'évaluation est coûteuse et les objectifs en conflit, la bonne approche est de réduire le coût d'une évaluation unique et d'exprimer explicitement les conflits et contraintes, plutôt que de réduire le nombre d'itérations ou de fusionner par simple pondération.
La bonne réponse est « permettre aux candidats d'être sauvegardés, comparés et poursuivis, pour que le processus évolutif ait mémoire, direction et diversité ». Le mécanisme de rétention n'est pas responsable de l'évaluation ni de la correction des bornes des variables.
La bonne réponse est « chaque étape doit être reproductible et pouvoir répondre à "ce changement est-il vraiment meilleur", sinon le biais sera amplifié dans les itérations ». Une évaluation globale a posteriori ne remplace pas la vérification progressive ; l'omission de variables et la distorsion de l'évaluation se produisent à la phase de transformation, et l'itération ne fera qu'amplifier le biais.
En cas de bonne réponse, confirmer que l'étudiant peut relier les concepts de cette page et expliquer sa justification ; en cas de mauvaise réponse, demander à l'étudiant de revenir au paragraphe correspondant, de trouver les preuves ou exemples clés avant de juger.
> **Indices d'exercices**
>
> - Optimisation géométrique des canaux d'une plaque de refroidissement de batterie. Ne prendre que la largeur du canal comme variable de décision, en ignorant les degrés de liberté structurels discrets comme la direction du canal, la forme topologique, le nombre de niveaux de branchement, la position des entrées/sorties, relève d'une délimitation trop étroite des objets variables, la véritable géométrie optimale pouvant ne pas être dans l'espace de recherche
> - Ne prendre que la température maximale comme unique objectif, en confiant la perte de charge et l'uniformité de température au jugement empirique, relève d'une distorsion des critères d'évaluation, les conflits multi-objectifs n'étant pas explicitement modélisés
> - Une simulation unique de 3 heures multipliée par 200 générations, sans contrôle du coût d'évaluation ni critères de vérification reproductibles, en choisissant directement dans les résultats l'individu « qui semble le meilleur », ne peut pas répondre à « ce changement est-il vraiment meilleur ». Sur les objets variables, intégrer ensemble les paramètres continus (largeur, profondeur, épaisseur de paroi du canal) et les structures discrètes (topologie du canal, nombre de niveaux de branchement, position des entrées/sorties), préciser les plages de valeurs ou le mode d'encodage, et distinguer les quantités fixes, la condition de vérification étant que les variables sont échantillonnables. Sur les critères d'évaluation, écrire la température maximale, la perte de charge et l'uniformité de température comme fonctions objectif multi-objectifs explicites, la limite supérieure de perte de charge et la faisabilité de fabrication comme contraintes dures, utiliser un modèle substitut pour assumer la plupart des évaluations avec un étalonnage périodique par simulation réelle, les conditions de vérification étant que l'objectif est calculable et stable/reproductible pour une même entrée. Sur le mécanisme de rétention, conserver un ensemble de candidats diversifiés équilibrant les objectifs, plutôt qu'une solution optimale unique, définir les règles de comparaison et de poursuite, et surveiller l'homogénéisation par une mesure de diversité, la condition de vérification étant que les candidats sont héritables. Dans l'exécution et la vérification, enregistrer génération par génération les indicateurs reproductibles
> - Si la crédibilité de l'évaluation baisse, revenir à la construction des critères d'évaluation pour réétalonner
> - Si la diversité s'effondre, revenir au mécanisme de rétention pour ajuster la stratégie de sélection et de poursuite.
**Activité en classe**
Demander aux étudiants de réécrire en une phrase « améliorer cette conception » en une définition de problème d'exploration comprenant objets variables, critères d'évaluation et mécanisme de rétention, puis de vérifier mutuellement si les conditions « échantillonnable, calculable, héritable, reproductible » sont satisfaites.
**Vérification de compréhension**
Demander aléatoirement à un étudiant de résumer avec ses propres mots les points clés de cette page, l'enseignant complétant selon la réponse les conditions de validation et les boucles de rétroaction manquantes.
> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer « définir d'abord, puis lancer l'optimiseur » et les deux types de mécanismes de retour, passer à la page suivante d'exemples, d'application ou de résumé.
### Optimisation multi-objectifs et exploration multi-solutions
*Page 5*
> **Objectif de la page :** Reconnaître la complexité des tiraillements multi-objectifs dans le monde réel et la nécessité de conserver un ensemble de solutions candidates.
> **Objectif de la page**
>
> Reconnaître la complexité des tiraillements multi-objectifs dans le monde réel, comprendre pourquoi il est nécessaire de conserver un ensemble de solutions candidates, et maîtriser la domination de Pareto, le front de Pareto, le coût de la scalarisation ainsi que l'évaluation bidimensionnelle de la convergence et de la diversité.
**Points clés de l'enseignement**
- Est-ce vraiment un problème multi-objectifs ? Le critère n'est pas « le nombre d'objectifs est supérieur à 1 », mais si les objectifs sont en relation de compromis. Prenons la conception de profil d'aile supercritique : le rapport portance/traînée, la résistance structurelle, la marge de décrochage et le coût de fabrication/simulation se tiraillent mutuellement ; augmenter le rapport portance/traînée signifie souvent une augmentation simultanée des charges structurelles et du coût de fabrication. Si tous les objectifs peuvent être améliorés simultanément sans perte, le problème dégénère en un problème mono-objectif, et l'exploration multi-solutions est alors inutile et gaspille du calcul. Des directions opposées, un compromis mutuel, voilà ce qui constitue un véritable problème multi-objectifs. Deux, domination de Pareto et front de Pareto. Une solution A domine une solution B si et seulement si A n'est pas inférieure à B sur tous les objectifs (pour chaque objectif i, fᵢ(A) ≤ fᵢ(B)), et est strictement meilleure sur au moins un objectif (il existe j tel que fⱼ(A) < fⱼ(B)). Toute solution dominée a un remplaçant « au moins aussi bon, meilleur quelque part », donc aucune valeur de rétention. Toutes les solutions non dominées par aucune autre constituent le front de Pareto — les solutions du front ne se dominent pas mutuellement, et laquelle est la plus appropriée dépend des préférences, pas des mathématiques. Trois, le coût de la mono-objectivation. Les méthodes de scalarisation comme la somme pondérée et la ε-contrainte compressent les objectifs vectoriels en un scalaire, ce qui est pratique en ingénierie mais a un coût bien concret : masquer la structure des compromis — une fois les poids fixés, la forme du front et les directions alternatives deviennent invisibles, le décideur ne voit qu'un score. Les poids doivent être donnés à l'avance — or les préférences réelles ne peuvent souvent pas être formalisées à l'avance, et ne se clarifient souvent qu'au stade de l'évaluation. Couverture limitée — la somme pondérée ne peut généralement atteindre que quelques points de contact sur le front, certaines portions du front non convexe étant difficiles à atteindre. Si un examen ultérieur modifie les poids, toute la recherche doit être relancée, ce qui est exactement l'inverse de « une exploration pour plusieurs libertés de décision ». Convergence et diversité. La convergence (l'ensemble de solutions se rapproche-t-il du vrai front) et la diversité (les solutions couvrent-elles différentes portions du front). Les deux se tirent souvent mutuellement : si la pression de sélection penche excessivement vers « meilleur », la population s'effondre sur un point ou un petit segment du front, semblant converger vite mais perdant l'information de compromis. Il faut donc maintenir explicitement la diversité de la population, en accompagnant la pression de sélection de crowding distance, décomposition, indicateur (comme l'hypervolume). Le déplacement de la position décisionnelle. L'optimiseur ne fait que produire un groupe de candidats comparables, la sélection finale est faite par les préférences ou les experts du domaine, l'optimiseur ne doit pas converger prématurément à la place du décideur. La raison pratique de conserver un groupe de candidats différenciés est la « couverture » — lorsque les préférences sont inconnues, changent selon le contexte, ou que les contraintes seront corrigées au stade du déploiement, un groupe de solutions diversifiées a plus de valeur qu'une « solution optimale » unique. En termes d'interface d'implémentation, un problème multi-objectifs doit être défini comme une fonction d'évaluation à valeurs vectorielles (retournant plusieurs valeurs d'objectifs en une fois) avec une sortie en ensemble de solutions candidates, plutôt qu'une fitness scalaire avec une valeur de retour unique. Le nombre de valeurs de retour de la fonction d'évaluation détermine la dimension des objectifs, la structure de sortie détermine si la diversité peut être préservée.
> **Indices de matériel**
>
> - La page fournit un nuage de points du front de Pareto en 2D, avec en abscisse l'objectif 1 masse structurelle (plus petit est mieux), en ordonnée l'objectif 2 coût de fabrication (plus petit est mieux). Le graphique annote les solutions non dominées, les solutions dominées, le front de Pareto, les points atteints par scalarisation, la direction d'amélioration, les zones sparses et denses. On peut s'appuyer sur ce graphique pour expliquer intuitivement les relations de domination, la forme du front et la diversité, et montrer que la somme pondérée ne peut généralement atteindre que quelques points du front.
> **Indices d'exercices**
>
> - La page contient 5 questions à choix unique et 1 étude de cas. La question 1 porte sur la détermination de la domination de Pareto, la bonne réponse étant « la solution A domine la solution B si et seulement si A n'est pas inférieure à B sur tous les objectifs, et est strictement meilleure sur au moins un objectif ». Lors de la présentation, souligner que les deux conditions doivent être satisfaites simultanément, que les solutions aux mérites croisés ne se dominent pas mutuellement et restent toutes deux sur le front de Pareto. La question 2 porte sur le critère de jugement d'un problème multi-objectifs, la bonne réponse étant « les objectifs sont de directions opposées, améliorer l'un se fait nécessairement au détriment de l'autre ». Lors de la présentation, indiquer que c'est la conflictualité qui est l'essence du multi-objectifs, le point clé n'étant pas le nombre d'objectifs mais la relation de compromis mutuel. La question 3 porte sur le jugement des méthodes de scalarisation, la bonne réponse étant « la scalarisation masque la structure des compromis et exige des poids donnés à l'avance, alors que les préférences réelles ne peuvent souvent pas être formalisées à l'avance ». Lors de la présentation, rappeler les deux coûts : masquer la structure des compromis, et devoir donner les poids à l'avance. La question 4 porte sur la relation entre convergence et diversité, la bonne réponse étant « les deux se tirent souvent mutuellement, une poursuite excessive de la convergence fait facilement s'effondrer la population sur un segment particulier du front ». On peut demander en retour : si toutes les solutions s'agglutinent en un point du front, bien qu'elles semblent converger, le décideur peut-il encore choisir ? La question 5 porte sur la répartition entre optimiseur et décideur, la bonne réponse étant « l'optimiseur produit un groupe de candidats non dominés comparables, la sélection finale est confiée aux préférences ou aux experts du domaine ». Lors de la présentation, expliquer que la position décisionnelle s'est déplacée, la valeur de l'optimisation multi-objectifs résidant précisément dans la conservation du groupe de candidats. L'étude de cas porte sur le compromis multi-objectifs d'un profil d'aile supercritique. La question 1 demande d'expliquer pourquoi il s'agit d'un véritable problème multi-objectifs, et le risque de produire un unique « profil optimal » par score pondéré au stade de l'évaluation. Points clés de la réponse : les objectifs sont de directions opposées, se tiraillant mutuellement, impossibles à améliorer simultanément sans perte
> - Le score pondéré masque la structure des compromis, exige des poids donnés à l'avance, et dès que les poids sont ajustés il faut relancer, ce que le budget de simulation ne peut difficilement supporter. La question 2 demande comment définir la fonction d'évaluation et la structure de sortie, et comment sélectionner sur site lors de l'évaluation. Points clés de la réponse : la fonction d'évaluation passe à une forme à valeurs vectorielles, retournant un quadruplet (rapport portance/traînée, masse structurelle, marge de décrochage, coût de fabrication et de simulation)
> - La sortie est un ensemble de solutions candidates, c'est-à-dire un groupe de solutions du front de Pareto non dominées
> - Au niveau algorithmique, maintenir explicitement la diversité, avec une pression de sélection par crowding distance, décomposition ou hypervolume
> - Lors de l'évaluation sur site, arbitrer selon les préférences réelles parmi le groupe de candidats. En cas de bonne réponse, confirmer que l'étudiant peut relier les concepts de cette page et expliquer sa justification
> - En cas de mauvaise réponse, demander à l'étudiant de revenir à l'explication de cette page, de trouver les preuves ou exemples clés avant de juger.
**Activité en classe**
On peut demander aux étudiants de donner un exemple de conflit multi-objectifs du quotidien (comme le compromis performance, prix, autonomie lors de l'achat d'un téléphone), d'expliquer pourquoi il n'existe pas de solution optimale unique, et la valeur de conserver un ensemble de solutions candidates.
**Vérification de compréhension**
Demander aléatoirement à un étudiant de résumer avec ses propres mots les points clés de cette page, l'enseignant complétant selon la réponse les mots-clés manquants, comme domination de Pareto, front de Pareto, convergence, diversité, effondrement de la population, fonction d'évaluation à valeurs vectorielles.
> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer l'essence du problème multi-objectifs (conflit d'objectifs) ainsi que la signification du front de Pareto et de la diversité, passer à la page suivante d'exemples, d'application ou de résumé.
**Source du matériel**
Issu du brouillon EvoClass, pages 7-7.
### MetaDE : améliorer les algorithmes évolutionnaires par les algorithmes évolutionnaires
*Page 6*
> **Objectif de la page :** Comprendre comment prendre la méthode de production de solutions candidates elle-même comme objet d'évolution.
**Points clés de l'enseignement**
- La couche interne répond à « qu'a-t-on calculé », la couche externe à « comment calculer mieux ». Entre les deux couches ne circule qu'un signal — la performance sur la tâche, c'est-à-dire la fitness.
- Ne pas prendre la solution obtenue par la couche interne comme le résultat final de MetaDE. Le vrai produit est une configuration d'algorithme transférable : la configuration reste efficace sur de nouvelles instances de la même famille, alors qu'une solution unique est souvent déjà périmée.
- Fermez le support et demandez-vous : une évaluation externe équivaut approximativement à combien d'exécutions internes complètes ? Si vous ne pouvez pas répondre, c'est que vous n'avez pas encore saisi la structure de coût de MetaDE et pourquoi le parallélisme est nécessaire.
【Objectif de la page】
Comprendre comment prendre la méthode de production de solutions candidates elle-même comme objet d'évolution, c'est-à-dire la boucle d'optimisation bi-niveau de MetaDE qui améliore les algorithmes évolutionnaires par les algorithmes évolutionnaires.
【Ordre de présentation】
La stratégie de mutation, le taux de croisement CR, le facteur d'échelle F, la taille de population NP — qui a choisi ces configurations ?
La couche externe encode et fait évoluer les configurations, la couche interne exécute DE en parallèle sur des tâches réelles et retourne l'évaluation de performance.
Passer de « trouver une solution » à « trouver une méthode qui trouve des solutions ».
Configuration descendante → résolution interne → retour de performance → mise à jour externe ; le coût d'évaluation est élevé, le parallélisme GPU est la condition clé d'activation.
5. Résumer l'essence en une phrase et les erreurs courantes, puis faire les exercices et la vérification de compréhension.
【Points clés de l'enseignement】
La couche interne reçoit un ensemble de configurations DE concrètes, exécute une résolution complète sur une tâche réelle, produit des solutions candidates et retourne une évaluation de performance comparable ; la couche externe encode les configurations, hyperparamètres ou combinaisons de stratégies DE comme individus, utilise la performance sur la tâche comme fitness, et met à jour la génération suivante de configurations par sélection, recombinaison et mutation.
La sortie du DE traditionnel est un vecteur solution ; la sortie de MetaDE est un ensemble de configurations d'algorithme capables de produire stablement de meilleures solutions sur ce type de tâche. L'objet de recherche passe de « la réponse » à « la machine qui produit les réponses », permettant au résultat d'une recherche externe d'être transféré et réutilisé sur d'autres instances de la même famille.
L'ensemble du système est relié par une boucle fermée — la couche externe transmet la configuration → la couche interne exécute la résolution → la performance est renvoyée → la couche externe met à jour la génération suivante de configurations sur cette base. Pour qu'un individu de la couche externe obtienne une fitness, il doit payer le coût d'une exécution interne complète (souvent plusieurs en parallèle), donc la gestion du coût d'évaluation et l'ordonnancement parallèle sont au cœur de la conception du système. C'est précisément la capacité du GPU à exécuter simultanément un grand nombre de tâches internes qui rend cette méta-optimisation « au coût d'évaluation élevé » réalisable en ingénierie.
La couche interne est responsable de « qu'a-t-on calculé », la couche externe de « comment calculer mieux ». Les deux couches partagent le même signal de fitness — la performance sur la tâche, ce qui est précisément la raison pour laquelle elles peuvent former une boucle fermée.
【Couverture des mots-clés】
Optimisation bi-niveau, couche interne, couche externe, fitness, transmission de configuration, retour de performance, parallélisme GPU, coût d'évaluation, configuration d'évolution différentielle (stratégie de mutation, taux de croisement CR, facteur d'échelle F, taille de population NP).
【Indices d'exercices】
L'objet d'évolution de la couche externe est la configuration d'algorithme ; la responsabilité de la couche interne est de recevoir la configuration, résoudre sur une tâche réelle et retourner l'évaluation de performance ; l'ordre de la boucle d'information est transmission de configuration → résolution interne → retour de performance → mise à jour externe ; par rapport au DE traditionnel, le déplacement d'objectif va de la recherche de la solution optimale d'un problème unique à la recherche d'algorithmes et configurations produisant mieux des solutions ; le principal coût de calcul provient du fait qu'évaluer un individu externe exige le coût d'une exécution interne complète, le parallélisme GPU exécutant simultanément un grand nombre de tâches internes, rendant la méta-optimisation réalisable en ingénierie.
En cas de bonne réponse, confirmer que l'étudiant peut relier les concepts de cette page et expliquer sa justification ; en cas de mauvaise réponse, suggérer de revenir à l'explication de cette page, de trouver les preuves ou exemples clés avant de juger.
Configuration d'un solveur de tournées logistiques avec MetaDE. La couche interne exécute complètement DE sur des tâches de livraison réelles, obtient une solution de tournée et un coût de transport moyen, retournés comme évaluation de performance comparable. La couche externe encode la configuration DE (comme [stratégie de mutation DE/best/1, CR = 0.7, F = 0.5, NP = 60]) comme individu, utilise le coût de transport moyen comme fitness, exécute sélection, recombinaison et mutation, génère la génération suivante de configurations. Avec un budget GPU limité, on peut utiliser une évaluation hiérarchique (pré-filtrer d'abord avec un petit nombre de tâches représentatives, ne réévaluer sur l'ensemble complet que les configurations en tête) et un ordonnancement parallèle par lots (regrouper en lots les exécutions internes correspondant à tous les individus d'une même génération et les soumettre au GPU) pour réduire le coût d'évaluation ou améliorer l'efficacité de la recherche ;
On peut aussi réduire la taille de la population externe ou utiliser un modèle substitut pour approximer la performance, mais il faut arbitrer entre diversité de recherche et biais d'estimation. Les justifications tournent toutes autour de « la fitness externe dépend d'une exécution interne complète » et « le parallélisme permet de diluer le temps d'attente d'un individu unique ».
【Erreurs courantes】
Ne pas prendre la solution obtenue par la couche interne comme le résultat final de MetaDE. Le vrai produit est une configuration d'algorithme transférable : la configuration reste efficace sur de nouvelles instances de la même famille, alors qu'une solution unique est souvent déjà périmée.
【Vérification de compréhension】
Une évaluation externe équivaut approximativement à combien d'exécutions internes complètes ? Si vous ne pouvez pas répondre, c'est que vous n'avez pas encore saisi la structure de coût de MetaDE et pourquoi le parallélisme est nécessaire. On peut aussi demander aux étudiants de résumer avec leurs propres mots les responsabilités des couches interne et externe et l'ordre de la boucle fermée.
【Indication de transition】
Après avoir confirmé que les étudiants peuvent énoncer « la couche interne répond à "qu'a-t-on calculé", la couche externe à "comment calculer mieux", les deux couches partageant le signal de fitness qu'est la performance sur la tâche », passer à la page suivante d'exemples, d'application ou de résumé.
### Mode de travail AI Native et entrée pratique
*Page 7*
> **Objectif de la page :** Expérimenter un workflow AI native sans mémorisation fastidieuse de commandes d'installation ou d'interfaces complexes.
> **Objectif de la page**
>
> Comprendre le mode de travail AI Native et l'entrée pratique, déplacer le point de départ de l'utilisation d'EvoX de la mémorisation des commandes d'installation et des interfaces complexes vers l'expression de l'intention expérimentale en langage naturel. Après l'apprentissage, l'étudiant doit pouvoir expliquer la signification de « le dialogue comme entrée », et distinguer les maillons dont sont responsables respectivement les outils IA et le chercheur.
> **Ordre de présentation**
>
> D'abord comparer la méthode traditionnelle et la méthode AI Native ; puis expliquer le processus complet « intention en langage naturel → compréhension et exécution par l'IA → production de l'expérience EvoX » ; enfin, avec le cas de la navigation avec évitement d'obstacles d'un robot d'entrepôt, démontrer comment décrire une expérience à l'IA avec le trio « objectif—contrainte—validation ».
**Points clés de l'enseignement**
- Décrire la tâche, les contraintes et l'objectif de validation en langage naturel, l'IA se charge de comprendre le code et d'exécuter. Pas besoin de maîtriser au préalable les commandes d'installation, la configuration des dépendances et les appels d'interfaces complexes. Installation du framework, configuration d'exécution, choix ou génération d'algorithmes, tout peut être assisté par l'IA. Le dialogue devient l'entrée pratique reliant l'intention du chercheur à la production de l'expérience EvoX. Le chercheur se concentre sur le goût pour les problèmes, les compromis multi-objectifs, la validation des solutions et le jugement critique. Dans la méthode traditionnelle, pour lancer une expérience EvoX, il faut d'abord mémoriser les commandes, les dépendances et les interfaces
- Le mode de travail AI Native déplace l'entrée vers « l'expression de l'intention ». Vous décrivez sur quel problème, sous quelles contraintes, avec quels critères de validation, et des outils comme Codex se chargent de traduire l'intention en code exécutable et en opérations d'environnement, et retournent l'état d'exécution. Ainsi, le point de départ de l'expérience n'est plus la mémorisation de commandes, mais une définition claire du problème. Navigation avec évitement d'obstacles d'un robot d'entrepôt. On peut demander en langage naturel à l'IA d'appeler EvoX NSGA-II, de faire de l'optimisation multi-objectifs sur GPU et de produire des itinéraires visualisés. Il faut ici distinguer trois types d'informations : l'intention est « pour la navigation avec évitement d'obstacles d'un robot d'entrepôt, utiliser EvoX NSGA-II pour faire de l'optimisation multi-objectifs sur GPU »
- Les objectifs sont : longueur de chemin minimale, distance de sécurité maximale, consommation d'énergie minimale
- La contrainte est un retour des résultats en 5 minutes
- L'objectif de validation est de produire le front de Pareto et les itinéraires visualisés, et de conserver des résultats reproductibles. Les outils IA se chargent de comprendre le code, configurer l'environnement et les dépendances, choisir ou générer l'algorithme, exécuter sur GPU et retourner l'état
- La responsabilité humaine se déplace vers la définition du problème, la fixation des critères d'évaluation, les compromis multi-objectifs, la validation des solutions et le jugement critique.
**Traitement des exercices**
Si l'on demande « quel est le concept clé », il faut saisir « expérimenter un workflow AI native sans mémorisation fastidieuse de commandes d'installation ou d'interfaces complexes ». Si l'on demande de juger quelle affirmation est la plus raisonnable, il faut choisir l'option pouvant relier les concepts de cette page et fournir des preuves ou exemples ; se fier uniquement à l'intuition, changer tous les facteurs en même temps, ou sauter les ressources pour réciter directement la réponse ne répondent pas aux exigences. Concernant « accomplir rapidement la configuration d'environnement et la conception d'algorithme », il faut aussi pouvoir l'expliquer avec des preuves ou des exemples, pas seulement mémoriser la conclusion.
**Vérification de compréhension**
Demander aux étudiants d'expliquer avec leurs propres mots la relation « intention en langage naturel → compréhension et exécution par l'IA → production de l'expérience EvoX », et d'expliquer pourquoi le chercheur doit encore vérifier si les contraintes sont satisfaites, si le front de Pareto est raisonnable, et si l'itinéraire est sûr et faisable. Après avoir confirmé que les étudiants distinguent la responsabilité d'exécution de l'IA de la responsabilité de jugement de l'humain, passer au contenu pratique suivant.
### Pratique : tâche de navigation d'un robot d'entrepôt
*Page 8*
> **Objectif de la page :** Comprendre comment appeler rapidement EvoX via l'IA pour résoudre un problème concret de navigation avec évitement d'obstacles.
> **Ordre de présentation**
>
> Rayonnages, allées, obstacles, point de départ et point d'arrivée sont tous déterminés, il faut trouver un chemin sans collision et aussi court que possible.
>
> 2. Indiquer que la longueur du chemin et la sécurité d'évitement d'obstacles sont généralement en désaccord, donc il s'agit d'un problème typique d'optimisation multi-objectifs, et non d'un plus court chemin mono-objectif.
>
> 3. Expliquer que l'IA agit comme un « traducteur de tâches », transformant la description en langage naturel en appel exécutable EvoX, réduisant l'encodage manuel et la configuration de paramètres.
>
> 4. EvoX NSGA-II exécute en parallèle sur GPU l'évaluation de la population et la recherche, conserve plusieurs solutions de compromis, formant une famille d'itinéraires allant de « court mais risqué » à « long mais sûr ».
>
> Visualiser la carte des itinéraires candidats et la courbe de tendance de convergence, pour observer la faisabilité et la progression de la recherche.
**Points clés de l'enseignement**
- Fixer la disposition de l'entrepôt, l'environnement d'obstacles, le point de départ et le point d'arrivée du robot. Points clés du chemin, points de contrôle de courbure, rayon de virage, profil de vitesse, etc. Minimiser la longueur du chemin
- Minimiser le risque de collision ou maximiser la faisabilité sans collision. L'itinéraire doit rester dans les allées, ne pas traverser les rayonnages ou les obstacles, et satisfaire les contraintes cinématiques du robot. Transformer automatiquement la description en langage naturel en appel exécutable EvoX, réduire le coût de configuration
- Ne pas remplacer l'algorithme d'optimisation lui-même. Évaluer en parallèle un grand nombre d'itinéraires candidats, accélérer les itérations NSGA-II
- Ne pas changer le fait que le multi-objectifs comporte des solutions de compromis. Visualiser la carte des itinéraires pour observer la faisabilité des chemins, la diversité et l'itinéraire sans collision recommandé
- La courbe de convergence pour juger si l'on entre en plateau. Définir d'abord objectifs et contraintes avant de régler les paramètres
- La faisabilité prime sur la longueur du chemin
- Utiliser la tendance de convergence pour décider si l'on continue à itérer ou si l'on s'arrête.
**Traitement des exercices**
Éléments d'entrée de la tâche -> disposition fixe de l'entrepôt, environnement d'obstacles, point de départ et point d'arrivée. Rétroaction : l'entrée de la tâche définit l'environnement, les contraintes et les conditions de départ/arrivée.
Les deux objectifs traités par NSGA-II -> longueur du chemin et sécurité d'évitement d'obstacles. Rétroaction : un chemin plus court peut passer plus près des obstacles, et l'exigence de sécurité peut allonger le chemin.
La valeur principale de l'IA -> transformer automatiquement la description de la tâche en appel exécutable EvoX. Rétroaction : l'IA est la couche de traduction de tâches et de génération d'appels, réduisant le coût de configuration.
L'avantage du GPU -> évaluer en parallèle un grand nombre d'itinéraires candidats, accélérer les itérations NSGA-II. Rétroaction : le GPU accélère l'évaluation et la recherche, sans changer la nature du compromis multi-objectifs.
Carte des itinéraires visualisés et courbe de convergence -> observer respectivement la faisabilité et la diversité des itinéraires et l'itinéraire sans collision recommandé ; si le processus d'optimisation converge. Rétroaction : la carte des itinéraires montre la qualité spatiale des solutions, la tendance de convergence montre la progression de la recherche dans la dimension temporelle.
Définir les variables de décision, les deux objectifs d'optimisation, les contraintes ; expliquer la répartition entre l'IA, EvoX NSGA-II et le GPU, et expliquer comment la tendance de convergence aide à la décision. Points clés de la réponse : l'IA analyse la description de la tâche en appel EvoX ; NSGA-II évalue en parallèle sur GPU, le tri non dominé et la crowding distance maintiennent les solutions de compromis ; sortie des itinéraires visualisés et des courbes de convergence ; si la courbe est plate, le gain est limité, si elle continue à descendre, on peut augmenter le nombre d'itérations ou la taille de population.
**Vérification de compréhension**
Demander aléatoirement à un étudiant de résumer avec ses propres mots les points clés de cette page, l'enseignant complétant 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 à la page suivante d'exemples, d'application ou de résumé.
### Analyse des résultats expérimentaux et visualisation
*Page 9*
> **Objectif de la page :** Apprendre à interpréter la tendance de convergence et les données de résultats complètes du processus d'optimisation.
> **Objectif de la page**
>
> Apprendre à interpréter la tendance de convergence et les données de résultats complètes du processus d'optimisation, comprendre que « la tendance du processus + le résultat final » doivent se corroborer mutuellement, et qu'on ne peut pas conclure sur la base d'un seul résultat optimal ponctuel.
> **Ordre de présentation**
>
> 1. Lire d'abord la courbe de convergence, juger si le processus de recherche progresse.
>
> 2. Examiner ensuite l'itinéraire final et le tableau d'indicateurs sous la disposition fixe de l'entrepôt, juger si la solution est utilisable.
>
> 3. Appuyer des conclusions reproductibles par des données expérimentales complètes.
>
> 4. Traiter les erreurs d'interprétation courantes par des exercices et des cas.
**Points clés de l'enseignement**
- Deux types de preuves sont indispensables. La courbe répond à « la recherche bouge-t-elle », l'itinéraire et les indicateurs répondent à « le résultat est-il utilisable ». Ce n'est que lorsque la tendance de convergence indique que la recherche progresse et que la visualisation de l'itinéraire et le tableau d'indicateurs indiquent que la solution est utilisable que les deux conditions sont simultanément satisfaites et qu'on peut conclure. Sans l'une des deux moitiés, ce n'est qu'une conjecture. Amélioration continue, baisse stable en début et milieu de phase ou hausse stable de l'indicateur composite
- Oscillation, fluctuations sans tendance à long terme, pouvant provenir du bruit d'évaluation, de conflits de contraintes ou d'une diversité trop grande
- Stagnation, une section presque horizontale mais une amélioration encore possible par la suite
- Convergence prématurée, aplatissement complet très tôt sans récupération, souvent dû à la perte de diversité de la population ou à une compression prématurée de l'espace de solutions. Lorsque la courbe montre « stagnation tardive/convergence prématurée ? » en fin de phase, il faut distinguer en s'appuyant sur les journaux, sans écrire directement « a convergé ». Pour la comparaison d'itinéraires sous la disposition fixe de l'entrepôt, superposer l'itinéraire optimal et l'itinéraire de comparaison sur la même carte fixe de l'entrepôt, vérifier si le chemin est réellement accessible, si le contournement des obstacles est raisonnable, si le dernier segment près de l'arrivée est stable. La disposition fixe est une contrainte clé, permettant d'attribuer les différences d'itinéraires entre différentes exécutions ou différents paramètres à l'optimisation elle-même, et non à un changement de carte. Le tableau d'indicateurs peut donner une comparaison intuitive : longueur de chemin 128,4 contre 156,9, nombre total de virages 6 contre 9, coût composite 1,00 contre 1,21, montrant la supériorité de l'itinéraire optimal sur plusieurs indicateurs. Configuration d'exécution et graine aléatoire, journaux d'itération, valeurs de chaque objectif par génération, itinéraire final et résultats d'évaluation. Si la courbe ne s'améliore plus nettement en fin de phase, il faut s'appuyer sur les journaux complets pour juger s'il s'agit d'une convergence prématurée, d'une saturation de l'évaluation, ou d'une solution déjà proche de l'utilisable
- Si nécessaire, relancer ou faire une vérification croisée. Une courbe qui s'aplatit tôt en douceur n'équivaut pas automatiquement à avoir trouvé la solution optimale, ni automatiquement à un algorithme défaillant
- Un itinéraire qui semble beau n'équivaut pas non plus à une recherche stable. Un résultat optimal unique peut être une véritable amélioration, ou le produit de fluctuations aléatoires ou d'une saturation de l'évaluation ; la tendance du processus et le résultat final doivent se corroborer mutuellement.
**Couverture des mots-clés**
- Tendance de convergence, vérification de l'itinéraire, disposition fixe de l'entrepôt, reproductible, convergence prématurée, saturation de l'évaluation, indicateur d'hypervolume, longueur de chemin, nombre total de virages, coût composite.
> **Indices d'exercices**
>
> - Les cinq questions à choix multiples tournent autour des jugements centraux de cette page. La question 1 porte sur la relation entre la courbe de convergence et la visualisation de l'itinéraire final, la bonne direction étant « la courbe reflète si le processus de recherche progresse, l'itinéraire et le tableau d'indicateurs reflètent si la solution finale est utilisable, les deux doivent être jugés conjointement ». La question 2 demande comment traiter des valeurs d'objectif horizontales pendant longtemps après la 200e génération, la bonne direction étant « juger en s'appuyant sur les journaux complets s'il s'agit d'une convergence prématurée, d'une saturation de l'évaluation ou d'une solution déjà proche de l'utilisable, et si nécessaire ajuster la stratégie et relancer ». La question 3 demande ce qu'il faut sauvegarder et vérifier pour des conclusions reproductibles, la bonne direction étant « configuration d'exécution, graine aléatoire, journaux d'itération, valeurs de chaque objectif, itinéraire final et résultats d'évaluation ». La question 4 demande le but de la disposition fixe de l'entrepôt, la bonne direction étant « permettre d'attribuer les différences d'itinéraires entre différentes exécutions ou différents algorithmes à l'optimisation elle-même, et non à un changement d'environnement ». La question 5 demande une interprétation rigoureuse d'une courbe « très lisse et s'arrêtant très tôt », la bonne direction étant « vérifier s'il existe une saturation de l'évaluation ou une perte prématurée de diversité de la population, et valider par relance et vérification croisée des indicateurs ». Rétroaction de réponse : en cas de bonne réponse, indiquer que ce jugement peut relier les concepts de cette page et fournir une justification
> - En cas de mauvaise réponse, revenir à l'explication de cette page, trouver les preuves ou exemples clés avant de juger. Dans « reproduction de la navigation multi-objectifs sous disposition fixe de l'entrepôt », si après la 180e génération la courbe s'aplatit et donne un bon itinéraire candidat, il faut collecter et vérifier la configuration d'exécution et la graine aléatoire, les journaux d'itération, les valeurs de chaque objectif par génération, l'itinéraire final et les résultats d'évaluation sous disposition fixe, le tableau des indicateurs clés, et recommander une relance ou une vérification croisée. On ne peut pas utiliser seulement le résultat optimal unique, car un optimum ponctuel peut provenir de fluctuations aléatoires ou d'une saturation de l'évaluation, ne permettant pas d'indiquer si la recherche progresse réellement, ni d'être reproduit par d'autres. Si après relance la forme de la courbe est similaire mais l'itinéraire final différent, il faut comparer les distributions d'indicateurs plutôt que les valeurs ponctuelles, vérifier la cohérence des graines et des configurations, examiner la convergence prématurée ou la saturation de l'évaluation, et si nécessaire augmenter le nombre d'itérations, ajuster la stratégie de maintien de la diversité ou corriger la fonction d'évaluation, et donner dans le rapport des itinéraires typiques et des résumés statistiques.
**Vérification de compréhension**
Demander aléatoirement à un étudiant de résumer avec ses propres mots « la courbe montre la tendance, l'itinéraire montre le déploiement » ainsi que la relation « la tendance du processus et le résultat final sont tous deux indispensables », l'enseignant complétant selon la réponse les mots-clés manquants. On peut demander aux étudiants de donner un exemple proche de leur expérience pour expliquer pourquoi regarder seulement la courbe ou seulement l'itinéraire peut conduire à une erreur de jugement.
> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer que la courbe de convergence et la visualisation de l'itinéraire doivent être jugées conjointement, passer à la page suivante d'exemples, d'application ou de résumé.
### Plus les outils sont faciles à utiliser, plus la responsabilité humaine est claire
*Page 10*
> **Objectif de la page :** Prendre conscience du changement de rôle et de responsabilité du chercheur humain après la généralisation des outils d'automatisation.
> **Objectif de la page**
>
> Comprendre qu'après la généralisation des outils d'automatisation, la responsabilité du chercheur ne s'allège pas, mais se déplace de « l'implémentation » vers « la définition et l'arbitrage ». Cette page doit faire retenir aux étudiants une phrase : plus les outils sont faciles à utiliser, plus la responsabilité humaine est claire.
**Points clés de l'enseignement**
- L'IA et EvoX compriment très bas le coût d'exécution « idée→code→expérience », la génération rapide d'implémentations candidates, le réglage de paramètres en masse, le tracé de courbes deviennent faciles. Mais la baisse du coût d'exécution n'équivaut pas à la disparition du coût de jugement. Le modèle ne peut pas répondre à trois questions préalables à la place du chercheur : ce problème vaut-il la peine d'être étudié ? Les objectifs sont-ils précis ? La comparaison est-elle équitable ? Pouvoir s'exécuter, compiler, passer les tests, améliorer les indicateurs, ne sont que des signaux candidats, pas la validation d'une conclusion scientifique. À gauche, la couche d'exécution IA/outils, responsable de générer le code candidat, les expériences en masse et le réglage de paramètres, le tracé et la visualisation automatiques, et d'éliminer rapidement les implémentations de faible valeur
- À droite, la couche de responsabilité humaine, responsable de poser les questions clés, définir les objectifs et les critères d'évaluation, garantir une comparaison équitable, valider si les conclusions sont valides, ainsi que le jugement de valeur et le goût. Au centre, la porte du « jugement non externalisable », les critères de validation non négociables, les modifications candidates devant passer par l'arbitrage humain. La passerelle de validation de Genesis est précisément l'ingénierisation de cette frontière : les modifications candidates doivent passer la compilation, les tests, la vérification comportementale et la validation de niveau supérieur pour entrer dans l'histoire du projet. Dans une expérience multi-objectifs EvoX, l'Agent peut rapidement générer des solutions candidates, régler les paramètres et tracer, mais le chercheur doit encore examiner : la fonction objectif représente-t-elle un besoin réel ? La diversité des candidats est-elle masquée par les indicateurs ? Les modes d'échec sont-ils sélectivement montrés ? À ce stade, la valeur de l'outil est de faire éliminer plus vite les implémentations de faible valeur, et de faire du jugement de haute valeur le goulot d'étranglement plus tôt. L'indice de Turing rejoint également ce point : il y a beaucoup de choses à faire devant nous, Code is cheap. Taste matters. La capacité centrale est de poser les questions clés et de contrôler les conclusions de manière reproductible
- Le goût du chercheur détermine en quelle valeur scientifique se transforme finalement la commodité technique.
**Couverture des mots-clés**
- Coût d'exécution, coût de jugement, jugement non externalisable, validité scientifique, passerelle de validation, signaux candidats, comparaison équitable, jugement de valeur et goût. Source du matériel : cette page s'articule autour de « déplacement de la responsabilité : de l'implémentation à la définition et à l'arbitrage » et « la validité des résultats prime sur le succès de l'exécution ». Indices de matériel : on peut utiliser un schéma comparatif gauche-droite pour mettre en évidence la répartition entre la couche d'exécution IA/outils et la couche de responsabilité humaine, en soulignant au centre le « jugement non externalisable ».
**Traitement des exercices**
La question 1 doit choisir « passer la compilation, les tests, la vérification comportementale et la validation de niveau supérieur », le point de rétroaction étant : peu importe la rapidité ou la beauté du graphique, ce n'est qu'un signal candidat, la clé étant la passerelle de validation. La question 2 doit choisir « le choix des problèmes, la définition des objectifs et les critères d'évaluation restent à la charge de l'humain », le point de rétroaction étant : l'outil accélère l'exécution, pas l'annulation du jugement. La question 3 doit choisir « le problème vaut-il la peine d'être étudié, les objectifs sont-ils précis, la comparaison est-elle équitable », le point de rétroaction étant : ces trois catégories sont des conditions préalables à la validité scientifique. La question 4 doit examiner en priorité « la fonction objectif représente-t-elle un besoin réel, la diversité des candidats est-elle masquée par les indicateurs, les modes d'échec sont-ils sélectivement montrés », le point de rétroaction étant : l'amélioration des indicateurs n'équivaut pas à la validation de la conclusion.
La question 5 doit choisir « après la baisse du coût d'implémentation, le goût et le jugement du chercheur déterminent en quelle valeur scientifique se transforme la commodité technique », le point de rétroaction étant : Code is cheap signifie la baisse du coût d'implémentation, Taste matters signifie que le jugement et le goût sont plus importants.
Dans un projet multi-Agent Genesis, l'Agent peut proposer des correctifs candidats, exécuter des tests et résumer les indicateurs, mais l'approbation pour entrer dans l'histoire du projet, la fixation des critères de validation et l'interprétation des conclusions doivent être à la charge de l'humain. Les jugements non externalisables comprennent : l'amélioration de la stabilité est-elle un vrai besoin, comment définir la stabilité, la référence représente-t-elle un scénario réel, et les baselines, variables, modes d'échec sont-ils traités de manière cohérente. Si l'on prend seulement « l'amélioration de l'indicateur de référence » comme critère de validation, le risque peut provenir d'un biais de la fonction objectif, d'un sur-apprentissage de la référence, d'une présentation sélective des cas de succès, d'une dissimulation des modes d'échec ou d'une comparaison inéquitable.
La direction d'amélioration est d'ajouter à la passerelle de validation la reproduction de la baseline, le contrôle des variables, les expériences d'ablation, le rapport des modes d'échec, le compromis multi-objectifs et la vérification des limites d'extrapolation, et d'exiger que l'humain confirme si la fonction objectif représente le besoin réel et si la comparaison est équitable.
Demander d'abord si cela vaut la peine, ensuite comment l'implémenter ; considérer les critères de validation comme sa propre responsabilité ; le goût détermine la direction de la commodité technique. Vérification de compréhension : demander aux étudiants d'énoncer en une phrase quel est le jugement non externalisable le plus important de cette page, et d'expliquer comment le vérifier. Indication de transition : après avoir confirmé que les étudiants distinguent « signal candidat » et « conclusion scientifique », et peuvent énoncer la frontière entre la couche d'exécution et la couche de responsabilité, passer à la page suivante d'application ou de résumé.
### Cœur de la recherche : la capacité à poser les questions clés
*Page 11*
> **Objectif de la page :** Maîtriser la capacité de questionnement, plus importante que l'écriture de code à l'ère de la programmation automatisée.
> **Objectif de la page**
>
> Cette page doit faire comprendre aux étudiants que dans la recherche AI Native, la programmation automatisée et les grands modèles ont déjà comprimé très bas le coût de « l'implémentation des réponses », le centre de gravité de la recherche se déplace donc de « peut-on le faire » vers « vaut-il la peine de le faire, où faut-il le faire ». La capacité centrale du chercheur est de poser les questions clés, et de tenir la direction, les critères d'arbitrage et la signification scientifique.
**Points clés de l'enseignement**
- 1. Le changement de structure de coût est le point de départ logique de cette page. La génération de code, la recherche de solutions, l'exécution d'expériences peuvent tous être confiés à l'IA
- Lorsque les réponses deviennent bon marché, ce qui devient rare c'est « poser la bonne question ». L'IA se charge d'élargir l'espace des réponses et le chemin d'exécution, l'humain de la définition du problème et du contrôle de la direction, la responsabilité se déplace en conséquence. 2. À l'aide de la carte mentale de la page, décomposer la capacité de questionnement clé en six types d'éléments, et les expliquer un par un : objectifs et conflits — quelle quantité veut-on réellement améliorer, comment arbitrer entre multi-objectifs, qui est prioritaire
- Contraintes et frontières — quelles conditions ne sont pas négociables, quelle est la taille de l'espace de solutions
- Évaluation et vérification — les indicateurs sont-ils observables, quel est le protocole de vérification et le budget d'évaluation
- Candidats/espace de solutions — quel type de diversité et de robustesse est nécessaire
- Critères d'échec — quel résultat doit être jugé comme un échec
- Répartition homme-machine et goût — l'IA élargit les réponses, l'humain contrôle la direction. On peut suggérer aux étudiants de mémoriser ces six catégories comme une liste d'auto-vérification. 3. L'essence du questionnement clé n'est pas de creuser les détails d'implémentation, mais de transformer une intuition floue en une structure de recherche testable, évolutive et répartissable. La qualité du questionnement détermine la qualité de l'espace de solutions : plus la définition du problème est claire, plus la recherche et l'évolution sont susceptibles de tomber dans des zones significatives, et plus la production est susceptible d'être explicable et réutilisable
- Plus la définition est floue, plus le modèle ne peut qu'explorer aléatoirement dans un espace trop grand, les résultats semblant souvent faisables mais impossibles à capitaliser. 4. Répartition homme-machine et goût central du chercheur. L'IA élargit l'espace des réponses et le chemin d'exécution, l'humain contrôle la direction, les critères d'arbitrage et la signification scientifique. Prenons l'exemple d'une pratique d'évolution continue au niveau système comme Genesis : les modifications candidates doivent passer la compilation, les tests et la validation de niveau supérieur pour entrer dans la version de projet acceptée et devenir la base historique des travaux ultérieurs
- Si la phase de questionnement n'a pas défini clairement le protocole d'évaluation et les critères d'échec, la passerelle de validation n'a aucun moyen de juger, et la production de l'IA ne peut rester qu'un produit de code one-shot, sans pouvoir s'accumuler à travers les contextes et les cycles de tâches. Le goût central, ce sont trois jugements : qu'est-ce qui vaut la peine d'être demandé, quelles preuves sont acceptables, quelle solution est faisable mais ne vaut pas la peine d'être faite. Le réécrire en « quel est le vrai conflit ? Comment quantifier objectifs et contraintes ? Quel est le budget d'évaluation et les critères de vérification ? Quel type de diversité et de robustesse est nécessaire ? Quel résultat doit être jugé comme un échec ? » Ainsi l'IA peut implémenter efficacement les réponses, et l'humain a de quoi valider. Les cinq questions à choix multiples correspondent aux cinq jugements de cette page — pourquoi le cœur de la recherche s'est déplacé, l'essence du questionnement clé, les éléments qu'une question clé doit préciser, la relation entre qualité du questionnement et espace de solutions, les trois jugements du goût central. Il n'est pas nécessaire de les lire une par une, on peut d'abord laisser les étudiants répondre, puis corriger avec des rétroactions comme « ce qui est comprimé est le coût d'implémentation, pas le coût de jugement » et « flou ne signifie pas libre ». L'étude de cas demande aux étudiants de réécrire « faire de l'optimisation avec EvoX » en une carte de questions couvrant objectifs et conflits, contraintes et frontières, évaluation et vérification, critères d'échec, et d'expliquer comment la qualité du questionnement détermine si l'expérience peut se capitaliser en résultats de projet durablement évolutifs. Points de référence : Genesis traite le code soumis comme une modification candidate, qui n'entre dans la version acceptée qu'après compilation, tests et validation de niveau supérieur
- Sans indicateurs observables, protocole de vérification et critères d'échec, la validation n'a pas de base
- L'IA se charge de générer les candidats, la recherche et l'exécution des tests, l'humain de délimiter les objectifs, les contraintes dures, le budget d'évaluation et les critères d'échec et de prendre la décision d'acceptation. Demander aléatoirement à un étudiant de reformuler avec ses propres mots les six auto-vérifications, et de donner un besoin flou de sa propre recherche, en essayant de le réécrire sur place. Après avoir confirmé que les étudiants peuvent énoncer les deux relations « pouvoir s'exécuter n'équivaut pas à valoir l'investissement » et « la qualité du questionnement détermine la qualité de l'espace de solutions », passer à la page suivante.
### Répartition homme-machine : l'IA implémente les réponses, l'humain contrôle la direction
*Page 12*
> **Objectif de la page :** Clarifier la répartition et la collaboration entre l'IA et le chercheur dans le processus d'exploration scientifique.
**Points clés de l'enseignement**
- Avant chaque expérience, se poser trois questions : qui a choisi ce problème ? Qui a défini les critères d'évaluation ? Qui valide les conclusions ? Si les réponses aux trois questions pointent vers « moi », la répartition est saine ; si elles pointent toutes vers le modèle, le contrôle de la direction est déjà perdu.
- Une fois que les critères d'évaluation peuvent être réécrits par un processus automatisé, l'optimisation se tourne discrètement vers « l'indicateur le plus facile à améliorer ». Déclarer la fonction objectif et les contraintes en lecture seule est la première barrière contre la dérive.
- L'IA élargit la bande passante, l'humain préserve le sens — ce qui est livré n'est pas plus de chiffres, mais des conclusions qui tiennent debout.
### Objectif de la page
Clarifier la répartition et la collaboration entre l'IA et le chercheur, préciser la frontière entre la couche d'exécution IA et la couche de contrôle humaine, comprendre pourquoi « l'IA élargit la bande passante d'exploration, l'humain préserve la signification scientifique ».
### Ordre de présentation
Confier l'implémentation et l'exploration à l'IA, réserver la direction et le jugement au chercheur.
Boucle fermée de collaboration homme-machine. La couche d'exécution IA comprend l'implémentation des réponses, l'exécution en masse des expériences, la recherche de solutions candidates, le retour des résultats ; la couche de contrôle humaine comprend la définition du problème, le choix de la direction, le jugement des preuves, la validation de la signification scientifique. Les deux côtés sont couplés par « les résultats montent, les standards descendent » : l'IA pousse les réponses candidates et le retour d'expérience vers le chercheur, le chercheur renvoie les objectifs, contraintes et critères de validation vers l'IA.
Implémenter rapidement les réponses, exécuter en masse les expériences, rechercher les solutions candidates et retourner les résultats. Une fois le problème et les critères d'évaluation clairs, l'IA peut fournir en très peu de temps une solution exécutable et vérifiable, faisant passer l'essai-erreur de ressource rare à opération courante.
Poser les questions clés, fixer les objectifs, contraintes et critères d'évaluation, juger si les preuves sont crédibles, accomplir la validation de la signification scientifique. Il faut pouvoir distinguer « les résultats qui s'exécutent » des « résultats fiables », identifier le sur-apprentissage, la fuite de données et la falsification d'indicateurs.
L'absence de l'un des deux côtés rend le système inefficace. Avec seulement l'IA, on obtient un grand nombre de résultats insignifiants ; avec seulement l'humain, la bande passante d'exploration est limitée. Prenons l'exploration évolutionnaire multi-objectifs : l'IA peut générer et exécuter automatiquement un grand nombre de solutions candidates, le chercheur décide si les objectifs d'optimisation, les contraintes et les indicateurs d'évaluation reflètent le problème réel, et sélectionne les directions scientifiquement crédibles et méritant d'être poursuivies.
Confier aussi les critères d'évaluation à l'IA pour qu'elle les décide automatiquement. Le système optimisera alors très efficacement un objectif qui ne reflète pas le vrai problème scientifique, produisant un grand nombre de résultats « apparemment raisonnables » mais dénués de sens. Toute décision qui change « ce qui compte comme bon » doit rester du côté humain.
Qui a choisi ce problème ? Qui a défini les critères d'évaluation ? Qui valide les conclusions ? Si les réponses aux trois questions pointent vers « moi », la répartition est saine ; si elles pointent toutes vers le modèle, le contrôle de la direction est déjà perdu.
L'IA élargit la bande passante, l'humain préserve le sens — ce qui est livré n'est pas plus de chiffres, mais des conclusions qui tiennent debout.
### Points clés de l'enseignement
Implémentation des réponses, exécution en masse des expériences, recherche de solutions candidates, retour des résultats, le cœur étant de comprimer le coût d'implémentation à presque zéro.
Définition du problème, choix de la direction, jugement des preuves, validation de la signification scientifique, le cœur étant de garder le coût de jugement entre ses propres mains.
L'IA élargit la bande passante d'exploration, l'humain contrôle la direction et les critères de validation.
Une fois que les critères d'évaluation peuvent être réécrits par un processus automatisé, l'optimisation se tourne discrètement vers « l'indicateur le plus facile à améliorer ». Déclarer la fonction objectif et les contraintes en lecture seule est la première barrière contre la dérive.
Ce n'est pas de produire plus de chiffres, mais que les résultats aient un vrai sens scientifique, alors la quantité a de la valeur.
### Couverture des mots-clés
Couche d'exécution IA, couche de contrôle humaine, boucle fermée de collaboration homme-machine, bande passante d'exploration, dérive des critères d'évaluation, fonction objectif en lecture seule, validation de la signification scientifique, trois questions d'auto-vérification.
### Traitement des exercices
La bonne réponse est « implémenter rapidement les réponses, exécuter en masse les expériences et rechercher les solutions candidates ». L'IA assume l'implémentation et l'exploration ; décider de la valeur du problème, juger de la crédibilité des preuves et valider la signification scientifique relèvent de la couche de contrôle humaine.
La bonne réponse est « parce que c'est seulement lorsque les résultats ont un vrai sens scientifique que la quantité a de la valeur ». La quantité vient de la bande passante d'exploration de l'IA, la valeur vient du jugement humain sur la signification scientifique.
La bonne réponse est « si les objectifs d'optimisation, les contraintes et les indicateurs d'évaluation reflètent le problème réel ». La génération de candidats et l'exécution en masse relèvent de la couche d'exécution IA ; le chercheur doit tenir la couche « ce qui compte comme bon ».
La bonne réponse est « permettre au chercheur de concentrer son attention sur le jugement de direction et les critères de validation ». L'IA élargit l'étendue, l'humain fournit la direction, les deux sont complémentaires et non substituables.
La bonne réponse est « le système optimisera efficacement un objectif qui ne reflète pas le vrai problème scientifique, produisant un grand nombre de résultats apparemment raisonnables mais dénués de sens ». Confier les critères d'évaluation au système, c'est laisser l'évalué rédiger lui-même l'examen ; toute décision qui change les critères d'évaluation doit conserver une validation humaine.
### Traitement des cas
1. La couche d'exécution IA comprend la génération de formulations candidates, l'exécution en masse de simulations, la récupération des indicateurs de performance et la mise à jour de la population, qui relèvent de l'implémentation et de l'exploration. La couche de contrôle humaine comprend le système de matériaux à rechercher, les objectifs de performance et les contraintes de procédé, si les indicateurs reflètent le vrai sens physique, si les candidats finaux méritent un investissement expérimental ultérieur, qui relèvent de la direction et du jugement. Le critère de division est : toute décision qui change « ce qui compte comme bon » doit rester du côté humain ; tout travail qui exécute un standard déjà fixé à plus grande échelle peut être confié à l'IA.
2. Si l'on laisse l'IA ajuster automatiquement les poids des indicateurs de performance par méta-optimisation, le risque principal est la dérive des critères d'évaluation : une fois que le système optimisé détient aussi le pouvoir de s'évaluer, il penchera vers « l'indicateur le plus facile à améliorer », les formulations à haut score produites pouvant être physiquement irréalisables ou sans valeur pratique, et paraissant souvent très raisonnables en surface, difficiles à identifier d'un coup d'œil. Les protections comprennent : déclarer la fonction objectif et les contraintes comme contrôlées et en lecture seule ; la méta-optimisation ne peut ajuster qu'un petit nombre d'hyperparamètres dans les limites spécifiées par l'humain, avec des bornes supérieure et inférieure ; mettre en place une passerelle de validation indépendante de l'objectif d'optimisation, comme des expériences de synthèse et de caractérisation réelles ; tout changement de poids doit être explicitement examiné par le chercheur et documenté, garantissant la traçabilité des décisions de direction.
### Activité en classe
Demander aux étudiants d'utiliser un exemple proche de leur expérience d'apprentissage ou de recherche, de reformuler la répartition « l'IA implémente les réponses, l'humain contrôle la direction », et d'expliquer la relation entre cet exemple et les trois questions d'auto-vérification.
### Vérification de compréhension
Couche d'exécution IA, couche de contrôle humaine, boucle fermée de collaboration homme-machine, dérive des indicateurs, trois questions d'auto-vérification. Compléter selon la réponse les mots-clés manquants.
### Indication de transition
Après avoir confirmé que les étudiants peuvent énoncer la relation centrale « l'IA élargit la bande passante d'exploration, l'humain contrôle la direction et les critères de validation », passer à la page suivante d'exemples, d'application ou de résumé.
### Principe fondamental : Code is cheap. Taste matters
*Page 13*
> **Objectif de la page :** Appréhender la philosophie Turing et l'objectif ultime d'EvoX de construire une infrastructure ouverte.
> **Objectif de la page**
>
> Comprendre le principe fondamental « Code is cheap. Taste matters », et appréhender la philosophie Turing et l'objectif ultime d'EvoX de construire une infrastructure ouverte.
**Points clés de l'enseignement**
- 1. Code is cheap est une description objective de l'état actuel de l'ingénierie. Lorsque le coût marginal de la génération et de l'implémentation de code est comprimé à presque zéro par les grands modèles et les bases tensorisées, le code n'est plus une barrière, ni une unité de mesure de la contribution scientifique. « Pouvoir s'exécuter » dégénère de résultat en prérequis, de réussite démontrable en ticket d'entrée pour continuer à travailler. 2. Taste matters est un repositionnement de la responsabilité humaine après la répartition homme-machine. Lorsque « l'IA implémente les réponses, l'humain contrôle la direction » devient la répartition par défaut, ce qui est réellement rare du côté humain, c'est la capacité à poser les questions clés, fixer les critères d'évaluation, juger la direction dans les conflits multi-objectifs. 3. Quatre points d'ancrage du goût. Le choix des problèmes — quel problème traiter détermine plus la limite supérieure que la méthode utilisée, une direction erronée rend l'implémentation rapide d'autant plus gaspilleuse
- La conception de la fonction objectif et des critères d'évaluation — une fois les indicateurs mal choisis, le modèle ne convergera efficacement que dans la mauvaise direction
- Les critères d'arbitrage des compromis multi-objectifs — les préférences entre performance, reproductibilité, maintenabilité, coût de déploiement doivent être explicitement déclarées, et non décidées à la dernière minute
- L'interprétation et l'attribution des résultats — distinguer « s'exécute par hasard » de « vraiment compris », et juger de quels changements provient réellement le gain. 4. Le goût doit pouvoir être vérifié. Le goût n'est pas une assertion esthétique, et ne peut pas être arbitré par l'ancienneté ou le vote. Il doit être falsifié par « entrer dans l'environnement réel — recevoir le retour réel » : écrire le jugement comme une hypothèse vérifiable, et le réviser par les échecs et succès dans des scénarios réels. Sinon, la discussion ne se réduit qu'à une dispute de préférences. 5. La signification de l'infrastructure est de donner un point d'ancrage au goût. L'objectif ultime d'EvoX est précisément de construire une infrastructure ouverte capable d'entrer dans l'environnement réel et de recevoir le retour réel. Une base ouverte, découplée, composable abaisse suffisamment le coût de déploiement, permettant aux bonnes idées d'entrer à faible coût dans des scénarios réels, d'être sélectionnées, déposées, héritées — la capacité de jugement a ainsi un support sur lequel être continuellement affinée. Code cheap ne signifie pas que l'ingénierie peut être omise. La passerelle de validation, la reproductibilité, la maintenabilité et la boucle de rétroaction constituent toujours de véritables seuils. Le goût se manifeste précisément dans le jugement d'arbitrage sur ces seuils : quel retour mérite d'être cru, quels indicateurs doivent être maintenus, quelles tentatives échouées doivent être rejetées plutôt que fusionnées. La valeur d'un mécanisme à la Genesis est aussi là — les modifications candidates ne peuvent devenir la base historique héritable par les exécutants suivants qu'après avoir passé la compilation, les tests, la vérification comportementale et la validation de niveau supérieur. Nous ne pouvons voir qu'à très courte distance devant nous, mais nous pouvons voir qu'il y a là beaucoup de choses à accomplir. Plutôt que de débattre de la forme concrète de la finalité de l'intelligence, mieux vaut construire d'abord une infrastructure ouverte capable d'entrer continuellement dans des scénarios réels et de recevoir le retour réel, pour que chaque cycle d'exploration puisse être vérifié et hérité. La page utilise un graphique de tendance montrant la baisse continue du coût d'implémentation et la hausse continue de la valeur du jugement, leur croisement formant un point d'inflexion, signifiant que la capacité de jugement devient la variable clé. Sous le graphique sont listés les mots-clés de la vision d'EvoX : ouvert, composable, retour réel, évolution continue.
**Traitement des exercices**
Cette page comporte cinq questions à choix multiples, vérifiant respectivement la compréhension de la signification d'ingénierie de Code is cheap, la direction du déplacement de la rareté, la falsifiabilité du goût, les quatre seuils d'ingénierie et l'objectif de l'infrastructure EvoX. Après avoir répondu, comparer avec les rétroactions, en distinguant surtout les « indicateurs du côté implémentation » et les « capacités du côté jugement » : nombre de lignes de code, taux de précision de complétion, popularité du framework, fréquence de commit ne peuvent pas remplacer le jugement sur « ce qui doit être accepté ». L'étude de cas demande à l'équipe de lister les maillons à investir en priorité et de concevoir un processus d'acceptation des modifications candidates qui teste le goût ;
Les directions de référence comprennent le choix des problèmes et la définition des objectifs, la conception de la fonction objectif et des critères d'évaluation, la passerelle de validation et les critères d'arbitrage multi-objectifs, l'interprétation et l'attribution des résultats, ainsi que la boucle fermée « modification candidate — test isolé — notation d'évaluation — validation de niveau supérieur — héritage historique — retour de rétroaction ».
**Vérification de compréhension**
Demander aléatoirement à un étudiant de résumer avec ses propres mots les points clés de cette page, l'enseignant complétant selon la réponse les mots-clés manquants, comme « pouvoir s'exécuter n'est qu'un ticket d'entrée », « le goût doit être falsifiable », « les quatre seuils d'ingénierie ».
> **Indication de transition**
>
> Cette page prolonge la répartition « l'IA implémente les réponses, l'humain contrôle la direction » de la page précédente, en donnant le principe fondamental qui soutient cette répartition ; la page suivante passe à la pratique de guider l'IA par le dialogue pour accomplir une tâche EvoX.
### Activité en classe : guider l'IA par le dialogue pour accomplir une tâche EvoX
*Page 14*
> **Objectif de la page :** Valider par la pratique le flux de tâche d'optimisation de base dans un environnement AI Native.
**Activité en classe**
Guider l'IA par le dialogue pour accomplir une tâche EvoX
> **Objectif de la page**
>
> Accomplir dans un vrai environnement EvoX la boucle minimale « invite → génération → exécution → validation ». Le point important n'est pas d'obtenir seulement un code lisible, mais de valider le mode de travail AI Native : l'humain donne la direction, l'IA fournit l'implémentation, l'humain valide.
> **Ordre de présentation**
>
> D'abord expliquer la tâche de l'activité, puis décomposer comment construire l'invite, ensuite expliquer comment valider les résultats d'exécution, enfin traiter les résultats non satisfaisants par l'ajout de contraintes, et revenir à la répartition homme-machine.
**Points clés de l'enseignement**
- Utiliser une invite conversationnelle pour piloter l'IA dans la génération et l'exécution d'une tâche d'optimisation EvoX de base, puis vérifier la sortie comme un ingénieur. Problème d'optimisation et fonction objectif (par exemple minimisation de la fonction Rastrigin), espace de recherche et dimension (par exemple 10 dimensions et plage de valeurs), algorithme ou opérateur (par exemple algorithme DE, opérateurs de croisement et de mutation), taille de population et nombre d'itérations (par exemple population 128, 200 générations), plateforme de calcul (CPU ou tensorisation GPU), sortie attendue (valeur optimale, courbe de convergence, journal d'exécution). Trop grossier déclenche la configuration par défaut, difficile de juger si cela correspond à l'intention
- Trop fin dégénère en codage manuel. L'approche appropriée est de préciser les contraintes et les critères de validation, en laissant les détails d'implémentation à l'IA. Par exemple, spécifier le problème, l'algorithme, la taille de population et le nombre d'itérations, sans avoir à préciser comment appeler concrètement l'interface. S'il s'exécute réellement, et pas seulement donne du code, on peut consulter le journal du terminal et le temps d'exécution
- Si la courbe de convergence est monotone vers l'optimum et sans oscillation anormale
- Si la valeur optimale correspond à l'ordre de grandeur connu du problème, par exemple l'optimum global de la fonction Rastrigin étant 0
- Si la graine aléatoire et la configuration sont reproductibles, une réexécution avec graine fixe devant donner des résultats identiques ou proches. Lorsque les résultats ne sont pas à la hauteur, ajouter en priorité des contraintes par le dialogue, par exemple « relancer avec seed=42 fixe et donner la moyenne et variance de trois répétitions », observer si l'IA peut corriger par itération plutôt que réécrire. L'humain est responsable de la définition du problème, des critères d'indicateurs et du jugement des résultats
- L'IA est responsable du choix des interfaces, de l'organisation du code et de l'exécution du débogage. Ne faire que la validation du flux de la tâche de base, sans dérouler les thèmes ultérieurs comme l'évolution bi-niveau MetaDE, les compromis multi-objectifs ou le multi-Agent Genesis. Exemple d'invite de référence : « Utiliser EvoX pour résoudre le minimum de la fonction Rastrigin (10 dimensions), avec l'algorithme DE, population 128, 200 générations, backend de tensorisation GPU, seed=42 fixe
- Veuillez exécuter directement et retourner la fitness optimale, la courbe de convergence et le journal d'exécution. » S'il s'exécute réellement, si la forme de la courbe de convergence est raisonnable, si la valeur optimale est proche de 0, si les résultats de réexécutions sont cohérents.
> **Indices d'exercices**
>
> - Pas besoin de spécifier le nombre exact de lignes de code de l'implémentation de l'algorithme
> - La preuve clé de l'exécution réelle est le journal d'itération du terminal et la courbe de convergence
> - En cas de mauvais résultats, le plus efficace est d'ajouter des contraintes, par exemple fixer la graine aléatoire et réexécuter
> - L'humain est principalement responsable de la définition du problème, des critères d'indicateurs et du jugement des résultats
> - La granularité de l'invite doit préciser les contraintes et les critères de validation, en laissant les détails d'implémentation à l'IA. Si l'étudiant répond mal, on peut le guider vers les trois endroits « éléments d'invite », « liste de vérification d'exécution », « répartition homme-machine » pour trouver des preuves. Fonction Ackley 20 dimensions, CMA-ES, population 64, 500 itérations, CPU, seed=123 fixe, si la courbe oscille fortement en début de phase et la valeur optimale est bien supérieure à 0, les causes possibles comprennent un pas trop grand, une diversité de population insuffisante, une inadéquation entre paramètres d'algorithme et dimension du problème, des fluctuations d'exploration initiale dues à la graine aléatoire, etc. Les contraintes ajoutées peuvent fixer la seed et réexécuter trois fois, calculer moyenne et variance
> - Demander la sortie de la variation de la valeur optimale par génération
> - Ajuster le pas ou la taille de population et relancer. Lors de la validation, outre la valeur optimale, il faut vérifier si l'exécution est réelle, la forme de la courbe de convergence, l'ordre de grandeur de la valeur optimale, la reproductibilité, la rationalité du temps d'exécution. On peut faire travailler les étudiants en groupes avec répartition des rôles, une personne responsable de la construction de l'invite, une de l'observation du journal d'exécution et de la courbe de convergence, une de la conclusion de validation par rapport à la liste de vérification
> - Enregistrer un échec ou un résultat non satisfaisant, et tenter de l'améliorer par ajout de contraintes.
**Vérification de compréhension**
Demander aléatoirement à un étudiant de résumer avec ses propres mots les points clés de cette page, l'enseignant complétant selon la réponse les éléments d'invite, les quatre questions de validation et le principe d'itération plutôt que de réécriture.
> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer la relation centrale « l'humain donne la direction, l'IA fournit l'implémentation, l'humain valide », passer à la page suivante d'exemples, d'application ou de résumé.
### Résumé du cours : workflow AI native et goût scientifique
*Page 15*
> **Objectif de la page :** Résumer le workflow AI native d'EvoX et la pensée critique dans la collaboration homme-machine.
> **Objectif de la page**
>
> Cette page, en conclusion de tout le cours, converge le workflow AI native d'EvoX et le goût scientifique irremplaçable du chercheur vers une même conclusion : lorsque les outils compriment à l'extrême le coût de « l'implémentation des réponses », « définir ce qui vaut la peine d'être fait, juger quels résultats sont crédibles » devient la ligne de partage de la valeur scientifique.
> **Ordre de présentation**
>
> À gauche, le workflow AI native, partant du dialogue en langage naturel, accomplissant la configuration de l'environnement, la construction du problème et des contraintes, le pilotage de l'exécution évolutive et de l'exploration en masse, l'analyse visuelle des résultats et le bilan ; à droite, le goût scientifique humain, responsable de la définition du problème, de la fixation des objectifs et contraintes, des compromis multi-objectifs, du jugement de la crédibilité des résultats et de la direction d'évolution.
>
> L'IA implémente les réponses, l'humain contrôle la direction ; en une phrase : Code is cheap. Taste matters.
>
> Le workflow comprime le coût du chemin de l'idée à la première expérience exécutable ; la responsabilité monte avec la commodité ; le goût scientifique a des points d'ancrage identifiables ; la pensée critique a quatre questions structurées ; l'évolution continue au niveau projet et système nécessite encore que l'humain fixe les critères de validation et la direction d'évolution.
>
> Ce qui est rare n'est pas le code, mais le jugement ; la maîtrise du workflow détermine la vitesse à laquelle on peut courir, le goût scientifique et la pensée critique déterminent si la direction est correcte.
**Points clés de l'enseignement**
- Le dialogue en langage naturel comme entrée pilote l'expérience EvoX sur toute la chaîne. Ce qui est réduit, c'est le coût du chemin entre « l'idée » et « la première expérience exécutable », pas l'expérience elle-même, et cela ne remplace pas la définition du problème et le jugement des résultats. Le squelette de script, les interfaces de paramètres et le code de tracé peuvent se former plus rapidement, le chercheur obtient donc une fréquence d'itération expérimentale plus élevée. Plus les outils sont faciles à utiliser, plus la responsabilité humaine est claire. L'automatisation transfère la charge d'exécution, pas la responsabilité de jugement. Lorsque l'IA produit des solutions candidates en quelques minutes, « les compromis multi-objectifs sont-ils raisonnables », « l'amélioration des indicateurs est-elle crédible », « quelle direction explorer ensuite » doivent encore être répondus par le chercheur. La commodité augmente le débit d'essai-erreur, et amplifie également la vitesse de propagation des mauvaises décisions. La définition du problème détermine quoi étudier et quoi abandonner
- La fixation des objectifs et contraintes traduit une intention floue en fonction objectif optimisable et contraintes dures
- Les compromis multi-objectifs donnent des préférences défendables entre vitesse de convergence, diversité, robustesse et coût
- Le jugement de la crédibilité des résultats distingue « ça s'exécute » de « la conclusion tient debout »
- La fixation de la direction d'évolution détermine où explorer au prochain cycle, plutôt que d'accepter passivement l'optimum actuel. Ce ne sont pas des problèmes de calcul, mais des problèmes de valeur et de jugement. L'hypothèse est-elle valide ? L'IA a peut-être silencieusement complété des prémisses non dites
- Les indicateurs sont-ils mal interprétés ? L'amélioration peut provenir d'une fuite de données, d'un changement de critère d'évaluation ou d'un sur-apprentissage
- Les résultats sont-ils reproductibles ? Graine aléatoire, ordonnancement parallèle, versions de dépendances affectent tous la reproductibilité
- Les frontières et modes d'échec sont-ils vérifiés ? Tiennent-ils encore sous contraintes extrêmes, données sparses ou haute dimension. L'IA est responsable de l'implémentation et de l'exploration en masse, l'humain de la direction et du jugement de valeur. Quel que soit le degré d'automatisation, les critères de validation et la direction d'évolution doivent encore être fixés par l'humain
- Une absence prolongée de ce jugement fait que les lacunes de goût sont amplifiées par le temps en dette technique difficile à rembourser. L'IA implémente les réponses, l'humain contrôle la direction. Avant chaque délégation de tâche à l'IA, réfléchir d'abord à ce que sont les critères de validation.
**Couverture des mots-clés**
- Workflow AI native, goût scientifique, pensée critique, répartition homme-machine, charge d'exécution, responsabilité de jugement, définition du problème, objectifs et contraintes, compromis multi-objectifs, crédibilité des résultats, direction d'évolution, dette technique, Code is cheap. Taste matters.
> **Indices d'exercices**
>
> - Les exercices de cette page tournent autour de la compression des coûts, du transfert de responsabilité, des points d'ancrage du goût scientifique, de la vérification critique et des risques de l'évolution continue. Lors du traitement, laisser d'abord les étudiants juger « ce qui est remplacé par l'automatisation, ce qui ne l'est pas », puis revenir au cadre en deux étapes « d'abord faire tourner, ensuite valider ».
**Traitement des exercices**
L'outil comprime le coût d'implémentation de l'idée à la première expérience exécutable, mais ne change pas la difficulté de la définition du problème et du jugement des résultats. Lors de la rétroaction, rappeler de distinguer « charge d'exécution » et « responsabilité de jugement ».
La vitesse de production augmente, rendant les conclusions non vérifiées plus facilement prises pour des résultats confirmés et diffusées. Lors de la rétroaction, souligner que la commodité augmente le débit d'essai-erreur, et amplifie proportionnellement la vitesse de propagation des mauvaises décisions.
Définition du problème, fixation des objectifs et contraintes, compromis multi-objectifs, jugement de la crédibilité des résultats, fixation de la direction d'évolution. Lors de la rétroaction, expliquer que ces maillons sont des problèmes de valeur et de jugement, pas de calcul.
Les hypothèses implicites que l'IA a silencieusement complétées sans les énoncer, et si les critères d'évaluation ont été modifiés. Lors de la rétroaction, indiquer que la vérification critique porte sur les hypothèses, les critères d'indicateurs, la reproductibilité et les conditions limites, pas sur la forme de présentation.
Les lacunes de goût sont continuellement amplifiées par le temps, s'accumulant en dette technique difficile à rembourser. Lors de la rétroaction, réaffirmer que l'automatisation ne peut garantir que « ça s'exécute », pas que « la direction est correcte ».
Face aux solutions candidates et au classement recommandé par l'IA, vérifier d'abord si les objectifs et contraintes correspondent aux vrais besoins métier, puis examiner les critères d'indicateurs et la baseline, inspecter la distribution et la robustesse des solutions sur le front de compromis, faire des tests de frontière et de mode d'échec, et fixer la graine aléatoire, les versions de dépendances et la configuration expérimentale pour garantir la reproduction. Si l'on décide entièrement la solution principale selon le classement recommandé par l'IA et que l'on avance automatiquement la direction, le risque est d'externaliser le jugement de valeur qu'est le compromis multi-objectifs, la mauvaise direction étant répétitivement héritée par les itérations ultérieures, et « ça s'exécute » étant pris à tort pour « la direction est correcte ». Lors de la refonte de la répartition, laisser l'IA responsable de l'implémentation et de l'exploration en masse, l'humain fixant explicitement les poids d'objectifs et les contraintes dures, définissant les critères de validation, conservant le droit de révision et de veto, et spécifiant les hypothèses et méthodes de vérification pour le prochain cycle d'exploration.
**Activité en classe**
Demander aux étudiants de reformuler avec leurs propres mots les « quatre questions d'auto-vérification », et de donner un exemple proche de leur expérience d'apprentissage ou de recherche, expliquant comment sauter la vérification conduit à prendre à tort « ça s'exécute » pour « ça tient debout ».
**Vérification de compréhension**
Demander aléatoirement à un étudiant de résumer les points clés de cette page, et de répondre « la maîtrise du workflow détermine quoi, le goût scientifique et la pensée critique déterminent quoi ». L'enseignant complète selon la réponse les relations manquantes : le premier détermine la vitesse, les seconds déterminent la direction et la valeur.
> **Indication de transition**
>
> Après avoir confirmé que les étudiants distinguent « ça s'exécute » de « ça tient debout », « implémenter les réponses » de « contrôler la direction », passer à la page suivante d'exemples, d'application ou de résumé.
### Annexe et entrées de la communauté open source
*Page 16*
> **Objectif de la page :** Obtenir les canaux de communication officiels d'EvoX et les ressources d'apprentissage continu.
> **Objectif de la page**
>
> Cette page, en annexe du cours, regroupe les entrées de la communauté officielle d'EvoX pour le système d'évolution intelligente et la pratique de recherche AI Native, et indique les canaux d'apprentissage continu, de questions et de participation à l'exploration de pointe après le cours.
**Points clés de l'enseignement**
- Distinguer d'abord les deux entrées officielles. Le compte officiel WeChat est « 演化机器智能 » (Intelligence des machines évolutionnaires), utilisé pour publier les mises à jour du cours, les articles techniques, les annonces d'activités et les interprétations de pointe, adapté au suivi systématique de la direction de l'intelligence évolutionnaire. Le groupe QQ officiel porte le numéro 297969717, utilisé pour les questions en temps réel, les discussions et les échanges entre pairs, facilitant l'obtention de retours sur des problèmes concrets. Les deux pointent vers « la participation continue à l'exploration de pointe de l'intelligence évolutionnaire », ne remplaçant pas l'apprentissage en classe, mais formant un cycle « apprendre — pratiquer — échanger — réapprendre ». Après avoir rejoint, parcourir d'abord les annonces épinglées et l'historique des messages, comprendre les règles et les ressources existantes, puis participer aux discussions en lien avec sa direction de recherche. Lors des questions, fournir un contexte clair, des questions précises et les méthodes déjà essayées
- Participer activement aux discussions des autres approfondit aussi la compréhension. Consulter régulièrement les contenus de pointe, transformer les ressources de la communauté en capacité de recherche. Les exercices de cette page tournent autour de trois faits et deux attitudes. Le nom du compte officiel est « 演化机器智能 »
- Le numéro du groupe QQ est 297969717
- Le but des entrées communautaires est de fournir des canaux d'apprentissage continu, de questions et d'exploration de pointe après le cours
- Pour obtenir des ressources après le cours, il faut suivre le compte officiel et rejoindre le groupe QQ via les entrées officielles
- L'utilisation de la communauté doit être active : poser des questions, partager et participer aux discussions, plutôt que ne l'utiliser qu'avant les examens, rejoindre des groupes non officiels ou rester en silence. L'étude de cas peut guider les étudiants pour écrire les deux canaux officiels, et donner au moins deux conseils d'apprentissage continu, comme suivre les mises à jour du compte officiel, poser des questions et échanger dans le groupe, suivre l'actualité de pointe, participer à des projets open source ou des activités en ligne, appliquer ce qui a été appris à la recherche réelle et partager son expérience.
**Vérification de compréhension**
Demander aux étudiants d'expliquer avec leurs propres mots à quoi servent respectivement les deux entrées officielles, et de reformuler la bonne pratique après avoir rejoint la communauté. Si les étudiants ne retiennent que les noms sans pouvoir expliquer les usages, les inviter à revoir la comparaison des deux entrées sur la page.
> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer la relation entre les entrées officielles et le cycle d'apprentissage continu, passer à la page suivante.
--- FIN DU TEXTE SOURCE ---