# Corpus de recherche Eternity II (eternity2.dev) — texte intégral > Toutes les pages de recherche traduites en français, mises bout à bout. Miroir lisible par machine du wiki à https://eternity2.dev/fr/research/. La carte avec les liens se trouve à https://eternity2.dev/fr/llms.txt. --- # Recherche > Le wiki de recherche ouvert de la communauté Eternity II : pourquoi le casse-tête est si difficile, tout ce qu'il faut pour construire un solveur, et les carnets ouverts des chercheurs : records, méthodes, expériences et impasses, le tout sourcé et reproductible. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/ - Mise à jour: 2026-07-21 --- > **Note** > > Ce wiki est en cours de construction : le site est jeune et absorbe peu à peu des années de recherche communautaire. S'il manque quelque chose que vous connaissez, la liste de diffusion ci-dessous est l'endroit indiqué pour le signaler. Ce wiki s'adresse à celles et ceux qui veulent vraiment le résoudre. Tous ceux qui se sont attaqués à Eternity II ont emprunté l'une de neuf routes, depuis la modélisation de sa résistance jusqu'à l'assaut par la force matérielle, en passant par l'élagage de la recherche et la construction progressive des plateaux. Choisissez la route qui vous intéresse ; chacune ouvre sur tout ce que le wiki en sait, puisé aussi bien dans la théorie que dans les guides de construction de solveurs et dans le carnet de laboratoire. ## Vous débutez ? Commencez par celles-ci Cinq pages, dans l'ordre, vous mènent de ne jamais avoir entendu parler du casse-tête à choisir votre propre cible : 1. **[Pourquoi il résiste](/fr/research/why/)** : les murs structurels qui rendent Eternity II difficile, pour savoir à quoi vous vous mesurez. 2. **[L'état de l'art](/fr/research/records/)** : qui détient le meilleur plateau et à quelle distance il se trouve d'une solution complète. 3. **[Faire tourner le code](/fr/research/build/toolkit/)** : le kit de démarrage qui score, génère et évalue déjà, pour que vous n'écriviez que le solveur. 4. **[Choisir une cible](/fr/research/open-problems/)** : la frontière ouverte, une ligne par angle qui vaut encore une tentative, étiquetée par son abordabilité. 5. **[Contribuer](/fr/research/contribute/)** : comment consigner ce que vous trouvez, crédité à votre nom, à côté du reste. > **[Interactive: RootsDiagram]** Rendered on the canonical page (link above); not shown in this markdown export. Vous préférez parcourir par mode de lecture plutôt que par méthode ? Le wiki se divise en quatre :
- [Pourquoi c'est difficile](/fr/research/why/) — Le design réglé pour résister à l'astuce, et les murs structurels (rigidité, entropie, motifs interdits) qui expliquent l'écart entre le meilleur plateau connu et une solution complète. - [Construire un solveur](/fr/research/build/) — Les données de validation, la littérature classée par utilité, les méthodes derrière les records, les impasses, et comment faire tourner le code vous-même. - [Le laboratoire](/fr/research/lab/) — Le carnet ouvert : les résultats structurels et les expériences de recherche nommées, conçues pour attaquer le casse-tête, chacune créditée à son auteur et reproductible à partir des sources. - [Histoire & communauté](/fr/research/community/) — Le record et les gens qui l'ont bâti : deux décennies racontées comme une histoire, les plateaux records eux-mêmes, les détenteurs de records et les théoriciens, et les articles.
Ou parcourez plutôt par méthode : les neuf routes de la colonne de gauche sont chacune un carrefour rassemblant tous les articles sur ce thème. ## Le rayon de référence Les consultations et la frontière que vous solliciterez encore et encore en lisant ou en construisant :
- [Référence](/fr/research/reference/) — Les décomptes exacts (pièces, couleurs, arêtes) pour vérifier votre propre code d'appariement d'arêtes et de contraintes. - [Glossaire](/fr/research/glossary/) — Chaque terme sur lequel le wiki s'appuie, défini une bonne fois : le jargon de la communauté, les mots chargés de l'informatique, et la notation dans laquelle les plateaux sont écrits. - [Problèmes ouverts](/fr/research/open-problems/) — La frontière ouverte sur un seul tableau : chaque angle qui vaut encore une tentative, le mur qu'il attaque, et où la dernière tentative s'est arrêtée.
L'histoire du casse-tête, ses records et les gens qui les ont poursuivis vivent désormais ensemble sous [Histoire & communauté](/fr/research/community/). ## Infrastructure communautaire La conversation de recherche se déroule dans quelques lieux de longue date :
- [Visualiseur de plateaux e2.bucas.name](https://e2.bucas.name) — Le visualiseur GPL de Jef Bucas ; son format d'URL est la lingua franca de la communauté (et ce site le parle nativement). - [Discord Eternity II](https://discord.gg/Ny5xs3q8w) — Un serveur actif où les amateurs partagent leurs runs, leurs records et leur code, en temps réel. - [groups.io/g/eternity2](https://groups.io/g/eternity2) — La liste de diffusion active : records, techniques, et plus de 15 ans de folklore accumulé.
## Pages de cette section - [Construire un solveur](https://eternity2.dev/fr/research/build/) — Le coin praticien du wiki : les données de validation pour vérifier votre code, la littérature classée par utilité, la chronologie du record et les méthodes qui la sous-tendent, les impasses, et comment exécuter le code vous-même. - [Histoire & communauté](https://eternity2.dev/fr/research/community/) — Le record et les personnes qui l'ont bâti : deux décennies d'Eternity II racontées comme une histoire, les grilles record elles-mêmes, les détenteurs du record et les théoriciens, la littérature académique, et comment ajouter votre propre travail au wiki. - [Contribuez vos recherches](https://eternity2.dev/fr/research/contribute/) — Ce wiki est le foyer de recherche de la communauté, et il y a de la place pour votre travail. Trois façons de le faire publier, du message sur la liste de diffusion à la pull request, plus le petit jeu de règles maison qui garde chaque page digne de confiance. - [Histoire : les grandes étapes](https://eternity2.dev/fr/research/history/) — L'histoire d'Eternity II en un coup d'œil, de la liste de diffusion fondée en 2000 au record de 470 qui tient toujours. Une chronologie parcourable des tournants, chacun renvoyant à l'histoire complète en deux parties et au message où il s'est produit. - [Le laboratoire](https://eternity2.dev/fr/research/lab/) — Le carnet ouvert du wiki : résultats structurels et expériences de recherche nommées, chacune attribuée au chercheur qui l'a menée et reproductible depuis les sources. Un coin de la recherche plus large de la communauté. - [Problèmes ouverts](https://eternity2.dev/fr/research/open-problems/) — La frontière ouverte d'Eternity II réunie au même endroit : chaque angle qui vaut encore une tentative, le mur qu'il attaque, ce qui a déjà été essayé et où cela s'est arrêté, et s'il s'agit d'une cible abordable pour un débutant ou d'un objectif difficile et bien cartographié. - [Articles](https://eternity2.dev/fr/research/papers/) — La littérature académique sur Eternity II et les casse-têtes à raccordement d'arêtes, tirée des notes de recherche du projet et de la liste de lectures de la communauté, classée selon l'utilité réelle de chaque article lorsqu'on cherche à écrire un solveur. - [Le who's who de la recherche sur E2](https://eternity2.dev/fr/research/people/) — Deux décennies de recherche sur Eternity II ont été menées par des personnes identifiées, sur une liste de diffusion. Cette page en est la galerie : qui elles sont, ce que chacune a apporté, et où le lire dans leurs propres mots. Un remerciement autant qu'un index. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Nombres de référence](https://eternity2.dev/fr/research/reference/) — Dénombrements exacts du nombre de façons valides de remplir un petit bloc à une position donnée du plateau officiel d'Eternity II, sous des règles de plus en plus contraintes : des nombres sûrs pour vérifier le code d'appariement des bords et de contraintes de votre solveur. - [Pourquoi c'est difficile](https://eternity2.dev/fr/research/why/) — Eternity II n'est pas difficile par accident. Le casse-tête a été conçu pour résister à l'ingéniosité, et les murs structurels mesurables (rigidité, entropie, motifs interdits) expliquent pourquoi aucune recherche, si ingénieuse soit-elle, n'a atteint la fin. --- # Construire un solveur > Le coin praticien du wiki : les données de validation pour vérifier votre code, la littérature classée par utilité, la chronologie du record et les méthodes qui la sous-tendent, les impasses, et comment exécuter le code vous-même. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/ - Mise à jour: 2026-07-21 --- Le coin praticien. Des données de validation pour confronter votre code, la littérature classée par utilité, la chronologie du record et les méthodes qui la sous-tendent, plus les impasses pour ne pas perdre un mois sur une approche dont on prouve qu'elle ne peut pas aboutir. ## Par où commencer 1. **[La boîte à outils du bâtisseur](/fr/research/build/toolkit/)** est l'unique étape qui vous mène à du code qui tourne : un espace de travail Rust prêt à l'emploi qui score, génère, convertit et mesure déjà, avec une boucle résoudre→balayer→comparer, pour que vous n'écriviez que le solveur. Configurez-le dans votre agent de code en une ligne, ou générez des plateaux dans le navigateur. Commencez ici. 2. **[Une carte de toutes les approches connues](/fr/research/build/approaches-map/)** est le panorama en une page : chaque famille d'attaque d'Eternity II, ce que chacune a atteint, et où elle bute. L'endroit où s'orienter avant de plonger. 3. **[Les techniques](/fr/research/build/techniques/)** sont l'étagère des techniques : les algorithmes et les idées d'élagage que l'on retrouve dans tout solveur sérieux, chacun avec son coût et ce qu'il a réellement rapporté sur ce puzzle. 4. **[Catalogue des solveurs](/fr/research/build/solvers/)** montre comment les moteurs du record assemblent ces briques, du 467 de Verhaard au 470 de Blackwood. 5. **[Nombres de référence](/fr/research/reference/)** et les **[faits établis](/fr/research/build/known-facts/)** vous donnent les comptages exacts pour vérifier votre propre code d'appariement de bords et de contraintes. 6. **[Impasses](/fr/research/build/dead-ends/)** recense les approches qui semblaient prometteuses mais dont on prouve qu'elles ne font pas bouger le score, pour que vous puissiez les écarter. 7. **[Exécuter le code vous-même](/fr/research/build/run-it-yourself/)** explique comment compiler et lancer le code propre à ce projet. La [chronologie du record](/fr/research/records/) et l'[histoire](/fr/research/community/hunt/) en deux parties retracent comment la communauté est passée des premiers plateaux partiels au 470 d'aujourd'hui. ## Pages de cette section - [La boîte à outils du bâtisseur](https://eternity2.dev/fr/research/build/toolkit/) — Un kit de démarrage Rust prêt à l'emploi pour construire votre propre solveur Eternity II : scorer, générer des plateaux au vrai équilibre des couleurs, générer des lots avec indices épinglés, convertir tous les formats, mesurer les performances, et une boucle résoudre→balayer→comparer, où vous n'écrivez que le solveur. Plus une configuration en une ligne pour les agents de code, et un générateur de plateaux directement dans le navigateur. - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les formats de plateau et de puzzle, couchés sur le papier](https://eternity2.dev/fr/research/build/formats/) — Tous les formats sous lesquels un plateau ou un puzzle Eternity II circule sur ce site et dans la communauté : la chaîne de lettres board_edges et la liste d'indices hints, e2pieces.txt, le CSV de puzzle, le JSON Puzzle du site, et l'URL de visualiseur, avec les règles exactes au niveau de l'octet (comment la bordure grise est encodée dans chacun) et, surtout, ce que chaque format sait et ne sait pas restituer. - [Faits et chiffres établis](https://eternity2.dev/fr/research/build/known-facts/) — Les chiffres que tout chercheur sur Eternity II finit par redémontrer, rassemblés au même endroit avec leur provenance : la définition du puzzle, le placement des indices, les conventions de score, le tableau des records, la taille de l'espace de recherche et les comptages structurels. - [Les benchmarks de la communauté](https://eternity2.dev/fr/research/build/benchmarks/) — Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. - [La boîte à outils de la communauté, 2007-2026](https://eternity2.dev/fr/research/build/tooling/) — Dix-neuf ans de logiciels communautaires pour Eternity II (interfaces de placement manuel, éditeurs, solveurs publics, générateurs et visualiseurs), plus la couche plus discrète qui les a rendus interopérables : e2pieces.txt, les sommes de contrôle CRC-16 et le format plateau-dans-une-URL devenu la lingua franca. Un recensement de référence, chaque outil rattaché au message qui l'a annoncé. - [Les quatre puzzles-indices](https://eternity2.dev/fr/research/build/clue-puzzles/) — Tomy a vendu quatre petits puzzles compagnons pour Eternity II : résolvez-en un, soumettez la solution, et le site officiel révélait la position d'une pièce sur le plateau principal. Ce qu'était chaque puzzle, le vérificateur en ligne défaillant, le marché gris d'eBay, pourquoi les puzzles 5 et 6 ne sont jamais venus, et la seconde vie des puzzles-indices comme cas de test pour la théorie des complexes et comme jeux de pièces donneuses. - [Les variantes et les revendications qui y prospèrent](https://eternity2.dev/fr/research/build/variants/) — Tous les « Eternity II » qui ne sont pas le vrai puzzle : la variante Marathon de TopCoder et le 468 non résolu de Takahashi, le 480/480 sans cadre de McGavin, les plateaux à jeux mélangés, le défi sans amorce et la mise en quarantaine des revendications, de l'avertissement de 2007 sur les jeux fantômes à l'éthique communautaire de vérification à connaissance nulle. Se termine par une liste de contrôle pour énoncer un score correctement. - [Comment cherchent les solveurs record](https://eternity2.dev/fr/research/build/solvers/) — Comment cherchent réellement les solveurs qui détiennent les records. Ce sont tous, au fond, des backtrackers en profondeur d'abord ; ce qui les distingue, c'est l'ordre dans lequel ils essaient les choses et la manière dont ils assouplissent les règles à l'approche de la fin. - [Réduire la recherche](https://eternity2.dev/fr/research/build/reduce/) — Tout ce qui élimine les états sans espoir avant que la recherche n'y perde du temps : propagation jusqu'au point fixe, filtre d'appariement all-different, no-goods appris et invariant de glissement des bords. - [Retour sur trace](https://eternity2.dev/fr/research/build/backtracking/) — La recherche en profondeur d'abord, prise au sérieux. L'ordre dans lequel un solveur visite les cases est son unique choix libre et fait varier la taille de l'arbre de plusieurs ordres de grandeur ; les redémarrages transforment un temps d'exécution à queue lourde en portefeuille. C'est la famille qui se cache derrière chaque backtracker record. - [Aller plus vite](https://eternity2.dev/fr/research/build/faster/) — Le débit brut : l'artisanat sous l'algorithme (tables de correspondance, structures dimensionnées pour le cache, code généré) et la répartition du travail sur de nombreuses machines. C'est ce qui décide si un nœud coûte 26 cycles ou 2 600, et c'est la démonstration la plus nette que la vitesse seule ne déplace pas le mur. - [Construire les plateaux par assemblage](https://eternity2.dev/fr/research/build/construct/) — Construire un plateau à haut score à partir d'une grille vide plutôt que de creuser par backtracking : la recherche en faisceau garde en vie les meilleurs plateaux partiels et les fait croître case par case. Le cheval de bataille des constructeurs partant de zéro de ce projet, et une illustration nette de la raison pour laquelle la seule largeur finit par caler dans les profondeurs de l'intérieur. - [Apprendre des grilles fortes](https://eternity2.dev/fr/research/build/learning/) — La plupart des attaques contre Eternity II cherchent à partir de zéro. Une famille distincte fait l'inverse : elle fouille le corpus des grilles déjà trouvées pour en extraire de la structure, puis réinjecte cette structure dans la recherche. Priors de position, ordonnancement appris des coups, fouille d'anti-motifs, décodage de records, et le mode de défaillance où un signal appris s'effondre. - [Recherche locale](https://eternity2.dev/fr/research/build/local-search/) — Partir d'un plateau complet mais imparfait et l'améliorer par des mouvements : destruction-réparation, recuit et trempe, recombinaison évolutionnaire. Les polisseurs les plus fiables du site, et les démonstrations les plus nettes du mur de rigidité, où chacun d'eux s'arrête à la même hauteur. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. - [Méthodes exactes](https://eternity2.dev/fr/research/build/exact/) — Des solveurs capables de prouver : encodages SAT et CSP, programmation en nombres entiers et ses relaxations, couverture exacte, rencontre au milieu et cartes de projection itérées. Les méthodes complètes s'enlisent sur le plateau entier, mais leurs verdicts valent leur pesant d'or comme preuves d'impossibilité sur des sous-plateaux. - [Analyse](https://eternity2.dev/fr/research/build/analysis/) — Ces méthodes ne cherchent pas à résoudre le casse-tête : elles le mesurent, et c'est ainsi que la communauté sait où se dressent les murs. Les arguments de parité fournissent des preuves d'impossibilité en une seule passe ; le comptage de solutions fixe le nombre de solutions complètes à un facteur deux près, sans que personne n'en ait jamais vu une seule. - [GPU et matériel](https://eternity2.dev/fr/research/build/hardware/) — Jeter du silicium contre le mur : portages GPU, pipelines FPGA, balayages distribués et l'éternelle proposition quantique. Voici le bilan de ce que chacun a réellement apporté, et pourquoi le mur qu'ils rencontrent tient à la mémoire et à la structure, non à l'arithmétique. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Le jeu de données](https://eternity2.dev/fr/research/build/dataset/) — Un jeu de données public sous licence CC0 pour Eternity II, en deux volets : quatorze instances de référence à résoudre, et un corpus de 7 658 plateaux forts distincts dont on peut s'inspirer. Chaque score est recalculé à partir du plateau lui-même, et le corpus est vérifié comme réellement varié, plutôt que mille copies d'un même plateau. - [L'exécuter soi-même](https://eternity2.dev/fr/research/build/run-it-yourself/) — L'ensemble du site, le moteur et chaque résultat de cette section tournent depuis un seul dépôt. Voici comment le lancer, recompiler le moteur WebAssembly et reproduire les chiffres. --- # Analyse > Ces méthodes ne cherchent pas à résoudre le casse-tête : elles le mesurent, et c'est ainsi que la communauté sait où se dressent les murs. Les arguments de parité fournissent des preuves d'impossibilité en une seule passe ; le comptage de solutions fixe le nombre de solutions complètes à un facteur deux près, sans que personne n'en ait jamais vu une seule. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/analysis/ - Mise à jour: 2026-07-13 --- Ces méthodes ne cherchent pas à résoudre le casse-tête : elles le mesurent, et c'est ainsi que la communauté sait où se dressent les murs. Les arguments de parité fournissent des preuves d'impossibilité en une seule passe ; le comptage de solutions fixe le nombre de solutions complètes à un facteur deux près, sans que personne n'en ait jamais vu une seule. Les pages ci-dessous procèdent technique par technique : ce qu'est chacune en une ligne, ce qu'elle a réellement atteint sur le vrai plateau 16×16, où elle s'arrête, et les expériences et mesures qui l'étayent. Pour embrasser tout le territoire d'un coup, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). ## Pages de cette section - [Arguments de parité](https://eternity2.dev/fr/research/build/analysis/parity-arguments/) — Comptez n'importe quoi sur un plateau à appariement d'arêtes deux fois, une fois de chaque côté, et les totaux doivent coïncider, livrant des preuves d'impossibilité au prix d'un seul passage. L'histoire du 479 en montre à la fois la puissance et le piège : un argument de parité limpide, vrai pour tout coup intérieur, mis en défaut par les soixante arêtes de bordure que personne ne comptabilise. - [Compter les solutions : mesurer ce qu'on ne peut pas trouver](https://eternity2.dev/fr/research/build/analysis/solution-counting/) — Personne n'a jamais vu une solution complète d'Eternity II, et pourtant la communauté sait, à un facteur deux près, combien il en existe. Cette page raconte l'histoire et le métier de ce nombre : recensements exacts sur petits plateaux, la formule d'espérance et sa convergence sur 14 702 en vingt ans, et les estimations par recherche élaguée auxquelles on n'a fait confiance que lorsque quatre exécutions indépendantes concordaient. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. --- # Arguments de parité > Comptez n'importe quoi sur un plateau à appariement d'arêtes deux fois, une fois de chaque côté, et les totaux doivent coïncider, livrant des preuves d'impossibilité au prix d'un seul passage. L'histoire du 479 en montre à la fois la puissance et le piège : un argument de parité limpide, vrai pour tout coup intérieur, mis en défaut par les soixante arêtes de bordure que personne ne comptabilise. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/analysis/parity-arguments/ - Mise à jour: 2026-07-02 - Sujets: structure, search-space - Source: L'argument de parité de kubzpa selon lequel un score de 479 est impossible (août 2007) — https://groups.io/g/eternity2/message/1640 - Source: La construction du 478 de psykowally : faire pivoter une pièce intérieure aux arêtes opposées identiques (msg 1642) — https://groups.io/g/eternity2/message/1642 - Source: La réfutation de Verhaard : 479 par une pièce de bordure retournée (janvier 2009) — https://groups.io/g/eternity2/message/6317 - Source: angwin_uk & mjqxxxx sur l'équilibre des types d'arêtes de bordure, 12 par côté (août 2007) — https://groups.io/g/eternity2/message/2073 - Source: Le méga-fil de 2011 sur la parité : damier et jeux de pièces équilibrés en rotation — https://groups.io/g/eternity2/message/8898 - Source: Le résultat négatif de John Gilbert : les jeux équilibrés bloquent les backtrackers plus vite (msg 8913) — https://groups.io/g/eternity2/message/8913 - Source: Le jeu quasi équilibré de Nick au papier-crayon, et la vérification de la somme globale par Jamison (msgs 8977/8978) — https://groups.io/g/eternity2/message/8977 --- Un argument de parité, c'est de la comptabilité en partie double appliquée à un plateau de jeu. Chaque arête intérieure au puzzle a deux côtés : tout ce qui se compte sur l'ensemble du plateau (occurrences de couleurs, arêtes appariées, sommes d'orientations) se trouve compté deux fois, une fois de chaque côté, et les deux livres de comptes doivent s'accorder. Un état où ils divergent n'est pas seulement peu prometteur : il est impossible, et aucune recherche n'est nécessaire pour le prouver. Sur un puzzle où [aucun coup n'est jamais forcé](/fr/research/why/no-forced-moves/) et où l'anticipation coûte cher, un invariant qui ne coûte qu'un passage sur le plateau et ne ment jamais mérite qu'on le prenne au sérieux, pour peu qu'on se souvienne dans quelle direction il pointe. ## L'histoire du 479, en trois actes Le plus beau récit de parité de la communauté commence deux semaines après le lancement. En août 2007, kubzpa soutint qu'un placement à *exactement* 479 arêtes appariées, une seule discordance, ne peut pas exister ([msg 1640](https://groups.io/g/eternity2/message/1640)). L'intuition est celle d'un basculement de parité : perturbez une pièce quelconque et les arêtes qu'elle touche changent d'état ensemble, de sorte que les discordances devraient venir par paires. psykowally fournit aussitôt le pendant constructif pour 478 : prenez un plateau résolu et faites pivoter de 180° une pièce intérieure dont les arêtes opposées portent des couleurs identiques : exactement deux arêtes se brisent ([msg 1642](https://groups.io/g/eternity2/message/1642)). L'argument est correct pour tout coup intérieur. Il échoue au cadre. En janvier 2009, Louis Verhaard pointa la fuite : les 60 arêtes grises tournées vers l'extérieur ne sont *pas comptabilisées*, si bien qu'une pièce de bordure dont les deux côtés tournés vers l'anneau partagent une couleur peut être retournée bout pour bout, brisant exactement une arête comptabilisée (l'arête de couture derrière elle) tandis que le changement du côté gris ne coûte rien ([msg 6317](https://groups.io/g/eternity2/message/6317)). Une discordance, score 479, parité mise en défaut par les arêtes que la convention de scoring ignore. Ce projet a vérifié l'affirmation sur le jeu de pièces officiel : 14 pièces de bordure sont éligibles (calculé), de sorte que toute solution complète implique un 479. C'est cette version de l'histoire que porte désormais [les faits établis](/fr/research/build/known-facts/). Verhaard ajouta une chute bureaucratique : le formulaire d'inscription au prix enregistrait les numéros de pièces mais pas les rotations, de sorte que le correcteur de Tomy aurait lu un tel plateau comme un 480. La leçon se généralise. Un argument de parité ne vaut que par les conditions de bord qu'il prend en compte, et les règles de scoring d'Eternity II percent le bord en soixante endroits. ## Retournez-la vous-même Les trois actes tiennent sur un petit plateau. Ci-dessous, un 8×8 encadré réellement résolu, généré par le moteur : chaque arête comptabilisée appariée, et un liseré gris extérieur que le score ignore, exactement comme les 60 arêtes grises du vrai puzzle (32 à cette taille). Chaque affirmation du récit ci-dessus tient ici en un clic. > **[Figure]** Interactif : l'argument de parité — interactive: ParityFlipLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pas à pas 1. **Partez du résolu.** Les 112 arêtes comptabilisées sont appariées, l'avatar du 480/480 sur ce plateau. La bande grise est le liseré que la convention de scoring ne lit jamais. 2. **Acte un : cliquez sur n'importe quelle pièce intérieure non marquée.** Un demi-tour échange ensemble les arêtes haut/bas et ensemble les arêtes gauche/droite, de sorte que les arêtes comptabilisées se brisent par paires selon chaque axe : 0, 2 ou 4 à la fois, jamais un compte impair. Essayez-en autant que vous voulez ; aucun clic intérieur ne produira jamais exactement une discordance. C'est l'argument de kubzpa, et pour les coups intérieurs il est imparable. 3. **Acte deux : cliquez sur une pièce intérieure cerclée de ciel.** Une paire opposée identique, l'autre non : exactement deux arêtes comptabilisées se brisent, et le badge affiche un plateau de classe 478, le pendant constructif de psykowally. 4. **Acte trois : cliquez sur une pièce de bordure cerclée d'émeraude.** Ses deux côtés tournés vers l'anneau partagent une couleur, si bien que le retournement à 180° laisse les deux arêtes latérales appariées. Seule l'arête de couture derrière elle se brise (*une* arête comptabilisée), tandis que le changement vers l'extérieur se gare sur le liseré gris (flashé en ambre), là où aucun correcteur ne regarde jamais. Une discordance. 479. La réfutation de Verhaard, en un clic. 5. **Auditez le bord.** Le panneau de comptage vous indique combien de pièces de ce tirage sont éligibles pour chaque coup ; sur le jeu officiel, 14 pièces de bordure sont éligibles (calculé), de sorte que toute solution complète implique un 479. La preuve était correcte partout où le scoring regardait ; la fuite, ce sont précisément les arêtes qu'il a exemptées. ## Ce que ça coûte Une vérification de parité ou d'équilibre, c'est un seul passage sur les arêtes comptabilisées : $$ O(\text{edges}) \;=\; O(480) \ \text{on the full board}, \qquad O(56) \ \text{for NS-1's seam}, $$ avec une constante si petite qu'elle est de fait gratuite : 480 lectures d'arêtes tiennent en microsecondes, contre des pas de recherche qui se comptent en milliards. C'est cette asymétrie de prix qui fait que de telles vérifications se composent avec tout : NS-1, après la fermeture de la bordure, rejette 10 à 28 % des impasses profondes pour 56 lectures, l'élagage le moins cher que ce projet connaisse. Mais l'asymétrie d'*information*, elle, joue en sens inverse, et elle ne fléchit jamais : un invariant violé est une preuve d'impossibilité, un invariant satisfait ne prouve absolument rien. Un passage sur les arêtes achète un certificat qui ne dit jamais que non. Il vaut exactement son prix, pourvu que personne ne le prenne pour une boussole. ## Sommes de couleurs et équilibre de multiensembles La seconde famille d'arguments de comptage dénombre les couleurs plutôt que les discordances. Dès août 2007, angwin_uk observa que la bordure est construite équilibrée : cinq types d'arêtes de bordure, douze de chacun de part et d'autre de l'arête grise de chaque pièce de bordure ([msg 2073](https://groups.io/g/eternity2/message/2073)). mjqxxxx affûta le point : les pièces de bordure occupent une orientation fixe, de sorte que chaque type doit se répartir *à parts égales* en arêtes tournées vers la gauche et vers la droite, une condition strictement plus forte que de simples comptes pairs ([msg 2098](https://groups.io/g/eternity2/message/2098)). Poussez ce raisonnement vers l'intérieur et vous atteignez la couture. Dans toute solution complète, le multiensemble des couleurs que l'anneau de bordure présente à l'intérieur doit égaler le multiensemble que l'intérieur lui présente en retour : chaque couleur reçue est rendue. C'est la condition NS-1 de Hopfer, formalisée en 2022 et traitée en détail sur [la page de l'équilibre de bordure](/fr/research/why/border-balance/) : une véritable condition nécessaire, peu coûteuse à vérifier, et aveugle à tout ce qui se passe d'intérieur à intérieur. Même mathématique, deux usages. En 2007, l'équilibre servait à [estimer combien de solutions de bordure existent](/fr/research/build/analysis/solution-counting/) ; en 2022, on le retourna en certificat d'élagage. ## L'expédition de 2011 : l'équilibre est abondant et n'achète rien Une fois le concours terminé, la liste passa l'été 2011 à pousser la parité aussi loin qu'elle pouvait aller. Juraj Pivovarov posa le problème du *jeu orienté* : partager les 256 pièces en deux tas de damier A et B de telle sorte que les comptes d'arêtes directionnelles de chaque couleur s'équilibrent, car connaître soit les orientations, soit l'affectation aux tas d'une solution rendrait le reste facile ([msg 8898](https://groups.io/g/eternity2/message/8898)). Peter McGavin réduisit la condition à des sommes par couleur, gauche égale droite et haut égale bas ([msg 8906](https://groups.io/g/eternity2/message/8906)). Juraj dénombra alors les jeux de damier équilibrés en rotation qui satisfont la condition : sa première estimation d'environ $4.5 \times 10^{485}$ ([msg 8929](https://groups.io/g/eternity2/message/8929)) tira un « il y a forcément une erreur » à Michael Field ([msg 8930](https://groups.io/g/eternity2/message/8930)), et le compte corrigé se stabilisa autour de $3 \times 10^{147}$ ([msg 8931](https://groups.io/g/eternity2/message/8931)). Tout du long, il présenta la recherche ne serait-ce que d'un seul de ces jeux comme une instance difficile de PARTITION. Deux résultats mirent fin à l'expédition, tous deux à conserver. John Gilbert mena l'expérience : on peut trouver des jeux de damier équilibrés un à un, mais fournir l'équilibre à un backtracker comme contrainte le fait bloquer *plus vite* : chaque placement puise désormais dans la moitié des pièces candidates, et la restriction coûte plus qu'elle n'élague ([msg 8913](https://groups.io/g/eternity2/message/8913)). Et Nick, travaillant au papier-crayon alors qu'il s'ennuyait dans un train ([msg 8960](https://groups.io/g/eternity2/message/8960)), conduisit une affectation complète des 256 pièces (damier plus rotation) à un seul basculement d'arête de l'équilibre ([msg 8977](https://groups.io/g/eternity2/message/8977)) ; Jason Jamison vérifia les sommes globales sous le codage de Nick (tous les hauts égaux à tous les bas à 2 809, tous les gauches égaux à tous les droits à 2 881) et rapporta que le jeu quasi équilibré bloquait tout de même son backtracker à environ 19 pièces d'un coin ([msg 8978](https://groups.io/g/eternity2/message/8978)). L'équilibre est réel, abondant, et n'achète rien à la recherche. ## Ce que la parité rapporte à l'auteur d'un solveur Trois choses, dont aucune n'est une solution. **Des conditions nécessaires peu coûteuses.** Une vérification de parité ou d'équilibre coûte un passage et se compose avec tout : un backtracker, une [recherche locale](/fr/research/build/local-search/local-search-alns/), un contrôle de cohérence sur le plateau qu'un autre prétend avoir. Les chiffres NS-1 ci-dessus donnent le tarif en vigueur. **L'asymétrie du certificat.** Chaque argument de cette page pointe dans un seul sens : un invariant violé dit *assurément cassé*, un invariant satisfait ne dit jamais *assurément bon*. Échangez deux pièces de bordure et NS-1 reste à zéro ; équilibrez parfaitement un jeu de pièces et le backtracker bloque quand même. La parité élague ; elle ne guide pas. **Un réflexe de conditions de bord.** La preuve du 479 était correcte partout où le prouveur regardait, et fausse parce que les règles de scoring créaient soixante arêtes qu'il n'avait pas à regarder. Avant de faire confiance à un argument de comptage sur ce puzzle, y compris ceux de ce projet, auditez ce que le cadre, la convention de scoring et le gris non comptabilisé exemptent en silence. Sur Eternity II, les exceptions vivent à la bordure, et la bordure est là où les arguments vont mourir. ## À lire aussi - [L'équilibre du bord](https://eternity2.dev/fr/research/why/border-balance/) — Un plateau résolu dissimule une loi comptable toute simple : chaque couleur que le bord tend vers l'intérieur, l'intérieur la lui rend aussitôt. La violer, c'est savoir sur-le-champ que le plateau est faux ; la respecter, en revanche, ne garantit rien. - [Faits et chiffres établis](https://eternity2.dev/fr/research/build/known-facts/) — Les chiffres que tout chercheur sur Eternity II finit par redémontrer, rassemblés au même endroit avec leur provenance : la définition du puzzle, le placement des indices, les conventions de score, le tableau des records, la taille de l'espace de recherche et les comptages structurels. --- # Compter les solutions : mesurer ce qu'on ne peut pas trouver > Personne n'a jamais vu une solution complète d'Eternity II, et pourtant la communauté sait, à un facteur deux près, combien il en existe. Cette page raconte l'histoire et le métier de ce nombre : recensements exacts sur petits plateaux, la formule d'espérance et sa convergence sur 14 702 en vingt ans, et les estimations par recherche élaguée auxquelles on n'a fait confiance que lorsque quatre exécutions indépendantes concordaient. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/analysis/solution-counting/ - Mise à jour: 2026-07-02 - Sujets: structure - Source: L'estimation de Brendan Owen le jour du lancement : 5 930 avec l'indice, ~4,65 M sans, réconciliant les « environ 5 millions » que Monckton avait donnés à Dave Clark (msg 987, 2007-07) — https://groups.io/g/eternity2/message/987 - Source: Le produit fermé de l'espérance du nombre de solutions posté sur la liste (msg 3385, 2007-11) — https://groups.io/g/eternity2/message/3385 - Source: L'article de kubzpa « E2 has 15 millions of solutions » (msg 3497, 2007-12 ; v2 après relecture par les pairs, msg 3583) — https://groups.io/g/eternity2/message/3497 - Source: Les quatre recherches de bordure élaguées et indépendantes d'Owen convergent sur ≈ 4,05×10³⁷ (msg 2696, 2007-09 ; premier chiffre msg 1225) — https://groups.io/g/eternity2/message/2696 - Source: McGavin : 1,1527×10⁷ solutions sans la pièce de départ contre 14 702 avec elle, et nombre de nœuds par solution inchangé (msg 8924, 2011) — https://groups.io/g/eternity2/message/8924 - Source: L'énoncé canonique de McGavin : 14 702 avec la pièce de départ, 4×10⁻⁸ avec les cinq indices (msg 11193, 2024) — https://groups.io/g/eternity2/message/11193 - Source: L'indice n°3 compté exactement : 2 195 647 488 solutions (msg 8168, 2010) — https://groups.io/g/eternity2/message/8168 - Source: Les deux références 9×9 épuisées : 2 et 3 solutions contre les 3,2 prédites (msg 8793, 2011 ; corrections 8801–8803) — https://groups.io/g/eternity2/message/8793 --- Personne n'a jamais exhibé de solution complète d'Eternity II. La communauté s'accorde néanmoins sur leur nombre, à un facteur deux près selon ce qu'elle revendique : environ **14 702** avec la pièce de départ obligatoire, et environ **4×10⁻⁸**, c'est-à-dire exactement une, une fois les cinq indices posés ([msg 11193](https://groups.io/g/eternity2/message/11193)). Cette page raconte comment un groupe de personnes a appris à dénombrer une chose qu'aucune d'elles ne pouvait trouver, et pourquoi elles s'en sont donné la peine. Le *pourquoi* n'est pas la curiosité. Un puzzle à 14 702 solutions et un puzzle à 1 sont des bêtes différentes sous tous les rapports qui comptent. **Conception** : les paramètres du puzzle ont été réglés pour que le nombre attendu se situe autour de un ; la communauté a rétro-conçu le bouton du concepteur en quelques semaines après l'annonce de 2007, lorsqu'Alan O'Donnell a écrit le nombre en fonction du nombre de couleurs $B$ et a trouvé qu'il franchit $1$ à $B \approx 14.67$ ([msg 94](https://groups.io/g/eternity2/message/94)) ; les [17 couleurs intérieures](/fr/research/why/phase-transition/) du vrai puzzle se situent juste au-delà de ce fil du rasoir. **Difficulté** : le nombre de solutions rapporté à la taille de l'arbre de recherche (nœuds par solution) est le vrai prix de la chasse, et il se comporte de façon contre-intuitive : Peter McGavin a calculé que lever la contrainte de la pièce de départ multiplie les solutions par 784 tout en laissant le nombre de nœuds par solution pratiquement inchangé, $9.2766\times10^{42}$ contre $9.2751\times10^{42}$ ([msg 8924](https://groups.io/g/eternity2/message/8924)). Plus de solutions ne veut pas dire un puzzle plus facile ; cela veut dire une meule de foin proportionnellement plus grande. **Vérification** : les comptages exacts sur de petites régions sont la monnaie de correction de la communauté : le moyen pour deux solveurs de prouver qu'ils lisent les mêmes pièces sans jamais les partager (voir [la culture des références](/fr/research/build/benchmarks/)). Une raison de plus pour laquelle le nombre importe : les solutions ne sont pas des variations sur un même thème. Brendan Owen et d'autres ont insisté sur le fait que des solutions distinctes constituent « en général une restructuration complète du puzzle tout entier », et non des permutations locales de quelques pièces ([msgs 7364/7365](https://groups.io/g/eternity2/message/7365)) ; ainsi 14 702 est un décompte de plateaux réellement différents, disséminés dans l'espace de recherche. ## Trois façons de compter Vingt ans de trafic sur la liste rangent chaque résultat de comptage dans trois régimes, chacun avec ses propres garanties, son propre prix et ses propres modes de défaillance. | Régime | Ce qu'il donne | Ce qu'il coûte | Résultat phare | | --- | --- | --- | --- | | Énumération exacte | Le vrai décompte | L'arbre de recherche entier | Indice n°3 : exactement 2 195 647 488 | | Espérance au premier moment | Une moyenne sur les puzzles de ce type | De l'arithmétique au crayon | 14 702 avec la pièce de départ | | Recherche échantillonnée / élaguée | Une estimation avec des barres d'erreur informelles | Un budget de nœuds fixé par exécution | Anneau de bordure ≈ 4,05×10³⁷ | ### Énumération exacte : compter en épuisant Là où l'arbre est assez petit pour être parcouru en entier, compter revient simplement à chercher sans s'arrêter au premier succès. La communauté s'en est servie dès les premières semaines comme d'un *protocole de vérification* : pavez le coin supérieur gauche 3×3 avec les 256 pièces et vous devez trouver exactement **2 633 221** solutions ([msg 2229](https://groups.io/g/eternity2/message/2229)), un nombre que l'on peut publier sans enfreindre le droit d'auteur sur le jeu de pièces, et impossible à reproduire avec ne serait-ce qu'une seule pièce mal saisie. Les coins 5×5 ont suivi en 2009, vérifiés de manière croisée par trois programmes indépendants (supérieur gauche : 1 596 901 885 652 solutions partielles avec les cinq indices, [msg 7103](https://groups.io/g/eternity2/message/7103), [7105](https://groups.io/g/eternity2/message/7105)). Retrouver le consensus vous faisait entrer dans le « Right Numbers Club » à demi facétieux de la communauté ; toute l'histoire est sur la [page des références](/fr/research/build/benchmarks/). Deux résultats exacts se détachent des autres. En 2010, apal1969 a épuisé le puzzle officiel de l'Indice n°3 (une véritable instance commerciale Tomy) et a trouvé exactement **2 195 647 488** solutions ([msg 8168](https://groups.io/g/eternity2/message/8168)) : la seule instance commercialisée de la famille dont le nombre de solutions soit connu exactement plutôt qu'estimé. Et en 2011, les deux puzzles de référence 9×9 de Brendan Owen ont été épuisés, au prix d'environ $1.9\times10^{14}$ et $1.45\times10^{14}$ nœuds et de trois semaines chacun sur un Opteron bicœur. Ils ont livré **2** et **3** solutions ; la [théorie complexe](/fr/research/why/complex-theory/) en avait prédit 3,2 pour le premier ([msg 8793](https://groups.io/g/eternity2/message/8793)). Même le comptage devait être compté soigneusement : le premier rapport annonçait une solution chacun, et il a fallu les backtrackers indépendamment mélangés de McGavin pour faire remonter les plateaux manquants ([msgs 8801–8803](https://groups.io/g/eternity2/message/8801)). Exhaustif ne veut pas dire exempt de bogue ; seule la réplication l'est. ### Le premier moment : compter par espérance Pour le plateau complet 16×16, l'épuisement est hors de portée : l'outil principal de la communauté a donc toujours été le calcul du *premier moment* (valeur attendue) : multiplier le nombre d'arrangements possibles des pièces par la probabilité que chaque arête interne concorde, en traitant les couleurs des arêtes comme des tirages indépendants. Les premières versions sont apparues en l'espace de **quelques jours** après l'annonce de janvier 2007, des mois avant que quiconque ait des pièces ([msg 38](https://groups.io/g/eternity2/message/38), [94](https://groups.io/g/eternity2/message/94)). Le jour du lancement, avec les vraies statistiques des pièces en main, Owen a calculé ≈ **5 930** solutions avec l'indice obligatoire et ≈ **4,65 millions** sans lui, puis s'est servi de cet écart pour auditer le marketing : Christopher Monckton avait donné à Dave Clark d'eternity2.net une meilleure estimation d'« environ 5 millions » de solutions, et Owen en a conclu que les mathématiciens de Monckton avaient simplement oublié la contrainte de l'indice ([msg 987](https://groups.io/g/eternity2/message/987)). David Eddy a ajouté le même jour que les [corrections de parité](/fr/research/build/analysis/parity-arguments/) (le nombre d'arêtes de chaque couleur doit être pair) apportent un facteur d'environ $2^{16}$ qui met les familles d'estimations d'accord ([msg 992](https://groups.io/g/eternity2/message/992)). La convergence a pris des années, et elle n'a pas été monotone. Le produit fermé a été posté en novembre 2007 ([msg 3385](https://groups.io/g/eternity2/message/3385)) ; mjqxxxx avait déjà entamé un cadre de comptage pleinement rigoureux ce mois de juillet ([msg 1221](https://groups.io/g/eternity2/message/1221)) ; l'article de kubzpa de décembre 2007 plaidait pour ~**15 millions** de solutions avec la pièce de départ. Il a reçu une véritable relecture par les pairs sur la liste : les corrections de la liste ont produit une deuxième version corrigée ([msg 3497](https://groups.io/g/eternity2/message/3497), [3583](https://groups.io/g/eternity2/message/3583)), puis mjqxxxx a détecté une incohérence de Monte-Carlo dans la v2 ([msg 3589](https://groups.io/g/eternity2/message/3589)) que kubzpa a fait remonter à un mélange biaisé, révisant à nouveau son estimation ([msg 3591](https://groups.io/g/eternity2/message/3591)). Un chiffre de « 20 000 solutions » a circulé pendant des années avant d'être remonté au site officiel français archivé ([msg 8515](https://groups.io/g/eternity2/message/8515)). Le nombre qui a survécu est celui de la théorie complexe : jagbrain a dérivé **14 702** d'un modèle de Markov fermé et indépendant en 2008, coïncidant exactement avec la méthode itérative d'Owen ([msg 5758](https://groups.io/g/eternity2/message/5758)) ; McGavin a publié le même chiffre en 2011 ([msg 8924](https://groups.io/g/eternity2/message/8924)) et l'a réénoncé comme la réponse canonique en 2024 : 14 702 avec la pièce de départ, « probablement exact à un facteur 2 près », et $4\times10^{-8}$ avec les cinq indices, « suggérant très fortement… une solution unique » ([msg 11193](https://groups.io/g/eternity2/message/11193)). La machinerie derrière ces nombres - l'espérance profondeur par profondeur et ce qu'elle prédit de l'arbre de recherche - vit sur la [page de la théorie complexe](/fr/research/why/complex-theory/) ; cette page-ci n'a besoin que de son résultat. Un bémol que la communauté a elle-même soulevé a sa place ici. E2 a été *engendré à partir d'une solution*, et choisir un puzzle en choisissant une solution suréchantillonne les jeux de pièces riches en solutions : le décompte conditionné par le processus de génération devrait donc être *supérieur* à l'espérance nue, d'une quantité que le fil de discussion a tenté sans succès de cerner ([msgs 6892/6894](https://groups.io/g/eternity2/message/6892)). Les formules d'espérance chiffrent un puzzle aléatoire ayant les statistiques d'E2 ; E2 n'est pas tout à fait un tel puzzle aléatoire. ### Recherche échantillonnée et élaguée : compter en survivant Entre l'exact et l'attendu se situe le troisième régime : lancer une véritable recherche, mais l'élaguer aléatoirement jusqu'à un budget fixé, puis remettre à l'échelle les survivants. Le joyau méthodologique de l'archive est le recensement de l'anneau de bordure fait par Owen en septembre 2007. Il a lancé **quatre recherches distinctes** du cadre de 60 pièces, chacune élaguant aléatoirement l'arbre tout en conservant environ 10 millions de nœuds actifs par profondeur. Chacune des quatre a indépendamment estimé **≈ 4,05×10³⁷** solutions de bordure ([msg 2696](https://groups.io/g/eternity2/message/2696), d'abord postée au [msg 1225](https://groups.io/g/eternity2/message/1225)). Le chiffre divergeait de treize ordres de grandeur de l'estimation publiée par eternity2.net, et cette réplication est exactement la raison pour laquelle la communauté a donné raison à Owen. Une exécution élaguée isolée peut être silencieusement biaisée par n'importe quoi ; quatre exécutions indépendantes qui concordent, c'est une barre d'erreur que l'on peut voir. Cette habitude (la réplication comme contrôle d'erreur, non comme argument d'autorité) est la même qui a plus tard régi les recensements des coins et les recomptages des 9×9. ## Pas à pas : la formule d'espérance sur un plateau minuscule Le calcul du premier moment mérite d'être fait une fois à la main. Prenons un E2 miniature : un plateau 3×3 encadré (4 coins, 4 bords, 1 pièce intérieure) avec une seule palette de $c$ couleurs sur chaque arête interne. **Étape 1 : compter les arrangements.** Les coins vont aux cases d'angle avec leur orientation forcée par les deux côtés gris ; de même pour les pièces de bord ; la seule pièce intérieure conserve ses 4 rotations : $$ A \;=\; 4! \times 4! \times 4 \;=\; 2304 . $$ **Étape 2 : compter les contraintes.** Le plateau compte $2\cdot3\cdot2 = 12$ arêtes internes. Si les couleurs étaient des tirages uniformes indépendants, chaque arête concorderait avec probabilité $1/c$. **Étape 3 : multiplier.** $$ \mathbb{E}[S] \;=\; \frac{2304}{c^{12}} \quad\Longrightarrow\quad c=2:\ 0.56, \qquad c=3:\ 0.0043 . $$ Voilà tout le dilemme du concepteur en une ligne : à deux couleurs, le puzzle minuscule attend environ une demi-solution ; à trois, il est presque certainement insoluble. Une fraction de couleur fait basculer l'espérance de part et d'autre de la ligne « exactement une ». Étendez le même produit au vrai plateau, avec $4!$ arrangements de coins, $56!$ arrangements de bords, $195!\cdot4^{195}$ arrangements intérieurs (la pièce de départ est fixée), 60 arêtes de l'anneau du cadre à $1/5$ et $56+364=420$ arêtes restantes à $1/17$, et vous obtenez la forme postée sur la liste en novembre 2007 ([msg 3385](https://groups.io/g/eternity2/message/3385)) : $$ \mathbb{E}[S] \;=\; 4!\;56!\;195!\;4^{195} \left(\tfrac{1}{5}\right)^{60}\left(\tfrac{1}{17}\right)^{420} \;\approx\; 0.02 . $$ Impossible de cacher l'écart : **0,02 n'est pas 14 702**. Le produit naïf est inférieur de près de six ordres de grandeur, et la communauté en connaissait la raison dès le départ. Traiter chaque arête comme un tirage à pile ou face indépendant à $1/17$ chiffre la dernière pièce comme la première, alors qu'en réalité le vrai jeu de pièces s'apparie parfaitement (chaque couleur a un compte pair, avec un [écart nul](/fr/research/build/known-facts/)) : les probabilités de concordance de la fin de partie sont donc conditionnées bien au-dessus de $1/17$ par tout ce qui est déjà placé. Ces corrections de parité et d'épuisement ont été signalées dans le message même qui a posté la formule, et le facteur de compte pair $\sim 2^{16}$ d'Eddy ([msg 992](https://groups.io/g/eternity2/message/992)) est le plus grand d'entre elles. La [théorie complexe](/fr/research/why/complex-theory/) est précisément ce calcul fait correctement, suivant les comptes de pièces et de couleurs survivants profondeur par profondeur au lieu de supposer une probabilité fixe, et c'est *cette* version-là qui atterrit à 14 702 et coïncide avec les comptages exhaustifs sur petits plateaux au facteur deux près qu'elle revendique. La structure de la formule (arrangements × probabilité de concordance) est juste ; tout le jeu réside dans l'endroit d'où l'on tire la probabilité. ## Ce que cela coûte Les trois régimes sont en réalité trois points sur une courbe coût–connaissance. **L'énumération exacte coûte l'arbre lui-même.** Compter, c'est une recherche exhaustive qui refuse de s'arrêter : chaque recensement 9×9 a coûté de l'ordre de $10^{14}$ nœuds et trois semaines de matériel de 2011, et le prix croît avec l'espace de recherche, non avec la réponse. Pour le puzzle complet, l'arbre est large de $\sim 10^{45}$ à son plateau ; le nombre exact de solutions d'E2 ne sera jamais calculé par personne, par cette voie. **L'espérance ne coûte presque rien, et c'est là son piège.** La formule du premier moment est de l'arithmétique en $O(1)$ (la version raffinée de la théorie complexe tient en quelques centaines de multiplications, une par case), et c'est pourquoi elle existait avant même la sortie du puzzle. Mais un premier moment ne porte aucune information sur la *variance* : il vous donne le décompte moyen sur les puzzles ayant les statistiques d'E2, non pas si la masse se trouve dans les instances typiques ou dans de rares monstres riches en solutions, ni si les plateaux partiels comptés à chaque profondeur sont réellement distincts. Les [résultats d'entropie et de loi d'aire](/fr/research/why/entropy-area-law/) montrent exactement où cet aveuglement fait mal : à mesure que les patchs grandissent, la distinction s'effondre d'une manière qu'aucun modèle d'indépendance ne peut voir. Servez-vous des espérances pour comparer des ordres de grandeur et cadrer les attentes, jamais comme de bornes. **L'échantillonnage n'achète des barres d'erreur que par la répétition.** Une recherche élaguée coûte un budget de nœuds par exécution et donne une estimation de biais inconnu ; Owen a payé quatre budgets pour l'anneau de bordure et acheté la seule forme de confiance qu'offre ce régime. La règle sur laquelle la communauté s'est arrêtée est celle qui mérite d'être emportée de cette page : un comptage échantillonné vu une seule fois est une anecdote ; le même comptage obtenu à partir d'exécutions, de graines et d'auteurs indépendants est une mesure. ## À lire aussi - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. - [Les benchmarks de la communauté](https://eternity2.dev/fr/research/build/benchmarks/) — Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. - [Faits et chiffres établis](https://eternity2.dev/fr/research/build/known-facts/) — Les chiffres que tout chercheur sur Eternity II finit par redémontrer, rassemblés au même endroit avec leur provenance : la définition du puzzle, le placement des indices, les conventions de score, le tableau des records, la taille de l'espace de recherche et les comptages structurels. --- # Une carte de toutes les approches connues > La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/approaches-map/ - Mise à jour: 2026-07-21 - Source: Le bilan que la communauté dresse elle-même de deux décennies d'effort : 1,6 TFlops, 10^19 opérations CPU, aucune solution (groups.io, message 3511) — https://groups.io/g/eternity2/message/3511 - Source: Le record en vigueur, 470, sur le puzzle officiel : Joshua Blackwood, « 470 Found », eternity2@groups.io, 2021 (groups.io, message 10117) — https://groups.io/g/eternity2/message/10117 - Source: Eternity II (Wikipédia) : le puzzle, le prix et le bilan public — https://en.wikipedia.org/wiki/Eternity_II_puzzle --- Ceux qui travaillent sur Eternity II finissent tous par poser la même question : existe-t-il un endroit qui recense *toutes* les approches ? La réponse habituelle est non, parce que ceux qui s'y attaquent forment un mélange d'universitaires, de solveurs de compétition et d'amateurs, et que personne n'a jamais dressé la carte. Cette page est cette carte. Elle n'ajoute aucune méthode nouvelle ; elle aligne celles que ce wiki documente déjà, une famille à la fois, pour que l'on embrasse tout le territoire avant de choisir une direction. Pour chaque famille : ce qu'elle est en une ligne, ce qu'elle a réellement atteint sur le vrai plateau 16×16, où elle s'arrête, et un lien vers la page de fond avec les labos, les mesures et les citations d'archives. Aucune de ces méthodes n'est une invention propre à Eternity II : elles viennent de la programmation par contraintes, de la combinatoire et de la cryptanalyse, et chaque page de fond nomme l'inventeur de la méthode et cite l'article d'origine. Ce que les pages de fond ajoutent, c'est le comportement de chacune lorsqu'on la braque sur ce puzzle précis, avec les mesures propres au projet là où elles existent et un simple « non mesuré » là où elles font défaut. L'[étagère des techniques](/fr/research/build/techniques/) est l'index de ces pages. ## L'unique idée qui organise toute la carte Chacune des familles ci-dessous cale au même endroit : le plafond communautaire de 470 arêtes accordées sur 480, avec [les propres expériences de ce projet](/fr/research/lab/experiments/raphael-anjou/) regroupées autour de [460–463](/fr/research/records/). Elles calent là pour la même raison, et il vaut la peine de l'énoncer avant le catalogue pour que le reste se lise comme autant de variations sur un même thème. La raison tient à un problème d'évaluation. Le seul signal peu coûteux dont dispose un solveur est le nombre d'arêtes accordées, et ce nombre ne dit pas à quelle distance de la solution on se trouve. Un plateau à 470 arêtes et un plateau à 460 peuvent être tout aussi loin de l'achèvement, car les dix dernières arêtes ne relèvent pas d'un travail de finition : elles siègent de l'autre côté d'un mur global qu'aucun score local ne perçoit. Ainsi les chercheurs systématiques et les chercheurs stochastiques, qui ne se ressemblent en rien, convergent vers la même hauteur. C'est le **[mur de rigidité](/fr/research/why/rigidity-wall/)** : les plateaux record sont localement figés, et le pas d'un excellent plateau à un plateau parfait est un unique échange indivisible, sans gradient à suivre. Son pendant est **[pourquoi un ordinateur plus rapide n'aide pas](/fr/research/why/prune-vs-speed/)** : lorsqu'on ne peut pas réduire la recherche, la vitesse brute n'achète presque rien. La section **[pourquoi c'est difficile](/fr/research/why/)** démontre les deux, et **[quel mur arrête quelle méthode](/fr/research/why/walls-and-methods/)** confronte chaque attaque au mur sur lequel elle meurt. Gardez cela en tête et la carte ci-dessous se lit sans peine : les familles diffèrent par la *manière* dont elles grimpent, non par la *hauteur* qu'elles atteignent. ## Recherche systématique La famille du retour arrière : placer les pièces une à une dans un ordre fixé ou calculé, élaguer les placements illégaux, et défaire en cas d'échec. Tout ce qui détient un record vit ici. - **[Ordres de remplissage](/fr/research/build/backtracking/fill-order/)**. L'ordre dans lequel un solveur à retour arrière visite les 256 cases est son unique degré de liberté, et il fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur sans coût d'exécution. Vingt ans de science communautaire, du débat fixe-contre-dynamique à la recherche en peigne de Verhaard. C'est le levier, pas un mur. - **[Cohérence d'arc](/fr/research/build/reduce/arc-consistency/)**. Faire en sorte que la liste de candidats de chaque case se défende contre ses voisines jusqu'à un point fixe, au-delà du simple contrôle anticipé à un coup. L'AC-3 de Mackworth et ses raffinements élaguent fortement sur les petits plateaux ; sur le plateau complet, l'élagage atteignable s'estompe à environ deux cases de distance et ne parvient pas à effondrer le facteur de branchement. - **[Tous-différents, le filtre de couplage de Régin](/fr/research/build/reduce/alldiff-regin/)**. Aucune pièce ne peut servir deux fois : une seule contrainte globale sur 256 cases, filtrée intégralement en temps polynomial par couplage biparti. Le propagateur le plus puissant que l'on ait mesuré ici, avec une réserve marquée dès que la recherche tolère des désaccords. - **[Apprentissage de no-goods](/fr/research/build/reduce/nogood-learning/)**. Un sous-arbre échoué est un théorème : le consigner et ne jamais y revenir. Tables de transposition et contraintes minées paient toutes deux sur les petits plateaux ; en 16×16, le nombre de no-goods distincts dépasse toute mémoire que l'on puisse détenir. - **[Redémarrages et queues lourdes](/fr/research/build/backtracking/restarts/)**. Le même solveur à retour arrière sur le même puzzle termine en des temps d'exécution qui diffèrent de plusieurs puissances de dix ; alors on coupe, on rebat les cartes, et on relance. Tout solveur record depuis 2007 est un portefeuille de redémarrages. Cela change les plateaux que l'on atteint, pas le plafond. - **[Rencontre au milieu](/fr/research/build/exact/meet-in-the-middle/)**. Énumérer deux moitiés et les joindre sur une interface commune, en échangeant de la mémoire contre la moitié de l'exposant. Réel sur des bandes du plateau ; l'expérience BANDSAW de ce projet a mesuré où cela cesse de payer à pleine taille. - **[Couverture exacte et dancing links](/fr/research/build/exact/exact-cover-dlx/)**. Eternity II s'énonce proprement comme une couverture exacte, et l'algorithme X de Knuth en est la machine classique. Il brille sur les petits plateaux et le dénombrement exhaustif ; en 16×16, l'arbre reste non réduit et un quasi-succès ne vaut aucun crédit partiel. - **[Ingénierie de solveur](/fr/research/build/faster/solver-engineering/)**. Non pas un algorithme mais l'artisanat qui le sous-tend : tables de correspondance, fonctions de hachage parfaites, structures dimensionnées au cache, code généré. Il décide si un nœud coûte 26 cycles ou 2 600, et c'est ce qui permet aux moteurs record de tourner. Il achète de la vitesse, et la vitesse est précisément ce qui ne déplace pas le mur. Le **[catalogue de solveurs](/fr/research/build/solvers/)** montre comment les moteurs record (le 467 de Verhaard, le 470 de Blackwood) assemblent ces pièces. ## Traductions vers d'autres solveurs Plutôt que d'écrire un solveur à retour arrière, on traduit le puzzle dans le langage d'entrée d'un solveur industriel et l'on laisse une décennie d'ingénierie mener la recherche. - **[Encodages SAT et CSP](/fr/research/build/exact/sat-csp-encodings/)**. Écrire le puzzle sous forme de clauses et le confier à un solveur complet. Tenté depuis 2008. Les solveurs calent sur le plateau complet, mais leurs verdicts gagnent encore leur place comme preuves d'impossibilité sur des sous-plateaux. - **[Relaxations PL et PLNE](/fr/research/build/exact/lp-relaxations/)**. L'écrire comme un programme en nombres entiers et abandonner l'intégralité : un solveur linéaire atteint une erreur nulle en quelques secondes en plaçant des fractions de pièces. Le confort s'arrête à l'instant où les pièces doivent être entières : un plateau à 420–440 arêtes, un mur PLNE dès le 8×8, et un meilleur résultat académique de 461 en une heure. ## Recherche locale et stochastique Partir d'un plateau complet (imparfait) et l'améliorer par des mouvements, guidé par un objectif. Ces méthodes ne ressemblent en rien au retour arrière, et elles s'arrêtent à la même hauteur. - **[Recherche locale et ALNS](/fr/research/build/local-search/local-search-alns/)**. Détruire une partie d'un plateau, la reconstruire en mieux, et apprendre quelles démolitions paient. Le polisseur le plus fiable ici, et la démonstration la plus nette de là où le polissage s'achève. - **[Recuit simulé et parallel tempering](/fr/research/build/local-search/parallel-tempering/)**. Traiter les désaccords comme une énergie et la température comme une tolérance à l'aggravation. Le recuit détient le record le plus ancien de cette famille ; le tempering franchit des barrières que le recuit ne peut franchir. Les deux s'arrêtent au même mur. - **[Recherche par faisceau](/fr/research/build/construct/beam-search/)**. Maintenir en vie les K plateaux partiels les plus prometteurs et les faire croître case par case. Le cheval de trait derrière les constructeurs partant de zéro de ce projet, et une illustration nette de pourquoi la largeur seule cale dans l'intérieur profond. - **[Approches évolutionnaires et génétiques](/fr/research/build/local-search/evolutionary/)**. Élever une population, garder les plus aptes, recombiner les survivants. La métaphore la plus naturelle de la boîte à outils, et celle dont l'opérateur central, le croisement, se heurte de plein fouet à la structure du puzzle. - **[Applications itérées et divide-and-concur](/fr/research/build/exact/iterated-maps/)**. Scinder le puzzle en deux ensembles de contraintes faciles à projeter et itérer une application dont les points fixes sont des solutions. La méthode d'Elser a fait la couverture de PNAS ; sur la liste Eternity II, elle a été testée une fois et jamais menée à son terme. ## Apprendre des plateaux forts Chacune des méthodes ci-dessus ne raisonne qu'à partir des règles du puzzle. Cette famille raisonne à partir des plateaux déjà trouvés : exploiter le corpus des plateaux forts pour en extraire de la structure et la réinjecter dans une recherche comme un biais. Elle atteint vite et sûrement le sommet de la plage d'une recherche, et elle ne relève pas le plafond. - **[Apprendre des plateaux forts](/fr/research/build/learning/)**. Le carrefour de la famille : [priors](/fr/research/build/learning/corpus-priors/) de position et de demande rare, [ordonnancement de coups appris](/fr/research/build/learning/learned-value-ordering/) par vote, [minage d'anti-motifs](/fr/research/build/learning/anti-pattern-mining/) qui sépare la structure partagée du piège partagé, et [décodage d'un record](/fr/research/build/learning/decoding-records/) pour retrouver le coup qu'une recherche ordinaire manquait. La [synthèse de l'effondrement](/fr/research/build/learning/when-learning-collapses/) est l'endroit où la famille s'arrête : accordez trop de confiance à un signal appris et la recherche se disloque, et même exploité parfaitement, aucune de ces méthodes ne franchit le mur de rigidité, car le corpus dont elles apprennent est fait de plateaux bloqués à ce même mur. ## Voies exotiques et matérielles Tous les quelques ans, quelqu'un propose un matériel neuf ou une physique neuve. Ces pages tiennent le registre de ce que chacune a réellement livré. - **[Résolution sur GPU](/fr/research/build/hardware/gpu-solving/)**. Cela ressemble à la charge de travail parfaite (des millions de sous-arbres indépendants), et dix-huit ans de tentatives ont mesuré une tout autre réalité : branchement divergent et état par fil qui déborde la mémoire rapide. Le mur est la mémoire, pas l'arithmétique. - **[Résolution sur FPGA](/fr/research/build/hardware/fpga-solving/)**. Placer les tables de correspondance à un cycle de distance dans la RAM embarquée et pipeliner des dizaines de minuscules solveurs à retour arrière. Michael Field l'a conçu, projeté 5 milliards de placements par seconde et par puce, et fait tourner un prototype. La voie a été cartographiée en détail et jamais parcourue jusqu'au bout. - **[Résolution distribuée](/fr/research/build/faster/distributed-solving/)**. Y jeter davantage d'ordinateurs : économiseurs d'écran BOINC, syndicats de partage du prix, grappes de consoles, fermes de cartes monobloc. L'effort total de la communauté a atteint environ 10^19 opérations sans solution ; la seule chose que la distribution fait vraiment bien est le dénombrement exhaustif sur les petits plateaux. - **[Approches quantiques](/fr/research/build/hardware/quantum/)**. Le plus ancien deus ex machina de la liste, invoqué dès le premier mois du puzzle et tous les quelques ans depuis. Deux histoires réelles (l'accélération quadratique de Grover et le recuit sur un QUBO), l'arithmétique confrontée aux chiffres réels d'Eternity II, et un bilan de zéro exécution. ## Analyse, pas des solveurs Celles-ci ne cherchent pas à résoudre le puzzle. Elles le mesurent, et c'est ainsi que la communauté sait où sont les murs. - **[Arguments de parité](/fr/research/build/analysis/parity-arguments/)**. Compter une quantité du plateau deux fois, une fois de chaque côté, et les totaux doivent coïncider, ce qui fournit des preuves d'impossibilité pour une passe. L'histoire du 479 en montre à la fois la puissance et le piège. - **[Dénombrement des solutions](/fr/research/build/analysis/solution-counting/)**. Personne n'a jamais vu de solution complète, et pourtant la communauté sait à un facteur deux près combien il en existe : recensements exacts sur les petits plateaux et une formule d'espérance qui a convergé vers environ 14 702. ## Impasses Certaines idées sonnent aussi bien que n'importe laquelle ci-dessus et, démontrablement, ne déplacent pas le score. La page **[impasses](/fr/research/build/dead-ends/)** les rassemble avec la raison de l'échec de chacune, pour vous épargner un mois de travail : brisure de symétrie (il n'y a pas de symétrie globale à briser), propagation de probabilités qui s'estompe à deux cases de distance, et d'autres. ## Ce que la carte vous dit Lisez-la de haut en bas et la forme est claire. Les familles systématiques détiennent les records parce qu'elles peuvent prouver des choses et élaguer fortement sur les petits plateaux, mais elles ne parviennent pas à réduire suffisamment la recherche complète pour atteindre la fin. Les familles stochastiques polissent magnifiquement et atteignent des plateaux réellement différents, puis calent à la même hauteur. Les voies matérielles changent la vitesse et jamais le plafond. Et les pages d'analyse expliquent pourquoi : les dix dernières arêtes ne sont pas affaire d'effort ou d'ingéniosité dans l'une ou l'autre famille, mais un mur global que chaque famille rencontre depuis sa propre direction. Si vous choisissez où investir votre temps, la question utile n'est pas quelle famille est la meilleure. C'est quel mur vous pensez pouvoir franchir, car c'est cela qui décide réellement du score. **[Quel mur arrête quelle méthode](/fr/research/why/walls-and-methods/)** est l'endroit par où commencer. Pour les cibles encore ouvertes à la frontière, et celles, nommées, qui valent la peine d'être attaquées ensuite, voyez le **[tableau des problèmes ouverts](/fr/research/open-problems/)**. ## À lire aussi - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. - [Comment cherchent les solveurs record](https://eternity2.dev/fr/research/build/solvers/) — Comment cherchent réellement les solveurs qui détiennent les records. Ce sont tous, au fond, des backtrackers en profondeur d'abord ; ce qui les distingue, c'est l'ordre dans lequel ils essaient les choses et la manière dont ils assouplissent les règles à l'approche de la fin. - [Pourquoi c'est difficile](https://eternity2.dev/fr/research/why/) — Eternity II n'est pas difficile par accident. Le casse-tête a été conçu pour résister à l'ingéniosité, et les murs structurels mesurables (rigidité, entropie, motifs interdits) expliquent pourquoi aucune recherche, si ingénieuse soit-elle, n'a atteint la fin. --- # Retour sur trace > La recherche en profondeur d'abord, prise au sérieux. L'ordre dans lequel un solveur visite les cases est son unique choix libre et fait varier la taille de l'arbre de plusieurs ordres de grandeur ; les redémarrages transforment un temps d'exécution à queue lourde en portefeuille. C'est la famille qui se cache derrière chaque backtracker record. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/backtracking/ - Mise à jour: 2026-07-13 --- La recherche en profondeur d'abord, prise au sérieux. L'ordre dans lequel un solveur visite les cases est son unique choix libre et fait varier la taille de l'arbre de plusieurs ordres de grandeur ; les redémarrages transforment un temps d'exécution à queue lourde en portefeuille. C'est la famille qui se cache derrière chaque backtracker record. Les pages ci-dessous procèdent technique par technique : ce qu'est chacune en une ligne, ce qu'elle a réellement atteint sur le vrai plateau 16×16, où elle s'arrête, et les laboratoires et mesures qui l'étayent. Pour embrasser tout le territoire d'un coup, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). ## Pages de cette section - [Ordres de remplissage](https://eternity2.dev/fr/research/build/backtracking/fill-order/) — L'ordre dans lequel un algorithme de retour arrière visite les 256 cases est son unique liberté : il ne coûte rien à l'exécution et fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur. Vingt ans de science communautaire, des guerres fixe-contre-dynamique aux courses de stratégies, jusqu'au carré magique 10×16 et à la recherche en peigne de Verhaard, répondent tous à la même question : quel chemin à travers le plateau est le moins coûteux ? - [Redémarrages et lois à queue lourde](https://eternity2.dev/fr/research/build/backtracking/restarts/) — Lancez deux fois le même backtracker sur le même casse-tête et les temps d'exécution diffèrent d'un facteur dix, cent, mille. La communauté l'a mesuré en 2007 ; la littérature CSP l'avait déjà nommé. Le remède (couper, rebattre, redémarrer) explique pourquoi chaque solveur record depuis est un portefeuille de redémarrages. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. --- # Ordres de remplissage > L'ordre dans lequel un algorithme de retour arrière visite les 256 cases est son unique liberté : il ne coûte rien à l'exécution et fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur. Vingt ans de science communautaire, des guerres fixe-contre-dynamique aux courses de stratégies, jusqu'au carré magique 10×16 et à la recherche en peigne de Verhaard, répondent tous à la même question : quel chemin à travers le plateau est le moins coûteux ? - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/backtracking/fill-order/ - Mise à jour: 2026-07-22 - Sujets: backtracking, search-space - Source: Le « meilleur ordre de recherche » d'Owen, le balayage quasi optimal et l'argument par comptage de formes (septembre 2007) — https://groups.io/g/eternity2/message/2714 - Source: Le débat fixe contre dynamique, où les chemins fixes l'emportent empiriquement (msg 2392 ; le verdict d'Owen, msg 2425) — https://groups.io/g/eternity2/message/2392 - Source: Vitesse, la réponse d'istarinz en un mot à la question du triomphe des chemins fixes (septembre 2008) — https://groups.io/g/eternity2/message/5860 - Source: Le « carré magique 10×16 » de Verhaard (msg 5868 ; l'explication en profondeur 160, msg 5879) — https://groups.io/g/eternity2/message/5868 - Source: Max mesure les orientations de balayage, 2,3 contre 2,7 × 10⁴⁰ nœuds (octobre 2008 ; le fil commence au msg 6015) — https://groups.io/g/eternity2/message/6023 - Source: L'expérience de conception d'Owen montrant que le balayage ne gagne que parce que la répartition 5/17 d'E2 est équilibrée (msg 5263 ; tableaux msg 5243) — https://groups.io/g/eternity2/message/5263 - Source: Verhaard dévoile la recherche en peigne pour les scores élevés (octobre 2008) — https://groups.io/g/eternity2/message/6112 - Source: L'ordre pour scores élevés de Max, quasi identique, douze rangées puis colonnes (octobre 2008) — https://groups.io/g/eternity2/message/6126 - Source: La course de stratégies à 89 794 nœuds, conception d'ordre automatisée contre réglage manuel (msg 2896 ; la riposte msg 2928) — https://groups.io/g/eternity2/message/2896 - Source: La chaîne de Markov de Verhaard, optimiser conjointement l'ordre de remplissage et le tableau de glissements (janvier 2009) — https://groups.io/g/eternity2/message/6423 - Source: Le duel 8×8 de Markus Zajc, la valeur restante minimale bat le balayage qui bat la réduction maximale (septembre 2008) — https://groups.io/g/eternity2/message/5918 - Source: Ansotegui, Bejar, Fernandez et Mateu, la lignée de benchmarks SAT/CSP dont les ordres statiques en damier et spirale sont rejoués par les mesures de carnet de cette page (CP 2008 ; version étendue en revue, Constraints 2013) — https://link.springer.com/article/10.1007/s10601-012-9128-9 - Source: L'étude hyper-heuristique de Wauters, Vancroonenburg et Vanden Berghe, dont la base de retour arrière fait courir le balayage par lignes contre spirale, spirale inverse et ordres en miroir (2012) — https://link.springer.com/article/10.1007/s10852-012-9178-4 --- Un algorithme de retour arrière n'a presque aucune liberté. Les pièces sont données, la règle d'appariement est donnée, le plateau est donné. La seule chose qui vous revient entièrement, c'est l'*ordre de remplissage* : la séquence dans laquelle les 256 cases sont remplies. Cela ressemble à un détail (la recherche est exhaustive quoi qu'il arrive), et c'est en réalité la décision à plus fort effet de levier de tout le solveur. Brendan Owen l'a dit sans détour en 2007 : « L'une des plus grosses économies de nombre de nœuds que vous puissiez faire consiste à choisir un bon ordre de recherche » ([msg 2714](https://groups.io/g/eternity2/message/2714)). Le même puzzle, parcouru dans un ordre différent, peut coûter dix ordres de grandeur de nœuds en plus. Et le choix est gratuit, arrêté avant même que la première pièce ne soit posée. Voilà pourquoi la liste de diffusion en a débattu pendant vingt ans. Le premier grand débat, à l'été 2007, opposait le *fixe au dynamique* : les vétérans d'Eternity I plaidaient pour le choix dynamique, à chaque étape, de la case la plus contrainte, l'heuristique CSP classique ([msg 2392](https://groups.io/g/eternity2/message/2392)). Les empiristes ont répondu par des comptages de nœuds : les meilleurs résultats venaient de chemins fixes, précalculés, et le verdict d'Owen fut qu'« un balayage par lignes après la pose de la pièce indice semble le meilleur » ([msg 2425](https://groups.io/g/eternity2/message/2425)). Un an plus tard, quand on lui a demandé pourquoi personne ne s'embêtait avec un placement entièrement dynamique, istarinz a résumé le volet ingénierie de la réponse en un mot, vitesse : un chemin fixe garde la boucle interne sans branchements et pilotée par tables ([msg 5860](https://groups.io/g/eternity2/message/5860)). Le volet théorique a demandé plus de temps, et fait l'objet de cette page. ## Le point de vue du comptage de contraintes Une idée sous-jacente à tout le reste : un placement de pièce n'est jamais testé que contre les voisins *déjà présents sur le plateau*. Une grille 16×16 possède exactement 480 jonctions internes, et tout ordre de remplissage complet (balayage par lignes, spirale, n'importe quoi) finit par vérifier les 480. L'ordre ne change que l'*ordonnancement* : quelles jonctions sont payées tôt, tant que l'arbre est encore étroit, et lesquelles sont reportées là où il est large. Une case qui arrive avec deux voisins déjà posés n'admet que peu de pièces candidates ; une case qui arrive sans aucun voisin les admet presque toutes et n'élague rien. Les bons ordres sont ceux qui nourrissent la recherche d'un régime régulier de cases contraintes, ce que fait précisément un balayage par lignes : après la première rangée, presque chaque nouvelle case touche une pièce à sa gauche et une pièce en dessous. Owen en a fait une méthode. Pour un ordre fixe, les nœuds à la profondeur $D$ valent (en espérance) le nombre de façons de paver la *forme* que l'ordre a construite à la profondeur $D$. Tout ordre candidat peut donc être noté, forme par forme, sans l'exécuter. Sa conclusion, tirée d'une analyse exhaustive : les formes qui dominent le total sont celles de tailles 121 à 185, et les meilleures formes dans cette fenêtre critique « forment un simple ordre de balayage par lignes » ([msg 2714](https://groups.io/g/eternity2/message/2714)). Toute la machinerie, probabilités de jonction comprises, est devenue la [théorie complexe](/fr/research/why/complex-theory/) ; cette page montre à quoi ressemblent ses réponses en pratique. Le carnet de laboratoire du projet met des chiffres sur le régime lui-même. Notons $k$ le nombre de côtés voisins déjà posés qu'une case présente au moment où la recherche l'atteint. Une loi de champ moyen dit que la case devrait admettre environ $4Rp^k$ placements candidats, où $R$ est le nombre de pièces encore en main et $p \approx 0{,}048$ la probabilité moyenne, pour E2, qu'un côté s'apparie à une couleur. Au début du remplissage intérieur, cela prédit environ 38 candidats pour une case $k=1$, 1,8 pour $k=2$, 0,09 pour $k=3$ et 0,004 pour $k=4$. Une énumération exacte contre le vrai jeu de 256 pièces (40 essais ensemencés par configuration) tombe à 20 à 40 % de ces prédictions et confirme les trois régimes qu'elles dessinent : les cases $k=1$ sont pour l'essentiel toujours remplissables ; les cases $k=2$ franchissent les 50 % de cases mortes quelque part entre 50 et 62 % de remplissage du plateau ; et les cases à trois voisins posés ou plus sont mortes dans 87 à 100 % des essais à tout niveau de remplissage, y compris au tout premier placement intérieur. (La loi est une idéalisation de champ moyen validée pour les statistiques de couleurs d'Eternity II, une seule instance ; ce n'est pas une affirmation sur l'appariement d'arêtes en général.) Lue comme règle de conception : un bon ordre est celui dont la frontière présente à chaque nouvelle case exactement deux voisins posés, assez pour élaguer, assez peu pour survivre. Le balayage par lignes le fait par construction, un $k=2$ constant après la première rangée ; tout ordre dont la frontière développe des poches concaves à trois côtés paie des cases quasi certainement mortes, quel que soit le taux de remplissage du plateau. Les mêmes régimes mesurent aussi ce que le retour arrière achète. Sans aucun retour arrière, un remplissage glouton aléatoire cale dans les 5 à 12 % premiers du plateau quel que soit le parcours : sur 8 graines par ordre, le calage médian est survenu au pas 15 pour le rang-majeur, 13 pour un parcours diagonal et 15 pour une spirale (le parcours diagonal s'étendait de 4 à 32), et aucune des 24 exécutions n'est allée plus loin. Tout parcours fabrique un coin concave fatal en une poignée de placements ; ce chiffre illustre la géométrie, ce n'est pas un banc d'essai de solveur. Le laboratoire ci-dessous rend l'ordonnancement visible. Il anime la séquence de visite de quatre ordres prédéfinis sur une grille 16×16 et trace, en direct, le comptage de contraintes (combien de voisins déjà posés possède chaque nouvelle case) ainsi que le cumul des jonctions collectées. (Il montre la *géométrie* ; pour faire courir de vraies résolutions le long de chemins que vous tracez vous-même, le pendant pratique est le [terrain de jeu des chemins de recherche](/playground/paths/).) > **[Figure]** Interactif : ordre de remplissage contre ramification — interactive: FillOrderLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Ce que la communauté a mesuré **Les courses de stratégies.** À la fin de 2007, la question était devenue quantitative : puzzles de référence partagés, comptages de nœuds en recherche complète et tableau de scores public. Le sommet du genre fut l'algorithme entièrement automatique de recherche de stratégie de doc_s_smith, qui a conçu un ordre de recherche épuisant le benchmark de taille 14 `hints15_2` en 89 794 nœuds, battant les 141 628 réglés à la main de Txibilis : la machine sur l'humain ([msg 2896](https://groups.io/g/eternity2/message/2896)). Txibilis a répliqué en deux jours avec 85 729 ([msg 2928](https://groups.io/g/eternity2/message/2928)) ; doc_s_smith s'interrogeait déjà sur les raisons de la force des humains dans cette discipline ([msg 2883](https://groups.io/g/eternity2/message/2883)). La leçon qui a survécu à la course : la qualité d'un ordre est mesurable, et les écarts ne sont jamais petits. **Dynamique contre fixe, mesuré.** L'argument fixe-contre-dynamique de 2007 a fait l'objet d'un petit test contrôlé en septembre 2008. Markus Zajc a exécuté trois ordres sur le 8×8 sans indice, chacun sur dix ordres de tuiles aléatoires pour annuler les effets de l'ordre d'entrée, tous sous un résolveur de contraintes : balayage simple, un ordre par valeur restante minimale qui prend toujours la case ayant le moins de candidats, et un ordre par réduction maximale qui prend la case dont le placement élague le plus. La valeur restante minimale l'a emporté ; le balayage est arrivé deuxième mais oscillait avec l'ordre d'entrée (sa meilleure exécution restait ~2× le vainqueur) ; la réduction maximale a fini dernière, car ensemencer tôt l'intérieur ouvert achète une grosse première coupe mais entraîne ensuite un facteur de ramification punitif à chaque retour arrière ([msg 5918](https://groups.io/g/eternity2/message/5918) ; les vidages de domaines par ordre sont dans son dossier de la zone de fichiers). C'est un petit plateau, mais c'est le duel le plus net de l'heuristique CSP classique contre un balayage fixe, et il atterrit là où les comptages de nœuds ultérieurs de la communauté aboutissent : la valeur réside dans le fait de nourrir la recherche de cases contraintes, qu'une règle dynamique ou un bon chemin fixe vous y mène. **La victoire du balayage est un fait de conception d'E2.** En avril 2008, Owen a construit des puzzles 16×16 où l'équilibre de couleurs bordure/intérieur était délibérément déséquilibré (2 couleurs de bordure et 19 d'intérieur, puis 14 et 15) et a noté les ordres balayage, centre d'abord et bordure d'abord sur chacun. Les conceptions déséquilibrées sont attaquables : le centre d'abord bat le balayage d'environ 150× sur la conception 2/19, la bordure d'abord l'emporte sur la 14/15. Sur la véritable répartition 5/17 d'E2, chaque écart *perd* : le centre d'abord coûte $1,22\times10^{60}$ nœuds contre $1,07\times10^{50}$ pour le balayage, parce que la conception équilibre la pavabilité de la bordure et de l'intérieur, donnant au puzzle « aucune zone faible par laquelle commencer à paver » ([msg 5263](https://groups.io/g/eternity2/message/5263), [5243](https://groups.io/g/eternity2/message/5243)). Le balayage par lignes n'est pas une loi de la nature ; c'est la bonne réponse à une conception adverse bien précise. **Le carré magique 10×16.** Pourquoi le balayage par lignes et pas, disons, un ordre par blocs 4×4 ? La règle empirique de la forme de frontière de Louis Verhaard : la plupart des ordres atteignent leur maximum de comptage de nœuds autour de la profondeur 160, donc ce qui compte, c'est la forme que votre ordre a construite *à cet endroit*, et la meilleure forme connue en profondeur 160 pour E2 est un rectangle 10×16 (avec deux coins remplis). Les ordres dont la frontière passe par « le carré magique 10×16 » sont quasi optimaux ; un balayage par blocs 2×2 le fait, un 4×4 non, ce qui est exactement l'écart que Max venait de mesurer ([msg 5868](https://groups.io/g/eternity2/message/5868), [5879](https://groups.io/g/eternity2/message/5879)). C'est la pièce que la seule courbe de comptage de contraintes ne peut pas voir : deux ordres peuvent payer les jonctions selon le même ordonnancement tout en différant par le périmètre de la région qu'ils construisent. **Pourquoi « résoudre la bordure d'abord » est un piège.** L'instinct humain le plus naturel, construire le cadre facile puis remplir le milieu, est quantitativement l'un des pires ordres, et en 2025 Owen et Peter McGavin ont détaillé pourquoi, précisément sur ce pic en profondeur 160. La bordure est réellement facile : après la pièce de départ, il y a environ $5,17\times10^{37}$ façons de la compléter, dont seulement 14 702 peuvent être remplies par les 196 pièces d'intérieur, si bien qu'environ $3,5\times10^{33}$ cadres doivent être essayés avant que l'un puisse ne serait-ce que *finir* ([msg 11572](https://groups.io/g/eternity2/message/11572)). Cela seul est déjà sans espoir, mais ce n'est pas le vrai problème. Le problème, c'est qu'avec le cadre fixé en premier, le comptage de nœuds continue de *grimper* après la bordure jusqu'à un pic d'environ $10^{57}$ vers 160 pièces, contre environ $10^{43}$ pour le balayage par rangées. Un ordre bordure d'abord s'engage tôt sur la bordure puis fonce droit dans un pic de quatorze ordres de grandeur plus haut que celui du balayage par rangées, car seul environ 1 cadre sur $10^{31}$ mène quelque part et chacun est coûteux à écarter ([msg 11573](https://groups.io/g/eternity2/message/11573)). Le balayage par lignes ne gagne pas en construisant une plus belle frontière, mais en ne payant jamais pour une bordure dont il ne peut pas encore savoir qu'elle est condamnée. **Mais quel balayage ?** Même au sein des balayages par lignes, il y a huit orientations : quatre coins de départ, rangées ou colonnes ([msg 6018](https://groups.io/g/eternity2/message/6018)). Max a mené sur plusieurs jours des estimations par échantillonnage de la taille de l'arbre complet par orientation : de droite à gauche se maintenait stable juste sous $2,7\times10^{40}$ nœuds, tandis que de bas en haut, de gauche à droite (l'orientation qui connecte le plus tôt la pièce de départ obligatoire, et celle qu'utilisait déjà Verhaard) tournait autour de $2,3\times10^{40}$ ([msg 6015](https://groups.io/g/eternity2/message/6015), [6023](https://groups.io/g/eternity2/message/6023)). Un choix de folklore devenu un ~15 % mesuré : minuscule à côté des ordres de grandeur ci-dessus, mais gratuit. **Des écarts qui ont payé.** L'orthodoxie de l'ordre de balayage a été constamment mise à l'épreuve, et l'a le plus souvent emporté, mais pas toujours. Owen lui-même a résolu son défi 14×14 avec un ordre en *carrés décroissants* après le blocage du balayage ; sur les plateaux irréguliers, l'argument d'équilibre ne tient plus ([msg 3124](https://groups.io/g/eternity2/message/3124)). Des hybrides ont été proposés, débutant en carrés croissants (moins coûteux au départ) puis basculant vers le balayage avant le pic de mi-profondeur ([msg 6142](https://groups.io/g/eternity2/message/6142)). Et Max a trouvé une véritable amélioration intra-balayage : au début d'une rangée, les candidats de bordure qui ne diffèrent que par leur seconde couleur de bordure non appariée sont équivalents : réfutez-en un et vous les avez tous réfutés. Verhaard, ravi (« Enfin quelque chose qui bat le simple balayage par rangées ! »), l'a implémentée et a confirmé ~10 % de l'espace de recherche éliminé à un coût quasi nul ([msg 5980](https://groups.io/g/eternity2/message/5980), [5983](https://groups.io/g/eternity2/message/5983), [6062](https://groups.io/g/eternity2/message/6062)). ### Des écarts qui n'ont pas payé (mesures du carnet) La communauté a surtout publié les écarts qui avaient un argument pour eux. Le carnet de laboratoire du projet garde l'autre espèce, des ordres séduisants qui ont perdu, et les régimes $k$ ci-dessus savent nommer le mécanisme de chacun. **Les spirales paient une taxe de fermeture.** Sur un banc d'essai d'intérieur 14×14 bordé (8 graines par bras), une spirale de l'extérieur vers l'intérieur s'est coincée à la profondeur 26 sur les 8 graines, au coin de fermeture de son premier anneau. Une spirale à pourtour libre a calé aux profondeurs 133 à 141 avec 0 complétion, contre 344 à 347 pour un balayage par lignes ; avec toutes les assistances du moteur activées, elle butait encore à 131 à 140 avec 0 complétion en 300 s, contre 446 à 448 pour le balayage. La loi en $k$ dit pourquoi : tout le premier anneau d'une spirale à pourtour libre tourne à un voisin posé ou moins par case, une ramification presque impossible à élaguer, tandis qu'une spirale bordée paie une *taxe de fermeture* : chaque anneau porte 4 ou 5 cases à trois voisins posés à ses coins et à son raccord, et les cases à trois côtés sont presque irremplissables. Le balayage par lignes est l'ordre de Boucle d'or, deux voisins constants et une seule zone de dégâts active. **Partir des indices perd.** « Commencer là où est l'information » sonne juste et pointe à l'envers. Dans un duel de 60 s sur le vrai puzzle (une configuration, une exécution, à lire donc comme notre test et non comme une réfutation), un ordre centré sur les indices, s'étalant depuis les cinq cases d'indice, a atteint la profondeur 42 (62 arêtes appariées) tandis qu'un ordre dynamique par case la plus contrainte, qui en pratique dévore d'abord la bordure tout en restant libre de l'abandonner (au contraire du cadre engagé du piège plus haut), atteignait la profondeur 164 (282 arêtes appariées). Les cases autour des indices centraux portent les domaines de pièces les plus *larges* du plateau ; l'ordre centré sur les indices donne la priorité exactement aux cases les moins contraintes. **Un X à travers les indices perd aussi.** Pré-engager deux diagonales larges de 3 cases passant par les cinq indices, puis remplir vers l'extérieur, a fini 51 arêtes appariées sous sa référence (396 contre 447 à budgets identiques, une seule graine). Trois expériences, un motif, énoncé comme un motif et non comme un théorème : chaque ordre statique que nous avons essayé qui passe tôt par des cases intérieures à large domaine a perdu. Un ordre statique n'esquive pas la région difficile ; il choisit quelle région devient la région difficile. Il choisit aussi où atterrissent les échecs : [là où s'entassent les mésappariements](/fr/research/why/mismatch-geometry/) sur un plateau presque parfait suit l'ordre de parcours, centre-bas pour les balayages de haut en bas, haut pour ceux de bas en haut (visible sur les plateaux de classe 469 de la communauté elle-même), coins pour les spirales partant du centre. Un ordre de remplissage ne décide pas seulement combien vous échouez, mais où. La littérature académique aboutit au même endroit. Ansotegui, Bejar, Fernandez et Mateu, qui ont fait des puzzles d'appariement d'arêtes des benchmarks SAT/CSP, travaillaient avec des ordres statiques de la famille damier-plus-spirale-centrale ; rejoué dans notre moteur sans le filtrage all-different complet que leurs modèles supposent, cet ordre a fait exploser les comptages de nœuds d'environ 600×. Et la base de retour arrière de l'étude hyper-heuristique de 2012 de Wauters, Vancroonenburg et Vanden Berghe a fait courir le balayage par lignes contre spirale, spirale inverse et ordres en miroir, et a trouvé le balayage significativement meilleur : une redécouverte indépendante de la thèse de la liste de diffusion. ### La recherche en peigne : la géométrie des scores élevés Tout ce qui précède optimise une recherche *complète*, dont le comptage de nœuds culmine près de la profondeur 160. En octobre 2008, alors qu'il gardait en privé les plateaux qui allaient remporter le prix d'examen de 10 000 dollars, Verhaard a répondu à une autre question d'Owen : quel est le meilleur ordre lorsqu'on poursuit un *score* partiel, et qu'on vit donc bien plus profond dans le plateau ([msg 6111](https://groups.io/g/eternity2/message/6111)) ? Sa réponse nommait une géométrie : les meilleurs ordres qu'il avait trouvés ressemblent à une **recherche en peigne** (la plupart des rangées parcourues horizontalement, puis les rangées restantes parcourues verticalement), avec la longueur des dents liée à la cible : « Plus le score que vous visez est bas, plus les dents du peigne s'allongent » ([msg 6112](https://groups.io/g/eternity2/message/6112)). Max avait convergé de façon indépendante vers presque le même ordre (douze rangées de balayage, puis balayage par colonnes) et a rapporté des scores « d'environ 1 arête plus bas » que ce qu'accomplissait le solveur de Louis ([msg 6126](https://groups.io/g/eternity2/message/6126)). L'intuition : une recherche complète doit franchir le goulet d'étranglement de la profondeur 160 le plus économiquement possible ; une recherche de score élevé veut au contraire de nombreuses façons peu coûteuses de *terminer*. Chaque dent verticale est une colonne courte, presque indépendante, dont les échecs sont locaux, si bien que des frontières profondes et à score élevé sont atteintes encore et encore. Le peigne était l'une des deux moitiés de la machine derrière le 467 ; l'autre moitié, le [glissement d'arêtes à seuil de profondeur](/fr/research/build/reduce/edge-slipping/), décidait de ce que les dents avaient le droit de placer. Et les deux étaient réglées *conjointement* : Verhaard optimisait l'ordre de remplissage et le tableau de glissements ensemble à l'aide d'une chaîne de Markov sur (profondeur, glissements utilisés), construite à partir de probabilités d'ajustement par profondeur mesurées ([msg 6423](https://groups.io/g/eternity2/message/6423)). Conception d'ordre par le calcul, non par le folklore. Le moteur complet est sur [la page eii de Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/). ### Le peigne, reproduit Le peigne a dormi dix-huit ans dans l'histoire des records avant que nous ne l'essayions chez nous ; c'est la relecture des messages ci-dessus qui a fait remonter le levier. Greffer la géométrie du peigne sur un producteur à recherche en faisceau écrit de zéro (rangées hautes en rang-majeur, rangées basses remplies en courtes dents verticales) a fait passer son meilleur partiel brut de 455 à 457 arêtes appariées sur 480, sur des plateaux aux cinq indices stricts, par le seul ordre de visite ; rien d'autre n'a changé. Derrière cette phrase il y a un balayage, pas un coup de chance : cinq ordres (rang-majeur plus des coupes de peigne après les rangées 8, 10, 12 et 14) croisés avec trois largeurs de faisceau (2048, 8192 et 16384), 24 graines chacun à calcul égal, sur 8 cœurs. Le nouveau plafond n'apparaît qu'au faisceau le plus large, où la coupe 14 a atteint 457 sur une graine et la coupe 12 456 sur deux, chaque plateau vérifié de trois façons indépendantes (un re-scoreur indépendant, un vérificateur externe et le compte propre du producteur ; placement strict des cinq indices, 256 pièces toutes distinctes). Aux largeurs plus petites, le peigne égale le meilleur du rang-majeur. Ce que le peigne déplace de façon fiable, c'est le plancher et le milieu de la distribution. À faisceau 2048, les coupes 10 et 12 relèvent le minimum sur 24 graines de 446 à 449 et la médiane de 449 à 451 ; au faisceau le plus large, la médiane de la coupe 12 gagne une arête. La coupe 12 atteint aussi 455, l'ancien plafond du rang-majeur, à la moitié de la largeur de faisceau, et à faisceau 8192 un balayage de 24 graines produit 15 plateaux à 453 ou mieux contre 9 pour le rang-majeur : +67 % de bons plateaux de départ par unité de calcul. La règle de Verhaard sur la longueur des dents tient aussi par le haut. Les dents longues (coupe 8, dents de 8 cases) régressent sous le rang-majeur à toutes les largeurs ; les dents courtes gagnent. La coupe 12, l'exact « douze rangées, puis colonnes » de Max, est la meilleure pour toute la distribution, tandis que la coupe 14 et ses dents de 2 cases trouve le meilleur plateau isolé sur une médiane plus basse : une géométrie de finition plus fine, à plus forte variance. Le mécanisme est l'intuition énoncée plus haut, désormais mesurée : chaque dent courte est une colonne presque indépendante dont les échecs restent confinés, si bien que des frontières profondes à score élevé sont atteintes encore et encore. L'ordre décide aussi où finit le mou récupérable. Une re-résolution exacte des trois dernières rangées hisse un plateau rang-majeur de 455 à 457 et ne fait rien pour un plateau peigne à 457 : la région remplie en dernier et la moins contrainte du peigne, ce sont ses dents verticales, pas ses rangées basses, donc une réparation par bande de rangées vise le mauvais endroit. Une re-résolution exacte alignée sur les dents, par bande de colonnes, amène les plateaux peigne à 459 et pas plus loin, parce que les dents sortent du faisceau déjà exactement optimales (un solveur exact a prouvé optimale une région de dents de 32 cases en 21 s environ) ; le peigne dépense pendant la construction le mou que la réparation aurait récupéré. Les deux routes convergent à 459 : le peigne encaisse le score en avance, le rang-majeur le laisse dans une queue récupérable, et ordre plus réparation de fin de partie moissonnent le même mou. Pour l'échelle, 455, 457 et 459 sont des comptes d'arêtes appariées sur plateaux aux cinq indices stricts, issus d'un producteur de carnet sur 8 cœurs ; les plateaux communautaires sont plus haut, et [la page des records](/fr/research/records/) tient le classement. ## L'autre ordre : quelle pièce essayer en premier Tout ce qui précède ordonne des *cases*. Le bouton jumeau est l'ordre des *pièces* essayées dans une case : le duel de Zajc portait sur la prochaine case à ouvrir, celui-ci porte sur le candidat à y glisser en premier. La réponse du carnet est un nul propre. Au sein d'un remplissage rang-majeur fixe, réordonner la liste de candidats de chaque case par rareté globale des couleurs (couleurs les plus rares d'abord) n'a rien changé de mesurable sur 8 graines par bras : à 60 s d'horloge égales, la médiane était de 389 arêtes appariées (indices épinglés, puzzle à cinq indices) dans *chaque* bras, ordre de référence, rareté d'abord, et un contre-ordre délibéré (couleurs les plus abondantes d'abord) conçu pour perdre. Le contrôle n'a pas perdu ; sa meilleure exécution (419) a battu la meilleure de la référence (415). Le débit de nœuds était plat d'un bras à l'autre, 8,2 à 9,6 millions de nœuds par seconde : le réordonnancement est gratuit, et sans valeur, dans les deux sens. (Avant la comparaison, le bras de référence a été vérifié identique nœud à nœud au moteur non modifié.) Le mécanisme est un signal affamé. Quand un balayage rang-majeur atteint une case, la liste de candidats est déjà filtrée à la poignée de pièces s'appariant à deux couleurs fixées, et un élagage global de faisabilité offre-demande exploite déjà la rareté des couleurs sur tout le stock restant ; l'ordre par rareté re-dérive, plus grossièrement, une information que la recherche utilise déjà, et savoir laquelle de trois pièces légales passe en premier compte peu quand le seau sera de toute façon épuisé. Cadrons-le comme mesuré : l'ordre des candidats a été inerte dans notre moteur à un point de fonctionnement (une pile d'élagages, un budget de 60 s, des signaux de rareté globaux seulement), et non « l'ordre des valeurs ne compte jamais nulle part ». Cela rime avec la seule victoire intra-balayage plus haut : les ~10 % de Max venaient de la *suppression* de candidats de bordure, pas de leur réordonnancement. Les gains vivent dans l'élagage et dans l'ordre des cases. ## Étape par étape 1. **Observez le balayage par lignes.** Après la première rangée, presque chaque placement rencontre exactement deux voisins posés : à gauche et en dessous. La courbe de contraintes se stabilise à 2, et le cumul des jonctions grimpe régulièrement : la recherche paie au fur et à mesure. 2. **Passez à la spirale.** Tout le premier anneau (60 placements) arrive avec au plus un voisin posé : soixante choix quasiment sans contrainte empilés avant que l'intérieur ne commence à les rembourser. La courbe cumulée fléchit sous la référence du balayage par lignes exactement là où l'arbre peut le moins se le permettre. 3. **Essayez la diagonale.** Surprise : les comptages ressemblent presque à ceux du balayage par lignes. C'est la limite du point de vue par comptage de voisins : la frontière de la diagonale est plus longue que celle d'un balayage pendant une bonne partie du milieu de partie, un effet de forme que seule la [théorie complexe](/fr/research/why/complex-theory/) (ou la règle magique du 10×16) peut noter. 4. **Sélectionnez le peigne à des dents de 4.** Douze rangées de balayage, puis des dents verticales, l'ordre de Max du [msg 6126](https://groups.io/g/eternity2/message/6126). Remarquez la petite falaise à chaque nouvelle dent : la première colonne paie une case faible, à 1 voisin, à sa base, le prix de la géométrie des scores élevés. 5. **Allongez les dents.** Une plus grande part du plateau passe en mode vertical et les placements faibles se multiplient. C'est le compromis de Verhaard, dit visuellement : plus le score que vous visez est bas (plus vous autoriserez de glissements), plus les dents que vous pouvez vous permettre sont longues. 6. **Puis faites-le courir pour de vrai.** Le [terrain de jeu des chemins de recherche](/playground/paths/) vous permet de tracer n'importe lequel de ces chemins, ou le vôtre, sur un vrai puzzle et de regarder des solveurs les parcourir en course, avec une estimation de pic de plateau en direct à côté. ## Ce que cela coûte À l'exécution, rien : un ordre de remplissage fixe est un tableau précalculé de 256 indices de case, et « choisir la case suivante » est un incrément d'indice : $O(1)$, zéro branchement, ce qui est précisément l'argument de vitesse qui a tué l'ordonnancement dynamique pour E2 ([msg 5860](https://groups.io/g/eternity2/message/5860)). Tout le coût et tout le bénéfice résident dans l'arbre que l'ordre induit : - **Entre familles d'ordres, des ordres de grandeur.** Le centre d'abord sur E2 est $10^{10}$ fois plus coûteux que le balayage ([msg 5263](https://groups.io/g/eternity2/message/5263)) ; un ordre par blocs 4×4 coûte ~70× de plus que le balayage 1×1 selon les estimations de théorie complexe de Max, l'écart que résume la règle magique du 10×16 ([msg 5867](https://groups.io/g/eternity2/message/5867)). - **Au sein d'une famille, des pourcentages mesurables.** Bas-haut-gauche-droite contre balayage droite-à-gauche : ~15 % ([msg 6023](https://groups.io/g/eternity2/message/6023)) ; élagage par équivalence des pièces de bordure : ~10 % ([msg 6062](https://groups.io/g/eternity2/message/6062)). Bon à prendre, jamais décisif. - **Choisir de travers est invisible.** Un mauvais ordre ne produit aucune erreur, juste un arbre $10^{10}$ fois plus gros, silencieusement. Voilà pourquoi la véritable avancée de la communauté ne fut aucun ordre en particulier, mais la capacité à *noter un ordre avant de l'exécuter* : les comptages de formes d'Owen, puis la [théorie complexe](/fr/research/why/complex-theory/), puis le réglage par chaîne de Markov de Verhaard combinant ordre et calendrier de glissements ([msg 6423](https://groups.io/g/eternity2/message/6423)). Chaque moteur record depuis lors a traité l'ordre comme un objet conçu et calculé : le peigne-plus-tableau-de-glissements de Verhaard ([eii](/fr/research/lab/experiments/louis-verhaard/eii/)), le balayage bas-gauche choisi par théorie complexe de McGavin, et l'ordre de balayage fixe sous les coupures à seuil de profondeur de [Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/). Vingt ans de science de l'ordre de balayage se condensent en une seule instruction : avant de dépenser la moindre heure-CPU, dépensez une milliseconde à noter le chemin. ## À lire aussi - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - [eii de Verhaard : le solveur qui a remporté l'unique prix](https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/eii/) — Le moteur derrière le 467, le seul score d'Eternity II jamais récompensé, reconstitué à partir des propres messages de Louis Verhaard sur la liste de diffusion : élagage prospectif, ordres de remplissage en peigne, décalage d'arête conditionné par la profondeur, calendrier de décalage réglé par chaîne de Markov. Et pourquoi son propre binaire Win32, sans code source, ne peut être ni compilé ni exécuté sur cette machine. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [Le glissement d'arête](https://eternity2.dev/fr/research/build/reduce/edge-slipping/) — Le coup primé de Louis Verhaard : laisser le backtracker poser une pièce non concordante, mais seulement à des profondeurs choisies près du bas du plateau. Chaque glissement autorisé coûte un point de score et multiplie de façon astronomique le nombre de plateaux cibles. Voilà pourquoi son 467 a été trouvé plus de cinquante fois, et l'ancêtre direct des ruptures de Blackwood. - [Redémarrages et lois à queue lourde](https://eternity2.dev/fr/research/build/backtracking/restarts/) — Lancez deux fois le même backtracker sur le même casse-tête et les temps d'exécution diffèrent d'un facteur dix, cent, mille. La communauté l'a mesuré en 2007 ; la littérature CSP l'avait déjà nommé. Le remède (couper, rebattre, redémarrer) explique pourquoi chaque solveur record depuis est un portefeuille de redémarrages. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Redémarrages et lois à queue lourde > Lancez deux fois le même backtracker sur le même casse-tête et les temps d'exécution diffèrent d'un facteur dix, cent, mille. La communauté l'a mesuré en 2007 ; la littérature CSP l'avait déjà nommé. Le remède (couper, rebattre, redémarrer) explique pourquoi chaque solveur record depuis est un portefeuille de redémarrages. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/backtracking/restarts/ - Mise à jour: 2026-07-02 - Sujets: backtracking, search-space - Source: L'expérience de Txibilis sur 500 casse-têtes : les redémarrages gagnent 52 % des courses, mais toute la queue (groups.io message 2822) — https://groups.io/g/eternity2/message/2822 - Source: L'affirmation originale d'antminder, backtracking avec redémarrages multiples (groups.io message 2420) — https://groups.io/g/eternity2/message/2420 - Source: Verhaard sur ce que l'échantillonnage par redémarrages a révélé du paysage des scores (groups.io message 5182) — https://groups.io/g/eternity2/message/5182 - Source: antminder sur la recherche sous contrainte de délai, où la probabilité dans la fenêtre l'emporte sur une meilleure moyenne (groups.io message 3089) — https://groups.io/g/eternity2/message/3089 - Source: Blackwood sur le plafond de 50 milliards, un nombre « arbitraire » (groups.io message 10066) — https://groups.io/g/eternity2/message/10066 - Source: La ferme de 20 PC redémarrés à la main de McGavin pour le recensement 9×9 (groups.io message 9342) — https://groups.io/g/eternity2/message/9342 - Source: La résolution 10×10 de McGavin : 92 907 recherches de rangée redémarrées et la loi des grands nombres (groups.io message 9688) — https://groups.io/g/eternity2/message/9688 - Source: Le fil sur l'hygiène du PRNG, période du générateur contre campagnes de redémarrages (groups.io message 6798) — https://groups.io/g/eternity2/message/6798 - Source: Gomes, Selman & Kautz, Heavy-Tailed Phenomena in Satisfiability and Constraint Satisfaction Problems (J. Automated Reasoning, 2000) — https://doi.org/10.1023/A:1006314320276 - Source: Gomes, Selman & Kautz, Boosting Combinatorial Search Through Randomization (AAAI-98) — https://cdn.aaai.org/AAAI/1998/AAAI98-061.pdf - Source: Luby, Sinclair & Zuckerman, Optimal Speedup of Las Vegas Algorithms (Information Processing Letters, 1993) — https://doi.org/10.1016/0020-0190(93)90029-9 --- Lancez le même backtracker sur deux casse-têtes tirés de la même distribution et les temps de résolution ne diffèrent pas de quelques pourcents ; ils diffèrent par puissances de dix. La communauté Eternity II l'a mesuré en octobre 2007. En réponse à l'affirmation d'antminder selon laquelle le « backtracking avec redémarrages multiples » battait le backtracking simple ([groups.io message 2420](https://groups.io/g/eternity2/message/2420)), un Txibilis sceptique a généré 500 casse-têtes 7×7 aléatoires et fait courir les deux politiques sur chacun, le solveur à redémarrages coupant à 10 millions de nœuds par tentative. Le redémarreur n'a gagné que 52 % des courses, à pile ou face. Il a alors examiné les *marges* : parmi les 240 courses gagnées par le backtracker simple, sa plus grande marge de victoire était de 90 millions de nœuds. Parmi les 260 gagnées par le redémarreur, la plus grande marge était de **50 463 millions**, et dans 45 de ces courses la seule marge du redémarreur dépassait la meilleure victoire du solveur simple ([message 2822](https://groups.io/g/eternity2/message/2822)). Une colonne du registre est bornée ; l'autre ne l'est pas. Cette asymétrie porte un nom dans la littérature : une **distribution des temps d'exécution à queue lourde**. Gomes, Selman et Kautz avaient décrit exactement ce phénomène dans la recherche SAT et CSP une décennie plus tôt ([AAAI-98](https://cdn.aaai.org/AAAI/1998/AAAI98-061.pdf)), et l'avaient formalisé dans [leur article de 2000](https://doi.org/10.1023/A:1006314320276) : pour le backtracking sur des instances difficiles, la fonction de survie décroît comme une loi de puissance, $P(T > t) \approx C\,t^{-\alpha}$, et non comme une exponentielle. La décroissance est si lente que pour $\alpha \le 1$ la *moyenne* du temps d'exécution est infinie. Chaque record d'Eternity II depuis, du [467 de Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/) et du [10×10 de McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) à la [vague des 468–470](/fr/research/lab/experiments/joshua-blackwood/solver/), a été trouvé par un solveur bâti autour de ce fait. ## Pourquoi les queues apparaissent Un backtracker en profondeur d'abord avec un [ordre de remplissage](/fr/research/build/backtracking/fill-order/) fixe prend ses décisions les moins coûteuses en premier, puis ne les revisite jamais : un solveur à balayage par rangées parvenu à la profondeur 150 a, en pratique, définitivement figé ses trois premières rangées. Si l'un de ces placements précoces est faux (légal, plausible, mais sur aucun plateau complétable), tout le sous-arbre en dessous est stérile, et le solveur doit *épuiser* ce sous-arbre avant que le mécanisme ordinaire de backtracking ne remonte assez haut pour défaire l'erreur. La taille des sous-arbres est exponentielle en la hauteur du mauvais tournant, si bien qu'un mauvais engagement à la profondeur 3 coûte exponentiellement plus cher qu'un à la profondeur 30. La queue de la distribution des temps d'exécution est précisément la distribution des mauvais engagements précoces, hérités pour toujours. Le revers est une *gauche* également épaisse : certaines exécutions réussissent toutes leurs décisions précoces par chance et se terminent d'une rapidité absurde. Le point de Gomes, Selman et Kautz est que les deux queues procèdent du même mécanisme d'amplification de la variance, et que la bonne réponse n'est pas une meilleure exécution moyenne mais *plus de tirages de la distribution*. Louis Verhaard a ajouté une observation propre à Eternity II. Il s'était d'abord servi des redémarrages comme instrument de sondage, dans l'espoir que les régions à haut score se regroupent comme des chaînes de montagnes : trouver l'Himalaya par échantillonnage grossier, puis grimper. Ce que son échantillonnage a réellement trouvé, c'est que les hauts scores sont dispersés « comme des gratte-ciels dans les villes » : un ou quelques-uns n'importe où, et en trouver un ne dit rien sur l'endroit où se dresse le suivant ([message 5182](https://groups.io/g/eternity2/message/5182)). Il n'y a aucun signal régional qui vaille qu'on s'attarde, ce qui ôte le dernier argument en faveur de la fidélité à une exécution qui peine. Le fil d'origine portait une réserve : Txibilis raisonnait que les redémarrages ne devraient payer que lorsque l'instance a *beaucoup* de solutions (autant de chances d'un préfixe chanceux) et moins sur un banc d'essai à solution unique. Pour Eternity II la distinction est sans objet, à l'avantage du chercheur : la [théorie complexe](/fr/research/why/complex-theory/) situe le casse-tête complet sans indice à environ $1{,}15 \times 10^7$ solutions, dont chacune l'emporte, et la chasse aux scores partiels compte des cibles astronomiquement plus nombreuses encore. ## Le remède Le remède est d'une simplicité presque gênante, et la recette de 2007 d'antminder le contient déjà tout entier : lancer le backtracker pour un budget fixe, et si aucune solution n'est apparue, **arrêter, rebattre l'ordre des pièces, et repartir du plateau vide** ([message 2420](https://groups.io/g/eternity2/message/2420)). Deux ingrédients comptent : - **La coupure** tronque la queue droite par décret. Aucune tentative ne peut coûter plus que le budget $c$, si bien que la colonne non bornée du registre de Txibilis cesse simplement d'exister. - **Une randomisation fraîche** (un ordre de candidats rebattu, une ouverture différente) fait de chaque tentative un tirage indépendant de la distribution des temps d'exécution, plutôt qu'un rejeu de la même descente vouée à l'échec. Sans elle, redémarrer n'est que la même exécution frappée d'amnésie. Quand la distribution est connue, il existe une coupure *fixe* optimale. Quand elle ne l'est pas, ce qui est le cas usuel, [Luby, Sinclair et Zuckerman](https://doi.org/10.1016/0020-0190(93)90029-9) ont prouvé qu'on n'en a guère besoin : leur planning universel $1,1,2,1,1,2,4,1,1,2,\ldots$ (chaque puissance de deux apparaissant selon un motif autosimilaire) reste à un facteur logarithmique près de la coupure fixe optimale sur *toute* distribution, et aucun planning universel ne peut faire mieux en général. À quoi ressemble la production, vingt ans plus tard : - **Le moteur de Blackwood** plafonne chaque tentative à 50 milliards de nœuds et rebat les pièces d'ouverture, le premier coin et la rangée du bas avant chaque nouvelle exécution, si bien qu'aucune paire de tentatives ne reparcourt le même préfixe ([la page du solveur](/fr/research/lab/experiments/joshua-blackwood/solver/) couvre la machinerie). Interrogé sur le choix du chiffre de 50 milliards, Blackwood a répondu : « Le nombre 50 G était arbitraire. J'ai essayé quelques grands nombres (au-delà de 1 G) et ça ne changeait pas grand-chose » ([message 10066](https://groups.io/g/eternity2/message/10066)). Cette insensibilité est elle-même une signature de queue lourde : quand l'ennemi est la queue, presque n'importe quelle coupure qui épargne le corps de la distribution fonctionne. - **Les fermes de McGavin** sont la même politique à l'échelle humaine. Son recensement des solutions 9×9 tournait sur « environ 20 PC » glanés pour atteindre 60 cœurs, chacun exécutant un backtracker à balayage par rangées à partir d'un tableau de pièces rebattu aléatoirement, et il « redémarrait manuellement ceux qui semblaient bloqués » ([message 9342](https://groups.io/g/eternity2/message/9342)). Sa résolution en 2017 du 10×10 de Brendan Owen, le banc d'essai résolu le plus difficile de la communauté, était un portefeuille de redémarrages par construction : 92 907 recherches indépendantes de première rangée, réparties sur plus de 400 cœurs, là où la théorie prédisait environ un succès pour 70 000. Son propre résumé : « aucune méthode nouvelle, juste de la persévérance systématique et la loi des grands nombres » ([message 9688](https://groups.io/g/eternity2/message/9688)). Il existe aussi une lecture stratégique, énoncée sur la liste dès 2007 : sous la contrainte d'un délai de concours, un solveur à *moins bonne moyenne* mais dont davantage de masse de probabilité tombe dans la fenêtre de temps est le meilleur solveur ([message 3089](https://groups.io/g/eternity2/message/3089)). Les redémarrages sont exactement ce compromis : ils remodèlent la distribution autour de son corps, au prix de jamais mener à terme une exécution de marathon. > **Alimentez le portefeuille en hasard authentique** > > Un portefeuille de redémarrages n'est aussi divers que ses rebattages. En 2009 un membre s'inquiétait que le générateur standard de son solveur, de période $2^{32}$, puisse silencieusement limiter la part de l'arbre que ses redémarrages pourraient jamais échantillonner ([message 6798](https://groups.io/g/eternity2/message/6798)) ; la réponse de la liste fut le Mersenne Twister, le remède standard pour la simulation non cryptographique ([message 6801](https://groups.io/g/eternity2/message/6801)). Un PRNG faible ne fait pas planter une campagne de redémarrages ; il rétrécit discrètement la distribution dans laquelle on tire. ## Regardez la queue s'effondrer Le laboratoire ci-dessous tire 400 exécutions de solveur d'un mélange à queue lourde initialisé par graine, calibré pour correspondre à la mesure de 2007 : un corps d'exécutions chanceuses autour de quelques millions de nœuds, une queue qui s'étire cinq ordres de grandeur au-delà. Puis il vous confie la coupure. > **[Figure]** Interactif : temps d'exécution à queue lourde et redémarrages — interactive: RestartTailLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pas à pas 1. **Regardez l'histogramme se remplir.** La médiane (marqueur émeraude) se stabilise dès les premières dizaines d'exécutions et ne bouge presque plus. La moyenne (marqueur rose) ne se stabilise jamais : chaque exécution qui tombe dans la queue la tire vers la droite. Une statistique dominée par ses échantillons les plus rares est la définition visuelle d'une queue lourde. 2. **Lisez l'axe logarithmique.** Le corps se situe près de $10^6$ nœuds ; les pires exécutions dépassent $10^{11}$, le même écart d'ordres de grandeur que le registre 90 M contre 50 463 M de Txibilis, sur une distribution assez petite pour être tracée. 3. **Maintenant coupez.** La coupure par défaut est de 10 millions de nœuds, celle de Txibilis lui-même. Chaque exécution ambre qui l'aurait pulvérisée est abandonnée à la ligne pointillée puis relancée. La moyenne et le P99 de la ligne à redémarrages chutent bien en dessous de la ligne à exécution unique : à la queue on ne survit pas, on la *supprime*. 4. **Coupez trop profond.** Faites glisser la coupure en deçà du bord gauche du corps. La probabilité de succès par tentative s'effondre, le nombre de tentatives attendu explose, et le total attendu grimpe. À l'extrême, aucune exécution ne peut aboutir et la politique ne réussit jamais. La coupure doit épargner les exécutions chanceuses sur lesquelles elle mise. 5. **Remarquez comme le point optimal est plat.** Entre « trop gourmand » et « trop patient » s'étend un plateau large de plusieurs ordres de grandeur où le total attendu ne varie presque pas. Les 50 milliards « arbitraires » de Blackwood, trouvés empiriquement, sont ce plateau qui s'exprime. ## Ce que ça coûte Fixez une coupure $c$ et soit $F(c) = P(T \le c)$ la chance qu'une tentative unique réussisse dans le budget. Les tentatives ratées coûtent $c$ chacune et leur nombre est géométrique, si bien que le travail total attendu jusqu'au premier succès est $$ \mathbb{E}[T_c] \;=\; \frac{1 - F(c)}{F(c)}\,c \;+\; \mathbb{E}[T \mid T \le c]. $$ Minimiser sur $c$ donne le meilleur temps à coupure fixe $\ell^{\ast} = \min_c \mathbb{E}[T_c]$. Face à une queue lourde $P(T > t) \approx C\,t^{-\alpha}$ ce n'est pas un raffinement mais un sauvetage : pour $\alpha \le 1$ la moyenne sans redémarrage $\mathbb{E}[T]$ diverge tandis que $\ell^{\ast}$ reste finie : la politique transforme une espérance infinie en une espérance finie. Et le théorème de Luby chiffre le prix de l'ignorance de $F$ : le planning universel atteint un temps attendu de $O(\ell^{\ast} \log \ell^{\ast})$ sans aucune connaissance de la distribution, et ce facteur logarithmique est optimal. Le prix du redémarrage est ce qu'il jette : un plateau partiel profond, abandonné. Sur Eternity II ce prix est exceptionnellement bas, pour deux raisons. Premièrement, l'[entonnoir de la théorie complexe](/fr/research/why/complex-theory/) : les exécutions calent contre un mur de profondeur à une profondeur caractéristique, et progresser au-delà est rare d'une manière qui ne se cumule pas. Les 92 907 recherches de rangée 10×10 de McGavin ont enregistré une profondeur de placement maximale de 88 à 99 (sur 100) pour toutes sauf une, avec bien plus de la moitié de la masse sur trois profondeurs seulement ([message 9688](https://groups.io/g/eternity2/message/9688)). Une exécution plantée au mur pendant des heures ne détient aucun actif qu'une exécution fraîche ne puisse regagner en quelques minutes ; son « avancement » était un billet de loterie, déjà gratté. Deuxièmement, l'état du plateau ne porte aucun apprentissage : contrairement à un [solveur SAT à apprentissage de clauses](/fr/research/build/reduce/nogood-learning/), un backtracker simple qui meurt à la profondeur 190 n'a rien consigné du *pourquoi*, si bien que persister ne préserve non plus aucune connaissance. Ce qui est véritablement perdu, c'est le certificat. Un portefeuille de redémarrages échantillonne l'arbre ; il ne le balaie pas. McGavin le dit sans détour à propos de son recensement 9×9 : « je n'ai pas parcouru systématiquement tout l'arbre de recherche, si bien que j'ai pu manquer certaines solutions » ([message 9342](https://groups.io/g/eternity2/message/9342)). Pour prouver qu'une région est vide, les redémarrages sont le mauvais outil. Pour trouver une solution, ou un plateau record, dans un espace où votre temps d'exécution s'étend sur des puissances de dix, ils sont la seule politique sensée, et chaque moteur de la [chronologie des records](/fr/research/records/) les emploie. ## À lire aussi - [LADDER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lancer des centaines de courtes recherches bon marché sur le plateau, ne garder que les départs les plus profonds, et faire monter les survivants à travers des tours de plus en plus longs. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [Ordres de remplissage](https://eternity2.dev/fr/research/build/backtracking/fill-order/) — L'ordre dans lequel un algorithme de retour arrière visite les 256 cases est son unique liberté : il ne coûte rien à l'exécution et fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur. Vingt ans de science communautaire, des guerres fixe-contre-dynamique aux courses de stratégies, jusqu'au carré magique 10×16 et à la recherche en peigne de Verhaard, répondent tous à la même question : quel chemin à travers le plateau est le moins coûteux ? - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. --- # Les benchmarks de la communauté > Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/benchmarks/ - Mise à jour: 2026-07-21 - Sujets: backtracking, speed - Source: La proposition de recensement des coins 3×3 : « Suggestion for Benchmark/Test » (arthurhucksake), eternity2@groups.io, 2007-08 — https://groups.io/g/eternity2/message/2229 - Source: Txibilis lance la suite de benchmarks : « New round of benchmarks... », eternity2@groups.io, 2007-08 — https://groups.io/g/eternity2/message/1610 - Source: Les jeux de données « Benchmarks for Beginners » de Geoff, eternity2@groups.io, 2008-02 — https://groups.io/g/eternity2/message/4322 - Source: hints.20.3 entièrement énuméré : « Algorithmic Challenges related to E2 » (doc_s_smith), eternity2@groups.io, 2010-07 — https://groups.io/g/eternity2/message/7861 - Source: Les deux 9×9 explorés exhaustivement (istarinz), eternity2@groups.io, 2011-03 — https://groups.io/g/eternity2/message/8793 - Source: Le set_1 10×10 de Brendan résolu (Peter McGavin), eternity2@groups.io, 2017-09 — https://groups.io/g/eternity2/message/9686 - Source: La suite Sample Puzzles de Dave Clark et son format de fichier documenté (fichiers groups.io) — https://groups.io/g/eternity2/files/Sample%20Puzzles - Source: Les plateaux de benchmark de tailles variables, côtés 11 à 16 (fichiers groups.io) — https://groups.io/g/eternity2/files/Benchmarks --- Toute communauté de solveurs a besoin de problèmes de test, mais celle d'Eternity II subissait une contrainte supplémentaire : en août 2007, Christopher Monckton a revendiqué un copyright sur le dessin des pièces et a menacé de poursuites « toute circulation de celles-ci, sous quelque forme ou support que ce soit », allant jusqu'à disqualifier Brendan Owen à cause d'un fichier qui ne contenait même pas les vraies pièces ([messages 1342](https://groups.io/g/eternity2/message/1342) et [1358](https://groups.io/g/eternity2/message/1358)). La communauté a donc bâti sa culture de test autour de deux choses qui *pouvaient*, elles, être partagées : des comptages dérivés calculés à partir des pièces, et des casse-têtes du même type qu'E2 générés à neuf. Ce sont encore aujourd'hui les bonnes façons de calibrer un solveur. ## Le protocole de recensement : vérifier sans partager Si deux personnes transcrivent les mêmes 256 pièces et écrivent du code correct, leurs solveurs doivent s'accorder sur les comptages exhaustifs. Cette observation, publiée par arthurhucksake en août 2007, est devenue le test de correction standard de la communauté : paver le coin supérieur gauche 3×3 avec toutes les pièces d'E2 et compter. La réponse est **2 633 221** solutions, ou **2 582 369** sans la pièce indice imposée ([message 2229](https://groups.io/g/eternity2/message/2229), [2370](https://groups.io/g/eternity2/message/2370)). Le recensement des blocs 2×2 a suivi le même automne, avec deux programmes indépendants convergeant vers **5 248** blocs de coin, **292 012** blocs de bord et **4 059 952** blocs intérieurs ([message 3044](https://groups.io/g/eternity2/message/3044), [3046](https://groups.io/g/eternity2/message/3046)). Le protocole a fait ses preuves. Quand apal1969 a publié en 2009 les comptages, pièce centrale par pièce centrale, de tous les partiels 3×3 intérieurs, la vague de programmes indépendants a débusqué des bugs des *deux* côtés. Un vérificateur a découvert que sa propre pièce indice était tournée de 90°, et apal1969 lui-même a trouvé une erreur affectant chaque pièce centrale sauf une ([message 6625](https://groups.io/g/eternity2/message/6625), [6657](https://groups.io/g/eternity2/message/6657), [6666](https://groups.io/g/eternity2/message/6666)). Retrouver les nombres du consensus vous valait d'être accueilli, à moitié pour rire, dans le « Right Numbers Club » ([message 6869](https://groups.io/g/eternity2/message/6869)). Partager des comptages plutôt que des pièces ne posait aucun problème de copyright, et cela attrapait plus de bugs que n'importe quelle relecture de code. Les formats d'échange se sont cristallisés à la même période : la communauté s'est standardisée sur les fichiers `e2pieces.txt` / `e2hints.txt` du projet eternity2.net de Dave Clark, consignés explicitement pour que les outils puissent interopérer ([messages 3571](https://groups.io/g/eternity2/message/3571) et [3572](https://groups.io/g/eternity2/message/3572)). La métrique, elle, a mis plus de temps. Un débat « nœud contre pas » sur ce qu'un solveur devrait au juste compter s'est soldé par l'aveu qu'aucune métrique commune ne serait adoptée ([message 3946](https://groups.io/g/eternity2/message/3946)). La convention de Txibilis, selon laquelle un nœud est un *placement valide engagé* et le lookahead n'est pas compté ([message 3843](https://groups.io/g/eternity2/message/3843)), est celle qu'emploient la plupart des chiffres de l'époque, et la raison pour laquelle les anciennes affirmations de vitesse demandent de la prudence dès qu'on les compare. ## La suite Txibilis et la course au nombre de nœuds En août 2007, après un débat sur ce à quoi devrait ressembler un substitut équitable d'E2 (la distribution plate 17+5 des couleurs, avant tout), Txibilis a généré des plateaux du type d'E2 aux côtés 11 à 14 avec des variantes d'indices (les fichiers `tiles_N_5.17`), et Craig Easton a mis en place une base de résultats ([message 1610](https://groups.io/g/eternity2/message/1610), [1683](https://groups.io/g/eternity2/message/1683), [1784](https://groups.io/g/eternity2/message/1784)). La suite est aussitôt devenue une arène de compétition : le premier balayage complet du casse-tête avec indices de taille 12 par doc_s_smith a coûté 750 226 469 nœuds ([message 1862](https://groups.io/g/eternity2/message/1862)) ; deux mois de duel entre son chercheur automatique de stratégie et les ordres de remplissage construits à la main par Txibilis ont fait tomber la recherche complète du benchmark de taille 14 `hints15_2` à 89 794 nœuds, puis 85 729 ([message 2896](https://groups.io/g/eternity2/message/2896), [2928](https://groups.io/g/eternity2/message/2928)) : des ordres de grandeur en dessous du point de départ de la course, avec des stratégies conçues par machine et par humain se disputant la tête. Les mêmes semaines ont livré un avant-goût de l'autre levier : le solveur à propagation de contraintes du nouveau venu Geoff n'a parcouru que 198 nœuds pour trouver une première solution sur un benchmark avec indices 14×14 ([message 2902](https://groups.io/g/eternity2/message/2902)). Et à l'extrémité des poids lourds, Txibilis a épuisé l'ensemble de l'espace de recherche 14×14 (environ 2,2 × 10¹³ nœuds) avec l'aide des ordinateurs d'amis ([message 2550](https://groups.io/g/eternity2/message/2550)). La leçon de cette course est celle sur laquelle ce wiki revient sans cesse : le nombre de nœuds est une propriété de l'*ordre de remplissage*, et l'écart entre un ordre naïf et un ordre conçu se mesure en ordres de grandeur, pas en pourcentage. C'est précisément cet écart que la [théorie de la complexité](/fr/research/why/complex-theory/) a rendu par la suite calculable à l'avance. ## Benchmarks for Beginners En février 2008, Geoff a emballé la rampe d'accès : trois casse-têtes tirés du « Set 1 » généré par Brendan Owen (un 6×6 avec un indice, un 8×8 avec deux, un 10×10 avec trois), publiés directement dans le message avec un format auto-documenté ([message 4322](https://groups.io/g/eternity2/message/4322)). Des jeux de solutions complets ont suivi (le 6×6 a 65 solutions distinctes, 260 en comptant les rotations ; [message 4604](https://groups.io/g/eternity2/message/4604)), et la suite a accumulé des nombres de calibration canoniques vers lesquels on oriente encore les nouveaux venus : 260 solutions avec rotations et une recherche par balayage de lignes complet d'exactement 69 284 103 nœuds pour le 6×6 ([message 7771](https://groups.io/g/eternity2/message/7771), [7777](https://groups.io/g/eternity2/message/7777)). Si votre solveur obtient un comptage différent, votre solveur est faux ; c'est toute la proposition de valeur. ## Le duel du 12×12 à 40 indices En mai 2008, Max a mis en ligne une instance conçue à dessein, le 12×12 de Brendan à 40 indices (quatre coins 3×3 plus un 2×2 central), pour mesurer de combien la connaissance des « environnements » des indices réduit la recherche ([message 5453](https://groups.io/g/eternity2/message/5453)). Ce qui a suivi est la meilleure comparaison mono-instance de l'époque, avec toutes les écoles en même temps : l'hybride cohérence d'arc + backtracking de Geoff a trouvé la solution en ~7 s et 1,29 × 10⁸ nœuds ([message 5455](https://groups.io/g/eternity2/message/5455)) ; la théorie de la complexité de Brendan a chiffré la recherche complète par simple balayage de lignes à 5,6 × 10⁸ nœuds ([message 5458](https://groups.io/g/eternity2/message/5458)) ; le force-brute en C généré d'istarinz a tourné à ~68 millions de placements par seconde ([message 5459](https://groups.io/g/eternity2/message/5459)) ; et le chemin réglé à la main par Txibilis a ramené la recherche complète à 2,89 × 10⁸ nœuds, plus de 20× en dessous du balayage de lignes, avec un chemin dérivé de la théorie arrivant juste derrière ([message 5494](https://groups.io/g/eternity2/message/5494), [5522](https://groups.io/g/eternity2/message/5522)). Propagation, théorie, vitesse brute et conception de chemin, tout cela sur un seul plateau : le format de duel dont tout auteur de solveur rêve secrètement. ## hints.20.3 : le défi de l'énumération complète Quand doc_s_smith est revenu en 2010, il a recadré le jeu : résoudre E2 lui-même relève de la force brute et est donc ennuyeux ; le problème intéressant et *comparable* est de compter exhaustivement les solutions de benchmarks riches en indices ([message 7803](https://groups.io/g/eternity2/message/7803)). Son fleuron était le casse-tête 16×16 `hints.20.3`, entièrement énuméré sur un seul cœur à 3,5 GHz : **29 481 602 025 785 nœuds** (environ 2,9 × 10¹³), 15,6 jours-CPU, exactement **une** solution ([message 7861](https://groups.io/g/eternity2/message/7861)). Il l'a posé comme un défi permanent : battre le nombre de nœuds, le temps, ou les deux. Le défi a fait ce que font les bons benchmarks : il a forcé la collaboration. En trois semaines, Martin (capiman), istarinz et doc ont fait converger leurs implémentations de cohérence d'arc et de réduction de domaine en échangeant des vidages complets des domaines 16×16 pour cette instance précise, s'attrapant mutuellement des bugs de miroir de coordonnées et de propagation ; l'estimation par doc du nombre de nœuds pour le benchmark est tombée de 1,6 × 10¹³ à 2,6 × 10¹² ([message 7890](https://groups.io/g/eternity2/message/7890), [7902](https://groups.io/g/eternity2/message/7902)). ## La paire de 9×9 : épuisée, puis re-vérifiée sur GPU En mars 2011, istarinz a rapporté avoir épuisé l'ensemble des espaces de recherche des *deux* casse-têtes 9×9 de Brendan, trois semaines chacun sur un Opteron bicœur : 191 750 810 226 600 nœuds pour le set 1, 145 088 777 827 367 pour le set 2, contre une estimation théorique de ~1,84 × 10¹⁴ ([message 8793](https://groups.io/g/eternity2/message/8793)). Le protocole de recensement a alors fait son office sur la réponse elle-même : il avait initialement annoncé une solution pour chacun, mais les backtrackers battus indépendamment de Peter McGavin ont trouvé une *seconde* solution au set 1 ([message 8801](https://groups.io/g/eternity2/message/8801)), et les décomptes corrigés (**2 solutions pour le set 1, 3 pour le set 2**) ont été confirmés quand McGavin a trouvé les trois solutions du set 2 ([message 8803](https://groups.io/g/eternity2/message/8803)). La théorie de la complexité avait prédit 3,2 solutions pour le set 1 : le bon ordre de grandeur sur la plus grande instance jamais explorée exhaustivement. Sept ans plus tard, les nombres ont été re-vérifiés à partir de zéro par une implémentation complètement différente sur un matériel absurdement différent : le solveur à compute-shader DirectX 12 d'Adam Miles a parcouru l'arbre complet du set 1 9×9 sur une Xbox One X en 25 h 24 m et a trouvé exactement les 2 solutions connues ([message 9822](https://groups.io/g/eternity2/message/9822)). Voilà à quoi ressemble une culture de benchmarks mûre : un recensement CPU de 2011 et un GPU de console de 2018 s'accordant à la solution près. ## Les 10×10 de Brendan : l'un est tombé, l'autre tient encore Les casse-têtes 10×10 sans indices de Brendan Owen constituaient la frontière reconnue de la communauté : « Personne n'a même encore résolu son 10×10. Le plus grand résolu est le 9×9 » ([message 8936](https://groups.io/g/eternity2/message/8936)). En septembre 2017, Peter McGavin a résolu **set_1** : énumérer les ~20 millions de premières lignes, les classer selon la probabilité de solution par nœud de l'arbre de recherche que donne la théorie de la complexité, et distribuer le backtracking sur plus de 400 cœurs de cartes ARM domestiques et de serveurs empruntés. La solution est arrivée après ~2 × 10¹⁷ nœuds (environ **180 cœurs-années**), à la recherche de ligne ~92 907 sur une prévision d'une pour 70 000, après avoir couvert moins de 0,5 % de l'arbre entier ([message 9686](https://groups.io/g/eternity2/message/9686) ; méthode et statistiques dans [9688](https://groups.io/g/eternity2/message/9688)). Martin a validé le plateau indépendamment ([message 9725](https://groups.io/g/eternity2/message/9725)), et le verdict de la communauté, « stupéfiant que ce soit réellement aussi difficile que prévu » ([message 9693](https://groups.io/g/eternity2/message/9693)), a fait office de plus forte validation empirique que la [théorie de la complexité](/fr/research/why/complex-theory/) ait jamais reçue. Selon les propres mots de McGavin : aucune méthode nouvelle, juste de la persévérance systématique et la loi des grands nombres. **Set_2 n'a jamais été résolu.** À la dernière mise à jour de cette page, il reste exactement ce que set_1 fut pendant une décennie : un 10×10 sans indices, aux statistiques connues, à la difficulté chiffrée par la théorie, attendant les 180 cœurs-années de quelqu'un. Si vous voulez un benchmark où vous faire un nom, c'est celui-là. Il figure sur le [tableau des problèmes ouverts](/fr/research/open-problems/) comme la cible nommée la plus proche sous le puzzle complet ; si vous vous y attaquez, [contribuer](/fr/research/contribute/) le plateau ou les statistiques donne au résultat un foyer permanent. ## Le débit, en termes de 2026 Les affirmations de vitesse de l'époque ci-dessus (les ~68 millions de placements par seconde d'istarinz en 2008) méritent une mise à jour, car les « placements par seconde » restent la façon dont la communauté jauge un solveur, et le plafond a bougé. Interrogé directement en juin 2026 sur ce que font les moteurs de pointe, Adam Miles a donné la règle empirique du moment : un backtracker CPU bien réglé atteint à peu près **50 millions de placements valides par seconde et par cœur**, et les solveurs GPU tournent **au-delà de 10 milliards de placements par seconde** ([message 11826](https://groups.io/g/eternity2/message/11826)). Des chiffres concrets du même fil le confirment : David Barr a mesuré son propre cœur CPU à ~23 millions de placements par seconde et son portage GPU à ~2,4 milliards ([message 11835](https://groups.io/g/eternity2/message/11835)), et le backtracker optimisé de Peter McGavin a atteint ~295 millions par seconde sur un cœur unique rapide ([message 11750](https://groups.io/g/eternity2/message/11750)) - mais c'est un chiffre de *plateau facile* ; sur un plateau difficile, le même moteur tourne à ~105 M, où un [moteur en Rust portable sur ce site](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) l'égale. Deux mises en garde héritées de l'ancien débat nœud-contre-pas subsistent : un « placement valide » ne compte que les pièces qui passent la recherche d'accord de couleur, pas chaque pièce essayée, et la vitesse mono-cœur sur un 16×16 complet vaut typiquement environ la moitié du chiffre sur petit casse-tête, parce que la recherche passe son temps dans la forêt dense des contraintes proches du bord. (Ces chiffres de placements/s sont un axe de « rapide », sans rapport avec le score en arêtes appariées d'un plateau ; le [registre d'ingénierie des solveurs](/fr/research/build/faster/solver-engineering/) fixe les trois sens du mot.) Rien de tout cela ne change le verdict [élagage contre vitesse](/fr/research/why/prune-vs-speed/) : un bond de débit de 400× depuis 2008 n'a pas fait bouger le record, parce qu'il rend l'arbre moins coûteux à parcourir, pas plus petit. ## Ce qu'il faut exécuter aujourd'hui Les suites historiques vivent dans la zone Files du groupe (avec quelques liens morts) ; le protocole qu'elles incarnent est plus facile à suivre aujourd'hui qu'à l'époque : 1. **Rejoignez d'abord le Right Numbers Club.** Avant de faire confiance à un quelconque chronométrage, confrontez votre solveur aux comptages exhaustifs. Ce site maintient l'équivalent moderne des publications de recensement (comptages exacts de blocs à chaque position du plateau, sous des règles de plus en plus contraintes) sur la page [nombres de référence](/fr/research/reference/). Les classiques marchent toujours aussi : 2 633 221 pour le coin 3×3, 69 284 103 nœuds de balayage de lignes pour le 6×6 de Brendan. 2. **Grimpez l'échelle.** Les casse-têtes générés par Brendan ont des réponses validées : 6×6 (65 solutions), 7×7 (set 1 : 6 297 solutions en 67 667 477 364 nœuds, le micro-benchmark standard depuis le [message 9793](https://groups.io/g/eternity2/message/9793)), 8×8 (24 solutions à coins fixés, [message 8890](https://groups.io/g/eternity2/message/8890)), la paire de 9×9 (2 et 3 solutions), puis `hints.20.3` (exactement 1 solution en 2,9 × 10¹³ nœuds). 3. **Rapportez les nombres de nœuds avec vos temps**, et dites ce que vous comptez : l'ambiguïté nœud-contre-pas de 2007 n'est jamais totalement morte, et un chronométrage sans nombre de nœuds est infalsifiable. C'est l'habitude de publier les deux qui a rendu les résultats de 2017-2018 comparables entre un Phenom, un Xeon et une Xbox. 4. **Puis visez set_2.** La [page des faits établis](/fr/research/build/known-facts/) donne les nombres du vrai plateau ; le 10×10 ouvert est le prochain barreau que la communauté s'accorde à placer juste en dessous. ## Où se trouvent réellement les fichiers Deux de ces suites ont survécu intactes à la migration Yahoo vers groups.io et méritent qu'on pointe directement son parseur dessus. Les [Sample Puzzles](https://groups.io/g/eternity2/files/Sample%20Puzzles) (2007) de Dave Clark sont le jeu de départ le plus propre : des plateaux 16×16 du type d'E2 à 16 et 40 couleurs de bord, chacun avec sa solution, dans un format auto-documenté. Un fichier de casse-tête `sample_16_16_16_flat.txt` s'ouvre sur une ligne `width height borders`, puis une ligne de couleurs `Left Top Right Bottom` par case (`0` est le gris) ; le fichier `solution_…` correspondant liste des lignes `piece x y orientation`, l'orientation `0`–`3` pour 0°/90°/180°/270° dans le sens horaire. Les variantes `flat` répartissent les couleurs uniformément ; les variantes `rand` assignent chaque bord indépendamment, si bien qu'une paire `flat`/`rand` est un test tout prêt du degré auquel votre solveur s'appuie sur une distribution uniforme des couleurs. Le [dossier Benchmarks](https://groups.io/g/eternity2/files/Benchmarks) rassemble les plateaux de tailles variables sur lesquels la course au nombre de nœuds ci-dessus s'est jouée (côtés 11 à 16, plus `8x8x8.txt`, un 8×8 à solution unique qu'un backtracker correct nettoie en une vingtaine de minutes). Entre ces deux dossiers, vous pouvez parcourir toute l'échelle, d'un casse-tête qui se résout le temps d'un café jusqu'aux 16×16 générés, sans jamais toucher aux pièces du prix protégées par copyright. ## À lire aussi - [Nombres de référence](https://eternity2.dev/fr/research/reference/) — Dénombrements exacts du nombre de façons valides de remplir un petit bloc à une position donnée du plateau officiel d'Eternity II, sous des règles de plus en plus contraintes : des nombres sûrs pour vérifier le code d'appariement des bords et de contraintes de votre solveur. - [Faits et chiffres établis](https://eternity2.dev/fr/research/build/known-facts/) — Les chiffres que tout chercheur sur Eternity II finit par redémontrer, rassemblés au même endroit avec leur provenance : la définition du puzzle, le placement des indices, les conventions de score, le tableau des records, la taille de l'espace de recherche et les comptages structurels. - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. --- # Les quatre puzzles-indices > Tomy a vendu quatre petits puzzles compagnons pour Eternity II : résolvez-en un, soumettez la solution, et le site officiel révélait la position d'une pièce sur le plateau principal. Ce qu'était chaque puzzle, le vérificateur en ligne défaillant, le marché gris d'eBay, pourquoi les puzzles 5 et 6 ne sont jamais venus, et la seconde vie des puzzles-indices comme cas de test pour la théorie des complexes et comme jeux de pièces donneuses. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/clue-puzzles/ - Mise à jour: 2026-07-02 - Source: Les règles officielles : quatre puzzles-indices, deux par an, un indice chacun, eternity2@groups.io, 2007-05 — https://groups.io/g/eternity2/message/182 - Source: Le texte des règles sur les puzzles-indices cité mot pour mot (Jim Towler), eternity2@groups.io, 2008-01 — https://groups.io/g/eternity2/message/4187 - Source: Les puzzles-indices 3 et 4 apparaissent sur le site britannique (Mark Sheppard), eternity2@groups.io, 2008-01 — https://groups.io/g/eternity2/message/3858 - Source: Le vérificateur en ligne accepte une mauvaise réponse à l'indice 4, eternity2@groups.io, 2008-01 — https://groups.io/g/eternity2/message/4109 - Source: Des indices de puzzle vendus sur eBay (Martin / capiman), eternity2@groups.io, 2008-01 — https://groups.io/g/eternity2/message/3971 - Source: TOMY : aucun projet pour les puzzles-indices 5 et 6 (Steve Grant), eternity2@groups.io, 2009-01 — https://groups.io/g/eternity2/message/6381 - Source: Les puzzles-indices 3 et 4 épuisés chez le fournisseur, eternity2@groups.io, 2009-10 — https://groups.io/g/eternity2/message/7185 - Source: Comptages exhaustifs des puzzles-indices face aux estimations de la théorie des complexes (apal1969, Peter McGavin), eternity2@groups.io, 2010-11 — https://groups.io/g/eternity2/message/8142 - Source: Jef Bucas livre la page Indices du visualiseur, eternity2@groups.io, 2021-01 — https://groups.io/g/eternity2/message/10082 - Source: Un « 480 » construit à partir d'un jeu E2 + les pièces des indices 1 et 2 (Peter McGavin), eternity2@groups.io, 2023-10 — https://groups.io/g/eternity2/message/11169 - Source: Le solveur SHORTER d'Armel Le Bail, dont les fichiers d'exemple portent les pièces des indices 1 et 2 (cristal.org, 2007) — http://www.cristal.org/Eternity-II/ - Source: Eternity2Puzzles.jl de Janos Wortmann, dont les fichiers de pièces portent les quatre puzzles-indices, y compris les indices 3 et 4 (GitHub, 2024–25) — https://github.com/jwortmann/Eternity2Puzzles.jl - Source: Les propres fichiers de positions des puzzles-indices d'eternity2.net (Wayback Machine, 2007-10-17) — https://web.archive.org/web/20071017024639/http://eternity2.net:80/e2pieces_clue2.txt --- À côté du puzzle-prix de 256 pièces, Tomy a vendu quatre petits puzzles compagnons, du **puzzle-indice 1** au **puzzle-indice 4**. Chacun était un puzzle d'appariement de bords à part entière, et chacun, une fois résolu et soumis sur le site officiel, révélait la position d'une pièce sur le plateau principal. Cette page traite de ces quatre *produits* : ce qu'ils contenaient, comment fonctionnait le mécanisme d'indice, comment ils ont été vendus puis discrètement retirés du commerce, et ce que la communauté en a fait par la suite. Ce n'est **pas** la page consacrée aux cinq positions-indices du puzzle principal. Ces positions (la pièce centrale obligatoire 139 en I8, plus les quatre optionnelles que les puzzles-indices révélaient) sont tabulées avec leur provenance dans [Faits et chiffres connus](/fr/research/build/known-facts/). Les deux sujets se rejoignent à mi-chemin : les quatre lignes optionnelles de ce tableau sont exactement ce à quoi servaient les quatre puzzles-indices. ## Le mécanisme : résoudre, soumettre, recevoir une position Les règles publiées en mai 2007 annonçaient quatre puzzles-indices, portant chacun un indice : deux en vente avec le puzzle principal en 2007, deux autres à suivre en 2008 ([msg 182](https://groups.io/g/eternity2/message/182)). Le texte des règles australiennes explicitait le mécanisme : « Pour chaque puzzle-indice que vous résolvez, soumettez votre solution pour obtenir un indice donnant la position correcte d'une pièce du puzzle-prix » ([msg 4187](https://groups.io/g/eternity2/message/4187)). En pratique, la récompense était le numéro de la pièce, sa case sur le plateau 16×16 **et sa rotation exacte** ([msg 7747](https://groups.io/g/eternity2/message/7747)). Trois détails de conception avaient leur importance : - **Les puzzles-indices ont de nombreuses solutions.** Contrairement au puzzle principal, ils contiennent des pièces dupliquées et quasi dupliquées ; les 36 pièces du puzzle-indice 1 ne portent que 110 motifs de bord distincts sur 288 possibles ([msg 2875](https://groups.io/g/eternity2/message/2875)). Tout agencement valide était accepté. - **Tout le monde recevait le même indice.** Soumettre des solutions différentes au même puzzle-indice renvoyait la même pièce-indice ([msg 2860](https://groups.io/g/eternity2/message/2860)) ; les indices étaient des propriétés fixes du puzzle principal, non des secrets propres à chaque client. - **Les indices étaient optionnels.** Selon les règles du concours, seule la pièce de départ était obligatoire ; les candidatures au prix pouvaient ignorer les quatre positions des puzzles-indices ([msg 11046](https://groups.io/g/eternity2/message/11046)), et la lignée du record ouvert (467→470) les ignore effectivement ; la lignée stricte à cinq indices, qui honore les quatre, est suivie séparément (meilleur score connu : 464, voir [Records et solveurs](/fr/research/records/)). ## Les quatre puzzles | Puzzle | Taille | Pièces | Couleurs (bord / intérieur) | En vente | Solutions | | --- | --- | --- | --- | --- | --- | | Puzzle-indice 1 | 6×6 | 36 | 4 / 3 | juillet 2007 | ≈ 3,6 × 10¹⁰ (échantillonné) | | Puzzle-indice 2 | 12×6 | 72 | 4 / 4 | juillet 2007 | jamais comptées entièrement (≥ 1,4 × 10⁶ trouvées) | | Puzzle-indice 3 | 6×6 | 36 | n/a | janvier 2008 | 2 195 647 488 (exact) | | Puzzle-indice 4 | 12×6 | 72 | 5 / 4 | janvier 2008 | jamais comptées entièrement | Tailles et dates de lancement : [msg 4187](https://groups.io/g/eternity2/message/4187), [msg 3858](https://groups.io/g/eternity2/message/3858) ; nombres de couleurs : [msg 8052](https://groups.io/g/eternity2/message/8052) (indice 1), [msg 8137](https://groups.io/g/eternity2/message/8137) (indices 2 et 4) ; nombres de solutions : ci-dessous. ### Puzzle-indice 1 : celui qui se résout à la main Un carré 6×6, lancé avec le puzzle principal en juillet 2007. Il est véritablement facile : résolu à la main en une centaine de coups, et un simple retour sur trace nécessite de l'ordre de 10²–10⁴ nœuds ([msg 2873](https://groups.io/g/eternity2/message/2873) ; solveur d'Anthony Cole : 108 nœuds, [msg 8775](https://groups.io/g/eternity2/message/8775)). L'envers de la facilité, c'est la dégénérescence : la recherche exhaustive partielle d'apal1969 extrapolait à environ 3,6 × 10¹⁰ solutions non dégénérées ([msg 8052](https://groups.io/g/eternity2/message/8052)). Ses sommes de contrôle CRC-16 sont les seules sommes de contrôle de puzzle-indice jamais publiées sur la liste ([msg 6769](https://groups.io/g/eternity2/message/6769) ; voir plus bas). > **[Interactive: CluePuzzlePieces]** Rendered on the canonical page (link above); not shown in this markdown export. ### Puzzle-indice 2 : le difficile Un rectangle 12×6, également de juillet 2007, et de l'avis général le plus difficile des quatre. « How to solve Clue2 ? » fut un fil de discussion en quelques mois ([msg 3381](https://groups.io/g/eternity2/message/3381)). Un ordinateur le résout en quelques millisecondes ([msg 3386](https://groups.io/g/eternity2/message/3386)), mais à la main il a déconcerté des gens qui avaient survolé l'indice 1 ([msg 3773](https://groups.io/g/eternity2/message/3773)), et apal1969 rapportait environ une journée de résolution à la main encore en 2010 ([msg 8137](https://groups.io/g/eternity2/message/8137)). C'est aussi le seul puzzle-indice dont les solutions n'ont jamais été comptées de façon exhaustive : une exécution de 8 heures avait trouvé ≈ 1,4 × 10⁶ solutions non dégénérées « et continuait » ([msg 8142](https://groups.io/g/eternity2/message/8142)), et Brendan Owen a jugé l'espace trop vaste pour une recherche complète ([msg 8143](https://groups.io/g/eternity2/message/8143)). Pour un solveur, il reste trivial : 1 637 300 nœuds, environ une seconde ([msg 8775](https://groups.io/g/eternity2/message/8775)). > **[Interactive: CluePuzzlePieces]** Rendered on the canonical page (link above); not shown in this markdown export. ### Puzzle-indice 3 : celui compté exactement Un second 6×6, annoncé sur le site britannique (avec l'indice 4) en janvier 2008 ([msg 3858](https://groups.io/g/eternity2/message/3858)) ; les premiers acheteurs l'avaient résolu et réclamé l'indice dès la mi-janvier ([msg 3982](https://groups.io/g/eternity2/message/3982)). Sa notoriété est venue plus tard : c'est le seul puzzle-indice dont le nombre de solutions est connu **exactement**, à 2 195 647 488, grâce à l'exécution exhaustive d'environ un jour d'apal1969 ([msg 8168](https://groups.io/g/eternity2/message/8168)). Ce comptage en a fait le plus précis des cas de test de puzzle-indice pour la [théorie des complexes](/fr/research/why/complex-theory/) (section suivante). Un retour sur trace trouve une première solution en 78 nœuds ([msg 8775](https://groups.io/g/eternity2/message/8775)). > **[Interactive: CluePuzzlePieces]** Rendered on the canonical page (link above); not shown in this markdown export. ### Puzzle-indice 4 : le dernier Un second 12×6, lancé aux côtés de l'indice 3 en janvier 2008, avec 5 couleurs de bord et 4 couleurs d'intérieur ([msg 8137](https://groups.io/g/eternity2/message/8137)). Plus facile que l'indice 2 pour une machine (première solution en 4 951 nœuds, [msg 8775](https://groups.io/g/eternity2/message/8775)) ; comme l'indice 2, ses solutions n'ont jamais été entièrement comptées, si bien que les estimations de McGavin issues de la théorie des complexes pour les puzzles 12×6 tenaient lieu de nombres exacts ([msg 10236](https://groups.io/g/eternity2/message/10236)). Sa marque durable sur les archives est le fiasco du vérificateur, ci-dessous. > **[Interactive: CluePuzzlePieces]** Rendered on the canonical page (link above); not shown in this markdown export. Le message de référence de Cole nomme aussi un cinquième frère, non officiel : la démo « web teaser » de 16 pièces sur le site officiel, résolue en 34 nœuds ([msg 8775](https://groups.io/g/eternity2/message/8775)). ## Le fiasco du vérificateur et le marché gris Le lancement des puzzles-indices ne fut pas sans accroc. Quand les formulaires de soumission des indices 3 et 4 ont ouvert en janvier 2008, les membres qui les sondaient ont découvert la validation défaillante : petzi.petzi a saisi sa solution de l'**indice 2** dans le formulaire de l'**indice 4** (avec une pièce erronée « 449 » qui n'existe pas dans un puzzle de 72 pièces), et le site l'a acceptée et a livré l'indice 4 ([msg 4109](https://groups.io/g/eternity2/message/4109), [4119](https://groups.io/g/eternity2/message/4119), [4141](https://groups.io/g/eternity2/message/4141)). La même astuce a échoué pour un autre membre ([msg 4117](https://groups.io/g/eternity2/message/4117)), donc le vérificateur n'était pas seulement laxiste mais incohérent. La meilleure hypothèse de la communauté pour une explication partielle : la forte redondance des pièces des puzzles-indices implique un nombre démesuré d'agencements valides, si bien que des soumissions à l'apparence erronée peuvent coïncider avec de vraies solutions ([msg 4118](https://groups.io/g/eternity2/message/4118)). Mais « 449 » exclut toute lecture dans laquelle le formulaire validait de vraies pièces. Personne n'a jamais signalé que Tomy l'ait corrigé ni reconnu. Les indices eux-mêmes ont fuité immédiatement : - **eBay.** Dès janvier 2008, des vendeurs proposaient les informations d'indice des puzzles-indices 1 et 2 comme un produit ([msg 3971](https://groups.io/g/eternity2/message/3971)) ; l'un d'eux les aurait vendues plus de deux douzaines de fois ([msg 3976](https://groups.io/g/eternity2/message/3976)), avec un bref débat pour savoir s'il est même répréhensible de revendre une information que l'on a achetée ([msg 3972](https://groups.io/g/eternity2/message/3972)). - **Dérivation.** En juillet 2008, danmayoh a dérivé les indices 3 et 4 d'une « matrice de possibilités » qu'un autre membre avait publiée. La matrice avait été construite à l'aide des indices, et la construction pouvait être inversée malgré des fautes de frappe délibérées. Le modérateur Brendan Owen a supprimé chaque message contenant la matrice « par sécurité » ([msg 5650](https://groups.io/g/eternity2/message/5650), [5651](https://groups.io/g/eternity2/message/5651)) ; danmayoh a confirmé que l'astuce ne pouvait pas faire surgir des indices qui n'étaient pas déjà intégrés ([msg 5732](https://groups.io/g/eternity2/message/5732)). ## Une courte durée de vie : épuisés, et pas de puzzles 5 et 6 La distribution fut irrégulière dès le départ : les indices 1 et 2 étaient au début introuvables aux États-Unis ([msg 2855](https://groups.io/g/eternity2/message/2855) fil de discussion), et les indices 3 et 4 sont apparus d'abord au Royaume-Uni, suscitant des plaintes de Suède, d'Australie, d'Espagne et des États-Unis ([msg 3858](https://groups.io/g/eternity2/message/3858), [4502](https://groups.io/g/eternity2/message/4502) et [7517](https://groups.io/g/eternity2/message/7517) fils de discussion). Puis l'approvisionnement s'est entièrement tari : - **Janvier 2009.** Après que le premier examen approfondi n'a révélé aucun gagnant, Steve Grant a écrit à la Careline de Tomy pour demander quand viendraient les puzzles-indices 5 et 6. La réponse : Tomy n'a **aucun projet de sortir d'autres puzzles-indices** ([msg 6381](https://groups.io/g/eternity2/message/6381)). La plupart du groupe fut soulagée ; davantage d'indices aurait dévalué le défi. - **Octobre 2009.** On a dit à un acheteur suédois que les indices 3 et 4 s'étaient épuisés au printemps 2009 et que le fournisseur ne pouvait pas se réapprovisionner ([msg 7185](https://groups.io/g/eternity2/message/7185)) ; en novembre, il n'existait plus de stock nulle part, comme si la production avait cessé ([msg 7232](https://groups.io/g/eternity2/message/7232)). - **Mai 2010.** Les puzzles avaient quitté le marché britannique depuis environ 18 mois et **n'ont jamais été commercialisés du tout dans certaines régions** ; la seconde main était la seule voie ([msg 7752](https://groups.io/g/eternity2/message/7752)), et les annonces eBay incluaient déjà les positions d'indice résolues elles-mêmes ([msg 7350](https://groups.io/g/eternity2/message/7350)). Ainsi, les puzzles-indices furent achetables pendant environ deux ans, dans certains pays jamais, et l'information qu'ils vendaient est devenue inachetable alors que le concours à 2 M$ avait encore un an et demi à courir. ## Les indices ont-ils seulement aidé ? La plupart du temps non, et la communauté le savait tôt. Brendan Owen ne les a jamais achetés (« juste un stratagème marketing »), calculant que les indices aident mais qu'« il n'y a pas assez d'indices, loin de là » pour rendre E2 traitable ([msg 2842](https://groups.io/g/eternity2/message/2842)) ; ses simulations de théorie des indices situaient le besoin à environ 20 indices bien placés ou plus ([msg 1107](https://groups.io/g/eternity2/message/1107)), affiné plus tard à ~12–13 indices répartis ([msg 5652](https://groups.io/g/eternity2/message/5652)). Répartis vaut mieux que groupés, une conclusion encore en cours d'affinage en 2026 ([msg 11736](https://groups.io/g/eternity2/message/11736)). Le tableau quantitatif, en trois nombres : - **Un indice réduit l'espace de recherche local d'environ 767×** : Verhaard a compté 3 366 façons de remplir le rectangle du coin jusqu'à une pièce-indice contre 2 582 369 sans elle ([msg 3543](https://groups.io/g/eternity2/message/3543)). - **Les quatre réduisent le nombre attendu de solutions de ≈ 14 702 à ≈ 4 × 10⁻⁸** ([théorie des complexes](/fr/research/why/complex-theory/) ; [msg 11193](https://groups.io/g/eternity2/message/11193)) ; les indices achètent l'*unicité*, à dessein. - **Mais le nombre attendu de nœuds par solution ne bouge quasiment pas** : McGavin a mesuré un coût de retour sur trace essentiellement identique avec et sans la contrainte supplémentaire ([msg 8924](https://groups.io/g/eternity2/message/8924)). Moins d'aiguilles, botte de foin proportionnellement plus petite. D'où le verdict établi, prononcé par Jef Bucas lorsqu'il a enfin publié les positions sur son visualiseur : « jusqu'à présent, l'essentiel des progrès a été accompli *sans* les indices » ([msg 10082](https://groups.io/g/eternity2/message/10082)). Le meilleur plateau qui respecte les cinq positions score 464 (Benjamin Riotte, 2026) ; le record ouvert, qui ne respecte que la pièce de départ obligatoire, est de 470 ([Records et solveurs](/fr/research/records/)). ## Vérifier un jeu-indice sans les pièces Comme le jeu principal, les motifs des pièces des puzzles-indices tombaient sous la revendication de droit d'auteur de l'inventeur, si bien qu'ils n'ont jamais été publiés. La réponse de la communauté, comme pour le puzzle-prix, fut des sommes de contrôle à la place des données ([msg 983](https://groups.io/g/eternity2/message/983), [msg 1063](https://groups.io/g/eternity2/message/1063) : le schéma CRC-16 d'Owen de la semaine du lancement). Les demandes de l'étendre aux puzzles-indices ont commencé en 2007 ([msg 3417](https://groups.io/g/eternity2/message/3417)), mais ce n'est qu'en 2009 que Thomas (l'auteur d'E2_Manual) a publié des sommes de contrôle CRC-16, pour le seul puzzle-indice 1, demandant à d'autres de les confirmer et de couvrir les indices 2 à 4 ([msg 6768](https://groups.io/g/eternity2/message/6768), [6769](https://groups.io/g/eternity2/message/6769)). **Aucune confirmation ni aucune somme de contrôle pour les indices 2, 3 ou 4 n'est jamais apparue sur la liste** : quiconque saisit aujourd'hui un jeu-indice de seconde main n'a toujours aucun moyen public de le valider. Il existait aussi une somme de contrôle au niveau des positions : un CRC sur e2hints.txt pour vérifier vos données d'*indice* sans les publier ([msg 1147](https://groups.io/g/eternity2/message/1147)). ## Postérité ### Les indices deviennent le folklore de la communauté Une fois les puzzles retirés de la vente, les positions qu'ils vendaient ont circulé sur la liste comme données non officielles : une liste pièce/position en 2009 ([msg 6778](https://groups.io/g/eternity2/message/6778)), ressortie chaque fois que quelqu'un le demandait ([msg 8808](https://groups.io/g/eternity2/message/8808), [8809](https://groups.io/g/eternity2/message/8809)), reformulée avec les rotations en 2012 ([msg 9067](https://groups.io/g/eternity2/message/9067)). Le propriétaire du groupe a refusé de cautionner la publication (« Ce serait une violation du droit d'auteur de M. Moncton ! », [msg 9210](https://groups.io/g/eternity2/message/9210)), mais les données ont survécu à l'objection : en janvier 2021, Jef Bucas a ajouté une page Indices au visualiseur de la communauté ([msg 10082](https://groups.io/g/eternity2/message/10082)), la pièce 181 fut confirmée de première main par un membre qui avait résolu son puzzle-indice et reçu cet indice de Tomy ([msg 10085](https://groups.io/g/eternity2/message/10085)), et les rotations furent recoupées une fois de plus en 2021 ([msg 10542](https://groups.io/g/eternity2/message/10542)). Les positions qui en résultent sont les quatre lignes optionnelles de [Faits et chiffres connus](/fr/research/build/known-facts/). ### Cas de test pour la théorie des complexes La seconde carrière des puzzles-indices fut celle de cibles de calibration pour la [théorie des complexes de Brendan Owen](/fr/research/why/complex-theory/). En novembre 2010, apal1969 a mené des comptages exhaustifs (indice 3 : exactement 2 195 647 488 solutions) et les a comparés aux estimations de Peter McGavin issues de la théorie ; l'écart initial de 10² fut attribué à McGavin ayant oublié de diviser par deux les comptages de types de bord, et après correction les estimations sont tombées à un ordre de grandeur près, exactement la précision qu'Owen revendiquait pour les petits plateaux ([msgs 8142–8172](https://groups.io/g/eternity2/message/8142) ; note de précision d'Owen [8171](https://groups.io/g/eternity2/message/8171), le correctif [8172](https://groups.io/g/eternity2/message/8172)). McGavin a ensuite déposé des estimations de retour sur trace pour tous les puzzles-indices dans la base de données du groupe ([msg 8901](https://groups.io/g/eternity2/message/8901)). Ce furent les premiers des [bancs d'essai](/fr/research/build/benchmarks/) exhaustif-contre-estimé qui ont fini par amener la communauté à faire confiance aux nombres de la théorie à l'échelle d'E2. Dès 2011, les puzzles eux-mêmes étaient des échauffements pour solveurs : les quatre tombent en moins d'une seconde ([msg 8773](https://groups.io/g/eternity2/message/8773), [8775](https://groups.io/g/eternity2/message/8775)). ### Jeux de pièces donneuses pour les « 480 » mixtes Enfin, les pièces physiques ont trouvé un usage que les concepteurs n'avaient jamais prévu. En 2014, Peter McGavin a présenté des « solutions » 16×16 complètes assemblées à partir d'un jeu E2 plus des pièces de puzzle-indice ([msg 9309](https://groups.io/g/eternity2/message/9309), [9310](https://groups.io/g/eternity2/message/9310)), et en 2023 il a construit un plateau complet 480/480 à partir des pièces d'**un jeu E2, un jeu Indice 1 et un jeu Indice 2** ([msg 11169](https://groups.io/g/eternity2/message/11169)), dans le défi de tuiles distinctes maximales de Vlastislav W. ([msg 11167](https://groups.io/g/eternity2/message/11167)). Pour être parfaitement clair : **ces plateaux ne sont pas des solutions d'Eternity II**. Ils utilisent des pièces qui ne font pas partie du jeu officiel de 256 pièces, et c'est pourquoi les revendications de « 480 » en une seule phrase doivent toujours être vérifiées face à la liste des pièces ([Records et solveurs](/fr/research/records/)). ## Retrouvés et résolus : les quatre La seule chose que tout le monde supposait perdue s'avère récupérable, et pas seulement pour les deux premiers. La communauté a retenu les motifs des pièces des puzzles-indices pour des motifs de droit d'auteur, et personne n'a publié les agencements sur la liste. Mais deux projets de solveurs indépendants les ont tout de même livrés comme exemples résolus. Le solveur **SHORTER** d'Armel Le Bail, un programme Fortran publié sur cristal.org en août 2007, en livre trois : un 6×6 de 36 pièces, un 12×6 de 72 pièces, et le plateau complet de 256 pièces. Le fichier de 256 pièces est le véritable jeu officiel Eternity II, et c'est ainsi que la provenance se vérifie : Le Bail lisait de véritables données Tomy au format eternity2.net. Les deux autres sont le **puzzle-indice 1 et le puzzle-indice 2**, motifs compris. Les **indices 3 et 4** ont surgi dans une seconde source, bien plus récente : [`Eternity2Puzzles.jl`](https://github.com/jwortmann/Eternity2Puzzles.jl) de Janos Wortmann, un paquet Julia qui porte les quatre puzzles-indices sous forme de simples fichiers de pièces (`clue1.txt` … `clue4.txt`). Ses `clue1`/`clue2` sont les deux mêmes puzzles que ceux livrés par Le Bail : nous avons canonicalisé chacun en un multiensemble de pièces invariant par rotation et réétiqueté en couleurs, et ils correspondent exactement aux indices 1 et 2 de Le Bail, pièce par pièce. Une source qui reproduit les deux puzzles que nous pouvons déjà recouper est une source digne de confiance pour les deux que nous ne pouvons pas, si bien que ses indices 3 et 4 reposent sur la même base. Les fichiers qu'eternity2.net a publiés lui-même, récupérés depuis la Wayback Machine, corroborent les tailles et les positions sur le plateau des indices 1 et 2, mais pas les motifs. Ils disposent chacun sous forme d'un bloc sur une grille 16×16, le 6×6 aux lignes 5–10 et colonnes 5–10, le 6×12 aux lignes 5–10 et colonnes 2–13, et réduisent chaque bord intérieur à une unique couleur de remplissage. (Le site n'a jamais hébergé de fichiers pour les indices 3 ou 4, qui ont été lancés après sa dernière capture.) Ainsi les fichiers officiels fixent *où* siégeaient les indices 1 et 2 ; les fichiers des solveurs sont le témoignage public de *ce que* sont les pièces, pour les quatre. Chacun fut résolu à partir de zéro pour confirmer qu'il s'agit de puzzles réels et cohérents. La résolution encode « placer chaque pièce de sorte que tous les bords s'apparient et que le gris siège sur le pourtour » comme une instance SAT et la confie à un solveur ; une passe distincte vérifie ensuite la réponse de manière indépendante (chaque pièce utilisée une fois, chaque bord interne apparié, le gris uniquement sur l'anneau extérieur). Les quatre se ferment parfaitement : les indices 1 et 3 sur la totalité de leurs 60 bords internes, les indices 2 et 4 sur la totalité des 126. Chaque plateau résolu est présenté dans sa propre section ci-dessus ([Indice 1](#puzzle-indice-1--celui-qui-se-résout-à-la-main), [Indice 2](#puzzle-indice-2--le-difficile), [Indice 3](#puzzle-indice-3--celui-compté-exactement), [Indice 4](#puzzle-indice-4--le-dernier)), dessiné avec les vrais motifs Eternity II. Chaque puzzle offre deux téléchargements : les pièces sous forme de données prêtes pour un solveur (le même JSON d'instance publié dans le [jeu de données](/fr/research/build/dataset/), bords dans l'ordre haut-droite-bas-gauche, la couleur 0 étant le pourtour) et sous forme d'un jeu de SVG par pièce, de la même manière que les pièces du puzzle principal sont proposées sur la [page du puzzle](/puzzle/). Une mise en garde sur les motifs. Les *pièces* sont assurément correctes : elles sont les données de bord récupérées, elles se recoupent entre les deux sources pour les indices 1 et 2, et chacune se résout en un plateau complet aux bords appariés, ce qu'un jeu de pièces erroné ne ferait pas. Les *motifs* présentés sont les vrais glyphes Eternity II, assignés dans l'ordre aux numéros de couleur de chaque indice ; ce ne sont presque certainement pas les motifs imprimés exacts de Tomy pour les puzzles-indices, qu'aucune source publique ne consigne. Lisez donc les plateaux et les téléchargements comme les pièces correctes dessinées dans l'art propre d'Eternity II, non comme un fac-similé des tuiles physiques. La récupération complète, les données de pièces des quatre, et la résolution reproductible sont dans le [topic clue-puzzle-pieces](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/clue-puzzle-pieces). Cela ne dit rien sur le droit d'auteur au nom duquel les agencements ont été retenus ; cela consigne simplement qu'ils étaient déjà publics dans les fichiers d'exemple de deux solveurs, et les montre résolus. ## Ce qui n'est pas publiquement documenté Des lacunes qu'un lecteur attentif devrait connaître : - **Les définitions des pièces des puzzles-indices n'ont jamais été publiées sur la liste** (droit d'auteur), et les seules sommes de contrôle de la communauté couvrent le puzzle-indice 1 et restent non confirmées ([msg 6769](https://groups.io/g/eternity2/message/6769)). Elles survivent tout de même dans les fichiers d'exemple de deux projets de solveurs, les indices 1 et 2 dans SHORTER de Le Bail et les quatre dans `Eternity2Puzzles.jl` de Wortmann, recoupés et résolus ci-dessus. - **Quel puzzle révélait quelle position.** Les archives ne rattachent jamais proprement le puzzle-indice *n* à une case précise parmi C3, C14, N3, N14. Seule la pièce 181 dispose d'une attestation de première main puzzle-vers-indice ([msg 10085](https://groups.io/g/eternity2/message/10085)), et même ce message ne dit pas quel puzzle numéroté l'a produite. - **Les nombres exacts de solutions pour les indices 2 et 4.** Seuls des estimations et des comptages partiels existent ([msg 8142](https://groups.io/g/eternity2/message/8142), [10236](https://groups.io/g/eternity2/message/10236)). - **Les chiffres de production et de ventes.** Combien de puzzles-indices ont été fabriqués ou vendus, et pourquoi la production s'est arrêtée début 2009, n'a jamais été indiqué par Tomy ; l'histoire de l'épuisement est reconstituée à partir des réponses des détaillants ([msg 7185](https://groups.io/g/eternity2/message/7185)). - **Les registres officiels des indices.** On ignore si la base de données de soumissions de Tomy et les réponses-indices canoniques survivent quelque part ; les positions reposent sur les recoupements de la communauté, non sur une publication officielle. ## À lire aussi - [Faits et chiffres établis](https://eternity2.dev/fr/research/build/known-facts/) — Les chiffres que tout chercheur sur Eternity II finit par redémontrer, rassemblés au même endroit avec leur provenance : la définition du puzzle, le placement des indices, les conventions de score, le tableau des records, la taille de l'espace de recherche et les comptages structurels. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. --- # Construire les plateaux par assemblage > Construire un plateau à haut score à partir d'une grille vide plutôt que de creuser par backtracking : la recherche en faisceau garde en vie les meilleurs plateaux partiels et les fait croître case par case. Le cheval de bataille des constructeurs partant de zéro de ce projet, et une illustration nette de la raison pour laquelle la seule largeur finit par caler dans les profondeurs de l'intérieur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/construct/ - Mise à jour: 2026-07-22 --- Construire un plateau à haut score à partir d'une grille vide plutôt que de creuser par backtracking : la recherche en faisceau garde en vie les meilleurs plateaux partiels et les fait croître case par case. Le cheval de bataille des constructeurs partant de zéro de ce projet, et une illustration nette de la raison pour laquelle la seule largeur finit par caler dans les profondeurs de l'intérieur. Les pages ci-dessous procèdent technique par technique : ce qu'est chacune en une ligne, ce qu'elle a réellement atteint sur le vrai plateau 16×16, où elle s'arrête, et les laboratoires et mesures qui l'étayent. Deux constructeurs vivent ici pour l'instant : [la recherche en faisceau](/fr/research/build/construct/beam-search/), le cheval de bataille case par case, et [la DP par colonnes en bandes](/fr/research/build/construct/band-column-dp/), qui fait croître le plateau par bandes de deux rangées. Pour embrasser tout le territoire d'un coup, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). ## Pages de cette section - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [DP par colonnes en bandes](https://eternity2.dev/fr/research/build/construct/band-column-dp/) — Découper le plateau en bandes de deux rangées, résoudre chaque bande à la perfection par une DP colonne par colonne sous faisceau, puis enchaîner les bandes de haut en bas. Un plateau complet à 444 bords appariés sur 480 en 35 secondes; toute la perte se loge dans les coutures verticales tardives. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. --- # DP par colonnes en bandes > Découper le plateau en bandes de deux rangées, résoudre chaque bande à la perfection par une DP colonne par colonne sous faisceau, puis enchaîner les bandes de haut en bas. Un plateau complet à 444 bords appariés sur 480 en 35 secondes; toute la perte se loge dans les coutures verticales tardives. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/construct/band-column-dp/ - Mise à jour: 2026-07-22 - Sujets: construction - Source: Zhou & Hansen, Beam-Stack Search : Integrating Backtracking with Beam Search (ICAPS 2005) — https://cdn.aaai.org/ICAPS/2005/ICAPS05-010.pdf --- Le [faisceau au niveau des cases](/fr/research/build/construct/beam-search/) fait croître un plateau case par case. La DP par colonnes en bandes change le grain du mouvement : on découpe le plateau 16×16 en bandes de deux rangées, on résout chaque bande à la perfection par une programmation dynamique colonne par colonne sous élagage en faisceau, puis on enchaîne les bandes de haut en bas, chaque bande nouvelle héritant de la rangée du bas de la précédente. Une bande isolée se résout toujours parfaitement. La chaîne complète un plateau entier à 444 bords appariés sur 480 en 35 secondes, et la totalité des 36 bords manquants se localise, par un calcul exact, dans les coutures verticales de la moitié basse : un échec d'horizon glouton, pas un accident d'inventaire de pièces. Une réserve gouverne tout ce qui suit. Chaque nombre de cette page provient d'une seule exécution déterministe par configuration, tirée du carnet : un ordre de construction fixe, aucun balayage de graines. « Échoue » signifie toujours « a échoué sous le faisceau et le budget indiqués », jamais « impossible ». ## Comment elle se déroule sur un plateau Traitons une bande de deux rangées comme une suite de colonnes lue de gauche à droite. Un état de la DP à la colonne $j$ est (pièce du haut et rotation, pièce du bas et rotation, ensemble des pièces déjà utilisées, score accumulé). Une transition vers la colonne $j+1$ pose une nouvelle paire haut/bas et peut gagner au plus 3 bords : deux appariements horizontaux contre la colonne précédente et un appariement vertical à l'intérieur de la nouvelle colonne. La DP exacte est exponentielle en l'ensemble des pièces utilisées; la liste d'états est donc élaguée aux $K$ meilleurs par colonne, le même élagage que le faisceau au niveau des cases, appliqué à un pas plus grossier : une colonne entière de bande par étape, deux pièces à la fois, ce qui exploite directement la structure 2D. Les cases du bord (qui exigent la couleur grise) réduisent fortement les candidats sur le pourtour. Le travail par bande est en $O(n \cdot K \cdot |P|^2)$; pour $n = 16$, $K = 10^4$, $|P| = 256$, cela fait de l'ordre de $10^{10}$ transitions candidates par bande : des minutes dans un moteur compilé, des heures en Python. C'est de l'arithmétique de conception, pas une mesure; c'est elle qui a motivé l'écriture du solveur en Rust. ## L'arithmétique des bandes Un plateau $n \times n$ compte $E = 2n(n-1)$ bords internes : 480 pour $n = 16$. Une bande de deux rangées contient au plus $3n - 2$ bords appariés (46 pour $n = 16$). En enchaînant des bandes qui partagent une rangée, chaque bande après la première apporte $2n - 1$ bords nouveaux (31), et la somme télescope exactement : $$ (3n - 2) + (n - 2)(2n - 1) = 2n(n - 1) = E. $$ Si chaque bande enchaînée était parfaite, la chaîne produirait donc un 480 complet. La décomposition ne perd rien en principe; l'identité comptable est élémentaire et indépendante de toute exécution. Le hic, et la tension centrale de cette page : une bande résolue à la perfection fige sa rangée du bas, et ce choix précis peut rendre la bande suivante infaisable ou sous-optimale. Des bandes parfaites isolément ne se composent pas en une chaîne parfaite. ## Une bande, c'est facile Mesuré, une exécution par configuration : la DP par colonnes a résolu la première bande à son maximum théorique sur toutes les tailles essayées, du 4×4 jusqu'au vrai 16×16 (46 sur 46 en 68 s à faisceau 5 000; les tailles plus petites ont pris de 0,1 à 12 s). Un constat contre-intuitif mérite son encadré : davantage de couleurs de bords rend la bande *plus rapide*, pas plus lente. Sur des instances 8×8, 5 couleurs ont pris 6,5 s et 8 couleurs 1,6 s. Plus de couleurs, c'est des contraintes plus serrées, donc moins de transitions faisables, et le faisceau se contracte. C'est l'inverse de ce que vivent les méthodes par hachage et échantillonnage. ## Enchaîner les bandes : un plateau complet en 35 secondes L'enchaînement de 15 bandes de haut en bas à faisceau 100 000 a complété un plateau entier de 256 pièces à **444 bords appariés sur 480 en 35 s**. Convention de score : ce plateau ignore les cinq pièces indices officielles (0 sur 5 en place); le 444 est donc un décompte de bords appariés sur un plateau non contraint, incomparable aux records qui respectent les indices. La variante respectueuse des indices, plus bas, atteint un partiel de 240 cases à 414 sur 480 avec les cinq indices. Pour les conventions et les chiffres en vigueur, côté communauté comme côté carnet, voir la [page des records](/fr/research/records/). Les scores par bande racontent l'histoire en une ligne : les bandes 0 à 7 sont toutes parfaites, puis une décrue monotone. | Bande (de haut en bas) | 0 à 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Score (sur 46) | 46 chacune | 45 | 45 | 43 | 42 | 40 | 36 | 35 | La largeur a ici une zone utile étroite, qui prolonge l'histoire des coûts de la [page recherche en faisceau](/fr/research/build/construct/beam-search/) : le faisceau 50 000 meurt à la dernière bande sans aucun état faisable (240 cases posées sur 256); le faisceau 100 000 termine; le faisceau 500 000 est contre-productif, le seul tri par colonne épuisant le budget (interruption en pleine première bande à 138 s). La zone utile se situe vers $10^5$. Une exécution par largeur; la frontière « 50 000 échoue, 100 000 termine » n'a pas été répliquée sur d'autres ordres ni d'autres départages. ## La perte loge dans les coutures verticales Relier les scores de bandes au score du plateau donne une identité exacte : les bords appariés du plateau égalent la somme des scores de bandes moins les bords horizontaux des rangées partagées, que la chaîne compte deux fois. Sur le plateau à 444, les scores de bandes somment à 654, et $654 - 444 = 210 = 14 \times 15$ : la somme horizontale des rangées partagées est à son maximum, autrement dit **chaque bord horizontal de chaque rangée partagée est apparié**. La totalité des 36 bords manquants se loge dans les coutures verticales entre les rangées 8 à 15, plus la rangée du bas : | Couture (en descendant) | 8/9 | 9/10 | 10/11 | 11/12 | 12/13 | 13/14 | bande finale | | --- | --- | --- | --- | --- | --- | --- | --- | | Bords perdus | 1 | 1 | 3 | 4 | 6 | 10 | 11 | (Le dernier chiffre se partage entre la dernière couture verticale et la rangée du bas.) C'est de l'arithmétique exacte sur un plateau mesuré; la structure qu'elle révèle (horizontales gratuites, verticales coûteuses) est le mécanisme général. La chaîne obtient gratuitement les bords horizontaux de chaque bande, puisqu'ils vivent à l'intérieur de la bande en cours d'optimisation, mais paie les bords verticaux avec des couleurs figées une bande plus tôt; à mesure que l'inventaire de pièces s'épuise, les couleurs de bas de bande figées cessent de correspondre à ce que les pièces restantes peuvent fournir. L'exécution respectueuse des indices rend la fin de partie dénombrable. Comparer le multi-ensemble de couleurs dont la dernière rangée a *besoin* sur ses bords supérieurs (dicté par les bas figés de la rangée précédente) à ce que les 16 pièces restantes peuvent fournir a montré 4 couleurs demandées mais absentes et 5 fournies mais inutiles : 5 cases de la dernière rangée avec littéralement zéro candidat faisable. Aucune recherche sur la dernière rangée n'y peut rien. La chaîne a besoin d'une contrainte tournée vers l'arrière (le multi-ensemble des couleurs de bas figées de chaque rangée doit rester couvert par les pièces restantes) que la construction purement descendante ne voit jamais. ## Un horizon glouton, pas un bas de plateau difficile Le bas du plateau est-il intrinsèquement plus dur ? Non : lancée de haut en bas, la chaîne produit 7 bandes parfaites depuis le bord supérieur, décroît, et échoue en *bas*; lancée de bas en haut, elle produit 7 bandes parfaites depuis le bord inférieur, décroît, et échoue en *haut*. Les deux directions s'arrêtent à 16 cases d'un plateau complet (240 posées sur 256), une exécution par direction. L'échec atterrit toujours au bord le plus éloigné de l'ancrage : chaque bord impose son propre jeu de contraintes, une chaîne ancrée satisfait le bord proche et dérive librement vis-à-vis du bord lointain, et la dérive se cumule. La décrue est une propriété de l'engagement glouton unidirectionnel, pas des rangées du bas. Pourquoi ne pas lancer les deux directions et recoller ? Apparier naïvement une moitié haute et une moitié basse indépendantes à la couture médiane exige l'accord de 16 couleurs; sous un modèle de couleurs aléatoires, la probabilité vaut environ $(1/23)^{16} \approx 10^{-22}$. Un rendez-vous exige une construction conjointe, pas deux exécutions indépendantes. S'ancrer au milieu est pire, dans la seule configuration essayée : partir d'une bande centrale (aucun bord sur les deux rangées) n'a pas réussi à compléter ne serait-ce qu'une bande à faisceau 5 000 en 120 s; des faisceaux plus larges n'ont pas été essayés. Un comptage grossier dit pourquoi : la contrainte de bord réduit les candidats d'environ 12 fois (environ 45 000 placements de paires faisables par état au bord contre environ 490 000 à l'intérieur). Les bords sont de la contrainte gratuite; l'intérieur n'offre au faisceau aucune prise. ## Leviers : regard en avant et reconstruction de la moitié basse **Regarder une bande en avant.** Reclasser les états du faisceau selon $\alpha \cdot (\text{score courant}) + \beta \cdot (\text{compatibilité avant})$, où la compatibilité avant compte, pour chaque couleur de bas figée $c$, combien de pièces restantes peuvent encore y répondre par leur bord supérieur, sous la forme log-somme $\sum_c \log(1 + \nu_c)$; $\alpha = 1$ et $\beta$ dans $[0{,}01;\ 0{,}1]$ gardent le score dominant. Cela vise exactement la perte des coutures verticales ci-dessus : cesser d'optimiser seulement la bande en cours, protéger les couleurs dont la bande suivante aura besoin. Effet mesuré, exécution unique : +3 bords sur la chaîne complète, de 444 à 447 (bords appariés, indices non imposés), pour un coût négligeable (environ 0,5 s par bande à faisceau $10^5$). **Reconstruire la moitié basse.** Sur le plateau à 444, les 8 rangées du haut plus leur couture d'interface portent 248 bords parfaitement appariés. Les geler et ne reconstruire que les 8 rangées du bas (un ensemble fixe de 128 pièces restantes contre une interface fixe de 16 couleurs) préserve ces 248 automatiquement, et la moitié reconstruite est majorée par 232 bords internes : une reconstruction parfaite serait littéralement un 480, et même une reconstruction parfaite sur les seules verticales dépasserait 460. La reconstruction est le problème que le solveur de bandes résout déjà (une chaîne partie d'un vecteur de couleurs de haut fixé); l'opérateur coûte donc 1 à 2 minutes. C'est une borne sur l'opérateur, pas une affirmation d'atteignabilité. Mesurée, la reconstruction gloutonne est un résultat nul : reconstruire la moitié basse avec la même DP gloutonne retombe exactement sur 444 où que la ligne de gel soit tracée (gel jusqu'à la rangée 7 : 444; jusqu'à la rangée 11 : 444; seule la reconstruction triviale de la dernière rangée conserve l'entrée à 447). La perte des bandes tardives est un artefact d'horizon glouton, pas un accident réparable du choix des pièces restantes : relancer le même glouton sur le reliquat depuis n'importe quelle rangée de départ aboutit au même endroit. Le +3 du regard en avant est le seul gain algorithmique trouvé dans cette famille. Portée : seule la reconstruction gloutonne sous faisceau a été testée; une résolution exacte de la moitié basse à 128 pièces (un problème d'appariement contraint) a été proposée et jamais lancée, si bien que la borne ci-dessus n'est pas entamée par ce négatif. ## Jouer avec les indices officiels Imposer les cinq pièces indices officielles exige de réserver chaque pièce indice dès le début de la construction. La version naïve a laissé une bande précoce dépenser gloutonnement une pièce dont une case indice avait besoin 10 rangées plus bas, et y est morte (208 cases sur 256, 3 indices sur 5) : une instance nette et concrète du [vol de pièces](/fr/research/why/piece-theft/), où un placement localement optimal dépense une pièce qu'une contrainte lointaine réclame. Avec les pièces indices en aval réservées d'emblée, la chaîne atteint **240 cases sur 256, les 5 indices respectés, 414 bords appariés sur 480** (dénominateur du plateau complet, 16 cases laissées vides) à faisceau 100 000. Exécution unique. Les pièces de coin ajoutent une contrainte à longue portée du même genre : les 2 pièces de coin (sur 4) que la rangée du haut dépense déterminent les couleurs de coin que la rangée du bas devra produire 14 rangées plus loin. Réserver ou pré-engager les quatre coins est la direction de correction naturelle; elle n'a pas été lancée dans ces mesures. ## Où elle s'arrête La DP par colonnes en bandes est une route rapide vers un bon plateau : 444 bords appariés en 35 secondes, avec chaque bord horizontal de rangée partagée apparié, là où le faisceau au niveau des cases atteint le milieu des 450 (bords appariés) en quelques minutes. Le plafond est l'engagement unidirectionnel lui-même : chaque bande paie ses coutures verticales avec des couleurs choisies une bande plus tôt et aucune recherche locale en bas ne peut les rembourser; c'est pourquoi les gains au-delà de ce palier sont venus du [polissage par destruction-réparation](/fr/research/build/local-search/local-search-alns/) plutôt que d'un surcroît de largeur. Les portes ouvertes que laisse cette famille sont concrètes : une résolution exacte de la moitié basse sous haut gelé, le score de regard en avant appliqué à chaque bande plutôt qu'après coup, et une construction bidirectionnelle conjointe qui se rejoint au milieu par conception plutôt que par chance. ## À lire aussi - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Recherche en faisceau > Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/construct/beam-search/ - Mise à jour: 2026-07-22 - Sujets: construction - Source: Zhou & Hansen, Beam-Stack Search : Integrating Backtracking with Beam Search (ICAPS 2005) — https://cdn.aaai.org/ICAPS/2005/ICAPS05-010.pdf - Source: Harvey & Ginsberg, Limited Discrepancy Search (IJCAI 1995) — https://www.ijcai.org/Proceedings/95-1/Papers/080.pdf - Source: Kool, van Hoof & Welling, Stochastic Beams and Where to Find Them (ICML 2019) — https://arxiv.org/abs/1903.06059 --- Un retour arrière en profondeur d'abord s'engage sur une seule plaquette partielle et creuse. La recherche en faisceau, elle, prend ses précautions : elle maintient en vie les $K$ meilleures plaquettes partielles à la fois, étend chacune d'elles d'une seule case, évalue tous les enfants, puis conserve à nouveau les $K$ meilleurs. L'idée remonte au système de reconnaissance vocale HARPY de Bruce Lowerre, dans les années 1970 ; l' [article sur la beam-stack search](https://cdn.aaai.org/ICAPS/2005/ICAPS05-010.pdf) de Zhou et Hansen offre un bon traitement moderne de cette famille de méthodes et de ses compromis. ## Comment elle se déroule sur une plaquette Fixons un ordre de balayage sur les 256 cases. Un état du faisceau est un placement partiel, l'ensemble des pièces déjà dépensées et un score de bords appariés. Étendre un état à la profondeur $d$ revient à essayer chaque couple (pièce, rotation) légal pour la case $d$ (légal au regard des voisins déjà posés et de l'inventaire restant) et à ajouter au score le nombre de bords nouvellement appariés. On réunit tous les enfants issus des $K$ survivants, on trie, on tronque à $K$, on répète 256 fois, et chaque survivant est alors une plaquette complète. C'est l'inventaire qui distingue ce cas de la recherche en faisceau sur un problème de contraintes générique : chaque pièce n'existe qu'en un seul exemplaire, si bien qu'un placement n'est pas un simple choix local mais un prélèvement sur un budget global. Ce détail décide de tout ce qui suit. ## Regarder un faisceau descendre Le laboratoire ci-dessous fait descendre un faisceau dans un arbre synthétique : facteur de branchement $b = 4$, profondeur $d = 14$, scores déterministes fondés sur un hachage, sans plaquette, parce que les pathologies sont plus faciles à *voir* quand l'instance est assez petite pour être dessinée. Deux traits y sont plantés délibérément : les scores des nœuds sont en partie héritables (un bon préfixe tend à avoir de bons enfants, ce qui fait précisément qu'un faisceau s'effondre sur un seul préfixe), et quelques nœuds **pièges** rapportent un gros score immédiat tout en empoisonnant discrètement chaque descendant : un modèle synthétique en deux lignes du [vol de pièces](/fr/research/why/piece-theft/), où un placement qui marque maintenant dépense une pièce dont l'intérieur profond aura besoin plus tard. > **[Figure]** Interactif : largeur du faisceau contre survie — interactive: BeamWidthLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Étape par étape 1. **Profondeur 0.** Le faisceau se réduit à la racine. À chaque tick, chaque survivant engendre ses $b = 4$ enfants, soit au plus $K \cdot 4$ candidats dans le vivier. 2. **Évaluer, trier, tronquer.** Les enfants réunis sont classés et seuls les $K$ meilleurs survivent. Tout ce qui passe sous le seuil est supprimé *pour toujours* : un faisceau ne revient jamais en arrière, si bien qu'un bon préfixe élagué à la profondeur 5 est inatteignable à la profondeur 10. C'est là qu'on abandonne la complétude. 3. **Observer l'agglutination.** La position horizontale d'un point encode son préfixe de chemin, de sorte que des branches distinctes vivent dans des grappes distinctes. En quelques niveaux, la plupart des survivants partagent un même préfixe à haut score : le compteur de *préfixes distincts* qui tombe vers 1 marque l'effondrement de la diversité, le faisceau dégénérant en glouton-avec-comptabilité. 4. **Suivre la trace rose.** C'est $K = 1$, le glouton pur. Quand il avale un piège ambré (gros gain maintenant, sous-arbre empoisonné ensuite), sa courbe de score s'aplatit définitivement. Un faisceau plus large ne survit au même piège que tant que ses survivants sont encore répartis sur plusieurs branches ; une fois effondré, il est tout aussi crédule. 5. **Faire glisser $K$ de 1 à 64.** Le score final grimpe puis s'aplatit ; chaque doublement de largeur rapporte moins, ces mêmes rendements à peu près logarithmiques que ce projet a mesurés sur des plaquettes réelles. Remarquez ce que le curseur ne change jamais : l'effondrement se produit quand même, seulement quelques niveaux plus tard. ## Ce qu'elle coûte La recherche en faisceau est une recherche exponentielle dont on a supprimé l'exponentielle par décret : $$ \text{time} \;=\; O(K \cdot b \cdot d), \qquad \text{memory} \;=\; O(K \cdot d), $$ pour une largeur $K$, un facteur de branchement $b$ et une profondeur $d$ (plus un tri en $O(Kb \log Kb)$ par niveau). Les deux sont linéaires en $K$, et c'est là tout l'attrait. Le prix, c'est l'*incomplétude* : un faisceau n'offre aucune garantie d'optimalité, aucun certificat en cas d'échec, et aucun moyen de revenir à un préfixe élagué. Son unique mode de défaillance systématique est l'effondrement que montre le laboratoire : quand les survivants deviennent $K$ copies d'un même préfixe, la largeur effective vaut 1, quel que soit le prix payé. À l'échelle d'Eternity II l'arithmétique est clémente, et c'est exactement pour cela que les faisceaux sont ici le moteur ex nihilo : $d = 256$ cases, $b$ = le nombre de candidats (pièce, rotation) légaux par case, quelques centaines au début, décroissant à mesure que l'inventaire se vide, si bien que même $K = 10^4$ coûte de l'ordre de $10^8$–$10^9$ évaluations d'enfants par plaquette complète : des minutes sur un ordinateur portable, incomparablement moins cher que tout chiffre exhaustif de la [page sur les impasses](/fr/research/build/dead-ends/). Ce que dit vraiment $O(K \cdot b \cdot d)$, ce n'est pas « bon marché » mais « aussi bon que sa seule fonction d'évaluation » : le faisceau évalue une fraction infime de l'arbre, et aucun score connu ne prédit quels préfixes de profondeur 100 se complètent encore bien. La largeur s'achète en monnaie linéaire ; la clairvoyance n'est pas à vendre. L'affirmation « des minutes sur un ordinateur portable » repose sur une courbe de coût mesurée. Sur un seul cœur du moteur de ce projet (balayage ligne par ligne, égalités tranchées par une loterie ensemencée entre scores exactement égaux ; tous les scores ici sont des bords appariés sur 480) : | Largeur $K$ | Temps par plaquette complète | Score brut | | --- | --- | --- | | 2048 | environ 1,8 s | autour de 449 | | 4096 | environ 2,3 s | 450 à 453 | | 8192 | environ 4,8 s | 452 à 453 | | 16384 | environ 10,4 s | 452 à 455 | Dix secondes par plaquette à $K = 16384$, c'est ce qui transforme un faisceau de constructeur en usine à plaquettes ; la section sur la diversité y revient plus bas. ## La largeur rapporte moins qu'on ne l'espère À $K = 1$ le faisceau est une construction gloutonne pure, et le glouton à redémarrages aléatoires a une queue de distribution brutalement lourde : sur le moteur de ce projet, des dizaines de milliers d'essais gloutons aléatoires ont plafonné autour de 408 sur 480, et l'extrapolation de la queue plaçait un 440 à des milliards de redémarrages. Élargir le faisceau vaut bien mieux, et le carnet dispose désormais de la distribution plutôt que de la tendance. Avec le départage transformé en loterie explicitement ensemencée (balayage ligne par ligne, égalités tranchées uniquement entre scores exactement égaux, bords appariés sur 480 partout), 32 graines par largeur donnent min / médiane / max de 361 / 373 / 389 à $K = 1$, 436 / 442 / 446 à $K = 64$, 444 / 447 / 451 à $K = 512$ et 446 / 450 / 452 à $K = 2048$ (23 graines dans ce dernier cas). Pousser la largeur à l'extrême ne déplace le sommet que d'un peu : 451 / 453 / 455 sur 32 graines à $K = 16384$, pareil à 32768, et 454 / 454,5 / 455 à $K = 131072$ (4 essais seulement, petit échantillon). Rien dans toute cette grille n'a dépassé 455 : sur ce producteur, la largeur seule n'a jamais franchi 455 bords appariés. (Mesuré sur le moteur de ce projet, non reproduit de façon indépendante ; pour situer ces chiffres ex nihilo face aux résultats communautaires, voir la page des [records](/fr/research/records/).) Les rendements sont à peu près logarithmiques en moyenne, et même pas garantis monotones. Sur un banc d'essai antérieur (les cinq pièces indices épinglées, un budget global de non-appariements, ordre de départage balayé), $K = 512$ a donné 415, $K = 2048$ a donné 450 avec une plaquette complète, et $K = 4096$ est retombé à 432 : trop étroit élague le futur vainqueur, trop large inonde le front de quasi-doublons partageant les mêmes engagements précoces condamnés. Une seule configuration sur un seul banc, mais la même courbe en U a resurgi indépendamment dans l'étude de déduplication plus bas ; ce qui compte comme doublon importe autant que la largeur. Une tentative de remède au problème de clairvoyance mérite d'être avouée : classer chaque candidat d'après un unique déroulé glouton s'est révélé trop bruité pour aider. À $K = 64$, cela a donné 426 là où le faisceau nu donnait 446, pour environ 170 fois le coût (une seule configuration, non balayée). Le sommet plat de ces distributions est structurel, pas un tirage chanceux retrouvé. Trois graines indépendantes de la même configuration $K = 2048$ ont atteint exactement 452 bords appariés avec les cinq pièces indices en place, et les trois plaquettes ne s'accordent deux à deux que sur environ 6 à 10 placements de pièces sur 256 : le niveau d'accord d'arrangements aléatoires sans lien partageant les indices. Treize pour cent des graines atteignent exactement 452 et à peu près la moitié tombent à deux points près. Des plaquettes sans lien qui convergent vers un même nombre, cela dit que le plafond appartient à la classe du producteur, pas à une famille de plaquettes en particulier ; et les essais plus larges ci-dessus montrent que le plafond de cette classe est en réalité 455, l'accumulation à 452 étant elle-même un artefact de largeur. Il y a une raison structurelle pour laquelle un faisceau pur ne peut guère être plus que « glouton, en plus large ». Un état de faisceau à la profondeur $d$ fait face exactement aux mêmes contraintes d'appariement de bords et d'inventaire qu'un nœud de DFS à la profondeur $d$ ; maintenir de nombreux états en vie ne relâche rien, et aucune fonction d'évaluation connue pour Eternity II ne prédit de façon fiable quels préfixes de profondeur 100 se complètent encore bien. Cette page concluait autrefois de cet argument que la largeur supplémentaire du faisceau ne faisait pour l'essentiel que reproduire ce que les redémarrages aléatoires d'un retour arrière fournissent déjà. Une mesure en tête-à-tête, ci-dessous, a montré que cette conclusion était fausse : la largeur paie exactement quand l'échec se noue bien au-dessus de la profondeur où il affleure. ## Le faisceau face à la profondeur d'abord, à coût égal La comparaison la plus propre du carnet oppose trois formes de recherche sur un même générateur de candidats et un même évaluateur, à budget de nœuds égal, si bien que la seule variable est ce que chaque recherche fait des mêmes coups. Le score est en bords appariés, avec une tolérance globale fixe de non-appariements. À environ 20 à 25 millions de nœuds chacune, la recherche en profondeur d'abord s'est enlisée à la profondeur 213 sur 256 cases avec 368 bords appariés ; la recherche à divergences limitées s'est enlisée à la profondeur 203 avec 349 ; le faisceau à $K = 2048$ a atteint la profondeur 256, une plaquette complète à 455 bords appariés. Avec les cinq pièces indices épinglées et 20 millions de nœuds, la profondeur d'abord s'est enlisée à la profondeur 190 (322 bords appariés, en ne tenant que trois indices sur cinq), tandis que le faisceau a complété la plaquette à 450 sur 480 avec les cinq indices en place, en environ huit secondes sur un seul fil d'exécution. Et ce n'est pas une loterie de graines : huit permutations de l'ordre de départage ont rendu une sortie identique à l'octet près. Le mécanisme est la correction promise plus haut. Une recherche en profondeur d'abord qui s'est trompée quarante cases au-dessus de l'endroit où elle échoue doit défaire chaque niveau intermédiaire avant de pouvoir toucher à l'erreur précoce, et les nœuds de cet intervalle sont exponentiellement nombreux. Les $K$ survivants du faisceau encodent déjà des choix superficiels différents, conservés côte à côte, si bien qu'une correction peu profonde est disponible à coût linéaire par niveau. La largeur ne relâche aucune contrainte ; ce qu'elle achète, c'est un substitut au retour arrière profond qu'une recherche en profondeur d'abord ne peut pas se payer. Sur ce puzzle, les engagements fatals se prennent bien au-dessus de la profondeur où ils affleurent, et c'est exactement le régime où ce substitut rapporte. La recherche à divergences limitées mérite son propre résultat négatif. La [LDS de Harvey et Ginsberg](https://www.ijcai.org/Proceedings/95-1/Papers/080.pdf) revisite le chemin glouton à quelques déviations à la fois, et gagne quand une bonne solution ne diffère du glouton qu'en quelques endroits précoces. Ici, elle n'a jamais égalé la profondeur d'abord pure à aucun budget testé (profondeur 196 contre 204 à un demi-million de nœuds, 203 contre 213 à 20 millions) et s'est montrée 10 à 30 fois plus lente par unité de progrès. Cela a tenu dans toutes les configurations essayées (divergence maximale de 5 à 20, deux budgets de non-appariements, avec et sans les indices), quoique toujours sur ce seul banc et ce seul évaluateur. La lecture : l'échec de budget de pièces est diffus, beaucoup de cases précoces éparpillées doivent toutes être tombées juste, si bien que toutes les coquilles à faible divergence autour du chemin glouton sont condamnées ensemble. Une note de portée. Les scores absolus de cette comparaison viennent d'un banc volontairement simple ; les producteurs ailleurs sur cette page les dépassent. La revendication est l'ordre relatif à coût de nœuds égal (faisceau devant profondeur d'abord devant LDS), pas les nombres. ## La diversité est le vrai bouton Livré à lui-même, un faisceau s'effondre : en quelques dizaines de cases, la plupart des survivants partagent un même préfixe à haut score, et le faisceau dégénère vers un glouton doté d'un surcroît de comptabilité. Les correctifs classiques sont la déduplication de préfixes et l'échantillonnage dans les $2K$ meilleurs plutôt que la prise des $K$ meilleurs, et les constructeurs de ce projet emploient les deux. Mais le levier de diversité le plus puissant trouvé ici ne se situait pas du tout dans le faisceau : c'était l'ordre de balayage. Faire tourner le même faisceau sous neuf ordres de visite différents ([GAUNTLET](/fr/research/lab/experiments/raphael-anjou/pipelines/gauntlet/)) a produit dix-huit familles de plaquettes distinctes là où seize graines d'un seul ordre en avaient produit une. L'ordre de balayage coupe pourtant dans les deux sens. Pour un évaluateur qui compte les appariements contre les voisins déjà posés, un ordre domine tout simplement en score brut : ligne par ligne a battu la spirale et le bord-d'abord d'un écart stable de 4 à 6 bords appariés à chaque largeur de $K = 2048$ à $K = 131072$ (médianes montant de 453 à 454,5 pour ligne par ligne, contre 448 à 450,5 pour la spirale et 448 à 450 pour le bord-d'abord). Le mécanisme est la visibilité. Passées la première ligne et la première colonne, l'ordre ligne par ligne engage chaque case contre deux voisins déjà posés ; la spirale et le bord-d'abord traversent de longues plages où une case n'est évaluée que contre zéro ou un voisin, leurs paris précoces sont donc moins informés, et aucune largeur ne répare entièrement un pari précoce moins informé. Les ordres perdants gagnent quand même leur place : ils déplacent la fin de partie difficile vers d'autres régions de la plaquette (on y revient dans la section sur le mur), ce qui en fait une source de population même à score brut plus bas. L'autre bouton fécond est le départage. [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/) tranche les égalités de score en faveur des pièces fréquentes à cette position dans un corpus de plaquettes fortes, relevant le plafond ex nihilo de quelques bords et atteignant 460 après raffinement (un chiffre de carnet ex nihilo, convention des bords appariés sur 480 ; voir la page des [records](/fr/research/records/) pour situer ce nombre face aux résultats communautaires). [LODESTONE](/fr/research/lab/experiments/raphael-anjou/learning/lodestone/) tranche les égalités en faveur des pièces qui servent des demandes rares, gagnant une petite amélioration médiane et une bien meilleure régularité, puis s'effondrant gravement dès que la loi a priori passe du rôle de départage à celui d'objectif. La loterie de départage a ses propres arêtes vives. Tirer au hasard *lequel* des candidats exactement à égalité survit, c'est de la diversité presque gratuite ; élargir ce qui compte comme égalité ne l'est pas. Traiter comme à égalité les candidats à un bord apparié du meilleur a coûté environ 50 à 60 points à chaque largeur testée, et à deux bords, 150 à 160 (mesuré jusqu'à $K = 2048$ ; largeurs supérieures non essayées). Le signal glouton se dilue plus vite que la largeur ne le récupère. Et la loterie se tarit. Au-delà de quelques centaines de survivants, les égalités exactes de score disparaissent pour l'essentiel, si bien qu'un faisceau à départage aléatoire devient déterministe en pratique, la même plaquette à chaque graine (la comparaison à coût égal plus haut a vu la même chose sous la forme d'une sortie identique à l'octet près quel que soit l'ordre de départage). Restaurer la diversité à grande largeur, c'est perturber les scores eux-mêmes. Ajouter un bruit de Gumbel au score de chaque candidat, l'astuce standard pour échantillonner des séquences sans remise ([Kool, van Hoof et Welling](https://arxiv.org/abs/1903.06059)), achète la diversité sur un tarif explicite : à température 0 le faisceau est déterministe et a atteint 460 bords appariés après raffinement, la même plaquette à chaque graine ; à 0,1 il a construit entre 446 et 453 avec une structure de coins réellement différente par graine ; à 0,5, 438 à 441 ; à 2,0 il s'est effondré vers 240 à 252 environ. Trois graines par température : fiez-vous à la forme du compromis plutôt qu'aux chiffres exacts. La déduplication, l'autre correctif classique, cache un piège qui interagit avec la largeur. Avec une clé grossière (survivants dédupliqués par l'ensemble des pièces utilisées), la courbe de largeur est ressortie en U dans un balayage à un essai par point : 446 à $K = 64$, 453 à $K = 1024$, puis retombée à 449 à $K = 4096$, parce qu'à grande largeur des quasi-doublons ne différant que par leur histoire récente évincent des préfixes réellement distincts. Une clé sensible au chemin a rétabli des gains monotones et atteint 455 bords appariés à $K = 16384$ (environ 21 minutes sur un seul fil dans cette implémentation précoce, autour de 10 Mo de mémoire). Un essai par point : une pathologie observée, pas une loi ; mais avec le point d'équilibre non monotone plus haut, cela fait deux observations du même mode de défaillance. Ce qui compte comme doublon est un choix de conception à part entière. Réunissez la loterie ensemencée et la table de coûts, et le faisceau cesse d'être un constructeur de plaquette unique : c'est une usine à plaquettes fortes sans lien entre elles. 160 graines à $K = 16384$ ont donné 19 plaquettes à 455 bords appariés, 27 à 454, 48 à 453, 46 à 452, 19 à 451 et une à 450 ; les 94 plaquettes à 453 ou mieux avaient toutes leurs treize premières lignes deux à deux distinctes, des familles de plaquettes distinctes plutôt que des variations d'une seule. Cela fait environ 1160 plaquettes par heure sur une modeste exécution parallèle à quatre voies, avec à peu près une graine sur huit atteignant le plafond de 455 et aucune n'atteignant 456. La diversité produite en masse est exactement l'entrée que réclame le polissage en aval. ## Le mur de profondeur Toutes les variantes de faisceau essayées ici s'enlisent de la même manière. La bordure et le premier intérieur se remplissent presque parfaitement ; les non-appariements se concentrent dans les dernières rangées, là où les pièces dont une case a besoin ont été dépensées bien plus tôt au service de cases plus faciles : le problème du [vol de pièces](/fr/research/why/piece-theft/). Un objectif local glouton ne peut pas voir ce budget global, et doubler $K$ ne recule le mur que d'un ou deux bords. Sur ce moteur, les faisceaux ex nihilo plafonnent au milieu des 450 ; la distance restante s'achète par le [polissage par destruction-réparation](/fr/research/build/local-search/local-search-alns/), et non par plus de largeur. Sur ce puzzle, la recherche en faisceau est un bon moyen d'atteindre vite le plateau, et aucunement un moyen de le quitter. La carte des non-appariements se mesure, et elle bouge avec l'ordre de balayage. Sur les plaquettes ligne par ligne, les dernières rangées portent l'essentiel des dégâts : sur une plaquette complète à 450 sur 480 avec les cinq indices en place, les rangées 13 à 15 concentraient 21 des 30 non-appariements. Un ordre en spirale étale au contraire ses non-appariements sur les rangées du milieu, parce que ses dernières cases sont le centre de la plaquette ; le bord-d'abord les concentre sur l'anneau le plus intérieur. L'emplacement du mur est une propriété de l'ordre de visite, pas du puzzle. Choisir l'ordre peut même relever le plafond d'un bord : un ordre de balayage en peigne, dont les non-appariements tombent en bandes verticales plutôt qu'en bas de plaquette, a produit six plaquettes brutes à 456 bords appariés sur 120 graines et à peu près le double du taux habituel de 455, là où ligne par ligne n'a produit aucun 456 en 160 graines. (Scores bruts de constructeur, convention des bords appariés ; la page des [records](/fr/research/records/) les met en contexte.) Deux observations du carnet précisent de quoi le mur est fait. D'abord, le faisceau atteint des complétions qu'un retour arrière n'autorisant qu'un non-appariement par case ne peut structurellement pas construire : la plaquette à 450 ci-dessus porte une case à deux bords non appariés, et un enfant à double non-appariement peut survivre dans le top $K$ alors qu'aucun chemin en profondeur d'abord à un seul non-appariement par case n'y mène. Ensuite, sur le propre préfixe de 240 cases du faisceau, un finisseur exact par séparation et évaluation a fait pire (433 ou 420 bords appariés, selon la part du préfixe épinglée) que la complétion du faisceau lui-même à 450 : la largeur avait déjà mieux exploré la queue qu'une recherche exacte limitée en profondeur ne le peut, complétions à double non-appariement comprises. ## À lire aussi - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [GAUNTLET](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/gauntlet/) — Lancer la même recherche en faisceau selon neuf ordres de parcours différents, pour qu'elle atterrisse dans des régions distinctes au lieu de toujours converger vers la même. L'ordre en zigzag a trouvé un plateau 458 inédit. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - [STAGED](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construire tout le plateau depuis zéro, sans cadre pré-posé, par étapes, en laissant la bordure émerger en dernier des pièces restantes. - [LODESTONE](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/lodestone/) — Une boussole ténue pour une recherche partie de zéro : l'inciter à engager les pièces rares tôt, là où elles sont nécessaires. Elle ne relève pas le plafond ; elle fait que la recherche atteint de façon fiable le sommet de sa propre plage. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. --- # Le jeu de données > Un jeu de données public sous licence CC0 pour Eternity II, en deux volets : quatorze instances de référence à résoudre, et un corpus de 7 658 plateaux forts distincts dont on peut s'inspirer. Chaque score est recalculé à partir du plateau lui-même, et le corpus est vérifié comme réellement varié, plutôt que mille copies d'un même plateau. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/dataset/ - Mise à jour: 2026-07-16 - Sujets: structure, learning - Source: Le jeu de données (ce dépôt) : les instances, l'archive zip du corpus de plateaux forts, le README et le script de génération — https://github.com/raphael-anjou/eternity2/tree/main/research/datasets --- Deux besoins reviennent sans cesse quand on travaille sur Eternity II : il faut des instances contre lesquelles lancer un solveur, et, si l'on veut s'inspirer des plateaux forts, il faut un corpus de tels plateaux. Ce jeu de données regroupe les deux, versé dans le domaine public sous licence [CC0](https://creativecommons.org/publicdomain/zero/1.0/), afin qu'il puisse être réutilisé pour n'importe quel usage sans attribution. Il comporte deux volets, tous deux hébergés dans le [répertoire du jeu de données](https://github.com/raphael-anjou/eternity2/tree/main/research/datasets). ## Volet A : les instances de référence Quatorze instances sur lesquelles un solveur s'exécute, chacune sous la forme d'un fichier JSON autonome contenant le jeu de pièces, les indices épinglés éventuels et le score maximal atteignable. - **Dix instances 16×16** (`e2-16x16-v00` … `v09`) : le jeu de pièces officiel d'Eternity II avec trois coins épinglés, selon dix dispositions de coins différentes. Épingler les coins produit dix instances distinctes mais d'égale difficulté à partir d'un seul jeu de pièces, ce qui permet à une étude de comparer les moteurs sur un axe de diversité plutôt que sur un plateau unique. Les trois études de moteurs de ce projet (l' [étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/), l' [étude de réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/) et le [banc d'essai mono-cœur](/fr/research/lab/experiments/single-core-benchmark/)) résolvent exactement ces dix-là. Score maximal : 480. - **Quatre sous-puzzles d'indices** (`e2-clue-clue1` … `clue4`) : les plateaux 6×6 et 12×6 plus petits, issus du jeu d'indices officiel du puzzle. Chacun est connu pour admettre une solution complète, ce qui en fait un fixture de correction rapide : un solveur incapable de boucler un plateau d'indices a un bug bien avant même d'affronter le puzzle complet. Chaque case est décrite dans l'ordre haut, droite, bas, gauche ; la couleur 0 correspond au liseré gris, et `pos` est l'indice de case en balayage par lignes. La forme d'un fichier d'instance : ```json { "id": "e2-16x16-v00", "family": "official-16x16-pin3corners", "width": 16, "height": 16, "numColors": 22, "pieces": [[up, right, down, left], ...], "hints": [{"pos": 0, "piece": 0, "rot": 3}, ...], "maxScore": 480 } ``` ## Volet B : un corpus de plateaux forts **7 658 plateaux distincts** dont le score va de 400 à 470, la matière première des méthodes qui [s'inspirent des plateaux forts](/fr/research/lab/experiments/raphael-anjou/learning/) : a priori de position, ordonnancement de coups appris, extraction d'anti-motifs. Il est distribué sous forme d'archive zip (`e2-strong-boards.zip`, environ 16 Mo) qui se décompresse vers les mêmes lignes au format CSV et au format JSON-lines : ``` id,score,family,edges e2b-00001,469,f008,adcaaendadwe… (1024 lowercase letters) ``` Le champ `edges` est le plateau lui-même : 256 cases multipliées par quatre côtés, en balayage par lignes, dans l'ordre haut-droite-bas-gauche, `a` pour le liseré gris. C'est exactement la chaîne que lit le visualiseur [e2.bucas.name](https://e2.bucas.name), de sorte que n'importe quel plateau se colle directement dans le visualiseur. La `family` correspond aux quatre pièces de coin du plateau, un indicateur du bassin dans lequel il se situe ; il existe 28 familles distinctes. La distribution des scores culmine nettement dans les 450 et quelques, là où se concentre une large récolte par faisceau mono-cœur, puis s'amincit en une longue traîne, avec 38 plateaux à 460 ou plus et le meilleur à 470. > **[Interactive: CorpusScoreDistribution]** Rendered on the canonical page (link above); not shown in this markdown export. ## Chaque score est recalculé, jamais pris pour argent comptant Aucun score de ce jeu de données n'est recopié d'un champ source. Chacun est recalculé à partir de la propre chaîne d'arêtes du plateau, en comptant les adjacences intérieures concordantes. Ce n'est pas une simple formalité : dans les données source, un plateau portait un score périmé, annonçant 453 alors que ses arêtes en valent en réalité 456, et le recalcul à partir des arêtes corrige cela automatiquement. Redérivez vous-même les scores à partir des chaînes d'arêtes et vous retrouverez exactement les nombres publiés. ## Le corpus est varié, non redondant Un tas de plusieurs milliers de plateaux ne mérite d'être publié que si les plateaux sont réellement différents. Avant de diffuser celui-ci, nous avons vérifié qu'il ne s'agit pas de simples perturbations d'un même plateau, et ce n'est pas le cas : - Seuls 13 des 7 671 plateaux source étaient des doublons exacts ; les autres sont distincts, ce qui en laisse 7 658. - Le plateau *médian* diffère de son plus proche voisin par 235 de ses 256 placements de pièces. Presque aucun plateau ne se trouve à moins de 10 placements d'un autre, et seulement 1 % à moins de 25. Bien que la plupart des plateaux partagent une bande de scores étroite, ils sont structurellement presque entièrement différents. - Les plateaux se répartissent entre 28 familles de coins distinctes plutôt que de s'entasser dans une seule. Le corpus est donc un échantillon réellement varié du paysage des plateaux forts. C'est ce qui importe pour tout ce qui l'exploite : un a priori appris à partir de milliers de copies d'un même plateau encoderait ce plateau-là, et non la structure des bons plateaux en général. ## Le régénérer Le [script de génération](https://github.com/raphael-anjou/eternity2/tree/main/research/datasets) régénère l'intégralité du jeu de données. Les instances sont assemblées à partir des fichiers de variantes publics ; le corpus est dédoublonné, rescoré à partir des arêtes, débarrassé de toute étiquette d'espace de travail (chemins source, noms internes de presets et de graines, noms de fichiers) et ré-indexé avec des identifiants neutres, de sorte que ce qui est distribué se réduit au contenu des plateaux et aux scores vérifiés, rien d'autre. ## À lire aussi - [Faits et chiffres établis](https://eternity2.dev/fr/research/build/known-facts/) — Les chiffres que tout chercheur sur Eternity II finit par redémontrer, rassemblés au même endroit avec leur provenance : la définition du puzzle, le placement des indices, les conventions de score, le tableau des records, la taille de l'espace de recherche et les comptages structurels. - [Nombres de référence](https://eternity2.dev/fr/research/reference/) — Dénombrements exacts du nombre de façons valides de remplir un petit bloc à une position donnée du plateau officiel d'Eternity II, sous des règles de plus en plus contraintes : des nombres sûrs pour vérifier le code d'appariement des bords et de contraintes de votre solveur. - [Apprendre à partir des grilles fortes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. --- # Impasses > Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/dead-ends/ - Mise à jour: 2026-07-22 - Sujets: search-space, learning, exact-methods - Source: Fermeture d'eternity2.net : 1,6 TFlops, 10^19 opérations CPU, aucune solution (groups.io message 3511) — https://groups.io/g/eternity2/message/3511 - Source: Max sur la propagation de probabilités : l'influence des contraintes s'estompe à environ deux cases (groups.io message 6208) — https://groups.io/g/eternity2/message/6208 - Source: Markus Zajc : les macro-tuiles accélèrent mais ne réduisent pas le domaine (groups.io message 5883) — https://groups.io/g/eternity2/message/5883 - Source: Markus Zajc évalue l'élagage par offre de bordure : 0,0014 % de tests en moins, 8 % plus lent (groups.io message 6060) — https://groups.io/g/eternity2/message/6060 - Source: Fu, Qiu, Zha : Generalize a Small Pre-trained Model to Arbitrarily Large TSP Instances (AAAI-21) — https://arxiv.org/abs/2012.10658 - Source: Rethinking Heatmap and MCTS for TSP (2024) — https://arxiv.org/abs/2411.09238 --- Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II. Aucune n'est une mauvaise idée en soi ; elles ne suffisent simplement pas à résoudre ce casse-tête. Nous consignons nos constats pour que vous investissiez votre temps ailleurs. Chaque entrée ouvre son verdict par une étiquette de fermeté : **Prouvé** signifie qu'un théorème ou un calcul exact ferme la porte ; **Mesuré** signifie que nous l'avons exécuté (ou que la communauté l'a fait) et vu échouer ; **Rapporté** signifie qu'un autre chercheur l'a exécuté et a documenté l'échec, sans que nous l'ayons rejoué nous-mêmes. Lorsque le verdict provient de nos propres exécutions, la page « pourquoi » liée porte la commande de reproduction exacte, et [exécutez-le vous-même](/fr/research/build/run-it-yourself/) en détaille la mise en place ; lorsque la communauté est arrivée là avant nous, nous citons le message d'archive. ## Briser la symétrie *Supposer que le plateau possède des symétries de rotation ou de miroir, et fixer certaines pièces pour réduire la recherche.* **Prouvé.** Le jeu officiel a été conçu sans pièce à symétrie de rotation et sans doublon, et l'unique indice central fixe l'orientation. Il n'y a aucune symétrie globale à briser : fixer des coins ne fait donc qu'un choix arbitraire, non un choix gratuit. [Pourquoi c'est un mur →](/fr/research/why/rare-color-geography/) L'absence va plus loin que les rotations et les doublons. Nous avons aussi cherché une symétrie par réétiquetage des couleurs : une énumération exhaustive de toutes les permutations de couleurs susceptibles d'envoyer le jeu de pièces sur lui-même (à rotation près) ne trouve que l'identité, parce que chacune des 22 couleurs intérieures possède un profil d'adjacence unique à travers les pièces. Le groupe de symétrie est de taille un ; le générateur a aussi brisé tous les échanges de couleurs. (Les couleurs intérieures portent tout de même une structure utile à connaître : elles tombent dans exactement trois classes de fréquence, 5 couleurs présentes 24 fois chacune, 5 présentes 48 fois et 12 présentes 50 fois, soit 960 demi-bords, deux fois les 480 bords.) ## Vérifier des invariants sur les cases déjà posées *Décomposer le jeu de pièces selon sa structure de réétiquetage des couleurs et élaguer la recherche avec des invariants calculés sur la partie du plateau déjà posée.* **Mesuré**, avec un mécanisme proche d'une preuve. Dans un backtracker qui ne pose jamais que des pièces concordantes, la région posée satisfait toujours toute contrainte qui ne mentionne que des cases posées : la recherche impose ces invariants par construction, si bien qu'un élagueur qui inspecte ce qui est déjà sur le plateau ne se déclenche jamais. Nous avons essayé trois variantes de l'idée et aucune n'a élagué une seule branche ; il n'y a ni accélération ni score à rapporter parce que les élagueurs ne se sont littéralement jamais déclenchés. Une variante à parcours en spirale était en outre pire, non meilleure, car elle perdait le bon ordonnancement de la région de départ. La portée à retenir : ceci réfute les invariants statiques sur la région posée sous une recherche strictement concordante, pas tout usage imaginable de la structure de couleurs du jeu de pièces. Un élagage utile doit regarder ce qui peut encore venir, des vérifications en avant sur les candidats des cases non posées, ou vivre dans une recherche qui tolère des discordances. À comparer au test d'offre de bordure plus bas : celui-là se déclenche trop tard ; ceux-ci ne se déclenchent jamais. ## Il suffit d'y jeter plus de puissance de calcul *Lancer le même solveur SAT ou de recherche sur une machine plus grosse, un GPU, un FPGA ou du matériel quantique.* **Mesuré.** Le mur n'est pas la fréquence d'horloge, c'est la qualité de l'encodage du problème et la forme de l'espace de recherche. Les solveurs SAT sur GPU offrent au mieux une petite accélération constante ; les recuits quantiques ne montrent aucun avantage à l'échelle qu'il faudrait ici. Le même algorithme, plus rapide, atteint le même mur un peu plus tôt. La communauté a mené cette expérience à grande échelle : la grille eternity2.net a lancé 1,6 téraflops et plus de $10^{19}$ opérations CPU sur le casse-tête, puis a fermé sans solution ([msg 3511](https://groups.io/g/eternity2/message/3511)). Et l'espoir quantique est régulièrement remis à flot, de [2007](https://groups.io/g/eternity2/message/1446) à [2024](https://groups.io/g/eternity2/message/11407). Le plafond auquel cela se mesure est le record en vigueur de 470/480 ; Blackwood, qui l'a établi, a rapporté que les solveurs SAT, les GPU et les caches de 2×2 pré-résolus ne l'ont pas aidé à le dépasser ([Records et solveurs](/fr/research/records/)). [Pourquoi c'est un mur →](/fr/research/why/prune-vs-speed/) ## La propagation par sondage (survey propagation) *La méthode de passage de messages qui a résolu d'immenses instances SAT aléatoires en repérant les grappes de solutions.* **Prouvé.** Elle suppose que le problème ressemble localement à un arbre. Eternity II est une grille avec un court cycle dans chaque bloc 2×2, ce qui invalide cette hypothèse. En pratique, les messages s'aplatissent au lieu de s'affiner, l'inverse exact de ce qui la fait fonctionner sur le SAT aléatoire. Aucun succès publié n'existe pour elle sur les casse-tête en grille. La communauté a remarqué cet aplatissement très tôt : en 2008, des expériences de propagation de probabilités de pièces ont constaté que l'influence des contraintes issues des indices et des coins semble « s'estomper » à environ deux cases de distance ([msg 6208](https://groups.io/g/eternity2/message/6208)). À la place : l'élagage qui paie sur cette grille est exact, non probabiliste ; la [cohérence d'arc](/fr/research/build/reduce/arc-consistency/) et le [filtre de couplage tous-différents](/fr/research/build/reduce/alldiff-regin/). Nous avons plus tard tenté nous-mêmes le sauvetage évident : passage de messages plus une pénalité lagrangienne par pièce censée restaurer la contrainte d'usage unique, sur un 4×4 généré. Mesuré, et cela ne converge pas. La marginale d'au moins une pièce s'effondre à exactement zéro partout, et une fois une marginale à zéro aucun multiplicateur ne peut la ranimer : l'écart de dualité ne se ferme jamais, le résidu restant autour de 1,2 à 1,7 sur plus de 50 itérations externes dans les trois réglages d'amortissement et de pas que nous avons essayés (marginale de pièce minimale 0,00 dans chaque configuration ; maximale 2,2 à 2,3 là où elle devrait valoir 1). C'est une seule instance jouet et trois réglages, un échec déjà au stade du 4×4. Le contraste avec la note sur les réseaux de tenseurs plus bas est la partie instructive : la même astuce lagrangienne fonctionne quand l'étape interne est une contraction exacte coûteuse et échoue quand c'est un passage de messages bon marché. La précision des marginales internes est tout l'enjeu. ## Ordonner les coups par propagation de croyances *Faire tourner une propagation de croyances sur les couleurs et utiliser ses indications par case pour décider quelle pièce essayer en premier.* **Mesuré.** Les indications ressortent presque uniformes : elles ne départagent donc guère les candidats. Lors d'une confrontation directe, choisir le coup suivant au hasard s'en tirait aussi bien, voire mieux, parce qu'un ordre informé fixe tend à répéter les mêmes erreurs. [Pourquoi c'est un mur →](/fr/research/why/no-forced-moves/) ## Trier les candidats par flexibilité future *Pré-trier chaque liste de candidats pour essayer d'abord les pièces dont les bords bas et droit ouvrent le plus d'options en aval : une heuristique d'ordre des coups qui ne coûte rien au moment de résoudre.* **Mesuré.** Sur le casse-tête officiel, un seul fil d'exécution, 10 secondes × 3 essais contre une base réglée : même profondeur maximale (192), même meilleur score (344 bords concordants), même schéma de visite des nœuds, et le débit est tombé de 84 ou 85 millions à 80 millions de nœuds par seconde, environ 5 %. Un sondage multi-fils de 30 secondes a marqué 429 contre 444 pour la base, mais c'est une graine unique : cela montre que l'ordre peut perturber le résultat, pas qu'il nuit de façon fiable. Le mécanisme : le point le plus profond atteignable était fixé par le calendrier de discordances du solveur, non par l'ordre des coups, et les pièces « flexibles pour la suite » sont corrélées aux pièces populaires que l'ordre existant essaie déjà tôt ; le tri n'apporte donc aucune information, il ne fait que remanier la disposition mémoire et le paie en localité de cache. Portée : c'est le verdict pour un chemin de calendrier réglé sur le casse-tête officiel ; le tableau pourrait différer sur des calendriers sans mur de profondeur ou sur des casse-tête générés aux distributions de couleurs uniformes. Même leçon que l'entrée sur la propagation de croyances ci-dessus, sous un angle moins cher : les ordres statiques informés ne battent pas les défauts ici. ## Le comptage par réseaux de tenseurs *Traiter le plateau comme un réseau de tenseurs et le contracter pour compter ou évaluer les coloriages cohérents aux frontières.* **Prouvé.** Il ne peut imposer que la concordance des bords en contact, jamais que chaque pièce soit utilisée exactement une fois. Cet angle mort est énorme : il dénombre de l'ordre de $10^{90}$ coloriages cohérents aux frontières contre l'unique solution réelle, ou presque, du casse-tête. Le passage de messages local est tout simplement incapable de voir la règle globale d'une pièce par case. [Pourquoi c'est un mur →](/fr/research/why/entropy-area-law/) Un amendement issu de travaux de carnet ultérieurs : l'angle mort peut être rapiécé, à petite échelle. Ajouter une pénalité lagrangienne par pièce par-dessus la contraction restaure assez l'unicité pour résoudre entièrement des casse-tête générés 4×4 (une seconde) et 6×6 (cinq minutes), vérifiés à pièces uniques et entièrement concordants. Le mur de coût arrive bien avant le 16×16 : la première tentative à pleine échelle a épuisé la mémoire vers 3 Go et est morte, et la troncature nécessaire pour tenir risque de jeter trop pour que le correctif garde un sens. C'est une tentative unique : la variante rapiécée est donc non validée à pleine échelle plutôt que prouvée impossible ; le verdict Prouvé ci-dessus porte sur la contraction pure. Imposer l'unicité par multiplicateurs exige des marginales internes précises, et la précision au nombre de couleurs du 16×16 réclame une dimension de lien dont la mémoire et le calcul explosent. ## Résoudre les couleurs d'abord, placer les pièces ensuite *Reformuler le plateau comme un graphe adjoint sur les couleurs, résoudre pour un agencement d'adjacences de couleurs partout cohérent aux bords, puis espérer que cet agencement soit plus facile à transformer en pavage réel qu'une résolution directe sur les pièces.* **Mesuré.** L'idée est élégante et a été explorée sur la liste de 2023 à 2025 : dépouiller le casse-tête pour ne garder que « quelle couleur touche quelle couleur », résoudre cet objet plus petit et s'en servir d'échafaudage. L'ennui, c'est que l'objet plus petit n'est pas petit. Énumérer seulement les agencements de couleurs intérieures pour E2 laisse environ $6.6\times10^{11}$ permutations, et le 17×17 explose à $2.97\times10^{13}$ ([msg 11182](https://groups.io/g/eternity2/message/11182)) ; et chacune d'elles doit encore être vérifiée contre une véritable affectation de pièces, car un agencement cohérent en couleurs n'a nullement à être pavable par les 256 pièces réelles. C'est l'angle mort du réseau de tenseurs sous un autre déguisement : satisfaire les adjacences de couleurs est nécessaire mais loin d'être suffisant, et la contrainte d'utiliser chaque pièce une seule fois, celle qui fait le vrai travail, est précisément ce que la vue « couleurs seules » laisse tomber. Le résumé de l'auteur lui-même après l'énumération : on « passerait beaucoup de temps à n'en valider qu'un seul » agencement contre toutes ses permutations de couleurs internes. [Pourquoi c'est un mur →](/fr/research/why/entropy-area-law/) ## Les bornes par relaxation *Résoudre la relaxation en programmation linéaire pour obtenir un plafond serré sur le nombre de bords qu'un plateau peut faire concorder.* **Mesuré.** La relaxation autorise des pièces fractionnaires réparties sur plusieurs cases, ce qui fabrique des concordances qu'aucun plateau réel ne peut avoir. Le résultat est un plafond autour de 478 alors que les meilleurs plateaux réels tournent autour de 458, un écart bien trop grand pour certifier quoi que ce soit. La contrainte agissante est l'unicité globale des pièces, que la relaxation jette. Les formulations en PL étaient à l'ordre du jour de la communauté dès le premier été, et déjà là un 4×4 mettait plus d'une heure à se résoudre ([msg 1678](https://groups.io/g/eternity2/message/1678)). À la place : la page [relaxations PL et PLNE](/fr/research/build/exact/lp-relaxations/) montre ce que ces encodages peuvent encore rapporter (preuves d'impossibilité et remplissages quasi optimaux sur des sous-plateaux), là où réside réellement leur valeur. La version entière n'est pas un sauvetage à pleine échelle non plus. Les 60 cases de bordure fixées, nous avons demandé à un solveur MIP libre (HiGHS, 4 fils, limite de 30 minutes) un intérieur optimal en entiers : environ 154 000 variables binaires de placement et 13 000 lignes de contraintes. Il est revenu sans trouver le moindre placement entier faisable, et a même étiqueté à tort l'affectation vide « optimale » à l'objectif 0, un rappel qu'il faut contrôler les statuts des solveurs. Portée à tenir serrée : un solveur, réglages par défaut, un budget. Cela ne réfute pas la programmation en nombres entiers ; nous avons depuis vu le choix d'encodage et de solveur tout changer sur des instances plus petites (un solveur de la classe CP-SAT résout entièrement, en moins d'une seconde, des instances où la même pile PL/MIP échoue). Une formulation générique à pleine échelle dépasse simplement ce qu'un solveur grand public peut même trouver faisable en une demi-heure ; les modèles entiers à région restreinte et à corpus restreint fonctionnent, eux, et c'est là que ces solveurs gagnent leur pain. ## Les bases de données de motifs (l'heuristique du Rubik's Cube) *Précalculer, pour chaque petite pièce de territoire, le nombre minimal de corrections de bords qu'exige toute complétion, et sommer ces coûts par zone en une heuristique admissible : la technique qui a percé le Rubik's Cube et le taquin à 15.* **Prouvé.** Sur Eternity II l'heuristique ne porte exactement aucune information, par calcul direct et non par échantillonnage. Le jeu officiel compte 22 couleurs intérieures distinctes et, sur les 256 pièces avec rotation, chacune des 22 est disponible sur chaque côté : tout bord intérieur potentiel est donc individuellement concordable. La borne supérieure par bord ressort à 480, le maximum, et la borne par zone 2×2 (225 zones × 4 bords internes, corrigée du double comptage) vaut aussi exactement 480. Les deux s'effondrent sur l'énoncé trivial que les 480 bords pourraient tous concorder. Les bases de motifs gagnent leur pain quand l'objectif est non additif, quand le coût joint d'une zone dépasse la somme de ses parties, comme les comptes de mouvements du Rubik. Le compte de bords concordants de ce casse-tête est exactement additif par bord, et la seule structure jointe, chaque pièce utilisée une fois, couple les cases globalement, ce qu'aucune zone locale ne peut voir. À la place : les [relaxations PL et PLNE](/fr/research/build/exact/lp-relaxations/), qui encodent, elles, la contrainte globale d'unicité, dominent strictement toute table de zones. ## La réduction de réseaux (LLL) sur les équations de placement *Encoder le placement en équations entières 0/1, prendre le réseau noyau, le réduire (LLL ou BKZ) et chercher la solution comme un problème de vecteur le plus proche : la machinerie derrière les célèbres attaques de sacs à dos et de programmes entiers.* **Prouvé** (les arguments centraux sont structurels ; la sonde d'échelle est mesurée). Trois portes se ferment tour à tour. D'abord, la partie qu'une attaque par réseau traite proprement, chaque case reçoit une pièce et chaque pièce une case, est un système d'affectation totalement unimodulaire, soluble en temps polynomial par l'algorithme hongrois ; nos expériences de récupération (10 instances plantées sur 10 en 2×2 et 3×3 retrouvées exactement, suivant la reformulation en réseau noyau d'Aardal, Hurkens et Lenstra) montrent la méthode résolvant un problème qui n'a jamais été dur. Ensuite, la partie qui est dure, les couleurs en vis-à-vis doivent concorder, est une contrainte conditionnelle (« bilinéaire ») sans plongement fidèle en égalités linéaires hors une explosion combinatoire de variables auxiliaires, qui efface l'avantage du réseau. Enfin, le système d'offre de couleurs n'est pas un sac à dos : chaque coefficient vaut exactement 1, les attaques classiques de somme de sous-ensembles à basse densité (Lagarias et Odlyzko 1985 ; Coster et collègues 1992) ne s'appliquent donc même pas, et une attaque LLL sur le plongement à poids unitaires dégénère en énumération pure. La sonde d'échelle est du même avis : le LLL exact en entiers sur le seul noyau d'affectation facile a pris 0,35 s en 2×2 et 42,6 s en 3×3, et a été tué au-delà de 175 s en 4×4 (dimension du noyau 993) ; l'ossature complète du 16×16 ferait environ 262 000 variables. (Ces temps viennent d'une implémentation exacte en pur Python, un énoncé pratique plutôt qu'asymptotique ; ce sont les arguments structurels qui portent le verdict.) Les sous-réseaux par couleur se réduisent à bas coût, moins d'une demi-seconde, mais 12 des 60 vecteurs les plus courts examinés en 3×3 exigent déjà qu'une pièce occupe deux cases : ils omettent exactement les contraintes qui comptent. La dureté du casse-tête loge dans une forme de problème, couplage bilinéaire plus distinction globale, dont les outils de réduction de réseaux ne sont pas natifs ; le sous-problème dont ils sont natifs est déjà polynomial. ## Apprendre une heuristique sur de petits plateaux *Entraîner un réseau de neurones sur de petits casse-tête, puis le transférer au plateau complet 16×16 pour guider la recherche.* **Mesuré.** Nous avons entraîné un modèle qui excellait sur les petits plateaux et l'avons vu s'effondrer sur le vrai. Il apprend à partir de coups candidats filtrés d'une façon, puis on l'interroge sur des coups filtrés très différemment, et les couleurs du casse-tête complet n'apparaissent jamais à l'entraînement. Le savoir-faire ne franchit pas l'écart de taille et de couleurs. [Pourquoi c'est un mur →](/fr/research/why/rigidity-wall/) ## La descente de gradient sur un plateau adouci *Rendre le plateau différentiable : une matrice pièces-vers-cases doublement stochastique par normalisation de Sinkhorn plus des softmax de rotation par case, maximiser l'espérance de bords concordants par descente de gradient avec recuit de température, puis arrondir vers un plateau réel.* **Mesuré.** L'écart de relaxation est intrinsèque. Le score adouci grimpe à 367/480, mais le meilleur plateau arrondi marque 336 bords concordants (autres graines 324 et 325, meilleur de 4), et l'arrondi empire à mesure que la température s'affûte ; une variante à passage avant dur est pire encore, à 280. Le test le plus fort était aussi le plus petit : restreint aux deux ou trois dernières rangées d'un plateau à nous à 459 sur 480 (score strict, les cinq indices posés), le reste gelé, exactement là où la re-résolution exacte gagne fiablement un à trois bords, l'optimiseur n'a même pas pu reproduire la propre queue du plateau (41 contre 49 concordances de région pour le tenant, sur 8 redémarrages à deux rangées ; 63 contre 76 à trois rangées). Une seule campagne, mais l'écart sur la région la plus facile est de 15 à 20 % sous le tenant, très au-delà du bruit. Le mécanisme fait écho aux entrées faux-480 et réseaux de tenseurs de cette page : l'optimum continu est une superposition de nombreux plateaux mutuellement incompatibles, et la contrainte que la relaxation adoucit, chaque pièce utilisée exactement une fois, est précisément celle qui porte la dureté ; l'adoucir fabrique des concordances qu'aucune permutation réelle ne peut honorer. C'est un troisième mode d'échec dans la famille apprentissage ; voir [quand l'apprentissage s'effondre](/fr/research/build/learning/when-learning-collapses/). ## Énumérer d'abord les grappes locales *Lister toute grappe 3×3 ou 4×4 valide, puis coudre les grappes ensemble en un plateau complet.* **Mesuré.** Les dénombrements explosent avant d'être utiles. Lors de notre essai, les grappes valides autour d'une seule région se comptaient déjà en dizaines de millions, et combiner quatre coins atteint l'ordre de $10^{12}$ uplets à pièces disjointes. On épuise le temps et le disque bien avant que les contraintes n'élaguent quoi que ce soit. L'idée ne cesse d'être redécouverte. Fin 2024, les « macro-pièces » 2×2 sont revenues, avec quelque 4 millions de blocs avant même que la disjonction des pièces n'entre en jeu ([msg 11428](https://groups.io/g/eternity2/message/11428)), et des vétérans ont renvoyé aux années de travaux 2×2 antérieurs présents dans l'archive ([msg 11429](https://groups.io/g/eternity2/message/11429)). [Pourquoi c'est un mur →](/fr/research/why/rigidity-wall/) ## Construire le plateau une rangée parfaite à la fois *Construire rangée par rangée, en utilisant un couplage biparti exact pour choisir la meilleure rangée possible étant donné les couleurs de bords que la rangée précédente expose.* **Mesuré.** Chaque rangée est localement optimale ; le plateau meurt quand même. Dans notre essai, la construction a heurté un mur vers la rangée 10 sur 16, à 294/480 bords concordants, les rangées 11 et suivantes infaisables tout court : les premières rangées localement optimales consomment exactement les pièces dont les couleurs de bords sont requises plus bas, et à la rangée 10 le stock restant ne peut plus fournir les couleurs demandées du tout. Garder en parallèle les 32 meilleures suites de rangées n'aide pas ; tous les candidats de tête puisent dans les mêmes pièces rares et s'affament ensemble à la même rangée. (Preuve de concept en un seul essai ; le programme dynamique glouton est essentiellement déterministe. Des faisceaux bien plus larges, 256 ou 1 024, n'ont pas été essayés, même si l'argument du stock partagé prédit le même mur.) Le mécanisme en une ligne : l'optimalité locale ne se compose pas, parce que la ressource contraignante est le stock de pièces partagé et qu'un engagement rangée par rangée le dépense invisiblement. Ce qui marche à la place, c'est la prévoyance jointe entre rangées : la [recherche en faisceau](/fr/research/build/construct/beam-search/) plein plateau que nos constructeurs utilisent réellement. ## Construire par les deux bouts et se rejoindre au milieu *Faire croître le plateau du haut vers le bas et du bas vers le haut en même temps et joindre les moitiés à une rangée médiane : chaque moitié reçoit la part la plus facile, ancrée à la bordure.* **Mesuré.** La jonction le tue. Avec des faisceaux haut et bas indépendants de largeur 32, la seule disjonction des pièces a échoué sur plus de 99,9 % des appariements : 0 paire valide sur 1 024. Une seconde variante garantissait la disjonction en relançant un faisceau montant dédié par état du haut, environ 8 fois le calcul, et n'a toujours produit aucune fusion, parce que la rangée de rencontre exige une concordance exacte d'une séquence de couleurs à 16 positions sur un alphabet d'environ 22 couleurs, et qu'avec les pièces restantes contraintes l'ensemble concordant est effectivement vide. Deux obstructions s'empilent : des recherches indépendantes puisent dans le même stock de pièces prometteuses, et même des moitiés disjointes doivent s'accorder sur une rangée entière de couleurs d'interface qu'aucun côté n'a optimisée. Construire par les deux bouts ne supprime pas la difficulté d'interface ; il déplace le mur du milieu de plateau vers la rangée de rencontre. Portée : deux variantes à une seule largeur de faisceau ; les jonctions adoucies (tolérer quelques discordances d'interface puis réparer, ou se rejoindre en diagonale) n'ont jamais été lancées, le verdict couvre donc les versions à jonction exacte, pas la construction bidirectionnelle en général. Le cousin en méthodes exactes de cette idée a sa propre page : [meet in the middle](/fr/research/build/exact/meet-in-the-middle/). ## Découper et conquérir (cube and conquer) *Scinder l'instance SAT en des millions de sous-cas (cubes), résoudre chacun indépendamment, puis recombiner. La technique qui a réglé le nombre de Schur cinq et le problème des triplets pythagoriciens.* **Rapporté.** William Millilaw l'a testée exhaustivement en mai 2026 et elle ne vide pas le plateau. En 16×16, la phase de découpage ne partitionne l'instance en rien de traitable sans un lourd prétraitement, et l'étape de conquête (un solveur à anticipation sur chaque cube) était elle-même plus lente que de lancer kissat directement. Le résultat, net, était une frontière ferme : la méthode fonctionne jusqu'à environ 8×8 et s'arrête là. Elle rejoint la longue lignée des méthodes exactes qui butent sur le même mur que la programmation en nombres entiers et la décision SAT, sans prise pour le franchir. À la place : [quel mur arrête quelle méthode](/fr/research/why/walls-and-methods/) confronte chaque attaque exacte à la barrière sur laquelle elle meurt, pour comprendre pourquoi celle-ci allait toujours s'arrêter là. ## Générer des plateaux avec un transformeur *Entraîner un modèle de type GPT sur un corpus de plateaux, le conditionner sur un score cible, et lui faire produire de nouveaux plateaux à haut score que la recherche n'a jamais trouvés.* **Rapporté.** William Millilaw a parcouru tout l'arc en mai 2026, et chaque étape a échoué pour une raison propre. Un modèle de 51 millions de paramètres a appris la grammaire d'un plateau (chaque pièce utilisée une fois, 96 pour cent structurellement valides) mais non la physique : sans conditionnement, ses plateaux affichaient en moyenne autour de 250 bords concordants, proche du hasard. Le conditionnement sur un score cible a relevé la moyenne, mais chaque plateau qu'il produisait en haut de la fourchette était une copie exacte, jeton pour jeton, d'un plateau communautaire mémorisé, dont le 469 de McGavin. Avec seulement une vingtaine de plateaux d'élite distincts dans le jeu d'entraînement contre des dizaines de millions de paramètres, le modèle les avait tout bonnement mémorisés ; la condition de score devenait une consultation d'index. Une passe finale d'apprentissage par renforcement l'a aggravé, non amélioré, car la queue d'élite est échantillonnée bien trop rarement pour donner un gradient stable. La leçon rejoint le résultat du [transfert depuis de petits plateaux](/fr/research/why/rigidity-wall/) sur cette page : l'imitation apprend la distribution qu'on lui montre et ne peut inventer la structure rare qu'exige un record. ## La construction par colonie de fourmis (pistes de phéromones) *Une colonie d'agents construit chacun un plateau complet de façon gloutonne-aléatoire ; un champ de phéromones sur les décisions (case, pièce, rotation) est renforcé le long des chemins des meilleurs finisseurs (système de fourmis max-min standard : évaporation, dépôts d'élite, écrêtage), pour que les constructions futures se concentrent sur des régions globalement cohérentes.* **Mesuré**, trois échecs en profondeur. Le plafond autonome était de 296/480 bords concordants, le meilleur sur les configurations balayées (meilleure configuration à une graine, échelle de preuve de concept), sous même une base simple de recherche large. Allumer l'apprentissage par phéromones a dégradé la colonie : la moyenne de population est tombée d'environ 265 à environ 252 en 40 itérations tandis qu'un témoin à redémarrages aléatoires sans phéromones tenait environ 265 et atteignait 289 ; ce témoin était une confrontation directe. Et le champ appris ne porte aucune information sur ce que font réellement les bons plateaux : confronté à un plateau à nous à 455 (bords concordants, les cinq indices posés), le champ classait le choix du bon plateau en premier dans 1,2 % des cases contre un taux de hasard de 0,9 %, avec un percentile moyen de 0,502, statistiquement indiscernable d'un tirage à pile ou face ; il ne peut donc même pas servir de guide à une meilleure recherche. Le mécanisme est l'attribution du mérite : avec environ 600 candidats légaux par case et de bons scores finaux issus de vastes ensembles interchangeables de choix précoces, « cette décision était sur un bon chemin » est du bruit. La phéromone amplifie un gagnant de loterie précoce arbitraire et la colonie converge prématurément vers un bassin médiocre. ## La recherche arborescente Monte-Carlo à prior bon marché (la greffe TSP) *Un résultat de 2024 a montré que pour le voyageur de commerce, un MCTS fort à prior sans paramètre égale les cartes de chaleur neuronales apprises ([arXiv:2411.09238](https://arxiv.org/abs/2411.09238)). Porter fidèlement le moteur sous-jacent ([Fu, Qiu et Zha, AAAI-21](https://arxiv.org/abs/2012.10658)), en transposant son mouvement de tournée k-opt vers l'analogue exact en affectation, une relocalisation cyclique de k pièces toujours faisable.* **Mesuré**, deux négatifs nets. Comme raffineur : la phase d'échanges par paires est un moteur de réparation sain (des plateaux abîmés de 452 bords concordants jusqu'à 295 remontent exactement à 452) mais ne dépasse jamais son point de départ, et le mouvement vedette façon k-opt est complètement inerte ; sur chaque essai et toute la grille d'hyperparamètres (poids de mélange, longueur de cycle, simulations par coup), environ 2 500 à 3 150 cycles de relocalisation échantillonnés par essai ont produit zéro amélioration. Comme producteur à partir de rien : une variante constructive à bandits par case, après une optimisation du chemin chaud de 2,5 à 3,3× pour rendre la comparaison équitable, se comporte comme un faisceau de largeur 512 à 1 024, mesurablement sous un faisceau de largeur 2048 à temps mural égal (fraction de résolution moyenne 0,596 contre 0,743 sur notre échelle de casse-tête générés ; 0,644 contre 0,721 sur les barreaux durs, 24 essais), et l'écart ne se referme pas avec le budget. Le résultat zéro-cycle-améliorant est structurel et non un échec de réglage, même si seul le portage fidèle a été testé. Le mécanisme : le k-opt du TSP fonctionne parce que la chaîne de mouvements suit des arêtes de tournée existantes et reconnecte donc par construction une structure largement compatible ; un problème de placement par concordance de bords n'a pas de tournée à suivre, et déplacer une tuile entière perturbe les concordances des quatre côtés à la fois. La moitié transférable de l'article, qu'une recherche plus un prior bon marché peut remplacer un modèle appris, a tenu ; la recherche elle-même a la forme du TSP. Sur ce casse-tête, la [largeur de faisceau](/fr/research/build/construct/beam-search/) brute reste le meilleur usage du même temps mural. ## Recombiner deux bons plateaux *Prendre deux plateaux à haut score, garder les cases où ils s'accordent, et recourir au croisement par partition pour raccorder les régions en désaccord en un enfant au moins aussi bon que ses deux parents. L'opérateur génétique doté d'une garantie de tunnelisation sur les problèmes pseudo-booléens.* **Rapporté.** William Millilaw l'a implémenté et évalué sur des paires de plateaux scorant 455 et plus. Il dégénère. La contrainte de permutation (une pièce ne peut être réutilisée) force les régions en désaccord à fusionner en une seule composante dès qu'on les ferme sous l'unicité des pièces ; l'opérateur se réduit donc à « prendre le meilleur parent » sur plus de 99 pour cent des paires. Les rares raccords améliorants plafonnaient à 469, le score des parents, jamais au-dessus. C'est la même leçon que le [mur de rigidité](/fr/research/why/rigidity-wall/), vue du côté de la recombinaison : les bons plateaux logent tous dans un unique bassin étroit, si bien que les mélanger produit davantage du même plutôt que du neuf. La version greffe échoue de la même façon, par l'autre bout. Nous avons pris un partiel à nous à 442 bords concordants et un plateau fini à 459 (score strict, les cinq indices posés) et greffé les placements du donneur sur la plus grande région de désaccord, 71 cases : le score est tombé de 442 à 271. Greffer cumulativement les six plus grandes régions n'est jamais remonté au-dessus de 271 (241 à 271 sur les six variantes). La réparation locale sur ce casse-tête récupère typiquement cinq à dix bords ; la greffe creuse un trou d'environ 170. Un partiel et un donneur, un exemple travaillé décisif plutôt qu'une constante universelle, mais le mécanisme est générique : une région greffée gagne les concordances internes de son donneur et casse des bords tout le long de sa frontière avec les cases intactes, et la frontière d'une région est grande relativement à son intérieur, si bien que les dégâts de frontière dominent. Les réparer signifie rechoisir aussi les cases juste au-delà de la couture, et itérer cette exigence s'étend jusqu'à ce que « greffer une région » soit devenu « reconstruire la moitié du plateau ». Les bons plateaux ne se décomposent pas en parties échangeables. ## Élargir le vocabulaire des discordances *Tout solveur de la famille de backtrackers détentrice des records ne peut laisser qu'un bord discordant au plus par case ; par construction son index ne peut même pas représenter une case qui casse deux fois. Or les meilleurs plateaux communautaires issus de recherche locale contiennent bien quatre ou cinq de ces cases à double casse. Construire donc la même recherche sur l'espace élargi où une case peut porter deux casses, et chasser là où personne d'autre ne le peut.* **Mesuré.** À temps mural égal, le vocabulaire élargi ne rapporte rien. Un A/B apparié de 54 manches, 27 paires à graines appariées sur trois formes de calendrier et deux directions de balayage à 600 secondes × 4 fils par manche, a donné 20 égalités, 4 victoires pour le moteur élargi et 3 pour le classique, chaque différence dans ±3 bords concordants, avec des distributions min/médiane/max par forme identiques (415/420/425 dans les deux bras pour une forme). Le moteur élargi a visité 0,87 à 0,94 fois les nœuds pour les mêmes résultats. Un recensement exhaustif séparé derrière un préfixe de 208 cases d'un plateau communautaire à 464 (score à cinq indices ; contexte sur la [page des records](/fr/research/records/)) a trouvé exactement quatre complétions à sept discordances totales ou moins : le 464 lui-même et trois variantes à une case à 462 et 463, et aucune n'utilisait de case à double casse. Le mécanisme : l'espace élargi est explorable mais jamais forcé. Le budget de discordances étalé sur tout le plateau, la recherche n'a presque jamais deux unités de marge restantes sur une même case : elle dépense donc son budget comme le moteur classique ; et dans la région de fin de partie quasi parfaite, la strate à double casse est vide tout court. Les cases à double casse connues des plateaux communautaires siègent en milieu de plateau et furent créées par des mouvements de réparation en recherche locale, non par un parcours en profondeur. Portée : une égalité à temps mural égal pour une famille de moteurs sur le casse-tête officiel, pas une preuve que la strate élargie est vide partout ; l'hypothèse de départ, que le plateau communautaire plafonne sur un mur de représentabilité, est rétrogradée en conjecture non étayée, non réfutée. ## Décoder les discordances comme un mot de code corrompu *Voir un plateau parfait comme un mot de code, chaque bord interne un contrôle de parité, et un plateau à haut score comme ce mot de code plus un petit syndrome d'erreur ; si le motif d'erreur a une structure, un décodage par syndrome ou une propagation de croyances devrait le localiser et le nettoyer à bas coût.* **Mesuré**, sur un plateau à nous à 459 sur 480 (score strict, les cinq indices posés) ; cette entrée et la suivante sont deux lentilles qui traitent le motif des discordances comme un signal structuré, et toutes deux n'en ont trouvé aucun. Le syndrome est aussi peu structuré que possible : les 21 discordances impliquent environ 21 paires de couleurs distinctes (deux paires seulement se répètent), éclatées en 13 fragments déconnectés, et le compte total de demi-bords de chaque couleur est pair, le plancher de parité sur les discordances vaut donc zéro ; rien d'algébrique n'interdit un plateau parfait ni ne force ces erreurs. Décoder n'achète en conséquence rien. Re-résoudre exactement les cases du support d'erreur (34 cases éparpillées, démarrage à chaud) tient à 459 sur 8 graines et une résolution de 200 secondes, pas mieux que la re-résolution en bande rectangulaire simple contre laquelle elle courait ; élargir la région d'un pas la rend trop grande pour bien se re-résoudre (433) ; et sans démarrage à chaud la région éparpillée régresse à 448. Un seul plateau étudié, même si le mécanisme suggère un tableau générique : les raccourcis de décodage exigent une erreur structurée (collisions répétées, coset de basse dimension, une grappe réparable), et un syndrome maximalement étalé dont les fragments ne se couplent que par l'inventaire des pièces est exactement le régime où le décodage dégénère en la même recherche exhaustive de queue que nous menons déjà. Les discordances sont un budget alloué globalement, pas une erreur locale à inverser. ## Traiter les discordances comme des défauts physiques *Modéliser chaque discordance comme un défaut topologique chargé dans le champ de couleurs : les défauts devraient siéger aux sites forcés par conservation, à interaction minimale, et les charges opposées devraient s'annihiler.* **Mesuré**, même plateau que l'entrée précédente, et chaque prémisse échoue. La position prédit extrêmement bien l'emplacement des discordances : l'indice de rangée seul sépare bords cassés et intacts avec une AUC de 0,895, et les 21 discordances siègent toutes dans les dernières rangées remplies. Tout signal de couleur est du bruit : AUC de rareté de couleur de 0,46 à 0,50, et les discordances portent des couleurs communes, non rares. Le plancher de conservation des couleurs sur la queue est proche de zéro ; le haut gelé ne pousse vers le bas aucune demande de couleur que les pièces restantes ne puissent servir, et même la borne de couplage la plus fine, consciente des orientations, ne force que 0 à 2 discordances là où il en existe 10 à 19. Le spectre de charges n'a essentiellement aucune paire de signes opposés : il n'y a rien à annihiler. Un objectif de répulsion de défauts ajouté à la re-résolution exacte de la queue change quelle solution départagée sort, mais pas le plafond ; la dernière rangée est prouvablement optimale étant données les rangées au-dessus. (Un balayage de résolution de région à froid a été arrêté après une seule graine, à 441, une fois le verdict clair ; tenez ce nombre pour une illustration à graine unique.) Le constat à garder : les discordances ne sont pas du tout des défauts dans un champ de couleurs. Ce sont de pures frustrations d'orientation combinatoires, issues de l'épuisement des pièces dans la région remplie en dernier ; la comptabilité des couleurs s'équilibre, et ce qui casse est la contrainte jointe à quatre côtés sur toutes les pièces restantes à la fois. Aucune réduction par coupe unique, par couleur ou par énergie de paires ne la capture. La géométrie des casses a sa propre page : [géométrie des discordances](/fr/research/why/mismatch-geometry/). ## Forcer une bordure diversifiée, puis remplir *La bordure est un sous-casse-tête plus petit. Résoudre d'abord pour de nombreux cadres valides différents, sur la théorie que la variété du cadre ensemence la variété du plateau entier.* **Rapporté.** William Millilaw l'a essayé et a trouvé la prémisse inversée. La bordure est la partie facile : à partir de rien, elle est déjà variée et rapide à poser. La ressource rare, c'est le remplissage intérieur, là où les pièces se raréfient et où les discordances se concentrent. Forcer la diversité du cadre dépense de l'effort là où il n'y a pas de pénurie et n'achète rien là où il y en a une. C'est un thème récurrent des expériences propres à ce projet aussi : le cadre vaut étonnamment peu ([STAGED](/fr/research/lab/experiments/raphael-anjou/pipelines/staged/) mesure au juste combien peu), et les dégâts de fin de partie tombent dans les coins intérieurs ([MOSAIC](/fr/research/lab/experiments/raphael-anjou/pipelines/mosaic/)). Nous avons mesuré la prémisse nous-mêmes, par deux directions. D'abord, le catalogue de bordures : une recherche bornée en temps (120 secondes, explicitement non exhaustive ; le vrai compte est inconnu) a produit 75 173 anneaux de bordure complets et intérieurement valides. En donnant au solveur un échantillon de 500 cadres épinglés, 47 % ont épuisé la recherche en moins de 200 millisecondes sous propagation de base, et pratiquement tous furent rejetés d'emblée dès que la propagation complète a couru contre les pièces indices officielles. Un anneau qui se referme sur lui-même ne satisfait que la concordance par paires autour du pourtour ; la faisabilité jointe avec les indices et la contrainte intérieure d'utiliser chaque pièce une fois est une condition bien plus forte, et pratiquement aucun des anneaux catalogués ne la remplit. Ensuite, les bordures parfaites comme graines. Nous avons généré 5 000 bordures parfaites distinctes à pièces uniques par programmation dynamique (les 60 cases de bordure posées, chaque bord de bordure concordant), échantillonné 100 uniformément, et donné à chacune le même pipeline : un remplissage intérieur de 60 secondes par propagation de contraintes, puis un polissage de 60 secondes par recherche locale. Meilleur score de tout le lot : 436/480 bords concordants ; environ la moitié des départs entre 420 et 427, un quart entre 380 et 419, et aucun au-dessus de 437. Les plateaux de la classe 455 à 460 de la même époque (score strict, les cinq indices posés) venaient tous d'un producteur en profondeur d'abord qui ne fixe pas la bordure en premier. Le polissage utilisait une seule graine et 60 secondes par départ : c'est donc un filtre bon marché, pas une réfutation exhaustive ; sous un polissage court à budget égal, aucun des 100 départs bordure-d'abord n'est arrivé à moins de 20 bords de ce que la recherche directe atteint. Une bordure parfaite sur-engage l'intérieur ; le remplissage optimise ensuite dans le profil de couleurs intérieur que la bordure autorise, et cette famille plafonne loin sous les meilleurs bassins. ## Construire un faux 480, puis le réparer *Partir d'un plateau où chaque bord concorde en autorisant les pièces en double, puis y échanger gloutonnement les vraies pièces une à une, dans l'espoir de maintenir le score à 480.* **Rapporté.** William Millilaw l'a exécuté et cela vire au jeu de la taupe : chaque vraie pièce que l'on force à entrer casse des bords ailleurs, et la réparation ne converge jamais, plafonnant autour de 463. La raison est la leçon qui sous-tend toute cette page. L'obstacle au 480 n'est pas que les bords soient durs à faire concorder ; un faux plateau à pièces répétées les fait toutes concorder sans peine. L'obstacle est la contrainte globale que chacune des 256 pièces soit utilisée exactement une fois, et c'est précisément ce que la construction du faux 480 jette. Le mur est informationnel, non affaire de réparation locale de bords. À la place : le [mur de rigidité](/fr/research/why/rigidity-wall/) explique pourquoi la réparation locale ne peut franchir ce dernier écart, quel que soit le plateau de départ. ## Amorcer la réparation avec le préfixe profond d'un solveur exact *Utiliser un backtracker exact à propagation de contraintes pour bâtir un préfixe cohérent très profond, l'épingler, et le donner à la recherche de réparation locale comme longueur d'avance.* **Mesuré**, une seule configuration ; à cadrer en conséquence. L'astuce d'épinglage approfondit réellement la recherche exacte elle-même ; entre les manches elle a porté le solveur de la profondeur 27 à la profondeur 152, du score 23 à 297 bords concordants, un vrai amplificateur de profondeur, et cette moitié positive reste utile quand on chasse des solutions exactes plutôt que des hauts scores (voir les [pages sur le backtracking](/fr/research/build/backtracking/)). Mais comme chercheur de score, cela se retourne : la réparation depuis le partiel épinglé à 297/480 (184 cases fixées) a fini à 424/480 bords concordants, contre une médiane de 430 à 450 (meilleur 451) pour la réparation à froid simple dans le lot de comparaison à 16 graines de la même époque. Ce bras amorcé était une seule graine, un calendrier et un préréglage de réparation : lisez-le comme « cette configuration a sous-performé chaque départ à froid du lot de comparaison », non comme une réfutation de tout amorçage par préfixe exact. Le mécanisme est la même leçon partir-du-mauvais-objet que l'entrée faux-480 ci-dessus : un solveur exact en mode première-solution optimise la cohérence, pas le score. Il renvoie le premier préfixe profond faisable qu'il trouve, pas un bon ; « profond et cohérent » n'est pas « proche du bon », et l'épinglage rend l'erreur permanente, puisque la recherche de réparation ne peut défaire les cases héritées et n'aurait jamais bâti ce squelette elle-même. ## Partir du centre et croître vers l'extérieur *Le centre a le plus de liberté de rotation : partir de là et laisser les contraintes s'accumuler en croissant vers la bordure.* **Mesuré**, et l'intuition est à l'envers. En confrontation directe sur des casse-tête générés de 5×5 à 8×8 contre les ordres rangée-par-rangée et bordure-d'abord, le centre-vers-l'extérieur a perdu chacune des six configurations : typiquement 10 à 100 fois plus lent, il a échoué tout court sur quatre des six dans des budgets où bordure-d'abord finissait (un 5×5 bloqué à la profondeur 22 sur 25 après 2 millions de nœuds sur un casse-tête que bordure-d'abord résolvait en 2 000 nœuds), et il était environ 60 fois plus lent sur l'un de ceux qu'il a résolus ; le cas 8×8 était le pire des trois ordres testés. Mesuré sur de petits casse-tête générés avec les ordres de balayage d'un seul solveur, mais la direction et l'ampleur furent uniformes sur les six cas. Le mécanisme : la liberté est l'ennemie de la propagation. La bordure fournit des contraintes dures et immédiates (les bords gris) ; le centre n'en fournit aucune, si bien qu'une recherche centre-vers-l'extérieur s'engage sur des couleurs arbitraires sans moyen de détecter tôt l'infaisabilité. Plus de liberté signifie moins d'élagage, pas une recherche plus rapide. À la place : la page [ordre de remplissage](/fr/research/build/backtracking/fill-order/) couvre les ordres qui aident vraiment. ## Encoder les stratégies humaines *Cadre d'abord, croissance de région compacte autour des indices, case la plus contrainte en premier, backtracking discipliné, et pilotage délibéré « dépense tes discordances avec sagesse » : coder la façon dont pensent les meilleurs solveurs humains.* **Mesuré**, et rien n'y survit. Un cadre parfait se trouve en quelques millisecondes et n'achète aucune traction (aucun des cinq indices ne touche la bordure). Le vrai tueur est l'épuisement des pièces, et il est invariant à l'ordre : le long d'une construction, le nombre moyen de pièces inutilisées qui conviennent parfaitement à une case s'effondre de 3,5 dans les premières rangées à 2,6, 2,0, 1,6 et 1,4 puis 0,4 à la rangée finale ; une discordance est donc presque toujours forcée à la fin, où que soit la fin. Trois ordres de remplissage humains ont couru à 6 graines chacun (bords concordants) : rangée-par-rangée 392, spirale depuis le centre 382, croissance ancrée aux indices 359. Chaque ordre déverse ses discordances sur ce qu'il remplit en dernier (la spirale sur l'anneau extérieur ; l'ancrage aux indices les étale partout, et marque le pire), et un départage « préserver les couleurs communes pour plus tard » a dégradé chaque ordre. Une trajectoire guidée unique plafonne vers 392, environ 67 bords sous ce qu'un faisceau large atteint sur le même matériel. Le mécanisme : le déficit qui produit les discordances est un fait d'inventaire global et conservé ; l'ordre choisit quelles cases en héritent, jamais s'il existe. Et la seule faculté humaine qui aiderait vraiment, suivre des milliers d'hypothèses en parallèle avec une anticipation globale, est exactement ce qu'est déjà la [recherche en faisceau](/fr/research/build/construct/beam-search/). Voir aussi [pourquoi il n'y a pas de coups forcés](/fr/research/why/no-forced-moves/). ## Précalculer des macro-tuiles 2×2 (ou plus grandes) *Résoudre chaque bloc 2×2 une fois, stocker les blocs valides, et placer quatre cases à la fois pour raccourcir la recherche.* **Mesuré.** Markus Zajc l'a décortiqué en 2008 : construire les macro-tuiles ne fait que déplacer le travail, il ne le supprime pas. On échange un petit ensemble de pièces isolées contre un très grand ensemble de blocs 2×2 : placer un bloc est donc plus rapide, mais le nombre de plateaux partiels distincts est inchangé, toujours de l'ordre de $10^{40}$ là où il faudrait $10^{4}$. Une accélération de 10× ou 100× sur un arbre hors d'atteinte reste hors d'atteinte ([msg 5883](https://groups.io/g/eternity2/message/5883)). Les macro-tuiles sont un gain réel à facteur constant pour un solveur rapide, ce pourquoi le [bac à sable de l'ordre des blocs](/playground/paths/) les prend en charge ; elles ne sont simplement pas une réduction de domaine, et seule une réduction de domaine ferait bouger les lignes. Le plafond auquel cela se mesure est le record en vigueur de 470/480 : Blackwood a rapporté que les caches de 2×2 pré-résolus ne l'ont pas aidé à le dépasser ([Records et solveurs](/fr/research/records/)). À la place : l'unique levier gratuit qui réduit vraiment l'arbre est l'[ordre de remplissage](/fr/research/build/backtracking/fill-order/). ## Piloter le backtracker en anneaux concentriques *Piloter le backtracker à calendrier de la famille détentrice des records vers l'intérieur en anneaux concentriques, sur la théorie qu'une géométrie en couches épouse là où les casses veulent se loger.* **Mesuré.** Il heurte un mur de profondeur structurel que plus de temps ne déplace pas. Un essai d'une heure sur le casse-tête officiel a visité 3,4 milliards de nœuds avec le placement le plus profond coincé sur un mur à la profondeur 80 : le mur était à 80 après cinq minutes et a gagné une case sur le reste de l'heure. Un essai de deux heures a fini au même 382/480 bords concordants que l'essai de cinq minutes. Un calendrier apparié à un ordre, un essai par budget : le verdict est que cet appariement échoue, non que les ordres en couches soient réfutés en général. Le mécanisme : le plan de relâchement du solveur à calendrier, là où il a le droit de dépenser ses discordances, est réglé pour un balayage rangée par rangée ; une géométrie en anneaux imposée de l'extérieur combat le calendrier au lieu de l'aider, et la recherche se coince à une profondeur fixe quel que soit le budget. L'[ordre de remplissage](/fr/research/build/backtracking/fill-order/) compte, mais il doit être co-conçu avec le calendrier de discordances, pas boulonné dessus. ## Partager une table de transposition entre travailleurs parallèles *Les moteurs d'échecs partagent une table de transposition entre fils ; faire pareil ici, en hachant chaque frontière explorée pour qu'aucun travailleur ne ré-explore un sous-arbre qu'un autre a déjà épuisé.* **Mesuré**, et la construction fut annulée sur la foi de la mesure, la façon bon marché de tuer une idée. Huit travailleurs ont couru 15 secondes chacun sur le casse-tête officiel avec un solveur identique, seul l'ordre des candidats étant mélangé par travailleur : chaque travailleur posait environ 214 cases sur son plateau le plus profond (profondeurs maximales de 192 à 235 sur les huit), mais l'accord par paires entre les plateaux les plus profonds de deux travailleurs quelconques était en moyenne de 1,8 case (maximum 5), une fraction d'accord de 0,8 %. Une seule mesure à huit travailleurs, mais face aux 50 % et plus qu'une table partagée exigerait pour payer, la taille d'effet ne laisse aucune ambiguïté. Le mécanisme : la recherche est extrêmement dépendante du chemin ; la première pièce essayée à la profondeur k remodèle ce qui est disponible à la profondeur k+1, en se composant tout le long de la trajectoire, si bien que des travailleurs ordonnés différemment ne reconvergent jamais vers le même plateau partiel. Une table de déduplication ne paie que si les chemins reconvergent comme les ouvertures d'échecs s'entonnent vers des milieux de partie partagés, et cette recherche n'a pas d'entonnoir pareil. Le revers est une bonne nouvelle : les travailleurs parallèles couvrent réellement des territoires différents, ce pourquoi le parallélisme simple non coordonné passe à l'échelle (huit fils ont atteint la profondeur 235 et 427 bords concordants en 30 secondes là où un fil atteignait 192 et 344) ; la [résolution distribuée](/fr/research/build/faster/distributed-solving/) bâtit exactement là-dessus. ## L'élagage par offre de bordure (le test « lollypop ») *Avant de récurser, compter la demande restante en couleurs de bordure contre les pièces encore disponibles ; si l'offre ne peut satisfaire la demande, couper la branche tôt.* **Mesuré.** Markus Zajc a implémenté ce test offre-contre-demande en complément de son solveur de contraintes et l'a évalué sur le 8×8 : il coupait environ 0,0014 % des tests tout en ajoutant 8 % au temps d'exécution, une perte nette claire. La raison est instructive : sur presque toute branche où le test d'offre de bordure aurait échoué, la propagation de contraintes ordinaire a *déjà* échoué une étape ou deux plus tôt ; la comptabilité supplémentaire paie donc pour une coupe que le solveur était sur le point de faire gratuitement ([msg 6060](https://groups.io/g/eternity2/message/6060)). Une règle d'élagage n'aide que si elle se déclenche avant les vérifications déjà en place, pas après. À la place : l'idée offre-contre-demande paie lorsqu'elle est fondue dans la propagation qui se déclenche en premier, le [filtre de couplage tous-différents](/fr/research/build/reduce/alldiff-regin/). Dix-sept ans plus tard, nous avons rejoué la même idée dans notre propre moteur, sur toutes les couleurs au lieu de la seule bordure : suivre combien de bords de pièces de chaque couleur restent non posés, et couper la branche quand une case de la frontière demande une couleur dont l'offre est épuisée. Casse-tête officiel, un seul fil, un essai de 10 secondes : la base a visité 630 millions de nœuds à 63 millions de nœuds par seconde ; avec le test, 388 millions à 39 millions, environ 40 % de débit en moins pour la même profondeur maximale (192) et le même meilleur score (344 bords concordants). Zéro élagage supplémentaire, et la raison est désormais précise : un index de candidats indexé par (couleur du haut, couleur de gauche) *est* déjà ce propagateur. Si poser une pièce épuisait une couleur qu'une case à venir demande, le panier de candidats de cette case est simplement vide un pas plus tard et la recherche rebrousse de toute façon ; le test explicite paie à chaque nœud pour une coupe que l'index fait gratuitement. Une variante dynamique à budgets par couleur ne fait pas mieux sur un backtracker strict : pour chaque couleur, suivre combien de ses demi-bords sont déjà définitivement discordants, et élaguer tout plateau partiel qui ne peut plus atteindre le score cible pour cette couleur. Sur 15 instantanés profonds d'états de recherche réels (profondeurs 195 à 212 sur 256 cases), elle s'est déclenchée zéro fois : un solveur qui ne pose jamais de pièce discordante ne crée que des partiels qui ne peuvent pas encore violer le budget, et au moment où le budget mordrait, la propagation ordinaire a déjà coupé la branche. (Sur une recherche tolérante aux discordances, le test reste non testé ici.) Une non-leçon voisine : trier tous les candidats globalement par un poids de rareté de couleur, le même ordre à chaque case, n'est pas une heuristique informée du tout ; c'est l'équivalent d'un réétiquetage fixe des pièces et cela n'ajoute aucune information. ## Le test de fermeture eulérienne de la bordure *Un anneau de bordure valide doit tracer un cycle eulérien dans le graphe dont les sommets sont les couleurs de bord de bordure et les arêtes les pièces de bordure : une condition nécessaire propre, proposée sur la liste de diffusion dès 2007. La vérifier pendant la recherche et élaguer les bordures qui ne peuvent plus se refermer.* **Mesuré**, zéro pouvoir d'élagage sur le casse-tête officiel. Testée à cinq profondeurs de recherche avec 200 000 tirages chacune, un million de bordures partielles en tout : la condition eulérienne ne s'est jamais déclenchée sur une configuration que la propagation ordinaire n'avait pas déjà tuée. La condition est nécessaire mais vide sur le jeu de pièces réel, et la raison est un fait de conception : le jeu officiel fut généré avec ses couleurs rares placées uniquement sur l'anneau de bordure, deux par pièce de bordure, et cette structure rend la fermeture eulérienne automatique pour toute bordure partielle qui s'approche un tant soit peu d'un anneau complet. Les configurations que le test rejetterait meurent bien plus tôt sous une propagation standard de type cohérence d'arc. Même leçon de famille que le test lollypop ci-dessus : un élagage n'aide que s'il se déclenche avant les vérifications déjà en place. ## L'élagage par motifs interdits pendant la recherche *Nous avons prouvé qu'un ensemble de combinaisons de pièces 2×2 ne peut apparaître dans aucun plateau entièrement concordant. L'étape suivante évidente : vérifier chaque zone 2×2 complétée pendant la recherche en profondeur et élaguer quand elle est interdite.* **Prouvé** vide par construction, puis vérifié empiriquement : sur 24 plateaux et 225 zones chacun, 5 400 zones complétées, zéro était interdite, exactement comme l'argument le prédit. Le test des motifs interdits demande si quatre pièces peuvent concorder intérieurement sous une rotation quelconque ; or une recherche strictement concordante ne complète jamais un 2×2 qu'après avoir déjà fait concorder ses quatre bords internes, si bien que chaque zone qu'elle complète est faisable par construction et que le test ne peut jamais se déclencher. Le pouvoir discriminant du théorème porte sur des sous-ensembles de pièces, ce qui exigerait une intégration en vérification avant, testant les zones avant que leurs cases soient remplies, et dans un balayage rangée par rangée la version bon marché de cette vérification est déjà faite implicitement par l'index de candidats. Le théorème lui-même reste vrai et utile ailleurs : voir les [motifs interdits](/fr/research/why/forbidden-patterns/). Même morale finale que l'entrée lollypop : un élagage qui se déclenche après vos vérifications existantes vaut exactement zéro. ## Ce que toute impasse a en commun L'écart entre le meilleur plateau connu et une solution complète ne ressemble pas à une optimisation manquante. Les bons plateaux sont localement figés et globalement contraints de façons que les correctifs locaux, un matériel plus rapide et les relaxations standard n'atteignent pas. Atteindre la fin semble exiger une idée d'une autre nature, non davantage de la même. Une convergence tardive mérite d'être consignée. Quatre lentilles essayées indépendamment la même saison, le décodage de mot de code, la physique des défauts, la descente de gradient sur plateau adouci et la stratégie humaine encodée, ont chacune redécouvert le même fait par une direction différente : l'obstacle est la distinction globale des pièces et l'épuisement de l'inventaire, non la concordance locale des bords. Quand quatre formalismes sans lien heurtent le même mur, c'est probablement le mur qu'il faut étudier. Voir [pourquoi un ordinateur plus rapide n'aide pas](/fr/research/why/prune-vs-speed/). ## À lire aussi - [L'exécuter soi-même](https://eternity2.dev/fr/research/build/run-it-yourself/) — L'ensemble du site, le moteur et chaque résultat de cette section tournent depuis un seul dépôt. Voici comment le lancer, recompiler le moteur WebAssembly et reproduire les chiffres. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Problèmes ouverts](https://eternity2.dev/fr/research/open-problems/) — La frontière ouverte d'Eternity II réunie au même endroit : chaque angle qui vaut encore une tentative, le mur qu'il attaque, ce qui a déjà été essayé et où cela s'est arrêté, et s'il s'agit d'une cible abordable pour un débutant ou d'un objectif difficile et bien cartographié. --- # Méthodes exactes > Des solveurs capables de prouver : encodages SAT et CSP, programmation en nombres entiers et ses relaxations, couverture exacte, rencontre au milieu et cartes de projection itérées. Les méthodes complètes s'enlisent sur le plateau entier, mais leurs verdicts valent leur pesant d'or comme preuves d'impossibilité sur des sous-plateaux. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/exact/ - Mise à jour: 2026-07-13 --- Des solveurs capables de prouver : encodages SAT et CSP, programmation en nombres entiers et ses relaxations, couverture exacte, rencontre au milieu et cartes de projection itérées. Les méthodes complètes s'enlisent sur le plateau entier, mais leurs verdicts valent leur pesant d'or comme preuves d'impossibilité sur des sous-plateaux. Les pages ci-dessous procèdent technique par technique : ce que chacune est en une ligne, ce qu'elle a réellement atteint sur le vrai plateau 16×16, où elle s'arrête, et les manips et mesures qui l'étayent. Pour embrasser tout le territoire d'un coup, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). ## Pages de cette section - [Couverture exacte et liens dansants](https://eternity2.dev/fr/research/build/exact/exact-cover-dlx/) — Eternity II se formule proprement comme un problème de couverture exacte, et l'algorithme X de Knuth muni des liens dansants en est la machine classique. Là où il brille vraiment (petits plateaux, dénombrement exhaustif) et les deux raisons pour lesquelles il ne vient pas à bout du 16×16 : un arbre de recherche jamais réduit, et aucun crédit partiel. - [Rendez-vous au milieu](https://eternity2.dev/fr/research/build/exact/meet-in-the-middle/) — Énumérer deux moitiés d'un problème et les recoller sur une interface partagée, en échangeant de la mémoire contre un exposant divisé par deux. L'astuce classique de Horowitz–Sahni, ce qu'elle donne sur des bandes du plateau, et ce que l'expérience BANDSAW de ce projet a mesuré, y compris la méthode unilatérale qui l'a battue. - [La traîne comme problème exact à part entière](https://eternity2.dev/fr/research/build/exact/exact-tail-endgame/) — Un plateau partiel solide, c'est une région haute que le producteur a travaillée plus une bande basse de rangées inachevées. On gèle le haut, on confie la traîne à un solveur de contraintes exact, et on lit quelle moitié fixe le plafond : la structure du producteur ou la fin de partie bâclée. - [Encodages SAT et CSP](https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/) — Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. - [Relaxations LP et PLNE : une demi-pièce partout](https://eternity2.dev/fr/research/build/exact/lp-relaxations/) — Écrivez Eternity II comme un programme en nombres entiers, abandonnez l'intégralité, et un solveur linéaire atteint une erreur nulle en quelques secondes, 30 % d'une pièce et 20 % d'une autre partageant un même coin. Dix-huit ans de campagnes communautaires ont mesuré où s'arrête le confort fractionnaire : un plateau à 420–440 arêtes dès que les pièces doivent être entières, un mur PLNE dès le 8×8, et un record académique de 461 en une heure. Ce qu'enseigne la route de l'optimiseur, et là où le LP reste utile. - [Applications itérées et divide-and-concur](https://eternity2.dev/fr/research/build/exact/iterated-maps/) — L'attaque des physiciens sur la satisfaction de contraintes : scinder le puzzle en deux ensembles de contraintes chacun facile à projeter, puis itérer une application dont les points fixes sont les solutions. La méthode de Veit Elser a fait la couverture de PNAS, et pourtant sur la liste Eternity II elle reste une voie admirée, testée une fois, jamais empruntée jusqu'au bout. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. --- # Couverture exacte et liens dansants > Eternity II se formule proprement comme un problème de couverture exacte, et l'algorithme X de Knuth muni des liens dansants en est la machine classique. Là où il brille vraiment (petits plateaux, dénombrement exhaustif) et les deux raisons pour lesquelles il ne vient pas à bout du 16×16 : un arbre de recherche jamais réduit, et aucun crédit partiel. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/exact/exact-cover-dlx/ - Mise à jour: 2026-07-02 - Sujets: exact-methods - Source: Knuth 2000, « Dancing Links » (arXiv cs/0011047) — https://arxiv.org/abs/cs/0011047 - Source: L'algorithme X de Knuth (Wikipédia) — https://en.wikipedia.org/wiki/Knuth%27s_Algorithm_X - Source: Couverture exacte (Wikipédia) — https://en.wikipedia.org/wiki/Exact_cover --- Certains casse-têtes doivent être tordus pour entrer dans un formalisme ; Eternity II tombe dans la couverture exacte presque de lui-même. Un problème de couverture exacte pose la question suivante : étant donné un ensemble d'éléments et une collection d'options, chaque option couvrant certains éléments, sélectionner des options de sorte que chaque élément soit couvert *exactement une fois*. Les pavages par pentaminos, le sudoku et le problème des n reines en sont les clients classiques, et l'appariement de bords est le voisin d'à côté. ## Le plateau comme couverture exacte Prenons 512 éléments : un par case (« la case $c$ est remplie ») et un par pièce (« la pièce $p$ est utilisée »). Chaque option est un placement concret, la pièce $p$ sur la case $c$ dans la rotation $r$, couvrant exactement deux éléments, sa case et sa pièce. Une sélection d'options couvrant chaque élément exactement une fois est précisément un plateau dont chaque case est remplie et chaque pièce utilisée une fois. Ce que la couverture exacte pure ne sait pas exprimer, c'est que les bords en contact doivent concorder. L'extension propre à Knuth s'en charge : XCC, la couverture exacte avec couleurs, où des éléments secondaires (ici, un par arête intérieure de la grille) portent une couleur, et où deux options ne peuvent partager un élément secondaire que si elles lui affectent la même couleur. Une solution XCC complète est alors exactement un plateau Eternity II parfait. L'encodage est fidèle : rien du casse-tête n'est approximé au passage. ## L'algorithme X, et pourquoi les liens dansent L'algorithme X de Knuth résout la couverture exacte par essais et erreurs disciplinés : choisir l'élément ayant le moins d'options restantes (la règle « échouer en premier »), essayer chaque option qui le couvre, retirer tout ce que cette option rend impossible, et récurser ; en cas d'échec, restaurer et essayer la suivante. Les liens dansants (DLX) sont la structure de données qui rend l'étape de restauration élégante. La matrice des options réside dans des listes doublement chaînées circulaires, et retirer un élément se réduit à deux écritures de pointeurs, `left.right = right; right.left = left`, ce qui laisse intacts les propres pointeurs du nœud retiré. Annuler le retrait, ce sont les deux mêmes écritures à l'envers. Le retour en arrière devient une chirurgie de pointeurs sans aucune copie, et la mémoire touchée est exactement proportionnelle au travail effectué. C'est l'un des algorithmes les plus élégants de la boîte à outils combinatoire, et l'article de Knuth est un véritable plaisir de lecture. ## Regardez les liens danser Voici la recherche complète sur l'instance précise dont Knuth se sert dans son article : sept éléments A–G, six options R1–R6, exactement une solution. Parcourez-la pas à pas et observez les trois mouvements qui composent tout l'algorithme : choisir la colonne la plus vide, la couvrir (colonnes et lignes se détachent du treillis), et, en cas d'échec, découvrir en sens inverse (les mêmes liens se ressoudent). L'impasse à la colonne E est le moment qui mérite qu'on ralentisse : tout ce que la mauvaise décision avait retiré revient dans l'ordre exactement inverse, pour deux écritures de pointeurs par lien. > **[Figure]** Interactif : couvrir et découvrir avec les liens dansants — interactive: DancingLinksLab. Rendered on the canonical page (link above); not shown in this markdown export. Notez ce qui n'arrive jamais : aucune copie, aucune reconstruction, aucun balayage pour retrouver ce qu'il faut restaurer. Les nœuds retirés conservent leurs propres pointeurs pendant qu'ils sont détachés, et c'est là toute l'astuce : annuler une couverture coûte aussi peu que de la faire. ## Pas à pas Le même déroulement, en mots. La matrice est R1 \{C,E,F\}, R2 \{A,D,G\}, R3 \{B,C,F\}, R4 \{A,D\}, R5 \{B,G\}, R6 \{D,E,G\} : 1. **Choisir la colonne A.** Deux options vivantes, à égalité pour le minimum ; « échouer en premier » dit de brancher sur l'élément le plus contraint. Essayer sa première option, R2 \{A,D,G\} : couvrir les colonnes A, D et G. Toute ligne qui les touche (R2, R4, R5, R6) se détache. 2. **Récurser.** Seules R1 et R3 survivent. La colonne B n'a plus qu'une seule option vivante, donc la choisir, essayer R3 \{B,C,F\} : couvrir B, C, F, ce qui détache R1. 3. **Impasse.** La colonne E reste non couverte et aucune option vivante ne la couvre. Cette branche ne peut jamais aboutir, donc aucune recherche plus profonde n'est même tentée. 4. **La danse.** Découvrir F, C, B, puis G, D, A, dans l'ordre exactement inverse, chaque restauration étant l'image miroir du retrait. La matrice est revenue bit pour bit à son état initial, sans avoir été sauvegardée où que ce soit. 5. **Essayer l'autre option de A, R4 \{A,D\}.** Couvrir A, D. La colonne E n'a maintenant qu'une seule option vivante, R1 \{C,E,F\} : couvrir C, E, F. La colonne B n'a plus qu'une option, R5 \{B,G\} : couvrir B, G. 6. **Plus aucune colonne ne subsiste**, chaque élément couvert exactement une fois. Solution : R1 + R4 + R5, trouvée à la profondeur 3 avec une seule impasse. La recherche se déroule ensuite entièrement à rebours, vérifie qu'aucune autre branche n'existe, et signale exactement une solution - et cette certitude d'exhaustivité est tout le produit. ## Ce qu'il en coûte Le bilan comporte deux lignes très différentes : - **Le problème est NP-complet.** La couverture exacte figure sur la liste originelle de Karp de 1972, donc aucun algorithme polynomial n'est connu pour elle, et l'algorithme X est exponentiel dans le pire cas : c'est une recherche par retour en arrière complète, et son arbre peut croître comme le produit du branchement à chaque niveau. - **C'est la structure de données qui est bon marché.** DLX rend chaque retrait de lien et chaque restauration $O(1)$ : deux écritures de pointeurs, avec une annulation exacte, de sorte que le temps total est $O(1)$ par lien touché, proportionnel à l'arbre que la recherche explore réellement. Les liens dansants achètent un superbe facteur constant et un coût de restauration nul ; ils ne réduisent pas l'arbre d'un seul nœud. À l'échelle d'Eternity II : la matrice XCC elle-même est parfaitement maîtrisable, avec 512 éléments primaires (256 cases + 256 pièces), 480 éléments secondaires pour les arêtes intérieures et leurs 22 couleurs, et au plus $256 \times 256 \times 4 = 262{,}144$ options avant élagage par symétrie et par bordure. La construire, c'est quelques minutes de travail. C'est l'arbre au-dessus qui est le mur : sans [aucun coup forcé](/fr/research/why/no-forced-moves/), le branchement reste large jusqu'en bas, sur un espace généralement estimé aux alentours de $10^{100}$, et $O(1)$ par nœud multiplié par un nombre astronomique de nœuds reste astronomique. C'est le sens précis dans lequel DLX est le bon outil pour les petits plateaux et la mauvaise arme pour le 16×16. ## Là où il brille DLX est le bon outil quand on veut *toutes* les solutions, ou un dénombrement, ou une preuve d'unicité, sur des instances assez petites pour être épuisées. Sur les petits plateaux d'appariement de bords, il fait exactement cela : énumération complète avec d'excellents facteurs constants, aucune solution manquée, aucun état répété. Dénombrer les pavages complets de régions de la taille d'un indice, vérifier qu'un mini-casse-tête généré possède une solution unique, recouper les dénombrements exhaustifs d'un autre solveur : voilà son terrain de prédilection, et là aucune méthode heuristique ne rivalise. Une note de projet venue du terrain, offerte comme mise en garde plutôt que comme résultat : une implémentation XCC repartie de zéro s'est ici validée sans accroc sur les n reines et sur des plateaux triviaux, puis est restée cassée des jours durant sur tout ce qui était plus grand, car l'interaction entre la purification pilotée par les couleurs et la restauration couvrir/découvrir est réellement subtile. Si vous la construisez, suivez à la lettre l'algorithme publié par Knuth ; les jours perdus ci-dessus, c'est ce projet qui les a perdus. ## Pourquoi il ne vient pas à bout du 16×16 Deux murs indépendants, dont l'un ou l'autre suffirait. **L'arbre est le même arbre.** La couverture exacte redécrit la recherche ; elle ne la réduit pas. Le choix d'élément « échouer en premier » est un bon ordre de variables, mais [aucun coup n'est jamais forcé](/fr/research/why/no-forced-moves/) sur ce casse-tête : l'élément le moins couvert offre encore des dizaines d'options vivantes très loin dans la recherche, si bien que le branchement reste énorme jusqu'en bas, sur un espace généralement estimé aux alentours de $10^{100}$ plateaux. Un moteur DLX parcourt cet arbre en entier ou pas utilement du tout ; et sa boucle interne de parcours de pointeurs est limitée par la mémoire, un ordre de grandeur derrière les moteurs à tableaux réglés pour le cache qu'emploient les [meilleurs solveurs par retour en arrière](/fr/research/lab/experiments/joshua-blackwood/solver/). **Aucun crédit partiel.** DLX répond à une seule question : couvert exactement, ou non. Toute l'économie d'Eternity II repose sur des scores partiels (467, 469, 470) et sur des recherches qui tolèrent délibérément quelques bords mal appariés pour y parvenir. La couverture exacte n'a aucun moyen natif de laisser un bord non apparié moyennant une pénalité ; la relâcher à ce point revient à la reconstruire en séparation et évaluation, et à ce moment-là l'élégance qui la justifiait a disparu. ## Verdict Gardez DLX sur l'étagère pour ce qu'il est : l'instrument de l'exhaustivité. Dénombrement, preuves d'unicité, vérité de terrain sur les petits plateaux : imbattable, et digne du soin d'implémentation qu'il exige. Comme attaque du casse-tête complet, c'est une [impasse](/fr/research/build/dead-ends/), pour des raisons structurelles qu'aucun facteur constant ne corrigera : l'arbre qu'il doit épuiser est astronomique, et le jeu des scores partiels auquel joue toute méthode détentrice d'un record est un jeu où il ne peut pas entrer. ## À lire aussi - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. --- # La traîne comme problème exact à part entière > Un plateau partiel solide, c'est une région haute que le producteur a travaillée plus une bande basse de rangées inachevées. On gèle le haut, on confie la traîne à un solveur de contraintes exact, et on lit quelle moitié fixe le plafond : la structure du producteur ou la fin de partie bâclée. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/exact/exact-tail-endgame/ - Mise à jour: 2026-07-23 - Sujets: exact-methods, construction - Reproduire: `just research-exact-tail-endgame` - Source: Solveur CP-SAT de Google OR-Tools (le moteur exact utilisé pour le modèle de traîne) — https://developers.google.com/optimization/cp/cp_solver - Source: Problème d'affectation (Wikipédia), la relaxation linéaire que la traîne n'est pas — https://en.wikipedia.org/wiki/Assignment_problem --- Un plateau partiel solide, c'est deux choses collées ensemble : une région haute que le producteur a longuement travaillée, et une bande basse de quelques rangées inachevées. Quand un tel plateau reste sous un score visé, la question naturelle est : quelle moitié est en cause ? Le plafond est-il fixé par la structure haute du producteur, ou par la fin de partie des dernières rangées que le producteur a expédiée à bon marché ? Cette page traite cette fin de partie comme sa propre optimisation exacte, découplée du producteur, et se sert de la réponse comme d'un instrument : geler le haut, résoudre la traîne jusqu'à (ou vers) l'optimum, et lire si la résolution exacte rapporte quoi que ce soit que le producteur a laissé sur la table. Chaque score ci-dessous suit la même convention : arêtes intérieures appariées hors bordure, de sorte qu'un plateau 16×16 complet plafonne à 480, et les cinq pièces indices officielles sont fixées à leur place et jamais déplacées. Cette dernière clause garde la comparaison équitable, elle est donc intégrée au modèle plutôt que vérifiée après coup. ## La traîne comme petit problème exact Fixons un plateau complet produit par un remplisseur glouton en ordre ligne par ligne à graine (la même famille de producteurs que l'[étude de finissabilité](/fr/research/lab/experiments/raphael-anjou/frostline/), adaptée pour honorer les cinq indices afin que chaque plateau émis soit valide sur les indices par construction). On gèle les rangées $0$ à $15-R$ ; les $R$ rangées du bas forment la bande de traîne, moins toute case portant un indice, qui reste gelée. Les pièces propres de la traîne, celles que le producteur y a placées, forment le vivier à permuter. La traîne est alors confiée à un modèle CP-SAT : - une (pièce, rotation) légale au bord par case libre, tirée du vivier propre de la traîne, avec un AllDifferent pour qu'aucune pièce ne serve deux fois ; - des variables de couleur par côté canalisées depuis le choix (pièce, rotation) par des tables de côtés Element ; - des contraintes dures pour la bordure (gris exactement sur les arêtes face au bord) et pour chaque adjacence que la traîne touche ; - un booléen d'appariement sur chaque arête touchée par la traîne, l'objectif maximisant leur somme. Ce n'est pas une affectation linéaire. Le coût d'une case se scinde entre les arêtes faisant face au haut gelé (qui ne dépendent que du choix de cette case) et les arêtes faisant face à une autre case libre (un produit de deux décisions). Les termes libre-libre sont réellement bilinéaires, si bien qu'un appariement biparti à la Hongrois ne peut représenter la traîne exactement ; il ne tarife que la frontière gelée. Ce qui rend la traîne traitable malgré tout, c'est la taille, pas la linéarité : à une ou deux rangées le solveur de contraintes la boucle directement, là où un simple appariement serait aveugle à la moitié de l'objectif. Le même modelage apparaît dans les notes du projet sur les [encodages SAT et CSP](/fr/research/build/exact/sat-csp-encodings/) ; ici il vise un sous-plateau plutôt que le puzzle entier. ## Le budget de ruptures entrantes Le producteur remplit rangée par rangée et impute à chaque case un budget sur ses seules arêtes *entrantes* : en ordre ligne par ligne, les arêtes entrantes d'une case sont son haut et sa gauche. En notant $\mathrm{conf}(c)$ le nombre de ces deux-là qui ne s'apparient pas, le producteur travaille dans le régime $\mathrm{conf}(c)\le 1$ : au plus une rupture entrante par case. Le modèle exact reflète cela exactement par un plafond par case, et balayer le plafond est le second axe de l'expérience : - **plafond $=1$** reproduit le monde propre du producteur, $\le 1$ rupture par case. Toute case que le modèle exact remplit est une case que le producteur aurait pu, en principe, bâtir. - **plafond $=2$** admet une *double* rupture entrante à une case : deux désaccords arrivant d'un coup. C'est un placement que le producteur $\le 1$ rupture ne peut jamais faire, donc tout point qu'il rapporte est un point structurellement hors de portée du producteur. L'écart entre les deux plafonds est le prix, en arêtes appariées, du seul coup que le producteur ne peut pas jouer. ## Ce que la traîne exacte rapporte Pour chaque graine de producteur, le modèle est lancé à une rangée (traîne de 16 cases) et deux rangées (traîne de 32 cases), aux deux plafonds. La quantité vedette est le delta, $\text{score exact} - \text{score producteur}$, sur le haut gelé identique. Par construction, la résolution exacte domine la traîne gloutonne, donc le delta n'est jamais négatif ; son intérêt est de savoir s'il est *strictement positif* (le producteur a laissé des points dans la traîne) ou *nul* (le producteur était déjà optimal sur la traîne), et comment cette réponse varie selon les graines. À une rangée, le modèle atteint un optimum prouvé chaque fois qu'il est faisable, en quelques centièmes de seconde. Chaque plateau émis est rescoré indépendamment du solveur, et la vérification va de bout en bout : le blob d'arêtes de l'URL de visualiseur est décodé en une grille de couleurs et ses appariements intérieurs recomptés à zéro, et ce recompte concorde avec le score annoncé par le solveur (pour le plateau à une rangée de la première graine, $385$ se redécode en $385$). Le jeu de pièces est aussi revérifié distinct et les cinq indices revérifiés en place. Quelques graines montrent toute l'histoire en miniature : > **[Figure]** Traîne d'une rangée (16 cases), optimum prouvé, quatre graines de producteur — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. Trois régimes coexistent sur un même banc d'essai, et ce sont exactement les régimes que le carnet source décrivait séparément : - **Traîne limitante** (graine 1). La traîne gloutonne laisse $6$ arêtes appariées sur la table que la résolution exacte récupère, sans avoir besoin d'une rupture double. Ici la contrainte limitante est bien la fin de partie, et le producteur l'a sous-résolue. - **Traîne serrée** (graine 2, plafond $=1$). La résolution exacte égalise le producteur : delta $0$. La traîne propre du producteur était déjà optimale sous sa règle $\le 1$ rupture, il n'y a donc rien à récupérer, et le plafond réside dans la structure haute, pas dans la traîne. Porter le plafond à $2$ trouve alors exactement un point de plus, et c'est précisément une rupture double entrante, le seul levier que le producteur ne peut pas actionner. - **Rupture double porteuse** (graine 3, plafond $=1$). Le plus fort de tous : le producteur $\le 1$ rupture ne peut compléter cette traîne *à aucun score*, donc plafond $=1$ est infaisable. Seule une rupture double entrante admet un remplissage tout court, et plafond $=2$ atteint alors un optimum prouvé. La rupture double n'est pas un bonus ici ; c'est la différence entre une complétion et aucune. Sur tout le balayage à 24 graines à une rangée, la répartition est le résultat : au plafond $=1$, $18$ graines sont à traîne limitante (delta strictement positif), $1$ à traîne serrée (delta nul), et $5$ carrément infaisables (aucune complétion $\le 1$ rupture de la traîne n'existe). Les points récupérés vont de $0$ à $8$ arêtes appariées, médiane $4$, moyenne d'environ $3{,}9$. Porter le plafond à $2$ rend les $24$ graines faisables et toutes à traîne limitante, avec des deltas de $1$ à $9$, médiane $4{,}5$, moyenne d'environ $4{,}8$ : le coup de rupture double débloque à la fois les cinq graines coincées et ajoute un point ou deux presque partout ailleurs. Que la traîne soit la contrainte limitante est une propriété du plateau individuel, pas un absolu. À deux rangées la traîne passe à 32 cases et le modèle ne prouve plus l'optimalité dans le budget de temps : il rend des incumbents faisables à environ $45$ s chacun. Les deltas y sont plus grands mais ce sont des *bornes inférieures*, puisqu'une meilleure complétion peut exister que le solveur n'a pas certifiée. > **[Figure]** Traîne de deux rangées (32 cases), faisable non prouvée optimale, quatre graines — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. ## Ce que cela règle, et ce que cela ne règle pas Lue comme un instrument, la traîne exacte répond nettement à la question « quelle moitié ? » sur ce banc d'essai : parfois la traîne (delta strictement positif, la fin de partie était sous-résolue), parfois le haut (delta nul, la traîne était déjà serrée). La réponse dépend du producteur, ce qui est justement le fond de l'affaire. Un même score de plateau peut cacher l'un ou l'autre régime, et le diagnostic bon marché pour les distinguer est de savoir si le solveur exact ferme l'écart d'optimalité. Quand il le fait et que le delta est nul, la traîne est serrée et aucun finisseur n'aidera ; quand le delta est positif, le finisseur heuristique du producteur a laissé des arêtes appariées non réclamées. Le plafond de rupture double affine cela : au moins une graine ici n'a *aucune* complétion de sa traîne bâtissable par le producteur, donc la capacité du solveur exact à placer une rupture double entrante est porteuse plutôt que cosmétique. Ce que ce petit run ne règle pas, c'est le record. Le producteur ici est un remplisseur glouton simple dont les plateaux se situent entre le milieu des 360 et la fin des 370, bien en dessous des producteurs de piste-record qu'utilisait le résultat source, donc traîner exactement ici ne peut *pas déplacer un record* : le titre au niveau record du carnet, une traîne exacte battant un finisseur heuristique d'une arête appariée sur un plateau bien plus fort, est lié à ce producteur plus fort et n'est pas reproduit ici. Ce qui est reproduit, c'est le mécanisme et la forme de l'effet : la bande basse est un véritable petit problème exact, la résolution exacte ne perd jamais contre la traîne propre du producteur et la bat souvent, le plafond de rupture double rapporte des points réels et parfois porteurs, et le fait que la traîne soit la contrainte limitante dépend du plateau. Les chiffres à deux rangées sont des bornes inférieures, pas des optima prouvés, et doivent se lire comme tels. Pour situer n'importe lequel de ces scores d'arêtes appariées face aux meilleurs résultats de la communauté, obtenus avec des budgets de calcul bien plus grands, voir la [page des records](/fr/research/records/). L'appariement que vise cette page, un producteur fort fini par un solveur des dernières rangées *exact* plutôt qu'heuristique, est aussi le pas suivant naturel pour les [producteurs par faisceau](/fr/research/build/construct/beam-search/) du projet : le finisseur, pas le producteur, est là où la méthode exacte gagne sa place. ## Reproduire Le plan, le script CP-SAT et la table de résultats validée vivent avec le [sujet de reproduction](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/exact-tail-endgame). Une seule commande régénère tout le balayage : ```sh just research-exact-tail-endgame ``` Elle produit `results/tailforge.json` : un enregistrement par (graine, rangées, plafond) avec le score producteur, le score exact, le delta, le statut CP-SAT et un drapeau de revérification indépendante, plus un résumé par configuration de la distribution des deltas selon les graines. Les résolutions à une rangée sont exactes et reproduisent leurs optima prouvés à la réexécution ; les résolutions à deux rangées sont des incumbents faisables à graines dont les deltas exacts sont liés à la lignée, elles reproduisent donc le signe et la forme plutôt que le chiffre exact. ## À lire aussi - [Lire l'avenir d'une rangée dans ses pièces restantes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/frostline/) — Une énergie libre issue de la propagation de croyances, calculée sur les pièces restantes de la dernière rangée, prédit le rang de la meilleure fin possible. Le signal n'est pas un proxy du score brut, survit à un changement de producteur et meurt au-delà d'une rangée. - [Rendez-vous au milieu](https://eternity2.dev/fr/research/build/exact/meet-in-the-middle/) — Énumérer deux moitiés d'un problème et les recoller sur une interface partagée, en échangeant de la mémoire contre un exposant divisé par deux. L'astuce classique de Horowitz–Sahni, ce qu'elle donne sur des bandes du plateau, et ce que l'expérience BANDSAW de ce projet a mesuré, y compris la méthode unilatérale qui l'a battue. - [Encodages SAT et CSP](https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/) — Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Applications itérées et divide-and-concur > L'attaque des physiciens sur la satisfaction de contraintes : scinder le puzzle en deux ensembles de contraintes chacun facile à projeter, puis itérer une application dont les points fixes sont les solutions. La méthode de Veit Elser a fait la couverture de PNAS, et pourtant sur la liste Eternity II elle reste une voie admirée, testée une fois, jamais empruntée jusqu'au bout. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/exact/iterated-maps/ - Mise à jour: 2026-07-02 - Sujets: exact-methods, learning - Source: Elser, Rankenburg & Thibault, Searching with iterated maps (PNAS 104:418, 2007) — https://doi.org/10.1073/pnas.0606359104 - Source: Gravel & Elser, Divide and concur: a general approach to constraint satisfaction (Phys. Rev. E 78, 036706, 2008) — https://doi.org/10.1103/PhysRevE.78.036706 - Source: Gravel & Elser, Divide and concur: open preprint (arXiv:0801.0222) — https://arxiv.org/abs/0801.0222 - Source: Aragón Artacho, Borwein & Tam, Recent results on Douglas–Rachford methods for combinatorial optimization problems (arXiv:1305.2657) — https://arxiv.org/abs/1305.2657 - Source: JSA formalise le problème dual et présente les travaux d'Elser à la liste (message groups.io 9347) — https://groups.io/g/eternity2/message/9347 - Source: JSA sur les articles divide-and-concur et la question ouverte du passage à l'échelle (message groups.io 9350) — https://groups.io/g/eternity2/message/9350 - Source: Le test de Dima : un simple hill-climber bat la difference map sur le propre benchmark de l'article (message groups.io 9351) — https://groups.io/g/eternity2/message/9351 - Source: Les diapositives ICCOPT-MOPTA 2007 d'Elser déposées dans les fichiers du groupe, « Eternity II mentionné dans les 3 dernières diapositives » (message groups.io 9349) — https://groups.io/g/eternity2/message/9349 - Source: Code source de Veit Elser, avec un exemple de puzzle 5×5, partagé dans les fichiers du groupe (message groups.io 9362) — https://groups.io/g/eternity2/message/9362 - Source: Le récapitulatif de JSA en 2015 : les petites versions du modèle résolues, la grande non (message groups.io 9442) — https://groups.io/g/eternity2/message/9442 - Source: L'esquisse du transfert primal–dual de Dima avec appariement hongrois (message groups.io 9445) — https://groups.io/g/eternity2/message/9445 - Source: Le précédent de l'échange d'arêtes SRD : 8×8 résolu, jamais le 10×10 (message groups.io 9447) — https://groups.io/g/eternity2/message/9447 - Source: Douglas–Rachford nommé sur la liste, via la note Wikipédia sur TetraVex (message groups.io 11592) — https://groups.io/g/eternity2/message/11592 - Source: JSA relie Douglas–Rachford à la lignée d'Elser (message groups.io 11594) — https://groups.io/g/eternity2/message/11594 --- Jusqu'ici, chaque méthode de ce rayonnage traite Eternity II comme une recherche discrète : placer, vérifier, revenir en arrière. La communauté des physiciens a proposé quelque chose de plus étrange. Le groupe de Veit Elser à Cornell a reformulé la satisfaction de contraintes comme de la géométrie, un point rebondissant entre deux ensembles dans un espace de grande dimension, et a fait chevaucher un même schéma d'itération de la reconstruction de phase en cristallographie aux rayons X jusqu'au Sudoku, au 3-SAT et au repliement des protéines, portant la méthode en couverture de PNAS ([Elser, Rankenburg & Thibault, 2007](https://doi.org/10.1073/pnas.0606359104)). Les puzzles à appariement d'arêtes en sont presque l'illustration idéale, et la couverture de ce numéro de PNAS en montrait précisément un, comme l'a fait remarquer le membre qui a apporté ces travaux à la liste ([message groups.io 9347](https://groups.io/g/eternity2/message/9347)). Cette page explique la méthode comme il se doit, car elle est réellement frappante et réellement différente de tout le reste du catalogue. Elle rapporte ensuite ce que la communauté Eternity II en a effectivement fait : un accès d'intérêt en 2014–2015, un test empirique, une archive du propre code d'Elser partagée, et aucune campagne. C'est une voie connue, ici peu fréquentée. ## Deux ensembles faciles, une intersection difficile On plonge un état du plateau comme un point $x$ dans un espace euclidien, disons un vecteur réel avec une coordonnée par triplet (case, pièce, rotation), où un plateau légal est une assignation 0/1. Définissons maintenant deux ensembles de contraintes : - $C_1$, **pièces utilisées une fois** : chaque case contient exactement une pièce-rotation, et chaque pièce est utilisée exactement une fois. Les couleurs des arêtes sont ignorées. - $C_2$, **arêtes concordantes** : chaque paire d'arêtes en contact s'accorde en couleur, et le bord est gris. L'inventaire des pièces est ignoré, si bien que les cases peuvent contenir des mélanges fractionnaires ou des pièces dupliquées. Un Eternity II résolu est exactement un point de $C_1 \cap C_2$. L'astuce qui rend la formulation utile, c'est que chaque ensemble *pris seul* est facile à projeter. Étant donné un $x$ arbitraire, on peut calculer à moindre coût le point le plus proche de l'ensemble : - $P_1(x)$, l'assignation de pièces valide la plus proche, est un problème d'appariement biparti : affecter 256 pièces à 256 cases pour maximiser l'affinité totale. L'algorithme hongrois le résout exactement en temps polynomial, le même moteur d'affectation qui alimente l'étape de recomplétion de la [recherche locale](/fr/research/build/local-search/local-search-alns/). - $P_2(x)$, le coloriage cohérent en arêtes le plus proche, se décompose arête par arête : chaque jointure intérieure moyenne simplement ses deux côtés vers l'accord. Purement local, massivement parallèle. Chaque projection est un problème résolu. Toute la difficulté d'Eternity II réside entièrement dans l'*intersection*, et le schéma naïf, l'alternance de projections $x \mapsto P_1(P_2(x))$, échoue exactement comme on l'imagine : il converge vers une paire de points, un dans chaque ensemble, localement aussi proches que possible et globalement faux. Un minimum local, déguisé en projection. Cette vision à deux faces a atteint la liste indépendamment d'Elser. Dès 2008, antminder proposait de découper les pièces en triangles d'arête et de chercher dans le domaine des losanges colorés ([message 6184](https://groups.io/g/eternity2/message/6184)), et JSA y a aussitôt reconnu le *problème dual* ([message 6185](https://groups.io/g/eternity2/message/6185)) : Eternity II, c'est 256 pièces à disposer pour que 480 arêtes concordent, ou 480 carrés d'arête colorés à disposer pour qu'ils engendrent les 256 pièces correctes. Résoudre, c'est rendre les deux descriptions vraies à la fois. ## La difference map La réponse d'Elser au piège du minimum local n'est pas d'alterner les projections, mais d'itérer une *difference map*. Sous la forme publiée, avec le paramètre fixé à $\beta = 1$, un pas s'écrit $$ x \;\mapsto\; D(x) \;=\; x \;+\; P_1\!\big(2P_2(x) - x\big) \;-\; P_2(x), $$ et la famille à $\beta$ général interpole autour de cette expression au moyen de points « estimés » internes $f_i(x)$ construits à partir des projections ([PNAS 2007](https://doi.org/10.1073/pnas.0606359104)). Trois propriétés font tout le travail : 1. **Point fixe = solution.** Si $D(x^\ast) = x^\ast$, alors $P_1(2P_2(x^\ast) - x^\ast) = P_2(x^\ast)$ : le même point appartient aux deux ensembles. On lit la solution comme $P_2(x^\ast)$, et non comme $x^\ast$ lui-même : l'itéré est un *chercheur*, non un plateau. La terminaison est détectée lorsque le déplacement $\Delta = \lVert D(x) - x \rVert$ passe sous un seuil, et le candidat est alors vérifié exactement. 2. **Aucune fonction de coût.** L'application ne descend rien. Cela ressemble à un défaut, et c'est précisément l'intérêt : un hill-climber reste bloqué là où sa fonction de score présente un optimum local, mais la difference map n'a aucun score pour la flatter et la retenir. Loin des points fixes elle continue de bouger, en pratique de façon chaotique, si bien que les configurations quasi-optimales qui piègent la [recherche locale](/fr/research/build/local-search/local-search-alns/) sont des lieux qu'elle visite puis quitte. C'est l'« effet tunnel » que les physiciens prisaient. 3. **L'itéré vit hors des deux ensembles.** $x$ n'a pas besoin de satisfaire l'une ou l'autre contrainte pendant la recherche. Comme les plateaux fractionnaires de la [relaxation LP](/fr/research/build/exact/lp-relaxations/), il explore une superposition de plateaux. À la différence du LP, il n'a aucun objectif à optimiser et aucun optimum sur lequel plafonner : ses seuls lieux de repos sont les solutions. Pour $\beta = 1$ la difference map coïncide avec l'**itération de Douglas–Rachford**, une méthode de projection que les analystes convexes étudient depuis les années 1950 ; la convergence est démontrable lorsque les deux ensembles sont convexes, et totalement non garantie ici, où $C_1$ est un nuage de points de permutation. La liste Eternity II n'a appris le nom de la famille qu'en 2025, quand Wyatt Carpenter a trouvé Wikipédia créditant « l'algorithme de Douglas–Rachford » pour la résolution de TetraVex et l'a signalé comme une piste possiblement prometteuse que personne n'avait soulevée ([message 11592](https://groups.io/g/eternity2/message/11592)) ; JSA a bouclé la boucle, renvoyant au fil Elser de 2014–2016 et présentant Douglas–Rachford comme la vision par décomposition $f(x) + g(x)$ de la même attaque ([message 11594](https://groups.io/g/eternity2/message/11594)). La littérature d'optimisation avait bel et bien adopté la méthode pour exactement cette famille de puzzles ([Aragón Artacho, Borwein & Tam](https://arxiv.org/abs/1305.2657)). ## Divide and concur : l'astuce des répliques L'image à deux ensembles ci-dessus exigeait une projection globale ($P_1$ est un unique gros appariement). L'article suivant de Gravel et Elser, [*Divide and concur*](https://doi.org/10.1103/PhysRevE.78.036706) ([préprint ouvert](https://arxiv.org/abs/0801.0222)), rend la construction mécanique pour *n'importe quel* CSP. On donne à chaque contrainte sa propre **réplique** privée de chaque variable qu'elle touche : - La projection **divide** satisfait chaque contrainte indépendamment sur ses propres répliques. Chaque contrainte devient un petit problème local (pour Eternity II : une arête, deux côtés de pièce), trivialement projetable. - La projection **concur** force toutes les répliques d'une même variable à s'accorder, en remplaçant chacune par leur moyenne, la projection la moins coûteuse qu'on puisse imaginer. Faites tourner la difference map entre *divide* et *concur* et vous obtenez un solveur CSP général dont le travail par itération est entièrement local, l'étape de moyennage jouant le rôle de la communication. Gravel et Elser l'ont comparé au 3-SAT, où il passait à l'échelle de façon comparable à WalkSAT, et s'en sont servis pour améliorer des empilements de sphères connus. Lorsque la méthode a atteint la liste, Dima en a immédiatement reconnu la structure venue de son propre domaine : le schéma de moyennage des répliques est un proche parent de la propagation de croyance sur le graphe de contraintes, un lien que les auteurs eux-mêmes établissent ([message 9348](https://groups.io/g/eternity2/message/9348)). Pour les lecteurs de ce wiki l'air de famille va plus loin : une recherche par passage de messages sur un graphe qui n'est localement arborescent nulle part (chaque bloc 2×2 est un cycle) est exactement le cadre où les méthodes apparentées de la page [impasses](/fr/research/build/dead-ends/) (propagation d'enquête, ordonnancement des coups par propagation de croyance) se sont aplaties et éteintes. ## Ce que montre réellement l'archive Le compte rendu, intégral, car il est court. - **2008, un rejet en passant.** La première mention de la méthode sur la liste est Don Milne rangeant la « difference map » parmi les techniques d'optimisation qu'il jugeait incapables de résoudre des CSP complexes : elles ne brillent que lorsque les solutions sont denses, et Eternity II a été [conçu pour n'en avoir presque exactement qu'une](/fr/research/why/complex-theory/) ([message 5479](https://groups.io/g/eternity2/message/5479)). - **2014, la véritable introduction.** Le schéma du réseau d'arêtes du puzzle proposé par un membre a conduit JSA à énoncer le problème dual et à présenter les travaux d'Elser : la difference map « fait des allers-retours entre les deux problèmes duaux » ([message 9347](https://groups.io/g/eternity2/message/9347)), avec des renvois vers l'article de PNAS et l'article divide-and-concur de Physical Review ([message 9350](https://groups.io/g/eternity2/message/9350)). Les propres diapositives ICCOPT-MOPTA 2007 d'Elser, qui mentionnent Eternity II dans leurs trois dernières diapositives, ont été déposées dans les fichiers du groupe ([message 9349](https://groups.io/g/eternity2/message/9349)). - **2014, l'unique test empirique.** Dima a lu l'article de PNAS, l'a apprécié, et l'a vérifié : il a écrit un simple hill-climber pour le propre benchmark de 3-coloriage de graphe de l'article et a résolu l'instance $N=16$ en quelques secondes, là où la Table 2 de l'article donne à la difference map de l'ordre de dix minutes. « Ce qui me fait me demander si c'est vraiment à la hauteur de la hype » ([message 9351](https://groups.io/g/eternity2/message/9351)), tout en jugeant encore l'idée à deux faces pièces-contre-arêtes digne d'être explorée pour E2. - **2015, du code et une promesse.** Quelqu'un a obtenu du code source d'Elser en personne, avec un exemple d'appariement d'arêtes 5×5 traité, et l'a partagé dans les fichiers du groupe ([message 9362](https://groups.io/g/eternity2/message/9362)). Dans le fil « New Approach? » cet été-là, JSA a récapitulé le statut de la méthode : elle « a résolu de petites versions du modèle d'Eternity II », et si elle avait résolu la grande « nous en aurions entendu parler » ([message 9442](https://groups.io/g/eternity2/message/9442)). Juraj Pivovarov a demandé une difference map concrète écrite noir sur blanc pour Eternity II ([message 9443](https://groups.io/g/eternity2/message/9443)) ; JSA a promis un bref exposé ([message 9446](https://groups.io/g/eternity2/message/9446)) qui n'apparaît jamais dans l'archive. Dans le même fil Dima a esquissé explicitement le transfert primal–dual (transporter une solution de coloriage d'arêtes vers l'assignation de pièces la plus proche avec l'algorithme hongrois, et retour) et a rapporté que son propre recuit côté dual plafonnait à 48/49 tuiles correctes sur le 7×7 de Brendan Owen ([message 9445](https://groups.io/g/eternity2/message/9445)), tandis que Mike Pringle rappelait le cousin maison de la liste, l'approche d'échange d'arêtes SRD de 2007 : capable du 8×8, jamais du 10×10 ([message 9447](https://groups.io/g/eternity2/message/9447)). - **2025, un nom et un haussement d'épaules.** Le fil Douglas–Rachford ([message 11592](https://groups.io/g/eternity2/message/11592)) n'a suscité qu'une évaluation rapide, utile pour la théorie, « mais guère plus » ([message 11593](https://groups.io/g/eternity2/message/11593)), et la réflexion de JSA selon laquelle, sur un puzzle bâti pour être optimalement difficile, il s'attendrait à ce que le nombre d'itérations soit « de l'ordre de » celui des nœuds d'un backtracker de toute façon ([message 11594](https://groups.io/g/eternity2/message/11594)). Voilà le compte rendu tout entier : aucun membre n'a jamais rapporté avoir fait tourner la difference map ou divide-and-concur sur le puzzle complet à 480 arêtes, ni même sur l'échelle de benchmarks 10×10. La littérature à comité de lecture a une forme comparable. Le groupe d'Elser a publié les succès de la méthode sur le coloriage, le SAT, l'empilement et le repliement, et a réservé Eternity II aux exposés, aux illustrations de couverture et au code d'exemple. Personne n'a publié de résultat de difference map sur le puzzle complet, positif ou négatif. > **Pourquoi si peu de reprise ?** > > En partie le calendrier (le fil de 2014 est tombé dans les années les plus calmes de l'archive) et en partie le point de données de Dima, qui a vite terni l'éclat. Mais la raison plus profonde est celle que Don Milne a donnée en 2008 et que JSA a répétée en 2025 : les méthodes stochastiques continues paient lorsque les solutions sont abondantes relativement à l'espace, et Eternity II siège au [pic de difficulté conçu](/fr/research/why/complex-theory/) où elles ne le sont pas. La méthode est célèbre *parce que* l'appariement d'arêtes l'illustre à merveille, non parce qu'elle résout l'appariement d'arêtes à grande échelle. ## À quoi ressemblerait une tentative aujourd'hui L'écart entre « discuté » et « mesuré » est assez étroit pour qu'une seule personne puisse le combler. Une tentative moderne consisterait à : 1. **Fixer le plongement.** Vecteurs one-hot par case sur 1 024 pièces-rotations (la version à deux ensembles), ou répliques divide-and-concur par contrainte d'arête. C'est l'étape que Juraj a réclamée en 2015 et que personne n'a écrite pour E2 ; le code 5x5 partagé par Elser ([message 9362](https://groups.io/g/eternity2/message/9362)) en est le gabarit de départ naturel. 2. **Implémenter les deux projections.** L'accord d'arête est une moyenne locale ; la validité de pièce est une résolution hongroise par itération (256 cases x 1 024 candidats), ou du pur moyennage de répliques sous la forme divide-and-concur. 3. **Gravir l'échelle des benchmarks.** Confronter à la [suite de puzzles de Brendan Owen](/fr/research/build/benchmarks/), le même 7×7 où le recuit dual de Dima a atteint 48/49, puis 8×8, 9×9, 10×10, avec un simple hill-climber et un backtracker à redémarrages comme témoins, en traçant les itérations-jusqu'à-solution en fonction de la difficulté de l'instance. 4. **Rapporter la courbe, pas l'anecdote.** La sortie intéressante est l'exposant de passage à l'échelle : les propres articles d'Elser rapportent des nombres d'itérations croissant fortement avec la difficulté de l'instance, et la question ouverte que JSA a posée en 2014, comment cela passe-t-il à l'échelle pour des instances de classe E2 ? ([message 9350](https://groups.io/g/eternity2/message/9350)), n'a jamais reçu de réponse chiffrée sous forme de graphe. Le meilleur cas réaliste n'est pas un puzzle résolu. C'est une méthode caractérisée : soit une courbe de passage à l'échelle qui croise celle du backtracker en un point intéressant, ce qui serait une nouvelle, soit une entrée négative propre pour le registre des [impasses](/fr/research/build/dead-ends/), ce qui est aussi un progrès. ## Ce que cela coûte - **Par itération : deux projections.** La projection d'arête est linéaire en le nombre d'arêtes. La projection de pièce est la coûteuse : une résolution d'affectation exacte est en $O(n^3)$ pour l'algorithme hongrois, et à $n = 256$ cases cela fait des millions d'opérations par *itération*, face aux [dizaines de millions de placements par seconde](/fr/research/build/faster/solver-engineering/) d'un backtracker réglé. Divide-and-concur échange cela contre du pur moyennage local, au prix d'un état répliqué bien plus volumineux. - **Aucune garantie de convergence.** La théorie de convergence de Douglas–Rachford est convexe ; les deux ensembles d'Eternity II sont des nuages combinatoires. Sur les instances faisables, l'application trouve généralement des points fixes en pratique (c'est le contenu empirique des articles), mais rien ne borne le nombre d'itérations, et sur ce puzzle l'attente de JSA est qu'il égale le nombre de nœuds du backtracking ([message 11594](https://groups.io/g/eternity2/message/11594)). - **Point fixe = solution, et rien de moindre.** La méthode n'offre aucune sortie partielle utile : jusqu'à ce que $\Delta \to 0$ vous avez un point errant dans un espace fractionnaire, et non un plateau scoré. Il n'y a aucun lot de consolation à 460 arêtes en chemin, ce qui importe sur le seul puzzle où l'[échelle des records](/fr/research/records/) se compte en scores partiels. - **Le tableau des scores.** Un test communautaire, perdu face à un hill-climber sur le propre benchmark de la méthode ([message 9351](https://groups.io/g/eternity2/message/9351)) ; de petits modèles d'appariement d'arêtes résolus dans les matériaux d'Elser ; le puzzle complet intouché. Élégante, rigoureuse, ici non démontrée, et, chose inhabituelle pour ce wiki, encore non mesurée plutôt que mesurée-et-enterrée. ## À lire aussi - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Relaxations LP et PLNE : une demi-pièce partout](https://eternity2.dev/fr/research/build/exact/lp-relaxations/) — Écrivez Eternity II comme un programme en nombres entiers, abandonnez l'intégralité, et un solveur linéaire atteint une erreur nulle en quelques secondes, 30 % d'une pièce et 20 % d'une autre partageant un même coin. Dix-huit ans de campagnes communautaires ont mesuré où s'arrête le confort fractionnaire : un plateau à 420–440 arêtes dès que les pièces doivent être entières, un mur PLNE dès le 8×8, et un record académique de 461 en une heure. Ce qu'enseigne la route de l'optimiseur, et là où le LP reste utile. - [Encodages SAT et CSP](https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/) — Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. --- # Relaxations LP et PLNE : une demi-pièce partout > Écrivez Eternity II comme un programme en nombres entiers, abandonnez l'intégralité, et un solveur linéaire atteint une erreur nulle en quelques secondes, 30 % d'une pièce et 20 % d'une autre partageant un même coin. Dix-huit ans de campagnes communautaires ont mesuré où s'arrête le confort fractionnaire : un plateau à 420–440 arêtes dès que les pièces doivent être entières, un mur PLNE dès le 8×8, et un record académique de 461 en une heure. Ce qu'enseigne la route de l'optimiseur, et là où le LP reste utile. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/exact/lp-relaxations/ - Mise à jour: 2026-07-22 - Sujets: exact-methods - Source: La formulation en clique maximum : 262 144 sommets de placement, trouver une clique de 256 (groups.io message 627, 2007) — https://groups.io/g/eternity2/message/627 - Source: Ensembles de rotations résolus par PLNE (glpsol) en environ 5 secondes chacun (groups.io message 3320, 2007) — https://groups.io/g/eternity2/message/3320 - Source: Rapport d'étape LP de Vlasta : 160 254 binaires ; la PLNE « applicable seulement aux puzzles 8×8 » (groups.io message 5602, 2008) — https://groups.io/g/eternity2/message/5602 - Source: Formulation par ascension continue d'Andrew et l'estimation à 800 000 jours (groups.io message 5304, 2008) — https://groups.io/g/eternity2/message/5304 - Source: Le LP à 50 000 variables de Benjamin et son coin fractionnaire : 30 % pièce 1, 20 % pièce 2 (groups.io message 6905, 2009) — https://groups.io/g/eternity2/message/6905 - Source: Décompte des contraintes de Benjamin (7 952 équations) et l'astuce d'intégralité quadratique (groups.io messages 6910/6913, 2009) — https://groups.io/g/eternity2/message/6913 - Source: Andrew sur le solveur implicite : « chaque pièce est partout », Newton–Raphson sur 250 000 poids (groups.io message 6911, 2009) — https://groups.io/g/eternity2/message/6911 - Source: Programme en nombres entiers binaires AMPL/CPLEX de Timmermans : 272 704 variables, 24 566 équations (groups.io message 6728, 2009) — https://groups.io/g/eternity2/message/6728 - Source: La « solution » 12×12 en domaine réel à 5,3 % d'infaisabilité (groups.io message 6745, 2009) — https://groups.io/g/eternity2/message/6745 - Source: Rétrospective de Munjak : affectation avec contraintes latérales, 200–224 pièces, sans retour arrière (groups.io message 8791, 2011) — https://groups.io/g/eternity2/message/8791 - Source: Wauters : la ligne académique, 461/480 arêtes correspondantes en une heure (groups.io message 9023, 2012) — https://groups.io/g/eternity2/message/9023 - Source: Wauters : ensembles de rotations par MILP en quelques millisecondes (groups.io message 9071, 2012) — https://groups.io/g/eternity2/message/9071 - Source: L'article MILP + clique maximum parvient à la liste (groups.io message 9683, 2017) — https://groups.io/g/eternity2/message/9683 - Source: Salassa, Vancroonenburg, Wauters, Della Croce & Vanden Berghe, MILP and Max-Clique based heuristics for the Eternity II puzzle (arXiv:1709.00252, 2017) — https://arxiv.org/abs/1709.00252 - Source: Wauters, Vancroonenburg & Vanden Berghe, A guide-and-observe hyper-heuristic approach to the Eternity II puzzle (JMMA, 2012) — https://link.springer.com/article/10.1007/s10852-012-9178-4 - Source: La PLNE moderne de Garvie : une instance 10×10 à 6 couleurs résolue en environ 19 minutes (groups.io message 11502, 2025) — https://groups.io/g/eternity2/message/11502 --- Il existe trois routes classiques vers Eternity II. Le retour arrière parcourt l'arbre. Les [encodages SAT et CSP](/fr/research/build/exact/sat-csp-encodings/) confient la logique à un solveur industriel. La troisième route appartient aux optimiseurs : écrire le puzzle comme un programme en nombres entiers (variables, contraintes linéaires, objectif) et appeler CPLEX. C'est la route que tout spécialiste de recherche opérationnelle essaie en premier, car elle s'accompagne d'un coup que les deux autres n'ont pas : la *relaxation*. Supprimez l'exigence que les variables soient entières et le programme en nombres entiers, NP-difficile, devient un programme linéaire, résoluble en temps polynomial. Résolvez la version facile, espérez que la réponse soit presque entière, réparez le reste. La communauté a emprunté cette route à répétition entre 2007 et 2025, avec des solveurs allant de `glpsol` à CPLEX en passant par des Newton–Raphson codés à la main, et le résultat a été mesuré assez précisément pour mériter une page : la relaxation se résout vite et rapporte un plateau presque parfait, fait de fractions de pièces. Forcez les pièces à être entières et le score s'effondre sur un plateau autour de 420–440 des 480 arêtes. L'écart entre l'optimum fractionnaire et l'optimum entier n'est pas un détail technique. C'est exactement l'endroit où vit le puzzle. ## La formulation Une variable binaire par placement, exactement comme dans l'encodage SAT : soit $x_{c,p,r} \in \{0,1\}$ signifiant « la pièce $p$ occupe la case $c$ avec la rotation $r$ ». Deux familles de contraintes d'affectation et un décompte par joint donnent le modèle complet : $$ \begin{aligned} \max \;\; & \sum_{s} y_s && \text{(matched seams)} \\ \text{s.t.} \;\; & \sum_{p,\,r} x_{c,p,r} = 1 && \forall\, \text{cell } c \\ & \sum_{c,\,r} x_{c,p,r} = 1 && \forall\, \text{piece } p \\ & y_s \,\le\, \sum_{k} \min\!\big( f_{s,k}^{1},\, f_{s,k}^{2} \big) && \forall\, \text{seam } s \end{aligned} $$ où $f_{s,k}^{i}$ est le flux de couleur, le poids total des placements du côté $i$ du joint $s$ qui exposent la couleur $k$ à travers celui-ci, $f_{s,k}^{i} = \sum_{(p,r)\,\text{showing}\,k} x_{c_i,p,r}$. Le $\min$ est linéarisé avec une variable auxiliaire par joint et par couleur ; pour la version de *faisabilité*, on exige plutôt un flux de couleur égal des deux côtés de chaque joint. Les modèles de la communauté atterrissent exactement là où l'arithmétique le prédit. Le LP de Benjamin de 2009 comptait ~50 000 variables (placements élagués aux positions valides) et 7 952 équations : 256 par case, 256 par pièce, et $60 \times 5 + 420 \times 17 = 7{,}440$ contraintes d'équilibre couleur-joint ([message 6910](https://groups.io/g/eternity2/message/6910)). Le modèle de Vlasta de 2008 portait 160 254 binaires ([message 5602](https://groups.io/g/eternity2/message/5602)) ; le programme binaire AMPL/CPLEX de Jimmy Timmermans, 272 704 variables et 24 566 équations ([message 6728](https://groups.io/g/eternity2/message/6728)). Günter Stertenbrink avait déjà posé la forme graphe équivalente en 2007 : faire des 262 144 placements des sommets, relier les paires compatibles, et demander une clique de taille 256 ([message 627](https://groups.io/g/eternity2/message/627)), la formulation vers laquelle la littérature académique est revenue une décennie plus tard. ## Relaxez-le, et il se résout en quelques secondes La relaxation ne demande qu'une seule modification : remplacer $x_{c,p,r} \in \{0,1\}$ par $0 \le x_{c,p,r} \le 1$. Ce simple changement fait franchir au problème la frontière la plus importante de l'optimisation. Le programme en nombres entiers est NP-difficile : la programmation en 0–1 est l'un des 21 problèmes complets originaux de Karp. Le programme linéaire est résoluble en temps polynomial (ellipsoïde, points intérieurs), et en pratique le simplexe expédie ces tailles de modèle presque instantanément. Benjamin l'a mesuré : son système à 50 000 variables a atteint une erreur inférieure à 0,01 en une dizaine de secondes ([message 6913](https://groups.io/g/eternity2/message/6913)). Deux propriétés rendent la relaxation véritablement utile, et pas seulement rapide. Toute solution entière est aussi une solution fractionnaire, donc l'optimum du LP est une *borne* : aucun plateau réel ne peut jamais marquer plus que ne le dit la relaxation. Et les solveurs LP renvoient des certificats (valeurs duales, preuves d'infaisabilité) que les méthodes sans variables entières n'offrent pas. Toute la question est de savoir quelle part de cette rapidité survit au retour vers les pièces entières. ## Le plateau fractionnaire Voici à quoi ressemble réellement l'optimum du LP, dans les mots de celui qui l'a calculé. Le système de Benjamin « a convergé relativement vite vers une erreur nulle » (un plateau parfait, autant que les contraintes pouvaient le voir), et le coin supérieur gauche contenait « 30 % pièce 1, 20 % pièce 2, 10 % pièce 3, 40 % pièce 4 » ([message 6905](https://groups.io/g/eternity2/message/6905)). L'expérience parallèle d'Andrew menait la même idée comme une ascension itérée sur une grille de poids 256×256×4 : « chaque pièce est partout » ([message 6911](https://groups.io/g/eternity2/message/6911)). La relaxation est satisfaite parce qu'une superposition peut se couvrir. Un quart d'une pièce à arête bleue plus trois quarts d'une pièce à arête rose présente un mélange qui correspond simultanément en partie à un voisin bleu et à un voisin rose, une correspondance qu'aucun plateau physique ne peut réaliser. Les contraintes linéaires savent tarifer quelle part de chaque pièce se trouve où ; elles ne peuvent pas exprimer « exactement l'une de celles-ci est réelle », car *une-parmi* n'est pas un fait linéaire. Il faut une contrainte quadratique (ou une contrainte d'intégralité) pour le dire. Benjamin a utilisé $(\sum v_i)^2 - \sum v_i^2 = 0$, qui force toutes les variables d'un groupe sauf une à zéro ([message 6913](https://groups.io/g/eternity2/message/6913)), et dès qu'il l'a ajoutée, la convergence est morte : le système « stagne à des valeurs plus élevées qui ressemblent à des résultats du type 420-440 / 480 arêtes correctes » ([message 6905](https://groups.io/g/eternity2/message/6905)). Une théorie limpide sous-tend l'observation. Les deux familles d'affectation à elles seules définissent un polytope dont tous les sommets sont entiers (c'est Birkhoff–von Neumann, et c'est précisément pourquoi l'algorithme hongrois résout l'affectation pure en temps polynomial). Ajoutez les contraintes de joint et cette propriété d'intégralité est détruite : le polytope acquiert des sommets fractionnaires, et l'optimum du LP se pose sur l'un d'eux. La rétrospective de David Munjak comprime cela en une ligne, listant parmi ses approches essayées « Problème d'affectation (solutions entières) » suivi de « Problème d'affectation avec contraintes latérales (solutions pas nécessairement entières) » ([message 8791](https://groups.io/g/eternity2/message/8791)). Les contraintes latérales (les arêtes, le puzzle véritable) sont exactement ce qui brise la garantie. Eternity II est un problème d'affectation facile soudé à un couplage difficile, et la relaxation optimise discrètement la seule moitié facile. ### La version à deux pièces Tout l'écart tient dans deux cases. Prenez deux cases adjacentes et deux pièces, l'une entièrement couleur 1, l'autre entièrement couleur 2. Tout arrangement en pièces entières marque 0 : le joint voit toujours la couleur 1 contre la couleur 2. Le LP marque exactement 1,0 : placez la moitié de chaque pièce dans chaque case, et les variables de correspondance linéarisées du joint collectent 0,5 de crédit pour la couleur 1 plus 0,5 pour la couleur 2, l'optimum fractionnaire se posant précisément au point 50/50. Nous l'avons vérifié à la main et avec un solveur LP (le programme entier renvoie 0, la relaxation renvoie 1,0). C'est le coin à « 30 % pièce 1 » de Benjamin réduit à son algèbre minimale, et cela isole le mécanisme : les variables de joint *récompensent* activement les affectations fractionnaires par case, donc le LP préfère les superpositions. L'exemple affûte aussi l'histoire Birkhoff–von Neumann. À cet optimum fractionnaire, les contraintes d'affectation sont satisfaites exactement ; rien dans le polytope d'affectation n'est forcé. C'est le seul objectif de joint en min-de-sommes qui tire l'optimum hors des sommets entiers. La moitié affectation du modèle n'a jamais été le problème. ## Le plateau mesuré Tous les quelques années, un nouveau venu empruntait la route, avec de meilleurs solveurs et davantage de mémoire, et se heurtait aux trois mêmes murs : la PLNE complète est insoluble au-delà des tailles jouets ; le LP est soluble et fractionnaire ; arrondir ou contraindre vers l'intégralité aboutit dans les 400 et quelques. Les campagnes, dans l'ordre : | Année | Qui | Modèle | Où elle s'est arrêtée | Msg | | --- | --- | --- | --- | --- | | 2007 | Günter Stertenbrink | Clique maximum, 262 144 sommets | Formulation seule ; jamais passée à l'échelle | [166](https://groups.io/g/eternity2/message/166), [627](https://groups.io/g/eternity2/message/627) | | 2007 | dmitri_ulitski | PLNE (glpsol) sur des ensembles de rotations | Résolu en ~5 s par ensemble ; le sous-problème est facile | [3320](https://groups.io/g/eternity2/message/3320) | | 2008 | Vlasta | PLNE, 160 254 binaires | « Applicable seulement aux puzzles 8x8 » ; passé au SAT, atteint 428 | [5602](https://groups.io/g/eternity2/message/5602) | | 2008–09 | Andrew (bozmo2004) | Ascension continue, Newton–Raphson sur ~250k poids | ~800 000 jours projetés avec son prototype VBA | [5304](https://groups.io/g/eternity2/message/5304), [6911](https://groups.io/g/eternity2/message/6911) | | 2009 | Benjamin (okifinoki) | LP, ~50 000 var., 7 952 contraintes | Erreur nulle en ~10 s, fractionnaire ; forcé entier : stagne à 420–440/480 | [6905](https://groups.io/g/eternity2/message/6905), [6913](https://groups.io/g/eternity2/message/6913) | | 2009–10 | Jimmy Timmermans | Idéaux toriques ; BIP AMPL/CPLEX, 272 704 puis 153k var. | Limite de 32k variables de Singular ; un 12x12 « résolu » à 5,3 % d'infaisabilité (converge, pas l'intégralité) | [6716](https://groups.io/g/eternity2/message/6716), [6728](https://groups.io/g/eternity2/message/6728), [6745](https://groups.io/g/eternity2/message/6745), [8077](https://groups.io/g/eternity2/message/8077) | | 2010 | Vlasta | MILP (164 256 booléens) converti en SAT | 8x8 en ~1 min ; à parité avec les retours arrière, sans aller plus loin | [7858](https://groups.io/g/eternity2/message/7858) | | 2008–10 | David Munjak | Affectation avec contraintes latérales, valeurs fractionnaires comme probabilités | 200–224 pièces placées, puis une impasse détectée ; jamais de retour arrière | [8791](https://groups.io/g/eternity2/message/8791) | | 2012 | Groupe Wauters | Hyper-heuristique (évaluée par les pairs) | 461/480 en une heure (la ligne académique) | [9023](https://groups.io/g/eternity2/message/9023) | | 2012 | Tony Wauters | MILP pour les ensembles de rotations | Millisecondes ; encore une fois, le sous-problème facile | [9071](https://groups.io/g/eternity2/message/9071) | | 2017 | Salassa, Vancroonenburg, Wauters et al. | Formulations MILP + clique maximum | « Computationnellement insoluble pour les instances de taille moyenne et grande » ; recyclées en décompositions heuristiques | [9683](https://groups.io/g/eternity2/message/9683), [arXiv](https://arxiv.org/abs/1709.00252) | | 2025 | Marcus Garvie | PLNE moderne | 10x10 à 6 couleurs en ~19 min ; l'E2 complet hors de portée | [11502](https://groups.io/g/eternity2/message/11502) | Trois lectures du tableau. D'abord, remarquez où la PLNE *gagne* : les ensembles de rotations, où l'on fixe uniquement l'orientation de chaque pièce de sorte que les comptes d'arêtes directionnels s'équilibrent, sont tombés sous `glpsol` en cinq secondes en 2007 et sous CPLEX en quelques millisecondes en 2012. Quand la structure entière est authentiquement facile, le solveur le dit immédiatement ; le silence du puzzle complet est un verdict, pas un problème d'outillage. Ensuite, les chiffres du plateau s'accordent à travers des machineries totalement différentes : les 420–440 de Benjamin par LP pénalisé, les 200–224 pièces placées sans faute de Munjak par affectation itérée, les 461 du groupe Wauters avec une heure de réparation métaheuristique par-dessus. Tout ce qui a une forme d'optimiseur atterrit dans la même bande des 400 et quelques que la simple [recherche locale](/fr/research/build/local-search/local-search-alns/) atteint sans aucun LP. Enfin, l'article de 2017, le traitement académique le plus solide, avec à la fois une formulation MILP et une formulation en clique maximum, concède l'insolubilité dans son résumé et bascule vers l'usage des formulations *à l'intérieur* d'heuristiques. Les bâtisseurs de la route eux-mêmes ont posé le panneau de déviation. Le versant « borne » de l'histoire a la même forme et vit sur le [registre des impasses](/fr/research/build/dead-ends/) : les plafonds LP mesurés de ce projet se situent entre 477 et 479 alors que les plateaux qui les portent avoisinent 458, un écart bien trop large pour certifier quoi que ce soit, pour exactement la raison de couverture fractionnaire évoquée plus haut. L'anatomie de ces bornes a sa propre section plus bas. Un fait de littérature mérite sa place à côté du tableau. Le traitement académique le plus solide, l'article MILP + clique maximum de 2017, ne résout des instances entières que jusqu'à environ 7×7 ou 8×8 et ne rapporte jamais de borne de relaxation LP pour l'instance 16×16 ([arXiv:1709.00252](https://arxiv.org/abs/1709.00252)). Pour autant que le registre public en témoigne, personne n'a publié de borne LP ou MILP valide sous 480 pour l'Eternity II complet. Les valeurs 477 à 479 mesurées plus bas sont *conditionnelles* (elles supposent une bordure fixée) ; la question inconditionnelle reste donc ouverte : prouver une borne valide quelconque sous 480 par relaxation convexe serait du neuf. ## Reformuler le puzzle sur les côtés de pièces Nous avons essayé une relaxation de notre cru, construite par l'autre bout du modèle. Au lieu de demander quelle pièce occupe quelle case, on liste les 1 024 côtés de pièces (256 pièces, 4 côtés chacune) et on demande quels côtés s'apparient : deux côtés ne peuvent se rencontrer que si leurs couleurs coïncident, et un plateau achevé est un appariement des 960 côtés non-bordure en les 480 joints intérieurs. Ce compte est exact par construction : les 4 pièces de coin apportent 2 côtés non-bordure chacune, les 56 pièces de bord en apportent 3, les 196 pièces intérieures en apportent 4, et $8 + 168 + 784 = 960 = 480 \times 2$. L'instance n'a aucun mou ; chaque côté non-bordure doit trouver un partenaire. Le LP sur ce graphe d'appariement raconte son histoire en trois temps. Figez chaque pièce dans une orientation fixe et la borne vaut 307,00, entière et égale à un décompte en forme close, mais non valide pour le vrai puzzle puisque les rotations sont interdites. Laissez les côtés s'apparier librement à travers les rotations (21 636 variables d'appariement, une contrainte de degré par côté) et le LP atteint exactement 480,00, avec 132 appariements fractionnaires ; ajouter des budgets d'appariement par pièce ne change rien. Ajoutez la cohérence de rotation, une variable de rotation relâchée par pièce couplée aux appariements pour que les côtés appariés d'une pièce s'accordent sur une seule orientation (262 900 variables, environ 503 000 contraintes, quelques minutes de solveur) : toujours 480,00, désormais avec tous les appariements fractionnaires et pas une seule pièce à rotation entière. Le LP garde 480 faisable en plaçant chaque pièce partiellement dans ses quatre rotations à la fois, le jumeau côté-de-pièce du coin à « 30 % pièce 1 » vu plus haut. Le registre des couleurs s'équilibre donc parfaitement à chaque niveau de la relaxation que nous pouvions nous offrir, et une borne qui se cale au maximum est un résultat négatif d'un genre précis et utile : il localise la difficulté. Rien dans « quels côtés peuvent s'apparier avec quels autres » n'obstrue un 480. L'obstruction vit entièrement dans ce que ces relaxations ne voient pas, à savoir que chaque pièce occupe une case entière et que l'appariement doit se poser à plat en grille 16×16. Même verdict que le modèle case-pièce, atteint par la direction opposée. Trois mesures ultérieures ferment complètement la question de l'offre. D'abord, la borne de comptage la plus simple qui soit, chaque couleur $c$ à $m_c$ demi-arêtes autorise au plus $\lfloor m_c/2 \rfloor$ joints appariés, s'évalue sur le vrai jeu de pièces à $5 \cdot 12 + 5 \cdot 24 + 12 \cdot 25 = 480$ exactement, parce que chacun des 22 comptes de couleur est pair. Le budget global de couleurs est vide de sens *par construction du puzzle* ; tout argument de rareté doit être local ou conditionnel. Ensuite, les rotations entières ne restaurent pas l'obstruction. Donnez à chaque pièce une unique variable de rotation entière et demandez au modèle d'offre par couleur si les engagements de rotation suffisent à bloquer 480 : non. L'optimum LP vaut 480,0 et, cette fois résolu aussi à l'optimalité entière, l'optimum entier vaut également 480,0 : pour chaque couleur il existe une affectation de rotations entières qui place ses arêtes sur les bons côtés pour dépenser tout le budget $\lfloor N_k/2 \rfloor$. Cela ajoute un quatrième barreau à l'échelle ci-dessus (rotations figées 307, appariement libre 480,00 fractionnaire, cohérence de rotation 480,00 fractionnaire, et désormais même les rotations entières laissent 480 faisable au niveau de l'offre). La flexibilité de rotation n'est jamais la contrainte active ; l'obstruction est positionnelle, quelle case, à côté de quelle case. Enfin, la vue « offre » ne sait même pas classer des plateaux partiels. Un LP de joints plafonné par l'offre par couleur (0,1 seconde par bordure) renvoie 480 pour les six bordures que nous lui avons soumises, la bordure qui porte le plateau communautaire à 469 arêtes (arêtes correspondantes, hors convention stricte à cinq indices ; les conventions sont sur [la page des records](/fr/research/records/)) comme cinq bordures fraîchement générées. Comme discriminateur de qualité de bordure, le LP au niveau de l'offre est inutile ; le LP positionnel, par case, de la section suivante les sépare de façon démontrée. ## Conditionner la borne sur une bordure La borne inconditionnelle se cale au plafond, alors nous l'avons conditionnée. Fixez une bordure complète (les 60 pièces du périmètre) et résolvez la relaxation LP sur les 196 cases intérieures : l'optimum est une borne supérieure valide *pour cette bordure*. Une note de convention avant les chiffres : chaque score de cette section compte les arêtes correspondantes sur 480 sur le 16×16 canonique avec les cinq indices officiels épinglés, et les plateaux mesurés sont les meilleurs de ce projet au moment de la mesure, pas des records ; les meilleurs communautaires sont plus hauts, tout le contexte est sur [la page des records](/fr/research/records/). La première surprise est le nombre de bordures différentes qui partagent un même plafond. Quatre plateaux de nos archives, aux quatre bordures distinctes, marquant 458, 457, 455 et 454 arêtes correspondantes, renvoient tous exactement la même borne LP conditionnelle : **478**. Et deux de ces bordures n'ont structurellement rien à voir avec les autres : un plateau à 457 partage l'intégralité des quatre rangées hautes (56 pièces) avec le plateau à 458, mais les plateaux à 454 et 455 ne partagent avec lui que 8 ou 9 placements sur 256, environ 3 %. La borne est donc un invariant grossier que des plateaux authentiquement différents ont en commun, pas l'empreinte d'une famille de solutions. La recherche locale confirme que les plateaux eux-mêmes sont coincés : des poussées sur les trois plateaux non-458 (8, 4 et 4 graines à dix minutes chacune) les ont soulevés de +0, +0 et +1 ; chaque bassin gît à son propre optimum local bien sous le plafond partagé de 478. Deux mesures plus modestes esquissent le paysage autour de ce plafond. La bordure du plateau à 458 se comporte comme un maximum local de la borne elle-même : les 13 perturbations aléatoires de bordure que nous avons essayées (5 échanges simples et 8 permutations à trois pièces, une seule graine RNG) ont toutes abaissé la borne conditionnelle, de 2 à 5,5 points. Treize essais d'une seule graine font une esquisse, pas un théorème. Et projeter la bordure du plateau communautaire à 469 arêtes dans la convention à cinq indices (superposer les cinq indices, recaser les pièces délogées) *abaisse* son plafond conditionnel à 477, un point sous la bordure de notre plateau à 458 : un indice structurel, pas une preuve, que le plafond à cinq indices pourrait se situer sous le plafond sans indices. ### Où vit l'écart Bordure fixée, la borne se décompose sur les trois types de joints : 60 joints de l'anneau de bordure (entièrement déterminés par la bordure), 56 joints bordure-intérieur et 364 joints intérieur-intérieur, pour un maximum combinatoire de $60 + 56 + 364 = 480$. Beaucoup de bordures différentes présentent le même multi-ensemble de demandes de couleurs tournées vers l'intérieur, d'où tant de valeurs LP partagées. Sur la bordure du plateau à 458, la décomposition se lit $478 = 60 + 54{,}02 + 363{,}98$. Lisez-la lentement : la part intérieur-intérieur est essentiellement *serrée*, le LP ne concède que 0,02 des 364 joints intérieurs ; toute la perte contre le maximum siège au joint bordure-intérieur. Le verdict du LP sur cette bordure : 2 de ses 56 joints tournés vers l'intérieur sont structurellement inappariables par toute complétion intérieure. Le plateau lui-même en laisse 4 non appariés, donc au plus 2 sont théoriquement réparables, un gain maximal intra-bordure de +2, vers 460. Nous avons testé cette marge une fois : une re-résolution entière exacte libérant 84 cases (le périmètre bas plus les cinq rangées intérieures basses ; 30 minutes, un solveur, une exécution) a renvoyé un delta de 0. Soit le +2 n'est pas faisable en entiers, soit il demande une fenêtre plus large. Une deuxième bordure échange dans l'autre sens : sa décomposition est $477 = 60 + 54{,}17 + 362{,}83$, un peu plus de marge bordure-intérieur mais environ 1,15 joint intérieur de moins. Aucune couleur seule ne domine l'un ou l'autre écart ; le couplage est diffus. Atteindre 480 exige les deux parts au maximum en même temps, et aucune bordure mesurée n'a les deux. Un micro-fait du design des couleurs du puzzle tombe des mêmes tables : les cinq couleurs rares (24 demi-arêtes chacune) contribuent exactement 0 à la part intérieur-intérieur, parce qu'elles n'apparaissent que sur les côtés intérieurs des pièces de bordure ; un appariement intérieur-intérieur de couleur rare est impossible par taxonomie des pièces. ### Une signature, pas un prédicteur Le plus haut plafond conditionnel de nos archives est **479**, à un de la perfection, et il repose sur un plateau qui ne marque que 457. Sa bordure est sortie d'à peine une minute de recherche locale, contre des heures derrière les bordures à 478. Pourtant huit graines de recherche locale indépendantes à une heure chacune plafonnent toutes à 457, et une re-résolution entière exacte de l'union de tous ses amas de défauts (28 cases libérées) prouve qu'aucune amélioration locale n'existe : delta 0 en 0,46 seconde. Les trois décompositions s'alignent en $478 = 60 + 54{,}02 + 363{,}98$, $477 = 60 + 54{,}17 + 362{,}83$ et $479 = 60 + 55{,}48 + 363{,}52$, et l'écart LP-entier par plateau se lit 20, 20 et 22 : quasi constant sur toutes les bordures testées (479 est aussi le plus haut plafond vu sur 18 LP conditionnels de bordures variées). La borne conditionnelle *classe* donc les bordures par structure, mais elle ne prédit pas quelle bordure donne le meilleur plateau en pièces entières ; la bordure au plafond 479 est verrouillée en entiers plus bas que celle au plafond 478. Le mécanisme est celui de la page : la marge supplémentaire est du mou de couverture fractionnaire, et un plafond plus haut signifie seulement que le registre des couleurs est *plus proche* de l'équilibrable, pas qu'un plateau entier le réalise. Une conjecture mérite d'être écrite comme telle : la bordure d'un plateau parfait doit avoir une borne conditionnelle d'exactement 480, les deux parts au maximum à la fois, et la bordure à 479 montre que le LP approche cette condition nécessaire à un près. Une dernière mise en garde sur la lecture de ces décompositions : les allocations LP par couleur ne sont **pas** des bornes par couleur. Sur le plateau à 458, le compte entier réel d'une couleur (21) dépasse le plancher de son allocation LP (20,89, qui s'arrondit à 20 par en bas). L'optimum LP est une allocation jointe entre couleurs ; lire ses lignes par couleur comme des plafonds individuels est une erreur de catégorie. L'anatomie complète sur ce plateau : total LP des joints intérieurs de 363,96 contre 346 joints réellement appariés, un écart intérieur de 17,96, dont 5,96 de mou fractionnaire et 12 dus au LP qui alloue les couleurs autrement qu'aucun plateau en pièces entières ne le peut. ## Racheter l'écart : trois tentatives mesurées La réponse des manuels à un LP lâche est de le resserrer : lever les termes bilinéaires, ajouter des plans coupants, grimper la hiérarchie des relaxations. Nous avons essayé une fois chacun et mesuré. Aucune tentative n'a fermé l'écart, et deux des échecs sont assez instructifs pour être la leçon. **Le levage de McCormick : valide en théorie, ingérable à taille réelle.** Le remède standard aux produits de variables est une variable auxiliaire par joint et par paire de placements compatibles, prise en sandwich par $z \le x_1$, $z \le x_2$ et $z \ge x_1 + x_2 - 1$. Sur de petites instances, notre implémentation reproduit la borne standard : un 6×6 demande 22 000 variables de paires et 2,5 secondes, un 8×8 à 4 couleurs 300 000 et 60 secondes. La montée en taille s'arrête aussitôt après : un 8×8 à 6 couleurs et un 10×10 à 6 couleurs (1,25 million de variables de paires) dépassent tous deux les 60 secondes sur notre solveur LP, et le puzzle complet demanderait de l'ordre de 5 à 20 millions de variables de paires à environ trois contraintes chacune, au-delà de ce que ce solveur encaisse. Les deux raccourcis évidents ont produit des bornes *invalides*, en sens opposés, et chacun se réfute par la seule arithmétique. Restreindre les variables de paires aux placements de masse LP supérieure à 0,05 sous-compte et renvoie 402, sous un plateau faisable connu à 458 ; une borne supérieure sous un point faisable est une preuve d'invalidité. Garder à la fois les variables de paires et les variables de joints d'origine double-compte et renvoie 479,58, *au-dessus* du 478 non levé ; ajouter des contraintes ne peut qu'abaisser un optimum LP, donc celui-là aussi se réfute tout seul. Le motif correct, la génération en plans coupants des inégalités de McCormick violées avec des coûts réduits exacts, exige un accès au solveur plus bas niveau que ce que nous avons construit : non essayé, pas impossible. **Des plans coupants sur la rareté des couleurs : valides ou vides, jamais les deux.** Nous avons implémenté un branch-and-cut avec une seule famille de coupes, des coupes de cliques d'offre sur le graphe de conflit des couleurs (« si un ensemble de joints est forcé à la couleur $k$, au plus $\lfloor \text{offre}_k/2 \rfloor$ d'entre eux peuvent s'apparier »), mono-thread, une seule configuration ; le verdict ci-dessous porte sur cette famille de coupes, pas sur toutes les coupes. Les LP de queue sans coupe, sur l'un de nos plateaux à 459 arêtes (arêtes correspondantes, convention à cinq indices), sont valides mais lâches de 4 à 22 % : libérer les 1, 2, 3 et 4 dernières rangées donne des bornes LP de 27, 58, 90 et 124 contre 26, 49, 74 et 104 atteints, sans jamais rien certifier. La coupe telle qu'énoncée est pire que lâche, elle est invalide : sur la queue à une rangée, elle pousse le LP à 20, *sous* le 26 faisable, donc l'inégalité a tranché l'optimum vrai (les demi-arêtes de couleur $k$ se consomment aussi hors de l'ensemble forcé, et par les trois autres côtés de chaque pièce). Toute comptabilité assez lâche pour être valide est retombée sur la borne sans coupe, vide. Le fil conducteur rejoint le reste de la page : la difficulté du puzzle est la distinction globale, chaque pièce utilisée exactement une fois, pas la rareté locale des couleurs, et les cliques du graphe de conflit des couleurs sont minuscules et peu informatives. **Un étage plus haut dans la hiérarchie : le SDP est tout aussi aveugle.** Le barreau au-dessus du LP est le levage semi-défini de niveau 1 (Shor) de la formulation quadratique, valide par construction : toute vraie solution reste faisable à la même valeur d'objectif. Nous l'avons construit exactement sur des instances 3×3 plantées aux optima certifiés de 12, 11 et 11 sur 12. Sur les deux instances non triviales, le SDP certifie 12,000 : il ne voit pas une obstruction de taille unité qu'un comptage élémentaire (5 demi-arêtes d'une couleur autorisent au plus 2 appariements) règle instantanément. Un contrôle LP McCormick valide renvoie le même 12,000, donc l'aveuglement est déjà présent au niveau linéaire ; la contrainte semi-définie positive n'ajoute rien ici. Et le coût explose immédiatement : le levage complet conscient des rotations à seulement 9 cases (324 variables, un bloc semi-défini de 325×325) a échoué trois tentatives indépendantes sous un budget mono-cœur de 280 secondes. Savoir si le levage joint aux rotations retrouverait la justesse est ouvert, pas réfuté. Ce sont des constats de calcul sur des instances minuscules avec un seul solveur SDP, pas des théorèmes. ## Ce que ça coûte - **Le LP : polynomial, authentiquement rapide.** Les méthodes de points intérieurs résolvent les programmes linéaires en temps polynomial ; sur des modèles de cette taille (50k–270k variables, de quelques milliers à quelques centaines de milliers de contraintes), les solveurs modernes terminent en quelques secondes à quelques minutes. C'est le seul objet authentiquement bon marché de la page. - **La PLNE : NP-difficile, et pas dans l'abstrait.** Le séparation-évaluation est un retour arrière avec une borne LP à chaque nœud : exponentiel dans le pire cas, et une instance [construite au pic de difficulté](/fr/research/why/phase-transition/) est conçue pour réaliser ce pire cas. La forme mesurée du coût : un solveur qui gère le 8×8 (64 pièces) ne renvoie rien sur le 16×16, car l'arbre sous la racine est élevé au carré, pas doublé. - **Le saut d'intégralité est la vraie monnaie.** Toute la valeur de la méthode est la distance entre l'optimum du LP et la meilleure solution entière. Ici cette distance est d'environ 478 contre 458-et-ça-stagne : la relaxation dépense son budget polynomial à répondre à une question sur un puzzle différent, fractionnaire. Les plans coupants existent pour réduire cet écart ; personne n'a rapporté de coupes qui en ferment ne serait-ce qu'une entaille sur l'E2, nos trois tentatives mesurées ci-dessus comprises, et la structure par joint qui simule les correspondances régénère le mou partout. - **Le séparation-évaluation élague avec la borne qu'il a.** Un nœud n'est coupé que lorsque sa borne LP tombe sous l'incumbent. Avec la borne qui flotte à ~20 arêtes au-dessus de tout ce qui est réel, presque rien n'est élagué : l'analogue exact des clauses apprises larges et inutiles dans [CDCL](/fr/research/build/exact/sat-csp-encodings/), la route d'à côté. ## À quoi le LP et le MIP servent encore La conclusion juste est une relocalisation, pas un rejet, la même que celle que la [page SAT](/fr/research/build/exact/sat-csp-encodings/) atteint pour le CDCL. - **Des bornes, énoncées avec leurs barres d'erreur.** La relaxation *est* un plafond valide, calculé en temps polynomial ; elle est simplement lâche ici. L'[entrée des impasses](/fr/research/build/dead-ends/) consigne le verdict pour que personne ne le redémontre en espérant un certificat. - **Une mise en garde : toute relaxation n'est pas une borne.** Une « relaxation » bon marché et tentante, recombler le plateau case par case avec la pièce localement la meilleure en *autorisant la réutilisation des pièces*, n'est un plafond valide d'aucune sorte : c'est une heuristique gloutonne dont le point fixe dépend du plateau de départ. Depuis l'un de nos plateaux à 457 arêtes (arêtes correspondantes, convention à cinq indices), elle converge vers 461 ; depuis un plateau à 456, vers 461 ; depuis un plateau à 440, jusqu'à 469. L'usage valide est celui d'*indicateur de marge* : quand le score glouton relâché égale le score du plateau, le plateau est prouvé maximum local strict même avec l'unicité des pièces relâchée, un certificat d'impasse plus fort que les tests par opérateurs. Sur ce plateau à 457, l'écart de +4 a été prouvé infermable par toute chaîne de permutations jusqu'à la longueur 11 (40 millions de permutations, zéro amélioration). La règle : seules les valeurs issues du LP ou du MIP sont des plafonds ; les scores gloutons relâchés sont des diagnostics. - **Des sous-problèmes d'affectation, où l'intégralité est gratuite.** Au sein des boucles de réparation, recombler $k$ trous deux à deux non adjacents est un pur problème d'affectation $k \times k$ : polytope de Birkhoff, sommets entiers, algorithme hongrois en $O(k^3)$. C'est le voisinage Eternity II de Schaus, et c'est le seul endroit de ce wiki où la machinerie de l'optimiseur tourne à pleine puissance : voir [recherche locale et ALNS](/fr/research/build/local-search/local-search-alns/). - **Des sous-problèmes entiers faciles, expédiés instantanément.** Les ensembles de rotations par MILP en quelques millisecondes ([message 9071](https://groups.io/g/eternity2/message/9071)) sont le motif : quand une sous-question a une structure traitable, un solveur MIP est le moyen fiable le plus rapide de la trancher, y compris de trancher que la réponse n'aide pas. - **L'infaisabilité comme théorème.** Une PLNE qui revient infaisable sur une région épinglée prouve la même impossibilité qu'un appel SAT UNSAT : la monnaie-certificat derrière le [mur de rigidité](/fr/research/why/rigidity-wall/). Ce projet frappe ces certificats avec le SAT, plus rapide sur cet encodage ; un solveur MIP est un second atelier de frappe légitime, et le placeur de Munjak a utilisé exactement ce signal, « identifiant un problème qui empêcherait le placement des 256 pièces » ([message 8791](https://groups.io/g/eternity2/message/8791)). - **Des formulations comme générateurs de voisinages.** La contribution durable de l'article de 2017 est méthodologique : des méthodes constructives fondées sur le MILP amorçant une recherche locale à voisinages multiples, plus de nouvelles instances de référence difficiles pour la communauté ([arXiv:1709.00252](https://arxiv.org/abs/1709.00252)). La formulation survit comme une *pièce*, à l'intérieur d'une heuristique qui s'approprie le problème d'intégralité au lieu de le relâcher. - **La formulation est l'algorithme.** Nous avons mesuré deux encodages MIP de la même tâche, recombiner un petit corpus de bons plateaux en un meilleur, et ils se comportent comme le jour et la nuit (un seul solveur, CBC, exécutions uniques). L'encodage A, « chaque case choisit un plateau source », porte des variables de joints quadratiques en la taille du corpus : correct à 4 ou 5 plateaux (optimum entier trouvé en 17 à 86 secondes), mais à 9 plateaux (environ 50 000 variables de joints et 100 000 contraintes) le solveur n'a trouvé aucune solution entière faisable en 30 minutes, et sa borne LP de 1 094, plus du double du plafond de 480, ne signifiait rien. L'encodage B, « libérer une région, une variable par case-pièce-rotation, épingler le reste », est 10 à 50 fois plus petit (environ 800 variables), se résout en moins d'une minute, et son LP est serré contre l'optimum entier : il *prouve* l'optimalité locale au lieu de deviner. Le mécanisme : les variables de l'encodage A ne portent aucun sens géométrique que le LP puisse exploiter, des mélanges fractionnaires de plateaux gagnent un crédit qu'aucun arrondi ne préserve, tandis que les variables de l'encodage B sont des placements, donc son polytope reste proche de l'enveloppe entière. L'article de 2017 qui recycle ses formulations dans des heuristiques est la même leçon vue de l'autre côté. La route de l'optimiseur, parcourue jusqu'au bout, enseigne un fait limpide sur Eternity II : le puzzle est exactement la contrainte d'intégralité. Tout ce qui est linéaire en lui, les flux, les équilibres, le squelette d'affectation, est polynomial et a été résolu dès 2009, à erreur nulle, en dix secondes. Ce qui reste, c'est l'exigence que chaque pièce soit quelque part, *entière*, une fois. Le joyeux plateau fractionnaire de la relaxation est l'image la plus nette que quiconque ait dessinée de ce à quoi ressemblent les 99 % faciles sans le 1 % difficile. ## À lire aussi - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Encodages SAT et CSP](https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/) — Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. - [All-different, le filtre par matching de Régin](https://eternity2.dev/fr/research/build/reduce/alldiff-regin/) — Aucune pièce ne peut servir deux fois : une seule contrainte all-different globale sur 256 cases. Jean-Charles Régin a montré en 1994 comment un matching biparti la filtre complètement en temps polynomial ; sa variante par couleur est le propagateur le plus puissant jamais mesuré sur l'edge matching, avec une réserve nette sur les recherches tolérantes aux erreurs. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Rendez-vous au milieu > Énumérer deux moitiés d'un problème et les recoller sur une interface partagée, en échangeant de la mémoire contre un exposant divisé par deux. L'astuce classique de Horowitz–Sahni, ce qu'elle donne sur des bandes du plateau, et ce que l'expérience BANDSAW de ce projet a mesuré, y compris la méthode unilatérale qui l'a battue. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/exact/meet-in-the-middle/ - Mise à jour: 2026-07-22 - Sujets: exact-methods - Source: Horowitz & Sahni 1974, « Computing Partitions with Applications to the Knapsack Problem » (JACM), l'origine classique — https://doi.org/10.1145/321812.321823 - Source: L'attaque par rendez-vous au milieu (Wikipédia), la branche cryptanalytique de la même idée — https://en.wikipedia.org/wiki/Meet-in-the-middle_attack - Source: Recherche bidirectionnelle (Wikipédia) — https://en.wikipedia.org/wiki/Bidirectional_search - Source: Ngo, Porat, Ré & Rudra, « Worst-case Optimal Join Algorithms » (JACM 2018), pourquoi les jointures par paires perdent sur les requêtes cycliques — https://doi.org/10.1145/3180143 - Source: Algorithme de jointure optimal au pire cas (Wikipédia, en anglais) — https://en.wikipedia.org/wiki/Worst-case_optimal_join_algorithm --- Le rendez-vous au milieu est la plus ancienne astuce de découpe d'exposant en recherche combinatoire : au lieu d'explorer un arbre de profondeur $n$, on explore deux arbres de profondeur $n/2$ et on recolle leurs feuilles sur une interface partagée. Ellis Horowitz et Sartaj Sahni l'ont introduite en 1974 pour le problème du sac à dos, transformant un temps $O(2^n)$ en un temps $O(2^{n/2})$, au prix du stockage des $2^{n/2}$ résultats d'une moitié dans une table indexée de sorte que l'autre moitié puisse les y retrouver. La même idée resurgit sous la forme de l'attaque par rendez-vous au milieu en cryptanalyse (pourquoi le double DES n'apporte presque rien de plus que le DES simple) et de la recherche bidirectionnelle en calcul de chemins. Le schéma est toujours le même : deux énumérations bon marché plus un recollement, à la place d'une seule énumération impossible. ## Ce que cela donne sur le plateau Eternity II offre une découpe naturelle : une couture horizontale. Prenons une bande de rangées à compléter ; scindons-la en une moitié haute et une moitié basse. Énumérons toutes les façons de remplir la moitié haute, indexées par deux choses : l'ensemble exact des pièces qu'elle a consommées, et le vecteur des couleurs de bord qu'elle laisse pendantes sur la couture. Énumérons la moitié basse de manière symétrique. Puis recollons : toute paire haut/bas dont les couleurs de couture s'accordent et dont les ensembles de pièces sont disjoints forme un remplissage complet, trouvé sans jamais avoir parcouru l'arbre de la bande entière. La clause de disjonction est la douleur propre à E2, et elle n'est pas optionnelle. Dans le sac à dos, les deux moitiés sont indépendantes par construction ; ici, elles puisent dans un unique pool de pièces partagé, si bien que les moitiés hautes doivent être regroupées par leur empreinte exacte de pool et chaque groupe recollé uniquement contre des moitiés basses construites à partir des pièces complémentaires. Négligez cette comptabilité et le recollement produira allègrement des plateaux fantômes qui utilisent une pièce deux fois. Établir correctement la comptabilité exacte des pools complémentaires a été une leçon de correction durement acquise dans l'expérience du projet ci-dessous. ## Le compromis Le compromis de manuel, c'est du temps contre de la mémoire : l'exposant est divisé par deux, et l'énumération d'une moitié doit être conservée dans une table de hachage. Sur le plateau, l'état d'interface est une rangée de couleurs de bord (16 cellules de large sur le puzzle complet) plus l'empreinte de pool, si bien que l'espace des clés de la table croît vite avec la largeur de la bande, et c'est la mémoire, non le temps, qui constitue en général le premier mur. Le recollement lui-même est bon marché (du hachage) ; tout tient au nombre d'entrées que chaque côté doit stocker et à la fréquence à laquelle les signatures de couture coïncident réellement. L'objection évidente est « il suffit de hacher plus finement » : réduire la clé en fusionnant les couleurs qui se comportent pareil. Une vérification de carnet tranche par la négative. Fusionner deux couleurs n'est licite que si elles sont interchangeables face à chaque couleur opposée, ce qui revient à une symétrie globale de réétiquetage des couleurs sur l'ensemble du jeu de pièces ; la vérification directe contre le fichier des pièces montre qu'aucun automorphisme de ce genre n'existe. Les 22 couleurs se répartissent en classes de fréquences inégales (5 couleurs à 24 demi-arêtes, 5 à 48, 12 à 50), et aucune paire de couleurs ne partage à la fois l'offre et la structure d'incidence. La seule relaxation licite consiste à projeter la signature de couture sur son *multiensemble* de couleurs et à s'en servir comme pré-filtre, ce qui réduit les seaux d'environ un facteur $k!$ pour une couture de longueur $k$ : un soulagement polynomial, jamais exponentiel. Les grosses clés restent grosses. ## Sentir la racine carrée Les chiffres fixent le compromis d'une manière que la prose ne peut pas. Le laboratoire ci-dessous propose deux vues. *Le compromis* place les trois factures côte à côte sur une échelle logarithmique à mesure que l'on fait croître le problème : temps unilatéral $2^n$, temps MITM $2 \cdot 2^{n/2}$, mémoire MITM $2^{n/2}$ entrées de table. *Le recollement* fait passer une micro-instance complète ($n = 10$, deux moitiés de $2^5 = 32$ candidats chacune) par la phase de stockage et la phase de sondage, pour que l'on puisse voir d'où vient la vitesse et où passe la mémoire. > **[Figure]** Interactif : le coût mémoire du rendez-vous au milieu — interactive: MitmCostLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pas à pas 1. **Faites glisser $n$ dans la vue du compromis.** Chaque $+2$ sur le curseur *quadruple* la barre rouge unilatérale mais ne fait que *doubler* les deux barres MITM. Cette différence d'un facteur deux dans le taux de croissance est toute l'astuce : l'exposant est divisé par deux, donc sur une échelle logarithmique les barres MITM montent à la moitié de la pente. 2. **Regardez la barre de mémoire arriver.** Vers $n \approx 60$, la table (à 16 octets par entrée, dans une hypothèse optimiste) dépasse une machine de 16 Gio, alors que la barre de *temps* MITM reste confortable. La mémoire frappe le mur en premier : c'est le même ordre d'événements que BANDSAW a enregistré, où les entrées réelles portent une empreinte de pool et un vecteur de couture et sont bien plus lourdes que 16 octets. 3. **Passez à la vue du recollement.** La moitié gauche énumère ses 32 candidats et stocke chacun d'eux dans une table de hachage indexée par sa signature de couture (une parmi 48). C'est la phase qui paie la facture de mémoire : le compteur sous *mémoire de la table* est la facture qui arrive, entrée par entrée. 4. **La phase de sondage.** Les 32 candidats de la moitié droite arrivent un par tick, et chacun effectue exactement une consultation. Un seau vide écarte toute une famille de combinaisons en une seule étape ; un seau occupé fournit une solution recollée par partenaire stocké, trouvée sans parcourir l'arbre entier. 5. **Lisez le décompte final.** $2 \cdot 32 = 64$ étapes d'énumération plus $32$ entrées stockées remplacent $2^{10} = 1{,}024$ parcours complets. Sur Eternity II, la même arithmétique tient, à ceci près qu'un recollement ne compte que si les couleurs de couture s'accordent *et* si les pools de pièces sont disjoints, ce à quoi sert la comptabilité par regroupement selon l'empreinte évoquée plus haut. ## Ce que cela coûte La comptabilité classique de Horowitz–Sahni, pour un problème à $n$ choix binaires : $$ \underbrace{O(2^n)\ \text{time},\ O(n)\ \text{space}}_{\text{one-sided enumeration}} \quad\longrightarrow\quad \underbrace{O(2^{n/2})\ \text{time},\ O(2^{n/2})\ \text{space}}_{\text{meet in the middle}} $$ (plus un facteur $\log$ si les moitiés sont triées plutôt que hachées). Notons ce qui est conservé : le *produit* du temps et de l'espace reste de l'ordre de $2^n$. Le rendez-vous au milieu ne détruit jamais l'exponentielle ; il scinde une facture impayable en deux plus petites, et toutes deux doivent être soldées. La racine carrée du temps d'exécution s'achète par une facture de mémoire exponentielle, raison pour laquelle la méthode l'emporte exactement quand $2^{n/2}$ entrées tiennent encore en RAM et perd dès l'instant où elles n'y tiennent plus. Sur Eternity II, le modèle propre à $n$ choix demande deux corrections. Premièrement, l'interface n'est pas un seul nombre mais un état large (un vecteur de couture pouvant aller jusqu'à 16 couleurs de bord plus l'empreinte exacte du pool de pièces), si bien que les clés de la table sont grosses, les entrées lourdes, et le mur de mémoire arrive bien avant le point de bascule du manuel. Deuxièmement, les moitiés sont couplées par le pool de pièces partagé, si bien que le recollement n'est pas un simple accès de hachage gratuit mais un accès de hachage *filtré par pools complémentaires*. BANDSAW en a mesuré la conséquence : à l'intérieur de petits budgets de discordance, les deux côtés restent énumérables et la méthode est exacte, mais chaque unité de budget supplémentaire gonfle les deux arbres d'environ un facteur vingt, et près de l'horizon, le projet a payé pour des millions de moitiés hautes stockées dont aucune moitié basse n'a jamais sondé le seau avec succès. ## Une formule de coût pour les moitiés Le couplage peut être chiffré, pas seulement évoqué. Un calcul de carnet donne le nombre attendu de remplissages valides d'une région d'aire $a$ et d'interface de longueur $k$ (pour des régions ne touchant aucun bord du plateau) : $$ T(a,k)\;=\;\frac{256!}{(256-a)!}\cdot 4^a\cdot p^{\,2a-k/2}, $$ où $p = 0{,}048177$ est la probabilité que deux demi-arêtes tirées au hasard partagent une couleur sous la distribution réelle des fréquences de couleurs : environ 6 % au-dessus du naïf $1/22 \approx 0{,}0455$, une inflation que les fréquences inégales imposent par Cauchy–Schwarz. La factorielle décroissante compte les choix ordonnés de pièces, $4^a$ les rotations, et l'exposant $2a - k/2$ est exact : une identité de double comptage donne à toute région sans bord d'aire $a$ et de périmètre $k$ exactement $2a - k/2$ arêtes intérieures, chacune facturée comme une concordance indépendante. La formule a été validée contre des comptages exhaustifs sur des instances plantées de 10×10 à 12×12 : exacte (ratio 1,000) quand la région n'a aucune arête intérieure, à 3 à 20 % près pour une ou deux arêtes intérieures, et l'erreur diminue quand le nombre de couleurs augmente (ratio 0,806 à 6 couleurs, remontant à 1,010 à 22), la direction que prédit l'épuisement d'un pool fini. Les régions à quatre arêtes intérieures ou plus dépassent déjà la vérification par force brute même sur un jouet 12×12 ; le compte prédit pour une région de 9 cellules est d'environ $6 \times 10^{11}$. La validation à petite échelle est donc une mesure, tandis que l'extrapolation de la formule aux grandes régions relève d'un modèle, et tout ce qui suit doit se lire avec cette étiquette. ## Pourquoi aucune taille de découpe ne gagne Donnons à la formule l'optimisation complète : choisir l'aire de région $a$, lui accorder le périmètre minimal atteignable (une borne classique sur les polyominos, due à Harary et Harborth en 1976, donne $k_{\min} = 2\lceil 2\sqrt{a}\rceil$), et minimiser la facture totale de la taille de table plus la sortie du recollement. Le balayage ne trouve aucun point d'équilibre intérieur : le coût croît de façon monotone avec l'aire de la région, le coût en $\log_{10}$ passant de 3,0 à $a=1$ à 16,4 à $a=16$, 48,7 à $a=64$, 61,5 à $a=128$. L'optimum est la « région » dégénérée d'une seule cellule, c'est-à-dire la propagation de contraintes ordinaire, cellule par cellule. Le mécanisme mérite d'être énoncé sans détour. Le rendez-vous au milieu classique gagne parce que les deux moitiés énumèrent des univers *indépendants* dont le produit reconstitue l'espace complet au coût de la racine carrée de chaque côté. Ici, les deux moitiés puisent dans un unique pool partagé de 256 pièces sous une contrainte globale de disjonction : la base combinatoire est une factorielle décroissante dont le coût marginal par cellule *augmente* avec l'aire, les deux côtés paient la facture super-linéaire simultanément, et l'économie en racine carrée ne se matérialise jamais. C'est ce que dit le calcul, validé sur de petits plateaux plantés ; c'est un verdict calculé sur un modèle, non une mesure à la taille du plateau complet. Une esquive tentante échoue elle aussi. Ancrer la région dans un coin, pour que deux de ses côtés soient du bord libre du plateau, ressemble à du périmètre gratuit ; c'est l'inverse. Une cellule qui touche le bord est une contrainte dure supplémentaire, pas un cadeau : seules les pièces portant physiquement la couleur du bord y sont éligibles, un pool restreint d'au plus 60 des 256 pièces (4 pièces de coin plus 56 pièces de bord). Le recomptage avec les classes restreintes, vérifié par comptage direct contre le fichier des pièces, facture les régions ancrées dans un coin strictement plus cher que ne le suggère le modèle naïf. Le bord rétrécit le pool éligible plus vite qu'il ne supprime de contraintes de concordance. ## Et quatre quadrants ? Si deux moitiés échouent, le réflexe suivant est quatre quadrants 8×8. C'est pire encore, et la raison rejoint un joli coin de la théorie des bases de données. Quatre quadrants forment une jointure en 4-cycle : chacun partage une interface de 8 arêtes avec deux voisins, le cadre de manuel où la théorie des jointures optimales au pire cas montre que tout plan qui matérialise d'abord une jointure par paires est dominé. Le même calcul de carnet facture un plan à quadrants matérialisés à environ $10^{80}$ lignes intermédiaires contre environ $10^{62}$ pour la simple découpe en deux sur la même aire, parce que le produit par paires enfle avant que les contraintes croisées des deux autres quadrants ne puissent l'élaguer, et aucun ordre de jointure ne peut le sauver (là encore, un chiffre de modèle à ces échelles). La seule façon d'atteindre la taille de sortie théoriquement optimale est un algorithme de jointure optimal au pire cas, qui intersecte simultanément toutes les contraintes portant sur chaque variable. Sur une grille bidimensionnelle, c'est exactement ce que fait déjà le retour sur trace ordinaire avec propagation de contraintes, cellule par cellule. Le rendez-vous au milieu à plusieurs voies retombe dans la recherche unilatérale qu'il était censé battre. ## Ce que BANDSAW a mesuré Ce projet a mené l'idée jusqu'au bout, rigoureusement, dans l'[expérience BANDSAW](/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) : complétion optimale exacte d'une bande, recollement par rendez-vous au milieu avec comptabilité exacte des pools, approfondissement itératif sur le budget de discordance, le tout validé sur un banc d'essai 10×10 contre la force brute. Trois constats, mesurés sur le moteur de ce projet et non répliqués de manière indépendante : - **Ça marche, mais à la quasi-perfection seulement.** À l'intérieur de petits budgets de discordance, la méthode est exacte et abordable. Mais chaque unité de budget de discordance gonfle les arbres d'énumération d'environ un facteur vingt, si bien que le régime où l'exactitude reste payable se dissout au bout d'une poignée de défauts autorisés. - **Une méthode unilatérale l'a battue.** Armé des mêmes tables de bornes inférieures exactes (bornes de suffixe min-plus calculées colonne par colonne), un simple branch-and-bound à approfondissement itératif a prouvé l'optimalité en une douzaine de secondes sur un barreau où le recollement bidirectionnel n'a pas terminé. Le MITM paie l'énumération complète des *deux* moitiés même lorsqu'un unique optimum accompagné d'une preuve d'épuisement suffirait ; près de l'horizon de décidabilité, son recollement ne s'est presque jamais déclenché : des millions de moitiés hautes stockées, zéro moitié basse concordante, les deux factures payées pour rien. - **Les sorties durables ont été les bornes.** Ce qui a survécu à l'expérience, ce n'est pas le recollement mais les tables de bornes inférieures admissibles et les certificats de budget exacts qu'elles permettent, des instruments désormais utilisés ailleurs. La conclusion consignée était sans détour : aucun déploiement du rendez-vous au milieu à la taille du plateau complet. ## Les coutures apparaissent même dans les constructions unilatérales Une mesure de carnet plus tardive offre à l'histoire de la couture une coda inattendue : l'interface porte la difficulté même quand personne ne recolle rien. Sur des plateaux solides construits en deux phases (les rangées du haut remplies de gauche à droite, puis les rangées restantes remplies en colonnes verticales), les discordances se concentrent presque entièrement sur la couture horizontale où les deux régimes de remplissage se rencontrent. Sur le meilleur de ces plateaux, en comptant les arêtes concordantes sur 480 avec les cinq pièces indices officielles en place, 13 des 23 ruptures totales se trouvaient dans la seule première rangée de la région remplie en colonnes ; deux plateaux frères à 456 sur 480 (24 ruptures chacun) montraient la même concentration en bande. C'est une observation sur un seul pipeline, trois plateaux d'une même famille de producteurs, mais le mécanisme se lit clairement : chaque phase optimise localement son propre front et repousse la dette vers l'interface entre les deux, le phénomène même que cette page décrit pour les recollements bilatéraux, resurgissant à l'intérieur d'un constructeur unilatéral. La même étude a livré un diagnostic bon marché pour savoir où les méthodes exactes paient. Résoudre exactement une région gelée de 32 cellules du plateau à 457 arêtes (le reste du plateau épinglé, les pièces indices épinglées) a *prouvé* la région déjà optimale en 21 secondes, et un balayage de re-résolution sur 9 graines a rendu des résultats identiques avec une variance nulle : zéro marge, rien à gagner. Libérer à la place une bande de 48 cellules qui enjambe la couture est revenu faisable mais non prouvé optimal, et re-résoudre avec des graines différentes échantillonnait des incumbents différents ; sur un balayage de 40 graines, un tirage a amélioré le plateau de 2 arêtes concordantes, à 459 sur 480 sous la même convention, vérifié indépendamment de trois façons, en environ 200 secondes. Élargir la bande libérée à 64 cellules dépassait la cible : dans le même budget, le meilleur incumbent du solveur atterrissait sous le score de départ, à 455. (Ce 459 égalait le meilleur score du carnet avec ce pipeline à l'époque ; pour situer de tels scores face aux résultats communautaires obtenus avec des budgets de calcul bien plus grands, voir la [page des records](/fr/research/records/).) Le levier caché là-dedans : quand le solveur exact ferme l'écart d'optimalité, la région est serrée et aucune méthode n'aidera ; quand il n'y parvient pas, son incumbent est en pratique un tirage de loterie et re-tirer est le coup à jouer. « Le solveur a-t-il prouvé l'optimalité ? » est une carte gratuite des marges restantes. ## Limites, et ce qui reste ouvert La leçon générale rejoint la littérature classique : le rendez-vous au milieu l'emporte quand l'interface est étroite, quand les moitiés sont véritablement indépendantes, et quand une réponse résolu/non résolu suffit. Eternity II met ces trois conditions à rude épreuve : la couture porte un large vecteur de couleurs, le pool de pièces partagé couple les moitiés, et la partie record se joue au crédit partiel, ce qui regonfle les deux arbres. Le cousin *heuristique* a lui aussi été essayé désormais, et le recollement ne s'est jamais déclenché. Le design du carnet (un faisceau de plateaux partiels croissant vers le bas depuis les rangées du haut, un second faisceau croissant vers le haut depuis les rangées du bas, les paires recollées sur une rangée médiane) a été exécuté en deux variantes. Avec des faisceaux indépendants à la largeur 32, 0 des 1 024 paires candidates étaient valides : les deux faisceaux gravitent vers les mêmes pièces prometteuses, si bien que l'exigence de disjonction des pièces échoue presque toujours. Avec des faisceaux dépendants (pour chaque état du haut, relancer le faisceau du bas restreint aux pièces inutilisées, à environ 8 fois le calcul), la disjonction est garantie par construction, et pourtant zéro plateau complet n'est apparu : l'interface de 16 couleurs à la rangée de rencontre ne concorde pratiquement jamais exactement. Elle se comporte comme une contrainte de couplage biparti complet à la rangée de rencontre, le même mur qui arrête la recherche unilatérale rangée par rangée, simplement déplacé sur la couture. La portée de ce négatif compte. Il couvre une seule famille de configurations : deux variantes, un seul design de rangée de rencontre, des largeurs de faisceau jusqu'à environ 300, et une interface exacte (les 16 arêtes doivent toutes concorder). Une interface *souple*, qui tolère quelques discordances sur la couture et les répare ensuite, a été conçue mais jamais exécutée, et une couture verticale (en colonne) n'a jamais été essayée. L'état mesuré est donc celui-ci : le faisceau bidirectionnel à interface exacte échoue aux largeurs praticables, et le cousin à interface souple est la partie encore ouverte. ## À lire aussi - [BANDSAW](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Résoudre exactement une bande de rangées en se rejoignant au milieu, pour trouver la vraie meilleure fin et mesurer jusqu'où décider une fin de partie. - [CLOISTER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fixer une bordure parfaite, puis explorer l'intérieur en traitant les arêtes de la bordure comme des contraintes dures dès la toute première case. - [Couverture exacte et liens dansants](https://eternity2.dev/fr/research/build/exact/exact-cover-dlx/) — Eternity II se formule proprement comme un problème de couverture exacte, et l'algorithme X de Knuth muni des liens dansants en est la machine classique. Là où il brille vraiment (petits plateaux, dénombrement exhaustif) et les deux raisons pour lesquelles il ne vient pas à bout du 16×16 : un arbre de recherche jamais réduit, et aucun crédit partiel. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Encodages SAT et CSP > Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/ - Mise à jour: 2026-07-02 - Sujets: exact-methods - Source: Heule, Solving edge-matching problems with satisfiability solvers (2008) — https://www.cs.cmu.edu/~mheule/publications/eternity.pdf - Source: Ansótegui, Béjar, Fernàndez & Mateu, Edge Matching Puzzles as Hard SAT/CSP Benchmarks (CP 2008) — https://link.springer.com/chapter/10.1007/978-3-540-85958-1_39 - Source: Ansótegui, Béjar, Fernàndez & Mateu, On the hardness of solving edge matching puzzles as SAT or CSP problems (Constraints, Springer) — https://link.springer.com/article/10.1007/s10601-012-9128-9 - Source: Ansótegui, Béjar, Fernàndez & Mateu, How Hard is a Commercial Puzzle: the Eternity II Challenge (CCIA 2008) — https://repositori.udl.cat/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/download --- Les solveurs SAT modernes tranchent des problèmes industriels comptant des millions de variables ; le geste évident est donc d'écrire Eternity II sous forme de clauses et de laisser CDCL creuser. C'est exactement ce que l'on tente depuis 2008. Les encodages sont propres et les petites tailles tombent instantanément ; le puzzle complet, lui, ne bronche pas. Comprendre pourquoi, c'est apprendre ce dont se nourrit réellement la recherche pilotée par les conflits. ## L'encodage L'encodage direct introduit une variable $x_{c,p,r}$ pour « la pièce $p$ occupe la case $c$ avec la rotation $r$ », puis trois familles de contraintes : chaque case reçoit exactement un placement, chaque pièce est utilisée au plus une fois, et deux placements en désaccord le long d'une arête commune s'excluent mutuellement. Le même modèle se lit naturellement comme un CSP : une variable par case, les placements comme valeurs du domaine, un *alldifferent* sur les pièces, et des contraintes de table sur les cases adjacentes. C'est cette formulation que les articles de référence étudient aux côtés de la forme clausale. La forme clausale directe explose rapidement, car les clauses de désaccord d'arête, prises deux à deux, se multiplient. L' [article de 2008](https://www.cs.cmu.edu/~mheule/publications/eternity.pdf) de Marijn Heule a montré le remède standard : introduire des variables auxiliaires pour la couleur affichée sur chaque couture interne, de sorte qu'un placement implique ses quatre couleurs de couture et que le désaccord soit exclu une fois par couture plutôt qu'une fois par paire. Avec des encodages compacts, un bris de symétrie et un réglage fin du solveur, Heule a résolu des instances d'assemblage d'arêtes bien au-delà de ce qu'atteignait l'encodage naïf. Malgré tout, les CNF du puzzle complet 16×16 bâties par la communauté atteignent environ cent mille variables et des centaines de millions de clauses (comme rapporté sur la [liste de diffusion communautaire](https://groups.io/g/eternity2)). Elles se chargent sans problème, et restent totalement non résolues. ## Prendre-en la mesure Des nombres à quatorze chiffres cessent de signifier quoi que ce soit dans un texte ; mieux vaut donc les mesurer. L'explorateur ci-dessous calcule les deux encodages en direct à partir de la dérivation ci-dessus. Faites glisser la taille du plateau depuis le plafond du SAT pur de la communauté, à 10×10, jusqu'au 16×16 complet, et observez les barres en échelle logarithmique. En dessous, une instance à six clauses montre l'autre moitié de l'histoire : la cascade de propagation unitaire dont se nourrit l'apprentissage de clauses de CDCL, et que ce puzzle affame. > **[Figure]** Interactif : explosion de la taille des encodages SAT/CSP — interactive: EncodingSizeLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pas à pas Dérivez les tailles une fois à la main ; elles cessent d'être du folklore. 1. **Variables de placement.** $p = n^2$ pièces, $4$ rotations, $n^2$ cases : $x_{c,p,r}$ donne $n^2 \cdot p \cdot 4 = 4n^4$ variables. À $n = 16$, cela fait $262{,}144$ placements bruts ; élaguer les impossibles (les pièces de bord ne siègent que sur le pourtour, les coins uniquement dans les coins) ramène ce nombre aux « environ cent mille variables » que portent réellement les CNF communautaires. 2. **Contraintes de case et de pièce.** Chaque case reçoit exactement un placement : une longue clause plus, deux à deux, $\binom{4n^2}{2}$ exclusions par case. Chaque pièce est utilisée au plus une fois : encore $\binom{4n^2}{2}$ par pièce. Le « au plus un » par paires est quadratique ; c'est ce que les encodages compacts (séquentiel, commander) réduisent à $O(4n^2)$ clauses chacun, au prix de variables auxiliaires. 3. **Les clauses de conflit directes : l'explosion.** Le plateau compte $2n(n-1)$ coutures internes. Pour chaque couture, chaque paire de placements en désaccord reçoit une clause binaire : environ $(4n^2)^2 (1 - 1/c)$ paires par couture si les couleurs étaient uniformes. À $n = 16$, $c = 17$ : $480 \times 1024^2 \times \tfrac{16}{17} \approx 4.7 \times 10^8$ clauses, les « centaines de millions » rapportées pour les CNF du plateau complet, retrouvées à partir des premiers principes. 4. **L'astuce de couture de Heule.** Nommer la couleur de chaque couture : $2n(n-1) \cdot c$ variables auxiliaires ($8{,}160$ à taille pleine). Désormais chaque placement *implique* ses quatre couleurs de couture (au plus $16n^4$ clauses binaires) et le désaccord est interdit une fois par couture, non une fois par paire : $\binom{c}{2}$ clauses par couture, soit environ $65{,}000$ au total. La machinerie des conflits s'effondre de trois ordres de grandeur. C'est précisément pourquoi les instances de Heule ont atteint des tailles que l'encodage naïf n'a jamais effleurées, et pourquoi le plafond reste proche de 10×10 plutôt que de 16×16 : la taille n'a jamais été le seul problème. ## Ce que cela coûte - **Le solveur, dans le pire des cas : exponentiel.** SAT est NP-complet, et CDCL est une procédure fondée sur la résolution : sur les familles à borne inférieure de résolution exponentielle, *aucune* de ses exécutions ne peut être sous-exponentielle. Son succès industriel dit quelque chose de la structure typique, pas du coût dans le pire cas, et une instance construite au pic de difficulté est aussi éloignée du typique qu'il est possible de l'être. - **Propagation unitaire : bon marché par conception.** Avec deux littéraux surveillés par clause, une clause n'est examinée que lorsque l'un de ses deux témoins est falsifié, et chaque visite coûte $O(\text{longueur de clause})$ pour trouver un nouveau témoin. La propagation explique comment CDCL peut se permettre des millions de décisions par seconde même sur d'énormes CNF ; charger Eternity II n'a jamais été le problème. - **Analyse de conflit : payer proportionnellement au graphe d'implication.** Chaque conflit est analysé en remontant le graphe d'implication jusqu'à une coupe (premier-UIP), au coût d'un temps linéaire dans le graphe parcouru, et produit une clause apprise dont le pouvoir d'élagage dépend de sa *brièveté*. C'est l'étape que ce puzzle affame : des chaînes d'implication plates rendent le parcours trivial et la clause apprise large. Plein tarif, aucun produit. - **Le côté CSP a la même forme.** Imposer la [cohérence d'arc](/fr/research/build/reduce/arc-consistency/) sur les contraintes de table est polynomial par nœud, et le filtre GAC *alldifferent* de Régin exécute un couplage biparti en $O(m\sqrt{n})$ par appel (voir la [page alldifferent](/fr/research/build/reduce/alldiff-regin/)). Une propagation polynomiale posée sur un arbre de recherche exponentiel : puissante localement, impuissante globalement. - **Là où le bilan s'équilibre.** Sur le plateau complet, le comportement du pire cas est le comportement observé. Sur des sous-problèmes épinglés, la même machinerie renvoie UNSAT en moins de deux secondes : un théorème d'impossibilité par requête, au prix d'une consultation de base de données. Les coûts n'ont pas changé ; la question, si. ## Ce qu'ont montré les benchmarks publiés L'étude systématique revient à Ansótegui, Béjar, Fernàndez et Mateu, dans un [article de CP 2008](https://link.springer.com/chapter/10.1007/978-3-540-85958-1_39) et une [version journal étendue dans Constraints](https://link.springer.com/article/10.1007/s10601-012-9128-9), accompagnés d'un article demandant, mot pour mot, [à quel point le puzzle commercial est réellement difficile](https://repositori.udl.cat/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/download). Leur conclusion phare : les puzzles d'assemblage d'arêtes généralisés font d'excellents benchmarks SAT/CSP précisément parce que la difficulté est ajustable : en variant le nombre de couleurs, le temps de résolution monte jusqu'à un pic aigu où les solutions sont rares mais réelles. Les décomptes de couleurs d'Eternity II se situent à ce pic, par conception ; la [page sur la transition de phase](/fr/research/why/phase-transition/) le détaille. En pratique, les solveurs complets expédient les petits plateaux en quelques secondes puis heurtent une falaise exponentielle ; les expériences communautaires menées au fil des ans placent le plafond pratique du SAT pur sur les instances de style Eternity autour de l'échelle 10×10, bien en deçà du 16×16. Voir la [page des articles](/fr/research/papers/) pour le fil complet de la littérature. ## Pourquoi CDCL s'enlise sur le plateau complet CDCL tire sa puissance de l'apprentissage de clauses : lorsque la propagation rencontre un conflit, le solveur remonte le graphe d'implication jusqu'à un petit ensemble de décisions qui l'ont causé, et enregistre cette combinaison comme interdite. La clause apprise est courte et générale lorsque les conflits naissent de longues chaînes de propagation unitaire. Eternity II affame ce mécanisme. L'analyse par ce projet de son propre moteur CSP (nuancée en conséquence : mesurée ici, non répliquée de façon indépendante) a révélé une structure d'implication quasi plate (une suppression de domaine remonte à un unique placement voisin, non à une chaîne profonde), de sorte que l'analyse de conflit n'a presque rien à comprimer, et les [no-goods](/fr/research/build/reduce/nogood-learning/) appris ressortent larges et spécifiques au lieu d'être courts et généraux. Pire, les conflits surgissent tard : avec une propagation forte à l'œuvre, les vidages de domaine ne se produisent pratiquement jamais avant la profondeur 50, la médiane se situant profondément dans le plateau. Une clause large portant sur une configuration profonde et spécifique n'élague presque rien d'autre. Ajoutez une instance délibérément réglée sur le pic de difficulté, et le puzzle complet est proche d'un pire cas pour la recherche pilotée par les conflits. ## Où les verdicts exacts paient encore Rien de tout cela ne rend les encodages inutiles ; cela les relocalise. La réponse UNSAT d'un solveur complet est un théorème, et sur des sous-problèmes ces théorèmes s'obtiennent à bas prix. L'usage le plus productif du SAT dans ce projet (même nuance que ci-dessus) est celui d'un *oracle sur des régions* : épingler la majeure partie d'un plateau fort, libérer un voisinage de ses désaccords restants, et demander une complétion entièrement assortie. La réponse revient UNSAT, généralement en moins de deux secondes, et prouve qu'aucun réarrangement local de cette région ne peut jamais terminer le plateau, ce qui est la machinerie derrière le [mur de rigidité](/fr/research/why/rigidity-wall/). La même astuce filtre des anneaux de bord entiers : épingler un bord candidat, libérer les 191 cases intérieures, et un UNSAT en moins d'une seconde certifie que ce bord ne pourra jamais porter un intérieur parfait. Et au sein d'un moteur de recherche CSP, la même idée en miniature (enregistrer des no-goods durs aux échecs de propagation pour ne jamais réemprunter une impasse structurelle) est correcte par construction et bon marché à vérifier avec des littéraux surveillés à la manière de SAT. Voilà la division du travail : comme solveur frontal du puzzle complet, CDCL est dépassé ; comme générateur rapide de certificats d'impossibilité pour des morceaux de celui-ci, rien d'autre ne s'en approche. ## À lire aussi - [MOSAIC](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/mosaic/) — Découper le plateau en petits blocs, résoudre chacun jusqu'à l'optimum prouvé, puis les recoller en payant les coutures au lieu de les interdire. En partant de zéro, sans record à recopier, la méthode atteint 448. - [Articles](https://eternity2.dev/fr/research/papers/) — La littérature académique sur Eternity II et les casse-têtes à raccordement d'arêtes, tirée des notes de recherche du projet et de la liste de lectures de la communauté, classée selon l'utilité réelle de chaque article lorsqu'on cherche à écrire un solveur. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. --- # Aller plus vite > Le débit brut : l'artisanat sous l'algorithme (tables de correspondance, structures dimensionnées pour le cache, code généré) et la répartition du travail sur de nombreuses machines. C'est ce qui décide si un nœud coûte 26 cycles ou 2 600, et c'est la démonstration la plus nette que la vitesse seule ne déplace pas le mur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/faster/ - Mise à jour: 2026-07-13 --- Le débit brut : l'artisanat sous l'algorithme (tables de correspondance, structures dimensionnées pour le cache, code généré) et la répartition du travail sur de nombreuses machines. C'est ce qui décide si un nœud coûte 26 cycles ou 2 600, et c'est la démonstration la plus nette que la vitesse seule ne déplace pas le mur. Les pages ci-dessous procèdent technique par technique : ce qu'est chacune en une ligne, ce qu'elle a réellement atteint sur le vrai plateau 16×16, où elle s'arrête, et les expériences et mesures qui l'étayent. Pour embrasser tout le territoire d'un coup, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). Deux points d'entrée si vous voulez l'argument de bout en bout. [L'ingénierie des solveurs](/fr/research/build/faster/solver-engineering/) est le registre sur vingt ans de la communauté - chaque technique d'artisanat, ce qu'elle a coûté, ce qu'elle a rapporté - et il fixe les trois choses différentes qu'on appelle « rapide » pour que les nombres cessent de glisser. Pour une démonstration concrète de première main, l'[expérience du backtracker JIT](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) porte du Rust portable, échelon par échelon, jusqu'à la vitesse du C le plus optimisé à la main de la communauté - à égalité sur les plateaux difficiles et réalistes - puis montre pourquoi même cela [ne déplace pas le mur](/fr/research/lab/experiments/raphael-anjou/going-fast/). ## Pages de cette section - [Ingénierie de solveur : l'artisanat sous l'algorithme](https://eternity2.dev/fr/research/build/faster/solver-engineering/) — Tous les solveurs record exécutent le même backtracking en profondeur d'abord. Ce qui les distingue, c'est la couche en dessous : tables de correspondance, hachages parfaits, structs taillées pour le cache, code généré, archéologie du compilateur. C'est cet artisanat qui décide si un nœud coûte 26 cycles ou 2 600. Vingt ans de registre d'ingénierie de la communauté, technique par technique, et ce que tout cela a rapporté. - [Résoudre en réparti : essaims, syndicats et fermes de cœurs](https://eternity2.dev/fr/research/build/faster/distributed-solving/) — Tous les quelques années, la communauté a jeté davantage d'ordinateurs sur Eternity II : économiseurs d'écran BOINC, syndicats à partage de prix, grappes de PlayStation, fermes de cartes uniques récupérées. Ce que 10^19 opérations ont acheté, comment un parcours en profondeur d'abord se partitionne réellement, et la seule tâche pour laquelle la répartition s'est révélée douée. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. --- # Résoudre en réparti : essaims, syndicats et fermes de cœurs > Tous les quelques années, la communauté a jeté davantage d'ordinateurs sur Eternity II : économiseurs d'écran BOINC, syndicats à partage de prix, grappes de PlayStation, fermes de cartes uniques récupérées. Ce que 10^19 opérations ont acheté, comment un parcours en profondeur d'abord se partitionne réellement, et la seule tâche pour laquelle la répartition s'est révélée douée. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/faster/distributed-solving/ - Mise à jour: 2026-07-02 - Sujets: speed, backtracking - Source: eternity2.net se lance sur BOINC, et les sceptiques répondent (groups.io message 756) — https://groups.io/g/eternity2/message/756 - Source: Le bilan de fermeture : 1,6 TFlops, plus de 10^19 opérations, milieu des 460 (groups.io message 3511) — https://groups.io/g/eternity2/message/3511 - Source: Le Eternity 2 Syndicate : parts de prix proportionnelles aux placements (groups.io message 3021) — https://groups.io/g/eternity2/message/3021 - Source: Verhaard publie eii avec un partage de prix 50-50 (groups.io message 5940) — https://groups.io/g/eternity2/message/5940 - Source: La grappe de François Galea et ses PlayStation 3 (groups.io message 6918) — https://groups.io/g/eternity2/message/6918 - Source: La liste des rangées supérieures du 10×10 : 4 318 956 rangées à réserver (groups.io message 9164) — https://groups.io/g/eternity2/message/9164 - Source: La ferme de rangées à 400+ cœurs de McGavin résout le 10×10 (groups.io message 9688) — https://groups.io/g/eternity2/message/9688 - Source: Le 469 : quelques jours sur environ deux cents cœurs (groups.io message 10045) — https://groups.io/g/eternity2/message/10045 - Source: Le wrapper_blackwood de Jef Bucas, un serveur de tâches pour études paramétriques — https://github.com/jfbucas/wrapper_blackwood --- L'idée est arrivée avant le casse-tête lui-même. En mai 2007, deux mois avant la mise en vente d'Eternity II, la liste de diffusion évoquait un effort communautaire à la manière de SETI@home, et la réponse de Brendan Owen fut le premier énoncé clair de la thèse que les quinze années suivantes n'ont cessé de confirmer : il existe des jeux de pièces qui « seront impossibles avec les algorithmes de retour arrière actuels », quel que soit le nombre de machines enrôlées ([groups.io message 222](https://groups.io/g/eternity2/message/222), [message 226](https://groups.io/g/eternity2/message/226)). La communauté a tout de même construit les projets répartis, plus d'une fois et sous deux formes distinctes. Toutes deux méritent qu'on les comprenne, car l'une d'elles s'est révélée réellement utile. L'histoire sociale (l'essor et le déclin d'eternity2.net, les querelles de concours qui l'entouraient) se trouve dans [les pages d'histoire](/fr/research/community/hunt/) ; cette page est la vue systèmes. ## Essaims de bénévoles La première forme, c'est la foule : des inconnus téléchargent un client, donnent des cycles, et se partagent tout prix par contrat. **eternity2.net** était le fer de lance. Dave Clark, auteur d'un solveur réparti pour Eternity I, l'a lancé sur l'infrastructure BOINC de Berkeley le mois même où le casse-tête est sorti, en juillet 2007 ([message 756](https://groups.io/g/eternity2/message/756)). Les sceptiques affirmaient dès le lancement que, sans avancée algorithmique, même 100 000 machines n'avaient pour ainsi dire aucune chance ([message 763](https://groups.io/g/eternity2/message/763)) ; la foule est venue quand même. En six semaines, le projet comptait plus de 1 300 membres inscrits ; 160 d'entre eux se trouvaient aux États-Unis, où le casse-tête n'était pas encore sorti ([message 2122](https://groups.io/g/eternity2/message/2122), [message 2132](https://groups.io/g/eternity2/message/2132)). Le projet a soumis à Tomy une partielle à 462 arêtes, puis une 463 ([message 2663](https://groups.io/g/eternity2/message/2663)), le nombre qui a servi de plafond public à la communauté pendant plus d'un an. Cinq mois après le lancement, Clark l'a fermé et a publié le bilan : plus de 1,6 TFlops de puissance de calcul cumulée, plus de 10¹⁹ opérations processeur, meilleurs scores « dans le milieu des 460 environ », et son propre verdict qu'une solution par force brute « allait toujours de toute évidence être impossible » ([message 3511](https://groups.io/g/eternity2/message/3511)). Il a ouvert le code source de son solveur de recherche en partant ([message 3716](https://groups.io/g/eternity2/message/3716)), et ses formats de fichiers sont devenus le standard d'échange de la communauté. **Le Eternity 2 Syndicate** y a ajouté le juridique. Lancé en octobre 2007 à eternity2syndicate.co.uk, ses membres faisaient tourner un backtracker rapide sur un espace de recherche partitionné (la même architecture qu'eternity2.net) mais avec un contrat explicite : l'argent du prix partagé proportionnellement aux placements apportés. En une semaine, il annonçait ~20 machines à une moyenne de 300 millions de placements par seconde ; bientôt 40 membres faisaient tourner 50 instances de solveur, avec des statistiques de progression réservées aux membres ([message 3021](https://groups.io/g/eternity2/message/3021), [message 3078](https://groups.io/g/eternity2/message/3078), [message 3105](https://groups.io/g/eternity2/message/3105)). Un site français de résolution répartie tournait en parallèle ; Clark a salué la « concurrence » ([message 1254](https://groups.io/g/eternity2/message/1254)). En mai 2008 est venue la version à micro-échelle : le « E2@home » d'e2dude, une seule personne revendiquant des scores supérieurs à 460 par semaine et par PC et recrutant des bénévoles pour une part du prix mineur de 10 000 $ ([message 5474](https://groups.io/g/eternity2/message/5474)). Aucun de ces essaims n'a battu de record. La seule campagne de bénévoles à avoir gagné de l'argent a inversé la recette : au lieu d'un client faible sur de nombreuses machines, Louis Verhaard a publié le *solveur le plus puissant qui existât*, eii, pour que quiconque puisse le faire tourner, avec le prix partagé 50-50 entre lui et l'utilisateur au meilleur score ([message 5940](https://groups.io/g/eternity2/message/5940)). Les machines de la communauté ont trouvé son 467 plus de quarante fois ([message 6275](https://groups.io/g/eternity2/message/6275)), et il a remporté le seul prix qu'Eternity II ait jamais versé. [La page eii](/fr/research/lab/experiments/louis-verhaard/eii/) raconte cette histoire en entier ; la leçon pour cette page-ci est sans détour : l'algorithme était l'actif, et la foule n'en était que le multiplicateur. ## Parcs de machines en propre La seconde forme est plus discrète et a survécu à la première : un chercheur, de nombreuses machines qu'il contrôle personnellement, visant une cible *finie*. **La grappe de François Galea.** En 2009, Galea a rapporté avoir résolu exactement le banc d'essai 10×9 de Brendan Owen (93 jours sur une grappe de 7 nœuds de Pentium 4 doubles) et avoir le 10×10 en cours depuis ~110 jours sur une grappe de trois PlayStation 3, toujours non résolu (istarinz avait abandonné le même 10×10 après un mois sur un Xeon quadricœur) ([message 6918](https://groups.io/g/eternity2/message/6918)). C'est le plus ancien exemple net du bon cas d'usage : le 10×9 possède un arbre connaissable et fini, si bien que davantage de cœurs achètent une véritable date d'achèvement plutôt qu'un billet de loterie. **[La ferme récupérée de Peter McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/).** McGavin a bâti son parc avec tout ce qui coûtait peu : ~20 cœurs à la maison, trois ODROID XU4, vingt-cinq Orange Pi Lite à 12 $ (130+ cœurs), puis des serveurs de travail empruntés pour 400+ au total. Ce pic était intermittent, non soutenu : le travail était « étalé sur environ 4 ans en utilisant par intermittence jusqu'à environ 400 cœurs à la fois » ([message 9804](https://groups.io/g/eternity2/message/9804)), les serveurs empruntés seulement lors du dernier mois environ, et selon sa propre note les cœurs de serveur « sont des hyperthreads, à proprement parler » ([message 9753](https://groups.io/g/eternity2/message/9753)) tandis que les cartes ARM tournent à environ un tiers d'un cœur de PC. En 2017, cette ferme a résolu le set_1 10×10 de Brendan, le banc d'essai communautaire vieux d'une décennie : ~2×10¹⁷ nœuds, environ 180 cœurs-ans, moins de 0,5 % de l'arbre complet, « aucune nouvelle méthode, juste de la persévérance systématique et la loi des grands nombres » ([message 9686](https://groups.io/g/eternity2/message/9686), [message 9688](https://groups.io/g/eternity2/message/9688)). Trois ans plus tard, il a pointé « environ deux cents » cœurs sur le solveur fraîchement publié de Joshua Blackwood pendant quelques jours et a décroché le 469, alors record absolu sur le vrai casse-tête ([message 10045](https://groups.io/g/eternity2/message/10045)). Le cloud a fait des apparitions éclair : Amazon EC2 a été suggéré dès 2010 ([message 8106](https://groups.io/g/eternity2/message/8106)), et David Barr a essayé son programme de recherche sur AWS Lambda en 2016 ([message 9642](https://groups.io/g/eternity2/message/9642)). Mais les parcs loués n'ont jamais supplanté ceux détenus en propre ; pour un casse-tête sans échéance, l'économie favorise le matériel qu'on peut laisser tourner pendant des années. ## Le recensement | Effort | Modèle | Échelle | Résultat | Source | | --- | --- | --- | --- | --- | | eternity2.net (Dave Clark, 2007) | Essaim de bénévoles (BOINC) | 1 300+ membres, 1,6 TFlops | 462–463 soumis ; >10¹⁹ ops ; fermé après 5 mois | [756](https://groups.io/g/eternity2/message/756), [3511](https://groups.io/g/eternity2/message/3511) | | Site réparti français (royale_zerezo, 2007) | Essaim de bénévoles | inconnu | S'est éteint sans résultat | [1253](https://groups.io/g/eternity2/message/1253) | | Eternity 2 Syndicate (Amos, 2007) | Essaim de bénévoles + contrat de prix | ~40 membres, 50 instances, ~300M placements/s | Aucun record ; s'est éteint avec le site | [3021](https://groups.io/g/eternity2/message/3021), [3078](https://groups.io/g/eternity2/message/3078), [3105](https://groups.io/g/eternity2/message/3105) | | E2@home (e2dude, 2008) | Micro-syndicat | Quelques bénévoles | Revendique plus de 460 ; aucun record vérifié | [5474](https://groups.io/g/eternity2/message/5474) | | Publication d'eii (Verhaard, 2008–09) | Binaire publié, partage de prix 50-50 | PC de la communauté | 467 trouvé 40+ fois ; le seul prix jamais versé | [5940](https://groups.io/g/eternity2/message/5940), [6275](https://groups.io/g/eternity2/message/6275) | | Grappe + PS3 de Galea (2009) | Parc en propre | 14 CPU + 3 PlayStation 3 | 10x9 résolu exactement en 93 jours ; 10x10 non résolu | [6918](https://groups.io/g/eternity2/message/6918) | | Réservations de rangées supérieures (2013) | Protocole de liste de diffusion | Une poignée de membres | 4 318 956 rangées listées ; solution connue vérifiée ; s'est essoufflé | [9164](https://groups.io/g/eternity2/message/9164), [9177](https://groups.io/g/eternity2/message/9177) | | Ferme de rangées de McGavin (2016–17) | Parc en propre (récupéré) | 400+ cœurs au pic, intermittent sur ~4 ans (beaucoup sont des hyperthreads) | set_1 10×10 de Brendan résolu, ~180 cœurs-ans | [9688](https://groups.io/g/eternity2/message/9688), [9804](https://groups.io/g/eternity2/message/9804) | | McGavin sur le solveur de Blackwood (2020) | Parc en propre | « environ deux cents » cœurs, quelques jours | 469/480, le record de son temps | [10045](https://groups.io/g/eternity2/message/10045) | | wrapper_blackwood (Bucas, 2021–) | Serveur de tâches + clients par cœur | Un travailleur par cœur | Cartes de paramètres, pas des records | [dépôt](https://github.com/jfbucas/wrapper_blackwood) | ## Comment partitionner un parcours en profondeur d'abord ? Le retour arrière a l'air séquentiel, mais il se répartit à merveille : fixez un préfixe de la recherche et chaque sous-arbre en dessous devient une tâche indépendante, sans le moindre besoin de communication. La communauté a employé trois recettes concrètes. **Bandes de préfixes.** Découper l'espace des premiers placements en plages et confier chaque plage à un travailleur. C'est ce qu'ont fait eternity2.net et le Syndicate, l'« espace de recherche partitionné » du [message 3021](https://groups.io/g/eternity2/message/3021), et c'est la forme la plus faible, car sur le casse-tête complet chaque bande est également désespérée. **Listes de premières rangées.** Énumérer toutes les complétions légales de la première rangée, puis traiter chaque rangée comme une tâche : un retour arrière borné sur le reste du plateau. En 2013, sur la suggestion de McGavin, Martin (capiman) a énuméré les 4 318 956 rangées supérieures légales du set 1 10×10 de Brendan et a publié la liste ([message 9164](https://groups.io/g/eternity2/message/9164)). McGavin a parcouru jusqu'au bout la rangée contenant la solution connue, la rangée 1 407 888, en 15 310 secondes, trouvant exactement cette solution ([message 9167](https://groups.io/g/eternity2/message/9167)), et Michel Gaillard a « réservé » les entrées 1000002–1000035 en postant sur la liste ([message 9177](https://groups.io/g/eternity2/message/9177)). Cet effort de 2013 s'est essoufflé ; celui de 2017 a ajouté l'ingrédient manquant : le *classement*. McGavin a noté ~20 millions de permutations de première rangée par leur probabilité, au sens de la [théorie du complexe](/fr/research/why/complex-theory/), de solution par nœud d'arbre de recherche et a mis en ferme les meilleures rangées d'abord. La solution est arrivée au parcours de rangée ~92 907 contre une prédiction d'une pour ~70 000 ([message 9688](https://groups.io/g/eternity2/message/9688)). Le classement faisait la différence entre une loterie et un calendrier. Les tâches ont une valeur extrêmement inégale ; un bon modèle statique de savoir quelles tranches sont prometteuses vaut plus que n'importe quelle quantité de matériel supplémentaire. **Balayages de paramètres.** La variante moderne répartit des *configurations* au lieu de sous-arbres. Le [wrapper_blackwood](https://github.com/jfbucas/wrapper_blackwood) de Jef Bucas est un petit serveur Python qui distribue des tâches par HTTP, où chaque tâche est une variation des paramètres du [solveur de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) ; les clients (un travailleur par cœur) génèrent le source C# à partir de gabarits avec cette variation intégrée, le compilent, l'exécutent et rapportent. La sortie n'est pas un record mais une carte : quels triplets de couleurs et quels calendriers de quotas atteignent la profondeur, agrégés sur des centaines d'exécutions. ## Coordination et confiance La mécanique de coordination était d'une informalité frappante. Le protocole de réservation de 2013 reposait sur l'honneur : on revendiquait une plage de rangées en postant un message ([message 9177](https://groups.io/g/eternity2/message/9177)), et cela fonctionnait parce que les participants se comptaient sur les doigts d'une main. La vérification, en revanche, était prise au sérieux, et c'était toujours la même méthode : le recalcul indépendant. Quand McGavin a vérifié la rangée 1 407 888, apal1969 a réexécuté la même rangée sur un code distinct et l'a confirmée avec 6,77×10¹¹ nœuds ([message 9168](https://groups.io/g/eternity2/message/9168)) ; quand le 10×10 est tombé en 2017, Martin a validé la solution de façon indépendante ([message 9725](https://groups.io/g/eternity2/message/9725)) ; les plateaux records étaient publiés avec la liste complète des pièces et vérifiés dans le visualiseur en ligne de Jef Bucas ([message 10045](https://groups.io/g/eternity2/message/10045)). Rien n'entrait au registre de la communauté sur la seule parole de quelqu'un. Le véritable problème de coordination de l'ère des essaims était économique, et le concours l'aggravait : les inscriptions au prix pouvaient être disqualifiées si elles étaient publiées, si bien qu'eternity2.net a cessé de publier les scores supérieurs à 463 : un projet réparti incapable de dire à ses propres bénévoles ce qu'ils avaient trouvé ([message 3511](https://groups.io/g/eternity2/message/3511)). Les contrats de partage de prix (les parts proportionnelles aux placements du Syndicate, le 50-50 d'eii, la part du prix mineur d'E2@home) étaient des tentatives d'empêcher les bénévoles d'empocher une trouvaille pour eux-mêmes, et de les garder motivés, à l'intérieur de ce secret imposé. Quand le concours est mort, le problème s'est évaporé : les efforts modernes publient tout, et la confiance repose sur la reproductibilité plutôt que sur des contrats. ## Ce que 10^19 opérations ont acheté Rien, et la communauté en connaissait la raison avant même de commencer. Les estimations d'arbre du groupe lui-même, convergeant à partir d'implémentations indépendantes en 2008, situaient la recherche complète à environ 2,2×10⁴³ nœuds par solution, de l'ordre de 10²⁷ cœurs-ans ([message 5193](https://groups.io/g/eternity2/message/5193), [message 5197](https://groups.io/g/eternity2/message/5197)). Face à cela, le total cumulé de 10¹⁹ opérations d'eternity2.net représente environ 10⁻²⁴ du travail d'une seule solution : multiplier votre parc par mille, ou par un million, ne déplace en rien un nombre pareil. Owen l'avait dit deux mois avant la sortie du casse-tête ([message 226](https://groups.io/g/eternity2/message/226)) ; la lettre de fermeture de Clark le concédait presque dans les mêmes termes ([message 3511](https://groups.io/g/eternity2/message/3511)). Le point plus profond est celui sur lequel ce wiki ne cesse de revenir : le matériel multiplie une recherche, tandis que l'élagage la *reconfigure*. [Élagage contre vitesse](/fr/research/why/prune-vs-speed/) développe l'argument général, et [la théorie du complexe](/fr/research/why/complex-theory/) fournit l'arithmétique exacte de la raison pour laquelle l'arbre du casse-tête complet écrase tout parc concevable. Chaque effort réparti sur le casse-tête complet a confirmé l'argument de dénombrement ; aucun ne l'a entamé. ## Ce à quoi la répartition sert réellement Les efforts qui ont fonctionné partagent une propriété : la cible était finie et les mathématiques le disaient à l'avance. - **Résolution exhaustive à la frontière de faisabilité.** Le 10×9 de Galea et le 10×10 de McGavin sont des arbres de ~10¹⁵–10¹⁷ nœuds : monstrueux pour une seule machine, traitables pour un parc. La répartition a converti « un jour » en 93 jours et 180 cœurs-ans respectivement. - **Mesure.** Le 10×10 de McGavin a fait double emploi comme la plus solide validation que [la théorie du complexe](/fr/research/why/complex-theory/) ait jamais reçue : la solution est arrivée selon le calendrier prédit, et les histogrammes de nœuds publiés correspondaient au modèle ([message 9688](https://groups.io/g/eternity2/message/9688)). Une ferme de cœurs est un bel instrument pour mesurer une théorie. - **Études paramétriques.** wrapper_blackwood est le gabarit moderne : quand la question est « laquelle de ces mille configurations cherche le plus profond ? », les tâches sont vérifiables, bornées et indépendantes, ce qui est exactement ce que la répartition recherche. - **Des records, mais seulement en aval d'un algorithme.** Le 469 est venu de ~200 cœurs faisant tourner un solveur qui était déjà, à lui seul, de classe record ([message 10045](https://groups.io/g/eternity2/message/10045)). Les cœurs ont multiplié l'algorithme de Blackwood ; à aucun moment dans cette archive ils ne s'y sont substitués. > **Le résumé en une ligne** > > Quinze ans de calcul collectif, distillés : les foules sans algorithme n'ont rien acheté ; les parcs pointés sur des cibles finies et bien modélisées ont acheté exactement ce que le modèle promettait. Le multiplicateur est réel ; il ne fait que multiplier ce que vous avez déjà. ## À lire aussi - [La traque, une histoire (partie I : 2000-2009)](https://eternity2.dev/fr/research/community/hunt/) — L'histoire de la communauté, d'une liste de diffusion fondée sept ans avant que le casse-tête n'existe jusqu'au prix d'examen de 10 000 $ remporté sous un nom d'emprunt, chaque événement rattaché à son message d'origine. Partie I d'une chronique en cours. - [eii de Verhaard : le solveur qui a remporté l'unique prix](https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/eii/) — Le moteur derrière le 467, le seul score d'Eternity II jamais récompensé, reconstitué à partir des propres messages de Louis Verhaard sur la liste de diffusion : élagage prospectif, ordres de remplissage en peigne, décalage d'arête conditionné par la profondeur, calendrier de décalage réglé par chaîne de Markov. Et pourquoi son propre binaire Win32, sans code source, ne peut être ni compilé ni exécuté sur cette machine. - [Le backtracker C de McGavin : l'histoire du débit, reconstruit ici](https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/backtracker/) — Le backtracker C de Peter McGavin, le plus rapide de la communauté : une recette d'optimisation de 2007 capitalisée pendant deux décennies via code généré, tables de correspondance et astuces de compteur, puis compilée sur mon M1 et pointée vers le vrai puzzle à 256 pièces, où en mono-cœur elle dépasse 200 des 256 pièces à ~109M placements/s. --- # Ingénierie de solveur : l'artisanat sous l'algorithme > Tous les solveurs record exécutent le même backtracking en profondeur d'abord. Ce qui les distingue, c'est la couche en dessous : tables de correspondance, hachages parfaits, structs taillées pour le cache, code généré, archéologie du compilateur. C'est cet artisanat qui décide si un nœud coûte 26 cycles ou 2 600. Vingt ans de registre d'ingénierie de la communauté, technique par technique, et ce que tout cela a rapporté. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/faster/solver-engineering/ - Mise à jour: 2026-07-22 - Sujets: speed - Source: Le fil Lebel disséqué : le solveur C++ de référence de l'époque mis à nu (groups.io message 1704, 2007) — https://groups.io/g/eternity2/message/1704 - Source: Le hachage parfait minimal à 1024 clés de Nathan remplaçant un tableau d'un million d'entrées (groups.io message 1831) — https://groups.io/g/eternity2/message/1831 - Source: La recette d'optimisation de Mike Field : « La force brute ne fonctionne pas » (groups.io message 3098) — https://groups.io/g/eternity2/message/3098 - Source: Le budget au cycle près de Field : 75 M tuiles/s, ~26 cycles, moitié bloquée sur la mémoire (groups.io message 9003) — https://groups.io/g/eternity2/message/9003 - Source: Instructions d'extraction de bits BMI/BMI2 : de 78 à 90 M placements/s (groups.io message 9796) — https://groups.io/g/eternity2/message/9796 - Source: Les résultats négatifs de Blackwood : seules les heuristiques ont jamais payé (groups.io message 10056) — https://groups.io/g/eternity2/message/10056 - Source: Ce qu'est un « nœud » : le fil sur la convention de comptage (groups.io message 3843, 2008) — https://groups.io/g/eternity2/message/3843 - Source: La convention des pièces par seconde fixée (groups.io message 9739, 2017) — https://groups.io/g/eternity2/message/9739 - Source: Chiffres modernes en mono-cœur : 72,7 M/s en C++, 68,4 M/s en Rust (groups.io message 11633, 2025) — https://groups.io/g/eternity2/message/11633 - Source: Le manuel de compilation de McGavin : versions de clang, drapeaux natifs, PGO (groups.io message 11751, 2026) — https://groups.io/g/eternity2/message/11751 - Source: The Rust Performance Book : configuration de build (LTO, codegen units, PGO) — https://nnethercote.github.io/perf-book/build-configuration.html - Source: L'optimisation guidée par profilage dans rustc (documentation officielle) — https://doc.rust-lang.org/beta/rustc/profile-guided-optimization.html - Source: Optimiser des programmes Rust avec PGO et BOLT via cargo-pgo (Beranek, 2023) — https://kobzol.github.io/rust/cargo/2023/07/28/rust-cargo-pgo.html - Source: Microarchitecture de l'Apple M1 : lignes de cache de 128 octets, 128 Ko de L1d (7-cpu.com) — https://www.7-cpu.com/cpu/Apple_M1.html --- Réduisez n'importe quel solveur record à son squelette et vous retrouvez la même boucle : poser une pièce, vérifier les arêtes, revenir en arrière en cas de blocage. L'algorithme était figé dès 2007. Ce sur quoi la communauté rivalise réellement depuis vingt ans, c'est la couche *en dessous* de l'algorithme : l'artisanat qui décide si visiter un nœud de cet arbre coûte environ 26 cycles d'horloge, comme Mike Field l'a mesuré sur son propre moteur ([message 9003](https://groups.io/g/eternity2/message/9003)), ou cent fois plus dans un interpréteur naïf. Même arbre, même recherche, deux ordres de grandeur d'écart en placements par seconde. Cette page rassemble cet artisanat, technique par technique, chacune avec sa source primaire dans les archives de la liste de diffusion. La chronologie de la manière dont un moteur les a cumulées pendant deux décennies est racontée sur la [page McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) ; l'anatomie du moteur derrière les plateaux record est sur la [page Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/). Voici l'étagère où tous deux puisent. ## Les tables de correspondance de candidats : l'astuce universelle Tout backtracker rapide partage une idée porteuse : ne jamais *chercher* les pièces candidates, mais les consulter. Fixez l'[ordre de remplissage](/fr/research/build/backtracking/fill-order/) (un balayage par lignes, en général), et chaque case expose exactement deux contraintes connues quand son tour vient, la couleur de son arête nord et celle de son arête ouest. Vous précalculez donc une table indexée par cette paire de couleurs, et trouver toutes les pièces qui peuvent légalement occuper la case courante devient un seul accès mémoire. La recette de Field de 2007 la plaçait en tête de liste, avec son corollaire : c'est un ordre de recherche **fixe** qui rend la clé à deux arêtes possible tout court, et poser une pièce ne met alors à jour que ses voisines sud et est ([message 3098](https://groups.io/g/eternity2/message/3098)). La même conception était disséquée la même année autour du solveur C++ public de Marc Lebel, le backtracker rapide de référence de l'époque, dans le fil qui fait aussi office de premier séminaire d'ingénierie de la communauté ([message 1704](https://groups.io/g/eternity2/message/1704)). La recette de 2007 recèle une troisième forme de table, facile à manquer : pour la case juste au-dessus ou à côté d'une *pièce indice obligatoire*, on indexe la consultation sur trois arêtes (nord, sud, ouest), de sorte que les candidats sont pré-filtrés contre la couleur fixe de l'indice, sans aucune perte de complétude ([message 3098](https://groups.io/g/eternity2/message/3098)). J'ai redécouvert son intérêt deux décennies plus tard, dans mon propre carnet : sur un plateau avec indices, les cases entourant un indice se sont révélées un gouffre à débit, avec des threads brassant ~85 M placements par seconde contre le mur de l'indice pendant vingt minutes ; le remède était exactement la table à trois arêtes de Field. Les archives contenaient déjà la réponse. Tout le reste de cette page est un raffinement de cette table : la rendre plus petite, densifier ses entrées, ou dérouler le code autour d'elle. ## Le hachage parfait minimal : la table réduite à la juste taille La table de correspondance a un problème de taille dès qu'on l'indexe sur plus de deux arêtes. Dans le fil Lebel, Nathan a décrit la version en force brute : un tableau à 4 dimensions indexé par les quatre couleurs d'arêtes, `combo4[32][32][32][32]`. Un million d'entrées, majoritairement nulles, des défauts de cache garantis. Son correctif a adopté le générateur de hachage parfait minimal (celui de Bob Jenkins) vers lequel un autre membre avait orienté la liste. Comme les 256 pièces en 4 rotations ne produisent que 1024 quadruplets d'arêtes distincts, un hachage parfait minimal fait correspondre la clé compactée de 32 bits à une table de 1024 entrées sans collision : « assez petite pour tenir dans le cache la plupart du temps », avec un surcoût de hachage quasi nul, et les clés absentes lisent simplement un compte de zéro ([message 1831](https://groups.io/g/eternity2/message/1831)). Un million d'entrées ramené à mille, uniquement pour que l'ensemble de travail vive en L1. Il a tracé la frontière lui-même : la table à quatre arêtes ne gagne son loyer que lorsque l'ordre de remplissage peut laisser des trous ; un solveur à balayage strict n'en a jamais besoin. ## Compactage de bits et dimensionnement des structs : le cache, le vrai adversaire Le budget en cycles de Field explique pourquoi tant de cet artisanat porte sur l'agencement mémoire : à 75 M tuiles par seconde et par cœur, plus de la moitié du temps était bloquée sur l'accès mémoire, pas sur le calcul ([message 9003](https://groups.io/g/eternity2/message/9003)). La réponse est de faire compter chaque octet que la recherche touche. Compactez les quatre côtés d'une pièce dans un seul entier ([message 3098](https://groups.io/g/eternity2/message/3098)). Gardez l'ensemble des pièces utilisées comme un mot de 64 bits par groupe et court-circuitez toute une boucle de candidats avec un unique test de masque, une optimisation qu'Arnaud Carré et Adam Miles ont découvert avoir implémentée indépendamment, ligne pour ligne ([message 9808](https://groups.io/g/eternity2/message/9808), [message 9809](https://groups.io/g/eternity2/message/9809)). Dimensionnez l'entrée de la table de candidats pour que la table entière tienne dans le cache. C'est exactement la conception de la struct `RotatedPiece` de six octets de Blackwood, déjà racontée sur [la page Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) : numéro de pièce, rotation, les deux côtés exposés, un compte de ruptures et un compte heuristique, et rien d'autre. Ces astuces se cumulent encore en 2026. Sur un moteur en profondeur d'abord par ailleurs identique, dans mon carnet, trois micro-changements exactement de cette famille ont totalisé **+27 %** (92 à 93 M contre 72 à 73 M placements par seconde, stable sur des budgets de 3, 5, 10 et 15 secondes ; un moteur, un puzzle, une machine, donc lisez-y une forme plutôt qu'une constante universelle). Un : des **listes de candidats terminées par sentinelle**, chaque seau se finissant sur une valeur impossible, si bien que le balayage tient en un chargement et une comparaison au lieu d'un compteur de bornes, libérant un registre. Deux : l'ensemble des pièces utilisées en **mots de bitset u64** au lieu d'un octet par pièce ; même nombre d'octets, mais le test est un unique AND et tout l'ensemble tient dans une ou deux lignes de cache. Trois : un **curseur de reprise unique** par profondeur au lieu d'une paire début/fin, divisant par deux la comptabilité du retour arrière. Et l'artisanat n'est pas propre aux backtrackers : dans un solveur à propagation de contraintes qui maintient des domaines de candidats complets par case, passer ces domaines en mots de bitset u64 a transformé la révision d'arc-cohérence en une poignée d'opérations sur mots et a rapporté +48 à +101 % selon le mélange de propagateurs, le travail d'agencement qui a suivi (table de rotations précalculée, consultation de pièce en O(1), annulation par arène) se cumulant à ~4,6× sur le profil le plus léger. Lectures de débit à graine unique, et un solveur à propagation fait bien plus de travail par nœud que les marcheurs rapides de cette page : emportez les ratios, pas les valeurs absolues. La leçon, elle, voyage entière : la représentation du domaine *est* le moteur. ## Bipièces et métatuiles : précomposer, et payer en mémoire Si une consultation vous donne les pièces candidates, pourquoi ne pas précomposer des paires en « bipièces » 1×2 et poser deux cases par nœud ? Mesuré sur le code de Lebel en août 2007, ça marchait : environ 20 à 30 % plus rapide ([message 1734](https://groups.io/g/eternity2/message/1734)). Mais le compromis est rude et les archives en documentent les deux faces. En passant aux blocs 2×2, un membre a mesuré à peu près 4,2× *plus lent* et a rejeté d'emblée les pièces plus grandes ([message 1730](https://groups.io/g/eternity2/message/1730)). Pas de surprise une fois les tables comptées : environ 4 millions de combinaisons 2×2 intérieures distinctes ([message 3044](https://groups.io/g/eternity2/message/3044)). Louis Verhaard a rapporté que les bipièces n'aidaient « que très marginalement » dans son propre backtracker rapide ([message 3061](https://groups.io/g/eternity2/message/3061)). Et en 2008 la liste a tranché la question théorique sous-jacente : un solveur à métatuiles visite essentiellement la même frontière de contraintes qu'un solveur 1×1 (« synchronisés toutes les 4 pièces »), de sorte que le gain est au niveau de l'implémentation, jamais une réduction de l'espace de recherche ([message 5842](https://groups.io/g/eternity2/message/5842), [message 5899](https://groups.io/g/eternity2/message/5899)). La précomposition est une accélération qu'on paie en mémoire, et au-delà du 1×2 le prix devient négatif. ## Génération de code : écrire le programme qui écrit le solveur Les dernières indirections de la boucle interne (« sur quelle case suis-je ? quelles sont ses voisines ? ») peuvent être supprimées en n'ayant tout simplement pas de boucle. La recette de Field : *générer* procéduralement du code monolithique en ligne droite, un bloc par case, chaque bloc connaissant ses propres voisines comme des constantes ; son code généré se compilait en environ 33 instructions par case ([message 3098](https://groups.io/g/eternity2/message/3098)). L'idée s'est répandue vite : dès mi-2008, istarinz générait un solveur C non récursif par puzzle et par chemin de remplissage, compilé avec le compilateur Intel ([message 5480](https://groups.io/g/eternity2/message/5480), [message 5438](https://groups.io/g/eternity2/message/5438)), la même saison où la liste comparait ses notes sur les backtrackers non récursifs en général ([message 4683](https://groups.io/g/eternity2/message/4683)). Le `body.c` de Peter McGavin, c'est cette idée cumulée pendant vingt ans : des blocs étiquetés comme `cell_9_2_next:`, des chaînes de `goto` remontant dans la case précédente à l'épuisement, le fichier entier régénéré pour chaque puzzle et chaque jeu d'indices ([message 11337](https://groups.io/g/eternity2/message/11337), [message 11782](https://groups.io/g/eternity2/message/11782)). Et ça marche d'une langage à l'autre : libblackwood de Jef Bucas, un générateur Python émettant du C, a rendu l'algorithme C# de Blackwood environ deux fois plus rapide sur la même machine ([message 10065](https://groups.io/g/eternity2/message/10065), [message 10078](https://groups.io/g/eternity2/message/10078)). La recette se reproduit aussi dans un langage moderne et essentiellement sûr. Dans mon carnet, une macro procédurale Rust déplie la boucle de recherche en 256 branches spécialisées par case, les faits de ligne, de colonne et de bordure devenant des constantes de compilation : mesuré **+21 %** seule, **+25 %** combinée à l'optimisation guidée par profilage, et **+30 à 35 %** une fois repliées les tables de constantes par calendrier de remplissage (dispersion ±1 % sur 4 exécutions ; la correction est verrouillée sur une profondeur maximale et un score identiques). L'estimation analytique préalable donnait +5 à 10 % ; le surplus est venu de la spécialisation de la prédiction de branchement par branche et de l'agencement du code, pas du repliement de constantes lui-même. La facture : le temps de compilation est passé de 5 secondes à 41. La recette de Field signalait déjà le revers en 2007 : le code généré monolithique perd environ un tiers de son avantage sur les grands ensembles de travail parce que le cache d'instructions déborde ([message 3098](https://groups.io/g/eternity2/message/3098)), ce qui recoupe cette expérience mesurée ; une partie de ce que la génération de code achète, c'est de l'agencement, et l'agencement est précisément ce qu'un I-cache qui déborde reprend. ## Réalités du compilateur : les derniers 20 %, pas les 10²⁰ manquants Sous le code source, il reste du débit à récolter, dans les instructions et les drapeaux plutôt que dans les idées. Adam Miles a fait passer son solveur de 78 à 90 millions de placements par seconde avec les instructions d'extraction de bits `bextr` de BMI et `pext` de BMI2, tout en notant qu'il devenait « de plus en plus difficile » d'aller plus loin ([message 9796](https://groups.io/g/eternity2/message/9796)). Le manuel de McGavin de 2026 est le folklore accumulé : essayez clang, icc et icx face à gcc ; essayez les *versions* (clang-15 bat clang-19 sur ses cartes ARM) ; ajoutez `-march=native` et `-mtune=native` ; utilisez l'optimisation guidée par profilage. Aucune de ces astuces n'est une solution miracle ([message 11751](https://groups.io/g/eternity2/message/11751)). Son astuce de compteur du même message est le genre en miniature : le compteur de placements de 64 bits est alimenté par un registre de 16 bits qui déborde, ajoutant `0x10000` à la fois, parce qu'il a chronométré les deux méthodes il y a des années sur du matériel 32 bits et que l'astuce l'a emporté. La ligne PGO du manuel peut recevoir des chiffres. Mesurée sur trois moteurs Rust de mon carnet, même charge de travail et même machine, l'optimisation guidée par profilage a rapporté **+14 %, +12 % et +4 %** (une charge de travail par binaire, donc des chiffres à charge unique), et l'ampleur du gain suivait le nombre de branchements imprévisibles que chaque boucle interne laissait encore au compilateur à agencer ; les références standard sont le [Rust Performance Book](https://nnethercote.github.io/perf-book/build-configuration.html) et la [documentation PGO de rustc](https://doc.rust-lang.org/beta/rustc/profile-guided-optimization.html). Deux notes pratiques voyagent avec ces chiffres. L'exécution d'entraînement doit être représentative : un build PGO entraîné sur un seul motif de branchement peut sortir *plus lent* que la base hors distribution. Et les optimiseurs post-édition de liens que le manuel désigne ensuite ([BOLT, via cargo-pgo](https://kobzol.github.io/rust/cargo/2023/07/28/rust-cargo-pgo.html)) ne traitent que les binaires ELF, donc Linux en pratique ; qui suit le manuel de la communauté sur un Mac s'arrête au PGO. Le même réalisme s'applique au matériel. Le multithreading passe à l'échelle de la manière évidente : les solveurs multi-cœurs ont franchi les 100 M placements/s en 2008 ([message 5804](https://groups.io/g/eternity2/message/5804)), et un seul Core i7 a atteint 558 M/s en décembre de cette année-là ([message 6212](https://groups.io/g/eternity2/message/6212)). Les progrès en mono-cœur, en revanche, se sont pour l'essentiel arrêtés. En publiant sa table 2025 de neuf combinaisons CPU/compilateur (38 à 84 M placements/s), McGavin notait que les vitesses sur les CPU les plus récents « ne sont qu'un peu plus rapides » que sur son Phenom II de 2010 ([message 11643](https://groups.io/g/eternity2/message/11643)). Les moteurs ont heurté le mur mémoire de Field il y a quinze ans et s'y appuient depuis. ## Ce que coûte un nœud en 2026 : l'anatomie, mesurée Le budget en cycles de Field ouvrait cette page depuis 2007. Voici la version refaite depuis mon propre carnet, sur un cœur performance d'Apple M1 (lignes de cache de 128 octets, 128 Ko de cache de données L1 ; [les tables de latence du M1](https://www.7-cpu.com/cpu/Apple_M1.html) sont la version moderne des chiffres contre lesquels Field se battait). Un nœud de mon backtracker Rust sans élagage coûte **environ 90 à 145 cycles** : des lectures propres, sans contention, données en fourchette parce qu'une machine chargée poussait le même binaire bien au-dessus. La surprise est la destination des cycles. L'arithmétique de vérification des arêtes est pour ainsi dire gratuite. Le nœud est dominé par **l'évacuation des pièces déjà utilisées hors de la liste de candidats** : environ 6,7 lectures de candidats par nœud, dont environ 5,9 (88 %) sont rejetées uniquement parce que la pièce est déjà sur le plateau. Chaque rejet est un chargement L1 plus un branchement dépendant des données ; toute la boucle de rejet tient en dix instructions et un seul chargement. Trois instruments croisés placent le plancher d'instructions retirées à environ 75 à 90 instructions par nœud, soit, au débit d'émission de pointe du cœur, à peu près 12 à 15 cycles. Les 90 à 145 mesurés se situent 7 à 10× au-dessus de ce plancher, et l'écart a un seul nom : **la mauvaise prédiction de branchement** sur le test de pièce utilisée, dont l'issue dépend des pièces que la recherche a posées et ne peut donc pas être prédite. En 2007, le mur était la mémoire ; Field mesurait la moitié de ses cycles bloqués sur des chargements ([message 9003](https://groups.io/g/eternity2/message/9003)). Sur les larges cœurs à exécution dans le désordre des années 2020, aux caches L1 généreux, le mur s'est déplacé vers l'entropie de branchement. Une mesure de plus complète l'anatomie. Activer un élagage de faisabilité correct, du genre que font tourner les moteurs de record, multiplie le coût du nœud par environ 13 à 24×, à **environ 2 180 cycles par nœud** : le test de l'élagage est invoqué environ 8 fois par nœud et, en rejetant des candidats, force le balayage environ 10× plus loin dans la liste (les lectures de candidats sautent de 6,7 à 67,6 par nœud). Et cela reste massivement rentable, parce que l'élagage achète des ordres de grandeur de nœuds en moins vers la même profondeur. C'est [l'argument élagage contre vitesse](/fr/research/why/prune-vs-speed/) saisi dans une seule table de coûts : le moteur tourne délibérément ~15× plus lentement par nœud parce que le produit nœuds × coût-par-nœud est ce qui compte. (Méthodologie : les comptes de nœuds sont identiques au bit près d'une exécution à l'autre, la discipline de somme de contrôle décrite plus bas ; les débits sont des médianes sur 7 répétitions ; une machine, un régime de plateau, donc chaque chiffre est à portée limitée.) ### Ce qu'une réécriture peut acheter : une réponse verrouillée par équivalence L'anatomie en main, la question suivante est ce qu'une réécriture récupère. J'ai reconstruit le noyau de placement chaud de six façons dans un laboratoire isolé : entrées de candidats compactées, préchargement logiciel, scission de boucle stricte/relâchée, pipelinage logiciel, tables annexes compactées, et des combinaisons, sous une règle dure : le chrono d'une variante ne compte que si elle reproduit **le compte de nœuds exact, la profondeur maximale et un hachage de trajectoire roulant** du moteur de production, replié sur chaque validation (profondeur, pièce, rotation). Ce verrou est le grand frère de la somme de contrôle par compte de nœuds de la communauté (c'est aussi ainsi que [l'expérience en Rust portable](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) plus bas vérifie ses échelons) ; aucune accélération issue d'une sémantique discrètement modifiée ne peut s'y glisser. Chaque chiffre ici l'a passé. Le total pour une réécriture scalaire à sémantique exacte : **1,2 à 1,4× robuste, environ 1,8× en pointe** dans la région la plus favorable. Pas 10×. Le résultat porteur est un négatif. Les deux optimisations de cache « évidentes » furent quasi nulles : compacter les couleurs dans l'entrée de candidat, pour supprimer deux collectes en table, a rapporté 1,0 à 1,2× et a parfois régressé ; réduire les tables annexes de 64 Ko à une forme de 1 Ko résidente en L1 a rapporté au plus 1,26×. C'est une preuve par le nul que les chargements étaient déjà servis par le cache. Le coût résiduel est le branchement de pièce utilisée qui se prédit mal, et toute variante qui préserve la trajectoire exacte de la recherche doit garder ce branchement. Les seules variantes utiles ont restructuré le flot de contrôle *autour* de lui (scission de boucle, pipelinage logiciel), raison pour laquelle elles plafonnent à 1,2 à 1,4× et ne se cumulent pas : elles attaquent le même résidu. Un premier essai de flux de candidats par bitset sur cette conception a mesuré 16 à 25 % *plus lent*, même portée. L'échappatoire du traitement par lots a eu son procès aussi : fusionner deux cases horizontalement adjacentes en un pas « domino », vérifié comme produisant des ensembles de complétions identiques, exhaustivement, jusqu'à un branchement à 3 171 voies. Cela a rapporté 1,05 à 1,13× dans un régime où 74 % des cases pouvaient fusionner, et fut net neutre (0,96 à 1,03×) dans le régime où tourne réellement la recherche de type record, où seules 27 % fusionnent. Le mécanisme explique le plafond : le lot amortit la coquille de boucle par case, environ 7 % d'un nœud, mais le balayage dominant filtré par pièces utilisées est irréductible par case ; la seconde case parcourt quand même son propre seau contre l'ensemble utilisé vivant, ce qu'aucune table de paires statique ne peut encoder. L'arithmétique esquissée dit que des blocs plus grands heurtent le même mur, mais cette extrapolation reste non testée au-delà des paires. Tout ceci vaut pour une conception de moteur, un jeu d'instructions, un régime de puzzle ; la formulation juste est que **pour cette conception sur ce matériel, le plafond scalaire est d'environ 1,5 à 2×**, et le mur a un nom. Savoir si un flux de candidats SIMD sans mauvaise prédiction peut aller plus loin est une direction ouverte, pas un résultat. ## Discipline de mesure : c'est quoi, au juste, un « nœud » ? Une culture d'ingénierie ne vaut que ses bancs d'essai, et les archives ont dû bâtir cette discipline à la dure. En janvier 2008, comparer les revendications de vitesse a forcé la question de définition : Txibilis comptait un nœud comme chaque pièce *valide* posée sur le plateau, sans anticipation ([message 3843](https://groups.io/g/eternity2/message/3843)) ; d'autres comptaient les placements tentés, ou les étapes, et le fil a conclu qu'une métrique sur laquelle tout le monde s'accorde n'existe peut-être pas ([message 3946](https://groups.io/g/eternity2/message/3946)). La question est revenue en 2017 et a reçu la réponse standard : les « pièces par seconde » de la communauté comptent les pièces *posées* par seconde, à la manière des échecs ([message 9739](https://groups.io/g/eternity2/message/9739), [message 9740](https://groups.io/g/eternity2/message/9740)). L'objection standard l'accompagnait : la métrique flatte les ordres de remplissage à balayage et ne dit rien sur la couverture de l'espace de recherche par unité de temps ([message 9746](https://groups.io/g/eternity2/message/9746)). Deux conséquences pratiques. D'abord : ne jamais comparer les chiffres en M/s de deux solveurs sans vérifier ce qu'ils comptent ; un solveur « plus rapide » peut simplement avoir une définition plus généreuse. Ensuite, l'habitude positive qui en a découlé : publier **le compte de nœuds à côté des chronos**. Un backtracker déterministe parcourant un arbre fixe doit compter les mêmes nœuds sur n'importe quelle machine, si bien que les comptes de nœuds exacts sont devenus les sommes de contrôle de la communauté, la façon dont les portages, réécritures et nouveaux matériels prouvent qu'ils parcourent le même arbre avant que leur vitesse ne signifie quoi que ce soit. Il y a une troisième confusion à nommer une fois pour toutes, car elle revient dès que ces nombres atteignent un public plus large. « Rapide » désigne trois quantités sans rapport, et aucune ne se convertit dans l'autre : - **Placements par seconde** (soit pièces/s ou nœuds/s) - à quelle vitesse la recherche *avance*. C'est ce que mesure chaque chiffre de cette page, et cela dépend du plateau autant que du moteur. Le C de McGavin fait ~287 M sur un plateau facile mais ~105 M sur un difficile ; un [moteur en Rust portable sur ce site](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) atteint ~110 M sur le même plateau difficile - à égalité là - et ~122 M sur le facile. - **Arêtes appariées sur 480** - à quel point un plateau est *bon*. C'est l'axe où vivent les [records](/fr/research/records/) (le plafond est 470). Il est indépendant de la vitesse de marche : un moteur lent trouve régulièrement un meilleur plateau qu'un rapide. - **Placements agrégés par seconde** - un total de *grappe*, plusieurs machines additionnées. Le « ~300 M/s » parfois épinglé sur un seul moteur est en fait la [grappe du Eternity 2 Syndicate](/fr/research/build/faster/distributed-solving/), une vingtaine de machines additionnées, pas un cœur. Un grand nombre sur le premier axe ne dit rien du deuxième, et le troisième n'est pas du tout une vitesse de moteur. Quand ce site cite un débit, c'est toujours des placements/s sur un cœur sauf mention contraire ; là où le *compromis* entre dépenser le budget d'un solveur en vitesse ou en jugement est le sujet, cet argument vit sur [aller vite](/fr/research/lab/experiments/raphael-anjou/going-fast/). ### Profiler, puis optimiser : les prédictions perdent contre les flamegraphs La discipline se prolonge sous le banc d'essai, jusque dans la boucle d'optimisation elle-même. Une passe de profilage sur mon solveur à forte propagation (un profileur par échantillonnage avec résolution des trames inlinées) a livré sept correctifs dirigés par flamegraph valant **+22 à 27 %** au total, chacun mesuré séparément : fusionner un test de vacuité dans la boucle de bitset a fait +27,5 % sur le profil le plus léger, remplacer une liste de travail matérialisée par un parcours de bitmap sur pile +7 %, une reconstruction de compteur par popcount +4,3 %. Pendant ce temps, **cinq optimisations prédites statiquement furent réfutées par le même profil** : chacune un gain d'école de 1 à 5 % sur le papier (indications d'inline, réutilisation d'instantané, remontée de dispatch, réordonnancement de struct, déroulage manuel), chacune soit absente des 200 premiers échantillons, soit mesurée neutre, parce que le compilateur les faisait déjà. Un correctif relevait de la pure hygiène de mesure : l'appel de chronométrage lui-même pesait **12,4 %** du temps d'exécution à un taux de vérification d'échéance de 1 sur 64, et le ramener à 1 sur 4096 a tout récupéré, le motif de l'échéance masquée à l'état pur. L'arithmétique de cache sans profil trompe de la même façon, dans les deux sens. Remplacer une table de consultation plate de 1 Mo par une table compacte de 16 Ko résidente en L1, créditée d'environ 20 % par l'arithmétique des latences, a mesuré **0 %** avec une légère régression (trois exécutions de 10 secondes) : les clés réellement touchées se regroupaient et étaient déjà chaudes en cache. `panic = "abort"` a de même mesuré nul une fois la boucle chaude vidée de ses arêtes de panique. Ce sont des pourcentages à graine unique, machine unique, propres à un moteur ; le motif durable est qu'environ la moitié des prédictions statiques d'expert étaient fausses, dans chaque sens, et que le flamegraph a arbitré chaque litige. Mesurer, pas modéliser. ## L'étagère en un coup d'œil | Technique | Ce qu'elle coûte | Ce qu'elle a rapporté | Source | | --- | --- | --- | --- | | Tables de candidats par position (clé à deux arêtes) | mémoire pour les tables ; un ordre de remplissage fixe | les candidats en un seul accès mémoire, la base que partage tout solveur rapide | [3098](https://groups.io/g/eternity2/message/3098) | | Hachage parfait minimal | construction de hachage hors ligne | table d'un million d'entrées → 1024 entrées, résidente en cache | [1831](https://groups.io/g/eternity2/message/1831) | | Compactage de bits, structs taillées pour le cache | contorsions de code | moins de blocages là où >50 % du temps est mémoire ; court-circuits par masque de 64 bits | [9003](https://groups.io/g/eternity2/message/9003), [9808](https://groups.io/g/eternity2/message/9808) | | Bipièces (précomposition 1×2) | les tables grossissent vite ; pas de réduction de l'espace de recherche | +20 à 30 % en 1×2 ; ~4,2× *plus lent* en 2×2 | [1734](https://groups.io/g/eternity2/message/1734), [5899](https://groups.io/g/eternity2/message/5899) | | Génération de code (code en ligne droite par case) | un pipeline de compilation ; régénérer par puzzle | ~33 instructions/case (2007) ; ~2× grâce au C de libblackwood (2020) | [3098](https://groups.io/g/eternity2/message/3098), [10065](https://groups.io/g/eternity2/message/10065) | | Instructions d'extraction de bits BMI/BMI2 | portabilité | 78 → 90 M placements/s | [9796](https://groups.io/g/eternity2/message/9796) | | Comparatif de compilateurs, drapeaux natifs, PGO | tâtonnements, par machine | gains « significatifs » mais non quantifiés, de quelques à quelques dizaines de pour cent | [11751](https://groups.io/g/eternity2/message/11751) | | Astuces de compteur (alimentation par débordement 16 bits) | obscurité | mesurable seulement sur le matériel de l'ère 32 bits | [11751](https://groups.io/g/eternity2/message/11751) | ## Vingt ans, de ~1× à 4× par cœur Prenons maintenant du recul. La recette de Field de 2007 faisait déjà 60 à 80 millions de placements par seconde et par cœur ([message 3098](https://groups.io/g/eternity2/message/3098)). Les vingt ans d'artisanat qui ont suivi ont élargi cette fourchette plutôt que de la multiplier uniformément. Sur du code portable, le gain est modeste, même si les deux chiffres de 2025 ne portent pas sur le même puzzle : 72,7 M/s d'un solveur C++ affûté sur un plateau 8×8 et 68,4 M/s d'un descendant Rust de celui de Blackwood sur du 16×16 en 2025 ([message 11633](https://groups.io/g/eternity2/message/11633), [message 11634](https://groups.io/g/eternity2/message/11634)), à peine au-dessus de la base de 2007. Le facteur ~4× n'apparaît qu'avec du C généré par case sur le matériel le plus récent : autour de 225 à 295 M/s pour celui de McGavin sur de petits puzzles ([message 11751](https://groups.io/g/eternity2/message/11751) note que le débit est à peu près divisé par deux sur du 16×16, la taille qu'E2 a réellement ; [message 11750](https://groups.io/g/eternity2/message/11750)), il mêle donc un gain de génération de code à un gain matériel, pas de l'artisanat seul. Sur ces mêmes vingt ans, le record a bougé de trois arêtes : de 467 à 470. Mon propre carnet a rejoué ce registre de vingt ans en un après-midi. Le premier solveur de ce site, à forte propagation, marchait à environ 370 k placements par seconde ; le moteur record en C généré de la communauté en fait environ 295 M sur un matériel comparable, un écart de 800×. Porter la *forme* du moteur C vers un Rust penchant vers le sûr (tables de candidats plates sensibles à la bordure, bitset de pièces utilisées en quatre mots, listes de candidats terminées par sentinelle, drapeaux précalculés par profondeur) en a comblé environ 180× en une journée : 65 à 68 M placements par seconde en mono-thread, médiane 67 M sur 4 graines avec environ 5 % de dispersion, sur une machine, pour atterrir à ~22 % du moteur C avant toute spécialisation par case. À ce stade, le portage n'avait pas été vérifié comme parcourant l'arbre identique : lisez-y un résultat de forme de débit, pas un portage vérifié ; la comparaison vérifiée est l'expérience ci-dessous. Mais la leçon tient déjà : chaque technique de ce portage figure sur l'étagère de cette page, l'étagère appliquée ensemble *est* le facteur cent, et l'écart était d'architecture, pas de langage. (Ces 65 à 68 M sont le moteur de ce carnet ; les 68,4 M en Rust de la communauté cités plus haut sont un autre programme, une coïncidence de fourchettes.) Une [expérience de 2026 sur ce site](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) sépare directement ces deux gains. Elle prend un backtracker en *Rust portable et sûr* et applique le même artisanat - code généré par case, cases empaquetées, ensemble utilisé en tableau d'octets, fusion de cases - puis le mesure face au C de McGavin sur une machine, même plateau, tous deux sans affichage, dos à dos. En gardant le matériel fixe, le moteur portable **égale le C sur les plateaux difficiles et profonds** (≈105 à 110 M nœuds de recherche/s chacun) tandis que le C reste ~2,3× plus rapide sur les faciles et peu ramifiés (≈287 M contre ≈122 M) - chaque échelon vérifié comme parcourant l'arbre identique. La leçon tranche dans les deux sens : l'art de la génération de code est réel et reproductible dans un langage moderne - assez pour égaler du C optimisé à la main là où la recherche est difficile - *et* il reste seulement le facteur constant que cette page décrit. Le même moteur, pointé sur le vrai puzzle, plafonne dans les hauts 300 sur 480, exactement là où la vitesse seule vous laisse. Deux mesures de carnet de plus ferment la comptabilité. D'abord, le facteur constant pris sur le fait : un gain de +25 % de débit mono-thread issu du code généré par profondeur **n'a pas changé la qualité de plateau atteinte** à budget multi-thread fixe de 5 minutes. Des partiels identiques à 444 arêtes appariées sur 480, et les mêmes 450 à 451 arêtes appariées après une passe de réparation, stables sur 3 graines avec environ 0,5 % de dispersion (une machine, un point de budget ; convention des arêtes appariées, et voyez [la page des records](/fr/research/records/) pour situer tout chiffre de ce genre face à ceux de la communauté). La recherche converge vers la même trajectoire ; marcher plus vite ne fait que l'atteindre plus tôt. Ensuite, la mise en garde multithread que 2008 n'a jamais eu à affronter : sur une puce à 8 cœurs au système mémoire partagé, 4 threads tournaient à 52 M placements par seconde chacun quand 8 threads tombaient à 22 M chacun, un agrégat quasi plat, et les deux atteignaient le même score au même budget. Le multithread passe à l'échelle de la manière évidente jusqu'à saturation du système mémoire. Les praticiens l'ont dit eux-mêmes. Joshua Blackwood, cataloguant ses impasses après le 469 ([solveurs SAT](/fr/research/build/exact/sat-csp-encodings/), [GPU](/fr/research/build/hardware/gpu-solving/), blocs 2×2 en cache, tous mesurés et abandonnés), a constaté que seul le raffinement des *heuristiques* avait jamais payé, valant encore ~2× ([message 10056](https://groups.io/g/eternity2/message/10056)). Et quand le fil vitesse de 2025 s'est éteint, Razvan en a écrit l'épitaphe : quelle que soit la vitesse à laquelle on peut vérifier, « nous n'y ferons pas la moindre entaille » dans l'espace de recherche d'E2 ([message 11657](https://groups.io/g/eternity2/message/11657)). L'artisanat de cette page est réel, mesurable et vaut la peine d'être appris ; c'est ce qui permet à une ferme d'amateurs de parcourir 10¹⁷ nœuds. Mais un facteur constant reste un facteur constant. [Pourquoi rétrécir l'arbre bat accélérer la marche](/fr/research/why/prune-vs-speed/) est l'arithmétique de cette phrase ; cette page en est le registre d'ingénierie. ## À lire aussi - [Le backtracker C de McGavin : l'histoire du débit, reconstruit ici](https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/backtracker/) — Le backtracker C de Peter McGavin, le plus rapide de la communauté : une recette d'optimisation de 2007 capitalisée pendant deux décennies via code généré, tables de correspondance et astuces de compteur, puis compilée sur mon M1 et pointée vers le vrai puzzle à 256 pièces, où en mono-cœur elle dépasse 200 des 256 pièces à ~109M placements/s. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [Le backtracker JIT : du Rust portable à égalité avec du C optimisé sur les plateaux difficiles](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) — Un backtracker Rust en profondeur d'abord, sûr et portable, spécialisé à l'exécution en émettant puis compilant du Rust propre à chaque puzzle, porté de 43 à 123 millions de nœuds de recherche par seconde sur un cœur. Mesuré équitablement face au C de Peter McGavin sur la même machine : à égalité sur les plateaux difficiles et profonds comme le vrai Eternity II, et à environ 44 % de sa vitesse sur les faciles. Chaque échelon parcourt l'arbre identique ; tout le gain vient du code, pas de l'algorithme. --- # Les formats de plateau et de puzzle, couchés sur le papier > Tous les formats sous lesquels un plateau ou un puzzle Eternity II circule sur ce site et dans la communauté : la chaîne de lettres board_edges et la liste d'indices hints, e2pieces.txt, le CSV de puzzle, le JSON Puzzle du site, et l'URL de visualiseur, avec les règles exactes au niveau de l'octet (comment la bordure grise est encodée dans chacun) et, surtout, ce que chaque format sait et ne sait pas restituer. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/formats/ - Mise à jour: 2026-07-16 - Source: La couche IO canonique qui définit ces formats (e2-io : l'unique format de plateau, dérivé partout ailleurs) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/common/crates/e2-io --- Un plateau est chose simple : 256 tuiles, chacune munie de quatre arêtes colorées, chacune posée à une case avec une rotation. Mais la communauté l'a couché sur le papier d'une douzaine de manières en dix-neuf ans, et ces manières ne coïncident jamais tout à fait. Une chaîne de lettres, une chaîne de chiffres, une URL, un CSV, un JSON. Ils disent la même chose dans des alphabets différents, et à l'instant où l'on déplace un plateau d'un outil à l'autre, on bute sur la couture. Cette page, c'est la couture, couchée sur le papier : tous les formats sous lesquels un plateau ou un puzzle circule ici, avec les règles au niveau de l'octet, y compris le seul détail qui mord tout le monde, **la façon dont chaque format encode la bordure grise**, et, pour chacun, une note claire sur ce qu'il sait et ne sait pas restituer. Si vous ne retenez qu'une chose : collez n'importe quel plateau dans le [convertisseur de formats](/convert/) et relisez directement les autres. > **Une entrée, une sortie** > > Le contrat IO est symétrique et réduit. **Entrée :** une instance de puzzle en JSON (le schéma `Puzzle` du site, ci-dessous) ; chaque algorithme est invoqué avec `--puzzle .json`. **Sortie :** un document de plateau en JSON (le `BoardDoc`, ci-dessous), portant en champ une URL [eternity2.dev](/viewer/) prête à ouvrir. C'est tout : puzzle-JSON en entrée, plateau-JSON en sortie, deux fichiers uniques et autodescriptifs. Tout le reste de cette page est soit une *entrée* historique que les outils acceptent encore (CSV, `board_edges` nu), soit un format *dérivé* que le [convertisseur](/convert/) sait vous fournir. Il n'y a plus de séparation `.url`-ici, `.json`-là, deux-fichiers-parfois. ## Le vocabulaire Une **couleur** est un petit entier. `0` est la bordure grise extérieure ; les couleurs intérieures vont de `1..=22` pour le puzzle officiel (22 est exactement le nombre de motifs existants). Un **quadruplet d'arêtes** est l'ensemble des quatre couleurs d'une case dans l'ordre **URDL** (haut, droite, bas, gauche), en lisant la tuile *telle que posée et tournée*, et non comme une tuile de catalogue. Une case est soit remplie (un quadruplet réel), soit vide ; une case vide s'écrit comme si elle était toute en bordure, `[0, 0, 0, 0]`. Un fait découle de « telle que posée », et il est la source de la plupart des confusions entre formats : un plateau porte des arêtes **tournées**, pas un numéro de rotation. Mais ce n'est pas une perte. Les pièces d'Eternity II sont **toutes distinctes à rotation près** (le jeu officiel l'est, et tout générateur fidèle le maintient), donc le quadruplet d'arêtes d'une case identifie une seule pièce, et la rotation est le tour qui amène le quadruplet de catalogue de cette pièce sur celui qui est posé. Apparier le quadruplet au jeu restitue **les deux** : l'identité et la rotation. Ainsi les arêtes sont le plateau tout entier : elles le rendent, le scorent, et nomment chaque pièce et son orientation. Le seul cas où elles échouent est un jeu artificiel où deux pièces partagent un motif d'arêtes à rotation près, ce que le vrai Eternity II n'a jamais, et là un canal numéro-de-pièce désambiguïse. C'est l'unique raison d'être de `board_pieces`. ## board_edges : la chaîne de lettres La lingua franca. Quatre lettres minuscules par case, ligne par ligne, en URDL, avec `letter = 'a' + colour`. La bordure est donc **`a`**, la couleur intérieure 1 est `b`, jusqu'à la couleur 22 = `w`. Une case vide est **`aaaa`**, indistinguable d'une vraie tuile toute en bordure, ce qui n'arrive jamais sur un plateau légal ; l'ambiguïté est donc sans danger. Le plateau officiel 16×16 fait `256 × 4 = 1024` lettres. ```text adca beaa … cell 0 = [0,3,2,0], cell 1 = [1,4,0,0], … ``` - **Bordure :** la lettre `a` (couleur 0). - **Restitue :** tout du plateau, le rendu complet, le score exact, et, parce que les pièces sont distinctes à rotation près, l'identité de chaque pièce et sa rotation par appariement au jeu. - **Ne restitue pas :** quelles cases étaient *données comme indices* plutôt que résolues ; c'est une propriété du puzzle, pas du plateau, et cela voyage dans `hints`. Une subtilité rare : certains outils permutent le glyphe que chaque lettre dessine (`motifs_order`). Les ordres `marie` et `jblackwood` sont identiques entre eux ; `jef` est une permutation différente. Le convertisseur et le visualiseur les retraduisent vers l'alphabet par défaut à l'entrée, si bien que vous n'avez jamais à y penser ; mais si vous voyez un plateau dont les couleurs semblent brouillées, c'est un `motifs_order` non traduit qui en est la cause. ## hints : les cases-indices Un plateau et les indices dont il est issu ont leur place au même endroit, adressés de la même façon. `hints` liste les cases-indices épinglées, chacune sous la forme `pos.rot`, l'indice de case en ordre ligne par ligne et le quart de tour horaire, joints par `-`. Cinq indices officiels font environ trente caractères. ```text hints=34.1-45.2-135.0-210.3-221.0 ``` La pièce de chaque case-indice est déjà connue par `board_edges`, donc un indice n'a besoin que de sa position et de son orientation, jamais d'un identifiant de pièce. C'est la même forme `(case, rotation)` que tout format durable emploie pour une pièce épinglée : le `x,y,rotation` du CSV, le `{pos, rot}` du JSON du site. - **Restitue :** quelles cases sont des indices, pour que le visualiseur les marque et qu'un solveur en parte. Absent signifie « aucun indice », un simple plateau résolu ou partiel. - **Se marie avec :** `board_edges`. Ensemble ils portent un *puzzle-avec-indices* entier dans un seul lien, ce qu'un plateau nu ne pourrait jamais. ## board_pieces : le canal d'interopérabilité Certains outils de la communauté, notamment les liens e2.bucas.name, portent un canal de pièces explicite : trois chiffres décimaux par case, le numéro de pièce **en base 1**, `000` pour une case vide (le plateau officiel fait `256 × 3 = 768` chiffres). Nous le **lisons** quand il est présent, mais n'avons jamais besoin de l'émettre, car `board_edges` nomme déjà chaque pièce sur un jeu aux pièces distinctes. ```text 001 005 007 … piece 1 at cell 0, piece 5 at cell 1, … ``` - **Bordure / vide :** `000`. - **Restitue :** l'identité de pièce directement (et la rotation, par appariement au jeu), la même chose que les arêtes restituent seules pour un vrai plateau. - **À lui seul :** inutile sans les arêtes ; c'est une surcouche, pas un plateau. Son seul usage irremplaçable est un jeu artificiel dont des pièces se répètent à rotation près, où les arêtes seules sont ambiguës. ## e2pieces.txt : les pièces telles que posées Le plus ancien format d'échange, couché sur le papier par la communauté en 2007 (voir le [recensement de la boîte à outils](/fr/research/build/tooling/)). Une ligne par case **remplie**, dans l'ordre de lecture, quatre entiers d'arête séparés par des blancs dans l'ordre URDL. ```text 0 3 2 0 1 4 0 0 … ``` - **Bordure :** l'entier `0`. - **Restitue :** rendu et score, comme `board_edges` ; ce sont les mêmes données en décimal. Il liste les pièces **telles que posées et tournées**, ce n'est donc *pas* un catalogue canonique à rotation 0, et un plateau seul ne peut pas l'y ramener. ## Puzzle CSV : ce que lisent les moteurs autonomes Le format que consomment le C de McGavin et le C# de Blackwood, et la forme sous laquelle sont écrits les fichiers `variant_NN.csv` du banc d'essai. Un en-tête de taille, puis une ligne par pièce : `top,right,bottom,left`, suivi optionnellement de `x,y,rotation` pour un indice épinglé. ```text 16 1111111111111111,0000000000000001,0000000000000010,1111111111111111,0,0,0 … ``` Chaque couleur est un **mot binaire 16 bits complété par des zéros**. Et voici le détail qui fait trébucher tout le monde, et la raison d'être de cette page : > **Dans le CSV, la bordure est tout en un** > > Dans le CSV de puzzle, la bordure grise est **`1111111111111111`**, tout en un, le mot 16 bits `65535`, et *non* tout en zéros. Les couleurs intérieures sont leur petit entier en binaire, donc la couleur 1 est `0000000000000001`. Un lecteur remappe le mot `65535` vers l'identifiant intérieur `0`. C'est l'inverse de tous les autres formats de cette page, où la bordure est la valeur *basse* (`a`, `0`, `000`). C'est un choix de sentinelle historique, conservé pour la compatibilité au niveau de l'octet avec les moteurs qui le lisent. - **Bordure :** le mot tout-en-un `1111111111111111` (65535). - **Restitue :** le puzzle complet, pièces et indices. C'est un format de *puzzle* (le jeu de tuiles), non un simple plateau posé. ## JSON du site (`Puzzle`) : l'entrée canonique L'unique format dont chaque algorithme est nourri : `--puzzle variant_NN.json`. Le moteur du site, les études DFS/repair et le banc d'essai monocœur lisent tous le *même* schéma (compatible au niveau de l'octet avec le type `Puzzle` du web), de sorte que toutes les expériences tournent sur les mêmes instances. Il porte explicitement le jeu de pièces à rotation 0 et les indices épinglés, ce qui en fait une entrée depuis laquelle un solveur peut démarrer, plutôt qu'un plateau qu'il aurait déjà rempli. ```json { "name": "e2_official_variant00_pin3corners", "width": 16, "height": 16, "numColors": 22, "pieces": [[0,1,2,0], [0,0,3,1], …], "hints": [{ "pos": 34, "piece": 118, "rot": 2 }, …] } ``` - **Bordure :** la couleur `0`, comme entier dans les quadruplets `pieces`. - **Restitue :** tout ce qui concerne l'*instance* : les tuiles canoniques à rotation 0, le nombre de couleurs, et chaque indice épinglé avec sa rotation exacte. C'est le seul format qui porte la rotation et l'ordre de catalogue par construction, parce qu'il décrit le puzzle, et non un placement sur celui-ci. ## Le JSON de plateau canonique (`BoardDoc`) : l'unique sortie Ce que chaque solveur du site écrit désormais : un `.json` autodescriptif par plateau. Il replie le plateau, son score, son empreinte de contenu, les deux chaînes de lettres et l'URL du visualiseur en un seul document, si bien qu'un outil en aval n'a besoin de rien d'autre. ```json { "name": "…", "size": 16, "score": 466, "breaks": 14, "board": [3, 16, 24, …], "board_hash": 2059303548241384230, "board_edges": "abda…", "board_pieces": "001005…", "url": "https://eternity2.dev/viewer?puzzle=…&puzzle_size=16&board_edges=…" } ``` `board` est le vecteur de placement **`piece*4 + rot`** en ordre ligne par ligne (`-1` pour une case vide), le même encodage par lequel le `Puzzle` du site fait son aller-retour. `breaks` vaut `max_score − score` (les arêtes intérieures non appariées ; sur un plateau plein, le nombre de cassures). `board_hash` est une empreinte FNV-1a de la grille de placement, le verrou bit-à-bit qui répond à « ces deux exécutions ont-elles produit le même plateau ». - **Bordure :** comme dans `board_edges` (`a`) et `board_pieces` (`000`) ; le vecteur `board` utilise `-1` pour le vide. - **Restitue :** tout ce qu'un plateau peut porter : rendu, score, identité et rotation (via `board_pieces` et `board`), plus la provenance (`name`, `board_hash`) et une vue en un clic (`url`). ## Les URL de visualiseur Deux URL, même plateau, deux hôtes. **eternity2.dev, le lien canonique.** Le format qu'émet chaque algorithme ici. Le plateau voyage entièrement dans `board_edges` ; les indices épinglés voyagent dans `hints`. Plateaux carrés, donc un unique `puzzle_size` (le visualiseur lit aussi les `board_w`/`board_h` de bucas), et chaque valeur reste dans la plage URL-compatible, de sorte que le lien n'a besoin d'aucun encodage-pourcent : ```text https://eternity2.dev/viewer?puzzle=NAME&puzzle_size=16&board_edges=…&hints=135.0-210.1 ``` `hints` est omis pour un plateau sans indices. Comme les arêtes portent l'identité des pièces, il n'y a pas de canal de pièces ici : le plateau et ses indices tiennent dans ces deux champs. **e2.bucas.name, le visualiseur communautaire.** L'original de Jef Bucas, le visualiseur dont le format d'URL *est devenu* tout ce vocabulaire (la [boîte à outils](/fr/research/build/tooling/) raconte cette histoire). Pleinement pris en charge en entrée, et disponible en sortie dérivée avec sa paire `board_w`/`board_h` et un fragment `#`. Nous l'émettons en arêtes seules (bucas retrouve les pièces à partir des arêtes pour un jeu distinct) ; les liens bucas d'autres outils portent souvent aussi un canal `board_pieces`, que nous lisons en entrée : ```text https://e2.bucas.name/#puzzle=NAME&board_w=16&board_h=16&board_edges=… ``` Le [visualiseur](/viewer/) lit l'un comme l'autre de façon transparente ; le [convertisseur](/convert/) vous fournit les deux. La forme eternity2.dev est canonique ici uniquement parce qu'elle ouvre le visualiseur de *ce* site, avec son scoring, sa surcouche d'indices et sa vérification du jeu de pièces ; la forme bucas reste l'original partagé de la communauté, crédité en conséquence. ## Passer de l'un à l'autre
| Format | Bordure | Porte la rotation ? | Porte l'identité ? | C'est un… | | --- | --- | --- | --- | --- | | `board_edges` | `a` | oui (par appariement) | oui (par appariement) | plateau posé | | `hints` | n/a | oui (`pos.rot`) | via les arêtes | jeu d'indices | | `board_pieces` | `000` | avec les arêtes | oui | surcouche | | `e2pieces.txt` | `0` | oui (par appariement) | oui (par appariement) | plateau posé | | Puzzle CSV | `1111…1` (tout en un) | indices seulement | oui (tuiles) | puzzle | | JSON du site | `0` | oui | oui | puzzle | | JSON `BoardDoc` | `a` / `000` / `-1` | oui | oui | plateau posé | | URL eternity2.dev | `a` | oui (par appariement) | oui (par appariement) | lien vers un plateau | | URL bucas | `a` | avec les pièces | avec les pièces | lien vers un plateau |
Chaque conversion de ce tableau est à un collage de distance dans le [convertisseur de formats](/convert/) : déposez-y une URL, une chaîne `board_edges` nue ou un bloc de paramètres, et relisez l'URL eternity2.dev, le JSON canonique, le CSV, `board_pieces`, `e2pieces.txt` et l'URL bucas, avec un aperçu en direct et le score, pour voir que le fichier est correct avant de vous y fier. ## À lire aussi - [La boîte à outils de la communauté, 2007-2026](https://eternity2.dev/fr/research/build/tooling/) — Dix-neuf ans de logiciels communautaires pour Eternity II (interfaces de placement manuel, éditeurs, solveurs publics, générateurs et visualiseurs), plus la couche plus discrète qui les a rendus interopérables : e2pieces.txt, les sommes de contrôle CRC-16 et le format plateau-dans-une-URL devenu la lingua franca. Un recensement de référence, chaque outil rattaché au message qui l'a annoncé. - [Les benchmarks de la communauté](https://eternity2.dev/fr/research/build/benchmarks/) — Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. - [Le jeu de données](https://eternity2.dev/fr/research/build/dataset/) — Un jeu de données public sous licence CC0 pour Eternity II, en deux volets : quatorze instances de référence à résoudre, et un corpus de 7 658 plateaux forts distincts dont on peut s'inspirer. Chaque score est recalculé à partir du plateau lui-même, et le corpus est vérifié comme réellement varié, plutôt que mille copies d'un même plateau. --- # GPU et matériel > Jeter du silicium contre le mur : portages GPU, pipelines FPGA, balayages distribués et l'éternelle proposition quantique. Voici le bilan de ce que chacun a réellement apporté, et pourquoi le mur qu'ils rencontrent tient à la mémoire et à la structure, non à l'arithmétique. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/hardware/ - Mise à jour: 2026-07-13 --- Jeter du silicium contre le mur : portages GPU, pipelines FPGA, balayages distribués et l'éternelle proposition quantique. Voici le bilan de ce que chacun a réellement apporté, et pourquoi le mur qu'ils rencontrent tient à la mémoire et à la structure, non à l'arithmétique. Les pages ci-dessous procèdent technique par technique : ce qu'est chacune en une ligne, ce qu'elle a effectivement atteint sur le vrai plateau 16×16, où elle s'arrête, et les expériences et mesures qui l'étayent. Pour embrasser tout le territoire d'un seul coup, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). ## Pages de cette section - [Résoudre sur GPU : le mur, c'est la mémoire, pas le calcul](https://eternity2.dev/fr/research/build/hardware/gpu-solving/) — Eternity II ressemble à la charge de travail GPU idéale : des millions de sous-arbres indépendants, massivement parallèles. Dix-huit ans de tentatives de la communauté ont mesuré une tout autre réalité : branchement divergent, état par thread qui déborde de la mémoire rapide, et une boucle de placement déjà limitée par la mémoire sur CPU. Ce que les GPU ont réellement donné, et la seule charge où ils brillent vraiment. - [Résolution sur FPGA : cartographiée, mais jamais parcourue](https://eternity2.dev/fr/research/build/hardware/fpga-solving/) — Si la boucle de placement est limitée par la latence mémoire, un FPGA semble la réponse exacte : loger les tables de correspondance dans la block RAM embarquée, à un cycle de distance, et pipeliner des dizaines de petits backtrackers sur une même puce. La communauté a cartographié cette route en détail. Michael Field a conçu le solveur, projeté cinq milliards de placements par seconde et par puce, et fait tourner un prototype sur silicium réel. Puis la route n'a jamais été parcourue jusqu'au bout. Le dossier complet, et pourquoi. - [Approches quantiques : deux accélérations à leur vrai prix](https://eternity2.dev/fr/research/build/hardware/quantum/) — L'ordinateur quantique est le plus ancien deus ex machina de la liste, invoqué dès le premier mois du casse-tête et tous les quelques ans depuis. Il n'existe qu'exactement deux histoires réelles à raconter : l'accélération quadratique de Grover et le recuit sur un encodage QUBO. Cette page les raconte proprement toutes deux, fait le calcul face aux chiffres réels d'Eternity II, et rapporte l'intégralité des traces de la communauté : dix-neuf ans de digressions, une tentative d'embedding inachevée, zéro exécution. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. --- # Résolution sur FPGA : cartographiée, mais jamais parcourue > Si la boucle de placement est limitée par la latence mémoire, un FPGA semble la réponse exacte : loger les tables de correspondance dans la block RAM embarquée, à un cycle de distance, et pipeliner des dizaines de petits backtrackers sur une même puce. La communauté a cartographié cette route en détail. Michael Field a conçu le solveur, projeté cinq milliards de placements par seconde et par puce, et fait tourner un prototype sur silicium réel. Puis la route n'a jamais été parcourue jusqu'au bout. Le dossier complet, et pourquoi. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/hardware/fpga-solving/ - Mise à jour: 2026-07-02 - Sujets: speed, hardware - Source: La première proposition FPGA : la couverture exacte en matériel (groups.io message 2623, 2007) — https://groups.io/g/eternity2/message/2623 - Source: Le plan Altera de Bob Cousins pour Eternity I et le goulot d'étranglement des communications (groups.io message 3259, 2007) — https://groups.io/g/eternity2/message/3259 - Source: Le VHDL d'échange d'arêtes de Mike Pringle : le premier HDL réellement écrit (groups.io message 5493, 2008) — https://groups.io/g/eternity2/message/5493 - Source: 'E2 in hardware...', l'échange sur la faisabilité de 2010 (groups.io message 8063) — https://groups.io/g/eternity2/message/8063 - Source: L'analyse mémoire de Field : 'these problems also carry over to FPGAs' (groups.io message 9003, 2011) — https://groups.io/g/eternity2/message/9003 - Source: Le design de 2014 : restriction uniforme au 15×15, ~4 Ko de tables, 5 G placements/s/puce projetés (groups.io message 9226) — https://groups.io/g/eternity2/message/9226 - Source: Les tables de correspondance, bit par bit (groups.io message 9228, 2014) — https://groups.io/g/eternity2/message/9228 - Source: La refonte hyper-pipelinée après le bug de bande passante mémoire (groups.io message 9232, 2014) — https://groups.io/g/eternity2/message/9232 - Source: Premier essai sur silicium réel : un thread, une LED (groups.io message 9236, 2014) — https://groups.io/g/eternity2/message/9236 - Source: Le bug de symétrie corrigé ; le matériel parcourt l'arbre complet du benchmark (groups.io message 9237, 2014) — https://groups.io/g/eternity2/message/9237 - Source: La rétrospective de Field lui-même : 'a fun deadend' (groups.io message 10649, 2022) — https://groups.io/g/eternity2/message/10649 - Source: L'unique tentative FPGA académique, ReConFig 2011 (ieeexplore 6044826 ; discutée dans le message 10651) — https://ieeexplore.ieee.org/document/6044826 --- La [page GPU](/fr/research/build/hardware/gpu-solving/) se termine sur un mur : un backtracker d'Eternity II n'est pas limité par le calcul, c'est une chaîne de petites lectures mémoire dépendantes, et l'analyse de Mike Field en 2011 montrait que les deux branches GPU (coopérer ou travailler seul) butent toutes deux sur le bus mémoire externe ([message 9003](https://groups.io/g/eternity2/message/9003)). Un FPGA est la seule pièce de silicium qui semble répondre précisément à cette objection. Il n'y a pas de hiérarchie de cache à manquer : les tables de correspondance vivent dans la block RAM embarquée, à un cycle d'horloge, réparties en des dizaines de petites mémoires indépendantes que l'on peut toutes lire *dans le même cycle*. Les décalages de bits et les masques qui coûtent des instructions sur un CPU deviennent gratuits, câblés dans la logique. Et au lieu d'un seul gros cœur rapide, on dépose de nombreux petits cœurs lents, chacun un backtracker complet avec ses propres tables. La communauté a repéré cette route très tôt et l'a cartographiée à fond. Un membre a conçu le solveur, publié le chemin de données, projeté cinq milliards de placements par seconde et par puce, et fait tourner un prototype sur du matériel réel. Puis - et cette page existe pour le dire clairement - personne n'a jamais parcouru la route jusqu'au bout. Aucune exécution FPGA sur Eternity II complet n'a jamais été rapportée, en dix-neuf ans d'archives. Ce qui est intéressant, c'est que les raisons figurent elles aussi au dossier, dans les propres mots du concepteur. ## Pourquoi les FPGA répondent au mur exact que rencontrent les GPU Rappelons la bifurcation issue de l'analyse de Field (racontée en entier sur la [page GPU](/fr/research/build/hardware/gpu-solving/)) : les chercheurs parallèles soit partagent de l'information, ce qui exige une bande passante de synchronisation dont le tissu logique ne dispose pas, soit travaillent indépendamment, ce qui exige un état par ouvrier dépassant les ~8 Ko de mémoire rapide alloués à une voie GPU, déversant tout sur un unique bus externe partagé. Son message de 2011 appliquait le même argument aux FPGA dans la foulée : « either need to store too much information, pass too much information around or it choke[s] on memory bandwidth » ([message 9003](https://groups.io/g/eternity2/message/9003)). Mais la version FPGA de l'argument comporte une échappatoire que la version GPU n'a pas. Sur un GPU, le budget de mémoire rapide par ouvrier est fixé par le constructeur. Sur un FPGA, c'est *vous* qui dessinez la carte mémoire : si vous parvenez à réduire tout l'univers d'un backtracker (tables de candidats, état du plateau, ensemble des pièces utilisées) assez petit, vous pouvez l'instancier entièrement en block RAM, le répliquer cinquante fois, et aucun ouvrier ne touchera jamais la mémoire externe. Le mur de bande passante n'est pas franchi ; il est supprimé. Toute l'histoire FPGA de ces archives est la poursuite de ce « si » : rendre l'état du solveur assez petit et *uniforme* pour qu'il devienne matériel. Il a fallu six années de réflexion en arrière-plan à un membre pour y arriver, et la réponse a exigé de changer le problème. ## Les esquisses : 2007–2012 Les FPGA font leur entrée dans les archives quelques semaines à peine après le puzzle lui-même. En août 2007, psykowally, renonçant à un énième brute-forcer logiciel, songeait à le faire « in FPGA or something » tout en devinant que cela ne ferait « take off a few factors » ([message 2022](https://groups.io/g/eternity2/message/2022)), une supposition que les sept années suivantes ne cesseraient de confirmer. En septembre, Dieter Gehrke demandait si quelqu'un avait envisagé la couverture exacte en matériel, en pointant une implémentation FPGA académique ([message 2623](https://groups.io/g/eternity2/message/2623)). Personne ne l'avait fait. Le fil du sondage de novembre 2007 (« purpose built electronics » recueillit exactement une voix, comme le nota son unique votant) produisit la première vraie discussion d'ingénierie. Bob Cousins avait déjà acheté un kit d'évaluation Altera *pour Eternity I*, planifié un accélérateur FPGA pour un backtracker logiciel, et abandonné : même à 10 millions de positions par seconde en matériel, le goulot d'étranglement était la communication avec le PC ([message 3259](https://groups.io/g/eternity2/message/3259)). Glen Dudley mit le doigt sur ce qui fait que le backtracking gaspille du silicium : placez 200 pièces, revenez-en de cinq, et la valeur de 195 cellules de matériel dédié reste inactive ce cycle-là ([message 3260](https://groups.io/g/eternity2/message/3260)). Un autre membre annonça qu'il « just started » un design VHDL et cherchait des collaborateurs ([message 3266](https://groups.io/g/eternity2/message/3266)) ; on n'entendit plus jamais parler de lui sur le sujet. Un troisième aligna les chiffres qui dégrisent : troquer l'horloge d'un cœur de PC contre le parallélisme d'un FPGA coûte 10 à 1000× à l'entrée, et l'on serait « better off... just using multiple computers » ([message 3268](https://groups.io/g/eternity2/message/3268)). Le SAT-en-matériel subit le même tri en 2008 : des millions de termes de clauses ne tiennent pas dans la logique du plus grand FPGA ([message 4723](https://groups.io/g/eternity2/message/4723)). Une seule personne écrivit réellement du HDL. En mai 2008, Mike Pringle décrivit un chercheur local par échange d'arêtes dont la fonction d'aptitude (compter les pièces valides et uniques qu'implique l'affectation d'arêtes courante) était conçue pour *échanger et scorer en une seule horloge*. « I have the VHDL done for this but I ran out of FPGA resources on the evaluation board I have for anything over 8×8 » ([message 5493](https://groups.io/g/eternity2/message/5493)). Premier HDL du dossier, premier mur de ressources du dossier, même message. Puis vint le protagoniste. En octobre 2010, Michael Field, l'ingénieur dont le budget de 26 cycles par placement ancre la [page consacrée à l'ingénierie des solveurs](/fr/research/build/faster/solver-engineering/), ouvrit un fil intitulé « E2 in hardware... », ayant commencé à jouer avec des cartes FPGA Digilent. Sa première estimation sobre : un backtracker matériel tournerait « roughly as fast as a PC's cpu core » ; le vrai gain serait une vérification de contraintes massivement parallèle, la cohérence d'arc évaluée à chaque étape ([message 8063](https://groups.io/g/eternity2/message/8063)). La réponse coût/bénéfice de Martin (capiman) tint la route : un backtracker matériel n'égale qu'un des quatre cœurs déjà présents dans votre PC, donc seuls les usages en logique parallèle sont intéressants, et les ~2 816 bits d'état de plateau que réclame un tissu de cohérence d'arc complet pourraient ne pas tenir dans le plus grand FPGA du marché ([message 8064](https://groups.io/g/eternity2/message/8064)). Field esquissa un tissu de 256 cellules avec 18 bits de motif par côté et un bus de requête de pièces, et conclut par la phrase qui pourrait servir de légende à toute cette page : « no matter what it won't be a silver bullet » ([message 8065](https://groups.io/g/eternity2/message/8065)). En 2012, il avait conclu que les FPGA étaient « next to useless for implementing an E2 back-tracker » : la boucle de rétroaction entre plateau et sac est trop serrée, si bien que « the clock speed of a CPU wins », et il se demandait plutôt s'il fallait utiliser le tissu pour générer des jeux de rotations qu'un CPU vérifierait ([message 9069](https://groups.io/g/eternity2/message/9069)). ## Le design de Field en 2014 : acheter l'uniformité, la payer en généralité Le 7 février 2014, Field publia « Solving Eternity II in FPGA hardware » : le problème avait « been sitting in my subconscious, slowly chewing over it for about 6 years. Last night I had a bit of an eureka moment » ([message 9226](https://groups.io/g/eternity2/message/9226)). Son ancien solveur logiciel de classe record ne pouvait pas devenir matériel pour deux raisons qu'il nomma précisément : il exigeait une table de correspondance de ~6 Mo (17×17×17×17×15 entrées de 32 bits) à accès véritablement aléatoire, et la boucle placer-vérifier-revenir n'a presque aucun parallélisme à grain fin. L'eurêka fut de *relâcher le problème* jusqu'à ce que le chemin de données devienne uniforme : - **Ne faire du backtracking que sur le 15×15 en haut à gauche** (jamais la colonne de droite ni la ligne du bas), et n'utiliser aucune pièce indice. - Remplir du haut-gauche vers le bas-droite, de sorte que la recherche de candidats de **chaque** cellule soit indexée de la même façon : par les couleurs de ses arêtes du haut et de gauche. Aucun cas particulier, aucune table par cellule, un circuit identique, partout. Cette uniformité fit s'effondrer le problème mémoire. Toute la structure de correspondance tenait dans environ **4 096 octets de ROM** plus ~1 Ko d'état par solveur ([message 9226](https://groups.io/g/eternity2/message/9226)) : une table de tuiles de 1024 entrées, large de 18 bits (numéro de tuile, motif de droite, motif du bas, triés par motifs haut/gauche) plus un index de 324 entrées donnant pour chaque paire de couleurs son début et son décompte ([message 9228](https://groups.io/g/eternity2/message/9228)). En matériel, notait-il, les décalages et les masques sont du câblage gratuit, les deux tables résident dans des BRAM différentes, donc les deux recherches se font en parallèle, et la lecture-écriture au même cycle de la block RAM offre un test-and-set atomique sur le bit de pièce utilisée : tout le trafic mémoire de la boucle interne, à un cycle de distance. Comparez ces 4 Ko au « >8 Ko par thread » fatal de la [page GPU](/fr/research/build/hardware/gpu-solving/) : voilà à quoi ressemble la suppression du mur de bande passante. La projection : environ **50 instances de solveur sur un Zynq 7020 à ~200 MHz**, chaque placement/déplacement coûtant en moyenne ~2 cycles, « up to 5 billion tile placements per second per chip » ([message 9226](https://groups.io/g/eternity2/message/9226)). À titre de comparaison, les meilleurs cœurs CPU de l'époque faisaient 70 à 115 millions. ## Ce qui a réellement tourné Le mois suivant est la mise en route matérielle la mieux documentée des archives, et chaque étape mérite d'être consignée, car chacune céda un peu de la projection. - **20 février.** La simulation place ses premières tuiles ; la synthèse annonce >109 MHz sur un Spartan-6 LX9 en utilisant ~10 % de sa logique ; près de 50 M placements/s par instance en début de puzzle, se dégradant à mesure que davantage de pièces sont utilisées et que des cycles sont dépensés à les éviter ([message 9231](https://groups.io/g/eternity2/message/9231)). - **25 février.** La première victime au dossier : le design « didn't pan out, I had memory bandwidth issues during a 'tile lift' » (déplacer une pièce exige deux écritures à la fois, et un port de BRAM reste un port de BRAM). Le correctif est élégant : un **hyper-pipeline** à quatre étages, quatre backtrackers indépendants se partageant dans le temps un unique chemin de données, de sorte que l'accès mémoire de chaque étage ait lieu dans son propre cycle. Timing : 132,363 MHz ; coût par cœur de 96 registres et 334 LUT ; une estimation de 10 cœurs sur le petit LX9 ou 50 sur un LX45, « around 5,000M 'actions' per second » ([message 9232](https://groups.io/g/eternity2/message/9232)). - **1er mars : silicium réel.** Arnaud Carré avait fourni un benchmark 16×16 à 29 couleurs que son solveur CPU optimisé parcourt entièrement en 34,75 s à 114,5 M récursions/s sur un cœur i7-3770K ([message 9234](https://groups.io/g/eternity2/message/9234)). Field le chargea dans du matériel réel à 200 MHz, la sortie étant limitée, pour l'instant, à une unique LED qui s'allume tant qu'un thread tourne. La LED s'éteignit après 1 min 21 s ; son calcul de coin de table estimait chaque thread à environ un tiers d'un thread i7, et un build à quatre cœurs, seize threads, sur sa carte alimentée par USB à ~800 M vérifications/s. Il publia le design sur son site ([message 9236](https://groups.io/g/eternity2/message/9236)). Deux jours plus tard, il trouva le défaut dans cette comparaison et révisa le chiffre à la baisse, à 1/8 ; le nombre corrigé figure plus bas. - **3 mars : le bug de symétrie.** La comparaison des décomptes avec Arnaud révéla que la tuile fixe en haut à gauche de Field faisait le quart du travail du benchmark. Corrigé, un thread matériel parcourt l'arbre entier en 199 secondes, « about an 1/8th of the speed of Arnaud's i7 solver running on one core », mais 24 threads tiennent sur une carte à moins de 100 $, et un pipeline à 8 étages devrait en permettre 48. Le matériel trouva et imprima les quatre solutions, horodatages et plateaux dans le message ([message 9237](https://groups.io/g/eternity2/message/9237)). Et c'est là que le dossier s'arrête. Le pipeline à 8 étages, les 48 threads, le portage sur Zynq, l'exécution du puzzle complet : aucun d'eux n'apparaît jamais dans les archives. mulisak demanda comment se lancer, et Field répondit par des liens vers des chaînes d'outils et son propre livre gratuit sur les FPGA ([message 9245](https://groups.io/g/eternity2/message/9245)) ; le 1er avril, mulisak proposa « e2coin », une cryptomonnaie dont la preuve de travail serait l'appariement d'arêtes, en soutenant qu'E2 est « CPU friendly - GPU unfriendly - but... FPGA friendly » ([message 9260](https://groups.io/g/eternity2/message/9260)) ; le fil dériva vers des benchmarks CPU, et le matériel se tut. ## Pourquoi rien n'a abouti **Rien n'a abouti, et le concepteur en a dit la raison.** En janvier 2022, Jef Bucas demanda si quelqu'un avait accès à un article IEEE sur les FPGA et Eternity II, et la réponse de Field est la rétrospective sur laquelle cette page est bâtie : « The E2 problem is correctly sized to make an FPGA solver hard :) ». À cause de la rétroaction serrée entre plateau et sac, il « couldn't get faster than a single core on a low-end PC (~75M tiles per sec) », et la mémoire des tables de correspondance « is high enough that you quickly exhaust on-chip RAM if you are trying multiple instances. It was a fun deadend for me » ([message 10649](https://groups.io/g/eternity2/message/10649)). Lisez cela au regard de la projection : le chiffre de 5 G/s supposait cinquante instances, et la BRAM même qui rendait une instance rapide est ce qui plafonnait le nombre d'instances qui tiennent. Les propres rapports de synthèse du prototype l'avaient annoncé : un seul cœur de la taille du benchmark réclamait déjà 23 des 64 blocs RAM du LX9 ([message 9236](https://groups.io/g/eternity2/message/9236)). **L'économie non plus n'a jamais tenu.** Le seul membre à avoir tenté les deux mondes, valy, se souvenait de la carte de Field avec affection (« he was crunching 15 Mn/s on an FPGA platform. Perf/W maybe unbeatable », [message 9588](https://groups.io/g/eternity2/message/9588)), puis décrivait le coût : le travail sur FPGA est « soooo slow to compile... code... debug... You need to be an expert or have plenty of spare time and motivation. I've tried once, that was my hardest programming experience » ([message 9590](https://groups.io/g/eternity2/message/9590)). Des mois de mise en route HDL achetèrent ce que le [registre de l'ingénierie des solveurs](/fr/research/build/faster/solver-engineering/) obtient d'un simple drapeau de compilation. Cette asymétrie, et non un quelconque mur technique isolé, explique pourquoi chaque fil FPGA des archives se termine dans le silence : le « FPGA custom engine in 2022 » promis par un membre en 2021 ([message 10581](https://groups.io/g/eternity2/message/10581)) est le dernier de la lignée, et lui non plus n'a jamais refait surface. **L'unique tentative menée à terme fut académique, et elle fit moins bien que le logiciel.** L'article demandé par Bucas, « Exploitation of Parallel Search Space Evaluation with FPGAs in Combinatorial Problems: The Eternity II Case » (ReConFig 2011, [ieeexplore 6044826](https://ieeexplore.ieee.org/document/6044826)), est le seul système FPGA Eternity II achevé et publié de tout le dossier. Son bilan, tel que la liste le lut : « After three months, the best available solution contained 187/196 center pieces » ([message 10651](https://groups.io/g/eternity2/message/10651)), bien en deçà de ce que produisaient les heuristiques logicielles de l'époque. Le verdict de Bucas fut celui de la communauté : « a bit disappointed by the results in term of speed... I would expect more from a 'dedicated' HW » ([message 10655](https://groups.io/g/eternity2/message/10655)). ## Le dossier, en un coup d'œil | Qui | Quand | Ce qui s'est passé | Msg | | --- | --- | --- | --- | | psykowally | 2007 | Première mention d'un FPGA ; devine « a few factors » d'accélération | [2022](https://groups.io/g/eternity2/message/2022) | | Dieter Gehrke | 2007 | Propose la couverture exacte en matériel FPGA ; aucun preneur | [2623](https://groups.io/g/eternity2/message/2623) | | Bob Cousins | 2007 | Plan d'accélérateur Altera de l'ère E1, abandonné sur le goulot des comms PC ; idée hybride | [3259](https://groups.io/g/eternity2/message/3259) | | jp_yahoo | 2007 | Démarre un design VHDL, cherche des collaborateurs ; plus jamais entendu | [3266](https://groups.io/g/eternity2/message/3266) | | Mike Pringle | 2008 | Recherche locale par échange d'arêtes, VHDL écrit ; à court de ressources au-delà du 8×8 | [5493](https://groups.io/g/eternity2/message/5493) | | Field & Martin | 2010 | Échange sur la faisabilité : un backtracker matériel n'égale qu'un cœur de CPU | [8063](https://groups.io/g/eternity2/message/8063), [8064](https://groups.io/g/eternity2/message/8064) | | Mike Field | 2011–12 | L'analyse mémoire « carries over to FPGAs » ; verdict « next to useless » pour le backtracking | [9003](https://groups.io/g/eternity2/message/9003), [9069](https://groups.io/g/eternity2/message/9069) | | Mike Field | 2014 | Le design : 15×15 uniforme, tables de 4 Ko, 50 instances @ 200 MHz, 5 G/s/puce projetés | [9226](https://groups.io/g/eternity2/message/9226), [9228](https://groups.io/g/eternity2/message/9228) | | Mike Field | 2014 | Construit et mesuré : prototype hyper-pipeliné parcourant un benchmark 16×16 sur silicium ; 1 thread ≈ 1/8 de cœur i7 (sa propre correction d'un 1/3 initial) | [9237](https://groups.io/g/eternity2/message/9237) | | mulisak | 2014 | e2coin : E2 comme preuve de travail FPGA-friendly ; posté le 1er avril, sans écho | [9260](https://groups.io/g/eternity2/message/9260) | | équipe académique | 2011 | Seul système FPGA achevé ; 3 mois → 187/196 pièces du centre | [10651](https://groups.io/g/eternity2/message/10651) | | Brahim Hamadicharef | 2021 | Annonce un « FPGA custom engine in 2022 » ; plus jamais mentionné | [10581](https://groups.io/g/eternity2/message/10581) | | Mike Field | 2022 | La rétrospective : « a fun deadend », l'épuisement de la BRAM plafonne les instances | [10649](https://groups.io/g/eternity2/message/10649) | ## L'arithmétique qui mord toujours Accordez à la projection tout ce qu'elle a demandé. Disons que la puce à 50 cœurs, 200 MHz, ait été livrée à ses pleins **5×10⁹ placements/s**, et disons que vous ayez rempli un rack de deux mille d'entre elles : **10¹³ placements par seconde**, plus que la flotte combinée de toute la communauté n'en a jamais aligné. Une année vaut ~3×10⁷ secondes, donc le rack parcourt ~3×10²⁰ nœuds par an. L'arbre de recherche du puzzle complet est, à son plateau, large de l'ordre de **10⁴⁵ plateaux partiels** ([la théorie de la complexité](/fr/research/why/complex-theory/) fait cette mesure correctement). La division : environ **10²⁴ rack-années**. Chaque ordre de grandeur que le matériel gagne déplace cet exposant d'une unité, et il en manque vingt-quatre. C'est la même phrase sur laquelle se termine la page GPU, car c'est la même mathématique : le matériel est un diviseur constant, et le mur d'E2 est exponentiel. [Pourquoi un ordinateur plus rapide n'aide pas](/fr/research/why/prune-vs-speed/) mène l'argument général ; le chapitre FPGA n'en est que l'étude de cas la plus nette, car ici même les nombres *projetés* (sans parler des nombres mesurés) concèdent le point avant que la division ne commence. ## Ce que viserait aujourd'hui une tentative sur FPGA La carte est toujours sur la table, et certaines de ses parties ont bien vieilli. La propre mise en garde de Field en 2022 joue désormais dans l'autre sens : « cheaper FPGAs are now much larger » ([message 10649](https://groups.io/g/eternity2/message/10649)) : une pièce moderne de milieu de gamme porte des mégaoctets de block RAM là où son Spartan-6 avait des kilooctets, si bien que le plafond du nombre d'instances qui tuait la projection de 2014 s'est réellement relevé. Mais la liste des cibles qui résistent à l'examen est la même que celle à laquelle aboutit la [page GPU](/fr/research/build/hardware/gpu-solving/) : - **Pas la recherche.** Une tentative de record a besoin d'heuristiques, de redémarrages, et de la liberté de changer l'ordre de remplissage en cours de campagne, tout ce que Field a cédé pour rendre le chemin de données uniforme. Le relâchement au 15×15 qui a rendu le matériel possible est exactement ce qu'un chasseur de record ne peut pas accepter. - **Énumération et vérification.** Les balayages exhaustifs à forme fixe (re-vérification de recensement, comptage de lignes et de blocs, sous-puzzles bornés) sont uniformes par construction : la propriété que Field a dû acheter, ces charges de travail l'obtiennent gratuitement. Son prototype avait déjà démontré l'acte essentiel, parcourir un arbre de benchmark 16×16 complet sur silicium et y trouver exactement ses quatre solutions ([message 9237](https://groups.io/g/eternity2/message/9237)). - **Placements par watt.** Le créneau que personne n'a contesté : le « perf/W maybe unbeatable » de valy ([message 9588](https://groups.io/g/eternity2/message/9588)) tient toujours pour quiconque fait tourner un recensement de fond sur plusieurs années, où le budget est la facture d'électricité, non le débit de placements. La route, autrement dit, mène quelque part, simplement pas à 480. Elle a été cartographiée par quelqu'un qui connaissait à la fois le logiciel et le silicium mieux que quiconque sur la liste, parcourue jusqu'à la première sortie, et soigneusement balisée au retour : une impasse amusante, correctement dimensionnée pour en être une. ## À lire aussi - [Résoudre sur GPU : le mur, c'est la mémoire, pas le calcul](https://eternity2.dev/fr/research/build/hardware/gpu-solving/) — Eternity II ressemble à la charge de travail GPU idéale : des millions de sous-arbres indépendants, massivement parallèles. Dix-huit ans de tentatives de la communauté ont mesuré une tout autre réalité : branchement divergent, état par thread qui déborde de la mémoire rapide, et une boucle de placement déjà limitée par la mémoire sur CPU. Ce que les GPU ont réellement donné, et la seule charge où ils brillent vraiment. - [Ingénierie de solveur : l'artisanat sous l'algorithme](https://eternity2.dev/fr/research/build/faster/solver-engineering/) — Tous les solveurs record exécutent le même backtracking en profondeur d'abord. Ce qui les distingue, c'est la couche en dessous : tables de correspondance, hachages parfaits, structs taillées pour le cache, code généré, archéologie du compilateur. C'est cet artisanat qui décide si un nœud coûte 26 cycles ou 2 600. Vingt ans de registre d'ingénierie de la communauté, technique par technique, et ce que tout cela a rapporté. - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. --- # Résoudre sur GPU : le mur, c'est la mémoire, pas le calcul > Eternity II ressemble à la charge de travail GPU idéale : des millions de sous-arbres indépendants, massivement parallèles. Dix-huit ans de tentatives de la communauté ont mesuré une tout autre réalité : branchement divergent, état par thread qui déborde de la mémoire rapide, et une boucle de placement déjà limitée par la mémoire sur CPU. Ce que les GPU ont réellement donné, et la seule charge où ils brillent vraiment. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/hardware/gpu-solving/ - Mise à jour: 2026-07-02 - Sujets: speed, hardware - Source: La première proposition de solveur GPU : « peut-être 4 ou 5 fois » (groups.io message 351, 2007) — https://groups.io/g/eternity2/message/351 - Source: La question CUDA et un solveur CSP en GLSL en cours (groups.io message 5407, 2008) — https://groups.io/g/eternity2/message/5407 - Source: « Quelqu'un utilise-t-il OpenCL pour E2 ? », la première discussion OpenCL (groups.io message 7653, 2010) — https://groups.io/g/eternity2/message/7653 - Source: L'analyse de bande passante mémoire de Mike Field, l'argument négatif définitif (groups.io message 9003, 2011) — https://groups.io/g/eternity2/message/9003 - Source: Le solveur OpenCL fonctionnel de David Barr (groups.io message 9360, 2015) — https://groups.io/g/eternity2/message/9360 - Source: Le solveur de Barr publié en open source (github.com/david3x3x3/eternity2) — https://github.com/david3x3x3/eternity2 - Source: Le solveur de calcul DirectX 12 d'Adam Miles sur une Xbox One X (groups.io message 9811, 2018) — https://groups.io/g/eternity2/message/9811 - Source: Le résultat : le 9×9 jeu 1 revérifié exhaustivement en 25 h 24 (groups.io message 9822, 2018) — https://groups.io/g/eternity2/message/9822 - Source: Miles sur le vrai problème du parallélisme : garder chaque processeur occupé (groups.io message 9984, 2020) — https://groups.io/g/eternity2/message/9984 - Source: Le bilan de Blackwood : GPU mesuré pendant la campagne du record, mais pas conservé (groups.io message 10056, 2020) — https://groups.io/g/eternity2/message/10056 - Source: La RTX 4090 louée de Barr : 3,17 milliards de placements/s sur un 10×10, limitée par la mémoire sur le puzzle complet (groups.io message 11598, 2025) — https://groups.io/g/eternity2/message/11598 --- Sur le papier, Eternity II est le problème GPU parfait. Fixez les deux premières rangées du plateau et vous obtenez des millions de sous-arbres totalement indépendants ; rien de ce qu'apprend un sous-arbre n'a la moindre importance pour un autre. « Massivement parallèle » est le terme des manuels, et un GPU moderne offre des dizaines de milliers de voies parallèles et des téraflops de calcul à saturer. La communauté l'a vu immédiatement (la première proposition de solveur GPU date de juin 2007, quelques semaines avant même la sortie du puzzle) et n'a cessé de le revoir pendant dix-huit ans, dans un fil littéralement intitulé « Graphic cards as CPU's? » qui a refait surface en 2010, 2011 et 2019. La réponse mesurée, à travers chaque implémentation réelle, est que les téraflops ne sont pas la ressource qui compte. Un backtracker d'Eternity II passe sa vie à faire de minuscules consultations de tables et à brancher sur les résultats : une charge qui était *déjà* bloquée sur les accès mémoire sur CPU, et que les GPU aggravent de deux manières précises et bien comprises. Cette page retrace l'argument à travers ceux qui l'ont porté : le [bilan des impasses](/fr/research/build/dead-ends/) en donne le verdict en un paragraphe ; voici le pourquoi. ## Pourquoi ça a l'air parfait L'idée est arrivée avant le matériel. En juin 2007, Simon Chapple a évoqué la résolution par force brute sur les cartes 8800 de Nvidia, et un membre postant sous le nom de James a estimé qu'un GPU pourrait rendre un solveur « peut-être 4 ou 5 fois » plus rapide ([message 351](https://groups.io/g/eternity2/message/351), [message 355](https://groups.io/g/eternity2/message/355)). Cette estimation se révélerait plus proche de la vérité que ne le laissaient croire les rapports de téraflops. (La même année, le premier fil « GPU » de la liste portait en réalité sur une *Gnutella* Processing Unit, ce qui relève du [calcul distribué](/fr/research/build/faster/distributed-solving/) et non du graphisme ([message 3020](https://groups.io/g/eternity2/message/3020)).) En mai 2008 vint la question CUDA (quelqu'un a-t-il essayé de faire tourner des backtrackers sur 96 à 128 cœurs GPU ?), à laquelle répondit un membre qui était « presque au bout » d'un solveur CSP en GLSL et préférait GLSL pour ses exigences matérielles plus faibles ([message 5407](https://groups.io/g/eternity2/message/5407), [message 5409](https://groups.io/g/eternity2/message/5409)). On n'entendit plus jamais parler de ce solveur. En 2010, Thomas posa la première question OpenCL sous la forme la plus citable de l'archive : il possédait désormais du matériel capable de plus de 10¹² opérations par seconde, « mais malheureusement il me manque un programme adapté qui puisse l'exploiter » ([message 7653](https://groups.io/g/eternity2/message/7653)). Cette phrase est tout le sujet en miniature. Les opérations par seconde étaient bien réelles. Le programme adapté était la partie difficile, et les raisons pour lesquelles elle est restée difficile ont été diagnostiquées avec précision, un an plus tard. ## L'analyse de Field : la bifurcation sans bonne branche En novembre 2011, dans ce même fil récurrent, Mike Field - dont le budget au cycle près de son propre moteur ancre la [page ingénierie de solveur](/fr/research/build/faster/solver-engineering/) - a publié l'analyse négative définitive de l'archive ([message 9003](https://groups.io/g/eternity2/message/9003), correction de coquille au [message 9004](https://groups.io/g/eternity2/message/9004)). Son point de départ était une mesure, pas une opinion : son backtracker plaçait 75 millions de tuiles par seconde et par cœur sur un AMD à 2 GHz (environ 26 cycles d'horloge par tuile), et le nombre brut d'instructions revenait à peu près à la moitié, de sorte que **plus de 50 % du temps le code était bloqué sur les accès mémoire**. La boucle interne d'un solveur Eternity II n'est pas du calcul. C'est une chaîne de petites lectures dépendantes : table des candidats, données des pièces, état du plateau, branchement. À partir de là, Field a posé une bifurcation. Projetez la recherche sur un GPU et chaque processeur de flux soit coopère avec ses voisins, soit travaille seul : - **S'ils coopèrent**, ils doivent partager de l'information en permanence, et la bande passante de synchronisation que cela exige est précisément ce que les GPU ne fournissent pas. Il n'y a pas de « gigantesque crossbar » entre les processeurs de flux ; le tissu a été conçu pour des pixels qui ne se parlent pas. - **S'ils travaillent seuls** (disons 1 024 backtrackers indépendants), alors chacun a besoin de sa propre définition du problème et de son propre état de recherche : les tables de tuiles, le plateau, le code pour les traiter. Ce paquet est petit selon les standards CPU et pourtant **trop gros pour les ~8 Ko de mémoire locale rapide dont dispose chaque processeur de flux**. L'état déborde vers la mémoire externe du GPU, et chaque solveur de la puce fait désormais la queue pour le même bus mémoire. L'une comme l'autre branche aboutit au même mur : la bande passante de la mémoire externe. Et Field a ajouté la nuance qui rend ce mur particulièrement tenace pour ce puzzle : presque chaque variable qu'un solveur E2 manipule tient sur 16 bits, si bien que ce dont la recherche a besoin, ce sont davantage de *transactions* mémoire à des fréquences plus élevées, pas des bus plus larges : « un bus mémoire de 128 bits sera à peine plus rapide qu'un bus de 16 bits ». Élargir la lance à incendie ne sert à rien quand on sirote à la paille. Sa conclusion couvrait les [FPGA](/fr/research/build/hardware/fpga-solving/) avec le même argument, et il ne voyait aucune de ces pistes gagner un ordre de grandeur sur un cœur CPU. Son conseil pratique : « procurez-vous un AMD Hex core à double socket... et ayez énormément de chance » ([message 9003](https://groups.io/g/eternity2/message/9003)). Rien de ce qui a été mesuré depuis n'a renversé cela. C'est l'ancre à laquelle tient le reste de la page. ## Le second mur : la divergence, ou l'armée oisive L'argument de Field porte sur l'endroit où vivent les octets. L'autre mur porte sur la manière dont les GPU exécutent : les voies tournent en groupes synchronisés, et un groupe avance à la vitesse de la voie qui a encore du travail. Le backtracking est le flux de contrôle le plus divergent qu'on puisse imaginer. Deux recherches qui partent de préfixes adjacents se retrouvent dans des états de plateau complètement différents en quelques placements, l'une revenant en arrière à la profondeur 40 pendant que sa voisine avance à la profondeur 55. Adam Miles, ingénieur graphique qui avait effectivement construit le solveur GPU le plus rapide de l'archive (ci-dessous), a énoncé le problème à partir de son expérience : le plus difficile est de « garder chaque processeur en train de faire quelque chose d'utile à chaque cycle d'horloge » (certains threads tombent tout simplement à court de tuiles candidates et attendent), et puisque personne n'a d'algorithme prouvé meilleur que la force brute, « le temps passé à communiquer est du temps qui n'est pas passé à calculer » ([message 9984](https://groups.io/g/eternity2/message/9984)). David Barr a heurté le même mur au niveau de la granularité d'ordonnancement en 2025 : répartissez la recherche entre les workers et certains sous-arbres prennent bien plus de temps que d'autres, si bien qu'une exécution se termine avec « un nombre décroissant de workers actifs » monopolisant tout le GPU pendant que des milliers de voies restent oisives ([message 11598](https://groups.io/g/eternity2/message/11598)). Les sous-arbres massivement parallèles sont bien réels ; ils sont simplement massivement *inégaux*. ## Ce qui a quand même été construit La communauté ne s'est pas arrêtée à l'analyse ; elle a construit les solveurs et publié les chiffres, ce qui permet à cette page de rapporter les deux directions avec des mesures. **Le solveur OpenCL de David Barr (2015).** Le premier solveur GPU fonctionnel et publié : PyOpenCL, tournant sur une Radeon HD 7870. Il a fouillé intégralement une rangée de la liste de premières rangées du 10×10 de Martin (la rangée contenant la solution connue) en 3 h 46, le travail étant divisé en 1 620 parts ([message 9360](https://groups.io/g/eternity2/message/9360), [message 9364](https://groups.io/g/eternity2/message/9364)) ; sa référence CPU était de 120 M placements/s sur les 8 cœurs d'un FX-8120 ([message 9366](https://groups.io/g/eternity2/message/9366)). Il a publié le code source sur [github.com/david3x3x3/eternity2](https://github.com/david3x3x3/eternity2) ([message 9367](https://groups.io/g/eternity2/message/9367)), l'un des rares solveurs E2 open source de son époque. **Le solveur DirectX 12 d'Adam Miles (2018).** Après avoir mis de côté un solveur AVX2 presque terminé, jugé pas assez rentable ([message 9811](https://groups.io/g/eternity2/message/9811)), Miles a écrit des compute shaders DX12 et les a fait tourner sur une Xbox One X, une pièce à 6 téraflops. La conception de son kernel est un cas d'école : travailler *avec* les deux murs plutôt que de prétendre qu'ils n'existent pas. Une « pré-résolution » en largeur d'abord énumère chaque solution partielle des 14 à 18 premières tuiles sur le GPU lui-même (3,3 millions de préfixes de deux rangées pour le 7×7 ; 155,8 millions de préfixes de 16 tuiles pour le 9×9), chacun empaqueté dans 20 octets (un masque de pièces utilisées sur 96 bits plus douze couleurs d'arête sur 5 bits) avant qu'un balayage massivement parallèle ne termine chaque préfixe ([message 9814](https://groups.io/g/eternity2/message/9814), [message 9819](https://groups.io/g/eternity2/message/9819)). État uniforme, état minuscule, aucune diaphonie. Le 7×7 jeu 1 de Brendan est tombé de 74 à 25 puis à 14 secondes, face à une référence CPU optimisée de 529 secondes ; le 8×8 a pris 248 secondes. Le solveur OpenCL de Barr sur une GTX 1060 a exécuté le même 7×7 en 73 secondes, et les deux ont échangé des notes sur les kernels expliquant exactement pourquoi les téraflops déçoivent ([message 9818](https://groups.io/g/eternity2/message/9818)). Miles a réécrit le solveur une nouvelle fois en 2020 sur du matériel haut de gamme qu'il ne pouvait pas encore nommer ([message 9994](https://groups.io/g/eternity2/message/9994), [message 9998](https://groups.io/g/eternity2/message/9998)). **Joshua Blackwood (2020).** L'auteur des plateaux record a mesuré un portage GPU pendant la campagne qui a produit la famille 468-470, aux côtés de solveurs SAT et de blocs 2×2 mis en cache (« j'ai mesuré tout ce que j'ai fait »), et n'en a conservé aucun. Seules les heuristiques affinées ont fini par payer, pour un facteur supplémentaire d'environ 2x ([message 10056](https://groups.io/g/eternity2/message/10056)). Le catalogue complet de ce qu'il a abandonné est sur la [page des impasses](/fr/research/build/dead-ends/). **David Barr, de nouveau (2025).** Le point de données moderne : son chercheur en profondeur d'abord en Python/OpenCL sur une RTX 4090 louée (vast.ai, 0,25 à 0,34 $/heure) fouille environ **3,17 milliards de placements par seconde** sur le 10×10 de Brendan ; selon ses propres mots, cependant, le code actuel « ne fonctionne pas bien avec le puzzle Eternity complet en raison des limitations mémoire » ([message 11598](https://groups.io/g/eternity2/message/11598)). Quatorze ans après le message de Field, le meilleur chiffre GPU de l'archive s'accompagne toujours de la réserve de Field. ## Les tentatives, en un coup d'œil | Qui | Matériel | Ce qui s'est passé | Msg | | --- | --- | --- | --- | | Simon Chapple et James (2007) | Nvidia 8800 (proposition) | Première proposition GPU ; « peut-être 4 ou 5 fois » plus rapide estimé ; jamais construit | [351](https://groups.io/g/eternity2/message/351), [355](https://groups.io/g/eternity2/message/355) | | knucklefinger (2008) | Shaders GLSL | « Presque au bout » d'un solveur CSP en GLSL ; aucun résultat jamais publié | [5407](https://groups.io/g/eternity2/message/5407), [5409](https://groups.io/g/eternity2/message/5409) | | Thomas / trans.spam (2010) | non précisé, >10¹² op/s | Première question OpenCL ; expériences lancées, aucun retour | [7653](https://groups.io/g/eternity2/message/7653), [7656](https://groups.io/g/eternity2/message/7656) | | valy / 21valy (2011) | carte à 80 SP, puis Radeon 5770 | Sous-puzzle jouet 4x4 porté sur OpenCL : 4 s en C monocœur contre 60 s sur le GPU ; code partagé | [8982](https://groups.io/g/eternity2/message/8982), [8994](https://groups.io/g/eternity2/message/8994) | | Mike Field (2011) | (analyse) | L'argument négatif : la coopération exige une bande passante que les GPU n'ont pas ; l'indépendance exige >8 Ko d'état par thread ; aucun ordre de grandeur disponible | [9003](https://groups.io/g/eternity2/message/9003), [9004](https://groups.io/g/eternity2/message/9004) | | David Barr (2015) | Radeon HD 7870, PyOpenCL | Premier solveur GPU fonctionnel publié ; une première rangée de 10x10 fouillée intégralement en 3 h 46 ; open source | [9360](https://groups.io/g/eternity2/message/9360), [9367](https://groups.io/g/eternity2/message/9367) | | Adam Miles (2018) | Xbox One X, calcul DX12 | 7x7 jeu 1 en 14 s (CPU : 529 s) ; 9x9 jeu 1 revérifié exhaustivement en 25 h 24, exactement les 2 solutions connues | [9811](https://groups.io/g/eternity2/message/9811), [9822](https://groups.io/g/eternity2/message/9822) | | David Barr (2018) | GTX 1060, OpenCL | 7x7 jeu 1 en 73 s ; notes de conception de kernel échangées avec Miles | [9818](https://groups.io/g/eternity2/message/9818) | | Adam Miles (2020) | GPU haut de gamme non annoncé | Réécriture avec « pas mal de vitesse en plus » ; explicite que le 16×16 complet reste hors de portée | [9994](https://groups.io/g/eternity2/message/9994), [9996](https://groups.io/g/eternity2/message/9996), [9998](https://groups.io/g/eternity2/message/9998) | | Joshua Blackwood (2020) | GPU non précisé | Mesuré pendant la campagne du record 468-470 ; non conservé, seules les heuristiques ont payé | [10056](https://groups.io/g/eternity2/message/10056) | | David Barr (2025) | RTX 4090 louée (vast.ai) | ~3,17 Md placements/s sur le 10x10 de Brendan à ~0,30 $/h ; E2 complet échoue sur les limites mémoire | [11598](https://groups.io/g/eternity2/message/11598) | ## Ce que disent réellement les chiffres Placez les 3,17 milliards de placements par seconde de Barr à côté des chiffres CPU de la communauté, environ 70 à 90 M/s pour un cœur unique bien réglé et 225 à 295 M/s pour le C généré de [McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) sur le matériel le plus récent (le bilan complet est sur la [page ingénierie de solveur](/fr/research/build/faster/solver-engineering/)), et le meilleur résultat GPU équivaut à quelque chose entre dix et quarante cœurs CPU. C'est une constante réelle et utile. C'est aussi *seulement* une constante, achetée sur un petit puzzle où l'état par thread reste minuscule, et qui se dégrade vers l'analyse de Field précisément lorsque le plateau grandit jusqu'aux 256 pièces réelles. L'estimation de James en 2007, « 4 ou 5 fois », était à côté ; le rapport des téraflops, un facteur mille, était bien plus à côté, et dans l'autre sens. Un facteur constant a ici un sens précis : [pourquoi un ordinateur plus rapide n'aide pas](/fr/research/why/prune-vs-speed/) fait le calcul, et la [page des impasses](/fr/research/build/dead-ends/) en consigne le verdict : le même algorithme, plus rapide, heurte le même mur un peu plus tôt. ## Là où les GPU brillent vraiment ici Passons à l'autre moitié du bilan. Le 25 février 2018, la Xbox One X de Miles a achevé de parcourir l'**intégralité** de l'arbre de recherche du 9×9 jeu 1 de Brendan en 25 heures et 24 minutes, trouvant exactement 2 solutions, à 22 % et 32 % de la recherche, après quoi la machine a passé dix-sept heures de plus à prouver qu'il n'y en avait pas d'autres ([message 9822](https://groups.io/g/eternity2/message/9822)). Cela a confirmé de manière indépendante le recensement de McGavin de 2014, avec un algorithme différent, un langage différent et un silicium radicalement différent. C'est l'un des résultats de vérification les plus solides de l'archive. Remarquez ce qui l'a rendu possible. L'énumération exhaustive d'un arbre de forme fixe est uniforme : chaque voie exécute la même boucle peu profonde sur des préfixes de même taille, l'état tient dans l'empaquetage de 20 octets de Miles, personne n'a besoin de se parler, et personne ne se soucie que certaines voies finissent tôt puisque le but est l'arbre entier, pas une branche chanceuse. Toute propriété qui casse la *recherche* sur GPU est absente de la *vérification* sur GPU. Le conseil de clôture s'écrit donc tout seul, et il n'est ni espoir ni désespoir. Un GPU ne trouvera pas la solution : trois praticiens de l'ère du record l'ont mesuré indépendamment, et l'argument du pourquoi tient depuis 2011. Mais si votre charge de travail consiste à revérifier un recensement, à énumérer des rangées ou des blocs, ou à balayer exhaustivement un sous-puzzle borné (forme fixe, petit état, travail uniforme), une 4090 louée à trente cents l'heure est le calcul le moins cher jamais mesuré pour ce problème. Braquez le GPU sur ce qu'il est : non pas un chercheur plus profond, mais un compteur très rapide. ## À lire aussi - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Ingénierie de solveur : l'artisanat sous l'algorithme](https://eternity2.dev/fr/research/build/faster/solver-engineering/) — Tous les solveurs record exécutent le même backtracking en profondeur d'abord. Ce qui les distingue, c'est la couche en dessous : tables de correspondance, hachages parfaits, structs taillées pour le cache, code généré, archéologie du compilateur. C'est cet artisanat qui décide si un nœud coûte 26 cycles ou 2 600. Vingt ans de registre d'ingénierie de la communauté, technique par technique, et ce que tout cela a rapporté. - [Le backtracker C de McGavin : l'histoire du débit, reconstruit ici](https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/backtracker/) — Le backtracker C de Peter McGavin, le plus rapide de la communauté : une recette d'optimisation de 2007 capitalisée pendant deux décennies via code généré, tables de correspondance et astuces de compteur, puis compilée sur mon M1 et pointée vers le vrai puzzle à 256 pièces, où en mono-cœur elle dépasse 200 des 256 pièces à ~109M placements/s. --- # Approches quantiques : deux accélérations à leur vrai prix > L'ordinateur quantique est le plus ancien deus ex machina de la liste, invoqué dès le premier mois du casse-tête et tous les quelques ans depuis. Il n'existe qu'exactement deux histoires réelles à raconter : l'accélération quadratique de Grover et le recuit sur un encodage QUBO. Cette page les raconte proprement toutes deux, fait le calcul face aux chiffres réels d'Eternity II, et rapporte l'intégralité des traces de la communauté : dix-neuf ans de digressions, une tentative d'embedding inachevée, zéro exécution. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/hardware/quantum/ - Mise à jour: 2026-07-02 - Sujets: hardware, exact-methods - Source: Grover, A fast quantum mechanical algorithm for database search (arXiv:quant-ph/9605043, 1996) — https://arxiv.org/abs/quant-ph/9605043 - Source: Bennett, Bernstein, Brassard & Vazirani, Strengths and weaknesses of quantum computing : la limite quadratique (arXiv:quant-ph/9701001) — https://arxiv.org/abs/quant-ph/9701001 - Source: Montanaro, Quantum walk speedup of backtracking algorithms (arXiv:1509.02374) — https://arxiv.org/abs/1509.02374 - Source: Lucas, Ising formulations of many NP problems (arXiv:1302.5843, 2014) — https://arxiv.org/abs/1302.5843 - Source: Bengtsson et al., QAOA résout de petites instances d'exact-cover sur deux qubits supraconducteurs (arXiv:1912.10495) — https://arxiv.org/abs/1912.10495 - Source: Ambainis, Quantum search algorithms, la synthèse qu'Alan a postée sur la liste (arXiv:quant-ph/0504012) — https://arxiv.org/abs/quant-ph/0504012 - Source: Aaronson & Ambainis, Quantum search of spatial regions (arXiv:quant-ph/0303041) — https://arxiv.org/abs/quant-ph/0303041 - Source: Le fil « Quantum computing » de 2007 s'ouvre (groups.io message 1446) — https://groups.io/g/eternity2/message/1446 - Source: Max lit Deutsch : l'accélération quantique pour E2 « serait très modérée » (groups.io message 6484, 2009) — https://groups.io/g/eternity2/message/6484 - Source: D-Wave nommé pour la première fois sur la liste (groups.io message 7796, 2010) — https://groups.io/g/eternity2/message/7796 - Source: Le calcul Grover de McGavin : 3,4x10^40 nœuds, racine carrée, 135 qubits (groups.io message 10258, 2021) — https://groups.io/g/eternity2/message/10258 - Source: McGavin pose la question ouverte (groups.io message 10260, 2021) — https://groups.io/g/eternity2/message/10260 - Source: mulisak, « que l'informatique quantique nous sauve ! » : QAOA sur exact cover (groups.io message 10791, 2022) — https://groups.io/g/eternity2/message/10791 - Source: Recuit quantique et le temps communautaire gratuit de D-Wave suggérés (groups.io message 11175, 2023) — https://groups.io/g/eternity2/message/11175 - Source: La tentative D-Wave DQM de Patrick Poitras se heurte au mur de la connectivité (groups.io message 11176, 2023) — https://groups.io/g/eternity2/message/11176 - Source: mulisak dimensionne le modèle en circuit : 3 000+ qubits nécessaires, ~150 existent (groups.io message 11813, 2026) — https://groups.io/g/eternity2/message/11813 --- L'ordinateur quantique est entré dans l'archive d'Eternity II dès le premier mois du casse-tête. En mai 2007, des semaines avant que la plupart des membres aient écrit un solveur, l'un d'eux proposa de fonder le « Homebrew Quantum Computer Club » ([message 263](https://groups.io/g/eternity2/message/263)). C'était une plaisanterie, et la première apparition d'une figure qui allait hanter la liste pendant dix-neuf ans : la machine venue du futur qui dissout le problème tout entier. On l'a invoquée comme fantasme, comme satire, comme vœu sur la liste au Père Noël, et parfois comme véritable question technique. Ce qu'elle n'a jamais été, nulle part dans les traces, c'est *utilisée* : aucun membre n'a jamais rapporté avoir fait tourner du matériel ou un simulateur quantique contre une quelconque instance d'Eternity II, de quelque taille que ce soit. Ces maigres traces méritent tout de même une page, pour deux raisons. Premièrement, il existe exactement deux histoires quantiques réelles pertinentes pour E2, la recherche de Grover et le recuit sur un encodage d'Ising, et toutes deux peuvent être racontées avec de vrais calculs, d'une manière que les digressions éparses de la liste n'ont jamais tout à fait assemblée. Deuxièmement, le calcul est éclairant : l'informatique quantique offre la plus forte accélération que la physique promette actuellement pour la recherche aveugle, et évaluer E2 à l'aune de celle-ci montre précisément *pourquoi* ce casse-tête résiste : les mêmes murs que cartographient les [pages sur la structure](/fr/research/why/complex-theory/), vus de l'autre côté. ## Première histoire : Grover, la racine carrée [L'algorithme de Grover](https://arxiv.org/abs/quant-ph/9605043) est le résultat phare de la recherche quantique. Étant donné $N$ possibilités et un test en boîte noire pour « celle-ci est-elle une solution ? », un ordinateur quantique trouve une solution en environ $\tfrac{\pi}{4}\sqrt{N}$ évaluations du test, là où une machine classique en nécessite de l'ordre de $N$. Deux clauses en petits caractères comptent ici : - **L'accélération est quadratique, et c'est un théorème, pas une borne inférieure à battre.** Pour la recherche en boîte noire, [Bennett, Bernstein, Brassard et Vazirani](https://arxiv.org/abs/quant-ph/9701001) ont prouvé que la racine carrée est optimale : aucun algorithme quantique ne fait mieux sans exploiter la structure du problème. On ne sait *pas* que les ordinateurs quantiques résolvent les problèmes NP-complets en temps polynomial ; sur la recherche non structurée, ils divisent l'exposant par deux, point final. - **Avec $M$ solutions, le coût est $\sqrt{N/M}$.** Des solutions abondantes aident la recherche quantique exactement comme elles aident la recherche classique. Eternity II a été [conçu pour n'en avoir essentiellement qu'une](/fr/research/why/complex-theory/). La conception adverse qui affame les solveurs classiques affame Grover tout autant. Passons maintenant au calcul, face aux chiffres réels d'E2. **Face à l'espace brut.** Le décompte naïf des configurations (chaque pièce n'importe où, dans n'importe quelle rotation) est le fameux $\sim 10^{557}$ ([faits connus](/fr/research/build/known-facts/)). Grover le transforme en $$ \sqrt{10^{557}} \;\approx\; 10^{278.5} $$ appels séquentiels à l'oracle. Diviser 557 par deux laisse 278 : un nombre qui se moque de savoir si votre machine effectue une opération par seconde ou par temps de Planck. Rien de plus à dire sur la version non structurée. **Face à l'arbre structuré.** La comparaison juste n'est pas l'espace brut mais l'arbre qu'un bon backtracker parcourt réellement, et la communauté a fait ce calcul elle-même, dans le seul échange sur Grover véritablement technique de l'archive. En octobre 2021, à partir de l'estimation d'Akos selon laquelle un balayage complet de l'espace de recherche nécessite au minimum $3.4\times10^{40}$ opérations, [Peter McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) demanda si Grover pouvait fouiller cet arbre en $\sqrt{3.4\times10^{40}} \approx 1.8\times10^{20}$ opérations sur une machine à $\log_2(3.4\times10^{40}) = 135$ qubits ([message 10258](https://groups.io/g/eternity2/message/10258)), et reformula la question avec soin deux messages plus loin : « Grover ou un autre algorithme quantique pourrait-il fouiller l'arbre E2 en O(sqrt(N)) opérations ? » ([message 10260](https://groups.io/g/eternity2/message/10260)). Personne sur la liste ne répondit. La littérature, elle, répond : oui, presque. [Le backtracking quantique de Montanaro](https://arxiv.org/abs/1509.02374) parcourt un arbre de backtracking classique de $T$ nœuds en environ $\sqrt{T}$ (à des facteurs polynomiaux près) étapes quantiques, structure et élagage compris. Prenons le propre chiffre de ce wiki pour la largeur du plateau de l'arbre, environ $10^{45}$ plateaux partiels ([théorie de la complexité](/fr/research/why/complex-theory/)) : $$ \sqrt{10^{45}} \;\approx\; 3\times10^{22} \text{ étapes quantiques.} $$ $3\times10^{22}$ est-il faisable ? Accordons à la machine un cadeau absurde : un appel complet à l'oracle (vérifiant les 480 contraintes d'arête d'un plateau entier, de façon réversible) toutes les *nanosecondes*. Les itérations de Grover sont intrinsèquement séquentielles (faire tourner $k$ machines en parallèle n'achète que $\sqrt{k}$, pas $k$), ce qui donne donc $3\times10^{13}$ secondes : **environ un million d'années**. Aux cadences de portes logiques de l'ordre du kHz–MHz que projettent réellement les machines à correction d'erreurs, c'est plus long que l'âge de l'univers. Et les 135 qubits de McGavin ne comptent que le registre d'index : l'oracle doit maintenir le plateau (256 cellules × 10 bits de pièce-rotation, c'est déjà ~2 560 qubits logiques), la comptabilité des pièces utilisées, et les ancillae qui rendent la vérification réversible. Cela totalise des milliers de qubits logiques, soit des millions de qubits physiques aux surcoûts de correction d'erreurs actuels, face aux quelque 150 qubits bruités accessibles en 2026 ([message 11813](https://groups.io/g/eternity2/message/11813)). Le remarquable, c'est que la liste a vu juste très tôt, de son fauteuil. En février 2009, Max, lisant un essai de David Deutsch, concluait que « même si nous disposions aujourd'hui d'un grand ordinateur quantique, l'accélération pour des problèmes comme les échecs et probablement aussi E2 serait très modérée » ; il faudrait de nouveaux algorithmes, encore à découvrir, par-dessus ([message 6484](https://groups.io/g/eternity2/message/6484)). C'est le théorème BBBV, paraphrasé sur une liste de diffusion consacrée à un casse-tête, deux ans après le début de la chasse. ## Deuxième histoire : le recuit, et le casse-tête comme paysage énergétique La deuxième histoire est plus intéressante parce qu'elle est plus proche du constructible. Les recuiseurs quantiques (les machines de D-Wave) ne font pas tourner Grover. Ils refroidissent physiquement un réseau de qubits couplés vers l'état fondamental d'une fonction d'énergie programmable, un **QUBO** (quadratic unconstrained binary optimization), équivalent à un modèle d'Ising. [Le catalogue de Lucas (2014)](https://arxiv.org/abs/1302.5843) donne des formulations d'Ising pour les 21 problèmes NP-complets de Karp, et l'appariement d'arêtes s'encode exactement dans son style. Prenons la même variable qu'utilise [l'encodage SAT](/fr/research/build/exact/sat-csp-encodings/), $x_{p,c,r} = 1$ si la pièce $p$ occupe la cellule $c$ avec la rotation $r$, et écrivons $$ H \;=\; A\sum_{c}\Big(1-\!\!\sum_{p,r} x_{p,c,r}\Big)^{2} \;+\; A\sum_{p}\Big(1-\!\!\sum_{c,r} x_{p,c,r}\Big)^{2} \;+\; B \sum_{\langle c,c' \rangle} \sum_{\text{mismatching pairs}} x_{p,c,r}\,x_{p',c',r'} , $$ avec $A > B > 0$ : le premier terme punit les cellules qui ne portent pas exactement un placement, le deuxième punit les pièces non utilisées exactement une fois, le troisième ajoute $B$ par jonction intérieure mal appariée. L'état fondamental a une énergie nulle exactement lorsque le plateau est une solution parfaite. Il est plaisant de constater que les états excités de basse énergie *sont* des plateaux partiels à haut score, si bien que l'encodage parle nativement la langue de [l'échelle des records](/fr/research/records/). Ensuite, on le dimensionne. - **Variables :** $256 \times 256 \times 4 = 262{,}144$ binaires logiques. - **Couplages :** les 1 024 placements candidats de chaque cellule sont mutuellement exclusifs, ce qui signifie $\binom{1024}{2} \approx 5\times10^{5}$ termes quadratiques *par cellule*, et de nouveau par pièce : de l'ordre de $10^{8}$ couplages avant même de compter les termes de non-appariement. - **Matériel :** les plus grands recuiseurs de 2026 portent de l'ordre de 5 000 qubits physiques, chacun couplé à 15–20 voisins. Faire correspondre un problème logique à ce graphe creux (**minor-embedding**) représente chaque variable densément connectée par une *chaîne* de qubits physiques ; le plafond pratique pour un problème entièrement connecté est de quelques centaines de variables logiques par puce. Le groupe one-hot d'**une seule cellule** (1 024 variables mutuellement couplées) dépasse déjà cela plusieurs fois, et il y a 256 cellules. L'écart n'est pas une génération d'ingénierie ; ce sont plus de trois ordres de grandeur en variables et quatre en couplages, avant même le surcoût des chaînes. (Les solveurs *hybrides* de D-Wave acceptent des QUBO à un million de variables, mais là le processeur quantique est un sous-programme au sein d'une heuristique classique ; un « résultat » hybride ne serait pas un résultat quantique.) Et derrière le mur de la taille s'en dresse un plus ancien : un recuiseur, à n'importe quelle taille, est une machine de recherche locale physique qui descend ce paysage énergétique, le même paysage sur lequel [le recuit simulé et la recherche locale](/fr/research/build/local-search/local-search-alns/) de la communauté ont plafonné dans les 460. Rien dans la théorie du recuit quantique ne promet de creuser un tunnel à travers [la rareté qui a été ingénierée dans ce casse-tête](/fr/research/why/complex-theory/) ; sur des instances de type verre de spin, le gap adiabatique se referme et le temps de recuit explose. La remarque enjouée d'Alan en 2010 selon laquelle « le recuit simulé est l'un des problèmes pour lesquels on attend des QComputers qu'ils soient particulièrement bons » ([message 7802](https://groups.io/g/eternity2/message/7802)) est précisément l'espoir, et il demeure, sur cette classe de problèmes, un espoir plutôt qu'un résultat. ## Ce que dit réellement l'archive L'intégralité des traces quantiques de la liste, 2007–2026. Ce sont majoritairement des digressions, et ce tableau le dit ; les trois moments véritablement techniques sont signalés. | Quand | Qui | Ce qui a été dit | Msg | | --- | --- | --- | --- | | 2007-05 | gfleder | « Homebrew Quantum Computer Club ??? », la première plaisanterie | [263](https://groups.io/g/eternity2/message/263) | | 2007-06 | Steve Moyer | Cite le fil « home quantum computing » en faisant les premiers décomptes de permutations | [268](https://groups.io/g/eternity2/message/268) | | 2007-07 | Jim Witte | Question de panorama analogique/ADN/quantique ; un Q-comp « pourrait probablement cracher une solution en une seconde environ » | [824](https://groups.io/g/eternity2/message/824) | | 2007-08 | psykowally & al. | Le fil « Quantum computing » : « une façon évidente de résoudre le casse-tête... combien de bits arrivent-ils à gérer ? » ; Anurag : aucun matériel n'existe ; Grech : un vrai QC vaut plus que le prix ; une plaisanterie sur le calcul contrefactuel | [1446](https://groups.io/g/eternity2/message/1446), [1457](https://groups.io/g/eternity2/message/1457), [1464](https://groups.io/g/eternity2/message/1464), [1535](https://groups.io/g/eternity2/message/1535), [1540](https://groups.io/g/eternity2/message/1540) | | 2008 | divers | Le quantique listé parmi les « autres voies » (3995), mis en doute pour l'interférence (4032), souhaité (4850), tourné en dérision comme l'« ordinateur quantique voyageur du temps » (5413, 5442), objet de plaisanterie (5542), rattaché à des réflexions sur P=NP (5629), listé avec le calcul holographique et l'ADN (5736) | [3995](https://groups.io/g/eternity2/message/3995), [4032](https://groups.io/g/eternity2/message/4032), [4850](https://groups.io/g/eternity2/message/4850), [5413](https://groups.io/g/eternity2/message/5413), [5629](https://groups.io/g/eternity2/message/5629), [5736](https://groups.io/g/eternity2/message/5736) | | 2009-02 | lukas ; **Max** | « Où est le solveur "quantique" non linéaire ? », auquel il est répondu avec Deutsch : **l'accélération « serait très modérée »** | [6480](https://groups.io/g/eternity2/message/6480), [6484](https://groups.io/g/eternity2/message/6484) | | 2009-12 | andreas gammel | « Ordinateur quantique maison » : réflexion sur les fentes de Young, projeter la solution sur un mur | [7336](https://groups.io/g/eternity2/message/7336) | | 2010-06 | **Alan (Figjam)** & Geoff | « Il nous faut soit un ordinateur quantique de 2048 bits, soit acheter un billet de loterie » ; **D-Wave nommé** (premier pointeur matériel) ; les articles d'Ambainis et d'Aaronson–Ambainis postés ; espoirs d'effet tunnel quantique | [7789](https://groups.io/g/eternity2/message/7789), [7796](https://groups.io/g/eternity2/message/7796), [7799](https://groups.io/g/eternity2/message/7799), [7802](https://groups.io/g/eternity2/message/7802), [7811](https://groups.io/g/eternity2/message/7811) | | 2011-02 | Johannes Lindé | Démo Wolfram d'algorithmes de recherche quantique liée, « d'autres qui travaillent dans ce sens ? » | [8565](https://groups.io/g/eternity2/message/8565) | | 2015-06 | void solid | Lie le QUBO-Chimera d'alex1770 (à quel point le problème natif de D-Wave se résout *en logiciel*) dans un fil sans rapport ; pas de suite | [9417](https://groups.io/g/eternity2/message/9417) | | 2021-10 | **Peter McGavin** | **Le calcul Grover** : $3.4\times10^{40}$ nœuds $\to$ $1.8\times10^{20}$ ops, 135 qubits ; la question ouverte, jamais résolue sur la liste | [10258](https://groups.io/g/eternity2/message/10258), [10260](https://groups.io/g/eternity2/message/10260) | | 2022-07 | mulisak | « Que l'informatique quantique nous sauve ! » : un article QAOA sur [exact cover](/fr/research/build/exact/exact-cover-dlx/) + cuQuantum ; « convaincre Google/IBM/Microsoft... que ça les rendra célèbres » | [10791](https://groups.io/g/eternity2/message/10791) | | 2023-10 | Hopfer ; **Poitras** | L'idée « pseudo-quantique » d'un processeur par cellule ; recuit quantique + temps communautaire gratuit de D-Wave suggérés ; **l'unique tentative concrète**, un modèle D-Wave DQM bloqué sur l'embedding : connectivité à 15 voies contre 22 couleurs, « en espérant qu'ils sortent bientôt une puce Zephyr » | [11174](https://groups.io/g/eternity2/message/11174), [11175](https://groups.io/g/eternity2/message/11175), [11176](https://groups.io/g/eternity2/message/11176) | | 2023-12 | Jef Bucas | « Quelqu'un a un gros ordinateur quantique sur sa liste au Père Noël ? » | [11185](https://groups.io/g/eternity2/message/11185) | | 2024 | mulisak ; McGavin ; Joe | La machine à 127 qubits sur campus d'IBM signalée (11283) ; le quantique listé parmi les domaines d'où pourrait venir une percée (11346) ; l'annonce Willow de Google relayée (11407) | [11283](https://groups.io/g/eternity2/message/11283), [11346](https://groups.io/g/eternity2/message/11346), [11407](https://groups.io/g/eternity2/message/11407) | | 2026 | JSA ; **mulisak** | Les ordinateurs quantiques nommés comme l'une des deux voies à court terme (11788) ; le travail SAT est-il « un travail préparatoire... pour un éventuel ordinateur quantique ? » (11812) ; **la réponse chiffrée** : ~150 qubits bruités existent, un circuit de set-cover pour E2 en nécessite 3 000+, une preuve de concept QAOA/Grover à ~30 qubits est le plafond réaliste ; « ça n'a pas l'air d'être ce qui résoudra Eternity II de sitôt » | [11788](https://groups.io/g/eternity2/message/11788), [11812](https://groups.io/g/eternity2/message/11812), [11813](https://groups.io/g/eternity2/message/11813) | C'est tout. (Les autres occurrences de « quantique » dans l'archive sont des usages figurés comme « saut quantique », ou des digressions de physique sans rapport avec le calcul.) En résumé : trois moments techniques en dix-neuf ans (le théorème de fauteuil de Max en 2009, la racine carrée de McGavin en 2021, le décompte de qubits de mulisak en 2026), un embedding D-Wave inachevé, et zéro exécution rapportée de quoi que ce soit, sur quelque instance que ce soit. Les traces de la communauté sont minces, et le travail de cette page est de le dire plutôt que de les gonfler. > **Le quantique comme prisme, pas comme outil** > > Voici l'usage sobre de tout ceci. La recherche de type Grover est la *plus forte* accélération générique qu'offre une physique connue : elle divise l'exposant par deux, là où toutes les histoires de matériel de ce wiki ([FPGA](/fr/research/build/hardware/fpga-solving/), [GPU](/fr/research/build/hardware/gpu-solving/), clusters) ne divisent que par une constante. Et E2 s'en débarrasse d'un haussement d'épaules : $10^{45} \to 10^{22.5}$ perd toujours contre n'importe quelle horloge concevable. L'argument selon lequel [un ordinateur plus rapide n'aide pas](/fr/research/why/prune-vs-speed/) survit même à la meilleure accélération que la physique ait à offrir, ce qui en est la forme la plus forte. Pendant ce temps, l'histoire du recuit vient se fracasser sur l'autre mur : en tant que paysage énergétique, E2 a été [construit pour n'avoir qu'une aiguille et aucun gradient vers elle](/fr/research/why/complex-theory/). La véritable pertinence du quantique pour E2 aujourd'hui, c'est qu'évaluer le casse-tête à l'aune d'un matériel hypothétique localise la difficulté exactement là où les pages sur la structure disent qu'elle réside : dans l'arbre, pas dans l'horloge. ## À quoi ressemblerait une tentative sérieuse L'écart entre « souhaité » et « mesuré » est, pour une fois, peu coûteux à combler. Le temps de recuiseur se loue à la minute, et l'expérience elle-même est modeste : 1. **Encoder l'échelle, pas le casse-tête.** Écrire le QUBO ci-dessus (ou la forme à variables discrètes de Poitras, [message 11176](https://groups.io/g/eternity2/message/11176)) pour [la suite de bancs d'essai de Brendan Owen](/fr/research/build/benchmarks/) en commençant par du 4×4 et du 5×5, des tailles dont les groupes one-hot s'embarquent réellement sur une puce à ~5 000 qubits. 2. **Faire tourner trois solveurs sur le même $H$ :** le vrai QPU, le recuit simulé classique, et un hybride tabou/RS moderne : même fonction d'énergie, même seuil. Le QPU doit battre le recuit classique *sur son propre encodage* avant que la moindre affirmation plus large ait un sens. 3. **Sur du matériel à portes, faire la preuve de concept de mulisak** : QAOA ou Grover sur un jouet de set-cover à ~30 qubits ([message 11813](https://groups.io/g/eternity2/message/11813)), en sachant d'avance qu'elle démontre une machinerie, pas un progrès. 4. **Rapporter la courbe de passage à l'échelle, pas l'anecdote :** probabilité de succès et temps jusqu'à la solution en fonction de la taille du plateau, aux côtés de la référence classique. Le meilleur cas réaliste n'est pas un 6×6 résolu ; c'est un croisement mesuré ou, plus probablement, une entrée propre et sourcée au registre des [impasses](/fr/research/build/dead-ends/), ce qui sur ce wiki compte aussi comme un progrès. Tant que personne ne le fait, le tableau d'affichage indique : deux beaux algorithmes, un calcul qui s'achève sur $10^{22}$ étapes séquentielles, un encodage trois ordres de grandeur trop grand pour son matériel, et une archive de dix-neuf ans dans laquelle l'ordinateur quantique reste ce qu'il était en mai 2007 : le club que personne n'a jamais construit. ## À lire aussi - [Encodages SAT et CSP](https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/) — Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. - [Résolution sur FPGA : cartographiée, mais jamais parcourue](https://eternity2.dev/fr/research/build/hardware/fpga-solving/) — Si la boucle de placement est limitée par la latence mémoire, un FPGA semble la réponse exacte : loger les tables de correspondance dans la block RAM embarquée, à un cycle de distance, et pipeliner des dizaines de petits backtrackers sur une même puce. La communauté a cartographié cette route en détail. Michael Field a conçu le solveur, projeté cinq milliards de placements par seconde et par puce, et fait tourner un prototype sur silicium réel. Puis la route n'a jamais été parcourue jusqu'au bout. Le dossier complet, et pourquoi. - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. --- # Faits et chiffres établis > Les chiffres que tout chercheur sur Eternity II finit par redémontrer, rassemblés au même endroit avec leur provenance : la définition du puzzle, le placement des indices, les conventions de score, le tableau des records, la taille de l'espace de recherche et les comptages structurels. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/known-facts/ - Mise à jour: 2026-07-21 - Sujets: structure - Source: Wikipedia, « Eternity II puzzle » (le prix, la date limite, le 467 de Verhaard et l'estimation 10^557) — https://en.wikipedia.org/wiki/Eternity_II_puzzle - Source: 469 : fil « EternityII Solver » (le plateau de Blackwood et McGavin), eternity2@groups.io, 2020-09 — https://groups.io/g/eternity2/message/10045 - Source: 470 : « 470 Found » (Joshua Blackwood), eternity2@groups.io, 2021-03 — https://groups.io/g/eternity2/message/10117 - Source: 460 avec les cinq indices : fil « Highest points (of 480) with using all 5 (!) hints? », eternity2@groups.io, 2023-03 — https://groups.io/g/eternity2/message/11074 - Source: 464 avec les cinq indices (Benjamin Riotte) : fil « Record of Eternity2 with 5 hints? », eternity2@groups.io, 2026-07 — https://groups.io/g/eternity2/message/11919 - Source: Estimations du nombre attendu de solutions par Brendan Owen (groups.io message 5197) — https://groups.io/g/eternity2/message/5197 - Source: Louis Verhaard, détails de l'algorithme et du score du 467 (shortestpath.se) — https://www.shortestpath.se/eii/eii_details.html - Source: e2.bucas.name (Jef Bucas), le visualiseur de plateaux de la communauté ; chaque plateau record s'y re-score — https://e2.bucas.name --- Toute discussion sur Eternity II finit par s'interrompre le temps que quelqu'un redémontre la même poignée de chiffres. Cette page, c'est cette poignée, notée une bonne fois pour toutes. Les faits marqués **calculé** sont redémontrés exactement à partir du jeu de pièces officiel, les mêmes données que celles sur lesquelles nos pages [chiffres de référence](/fr/research/reference/) et [Pourquoi est-ce difficile ?](/fr/research/why/) sont vérifiées, et n'importe qui peut les reproduire. Les faits de records proviennent des messages primaires de la liste de diffusion ; les faits encyclopédiques de Wikipedia. ## Le puzzle en chiffres | Fait | Valeur | Provenance | | --- | --- | --- | | Plateau | 16×16 = 256 cases, encadré | officiel | | Pièces | 256, toutes distinctes | officiel ; calculé | | Pièces coin (2 côtés gris) | 4 | calculé | | Pièces bord (1 côté gris) | 56 | calculé | | Pièces intérieures (0 côté gris) | 196 | calculé | | Couleurs (bordure grise exclue) | 22 | calculé | | dont couleurs réservées au cadre | 5 | calculé | | dont couleurs de la palette intérieure | 17 | calculé | | Arêtes internes (paires de cases adjacentes) | 480 = 2 · 16 · 15 | calculé | | Placements d'indices fixés | 5 | officiel | | Prix | 2 000 000 $, non réclamé ; date limite midi, 31 déc. 2010 | Wikipedia | La couleur de la bordure extérieure grise ne fait pas partie des 22 : elle n'apparaît jamais sur une arête interne. La répartition 5 + 17 des couleurs n'est pas fortuite : 17 couleurs intérieures, c'est [exactement le pic de difficulté](/fr/research/why/phase-transition/) pour un puzzle de cette taille. ## Les cinq indices La feuille de règles fixe une pièce ; Tomy a vendu quatre plus petits [puzzles-indices](/fr/research/build/clue-puzzles/) dont chaque solution révélait un placement supplémentaire, et les placements restants ont été publiés par la suite. Les cases utilisent la notation de plateau de [e2.bucas.name](https://e2.bucas.name) : lignes A–P depuis le haut, colonnes 1–16 depuis la gauche. Les numéros de pièces vont de 1 à 256 dans l'ordre de la liste officielle, et la rotation se compte dans le sens horaire à partir de l'orientation stockée de la pièce. | Case | Pièce | Rotation | Quel indice | | --- | --- | --- | --- | | I8 | 139 | 0° | obligatoire (dans le livret de règles) | | C3 | 208 | 90° | puzzle-indice | | C14 | 255 | 90° | puzzle-indice | | N3 | 181 | 90° | puzzle-indice | | N14 | 249 | 180° | puzzle-indice | > **[Figure]** interactive: CluePositionsDiagram. Rendered on the canonical page (link above); not shown in this markdown export. Un plateau qui respecte les cinq indices est dit **strictement canonique** ; la plupart des plateaux records ne respectent que l'indice central obligatoire (« canonique »). Cette distinction scinde le tableau des records en deux ; voir plus bas. Les indices tranchent aussi une question de dénombrement : avec seulement la pièce obligatoire placée, la [théorie complexe](/fr/research/why/complex-theory/) prévoit ≈ 14 702 solutions complètes ; avec les cinq, ≈ 1. Le puzzle à 5 indices possède, par conception, une unique solution attendue. ## Conventions de score - **Score = arêtes internes appariées, sur 480.** Les 60 arêtes grises tournées vers l'extérieur, autour du cadre, ne sont pas comptées. C'est la convention du jury du prix, de tous les records du tableau ci-dessous, et de ce wiki. - **« Ruptures » = 480 − score.** Les auteurs de solveurs rapportent souvent le nombre de non-appariements à la place : le 468 de Blackwood a été annoncé à la liste de diffusion comme « 12 breaks ». - **479 est possible, mais uniquement par la bordure.** Un [argument de parité](/fr/research/build/analysis/parity-arguments/) de l'été du lancement affirmait qu'un unique non-appariement ne peut exister ([kubzpa, 2007](https://groups.io/g/eternity2/message/1640)), et il tient pour les mouvements intérieurs (faire pivoter une pièce intérieure aux arêtes opposées égales en rompt deux, donnant 478, [msg 1642](https://groups.io/g/eternity2/message/1642)). Mais la parité fuit à travers les 60 arêtes de bordure extérieure *non comptées* : retourner une pièce de bordure dont les deux côtés tournés vers l'anneau partagent une couleur rompt exactement une arête comptée ([Verhaard, 2009](https://groups.io/g/eternity2/message/6317)). Le jeu officiel compte 14 pièces de bordure de ce type (calculé), si bien que toute solution complète implique l'existence d'un 479. - **Vérifiez le jeu de pièces avant de comparer les scores.** Plusieurs plateaux « 480 » faisant la une utilisent des [jeux de pièces variants](/fr/research/build/variants/) (conceptions Clue-1/Clue-2, jeux mixtes, le variant TopCoder sans cadre). Ce sont des puzzles différents ; voir [Records et solveurs](/fr/research/records/). Les 480 arêtes internes se répartissent en trois familles (calculé) : | Famille d'arêtes | Nombre | | --- | --- | | Bord ↔ bord (autour de l'anneau du cadre de 60 pièces) | 60 | | Bord ↔ intérieur (la couture, 4 × 14) | 56 | | Intérieur ↔ intérieur (à l'intérieur du cœur 14×14) | 364 | | **Total** | **480** | ## Le tableau des records La chronologie complète, avec aperçus des plateaux et références par record, se trouve sur [Records et solveurs](/fr/research/records/). Les chiffres eux-mêmes : | Score | Qui | Quand | Catégorie | | --- | --- | --- | --- | | 467 | Équipe de Louis Verhaard | Sept. 2008 | canonique ; a remporté le prix partiel de 10 000 $ | | 468 | Joshua Blackwood | Août 2020 | canonique | | 469 | Peter McGavin (solveur de Blackwood) | Sept. 2020 | canonique | | 469 | divers (~7 plateaux, trouvailles indépendantes plus un simple échange à partir de celui de McGavin) | Nov. 2020 | canonique | | **470** | **Joshua Blackwood** | **Mars 2021** | **canonique, le plafond depuis lors** | | 470 | Jef Bucas | Déc. 2024 | canonique (égalisation du 470) | | 460 | Bruno Gauthier | Mars 2023 | strictement canonique ; meilleur plateau respectant les quatre indices optionnels, de 2023 jusqu'à être battu en juil. 2026 | | **464** | **Benjamin Riotte** | **Juil. 2026** | **record strictement canonique ; a battu le 460 de Gauthier, les cinq indices respectés** | | « 480 » | divers | 2023 | jeux de pièces variants, pas le puzzle canonique | Les 469 ont longtemps été cités comme le plafond, mais la vérification au niveau des plateaux montre que les plateaux 468/469/470 relèvent tous du même régime « pièce de départ seule » (les règles du concours ne fixaient que la pièce de départ), si bien que le 470 est le record sur le même puzzle, pas sur un variant plus facile. Aucune solution canonique complète (480/480) n'a jamais été rapportée par qui que ce soit, dans aucune source publique. L'écart de 10 arêtes tient depuis mars 2021. Les aperçus des plateaux et les références par record de chaque ligne sont sur [Records et solveurs](/fr/research/records/). **Cibles ouvertes.** Le 16×16 complet n'est pas le seul plateau non résolu à porter un nom. Le plus proche est le [10×10 set_2 de Brendan Owen](/fr/research/build/benchmarks/#les-1010-de-brendan--lun-est-tombé-lautre-tient-encore) : son jumeau set_1 est tombé après environ 180 cœurs-années, et set_2 reste ouvert, sa difficulté déjà chiffrée par la théorie. Le [tableau des problèmes ouverts](/fr/research/open-problems/) le rassemble avec le reste de la frontière vivante. ## Quelle est la taille de la recherche | Comptage | Valeur | Provenance | | --- | --- | --- | | Tous les placements, sans contrainte : 256! · 4²⁵⁶ | ≈ 1,15 × 10⁶⁶¹ | calculé | | Coins dans les coins, bords sur la bordure (orientation forcée), indice fixé : 4! · 56! · 195! · 4¹⁹⁵ | ≈ 1,115 × 10⁵⁵⁷ | calculé ; correspond au chiffre largement cité de Wikipedia | | Point le plus large de l'arbre de recherche (estimation par théorie complexe, balayage par ligne) | ≈ 10⁴⁵ façons d'étendre, autour de la profondeur 50–200 | Owen / McGavin, voir [théorie complexe](/fr/research/why/complex-theory/) | | Solutions complètes attendues, 1 indice / 5 indices | ≈ 14 702 / ≈ 1 | idem | Le chiffre 10⁵⁵⁷ mérite qu'on sache le redémontrer plutôt que de le citer : les 4 pièces coin vont aux 4 coins (orientation forcée par les deux côtés gris), les 56 pièces bord aux 56 emplacements de bordure (orientation forcée), et les 195 pièces intérieures libres restantes (196 moins l'indice fixé) prennent chacune l'une des 4 rotations. ## Faits de symétrie Tous calculés à partir du jeu de pièces officiel : - **Aucune pièce n'est symétrique par rotation.** Chacune des 256 pièces possède 4 orientations distinctes, de sorte que la rotation ne réduit jamais l'ensemble de candidats d'une pièce. - **Aucune paire de pièces n'est identique, même à rotation près.** Il n'y a aucun doublon interchangeable à exploiter. - **Cinq paires partagent un multi-ensemble de couleurs sans être la même pièce** : les pièces 3 & 4, 6 & 15, 8 & 52, 110 & 111, 172 & 182 (numérotation officielle à partir de 1) portent les mêmes quatre couleurs dans un ordre cyclique différent. - **Les indices brisent toutes les symétries du plateau.** Un plateau 16×16 n'a pas de case centrale, donc toute rotation ou réflexion déplace la case I8 de l'indice obligatoire : aucune symétrie non triviale n'envoie le puzzle indicé sur lui-même, et la rupture de symétrie n'offre aucune réduction supplémentaire de l'espace de recherche. ## Les couleurs, arête par arête Les 256 pièces portent 1 024 vignettes d'arête ; 64 sont grises (2 par pièce coin, 1 par pièce bord), laissant 960 instances d'arête colorées. Leur recensement (calculé ; voir [géographie des couleurs rares](/fr/research/why/rare-color-geography/)) : | Groupe de couleurs | Couleurs | Instances d'arête chacune | Total | | --- | --- | --- | --- | | Réservées au cadre (« rares ») | 5 | 24 (toutes sur des pièces du cadre, aucune à l'intérieur) | 120 | | Palette intérieure, faible | 5 | 48 | 240 | | Palette intérieure, élevée | 12 | 50 | 600 | | **Total** | **22** | | **960** | Deux conséquences que les chercheurs redécouvrent sans cesse : - **Chaque compte par couleur est pair, et les moitiés somment à exactement 480.** Une arête interne appariée consomme deux instances d'une même couleur, donc une solution parfaite requiert $\sum_c N_c / 2 = 480$ appariements, ce qui est exactement le nombre d'arêtes internes. Il n'y a **aucune marge** : dans une solution complète, chaque instance d'arête de chaque couleur trouve son partenaire. - **Les cinq couleurs rares ne vivent que sur le cadre** (24 instances chacune), ce qui fait de l'anneau du cadre un sous-puzzle quasi autonome ; la géométrie est détaillée dans [géographie des couleurs rares](/fr/research/why/rare-color-geography/). ## Structure locale Comptages exacts et exhaustifs sur les pièces intérieures officielles (calculé ; détails et démos interactives sur les pages liées) : | Fait | Valeur | Voir | | --- | --- | --- | | Placements intérieurs aléatoires à 2 cases infaisables | 14 890 / 38 220 ≈ 39 % | [motifs interdits](/fr/research/why/forbidden-patterns/) | | Placements de L-tromino aléatoires infaisables | ≈ 83,3 % | idem | | Placements intérieurs aléatoires 2×2 infaisables | 1 427 039 544 / 1 431 033 240 ≈ 99,72 % | idem | | Pièces intérieures ayant un voisin forcé | 0 : chaque pièce a de 73 à 137 voisins de droite possibles | [aucun coup forcé](/fr/research/why/no-forced-moves/) | | Équilibre de couleurs bord↔intérieur dans toute solution complète | déficit $\Delta = 0$ (une condition nécessaire, Hopfer 2022) | [l'équilibre de la bordure](/fr/research/why/border-balance/) | ## Lire la provenance - **calculé** : redémontré exactement à partir du jeu officiel de 256 pièces ; les pages concernées portent les commandes de reproduction `just research-…` et les résultats bruts vivent dans le [dépôt](https://github.com/raphael-anjou/eternity2). - **groups.io** : les scores records (468, 469, 470, le 464 strict) n'existent que dans les messages de la liste de diffusion et sur le visualiseur de plateaux de la communauté ; les messages d'annonce exacts sont liés depuis [Records et solveurs](/fr/research/records/), et chaque plateau peut être re-scoré sur [e2.bucas.name](https://e2.bucas.name). - **Wikipedia** : ne couvre que la couche encyclopédique (le prix, la date limite et le 467 de Verhaard). ## À lire aussi - [Nombres de référence](https://eternity2.dev/fr/research/reference/) — Dénombrements exacts du nombre de façons valides de remplir un petit bloc à une position donnée du plateau officiel d'Eternity II, sous des règles de plus en plus contraintes : des nombres sûrs pour vérifier le code d'appariement des bords et de contraintes de votre solveur. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). --- # Apprendre des grilles fortes > La plupart des attaques contre Eternity II cherchent à partir de zéro. Une famille distincte fait l'inverse : elle fouille le corpus des grilles déjà trouvées pour en extraire de la structure, puis réinjecte cette structure dans la recherche. Priors de position, ordonnancement appris des coups, fouille d'anti-motifs, décodage de records, et le mode de défaillance où un signal appris s'effondre. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/learning/ - Mise à jour: 2026-07-16 --- Toutes les autres familles de ce rayon cherchent à partir de zéro : un backtracker creuse, un beam construit, une recherche locale peaufine, chacun ne raisonnant qu'à partir des règles du puzzle et de la grille qu'il a sous les yeux. Cette famille-ci procède autrement. Elle prend le corpus des grilles fortes déjà trouvées, y lit de la structure, et réinjecte cette structure dans une recherche sous forme de biais. Elle tient davantage de l'apprentissage par imitation que de la conception d'algorithme de recherche : la question n'est pas « quel est un bon coup » à partir de zéro, mais « qu'avaient tendance à faire les grilles qui ont bien marqué, et cela peut-il être réutilisé ». Les pages ci-dessous procèdent technique par technique. Chacune est réellement sa propre méthode, si bien qu'elles ne partagent pas une même forme comme le font les affineurs de recherche locale : un prior de position, un classement appris des coups, un fouilleur d'anti-motifs et un rejeu de témoin partagent une thèse mais pas un mécanisme. Pour embrasser tout le territoire d'un coup, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). Pour les expériences exécutables qui incarnent ces techniques, avec leurs grilles et leurs chiffres, voyez les [expériences d'apprentissage à partir des grilles](/fr/research/lab/experiments/raphael-anjou/learning/). ## La thèse, et sa limite Un signal appris aide lorsqu'il capture une structure réelle et transférable : quelque chose de vrai des bonnes grilles qu'une recherche partant de zéro devrait sinon redécouvrir par chance. Où chaque pièce a tendance à se placer, quelles pièces aiment à se toucher, quelle demande rare une pièce rare est la seule à pouvoir satisfaire. Câblée dans une recherche comme un biais léger, cette structure porte de façon fiable une construction vers le haut de sa propre fourchette. La limite est ce qui fait de ceci une recherche plutôt qu'un sac d'astuces. Le corpus dont ces signaux sont appris est lui-même sous-parfait : chaque grille qu'il contient est bloquée quelque part sous 480. Un signal extrait du corpus encode donc le *plafond* de la communauté autant que sa sagesse, et un signal qui ne fait que réencoder le plateau sur lequel chaque grille forte est déjà coincée ne relève rien. Poussez un prior appris, bon pour départager, jusque dans la fonction objectif, et la recherche s'effondre, car elle se met à troquer l'arête qu'elle a devant elle contre une intuition statistique. Le fil conducteur limpide de toute cette famille : apprendre des grilles fortes vous fait atteindre le plateau vite et de façon fiable, mais ne vous fait pas, à lui seul, le franchir. Le plafond, c'est le [mur de rigidité](/fr/research/why/rigidity-wall/), et aucune quantité de fouille de corpus ne le déplace. ## Les techniques - **[Priors de corpus](/fr/research/build/learning/corpus-priors/)** en sont la forme la plus simple : comptez où chaque pièce se place dans les grilles fortes, ou à quelle fréquence une pièce satisfait une demande rare, et servez-vous du compte comme critère de départage en construction. Les expériences [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/) et [LODESTONE](/fr/research/lab/experiments/raphael-anjou/learning/lodestone/). - **[Ordonnancement appris des coups](/fr/research/build/learning/learned-value-ordering/)** classe les placements candidats selon plusieurs signaux appris à la fois, et les laisse voter, de sorte qu'aucune intuition isolée ne mène la recherche dans la même impasse. L'expérience [KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/). - **[Fouille d'anti-motifs](/fr/research/build/learning/anti-pattern-mining/)** est l'idée la plus subtile : tout accord entre grilles fortes n'est pas bon. Séparez la structure réelle du piège partagé, et attaquez le piège. L'expérience [PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/), qui a atteint la meilleure grille de ce projet. - **[Décodage de records](/fr/research/build/learning/decoding-records/)** reconstruit exactement une grille record connue, pièce pour pièce, afin de retrouver l'ingrédient qui manquait à une recherche ordinaire. La reproduction comme preuve. L'expérience [REPLAY](/fr/research/lab/experiments/raphael-anjou/learning/replay/). - **[Quand l'apprentissage s'effondre](/fr/research/build/learning/when-learning-collapses/)** est la synthèse sur le mode de défaillance : précisément quand un signal appris cesse d'aider, pourquoi lui accorder trop de confiance ruine la recherche, et pourquoi aucune de ces méthodes ne relève le plafond. Elle pose la limite de toute la section : les signaux appris atteignent le plateau plus vite, mais aucun ne le soulève. ## Pages de cette section - [Priors de corpus](https://eternity2.dev/fr/research/build/learning/corpus-priors/) — La façon la plus simple d'apprendre des bons plateaux : compter où chaque pièce tend à se placer, ou à quelle fréquence elle satisfait une demande rare, et se servir de ce décompte comme d'un léger départage en construction. Ce doit rester un départage ; dès qu'il entre dans l'objectif, il fait s'effondrer la recherche. - [Ordonnancement des coups appris](https://eternity2.dev/fr/research/build/learning/learned-value-ordering/) — Quand plusieurs pièces conviennent, laquelle poser ensuite ? Plutôt qu'une seule règle empirique, on transporte plusieurs signaux appris des bons plateaux et on les fait voter. Le vote empêche la recherche de trop se fier à une intuition unique et de foncer vers la même impasse. - [Fouille d'anti-motifs](https://eternity2.dev/fr/research/build/learning/anti-pattern-mining/) — L'idée subtile derrière l'apprentissage à partir des grilles fortes : tout accord entre elles n'est pas bon à prendre. Certains placements partagés sont de vraies structures ; d'autres sont un piège commun qui plafonne chaque recherche juste sous le sommet. Distinguer les deux, puis attaquer le piège. - [Décoder les records](https://eternity2.dev/fr/research/build/learning/decoding-records/) — La façon la plus littérale d'apprendre d'une grille forte : la reconstruire à l'identique, pièce par pièce, jusqu'à ce que votre recherche sache la reproduire. Ce que la reconstruction vous force à ajouter est l'ingrédient qui manquait à votre recherche, et la reproduction en est la preuve. - [Quand l'apprentissage s'effondre](https://eternity2.dev/fr/research/build/learning/when-learning-collapses/) — La moitié désenchantée de l'apprentissage à partir des grilles fortes. Un signal appris atteint fiablement le sommet de la plage propre à une recherche, puis s'arrête. Faites-lui trop confiance et la recherche s'effondre ; même utilisé parfaitement il ne relève pas le plafond, car le plafond n'est pas une chose que le corpus connaît. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. - [Apprendre à partir des grilles fortes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. --- # Fouille d'anti-motifs > L'idée subtile derrière l'apprentissage à partir des grilles fortes : tout accord entre elles n'est pas bon à prendre. Certains placements partagés sont de vraies structures ; d'autres sont un piège commun qui plafonne chaque recherche juste sous le sommet. Distinguer les deux, puis attaquer le piège. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/learning/anti-pattern-mining/ - Mise à jour: 2026-07-16 - Sujets: local-search, learning - Source: Ropke & Pisinger 2006, recherche adaptative à grand voisinage (le cadre destruction-réparation que l'on dirige ici) — https://doi.org/10.1287/trsc.1050.0135 --- Chaque technique vue jusqu'ici traite l'accord entre grilles fortes comme un atout : là où les bonnes grilles concordent, on les suit. Celle-ci décompose cet accord, car une partie en est un piège. Quand de nombreuses recherches indépendantes atteignent toutes une grille élevée mais imparfaite, elles s'accordent sur un très grand nombre de placements ; une partie de cet accord est une structure authentique, l'autre une mauvaise habitude partagée : un choix local qui paraît bon, semble forcé, et plafonne discrètement chaque recherche juste sous le sommet. Toute l'idée consiste à distinguer les deux, puis à attaquer le piège. ## Deux fréquences, pas une Un simple comptage ne peut pas séparer la vraie structure du piège, car les deux apparaissent presque partout. L'astuce est de calculer *deux* fréquences pour chaque motif candidat et de les comparer. Sur un corpus de grilles réparties sur une large plage de scores, pour chaque paire de cases adjacentes et chaque paire de pièces qui s'y trouve un jour, on mesure : $$ p_\text{high} = \frac{\#\{\text{grilles avec la paire, score} \ge 460\}}{\#\{\text{grilles} \ge 460\}}, \qquad p_\text{all} = \frac{\#\{\text{grilles avec la paire}\}}{\#\{\text{toutes les grilles}\}} $$ ainsi qu'un *plafond* : le meilleur score parmi les grilles contenant le motif. Deux catégories émergent. Un **bon consensus** correspond à un $p_\text{all}$ élevé avec un plafond élevé : un motif que les grilles fortes partagent *et* que les toutes meilleures grilles conservent, une structure réelle et digne de confiance. Un **piège de consensus** correspond à un $p_\text{all}$ élevé avec un plafond bloqué juste sous le sommet : un motif que presque toutes les grilles adoptent mais qu'aucune grille de tête ne retient, le mauvais choix consensuel qui verrouille toute une famille sous le record. La vue à fréquence unique ne peut pas les distinguer ; c'est le partage par bassin qui fait tout le travail. > **[Figure]** Interactif : la carte des pièges, famille de coins par famille de coins — interactive: PalimpsestDiagram. Rendered on the canonical page (link above); not shown in this markdown export. ## Diriger, pas interdire Savoir où sont les pièges transforme le corpus en une carte des placements à qui faire confiance et de ceux à défaire. L'expérience [PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) l'exploite pour diriger une recherche [ALNS](/fr/research/build/local-search/local-search-alns/) : on prend une grille prise dans le bassin du piège, on cherche le coin dont le retrait casse le plus de motifs-pièges tout en épargnant les motifs de bon consensus, on brise délibérément ces cases, et on rend la grille à la boucle de réparation, dont l'opérateur de destruction rouvre précisément ces régions brisées et les reconstruit. Dirigée ainsi, elle a atteint 463, la meilleure grille produite par ce projet (l'[expérience PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/), dont la grille versionnée se reproduit via `just research-record-boards`). La réserve est la leçon. Vouloir utiliser la liste des pièges *directement*, en forçant la recherche à éviter chaque placement piégé, n'a pas fonctionné et a dégradé les grilles. La valeur résidait dans la lecture du corpus pour choisir *où viser* la recherche, non dans le codage en dur de ses conclusions en interdiction. Une carte apprise est un bon repère pour orienter une recherche et un mauvais jeu de chaînes à lui river, ce qui est la même frontière entre départage et objectif qui traverse les [a priori de corpus](/fr/research/build/learning/corpus-priors/), vue de l'autre côté : ici le danger n'est pas de surpondérer un bon signal mais de trop se fier à un signal sur ce qui est *mauvais*. Même parfaitement dirigée, cette approche ne franchit pas le sommet. Reconstruire les régions piégées tend à ramener sur la même grille de tête déjà connue plutôt que sur une grille véritablement nouvelle, car le piège n'est pas une erreur qu'une recherche plus astucieuse éviterait ; c'est le [mur de rigidité](/fr/research/why/rigidity-wall/) lui-même. C'est le sujet de la [page sur l'effondrement](/fr/research/build/learning/when-learning-collapses/). ## À lire aussi - [Ordonnancement des coups appris](https://eternity2.dev/fr/research/build/learning/learned-value-ordering/) — Quand plusieurs pièces conviennent, laquelle poser ensuite ? Plutôt qu'une seule règle empirique, on transporte plusieurs signaux appris des bons plateaux et on les fait voter. Le vote empêche la recherche de trop se fier à une intuition unique et de foncer vers la même impasse. - [Quand l'apprentissage s'effondre](https://eternity2.dev/fr/research/build/learning/when-learning-collapses/) — La moitié désenchantée de l'apprentissage à partir des grilles fortes. Un signal appris atteint fiablement le sommet de la plage propre à une recherche, puis s'arrête. Faites-lui trop confiance et la recherche s'effondre ; même utilisé parfaitement il ne relève pas le plafond, car le plafond n'est pas une chose que le corpus connaît. - [PALIMPSEST](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Lire chaque plateau fort pour repérer les habitudes qui, en silence, plafonnent un plateau, puis les briser. Cette expérience a produit le meilleur plateau du projet : 463 sur 480. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. --- # Priors de corpus > La façon la plus simple d'apprendre des bons plateaux : compter où chaque pièce tend à se placer, ou à quelle fréquence elle satisfait une demande rare, et se servir de ce décompte comme d'un léger départage en construction. Ce doit rester un départage ; dès qu'il entre dans l'objectif, il fait s'effondrer la recherche. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/learning/corpus-priors/ - Mise à jour: 2026-07-16 - Sujets: construction, learning - Source: Recherche en faisceau (page concept de ce projet) : la construction à largeur bornée qu'un prior biaise — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx --- La chose la plus simple qu'on puisse apprendre d'un tas de bons plateaux est un décompte. Pour chaque case du plateau, à quelle fréquence chaque pièce s'y place-t-elle à travers les bons plateaux ? Ce simple relevé est un *prior* : une préférence statistique légère pour ce qui a tendance à appartenir à tel endroit. Il ne copie aucun plateau en particulier ; il lit toute la foule d'un coup et en distille un biais. ## La matrice de décomptes Prenez chaque plateau du corpus qui dépasse un seuil de score, et relevez une matrice $M[c][p]$ : combien de bons plateaux placent la pièce $p$ dans la case $c$. Normalisée par case, $M[c][\cdot]$ est une distribution sur les pièces pour cette position, la préférence apprise. Sa construction coûte une seule passe linéaire sur le corpus, et rien de plus au moment de la recherche qu'une consultation. > **[Figure]** Interactif : la carte de chaleur du prior de position — interactive: PriorDiagram. Rendered on the canonical page (link above); not shown in this markdown export. Le prior ne sert jamais qu'à départager. Une [recherche en faisceau](/fr/research/build/construct/beam-search/) étend ses plateaux partiels case par case ; quand deux placements candidats apparient le même nombre d'arêtes, le prior fait pencher le choix vers la pièce la plus typique des bons plateaux à cet endroit. Le décompte d'arêtes appariées décide toujours ; le prior ne parle que lorsque le décompte est muet. C'est l'expérience [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/), qui bâtit un plateau compétitif à partir d'une grille vide, sans plateau où s'ancrer, et atteint ainsi 460. Trois affûtages du même décompte méritent d'être nommés, car chacun échange la force du signal contre du bruit : - **Sensible à la rotation.** On scinde chaque pièce selon ses quatre rotations, de sorte que le prior préfère non seulement la bonne pièce mais la bonne orientation. La matrice passe de $256 \times 256$ à $1024 \times 256$ ; le signal est plus fin mais plus mince par case. - **Par famille de coins.** Les bons plateaux se répartissent en familles selon leurs quatre pièces de coin. Un prior bâti à partir des plateaux d'une seule famille capture une structure que la matrice mise en commun gomme par moyenne, ce qui a permis à PRIOR d'atteindre un bassin neuf plutôt que le bassin commun et encombré. - **Seuil plus sévère.** On reconstruit le prior à partir des seuls tout meilleurs plateaux. Le plafond de la construction s'élève, au prix d'un signal plus mince et plus bruité, appris à partir de moins d'exemples. ## Un prior sur la demande, pas la position Le décompte n'a pas à porter sur les positions. Un prior plus subtil demande, pour chaque *pièce*, à quelle fréquence elle finit par satisfaire une **demande rare** : une case dont les couleurs nord et ouest ne peuvent être servies que par une ou deux pièces de tout le jeu. Les bons plateaux satisfont de plus en plus les mêmes demandes rares à mesure qu'ils progressent, si bien qu'une pièce qui est souvent celle qui se dépense sur une couleur rare gagne un poids élevé. Classer les candidats selon les arêtes appariées plus un petit multiple de ce poids pousse la recherche à engager tôt les pièces rares, avant qu'elles ne soient dérobées. C'est l'expérience [LODESTONE](/fr/research/lab/experiments/raphael-anjou/learning/lodestone/), et elle se rattache à la [géographie des couleurs rares](/fr/research/why/rare-color-geography/) du puzzle. ## Pourquoi cela reste un départage Le détail porteur, pour le prior positionnel comme pour celui de la demande rare, est que le multiple sur le prior doit être *minuscule*. Un prior est un pur départageur : il tranche entre des coups qui apparient également, et rien de plus. Montez le poids ne serait-ce qu'un peu et la recherche se met à troquer une arête appariée réelle contre une intuition statistique, et le score s'effondre : LODESTONE tombe de 451 à 422 à 380 à mesure que le poids grimpe. Cet effondrement n'est pas un bogue d'implémentation ; c'est la forme de toute la famille, et il a sa propre page : [quand l'apprentissage s'effondre](/fr/research/build/learning/when-learning-collapses/). ## À lire aussi - [Ordonnancement des coups appris](https://eternity2.dev/fr/research/build/learning/learned-value-ordering/) — Quand plusieurs pièces conviennent, laquelle poser ensuite ? Plutôt qu'une seule règle empirique, on transporte plusieurs signaux appris des bons plateaux et on les fait voter. Le vote empêche la recherche de trop se fier à une intuition unique et de foncer vers la même impasse. - [Quand l'apprentissage s'effondre](https://eternity2.dev/fr/research/build/learning/when-learning-collapses/) — La moitié désenchantée de l'apprentissage à partir des grilles fortes. Un signal appris atteint fiablement le sommet de la plage propre à une recherche, puis s'arrête. Faites-lui trop confiance et la recherche s'effondre ; même utilisé parfaitement il ne relève pas le plafond, car le plafond n'est pas une chose que le corpus connaît. - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - [LODESTONE](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/lodestone/) — Une boussole ténue pour une recherche partie de zéro : l'inciter à engager les pièces rares tôt, là où elles sont nécessaires. Elle ne relève pas le plafond ; elle fait que la recherche atteint de façon fiable le sommet de sa propre plage. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. --- # Décoder les records > La façon la plus littérale d'apprendre d'une grille forte : la reconstruire à l'identique, pièce par pièce, jusqu'à ce que votre recherche sache la reproduire. Ce que la reconstruction vous force à ajouter est l'ingrédient qui manquait à votre recherche, et la reproduction en est la preuve. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/learning/decoding-records/ - Mise à jour: 2026-07-16 - Sujets: backtracking, learning - Source: Grilles record de la communauté (chronologie des records de ce projet) : les témoins qu'un rejeu reconstruit — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/records.mdx --- Les priors de corpus et le minage d'anti-motifs apprennent une *statistique* à partir de nombreuses grilles. Cette technique-ci apprend d'une *seule* grille, et elle apprend la chose la plus difficile à percevoir de loin : le coup unique qu'une recherche ordinaire ne peut pas jouer. La méthode est d'une littéralité brutale. Prenez une grille record connue, et tentez de faire reconstruire cette grille à votre propre recherche, à l'identique, pièce par pièce. Tout ce que vous devez ajouter à votre recherche avant qu'elle puisse emprunter ce chemin est précisément l'ingrédient qui lui manquait, et la reconstruction exacte prouve que cet ingrédient est réel. ## La reproduction comme preuve Le dispositif est une recherche en profondeur d'abord menée dans un mode délibérément contraint, visant une grille témoin précise plutôt que d'explorer librement : - **Ordonnancement du prior avant le coût.** Un backtracker ordinaire tolérant aux ruptures classe les placements candidats par coût de désaccord immédiat, le moins cher d'abord. Un rejeu inverse la priorité, de sorte que les placements réellement utilisés par la grille témoin l'emportent sur ceux qui paraissent moins chers. La recherche est tirée le long du bon chemin connu au lieu de s'en écarter. - **Une queue exacte.** Les dernières cellules sont résolues exactement plutôt que de façon heuristique, si bien que la finale qu'une exécution ordinaire bâcle est fermée de manière déterministe. - **La relaxation à l'épreuve.** L'ordonnancement et la queue étant fixés, vous faites varier la seule règle que vous soupçonnez d'être la barrière, et vous guettez l'instant où le témoin se reconstruit. C'est l'expérience [REPLAY](/fr/research/lab/experiments/raphael-anjou/learning/replay/), et ce qu'elle a trouvé sur les grilles strict-460 de la communauté est un exemple net de la récompense. La recherche tolérante aux ruptures propre au projet avait saturé à 457 ou 458 quoi qu'il arrive, et la raison s'est révélée être une seule règle que personne n'avait remise en question : elle n'autorisait au plus qu'*une* arête en désaccord par cellule. Les grilles record contiennent chacune quatre ou cinq cellules qui paient *deux* désaccords d'un coup. Une recherche plafonnée à une rupture par cellule est littéralement incapable de représenter ces grilles ; elle était donc coupée des cibles mêmes qu'elle poursuivait. > **[Figure]** Interactif : les cellules à double rupture — interactive: DoubleBreakDiagram. Rendered on the canonical page (link above); not shown in this markdown export. > **[Figure]** Interactif : rejouer le calendrier des ruptures — interactive: DoubleBreakLab. Rendered on the canonical page (link above); not shown in this markdown export. Portez le budget par cellule de un à deux, et les deux témoins strict-460 de la communauté se reconstruisent à l'identique, chaque pièce à sa place, le score se vérifiant arête après arête. La reconstruction *est* le résultat : un résultat de complétude de recherche déguisé en tentative de record. Le mur était dans l'ensemble des coups, pas dans le calcul. ## Ce que le décodage peut et ne peut pas acheter Décoder un record est le diagnostic le plus tranchant de cette famille, car il transforme un soupçon vague (« il manque quelque chose à notre recherche ») en une affirmation précise et vérifiable (« elle ne peut pas payer deux ruptures sur une même cellule »). Il est aussi, dans le même souffle, le plus franc sur ses limites. Retrouver la double rupture hisse l'échelle stricte à 460, mais il ne dit pas, à lui seul, si deux ruptures par cellule ouvrent un chemin vers 461 et au-delà ou seulement vers les 460 connus. Le décodage vous dit l'ingrédient qu'un témoin a utilisé ; il ne garantit pas que cet ingrédient porte plus loin que le témoin lui-même. Cet écart, un coup appris qui atteint le plateau sans rien prouver au-delà, est le thème de la [page sur l'effondrement](/fr/research/build/learning/when-learning-collapses/). ## À lire aussi - [Fouille d'anti-motifs](https://eternity2.dev/fr/research/build/learning/anti-pattern-mining/) — L'idée subtile derrière l'apprentissage à partir des grilles fortes : tout accord entre elles n'est pas bon à prendre. Certains placements partagés sont de vraies structures ; d'autres sont un piège commun qui plafonne chaque recherche juste sous le sommet. Distinguer les deux, puis attaquer le piège. - [Quand l'apprentissage s'effondre](https://eternity2.dev/fr/research/build/learning/when-learning-collapses/) — La moitié désenchantée de l'apprentissage à partir des grilles fortes. Un signal appris atteint fiablement le sommet de la plage propre à une recherche, puis s'arrête. Faites-lui trop confiance et la recherche s'effondre ; même utilisé parfaitement il ne relève pas le plafond, car le plafond n'est pas une chose que le corpus connaît. - [REPLAY](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/replay/) — Reconstruire à l'identique les plateaux stricts à 460 de la communauté, et découvrir au passage le coup que les solveurs ordinaires ne savent pas jouer : payer deux désaccords sur une même case. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Apprentissage des no-goods : se souvenir de ses échecs](https://eternity2.dev/fr/research/build/reduce/nogood-learning/) — Un sous-arbre voué à l'échec est un théorème : cet état partiel ne pourra jamais s'étendre. Mémorisez-le et n'y revenez plus jamais. La communauté a essayé les deux variantes : tables de transposition à la manière des échecs sur la frontière de recherche, et contraintes extraites du puzzle lui-même. Le bilan complet de ce que la mémoire achète à l'échelle d'E2, et les petits plateaux où elle paie vraiment. --- # Ordonnancement des coups appris > Quand plusieurs pièces conviennent, laquelle poser ensuite ? Plutôt qu'une seule règle empirique, on transporte plusieurs signaux appris des bons plateaux et on les fait voter. Le vote empêche la recherche de trop se fier à une intuition unique et de foncer vers la même impasse. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/learning/learned-value-ordering/ - Mise à jour: 2026-07-16 - Sujets: construction, learning - Source: La recherche en faisceau (page concept de ce projet) : la construction dont l'ordonnancement des valeurs est appris — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx --- Lorsqu'on construit un plateau pièce par pièce, la décision difficile est de choisir quelle pièce poser ensuite quand plusieurs conviennent tout aussi bien. Une règle empirique unique - le coût le plus faible d'abord, la case la plus contrainte d'abord - a tendance à conduire la recherche vers la même impasse à chaque exécution. Un [a priori de corpus](/fr/research/build/learning/corpus-priors/) améliore les choses grâce à un signal appris. Cette technique va plus loin encore en transportant *plusieurs* signaux appris à la fois et en les faisant voter, de sorte qu'aucune intuition ne s'approprie à elle seule la décision. ## Plusieurs signaux, un seul vote À partir du corpus des bons plateaux, on peut apprendre plus d'une chose à la fois, et les signaux sont de simples décomptes bon marché sur le même ensemble de plateaux : - **Pièce-en-position.** À quelle fréquence une pièce apparaît dans une case donnée à travers les bons plateaux : l'a priori positionnel de la page précédente. - **Adjacence de paires de pièces.** À quelle fréquence deux pièces particulières finissent au contact. Un voisinage que le décompte positionnel ne voit pas. - **L'a priori de patch 2×2.** Pour chaque petit patch de quatre cases, un rapport de log-cotes lissé à la Laplace mesurant combien de fois il apparaît dans les plateaux à haut score par rapport aux plateaux à bas score. Un patch courant dans les bons plateaux et rare dans les mauvais obtient un score positif ; un patch piège-à-consensus obtient un score négatif. C'est le plus tranchant des trois, car c'est le seul qui oppose le bon au mauvais plutôt que de se contenter de compter le bon. À chaque étape, le faisceau évalue chaque pose candidate par son gain en arêtes appariées augmenté d'une somme pondérée des trois signaux, et conserve les quelques meilleures. Un peu de hasard injecté empêche les faisceaux parallèles de s'effondrer sur un seul chemin. > **[Figure]** Interactif : le vote de pose à trois signaux — interactive: KeyringDiagram. Rendered on the canonical page (link above); not shown in this markdown export. C'est l'expérience [KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/), un trousseau d'intuitions plutôt qu'une seule. Elle a atteint 460 dans une famille de coins qu'aucune recherche antérieure n'avait su percer, et c'est là le vrai bénéfice : puisque les bons plateaux sont connus pour occuper des bassins isolés, un signal assez varié pour atteindre une *nouvelle* famille vaut plus qu'un signal qui redécouvre un plateau déjà connu. ## Pourquoi le vote surpasse un signal unique Un signal appris unique a le même mode d'échec qu'une règle unique écrite à la main : partout où il se trompe, il se trompe à chaque fois, et il entraîne tous les faisceaux dans la même direction. Trois signaux appris à partir de vues différentes du corpus - position, adjacence et qualité de patch - se contredisent en des endroits différents, et leur désaccord est précisément le hasard qui maintient les faisceaux en exploration de régions différentes. L'a priori de patch porte le plus de poids parce qu'il est le seul à encoder le *mauvais* : il peut éloigner la recherche d'une pose, et pas seulement l'y attirer, ce qui est le germe de l'idée qui mûrit en [fouille d'anti-motifs](/fr/research/build/learning/anti-pattern-mining/). La même réserve que pour tout signal appris s'applique. Les trois a priori sont extraits d'un corpus lui-même sous-optimal ; ils encodent donc autant le plafond de la communauté que sa sagesse, et le vote atteint de façon fiable le sommet de la portée de la recherche sans relever cette portée. L'endroit où se situe cette frontière fait [l'objet de sa propre page](/fr/research/build/learning/when-learning-collapses/). ## À lire aussi - [Priors de corpus](https://eternity2.dev/fr/research/build/learning/corpus-priors/) — La façon la plus simple d'apprendre des bons plateaux : compter où chaque pièce tend à se placer, ou à quelle fréquence elle satisfait une demande rare, et se servir de ce décompte comme d'un léger départage en construction. Ce doit rester un départage ; dès qu'il entre dans l'objectif, il fait s'effondrer la recherche. - [Fouille d'anti-motifs](https://eternity2.dev/fr/research/build/learning/anti-pattern-mining/) — L'idée subtile derrière l'apprentissage à partir des grilles fortes : tout accord entre elles n'est pas bon à prendre. Certains placements partagés sont de vraies structures ; d'autres sont un piège commun qui plafonne chaque recherche juste sous le sommet. Distinguer les deux, puis attaquer le piège. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [Motifs interdits](https://eternity2.dev/fr/research/why/forbidden-patterns/) — Presque tout petit assemblage de pièces que l'on pourrait construire est impossible. Pour un carré 2×2, 99,72 % des façons de placer quatre pièces ne pourront jamais s'accorder. --- # Quand l'apprentissage s'effondre > La moitié désenchantée de l'apprentissage à partir des grilles fortes. Un signal appris atteint fiablement le sommet de la plage propre à une recherche, puis s'arrête. Faites-lui trop confiance et la recherche s'effondre ; même utilisé parfaitement il ne relève pas le plafond, car le plafond n'est pas une chose que le corpus connaît. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/learning/when-learning-collapses/ - Mise à jour: 2026-07-16 - Sujets: learning, search-space - Source: Le mur de rigidité (ce projet) : le plafond mesuré que tout signal appris atteint et qu'aucun ne franchit — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/why/rigidity-wall.mdx --- Les quatre autres pages de cette section traitent de ce que l'apprentissage à partir des grilles fortes *rapporte*. Celle-ci traite de l'endroit où il s'arrête, et c'est la page qui maintient toute la famille les pieds sur terre, car chaque technique présentée ici partage les deux mêmes modes d'échec et il vaut mieux les énoncer clairement que de laisser un lecteur prendre un sac d'astuces apprises pour un moyen de franchir le mur. ## Échec un : le signal devient l'objectif Chaque signal appris de cette section n'est sûr qu'en tant que *départage*. Il tranche entre des coups par ailleurs équivalents sur la seule chose qui compte vraiment, le bord apparié devant vous, et il ne doit jamais l'emporter sur cette chose. Dès l'instant où un a priori appris passe du rang de départage à celui de composante de l'objectif, la recherche se met à échanger un vrai bord apparié contre une intuition statistique, et elle s'effondre. [LODESTONE](/fr/research/lab/experiments/raphael-anjou/learning/lodestone/) en est la mesure la plus nette. À un poids infime, son a priori de pièces rares en premier fait passer le score médian de départ de 449 à 451 et resserre la dispersion. Augmentez le poids ne serait-ce que légèrement et le score chute à 422, puis 380, car courir après les demandes rares du corpus s'échange alors directement contre l'appariement du bord devant vous. La même forme apparaît dans le [minage d'anti-patrons](/fr/research/build/learning/anti-pattern-mining/) par l'autre bout : utiliser la liste des pièges comme un guidage doux atteignait 463, mais *interdire* durement les placements piégés dégradait les grilles. Un signal appris est un bon coup de pouce et une mauvaise loi. L'effondrement n'est pas un accident de réglage qu'on pourrait faire disparaître par l'ingénierie ; c'est le signal qui vous dit qu'il n'a jamais été qu'une intuition. ## Échec deux : le plafond n'est pas dans le corpus La limite plus profonde est plus discrète, parce qu'elle ressemble à un succès. Utilisé correctement, comme départage, un signal appris porte fiablement une recherche jusqu'au sommet de *sa propre plage*, et pas plus loin. LODESTONE dit explicitement qu'il « ne touche pas le plafond du bassin qui arrête toute méthode près du sommet ». [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/) et [KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/) atteignent 460 en partant de zéro, le sommet de la plage de construction depuis zéro, mais pas au-delà. [PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/), le plus fort d'entre eux, atteint 463 puis constate que reconstruire les régions piégées ramène sur la même grille sommet déjà connue plutôt que sur une nouvelle. La raison est structurelle, et c'est la thèse de toute la section retournée. Chaque grille du corpus est elle-même bloquée sous 480. Un signal miné à partir de ce corpus encode *où se trouvent* les grilles fortes, c'est-à-dire le plateau, si bien qu'un signal appris qui se contente de ré-encoder le plateau ne peut pas hisser une recherche au-dessus. Le corpus connaît la forme du bassin dans lequel ses grilles sont prises ; il ne connaît pas la sortie, parce qu'aucune de ses grilles ne l'a trouvée. Ce qui arrête toute méthode près du sommet, c'est le [mur de rigidité](/fr/research/why/rigidity-wall/) : près d'une grille forte, les désappariements restants se verrouillent en un unique [σ-cycle](/fr/research/why/sigma-cycles/) imbriqué qu'aucun coup local ne peut ouvrir. Ce mur est une propriété du casse-tête, non de l'ignorance d'une recherche, et aucun minage de corpus ne le déplace, car le corpus est fait de grilles qui butent contre ce même mur. ## À quoi sert vraiment cette famille Rien de tout cela ne rend l'apprentissage à partir des grilles fortes inutile. Cela le rend *précis*. Un signal appris est le moyen le plus rapide et le plus fiable d'amener une recherche *jusqu'au* plateau : construire une grille compétitive à partir de rien (PRIOR, KEYRING), l'atteindre dans un bassin inédit (la nouvelle famille de coins de KEYRING), se poser à chaque fois au sommet de la plage plutôt que de trébucher parfois (la dispersion resserrée de LODESTONE), ou diagnostiquer le coup exact qui manquait à une recherche pour atteindre une hauteur connue (le double déblocage de [REPLAY](/fr/research/lab/experiments/raphael-anjou/learning/replay/)). Ce à quoi il ne sert pas, c'est à passer *au-delà* du plateau, et une section sur l'apprentissage à partir des grilles fortes qui prétendrait le contraire vendrait au lecteur la seule chose que le corpus, de façon prouvée, ne peut pas contenir. Les pipelines construire-puis-raffiner qui atteignent les meilleures grilles de ce projet répartissent le travail proprement : un constructeur appris pour atteindre vite le sommet de la plage, puis une confrontation distincte avec le mur de rigidité, que l'apprentissage à partir des grilles fortes sait décrire mais ne sait pas dissoudre. ## À lire aussi - [Priors de corpus](https://eternity2.dev/fr/research/build/learning/corpus-priors/) — La façon la plus simple d'apprendre des bons plateaux : compter où chaque pièce tend à se placer, ou à quelle fréquence elle satisfait une demande rare, et se servir de ce décompte comme d'un léger départage en construction. Ce doit rester un départage ; dès qu'il entre dans l'objectif, il fait s'effondrer la recherche. - [Fouille d'anti-motifs](https://eternity2.dev/fr/research/build/learning/anti-pattern-mining/) — L'idée subtile derrière l'apprentissage à partir des grilles fortes : tout accord entre elles n'est pas bon à prendre. Certains placements partagés sont de vraies structures ; d'autres sont un piège commun qui plafonne chaque recherche juste sous le sommet. Distinguer les deux, puis attaquer le piège. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - [LODESTONE](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/lodestone/) — Une boussole ténue pour une recherche partie de zéro : l'inciter à engager les pièces rares tôt, là où elles sont nécessaires. Elle ne relève pas le plafond ; elle fait que la recherche atteint de façon fiable le sommet de sa propre plage. --- # Recherche locale > Partir d'un plateau complet mais imparfait et l'améliorer par des mouvements : destruction-réparation, recuit et trempe, recombinaison évolutionnaire. Les polisseurs les plus fiables du site, et les démonstrations les plus nettes du mur de rigidité, où chacun d'eux s'arrête à la même hauteur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/local-search/ - Mise à jour: 2026-07-13 --- Partir d'un plateau complet mais imparfait et l'améliorer par des mouvements : destruction-réparation, recuit et trempe, recombinaison évolutionnaire. Les polisseurs les plus fiables du site, et les démonstrations les plus nettes du mur de rigidité, où chacun d'eux s'arrête à la même hauteur. Les pages ci-dessous procèdent technique par technique : ce qu'est chacune en une ligne, ce qu'elle a réellement atteint sur le vrai plateau 16×16, où elle s'arrête, et les laboratoires et mesures qui l'étayent. Pour l'ensemble du territoire d'un seul coup d'œil, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). ## Pages de cette section - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. - [Recuit simulé et tempérage parallèle](https://eternity2.dev/fr/research/build/local-search/parallel-tempering/) — Voir les désaccords comme de l'énergie et la température comme une tolérance à la dégradation. Le recuit détient le plus ancien record du puzzle ; le tempérage parallèle franchit des barrières que le recuit ne passe pas. Les deux butent sur le même mur. - [Approches évolutionnaires et génétiques](https://eternity2.dev/fr/research/build/local-search/evolutionary/) — Faire évoluer une population de plateaux, garder les plus adaptés, recombiner les survivants. La métaphore la plus naturelle de la boîte à outils, et la seule méthode dont l'opérateur central, le croisement, s'oppose de front à la structure d'Eternity II. Le relevé complet de ce que la communauté a fait évoluer, mesuré et abandonné. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. --- # Approches évolutionnaires et génétiques > Faire évoluer une population de plateaux, garder les plus adaptés, recombiner les survivants. La métaphore la plus naturelle de la boîte à outils, et la seule méthode dont l'opérateur central, le croisement, s'oppose de front à la structure d'Eternity II. Le relevé complet de ce que la communauté a fait évoluer, mesuré et abandonné. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/local-search/evolutionary/ - Mise à jour: 2026-07-02 - Sujets: local-search, learning - Source: Le plan complet de GA de simon.chapple : génome en spirale, gènes contraints par classe, fitness (groups.io message 302) — https://groups.io/g/eternity2/message/302 - Source: L'étude GA de deux semaines de Steve Moyer, « Le croisement semble n'avoir aucun impact » (groups.io message 565) — https://groups.io/g/eternity2/message/565 - Source: cambdacambda : le croisement n'est pas utile ; population x10 = CPU x10, mêmes itérations (groups.io message 578) — https://groups.io/g/eternity2/message/578 - Source: sam_maes : la mutation est évidente, un opérateur de croisement plausible ne l'est pas (groups.io message 1468) — https://groups.io/g/eternity2/message/1468 - Source: sam_maes sur le vrai problème, les bonnes solutions partielles sont difficiles à combiner (groups.io message 1492) — https://groups.io/g/eternity2/message/1492 - Source: TD : mélanger deux parents, c'est mélanger deux permutations ; doublons, trous et l'idée de réparation (groups.io message 1500) — https://groups.io/g/eternity2/message/1500 - Source: Le plateau du GA de mobaladje vers 406/480 (groups.io message 2360) — https://groups.io/g/eternity2/message/2360 - Source: La recette classique de mobaladje, et des non-appariements répartis uniformément sur le plateau (groups.io message 2516) — https://groups.io/g/eternity2/message/2516 - Source: Lyman : deux solutions partielles ont de fortes chances de vouloir les mêmes pièces à des emplacements différents (groups.io message 2591) — https://groups.io/g/eternity2/message/2591 - Source: L'esquisse de croisement-réparation de Lyman, avec son propre verdict (groups.io message 2612) — https://groups.io/g/eternity2/message/2612 - Source: L'hybride backtracker+GA d'antminder, 462/480 en environ un jour avec un opérateur de réparation de Munkres (groups.io message 5589) — https://groups.io/g/eternity2/message/5589 - Source: Pierre Schaus explique le voisinage d'affectation optimale derrière cette réparation (groups.io message 5601) — https://groups.io/g/eternity2/message/5601 - Source: antminder le remise au placard ; une semaine pour atteindre 463, et l'eii de Verhaard « l'écrase complètement » (groups.io message 5950) — https://groups.io/g/eternity2/message/5950 - Source: L'autopsie de 2011 de jagbrain sur les raisons pour lesquelles les hypothèses de GA/SA échouent sur cet espace de recherche (groups.io message 8257) — https://groups.io/g/eternity2/message/8257 - Source: Niang, Solving the Eternity II Puzzle using Evolutionary Computing Techniques (mémoire de MASc, Concordia, 2011) — https://spectrum.library.concordia.ca/id/eprint/7487/1/Niang_MASc_S2011.pdf - Source: Wauters, Vancroonenburg & Vanden Berghe, A guide-and-observe hyper-heuristic approach to the Eternity II puzzle (JMMA 11, 2012) — https://link.springer.com/article/10.1007/s10852-012-9178-4 --- Dix jours après le lancement du puzzle, la liste de diffusion avait déjà sur la table une conception complète d'algorithme génétique : numéroter les pièces, enfiler le plateau sur un génome en spirale partant de la pièce-indice, noter la connectivité, faire évoluer ([groups.io message 302](https://groups.io/g/eternity2/message/302)). C'est la métaphore la plus naturelle de la boîte à outils : une population de plateaux, la survie des mieux appariés, des enfants qui héritent de bons fragments de deux bons parents. Au fil des années suivantes, la communauté a construit ces solveurs, les a mesurés soigneusement, et les a vus l'un après l'autre plafonner dans le bas des 400 pendant que de simples backtrackers filaient bien au-delà. Cette page enseigne la recette, puis la raison de son échec. Cette raison mérite d'être bien comprise, car elle ne tient pas au fait que « les GA sont faibles » mais à un heurt structurel précis entre le croisement et les problèmes de permutation. De là, la page suit les idées qui ont survécu jusqu'aux pages où elles vivent aujourd'hui. ## La recette sur un plateau Un algorithme génétique a besoin de quatre ingrédients, et Eternity II offre chacun d'eux presque trop facilement : 1. **Génome.** Une solution candidate encodée pour la reproduction. Ici : une affectation des 256 pièces aux 256 cases, plus une rotation pour chacune (de façon équivalente, une permutation de la liste de pièces). Le plan de Chapple, dès la semaine du lancement, enfilait les cases sur une spirale partant de la pièce-indice vers l'extérieur, avec les gènes de bordure et de coin contraints aux pièces de bordure et de coin ([message 302](https://groups.io/g/eternity2/message/302)) ; la plupart des implémentations ultérieures ont utilisé directement le plateau plat. 2. **Fitness.** Compter les arêtes appariées, le même score de 0 à 480 dans lequel est libellée l'[échelle des records](/fr/research/records/). Le solveur de mobaladje était exactement cette boucle classique : générer une population aléatoire, évaluer, sélectionner les meilleurs, les croiser, muter un peu, recommencer ([message 2516](https://groups.io/g/eternity2/message/2516)). 3. **Mutation.** Échanger deux pièces, en faire pivoter une sur place, brouiller un petit pan. Tout le monde s'accordait à dire que cette partie était facile: « les opérateurs de mutation sont évidents », comme le formulait le premier fil de discussion sérieux sur les GA ([message 1468](https://groups.io/g/eternity2/message/1468)). 4. **Croisement.** Prendre deux parents à haut score et produire un enfant qui hérite des deux. C'est l'ingrédient qui fait qu'un GA est un GA plutôt qu'une population de grimpeurs de collines, et sur ce puzzle c'est là que tout se gâte. ## Le problème central : le croisement sur une permutation La promesse du croisement, c'est la recombinaison de briques de base : une créature qui excelle à voler et une qui excelle à nager pourraient produire une créature qui fait les deux. Lyman Hurd a énoncé la prémisse sur la liste (ainsi que son propre doute) en une phrase : deux solutions partielles ont de fortes chances de vouloir *les mêmes tuiles à des emplacements différents* ([message 2591](https://groups.io/g/eternity2/message/2591)). Rendons cela concret. Un génome est une permutation de 256 pièces. Prenez deux bons parents et coupez-les en un point (ou mélangez-les uniformément) : l'enfant garde les cases 1 à $k$ du parent A et le reste du parent B. Comme les parents arrangent différemment les *mêmes* pièces, l'enfant détient désormais certaines pièces en double et en manque d'autres entièrement ; ce n'est pas du tout un plateau. TD l'a détaillé quelques heures à peine après que la question a été posée : mélanger deux parents, c'est mélanger deux permutations de 1..256, et le résultat « n'est pas une permutation valide car certaines valeurs sont dupliquées et d'autres sont manquantes » ([message 1500](https://groups.io/g/eternity2/message/1500)). Regardez cela se produire. Deux parents *parfaits* (le même plateau résolu et sa rotation d'un quart de tour, deux arrangements irréprochables des mêmes pièces) produisent un enfant illégal à presque chaque point de coupe : > **[Figure]** Interactif : conflits de croisement dans la recombinaison — interactive: CrossoverClashLab. Rendered on the canonical page (link above); not shown in this markdown export. La fitness de l'enfant naïf est quasi parfaite, et c'est là le piège : chaque moitié héritée est résolue en interne, si bien qu'une fonction de fitness qui compte les arêtes adore un génome qui n'est même pas un plateau. Toute correction pratique est un **opérateur de réparation** : supprimer les doublons, insérer les pièces manquantes ([message 1500](https://groups.io/g/eternity2/message/1500)), ou échanger les entrées dupliquées entre les deux enfants pour préserver autant de « bonnes idées » que possible, comme Lyman l'a esquissé avant de conclure qu'il avait « peu d'espoir que cela tombe par hasard sur la solution réelle » ([message 2612](https://groups.io/g/eternity2/message/2612)). Mais les gènes réparés atterrissent dans des cases dont les voisins ont été hérités de l'*autre* parent, où ils n'apparient rien. La réparation transforme le croisement en une mutation vaste et mal ajustée. À ce stade, la population n'est qu'un ensemble de grimpeurs de collines par mutation parallèles qui paient le surcoût du croisement. > **Mais le croisement marche sur le TSP, non ?** > > sam_maes a soulevé l'objection naturelle : les GA gèrent le problème du voyageur de commerce, lui aussi un problème de permutation ([message 1492](https://groups.io/g/eternity2/message/1492)). La différence tient à ce qu'est une « brique de base ». La valeur d'un circuit réside dans ses adjacences, et les croisements préservant l'ordre (OX, PMX) héritent de fragments d'adjacence de façon significative. La valeur d'un plateau Eternity II réside dans des placements exacts pièce-sur-case vérifiés contre 22 couleurs, et deux bons plateaux ne s'accordent sur presque aucun. Le propre diagnostic de sam_maes était le bon : le problème n'est pas la taille de l'espace de recherche mais que « les bonnes solutions partielles sont difficiles à combiner ». La version la plus profonde de cet argument a été mesurée sur ce site des années plus tard : deux plateaux à haut score sont liés par de grands [σ-cycles](/fr/research/why/sigma-cycles/) imbriqués, et toute application *partielle* d'un cycle obtient un score pire que l'une ou l'autre des extrémités. Le croisement est exactement une application partielle de la permutation qui relie les parents. La vallée entre deux bons parents n'est pas un accident de l'opérateur : c'est la structure du paysage. ## Ce que la communauté a mesuré Le relevé, dans l'ordre chronologique, est remarquablement cohérent. - **2007, l'étude de deux semaines.** Steve Moyer a fait tourner un GA de 1000 individus avec croisement préservant l'ordre et a rapporté les chiffres qui ont tranché la question tôt : « Le croisement semble n'avoir aucun impact », et la taille de la population importe à peine, puisqu'une population de 100 individus convergeait à peu près aussi vite pour un dixième du coût ([message 565](https://groups.io/g/eternity2/message/565)). Une réponse indépendante a confirmé les deux constats à partir d'expériences distinctes ([message 578](https://groups.io/g/eternity2/message/578)). - **2007, les plateaux.** Le GA d'insurrectors sur le 14×14 intérieur a atteint 326 à 330 des 364 arêtes puis s'est bloqué, concluant que les GA « sont assez mauvais sur ce type de problèmes combinatoires » ([message 1311](https://groups.io/g/eternity2/message/1311)). Le GA plateau complet de mobaladje a touché son optimum local « vers 406 (/480) » ([message 2360](https://groups.io/g/eternity2/message/2360)), les non-appariements répartis uniformément sur le plateau, sans région faible réparable ([message 2516](https://groups.io/g/eternity2/message/2516)). JSA a pointé le problème sous-jacent : la métrique sur 480 est un mauvais guide, et personne n'en a trouvé de meilleure ([message 2683](https://groups.io/g/eternity2/message/2683)). - **2008, l'hybride sérieux.** antminder a construit le solveur évolutionnaire le plus fort de l'archive : un backtracker tourne pendant environ 3 minutes et remplit légalement la majeure partie du plateau, puis un GA en régime permanent (chaque individu forcé unique) peaufine le reste. Le croisement disruptif est compensé par un opérateur de réparation qu'il avait déjà utilisé sur des problèmes de suivi : retirer des pièces non adjacentes et laisser l'algorithme de Munkres/hongrois les replacer *de façon optimale*. En moyenne, sur sept exécutions : 462/480 en un peu plus d'un jour ([message 5589](https://groups.io/g/eternity2/message/5589)). Pierre Schaus, de l'article JFPC duquel provenait l'opérateur, a confirmé le mécanisme sur la liste ([message 5601](https://groups.io/g/eternity2/message/5601)). Notez ce qui est arrivé à l'architecture : le GA ne fait plus évoluer des plateaux à partir de zéro ; il gère une boucle de redémarrage autour d'un backtracker et applique une réparation locale exacte. La couche génétique est devenue un simple échafaudage. - **2008, la mise au placard.** Trois mois plus tard, antminder a rapporté que son programme avait besoin « d'une semaine pour atteindre un score partiel de 463 » et que l'[eii](/fr/research/lab/experiments/louis-verhaard/eii/) de Louis Verhaard, fondé sur le backtracking, « l'écrase complètement » ([message 5950](https://groups.io/g/eternity2/message/5950)). Il l'a remisé. eii a ensuite porté le record de 467 ; aucun solveur évolutionnaire n'apparaît nulle part dans la lignée des records après ce point. - **La longue traîne.** Un blog de 2009 a demandé à la liste quel croisement les gens utilisaient ; la seule réponse de fond déconseillait d'espérer voir les GA progresser sans « reculer et ruiner les progrès précédents » ([message 6835](https://groups.io/g/eternity2/message/6835)). Un solveur de 2010 combinant réseau de neurones et GA a été partagé avec la mise en garde toute simple « il ne résoudra pas votre puzzle de toute façon » ([message 7454](https://groups.io/g/eternity2/message/7454)). Un recensement de solveurs de 2011 a enregistré 190 pièces par backtracking pur contre 209 avec un hybride génétique ([message 8787](https://groups.io/g/eternity2/message/8787)) : honorable, et à quelque cinquante pièces du meilleur de la même époque. jagbrain a écrit l'autopsie de la communauté la même année : les GA et le recuit supposent un paysage que l'on peut gravir, or celui-ci est immense, « fractalisé », avec un placement des solutions quasi aléatoire ([message 8257](https://groups.io/g/eternity2/message/8257)). - **Là où un GA *a* brillé.** Sur le sous-problème lisse des ensembles de rotations (choisir une rotation par pièce de sorte que tous les décomptes de couleurs s'équilibrent), le GA d'antminder « ne reste presque jamais bloqué dans un minimum local » ([message 3443](https://groups.io/g/eternity2/message/3443)) et celui de Varga trouvait des ensembles équilibrés en quelques secondes là où le backtracking échouait ([message 8900](https://groups.io/g/eternity2/message/8900)). Le contraste est la leçon : l'évolution gère très bien la relaxation ; il se trouve simplement que la relaxation n'élaguait rien. Le relevé académique concorde avec celui de la liste. Le seul traitement de la longueur d'un mémoire consacré au calcul évolutionnaire appliqué à Eternity II ([Niang 2011](https://spectrum.library.concordia.ca/id/eprint/7487/1/Niang_MASc_S2011.pdf)) passe en revue l'espace de conception des GA sans détrôner les métaheuristiques de la littérature de 2008-2012, et les heuristiques publiées les plus fortes de cette veine (recherche tabou, VLNS, [hyper-heuristiques](https://link.springer.com/article/10.1007/s10852-012-9178-4)) ont toutes abandonné la recombinaison de plateaux. ## Où sont allées les idées survivantes Rien sur ce wiki n'est plus mort que la reproduction de plateaux, mais trois idées de l'ère des GA ont survécu en déménageant : - **La population est devenue des redémarrages.** Une fois que le croisement n'apporte rien, une population de plateaux en mutation est exactement un portefeuille de redémarrages indépendants. Le constat de Moyer selon lequel la taille de la population importe à peine est la leçon des redémarrages déguisée: des tirages indépendants de la même distribution, non une évolution qui se cumule. Le dossier mesuré des portefeuilles de redémarrage est sur la [page des redémarrages](/fr/research/build/backtracking/restarts/). - **Mutation + sélection + réparation intelligente est devenue l'ALNS.** L'opérateur de réparation de Munkres d'antminder à l'intérieur d'une boucle de destruction/reconstruction *est* le remplissage fondé sur l'affectation de la [recherche locale et l'ALNS](/fr/research/build/local-search/local-search-alns/), où il reste le polisseur le plus fiable de ce projet. La partie gagnante de l'hybride de 2008 n'a jamais été la génétique ; c'était le voisinage. - **L'évolution est montée d'un niveau.** La veine des hyper-heuristiques ([Wauters et al. 2012](https://link.springer.com/article/10.1007/s10852-012-9178-4)) conserve la sélection et l'adaptation mais les applique aux *opérateurs*, non aux plateaux : apprendre quels coups paient et s'appuyer dessus. C'est littéralement l'étape « adapter » de l'ALNS. Faire évoluer les paramètres de la recherche a survécu ; faire évoluer ses solutions non. ## Ce que cela coûte - **Par génération : $O(P \cdot (f + g))$** pour une taille de population $P$, un coût de fitness $f$ (un décompte linéaire d'arêtes, bon marché) et un coût d'opérateur $g$, bon marché pour les mutations par échange, $O(k^3)$ par réparation hongroise de $k$ cases, et sans valeur entre les deux pour le croisement réparé. Le multiplicateur $P$ est la partie douloureuse : les mesures de la communauté disent qu'il achète une diversité que la mutation seule reproduit pour un dixième du coût ([message 578](https://groups.io/g/eternity2/message/578)). - **Aucune garantie d'aucune sorte.** Pas de complétude, pas de certificat d'optimalité, et, contrairement à l'[ALNS](/fr/research/build/local-search/local-search-alns/), qui au moins peaufine un bon plateau qu'on lui tend, un GA issu de populations aléatoires dépense la majeure partie de son budget à redécouvrir ce qu'un constructeur glouton produit en quelques millisecondes. - **Là où les GA plafonnent réellement.** Les GA purs plafonnent autour de 406/480 sur le plateau complet ([message 2360](https://groups.io/g/eternity2/message/2360)). Le meilleur hybride jamais rapporté sur la liste faisait en moyenne 462 par jour en 2008 en rétrogradant le GA au rang de couche de gestion au-dessus d'un backtracker et d'une réparation exacte ([message 5589](https://groups.io/g/eternity2/message/5589)), et son auteur l'a remisé la semaine où un solveur de backtracking pur est apparu ([message 5950](https://groups.io/g/eternity2/message/5950)). Le croisement, la seule idée que l'évolution apporte et que rien d'autre dans ce catalogue ne possède, est structurellement inadapté à un puzzle dont les bonnes solutions [ne partagent presque rien de transplantable](/fr/research/why/sigma-cycles/). Ce qui a survécu de l'ère des GA est bien réel, et rien de tout cela n'est génétique. ## À lire aussi - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. --- # Recherche locale et ALNS > Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/local-search/local-search-alns/ - Mise à jour: 2026-07-02 - Sujets: local-search - Source: L'article JFPC de Pierre Schaus + le voisinage à remplissage hongrois, détaillé pour la première fois sur la liste (groups.io msg 5589, juin 2008) — https://groups.io/g/eternity2/message/5589 - Source: Ropke & Pisinger, An Adaptive Large Neighborhood Search Heuristic for the Pickup and Delivery Problem with Time Windows (Transportation Science, 2006) — https://doi.org/10.1287/trsc.1050.0135 - Source: Shaw, Using Constraint Programming and Local Search Methods to Solve Vehicle Routing Problems (CP 1998, le LNS d'origine) — https://link.springer.com/chapter/10.1007/3-540-49481-2_30 - Source: Schaus & Deville, Hybridization of CP and VLNS for Eternity II (JFPC 2008) — https://hdl.handle.net/2078.5/253676 --- Une fois que l'on tient un plateau solide, les déplacements pièce par pièce cessent presque immédiatement de rapporter. La recherche à grand voisinage fait le pari inverse : arracher toute une région (des dizaines de cellules) et la reconstruire avec quelque chose de plus fin que la passe gloutonne qui l'avait posée. L'idée revient à Paul Shaw ([CP 1998](https://link.springer.com/chapter/10.1007/3-540-49481-2_30)) ; la version *adaptative*, ALNS, est due à Ropke et Pisinger ([Transportation Science 2006](https://doi.org/10.1287/trsc.1050.0135)), qui ont ajouté un portefeuille d'opérateurs de destruction et de réparation ainsi qu'une règle d'apprentissage qui oriente l'effort vers les opérateurs ayant récemment réussi. ## La boucle Une itération d'ALNS sur un plateau : 1. **Détruire.** Choisir un opérateur de destruction, retirer les $k$ cellules qu'il sélectionne. 2. **Réparer.** Combler le trou (remplissage glouton, [propagation de contraintes](/fr/research/build/reduce/arc-consistency/), ou résolution exacte du petit sous-problème). 3. **Accepter.** Conserver le nouveau plateau s'il obtient un meilleur score, ou parfois malgré tout selon une règle de recuit simulé. 4. **Adapter.** Repondérer les opérateurs selon leur succès récent, pour que la roulette favorise ce qui a bien marché. Eternity II se prête particulièrement bien à l'étape 1, car un plateau partiel vous dit exactement où ça fait mal : les arêtes non appariées. ## La regarder tourner Lire la boucle est une chose ; la regarder apprendre en est une autre. Ci-dessous, un vrai plateau 8×8 résolu par le moteur a été volontairement endommagé, et la boucle ALNS complète y tourne au ralenti : détruire, remplir gloutonnement pièce par pièce, accepter ou annuler, repondérer. Forcez un opérateur à la main et regardez sa barre de poids réagir ; ou laissez simplement la roulette dériver vers ce qui a payé. > **[Figure]** Interactif : la boucle détruire-réparer — interactive: AlnsLoopLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Étape par étape Une itération, exactement comme le laboratoire l'exécute : 1. **Tirer un opérateur.** Sélection par roulette : l'opérateur $o$ est choisi avec la probabilité $w_o / \sum_j w_j$. Tous les poids partent égaux ; la roulette est uniforme jusqu'à ce que les résultats arrivent. 2. **Détruire.** L'opérateur renvoie $k$ cellules dont les pièces quittent le plateau. Tirer des cellules au hasard ou une forme fixe coûte $O(k)$ ; les opérateurs guidés par les conflits (pire rangée, cellules les plus en conflit) ont aussi besoin de la carte des désappariements, ce qui coûte un balayage linéaire à moins que le moteur ne la maintienne de façon incrémentale. Le nôtre le fait, précisément pour que la destruction reste en $O(k)$. 3. **Réparer, gloutonnement.** Jusqu'à ce que le trou soit plein : prendre la cellule vide ayant le plus de voisins déjà placés (la plus contrainte d'abord), essayer chaque pièce retirée dans les quatre rotations, garder le placement qui apparie le plus de coutures. Chacun des $k$ placements balaie les candidats restants, donc la passe coûte $O(k \cdot |C|)$ où $|C|$ est le réservoir de candidats (pièces libres × 4 rotations). 4. **Accepter ou annuler.** Évaluer la région reconstruite ; seules les coutures touchant les $k$ cellules ont changé, donc la réévaluation est en $O(k)$. Conserver le plateau si $\Delta \geq 0$, sinon le conserver quand même avec la probabilité $e^{\Delta/T}$ ; en cas de rejet, restaurer l'instantané. 5. **Adapter.** Mettre à jour le poids du gagnant, $w_o \leftarrow \lambda\, w_o + (1 - \lambda)\, \psi$, où la récompense $\psi$ est échelonnée : nouveau meilleur global > amélioration > déplacement latéral accepté > rejet. Ce lissage exponentiel est tout ce qu'il y a d'« adaptatif » dans ALNS. L'original de Ropke et Pisinger tient la même comptabilité sur des segments de quelques centaines d'itérations. ## Ce que ça coûte Par itération, avec $k$ cellules détruites : $$ \underbrace{O(k)}_{\text{destruction}} \;+\; \underbrace{O(k \cdot |C|)}_{\text{réparation gloutonne}} \;+\; \underbrace{O(k)}_{\text{évaluation}} \;+\; \underbrace{O(|\mathcal{O}|)}_{\text{adaptation}} $$ Trois raffinements qui valent la peine d'être connus : - **Le remplissage optimal est un problème d'affectation (parfois).** Lorsque les cellules libérées sont deux à deux non adjacentes, le coût de chaque trou ne dépend que de ses voisins fixes, si bien que le remplissage est exactement un problème d'affectation $k \times k$ : l'algorithme hongrois le résout de façon optimale en $O(k^3)$. C'est le voisinage Eternity II de Schaus. Dès que deux trous se touchent, leurs choix se couplent, et la réparation optimale devient une petite recherche CP/exacte, exponentielle dans le pire des cas en $k$, ce qui explique pourquoi les grosses destructions cessent de rapporter. - **Anytime, et rien de plus.** ALNS améliore une réponse admissible et peut être arrêté à tout moment ; le meilleur plateau obtenu jusque-là *est* la sortie. Il n'offre aucune garantie de complétude ni d'optimalité : il ne peut jamais certifier qu'aucun meilleur plateau n'existe. Sur ce puzzle, ce certificat doit venir d'ailleurs (l'oracle SAT derrière le [mur de rigidité](/fr/research/why/rigidity-wall/)). - **À l'échelle d'Eternity II, la boucle est bon marché ; l'évasion ne l'est pas.** Avec $k = 20$ à $80$ des 256 cellules et quelques centaines de candidats par trou, une itération coûte de la microseconde à la milliseconde, et les courbes d'amélioration s'aplatissent en quelques dizaines d'itérations. Le coût contraignant n'est donc pas l'arithmétique mais la probabilité qu'un voisinage de $k$ cellules contienne l'unique [σ-cycle](/fr/research/why/sigma-cycles/) imbriqué qui mène vers le haut, et cette probabilité est ce qui s'effondre près du sommet. ## Un portefeuille d'opérateurs pour les plateaux Les opérateurs de destruction livrés par ce projet sont pour la plupart conscients de la géométrie et des conflits : des cellules aléatoires en référence de base, les cellules incidentes à des arêtes non appariées, les $k$ cellules les plus en conflit, la pire rangée ou bande de rangées, une composante connexe du graphe de désappariement (éventuellement avec un halo d'une cellule autour), des rectangles et des anneaux concentriques. Deux constats issus du réglage du portefeuille, tous deux mesurés sur le moteur de ce projet et non répliqués de façon indépendante : - **La sélection l'emporte sur la couverture.** Un ensemble sélectionné de cinq opérateurs a surpassé l'ensemble complet de onze ; répartir les poids adaptatifs sur trop d'opérateurs dilue le signal d'apprentissage. - **La température n'est pas le levier.** Sur une plage de températures d'acceptation d'un facteur dix, les scores finaux étaient identiques, parce que près du sommet le paysage est dominé par des plateaux à score égal où pratiquement chaque déplacement est accepté à n'importe quelle température. Que détruire-réparer convienne à ce puzzle est une observation ancienne : Schaus et Deville avaient hybridé la programmation par contraintes avec la recherche à grand voisinage sur Eternity II dès [2008](https://hdl.handle.net/2078.5/253676), en utilisant la CP comme étape de réparation, la même division du travail qui fonctionne ici. ## Ce que ça rapporte de façon fiable La finition finale. Sur le moteur de ce projet, ALNS est l'étape qui transforme une sortie constructive en plateaux dignes des records : les constructions par [faisceau](/fr/research/build/construct/beam-search/) qui atterrissent régulièrement au milieu des 450 gagnent plusieurs arêtes sous une passe de raffinement, et les plateaux les plus solides du projet portent tous un gain ALNS comme dernière étape. Sur des puzzles générés plus petits, l'effet est spectaculaire et reproductible : détruire-réparer comble l'essentiel de la distance entre un placement aléatoire et le meilleur score atteignable, sur une large plage de serrage du puzzle, avant de saturer sur les instances les plus difficiles. (Tout ceci est mesuré ici, et nuancé en conséquence.) Tout aussi caractéristique : les gains arrivent tôt. Les courbes d'amélioration s'aplatissent dès les premières dizaines d'itérations, et laisser une exécution tourner dix fois plus longtemps reproduit le même score final. Quand ALNS s'arrête, il s'est arrêté. ## Le mur qu'il rencontre La raison pour laquelle il s'arrête est la partie intéressante, et ce site y consacre deux pages entières. Sur chaque plateau de tête, les désappariements restants sont prouvablement verrouillés : libérer un voisinage généreux autour d'eux et le fouiller exhaustivement ne trouve rien de mieux ; c'est le [mur de rigidité](/fr/research/why/rigidity-wall/). Et passer d'un plateau de tête à un meilleur exige de relocaliser un grand ensemble de pièces dans une seule boucle imbriquée, où toute application partielle de la boucle obtient un score pire que de ne rien faire : la [structure en σ-cycles](/fr/research/why/sigma-cycles/). ALNS a exactement la mauvaise forme pour cela. Un voisinage de destruction de 20 à 80 cellules ne couvre presque jamais l'unique cycle qui compte, et lorsque la destruction est assez grande pour le couvrir, l'étape de réparation affronte un sous-problème presque aussi difficile que le puzzle lui-même et rend moins que ce qui a été arraché. Détruire-réparer explore un bassin à merveille et n'en sort pour ainsi dire jamais. Le résumé que soutiennent les mesures de ce projet : ALNS est le meilleur dernier kilomètre dont nous disposons, et ce n'est qu'un dernier kilomètre. ## À lire aussi - [L'étude de la réparation](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/) — La jumelle de l'étude DFS, pour l'autre manière d'attaquer Eternity II : détruire une partie d'un plateau, la reconstruire, garder le changement s'il aide. Une question, posée avec soin. Que rapporte chaque décision de cette boucle : quelle région détruire, comment la reconstruire, quand garder un mouvement, quand redémarrer, et de quel plateau partir ? - [PALIMPSEST](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Lire chaque plateau fort pour repérer les habitudes qui, en silence, plafonnent un plateau, puis les briser. Cette expérience a produit le meilleur plateau du projet : 463 sur 480. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [Recuit simulé et tempérage parallèle](https://eternity2.dev/fr/research/build/local-search/parallel-tempering/) — Voir les désaccords comme de l'énergie et la température comme une tolérance à la dégradation. Le recuit détient le plus ancien record du puzzle ; le tempérage parallèle franchit des barrières que le recuit ne passe pas. Les deux butent sur le même mur. --- # Recuit simulé et tempérage parallèle > Voir les désaccords comme de l'énergie et la température comme une tolérance à la dégradation. Le recuit détient le plus ancien record du puzzle ; le tempérage parallèle franchit des barrières que le recuit ne passe pas. Les deux butent sur le même mur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/local-search/parallel-tempering/ - Mise à jour: 2026-07-02 - Sujets: local-search - Source: Swendsen & Wang, Replica Monte Carlo Simulation of Spin-Glasses (Physical Review Letters, 1986) — https://doi.org/10.1103/PhysRevLett.57.2607 - Source: Earl & Deem, Parallel tempering : théorie, applications et nouvelles perspectives (Phys. Chem. Chem. Phys., 2005) — https://arxiv.org/abs/physics/0508111 - Source: La liste de diffusion Eternity II, où Verhaard a décrit sa méthode de recuit de 2008 (groups.io) — https://groups.io/g/eternity2 --- Le recuit simulé lit un plateau comme un système physique : les arêtes non appariées sont de l'énergie, les mouvements qui abaissent l'énergie sont toujours acceptés, et ceux qui l'augmentent le sont avec une probabilité $e^{-\Delta E / T}$. À chaud, la recherche vagabonde ; en refroidissant, le plateau se fige dans un arrangement de basse énergie, idéalement un arrangement profond, et pas seulement le plus proche. Toute la difficulté tient au calendrier de refroidissement : refroidissez trop vite et vous gelez dans un optimum local médiocre ; refroidissez assez lentement pour un puzzle de cette taille et vous attendez indéfiniment. ## D'une température à une échelle Le tempérage parallèle (échange de répliques) dissout le problème du calendrier en faisant tourner toute l'échelle d'un coup. La méthode vient de la physique des verres de spin : l' [article de Monte-Carlo par répliques de 1986](https://doi.org/10.1103/PhysRevLett.57.2607) de Swendsen et Wang en est le précurseur, l'échange de répliques sous sa forme moderne est généralement attribué à Geyer (1991) puis à Hukushima et Nemoto (1996), et la [revue de 2005](https://arxiv.org/abs/physics/0508111) d'Earl et Deem en est la synthèse moderne de référence. $K$ copies du plateau exécutent un recuit simulé à des températures fixes $T_1 < T_2 < \dots < T_K$ ; périodiquement, des répliques adjacentes proposent d'échanger leurs états, échange accepté selon la règle de Metropolis $$ P(\text{swap}) = \min\bigl(1,\; e^{(\beta_i - \beta_j)(E_i - E_j)}\bigr) = \min\bigl(1,\; e^{\Delta\beta\,\Delta E}\bigr), $$ avec $\beta = 1/T$, $\Delta\beta = \beta_i - \beta_j$ et $\Delta E = E_i - E_j$. Lisons-la une fois avec des signes concrets : si la réplique $i$ est la plus froide ($\Delta\beta > 0$) et que la réplique la plus chaude détient l'énergie la *plus basse* ($\Delta E > 0$), l'exposant est positif et l'échange est accepté avec certitude : le bon état est toujours transmis gratuitement en descendant l'échelle. Les répliques chaudes parcourent les barrières ; les répliques froides exploitent ; les échanges font descendre les configurations prometteuses le long de l'échelle pour qu'elles soient raffinées. Aucune chaîne unique n'a jamais à survivre à un calendrier de refroidissement. ## Voir l'échelle battre une seule chaîne froide L'affirmation qui vaut d'être vue est la comparaison : la même chaîne froide, avec et sans une échelle au-dessus d'elle. Ci-dessous, quatre répliques explorent un paysage synthétique accidenté dont le minimum global se cache derrière des barrières ; un fantôme gris exécute seul la dynamique froide identique. Observez les éclairs d'échange (vert pour accepté) faire descendre le bassin de droite jusqu'au barreau froid, tandis que le fantôme reste éternellement dans le puits de départ. Puis faites glisser le curseur d'espacement vers ses deux extrêmes et reproduisez les deux échecs classiques de l'échelle. > **[Figure]** Interactif : l'échelle du tempérage parallèle — interactive: TemperingLadderLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pas à pas Un tour de tempérage parallèle, tel que le laboratoire l'exécute : 1. **Balayage.** Chaque réplique effectue des mouvements de Metropolis à sa propre température fixe : proposer un changement local, calculer $\Delta E$, accepter si cela descend, sinon avec une probabilité $e^{-\Delta E / T_i}$. Sur un plateau, un mouvement d'une seule pièce touche au plus quatre coutures, de sorte que le $\Delta E$ de chaque mouvement est en $O(1)$. 2. **Tentative d'échange.** Choisir une paire adjacente $(i, i{+}1)$, calculer $\Delta\beta\,\Delta E$ à partir des deux énergies mises en cache, accepter avec $\min(1, e^{\Delta\beta \Delta E})$. En cas d'acceptation, les deux répliques échangent leurs configurations (de manière équivalente : leurs températures) ; rien d'autre ne bouge. 3. **Comptabilité.** Suivre le taux d'acceptation des échanges par paire de barreaux. Ce nombre *est* le diagnostic de l'échelle : proche de 100 %, les barreaux adjacents voient le même paysage et l'un d'eux est gaspillé ; proche de 0 %, l'échelle s'est découplée en chaînes indépendantes. Les échelles utiles se situent à quelques dizaines de pour cent : fréquentes mais pas gratuites, exactement le régime qu'Earl et Deem recommandent et celui vers lequel nos exécutions ont convergé. 4. **Recommencer.** Les bons états descendent les barreaux en marche aléatoire ; les états bloqués remontent, sont secoués pour se libérer, et redescendent différents. ## Ce que ça coûte - **Par balayage :** $R$ répliques × $N$ sites, chaque mouvement demandant une évaluation locale en $O(1)$, soit $O(R \cdot N)$, exactement $R$ fois une seule chaîne. La mémoire est en $O(R \cdot N)$ : chaque réplique est un plateau complet. - **Par phase d'échange :** les $R{-}1$ paires adjacentes nécessitent chacune une exponentielle des énergies en cache : $O(R)$ au total, une erreur d'arrondi à côté des balayages. - **Le gain porte sur le temps de mélange, pas sur le coût du pas.** Une chaîne froide isolée franchit une barrière d'énergie $\Delta E$ en environ $e^{\Delta E / T_{\text{cold}}}$ tentatives (l'attente d'Arrhenius ; le franchissement de 76 cellules que nous avons mesuré se situait à $e^{-21}$ par tentative à $T = 1$). L'échelle remplace cette attente par de la diffusion : une configuration se promène aléatoirement à travers $R$ barreaux, et avec un espacement géométrique réglé pour une acceptation par barreau constante, un aller-retour coûte de l'ordre de $R^2$ tours d'échange. Vous payez un facteur constant $R$ par balayage pour transformer une attente exponentielle en une navette polynomiale. Cette asymétrie constitue tout l'argument de la méthode. - **Aucune garantie, comme tous les échantillonneurs.** Le tempérage parallèle n'est pas complet et ne certifie rien ; il converge finalement vers la bonne distribution, sans borne utile sur ce « finalement ». Et là où le paysage offre des égalités plutôt que des barrières, comme sur les plateaux à iso-score au sommet de ce puzzle, $\Delta E = 0$ fait se comporter tous les barreaux à l'identique, et l'avantage de l'échelle s'évanouit par construction, ce qui est précisément ce que rapporte le verdict ci-dessous. ## Pourquoi ce puzzle a besoin de l'échelle Les mesures de ce projet (sur notre propre moteur ; non répliquées de manière indépendante) donnent une raison inhabituellement concrète. Entre un plateau solide et un meilleur, le mouvement qui les relie est une unique relocalisation imbriquée de dizaines de pièces dans laquelle *tout* sous-ensemble strict du mouvement perd des arêtes : la [structure en σ-cycles](/fr/research/why/sigma-cycles/). Une transition mesurée a exigé un mouvement de 76 cellules dont les états intermédiaires se situaient environ 21 arêtes sous le point de départ : à $T = 1$, l'acceptation est de l'ordre de $e^{-21}$, sans espoir. Avec la température maximale de l'échelle portée à environ 30, le franchissement a réellement eu lieu, et a produit ce qui était alors le meilleur plateau à démarrage à froid du projet. La température, employée correctement, est un vrai levier contre de vraies barrières. La conception de l'échelle est là où la pratique mord. Lorsque nous avons espacé les températures trop étroitement, l'échange de répliques acceptait chaque échange. Un taux d'acceptation de 100 % a l'air sain et signifie l'inverse : les répliques adjacentes voyaient en pratique le même paysage, et l'échelle n'ajoutait rien. Un espacement géométrique avec un barreau supérieur véritablement chaud, réglé pour que les échanges soient fréquents mais pas gratuits, est le conseil standard d'Earl et Deem, et il correspondait à ce que nous avons observé. ## Le record communautaire bâti par le recuit Le recuit a une histoire distinguée sur ce puzzle. Le record le plus durable sur le jeu de pièces canonique (le 467 sur 480 de Louis Verhaard en 2008, invaincu jusqu'aux backtrackers de l'ère Blackwood en 2020) provenait d'une méthode de recuit, et d'une méthode inhabituelle : comme il l'a décrit sur la [liste de diffusion communautaire](https://groups.io/g/eternity2), il recuisait la *composition* d'un sous-ensemble de pièces, échangeant des pièces à l'entrée et à la sortie d'un groupe candidat sous un score de pavabilité, plutôt que de recuire des positions sur le plateau. La leçon se généralise : sur Eternity II, le choix de *ce que l'on recuit* comptait davantage que le recuit lui-même. ## Le verdict À partir des mesures de ce projet, nuancées en conséquence : le tempérage parallèle franchit mieux les barrières que le recuit ordinaire, et sur la tranche intermédiaire de la montée cette différence est réelle et fiable. Près du sommet, elle se dissout. Les plateaux de là-haut sont à iso-score : des égalités partout, de sorte que l'acceptation ne dépend plus du tout de la température, et pousser la chaleur au lieu de grimper ne fait que randomiser le plateau, qui ensuite ne retrouve jamais le chemin du territoire des records. Les répliques lancées depuis un plateau de tête plafonnent au score de la graine, à chaque chaîne, à chaque échelle que nous avons essayée. Le tempérage vous déplace entre les collines ; il n'abroge pas le [mur de rigidité](/fr/research/why/rigidity-wall/). ## À lire aussi - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. --- # Réduire la recherche > Tout ce qui élimine les états sans espoir avant que la recherche n'y perde du temps : propagation jusqu'au point fixe, filtre d'appariement all-different, no-goods appris et invariant de glissement des bords. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/reduce/ - Mise à jour: 2026-07-13 --- Tout ce qui élimine les états sans espoir avant que la recherche n'y perde du temps : propagation jusqu'au point fixe, filtre d'appariement all-different, no-goods appris et invariant de glissement des bords. Ces méthodes élaguent fortement sur les petits plateaux ; la leçon qui revient ici, c'est jusqu'où cet élagage porte sur le plateau complet 16×16, et où il s'essouffle. Les pages ci-dessous procèdent technique par technique : ce que chacune est en une ligne, ce qu'elle a réellement permis d'atteindre sur le vrai plateau 16×16, où elle s'arrête, et les expériences et mesures qui l'étayent. Pour embrasser tout le terrain d'un coup, commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/). ## Pages de cette section - [La cohérence d'arc, à partir d'AC-3](https://eternity2.dev/fr/research/build/reduce/arc-consistency/) — Le forward checking regarde un coup à l'avance ; la cohérence d'arc oblige la liste de candidats de chaque case à se défendre contre celle de chaque voisine, jusqu'à un point fixe. AC-3 de Mackworth, les raffinements optimaux qui ont suivi, ce que toute cette famille a réellement mesuré sur ce casse-tête, et où elle devient incorrecte. - [All-different, le filtre par matching de Régin](https://eternity2.dev/fr/research/build/reduce/alldiff-regin/) — Aucune pièce ne peut servir deux fois : une seule contrainte all-different globale sur 256 cases. Jean-Charles Régin a montré en 1994 comment un matching biparti la filtre complètement en temps polynomial ; sa variante par couleur est le propagateur le plus puissant jamais mesuré sur l'edge matching, avec une réserve nette sur les recherches tolérantes aux erreurs. - [Le glissement d'arête](https://eternity2.dev/fr/research/build/reduce/edge-slipping/) — Le coup primé de Louis Verhaard : laisser le backtracker poser une pièce non concordante, mais seulement à des profondeurs choisies près du bas du plateau. Chaque glissement autorisé coûte un point de score et multiplie de façon astronomique le nombre de plateaux cibles. Voilà pourquoi son 467 a été trouvé plus de cinquante fois, et l'ancêtre direct des ruptures de Blackwood. - [Apprentissage des no-goods : se souvenir de ses échecs](https://eternity2.dev/fr/research/build/reduce/nogood-learning/) — Un sous-arbre voué à l'échec est un théorème : cet état partiel ne pourra jamais s'étendre. Mémorisez-le et n'y revenez plus jamais. La communauté a essayé les deux variantes : tables de transposition à la manière des échecs sur la frontière de recherche, et contraintes extraites du puzzle lui-même. Le bilan complet de ce que la mémoire achète à l'échelle d'E2, et les petits plateaux où elle paie vraiment. ## À lire aussi - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les techniques](https://eternity2.dev/fr/research/build/techniques/) — L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. --- # All-different, le filtre par matching de Régin > Aucune pièce ne peut servir deux fois : une seule contrainte all-different globale sur 256 cases. Jean-Charles Régin a montré en 1994 comment un matching biparti la filtre complètement en temps polynomial ; sa variante par couleur est le propagateur le plus puissant jamais mesuré sur l'edge matching, avec une réserve nette sur les recherches tolérantes aux erreurs. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/reduce/alldiff-regin/ - Mise à jour: 2026-07-02 - Sujets: search-space, exact-methods - Source: Régin 1994, « A Filtering Algorithm for Constraints of Difference in CSPs » (AAAI-94) — https://cdn.aaai.org/AAAI/1994/AAAI94-055.pdf - Source: Ansótegui, Béjar, Fernández & Mateu 2008, « Edge Matching Puzzles as Hard SAT/CSP Benchmarks » (CP 2008) : le filtre par matching par couleur — https://doi.org/10.1007/978-3-540-85958-1_42 - Source: Algorithme de matching de Hopcroft-Karp (Wikipédia) — https://en.wikipedia.org/wiki/Hopcroft%E2%80%93Karp_algorithm --- Sous le matching des couleurs, Eternity II porte une seconde loi globale : les 256 cases doivent recevoir 256 pièces *distinctes*. Écrite comme une contrainte, c'est un unique all-different sur tout le plateau. La plupart des solveurs l'imposent de la façon la plus faible possible (quand une pièce est posée, on la raye partout ailleurs), ce qui laisse passer toute une classe de positions mortes : cinq cases dont les candidats restants ne puisent que dans quatre pièces sont déjà insolubles, et un simple rayage ne s'en apercevra que bien plus tard. ## Le filtre de Régin (1994) Jean-Charles Régin a montré que la contrainte all-different peut être filtrée *complètement*, en temps polynomial : tout candidat n'apparaissant dans aucune affectation globale valide est supprimé. La construction relève de la pure théorie des graphes : 1. Construire le graphe biparti cases contre pièces, avec une arête partout où une pièce reste dans le domaine d'une case. 2. Calculer un matching maximum (Hopcroft-Karp, $O(m \sqrt{n})$). S'il ne couvre pas toutes les cases, la position est morte ; on remonte immédiatement. 3. Orienter le graphe autour du matching et calculer ses composantes fortement connexes (Tarjan, temps linéaire). Un théorème de Berge identifie alors, en une seule passe, exactement quelles arêtes appartiennent à *un* matching maximum. 4. Toute arête qui n'appartient à aucun est un candidat qu'on peut supprimer du domaine de sa case, de façon correcte. Cet article a de fait fondé le champ des contraintes globales en programmation par contraintes : une contrainte sur des centaines de variables, filtrée optimalement par un seul algorithme combinatoire plutôt que décomposée en de faibles vérifications deux à deux. Les versions incrémentales (Régin 1995 ; Mehlhorn & Thiel 2000) réparent le matching après quelques suppressions au lieu de le recalculer, ce qui le rend abordable au cœur d'une boucle de recherche. ## Voir le filtre à l'œuvre La construction est plus facile à croire qu'à imaginer, alors la voici sur une instance à six pièces conçue pour contenir un piège : les cases C1 et C2 ne puisent toutes deux que dans les pièces P1 et P2, un ensemble de Hall. Le rayage ne voit rien de fautif à ce que C3 garde P2 comme candidat ; l'argument du matching prouve que cela ne peut jamais arriver. Construisez d'abord le matching (observez un chemin augmentant expulser et réaiguiller une affectation antérieure), puis lancez le filtre et regardez les composantes fortement connexes exposer chaque arête qu'aucun matching maximum ne peut utiliser. > **[Figure]** Interactif : le filtre par matching de Régin à l'œuvre — interactive: ReginMatchingLab. Rendered on the canonical page (link above); not shown in this markdown export. Le gain à remarquer : trois arêtes supprimées, et deux cases *forcées*. C3 doit prendre P3 et C6 doit prendre P6, des conclusions qu'un raisonnement deux à deux n'atteindrait qu'après un branchement. Voilà ce que signifie « filtrer optimalement » : après la passe de Régin, tout candidat survivant participe réellement à une affectation complète. ## Étape par étape Le même déroulé, en mots : 1. **Construire le graphe biparti.** Les cases d'un côté, les pièces de l'autre, une arête partout où une pièce reste dans le domaine d'une case : six cases, six pièces, treize arêtes dans la démo. 2. **Faire croître un matching par chemins augmentants.** C1 prend P1. C2 veut aussi P1 : au lieu d'abandonner, on suit le *chemin alternant* C2-P1-C1-P2. P1 est pris, mais son propriétaire C1 dispose d'une alternative libre, P2. On retourne chaque arête du chemin : C1 glisse vers P2, C2 obtient P1, et le matching a grandi d'une unité. On répète jusqu'à ce que toutes les cases soient couvertes. Si une case épuise un jour ses chemins, il n'existe aucune affectation complète et la recherche remonte sur-le-champ. 3. **Orienter le graphe.** Les arêtes du matching pointent case → pièce ; les arêtes hors matching pointent pièce → case. Un cycle alternant du graphe original devient alors un cycle orienté dans celui-ci. 4. **Calculer les composantes fortement connexes** (Tarjan, une passe linéaire). Dans la démo, \{C1, C2, P1, P2\} forment une composante (elles s'échangent leurs deux pièces le long d'un cycle) et \{C4, C5, P4, P5\} une autre. 5. **Appliquer la règle de Berge.** Une arête hors matching ne peut rejoindre *un* matching maximum que si elle se trouve sur un cycle alternant (même composante) ou sur un chemin alternant issu d'un sommet libre (aucun ici ; le matching est parfait). Tout le reste est mort : C3-P2, C4-P3 et C6-P5 traversent chacune deux composantes, elles sont donc supprimées, de manière prouvée et non heuristique. 6. **Relever les réductions.** Le domaine de C3 se réduit à \{P3\}, celui de C6 à \{P6\} : deux placements forcés trouvés sans un seul branchement. ## Ce que cela coûte Une invocation à partir de zéro, c'est deux passes de graphe : - **Matching maximum** via Hopcroft-Karp : $O(m \sqrt{n})$ pour $m$ arêtes admissibles sur $n$ sommets, le terme dominant. - **Décomposition en composantes fortement connexes** via Tarjan : $O(n + m)$, linéaire, plus autant à nouveau pour balayer les arêtes et supprimer. Pour l'all-different au niveau des pièces sur Eternity II, $n = 512$ sommets (256 cases + 256 pièces) et $m$ vaut au plus $256 \times 256 = 65{,}536$ arêtes, si bien que $m\sqrt{n} \approx 1{,}5$ million d'opérations sur arêtes pour une construction complète. C'est de la menue monnaie sur du matériel moderne, et c'est le *pire* cas, à partir de zéro, avec des domaines aussi lâches que possible. Au sein d'une recherche, personne ne reconstruit : les versions incrémentales citées plus haut conservent le matching précédent, le réparent par quelques chemins augmentants après chaque changement de domaine, et relancent la passe linéaire des composantes fortement connexes, ce qui revient en pratique à un refiltrage quasi linéaire par nœud. La variante par couleur est plus petite encore : un graphe par classe de couleur sur les seules demi-arêtes portant cette couleur, 22 petits matchings au lieu d'un seul gros. L'étiquette polynomiale est le point clé : c'est un filtrage complet d'une contrainte globale au tarif d'un algorithme de graphes, pas au tarif d'une recherche. ## Pourquoi cela mord sur Eternity II Le même théorème s'applique à deux niveaux différents sur ce puzzle. **Par couleur.** Pour chaque couleur, les demi-arêtes qui la portent doivent s'apparier parfaitement entre cases adjacentes : une condition de matching parfait par classe de couleur. Ansótegui, Béjar, Fernández et Mateu ont construit exactement ce propagateur sur le théorème de Régin pour les CSP d'edge matching, et l'ont qualifié de contrainte globale la plus puissante qu'ils aient trouvée pour ces puzzles. Cela recoupe l'expérience de ce projet : le filtre par couleur est le propagateur le plus fort du moteur de matching exact du projet, l'ingrédient qui (conjointement à la [cohérence d'arc](/fr/research/build/reduce/arc-consistency/)) fait passer un simple backtracker à 449 arêtes sur 480 en moins d'une minute (mesuré sur le moteur de ce projet, non répliqué de façon indépendante). Il gagne sa place tard : le projet le réserve aux positions profondes, où les domaines sont assez serrés pour que les matchings échouent et où le coût est amorti. **Par pièce.** La lecture directe, pièces restantes contre cases vides, attrape les pièges de type Hall que le rayage manque : des groupes entiers de cases se disputant trop peu de pièces, détectés avant que la machinerie deux à deux ne voie la moindre contradiction. Puisque [aucun coup n'est jamais forcé](/fr/research/why/no-forced-moves/) sur ce puzzle, un filtre qui raisonne sur des groupes plutôt que sur des cases isolées est exactement le genre de levier qui manque cruellement. ## La réserve Blackwood, dite sans détour Le filtre par couleur suppose que chaque couleur doit s'apparier *exactement*. Une [recherche à la Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) brise cette hypothèse à dessein : ses indices de rupture autorisent un budget d'erreurs aux profondeurs tardives, si bien qu'un plateau que le filtre déclare « impossible » peut être précisément le 470 que la recherche traque. Faire tourner le filtre par matching par couleur au sein d'une recherche tolérante aux erreurs est incorrect, point final. Sur le moteur de ce projet, il est désactivé dans ce régime, et son retrait (avec le reste des propagateurs stricts) a fait partie d'un gros gain de vitesse en mono-thread. L'all-different au niveau des pièces fait exception, et cela compte : même une recherche tolérante aux erreurs n'utilise jamais deux fois une pièce. L'unicité des pièces reste stricte là où le matching des couleurs ne l'est plus, si bien que le filtre de Régin sur les pièces demeure correct précisément dans le régime où tout le reste de la famille de propagation s'effondre. C'est le seul propagateur global fort dont dispose un moteur de record. ## Bénéfice, et ce qu'on ignore encore Le versant coût du bilan est ci-dessus, et il est polynomial de bout en bout. Le versant bénéfice, en revanche, a un trou : l'article original de Régin évalue un jouet à 25 variables, et il n'existe aucune mesure publiée du filtre sur un all-different à 256 variables ayant la forme d'Eternity II. Ce projet n'a pas non plus construit la version au niveau des pièces ; sa promesse au sein des recherches tolérantes aux erreurs est un argument, pas un chiffre. À traiter comme le pari ouvert le mieux étayé du rayon : correct là où plus rien de fort ne l'est, coût connu comme polynomial, gain non mesuré. ## À lire aussi - [La cohérence d'arc, à partir d'AC-3](https://eternity2.dev/fr/research/build/reduce/arc-consistency/) — Le forward checking regarde un coup à l'avance ; la cohérence d'arc oblige la liste de candidats de chaque case à se défendre contre celle de chaque voisine, jusqu'à un point fixe. AC-3 de Mackworth, les raffinements optimaux qui ont suivi, ce que toute cette famille a réellement mesuré sur ce casse-tête, et où elle devient incorrecte. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. --- # La cohérence d'arc, à partir d'AC-3 > Le forward checking regarde un coup à l'avance ; la cohérence d'arc oblige la liste de candidats de chaque case à se défendre contre celle de chaque voisine, jusqu'à un point fixe. AC-3 de Mackworth, les raffinements optimaux qui ont suivi, ce que toute cette famille a réellement mesuré sur ce casse-tête, et où elle devient incorrecte. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/reduce/arc-consistency/ - Mise à jour: 2026-07-02 - Sujets: search-space - Source: Mackworth 1977, « Consistency in Networks of Relations » (Artificial Intelligence 8) : AC-3 — https://doi.org/10.1016/0004-3702(77)90007-8 - Source: Bessière, Régin, Yap & Zhang 2005, « An Optimal Coarse-grained Arc Consistency Algorithm » (AIJ) : AC-2001/AC-3.1 — https://doi.org/10.1016/j.artint.2005.02.004 - Source: Algorithme AC-3 (Wikipédia) — https://en.wikipedia.org/wiki/AC-3_algorithm --- Sur Eternity II, un algorithme de backtracking passe le plus clair de son temps non pas à poser des pièces mais à les écarter. Puisqu'[aucune case n'est jamais forcée](/fr/research/why/no-forced-moves/) (chaque position intérieure conserve des dizaines de candidats vivants jusque tard dans la recherche), le seul levier disponible est de rétrécir ces listes de candidats aussi fortement et aussi économiquement que possible. La cohérence d'arc est la machinerie standard pour cela, et elle traîne derrière elle un demi-siècle de publications. ## Des domaines qui se surveillent mutuellement Attribuons à chaque case vide un *domaine* : l'ensemble des candidats pièce-et-rotation encore autorisés à cet endroit. Sur le casse-tête complet, cela démarre à environ 764 tuples par case intérieure. Le **forward checking** est la discipline en une étape : quand une pièce est posée, on la supprime de tous les autres domaines et on supprime tout candidat qui entre en conflit avec les arêtes nouvellement exposées. C'est peu coûteux, et tout solveur sérieux fait au moins cela. La **cohérence d'arc** exige davantage. Pour chaque paire de cases adjacentes, tout candidat d'un domaine doit avoir au moins un partenaire compatible dans l'autre, un *support*. Quand une suppression, où qu'elle soit, laisse un candidat sans support, ce candidat disparaît à son tour, et la vérification se propage vers l'extérieur jusqu'à ce que plus rien ne puisse être retiré. Pour l'appariement d'arêtes, cela signifie exactement : « une pièce ne peut rester dans une case que si chaque case voisine peut encore répondre à ses couleurs ». ## AC-3, et où il gaspille du travail AC-3 d'Alan Mackworth (1977) est la façon à gros grain d'atteindre ce point fixe : on maintient une file d'arcs orientés, on révise un arc à la fois (on parcourt un domaine, on supprime les candidats sans support), et chaque fois qu'un domaine rétrécit, on réenfile les arcs qui pointent vers lui. C'est court, correct, et facile à rendre incrémental à l'intérieur d'une recherche, ce qui explique pourquoi il reste le choix par défaut partout. Au pire cas, il coûte $O(e d^3)$ pour $e$ arcs et une taille de domaine $d$ ; sur la grille 16×16, $e$ vaut $e = 960$ (les 480 adjacences intérieures, dans les deux sens) et $d \approx 764$. Son défaut connu : chaque révision cherche les supports de zéro, si bien que le même support est redécouvert des milliers de fois à mesure que la recherche plonge et remonte. ## Regardez-le tourner Les descriptions d'algorithmes à liste de travail se ressemblent toutes ; c'est en regardant l'un d'eux se stabiliser que tout devient clair. Ci-dessous, AC-3 sur une version miniature du problème : une grille 4×4, 3 couleurs d'arête, chaque case démarrant avec ses 64 candidats (16 tuiles × 4 rotations). Posez une pièce et suivez la file : quels arcs y entrent, ce que chaque révision supprime, comment une suppression réarme les arcs pointant vers le domaine rétréci, et comment l'onde s'éteint. Les compteurs comparent le travail d'AC-3 à celui de la boucle naïve de point fixe (AC-1 : rebalayer chaque arc jusqu'à ce qu'une passe complète soit propre) tournant sur exactement les mêmes positions. > **[Figure]** Interactif : regardez AC-3 se stabiliser vers un point fixe — interactive: AcThreeLab. Rendered on the canonical page (link above); not shown in this markdown export. Deux choses méritent l'attention. Les premiers placements ne propagent presque rien : un anneau de voisines rétrécit et l'onde s'arrête, parce que le deuxième anneau trouve encore des supports pour les trois couleurs parmi les survivants. Les placements tardifs se propagent bien plus loin : les domaines sont serrés, et une seule suppression isole des candidats à deux ou trois cases de distance. C'est exactement le comportement sur le vrai casse-tête : la cohérence d'arc gagne son pain dans la finale, pas dans l'ouverture. ## Étape par étape La même exécution, en mots. Voici tout AC-3 : 1. **Départ.** Chaque case détient un domaine de 64 candidats. La file d'arcs est vide ; sans aucune suppression, il n'y a rien à vérifier. 2. **Une pièce se pose sur B2.** Son domaine se réduit à l'unique candidat posé. Chaque arc *dirigé vers* B2 entre dans la file, un par voisine : ici (B1→B2), (C2→B2), (B3→B2), (A2→B2). Rien d'autre : aucun autre domaine n'a changé, donc aucun autre arc n'a pu perdre un support. 3. **On dépile un arc, on le révise.** Prenons (B1→B2) : on parcourt les 64 candidats de B1 et, pour chacun, on cherche dans le domaine de B2 un partenaire compatible, un *support*. B2 ne détient plus qu'une pièce, donc seuls survivent les candidats dont l'arête sud correspond à sa couleur nord : environ un tiers. Le reste est supprimé. 4. **Les suppressions réarment les arcs.** Le domaine de B1 a rétréci, donc les candidats ailleurs qui s'appuyaient sur ceux supprimés peuvent se retrouver isolés : chaque arc pointant vers B1 réentre dans la file, sauf celui venant de B2 qui vient de se déclencher. C'est la propagation. 5. **Pas de suppression, pas de réenfilage.** Quand une révision ne retire rien, l'arc est simplement abandonné. Tôt dans la partie, le deuxième anneau survit presque toujours intact, et la file se vide en une poignée de révisions. 6. **Point fixe.** La file est vide : chaque candidat, partout, a un support dans chaque domaine voisin. Aucun ordre de traitement ne change cet état final : le point fixe est unique, et la discipline de file ne change que la vitesse à laquelle on l'atteint. La comparaison avec AC-1 dans la démo est tout l'argument en faveur de la liste de travail : la boucle naïve reréviser les 48 arcs à chaque balayage jusqu'à ce qu'un balayage soit propre, effectuant les mêmes suppressions au prix de plusieurs fois plus de vérifications, et l'écart se creuse à mesure que la grille grandit. ## Ce qu'apportent les variantes plus fortes La littérature a passé deux décennies à corriger cette redondance. AC-4 (Mohr & Henderson 1986) compte les supports explicitement : temps optimal $O(e d^2)$, mais $O(e d^2)$ de mémoire et une pénible restauration d'état au backtrack. AC-6 et AC-7 (Bessière ; Bessière, Freuder & Régin) stockent les supports paresseusement et exploitent la bidirectionnalité, gardant le temps optimal avec un espace $O(e d)$ au prix d'une comptabilité fine. La version qui vaut la peine d'être connue aujourd'hui est **AC-2001/AC-3.1**, découverte indépendamment par Bessière & Régin et par Zhang & Yap en 2001 : on garde la boucle simple d'AC-3, mais on retient pour chaque paire candidat-arc le *dernier support trouvé*, on vérifie qu'il est toujours vivant avant de chercher de nouveau, et on reprend le parcours là où il s'était arrêté plutôt que de zéro. Cet unique entier par paire délivre la borne optimale $O(e d^2)$ avec seulement $O(e d)$ de mémoire ; sur ce casse-tête, cela fait environ 367 000 petits entiers, négligeable. L'étude de revue de 2005 mesure un CPU de 1,5 à 9 fois moindre qu'AC-3 dans une recherche à cohérence d'arc maintenue, et montre que l'avantage sur AC-6 *croît* avec la taille du domaine de l'autre côté de l'arc. Eternity II possède des domaines énormes des deux côtés de chaque arc, ce qui fait d'AC-2001 le choix de manuel. ## Le plafond : pourquoi pas la cohérence de chemin ? La cohérence d'arc vérifie des paires de cases. L'échelon supérieur, la *cohérence de chemin*, vérifie des triplets : elle retire toute paire d'affectations qu'aucune troisième case ne peut supporter, propageant une condition bien plus forte. Elle rétrécit énormément l'arbre de recherche, et la communauté a mesuré exactement de combien, et exactement pourquoi personne ne l'utilise. En mars 2008, Geoff a fait tourner toute l'échelle sur les casse-tête pour débutants de Brendan Owen ([msg 4827](https://groups.io/g/eternity2/message/4827)) : - Sur la 6×6, la simple cohérence nodale laisse un arbre de recherche de plus de **40 000 nœuds**. La cohérence de chemin-1 partielle le fait tomber à environ 10 000. La cohérence de chemin-2 partielle le fait tomber à **138 nœuds**, le strict minimum nécessaire pour parcourir les huit solutions. Mais le temps d'exécution passe de 0,25 seconde à plus de **10 secondes**. - Sur la 8×8, le compromis empire. La cohérence d'arc seule la résout en moins de **6 millions de nœuds et environ 36 secondes**. Ajouter un prétraitement de chemin-1 réduit l'arbre à environ 1 million de nœuds mais coûte environ **14 minutes** de prétraitement ; le prétraitement de chemin-2 tournait encore après **7 heures**. Le schéma est sans ambiguïté : chaque niveau plus fort de cohérence coupe réellement l'arbre de plusieurs ordres de grandeur, et chacun coûte plus qu'il n'économise. La conclusion de Geoff lui-même était que la cohérence de chemin « n'a tout simplement pas d'effet coût-bénéfice positif » sur ce casse-tête. C'est [élaguer contre vitesse](/fr/research/why/prune-vs-speed/) énoncé dans la langue d'un vrai algorithme : l'élagage est réel et important, mais ici la machinerie pour le calculer est plus coûteuse que la recherche qu'elle supprime, ce qui explique pourquoi les moteurs recordmen s'arrêtent à la cohérence d'arc (ou en dessous) et consacrent le temps économisé à des placements bruts. ## Ce que cela coûte La comptabilité, avec $e$ le nombre d'arcs orientés et $d$ la taille maximale de domaine : - **AC-3** tourne en $O(e d^3)$ au pire cas : chaque arc peut être réenfilé jusqu'à $d$ fois (une par suppression dans son domaine distant), et chaque révision coûte jusqu'à $d^2$ vérifications de support. Sa mémoire de travail se limite à la file, $O(e)$. - **AC-2001** tourne en $O(e d^2)$, ce qui est *optimal* pour tout algorithme fondé sur la révision d'arcs : il y a $e d$ paires candidat–arc et chacune peut nécessiter que son support soit parcouru une fois sur un domaine de taille $d$. Le prix est la table du dernier support : un entier par paire candidat–arc, $O(e d)$ d'espace. À l'échelle d'Eternity II, ces symboles valent : $e = 960$ (480 adjacences intérieures, dans les deux sens) et $d \approx 764$ tuples candidats par case intérieure. Les bornes au pire cas se situent donc vers $e d^3 \approx 4 \times 10^{11}$ vérifications élémentaires pour AC-3 contre $e d^2 \approx 5{,}6 \times 10^8$ pour AC-2001, trois ordres de grandeur d'écart sur le papier. Les pires cas sont pessimistes (les propagations réelles ne touchent que quelques cases, comme le montre la démo ci-dessus), mais ce rapport explique pourquoi la littérature désigne la borne d'AC-3 comme la chose à corriger, et la correction ne coûte que $O(e d)$ entiers de mémoire. Le hic sur ce casse-tête n'est pas le coût de propagation par nœud ; c'est qu'à l'intérieur d'une recherche ce coût est payé à *chaque* nœud, des millions de fois par seconde, ce qui explique pourquoi les facteurs constants et le comportement du cache finissent par compter autant que l'exposant sur $d$. ## Mesuré sur ce casse-tête Sur le moteur de ce projet (mesuré ici ; pas répliqué indépendamment) : - Un backtracker simple propageant AC-3 conjointement avec le [filtre d'appariement par couleur](/fr/research/build/reduce/alldiff-regin/) atteint 449 arêtes sur 480 sur le casse-tête canonique en environ 44 secondes en mono-thread, autour de 2,5 secondes sur 8 cœurs. - La meilleure accélération algorithmique trouvée à l'intérieur d'AC-3 lui-même était banale : une table précalculée indiquant quelles rotations d'une même pièce partagent des couleurs d'arête, pour que les révisions cessent de la redériver, valant un gain de débit de 2,9× sur le banc de référence du moteur. - La partie non construite : AC-2001 a été recommandé deux fois dans les notes de ce projet et jamais réellement construit, si bien que son gain projeté de 2 à 5× ici est une lecture de la littérature, pas une mesure. Et la croyance qu'AC-3 dominait le profil d'exécution n'a elle-même jamais été confirmée par un profileur. Mesurer avant de porter. ## La réserve sur la correction La cohérence d'arc suppose que chaque arête doit correspondre parfaitement. Les moteurs recordmen, eux, non : les [recherches à la Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) autorisent un budget de non-correspondances délibérées aux grandes profondeurs, et sous ce régime la cohérence d'arc est *incorrecte* : elle élague des grilles qu'une non-correspondance autorisée rendrait parfaitement légales. Sur le moteur de ce projet, toute la famille AC est désactivée dans les exécutions tolérant les ruptures, pour exactement cette raison. Le seul propagateur fort qui survit au régime de non-correspondance est le all-different au niveau des pièces ; voir [le filtre de Régin](/fr/research/build/reduce/alldiff-regin/). ## Verdict Pour toute recherche à appariement exact, la cohérence d'arc est obligatoire et peu coûteuse : c'est la différence entre un backtracker qui patine et un qui atteint les 440. Le forward checking seul laisse des élagages sur la table ; AC-3 les récupère ; AC-2001 récupère les mêmes pour moins de CPU, à condition d'avoir d'abord vérifié que la propagation est bien là où partent vos cycles. Pour la chasse au record tolérante aux non-correspondances, laissez-le de côté ; la correction passe avant tout. ## À lire aussi - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [All-different, le filtre par matching de Régin](https://eternity2.dev/fr/research/build/reduce/alldiff-regin/) — Aucune pièce ne peut servir deux fois : une seule contrainte all-different globale sur 256 cases. Jean-Charles Régin a montré en 1994 comment un matching biparti la filtre complètement en temps polynomial ; sa variante par couleur est le propagateur le plus puissant jamais mesuré sur l'edge matching, avec une réserve nette sur les recherches tolérantes aux erreurs. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. --- # Le glissement d'arête > Le coup primé de Louis Verhaard : laisser le backtracker poser une pièce non concordante, mais seulement à des profondeurs choisies près du bas du plateau. Chaque glissement autorisé coûte un point de score et multiplie de façon astronomique le nombre de plateaux cibles. Voilà pourquoi son 467 a été trouvé plus de cinquante fois, et l'ancêtre direct des ruptures de Blackwood. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/reduce/edge-slipping/ - Mise à jour: 2026-07-02 - Sujets: search-space, local-search - Source: Verhaard définit le glissement d'arête (janvier 2009) — https://groups.io/g/eternity2/message/6328 - Source: Verhaard détaille la méthode du 467 : glissement conditionné à des profondeurs choisies, trouvé 50+ fois (décembre 2009) — https://groups.io/g/eternity2/message/7321 - Source: Le récit du 467 à la première personne par Verhaard : 247 pièces sans défaut (août 2009) — https://groups.io/g/eternity2/message/6891 - Source: La formule de dénombrement de Max pour N arêtes glissées (janvier 2009) — https://groups.io/g/eternity2/message/6390 - Source: Owen étend la théorie complexe aux glissements d'arête (msg 6408 ; la table des glissements est le msg 6412) — https://groups.io/g/eternity2/message/6408 - Source: La chaîne de Markov de Verhaard sur (profondeur, glissements) : comment le tableau de glissements a été optimisé (msg 6423) — https://groups.io/g/eternity2/message/6423 - Source: JSA reproduit le 467 avec le solveur public : l'échelle de rareté (msg 6687) — https://groups.io/g/eternity2/message/6687 - Source: La discipline « pas de ruptures adjacentes » de Blackwood (msg 10051) — https://groups.io/g/eternity2/message/10051 --- Le glissement d'arête, c'est le placement délibéré d'une pièce qui ne concorde pas avec l'un de ses voisins. Louis Verhaard, qui a forgé le terme sur la liste de diffusion, l'a défini en une phrase : « poser sur le plateau une pièce dont la couleur ne concorde pas avec celle d'un ou plusieurs de ses voisins » ([msg 6328](https://groups.io/g/eternity2/message/6328)). Cela ressemble à la description d'un échec. C'est en réalité l'idée de score partiel la plus lourde de conséquences de toute l'histoire du puzzle : parce que l'échelle des prix d'Eternity II récompensait les *arêtes concordantes* plutôt que l'achèvement parfait, une non-concordance coûte exactement un point sur 480, et tolérer un budget de non-concordances convertit une cible inatteignable, le plateau parfait, en un nombre astronomique de cibles atteignables. Tout l'art tient dans le mot *budget* : les glissements ne sont pas permis n'importe où, mais déverrouillés selon un calendrier, au plus profond de la recherche, là où ils sont bon marché. Toute cette page porte sur ce calendrier. ## La non-concordance qui remporte des prix À l'été 2008, Verhaard était bloqué par la voie légitime. Sans aucune tolérance à la non-concordance, il avait trouvé des centaines de plateaux partiels avec 248 pièces correctement placées (score 450) et estimait son plafond aux alentours de 456. Il n'a découvert que les pièces à moitié ajustées étaient *autorisées* qu'en exécutant le solveur public de Bob Cousins (à l'origine celui de Dave Clark) et en le voyant atteindre 458 en moins d'une minute ; de son propre aveu enjoué, il ne s'était jamais donné la peine de lire le règlement ([msg 5767](https://groups.io/g/eternity2/message/5767)). La même découverte a frappé Max de façon indépendante ce mois de juillet-là : il a modifié son backtracker pour tolérer une seule arête non concordante au-delà de la pièce 215 et a fait passer sur-le-champ un partiel en balayage de 219 pièces à 461 ([msg 5691](https://groups.io/g/eternity2/message/5691)) ; en septembre, il avait dépassé la « limite dont on ne parle pas » de la communauté, 463, « assez facilement ». La réponse de Verhaard, « Max, tu es vraiment un homme dangereux ! », ouvre l'échange sur la méthode dans lequel tous deux décrivent la forme de la technique aboutie : une recherche heuristique en profondeur d'abord, réglée pour garder les pièces restantes pavables, avec une tolérance à la non-concordance à la fin ([msgs 5767–5787](https://groups.io/g/eternity2/message/5767)). Six mois plus tard, le premier examen a payé : 10 000 $ à « Anna Karlsson de Lund » (l'épouse de Verhaard, faisant tourner son programme, [msg 6891](https://groups.io/g/eternity2/message/6891)) pour un plateau totalisant 467 arêtes concordantes sur 480. Le nombre qui importe pour cette page n'est pas 467 mais *cinquante* : « le 467 n'était pas un coup unique ; je l'ai trouvé plus de 50 fois » ([msg 7321](https://groups.io/g/eternity2/message/7321)). Un score qu'aucun argument exhaustif ne disait devoir être atteignable était trouvé de façon répétée, sur du matériel d'amateur, et lorsque Verhaard a publié le solveur, JSA l'a reproduit de l'extérieur, enregistrant 4 017 182 plateaux à 463, 227 245 à 464, 13 637 à 465, 625 à 466 et enfin deux 467 en environ quatre-vingts jours de fonctionnement continu ([msg 6687](https://groups.io/g/eternity2/message/6687)). Cette échelle de rareté est gravissable pour une raison : chaque barreau n'est pas un plateau unique mais une classe de plateaux combinatoirement énorme, et c'est le glissement qui rend la classe atteignable. La plupart des 467 de Verhaard avaient un score *propre*, des pièces sans aucune arête non concordante, de 247 seulement ([msg 7321](https://groups.io/g/eternity2/message/7321)) ; les non-concordances n'étaient pas des défauts sur le résultat, elles en étaient le mécanisme. ## Comment ça marche La description de Verhaard lui-même est concise ([msg 7321](https://groups.io/g/eternity2/message/7321)). Le programme « cherche normalement » (un backtracker en profondeur d'abord sur un ordre de remplissage fixe, avec des heuristiques réglées pour maximiser la pavabilité des pièces restantes) mais à certaines profondeurs il *autorise le glissement d'arête* : une pièce peut être posée avec une arête en désaccord avec un voisin déjà placé. Il est explicite sur ce que ce n'est pas : le solveur ne construit pas d'abord un partiel propre pour ensuite entasser les pièces restantes dans les trous à la fin, et c'est un programme différent de son chercheur de score propre, lequel a le droit de sauter des cases plutôt que de les rendre non concordantes. La tolérance est conditionnée à la profondeur et cumulative, structurée en ce que sa documentation appelle le *tableau de glissements* : pour chaque profondeur, le nombre d'arêtes glissées que la recherche est autorisée à avoir accumulées jusque-là. En dessous de la première barrière, le solveur est un backtracker exact ordinaire. Au-delà, chaque placement peut soit s'ajuster parfaitement, soit, si le budget de cette profondeur le permet, s'ajuster à moitié, et le budget déverrouille un glissement à la fois à mesure que la profondeur augmente. Deux faits font des barrières tardives tout l'enjeu : - **Le branchement.** Une pièce aléatoire s'ajuste à moitié bien plus souvent qu'elle ne s'ajuste pleinement. La machinerie de Verhaard suit les deux probabilités séparément, par profondeur, sous les noms `fitProb` et `halfFitProb` ([msg 6423](https://groups.io/g/eternity2/message/6423)). Ouvrez la porte du glissement à la profondeur 40 et vous multipliez la largeur de l'arbre là où il est déjà le plus large, noyant la recherche sous des préfixes inutiles. Ouvrez-la à la profondeur 210, où les branches survivantes sont quasiment forcées et où le nombre de candidats avoisine zéro, et la même option supplémentaire ranime des branches moribondes pour presque rien. - **L'héritage.** Une recherche en profondeur d'abord ne répare jamais un glissement ; le défaire signifie revenir en arrière à travers tout ce qui a été placé après lui. Un glissement admis à la profondeur 41 est scellé sous 215 placements ultérieurs ; un admis à la profondeur 221 en a 35 sous lui. Les glissements précoces dépensent le budget là où il rapporte le moins et coûte le plus. Et les barrières n'ont pas été devinées. Verhaard a optimisé à la fois l'ordre de remplissage et le tableau de glissements au moyen d'une chaîne de Markov dont les états sont des paires (profondeur, glissements déjà utilisés), avec des probabilités de transition estimées à partir des taux mesurés d'ajustement plein et à moitié ; à partir de la chaîne, il a calculé la probabilité d'atteindre le bas du plateau et le nombre de nœuds que chaque calendrier candidat coûterait ([msg 6423](https://groups.io/g/eternity2/message/6423)). Le calendrier gagnant concentrait tout le budget tardivement : treize glissements, une cible de 467. > **[Figure]** Interactif : la transformation par glissement d'arête — interactive: EdgeSlipLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Étape par étape 1. **Fixez N = 0.** Une seule classe cible : les plateaux parfaits. Personne n'en a jamais trouvé, et la [théorie complexe](/fr/research/why/complex-theory/) explique pourquoi personne ne devrait s'y attendre. 2. **Glissez jusqu'à N = 2.** Déjà ≈ 1,8 × 10⁵ fois plus de cibles, au score 478. Chaque glissement supplémentaire autorisé multiplie encore la classe, si bien que les barres grimpent d'environ deux ordres de grandeur par étape. 3. **Attention au trou à N = 1.** Il n'y a pas de barre : une arête intérieure glissée isolée est interdite par la parité, et la table des glissements d'Owen y a un zéro exact ([msg 6412](https://groups.io/g/eternity2/message/6412)). Les seuls plateaux à non-concordance unique passent par le bord extérieur non compté, la même fuite qui a produit [l'histoire du 479](/fr/research/build/analysis/parity-arguments/). 4. **Arrêtez-vous à N = 10.** Score cible 470, le record actuel, et exactement le budget de ruptures du [solveur de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/). 5. **Arrêtez-vous à N = 13.** Score cible 467, multiplicateur ≈ 6,9 × 10²⁷. Voilà pourquoi le programme d'un seul amateur a trouvé le plateau primé plus de cinquante fois. 6. **Basculez les barrières vers le début.** Même budget, même multiplicateur, mais le glissement le plus précoce se retrouve maintenant sous 215 placements ultérieurs au lieu de 55, et le branchement supplémentaire atterrit là où l'arbre est le plus large. C'est le calendrier, non le budget, que la chaîne de Markov de Verhaard était conçue pour bien régler. ## Ce que ça coûte Interrogé sur le nombre de partiels élevés existants, Max a raisonné à rebours à partir des solutions complètes et a produit le décompte empirique de la communauté pour les plateaux ayant $N$ arêtes intérieures glissées ([msg 6390](https://groups.io/g/eternity2/message/6390)): $$ S(480-N) \;\approx\; 2^{\,N-1}\binom{420}{N}\,S(480), \qquad N \ge 2, $$ où $\binom{420}{N}$ choisit lesquelles des 420 jonctions intérieures se rompent, les puissances de deux rendent compte (grossièrement) des manières de réaliser chaque rupture, et $S(480)$ est le nombre de plateaux parfaits. En injectant l'estimation précoce de la théorie complexe $S(480) = 26{,}700$, il a obtenu environ $4{,}7 \times 10^9$ plateaux à 478, $2{,}9 \times 10^{30}$ à 468 et $1{,}8 \times 10^{32}$ à 467, des nombres que ce projet a revérifiés à partir de la formule. Deux conséquences importent plus que les valeurs absolues, que Max lui-même a signalées comme simplifiées à l'excès : - **Le coût d'une arête concordante de plus.** Les rapports consécutifs se télescopent : $S(467)/S(468) = 2\binom{420}{13}/\binom{420}{12} = 2 \cdot 408/13 \approx 63$. Chaque arête que vous refusez de glisser réduit la classe cible d'un facteur d'environ soixante, ce qui correspond, comme l'a noté Max, au comportement observé du solveur de Verhaard ([msg 6390](https://groups.io/g/eternity2/message/6390)), et est du même ordre que la règle empirique d'Owen d'environ 100× par arête, publiée le lendemain sur le même fil ([msg 6391](https://groups.io/g/eternity2/message/6391)). - **Le plafond.** La multiplication s'achète au prix du score : $N$ glissements autorisés plafonnent le plateau à $480 - N$ pour toujours. Le glissement achète de l'atteignabilité, non de la qualité ; il convertit une recherche impossible en une recherche réalisable dont le meilleur résultat possible est strictement inférieur. Le prix en temps d'exécution, en revanche, est presque nul : par placement, le solveur compare un compteur de glissements à l'entrée du tableau de glissements correspondant à la profondeur courante (comptabilité en $O(1)$, incrémentée sur un placement à moitié ajusté et restaurée au retour en arrière). Tout le coût réside dans l'arbre qu'il déverrouille, ce qui explique pourquoi le placement des barrières est le problème de conception. Owen a bouclé la boucle en étendant la [théorie complexe](/fr/research/why/complex-theory/) aux glissements : remplacer la probabilité que les $m$ jonctions concordent toutes par $pm(m,v)$, la probabilité qu'exactement $v$ concordent, via la récurrence $pm(m,v) = pm(m-1,v) - pm(m,v+1)$, puis pondérer par les manières de positionner les glissements ([msg 6408](https://groups.io/g/eternity2/message/6408)). Sa table place les plateaux à 13 glissements à $2{,}05 \times 10^{35}$ fois le nombre de plateaux parfaits ([msg 6412](https://groups.io/g/eternity2/message/6412)), sept ordres de grandeur au-dessus du chiffre de Max, parce que la théorie compte aussi des quasi-plateaux qui ne sont des perturbations d'aucune solution, tandis que Max ne comptait que ceux dérivés d'un plateau parfait. Prenez l'un ou l'autre nombre : l'ensemble des cibles explose de façon combinatoire, tandis que le prix est linéaire en score. ## Du glissement aux ruptures Pendant douze ans, le 467 a tenu, et la conception aussi. Quand Joshua Blackwood est arrivé en 2020, un outsider dont le 468 a été relayé à la liste depuis Reddit, son solveur record portait une liste codée en dur : ```csharp break_indexes_allowed = new List() { 201, 206, 211, 216, 221, 225, 229, 233, 237, 239 }; ``` Lisez-la à la lumière de cette page et c'est un tableau de glissements : les non-concordances (« ruptures », dans son vocabulaire) interdites purement et simplement pour les 200 premiers placements, puis déverrouillées de façon cumulative, une à la fois, à des profondeurs choisies à la main, dix au total, pour un score cible de 470. Le concept, le conditionnement par profondeur et la concentration tardive du budget sont la conception de Verhaard de 2008, redérivée à force record ; c'est le réglage précis de ces profondeurs de déverrouillage qui a fait passer Blackwood de 469 à 470. Il a aussi ajouté une discipline que la version de Verhaard n'avait pas : deux ruptures ne peuvent jamais se toucher, si bien que chaque non-concordance se tient isolée parmi des arêtes concordantes, ce qui explique pourquoi n'importe laquelle de ses exécutions atteignant 255 placements se complète jusqu'à 256, et pourquoi un plateau à 469 fait aussi office de partiel propre de 249 pièces avec sept trous ([msg 10051](https://groups.io/g/eternity2/message/10051)). La machine complète, avec ses calendriers de quotas et son étude de paramètres, est sur [la page Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/). L'arithmétique de la filiation mérite d'être dite à voix haute. Les treize glissements de Verhaard visaient 467 ; les dix de Blackwood visent 470. Selon le rapport de Max, chaque glissement retiré coûte un facteur d'environ soixante, si bien que ces trois arêtes représentent en gros un multiplicateur de difficulté de $2 \times 10^5$, payé par douze ans de matériel, une boucle interne plus rapide et une communauté faisant tourner le code en parallèle. La technique elle-même n'a pas changé. Sur un puzzle scoré par arêtes concordantes, le coup gagnant, deux fois et à treize ans d'écart, n'a pas été une meilleure recherche de plateaux parfaits. Ce fut une redéfinition calendaire et budgétée de ce qui compte comme cible. ## À lire aussi - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [Arguments de parité](https://eternity2.dev/fr/research/build/analysis/parity-arguments/) — Comptez n'importe quoi sur un plateau à appariement d'arêtes deux fois, une fois de chaque côté, et les totaux doivent coïncider, livrant des preuves d'impossibilité au prix d'un seul passage. L'histoire du 479 en montre à la fois la puissance et le piège : un argument de parité limpide, vrai pour tout coup intérieur, mis en défaut par les soixante arêtes de bordure que personne ne comptabilise. - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. --- # Apprentissage des no-goods : se souvenir de ses échecs > Un sous-arbre voué à l'échec est un théorème : cet état partiel ne pourra jamais s'étendre. Mémorisez-le et n'y revenez plus jamais. La communauté a essayé les deux variantes : tables de transposition à la manière des échecs sur la frontière de recherche, et contraintes extraites du puzzle lui-même. Le bilan complet de ce que la mémoire achète à l'échelle d'E2, et les petits plateaux où elle paie vraiment. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/reduce/nogood-learning/ - Mise à jour: 2026-07-02 - Sujets: search-space, exact-methods - Source: Le schéma d'index de frontière de Max : 16 arêtes non appariées plus un bitmap de pièces (groups.io message 6137, 2008) — https://groups.io/g/eternity2/message/6137 - Source: Lindström l'essaie, « il apprend de ses erreurs » (groups.io message 6138) — https://groups.io/g/eternity2/message/6138 - Source: Le conseil de Verhaard à la manière des échecs : mémoire fixe, hachage, écrasement (groups.io message 6144) — https://groups.io/g/eternity2/message/6144 - Source: La taille de clé corrigée : 76 bits d'état de frontière ; taux de succès 0,1 % → 1 % avant épuisement de la mémoire (groups.io message 6145) — https://groups.io/g/eternity2/message/6145 - Source: Le décompte de Max des signatures de frontière distinctes : 5²·17¹⁴ ≈ 4×10¹⁸ (groups.io message 6143) — https://groups.io/g/eternity2/message/6143 - Source: La méthode améliorée : mémoire minime, 75–80 % des branches écartées (groups.io message 6218) — https://groups.io/g/eternity2/message/6218 - Source: La saga des restore-lists commence (groups.io message 8854, 2011) — https://groups.io/g/eternity2/message/8854 - Source: Le correctif de DeVincentis : une restore-list par arête, plus une pour les pièces utilisées (groups.io message 8886) — https://groups.io/g/eternity2/message/8886 - Source: Mesuré sur l'anneau de bordure 6×6 : 133 326 155 → 30 496 808 nœuds (groups.io message 8875) — https://groups.io/g/eternity2/message/8875 - Source: La Failure Lookup Table de Mocsi, abandonnée à cause d'un bug (groups.io message 8887) — https://groups.io/g/eternity2/message/8887 - Source: Les rangées supérieures dupliquées de McGavin : 40 heures-cœur prouvablement gaspillées (groups.io message 9610, 2016) — https://groups.io/g/eternity2/message/9610 - Source: Les mesures du taux de doublons de 21valy : ~1 % en clé exacte à mi-parcours ; la table relâchée sature en quelques minutes (groups.io message 9618) — https://groups.io/g/eternity2/message/9618 - Source: Verhaard : eii ne garde aucune mémoire des positions passées, et il a remporté les 10 000 $ (groups.io message 7451, 2010) — https://groups.io/g/eternity2/message/7451 - Source: Le bilan de Blackwood : mise en cache des 2×2 mesurée puis abandonnée (groups.io message 10056, 2020) — https://groups.io/g/eternity2/message/10056 - Source: L'extraction de placements invalides et l'appel à collaboration de Lindström (groups.io message 6743, 2009) — https://groups.io/g/eternity2/message/6743 - Source: La combinaison de deux pièces invalide de capiman pour le puzzle à 5 indices (groups.io message 10832, 2022) — https://groups.io/g/eternity2/message/10832 - Source: Le décompte : ~68 M de paires invalides trouvées, ~8,1×10⁹ indéterminées, et les ~32 000 paires d'une solution doivent toutes leur survivre (groups.io message 10973, 2023) — https://groups.io/g/eternity2/message/10973 - Source: Une combinaison de trois pièces invalide, disséquée jusqu'à trois cellules de l'anneau 0 (groups.io message 11131) — https://groups.io/g/eternity2/message/11131 - Source: SAT comme service d'invalidation : réduire un partiel sans issue à 28 pièces (groups.io messages 10289/10292, 2021) — https://groups.io/g/eternity2/message/10289 - Source: Le pipeline CNF de capiman : 130 180 variables, cryptominisat, partiels et anneaux (groups.io message 11822, 2026) — https://groups.io/g/eternity2/message/11822 --- Un backtracker qui abandonne un sous-arbre vient de démontrer un théorème : *cet état partiel ne peut pas être étendu en une solution*. Puis il jette le théorème et, quelques heures plus tard, le redémontre depuis une autre branche. L'apprentissage des no-goods, c'est le refus de gaspiller cette preuve : mémoriser l'état échoué, consulter le magasin avant de descendre, ne jamais y revenir. Les moteurs d'échecs fonctionnent sur cette idée (les tables de transposition), et les solveurs SAT l'ont industrialisée sous le nom d'apprentissage de clauses. La communauté d'Eternity II tente de la rentabiliser depuis 2008, sous deux variantes distinctes, et l'archive consigne à la fois les tentatives et les autopsies. ## Pourquoi un sous-arbre échoué est-il réutilisable Une recherche en profondeur d'abord suivant un [ordre de remplissage](/fr/research/build/backtracking/fill-order/) en ligne de balayage est fonction d'un nombre étonnamment réduit d'entrées. Lorsque le solveur se trouve à la profondeur $d$, tout le sous-arbre en dessous est déterminé par deux choses : la **frontière ouverte** (la séquence de couleurs exposée le long de la limite entre cellules placées et vides) et l'**ensemble des pièces encore en main**. Rien d'autre dans l'historique n'importe. Deux partiels de 128 pièces différents qui exposent les mêmes seize couleurs d'arête et laissent les mêmes 128 pièces inutilisées ont des sous-arbres *identiques*. Si le premier a échoué, le second échouera nécessairement, et le parcourir est pur gaspillage. [Peter McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) a surpris ce phénomène en pleine action en 2016 : deux combinaisons de rangée supérieure dans ses journaux de [farming](/fr/research/build/faster/distributed-solving/) 10×10 utilisaient les mêmes dix pièces avec la même permutation de couleurs le long de leur arête inférieure, et leurs arbres de recherche ont renvoyé exactement le même nombre de nœuds : 5 602 741 481 523 nœuds, deux fois. Les quelque 40 heures-cœur passées sur la seconde « ont été une perte de temps totale, puisque nous pouvions aisément prédire à l'avance que le résultat serait le même » ([message 9610](https://groups.io/g/eternity2/message/9610)). Le théorème est donc réel et le gaspillage aussi. Tout le reste de cette page porte sur la question de savoir si *se souvenir* revient moins cher que *redémontrer*. À l'échelle d'E2, cette question a une réponse étonnamment constante. ## Variante un : tables de transposition sur la frontière L'idée est arrivée sur la liste de diffusion en un seul fil à l'automne 2008. Max proposait d'indexer chaque partiel de 128 pièces (huit rangées achevées) par ses seize arêtes non appariées, en stockant à côté de l'index un bitmap des pièces qui étaient disponibles-plus-non-considérées lorsque le sous-arbre a échoué ; que l'on atteigne un autre partiel avec le même index dont les pièces disponibles forment un *sous-ensemble* du bitmap stocké, et l'on peut sauter le sous-arbre entier ([message 6137](https://groups.io/g/eternity2/message/6137)). Michael Lindström expérimentait déjà : cela « fonctionne plutôt bien, il apprend de ses erreurs et coupera de plus en plus de branches tôt dans la recherche » ([message 6138](https://groups.io/g/eternity2/message/6138)). [Louis Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/) a fourni la réponse d'ingénierie classique venue des échecs par ordinateur : ne pas essayer de tout stocker ; fixer un budget mémoire, hacher la position, écraser les anciennes entrées ([message 6144](https://groups.io/g/eternity2/message/6144)). Il a ajouté un avertissement : plus les ensembles de pièces de deux frontières correspondantes diffèrent, plus le sous-arbre que le succès peut légitimement couper est court. Puis les mesures sont arrivées, et elles constituent le cœur de l'histoire. La comptabilité corrigée de Lindström fixait la clé à 76 bits d'état de frontière (3 bits pour chacune des deux arêtes tournées vers la bordure, 5 bits pour chacune des quatorze arêtes intérieures), de sorte qu'une table directe nécessite $2^{76}/8$ octets, et Max a dénombré environ $5^2 \cdot 17^{14} \approx 4 \times 10^{18}$ signatures distinctes pour cette seule ligne de test ([message 6145](https://groups.io/g/eternity2/message/6145), [message 6143](https://groups.io/g/eternity2/message/6143)). En faisant tourner la chose réelle avec le point de rupture à 128 pièces, le taux d'écart a commencé à 0,1 % et a grimpé lentement jusqu'à environ 1 % avant que la mémoire ne s'épuise ([message 6145](https://groups.io/g/eternity2/message/6145)). Le verdict de Max sur ce 1 % : « nous ne devrions pas attendre de miracles de cette méthode » ([message 6152](https://groups.io/g/eternity2/message/6152)). Un mois plus tard, Lindström rapportait une version affinée : aucun état par pièce stocké, le point de test déplaçable, mémoire minime, « écarte environ 75-80 % en moyenne » ([message 6218](https://groups.io/g/eternity2/message/6218)). L'affirmation est frappante, mais personne d'autre ne l'a jamais mesurée et elle n'est jamais apparue dans un quelconque solveur record ; lorsqu'il est revenu en 2010, c'était pour demander au groupe de repérer le défaut de son schéma de réduction dynamique, et aucune réponse substantielle n'est venue ([message 7938](https://groups.io/g/eternity2/message/7938)). Notez ce qui rendait la clé si grosse : la frontière en ligne de balayage d'E2 est *large*. Une position d'échecs tient dans quelques dizaines d'octets quelle que soit la profondeur de la partie ; une frontière E2, ce sont seize arêtes ouvertes parmi dix-sept couleurs intérieures **plus** un ensemble de disponibilité de 256 pièces, et le nombre de signatures atteignables croît exponentiellement avec la longueur de la frontière. C'est la même quantité d'entropie de frontière qui gouverne la [loi d'aire de l'entropie](/fr/research/why/entropy-area-law/) : la frontière est là où réside l'information du puzzle, et une clé de transposition doit la porter tout entière ou bien être incorrecte. ## Les pièges de correction C'est précisément incorrectes que se sont révélées les variantes moins coûteuses, et la contribution la plus instructive de l'archive sur ce sujet est une autopsie publique. En 2011, Lindström a décrit un backtracker où chaque cellule tient une liste de candidats vivante, et où une pièce réfutée à une cellule est retirée de cette liste et rangée sur une « restore-list » attachée à la cellule antérieure dont l'annulation la rendrait de nouveau valide ; un élagage mémoïsé, en somme ([message 8854](https://groups.io/g/eternity2/message/8854)). Cela réduisait magnifiquement le nombre de nœuds et perdait silencieusement des solutions : ses runs 8×8 manquaient certaines des 52 solutions connues. Au fil de plus de trente messages, McGavin a insisté avec objections et cas de test sondants ([message 8866](https://groups.io/g/eternity2/message/8866)) jusqu'à ce que Joseph DeVincentis diagnostique le défaut : une unique restore-list confond le *pourquoi* de l'élimination d'une pièce. Chaque cellule a besoin d'une restore-list par arête voisine plus une pour les pièces utilisées ailleurs, restaurées à des moments différents du backtrack ([message 8871](https://groups.io/g/eternity2/message/8871), [message 8886](https://groups.io/g/eternity2/message/8886)). Le gain que le schéma poursuivait était réel : Lindström avait déjà mesuré l'anneau de bordure 6×6 tombant de 133 326 155 nœuds à 30 496 808 ([message 8875](https://groups.io/g/eternity2/message/8875)). Dans le même fil, Mocsi a reconnu sa propre Failure Lookup Table (recherche en spirale, enregistrement de l'arrangement des couleurs extérieures à chaque repli forcé vers la bordure, consultation avant de descendre), abandonnée parce qu'un bug l'empêchait de résoudre ne serait-ce que le 6×6 et « le débogage n'est pas si facile, quand il faut attendre plusieurs milliers d'itérations avant que le bug ne se produise » ([message 8887](https://groups.io/g/eternity2/message/8887)). La leçon se généralise. Un no-good est une *preuve*, et mettre en cache des preuves signifie que votre clé de cache doit capturer toutes les hypothèses que la preuve a utilisées. Sous-indexez-la en oubliant une arête voisine, une pièce utilisée ou un moment de restauration, et vous mettez en cache une fausseté qui supprime discrètement des solutions. C'est pourquoi la version correcte de l'idée à l'intérieur des moteurs CSP n'enregistre les no-goods qu'aux échecs de propagation avec leurs ensembles de raisons complets, vérifiés à la manière SAT avec des littéraux surveillés ; les mécanismes sont exposés sur la [page sur les encodages SAT et CSP](/fr/research/build/exact/sat-csp-encodings/). ## Variante deux : des no-goods sur le puzzle lui-même Une entrée de transposition dit « cet état, dans cette recherche, est mort ». Un type de no-good plus fort dit « cette configuration locale n'apparaît dans **aucune solution d'Eternity II** » : une contrainte apprise sur le puzzle, pas sur le run, valable pour tout solveur et partageable sous forme de fichier. Ce programme démarre lui aussi en 2009 avec Lindström : étant donnés les coins et les indices, il a dénombré ~4 500 placements simples intrinsèquement invalides, estimé entre 20 et 50 millions de combinaisons de deux pièces invalides, et appelé ouvertement des collaborateurs à vérifier et échanger des fichiers de « placements invalides » que tout solveur pourrait utiliser pour de la coupe de branches précoce ([message 6743](https://groups.io/g/eternity2/message/6743)) ; la comparaison de matrices de possibilité avec un autre membre ([message 6951](https://groups.io/g/eternity2/message/6951)) a fait aussitôt surgir un écart 618 contre 624 ([message 6956](https://groups.io/g/eternity2/message/6956)) que Lindström a mis sur le compte d'une confusion de rotation de son propre côté ([message 6957](https://groups.io/g/eternity2/message/6957)). La forme moderne et industrialisée est celle de capiman. À partir d'un CNF généré du puzzle à 5 indices (130 180 variables, ~4 Go, résolu avec un ancien cryptominisat ; le pipeline est décrit de première main au [message 11822](https://groups.io/g/eternity2/message/11822)), il extrait des placements de deux pièces prouvablement invalides, des paires qui ne peuvent coexister à leurs positions dans aucune solution ([message 10832](https://groups.io/g/eternity2/message/10832)), et a même disséqué une combinaison de *trois* pièces invalide jusqu'aux trois cellules de l'anneau 0 qu'elle étrangle ([message 11131](https://groups.io/g/eternity2/message/11131)). La même machinerie a tourné comme un service pour d'autres membres : à qui lui donnait un partiel sans issue, il retirait les pièces une à une, ne gardant chaque retrait que si le solveur SAT répondait encore UNSAT ([message 10292](https://groups.io/g/eternity2/message/10292)), et renvoyait un noyau de 28 pièces déjà non extensible ([message 10289](https://groups.io/g/eternity2/message/10289)). C'est de la minimisation de clause de conflit effectuée à la main, exactement ce qu'un solveur CDCL fait en interne après chaque conflit. La comptabilité, toutefois, donne à réfléchir et capiman l'a publiée lui-même : en février 2023, la mine contenait ~68 millions de paires invalides confirmées, contre environ $8{,}1 \times 10^9$ paires encore indéterminées ; cachées parmi les indéterminées, selon son estimation, se trouvent les ~32 000 paires d'une solution réelle, celles qu'aucune campagne d'invalidation n'a le droit de toucher ([message 10973](https://groups.io/g/eternity2/message/10973)). Soixante-huit millions de théorèmes, chacun individuellement vrai, couvrant collectivement moins de 1 % de l'espace des paires, sans moyen de deviner le reste sans risquer l'une des 32 000 qui doivent survivre. Les contraintes apprises sur E2 sont de véritables actifs. Elles sont simplement déposées sur un compte aux passifs astronomiques. Pourquoi la version automatisée de cet apprentissage par CDCL s'épuise elle aussi sur le plateau complet (chaînes d'implication plates, conflits tardifs et larges) est traité sur la [page sur les encodages SAT et CSP](/fr/research/build/exact/sat-csp-encodings/) ; c'est le même phénomène, rencontré du côté de l'extraction. ## Le palmarès : mesuré, puis abandonné Voici maintenant le contrepoids, car sur ce sujet les négatifs de l'archive sont mieux documentés que ses positifs. **Le solveur primé ne se souvenait de rien.** Interrogé en 2010 sur le fait de savoir si son solveur public dédoublonnait les milliers de plateaux à 463–465 qu'il trouvait, Verhaard a répondu sans détour : « il ne s'en souvient pas ». Il n'y avait aucune mémoire des positions passées, et vu les volumes de nœuds, quelqu'un avait presque certainement déjà recroisé n'importe quelle position donnée ([message 7451](https://groups.io/g/eternity2/message/7451)). C'est le même Verhaard qui avait donné le conseil de transposition à la manière des échecs deux ans plus tôt ([message 6144](https://groups.io/g/eternity2/message/6144)), et dont le moteur a détenu le record de 467 pendant plus d'une décennie. Il connaissait la technique ; il a livré sans elle. **Le moteur record a mesuré la mise en cache et l'a abandonnée.** En cataloguant ce qu'il a essayé après le 469, Joshua Blackwood a listé les solveurs SAT, les GPU, « et la mise en cache de tous les 2 par 2 pré-résolus », tout mesuré, rien gardé ; seul l'affinage des heuristiques de placement a payé, valant environ 2× ([message 10056](https://groups.io/g/eternity2/message/10056)). Les raisons qu'il invoque pour rejeter une conception de cache par thread apparentée relèvent de pure arithmétique mémoire : le coût de reconstruction lorsque la recherche retraverse la frontière du cache, et la certitude que des tables par thread ne tiendraient plus dans le L3. Les moteurs les plus rapides passent déjà plus de la moitié de leurs cycles bloqués sur la mémoire (voir [ingénierie des solveurs](/fr/research/build/faster/solver-engineering/)) ; une sonde de cache par nœud est une proposition d'ajouter un aller-retour à la latence DRAM à une boucle qui vit ou meurt par le L1. **Les taux de succès ont été mesurés, et ils sont maigres.** En 2016, 21valy a instrumenté un solveur 10×10 en ligne de balayage : les états exactement dupliqués (mêmes bordures, mêmes tuiles intérieures, mêmes nords exposés) surviennent à raison d'environ 1 % à mi-parcours du plateau, d'où sa « morale n°1 : ne pas se soucier des vrais doublons ». Les clés relâchées (tuiles intérieures seulement) montrent 30–40 % de répétition, mais le gain théorique plafonne sous les 25 % et sa table de hachage « croît trop rapidement … saturée en quelques minutes » ([message 9618](https://groups.io/g/eternity2/message/9618)). Un pour cent de succès, chacun épargnant un sous-arbre, contre une sonde à chaque nœud et une table dont l'ensemble actif dépasse la RAM en quelques minutes : voilà le problème du seuil de rentabilité en une seule mesure. Le motif commun aux trois cas : personne n'a réfuté le théorème. Les sous-arbres échoués *sont* réutilisables. Ce qui a échoué, c'est le taux de change : en 16×16 la clé de frontière est trop large, l'espace d'états trop grand pour qu'une table couvre une fraction utile, et le coût de sonde retombe sur la ressource exacte (la bande passante mémoire) que les backtrackers rapides ont déjà épuisée. ## Où elle paie vraiment Réduisez le plateau ou fermez la recherche, et la même idée change de signe. - **Petits plateaux et anneaux.** Le schéma de restore-lists de Lindström a réduit l'anneau de bordure 6×6 d'un facteur 4,4 ([message 8875](https://groups.io/g/eternity2/message/8875)). Sur un petit espace d'états, la table *peut* couvrir une fraction significative des frontières atteignables, de sorte que les taux de succès grimpent du pour-mille au pour-cent et au-delà. - **Énumération et comptage exhaustifs.** Lorsque l'arbre sera parcouru jusqu'au bout, chaque sous-arbre dupliqué est une revisite garantie, pas probabiliste : les rangées supérieures jumelles de McGavin ([message 9610](https://groups.io/g/eternity2/message/9610)) sont 40 heures-cœur qu'une vérification de signature aurait épargnées avec certitude. Dédoublonner des listes de rangées énumérées avant de les distribuer, c'est exactement cela, appliqué au sommet de l'arbre, et la culture du recensement de la communauté (les 9×9 exhaustifs, les puzzles à indices intégralement énumérés) est là où la discipline d'énumération l'emporte visiblement (voir [benchmarks](/fr/research/build/benchmarks/)). - **Finales.** Profondément dans le plateau, l'ensemble des pièces restantes est petit, la frontière courte, et le sous-problème se répète sur de nombreuses moitiés supérieures : le régime où une table de mémoïsation reste petite, chaude et fiable. - **À l'intérieur d'un moteur de propagation.** Enregistrer un no-good ferme avec son ensemble de raisons complet à chaque échec de propagation est correct par construction et bon marché à vérifier : l'héritage côté CSP de CDCL décrit sur la [page des encodages](/fr/research/build/exact/sat-csp-encodings/). ## Ce qu'elle coûte - **La clé : entropie de frontière, payée par entrée.** Une clé de transposition correcte, c'est la frontière ouverte plus l'ensemble des pièces restantes. À une ligne de test en milieu de plateau, cela fait $2 \cdot 3 + 14 \cdot 5 = 76$ bits d'état d'arête ([message 6145](https://groups.io/g/eternity2/message/6145)) plus un bitmap de pièces de 256 bits pour le test de sous-ensemble ([message 6137](https://groups.io/g/eternity2/message/6137)), et le nombre de clés *atteignables* à cette seule ligne est d'environ $5^2 \cdot 17^{14} \approx 4 \times 10^{18}$ ([message 6143](https://groups.io/g/eternity2/message/6143)). En général, la population de clés croît comme $e^{h \cdot \ell}$ pour une frontière de longueur $\ell$ : une loi de périmètre, le même terme de frontière que celui de la [loi d'aire](/fr/research/why/entropy-area-law/), et c'est pourquoi les petits plateaux sont bon marché et le 16×16 ne l'est pas. - **La table : la couverture, c'est la mémoire divisée par la population.** Une table de hachage de $M$ entrées face à $K$ clés atteignables en couvre $M/K$ ; avec $K \approx 4 \times 10^{18}$, une table de 64 Gio ($M \approx 2^{33}$ entrées) en couvre environ $10^{-9}$. Les succès ne viennent alors que de la localité à court terme, ce qu'a observé Lindström : 0,1 % grimpant à 1 % et calant contre le mur de la mémoire ([message 6145](https://groups.io/g/eternity2/message/6145)). - **La sonde : un aller-retour DRAM par nœud.** Un moteur moderne place $\sim$70 M de pièces par seconde (environ $14$ ns par nœud) tandis qu'une sonde aléatoire de table coûte un blocage mémoire de $\sim$100 ns, soit $c \approx 7$ nœuds de recherche. Le cache ne paie que si $$ p_{\text{hit}} \cdot \bar{S} \;>\; c \;\approx\; 7 \text{ nœuds}, $$ où $\bar{S}$ est la taille moyenne d'un sous-arbre sauté. Au $p_{\text{hit}} \approx 1\%$ mesuré ([message 9618](https://groups.io/g/eternity2/message/9618)), il faut $\bar{S} > 700$ nœuds *et* une table qui retienne effectivement ces entrées, celle-là même que 21valy a vue saturer en quelques minutes. À un $p_{\text{hit}} \sim 10^{-9}$ effectif, aucun $\bar{S}$ réaliste n'équilibre les comptes. - **La correction : l'ensemble de raisons complet, ou rien.** Chaque hypothèse que la preuve d'échec a utilisée doit figurer dans la clé : restore-lists par arête, listes de pièces utilisées, tout ([message 8886](https://groups.io/g/eternity2/message/8886)), et le mode de défaillance du sous-indexage, ce sont des solutions silencieusement perdues, le bug le plus coûteux qu'une recherche exhaustive puisse avoir. Voilà le résumé que l'archive a gagné en dix-huit ans : le théorème est gratuit, la mémoire ne l'est pas. Un sous-arbre échoué est bel et bien un fait qui vous appartient, mais à l'échelle du plateau complet, stocker des faits coûte plus cher que les redécouvrir, et les deux solveurs qui ont établi des records ont tous deux choisi, après mesure, d'oublier. ## À lire aussi - [REPLAY](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/replay/) — Reconstruire à l'identique les plateaux stricts à 460 de la communauté, et découvrir au passage le coup que les solveurs ordinaires ne savent pas jouer : payer deux désaccords sur une même case. - [Encodages SAT et CSP](https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/) — Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. - [Ingénierie de solveur : l'artisanat sous l'algorithme](https://eternity2.dev/fr/research/build/faster/solver-engineering/) — Tous les solveurs record exécutent le même backtracking en profondeur d'abord. Ce qui les distingue, c'est la couche en dessous : tables de correspondance, hachages parfaits, structs taillées pour le cache, code généré, archéologie du compilateur. C'est cet artisanat qui décide si un nœud coûte 26 cycles ou 2 600. Vingt ans de registre d'ingénierie de la communauté, technique par technique, et ce que tout cela a rapporté. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. --- # L'exécuter soi-même > L'ensemble du site, le moteur et chaque résultat de cette section tournent depuis un seul dépôt. Voici comment le lancer, recompiler le moteur WebAssembly et reproduire les chiffres. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/run-it-yourself/ - Mise à jour: 2026-07-21 - Source: Le dépôt eternity2 sur GitHub — https://github.com/raphael-anjou/eternity2 --- L'ensemble du site, le moteur et chaque résultat de cette section tournent depuis un seul dépôt. Voici comment le lancer et reproduire les chiffres. ## Récupérer le code Clonez le dépôt. Tout s'y trouve : le moteur Rust, le site web et les sujets de recherche avec leurs scripts de calcul. ```bash git clone https://github.com/raphael-anjou/eternity2 cd eternity2 ``` ## Ce qu'il vous faut Trois chaînes d'outils. Le moteur est écrit en Rust, le site est une application Node, et le moteur est livré au navigateur sous forme de WebAssembly. - **Rust**, version stable, avec la cible `wasm32-unknown-unknown` - **Node.js 22+ et pnpm** pour le site web (`corepack enable` vous procure pnpm) - **wasm-pack** pour compiler le moteur en WebAssembly - **just** (facultatif), un petit lanceur de tâches qui encapsule les commandes ci-dessous ## Compiler et lancer le site Avec `just` installé, deux commandes. La première compile le moteur en WebAssembly et installe les dépendances web ; la seconde démarre le site sur `localhost:5173` avec rechargement à chaud. ```bash just setup just dev ``` Vous préférez lancer les choses directement ? Chaque recette `just` n'est qu'un enrobage d'une seule ligne, vous pouvez donc vous passer entièrement de `just` : ```bash # build the engine to WebAssembly cd engine && wasm-pack build --target web --out-dir ../web/src/engine/pkg --release # install and run the site cd ../web && pnpm install && pnpm dev ``` ## Travailler sur le moteur Le moteur est une crate Rust classique qui compile aussi en WebAssembly. Lancez ses tests, puis recompilez le WASM chaque fois que vous le modifiez. Les tests comportent des vérifications croisées face à de vrais plateaux de la communauté, si bien qu'ils détectent toute modification du jeu de pièces, de la rotation ou du calcul de score. ```bash just test # cargo test --release just wasm # rebuild the WebAssembly after a change ``` ## Reproduire un résultat de recherche Chaque sujet de cette section est autonome : un article, un script de calcul et la sortie versionnée qu'il produit. Réexécuter le script régénère cette sortie. Les résultats déterministes reviennent identiques octet pour octet ; les exécutions qui dépendent du hasard ou qui prennent des heures le disent clairement, et livrent le plateau qu'elles ont trouvé, pour que vous puissiez tout de même le vérifier dans la visionneuse. Par exemple, le décompte des motifs interdits (une vingtaine de secondes) : ```bash just research-forbidden-patterns # or directly: cd research/topics/forbidden-patterns/compute cargo run --release > ../results/feasibility.json ``` Chaque résultat de cette section possède sa propre recette de reproduction ; l'[index de reproduction](/fr/research/build/reproduce/) les liste, chacune avec sa commande et ce qu'elle régénère. ## Lancer toutes les vérifications Une seule commande exécute ce que fait l'intégration continue : tests du moteur, vérification de types, lint et build de production. ```bash just check # engine tests, typecheck, lint, build ``` [Parcourir le dépôt sur GitHub](https://github.com/raphael-anjou/eternity2). ## À lire aussi - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. --- # Comment cherchent les solveurs record > Comment cherchent réellement les solveurs qui détiennent les records. Ce sont tous, au fond, des backtrackers en profondeur d'abord ; ce qui les distingue, c'est l'ordre dans lequel ils essaient les choses et la manière dont ils assouplissent les règles à l'approche de la fin. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/solvers/ - Mise à jour: 2026-07-21 - Sujets: backtracking, speed --- Tout solveur qui détient un record sérieux à Eternity II est, au fond, la même machine : un backtracker en profondeur d'abord. Ce qui les distingue, ce n'est pas la boucle, mais trois choix qui se superposent à celle-ci : l'ordre dans lequel ils visitent les cases, les heuristiques qui décident quelle pièce essayer en premier, et la manière dont ils assouplissent la fin de partie lorsqu'il n'existe plus de correspondance parfaite. Cette page est la visite neutre de ces choix. L'histoire complète et de première main de chaque moteur (décodée à partir du code source et de la littérature, puis reconstruite et mesurée) vit sur sa propre page de laboratoire, reliée depuis chaque section ci-dessous. ## Les moteurs en un coup d'œil Avant la visite, le catalogue : une ligne par moteur, et les quatre choix qui le distinguent. Chaque portée est mesurée sur un seul cœur, sur une même machine, si bien que les chiffres se comparent à l'identique plutôt que d'un cluster à l'autre ; chaque ligne renvoie à son compte rendu complet. | Moteur | Ordre de remplissage | Élagage | Régime matériel | Portée mesurée | | --- | --- | --- | --- | --- | | [Backtracker de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) | balayage par rangée depuis le bas-gauche, pièces de bord tard | quota de couleur par profondeur plus un budget d'indice de rupture selon la profondeur | un seul cœur ; le 470 est venu de nombreux cœurs en parallèle | 248/256 pièces sans contrainte ; s'arrête vers 45 une fois les cinq indices fixés | | [eii de Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/) | ordres de recherche en peigne | élagage anticipé face à des seuils de score réglés ; un calendrier de glissement réglé par Markov | binaire Win32 sur un cœur ; pas de source à recompiler | 467/480, le seul prix que le concours a payé | | [Backtracker C de McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) | selon le puzzle : balayage par rangée, spirale, ou bord d'abord | code généré plus tables de correspondance et astuces de compteur pour le débit brut | un seul cœur, ~109M placements/s sur le vrai puzzle | au-delà de 200/256 pièces ; conçu pour la vitesse, pas pour un score record | | [Réimplémentation de Verhaard](/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/) | recuit par échange de composition d'ensembles sous la métrique 2×2 | acceptation par recuit, constantes récupérées au bit près depuis le binaire | un seul cœur ; exécution versionnée et réexécutable | 438/480 sur le vrai puzzle à cinq indices | | [Préréglages CSP, mesurés](/fr/research/lab/experiments/single-core-benchmark/csp-presets/) | une douzaine de préréglages d'ordre, bord d'abord le meilleur | propagation par cohérence d'arc | un seul cœur, dix variantes ancrées par coin | près de 183 sur les variantes ancrées ; sous la moitié du score d'un prétendant | La visite ci-dessous parcourt les trois choix que ces lignes partagent. ## Le backtracking élémentaire Remplir le plateau case par case selon un ordre fixé. À chaque case, essayer toute pièce et toute rotation dont les bords correspondent à ce qui est déjà posé ; si aucune ne convient, revenir en arrière et essayer autrement la case précédente. Correct mais lent : l'arbre de recherche est d'une largeur astronomique. Voici exactement cela, au ralenti : un vrai backtracker sur une grille 3×3, une décision à la fois. Avancez pas à pas et observez une pièce se poser, une impasse apparaître, puis la recherche retirer la pièce et réessayer. > **[Interactive: DfsDemo]** Rendered on the canonical page (link above); not shown in this markdown export. ## L'ordre compte : le chemin de remplissage L'ordre dans lequel vous visitez les cases modifie la difficulté de plusieurs ordres de grandeur, car certains ordres forcent les conflits à apparaître tôt (c'est bon) tandis que d'autres les repoussent jusqu'à ce que beaucoup de travail soit gaspillé (c'est mauvais). Commencer par la bordure l'emporte largement sur un parcours ligne par ligne sur le même puzzle. C'est l'unique levier que règle chaque moteur record : les ordres de recherche en peigne de Verhaard, le balayage de Blackwood en lignes depuis le coin inférieur gauche avec les pièces de bordure intercalées tardivement, et le choix par McGavin, puzzle par puzzle, entre balayage en lignes, spirale vers l'intérieur ou bordure d'abord sont tous des réponses à la même question. ## Heuristiques : quelle pièce en premier Un backtracker élémentaire essaie les candidats dans un ordre arbitraire. Un moteur record les note, de sorte que les pièces les plus susceptibles de compter se posent en premier, et il élague toute branche qui prend du retard sur un calendrier. Le solveur de Blackwood, par exemple, privilégie trois couleurs et impose un quota par profondeur qui doit être atteint pour continuer à descendre ; Verhaard élague vers l'avant en s'appuyant sur des seuils de score réglés à la main. Les détails diffèrent, mais la forme est partagée : engager tôt les pièces contraintes, couper les branches qui ne peuvent pas rentabiliser leur coût. ## Assouplir la fin de partie : ruptures et glissement de bords Un pavage parfait de 256 pièces n'a jamais été trouvé. Chaque plateau record tolère plutôt une poignée de non-correspondances tardives, et les moteurs les atteignent en *planifiant* l'imperfection : un budget par profondeur de bords non appariés qui se débloque au plus profond de la recherche. Verhaard appelait le sien un tableau de glissement (slip array) ; Blackwood appelle le sien les indices de rupture (break indexes). Même idée, conditionnée par la profondeur pour que le début du plateau reste propre et que les non-correspondances ne soient dépensées que là où elles rapportent le plus. Le laboratoire ci-dessous vous permet de déplacer ce budget et d'observer comment le score atteignable évolue : > **[Interactive: BreakIndexLab]** Rendered on the canonical page (link above); not shown in this markdown export. ## Lire l'histoire complète du moteur Chaque moteur record dispose d'une page dédiée qui décode son fonctionnement, puis le reconstruit et le mesure sur une seule machine, en mono-cœur : - **[Le solveur de Blackwood, décodé et exécuté ici](/fr/research/lab/experiments/joshua-blackwood/solver/)** : le backtracker à calendrier et indices de rupture derrière le 470 en vigueur, avec l'étude de paramètres de Jef Bucas et une reconstruction qui file sans contraintes mais cale dès que les cinq indices sont épinglés. - **[L'eii de Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/)** : le moteur derrière le 467, le seul prix que le concours ait jamais versé : élagage vers l'avant, ordres de recherche en peigne, calendrier de glissement réglé par chaîne de Markov, et pourquoi son binaire sans source ne peut plus être exécuté aujourd'hui. - **[Le backtracker en C de McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/)** : le moteur le plus rapide de la communauté, une recette d'optimisation de 2007 affinée durant deux décennies, reconstruite ici et poussée au-delà de 200 pièces sur 256 à plus de 100 millions de placements par seconde. - **[Le backtracker JIT](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/)** : un moteur en Rust portable qui génère et compile du code propre à chaque puzzle, porté échelon par échelon jusqu'au débit de McGavin - à égalité avec son C optimisé à la main sur les plateaux difficiles et réalistes (son C reste plus rapide sur les faciles) - un résultat de vitesse sur un [axe qui lui est propre](/fr/research/lab/experiments/raphael-anjou/going-fast/) vis-à-vis du score que poursuivent les moteurs record. - **[Le moteur de référence de ce site](/fr/research/lab/experiments/raphael-anjou/engine/)** : non pas une machine à records, mais le backtracker Rust/WASM qui fait tourner chaque démonstration de ce wiki et en vérifie les chiffres. ## Le voir tourner Le bac à sable exécute un vrai solveur en profondeur d'abord dans votre navigateur. [Regardez-le chercher en direct](/playground/watch/), ou [dessinez votre propre ordre de remplissage](/playground/paths/) et lancez-le en course contre les classiques pour ressentir à quel point l'ordre compte. Pour les approches qui ne fonctionnent pas, voir les [impasses](/fr/research/build/dead-ends/). --- # Les techniques > L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/techniques/ - Mise à jour: 2026-07-21 - Source: Problème de satisfaction de contraintes (Wikipédia) : le cadre général — https://en.wikipedia.org/wiki/Constraint_satisfaction_problem --- L'étagère des techniques : les algorithmes et les idées d'élagage qui reviennent dans tout solveur Eternity II sérieux, chacun avec ce qu'il est, ce qu'il coûte et ce qu'il a réellement rapporté une fois mesuré sur ce puzzle. Vous débarquez ici, ou vous voulez voir tout le territoire d'un coup ? Commencez par [une carte de toutes les approches connues](/fr/research/build/approaches-map/) : chaque famille d'attaque sur une seule page, ce que chacune a atteint et où elle se heurte à un mur. Le [catalogue des solveurs](/fr/research/build/solvers/) montre comment les moteurs détenteurs de records assemblent ces pièces ; la page des [impasses](/fr/research/build/dead-ends/) recense les techniques qui semblaient tout aussi prometteuses et n'ont pas survécu à l'épreuve du terrain. ## À lire aussi - [Comment cherchent les solveurs record](https://eternity2.dev/fr/research/build/solvers/) — Comment cherchent réellement les solveurs qui détiennent les records. Ce sont tous, au fond, des backtrackers en profondeur d'abord ; ce qui les distingue, c'est l'ordre dans lequel ils essaient les choses et la manière dont ils assouplissent les règles à l'approche de la fin. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. --- # La boîte à outils de la communauté, 2007-2026 > Dix-neuf ans de logiciels communautaires pour Eternity II (interfaces de placement manuel, éditeurs, solveurs publics, générateurs et visualiseurs), plus la couche plus discrète qui les a rendus interopérables : e2pieces.txt, les sommes de contrôle CRC-16 et le format plateau-dans-une-URL devenu la lingua franca. Un recensement de référence, chaque outil rattaché au message qui l'a annoncé. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/tooling/ - Mise à jour: 2026-07-02 - Source: Le format de fichier e2pieces.txt mis par écrit (John Morrison), eternity2@groups.io, 2007-12 — https://groups.io/g/eternity2/message/3571 - Source: Le schéma de somme de contrôle CRC-16, semaine du lancement, eternity2@groups.io, 2007-07 — https://groups.io/g/eternity2/message/1063 - Source: Le Manual Placement Program d'eii4me, le premier outil GUI partagé, eternity2@groups.io, 2007-12 — https://groups.io/g/eternity2/message/3541 - Source: Naissance d'E2Lab (Fred / Eternity Blogger), eternity2@groups.io, 2009-10 — https://groups.io/g/eternity2/message/7071 - Source: Jef Bucas lance e2.bucas.name, le visualiseur de plateaux, eternity2@groups.io, 2019-11 — https://groups.io/g/eternity2/message/9955 - Source: Publication de libblackwood (Jef Bucas), eternity2@groups.io, 2020-11 — https://groups.io/g/eternity2/message/10078 - Source: Recensement des fichiers e2pieces.txt : « c'est le bazar ! » (Vasily V.), eternity2@groups.io, 2023-03 — https://groups.io/g/eternity2/message/11033 - Source: e2.bucas.name (Jef Bucas), le visualiseur communautaire et le format de plateau partagé d'aujourd'hui — https://e2.bucas.name --- La communauté Eternity II a écrit beaucoup de logiciels : des solveurs, bien sûr, mais aussi des programmes de placement manuel pour les joueurs à la main, des éditeurs de plateaux, des explorateurs de chemins de remplissage, des générateurs de puzzles, des rendus et des visualiseurs. Cette page est le recensement de cette boîte à outils : qui a construit chaque outil, quand, ce qu'il faisait, et où il vit aujourd'hui. Les [pages d'histoire](/fr/research/community/hunt/) racontent le récit dans lequel ces outils apparaissent, et les [pages solveurs](/fr/research/build/solvers/) couvrent les algorithmes. Les liens morts sont signalés comme morts ; rien ici n'est une recommandation de téléchargement. Une contrainte a façonné les années du concours. En août 2007, l'inventeur du puzzle a revendiqué un droit d'auteur sur le dessin des pièces et menacé les participants qui les faisaient circuler ([msg 1342](https://groups.io/g/eternity2/message/1342)) ; la norme est alors devenue que les outils communautaires ne livraient pas les pièces. Chaque programme ci-dessous attend de vous que vous saisissiez votre propre jeu : « un rite de passage dans la confrérie E2. Nous l'avons TOUS fait. », comme l'a formulé Alan O'Donnell lorsque la querelle a resurgi pour la énième fois ([msg 7578](https://groups.io/g/eternity2/message/7578)). Les modérateurs, de leur côté, retiraient les fichiers de pièces des archives d'outils mises en ligne quand les auteurs dérapaient ([msg 7609](https://groups.io/g/eternity2/message/7609)). C'est pourquoi la boîte à outils comporte une seconde couche, moins visible : des formats de fichiers partagés et des protocoles de somme de contrôle qui permettent aux outils et aux personnes d'interopérer sans que quiconque transmette les données des pièces. Les deux couches sont cataloguées ici. Cette norme s'est depuis érodée. Des fichiers `e2pieces.txt` remplis ont circulé sur GitHub pendant des années (Vasily V. a recensé « tous ceux qu'il a pu trouver » en 2023, plus bas), et des bibliothèques de jeux de pièces ouvertes ont suivi : Eternity2Puzzles.jl de jwortmann et eii-puzzles de Dobrogost embarquent tous deux le jeu. Les nombres d'adjacence des arêtes sont, en pratique, publics. Notre propre [kit de démarrage](/fr/research/build/toolkit/) fournit le jeu pour la même raison : la reproductibilité sans étape de transcription manuelle. ## 2007-2008 : les outils du lancement Les premiers outils précèdent le puzzle. Brendan Owen a publié du code source C++ pour générer des puzzles de type Eternity II en janvier 2007, six mois avant le lancement ; ce code est la graine de toute la culture des jeux d'essai ([msg 41](https://groups.io/g/eternity2/message/41)). Sergio « Zerjillo » Alonso a mis en ligne un corpus de 10 080 plateaux de test générés, plus le générateur et un tableur statistique, au printemps ([msg 201](https://groups.io/g/eternity2/message/201), [msg 202](https://groups.io/g/eternity2/message/202), [msg 203](https://groups.io/g/eternity2/message/203)). Owen avait aussi écrit un programme de vision par ordinateur pour lire les panneaux de pièces scannés, qui a numérisé le vrai puzzle la veille du lancement ([msg 789](https://groups.io/g/eternity2/message/789), [msg 1054](https://groups.io/g/eternity2/message/1054)). Le fleuron de l'année du lancement fut **eternity2.net** de Dave Clark, le [solveur distribué](/fr/research/build/faster/distributed-solving/) fondé sur BOINC ([msg 756](https://groups.io/g/eternity2/message/756)). Il a moins compté pour son calcul (le projet a fermé en décembre 2007 sans rien avoir changé, [msg 3511](https://groups.io/g/eternity2/message/3511)) que pour son héritage : les fichiers `e2pieces.txt` / `e2hints.txt` de son client sont devenus les formats standard de la communauté (voir plus bas), son solveur et ses fichiers de données ont été préservés dans l'archive du groupe avec la bénédiction de Clark ([msg 3633](https://groups.io/g/eternity2/message/3633)), Bob Cousins a livré des versions « rmc » du solveur corrigées par la communauté ([msg 3654](https://groups.io/g/eternity2/message/3654)), et Clark a rendu open-source son programme de R&D personnel, un solveur de recherche capable d'exporter des encodages SAT et LP et de générer des puzzles de type E2 ([msg 3716](https://groups.io/g/eternity2/message/3716)). Le premier backtracker *public* rapide fut le solveur C++ de Marc Lebel sur squaro.fr, dont la liste a disséqué les rouages dans le meilleur fil d'ingénierie de solveurs de l'époque ([msg 1704](https://groups.io/g/eternity2/message/1704)). Le rendu a été résolu tôt et astucieusement. Henk van der Griendt a photographié ses propres pièces et construit un visualiseur HTML à partir des clichés ([msg 2499](https://groups.io/g/eternity2/message/2499)) ; Ignacio Ruiz de Conejo est allé plus loin avec **EPiecesV2.ps**, un programme PostScript qui restitue n'importe quel plateau 16×16 ou jeu de 256 pièces à partir de la numérotation officielle des arêtes. Il a livré le *moteur de rendu* plutôt que les données des pièces, précisément pour rester du bon côté de la ligne du droit d'auteur ([msg 2616](https://groups.io/g/eternity2/message/2616)). Owen l'a adopté pour sa propre visualisation ([msg 2617](https://groups.io/g/eternity2/message/2617)). Les non-programmeurs ont eu leur outil en décembre 2007 : le **Manual Placement Program** d'eii4me (EternManShare.EXE), une interface VB6 pour placer les pièces à la main, publiée avec le source et itérée jusqu'à la version S3.00 en huit jours au gré des retours de la communauté ([msg 3541](https://groups.io/g/eternity2/message/3541), [msg 3719](https://groups.io/g/eternity2/message/3719)). Et en février 2008, Yannick Kirschhoffer a publié **Eternity II Editor 1.0.0**, un éditeur de plateaux Java multiplateforme qui allait devenir l'outil le plus durable de tous ([msg 4544](https://groups.io/g/eternity2/message/4544)). ## 2008-2010 : l'ère des éditeurs et la vague open-source La sortie centrale de l'époque fut **eii** de Louis Verhaard, le solveur qui a remporté le seul prix en argent qu'Eternity II ait jamais versé. Publié en septembre 2008 sur fingerboys.se avec ces mots : « Je suis bloqué et mon seul espoir d'améliorer mon meilleur score est de recourir à la force brute » ([msg 5940](https://groups.io/g/eternity2/message/5940)), il était distribué sous forme de binaire à faire tourner par des volontaires ; la documentation et un décodeur de ses fichiers de sortie `.eii` ont suivi en janvier 2009, accompagnés de la révélation que les utilisateurs avaient trouvé 467 plus de quarante fois ([msg 6275](https://groups.io/g/eternity2/message/6275)). Son hébergement est une leçon de pourrissement des liens : fingerboys.se était le site web du groupe de musique de Verhaard et a disparu avec le groupe ([msg 7446](https://groups.io/g/eternity2/message/7446)), si bien qu'en janvier 2010 le solveur a migré tel quel vers [shortestpath.se/eii](http://www.shortestpath.se/eii/), son propre site et son foyer de long terme ([msg 7439](https://groups.io/g/eternity2/message/7439)). Des amateurs le faisaient encore tourner à des scores de niveau 466 en 2011 ([msg 8840](https://groups.io/g/eternity2/message/8840)), et des vétérans guidaient encore les nouveaux venus à travers `eii.exe` en 2021 ([msg 10202](https://groups.io/g/eternity2/message/10202)). La machine elle-même a [sa propre page solveur](/fr/research/lab/experiments/louis-verhaard/eii/). Autour de lui, toute une étagère s'est remplie : - **E2_Manual**, le programme de placement manuel DirectX de trans.spam (Thomas), en v1.0.0.18 à la mi-2008 ([msg 5686](https://groups.io/g/eternity2/message/5686)), migré vers un projet SourceForge avec binaires et source en juin 2009 ([msg 6765](https://groups.io/g/eternity2/message/6765)). - **Eternity II Editor** est passé du statut d'éditeur à celui de solveur : 1.3 en mars 2009, puis 1.4.0 avec les vrais motifs E2, un solveur intégré et un générateur de plateaux aléatoires ([msg 6594](https://groups.io/g/eternity2/message/6594), [msg 6679](https://groups.io/g/eternity2/message/6679)), puis la v1.5 dans la journée suivant les demandes de fonctionnalités d'un utilisateur ([msg 6978](https://groups.io/g/eternity2/message/6978)). Il vit sur SourceForge (sourceforge.net/projects/eternityii) ; Kirschhoffer a refait surface en 2012 en proposant toujours de l'aide sur le code ([msg 9064](https://groups.io/g/eternity2/message/9064)), et en 2023 le 460 de Bruno Gauthier (le meilleur plateau à cinq indices jusqu'en 2026) a été « réalisé avec mon propre programme et Eternity II Editor » ([msg 11074](https://groups.io/g/eternity2/message/11074)), converti au format du visualiseur partagé par Peter McGavin ([msg 11081](https://groups.io/g/eternity2/message/11081)). - **E2Lab.** Fred (« Eternity Blogger ») a publié un éditeur+solveur Windows en octobre 2009 et itéré presque quotidiennement ([msg 7071](https://groups.io/g/eternity2/message/7071)) ; il a pris le nom E2Lab à la v1.0.0.20 ([msg 7148](https://groups.io/g/eternity2/message/7148)), et la v1.0.0.21 a retiré un « bouton magique » explicitement « pour respecter les règles du jeu » ([msg 7150](https://groups.io/g/eternity2/message/7150)). E2Lab est aussi à l'origine de la leçon canonique de la communauté sur la fiabilité des outils : en décembre 2009, un utilisateur a rapporté une fenêtre surgissante annonçant un 471 sur un plateau qui n'a jamais été enregistré, une affirmation invérifiable qui hante encore les discussions sur les records ([msg 7284](https://groups.io/g/eternity2/message/7284)). - **e2walker.** L'explorateur de chemins de remplissage de Philippe Coustaux, dans la section Fichiers du groupe depuis août 2007 ([msg 2313](https://groups.io/g/eternity2/message/2313)), révisé par Ole Knudsen (« Kron ») et, lors de l'inventaire dressé par la liste en 2009, toujours « le seul programme de son espèce » : un solveur qui permet de spécifier un chemin de remplissage arbitraire de 256 pas ([msg 7056](https://groups.io/g/eternity2/message/7056), [msg 7067](https://groups.io/g/eternity2/message/7067)). - **WhichWayToGo.jar.** L'interface d'okifinoki (Benjamin) pour noter des chemins de remplissage candidats selon le nombre d'options attendu par placement ; trois implémentations indépendantes ont convergé sur ses statistiques au fil du fil de discussion ([msg 6572](https://groups.io/g/eternity2/message/6572)). Son générateur de puzzles graphique E2Generator.jar avait rejoint l'espace Fichiers l'automne précédent ([msg 6036](https://groups.io/g/eternity2/message/6036)). - **Le source ouvert des solveurs** est arrivé par vagues : le solveur C++ à propagation de contraintes de Markus Zajc ([msg 6748](https://groups.io/g/eternity2/message/6748)) ; le backtracker Java de Martin Hapl sur hapl.net, mis au jour par la liste et profilé par la communauté de 1,2 M à 2,9 M d'itérations/s ([msg 6794](https://groups.io/g/eternity2/message/6794), [msg 6916](https://groups.io/g/eternity2/message/6916)) ; le solveur C# à parallélisme de tâches de snazzyflapper, aussitôt remis en ligne sans le fichier de pièces que les modérateurs avaient signalé ([msg 7606](https://groups.io/g/eternity2/message/7606), [msg 7610](https://groups.io/g/eternity2/message/7610)) ; et l'**Eternity II Java Toolbox** de doc_s_smith, une suite de cinq outils (backtracker configurable, placement piloté par contraintes, recherche tolérante aux discordances avec réparation par échange, estimateur de nœuds Monte-Carlo, chercheur de stratégie de remplissage) qui a marqué le retour du vétéran d'Eternity I en juin 2010 ([msg 7755](https://groups.io/g/eternity2/message/7755)). ## 2011-2018 : les outils des années creuses À mesure que le concours mourait, les outils sont devenus plus étranges et plus personnels. Dan Hansen, après « 4 années captivantes » d'algorithmes E2, a livré **Edge Match Puzzles** pour iPhone, la première fois que l'expertise de la communauté devenait un produit grand public ([msg 8943](https://groups.io/g/eternity2/message/8943)) ; le groupe universitaire de Tony Wauters a publié une application Android de correspondance d'arêtes ([msg 9057](https://groups.io/g/eternity2/message/9057)). Juraj Pivovarov a mis en ligne un visualiseur d'ordre de balayage, qu'il présentait avec autodérision comme une « perte de temps totale » ([msg 9013](https://groups.io/g/eternity2/message/9013)). La théorie est devenue un document : le complex_theory.pdf de Peter McGavin, la transcription LaTeX du modèle d'Owen, était dans les Fichiers du groupe dès 2013 ([msg 9188](https://groups.io/g/eternity2/message/9188)). Le flambeau de l'open-source est passé à David Barr : un solveur OpenCL publié sur GitHub en 2015 ([msg 9360](https://groups.io/g/eternity2/message/9360), [msg 9367](https://groups.io/g/eternity2/message/9367)). Le dépôt, github.com/david3x3x3/eternity2, reste la base de code la plus réutilisée de l'époque, suivie de montages en grappe de Raspberry Pi avec une page d'état publique ([msg 9582](https://groups.io/g/eternity2/message/9582)), d'un solveur Python dans le navigateur via Pyodide ([msg 9854](https://groups.io/g/eternity2/message/9854)) et d'expériences de liens dansants (dancing-links) avec visualisations ([msg 10095](https://groups.io/g/eternity2/message/10095), [msg 10100](https://groups.io/g/eternity2/message/10100)). Le web a eu son premier terrain de jeu de solveur aussi : le backtracker de navigateur de Guillaume L. sur 16x16tetravex.xyz, dont les résolutions instantanées se sont effondrées en « sans fin » dès que les puzzles étaient régénérés avec des statistiques de couleurs de type E2, une démonstration en direct de l'endroit où réside la difficulté ([msg 9449](https://groups.io/g/eternity2/message/9449), [msg 9458](https://groups.io/g/eternity2/message/9458)). ## 2019-2026 : la pile moderne La chaîne d'outils moderne commence par un sauvetage. Quand Yahoo a annoncé qu'il effacerait le contenu de Groups en 2019, la migration vers groups.io a transféré les messages, fichiers et photos à quelques semaines près ([msg 9934](https://groups.io/g/eternity2/message/9934)), ce qui explique pourquoi les outils de l'espace Fichiers cités plus haut existent encore, à l'abri du mur d'adhésion du groupe. Deux semaines après la migration, Jef Bucas a lancé **[e2.bucas.name](https://e2.bucas.name)** : des plateaux rendus en SVG et encodés entièrement dans les paramètres d'URL (« puisque les paramètres sont après le '#', rien n'est réellement transmis au serveur »), avec un menu déroulant des meilleurs plateaux qui est discrètement devenu le livre des records de la communauté ([msg 9955](https://groups.io/g/eternity2/message/9955)). Une page Indices répondant aux éternelles questions sur les pièces-indices a suivi en 2021 ([msg 10082](https://groups.io/g/eternity2/message/10082)), et une refonte avec raccourcis clavier et affichage du score en 2022 ([msg 10590](https://groups.io/g/eternity2/message/10590)). Pratiquement chaque plateau partiel partagé depuis est une URL e2.bucas.name. La lignée des solveurs de records est une histoire à trois dépôts. Joshua Blackwood a rendu open-source son **EternityII_Solver** en C# (le code derrière le 468) en septembre 2020, après avoir d'abord demandé un fichier de pièces standard pour que son dépôt ne livre pas de données protégées ([msg 10037](https://groups.io/g/eternity2/message/10037), [msg 10034](https://groups.io/g/eternity2/message/10034)). Bucas l'a eu en état de marche sous Mono en quelques heures ([msg 10038](https://groups.io/g/eternity2/message/10038)), l'a réécrit en C pour environ le double de la vitesse ([msg 10065](https://groups.io/g/eternity2/message/10065)), et a publié le générateur derrière le portage sous le nom de **libblackwood** (du Python qui émet du C rapide) sur github.com/jfbucas/libblackwood ([msg 10078](https://groups.io/g/eternity2/message/10078)). Quand le dépôt d'origine est discrètement passé en privé, le « Où est le logiciel que vous utilisez tous ? » d'un nouveau venu l'a fait republier : « C'est exactement le code utilisé pour trouver un 470 » ([msg 10161](https://groups.io/g/eternity2/message/10161)). Le portage, l'original et le visualiseur constituent la pile derrière chaque record depuis 2020 ; la [page du solveur Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) couvre l'algorithme lui-même. Le reste de l'étagère moderne : **E2Play** de mtmidgee, un ancien plateau de jeu manuel VB recodé en C# et rendu open-source depuis le confinement australien, « pas un solveur (en aucune manière, forme ou façon) » ([msg 10208](https://groups.io/g/eternity2/message/10208)) ; **solveforscore** de David Barr, un maximiseur de score en Python publié dans son dépôt GitHub, qui a produit un 462 sans indices ([msg 11088](https://groups.io/g/eternity2/message/11088), [msg 11101](https://groups.io/g/eternity2/message/11101)) ; **Eternity2Puzzles.jl** de jwortmann, un paquet Julia qui étend la théorie de la complexité avec les jointures invalides et un tableau de glissement ([msg 11603](https://groups.io/g/eternity2/message/11603)) ; et **eii-puzzles** de Michal Dobrogost (github.com/michal-dobrogost/eii-puzzles), un générateur de puzzles bien testé doté d'une bibliothèque d'analyse C en-têtes seulement, générant des instances à 5 indices à la manière de l'original ([msg 11752](https://groups.io/g/eternity2/message/11752)). ## La couche des conventions Les formats ont survécu à la plupart des outils, et ce sont eux qu'un nouveau venu a réellement besoin de connaître. **e2pieces.txt / e2hints.txt.** Le format du fichier de pièces a été fixé par le client BOINC d'eternity2.net (un solveur distribué a besoin d'une entrée standard, [msg 10952](https://groups.io/g/eternity2/message/10952)), et a été consciemment mis par écrit comme standard de la communauté en décembre 2007, John Morrison publiant des descriptions explicites du format ([msg 3571](https://groups.io/g/eternity2/message/3571), [msg 3572](https://groups.io/g/eternity2/message/3572)). Quinze ans de dérive ont suivi : lorsque Vasily V. a recensé en 2023 tous les `e2pieces.txt` qu'il a pu trouver sur GitHub, son verdict fut « c'est le bazar ! ». Il a trouvé des numérotations et palettes incohérentes et au moins un mauvais fichier qui avait été recommandé aux nouveaux venus ([msg 11033](https://groups.io/g/eternity2/message/11033)). Le fil sur la confusion des formats qui l'avait immédiatement précédé avait déjà produit la liste de pièces de référence dans la numérotation devenue standard de facto vers laquelle on oriente les nouveaux venus aujourd'hui ([msg 10970](https://groups.io/g/eternity2/message/10970)), vérifiée conforme-somme-de-contrôle dans le suivi du recensement ([msg 11034](https://groups.io/g/eternity2/message/11034)). Les conventions de numérotation elles-mêmes sont des décisions de la semaine du lancement : les types d'arêtes numérotés d'après le livret, actés avant que le puzzle n'ait deux semaines ([msg 983](https://groups.io/g/eternity2/message/983)) ; une proposition de 2009 de renuméroter les motifs « universellement » a été refusée précisément parce que des standards de facto existaient déjà ([msg 6804](https://groups.io/g/eternity2/message/6804)). **Sommes de contrôle CRC-16.** Durant les années du concours, quand la norme était de ne pas redistribuer le jeu de pièces, la communauté vérifiait plutôt les transcriptions : on publiait des sommes de contrôle CRC-16 par bloc de 8 pièces et on comparait. Les membres ont convergé sur des CRC identiques dans la journée suivant le lancement ([msg 1063](https://groups.io/g/eternity2/message/1063), [msg 1073](https://groups.io/g/eternity2/message/1073)) ; les utilitaires de somme de contrôle (Checksum-v4.txt, ChecksumCalc.zip) se sont installés dans la section Fichiers comme réponse standard à « mon fichier de pièces est-il correct ? » ([msg 7591](https://groups.io/g/eternity2/message/7591)), et le protocole a été étendu aux puzzles à indices en 2009 ([msg 6769](https://groups.io/g/eternity2/message/6769)). **Le format plateau-dans-une-URL.** Depuis 2019, un plateau *est* une URL e2.bucas.name : largeur, hauteur, liste de pièces et arêtes dans le fragment, rendu côté client, rien d'envoyé à aucun serveur ([msg 9955](https://groups.io/g/eternity2/message/9955)). C'est le format dans lequel les records sont annoncés, vérifiés et archivés : la lingua franca d'aujourd'hui, comme `e2pieces.txt` l'était en 2008. Ce site est une branche de plus de cette lignée : son [visualiseur](/viewer/) lit le même format d'URL, et les plateaux communautaires qu'il embarque sont catalogués dans [les plateaux notables](/fr/research/community/boards/). ## Le recensement | Outil | Auteur | Naissance | Statut | Source | | --- | --- | --- | --- | --- | | Générateur de puzzles de type E2 (C++) | Brendan Owen | 2007-01 | Fichiers du groupe (membres) | [41](https://groups.io/g/eternity2/message/41) | | Corpus d'essai + générateur | Sergio "Zerjillo" Alonso | 2007-05 | Fichiers du groupe (membres) | [201](https://groups.io/g/eternity2/message/201) | | eternity2.net (BOINC) + solveur R&D | Dave Clark | 2007-07 | fermé 2007-12 ; fichiers archivés | [756](https://groups.io/g/eternity2/message/756), [3716](https://groups.io/g/eternity2/message/3716) | | Solveur C++ public (squaro.fr) | Marc Lebel | 2007-08 | statut actuel inconnu | [1704](https://groups.io/g/eternity2/message/1704) | | e2walker (explorateur de chemins) | Philippe Coustaux | 2007-08 | Fichiers du groupe (membres) | [2313](https://groups.io/g/eternity2/message/2313), [7056](https://groups.io/g/eternity2/message/7056) | | Visualiseur HTML à base de photos | Henk van der Griendt | 2007-09 | personnel ; jamais distribué | [2499](https://groups.io/g/eternity2/message/2499) | | EPiecesV2.ps (moteur de rendu PostScript) | Ignacio Ruiz de Conejo | 2007-09 | Fichiers du groupe (membres) | [2616](https://groups.io/g/eternity2/message/2616) | | Manual Placement Program | eii4me | 2007-12 | Fichiers du groupe (membres) | [3541](https://groups.io/g/eternity2/message/3541) | | Eternity II Editor | Yannick Kirschhoffer | 2008-02 | SourceForge ; utilisé jusqu'en 2023 | [4544](https://groups.io/g/eternity2/message/4544), [11074](https://groups.io/g/eternity2/message/11074) | | E2_Manual | trans.spam (Thomas) | 2008-07 | SourceForge (2009) | [5686](https://groups.io/g/eternity2/message/5686), [6765](https://groups.io/g/eternity2/message/6765) | | eii (solveur distribué + décodeur) | Louis Verhaard | 2008-09 | shortestpath.se/eii ; fingerboys.se mort | [5940](https://groups.io/g/eternity2/message/5940), [7439](https://groups.io/g/eternity2/message/7439) | | E2Generator.jar | okifinoki (Benjamin) | 2008-10 | Fichiers du groupe (membres) | [6036](https://groups.io/g/eternity2/message/6036) | | WhichWayToGo.jar | okifinoki (Benjamin) | 2009-03 | Fichiers du groupe (membres) | [6572](https://groups.io/g/eternity2/message/6572) | | Solveur C++ à contraintes | Markus Zajc | 2009-05 | Fichiers du groupe (membres) | [6748](https://groups.io/g/eternity2/message/6748) | | Backtracker Java (hapl.net) | Martin Hapl | 2009-07 | hapl.net ; statut actuel inconnu | [6794](https://groups.io/g/eternity2/message/6794) | | E2Lab (éditeur + solveur) | Fred ("Eternity Blogger") | 2009-10 | blog de l'auteur ; statut actuel inconnu | [7071](https://groups.io/g/eternity2/message/7071) | | Eternity II Java Toolbox | doc_s_smith (Dietmar Wolz) | 2010-06 | Fichiers du groupe (membres) | [7755](https://groups.io/g/eternity2/message/7755) | | Edge Match Puzzles (iPhone) | Dan Hansen | 2011-07 | sortie App Store ; statut inconnu | [8943](https://groups.io/g/eternity2/message/8943) | | Visualiseur d'ordre de balayage | Juraj Pivovarov | 2012-01 | Fichiers du groupe (membres) | [9013](https://groups.io/g/eternity2/message/9013) | | complex_theory.pdf | Peter McGavin | 2013-07 | Fichiers du groupe (membres) | [9188](https://groups.io/g/eternity2/message/9188) | | Solveurs OpenCL/CPU, solveforscore | David Barr | 2015-04 | GitHub (david3x3x3/eternity2) | [9367](https://groups.io/g/eternity2/message/9367), [11088](https://groups.io/g/eternity2/message/11088) | | Solveur de navigateur (16x16tetravex.xyz) | Guillaume L. | 2015-09 | statut actuel inconnu | [9449](https://groups.io/g/eternity2/message/9449) | | e2.bucas.name (visualiseur de plateaux) | Jef Bucas | 2019-11 | en ligne | [9955](https://groups.io/g/eternity2/message/9955) | | EternityII_Solver | Joshua Blackwood | 2020-09 | GitHub (public à nouveau depuis 2021) | [10037](https://groups.io/g/eternity2/message/10037), [10161](https://groups.io/g/eternity2/message/10161) | | libblackwood (générateur de portage C) | Jef Bucas | 2020-11 | GitHub (jfbucas/libblackwood) | [10078](https://groups.io/g/eternity2/message/10078) | | E2Play (plateau de jeu manuel) | mtmidgee | 2021-08 | rendu open-source | [10208](https://groups.io/g/eternity2/message/10208) | | Eternity2Puzzles.jl | jwortmann | 2025-08 | GitHub | [11603](https://groups.io/g/eternity2/message/11603) | | eii-puzzles (générateur + bibliothèque C) | Michal Dobrogost | 2026-01 | GitHub (michal-dobrogost/eii-puzzles) | [11752](https://groups.io/g/eternity2/message/11752) | Là où un statut indique « Fichiers du groupe (membres) », l'artefact a survécu à la migration Yahoo-vers-groups.io de 2019 ([msg 9934](https://groups.io/g/eternity2/message/9934)) et est accessible aux [membres du groupe](https://groups.io/g/eternity2). Les *jeux* d'essai qui ont transité par ces outils (celui de Txibilis, de Geoff, de Benoist, les 9×9 et 10×10 d'Owen) ont [leur propre page](/fr/research/build/benchmarks/). ## À lire aussi - [Les benchmarks de la communauté](https://eternity2.dev/fr/research/build/benchmarks/) — Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. - [La traque, une histoire (partie I : 2000-2009)](https://eternity2.dev/fr/research/community/hunt/) — L'histoire de la communauté, d'une liste de diffusion fondée sept ans avant que le casse-tête n'existe jusqu'au prix d'examen de 10 000 $ remporté sous un nom d'emprunt, chaque événement rattaché à son message d'origine. Partie I d'une chronique en cours. - [Les plateaux marquants](https://eternity2.dev/fr/research/community/boards/) — Les plateaux célèbres d'Eternity II, traités comme des objets d'étude à part entière : le 467 primé de Verhaard, la lignée de records Blackwood jusqu'à 470, le record strict à cinq indices porté à 464, et les plateaux propres à ce projet : qui a trouvé chacun, quand, et ce qui le rend structurellement intéressant. Chaque plateau embarqué s'ouvre dans le visualiseur. --- # La boîte à outils du bâtisseur > Un kit de démarrage Rust prêt à l'emploi pour construire votre propre solveur Eternity II : scorer, générer des plateaux au vrai équilibre des couleurs, générer des lots avec indices épinglés, convertir tous les formats, mesurer les performances, et une boucle résoudre→balayer→comparer, où vous n'écrivez que le solveur. Plus une configuration en une ligne pour les agents de code, et un générateur de plateaux directement dans le navigateur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/toolkit/ - Mise à jour: 2026-07-20 - Source: Le kit de démarrage (ce dépôt) : l'espace de travail Rust, les exemples et les fichiers de configuration pour agents — https://github.com/raphael-anjou/eternity2/tree/main/research/starter-kit --- Tout ce qu'il faut pour *commencer* à construire un solveur Eternity II, sauf le solveur lui-même. Le [kit de démarrage](https://github.com/raphael-anjou/eternity2/tree/main/research/starter-kit) est un dossier du dépôt : un petit espace de travail Rust qui fait déjà la plomberie. Scoring, génération de plateaux, génération de lots avec indices épinglés, conversion de formats, benchmarks, et une boucle complète **résoudre → balayer → comparer** : tout y est. Vous écrivez un seul `Solver` ; tout le reste continue de fonctionner autour. Rien dans le kit ne réimplémente le scoring, la génération ou les formats. Ils proviennent des mêmes bibliothèques partagées que le site lui-même utilise, donc un score du kit est le *même* nombre que celui produit par le [visualiseur](/viewer/) et tout autre moteur : le décompte canonique des arêtes appariées, bordure exclue. Copiez le dossier, glissez-y votre idée, et itérez. > **[Interactive: AgentSetupBlock]** Rendered on the canonical page (link above); not shown in this markdown export. ## Ce qu'il y a dans la boîte - **Scorer et vérifier n'importe quel plateau**, depuis une URL `eternity2.dev` / `e2.bucas.name` ou un simple bloc `board_edges`, via le scorer canonique, et le contrôler contre le vrai jeu de pièces officiel (pièces toutes distinctes, conformité des indices), que le kit fournit désormais. - **Générer des plateaux** au vrai équilibre des couleurs d'Eternity II : cinq couleurs de bordure confinées au cadre, l'intérieur équilibré, chaque pièce distincte, entièrement déterministe selon la graine. - **Générer des lots** (« donne-moi 100 plateaux, ces graines, cinq indices épinglés ») en JSON de schéma-site reproductible que vous pouvez relire directement. - **Convertir** entre tous les formats de la communauté : `board_edges`, `board_pieces`, `e2pieces.txt`, les URLs `eternity2.dev` et bucas héritées, et le CSV. Voir la [référence des formats](/fr/research/build/formats/). - **Mesurer** la plomberie en mono-cœur, pour connaître le budget de surcharge de votre solveur. - **La boucle d'itération :** un trait `Solver` stable, un lanceur de balayage qui écrit des répertoires de run reproductibles, et un outil `compare` qui compare deux runs, avec la discipline de variance qu'exige ce puzzle intégrée. ## La seule règle que le kit impose pour vous Sur Eternity II, le score varie beaucoup d'une graine à l'autre : l'écart-type entre graines est d'environ 12 à 20 points pour un solveur de plateau complet. Une différence d'un ou deux points de moyenne entre deux versions de solveur est donc presque toujours du bruit. L'outil `compare` du kit refuse de qualifier de gain une différence en dessous du bruit, vous dit de balayer au moins 40 graines, et rapporte toujours l'écart. Gardez tout en mono-cœur, comme le font les [benchmarks](/fr/research/build/benchmarks/) du site, et vos chiffres restent comparables à ceux de tous les autres. ## Écrire votre premier solveur Tout le kit est bâti autour d'un seul trait : ```rust use e2_kit::{Board, Budget, Instance, SolveOutcome, Solver}; struct MySolver; impl Solver for MySolver { fn name(&self) -> String { "my-solver".into() } fn solve(&mut self, instance: &Instance, start: &Board, budget: Budget) -> SolveOutcome { let mut board = start.clone(); // `start` porte déjà les indices épinglés // ...votre recherche ici. Interrogez budget.expired(). SolveOutcome::complete(board) // ou ::improved / ::exhausted / ::bound } } ``` Copiez `examples/my_solver.rs` (une base gloutonne complète et fonctionnelle), remplacez le corps de `solve`, puis balayez-le : ```bash cargo run --release --example sweep -- --n 40 --budget 3 cargo run --release --bin e2kit -- compare runs/ runs/ ``` Les recettes complètes (scoring, génération, lot, conversion, benchmark) sont dans le [README](https://github.com/raphael-anjou/eternity2/tree/main/research/starter-kit#readme) du kit. Les plateaux pour tester un solveur sont dans le [jeu de données](/fr/research/build/dataset/) CC0 ; les approches à essayer sont recensées dans la [carte de toutes les approches connues](/fr/research/build/approaches-map/). ## Générer des plateaux ici même Le générateur du kit, dans le navigateur : le même moteur WASM, sans installation. Choisissez une forme et une plage de graines, et il produit un lot reproductible ; cliquez sur un plateau pour l'ouvrir dans le [visualiseur](/viewer/) et le scorer arête par arête. > **[Interactive: BoardGenerator]** Rendered on the canonical page (link above); not shown in this markdown export. Vous voulez la même chose en ligne de commande, ou 10 000 plateaux avec indices épinglés ? Utilisez l'exemple `generate_batch` du kit : il écrit chaque plateau en JSON que vous pouvez réinjecter directement dans un solveur. ## À lire aussi - [L'exécuter soi-même](https://eternity2.dev/fr/research/build/run-it-yourself/) — L'ensemble du site, le moteur et chaque résultat de cette section tournent depuis un seul dépôt. Voici comment le lancer, recompiler le moteur WebAssembly et reproduire les chiffres. - [Le jeu de données](https://eternity2.dev/fr/research/build/dataset/) — Un jeu de données public sous licence CC0 pour Eternity II, en deux volets : quatorze instances de référence à résoudre, et un corpus de 7 658 plateaux forts distincts dont on peut s'inspirer. Chaque score est recalculé à partir du plateau lui-même, et le corpus est vérifié comme réellement varié, plutôt que mille copies d'un même plateau. - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Les formats de plateau et de puzzle, couchés sur le papier](https://eternity2.dev/fr/research/build/formats/) — Tous les formats sous lesquels un plateau ou un puzzle Eternity II circule sur ce site et dans la communauté : la chaîne de lettres board_edges et la liste d'indices hints, e2pieces.txt, le CSV de puzzle, le JSON Puzzle du site, et l'URL de visualiseur, avec les règles exactes au niveau de l'octet (comment la bordure grise est encodée dans chacun) et, surtout, ce que chaque format sait et ne sait pas restituer. --- # Les variantes et les revendications qui y prospèrent > Tous les « Eternity II » qui ne sont pas le vrai puzzle : la variante Marathon de TopCoder et le 468 non résolu de Takahashi, le 480/480 sans cadre de McGavin, les plateaux à jeux mélangés, le défi sans amorce et la mise en quarantaine des revendications, de l'avertissement de 2007 sur les jeux fantômes à l'éthique communautaire de vérification à connaissance nulle. Se termine par une liste de contrôle pour énoncer un score correctement. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/build/variants/ - Mise à jour: 2026-07-02 - Source: L'avertissement sur les jeux fantômes (Sergio Demian Lerner), eternity2@groups.io, 2007-07 — https://groups.io/g/eternity2/message/1210 - Source: Le popup « 471 » non sauvegardé d'E2Lab, eternity2@groups.io, 2009-12 — https://groups.io/g/eternity2/message/7284 - Source: Une résolution à la main valant « au moins 472 », jamais prouvée, eternity2@groups.io, 2010-01 — https://groups.io/g/eternity2/message/7383 - Source: Brendan Owen demande au revendiquant du 476/480 de publier la grille, eternity2@groups.io, 2011-02 — https://groups.io/g/eternity2/message/8676 - Source: Le défi sans amorce à 1000 $, quantifié par Peter McGavin, eternity2@groups.io, 2011-06 — https://groups.io/g/eternity2/message/8924 - Source: La revendication « résolu » de Vautrin tombe aux contrôles de pièces dupliquées, eternity2@groups.io, 2014-10 — https://groups.io/g/eternity2/message/9300 - Source: La revendication du 468 de Takahashi refait surface (Dima), eternity2@groups.io, 2017-09 — https://groups.io/g/eternity2/message/9694 - Source: Le contrôle des règles de TopCoder : pièces générées aléatoirement (Peter McGavin), eternity2@groups.io, 2017-10 — https://groups.io/g/eternity2/message/9697 - Source: E2 sans cadre résolu : des milliers de plateaux 480/480 (Peter McGavin), eternity2@groups.io, 2017-11 — https://groups.io/g/eternity2/message/9750 - Source: Pourquoi le 480 sans cadre est disqualifié : bords gris hors du pourtour, eternity2@groups.io, 2017-11 — https://groups.io/g/eternity2/message/9766 - Source: Le « 480 » à jeux mélangés : un E2 + un Clue-1 + un Clue-2 (Peter McGavin), eternity2@groups.io, 2023-10 — https://groups.io/g/eternity2/message/11169 --- En plus de vingt ans, l'archive a accumulé une petite ménagerie de puzzles *presque* Eternity II : les mêmes pièces mais une règle en moins, les mêmes règles mais des pièces différentes, le même plateau mais des pièces donneuses glissées dedans. Chaque variante est un objet d'étude légitime (certaines ont produit des résultats véritablement remarquables), mais chacune est aussi devenue, tôt ou tard, l'adresse de domiciliation d'un score vedette qui n'est pas un record sur le vrai puzzle. Cette page est le guide de terrain : ce qu'est chaque variante, ce qui y a réellement été accompli, et comment la communauté a appris à tenir les scores de variantes hors de la [table des records](/fr/research/records/). ## Pourquoi les variantes comptent : un score ne se compare qu'à l'intérieur d'un même jeu Il y a une seule leçon, et tout le reste de cette page en est une étude de cas : **un score n'est comparable à un autre que si les deux ont été obtenus sur le même jeu de pièces sous le même régime de règles.** Le vrai puzzle est le plateau vendu par Tomy : 256 pièces spécifiques, un cadre 16×16 avec les bords gris sur le pourtour, et la pièce d'amorce fixée en I8 (les quatre autres placements d'indices étaient des aides optionnelles selon les règles du concours, [msg 11046](https://groups.io/g/eternity2/message/11046)). La lignée des records 467 → 468 → 469 → 470 vit tout entière dans ce seul régime, vérifiée plateau par plateau ([msg 10554](https://groups.io/g/eternity2/message/10554)) ; la lignée stricte à cinq indices (meilleure connue : 464) est suivie séparément parce qu'elle constitue un régime *plus difficile*, non un puzzle différent ([Records et solveurs](/fr/research/records/)). Changez le jeu de pièces et « 480 » peut devenir facile. Supprimez la règle du cadre et le 480/480 a effectivement été *atteint*. Supprimez la contrainte d'amorce et le nombre attendu de solutions se multiplie par 784. Aucun de ces nombres ne dit quoi que ce soit sur le 480 officiel, qui reste introuvable. D'où le catalogue ci-dessous, et la mise en quarantaine qui le suit. ## Le catalogue ### La variante Marathon de TopCoder et la revendication du 468 de Takahashi En 2009, TopCoder a organisé un Marathon Match sur un problème de *style* Eternity II. Lorsque Peter McGavin a examiné l'énoncé du concours des années plus tard, il a constaté qu'il utilisait des **pièces générées aléatoirement**, apparemment avec des comptes de couleurs différents de ceux d'E2 et peut-être sans distinction entre les types de bords de bordure et d'intérieur ([msg 9697](https://groups.io/g/eternity2/message/9697)). Chaque test était son propre puzzle. Cela fait de tout score du concours un énoncé sur des instances aléatoires de la *classe* de puzzle, non sur les 256 pièces fixes de Monckton : un jeu différent, aussi semblable que paraisse la feuille de règles. La revendication qui s'y rattache a refait surface en septembre 2017, dans le sillage de la résolution du [benchmark 10×10](/fr/research/build/benchmarks/) de McGavin : Dima a rapporté que « 467 a été battu en 2009 ». Naohiro Takahashi (chokudai), un programmeur compétitif de premier plan, avait tweeté un 468. Dima a déclaré sans détour qu'il n'avait jamais vu la solution et qu'elle n'était pas vérifiée ([msg 9694](https://groups.io/g/eternity2/message/9694), [9696](https://groups.io/g/eternity2/message/9696)). L'examen a suivi le protocole habituel. McGavin, surpris qu'une méthode « simple » de type recherche par faisceau puisse battre tout ce que contenait [l'arsenal de Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/) ([msg 9695](https://groups.io/g/eternity2/message/9695)), a effectué le contrôle des règles ci-dessus et demandé confirmation que le 468 utilisait les pièces originales ([msg 9697](https://groups.io/g/eternity2/message/9697)). David Barr a plaidé le contraire : le tweet dit « Eternity 2 », et le profil de Takahashi lui-même distingue le concours TopCoder du vrai puzzle ([msg 9698](https://groups.io/g/eternity2/message/9698)). Dima s'est engagé à le contacter et à lui demander la solution : « C'est le seul moyen d'en avoir le cœur net » ([msg 9700](https://groups.io/g/eternity2/message/9700)). Aucune résolution n'est jamais apparue dans l'archive, si bien que le statut de la revendication reste indéterminé. Racontée dans son entier : *si* le 468 portait sur la variante TopCoder, il est incomparable aux règles près avec le 467 de Verhaard ; *si* c'était sur les vraies pièces, aucun plateau n'a jamais été produit. Dans les deux cas, il reste hors de la table des records en tant que revendication, non en tant que record. ### E2 sans cadre : le 480/480 de McGavin qui n'est pas une solution Le plus beau non-résultat de l'archive. Fin 2017, Peter McGavin s'est fixé une variante : placer **l'ensemble des 256 vraies pièces** sur le vrai plateau 16×16, mais traiter les bords gris comme des couleurs ordinaires (de sorte que les pièces de bordure migrent dans une bande intérieure) et maximiser les jonctions internes. Le 2 novembre, il a publié 479/480 ([msg 9736](https://groups.io/g/eternity2/message/9736)) ; dix jours plus tard, l'un de ses backtrackers, travaillant à partir de sa 4400ᵉ sous-solution 14×15 environ, a trouvé non pas une mais **des milliers de configurations complètes 480/480** ([msg 9750](https://groups.io/g/eternity2/message/9750), image en [9755](https://groups.io/g/eternity2/message/9755)). Henk van der Griendt a disposé les pièces physiquement et confirmé qu'elles s'assemblaient ([msg 9754](https://groups.io/g/eternity2/message/9754)). La question inévitable est venue : donc vous avez résolu Eternity 2 ? McGavin a été précis. Le plateau totalise 480/480 jonctions internes avec les pièces originales sur le plateau original, mais « les règles du concours disent que les bords gris doivent se trouver autour de la bordure, ce qui n'est manifestement pas le cas. De ce point de vue, l'entrée est disqualifiée » ([msg 9757](https://groups.io/g/eternity2/message/9757), [9766](https://groups.io/g/eternity2/message/9766)). Son propre résumé est le modèle de la façon de rapporter un résultat de variante : « Je me suis fixé mon propre défi de type E2 avec mes propres règles, puis je l'ai résolu » ([msg 9767](https://groups.io/g/eternity2/message/9767)). Il a estimé la difficulté de la variante comparable à celle de construire un 14×14 sans cadre à partir des 196 pièces centrales ([msg 9719](https://groups.io/g/eternity2/message/9719)). Difficile, mais manifestement pas au niveau d'E2 : la contrainte de cadre que la variante supprime est précisément là où se concentre la difficulté du vrai puzzle. ### Jeux de pièces mélangés : les « 480 » à pièces donneuses La troisième famille conserve la règle du cadre et change les pièces. En 2014, McGavin a montré des plateaux 16×16 complets construits à partir de *deux* jeux d'E2, en exploitant les pièces dupliquées ([msg 9305](https://groups.io/g/eternity2/message/9305)), et en octobre 2023 il a construit un plateau complet 480/480 à partir des pièces d'un jeu d'E2, d'un jeu Clue-1 et d'un jeu Clue-2 ([msg 11169](https://groups.io/g/eternity2/message/11169)), dans le défi du maximum de tuiles distinctes de Vlastislav W., un jeu délibéré dont la métrique est le nombre de tuiles officielles *distinctes* qu'un tel plateau peut porter (record : 238, [msg 11167](https://groups.io/g/eternity2/message/11167), [11170](https://groups.io/g/eternity2/message/11170)). Ces constructions ne cachent rien : clairement étiquetées par leurs auteurs, elles sont la raison pour laquelle la table des records porte un badge « variante » sur sa ligne de 2023. L'histoire complète des jeux donneurs (ce qu'étaient les puzzles à indices, et comment leurs pièces ont fini dans ces plateaux) se trouve sur [la page des puzzles à indices](/fr/research/build/clue-puzzles/). ### La variante sans amorce et le défi à 1000 $ En juin 2011, le membre de la liste ebeternity a mis 1000 $ en jeu pour une solution complète d'E2 **sans** la contrainte d'amorce de la pièce 139, valable jusqu'à fin septembre ([msg 8922](https://groups.io/g/eternity2/message/8922)). C'était la première mise en argent d'après-concours sur la table. McGavin a immédiatement quantifié ce que l'assouplissement rapporte : un nombre estimé de **1,1527 × 10⁷ solutions sans la contrainte d'amorce contre 14 702 avec elle**, 784 fois plus d'aiguilles, et pourtant le coût attendu du backtracker par solution bouge à peine (9,2766 × 10⁴² nœuds contre 9,2751 × 10⁴², dans le meilleur ordre de recherche connu) ([msg 8924](https://groups.io/g/eternity2/message/8924)). Moins de contraintes, botte de foin proportionnellement plus grande : la variante est 784× « plus facile » en nombre de solutions et essentiellement inchangée en quantité de travail. Personne n'a réclamé l'argent. Le seul « solve » à avoir atteint le fil de discussion était une revendication de 480 de seconde main promptement qualifiée de bidon, donnant lieu au résumé par Johannes Lindé d'une décennie de telles revendications : les revendiquants deviennent « assez indignés (ou silencieux) dès qu'on demande une preuve » ([msg 8951](https://groups.io/g/eternity2/message/8951), [8952](https://groups.io/g/eternity2/message/8952)). ### Un objectif différent : le plus de pièces placées, zéro conflit Toute variante ne change pas les pièces ou le cadre. Certaines changent la *règle de score*, et l'exemple le plus net est l'objectif du placement maximal sans conflit : au lieu de compter les bords appariés sur un plateau complet, on compte le plus grand nombre de pièces qu'on peut placer de sorte que **chaque** pièce placée s'accorde avec tous ses voisins, en laissant des trous plutôt que des désaccords. Le score est « pièces placées », non « bords appariés », et les deux ne sont pas comparables : un plateau avec une poignée de trous ne dit rien de la façon dont un plateau complet issu de la même recherche serait noté. La frontière ici est ancienne et étroite, et elle appartient toujours à Louis Verhaard. Son plateau « Only seven holes » de vers 2008 place **249 des 256** pièces sans conflit, les sept trous regroupés dans la bande supérieure (rangées 1 à 4). En juin 2026, Laurent Zamofing a atteint **248**, à un de lui, en recombinant les plateaux à 467 bords publiés par la communauté comme donneurs pour le croisement ([msg 11890](https://groups.io/g/eternity2/message/11890), [11901](https://groups.io/g/eternity2/message/11901)). Ce qui est frappant, c'est que les deux plateaux atteignent une *impasse locale prouvée* à leur score : les sept trous de Verhaard ne peuvent pas être comblés par les sept pièces restantes, et libérer un voisinage de rayon 6 autour d'eux n'atteint jamais 250. Que les trous résiduels tombent toujours dans la même bande supérieure, sous un objectif qui n'a rien à voir avec le compte de bords, constitue à soi seul une petite découverte, et c'est de nouveau [la géométrie des désaccords](/fr/research/why/mismatch-geometry/) : les dégâts s'accumulent contre le bord sur lequel la recherche se termine, quel que soit ce qu'elle optimise. ## La quarantaine des revendications Les variantes sont une façon dont naît un faux « record » ; l'autre est une revendication sans plateau attaché. La réponse de la communauté aux deux a mûri en un protocole, et son histoire vaut d'être racontée parce que les revendications mises en quarantaine circulent encore. **La forme la plus ancienne : l'avertissement sur les jeux fantômes (2007).** Quelques jours après le lancement, Sergio Demian Lerner a mis la liste en garde contre les « jeux fantômes » : accepter le benchmark « aléatoire » de style E2 d'un inconnu pouvait signifier résoudre à son insu un réencodage isomorphe du vrai puzzle, et livrer à l'inconnu une solution valant 2 M$ ([msg 1210](https://groups.io/g/eternity2/message/1210)). La communauté a adopté la pratique de publier les benchmarks avec leur provenance et leurs solutions connues ([msg 1213](https://groups.io/g/eternity2/message/1213)). L'intuition se généralise : *un jeu de pièces que vous ne pouvez pas vérifier est une revendication que vous ne pouvez pas noter*. L'examen des jeux faisait partie de la culture avant qu'aucun faux célèbre n'arrive. **Le 471 qui n'a jamais été sauvegardé (2009).** Un matin, Dominique Schaltz a rapporté qu'E2Lab avait affiché pendant la nuit une boîte de message indiquant 471, mais que le score n'apparaissait pas sur sa grille et que la configuration n'avait apparemment jamais été sauvegardée ([msg 7284](https://groups.io/g/eternity2/message/7284)). En quelques semaines, cela a résonné à travers la liste comme « quelqu'un a touché 471 » ([msg 7317](https://groups.io/g/eternity2/message/7317), [7353](https://groups.io/g/eternity2/message/7353)). Aucun plateau n'a jamais existé. L'épisode est l'illustration la plus nette de la raison pour laquelle la règle est *un plateau ou ça n'a pas eu lieu* : un popup logiciel rapporté fidèlement, une fois détaché de ses réserves, a circulé comme un record. **La résolution à la main ≥472 (2010).** Faruk Barber a rapporté avoir complété tout le plateau à la main sans aucune des pièces d'indice sur leurs positions ; Henk van der Griendt a calculé que la revendication vaudrait au moins 472 après avoir échangé l'amorce pour la mettre en conformité ([msg 7383](https://groups.io/g/eternity2/message/7383), [7385](https://groups.io/g/eternity2/message/7385)). Al Hopfer a qualifié cela de « tout simplement ridicule » : un authentique 472 écraserait le 467 connu ([msg 7427](https://groups.io/g/eternity2/message/7427)). Aucune preuve n'a jamais été publiée ; le revendiquant proposait simultanément ses puzzles à indices à la vente ([msg 7395](https://groups.io/g/eternity2/message/7395)). **L'éclosion 476-puis-480 (2011).** En janvier 2011, Alain Bidon a revendiqué un 476/480 obtenu sans la pièce d'amorce en place ; le message d'origine manque dans l'export de l'archive et ne survit qu'à travers les réponses ([msg 8247](https://groups.io/g/eternity2/message/8247)). La liste l'a aussitôt renoté selon les règles (au mieux 472 sans l'amorce, 468 garanti après mise en conformité). En février, la revendication avait grossi en de multiples **480** sans indice ([msg 8636](https://groups.io/g/eternity2/message/8636)) et s'est heurtée à ce qu'un membre a appelé « le bon vieux test à connaissance nulle ». Les deux exigences de Brendan Owen dans ce fil restent le modèle du genre : « il y a un bug dans votre programme. Placez réellement les vraies pièces » ([msg 8670](https://groups.io/g/eternity2/message/8670)), et « pourriez-vous s'il vous plaît publier la grille des identifiants de pièces » ([msg 8676](https://groups.io/g/eternity2/message/8676)) ; Bruce l'a rendu concret : il suffit de retourner chaque pièce et de publier la liste 16×16 des numéros inscrits au dos ([msg 8681](https://groups.io/g/eternity2/message/8681)). Aucune grille n'est jamais apparue. À la même saison, une annonce anonyme de « nouvel algorithme » a été accueillie par l'autre défi habituel : le prouver en résolvant [le benchmark 10×10 sans indice de Brendan](/fr/research/build/benchmarks/) ([msg 8262](https://groups.io/g/eternity2/message/8262), [8264](https://groups.io/g/eternity2/message/8264)). **L'affaire Vautrin (2014) : le protocole fonctionnant de bout en bout.** Nicolas Vautrin a d'abord revendiqué que son programme pouvait prouver qu'E2 n'a *aucune* solution, s'est rétracté (un bug), puis quelques jours plus tard a publié « eternity2 résolu ;) » tout en retenant la solution à cause d'un prix ([msg 9280](https://groups.io/g/eternity2/message/9280), [9286](https://groups.io/g/eternity2/message/9286), [9291](https://groups.io/g/eternity2/message/9291)). Cette fois un artefact vérifiable existait, une solution revendiquée à l'un des benchmarks de Brendan, et la vérification l'a tué en quelques jours : l'éditeur de Conny Öström y a trouvé **115 pièces dupliquées** ([msg 9300](https://groups.io/g/eternity2/message/9300)), McGavin a exhibé une pièce utilisée cinq fois ([msg 9301](https://groups.io/g/eternity2/message/9301)), Arnaud Carré a identifié le bug de comptabilité exact ([msg 9308](https://groups.io/g/eternity2/message/9308)), et Vautrin a concédé ([msg 9303](https://groups.io/g/eternity2/message/9303)). Personne n'a eu à faire confiance à qui que ce soit : la grille était publiée, donc la grille pouvait être vérifiée. Le schéma commun à ces cinq histoires est le véritable savoir institutionnel de la communauté. Les revendications meurent ou survivent sur des artefacts (une grille d'identifiants de pièces, un benchmark public résolu, une somme de contrôle), jamais sur la réputation, l'enthousiasme ou la plausibilité. Le 471, le ≥472 et les 476/480 ne doivent jamais entrer dans la table des records ; le 468 de Takahashi attend dehors qu'un plateau se présente ; et l'épisode Vautrin montre la même mécanique dissiper une erreur authentique en quatre jours. ## Comment énoncer un score correctement Distillée des vingt années ci-dessus, la liste de contrôle que l'archive fait respecter de fait. Un score ne signifie rien sans les quatre : 1. **Nommez le jeu de pièces.** E2 officiel à 256 pièces ? Un jeu de benchmark de Brendan (lequel) ? Des pièces aléatoires ? Des jeux donneurs mélangés ? Si le jeu est privé ou invérifiable, il ne vaut aucun score ; l'[avertissement sur les jeux fantômes](https://groups.io/g/eternity2/message/1210) porte exactement là-dessus. 2. **Nommez le régime de règles.** Encadré avec les bords gris sur le pourtour ? Amorce seule (la lignée de records 467→470), cinq indices stricts (la lignée du 464), sans amorce (le défi à 1000 $), ou sans cadre ? Les scores ne se transfèrent pas d'un régime à l'autre : 784× plus de solutions, ce n'est toujours pas le même jeu. 3. **Publiez le plateau.** La grille 16×16 des identifiants de pièces avec les rotations : l'exigence de Brendan, le « retournez chaque pièce » de Bruce. Un plateau peut être renoté par quiconque ; un nombre, non. Chaque plateau de [la page des plateaux notables](/fr/research/community/boards/) peut être chargé et renoté bord par bord dans le [visualiseur](/viewer/). 4. **Dites qui et quand, avec un lien.** La table des records ne porte que des entrées avec une source primaire ; les revendications qui ne vivent que dans un popup, un tweet ou un souvenir restent en quarantaine ([Records et solveurs](/fr/research/records/)). Jeu + régime + plateau, ou ça n'a pas eu lieu. ## À lire aussi - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Les quatre puzzles-indices](https://eternity2.dev/fr/research/build/clue-puzzles/) — Tomy a vendu quatre petits puzzles compagnons pour Eternity II : résolvez-en un, soumettez la solution, et le site officiel révélait la position d'une pièce sur le plateau principal. Ce qu'était chaque puzzle, le vérificateur en ligne défaillant, le marché gris d'eBay, pourquoi les puzzles 5 et 6 ne sont jamais venus, et la seconde vie des puzzles-indices comme cas de test pour la théorie des complexes et comme jeux de pièces donneuses. - [Les plateaux marquants](https://eternity2.dev/fr/research/community/boards/) — Les plateaux célèbres d'Eternity II, traités comme des objets d'étude à part entière : le 467 primé de Verhaard, la lignée de records Blackwood jusqu'à 470, le record strict à cinq indices porté à 464, et les plateaux propres à ce projet : qui a trouvé chacun, quand, et ce qui le rend structurellement intéressant. Chaque plateau embarqué s'ouvre dans le visualiseur. --- # Histoire & communauté > Le record et les personnes qui l'ont bâti : deux décennies d'Eternity II racontées comme une histoire, les grilles record elles-mêmes, les détenteurs du record et les théoriciens, la littérature académique, et comment ajouter votre propre travail au wiki. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/community/ - Mise à jour: 2026-07-13 --- Eternity II est une histoire avant d'être un algorithme. Cette section conserve la mémoire de la communauté : comment le record a grimpé, les grilles qui portent la lignée, les personnes qui les ont trouvées, les articles écrits en chemin, et comment ajouter ce que vous savez.
- [Histoire : les grandes étapes](/fr/research/history/) — Toute l'histoire d'un coup d'œil : une chronologie parcourable des tournants, de la liste de diffusion fondée en 2000 au record de 470 qui tient toujours. - [La traque, en intégralité](/fr/research/community/hunt/) — Le récit détaillé en deux parties : l'ère fondatrice (2000-2009) et la lignée moderne du record (2009-2026), avec les messages qui attestent chaque tournant. - [Records & solveurs](/fr/research/records/) — La chronologie du record et les moteurs qui l'ont établie : qui a atteint 470/480, et ce que ces grilles révèlent sur le mur. - [Les grilles marquantes](/fr/research/community/boards/) — La lignée du record racontée à travers les grilles elles-mêmes : le 467 de Verhaard, la montée jusqu'à 470, le record strict à cinq indices, chacune avec ses arêtes non concordantes marquées et ouvrable dans la visionneuse. - [Qui est qui](/fr/research/people/) — Les personnes derrière deux décennies de recherche (fondateurs, détenteurs du record, théoriciens), avec ce que chacun a apporté et les messages qui l'attestent. - [Articles](/fr/research/papers/) — La littérature académique sur Eternity II et l'appariement d'arêtes, classée selon son utilité réelle pour qui construit un solveur. - [Contribuer](/fr/research/contribute/) — Comment enrichir le wiki : les sources qu'il tient pour fiables, la façon dont les découvertes sont créditées, et où envoyer ce que vous savez.
## L'archive de la communauté Une grande partie de ce sur quoi s'appuie ce wiki réside, à l'état brut, dans la [zone Fichiers de groups.io](https://groups.io/g/eternity2/files) : environ 300 Mo accumulés sur deux décennies. Il vaut la peine de savoir ce qui s'y trouve.
- [L'archive des articles](https://groups.io/g/eternity2/files/00_Eternity2_articles_papers_presentations_books) — Quinze PDF datés, de 2007 à 2020 : les preuves de complexité, les articles SAT/CSP et MILP, des thèses, et une bibliographie tenue à jour. La colonne vertébrale de notre page [Articles](/fr/research/papers/). - [Théorie du puzzle & preuves](https://groups.io/g/eternity2/files/Puzzle%20Theory) — Seize autres : les bornes de transition de phase, la preuve de faisabilité par arête partagée, des notes de séminaire françaises, et des travaux transversaux issus de la littérature SAT et physique. - [Des décennies de solveurs](https://groups.io/g/eternity2/files) — Des dizaines de dossiers de contributeurs (Brendan, Guenter, Peter McGavin, et bien d'autres) : backtrackers, encodeurs SAT et de couverture exacte, tentatives GA et GPU, avec le code source, la plupart antérieurs à ce wiki. - [Bases de données](https://groups.io/g/eternity2/databases) — La tabulation des ["estimations du backtracker"](/fr/research/why/complex-theory/) de Brendan Owen (les tailles d'arbre et les nombres de solutions que vous retrouverez intégrés dans les pages de théorie) et les classements du record, le tout interrogeable.
Des puzzles d'exemple, des jeux de référence et des images de grilles s'y trouvent aussi. Si vous découvrez quelque chose qui mérite une page, [dites-le](/fr/research/contribute/) et cela pourra en devenir une. ## Pages de cette section - [La traque, une histoire (partie I : 2000-2009)](https://eternity2.dev/fr/research/community/hunt/) — L'histoire de la communauté, d'une liste de diffusion fondée sept ans avant que le casse-tête n'existe jusqu'au prix d'examen de 10 000 $ remporté sous un nom d'emprunt, chaque événement rattaché à son message d'origine. Partie I d'une chronique en cours. - [La traque, une histoire, partie II : 2009-2026](https://eternity2.dev/fr/research/community/hunt-part-2/) — Dix-sept ans après le prix : le concours s'éteint avec sa solution enfermée dans un coffre, 467 tient une décennie, l'archive survit à la fermeture de Yahoo à quelques jours près, puis un inconnu venu de Reddit réécrit le livre des records. Chaque événement est rattaché à son message d'origine. - [Les plateaux marquants](https://eternity2.dev/fr/research/community/boards/) — Les plateaux célèbres d'Eternity II, traités comme des objets d'étude à part entière : le 467 primé de Verhaard, la lignée de records Blackwood jusqu'à 470, le record strict à cinq indices porté à 464, et les plateaux propres à ce projet : qui a trouvé chacun, quand, et ce qui le rend structurellement intéressant. Chaque plateau embarqué s'ouvre dans le visualiseur. --- # Les plateaux marquants > Les plateaux célèbres d'Eternity II, traités comme des objets d'étude à part entière : le 467 primé de Verhaard, la lignée de records Blackwood jusqu'à 470, le record strict à cinq indices porté à 464, et les plateaux propres à ce projet : qui a trouvé chacun, quand, et ce qui le rend structurellement intéressant. Chaque plateau embarqué s'ouvre dans le visualiseur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/community/boards/ - Mise à jour: 2026-07-02 - Source: msg 6337 : le résultat du contrôle de janvier 2009, 10 000 $ à Anna Karlsson de Lund pour 467/480 — https://groups.io/g/eternity2/message/6337 - Source: msg 10032 : le 468 de Blackwood parvient à la liste depuis Reddit — https://groups.io/g/eternity2/message/10032 - Source: msg 10045 : McGavin annonce le 469 — https://groups.io/g/eternity2/message/10045 - Source: msg 10074 : le 469 de Fernandez obtenu par échange d'une seule pièce — https://groups.io/g/eternity2/message/10074 - Source: msg 10117 : le 470 de Blackwood — https://groups.io/g/eternity2/message/10117 - Source: msg 11401 : Bucas égale le 470 — https://groups.io/g/eternity2/message/11401 - Source: msg 11074 : le 460 strict à cinq indices de Gauthier (le record 2023-2026) — https://groups.io/g/eternity2/message/11074 - Source: Le 464 de Riotte, le nouveau record strict à cinq indices (groups.io, juillet 2026) — https://groups.io/g/eternity2/message/11919 - Source: e2.bucas.name (Jef Bucas), le visualiseur communautaire où ces plateaux ont d'abord été partagés — https://e2.bucas.name --- L'histoire d'Eternity II se raconte d'ordinaire à travers les personnes et les solveurs. Cette page la raconte à travers les plateaux eux-mêmes : la poignée d'objets qui portent toute la lignée des records, quel qu'en soit l'auteur. Chaque entrée indique qui a annoncé le plateau et où, ainsi que ce que l'on sait publiquement de sa structure. Tous les plateaux présentés ici sont embarqués avec ce site : cliquez sur n'importe quel aperçu pour le charger dans le [visualiseur](/viewer/) et le réévaluer arête par arête. La chronologie complète et l'historique des méthodes vivent sur la [page des records](/fr/research/records/) ; ceci en est la galerie. ## La lignée des records : 467 → 468 → 469 → 470 ### Le 467 de Verhaard (2008) : le plateau primé Le plateau qui a remporté le seul prix en argent jamais versé par Eternity II. Le [solveur distribué *eii*](/fr/research/lab/experiments/louis-verhaard/eii/) de Louis Verhaard, diffusé aux volontaires en septembre 2008 avec ces mots, « I am stuck » ([msg 5940](https://groups.io/g/eternity2/message/5940)), avait trouvé un 467/480 plus de 40 fois, par des utilisateurs différents, au moment où il l'a documenté ([msg 6275](https://groups.io/g/eternity2/message/6275)). Au contrôle du 31 décembre 2008, l'entrée, soumise sous le nom d'Anna Karlsson de Lund (le foyer de Verhaard), a emporté le prix de 10 000 $ récompensant la meilleure solution partielle ([msg 6337](https://groups.io/g/eternity2/message/6337), le groupe reconnaissant aussitôt la gagnante au [msg 6349](https://groups.io/g/eternity2/message/6349)). Deux notes de bas de page ultérieures changent la lecture de ce plateau. En relisant le récit de Verhaard lui-même, Jef Bucas a remarqué que le 467 avait été obtenu sous un handicap que l'auteur s'était imposé : Verhaard avait mal interprété les règles et restreint le type de plateau qu'il s'autorisait à soumettre ([msg 10582](https://groups.io/g/eternity2/message/10582)). Et dès 2023, le score était devenu une cible d'étalonnage : « la semaine dernière j'ai trouvé une trentaine de 467. Je m'en sers comme repère pour calibrer le code que je fais tourner » ([msg 11001](https://groups.io/g/eternity2/message/11001)). Il n'en a pas moins tenu comme record pendant douze ans. > **[Interactive: CommunityBoard]** Rendered on the canonical page (link above); not shown in this markdown export. Le visualiseur embarque aussi, dans son menu de plateaux, trois 467 frères (Verhaard 467a, 467b, 467c) issus de la même campagne. ### Le 468 de Blackwood (2020) : le plateau venu de l'extérieur La première avancée au-delà de 467 en douze ans est venue de l'extérieur de la communauté : un message Reddit de Joshua Blackwood, alors inconnu de la liste de diffusion, relayé au [msg 10032](https://groups.io/g/eternity2/message/10032). Un plateau à seulement 12 ruptures, 468/480. Bucas l'a vérifié, l'a ajouté au visualiseur, et a transmis la revendication stupéfiante selon laquelle l'auteur pouvait « trouver un 468 tous les 4 jours » ([msg 10033](https://groups.io/g/eternity2/message/10033)). Quelques jours plus tard, Blackwood a ouvert le code [du solveur qui l'avait trouvé](/fr/research/lab/experiments/joshua-blackwood/solver/) ([msg 10037](https://groups.io/g/eternity2/message/10037)). Tous les plateaux qui suivent remontent à ce code. > **[Interactive: CommunityBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ### Le 469 de McGavin (2020) : le plateau plafond « Votre solveur est fantastique !! Je l'ai fait tourner quelques jours sur environ deux cents cœurs et j'ai décroché le jackpot. Nouveau record de 469 ! Seulement 11 ruptures ! » Ainsi écrivait Peter McGavin, faisant tourner le solveur fraîchement publié par Blackwood ([msg 10045](https://groups.io/g/eternity2/message/10045)). Blackwood a expliqué dans le même fil la discipline de rupture du solveur : les ruptures ne se touchent jamais, si bien que ce 469 équivaut à une partielle de 249 pièces avec 7 trous ([msg 10051](https://groups.io/g/eternity2/message/10051)). Structurellement, ce plateau porte une signature que l'on peut vérifier soi-même : ses onze arêtes non appariées se logent toutes dans les cinq premières rangées, laissant une dalle de onze rangées localement irréprochable : les dégâts sont balayés contre le bord où la recherche s'est terminée. Cette géométrie, et la raison pour laquelle elle bascule sur les plateaux construits dans l'autre sens, est analysée dans [Où vivent les défauts](/fr/research/why/mismatch-geometry/). > **[Interactive: CommunityBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ### La vague des 469 (octobre-novembre 2020) Bucas a publié ses deux premiers 469 en octobre ([msg 10052](https://groups.io/g/eternity2/message/10052), « Here are 2 other 469 »), a porté l'algorithme de Blackwood en C, en doublant à peu près sa vitesse ([msg 10065](https://groups.io/g/eternity2/message/10065)), et le flot n'a pas tari : les plateaux c à g en novembre, du [msg 10067](https://groups.io/g/eternity2/message/10067) (« Another one yay \o/ ») au [msg 10078](https://groups.io/g/eternity2/message/10078), publié en même temps que le portage ouvert, *libblackwood*. Les sept figurent dans le menu de plateaux du visualiseur sous les noms Bucas 469a-g. L'exception, c'est celui de Carlos Fernandez. Il a passé le 469 de McGavin à un programme d'échange de pièces de sa conception et en a trouvé un autre 469 ne différant que d'une seule pièce ([msg 10074](https://groups.io/g/eternity2/message/10074)), preuve, selon les mots de Bucas lorsqu'il l'a ajouté au visualiseur, que « même à 469, il reste encore un tout petit peu de souplesse » ([msg 10075](https://groups.io/g/eternity2/message/10075)). Cette souplesse est mince : c'est exactement le genre d'égalité isolée que prédit l'analyse de rigidité ci-dessous, et non un chemin vers le haut. ### Les 470 (2021 et 2024) : le plafond actuel Blackwood a clos son propre arc par un message presque sans paroles : une URL de visualiseur, une liste de pièces (470/480, 10 ruptures) et cette seule ligne, « I haven't physically put it together yet, but I found one! » ([msg 10117](https://groups.io/g/eternity2/message/10117)). Il a confirmé plus tard qu'il l'avait trouvé avec exactement le code du dépôt public ([msg 10161](https://groups.io/g/eternity2/message/10161)), avec le calendrier réaccordé qu'il avait publié à l'avance, puis s'est arrêté : « Je n'ai pas écrit une ligne de code ni fait tourner le moindre algorithme depuis que j'ai trouvé un 470 » ([msg 10185](https://groups.io/g/eternity2/message/10185)). > **[Interactive: CommunityBoard]** Rendered on the canonical page (link above); not shown in this markdown export. Le score a été égalé une fois, pas battu. En décembre 2024, Bucas a relancé « quelques threads du code de Joshua » et un autre 470 est apparu ([msg 11401](https://groups.io/g/eternity2/message/11401)) ; Fernandez a remarqué que ses trois motifs de bordure non appariés permettaient un réarrangement et a publié un 470b ([msg 11403](https://groups.io/g/eternity2/message/11403)). La classe des 470 reste un monopole du solveur de Blackwood, et 470 demeure le plafond : « Personne n'en est même proche… Le meilleur résultat à ce jour est la solution partielle de Joshua Blackwood, 470/480 arêtes appariées » ([msg 11343](https://groups.io/g/eternity2/message/11343)). > **[Interactive: CommunityBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ## Ce que les plateaux records ont en commun Trois faits publiquement documentés valent pour toute la lignée 468/469/470. **Même régime d'indices.** Tous placent la pièce de départ obligatoire à son emplacement officiel et aucune des quatre pièces indices facultatives au sien. La communauté l'a vérifié pour le 470 ([msg 10554](https://groups.io/g/eternity2/message/10554)), et Blackwood a confirmé qu'il disposait des tuiles indices et avait délibérément choisi de ne pas les utiliser ([msg 10185](https://groups.io/g/eternity2/message/10185)). Sous les règles originales du concours, seule la pièce de départ était obligatoire : ces plateaux étaient donc éligibles au prix en l'état. **Défauts en bandes.** Les quelques arêtes non appariées ne sont pas dispersées ; elles se tassent en une seule bande de rangées contre le bord où la recherche s'est terminée. [Où vivent les défauts](/fr/research/why/mismatch-geometry/) évalue les plateaux réels en direct et met la bande en évidence ; on y voit aussi les plateaux de ce projet exhiber la même bande, en miroir. **Rigidité locale.** Aucun de ces plateaux n'est une quasi-solution en attente d'un polissage. [Le mur de rigidité](/fr/research/why/rigidity-wall/) recourt à des résolutions exactes en programmation en nombres entiers pour prouver que, sur les plateaux records, libérer des régions entières et les remplir de nouveau de façon optimale rend le même agencement : les meilleurs plateaux siègent au fond de leur propre vallée. Le 469 de Fernandez, obtenu par échange d'une seule pièce, est l'exception qui confirme la règle : une égalité voisine, jamais une marche vers le haut. ## La lignée stricte à cinq indices : du 460 de Gauthier au 464 de Riotte La plupart des plateaux records publiés ne conservent que la pièce de départ obligatoire. En mars 2023, un fil a posé la question plus exigeante : quel est le meilleur plateau qui respecte **les cinq** indices officiels ([msg 11037](https://groups.io/g/eternity2/message/11037)) ? Une échelle a été gravie en quelques jours : 412, puis 452 et 457 (Carlos Fernandez), puis 453/455/456/458 (David Barr), s'arrêtant au **460 de Bruno Gauthier**, « réalisé avec mon propre programme et l'Eternity II Editor » ([msg 11074](https://groups.io/g/eternity2/message/11074)) ; McGavin l'a converti au format partagé du visualiseur ([msg 11081](https://groups.io/g/eternity2/message/11081)). Ce 460 a tenu plus de trois ans. Fin juin 2026, un nouveau fil, « Record of Eternity2 with 5 hints? », a rouvert la lignée : **Benjamin Riotte** a publié un 461, puis une vague de résultats grimpant jusqu'à **464/480 (seulement 16 arêtes rompues)**, la première avancée sur le record strict depuis 2023 ([groups.io msg 11919](https://groups.io/g/eternity2/message/11919)). **Igor Pejic** a atteint la même plage 463-464 de façon indépendante dans le même fil, en s'appuyant sur ce qu'il a décrit comme un « algorithme DFS de Blackwood modifié ». Tous ces plateaux respectent les cinq indices à leurs cellules officielles (départ n°139, indices n°208, n°255, n°181, n°249). La lignée stricte importe en raison de ce qu'impliquent les cinq indices : l'estimation communautaire du nombre de solutions, les cinq indices placés, est d'environ 0,00000004 (une cible pratiquement unique), contre à peu près 14 702 « solutions » attendues avec la seule pièce de départ ([msg 11193](https://groups.io/g/eternity2/message/11193)). Un plateau à cinq indices joue exactement le jeu que les concepteurs ont défini. Le 464 se tient seize arêtes en dessous de la solution complète, et cet écart est lui-même une donnée. > **[Interactive: BoardsFoundGallery]** Rendered on the canonical page (link above); not shown in this markdown export. ## Les plateaux de ce projet Les expériences propres à ce site ont produit quatre plateaux qui méritent d'être conservés, étiquetés pour ce qu'ils sont : des expériences plusieurs marches sous la lignée communautaire, et documentées de bout en bout. Chacun renvoie à l'expérience qui l'a trouvé ; chaque score est recalculé à partir des arêtes propres au plateau. ### PALIMPSEST (463) Le meilleur du projet, trouvé en lisant tout le corpus des plateaux forts pour séparer la vraie structure partagée des mauvaises habitudes partagées, puis en attaquant les pièges. Le récit complet se trouve dans [l'expérience PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/). > **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ### KEYRING (460) Construit à partir de rien en laissant trois signaux appris voter sur chaque placement, atteignant 460 dans une famille de plateaux qu'aucune recherche antérieure ici n'avait su percer ; voir [KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/). Ses défauts se regroupent en bande dans les rangées du bas, l'image en miroir du 469 de McGavin. Cette empreinte liée à l'ordre de balayage est expliquée dans [Où vivent les défauts](/fr/research/why/mismatch-geometry/). > **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ### PRIOR (460) À partir de rien, plus destruction-réparation, en départageant les égalités de construction par l'endroit où les pièces ont tendance à se poser dans les plateaux forts (voir [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/)). > **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ### GAUNTLET (458) La même [recherche en faisceau](/fr/research/build/construct/beam-search/) lancée sur neuf ordres de balayage pour qu'elle atterrisse dans des régions différentes de l'espace des plateaux ; l'ordre en zigzag a trouvé ce 458. Le compte rendu complet est dans [GAUNTLET](/fr/research/lab/experiments/raphael-anjou/pipelines/gauntlet/). > **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ## À lire aussi - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. --- # La traque, une histoire (partie I : 2000-2009) > L'histoire de la communauté, d'une liste de diffusion fondée sept ans avant que le casse-tête n'existe jusqu'au prix d'examen de 10 000 $ remporté sous un nom d'emprunt, chaque événement rattaché à son message d'origine. Partie I d'une chronique en cours. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/community/hunt/ - Mise à jour: 2026-07-02 - Source: L'ultimatum de Monckton sur le copyright et la disqualification de Brendan Owen (message groups.io 1342) — https://groups.io/g/eternity2/message/1342 - Source: Brendan Owen dérive la conception 17+5 comme le casse-tête le plus difficile possible (message groups.io 1947) — https://groups.io/g/eternity2/message/1947 - Source: eternity2.net ferme : 1,6 TFlops, 10^19 opérations, aucune solution (message groups.io 3511) — https://groups.io/g/eternity2/message/3511 - Source: Louis Verhaard publie le solveur eii : « I am stuck » (message groups.io 5940) — https://groups.io/g/eternity2/message/5940 - Source: Premier résultat d'examen : 10 000 $ à Anna Karlsson de Lund, score 467 (message groups.io 6337) — https://groups.io/g/eternity2/message/6337 - Source: Wikipédia, « Eternity II puzzle » — https://en.wikipedia.org/wiki/Eternity_II_puzzle --- Eternity II a une histoire officielle (un communiqué de presse, un prix, une échéance) et il en a une véritable, qui s'est déroulée sur une liste de diffusion. Le [groupe eternity2](https://groups.io/g/eternity2) (à l'origine un groupe Yahoo) est l'endroit où le casse-tête a été analysé avant d'exister, numérisé le jour de son lancement, déclaré insoluble en moins de quinze jours, et où la seule somme de prix jamais versée a discrètement été rattachée à l'un des habitués de la liste. Cette page raconte cette histoire à partir de l'archive elle-même : chaque événement renvoie au message où il s'est produit. La partie I couvre de la fondation du groupe jusqu'à la première date d'examen, de 2000 à février 2009. ## Le groupe qui précède son casse-tête (2000-2006) Le fait le plus étrange à propos de la communauté Eternity II est sa date de naissance. Brendan Owen a créé le groupe eternity_two en octobre 2000, six ans et demi avant l'annonce du casse-tête, « because we anticipated a follow up puzzle » à Eternity I ([msg 404](https://groups.io/g/eternity2/message/404)). Les plus anciens messages conservés spéculent sur ce que pourraient être les pièces de la suite, et misent à tort sur des tétraèdres 3D ([msg 8](https://groups.io/g/eternity2/message/8)). Dès 2001, le groupe répétait déjà le problème du concepteur plutôt que celui du solveur : Günter Stertenbrink demandait comment on construirait un casse-tête doté d'un prix colossal et d'une chance d'à peine 1 % d'être résolu en dix ans ([msg 15](https://groups.io/g/eternity2/message/15)), presque exactement le cahier des charges que l'équipe de Christopher Monckton allait plus tard exécuter. Les vétérans d'Eternity I dérivaient là et attendaient : Dave Clark, auteur du solveur distribué ESolve pour E1, a rejoint le groupe en avril 2001 ([msg 21](https://groups.io/g/eternity2/message/21)). Lorsque les premiers comptes rendus de presse sont arrivés en décembre 2005, avec Monckton promettant que la suite exigerait « the lifetime of the Universe » tandis que le co-concepteur Oliver Riordan parlait de « several years », Stertenbrink en a tiré la conclusion qui s'imposait : « So we can conclude, the end of the universe is in several years. » ([msg 34](https://groups.io/g/eternity2/message/34)) ## L'été du lancement (2007) L'annonce est tombée le 22 janvier 2007 : 256 pièces, 2 000 000 $ US pour la première solution correcte, lancement le 28 juillet, et un coup médiatique au London Toy Fair où un homme fort détruisait « the computer containing a solution » ([msg 36](https://groups.io/g/eternity2/message/36)). Cet ordinateur, comme un initié chez le distributeur l'a plus tard admis, ne contenait absolument rien ([msg 148](https://groups.io/g/eternity2/message/148)). Le groupe n'a pas attendu les pièces. En deux jours, il comptait les types de bords sur des photos promotionnelles, et Owen avait dérivé la formule du nombre attendu de solutions qui faisait de la difficulté un paramètre de conception ajustable ([msg 38](https://groups.io/g/eternity2/message/38), [msg 44](https://groups.io/g/eternity2/message/44)). Il a publié un générateur de casse-têtes de type Eternity II ([msg 41](https://groups.io/g/eternity2/message/41)) ; Alan O'Donnell avait le premier solveur fonctionnel une semaine plus tard ([msg 64](https://groups.io/g/eternity2/message/64)). Au 8 juillet, trois semaines avant que quiconque ait touché une vraie pièce, anr_56 avait estimé les comptes de types de bords à partir des photos de lancement et Owen avait fait tourner les chiffres sur cette configuration : environ 10^30 fois plus difficile que les jeux d'essai que le groupe résolvait en quelques minutes. « No one will solve this puzzle », a-t-il conclu ([msg 665](https://groups.io/g/eternity2/message/665)). Puis vinrent les fameuses 48 heures. L'Australie a reçu le casse-tête en premier, et Owen était chez Kmart la veille du lancement, « first one to grab it off their stack » ([msg 1051](https://groups.io/g/eternity2/message/1051)). Il a fait passer les panneaux de pièces dans un programme de vision par ordinateur qu'il avait écrit à l'avance ([msg 789](https://groups.io/g/eternity2/message/789)), a rapporté une distribution des bords « as flat as could be » ([msg 1054](https://groups.io/g/eternity2/message/1054)), et a confirmé les paramètres réels : 5 couleurs de bordure, 17 couleurs intérieures, le pire des scénarios pour le groupe ([msg 977](https://groups.io/g/eternity2/message/977)). Ensuite, après la « nice chat to Mr Monckton » de Dave Clark, il a publié la première estimation du nombre de solutions pour le jeu de pièces réel : environ 5 930 solutions avec l'indice obligatoire, contre le chiffre de Monckton lui-même d'environ 5 millions ([msg 987](https://groups.io/g/eternity2/message/987)). Le casse-tête avait deux jours et sa difficulté était déjà mesurée. La même semaine a fixé les usages de la communauté. Pour vérifier les transcriptions de pièces sans partager de données protégées, les membres ont convergé vers des sommes de contrôle CRC publiées ([msg 1063](https://groups.io/g/eternity2/message/1063)) ; et le nouveau venu Sergio Demian Lerner a mis en garde contre les « jeux fantômes » : le jeu d'essai d'un inconnu pouvait être le vrai casse-tête réencodé, vous incitant à livrer une solution à 2 M$ ([msg 1210](https://groups.io/g/eternity2/message/1210)). ## La course à la théorie (2007-2008) Une semaine après le début d'août, l'inventeur du casse-tête est arrivé en personne ; il venait disqualifier quelqu'un. Postant depuis une adresse Yahoo invérifiable, Christopher Monckton a déclaré détenir le copyright sur les motifs des pièces et que son « web-trawling software » avait signalé le site web de Brendan Owen : Owen, qui visait le prix moindre, était éliminé ([msg 1342](https://groups.io/g/eternity2/message/1342), [msg 1352](https://groups.io/g/eternity2/message/1352), [msg 1358](https://groups.io/g/eternity2/message/1358)). Il est apparu par la suite que le fichier incriminé ne correspondait même pas aux vraies pièces ([msg 1358](https://groups.io/g/eternity2/message/1358)). Des membres ont protesté qu'un compte de forum anonyme ne pouvait guère avoir de poids officiel ; Monckton a persisté ([msg 1374](https://groups.io/g/eternity2/message/1374), [msg 1377](https://groups.io/g/eternity2/message/1377)). Le refroidissement a été réel et durable : un an plus tard, Owen, en tant que modérateur, supprimait encore des tables de données dérivées « to be safe » ([msg 5651](https://groups.io/g/eternity2/message/5651)). C'est dans ce climat qu'Owen, montrant que les statistiques plates des pièces d'E2 tuaient la stratégie qui avait percé Eternity I, a tracé sa ligne rouge : « If we cannot talk about something as fundamental as piece frequencies, then I will give up on this puzzle now » ([msg 1667](https://groups.io/g/eternity2/message/1667), [msg 1694](https://groups.io/g/eternity2/message/1694)). La théorie est venue vite après cela. kubzpa a prouvé par un [argument de parité](/fr/research/build/analysis/parity-arguments/) qu'un score d'exactement 479 (un seul bord non concordant) est impossible ([msg 1640](https://groups.io/g/eternity2/message/1640)) ; gardez cela en tête, car dix-sept mois plus tard cet argument rencontrera un contre-exemple. Owen a ensuite produit le résultat emblématique de la période : en supposant que les concepteurs voulaient le 16×16 le plus difficile possible, avec une distribution plate et environ une solution attendue, le nombre de couleurs intérieures devrait être (196! · 4^196)^(1/392) ≈ 17,14, soit 17 couleurs intérieures et 5 couleurs de bordure. Exactement le vrai casse-tête ([msg 1947](https://groups.io/g/eternity2/message/1947)). La répartition 17+5 n'était pas un coup de malchance ; c'était [une flèche en plein sur le pic de difficulté](/fr/research/why/phase-transition/), et le groupe avait rétro-conçu le ciblage. Les affirmations théoriques étaient confrontées aux comptes de nœuds mesurés sur des [jeux d'essai](/fr/research/build/benchmarks/) partagés. Angel de Vicente, postant sous le pseudonyme Txibilis, a construit la suite standard de plateaux de test de type E2 ([msg 1610](https://groups.io/g/eternity2/message/1610)), et un duel s'est engagé : les [ordres de remplissage](/fr/research/build/backtracking/fill-order/) conçus à la main par Txibilis contre l'optimiseur de stratégie automatisé de doc_s_smith, faisant chuter de plusieurs ordres de grandeur les comptes de nœuds en recherche complète ; un jeu d'essai s'établissait à 89 794 nœuds, battu en deux jours par 85 729 ([msg 2896](https://groups.io/g/eternity2/message/2896), [msg 2928](https://groups.io/g/eternity2/message/2928)). En plein duel, la liste a découvert qui était doc_s_smith : Dietmar Wolz, découvreur de la plupart des solutions connues d'Eternity I ([msg 2972](https://groups.io/g/eternity2/message/2972)). Les estimations ont convergé elles aussi. L'article de kubzpa situait le nombre de solutions près de 15 millions ([msg 3497](https://groups.io/g/eternity2/message/3497)) ; Owen a mesuré la profondeur de branchement de l'arbre de recherche niveau par niveau, trouvant que le compte de nœuds culmine à 161 pièces placées ([msg 3147](https://groups.io/g/eternity2/message/3147)) ; et en avril 2008 il a annoncé avoir « nailed the theory » : un modèle exact de l'arbre de recherche dont les prédictions se superposaient aux courbes empiriques, vérifié de manière indépendante par Louis Verhaard : de l'ordre de 10^27 années-CPU par solution ([msg 5197](https://groups.io/g/eternity2/message/5197), [msg 5193](https://groups.io/g/eternity2/message/5193), [msg 5209](https://groups.io/g/eternity2/message/5209)). Le théoricien en chef du groupe a agi sur la foi de ses propres chiffres : il chassait désormais le score le plus haut, pas 480 ([msg 4996](https://groups.io/g/eternity2/message/4996)). ## Grosses machines et syndicats Si un seul ordinateur était sans espoir, peut-être que des milliers ne l'étaient pas. eternity2.net de Dave Clark, un [solveur distribué](/fr/research/build/faster/distributed-solving/) basé sur BOINC, a été lancé avec le casse-tête en juillet 2007 ([msg 756](https://groups.io/g/eternity2/message/756)) et comptait 1 300 membres en un mois, dont 160 aux États-Unis, où le casse-tête n'était même pas encore sorti ([msg 2122](https://groups.io/g/eternity2/message/2122), [msg 2132](https://groups.io/g/eternity2/message/2132)). Le projet a soumis à Tomy un partiel à 462 bords, puis 463 ([msg 2663](https://groups.io/g/eternity2/message/2663)), un nombre qui allait faire office de plafond public du score de la communauté pendant plus d'un an. Un « Eternity 2 Syndicate » de partage des gains a suivi, rémunérant les membres au prorata des placements apportés ([msg 3021](https://groups.io/g/eternity2/message/3021)). Cela a duré cinq mois. En décembre 2007, Clark a fermé eternity2.net, publiant le décompte final : plus de 1,6 TFlops de puissance de calcul agrégée, plus de 10^19 opérations CPU, meilleurs scores dans les milieux 460. Son verdict : une solution par force brute « was always clearly going to be impossible » ([msg 3511](https://groups.io/g/eternity2/message/3511)). La liste a immédiatement engendré des fils intitulés « Eternity2 Must Have Been Solved » ; il ne l'avait pas été ([msg 3554](https://groups.io/g/eternity2/message/3554)). Les fichiers du projet ont été conservés dans l'archive du groupe ([msg 3633](https://groups.io/g/eternity2/message/3633)), et Clark a ouvert le code source de son solveur de recherche ([msg 3716](https://groups.io/g/eternity2/message/3716)). Il a aussi laissé à l'archive sa meilleure source primaire sur la création du casse-tête : un appel téléphonique avec Monckton, qui décrivait des juges saisissant de l'entropie dans un générateur bâti par les vainqueurs d'Eternity I, Alex Selby et Oliver Riordan, la solution imprimée une seule fois puis mise au coffre ([msg 4177](https://groups.io/g/eternity2/message/4177)), « whilst all parties were out of the room », selon la formule du dépliant du distributeur Tomy qu'il avait posté au lancement ([msg 901](https://groups.io/g/eternity2/message/901)). Le flanc des méthodes exactes ne s'en est pas mieux tiré. Un [encodage SAT](/fr/research/build/exact/sat-csp-encodings/) publié du casse-tête complet s'accompagnait d'un appel à quiconque posséderait une machine dotée de plus de 16 Go de RAM ([msg 4084](https://groups.io/g/eternity2/message/4084)) ; la programmation en nombres entiers mourait aux plateaux 8×8 ([msg 5602](https://groups.io/g/eternity2/message/5602)). La vitesse brute continuait de grimper : istarinz a franchi les 100 millions de placements par seconde sur plusieurs cœurs ([msg 5804](https://groups.io/g/eternity2/message/5804)), puis a mesuré 558 millions sur un Core i7 flambant neuf ([msg 6212](https://groups.io/g/eternity2/message/6212)). Mais face à des espaces de recherche mesurés en puissances de quarante, le débit était une erreur d'arrondi. ## La route vers 467 (2008) Les scores avaient grimpé tout du long : 410 pour Pierre Schaus dans les premières semaines ([msg 1568](https://groups.io/g/eternity2/message/1568)), 453 pour philippe.dupond ([msg 3998](https://groups.io/g/eternity2/message/3998)), 461 pour e2dude ([msg 4440](https://groups.io/g/eternity2/message/4440)), avec 463 comme « current known high » ([msg 5688](https://groups.io/g/eternity2/message/5688)). Les méthodes ont changé de nature à la mi-2008 : Schaus a publié son article de programmation par contraintes, dont le coup clé (retirer un ensemble de pièces non adjacentes et les replacer *de façon optimale* en résolvant un problème d'affectation) est devenu le moteur de l'hybride d'antminder, qui atteignait un 462 par jour en moyenne ([msg 5589](https://groups.io/g/eternity2/message/5589), [msg 5601](https://groups.io/g/eternity2/message/5601)). Pendant ce temps, deux personnes avaient discrètement dépassé le plafond. Dans un long échange en août, Max rapportait aller « beyond the 'don't-talk-about-limit' quite easily » ; Louis Verhaard (« Max, you are really a dangerous man! ») confrontait ses méthodes aux siennes et découvrait qu'ils avaient convergé vers la même signature heuristique, promettant une divulgation complète « after new-year », c'est-à-dire après la date d'examen du 31 décembre ([msg 5767](https://groups.io/g/eternity2/message/5767), [msg 5780](https://groups.io/g/eternity2/message/5780)). Verhaard ne révélerait que la géométrie : ses meilleurs ordres de remplissage à haut score ressemblaient à un « peigne » : la plupart des rangées balayées horizontalement, le reste verticalement ([msg 6112](https://groups.io/g/eternity2/message/6112)). Puis, le 22 septembre 2008, Verhaard a publié [son solveur](/fr/research/lab/experiments/louis-verhaard/eii/) que chacun pouvait faire tourner sur fingerboys.se : « This because I am stuck and my only hope to improve my best score is by using brute force » ([msg 5940](https://groups.io/g/eternity2/message/5940)). Tout prix serait partagé 50-50 avec l'utilisateur au meilleur score. antminder, dont le propre programme mettait une semaine pour atteindre 463, était sans détour : eii « completely blows it away » ([msg 5950](https://groups.io/g/eternity2/message/5950)). Le prix lui-même relevait encore du folklore (le règlement ne promettait qu'un « lesser prize » discrétionnaire) jusqu'à ce que Max retrace le chiffre de 10 000 $ dans une interview de Monckton sur le site officiel français ([msg 6073](https://groups.io/g/eternity2/message/6073)). Verhaard, trois mois avant de le remporter, affirmait s'en moquer : il faisait cela pour l'honneur, et seulement pour cette année-là ([msg 6072](https://groups.io/g/eternity2/message/6072)). Le même automne, les résolveurs à la main ont fait surface : Christine Raisin descendue à 21 pièces restant dans le couvercle de la boîte ([msg 5935](https://groups.io/g/eternity2/message/5935)), Verhaard triant les pièces par motif avec sa fille de sept ans et organisant une mini-compétition de résolution à la main, les fils inventant des surnoms comme « pink swords » et « kipper ties » pour les motifs ([msg 5933](https://groups.io/g/eternity2/message/5933), [msg 5929](https://groups.io/g/eternity2/message/5929), [msg 5958](https://groups.io/g/eternity2/message/5958), [msg 5959](https://groups.io/g/eternity2/message/5959)). La liste n'a jamais été qu'un banc d'essai de solveurs. ## La farce de la date d'examen (décembre 2008 → janvier 2009) À l'approche de la première date d'examen, la communauté était en attente : plusieurs membres refusaient d'engager un effort sérieux tant que le casse-tête n'aurait pas prouvé qu'il pouvait survivre à sa première échéance ([msg 6216](https://groups.io/g/eternity2/message/6216)) ; NickB avait parié 20 £ sur l'absence de vainqueur et jugeait son argent en sécurité ([msg 5979](https://groups.io/g/eternity2/message/5979)). Le 31 décembre 2008 est venu et reparti. Rien. Des membres ont écrit aux adresses britannique et américaine de Tomy et laissé des messages vocaux, sans réponse ([msg 6245](https://groups.io/g/eternity2/message/6245)) ; la Careline consommateurs ne savait « no details as of yet, regarding whether or not there is a winner » ([msg 6295](https://groups.io/g/eternity2/message/6295)). Le règlement disait que les vainqueurs seraient prévenus sous 14 jours et les résultats publiés dans le London Times et le New York Times ([msg 6296](https://groups.io/g/eternity2/message/6296), [msg 6336](https://groups.io/g/eternity2/message/6336)) ; aucune publication de ce genre n'a jamais visiblement paru. Entre-temps, le 6 janvier, Verhaard a publié la documentation de son solveur et en a dévoilé le plafond : les utilisateurs avaient trouvé 467 plus de quarante fois ([msg 6275](https://groups.io/g/eternity2/message/6275)). Le 15 janvier, à peu près le dernier jour de la fenêtre de 14 jours, Henk van der Griendt a trouvé une déclaration derrière un lien discret sur le site britannique seulement : des centaines de participations, aucune complète, le prix de 2 M$ toujours ouvert, et un prix de finaliste de 10 000 $ à **Anna Karlsson de Lund, Suède, pour 467 sur 480** ([msg 6337](https://groups.io/g/eternity2/message/6337)). Pas de communiqué de presse, pas de Times, et pas un mot de Monckton à aucun moment. La liste a eu besoin d'environ une heure pour décoder « Lund + 467 » : la participation venait du foyer de Louis Verhaard, soumise au nom de son épouse, qui avait reçu le courriel de félicitations quelques jours plus tôt ([msg 6349](https://groups.io/g/eternity2/message/6349)). Les félicitations ont afflué de tous les habitués ; Max a révélé que son propre meilleur score avait été 465, chaque bord supplémentaire coûtant à son programme un facteur d'environ 30 en temps ([msg 6348](https://groups.io/g/eternity2/message/6348)). La presse suédoise a publié la photo de famille : plus d'un an de travail, 13 « seams » d'une solution complète, une partie de l'argent allant au World Wildlife Fund ([msg 6374](https://groups.io/g/eternity2/message/6374), [msg 6375](https://groups.io/g/eternity2/message/6375)). Les suites ont eu trois piquants. Un chercheur du groupe SAT de Lleida a affirmé qu'atteindre 470 était « rather easy » avec leurs méthodes, une affirmation jamais étayée par la moindre participation soumise, comme Max l'a fait remarquer avec insistance ([msg 6306](https://groups.io/g/eternity2/message/6306), [msg 6360](https://groups.io/g/eternity2/message/6360)). Tomy a dit à un membre qu'il n'y aurait pas d'autres [casse-têtes à indices](/fr/research/build/clue-puzzles/), ce que la plupart de la liste a accueilli comme préservant la pureté du défi ([msg 6381](https://groups.io/g/eternity2/message/6381)). Et Verhaard a réglé au passage un théorème vieux de dix-sept mois : 479 *est* atteignable, en retournant une pièce de bordure dont les deux bords de bordure partagent une couleur dans une solution à 480. La preuve de parité de 2007 avait négligé les bords de bordure tournés vers l'extérieur, que le score ne compte jamais ([msg 6317](https://groups.io/g/eternity2/message/6317)). Même le résultat d'impossibilité le plus net de la communauté avait une faille ; le casse-tête, non résolu, gardait toutes les siennes. ## L'histoire continue > **Partie II : 2009-2026** > > L'histoire continue dans la [partie II](/fr/research/community/hunt-part-2/) : la rumeur hongroise « nous l'avons résolu » tranchée, la mort du concours avec sa solution enfermée dans un coffre, la décennie du 467, la migration qui a sauvé cette archive à quelques jours près, et la vague de records qui a porté le plateau à 470. ## À lire aussi - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). --- # La traque, une histoire, partie II : 2009-2026 > Dix-sept ans après le prix : le concours s'éteint avec sa solution enfermée dans un coffre, 467 tient une décennie, l'archive survit à la fermeture de Yahoo à quelques jours près, puis un inconnu venu de Reddit réécrit le livre des records. Chaque événement est rattaché à son message d'origine. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/community/hunt-part-2/ - Mise à jour: 2026-07-02 - Source: Monckton clôt le concours : « Aucune prolongation de délai n'est autorisée par le règlement » (groups.io message 8477) — https://groups.io/g/eternity2/message/8477 - Source: Peter McGavin résout le 10×10 de Brendan Owen en ~180 années-cœur, dans les marges d'erreur de la théorie de la complexité (groups.io message 9688) — https://groups.io/g/eternity2/message/9688 - Source: Le 469 de McGavin avec le solveur de Blackwood : « Nouveau record de 469 ! Seulement 11 ruptures ! » (groups.io message 10045) — https://groups.io/g/eternity2/message/10045 - Source: Le 470 de Joshua Blackwood, le record actuel (groups.io message 10117) — https://groups.io/g/eternity2/message/10117 - Source: Le 460 de Bruno Gauthier, le meilleur plateau à cinq indices 2023-2026 (groups.io message 11074) — https://groups.io/g/eternity2/message/11074 - Source: Le 464 de Benjamin Riotte, le nouveau record à cinq indices (groups.io, juillet 2026) — https://groups.io/g/eternity2/message/11919 - Source: Jef Bucas égale le 470 avec le code de Blackwood (groups.io message 11401) — https://groups.io/g/eternity2/message/11401 --- La [partie I](/fr/research/community/hunt/) s'achevait en janvier 2009 sur un chèque de 10 000 dollars décodé en une heure et un casse-tête qui avait franchi sa première échéance sans une éraflure. La partie II couvre tout ce qui a suivi : la lente agonie du concours, la décennie où un seul nombre, 467, a refusé de bouger, le jour où l'archive elle-même a failli disparaître, et la vague de records qui l'a enfin ébranlé. Comme précédemment, c'est l'histoire de la communauté racontée depuis l'[archive eternity2](https://groups.io/g/eternity2), et chaque événement renvoie au message où il s'est produit. ## Le long silence et les irréductibles (2009-2010) La rumeur hongroise du « on l'a résolu » que la partie I laissait en suspens est morte comme meurent toujours ces prétentions sur cette liste. Une fois correctement traduits (une équipe de l'université ELTE revendiquant une résolution complète via une salade d'algorithmes incluant l'élagage alpha-bêta, pour un casse-tête à un seul joueur), les hongrois natifs ont jugé les messages confus et les ingénieurs ont refait les calculs ([msg 6575](https://groups.io/g/eternity2/message/6575)). En juin, le compte du prétendant et tous ses commentaires avaient été supprimés du forum hongrois ([msg 6764](https://groups.io/g/eternity2/message/6764)). L'histoire vérifiée de 2009 fut plus discrète et bien meilleure. JSA a fait tourner le [solveur eii](/fr/research/lab/experiments/louis-verhaard/eii/) public de Louis Verhaard sur un seul PC et a consigné la montée : quatre millions de 463, 625 fois 466, et enfin, vers le 82e jour, un 467, reproduisant de façon indépendante le score du prix avec le binaire public et quantifiant à quel point l'air se raréfie au-dessus de 466 ([msg 6687](https://groups.io/g/eternity2/message/6687)). En août, Verhaard en personne a livré le récit définitif, à la première personne, de l'entrée gagnante : « Anna est ma femme » ; c'est elle qui l'a soumise, « c'est mon programme qui a fait le travail », et le plateau à 467 contenait 247 pièces sans défaut ([msg 6891](https://groups.io/g/eternity2/message/6891)). En décembre, il a divulgué la méthode que la partie I ne pouvait qu'esquisser : il avait trouvé 467 « plus de 50 fois », en laissant le backtracker placer une arête discordante à des profondeurs choisies, le geste connu sous le nom de [glissement d'arête](/fr/research/build/reduce/edge-slipping/), conditionné par la profondeur ([msg 7321](https://groups.io/g/eternity2/message/7321)). La seconde date d'examen, le 31 décembre 2009, a rejoué la première en farce, sans le versement. Des semaines de silence, puis une brève (« Eternity II reste non résolu ») sans gagnant et, contrairement à 2008, sans le moindre prix du meilleur partiel ([msg 7471](https://groups.io/g/eternity2/message/7471)). Un membre a soutiré un échange écrit à Tomy : aucune activité organisée en 2009, les solutions partielles n'étaient même pas notées, et « le prix de la première année ne faisait partie que de la promotion initiale » ([msg 7488](https://groups.io/g/eternity2/message/7488)). Verhaard a confirmé qu'il n'avait pas amélioré son 467 ([msg 7494](https://groups.io/g/eternity2/message/7494)). Il a aussi republié son solveur sur shortestpath.se, son point d'ancrage à long terme, après la disparition du site de son groupe de musique ([msg 7439](https://groups.io/g/eternity2/message/7439), [msg 7446](https://groups.io/g/eternity2/message/7446)). Les prétentions ont fleuri dans le vide malgré tout : une fenêtre surgissante d'E2Lab annonçant un 471 sur un plateau qui ne fut jamais sauvegardé ([msg 7284](https://groups.io/g/eternity2/message/7284)), une résolution à la main sous-entendant au moins 472, écartée à vue ([msg 7383](https://groups.io/g/eternity2/message/7383), [msg 7427](https://groups.io/g/eternity2/message/7427)). Aucune n'a produit de plateau. Pendant ce temps, doc_s_smith, vétéran d'Eternity I, est revenu après trois ans et a transformé la liste en atelier d'algorithmes ([msg 7755](https://groups.io/g/eternity2/message/7755)), posant l'objectif que l'époque pouvait raisonnablement viser : résoudre E2 lui-même étant sans espoir, « le défi est clair : battre 468 arêtes accordées » ([msg 7803](https://groups.io/g/eternity2/message/7803)). Quand son estimateur de Monte-Carlo a divergé du [modèle de complexité](/fr/research/why/complex-theory/) de Brendan Owen de cinq ordres de grandeur, Verhaard a défendu le modèle comme « le plus beau travail jamais publié sur E2 » ([msg 7810](https://groups.io/g/eternity2/message/7810)), une phrase que les quinze années suivantes n'ont cessé de confirmer. ## Le concours meurt (décembre 2010 → 2011) Sollicité pour une prolongation d'un an de la date d'examen finale, Tomy a répondu en une ligne : « Aucune décsion [sic] ne sera prise avant la prochaine date d'examen » ([msg 8006](https://groups.io/g/eternity2/message/8006)). L'échéance du 31 décembre 2010 est passée dans un humour de potence, les membres plaisantant sur l'envoi par coursier d'une hypothétique solution de dernière minute au bureau de poste ([msg 8197](https://groups.io/g/eternity2/message/8197)). Puis le site officiel s'est éteint, « suspendu dans l'attente de la confirmation de l'examen final » ([msg 8270](https://groups.io/g/eternity2/message/8270)) ; Verhaard a écrit : « Je peux vous dire en toute honnêteté que je ne l'ai pas résolu » ([msg 8277](https://groups.io/g/eternity2/message/8277)). La fin est arrivée par la France : un communiqué de presse de Tomy France (échéance passée, pas de gagnant, pas d'année supplémentaire, les 2 M$ non réclamés) accueilli avec incrédulité jusqu'à ce que l'URL source refasse surface et que la page anglaise suive deux jours plus tard ([msg 8339](https://groups.io/g/eternity2/message/8339), [msg 8373](https://groups.io/g/eternity2/message/8373)). La réponse par courriel de Monckton à un membre a fermé la porte en personne : la compétition était terminée, et « Aucune prolongation de délai n'est autorisée par le règlement », un règlement qui, les membres l'ont aussitôt fait remarquer, autorisait explicitement d'autres dates d'examen à la discrétion du promoteur ([msg 8477](https://groups.io/g/eternity2/message/8477), [msg 8478](https://groups.io/g/eternity2/message/8478)). Brendan Owen, l'homme qui postait depuis avant même le lancement du casse-tête, a fait ses adieux : « C'était très amusant ». Il a aussi demandé à Verhaard de féliciter sa femme pour le meilleur score, confirmation de première main que 467 tenait à la clôture du concours ([msg 8429](https://groups.io/g/eternity2/message/8429)). Deux fils non tranchés ont défini l'après. L'un était le vide des prétentions : le 476 sans l'indice d'un membre (le message d'origine manque de l'archive ; il survit à travers ses réponses, [msg 8247](https://groups.io/g/eternity2/message/8247)) a dégénéré en plusieurs revendications de 480 sans indice et s'est heurté au mur du zéro-connaissance de la communauté (Owen : publiez la grille des identifiants de pièces) ; rien ne fut jamais publié ([msg 8676](https://groups.io/g/eternity2/message/8676)). L'autre était la solution elle-même. Le propriétaire du groupe a exposé le dispositif de garde : personne, ni Tomy, ni Monckton, ne connaît la solution ; elle est entre les mains d'experts en sinistres indépendants ([msg 8502](https://groups.io/g/eternity2/message/8502)). Owen a ensuite livré la déclaration encore citée aujourd'hui : Alex Selby et Oliver Riordan ont créé une solution lorsque Monckton les a payés pour engendrer un casse-tête pratiquement impossible, et elle gît « cachée au milieu de rames de texte imprimé enfermées dans un coffre », en assurance contre un recours juridique ([msg 8823](https://groups.io/g/eternity2/message/8823)). En avril 2011, le site officiel a confirmé que le prix n'avait pas été réclamé ([msg 8846](https://groups.io/g/eternity2/message/8846)). Ce qui a remplacé l'argent, c'est une échelle. Des classements communautaires sont apparus dans la base de données du groupe ([msg 8222](https://groups.io/g/eternity2/message/8222), [msg 8735](https://groups.io/g/eternity2/message/8735)) ; Owen, incité par une intuition sur le nombre d'or, a démontré que le nombre de nœuds d'un backtracker culmine à une fraction (1 − 1/e) du plateau : 256 × 0,632 = 161,8, la forme close derrière la « magie de 161 » observée de longue date ([msg 8125](https://groups.io/g/eternity2/message/8125)) ; et les premières recherches exhaustives sur les [tests de référence 9×9](/fr/research/build/benchmarks/) d'Owen sont tombées à un ordre de grandeur de ce que prédisait sa théorie ([msg 8793](https://groups.io/g/eternity2/message/8793), [msg 8803](https://groups.io/g/eternity2/message/8803)). Un nouveau nom a effectué l'essentiel de ces vérifications : Peter McGavin, qui, dès 2011, tenait le guichet de service de la théorie de la complexité et avait calculé les chiffres devenus canon, environ 14 702 solutions attendues avec la pièce obligatoire placée ([msg 8924](https://groups.io/g/eternity2/message/8924)). ## Les années calmes (2012-2018) Trois années pleines, de 2012 à 2014, ont produit moins de messages qu'un trimestre chargé de 2008. Le monde académique s'est présenté en personne : Tony Wauters a publié l'article évalué par les pairs de son groupe sur une hyper-heuristique (meilleur score 461/480 en une heure) et est resté pour répondre aux questions ([msg 9017](https://groups.io/g/eternity2/message/9017)) ; un second article, sur des heuristiques de PLNE et de clique maximale, a suivi en 2017 ([msg 9683](https://groups.io/g/eternity2/message/9683)). Le seul argent de prix de l'époque fut une reprise du concours par un détaillant tchèque, dotée de 12 000 EUR ([msg 9072](https://groups.io/g/eternity2/message/9072)), prolongée jusqu'en juillet 2015 ([msg 9271](https://groups.io/g/eternity2/message/9271)) ; son expiration est ensuite passée sans une seule mention sur la liste. Quand le nouveau venu Dima a demandé le meilleur résultat connu fin 2014 et a reçu la réponse canonique, sa réplique résumait l'époque en une ligne : « 467 encore, vraiment ? Mais c'était il y a 6 ans ! » ([msg 9318](https://groups.io/g/eternity2/message/9318)). Sous la surface, deux choses ont mûri. La théorie est devenue un document : McGavin a transcrit le modèle de complexité d'Owen en LaTeX sous le nom complex_theory.pdf, dans les fichiers du groupe ([msg 9188](https://groups.io/g/eternity2/message/9188)), transformant le folklore en quelque chose que les nouveaux venus pouvaient réellement lire. Et la vitesse est redevenue une culture : Arnaud Carré a publié un solveur mono-cœur à 114 millions de récursions par seconde comme étalon de comparaison ([msg 9233](https://groups.io/g/eternity2/message/9233)), Michael Field a conçu un backtracker sur FPGA ([msg 9226](https://groups.io/g/eternity2/message/9226)), et un registre de nœuds par watt s'est étendu de grappes de Raspberry Pi à une Xbox One X ([msg 9519](https://groups.io/g/eternity2/message/9519), [msg 9816](https://groups.io/g/eternity2/message/9816)). Le filtre à prétentions a continué de fonctionner lui aussi : un « eternity2 résolu ;) » de 2014 est mort quand la vérification a trouvé une pièce utilisée cinq fois ([msg 9286](https://groups.io/g/eternity2/message/9286), [msg 9301](https://groups.io/g/eternity2/message/9301)). Puis, en septembre 2017, le test de référence partagé de la communauté est tombé. Peter McGavin a trouvé la première nouvelle solution au 10×10 sans indice de Brendan Owen, le « monstre » qui avait résisté à tous depuis 2008, en industrialisant exactement ce sur quoi la liste avait convergé : énumérer les ~20 millions de premières rangées possibles, les classer par la probabilité de solution par nœud de la théorie de la complexité, et les distribuer à tous les cœurs disponibles, des ODROID domestiques et Orange Pi à 12 $ aux serveurs de travail empruntés, 400 cœurs et plus au total ([msg 9686](https://groups.io/g/eternity2/message/9686), [msg 9688](https://groups.io/g/eternity2/message/9688)). La solution a coûté environ 2×10^17 nœuds (à peu près 180 années-cœur) et est arrivée à la recherche de rangée ~92 907 contre une prédiction d'une pour 70 000, dans les marges d'erreur de la théorie : selon les mots de McGavin, « aucune nouvelle méthode, juste de la persévérance systématique et la loi des grands nombres ». John Gilbert a parlé pour la liste : « Épatant que ce soit vraiment aussi dur que prévu » ([msg 9693](https://groups.io/g/eternity2/message/9693)). Ce fut la plus forte validation que la théorie d'Owen ait jamais reçue, et la preuve que la culture du test de référence, et non la course au record, avait été la véritable réussite du groupe pour la décennie. Le même fil a soulevé une question de records qui ne s'est jamais résolue : Dima a exhumé un tweet de 2009 de la star de TopCoder Naohiro Takahashi revendiquant un 468, jamais accompagné d'un plateau, peut-être noté selon d'autres règles de concours, et laissé à jamais invérifié ([msg 9694](https://groups.io/g/eternity2/message/9694), [msg 9697](https://groups.io/g/eternity2/message/9697)). Deux mois plus tard, McGavin a placé les 256 vraies pièces sur le plateau 16×16 avec les 480 jonctions internes toutes accordées, un « E2 sans cadre » aux arêtes grises enfouies à l'intérieur, en étant scrupuleusement précis sur le fait que ce n'était pas une solution au casse-tête ([msg 9736](https://groups.io/g/eternity2/message/9736), [msg 9750](https://groups.io/g/eternity2/message/9750), [msg 9757](https://groups.io/g/eternity2/message/9757)). La fenêtre s'est refermée à marée basse : 2018 a produit 42 messages, et à un sondage de nouveau venu un vétéran a répondu : « quelqu'un qui moud encore du backtracking ?? aucune chance.... » ([msg 9832](https://groups.io/g/eternity2/message/9832)). ## La migration (2019) En octobre 2019, Yahoo a annoncé qu'il effacerait tout le contenu des Groups en quelques semaines : douze ans de décomptes de pièces, de preuves, de démentis et de sources de solveurs, disparus. Jef Bucas a donné l'alerte ([msg 9920](https://groups.io/g/eternity2/message/9920)), Robert Gerbicz a proposé groups.io, le fondateur Ole Knudsen a créé le nouveau groupe, et JSA a payé les frais de transfert : « Je peux payer les 5 premières années » ([msg 2](https://groups.io/g/eternity2/message/2)). Le transfert automatisé s'est achevé le 8 novembre 2019 avec environ 2 000 membres, messages, fichiers et photos intacts ([msg 9934](https://groups.io/g/eternity2/message/9934), [msg 9937](https://groups.io/g/eternity2/message/9937)). L'archive à partir de laquelle cette chronique est écrite a survécu à quelques jours près. Deux semaines plus tard, Bucas a lancé l'autre moitié de l'infrastructure de l'ère moderne : [e2.bucas.name](https://e2.bucas.name), une visionneuse de plateaux dont les plateaux vivent entièrement dans l'URL (rien n'est transmis au serveur), avec un menu déroulant des meilleurs plateaux qui est tranquillement devenu le livre des records de la communauté ([msg 9955](https://groups.io/g/eternity2/message/9955)). À propos, l'actualité des records de l'année était archivistique elle aussi : Verhaard a confirmé que son étonnant partiel sans défaut de 249 pièces était réel, « aucune tricherie… trouvé après une semaine environ, sur 1 ordinateur » ([msg 9890](https://groups.io/g/eternity2/message/9890)). ## La vague de records (2020-2021) Le 31 août 2020, un membre a relayé un message Reddit : un nouveau meilleur plateau avec seulement 12 ruptures, 468/480, la première avancée au-delà du 467 de Verhaard en douze ans ([msg 10032](https://groups.io/g/eternity2/message/10032)). L'auteur était Joshua Blackwood, un parfait inconnu de la liste. Bucas a vérifié le plateau, l'a ajouté à la visionneuse, et a transmis le détail qui a fait dresser l'oreille aux vétérans : l'auteur « dit qu'il peut trouver un 468 tous les 4 jours ! » ([msg 10033](https://groups.io/g/eternity2/message/10033)). Trois jours plus tard, Blackwood a mis le solveur lui-même en libre accès, porteur de changements heuristiques qu'il croyait « deux fois meilleurs » et préconfiguré pour chasser les 469 ([msg 10037](https://groups.io/g/eternity2/message/10037)). Ses notes d'ingénierie valaient autant que le code : solveurs SAT, GPU et caches de 2×2 pré-résolus avaient tous été mesurés puis écartés ; la magie tenait au calendrier heuristique et à un petit ensemble de profondeurs de « rupture » autorisées ([msg 10056](https://groups.io/g/eternity2/message/10056), [msg 10076](https://groups.io/g/eternity2/message/10076)). La communauté a fait ce qu'elle fait avec un bon code : elle l'a exécuté. Le 9 septembre 2020, Peter McGavin, l'homme qui avait résolu le 10×10, a écrit : « Ton solveur est fantastique !! Je l'ai fait tourner quelques jours sur environ deux cents cœurs et j'ai décroché le jackpot. Nouveau record de 469 ! Seulement 11 ruptures ! » ([msg 10045](https://groups.io/g/eternity2/message/10045)). Bucas a réécrit le solveur en C, en doublant à peu près sa vitesse, et une vague de 469 supplémentaires a suivi tout au long de novembre ([msg 10065](https://groups.io/g/eternity2/message/10065), [msg 10067](https://groups.io/g/eternity2/message/10067)) ; le générateur derrière le portage a été publié sous le nom de libblackwood ([msg 10078](https://groups.io/g/eternity2/message/10078)). Puis, le 30 mars 2021, un message de deux lignes : l'URL d'un plateau 470/480 ([msg 10117](https://groups.io/g/eternity2/message/10117)). Blackwood a confirmé plus tard que le dépôt public était « le code exact utilisé pour trouver un 470 » ([msg 10161](https://groups.io/g/eternity2/message/10161)), puis s'est retiré : « Je n'ai pas écrit une ligne de code ni fait tourner le moindre algorithme depuis que j'ai trouvé un 470 » ([msg 10185](https://groups.io/g/eternity2/message/10185)). Une clarification compte pour la manière dont on lit ces records. Le règlement propre au concours ne fixait que la pièce de départ, exigée à son emplacement et à sa rotation spécifiés ; les quatre autres indices étaient des aides facultatives ([msg 11046](https://groups.io/g/eternity2/message/11046)). Chaque plateau record à partir du 468 relève de ce même régime « pièce de départ seule » : la pièce 139 sur sa case obligatoire, aucun des quatre indices facultatifs à sa position officielle, une affirmation vérifiée au niveau du plateau pour le 470 ([msg 10554](https://groups.io/g/eternity2/message/10554)). Le 470 est le même casse-tête que les 469 longtemps cités comme le plafond, et non une variante plus facile ; Blackwood avait les tuiles d'indice et « ne les a délibérément pas utilisées » ([msg 10185](https://groups.io/g/eternity2/message/10185)). Les plateaux qui respectent en plus les quatre indices facultatifs forment une échelle distincte, plus stricte (plus de détails ci-dessous). La [page des records](/fr/research/records/) maintient les deux régimes explicitement séparés. Blackwood s'est autorisé un rappel : en reconfigurant son solveur pour zéro rupture, il a porté le record de placements consécutifs du 226 de longue date de Verhaard à 227, puis 230, le tout sur « un seul PC dans mon sous-sol » ([msg 10536](https://groups.io/g/eternity2/message/10536), [msg 10544](https://groups.io/g/eternity2/message/10544), [msg 10547](https://groups.io/g/eternity2/message/10547)). ## L'ère moderne (2022-2026) Les années d'après-vague se sont installées dans un rythme d'invariants, de calibrage et de provenance. En mai 2022, Al Hopfer, un habitué depuis 2009, a énoncé la condition de bordure désormais connue sur ce site sous le nom d'[équilibre NS-1](/fr/research/why/border-balance/) : le rebord extérieur de l'intérieur 14×14 « doit avoir le même mélange (parité) des images internes sur les 56 pièces de bordure » ([msg 10754](https://groups.io/g/eternity2/message/10754), [msg 10757](https://groups.io/g/eternity2/message/10757)). Dans le même fil, Carlos Fernandez résolvait des quadrants 14×14 en environ quatre minutes ([msg 10802](https://groups.io/g/eternity2/message/10802)). Les gros blocs intérieurs étaient devenus routiniers ; fermer le cadre, non. Le score du prix de 2008, quant à lui, a été formellement rétrogradé au rang de test de non-régression : « la semaine dernière j'ai trouvé environ 30 fois 467. J'utilise cette cible pour calibrer le code que je fais tourner », a écrit Bucas ([msg 11001](https://groups.io/g/eternity2/message/11001)). L'échelle plus stricte a eu son propre record. Un fil de 2023 collectant les meilleurs plateaux qui respectent **les cinq** placements d'indices a grimpé de 412 à 452 et 458, jusqu'au 460 de Bruno Gauthier ([msg 11074](https://groups.io/g/eternity2/message/11074)), qui a tenu plus de trois ans jusqu'au 464 de Benjamin Riotte en juillet 2026, un 461 s'élevant à 464/480 avec son propre solveur Blackwood modifié, Igor Pejic atteignant la même plage 463-464 de façon indépendante ([groups.io](https://groups.io/g/eternity2/message/11919)). La même année a produit le faux positif canonique de l'époque : un 16×16 complet, à 480 arêtes accordées, construit par McGavin à partir des pièces d'un jeu E2, d'un jeu Clue-1 et d'un jeu Clue-2, un « 480 » qui n'est pas le casse-tête, posté précisément pour faire valoir ce point ([msg 11169](https://groups.io/g/eternity2/message/11169)). La théorie a achevé son long voyage des messages au code source. En janvier 2024, McGavin a redonné les chiffres phares : 14 702 solutions attendues avec la seule pièce de départ, 0,00000004 avec les cinq indices, « suggérant très fortement… une solution unique » ([msg 11193](https://groups.io/g/eternity2/message/11193)). Le lendemain, il a publié complex_theory.c, son implémentation exacte en C du modèle d'Owen ([msg 11197](https://groups.io/g/eternity2/message/11197)) : la référence que le [moteur de complexité](/fr/research/lab/experiments/joshua-blackwood/solver/) propre à ce site porte. En décembre, Bucas a égalé le record : « J'ai relancé quelques fils du code de Joshua, et… un autre 470 est apparu ! » ([msg 11401](https://groups.io/g/eternity2/message/11401)), Fernandez postant une variation à bordure réarrangée la même semaine ([msg 11403](https://groups.io/g/eternity2/message/11403)). Le crédit que Bucas accordait n'a jamais vacillé : « Joshua Blackwood est l'actuel détenteur du record. J'ai humblement utilisé son code » ([msg 11555](https://groups.io/g/eternity2/message/11555)). Et son projet wrapper_blackwood a placé le point au-delà de l'opinion : une ferme qui a fait varier chaque paramètre de l'algorithme de Blackwood et en a mesuré les résultats, concluant que, dans les paramètres balayés, le réglage manuel de l'auteur était déjà quasi optimal ; ses notes sont publiées sur ce site avec son autorisation explicite ([msg 11905](https://groups.io/g/eternity2/message/11905)). Et les fondateurs sont revenus, ou pas. En mai 2025, Brendan Owen a posté pour la première fois depuis environ quatorze ans, répondant à une question de difficulté d'un nouveau venu ([msg 11500](https://groups.io/g/eternity2/message/11500)), disant à McGavin que ses années de travail étaient « très impressionnantes » ([msg 11521](https://groups.io/g/eternity2/message/11521)), et revenant à son propre modèle avec un calcul affiné des probabilités de jonction d'arêtes ([msg 11546](https://groups.io/g/eternity2/message/11546)). L'ère de l'IA est d'abord arrivée en farce : ChatGPT informant avec aplomb un membre qu'une solution « a fini par être trouvée par une équipe de passionnés de casse-tête » ([msg 10993](https://groups.io/g/eternity2/message/10993)), puis une appli de solveur codée à l'intuition dont le propriétaire concédait « ce n'est pas garanti à 100 % parce que Base44 c'est de l'IA », accueillie par un tutorat patient plutôt que par la moquerie ([msg 11755](https://groups.io/g/eternity2/message/11755), [msg 11818](https://groups.io/g/eternity2/message/11818)). Et en février 2026, la note de bienvenue annuelle s'est ouverte sur un hommage à Kronjuvel : Ole Knudsen, qui a créé le groupe, l'a animé pendant près de deux décennies, et a disparu de la liste depuis 2023 ([msg 11771](https://groups.io/g/eternity2/message/11771)). Le front actuel de l'archive est le 31 mars 2026 : un fil SAT débattant encore d'encodages CNF de 4 Go, un défi permanent juste pour le plaisir d'invalider un partiel de bordure, et la phrase d'un membre pour l'anniversaire : « doucement nous progressons vers les 20 ans d'E2 l'an prochain ;-) Résoudrons-nous E2 en 2026… ? » ([msg 11820](https://groups.io/g/eternity2/message/11820), [msg 11823](https://groups.io/g/eternity2/message/11823)). Le bilan après dix-neuf ans : le 480 n'a jamais été trouvé ; le 470 tient depuis 2021 ; et les dix arêtes manquantes sont, comme toujours, [là où vit tout le problème](/fr/research/records/). ## À lire aussi - [La traque, une histoire (partie I : 2000-2009)](https://eternity2.dev/fr/research/community/hunt/) — L'histoire de la communauté, d'une liste de diffusion fondée sept ans avant que le casse-tête n'existe jusqu'au prix d'examen de 10 000 $ remporté sous un nom d'emprunt, chaque événement rattaché à son message d'origine. Partie I d'une chronique en cours. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. --- # Contribuez vos recherches > Ce wiki est le foyer de recherche de la communauté, et il y a de la place pour votre travail. Trois façons de le faire publier, du message sur la liste de diffusion à la pull request, plus le petit jeu de règles maison qui garde chaque page digne de confiance. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/contribute/ - Mise à jour: 2026-07-21 --- Ce wiki n'est pas le blog d'une seule personne, porte close. Il se veut le foyer de recherche de la communauté : l'endroit où dix-neuf ans de travail sur Eternity II (records, méthodes, résultats structurels, [impasses](/fr/research/build/dead-ends/) comprises) sont consignés, sourcés et gardés trouvables. Chaque page [du labo](/fr/research/lab/) porte la signature de son auteur et se rassemble sur la [page contributeur](/fr/research/people/) de ce chercheur, aujourd'hui surtout [celle de Raphaël](/fr/research/people/raphael-anjou/), parce que c'est lui qui prend la peine de tout écrire, mais la structure crédite chaque contributeur par son nom. La vôtre peut prendre place juste à côté de la sienne. > **Rien à publier pour l'instant ?** > > Commencez par construire. La [boîte à outils du bâtisseur](/fr/research/build/toolkit/) vous mène à un solveur qui tourne, et pour une première cible où vous faire un nom, le [10×10 set_2 de Brendan Owen](/fr/research/build/benchmarks/#les-1010-de-brendan--lun-est-tombé-lautre-tient-encore) est le plateau non résolu le plus proche sous le puzzle complet. Un résultat là-dessus mérite d'être rapporté ici. Il existe déjà un précédent. La page sur [l'algorithme de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) repose sur les notes et l'étude de paramètres de Jef Bucas, republiées avec son accord explicite, ses figures et son nom sur chacune d'elles. C'est le modèle : le travail reste le vôtre, le wiki lui offre un foyer permanent et citable. ## Trois portes d'entrée **1. Postez-le et signalez-le : la voie la plus légère.** Partagez votre découverte là où la communauté discute déjà : la [liste de diffusion](https://groups.io/g/eternity2) ou le [serveur Discord](https://discord.gg/Ny5xs3q8w). Si vous souhaitez la voir sur le wiki, dites-le simplement dans votre message. Quelqu'un (généralement Raphaël) en rédigera une page, vous la soumettra, et la publiera avec tout le crédit qui vous revient. C'est exactement ainsi que la page Blackwood est née des notes de Jef. Vous n'avez jamais à toucher au dépôt. **2. Ouvrez une issue ou une pull request.** Le wiki est [un dépôt ouvert](https://github.com/raphael-anjou/eternity2), et une page de recherche n'est rien de plus qu'un fichier MDX sous `web/content/research/`. Ajouter le fichier *est* l'enregistrement : la barre latérale, la recherche et le sitemap le prennent en compte automatiquement. Chaque page commence par un petit bloc de frontmatter : ```yaml title: Your finding, in one line description: >- Two or three sentences that can stand alone in a search result. kind: finding # or experiment, concept, reference... updated: 2026-07-02 topics: [backtracking] sources: - label: Hopfer's statement of the NS-1 condition (2022) url: https://groups.io/g/eternity2/message/10754 ``` Si la page est une **expérience** (une recherche que vous avez mesurée), un bloc supplémentaire est requis : le matériel sur lequel elle a tourné. C'est ce qui permet à un lecteur de comparer votre résultat à celui de tous les autres, et le build refuse une page d'expérience qui en est dépourvue. ```yaml kind: experiment hardware: cores: 1 # logical cores used; sum across nodes for a cluster cpu: "AMD Ryzen 9 7950X" ramGb: 64 gpus: 0 accelerator: none # none | gpu | quantum | fpga | tpu machine: "desktop, single box" wallClock: "10 × 60 s" # budget per run × repeats runs: 10 seedPolicy: "randomized corner permutation per run" measured: true # true only for the standardized single-core bench ``` La page en fait une fiche technique avec un seul chiffre-titre dérivé : les **cœurs-heures** (cœurs × heures de temps réel), le coût véritable de la recherche. C'est ce chiffre unique qui met une recherche à un cœur et une minute et un balayage sur 400 cœurs en centre de données dans la même table sans que l'un flatte l'autre. Ne mettez `measured: true` que pour une référence mono-cœur standardisée (un cœur, un budget de temps fixe) ; une recherche multi-cœurs est un `native run` et consigne son matériel réel ainsi que le meilleur score atteint. Pas sûr de la tuyauterie ? Ouvrez une issue avec votre brouillon en markdown simple et nous nous occupons du reste. [Faites-le tourner vous-même](/fr/research/build/run-it-yourself/) explique comment lancer le site en local si vous voulez prévisualiser votre page. **3. Partagez données et plateaux.** Tout n'a pas besoin de prose. Un bon plateau, un balayage de paramètres, un jeu de données issu d'une longue recherche : tout cela est le bienvenu. Chaque plateau de ce site est vérifiable dans le [visualiseur](/viewer/), qui parle nativement le format d'URL standard de la communauté, si bien que n'importe qui peut contrôler votre résultat en un clic. Postez le plateau ou les données avec une note sur leur production, et cela peut étayer une page ou en devenir une. ## Les règles maison Elles existent pour une seule raison : que quiconque tombe sur n'importe quelle page puisse faire confiance à ce qu'il lit. - **Chaque affirmation renvoie à une source.** Un message de la liste de diffusion, un dépôt, un article : quelque chose que le lecteur peut suivre. - **Chaque chiffre est reproductible ou étiqueté pour ce qu'il est.** Les résultats déterministes s'accompagnent d'une commande qui les régénère à l'identique. Les calculs à graine, stochastiques ou lourds le disent clairement (« ne se reproduira pas à l'identique », « ~40 h sur 8 cœurs ») et livrent le plateau qu'ils ont trouvé pour qu'il reste vérifiable. Le statut de relecture d'une page l'accompagne sur un niveau distinct : `report` pour un compte rendu technique public mais pas encore relu, et `live` pour une page relue, citée et considérée comme acquise (`draft` étant l'état non publié que l'on croise rarement). - **Chaque expérience dit sur quoi elle a tourné.** Une recherche mesurée n'a aucun sens sans son matériel ; une page d'expérience doit donc porter le bloc `hardware:` ci-dessus (cœurs, matériel, budget de temps). Le build l'impose. Un score sans calcul derrière lui n'est pas un résultat que l'on peut comparer. - **Les pages françaises sont écrites, pas traduites.** Chaque page existe dans les deux langues, et la version française est de la vraie prose française, pas une passe automatique. Si vous n'écrivez qu'une seule langue, ce n'est pas grave ; un mainteneur peut faire traduire l'autre. - **Votre nom reste sur votre travail.** Encarts de crédit, liens de source, attributions de figures : la page Blackwood montre ce que cela donne en pratique. Rien n'est absorbé anonymement. ## Ce que le wiki rend en retour En échange du respect de ces règles, votre travail reçoit une infrastructure qu'un message de forum n'aura jamais : une page stable dans l'habillage de la documentation avec barre latérale, recherche et fil d'Ariane ; un rangement dans les [pôles thématiques](/fr/research/) pour qu'on la trouve par thème, et pas seulement par date ; un export en markdown brut de chaque page (ajoutez `.md` à son URL) pour qu'elle reste lisible par machine ; et une URL permanente que d'autres chercheurs pourront citer, des années plus tard et pas seulement cette semaine. Le puzzle a résisté à tout le monde jusqu'ici. Le moins que l'on puisse faire, c'est de veiller à ce que les progrès de personne contre lui ne se perdent. ## À lire aussi - [L'exécuter soi-même](https://eternity2.dev/fr/research/build/run-it-yourself/) — L'ensemble du site, le moteur et chaque résultat de cette section tournent depuis un seul dépôt. Voici comment le lancer, recompiler le moteur WebAssembly et reproduire les chiffres. - [La boîte à outils du bâtisseur](https://eternity2.dev/fr/research/build/toolkit/) — Un kit de démarrage Rust prêt à l'emploi pour construire votre propre solveur Eternity II : scorer, générer des plateaux au vrai équilibre des couleurs, générer des lots avec indices épinglés, convertir tous les formats, mesurer les performances, et une boucle résoudre→balayer→comparer, où vous n'écrivez que le solveur. Plus une configuration en une ligne pour les agents de code, et un générateur de plateaux directement dans le navigateur. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. --- # Histoire : les grandes étapes > L'histoire d'Eternity II en un coup d'œil, de la liste de diffusion fondée en 2000 au record de 470 qui tient toujours. Une chronologie parcourable des tournants, chacun renvoyant à l'histoire complète en deux parties et au message où il s'est produit. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/history/ - Mise à jour: 2026-07-11 - Source: L'archive de la liste de diffusion eternity2 (groups.io) : chaque jalon ci-dessous renvoie à son message d'origine — https://groups.io/g/eternity2 - Source: Wikipédia, « Eternity II puzzle » — https://en.wikipedia.org/wiki/Eternity_II_puzzle --- Eternity II a une histoire officielle (un lancement, un prix de 2 000 000 $, une échéance) et une histoire réelle, qui s'est jouée sur une liste de diffusion. Cette page raconte la vraie, réduite à ses tournants : les moments qui ont véritablement fait avancer le casse-tête, chacun tenant en une seule ligne lisible d'un coup d'œil. Pour le récit complet en prose, l'histoire est racontée en deux parties : la [partie I](/fr/research/community/hunt/) couvre 2000 à 2009, de la fondation du groupe au premier prix de vérification ; la [partie II](/fr/research/community/hunt-part-2/) couvre 2009 à aujourd'hui. Chaque jalon renvoie ici vers ces récits, et vers le message d'archive où il s'est produit. > **[Interactive: HistoryTimeline]** Rendered on the canonical page (link above); not shown in this markdown export. ## Pour aller plus loin - La [chronologie des records](/fr/research/records/) trace le score lui-même au fil du temps : le 467 de 2008, le long silence, la montée rapide jusqu'à 470, puis le plateau depuis 2021, avec le tableau complet et chaque plateau consultable arête par arête. - L'[histoire complète](/fr/research/community/hunt/) raconte la même histoire en prose, avec bien plus de détails sur les personnes, les débats et les impasses qu'une chronologie ne peut en contenir. - Les [personnes derrière tout cela](/fr/research/people/) racontent la même histoire par personne : qui a fait quoi, et où le lire dans leurs propres mots. ## À lire aussi - [La traque, une histoire (partie I : 2000-2009)](https://eternity2.dev/fr/research/community/hunt/) — L'histoire de la communauté, d'une liste de diffusion fondée sept ans avant que le casse-tête n'existe jusqu'au prix d'examen de 10 000 $ remporté sous un nom d'emprunt, chaque événement rattaché à son message d'origine. Partie I d'une chronique en cours. - [La traque, une histoire, partie II : 2009-2026](https://eternity2.dev/fr/research/community/hunt-part-2/) — Dix-sept ans après le prix : le concours s'éteint avec sa solution enfermée dans un coffre, 467 tient une décennie, l'archive survit à la fermeture de Yahoo à quelques jours près, puis un inconnu venu de Reddit réécrit le livre des records. Chaque événement est rattaché à son message d'origine. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Le who's who de la recherche sur E2](https://eternity2.dev/fr/research/people/) — Deux décennies de recherche sur Eternity II ont été menées par des personnes identifiées, sur une liste de diffusion. Cette page en est la galerie : qui elles sont, ce que chacune a apporté, et où le lire dans leurs propres mots. Un remerciement autant qu'un index. --- # Le laboratoire > Le carnet ouvert du wiki : résultats structurels et expériences de recherche nommées, chacune attribuée au chercheur qui l'a menée et reproductible depuis les sources. Un coin de la recherche plus large de la communauté. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/ - Mise à jour: 2026-07-21 --- Voici le carnet ouvert : résultats et expériences originaux sur Eternity II, rédigés en détail et attribués page par page au chercheur qui a fait le travail. Ce n'est pas le blog d'une seule personne. Les [expériences](/fr/research/lab/experiments/) sont organisées à raison d'une section par chercheur, et le travail de chacun se retrouve aussi rassemblé sur sa propre [page de contributeur](/fr/research/people/). Aujourd'hui, la section de [Raphaël](/fr/research/people/raphael-anjou/) est la plus complète, parce que c'est lui qui consigne les choses, mais la structure est conçue pour de nombreuses mains et une section attend la vôtre. Les méthodes, records et l'histoire de la communauté occupent le reste de la section recherche. ## Par où commencer - **[Les expériences](/fr/research/lab/experiments/)** sont la galerie complète : chaque recherche nommée et chaque résultat structurel, filtrables par issue et par chercheur. Commencez ici pour parcourir. - **[Quel mur arrête quelle méthode](/fr/research/why/walls-and-methods/)** lit la galerie comme une seule image : chaque expérience face au mur qu'elle attaque et au score où elle s'est arrêtée. - **[Comment le laboratoire publie](/fr/research/lab/experiments/methodology/)** est le standard éditorial commun que chaque page respecte, pour savoir ce que signifie chaque étiquette sur un résultat. - **[Contribuer](/fr/research/contribute/)** est la façon d'ajouter votre propre trouvaille, créditée à votre nom, à côté du reste. Les algorithmes présentés ici sont des expériences, pas des percées. Certains sont des idées originales ; d'autres réimplémentent fidèlement une technique connue de la communauté afin de mesurer précisément ce qu'elle apporte. Chaque compte rendu précise de quoi il s'agit, ce qu'il a attaqué, où il s'est arrêté et ce qu'il a laissé ouvert, de sorte que chacun puisse reprendre là où il s'est terminé. ## Tout est reproductible Aucun résultat sur ce site n'est une affirmation sans preuve. Les calculs déterministes sont livrés avec un script exécutable et la sortie exacte qu'il produit. Les recherches qui dépendent du hasard ou prennent des heures sont livrées avec le même script, plus le plateau qu'elles ont trouvé, que vous pouvez charger dans la visionneuse et vérifier arête par arête. L'étiquette de chaque résultat vous indique de quel type il s'agit. ## Comment le laboratoire publie Chaque page ici respecte une même norme éditoriale : quel type de contribution elle représente, si elle est publiée et à quel niveau, et avec quelle solidité son affirmation est étayée. [Comment le laboratoire publie](/fr/research/lab/experiments/methodology/) énonce cette norme, afin que les mêmes règles s'appliquent quel que soit l'auteur de la page. ## Ajoutez la vôtre Le carnet est ouvert. Si vous avez un résultat ou une recherche qui mérite d'être consigné, il y a [une place pour lui ici](/fr/research/contribute/), attribué à votre nom, aux côtés des autres. ## Pages de cette section - [Expériences](https://eternity2.dev/fr/research/lab/experiments/) — Les expériences de recherche nommées du laboratoire, une section par chercheur. Chacune est un run réel contre Eternity II avec son idée, son meilleur plateau et les questions qu'elle a laissées ouvertes. Le carnet de Raphaël Anjou est ici en entier ; le carnet reste ouvert à tous les autres. --- # Expériences > Les expériences de recherche nommées du laboratoire, une section par chercheur. Chacune est un run réel contre Eternity II avec son idée, son meilleur plateau et les questions qu'elle a laissées ouvertes. Le carnet de Raphaël Anjou est ici en entier ; le carnet reste ouvert à tous les autres. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/ - Mise à jour: 2026-07-21 --- Les expériences sont des runs de recherche nommés contre Eternity II, chacun documenté avec son idée, son meilleur résultat et les questions qu'il a laissées ouvertes. Elles sont créditées page par page au chercheur qui les a menées, et regroupées en une section par chercheur. Ce n'est qu'un coin de la recherche plus large de la communauté ; les méthodes, les records et l'histoire vivent dans le reste de la [section recherche](/fr/research/). > **[Interactive: ExperimentAuthors]** Rendered on the canonical page (link above); not shown in this markdown export. ## Chaque expérience notée, côte à côte Le grand tableau : chaque expérience nommée qui a atteint un plateau, tous chercheurs confondus, avec le score obtenu et la façon dont le run s'est terminé. Les lignes sont découvertes depuis les pages elles-mêmes, si bien que ce tableau reste en phase avec elles ; cliquez sur un en-tête de colonne pour réordonner. Chaque score est marqué de la convention sous laquelle il est mesuré (arêtes appariées, ou la piste plus stricte à cinq indices), car un simple NNN/480 ne veut pas dire la même chose sous chacune. > **[Interactive: ExperimentResultsTable]** Rendered on the canonical page (link above); not shown in this markdown export. Tout résultat n'est pas un solveur, et le tableau ci-dessus ne recense que les runs scorés. Pour parcourir le labo dans l'autre sens, selon le type de résultat de chaque page (les analyses, la théorie, les mesures, et les impasses gardées comme résultats négatifs à part entière), voyez l'[index par contribution](/fr/research/lab/experiments/by-contribution/). ## Ce qui compte ici comme expérience Certaines sont des idées originales ; d'autres réimplémentent fidèlement une technique connue de la communauté pour mesurer exactement ce qu'elle apporte. Chaque compte rendu précise de quoi il s'agit, ce qu'il a attaqué, où il s'est arrêté et ce qu'il a laissé ouvert, afin que chacun puisse reprendre là où il s'est terminé. Et chaque résultat est reproductible : les runs déterministes sont livrés avec un script et sa sortie exacte ; les recherches qui dépendent du hasard sont livrées avec ce même script plus le plateau trouvé, chargeable dans la [visionneuse](/viewer/) et vérifiable arête par arête. Chaque expérience indique aussi le **matériel sur lequel elle a tourné**, dans une fiche technique fixe : les cœurs, la machine, le budget de temps, et un chiffre dérivé, les cœur-heures, qui dit ce que le run a réellement coûté. C'est obligatoire, car un score ne veut rien dire sans le calcul qui le soutient. Quand un run est directement comparable, il porte un badge **banc standardisé** (un cœur, un budget fixe en minutes, relancé depuis des coins aléatoires) ; un run plus gros est un **run natif** qui consigne son vrai matériel et le meilleur score qu'il a atteint. Ainsi, une minute partie de zéro sur un cœur et un balayage en centre de données sur quatre cents cœurs tiennent dans la même table, chacun jugé face à ce qu'il a réellement dépensé. ## Pages de cette section - [Comment le laboratoire publie](https://eternity2.dev/fr/research/lab/experiments/methodology/) — Le standard éditorial de ce carnet ouvert : comment un travail de recherche sur Eternity II passe d'un travail non publié à une page publiée. De quel type de contribution il s'agit, s'il est publié, à quel niveau, et où il réside. Un standard commun, conçu pour s'étendre à de nombreux auteurs. - [Benchmark mono-cœur](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/) — Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - [Les expériences de Raphaël Anjou](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/) — Un carnet d'expériences de recherche sur Eternity II, organisé autour des moteurs partagés qui les font tourner, des pipelines de combinaison qui courent après le score, de quatre études qui décortiquent un paradigme de recherche une décision à la fois, et de résolutions exactes de fin de partie. Chacune expose son idée, son meilleur plateau et les questions qu'elle laisse ouvertes. La meilleure atteint 463 sur 480. - [Le moteur de Peter McGavin](https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/) — Le backtracker C que Peter McGavin a lui-même écrit, le solveur brut le plus rapide que la communauté ait mesuré. Récupéré sur la liste de diffusion, compilé sur un M1 et lancé sur le véritable Eternity II. Son code, son algorithme ; exécuté et documenté ici. - [Le solveur de Joshua Blackwood](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/) — Le solveur C# open source de Joshua Blackwood, celui qui a trouvé le record de 470 toujours en vigueur. Compilé et exécuté ici tel qu'il l'a publié, puis avec les cinq indices officiels fixés. Son code, son algorithme ; exécuté et documenté ici. - [L'eii de Louis Verhaard](https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/) — L'eii de Louis Verhaard a remporté le seul prix que le puzzle ait jamais payé, mais il n'existe que sous forme de binaire Windows sans code source. En quoi consiste sa méthode, pourquoi l'original ne tourne pas ici, et où vit une réimplémentation fidèle. --- # Le solveur de Joshua Blackwood > Le solveur C# open source de Joshua Blackwood, celui qui a trouvé le record de 470 toujours en vigueur. Compilé et exécuté ici tel qu'il l'a publié, puis avec les cinq indices officiels fixés. Son code, son algorithme ; exécuté et documenté ici. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/ - Mise à jour: 2026-07-15 --- Cette section porte sur le solveur de [Joshua Blackwood](/fr/research/people/joshua-blackwood/) lui-même : le programme C# open source qui a trouvé le 470 qui tient encore. L'algorithme et le code sont les siens, publics sur GitHub. Ce qui est ajouté ici, c'est l'exécution : compilé tel qu'il l'a publié, mesuré en mono-cœur, puis confronté au véritable puzzle à cinq indices pour voir ce que sa vitesse achète réellement. ## Pages de cette section - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. --- # Le solveur de Blackwood, décodé et exécuté ici > Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/ - Mise à jour: 2026-07-21 - Sujets: backtracking, speed - Reproduire: `git clone github.com/jblackwood345/EternityII_Solver; dotnet build -c Release` - Source: Le solveur de Joshua Blackwood (GitHub, GPL-3.0, la source d'origine) — https://github.com/jblackwood345/EternityII_Solver - Source: Les notes de Jef Bucas sur le solveur Blackwood (dépôt wrapper_blackwood) — https://github.com/jfbucas/wrapper_blackwood/blob/main/doc/Notes/Notes.md - Source: L'annonce de l'étude de Jef et l'autorisation de republier (groups.io message 11905) — https://groups.io/g/eternity2/message/11905 - Source: Le plan de réglage de Blackwood : les quatre leviers et le réajustement du 470 (groups.io message 10076) — https://groups.io/g/eternity2/message/10076 - Source: Le dépôt republié, « le code exact utilisé pour trouver un 470 » (groups.io message 10161) — https://groups.io/g/eternity2/message/10161 - Source: L'annonce du 470 par Blackwood (msg 10117) — https://groups.io/g/eternity2/message/10117 --- > **À qui appartient ce travail** > > L'algorithme et le code C# sont ceux de **Joshua Blackwood** ([EternityII_Solver](https://github.com/jblackwood345/EternityII_Solver), public sur GitHub sous licence GPL-3.0). Le décodage des rouages internes, ainsi que l'étude paramétrique rapportée ci-dessous, sont l'œuvre de Jef Bucas, dans son projet [wrapper_blackwood](https://github.com/jfbucas/wrapper_blackwood) ; les sections décodées reformulent et prolongent [ses notes](https://github.com/jfbucas/wrapper_blackwood/blob/main/doc/Notes/Notes.md) avec son autorisation explicite ([groups.io message 11905](https://groups.io/g/eternity2/message/11905)), et les figures sont les siennes, reproduites depuis ces mêmes notes. La dernière section, c'est [Raphaël Anjou](/fr/research/people/raphael-anjou/) construisant et exécutant le code de Blackwood sur une seule machine et rendant compte de ce qu'il a fait ; les trois petites modifications apportées à sa source y sont listées, chacune invitée par son propre README. Joshua Blackwood détient le record actuel de 470, trouvé avec un code qu'il a rendu public. Son solveur est, au fond, un backtracker classique en profondeur d'abord qui exécute la même boucle que n'importe quel autre : placer, vérifier, revenir en arrière. Ce qui en fait le moteur derrière les meilleures grilles de la communauté, c'est un ensemble d'heuristiques façonnées à la main et empilées par-dessus : une règle de score qui décide *quelles* pièces essayer en premier, un échéancier de quotas par profondeur qui élague les branches prenant du retard, un [ordre de remplissage](/fr/research/build/backtracking/fill-order/) réglé pour être « ni trop serré, ni trop lâche », et une tolérance aux mismatchs en fin de partie. Chacun de ces choix comporte des nombres, et l'étude de Jef Bucas a posé la question évidente : les nombres de Blackwood valent-ils quelque chose ? Oui, et c'en est gênant. Comme le code est un vrai programme C# compilable, on peut alors l'exécuter exactement tel que son auteur l'a écrit, ce que fait la dernière section ici. ## Noter les pièces selon trois couleurs Le solveur note chaque pièce d'après les couleurs de ses côtés, et il en privilégie exactement trois, une couleur de bordure et deux couleurs intérieures : ```csharp heuristic_sides = new List() { 13, 16, 10 }; ``` Les pièces portant ces couleurs sont triées en tête de chaque liste de candidats, de sorte que la recherche les engage tôt. Pourquoi ces trois-là ? C'est l'un des deux boutons que l'étude de Jef a manipulés (voir plus bas). Son échantillonnage suggère que les meilleurs scores connus proviennent de deux jeux de motifs distincts : > **[Figure]** interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. ## L'échéancier : une courbe de quotas sur 256 profondeurs Prioriser trois couleurs ne sert que si la recherche est *forcée* de les placer réellement. Le solveur porte donc un tableau de 256 entrées, une par profondeur, où chaque valeur est le nombre minimal de ces trois couleurs devant déjà figurer sur la grille pour continuer à descendre. Passez sous le quota et la branche est coupée sur-le-champ : retour en arrière, sans discussion. Blackwood a rempli ce tableau à la main, sous forme de rampe linéaire par morceaux : ```csharp heuristic_array = new int[256]; for (int i = 0; i < 256; i++) { if (i <= 16) heuristic_array[i] = 0; else if (i <= 26) heuristic_array[i] = (int)(((float)i - 16) * (float)2.8); else if (i <= 56) heuristic_array[i] = (int)((((float)i - 26) * (float)1.43333) + 28); else if (i <= 76) heuristic_array[i] = (int)(((((float)i - 56) * (float)0.9)) + 71); else if (i <= 102) heuristic_array[i] = (int)(((((float)i - 76) * (float)0.6538)) + 89); else if (i <= 160) heuristic_array[i] = (int)(((((float)i - 102) / 4.4615)) + 106); } ``` Libre jusqu'à la profondeur 16, raide dans la vingtaine, puis s'aplatissant jusqu'à la profondeur 160. C'est l'« échéancier » du schedule-and-break-index : un calendrier fixé d'avance pour épuiser les couleurs à forte fréquence, imposé comme un élagage strict. > **[Figure]** interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. ## L'ordre de remplissage : ni trop serré, ni trop lâche La recherche démarre en bas à gauche de la grille (le coin le plus proche de la pièce centrale obligatoire) et effectue un balayage de lignes standard jusqu'à la profondeur 180. Ensuite, elle intercale les pièces de bordure restantes (y compris le troisième coin) tous les quelques pas, parmi les placements intérieurs. C'est une voie médiane délibérée. Rentrer en spirale (l'anneau de bordure d'abord) engage trop tôt les pièces les plus contraintes ; un balayage de lignes pur les laisse toutes pour la fin, où elles vous tendent une embuscade. L'ordre de Blackwood relâche la pression de bordure progressivement. Pourquoi l'ordre compte-t-il autant, et comment le noter avant de l'exécuter, c'est exactement ce que formalise la [théorie de la complexité](/fr/research/why/complex-theory/). > **[Figure]** interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. ## Les breaks : acheter la fin de partie avec des mismatchs À l'approche de la fin de la recherche, le solveur cesse d'exiger la perfection. Un budget de mismatchs d'arêtes se déverrouille avec la profondeur, de façon cumulative : un break est autorisé à partir de la profondeur 201 (il peut être dépensé à 201 ou à n'importe quelle profondeur ultérieure), un deuxième à partir de 206, et ainsi de suite : ```csharp break_indexes_allowed = new List() { 201, 206, 211, 216, 221, 225, 229, 233, 237, 239 }; ``` Dix breaks au total, le dernier se déverrouillant à la profondeur 239. C'est ce qui rend les [grilles record](/fr/research/records/) atteignables tout court : un 256 parfait n'a jamais été trouvé, mais une grille qui tolère une poignée de mismatchs tardifs, c'est quelque chose qu'un backtracker peut réellement terminer. Deux détails affinent le tableau. D'abord, le budget s'accompagne d'une discipline : jamais deux breaks ne sont autorisés à se toucher : chaque mismatch doit rester isolé au milieu d'arêtes appariées. Blackwood en énonce lui-même la conséquence : toute exécution qui atteint 255 placements se complète automatiquement à 256, et une grille 469 est de manière équivalente un partiel de 249 pièces avec sept trous ([groups.io message 10051](https://groups.io/g/eternity2/message/10051)). Ensuite, la liste de dix entrées ci-dessus est elle-même un réajustement : en planifiant le passage de 469 à 470, Blackwood a ramené le budget de breaks de onze profondeurs à dix, un changement qu'il a documenté, levier par levier, dans son propre plan de réglage ([groups.io message 10076](https://groups.io/g/eternity2/message/10076)). Les points de déverrouillage décalés qu'il esquissait dans ce plan n'ont jamais été adoptés (le code 470 publié conserve les points de l'ère 469 et abandonne simplement le onzième), et c'est cet échéancier resserré qui a trouvé le 470. ## Redémarrages, aléatoire, et un plafond de 50 milliards de nœuds Un backtracker par balayage de lignes remonte rarement jusqu'à ses premières lignes, si bien qu'une mauvaise ouverture peut échouer une exécution entière dans une région impossible. La réponse de Blackwood est économique et efficace : rendre l'ouverture aléatoire (le premier coin et les pièces de la ligne du bas sont mélangés à chaque tentative, de sorte que deux exécutions ne retracent jamais le même préfixe) et plafonner chaque tentative à 50 milliards de nœuds explorés. Atteignez le plafond, abandonnez, [redémarrez](/fr/research/build/backtracking/restarts/) avec une nouvelle ouverture, et partez en chercher une plus fertile. ## Le faire tenir en cache Le dernier ingrédient est la sympathie mécanique. Les pièces candidates vivent dans des tables de correspondance par position, et chaque entrée est une structure compacte (numéro de pièce, rotation, les deux côtés exposés, un compteur de breaks et un compteur heuristique) dimensionnée pour que l'ensemble de travail tienne dans le cache du processeur : ```csharp public struct RotatedPiece { public ushort PieceNumber { get; set; } public byte Rotations { get; set; } public byte TopSide { get; set; } public byte RightSide { get; set; } public byte Break_Count { get; set; } public byte Heuristic_Side_Count { get; set; } } ``` C'est la moitié « débit » de l'histoire : la même conception que [Peter McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) a plus tard poussée jusqu'à des centaines de millions de placements par seconde. ## D'un unique 468 à une vague de records L'histoire du solveur est aussi instructive que ses rouages. Blackwood est arrivé en parfait outsider : son 468, la première avancée au-delà du [467 de Louis Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/) en douze ans, a atteint la liste de diffusion de seconde main, relayé depuis un post Reddit ([groups.io message 10032](https://groups.io/g/eternity2/message/10032)). Trois jours plus tard, il a ouvert le code du solveur, avec des heuristiques qu'il estimait « deux fois meilleures » que l'exécution du 468 ([message 10037](https://groups.io/g/eternity2/message/10037)) ; Jef Bucas l'avait en marche sous Mono sur Ubuntu presque immédiatement ([message 10038](https://groups.io/g/eternity2/message/10038)). En une semaine, Peter McGavin, en l'exécutant « sur environ deux cents cœurs », a atteint 469 ([message 10045](https://groups.io/g/eternity2/message/10045)). Bucas a ensuite réécrit l'algorithme en C pour environ le double de vitesse ([message 10065](https://groups.io/g/eternity2/message/10065)), une vague de nouvelles grilles 469 a suivi en quelques semaines, et le générateur de code derrière la réécriture a été publié sous le nom de [libblackwood](https://github.com/jfbucas/libblackwood) ([message 10078](https://groups.io/g/eternity2/message/10078)). Quand Blackwood a posté son 470 en mars 2021, il provenait de ce même code public. Ses propres mots, au sujet de la republication du dépôt après qu'il fut discrètement passé en privé : « C'est le code exact utilisé pour trouver un 470 » ([message 10161](https://groups.io/g/eternity2/message/10161)). Un record, mis en open source, est devenu une machine à records communautaire. ## L'étude paramétrique de Jef : wrapper_blackwood Tout ce qui précède décrit *comment* le solveur fonctionne. Jef Bucas a construit [wrapper_blackwood](https://github.com/jfbucas/wrapper_blackwood) pour se demander si ses nombres sont *justes*. Le dispositif est une petite [expérience distribuée](/fr/research/build/faster/distributed-solving/) : un serveur Python distribue des tâches par HTTP, où chaque tâche est une variante des paramètres du solveur. Les clients (un worker par cœur) récupèrent une tâche, génèrent la source C# à partir de templates avec cette variante intégrée, la compilent avec Mono, l'exécutent, et renvoient le résultat au serveur pour analyse. Deux paramètres ont eu droit au traitement : - **Les trois couleurs priorisées.** En échantillonnant de nombreux jeux différents de trois motifs, et en enregistrant la profondeur atteinte par l'algorithme avec chacun, sa [page de résultats](https://github.com/jfbucas/wrapper_blackwood/blob/main/doc/batch00_edge_combos_stats.html) associe chaque combinaison d'une couleur de bordure et de deux couleurs intérieures à la profondeur qu'elle a atteinte, accompagnée d'une carte de chaleur indiquant où, sur la grille, la recherche a passé son temps. Les meilleurs scores connus se concentrent sur deux jeux de motifs distincts. - **L'échéancier de quotas.** En exécutant de nombreuses variantes aléatoires du tableau heuristique de 256 entrées et en traçant la profondeur atteinte par chacune (plus c'est vert, mieux c'est), la courbe façonnée à la main par Blackwood tombe en plein milieu de la région verte. > **[Figure]** interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. ## Ce que le réglage manuel a réussi Ce dernier résultat mérite qu'on insiste. Blackwood a rempli son échéancier à la main : cinq segments linéaires, des coefficients estimés à l'œil. Lorsqu'un balayage aléatoire a exploré le voisinage autour de lui, la ligne réglée à la main se situait franchement dans la zone la plus performante. La conclusion de Jef, et la nôtre : les paramètres d'origine étaient presque optimaux. Le vieux conseil tient toujours. Avant de refondre les heuristiques d'un solveur record, vérifiez si son auteur n'a pas déjà trouvé l'optimum local à la main. > **Les propres résultats négatifs de Blackwood** > > Blackwood a mené le même audit sur lui-même. Après le 469, il a catalogué ses impasses sur la liste de diffusion ([groups.io message 10056](https://groups.io/g/eternity2/message/10056)) : éliminer quatre couleurs tôt au lieu de trois (aucun gain), réserver des couleurs pour la fin de partie (pire), des solveurs SAT tels que kissat, cryptominisat et Google OR-tools (médiocre), l'accélération GPU, et la mise en cache de tous les blocs 2×2 pré-résolus (mesurée, puis abandonnée). La seule chose qui ait jamais payé, c'est le raffinement des heuristiques elles-mêmes, valant encore un facteur ~2. C'est la même conclusion que le balayage de Jef, atteinte par l'autre bout : l'échéancier est la magie, pas la technologie brute. ## Répliquer l'étude Une réserve sur l'étude paramétrique, et elle est de Jef lui-même : les effectifs d'échantillons derrière ces résultats sont faibles, et il n'est pas sûr à 100 % de ses conclusions. Ses notes le disent clairement : il serait bon de tenter de reproduire ces résultats, pour les valider ou les invalider. Il offre ses échantillons, et le harnais [wrapper_blackwood](https://github.com/jfbucas/wrapper_blackwood) est public : dirigez quelques machines vers le serveur, relancez les balayages, et postez ce que vous trouvez sur la [liste de diffusion](https://groups.io/g/eternity2). Une réplication indépendante confirmerait ou réfuterait les conclusions, et l'un comme l'autre serait une véritable contribution. ## L'exécuter ici L'étude ci-dessus audite les paramètres de Blackwood ; cette dernière section audite autre chose : ce que fait son programme publié quand on le construit soi-même et qu'on le confronte au vrai puzzle, sur un seul cœur, sur ma machine. ### D'où vient le code La source est son dépôt public, [github.com/jblackwood345/EternityII_Solver](https://github.com/jblackwood345/EternityII_Solver), sous licence GPL-3.0. Il se construit sans modification sur .NET 8. Il n'est pas recopié ici : la licence comme les bonnes manières commandent de le lier, non de l'embarquer ; il a donc été cloné dans un répertoire temporaire, exécuté, et seuls les nombres ont été conservés. ### Ce qui a été modifié pour l'exécuter Son programme est écrit pour tourner sur le nombre total de cœurs d'une machine et pour ne sauvegarder que les grilles quasi complètes. Pour le mesurer sur un seul cœur, et pour voir quoi que ce soit en deçà d'une résolution complète, trois modifications ont été faites, chacune invitée par son propre README (« changez le nombre de cœurs », « changez la fonction de sauvegarde ») : - **Un seul thread de recherche.** Sa constante `number_virtual_cores` vaut 64 par défaut. Son `Parallel.For(1, N)` lance `N-1` workers, donc la fixer à 2 donne exactement un thread de recherche. - **Une ligne de progression.** Sans modification, dans une exécution bornée, il n'affiche que « Solving... ». Une seule ligne ajoutée rapporte le placement le plus profond atteint, de sorte qu'une exécution qui ne se termine pas produise tout de même un nombre. - **Un seuil de sauvegarde plus bas, et l'épinglage des indices** pour l'exécution contrainte ci-dessous. ### Tel que publié : rapide, et visant l'unique indice qui contraint Exécuté tel que son code se présente, sur un seul cœur pendant 60 secondes, il est rapide et va loin : - **248 / 256 pièces placées**, une grille qui se recote à **454 / 480** arêtes appariées. - **~18,9 millions de nœuds par seconde** (un nœud est une tentative de placement). Son programme publié n'a aucune notion d'indice : il traite chaque pièce, y compris les pièces spéciales, comme ordinaire et maximise les arêtes appariées brutes. C'est moins un compromis qu'il n'y paraît d'abord, car une grille Eternity II légale n'a qu'**une** contrainte contraignante, l'indice central obligatoire (la pièce 139 dans sa cellule centrale, dans son orientation donnée) ; les quatre autres « indices » du puzzle étaient des indices bonus lâchés par le concepteur, non des exigences. Sa fameuse grille **470** en est la preuve : dans le [visualiseur](/viewer/), elle se vérifie comme indices respectés **1 / 5**, le seul respecté étant le centre, et un seul suffit à une grille légale. Maximiser les arêtes sans logique d'indices n'est pas un raccourci contournant le puzzle ; c'est une manière légitime de s'attaquer à la seule contrainte qui compte. Les huit dernières cellules de cette grille 454 sont une véritable impasse : aucun agencement des huit pièces restantes ne les complète de façon parfaitement appariée. (Pour le plaisir, en confiant cette grille à [notre ALNS](/fr/research/build/local-search/local-search-alns/) pendant 30 secondes, il a rempli les huit et l'a poussée à 462 en réarrangeant la région.) ### Avec les indices épinglés : ça cale Épingler les pièces indices dans leurs cellules force le moteur à les respecter au lieu de les placer là où elles s'ajustent. Le même code, les cinq indices officiels épinglés, 120 secondes, un seul cœur : - **Placement le plus profond : environ 45 / 256.** Son heuristique d'ordre de balayage n'a rien à quoi s'accrocher dès que les pièces spéciales sont fixées en milieu de grille : elle patauge près des lignes du bas et ne remonte jamais. Épingler les cinq est plus strict que le puzzle ne l'exige à proprement parler (seul l'indice central est obligatoire), mais c'est la même contrainte à laquelle sont soumis les autres moteurs ici, et Blackwood atterrit bien en dessous du [438 de la réimplémentation Verhaard](/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/) ou du [204 de McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) sous la même contrainte. > **Une réserve fidèle** > > Cet épinglage d'indices est grossier : il interdit toute autre pièce aux cinq cellules d'indices et réserve ces pièces. Une refonte tenant compte des indices chercherait au contraire vers l'extérieur à partir des indices, et ferait mieux. 45 est donc un plancher pour « son code publié avec des indices boulonnés dessus », non un verdict sur l'approche. Son record 470 a été trouvé avec ce code plus une grande quantité de calcul et de chance, pas en deux minutes. ## À lire aussi - [Le backtracker C de McGavin : l'histoire du débit, reconstruit ici](https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/backtracker/) — Le backtracker C de Peter McGavin, le plus rapide de la communauté : une recette d'optimisation de 2007 capitalisée pendant deux décennies via code généré, tables de correspondance et astuces de compteur, puis compilée sur mon M1 et pointée vers le vrai puzzle à 256 pièces, où en mono-cœur elle dépasse 200 des 256 pièces à ~109M placements/s. - [eii de Verhaard : le solveur qui a remporté l'unique prix](https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/eii/) — Le moteur derrière le 467, le seul score d'Eternity II jamais récompensé, reconstitué à partir des propres messages de Louis Verhaard sur la liste de diffusion : élagage prospectif, ordres de remplissage en peigne, décalage d'arête conditionné par la profondeur, calendrier de décalage réglé par chaîne de Markov. Et pourquoi son propre binaire Win32, sans code source, ne peut être ni compilé ni exécuté sur cette machine. - [Benchmark mono-cœur](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/) — Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Comment cherchent les solveurs record](https://eternity2.dev/fr/research/build/solvers/) — Comment cherchent réellement les solveurs qui détiennent les records. Ce sont tous, au fond, des backtrackers en profondeur d'abord ; ce qui les distingue, c'est l'ordre dans lequel ils essaient les choses et la manière dont ils assouplissent les règles à l'approche de la fin. --- # L'eii de Louis Verhaard > L'eii de Louis Verhaard a remporté le seul prix que le puzzle ait jamais payé, mais il n'existe que sous forme de binaire Windows sans code source. En quoi consiste sa méthode, pourquoi l'original ne tourne pas ici, et où vit une réimplémentation fidèle. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/ - Mise à jour: 2026-07-15 --- Cette section porte sur l'eii de [Louis Verhaard](/fr/research/people/louis-verhaard/), le solveur qui a trouvé le 467 et remporté l'unique prix du puzzle. Contrairement à McGavin et Blackwood, il n'a jamais publié son code source : son propre programme ne peut donc pas être exécuté ici. Cette page consigne sa méthode et ce manque ; le moteur exécutable est une [réimplémentation](/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/), conservée dans la section de Raphaël Anjou parce que le code qui s'y trouve n'est pas celui de Verhaard. ## Pages de cette section - [eii de Verhaard : le solveur qui a remporté l'unique prix](https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/eii/) — Le moteur derrière le 467, le seul score d'Eternity II jamais récompensé, reconstitué à partir des propres messages de Louis Verhaard sur la liste de diffusion : élagage prospectif, ordres de remplissage en peigne, décalage d'arête conditionné par la profondeur, calendrier de décalage réglé par chaîne de Markov. Et pourquoi son propre binaire Win32, sans code source, ne peut être ni compilé ni exécuté sur cette machine. - [Réimplémentation de Verhaard](https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/) — Une réimplémentation intégrale de la méthode eii de Louis Verhaard, son propre binaire n'étant livré sans aucune source et refusant de tourner ici. Recuit par échange de composition d'ensemble sous la métrique de pavage 2×2 ; sur le vrai puzzle à cinq indices, elle atteint 438 sur 480, en monocœur. --- # eii de Verhaard : le solveur qui a remporté l'unique prix > Le moteur derrière le 467, le seul score d'Eternity II jamais récompensé, reconstitué à partir des propres messages de Louis Verhaard sur la liste de diffusion : élagage prospectif, ordres de remplissage en peigne, décalage d'arête conditionné par la profondeur, calendrier de décalage réglé par chaîne de Markov. Et pourquoi son propre binaire Win32, sans code source, ne peut être ni compilé ni exécuté sur cette machine. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/eii/ - Mise à jour: 2026-07-21 - Sujets: backtracking, local-search, speed - Source: Détails du solveur eii de Louis Verhaard (l'original, Win32 uniquement) — https://www.shortestpath.se/eii/eii_details.html - Source: La mise à disposition : « je suis bloqué… mon seul espoir est la force brute » (groups.io message 5940) — https://groups.io/g/eternity2/message/5940 - Source: Décodeur et documentation des rouages publiés ; 467 trouvé plus de 40 fois (groups.io message 6275) — https://groups.io/g/eternity2/message/6275 - Source: La méthode dévoilée : décalage d'arête conditionné par la profondeur, score propre 247 (groups.io message 7321) — https://groups.io/g/eternity2/message/7321 - Source: Le banc d'essai indépendant de JSA : un 467 en 82 jours avec le binaire public (groups.io message 6687) — https://groups.io/g/eternity2/message/6687 - Source: Le point d'ancrage durable du solveur : shortestpath.se/eii (groups.io message 7439) — https://groups.io/g/eternity2/message/7439 - Source: Verhaard sur sa méthode (groups.io msg 6891) — https://groups.io/g/eternity2/message/6891 --- > **À qui revient ce travail** > > Le solveur, nommé **eii**, et sa documentation sont l'œuvre de **Louis Verhaard**, hébergée sur son propre site ([shortestpath.se/eii](http://www.shortestpath.se/eii/)). L'entrée gagnante a été soumise au nom de son épouse, Anna Karlsson ; les propres mots de Verhaard tranchent la question du crédit : « Ma femme a soumis ma meilleure solution l'an dernier et a gagné 10 000 dollars » ([groups.io message 7451](https://groups.io/g/eternity2/message/7451)). Cette page, rédigée par [Raphaël Anjou](/fr/research/people/raphael-anjou/), reconstruit la machine à partir des messages de Verhaard sur la liste de diffusion de 2008 à 2010 et du banc d'essai public de JSA sur le binaire diffusé, et consigne pourquoi le binaire original ne peut absolument pas être exécuté ici. Le moteur exécutable est une [réimplémentation](/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/) distincte, classée dans la section de Raphaël parce que ce code n'est pas celui de Verhaard. L'eii de Louis Verhaard est le solveur derrière le 467/480 qui a remporté le prix de finaliste de 10 000 dollars à la première date d'examen, la seule somme jamais versée par le concours Eternity II. Ce même score a ensuite tenu le record pendant douze ans, jusqu'au 468 de Joshua Blackwood en 2020. Comme [le moteur de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/), il est au fond un backtracker en profondeur d'abord, surmonté d'heuristiques réglées à la main. À la différence de celui de Blackwood, ses rouages n'ont jamais été publiés sous forme de code ; ce dont nous disposons à la place est un témoignage d'une qualité rare : Verhaard a lui-même documenté les heuristiques et l'ordre de recherche, discuté la conception sur la liste de diffusion à la première personne, et livré un binaire public qu'un utilisateur indépendant a mené par banc d'essai jusqu'au score du prix. C'est cette absence de code source qui explique pourquoi, des trois moteurs communautaires étudiés dans ce laboratoire, le sien est celui qui ne peut pas être exécuté du tout ; la dernière section dit exactement pourquoi. ## La trajectoire : bloqué au-delà de 463, alors autant le diffuser Le récit fondateur de Verhaard désarme. Son premier programme de haut score ne plaçait que des pièces s'ajustant parfaitement, et plafonnait vers 450 : des centaines de partiels propres à 248 pièces, sans issue. Ce n'est qu'en essayant le solveur de Bob Cousins (à l'origine celui de Dave Clark), qui a trouvé un 458 en moins d'une minute, qu'il a saisi que le concours comptait les *arêtes concordantes*, si bien que les placements à moitié ajustés comptent eux aussi ([groups.io message 5767](https://groups.io/g/eternity2/message/5767)). De son propre aveu, il ne s'était jamais donné la peine de lire les règles ; Jef Bucas renvoyait encore les lecteurs vers cet aveu dans la documentation de Verhaard en 2021 ([groups.io message 10582](https://groups.io/g/eternity2/message/10582)). Au cours de l'été 2008, le plafond publiquement visible de la communauté était de 463 ([groups.io message 5688](https://groups.io/g/eternity2/message/5688)), et dans un échange remarquable Verhaard et Max ont confronté leurs notes, en tant que seuls deux à être connus pour avoir dépassé ce qu'ils appelaient la « limite-dont-on-ne- parle-pas » ([messages 5767–5787](https://groups.io/g/eternity2/message/5767)). Puis, le 22 septembre 2008, à trois mois de la première date d'examen, Verhaard a publié le solveur pour que quiconque puisse le faire tourner sur fingerboys.se : « Ceci parce que je suis bloqué et que mon seul espoir d'améliorer mon meilleur score passe par la force brute » ([message 5940](https://groups.io/g/eternity2/message/5940)). Les conditions calquaient celles d'eternity2.net : il fallait posséder le vrai casse-tête, et tout prix serait partagé à parts égales entre l'utilisateur ayant le meilleur score et Verhaard. La communauté est devenue sa ferme de calcul. Cela a marché. Le 6 janvier 2009, il a diffusé un décodeur pour les fichiers de sortie `.eii` du solveur, documenté les rouages (heuristiques et ordre de recherche), et dévoilé le nombre que la ferme avait atteint : 467, trouvé plus de 40 fois par différents utilisateurs ([message 6275](https://groups.io/g/eternity2/message/6275)). Neuf jours plus tard, l'annonce de Tomy est apparue : aucune solution complète, et un prix de finaliste de 10 000 dollars pour Anna Karlsson de Lund pour 467 sur 480 ([message 6337](https://groups.io/g/eternity2/message/6337)). Il a fallu à la liste environ une heure pour décoder « Lund + 467 ». Le reste de l'histoire du concours revient à [la page d'histoire](/fr/research/community/hunt/) : le silence de Tomy, la couverture presse, les suites. Ce qui suit ici, c'est la machine. ## Élagage prospectif contre des seuils statiques La boucle de base est un backtracker en profondeur d'abord sur un [ordre de remplissage](/fr/research/build/backtracking/fill-order/) fixe, mais qui élague par anticipation : les branches dont le score heuristique tombe sous un seuil sont coupées avant d'être explorées. Verhaard décrivait ses seuils comme statiques et réglés à la main : « surtout fondés sur de purs tâtonnements et sur une part limitée de théorie ou de mesures », lents à régler mais prévisibles sur de longues exécutions ([groups.io message 5771](https://groups.io/g/eternity2/message/5771), qu'on lui cite en retour dans le [message 5772](https://groups.io/g/eternity2/message/5772)). À quoi servent les seuils *au juste* ? La conception sur laquelle Max et lui ont convergé dans cet échange en est la part intéressante : on ne peut influer sur la sélection des pièces que tôt dans la recherche, mais ce que l'on veut maximiser, c'est la **pavabilité des pièces restantes** profondément dans le remplissage, autour des pièces 160 à 200, là où le facteur de branchement s'effondre vers des coups forcés. Les seuils précoces sont donc réglés, de façon semi-manuelle, pour répondre à la question : quel score heuristique les partiels précoces doivent-ils atteindre pour que les survivants portent un jeu de pièces restantes qui se pave encore bien ? Le verdict de Verhaard sur la description de Max : « Je crois qu'après tout nous travaillons de manière très semblable » ([message 5780](https://groups.io/g/eternity2/message/5780)). ## Le tableau de bord : où culmine la distribution des nœuds Comment sait-on qu'une heuristique est forte ? La mesure sur laquelle les deux se sont arrêtés (proposée par Max, adoptée par Verhaard) est l'endroit où se situe le pic de la distribution des nœuds par profondeur. Une recherche exhaustive sans heuristique sur E2 passe le plus clair de son temps autour de la profondeur 161, le chiffre de référence de Brendan Owen ([message 6112](https://groups.io/g/eternity2/message/6112)) ; leurs deux recherches heuristiques avaient poussé le pic juste sous 170 ([message 5780](https://groups.io/g/eternity2/message/5780)). Max a fourni l'interprétation : un pic à 170 équivaut à peu près à éliminer entièrement une couleur intérieure du casse-tête ; une « heuristique tueuse » qui en éliminerait deux semblait hors de portée ([message 5787](https://groups.io/g/eternity2/message/5787)). ## Recherche en peigne : un ordre de remplissage pour les hauts scores Une recherche de solution complète veut un balayage ligne par ligne ; une recherche de haut score vit plus profondément dans le plateau, et veut une frontière différente. Quand Brendan Owen a posé exactement cette question, Verhaard a révélé la forme de sa réponse : les meilleurs ordres qu'il avait trouvés ressemblent à une **recherche en peigne** (la plupart des lignes parcourues horizontalement, puis les lignes restantes parcourues verticalement), avec une longueur de dents liée à la cible : « Plus le score que vous visez est bas, plus les dents du peigne s'allongent » ([groups.io message 6112](https://groups.io/g/eternity2/message/6112)). Max avait convergé indépendamment vers une géométrie presque identique (douze lignes en balayage, puis balayage par colonnes) et rapportait que ses scores tournaient à environ une arête en dessous des « résultats que le solveur de Louis obtient » ([message 6126](https://groups.io/g/eternity2/message/6126)). ## Décalage d'arête, conditionné par la profondeur Le levier qui a réellement décroché le 467 est une imperfection délibérée. Interrogé directement à ce sujet un an plus tard, Verhaard a été précis : le programme du 467 cherche « normalement », mais à certaines profondeurs il autorise le **décalage d'arête** : placer une pièce présentant une arête discordante contre un voisin déjà posé. Il ne construit pas d'abord un partiel propre pour ensuite en rapiécer les trous ; les discordances sont budgétées *dans la descente elle-même*, débloquées à des profondeurs choisies. Et l'anatomie du résultat est parlante : la plupart des plateaux à 467 qu'il a examinés avaient un score propre de seulement 247, avec treize arêtes décalées dépensées là où le calendrier le permettait ([groups.io message 7321](https://groups.io/g/eternity2/message/7321)). Le 467 n'était pas non plus un coup de chance : il l'a trouvé plus de 50 fois ([même message](https://groups.io/g/eternity2/message/7321)). La technique elle-même a [sa propre page](/fr/research/build/reduce/edge-slipping/) : pourquoi des discordances programmées atteignent des plateaux qu'une recherche propre n'atteindrait jamais, et la théorie du dénombrement derrière le coût de chaque arête concordante supplémentaire. Ce qui a sa place ici, c'est la machinerie côté solveur : le budget de discordances par profondeur est un **tableau de décalage**, une entrée par profondeur, et c'est un objet réglé, non un tâtonnement. ## L'optimiseur du tableau de décalage : une chaîne de Markov En janvier 2009, dans le fil où Owen étendait la [théorie du complexe](/fr/research/why/complex-theory/) pour couvrir les décalages, Verhaard a publié l'esquisse (avec des extraits Java) de l'algorithme qu'il utilisait pour optimiser l'ordre de recherche et le tableau de décalage d'eii ([groups.io message 6423](https://groups.io/g/eternity2/message/6423)). L'entrée est un ordre de recherche candidat plus un tableau de décalage. Pour chaque profondeur, il estime deux nombres à partir d'exécutions expérimentales (la théorie suffirait pour démarrer, notait-il) : la probabilité qu'une pièce restante prise au hasard s'ajuste parfaitement, et la probabilité qu'elle s'ajuste avec une arête décalée. De là il construit une chaîne de Markov dont l'état est *(profondeur, arêtes décalées jusqu'ici)*, avec des transitions pour un placement propre et, là où le tableau de décalage l'autorise, pour un placement décalé. Faire tourner la chaîne de bout en bout donne la probabilité d'atteindre le bas et le nombre de nœuds attendu : un évaluateur en boucle fermée, peu coûteux, pour tout couple (ordre, calendrier de décalage), mémoïsé par souci d'efficacité. Il en a signalé lui-même la limite : le modèle simple ignore la parité des décalages, si bien qu'il devient peu fiable pour des scores cibles très élevés. L'air de famille avec ce qui est venu une décennie plus tard est difficile à manquer : les indices de rupture de Blackwood sont eux aussi un budget de discordances conditionné par la profondeur, et son calendrier de quotas est lui aussi une courbe pré-engagée, par profondeur, réglée à la main plutôt qu'optimisée par chaîne. La filiation passe par ce solveur. ## Le frère jumeau au score propre Les mêmes heuristiques animaient un second programme doté d'un coup de fin de partie différent : au lieu de décaler une arête, il peut *sauter une case*, c'est-à-dire laisser une cellule vide et poursuivre. Le nom est de lui ([message 7321](https://groups.io/g/eternity2/message/7321)). C'est le chasseur de score propre (sans discordance). Avec lui, Verhaard a rempli 14 lignes complètes plus deux pièces, un partiel impeccable de 226 pièces et le record dont il avait connaissance à l'époque ([groups.io message 6303](https://groups.io/g/eternity2/message/6303)). Lors d'un retour d'une journée en décembre 2009, après avoir estimé environ 2 000 partiels de 248 par 249, il a décroché trois 249 d'affilée et s'est arrêté, situant un 250 à peu près 4 000 fois plus difficile ([message 7306](https://groups.io/g/eternity2/message/7306)). Interrogé à ce sujet une décennie plus tard, il a confirmé que le 249 sur son site est réel : environ une semaine de calcul sur une seule machine ([message 9890](https://groups.io/g/eternity2/message/9890)). ## La reproduction publique : 82 jours pour un 467 Parce que le binaire était public, le 467 est le rare record de l'ère du concours doté d'une reproduction indépendante et chiffrée. JSA a fait tourner eii en continu sur un seul PC et a consigné la distribution des scores à mesure qu'elle s'accumulait : - **43 jours :** 2 008 484 fois 463 · 109 195 fois 464 · 6 048 fois 465 · 250 fois 466 · rien de plus haut ([groups.io message 6571](https://groups.io/g/eternity2/message/6571)) - **62 jours :** 427 fois 466, arrivant à raison d'environ 5 à 6 par jour, et toujours aucun 467 ([message 6653](https://groups.io/g/eternity2/message/6653)) - **82 jours :** deux 467, aux côtés de 4 017 182 fois 463 · 227 245 fois 464 · 13 637 fois 465 · 625 fois 466 ([message 6687](https://groups.io/g/eternity2/message/6687)) Ce dernier relevé est la mesure publique la plus nette de l'échelle exponentielle de rareté près du sommet : quatre millions de 463 pour deux ou trois 467, et un palier 466→467 qui a demandé à une seule machine près de trois mois. La formule de clôture de JSA, « Félicitations à Louis pour un algorithme bien pensé », fait aussi office de verdict de vérification. ## Ce qu'il a enseigné à la communauté Au-delà du score, eii a établi un précédent : quand on est bloqué, on diffuse le solveur et on laisse les machines de la communauté chasser, le partage du prix faisant office de contrat. Le 467 a été trouvé par des *utilisateurs* d'un binaire publié, plus de 40 fois, avant de remporter quoi que ce soit. Douze ans plus tard, [Joshua Blackwood a répété le schéma](/fr/research/lab/experiments/joshua-blackwood/solver/), en publiant un 468 et en ouvrant le code du moteur quelques jours après, et a récolté la même récompense : une vague de records communautaires sur son propre algorithme. L'autre leçon est méthodologique et traverse toute cette page : Verhaard a réglé son solveur contre des *modèles* plutôt que sur de simples impressions (le tableau de bord du pic de nœuds, l'évaluateur par chaîne de Markov), à une époque où cette discipline était rare. ## Où vit le code, et pourquoi il ne tournera pas ici Le point d'ancrage d'origine, fingerboys.se, était le site du groupe de musique de Verhaard ; quand le groupe a cessé de maintenir le site, le solveur a disparu avec lui pendant des mois. En janvier 2010, Verhaard l'a republié, inchangé, sur [shortestpath.se/eii](http://www.shortestpath.se/eii/) ([groups.io message 7439](https://groups.io/g/eternity2/message/7439)) ; cette adresse reste son point d'ancrage, et la source de première main derrière la ligne 467 dans [le tableau des records](/fr/research/records/). Une note opérationnelle issue des questions-réponses qui ont suivi : le solveur ne garde aucune mémoire des positions passées, si bien que ses milliers de plateaux à 463–465 ne sont pas dédoublonnés ([message 7451](https://groups.io/g/eternity2/message/7451)). Ce que « le code vit là » dissimule, c'est qu'aucun *code source* ne vit nulle part. Ce que Verhaard a livré, c'est `eii-1.0-win32.zip` : un `eii.exe` Windows, un lisez- moi, et quelques fichiers `.bat`. Il y a **zéro fichier source**, et c'est du Win32 uniquement. Cela ne tourne pas sur Apple silicon, et il n'y a sur cette machine ni couche Windows ni couche d'émulation pour l'exécuter. Son artefact est, ici, inexécutable, et il n'y a rien de lui à récupérer et compiler. Les ordres de remplissage en peigne et le calendrier de décalage conditionné par la profondeur décrits plus haut sont devenus un canon communautaire précisément parce qu'ils ont été récupérés depuis ses messages et, quand ils étaient numériques, à l'octet près depuis les chaînes de caractères à l'intérieur d'`eii.exe`, puisque ce binaire est le seul enregistrement survivant de ces éléments. Ainsi, « faire tourner Verhaard » tout court signifie reconstruire sa méthode à partir de cette documentation. C'est ce que fait la [réimplémentation de Verhaard](/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/), et sur le vrai casse-tête à cinq indices elle atteint 438 sur 480, en monocœur. Ce moteur est classé dans la section de Raphaël, pas dans celle-ci, parce qu'il est une lecture de la méthode de Verhaard, non le code de Verhaard. Nommer cette distinction fait partie du constat : des trois moteurs communautaires étudiés ici, le sien est celui qui ne peut pas être exécuté du tout. ## À lire aussi - [Réimplémentation de Verhaard](https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/) — Une réimplémentation intégrale de la méthode eii de Louis Verhaard, son propre binaire n'étant livré sans aucune source et refusant de tourner ici. Recuit par échange de composition d'ensemble sous la métrique de pavage 2×2 ; sur le vrai puzzle à cinq indices, elle atteint 438 sur 480, en monocœur. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [Le glissement d'arête](https://eternity2.dev/fr/research/build/reduce/edge-slipping/) — Le coup primé de Louis Verhaard : laisser le backtracker poser une pièce non concordante, mais seulement à des profondeurs choisies près du bas du plateau. Chaque glissement autorisé coûte un point de score et multiplie de façon astronomique le nombre de plateaux cibles. Voilà pourquoi son 467 a été trouvé plus de cinquante fois, et l'ancêtre direct des ruptures de Blackwood. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Comment cherchent les solveurs record](https://eternity2.dev/fr/research/build/solvers/) — Comment cherchent réellement les solveurs qui détiennent les records. Ce sont tous, au fond, des backtrackers en profondeur d'abord ; ce qui les distingue, c'est l'ordre dans lequel ils essaient les choses et la manière dont ils assouplissent les règles à l'approche de la fin. --- # Réimplémentation de Verhaard > Une réimplémentation intégrale de la méthode eii de Louis Verhaard, son propre binaire n'étant livré sans aucune source et refusant de tourner ici. Recuit par échange de composition d'ensemble sous la métrique de pavage 2×2 ; sur le vrai puzzle à cinq indices, elle atteint 438 sur 480, en monocœur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/ - Mise à jour: 2026-07-21 - Sujets: speed, local-search - Reproduire: `just experiments single-core-benchmark` - Source: Moteur exécutable + résultats versionnés + scripts (répertoire de référence de cette expérience) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark - Source: Détails du solveur eii de Louis Verhaard (l'original, Win32 uniquement) — https://www.shortestpath.se/eii/eii_details.html --- > **À qui revient ce travail** > > La **méthode** est [celle de Louis Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/). Le **code** présenté ici est une réimplémentation intégrale par [Raphaël Anjou](/fr/research/people/raphael-anjou/). Il est classé ici, dans la section de Verhaard, aux côtés de la méthode qu'il reconstruit, comme une reconstruction : une lecture de sa méthode, non son programme. La signature reste celle de Raphaël, car le code est le sien ; la section est celle de Verhaard, car l'idée l'est. L'eii original de Verhaard est un binaire Windows sans source qui [refuse de tourner ici](/fr/research/lab/experiments/louis-verhaard/eii/). Le seul moyen d'exécuter son approche est de la reconstruire, et c'est précisément cette reconstruction : le moteur même qui apparaît sous le nom `verhaard` sur la [grille](/fr/research/lab/experiments/single-core-benchmark/). ## Ce qu'elle réimplémente La méthode documentée de Verhaard : le **recuit par échange de composition d'ensemble** sous la métrique de pavage 2×2. On choisit un sous-ensemble intérieur d'environ 180 pièces, on recuit sa composition par échanges jusqu'à maximiser localement le nombre de sous-pavages 2×2 réalisables, on place en tête les pièces les plus problématiques, puis on cherche le reste sous cette ossature. Les constantes numériques du moteur ont été récupérées au bit près à partir des chaînes de caractères contenues dans `eii.exe`, ce binaire étant leur unique trace subsistante. Dire que l'on « fait tourner Verhaard » est un raccourci qu'il faut assumer : c'est une lecture de sa méthode, non de son code. Que ce soit le seul moyen d'exécuter son approche fait partie du constat. ## Ce qu'elle donne sur le vrai puzzle à cinq indices En monocœur, 120 secondes, les cinq indices officiels épinglés : - **438 / 480** arêtes appariées, un plateau **entièrement rempli** (256 pièces sur 256). - Les cinq indices respectés (une solution stricte aux indices), 42 arêtes rompues, à environ 40 millions de nœuds par seconde. L'exécution et le plateau produit sont versionnés dans le [répertoire de référence](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark) du moteur, et `just experiments single-core-benchmark` le relance, si bien que le 438 est vérifiable plutôt qu'affirmé. Il s'agit de l'instance à cinq indices, un puzzle plus difficile que les variantes à coins épinglés que note le [classement](/fr/research/lab/experiments/single-core-benchmark/), où le même moteur atteint un meilleur score de 451. Elle a trouvé 438 en une douzaine de secondes environ, puis a stagné sur le reste du budget : un authentique optimum local pour cette graine et ce temps. C'est la seule des trois réimplémentations communautaires présentes ici qui résolve bien le vrai puzzle à cinq indices, plutôt qu'une version plus facile, mais les trois ne mesurent pas la même chose, et la comparaison demande donc de la prudence. [Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) est mesuré sur la même base, arêtes appariées avec les indices épinglés, et cale autour de 45. [McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) ne l'est pas : son chiffre est une *profondeur* de placement (environ 204 pièces sur 256 atteintes), non un score d'arêtes appariées, si bien qu'il ne peut se lire sur le même axe que le 438 d'ici, et les deux nombres ne sont pas directement comparables. Ce que les trois partagent, c'est seulement le verdict selon lequel le puzzle contraint est bien plus dur que le puzzle libre ; les nombres qui sous-tendent ce verdict sont sur des échelles différentes. ## À lire aussi - [eii de Verhaard : le solveur qui a remporté l'unique prix](https://eternity2.dev/fr/research/lab/experiments/louis-verhaard/eii/) — Le moteur derrière le 467, le seul score d'Eternity II jamais récompensé, reconstitué à partir des propres messages de Louis Verhaard sur la liste de diffusion : élagage prospectif, ordres de remplissage en peigne, décalage d'arête conditionné par la profondeur, calendrier de décalage réglé par chaîne de Markov. Et pourquoi son propre binaire Win32, sans code source, ne peut être ni compilé ni exécuté sur cette machine. - [Benchmark mono-cœur](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/) — Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. --- # Comment le laboratoire publie > Le standard éditorial de ce carnet ouvert : comment un travail de recherche sur Eternity II passe d'un travail non publié à une page publiée. De quel type de contribution il s'agit, s'il est publié, à quel niveau, et où il réside. Un standard commun, conçu pour s'étendre à de nombreux auteurs. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/methodology/ - Mise à jour: 2026-07-21 --- Cette page constitue le standard éditorial qui sous-tend tout ce que contient le laboratoire. Elle existe pour qu'un résultat parvienne au lecteur sous la forme d'un objet rédigé, et non d'une note brute, et pour que les mêmes règles s'appliquent quel que soit l'auteur. ## Ce qui est publié, et ce qui ne l'est pas La règle de base sur laquelle tout repose : - **Le travail non publié n'apparaît pas ici.** L'endroit où un chercheur conserve ses travaux en cours ne regarde que lui. Cela ne figure tout simplement pas dans ce dépôt. Aucun brouillon inachevé ne traîne dans le carnet publié. - **Le travail publié réside dans le laboratoire.** Public, décanté, écrit pour un lecteur. Il est arrivé là après relecture. La publication se fait par pull request. Un chercheur ouvre une PR qui ajoute ou promeut une page, et c'est lors de la relecture de cette PR que se décide la publication, ainsi que le niveau auquel elle se fait. Rien n'entre dans les archives publiques sans PR, et c'est sur la PR qu'un second lecteur la confronte au standard décrit ci-dessous. Cela garde la relecture collégiale plutôt que d'en faire une barrière lourde, et cela s'étend à de nombreux auteurs. ## Trois axes décrivent chaque page Les tenir séparés, c'est toute la méthode. Il est facile de confondre « abouti », « reproductible » et « relu » en une notion vague de « terminé ». Ce ne sont pas la même chose. 1. **Contribution :** de quel type de résultat s'agit-il ? 2. **Niveau :** jusqu'où la relecture est-elle allée ? 3. **Rigueur et reproductibilité :** avec quelle fermeté l'affirmation est-elle étayée ? Plus l'attribution : qui a fait quoi. ## Axe 1 : la contribution Tout résultat n'est pas un solveur, et le carnet a cessé de faire comme si. Une page déclare sa contribution : - **solveur :** produit un plateau compétitif par recherche. Son score est un véritable résultat de recherche. Seuls ceux-là gagnent une ligne au classement. - **analyse :** démontre ou calcule une propriété d'un plateau existant ou de l'instance. Elle ne produit pas de nouveau plateau. - **reconstruction :** décode ou reconstitue le travail connu de la communauté pour en extraire un enseignement. Le nombre est le leur, décodé. - **théorie :** une propriété mathématique, une loi, ou une preuve d'impossibilité. - **méthode :** une technique décrite pour être réutilisée, non un run scoré. - **mesure :** un benchmark ou une observation empirique sur les solveurs ou les instances. - **résultat négatif :** une impasse explorée avec rigueur. À part entière, non reléguée en note de bas de page. - **outil** et **exposé :** un artefact logiciel, ou une explication. La distinction porteuse oppose le solveur à tout le reste. Un solveur par rencontre au milieu (meet-in-the-middle) qui prouve qu'une fin de partie est optimale est une analyse, non un solveur, et il n'a pas sa place sur un graphique de scores même s'il émet un nombre. C'est en réglant bien cet axe que le classement conserve un sens unique. Cet axe est aussi une surface de navigation : l'[index par contribution](/fr/research/lab/experiments/by-contribution/) regroupe les pages selon l'étiquette qu'elles déclarent, si bien que les analyses, la théorie, les mesures, et les [impasses gardées comme résultats négatifs à part entière](/fr/research/lab/experiments/by-contribution/negative/) ont chacune leur propre étagère. ## Axe 2 : le niveau Une fois publiée, une page porte un niveau qui indique avec quelle fermeté elle a été relue : - **Rapport technique :** public, mais la relecture a seulement confirmé qu'il est solide et rigoureusement présenté, et non qu'il a été vérifié de façon indépendante. La page porte un badge « rapport technique », de la même manière qu'un preprint est estampillé « pas encore relu ». Un état de repos légitime : tout n'a pas besoin d'aller plus loin. - **Résultat validé :** un second lecteur, ou le même auteur après un temps de décantation, a confirmé qu'il tient. Cité, traité comme quasi immuable ; les corrections se font sur place, annotées. Deux principes se transposent de la manière dont fonctionne la publication scientifique ailleurs. Le niveau est estampillé sur la page, si bien que le lecteur sait toujours ce qu'il a sous les yeux. Et la promotion se joue sur la rigueur, non sur le résultat : une méthode solide qui n'a rien trouvé est publiée comme résultat négatif, tandis qu'un résultat frappant obtenu par une méthode bancale ne l'est pas. ## Axe 3 : rigueur et reproductibilité Chaque page indique avec quelle fermeté son affirmation centrale est établie (prouvée, mesurée ou conjecturée) et à quel point elle est rejouable. Pour tout ce qui est quantitatif, le critère est simple : un nombre n'est publié que lorsque sa configuration exacte et sa graine (seed) sont archivées et qu'il peut être rejoué à partir de la documentation. Un score de benchmark sans configuration rejouable n'est pas publié. Les contributions moins coûteuses portent une exigence plus légère : un résultat négatif ou une explication demande un raisonnement solide et des limites clairement énoncées, non un script de reproduction. ## L'attribution, conçue pour plus d'auteurs Les pages de chaque chercheur se regroupent automatiquement sur sa page de contributeur, dérivées de la signature, jamais listées à la main. Ajouter un auteur revient à ajouter une entrée au registre et à écrire des pages en son nom. Lorsqu'une page a plus d'une main, un rôle de contributeur léger (qui l'a exécutée, qui l'a analysée, qui l'a validée, qui l'a rédigée) consigne la répartition, afin que le crédit reste juste à mesure que le laboratoire grandit. ## La décision, en bref Lorsqu'un travail est terminé : 1. **Nommer la contribution.** Solveur, analyse, reconstruction, théorie, méthode, mesure, résultat négatif, outil ou exposé. 2. **Décider s'il est publié.** On publie sur la rigueur, non sur l'enthousiasme. Une impasse solide est publiée. Un nombre sans configuration rejouable attend. 3. **Ouvrir une PR à un niveau.** Rapport technique s'il est rédigé mais pas encore vérifié de façon indépendante ; résultat validé une fois qu'un second lecteur l'a avalisé. 4. **Le placer.** Les solveurs et leurs semblables dans les expériences ; les résultats structurels dans pourquoi c'est difficile ; les techniques dans construire un solveur ; les mesures inter-solveurs avec les benchmarks. 5. **Ne le porter au graphique que si c'est un solveur.** Voilà tout le standard. Il est volontairement léger, car l'objectif est de relever le niveau plancher de chaque page sans ralentir le carnet. ## À lire aussi - [Le laboratoire](https://eternity2.dev/fr/research/lab/) — Le carnet ouvert du wiki : résultats structurels et expériences de recherche nommées, chacune attribuée au chercheur qui l'a menée et reproductible depuis les sources. Un coin de la recherche plus large de la communauté. - [Expériences](https://eternity2.dev/fr/research/lab/experiments/) — Les expériences de recherche nommées du laboratoire, une section par chercheur. Chacune est un run réel contre Eternity II avec son idée, son meilleur plateau et les questions qu'elle a laissées ouvertes. Le carnet de Raphaël Anjou est ici en entier ; le carnet reste ouvert à tous les autres. - [Contribuez vos recherches](https://eternity2.dev/fr/research/contribute/) — Ce wiki est le foyer de recherche de la communauté, et il y a de la place pour votre travail. Trois façons de le faire publier, du message sur la liste de diffusion à la pull request, plus le petit jeu de règles maison qui garde chaque page digne de confiance. --- # Le moteur de Peter McGavin > Le backtracker C que Peter McGavin a lui-même écrit, le solveur brut le plus rapide que la communauté ait mesuré. Récupéré sur la liste de diffusion, compilé sur un M1 et lancé sur le véritable Eternity II. Son code, son algorithme ; exécuté et documenté ici. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/ - Mise à jour: 2026-07-15 --- Cette section présente le solveur que [Peter McGavin](/fr/research/people/peter-mcgavin/) a écrit lui-même : le backtracker C qu'il a publié sur la liste de diffusion et qui, d'après les mesures de la communauté, est le moteur brut le plus rapide jamais exécuté. L'algorithme et le code sont de lui. Ce qui est ajouté ici, c'est l'exécution : récupéré depuis les sources, compilé sur une seule machine et pointé sur le véritable casse-tête, avec les chiffres documentés. ## Pages de cette section - [Le backtracker C de McGavin : l'histoire du débit, reconstruit ici](https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/backtracker/) — Le backtracker C de Peter McGavin, le plus rapide de la communauté : une recette d'optimisation de 2007 capitalisée pendant deux décennies via code généré, tables de correspondance et astuces de compteur, puis compilée sur mon M1 et pointée vers le vrai puzzle à 256 pièces, où en mono-cœur elle dépasse 200 des 256 pièces à ~109M placements/s. --- # Le backtracker C de McGavin : l'histoire du débit, reconstruit ici > Le backtracker C de Peter McGavin, le plus rapide de la communauté : une recette d'optimisation de 2007 capitalisée pendant deux décennies via code généré, tables de correspondance et astuces de compteur, puis compilée sur mon M1 et pointée vers le vrai puzzle à 256 pièces, où en mono-cœur elle dépasse 200 des 256 pièces à ~109M placements/s. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/backtracker/ - Mise à jour: 2026-07-21 - Sujets: speed, backtracking - Reproduire: `fetch genbody71.zip from groups.io msg 11749; gcc -Ofast -DG then without -DG` - Source: Le genbody71.zip de Peter McGavin (groups.io msg 11749, la source d'origine) — https://groups.io/g/eternity2/message/11749 - Source: La recette d'optimisation de Mike Field : « Brute force does not work » (groups.io message 3098, 2007) — https://groups.io/g/eternity2/message/3098 - Source: McGavin retrouve le fil de Field : « I found the old thread » (groups.io message 11338) — https://groups.io/g/eternity2/message/11338 - Source: La méthode 10×10 et les statistiques : 180 années-cœur (groups.io message 9688) — https://groups.io/g/eternity2/message/9688 - Source: L'annonce du 469 : quelques jours sur deux centaines de cœurs (groups.io message 10045) — https://groups.io/g/eternity2/message/10045 - Source: Table de débit multi-cœur, du Raspberry Pi au double Xeon (groups.io message 11369) — https://groups.io/g/eternity2/message/11369 - Source: Vitesses mono-cœur sur neuf combinaisons CPU/compilateur (groups.io message 11643) — https://groups.io/g/eternity2/message/11643 - Source: L'astuce du compteur et le manuel du compilateur (groups.io message 11751) — https://groups.io/g/eternity2/message/11751 - Source: 295M placements/s mesurés sur le code de McGavin (groups.io message 11750) — https://groups.io/g/eternity2/message/11750 --- > **À qui ce travail appartient** > > L'algorithme et le C sont le moteur auto-généré de **Peter McGavin** lui-même, publié sur la liste de diffusion. De son propre aveu, il repose sur une recette d'optimisation que Mike Field a publiée en 2007 ([message 3098](https://groups.io/g/eternity2/message/3098)), une dette qu'il a reconnue à deux reprises ([message 11338](https://groups.io/g/eternity2/message/11338), [message 11780](https://groups.io/g/eternity2/message/11780)). Un record est délibérément exclu de cette lignée : son 469 provient de l'exécution du [solveur de Joshua Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/), et non du sien ([message 10045](https://groups.io/g/eternity2/message/10045)). Cette page, c'est [Raphaël Anjou](/fr/research/people/raphael-anjou/) qui compile et exécute le code de McGavin sur une seule machine et qui documente ce qu'il a fait ; les seules modifications apportées à sa source sont les deux petites décrites ci-dessous. De fin 2010 à aujourd'hui, Peter McGavin est le bureau des théoriciens de la liste de diffusion et son chronomètre. C'est lui qui a mis en forme la [théorie complexe](/fr/research/why/complex-theory/) de Brendan Owen dans un article LaTeX ([message 9188](https://groups.io/g/eternity2/message/9188)), l'a réimplémentée comme référence C en 2024 ([message 11197](https://groups.io/g/eternity2/message/11197)), a résolu le [benchmark](/fr/research/build/benchmarks/) ouvert le plus difficile de la communauté et établi le record de 469 qui a tenu jusqu'au 470 de Blackwood. Mais sous tout cela court un projet plus discret, vieux de vingt ans : un simple backtracker à balayage de lignes en C, réglé jusqu'à compter les placements de tuiles par centaines de millions par seconde. Cette page retrace ce projet à travers ses propres chiffres publiés (d'où venait la vitesse, ce qu'elle a rapporté et ce que lui-même a dit qu'elle ne pourrait jamais faire), puis le compile ici et le pointe vers le vrai puzzle. ## La recette date de 2007, et il le dit En octobre 2007, en réponse à la question « d'où avez-vous entendu parler de 70 millions de pièces par seconde ? », Mike Field a publié un manuel complet d'optimisation sous le titre acéré « Brute force does not work » ([message 3098](https://groups.io/g/eternity2/message/3098)). Ses ingrédients : une table de correspondance indexée par les couleurs nord et ouest d'une cellule, si bien que trouver les pièces candidates ne coûte qu'un seul accès mémoire ; un ordre de recherche **fixe** exploité sans pitié (placer une pièce ne met à jour que ses voisins sud et est) ; aucune boucle du tout, mais du code monolithique *généré* procéduralement, un bloc en ligne droite par cellule ; un état minimal (reconstruire la jolie sortie plus tard, ne pas la stocker dans le chemin critique) ; les côtés d'une pièce empaquetés dans un seul entier ; et la lecture de l'assembleur généré à la chasse aux vidages de pipeline et aux défauts de cache L1. Le code de Field se compilait en environ 33 instructions par cellule et tournait à 60-80 millions de placements par seconde et par cœur sur un ordinateur de bureau de 2007, culminant près de 100 millions quand le jeu de travail restait dans le cache L1. Ce message est le génome du moteur de McGavin. Quand il a montré un extrait de son « affreux code source auto-généré » en 2024, on y reconnaissait le même organisme : un bloc étiqueté par cellule (`cell_9_2_next:`), une table `LookupNW` indexée par les couleurs nord et ouest, un tableau `tileFree`, des indications `register` et un `goto` de retour vers le bloc de la cellule précédente en cas d'épuisement ([message 11337](https://groups.io/g/eternity2/message/11337)). Il est parti à la recherche de l'origine quelques minutes plus tard et a publié le lien : « I found the old thread » ([message 11338](https://groups.io/g/eternity2/message/11338)) ; en 2026 il a répété l'attribution : son code C de backtracker optimisé « is based on » le message de Mike de 2007 ([message 11780](https://groups.io/g/eternity2/message/11780)). Field lui-même fournit la référence de l'époque. En 2011, il a rapporté son propre backtracker à 75 millions de tuiles placées par seconde et par cœur sur un AMD à 2 GHz, soit environ 26 cycles d'horloge par tuile, avec plus de la moitié du temps bloqué en attente d'accès mémoire ([message 9003](https://groups.io/g/eternity2/message/9003)). Ce chiffre, grosso modo 40 à 80 millions par cœur, est ce qu'un moteur communautaire sérieux a délivré pendant la décennie suivante, celui de McGavin compris. ## Ce qu'il a ajouté, dans ses propres mots La recette était publique ; la capitalisation est de McGavin. Les raffinements qu'il a décrits sur la liste, à peu près dans l'ordre où ils apparaissent : - **Un générateur de code, pas un programme.** Le C par cellule est régénéré pour chaque puzzle, jeu d'indices et [chemin de placement](/fr/research/build/backtracking/fill-order/). Son flux de travail de 2026 est un cycle compilation/exécution/compilation/exécution : la première passe reconstruit `body.c`, le code de cellule en ligne droite, et la seconde compile le solveur qui l'embarque. Sautez une étape après avoir modifié un fichier d'entrée et le programme « won't be doing anything sensible » ([message 11751](https://groups.io/g/eternity2/message/11751), [message 11782](https://groups.io/g/eternity2/message/11782)). En janvier 2026, il a publié l'ensemble sur la liste sous le nom `genbody71.zip` : 1 455 lignes de `genbody.c` plus un README, compilé avec `-DG` pour émettre `body.c` puis à nouveau sans pour construire le solveur qui l'inclut. Son propre avertissement ouvre le README : « This is experimental development code that evolved over several years --- not nice, elegant code at all » ([message 11749](https://groups.io/g/eternity2/message/11749)). - **Un compteur qui ne coûte presque rien.** `ntpll` (« number of tile placements per second long long », selon sa propre glose) n'est pas incrémenté directement. Un registre 16 bits est augmenté à chaque placement, et `0x10000` est ajouté au compteur 64 bits chaque fois qu'il déborde : un héritage des machines 32 bits où une incrémentation 64 bits gaspillait des registres ou touchait la RAM lente. Il a chronométré les deux approches il y a des années ; l'astuce l'a emporté. Sur les premières machines 64 bits, il était même plus rapide d'installer les bibliothèques de compatibilité 32 bits et de compiler avec `gcc -m32` ([message 11751](https://groups.io/g/eternity2/message/11751)). - **Archéologie du compilateur.** Compiler avec clang plutôt que gcc a donné « a significant speed boost » ([message 11330](https://groups.io/g/eternity2/message/11330)) ; sur ARM, clang-15 bat clang-19 et gcc ; ajoutez `-march=native` et `-mtune=native` ; essayez icc et icx ; utilisez l'optimisation guidée par profil ([message 11751](https://groups.io/g/eternity2/message/11751)). Rien de tout cela ne change la recherche. Cela change le nombre de recherches qu'un euro d'électricité permet d'acheter. - **Le chemin de placement comme choix mesuré.** Le balayage de lignes est le meilleur pour E2, mais la spirale entrante l'emporte sur les puzzles à indices 1 et 3, la bordure d'abord sur les 2 et 4, et la spirale sortante sur les variantes sans cadre ; il vérifie en lançant le solveur ou en interrogeant la théorie complexe, s'étant découvert « poor at judging solving orders » à l'œil ([message 9703](https://groups.io/g/eternity2/message/9703), [message 9713](https://groups.io/g/eternity2/message/9713)). ## Les chiffres, de 2007 à 2026 Chaque valeur ci-dessous provient de l'archive, dans les propres unités de son auteur. | Quand | Chiffre | Contexte | Source | | --- | --- | --- | --- | | 2007-10 | 60-80M placements/s/cœur, ~100M en pointe | Recette de Mike Field, AMD X2 3800+ | [3098](https://groups.io/g/eternity2/message/3098) | | 2011-02 | ~38M placements/s/cœur (2 300 × 10⁶/min) | McGavin comptant les coins 5x5 du 10x10 de Brendan, 4 cœurs ; 8672 est sa propre correction des unités (placements, pas solutions) | [8672](https://groups.io/g/eternity2/message/8672) | | 2011-06 | ~50M nœuds/s, mono-cœur | AMD Phenom II, balayage de lignes, 8x8 de Brendan | [8863](https://groups.io/g/eternity2/message/8863) | | 2011-11 | 75M/s/cœur (~26 cycles/tuile) | Référence de Field, AMD à 2 GHz, bloqué mémoire | [9003](https://groups.io/g/eternity2/message/9003) | | 2013-06 | 44,6M nœuds/s soutenus | un test de première ligne 10x10 à 683 milliards de nœuds | [9167](https://groups.io/g/eternity2/message/9167) | | 2014-04 | 67M placements/s, mono-cœur | Benchmark d'Arnaud Carré : les 4 solutions en moins d'une minute | [9263](https://groups.io/g/eternity2/message/9263) | | 2024-10 | 60-140M placements/s par backtracker | « depending on CPU type » | [11329](https://groups.io/g/eternity2/message/11329) | | 2024-11 | 99M → 10 160M nœuds/s par machine | Raspberry Pi 4 (4 processus) au double Xeon Gold 6338 (128) | [11369](https://groups.io/g/eternity2/message/11369) | | 2025-09 | 38-84M placements/s, mono-cœur | neuf combinaisons OS/compilateur/CPU sur le 8x8 de Brendan | [11643](https://groups.io/g/eternity2/message/11643) | | 2026-01 | ~225M placements/s, mono-cœur | Orange Pi 6 Plus sur petits puzzles ; « halves on 16x16 » | [11751](https://groups.io/g/eternity2/message/11751) | | 2026-01 | 295M placements/s, mono-cœur | Joe exécutant le code de McGavin sur un CPU plus récent, contre son propre C# à 27-37M | [11750](https://groups.io/g/eternity2/message/11750) | | 2026-02 | 44,0M contre 105,1M tuiles/s | arbre identique de 2,12 mille milliards de nœuds : Phenom II de 2010 contre Ryzen 5 5600H | [11782](https://groups.io/g/eternity2/message/11782) | Deux lectures de cette table. D'abord, l'accroche : le chiffre de ~295M/s (celui que notre [page des records](/fr/research/records/) cite) est réel, mais c'est la mesure de Joe, faite en janvier 2026 quand McGavin a partagé sa source et que Joe l'a exécutée sur du matériel plus récent que tout ce que McGavin possède ; le propre solveur C# de Joe atteignait 27-37M/s sur la même machine, et la meilleure vitesse qu'il avait vue mentionnée sur la liste était 70-90M/s ([message 11750](https://groups.io/g/eternity2/message/11750)). Le meilleur chiffre de McGavin lui-même est les ~225M/s de l'Orange Pi sur de petits puzzles ([message 11751](https://groups.io/g/eternity2/message/11751)). Deuxième lecture, plus discrète et plus instructive : la vitesse mono-cœur n'a quasiment pas bougé pendant quinze ans. McGavin l'a dit lui-même quand il a publié la table de 2025 : les vitesses sur les CPU les plus récents « are only a little faster » que sur son Phenom II de 2010 ([message 11643](https://groups.io/g/eternity2/message/11643)). Le moteur était déjà près du mur mémoire que Field décrivait en 2011. Ce qui a réellement grandi, c'est le nombre de cœurs qu'il pouvait pointer vers un problème. ## Des centaines de cœurs pour un budget de loisir Le chapitre de McGavin dans l'histoire de la [résolution distribuée](/fr/research/build/faster/distributed-solving/) de la communauté a un charme domestique. Pour la campagne 10×10, il a commencé avec une vingtaine de cœurs à la maison, puis a ajouté trois Odroid XU4 octa-cœur et vingt-cinq Orange Pi Lite quad-cœur à 12 dollars pièce (plus de 130 cœurs, chaque cœur ARM valant environ un tiers de la vitesse d'un cœur de PC) et, quand cela était permis, des serveurs multi-cœurs au travail, pour un total de plus de 400 ([message 9688](https://groups.io/g/eternity2/message/9688)). Les Orange Pi tournaient sur des chargeurs USB 12 ports (il a définitivement tué un chargeur en branchant douze cartes exécutant 48 backtrackers, et est redescendu à huit par chargeur) avec un réseau WiFi : un seul câble par carte, pour l'alimentation ([message 9690](https://groups.io/g/eternity2/message/9690)). L'orchestration tient en deux scripts shell : l'un démarre autant de backtrackers qu'un nœud a de cœurs, l'autre le lance sur ~20 nœuds via ssh, chacun avec 16 à 48 cœurs, quoique « well, they are hyperthreads, strictly speaking » ([message 9753](https://groups.io/g/eternity2/message/9753)). Au pic, « more than 400 backtrackers running at once » ([message 9751](https://groups.io/g/eternity2/message/9751)). ## Ce que la vitesse a rapporté **Les décomptes vérifiés, d'abord.** Les énumérations complètes rapides sont ce qui permet à la communauté de confronter la théorie à la réalité. En 2011, une exécution nocturne a compté 4 739 821 621 743 blocs de coin 5×5 du 10×10 de Brendan, contre une estimation de la théorie complexe de 5,0077 × 10¹², « pretty close… if I do say so myself » ([message 8672](https://groups.io/g/eternity2/message/8672)). En 2014, son mono-cœur a parcouru l'arbre du benchmark à 256 pièces d'Arnaud Carré (3 979 209 754 placements, les 4 solutions) en moins d'une minute ([message 9263](https://groups.io/g/eternity2/message/9263)). En 2026, deux machines différentes ont parcouru le même arbre à 2 120 424 701 160 nœuds d'un puzzle proche d'E2 et ont trouvé la même unique solution : le déterminisme comme fonctionnalité, le décompte de nœuds comme somme de contrôle ([message 11782](https://groups.io/g/eternity2/message/11782)). **Le 10×10, avant tout.** Le 10×10 set_1 de Brendan, un benchmark resté ouvert pendant une décennie, est tombé en septembre 2017 sous exactement cette machinerie : énumérer ~20 millions de premières lignes candidates, les classer par le nombre de solutions par nœud de recherche de la théorie complexe, et laisser la ferme les tester une par une, environ un jour-cœur chacune. La solution est arrivée au test de ligne ~92 907 sur une sur 70 000 prédite, après près de 2 × 10¹⁷ nœuds, soit environ **180 années-cœur**, moins de 0,5 % de l'arbre entier ([message 9686](https://groups.io/g/eternity2/message/9686), [message 9688](https://groups.io/g/eternity2/message/9688)), étalés sur environ quatre ans ([message 9804](https://groups.io/g/eternity2/message/9804)). Son résumé : « no new methods, just systematic persistence and the law of large numbers. » La [page des benchmarks](/fr/research/build/benchmarks/) raconte cette histoire comme la validation la plus forte de la théorie complexe ; ici, elle se dresse comme le point culminant de l'histoire du débit. **Et un record, sur le moteur d'un autre.** En septembre 2020, quelques jours après que Joshua Blackwood a ouvert le code de son solveur, McGavin l'a exécuté « for a few days on about a couple of hundred cores and hit the jackpot. New record score of 469! » ([message 10045](https://groups.io/g/eternity2/message/10045)), avec des statistiques d'exécution à l'avenant (2 832 plateaux atteignant 252 pièces, un à 255, un à 256 : [message 10049](https://groups.io/g/eternity2/message/10049)). Notez ce qui s'est combiné là : les [heuristiques de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) ont fourni la forme de la recherche ; la ferme de McGavin a fourni les placements. Son propre moteur C ne détient aucun record de score E2 ; ses 226 en balayage de lignes de février 2020 ont égalé l'ancienne marque de placements consécutifs de [Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/), sans plus ([message 10523](https://groups.io/g/eternity2/message/10523)). ## Ce que la vitesse n'a pas pu acheter McGavin est aussi le témoin le plus constant de l'archive *contre* la vitesse brute. Ses propres chiffres font le procès. Avec l'ordre de balayage de lignes, la théorie complexe situe l'arbre de recherche complet d'E2 à environ 1,6 × 10⁴⁷ placements ([message 9710](https://groups.io/g/eternity2/message/9710)), soit quelque 9,3 × 10⁴² par solution attendue ([message 9713](https://groups.io/g/eternity2/message/9713)). Même sur son meilleur chemin de placement à 5 indices (un arbre bien plus petit, environ 3,1 × 10⁴⁰ nœuds), il a calculé 4,9 × 10³² années à 100 millions de nœuds par seconde, et ajouter des milliards de cœurs vous laisse encore « orders of magnitude longer than the age of the Universe » ([message 11201](https://groups.io/g/eternity2/message/11201)). Il en avait tiré la conclusion bien avant, en 2013 : « It seems clear to me that E2 will not be solved by brute force. If it is to be solved at all, it will be by deep analysis and/or clever insight, in my opinion » ([message 9117](https://groups.io/g/eternity2/message/9117)). C'est pourquoi la plus grande accélération isolée qu'il ait jamais rapportée n'était pas du tout une accélération. Pour les chasses aux sous-solutions sans cadre, il a utilisé la théorie complexe comme une anticipation à la manière des échecs : estimer les solutions par nœud à chaque feuille 13 ou 14 plis en avance, mettre en cache les statistiques répétées, et diriger vers la meilleure branche. Gain global : un facteur d'environ 25 à la profondeur 81 ([message 9751](https://groups.io/g/eternity2/message/9751)). Aucune option de compilateur ne lui a jamais donné 25×. Façonner l'arbre a battu réduire les nanosecondes. C'est la [leçon centrale](/fr/research/why/prune-vs-speed/) de ce site, rapportée ici comme l'expérience de vingt ans d'un praticien : il a construit le moteur le plus rapide de l'histoire de la communauté, tout mesuré, et conclu que l'écart jusqu'à 480 ne s'est jamais joué sur le chronomètre. ## Le faire tourner ici Tout ce qui précède est tiré de l'archive. Le reste de cette page, c'est ce même moteur, compilé sur ma machine et pointé vers le vrai puzzle, pour que l'histoire du débit porte une mesure de première main et pas seulement une mesure relayée. ### D'où vient le code La source est `genbody.c`, jointe sous forme de `genbody71.zip` au [message 11749 de groups.io](https://groups.io/g/eternity2/message/11749). C'est 1 455 lignes de C, avec un README, un fichier de pièces et un fichier d'indices. Elle n'est pas copiée dans ce dépôt : elle reste sur la liste, là où son auteur l'a mise. C'est un programme à deux passes, et le README est franc sur le style (« dreadful C source code ... it really needs a lot of work to clean it up »). Compilée avec `-DG`, elle génère un second fichier C, `body.c`, spécialisé pour un puzzle. Recompilée sans `-DG`, elle inclut ce fichier généré et exécute la recherche. Ce flux de travail à deux passes est exactement la conception de générateur de code décrite plus haut, désormais devant moi. ### Ce qui a été changé pour le faire tourner Deux choses, toutes deux minimes : - **Rien, pour le compiler.** Il compile proprement sur silicium Apple avec `clang` (un avertissement de variable inutilisée). L'affichage de statut POSIX qu'il utilise, `setitimer` et `termios`, fonctionne sur macOS sans adaptateur. - **Le puzzle qu'il lit.** Les noms de fichiers étaient codés en dur vers le puzzle de test de Joe. Je les ai rendus lisibles depuis la ligne de commande pour pouvoir lui fournir le vrai Eternity II, et j'ai écrit les pièces et indices officiels dans son format `.puz` / `.hnt` à partir du fichier canonique du puzzle. Son chemin de recherche est construit de façon générique (cellules d'indice d'abord, puis un balayage de lignes), donc aucune autre modification n'a été nécessaire. ### Ce qu'il fait sur le puzzle de Joe Configuré tel que livré, sur le puzzle de test 16×16 à 18 indices de Joe, il est très rapide et il termine : - **~279 millions de placements de tuiles par seconde**, mono-cœur. - Résout le puzzle jusqu'au bout en environ 13 secondes (3,577 milliards de placements jusqu'à la première solution), à l'identique à chaque exécution. C'est le chiffre que la communauté entend par « McGavin est rapide ». Il est réel, et il est sur du matériel actuel, pas une machine vieille de sept ans : parfaitement dans la ligne des ~295M/s mesurés par Joe, et confortablement au-delà des ~225M/s de l'Orange Pi de McGavin lui-même. ### Ce qu'il fait sur le vrai Eternity II Alimenté avec le véritable puzzle à 256 pièces, une fois avec le seul indice central obligatoire et une fois avec les cinq indices officiels : son solveur ne sauvegarde un plateau que lorsqu'il trouve une solution **complète**, et le vrai puzzle n'a jamais été résolu, donc il ne sauvegarde rien et tourne sans s'arrêter. Ce qu'il rapporte, en direct, c'est la profondeur maximale qu'il a atteinte : | Puzzle | Placement le plus profond, 30 s | Débit | Solutions | | --- | --- | --- | --- | | Vrai E2, 1 indice | **205 / 256** | ~108 M placements/s | 0 | | Vrai E2, 5 indices | **204 / 256** | ~109 M placements/s | 0 | Deux choses méritent d'être dites clairement. D'abord, il s'agit d'une **profondeur** (jusqu'où la recherche est allée avant de rebrousser chemin), et non d'un score d'arêtes sur 480 : son programme n'émet pas de plateau partiel à re-scorer. Deuxièmement, le débit sur le vrai puzzle est d'environ 109 millions de placements par seconde, à peu près 40 % de sa vitesse sur le puzzle de Joe, parce que les contraintes du vrai puzzle élaguent plus dur. Le nombre d'indices ne le bouge quasiment pas : 205 avec un indice, 204 avec cinq. C'est la même leçon que ses propres messages atteignent, désormais sur mon propre matériel : le moteur brut est superbe pour parcourir un arbre et ne dit rien, à lui seul, sur l'endroit où se cache un plateau à score élevé. ### Mono-cœur, confirmé Le binaire ne lie que la bibliothèque système, n'a aucune primitive de threading dans sa source, et maintient un CPU à 100 % (pas 800 %) avec un seul thread du début à la fin. La vitesse est celle d'un cœur. C'est l'unité juste pour comparer les moteurs, et c'est celle qu'utilise le [benchmark mono-cœur](/fr/research/lab/experiments/single-core-benchmark/) pour placer ce moteur aux côtés de [celui de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) et de la [réimplémentation Verhaard](/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/). Les trois ne mesurent pas le même axe (le chiffre de McGavin est une profondeur de placement, pas un score d'arêtes concordantes), donc lisez la comparaison avec prudence. Un post-scriptum de première main sur le débit lui-même. Reconstruit sans affichage (son affichage terminal en direct lui coûte, en fait, ~2,7×) et pointé sur un plateau facile et un difficile, ce moteur C fixe la barre face à laquelle un [backtracker à génération de code en Rust portable](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) a ensuite été mesuré sur le même M1 : le Rust l'égale sur les plateaux difficiles et profonds comme le vrai puzzle (~105–110 M chacun) et reste ~2,3× derrière sur les faciles et peu ramifiés (~287 M contre ~122 M). Un calibrage utile de la part de l'avantage de ce moteur qui relève de l'artisanat portable et de la part qui tient à la forme du plateau sur lequel il tourne. ## À lire aussi - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. - [Benchmark mono-cœur](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/) — Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. - [Les benchmarks de la communauté](https://eternity2.dev/fr/research/build/benchmarks/) — Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. - [Comment cherchent les solveurs record](https://eternity2.dev/fr/research/build/solvers/) — Comment cherchent réellement les solveurs qui détiennent les records. Ce sont tous, au fond, des backtrackers en profondeur d'abord ; ce qui les distingue, c'est l'ordre dans lequel ils essaient les choses et la manière dont ils assouplissent les règles à l'approche de la fin. --- # Les expériences de Raphaël Anjou > Un carnet d'expériences de recherche sur Eternity II, organisé autour des moteurs partagés qui les font tourner, des pipelines de combinaison qui courent après le score, de quatre études qui décortiquent un paradigme de recherche une décision à la fois, et de résolutions exactes de fin de partie. Chacune expose son idée, son meilleur plateau et les questions qu'elle laisse ouvertes. La meilleure atteint 463 sur 480. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/ - Mise à jour: 2026-07-22 --- Voici le carnet des expériences de recherche sur Eternity II de [Raphaël Anjou](/fr/research/people/raphael-anjou/). Certaines sont des idées originales ; d'autres réimplémentent fidèlement une technique connue de la communauté pour mesurer exactement ce qu'elle apporte. Chacune consigne son idée, le plateau qu'elle a atteint et les questions qu'elle laisse ouvertes, et chaque plateau est réel et vérifiable dans le [visualiseur](/viewer/). Le meilleur atteint **463 sur 480** arêtes appariées ; le meilleur de la communauté sur le même puzzle est 470. Méthodes et plateaux sont ici au complet, rien n'est passé sous silence. C'est un carnet, non un résultat unique : mieux vaut donc en connaître l'agencement avant de s'y plonger. > **[Interactive: RecentlyAdded]** Rendered on the canonical page (link above); not shown in this markdown export. ## Ce que contient cette section Deux natures de choses cohabitent ici : l'**appareillage** sur lequel tournent les expériences, et les **expériences** elles-mêmes. Ces dernières se déclinent en trois genres : les pipelines qui courent après le score du plateau entier, les études qui isolent une décision de recherche à la fois, et les résolutions exactes qui *prouvent* une petite région au lieu de la deviner. Commencez là où se trouve la question qui vous tient à cœur.
- [Les moteurs](/fr/research/lab/experiments/raphael-anjou/engines/) — La machinerie partagée sur laquelle tournent les expériences : un producteur constructif par faisceau, une recherche locale par destruction-réparation et une famille de préréglages CSP. Documentée une seule fois ici pour que chaque étude puisse y renvoyer au lieu de réexpliquer la machine. Commencez ici si vous voulez comprendre comment fonctionne une recherche avant de lire ce qu'une étude en a fait. - [Pipelines de combinaison](/fr/research/lab/experiments/raphael-anjou/pipelines/) — Les exécutions nommées qui font grimper le score. Chacune est un pipeline, et non un algorithme isolé : construire un plateau avec un moteur, puis l'améliorer ou l'achever avec un autre. Tout l'intérêt réside dans la répartition du travail entre construction, réparation et fin de partie exacte. C'est de là que viennent les plateaux qui approchent le record. - [L'étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Le retour sur trace en profondeur d'abord, disséqué. Une famille de solveurs à rebroussement partant de zéro, séparés chacun par un seul changement (ordre de remplissage, heuristique, politique de rupture), exécutés sur les dix mêmes variantes à budget fixe, pour chiffrer la valeur de chaque idée. - [L'étude de réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/) — Sa jumelle, pour la recherche locale par destruction-réparation : quelle région détruire, comment la reconstruire, quand conserver un coup, de quel plateau partir. La boucle avec laquelle les records atteignent réellement le sommet, décortiquée une décision à la fois. - [Apprendre des plateaux forts](/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude tournée vers l'intérieur : plutôt que de faire varier la recherche, on fait varier ce qu'elle a le droit de *savoir*. Cinq expériences fouillent le corpus des plateaux forts pour en extraire de la structure et la réinjectent, et toutes cinq se heurtent au même mur. - [L'étude des indices](/fr/research/lab/experiments/raphael-anjou/hint-study/) — Donner gratuitement à un backtracker cinq pièces correctes, dans la géométrie d'indices du puzzle lui-même. Mesurées contre l'absence totale d'indices, elles n'aident jamais un backtracker chronologique sur ces plateaux ; elles peuvent coûter 10 à 20 points à un balayage compact et faire chuter d'environ 345 points un ordre qui court vers les indices, car une pièce épinglée est une contrainte dure qu'un ordre de remplissage fixe doit satisfaire à son arrivée. - [Rencontre au milieu](/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/) — Résolutions exactes de fin de partie : énumérer une région par les deux bouts et les raccorder sur la couture pour trouver la véritable meilleure complétion, avec la preuve qu'aucune ne fait mieux. Elles mesurent exactement une petite région au lieu de courir après le score du plateau entier. - [Aller vite](/fr/research/lab/experiments/raphael-anjou/going-fast/) — L'autre levier : non pas une recherche plus fine, mais plus rapide. Un backtracker en Rust portable qui génère et compile du Rust propre à chaque puzzle, porté échelon par échelon jusqu'à un débit de la classe de McGavin - à égalité avec le C le plus optimisé à la main de la communauté sur les plateaux difficiles et réalistes, depuis un langage sûr. Un résultat de vitesse, sur un axe propre, distinct des scores ci-dessus.
Les deux moteurs constructifs, le producteur par faisceau et l'étape de polissage ALNS, n'ont pas encore leur propre exposé ; là où un pipeline en pilote un, la page de ce pipeline indique ce que fait ce moteur au niveau dont l'étude a besoin. Les préréglages CSP sont le seul moteur documenté et mesuré en intégralité. À côté de cet appareillage, le petit [moteur de référence](/fr/research/lab/experiments/raphael-anjou/engine/) qui anime les démonstrations en direct du site et revérifie chaque chiffre a sa propre page. ## Constats et instruments Tout n'est pas ici pipeline ou étude. Trois pages se tiennent seules, une ligne chacune : - [FROSTLINE](/fr/research/lab/experiments/raphael-anjou/frostline/) : une énergie libre de propagation de croyances sur les pièces restantes de la dernière rangée, qui prédit par rang à quel point la rangée peut encore s'achever, et dont le signal meurt au-delà d'une rangée. - [LEDGER](/fr/research/lab/experiments/raphael-anjou/ledger/) : un élagage sain, couleur par couleur, de l'offre contre la demande pour un DFS à budget de ruptures, dont les économies se composent avec la profondeur. - [L'échelle de tailles](/fr/research/lab/experiments/raphael-anjou/scaling-ladder/) : un banc qui fait tourner un solveur tel quel sur des plateaux plantés, entièrement résolubles, de N = 8 à 14, pour trouver où la méthode s'effondre avant d'engager des semaines sur le vrai 16x16. Deux autres constats vivent sur l'étagère des pipelines : [rendre un producteur beam 10x meilleur](/fr/research/lab/experiments/raphael-anjou/pipelines/beam-width/), où la largeur elle-même s'est révélée la réponse à budget égal, et [le cadre fluide](/fr/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/), où un bord parfait s'est révélé être non pas un arrangement unique mais une variété connexe d'échanges gratuits. ## Où en est le carnet Lu comme une seule enquête, le carnet suit trois lignes. Les constructeurs partant de zéro et les pipelines de combinaison plafonnent dans une bande de 436 à 460 arêtes appariées : la construction seule cale, et ce que les pipelines ont gagné vient de la répartition du travail entre construction, réparation et fin de partie exacte, non d'un moteur en particulier. La [ligne d'apprentissage sur corpus](/fr/research/lab/experiments/raphael-anjou/learning/) atteint 460 à 463, et ses cinq expériences s'arrêtent toutes au même [mur de rigidité](/fr/research/why/rigidity-wall/). Les résolutions exactes par [rencontre au milieu](/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/) sont un résultat d'une autre nature : leurs plateaux à 437-448 s'accompagnent d'une preuve sur une petite région, non d'une course au score du plateau entier. La question ouverte du carnet est ce qu'une prochaine expérience devrait changer pour dépasser 463 ; varier la recherche et varier ce qu'elle sait ont tous deux buté sur des murs, le levier n'est donc probablement ni l'un ni l'autre seul. L'écart qui demeure est celui au 470 de la communauté, sur la [page des records](/fr/research/records/). Le carnet compte ses scores selon deux conventions, qui ne désignent pas le même sommet. En arêtes appariées, le meilleur est 463 ([PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/)). Sous la convention stricte des cinq indices, où les cinq indices officiels doivent occuper leurs cases, le meilleur est 461 : un producteur à ordre en peigne atteint 457, puis un polissage destruction-réparation le hisse par 459 et 460. Ces deux nombres restent sous les meilleures marques communautaires ; la [page des records](/fr/research/records/) tient les conventions et le classement à jour. ## Prochaines rédactions Des résultats existent au labo sans avoir encore leur page, dans l'ordre probable d'arrivée : la lignée stricte 461 ci-dessus, le finisseur exact qui scelle les dernières lignes d'un plateau produit, le faisceau à double rupture, et le producteur de bassins par nouveauté. Chacun arrivera avec sa reproduction exécutable, comme les pages ci-dessus. ## Comment lire les scores Le graphique et le tableau ci-dessous portent deux natures de chiffres à ne jamais confondre : c'est pourquoi ils sont représentés en deux groupes distincts. - **Exploration** est le meilleur plateau que chaque méthode a atteint lors d'exécutions exploratoires sur 8 cœurs, sans que le temps d'horloge soit consigné. Ce sont les chiffres phares que citent les exposés, et ils plafonnent au 463 de PALIMPSEST. - **Banc** est le banc d'essai standardisé sur un seul cœur : un cœur, soixante secondes, chaque plateau étant re-noté par le même barème canonique. Plus bas, et *directement comparable* d'une méthode à l'autre, ce que ne permettent pas les chiffres d'exploration. Toutes les expériences ne méritent pas une ligne. Les études font varier un curseur sur une grille de valeurs plutôt que de produire un seul plateau : les études [DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/) et [réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/) portent donc leur propre classement au lieu d'une ligne sur le graphique ; seul leur meilleur résultat de banc figure ici. [L'étude des indices](/fr/research/lab/experiments/raphael-anjou/hint-study/) porte de même ses propres tableaux sur ses pages et n'a pas de ligne sur le graphique. Les cinq expériences [d'apprentissage](/fr/research/lab/experiments/raphael-anjou/learning/) atteignent chacune un plateau scoré : elles gardent donc leur ligne en plus de leur foyer d'étude. Les lignes de banc ci-dessus sont des résultats d'étude, non des pages autonomes : elles n'apparaissent donc que sur le graphique. > **[Interactive: ExperimentScoreChart]** Rendered on the canonical page (link above); not shown in this markdown export. Les expériences nommées sous forme de tableau triable (cliquez sur un en-tête de colonne pour réordonner par score, nom, méthode ou mois). L'auteur, le mois, la rigueur et la reproductibilité sont lus depuis la page propre à chaque expérience, si bien que ce récapitulatif reste en phase avec elles. s.group !== "bench")} /> ## Pages de cette section - [Les moteurs partagés](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/engines/) — Les moteurs partagés qui sous-tendent les expériences de Raphaël Anjou. Les expériences nommées sont des études qui s'appuient dessus ; voici l'appareillage qu'elles ont en commun. Les préréglages CSP et la réimplémentation de Verhaard sont documentés intégralement, aux côtés du moteur de référence, du backtracker JIT, d'un guide de la vitesse et du harnais de l'échelle de tailles ; les moteurs constructifs ne sont pas encore publiés. - [Le moteur de référence qui fait tourner ce site](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/engine/) — Le backtracker Rust-vers-WebAssembly qui anime chaque démo en direct et vérifie chaque chiffre de ce wiki. Non pas une machine à records mais un moteur de référence, porté quatre fois et validé octet par octet, conçu pour que les affirmations d'ici soient rejouables. - [Pipelines de combinaison](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/) — Sept expériences de recherche nommées qui visent le score, chacune un pipeline plutôt qu'un algorithme unique : elle construit un plateau avec un moteur, puis le relève ou l'achève avec un autre. À leurs côtés, deux constats décortiquent la machinerie sur laquelle les pipelines s'appuient. Chaque page consigne son idée, son plateau et les questions qu'elle laisse ouvertes. - [L'étude DFS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. - [L'étude sur les indices](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/) — Donner à un backtracker cinq pièces correctes gratuitement, dans la géométrie même des indices du puzzle. Il s'avère que cela n'aide pas, et selon l'ordre de remplissage cela peut nuire gravement, car une pièce épinglée est une contrainte dure qu'un ordre de remplissage fixe doit satisfaire à son arrivée. Une famille d'ordres de remplissage, exécutée sur les mêmes plateaux indicés, un seul cœur, mesurée contre l'absence totale d'indices. - [L'étude de la réparation](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/) — La jumelle de l'étude DFS, pour l'autre manière d'attaquer Eternity II : détruire une partie d'un plateau, la reconstruire, garder le changement s'il aide. Une question, posée avec soin. Que rapporte chaque décision de cette boucle : quelle région détruire, comment la reconstruire, quand garder un mouvement, quand redémarrer, et de quel plateau partir ? - [Apprendre à partir des grilles fortes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. - [Meet in the middle](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/) — Des expériences exactes de fin de partie qui se rejoignent au milieu : énumérer une région depuis deux extrémités et raccorder sur la couture, pour trouver la vraie meilleure complétion avec une preuve plutôt que la meilleure conjecture d'une heuristique. Elles mesurent exactement une petite région au lieu de courir après le score du plateau entier. - [Aller vite : quand un solveur dépense son budget en vitesse](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/going-fast/) — Certains moteurs Eternity II mettent tout leur effort à parcourir l'arbre de recherche le plus vite possible ; d'autres le mettent dans le jugement sur où chercher. Voici le plaidoyer pour les premiers - ce qu'achète le débit brut, les trois choses différentes qu'on appelle « rapide », et pourquoi le moteur le plus rapide jamais construit ne sait toujours pas résoudre le puzzle. - [Le backtracker JIT : du Rust portable à égalité avec du C optimisé sur les plateaux difficiles](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) — Un backtracker Rust en profondeur d'abord, sûr et portable, spécialisé à l'exécution en émettant puis compilant du Rust propre à chaque puzzle, porté de 43 à 123 millions de nœuds de recherche par seconde sur un cœur. Mesuré équitablement face au C de Peter McGavin sur la même machine : à égalité sur les plateaux difficiles et profonds comme le vrai Eternity II, et à environ 44 % de sa vitesse sur les faciles. Chaque échelon parcourt l'arbre identique ; tout le gain vient du code, pas de l'algorithme. - [Un élagage correct par comptage des couleurs pour la recherche tolérante aux ruptures](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/ledger/) — Suivre, couleur par couleur, l'offre de demi-arêtes face à la demande du front dans un DFS à budget de ruptures, et élaguer dès que le déficit ou sa parité dépasse les ruptures restantes. Correct par construction ; le gain se compose avec la profondeur. - [Lire l'avenir d'une rangée dans ses pièces restantes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/frostline/) — Une énergie libre issue de la propagation de croyances, calculée sur les pièces restantes de la dernière rangée, prédit le rang de la meilleure fin possible. Le signal n'est pas un proxy du score brut, survit à un changement de producteur et meurt au-delà d'une rangée. - [L'échelle de tailles](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/scaling-ladder/) — Un banc qui fait tourner n'importe quel solveur, tel quel, sur des plateaux plantés entièrement résolubles à N = 8, 10, 12, 14, chacun avec un plafond prouvé de 2N(N-1) : la taille d'effondrement d'une méthode se mesure avant de passer des semaines sur le vrai 16×16. --- # L'étude DFS > Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/ - Mise à jour: 2026-07-16 - Sujets: backtracking, search-space, speed - Reproduire: `just experiments dfs-study` - Source: Moteur exécutable + résultats versionnés + scripts (le répertoire d'appui de cette étude) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study --- Tout solveur d'Eternity II détenteur d'un record (Blackwood, Verhaard, McGavin) est un backtracker en profondeur d'abord. Ce qui les distingue d'un backtracker de premier devoir de la semaine ne tient pas à leur nature mais à une poignée de décisions : l'ordre dans lequel ils remplissent les cases, l'anticipation qu'ils appliquent, et le fait de laisser ou non une arête *rompre*. Cette étude démonte ces décisions. Elle construit de zéro une famille de backtrackers en profondeur d'abord, chacun séparé de son voisin par un seul changement, et les exécute tous sur les mêmes dix variantes à coins fixés du puzzle officiel, sur un seul cœur, soixante secondes par exécution. Le score maximal est de 480 arêtes appariées. Le but n'est pas de gagner. La variante la plus forte présentée ici tourne en moyenne autour de 430 tout juste, bien en deçà des 464 de la communauté sur ces cinq indices, car soixante secondes sur un cœur ne représentent qu'une fraction infime du calcul qu'ont demandé les records. Le but est d'isoler *ce que vaut chaque idée* en ne changeant qu'une chose à la fois et en mesurant le résultat avec le même scoreur canonique pour chaque plateau. > **[Interactive: StartingPuzzleCarousel]** Rendered on the canonical page (link above); not shown in this markdown export. ## La famille, et le classement Quatre familles, disposées de sorte que des voisins diffèrent d'une seule décision. **Baseline** est le backtracker le plus brut possible, accompagné d'un jumeau spécialisé à la main qui chiffre le coût de l'ingénierie bas niveau. **Path order** fixe tout sauf la séquence dans laquelle les cases sont remplies. **Heuristic** fixe l'ordre et ajoute un propagateur à la fois. **Break** est l'axe d'élite : le mécanisme de rupture d'arête à seuil de profondeur sur lequel reposent les records. Les moteurs record de la communauté, le C de McGavin et le C# de Blackwood, sont eux-mêmes des backtrackers à rupture, ils prennent donc place dans la famille break, et non dans une catégorie à part. Savoir de qui est le code d'un moteur reste affaire d'étiquetage, non de couleur. Les deux apparaissent dans le classement à leur score à coins fixés, marqués d'un badge là où ils s'effondrent, puis de nouveau sur une grille sans fixation plus bas, où ils tournent tels qu'ils ont été conçus. > **[Interactive: DfsStudyLeaderboard]** Rendered on the canonical page (link above); not shown in this markdown export. ## Ce que l'étude a trouvé - **L'ordre de parcours est le plus grand levier gratuit, et le mauvais ordre est catastrophique.** Un simple parcours ligne par ligne tourne en moyenne à 377 ; un remplissage strict bord d'abord ou en spirale, sans heuristique pour le sauver, plafonne autour de 67. Même moteur, même budget, un écart de plus de 300 points dû au seul ordre de remplissage. - **L'heuristique de la case la plus contrainte (MRV) est ce qui rend le bord d'abord viable.** Elle fait passer un bord d'abord en panne de la soixantaine à une moyenne de 324, au prix de trois ordres de grandeur sur le débit de nœuds. Le débit de nœuds et le score sont deux axes distincts, une distinction sur laquelle l'étude revient de bout en bout. - **Davantage de propagation n'a pas acheté davantage de score à ce budget.** Le forward-checking, l'arc-cohérence et le raisonnement par couleur atterrissent à un point près l'un de l'autre (322, 321, 321), un écart bien à l'intérieur de la dispersion d'une exécution à l'autre : une anticipation plus lourde n'a donc ni aidé ni clairement nui. Elle dépense les soixante secondes à prouver de petites régions plutôt qu'à descendre plus profond. - **Les ruptures descendent plus profond que n'importe quelle recherche stricte.** Les backtrackers stricts plafonnent dans les 200 tout juste (le plus rapide, NAIVE-CODEGEN, à 216) ; un budget de rupture à seuil de profondeur dépasse 245 et tourne en moyenne autour de 430, car il peut forcer le passage au-delà d'une arête localement inappariable au lieu de remonter pour en sortir. Le facteur décisif est le *calendrier* des ruptures : déverrouiller les ruptures trop tôt (l'échelle de Verhaard, moyenne 399) score bien en deçà de l'échelle plus tardive de Blackwood (moyenne 431). Relever le plafond par case de un à deux n'a pas aidé à ce budget, un résultat nul rapporté comme mesuré. Chacun de ces points a sa propre page : la construction du moteur et la signification de chaque statistique relevée figurent sur la [page de méthode](/fr/research/lab/experiments/raphael-anjou/dfs-study/method/), et les comparaisons de parcours, d'heuristique et de rupture sont détaillées sur la [page des résultats](/fr/research/lab/experiments/raphael-anjou/dfs-study/findings/). ## Comment lire les chiffres Chaque plateau est re-scoré par un unique scoreur canonique, et le score auto-déclaré d'aucun moteur n'est pris pour argent comptant. Le débit est rapporté en nœuds de recherche par seconde et n'est **jamais comparé d'une famille à l'autre**, car un nœud qui exécute une arc-cohérence complète n'est pas la même unité de travail qu'un placement naïf. La profondeur est le placement le plus profond qu'a atteint une variante, sur 256. Le nombre de ruptures mérite une définition précise, car il est facile de l'énoncer de façon vague. Le *score* d'un plateau est le nombre de ses arêtes intérieures appariées, et l'écart `480 − score` est le déficit total d'arêtes non appariées du plateau. Sur un plateau **achevé**, chaque arête non appariée est une véritable rupture, si bien que là le score vaut exactement `480 − #ruptures`. Soixante secondes suffisent rarement à remplir le plateau, cependant, de sorte que la plupart des plateaux de variantes à rupture présentés ici sont partiels, et leur déficit est dominé par des arêtes simplement encore vides plutôt que rompues. Cette étude rapporte donc le **vrai nombre de ruptures**, c'est-à-dire les non-appariements intérieurs que la recherche a effectivement engagés sous son budget, suivis par la recherche elle-même plutôt qu'inférés du score. Ce nombre reste petit même quand le déficit est grand. Chaque plateau porte une `.url` bucas qui s'ouvre dans le [visualiseur](/viewer/), de sorte que le score comme les arêtes rompues peuvent se vérifier directement. Tout l'appareillage (l'espace de travail du moteur, les dix variantes, les résultats par exécution versionnés et les scripts de grille) réside sous le [répertoire d'appui](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study) de l'étude, et `just experiments dfs-study` reconstruit le moteur et relance toute la grille. ## Pages de cette section - [Comment l'étude DFS est construite](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/method/) — Le moteur derrière l'étude DFS : un backtracker composable où une variante est un changement déclaré au-dessus d'un parent, une couche IO partagée que chaque algorithme parle, et les définitions de chaque statistique que l'étude soulève : débit de nœuds, profondeur, ruptures. - [Ce que l'étude DFS a montré](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/findings/) — Les trois comparaisons au cœur de l'étude DFS, menées jusqu'au bout : l'ordre de remplissage (le balayage par lignes gagne, un mauvais ordre est catastrophique), les heuristiques (MRV sauve le remplissage du bord d'abord mais coûte du débit ; davantage de propagation n'a rien apporté) et les ruptures (elles brisent le mur de profondeur ; le levier, c'est le calendrier de ruptures, pas le plafond par cellule). ## À lire aussi - [Les expériences de Raphaël Anjou](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/) — Un carnet d'expériences de recherche sur Eternity II, organisé autour des moteurs partagés qui les font tourner, des pipelines de combinaison qui courent après le score, de quatre études qui décortiquent un paradigme de recherche une décision à la fois, et de résolutions exactes de fin de partie. Chacune expose son idée, son meilleur plateau et les questions qu'elle laisse ouvertes. La meilleure atteint 463 sur 480. - [Benchmark mono-cœur](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/) — Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - [Ordres de remplissage](https://eternity2.dev/fr/research/build/backtracking/fill-order/) — L'ordre dans lequel un algorithme de retour arrière visite les 256 cases est son unique liberté : il ne coûte rien à l'exécution et fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur. Vingt ans de science communautaire, des guerres fixe-contre-dynamique aux courses de stratégies, jusqu'au carré magique 10×16 et à la recherche en peigne de Verhaard, répondent tous à la même question : quel chemin à travers le plateau est le moins coûteux ? --- # Ce que l'étude DFS a montré > Les trois comparaisons au cœur de l'étude DFS, menées jusqu'au bout : l'ordre de remplissage (le balayage par lignes gagne, un mauvais ordre est catastrophique), les heuristiques (MRV sauve le remplissage du bord d'abord mais coûte du débit ; davantage de propagation n'a rien apporté) et les ruptures (elles brisent le mur de profondeur ; le levier, c'est le calendrier de ruptures, pas le plafond par cellule). - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/findings/ - Mise à jour: 2026-07-16 - Sujets: backtracking, search-space, speed - Source: Résultats par exécution versionnés (results.jsonl) et rapport par famille (report.md) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study/results --- Trois comparaisons portent l'[étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/). Chacune isole une décision en maintenant tout le reste fixe. Tous les scores sont le nombre moyen d'arêtes appariées sur les dix variantes à coins épinglés, mono-cœur, soixante secondes. Le débit se mesure en nœuds de recherche par seconde et n'est jamais comparé d'une famille à l'autre. ## Ce qu'apporte la spécialisation bas niveau : du débit, et rien d'autre Les deux références exécutent le *même* algorithme strict de balayage par lignes : `NAIVE-CLEAN` comme moteur généraliste lisible, `NAIVE-CODEGEN` comme boucle chaude 16×16 spécialisée à la main, réservée au balayage par lignes. La spécialisation livre ce qu'elle promet sur l'axe qu'elle vise. `NAIVE-CODEGEN` est sensiblement plus rapide par nœud, jusqu'à un tiers de plus sur certaines instances. Sur le *score*, les deux se valent, à un point ou deux d'écart à soixante secondes et bien à l'intérieur de la dispersion entre exécutions, ce qui est la lecture honnête plutôt qu'une affirmation selon laquelle la spécialisation *nuirait*. À temps de calcul fixé, un moteur plus rapide atteint un point différent du même arbre, et la meilleure solution partielle d'un retour sur trace ne varie pas de façon monotone avec la vitesse à laquelle il y est parvenu. Les références constituent donc une comparaison de *vitesse* propre et ne sont délibérément pas présentées comme une comparaison de *score*. Les effets sur le score qui méritent d'être étudiés se trouvent tous sur les axes ci-dessous, là où la recherche elle-même change. ## Ordre de remplissage : le balayage par lignes gagne, et le mauvais ordre est catastrophique Fixons le moteur (strict, sans heuristique) et changeons uniquement l'ordre dans lequel les cellules sont remplies. Les six ordres ne diffèrent que par l'endroit où la recherche envoie son front, montré ci-dessous. > **[Figure]** Les six ordres de remplissage, tracés comme le chemin que parcourt la recherche — interactive: PathOrderDiagram. Rendered on the canonical page (link above); not shown in this markdown export. - **Le balayage par lignes** est la référence forte, avec une moyenne de 377. Sa zone d'endommagement reste constante, puisque chaque nouvelle cellule a les deux mêmes voisines déjà placées, si bien qu'il atteint une grande profondeur avant le mur strict. - **Un remplissage strict du bord d'abord ou en spirale s'effondre.** Remplir d'abord l'anneau du bord, sans anticipation, mène droit dans les contraintes de coin et de bord les plus dures et cale presque aussitôt, autour d'une moyenne de 67 à une profondeur d'environ 66. La spirale paie la même taxe de fermeture. - **Le balayage par lignes de bas en haut fait encore pire sur cette géométrie d'indices** (moyenne 226, mais aussi bas que 18 sur certaines variantes), parce que les indices épinglés se trouvent dans des lignes que le remplissage de bas en haut atteint tôt et ne peut pas satisfaire. Même moteur, mêmes soixante secondes, un écart de plus de 300 points dû au seul ordre de remplissage. C'est la forme mesurée d'un savoir de la communauté : le bord d'abord n'est bon qu'*avec* une heuristique pour choisir les cellules à l'intérieur de l'anneau. Seul, c'est l'un des pires ordres disponibles. Éprouvez le levier vous-même : choisissez l'un des neuf ordres de parcours du moteur ci-dessous et regardez le même retour sur trace atteindre une profondeur différente sur le même puzzle. > **[Interactive: DfsScanOrderLab]** Rendered on the canonical page (link above); not shown in this markdown export. ## Heuristiques : MRV sauve le bord d'abord, mais le débit s'effondre Fixons maintenant le chemin près du cadre et ajoutons une chose à la fois. Le plus grand levier est **MRV**, qui remplit ensuite la cellule vide la plus contrainte, choisie dynamiquement. Il transforme le bord d'abord qui calait (moyenne 67) en une recherche dont la moyenne est de 324 (meilleur 341) à une profondeur d'environ 190. Il recalcule aussi la cellule la plus contrainte sur tout le front à chaque étape, si bien que le débit en nœuds chute de trois ordres de grandeur, de dizaines de millions de nœuds par seconde à quelques milliers. Chaque nœud vaut bien plus, et on en visite bien moins. Le débit en nœuds et le score sont des axes différents. Ajouter une anticipation plus lourde par-dessus n'a **pas** rapporté davantage de score à ce budget. - **La vérification en avant** (rejeter un placement qui vide le domaine d'une voisine) a atteint une moyenne de 322. - **La cohérence d'arc** et la **vérification d'approvisionnement par couleur** ont atteint chacune une moyenne de 321. Avec une dispersion de score par variante d'environ 11 points sur les dix instances, cet écart d'un point est bien dans le bruit : les trois propagateurs sont ici statistiquement indiscernables, si bien que la lecture honnête est qu'une anticipation plus lourde n'a ni aidé ni clairement nui, plutôt que la vérification en avant l'aurait emporté. - Un ordonnancement des valeurs **couleurs rares d'abord** est resté inerte, pas meilleur que le simple ordre d'insertion, faisant écho au résultat négatif répété de la communauté sur les ordres de valeurs à l'intérieur d'un même seau. La leçon n'est pas que la propagation est inutile. C'est qu'à petit budget fixe, sur cette instance, l'élagage utile le moins cher (la vérification en avant) capte déjà tout le bénéfice disponible, et qu'un raisonnement plus coûteux ne récupère pas son surcoût par nœud en soixante secondes. ## Ruptures : au-delà du mur, et le calendrier est le levier Le retour sur trace strict, quel que soit son ordre ou son heuristique, frappe un mur bien avant un plateau complet : le balayage par lignes plafonne autour de la profondeur 208 sur 256, et même la variante stricte la plus rapide (NAIVE-CODEGEN) n'atteint que 216. Les moteurs recordmen le franchissent en *rompant* : ils autorisent un nombre borné d'incompatibilités d'arêtes intérieures, libérées selon un calendrier de profondeur, avec une règle interdisant qu'une cellule porte trop d'arêtes rompues. Le score d'un plateau complet est alors `480 − #ruptures`. - **Les ruptures franchissent le mur.** Un budget de ruptures conditionné par la profondeur atteint au-delà de la profondeur 245 et tourne autour des 430 (rupture-1 donne 431 sur 480, meilleur 435), un gain important sur les 370 et quelques du strict, sur les mêmes instances et le même budget. C'est le mécanisme derrière les retours sur trace recordmen de la communauté, non pas un paradigme différent mais un relâchement de la règle d'appariement conditionné par la profondeur. - **Autoriser une seconde rupture par cellule n'a pas aidé ici.** Une rupture et deux ruptures atteignent le même meilleur plateau (435), et leurs moyennes (431,3 contre 428,5) sont dans la dispersion propre à la variante à deux ruptures, si bien qu'aucune ne domine en moyenne. Ce qui les distingue, c'est la régularité : la variante à une rupture est étroitement groupée (jamais en dessous de 427), tandis que la variante à deux ruptures descend jusqu'à 402. La géométrie à double rupture qu'emploient les plateaux 460 de la communauté semble avoir besoin de plus de soixante secondes pour porter ses fruits ; à ce budget, la liberté supplémentaire élargit surtout le branchement sans atteindre de meilleurs plateaux. C'est un résultat nul, rapporté tel qu'il a été mesuré plutôt que tel qu'on pourrait l'espérer. - **Le calendrier est le levier décisif.** L'échelle de glissement de Verhaard débloque les ruptures bien plus tôt que celle de Blackwood (profondeur 193 contre 201) et obtient ici un score nettement moins bon (moyenne 399 contre 431), parce que débloquer tôt dépense le budget en ruptures peu profondes. Quand et à quelle vitesse les ruptures s'ouvrent est une décision de réglage plutôt qu'un détail. Ces chiffres de ruptures voisinent avec ceux des réimplémentations à la Blackwood et à la Verhaard, reparties de zéro, du benchmark frère, qui atteignent les 430 et quelques sur les mêmes cinq indices. L'accord d'un moteur indépendant valide de façon croisée la machinerie de ruptures ici. ## Où se situent les moteurs de la communauté : deux grilles Blackwood et McGavin sont le haut de gamme de cette même famille, et tous deux se compilent et s'exécutent sur cette machine, si bien que cette étude les a fait tourner sur une grille épinglée et une grille non épinglée, chaque score étant recalculé canoniquement à partir du plateau propre au moteur. Le résultat est un enseignement à part entière, et il a deux moitiés. **Sur la grille épinglée, ils s'effondrent.** Le C de McGavin, compilé avec les propres options ARM de son auteur (réglage natif plus optimisation au moment de l'édition de liens), atteint la profondeur 211 sur le puzzle à indice central simple à environ 85 millions de tuiles par seconde, bien devant notre moteur strict le plus rapide, et pourtant épingler trois coins l'effondre à la profondeur 21, un score canonique de 13. Son chemin de balayage engendré ne visite jamais les coins tôt, si bien qu'un coin épinglé contraint aussitôt son voisinage et coince le chemin fixe presque immédiatement. Le C# de Blackwood code en dur son jeu de pièces et son balayage, si bien qu'il ne peut même pas exprimer un épinglage de coin arbitraire ; sur la contrainte à cinq indices correspondante, son heuristique de ruptures s'agite jusqu'à la profondeur 47, un score canonique de 75, parce qu'il est réglé pour l'instance à un indice, quasi non contrainte, où son record de 470 a été établi. > **[Figure]** L'effondrement à l'épinglage des coins : cellules placées sur 256 — interactive: PinCollapseDiagram. Rendered on the canonical page (link above); not shown in this markdown export. Cet effondrement est justement le propos. Un moteur recordman bâti autour d'une configuration d'indices ne se transfère pas à une autre, et un chemin de balayage fixe ne peut pas absorber un épinglage arbitraire. Nos moteurs repartis de zéro traitent un épinglage comme une cellule pré-placée que le balayage saute simplement, ce qui explique pourquoi ce sont eux, et non les binaires de la communauté, qui font office de doublures sur la grille épinglée. **Sur une grille non épinglée équitable, ils tournent comme prévu.** Donnez à chaque moteur les pièces officielles avec le seul indice central obligatoire, et rien ne se coince sur un coin. En soixante secondes sur un cœur, McGavin atteint 392, notre moteur de ruptures le plus fort 344, la réimplémentation de Verhaard 286, et Blackwood 214. Lisez ces chiffres comme ce qu'un seul cœur achète en une minute à froid, non comme le plafond d'un moteur : le 470 de Blackwood et les exécutions profondes de McGavin sont venus de journées sur des centaines de cœurs, que ce budget ne peut pas montrer. Ce que la grille montre, en revanche, c'est que les quatre tournent correctement une fois disparus les épinglages qui brisent un chemin de balayage fixe, ce qui est exactement ce que la grille épinglée refusait aux deux moteurs étrangers. Les deux grilles figurent sur le classement de l'étude ci-dessus. ## Le fil conducteur Un thème traverse les trois comparaisons : **le nombre de nœuds n'est pas le score.** Les variantes les plus rapides par nœud (la référence en codegen et le moteur strict de balayage par lignes) n'atteignent pas les meilleurs plateaux ; la plus lente par nœud (MRV avec propagation) en atteint de bien meilleurs ; et les ruptures qui l'emportent le font en changeant *quelle* branche est légale, non en visitant les branches plus vite. La vitesse brute est un facteur constant, tandis qu'où la recherche peut aller et si elle en a le droit est le facteur exponentiel. ## À lire aussi - [L'étude DFS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. - [Comment l'étude DFS est construite](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/method/) — Le moteur derrière l'étude DFS : un backtracker composable où une variante est un changement déclaré au-dessus d'un parent, une couche IO partagée que chaque algorithme parle, et les définitions de chaque statistique que l'étude soulève : débit de nœuds, profondeur, ruptures. - [Ordres de remplissage](https://eternity2.dev/fr/research/build/backtracking/fill-order/) — L'ordre dans lequel un algorithme de retour arrière visite les 256 cases est son unique liberté : il ne coûte rien à l'exécution et fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur. Vingt ans de science communautaire, des guerres fixe-contre-dynamique aux courses de stratégies, jusqu'au carré magique 10×16 et à la recherche en peigne de Verhaard, répondent tous à la même question : quel chemin à travers le plateau est le moins coûteux ? - [Un élagage correct par comptage des couleurs pour la recherche tolérante aux ruptures](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/ledger/) — Suivre, couleur par couleur, l'offre de demi-arêtes face à la demande du front dans un DFS à budget de ruptures, et élaguer dès que le déficit ou sa parité dépasse les ruptures restantes. Correct par construction ; le gain se compose avec la profondeur. --- # Comment l'étude DFS est construite > Le moteur derrière l'étude DFS : un backtracker composable où une variante est un changement déclaré au-dessus d'un parent, une couche IO partagée que chaque algorithme parle, et les définitions de chaque statistique que l'étude soulève : débit de nœuds, profondeur, ruptures. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/method/ - Mise à jour: 2026-07-16 - Sujets: backtracking, speed - Source: L'espace de travail du moteur (dfs-engine, dfs-run) sur la bibliothèque partagée e2-core / e2-io — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study/engine --- Cette page est l'appareillage derrière l'[étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/) : comment le moteur est construit, pourquoi une nouvelle variante coûte peu à ajouter, et ce que signifie chaque nombre parmi les résultats. Rien de tout cela ne dépend du moteur du [benchmark monocœur](/fr/research/lab/experiments/single-core-benchmark/) voisin. Tout l'enjeu était de réimplémenter la famille de zéro, en gardant le génie logiciel propre et le récit du « quoi s'empile sur quoi » explicite. ## Une variante est un changement déclaré au-dessus d'un parent Chaque algorithme de l'étude est le *même* backtracker récursif en profondeur d'abord, paramétré par quatre choix indépendants : - **ordre de parcours** : la séquence dans laquelle les cases sont remplies (par lignes, en spirale, bordure d'abord, le peigne de Verhaard, ou dynamique par case la plus contrainte) ; - **ordre des valeurs** : l'ordre dans lequel les pièces candidates d'une case sont essayées ; - **propagateur** : l'anticipation exécutée après chaque placement (aucune, vérification en avant, arc-cohérence, raisonnement par couleur) ; - **politique de rupture** : si une arête peut être discordante, et sous quel budget conditionné par la profondeur. Une variante est un petit enregistrement nommant ces quatre choix, accompagné du **parent dont elle dérive et d'une description en une ligne du changement unique qu'elle ajoute**. Ajouter une variante revient à ajouter un enregistrement au registre, sans nouveau code de recherche à moins que l'idée ne soit une stratégie véritablement nouvelle. La matrice du « quoi s'empile sur quoi » de la page des résultats est générée à partir de ces descriptions, si bien qu'elle ne peut pas diverger du code qui a tourné. C'est ce qui garde une étude étendue, avec des dizaines de variantes distantes d'un seul changement, maintenable plutôt qu'un tas de solveurs copiés-collés. ## Une couche IO, et des conversions entre moteurs Chaque algorithme de l'étude consomme un seul type d'instance et émet une seule sortie : le meilleur plateau, son score canonique, et une URL bucas. Autour de cela s'articule une couche IO partagée dotée de convertisseurs sans perte entre les formats que parlent les autres moteurs du site : le JSON au schéma du site du benchmark, le CSV des moteurs communautaires autonomes, les URL bucas, et les fichiers d'indices. L'étude lit les *mêmes* dix variantes à coins épinglés que le benchmark monocœur utilise, à travers cette couche, de sorte que les deux expériences sont directement comparables. Un petit utilitaire `dfs-convert` expose les conversions depuis le shell, si bien que la sortie de n'importe quel moteur du blog peut alimenter n'importe quel autre. ## Le scoreur est l'unique source de vérité Aucun score auto-déclaré par un moteur n'est digne de confiance. Chaque plateau, strict ou rompu, est re-scoré par un unique scoreur canonique : les adjacences intérieures, hors bordure, concordantes, comptées à droite et vers le bas pour chaque case. C'est octet pour octet la même formule que celle du scoreur du site et du benchmark, vérifiée par un test qui re-score un plateau à 469 connu et exige 469. C'est ce qui permet aux scores de variantes différentes, et à ceux du benchmark voisin, de tenir sur un seul axe. ## Les statistiques que l'étude soulève Pour chaque exécution, le moteur enregistre - et les résultats les portent jusqu'à la page : - **score** : arêtes concordantes canoniques (sur 480). Pour un plateau complet avec ruptures, cela égale `480 − #breaks`. - **débit de nœuds** : nœuds de recherche par seconde, un nœud par placement tenté. Rapporté par variante et **jamais comparé entre familles**, parce qu'un nœud qui exécute une arc-cohérence complète n'est pas la même unité de travail qu'un placement naïf. Une propagation lourde échange du débit contre de la qualité de nœud, et l'étude mesure les deux axes plutôt que de les fondre en un seul. Les variantes les plus lentes portent une réserve qu'il vaut la peine d'énoncer franchement : le moteur MRV choisit la case la plus contrainte en parcourant la liste de candidats de chaque case vide à chaque nœud, ce qui est intrinsèquement plus lourd qu'un ordre de remplissage fixe. Deux optimisations préservant le comportement le ramènent à quelques fois le coût des moteurs rapides, plutôt qu'aux milliers de fois qu'il valait autrefois : la recherche de la case la plus contrainte cesse de compter les candidats d'une case dès qu'ils dépassent la meilleure case trouvée jusqu'ici (une recherche de minimum n'a jamais besoin du décompte exact d'une case qui ne peut pas l'emporter), et elle évite de revérifier les arêtes sur lesquelles la liste de candidats est déjà indexée. Ce qu'elle ne fait toujours pas, c'est maintenir le décompte de candidats de chaque case de façon pleinement incrémentale d'un placement à l'autre, ce que ferait un solveur CSP de production ; cette dernière étape devrait suivre comment une pièce nouvellement utilisée affecte le décompte de chaque case, et elle est laissée de côté ici pour garder le moteur lisible. Le classement par score ne dépend d'aucun de ces points, puisque le débit est un axe distinct, mais le débit de nœuds MRV doit se lire comme celui de ce moteur propre plutôt que comme le meilleur possible de MRV. - **profondeur maximale atteinte** : le placement le plus profond effectué par la recherche, sur 256, la mesure par l'étude de la distance parcourue par une variante. Le backtracking strict heurte un mur dans les bas 200 (par lignes 208, la variante stricte la plus rapide 216) ; les ruptures le poussent bien au-delà, jusqu'à 243 à 245. - **profondeur à l'expiration** : où se tenait le front de recherche quand l'horloge a sonné, de sorte qu'une variante qui n'aboutit jamais enregistre quand même où elle travaillait. - **nombre de ruptures** : les arêtes intérieures sur lesquelles la recherche a réellement *rompu* sur le meilleur plateau. C'est zéro pour une variante stricte, et pour une variante à ruptures c'est le décompte que sa propre comptabilité de budget a engagé plutôt que le déficit de score. Sur un plateau achevé, cela égale `480 − score` ; sur un partiel expiré, le déficit compte aussi les arêtes encore vides, donc l'étude rapporte plutôt le vrai nombre de ruptures. L'URL bucas de chaque plateau rend les deux vérifiables dans le [visualiseur](/viewer/). - **retours arrière** : reculs hors d'une case après épuisement de ses candidats. ## Les deux références, et ce que coûte la spécialisation La variante la plus brute, `NAIVE-CLEAN`, est un moteur général lisible : des listes de candidats par case sans sentinelle, indexées par les deux voisins déjà placés, un cache d'arêtes résolues pour qu'aucune rotation ne soit recalculée sur le chemin chaud, et aucune allocation à l'intérieur de la recherche. Sa jumelle, `NAIVE-CODEGEN`, est le *même algorithme* réexprimé sous forme de boucle chaude spécialisée à la main, 16×16 uniquement, par lignes, gardée comme programme séparé pour que le moteur général reste propre. Les faire tourner face à face chiffre le prix du génie de bas niveau : sur ce puzzle, il achète un gain de débit modeste et dépendant de l'instance et, notamment, aucun meilleur score. Les chiffres sont sur la [page des résultats](/fr/research/lab/experiments/raphael-anjou/dfs-study/findings/). ## Correction des propagateurs La vérification en avant, l'arc-cohérence et le contrôle d'approvisionnement par couleur sont corrects *par construction*. Chacun ne rejette jamais qu'un état où une case a déjà un domaine vide, une case qu'aucune pièce inutilisée ne peut remplir, si bien qu'aucun d'eux ne peut retirer une branche qui mène à un achèvement réel. La révision d'arc-cohérence est délibérément prudente là où elle manque de précision : partout où elle pourrait être incertaine, elle élague *moins* plutôt que plus, restant du côté sûr. Les propagateurs ne sont corrects que sous placement strict, car sous un budget de ruptures une anticipation locale peut élaguer une branche que le budget global pourrait encore sauver, si bien que les variantes à ruptures n'exécutent délibérément aucun propagateur. Le registre l'impose : une variante qui associe des ruptures à un propagateur réservé au mode strict échoue à la compilation. Les tests du moteur vérifient cette contrainte ainsi que la comptabilité du score et des ruptures, même si la correction de l'élagage lui-même repose sur l'argument ci-dessus plutôt que sur un test. ## Reproductibilité L'espace de travail du moteur, les dix variantes, les résultats par exécution commités et les scripts de grille vivent tous sous le [répertoire de support](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/dfs-study) de l'étude. `just experiments dfs-study` reconstruit le moteur et rejoue toute la grille ; l'exécution est déterministe à graine fixée, et l'agencement des coins est le seul axe de diversité. ## À lire aussi - [L'étude DFS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. - [Ce que l'étude DFS a montré](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/findings/) — Les trois comparaisons au cœur de l'étude DFS, menées jusqu'au bout : l'ordre de remplissage (le balayage par lignes gagne, un mauvais ordre est catastrophique), les heuristiques (MRV sauve le remplissage du bord d'abord mais coûte du débit ; davantage de propagation n'a rien apporté) et les ruptures (elles brisent le mur de profondeur ; le levier, c'est le calendrier de ruptures, pas le plafond par cellule). - [Ordres de remplissage](https://eternity2.dev/fr/research/build/backtracking/fill-order/) — L'ordre dans lequel un algorithme de retour arrière visite les 256 cases est son unique liberté : il ne coûte rien à l'exécution et fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur. Vingt ans de science communautaire, des guerres fixe-contre-dynamique aux courses de stratégies, jusqu'au carré magique 10×16 et à la recherche en peigne de Verhaard, répondent tous à la même question : quel chemin à travers le plateau est le moins coûteux ? --- # Le moteur de référence qui fait tourner ce site > Le backtracker Rust-vers-WebAssembly qui anime chaque démo en direct et vérifie chaque chiffre de ce wiki. Non pas une machine à records mais un moteur de référence, porté quatre fois et validé octet par octet, conçu pour que les affirmations d'ici soient rejouables. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/engine/ - Mise à jour: 2026-07-17 - Sujets: backtracking, speed - Source: Le dépôt eternity2 sur GitHub — https://github.com/raphael-anjou/eternity2 --- > **À qui ce travail appartient** > > Cette page traite du moteur derrière le site que vous lisez, écrite par la personne qui l'a écrit, [Raphaël Anjou](/fr/research/people/raphael-anjou/). Ce n'est pas un solveur à records de la communauté : ceux-là sont étudiés ailleurs dans ce laboratoire ([Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/), [McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/), [Verhaard](/fr/research/lab/experiments/louis-verhaard/eii/)). Celui-ci siège parmi eux en pair, et un pair modeste : les solveurs à records détiennent les records ; celui-ci détient les preuves. Là où les [expériences nommées](/fr/research/lab/experiments/raphael-anjou/) posent chacune une question et où les [moteurs partagés](/fr/research/lab/experiments/raphael-anjou/engines/) sont l'appareillage sur lequel ces études tournent, cette page est une troisième chose : le petit moteur de référence qui fait tourner le site lui-même, vérifie les chiffres que citent les autres pages et anime chaque démo en direct. Il ne marque aucun record. Sa mission, c'est la vérifiabilité et la pédagogie. ## Ce qu'il est Un petit crate Rust compilé en WebAssembly, tournant en direct dans votre navigateur sur chaque page interactive de ce wiki. Il implémente les grands classiques, sans détour : le jeu officiel de pièces 16×16, un générateur qui construit des puzzles résolubles de n'importe quelle taille (avec un mode optionnel à la manière du vrai E2 qui restreint les couleurs de bordure à la bande du cadre), neuf ordres de visite des cases, un backtracker en profondeur d'abord strict, un scoreur, et une variante tolérante aux ruptures de la recherche, une réimplémentation de l'idée d'indice de rupture du [solveur de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/), conçue pour que les labos d'ici puissent en faire la démonstration. Un choix de conception compte plus que les algorithmes : le solveur est une machine à pas, non une fonction récursive. Les appelants le font avancer un pas borné à la fois, un placement ou un retour arrière, et lisent le plateau entre les pas. C'est ce qui permet à une page web d'animer une vraie recherche plutôt qu'un enregistrement figé : [la page d'observation](/playground/watch/) fait avancer précisément ce moteur, et non une vidéo de celui-ci. ## Un moteur, de nombreux portages Le site fait tourner un seul moteur : le crate Rust/WASM, la référence canonique. Mais le dépôt conserve toute une collection de réimplémentations fidèles de ce moteur dans d'autres langages : un portage TypeScript pur (zéro WASM), un portage C, un portage C++, et des études plus modestes en Python, Lua, COBOL, et même Brainfuck. Chacun est validé octet par octet contre les données de référence que le crate Rust produit : puzzles générés jusqu'à la sortie du RNG, les neuf chemins de remplissage à plusieurs tailles, et des exécutions complètes du solveur avec les comptes exacts de nœuds, de tentatives et de retours arrière. Cette discipline existe pour une seule raison : une démo interactive que vous ne pouvez pas recouper n'est qu'une animation. Deux implémentations indépendantes qui s'accordent jusqu'au dernier retour arrière sont bien plus difficiles à faire échouer de la même manière deux fois, et huit le sont plus encore. Les portages sont une pièce d'exposition, pas des options de build (le site fait toujours tourner Rust), et ils vivent ensemble dans la collection `engine-ports/` du dépôt. Certains (le backtracker en Brainfuck surtout) sont là pour le plaisir. ## Ce qu'il ne prétend pas être Ce n'est pas une machine à records, et il serait trompeur de le présenter comme tel. Le solveur strict ne porte aucun des calendriers de quotas réglés à la main ni aucune des stratégies de redémarrage qui font du [solveur de Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/) le moteur derrière les meilleurs plateaux de la communauté. Le meilleur score produit par [les expériences d'ici](/fr/research/lab/experiments/) est de 463 sur 480 ; le meilleur de la communauté sur le même puzzle est de 470. Les solveurs à records étudiés dans ce laboratoire sont tout simplement meilleurs pour trouver des plateaux. Le débit est un axe distinct, que ce moteur de référence ne poursuit délibérément pas - mais une expérience sœur, elle, le fait. Le [backtracker JIT](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) demande à quelle vitesse une recherche Rust *portable* peut aller, et atteint un [débit de la classe de McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) sur les plateaux difficiles et profonds qui ressemblent au vrai puzzle - à égalité avec son C optimisé à la main sur la même machine (son C reste ~2,3× plus rapide sur les plateaux faciles). C'est un résultat de vitesse, pas de résolution : il plafonne là où tout backtracker strict plafonne. Vitesse et score sont [des axes différents](/fr/research/lab/experiments/raphael-anjou/going-fast/), et le moteur de cette page n'optimise ni l'un ni l'autre - seulement le fait d'être vérifiable. La mission de ce moteur est autre : la vérifiabilité et la pédagogie. Quand ce wiki énonce un compte de nœuds, un chiffre de faisabilité ou un score, l'affirmation est vérifiée par ce moteur, et parce qu'il tourne dans votre navigateur et que sa source est publique, vous pouvez la vérifier aussi. ## Comment il fait tourner le wiki Chaque élément interactif de cette section recherche, c'est ce moteur : les démos DFS en direct, les courses d'ordres de remplissage sur [la page des chemins](/playground/paths/), le labo d'indice de rupture sur [le pôle des solveurs](/fr/research/build/solvers/), le scoring et la vérification du visualiseur de plateaux, et les comptes de référence versionnés que citent les pages de recherche. La suite de tests propre au moteur recoupe de vrais plateaux de la communauté, de sorte qu'un changement qui casserait le scoring ou les conventions de rotation échouerait bruyamment plutôt que de corrompre en silence les chiffres du site. ## Où se le procurer Tout se trouve dans un seul dépôt, [github.com/raphael-anjou/eternity2](https://github.com/raphael-anjou/eternity2), et [faites-le tourner vous-même](/fr/research/build/run-it-yourself/) déroule la construction du moteur, l'exécution de ses tests et la reproduction des résultats publiés, commande par commande. Une réserve sur l'état actuel : les exécutions d'expériences citées dans ce labo étaient exploratoires, leurs plateaux, quand ils sont liés, se vérifient dans le visualiseur, et aucune reproduction empaquetée en une seule commande de ces exécutions n'est encore livrée. ## Ce qui le fait avancer Le moteur ne grandit pas selon son propre calendrier ; il grandit quand [une expérience](/fr/research/lab/experiments/) a besoin de quelque chose. Le solveur tolérant aux ruptures existe parce que démontrer les indices de rupture en exigeait un ; le générateur restreint au cadre existe parce qu'un labo avait besoin de puzzles qui se comportent comme la vraie bordure d'E2. Cela garde le moteur petit, et cela garde chaque fonctionnalité rattachée à une question que quelqu'un a réellement posée. ## À lire aussi - [Les moteurs partagés](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/engines/) — Les moteurs partagés qui sous-tendent les expériences de Raphaël Anjou. Les expériences nommées sont des études qui s'appuient dessus ; voici l'appareillage qu'elles ont en commun. Les préréglages CSP et la réimplémentation de Verhaard sont documentés intégralement, aux côtés du moteur de référence, du backtracker JIT, d'un guide de la vitesse et du harnais de l'échelle de tailles ; les moteurs constructifs ne sont pas encore publiés. - [L'exécuter soi-même](https://eternity2.dev/fr/research/build/run-it-yourself/) — L'ensemble du site, le moteur et chaque résultat de cette section tournent depuis un seul dépôt. Voici comment le lancer, recompiler le moteur WebAssembly et reproduire les chiffres. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. --- # Les moteurs partagés > Les moteurs partagés qui sous-tendent les expériences de Raphaël Anjou. Les expériences nommées sont des études qui s'appuient dessus ; voici l'appareillage qu'elles ont en commun. Les préréglages CSP et la réimplémentation de Verhaard sont documentés intégralement, aux côtés du moteur de référence, du backtracker JIT, d'un guide de la vitesse et du harnais de l'échelle de tailles ; les moteurs constructifs ne sont pas encore publiés. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/engines/ - Mise à jour: 2026-07-22 --- Les [expériences](/fr/research/lab/experiments/raphael-anjou/) sont des études : chacune pose une question et rend compte du plateau qu'elle a atteint. Mais la plupart ne partent pas de rien. Elles s'appuient sur un petit ensemble de moteurs partagés, et le même moteur réapparaît d'une expérience à l'autre. Cette page documente cet appareillage une fois pour toutes, afin que les études puissent pointer ici plutôt que de réexpliquer la machine à chaque fois. Le moteur de référence qui anime les démonstrations en direct du site est une machine différente et a [sa propre page](/fr/research/lab/experiments/raphael-anjou/engine/) ; il apparaît ci-dessous dans son rôle d'appareillage.
- [Les préréglages CSP, mesurés](/fr/research/lab/experiments/single-core-benchmark/csp-presets/) — Un unique moteur de propagation de contraintes doté d'ordonnancements et de propagateurs interchangeables : cohérence d'arc, appariement par graphe de couleurs, plusieurs ordres de remplissage. Des réimplémentations fidèles de techniques connues de la communauté, exécutées selon une douzaine de préréglages sur les dix variantes, de sorte que le coût exact de chaque réglage figure au classement au lieu d'être débattu. - [La réimplémentation de Verhaard](/fr/research/lab/experiments/louis-verhaard/verhaard-reimpl/) — Une réimplémentation intégrale, repartie de zéro, de la méthode eii de Louis Verhaard, son propre binaire n'étant livré sans aucune source et ne tournant pas ici. Recuit par échange sur composition d'ensembles sous la métrique de pavage 2×2 ; sur le véritable puzzle à cinq indices, elle atteint 438 sur 480, en monocœur. - [Le moteur de référence qui fait tourner ce site](/fr/research/lab/experiments/raphael-anjou/engine/) — La machine de vérification et de démonstration du wiki, distincte des moteurs de recherche partagés : le backtracker Rust-vers-WebAssembly qui fait tourner chaque démonstration en direct et vérifie chaque nombre cité sur ces pages, porté quatre fois et testé octet par octet. - [Le backtracker JIT](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) — Un backtracker Rust en profondeur d'abord, sûr et portable, spécialisé à l'exécution en émettant et compilant du Rust propre à chaque puzzle, porté de 43 à 123 millions de nœuds de recherche par seconde sur un cœur et mesuré face au C optimisé à la main de Peter McGavin sur la même machine. - [Aller vite](/fr/research/lab/experiments/raphael-anjou/going-fast/) — Un guide de terrain des solveurs axés vitesse : ce qu'achète le débit brut, les trois choses différentes que les gens entendent par « rapide », et pourquoi le moteur le plus rapide jamais construit ne peut toujours pas résoudre le puzzle. - [L'échelle de tailles](/fr/research/lab/experiments/raphael-anjou/scaling-ladder/) — Le harnais qui fait tourner n'importe quel solveur, inchangé, sur des plateaux plantés entièrement résolubles à N = 8, 10, 12, 14, de sorte que la taille d'effondrement d'une méthode soit mesurée avant de passer des semaines sur le vrai 16×16.
Les deux moteurs constructifs sur lesquels ces études s'appuient également, le producteur en faisceau et l'étape de polissage ALNS, n'ont pas encore leur propre présentation ici ; ces pages sont retenues pour l'instant, et aucun des deux ne figure au classement du benchmark. Là où une expérience pilote l'un d'eux, sa propre page dit ce que fait ce moteur au niveau dont l'étude a besoin, si bien que rien de ce qui suit ne dépend de la lecture d'une page pas encore présente ici. Les deux moteurs documentés et mesurés intégralement sont les préréglages CSP et la réimplémentation de Verhaard. ## Pourquoi documenter les moteurs à part des expériences Une étude et son moteur répondent à des questions différentes. Le moteur répond à *comment fonctionne la recherche* - les structures de données, l'ordre de remplissage, les propagateurs - et il est réutilisé sans modification à travers de nombreuses études. L'étude répond à *ce qui se passe quand on braque ce moteur sur une idée particulière* : un a priori appris, une bordure fixée, un masque de rupture. Les tenir séparés permet à un lecteur qui veut comprendre l'a priori de PRIOR de ne pas avoir à relire le fonctionnement d'un faisceau, et à un lecteur qui veut le moteur de l'obtenir en un seul endroit, à jour et complet. Là où ces moteurs s'affrontent directement sous un budget fixé, ils apparaissent sur le [benchmark monocœur](/fr/research/lab/experiments/single-core-benchmark/). La théorie générale derrière chaque méthode se trouve dans la section [construire-un-solveur](/fr/research/build/) ; ces pages sont les moteurs spécifiques tels que construits et mesurés ici. --- # Lire l'avenir d'une rangée dans ses pièces restantes > Une énergie libre issue de la propagation de croyances, calculée sur les pièces restantes de la dernière rangée, prédit le rang de la meilleure fin possible. Le signal n'est pas un proxy du score brut, survit à un changement de producteur et meurt au-delà d'une rangée. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/frostline/ - Mise à jour: 2026-07-22 - Sujets: construction, structure, search-space - Reproduire: `just research-frostline` - Source: Yedidia, Freeman, Weiss : Understanding Belief Propagation and its Generalizations (MERL TR2001-22) — https://www.merl.com/publications/docs/TR2001-22.pdf - Source: Reproduction versionnée : plan, script et résultats (ce projet) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/tail-finishability-frostline --- Un constructeur classe ses plateaux partiels par arêtes appariées. Ce nombre ne dit rien de la capacité des pièces restantes à bien finir les cases qui restent. FROSTLINE pose la question : une quantité bon marché venue de la physique statistique, l'énergie libre de Bethe d'un modèle de propagation de croyances sur les pièces restantes de la dernière rangée, prédit-elle le meilleur score que cette rangée peut encore atteindre ? Sur une rangée, oui : rho de Spearman proche de -0,75, en validation croisée, et le signal survit à un changement de producteur. ## Comment ça marche On gèle les quinze premières rangées d'un plateau complet et on prend comme réserve les seize pièces que le plateau lui-même avait placées en rangée 15, ce qui garantit que la dernière rangée reste remplissable. Deux nombres sont alors calculés par plateau : - **L'étiquette.** Un solveur exact (une programmation dynamique par masques de bits sur les sous-ensembles de pièces et les couleurs de jointure, exacte en quelques millisecondes à 16 cases) donne le meilleur score de fin atteignable : les 15 arêtes internes de la dernière rangée plus les 16 arêtes de jointure contre la rangée 14, sur 31. - **Le prédicteur.** Un graphe de facteurs sur les seize cases vides, avec des états tirés de la réserve et des facteurs de paire qui récompensent l'accord de couleur à température inverse beta. La propagation de croyances somme-produit tourne dessus et on lit l'énergie libre de Bethe. Une énergie plus basse devrait signifier une fin plus atteignable. Deux choix de modélisation comptent. La fin de plateau est un problème de couplage maximal, pas de contraintes dures : un désaccord de couleur coûte un point au lieu d'être interdit, le graphe est donc un modèle souple à beta fini et non une instance de satisfiabilité. Et la jointure contre les rangées gelées doit être un facteur souple ; l'étude source a mesuré qu'un filtre de jointure dur se contredit sur 5 cases sur 16 des vrais sommets quasi optimaux. Sur une rangée, le graphe résiduel est une chaîne : la propagation de croyances y est exacte et l'énergie libre est le vrai logarithme de la fonction de partition. ## Le résultat L'étude source a trouvé l'effet sur 103 sommets distincts issus d'un faisceau de largeur 2048, scores bruts 446 à 452. La reproduction versionnée régénère tout dans un autre régime : 120 sommets gloutons ensemencés, scores bruts 361 à 396, étiquettes de fin 16 à 22. La colonne attendue cite l'étude source ; la colonne mesurée est cette exécution. > **[Figure]** Attendu vs mesuré, dernière rangée (16 cases) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. Le seuil pré-enregistré (|rho| d'au moins 0,4, ou AUC au-dessus de 0,75 ou en dessous de 0,25) est franchi à chaque beta essayé, avec le signe de la source. Deux lectures de la table : - **Pas un proxy du score brut.** À score du plateau contrôlé, la corrélation partielle reste à -0,74. Dans le régime glouton, le score brut est presque muet sur la fin (+0,08 contre +0,605 chez la source), ce qui rend ce contrôle plus strict ici, pas plus faible. - **On mesure le plateau, pas le producteur.** Le signal a été trouvé sur des sommets de faisceau et se reproduit sur des sommets gloutons, un producteur différent à distribution de qualité plus basse et plus large. Une statistique qui survit à cet échange lit les pièces restantes, pas un artefact de la façon dont le plateau a été construit. Des plateaux isolés rendent le point concret : le [pire sommet de fin](/viewer/?puzzle_size=16&board_edges=abeaachbadpcadidaftdabjfaeibaeteafoeaemfaeueabveacsbadtcadhdaacdencahhunptwhhjnttrujjkgrillkthjlourhmhjuuqlhvntqspwnpskphvjscafvcidaujsiwgsjnnpgujuogisjliwijurirsmtjprsllkptjoqwwvgksmwjuhsfadudweasoqwsujopmmuulwmslrlwvwlrnkvmpjnrilpkkgiokvkvulkmhgihrphdabmepcaqgmpjiggmrwmwvlrrtkvwvwtkvwvjgwvlorggllovmqllljmghhlpnqrbacrcocamjvogtgiwushlplukrwpwhtrwkuhwhqkruhhlgvvqmqgjovmpproqrqpcabhckfasiukgqiivprqlmtpwuhmtmsuujvmqovjhmkqvwppquiwvgourtrgqvgtbacvfjbaunrqigpnringtvvihnlvsvpnvlwvhwqlkrvwphkriqphoqnqrtrqgwstdafwbtearkgtpgnkntovvphtlsnppgmswqngqwtqjhhwkprhppjpnvokrkhvsntkfacnendarkmnnhskomnihmrmnwlmmsownhlsttkmhustsrtujminorrmhmortlgmcafhdofamnlosnnnnvjnriliwtgiopstloupklwosuhltnpgiiwgrluqqttlgkogfacrfubalrqwnpmojijpjjmiqphjsuvpkjhuttpjjistqwoiwolluisogmkiokqmcacpbtfaqikljvvijklquwokpmiwrgtmhsspqugssgruoslgkqjsssskkrvmqhwmcadgfufakounvuwolijjowuiinqwtkknsoiigtnqrvmtusuvgvgshunvvtkuwuwsdadsfgfauqnontmqjkqtugolqooiriqoommisommlnkojronijjrnvijktnlqosneabobdaagdadteadqbaegbabjbabqeacseaepbaepcablfaeqfafqeafpdaehbafcaad) de la reproduction fait 375 en brut avec une meilleure fin de 16, tandis que le [meilleur](/viewer/?puzzle_size=16&board_edges=adcaadhdadsdadidacidabhcacsbadpcadgdaendabveabgbabjbacvbadtcaacdcqeahwmqsoqwiqwoiklqhvrkmqlvphjqgimhngrivvlggsgvjprsvwpptwvwcafvepdammupqgqmwwvglwvwtqqwlhuqjlthmnwlrqunlhwqgwqnrjkgpppjvulkfafudofauploqgmpvomjvuwoqnoukolnttkmwhptunvhsnnnqoqnkuwojvmulwvvfacrfhcalghhmkigmnrknpgnoqtjjklqkgikpnigvoknnjroqovjwmsomsomvpnscaepchbahruhijurrijjgqiittlqlgmtiiwgisoikqjsrtrqvvitssphouisnhhueafqbjfaumhjulwmjmllinjmlktnrwpkwgsjouvgjtrurgrtisjgpgmsigtghmkqfaemfqfahnlvhsknlgosjigguksipgnksqugvgtqrusgrhoujnthmpjnpskpkssseaesfgfallogkillommiiwpmstgwnqgtuiwqliwistjiopsttnpgjnnvkvrnswuweadwfjbaovmjlrwvmorrpprogwvjksmwutmsrsmtjuhssthuplmtrqwlrqpqooiqdafwboeamniopmonrgtmolugsnhltkknqtjkmqnthmrmhiqpmorhwuiooujuinqwfacneqbailprorgltkvruvtkmkrvuhwkjnvilomnriqolirirqvpvntqjmijqkwhcacobpcajttpgiwtvwvkollwrlslwoklvntomokqqrlukgtrgkogtvphijvvjlijcadgcrbatusrhmwuvwkrlsuhuvuskokvtrwhpnqrplsnulpllkplprhkvmtrmrwmdaftbmdasiujjpjikrphunkoushwhvjswjhhhukjsntkpwnspsuvnqosujoshhrpfadubdaaueaencaepcackfachbaftfabubafteabteaelfaeoeafibaeteadpbaeeaab) fait 372 en brut avec une fin de 22. Le plateau au score brut plus bas a la meilleure fin. ## Ce qui ne suit pas - **Le signal meurt au-delà d'une rangée.** À étiquette constante et coupe plus haute, la corrélation de la source se dégrade de -0,74 à 16 cases résiduelles à -0,19 à 32 et -0,12 à 48, pendant que le domaine moyen par case passe de 12,5 à 32,6 puis 72,2. FROSTLINE est un oracle de fin de dernière rangée, pas un signal de pilotage en cours de construction. - **Il n'achète pas (encore) de meilleurs plateaux.** Dans l'étude source, s'en servir pour choisir quels partiels reçoivent du calcul exact ne bat pas le choix par score brut : le score final réalisé est dominé par l'étalement du score brut, quand l'énergie libre ne prédit qu'un petit delta de fin. Le discriminateur est réel ; la valeur de sélection, sous cette forme, non. - **Les quantités secondaires dépendent du régime.** La corrélation de l'entropie de Bethe change de signe entre régimes, et deux quantités nulles sur les sommets de faisceau portent un signal faible sur les sommets gloutons. Rien de tout cela ne touche le résultat principal, mais tout est consigné en réserve dans le plan versionné. - Rien ici ne déplace un score de plateau complet ; pour l'état réel du front, voir la [page des records](/fr/research/records/). ## Reproduire L'exécution est ensemencée et déterministe : `just research-frostline` régénère les 120 sommets, les étiquettes exactes et la table de corrélations complète en deux minutes environ sur un cœur, et reproduit le `frostline_r15.json` versionné. C'est une reproduction de palier qualitatif : le signe et la bande de force de l'effet sont régénérés ; l'ensemble de sommets de faisceau de l'étude source ne l'est pas. La liste complète des nombres attendus et l'argument de fidélité d'échelle vivent dans le plan lié ci-dessus. ## À lire aussi - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). --- # Aller vite : quand un solveur dépense son budget en vitesse > Certains moteurs Eternity II mettent tout leur effort à parcourir l'arbre de recherche le plus vite possible ; d'autres le mettent dans le jugement sur où chercher. Voici le plaidoyer pour les premiers - ce qu'achète le débit brut, les trois choses différentes qu'on appelle « rapide », et pourquoi le moteur le plus rapide jamais construit ne sait toujours pas résoudre le puzzle. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/going-fast/ - Mise à jour: 2026-07-20 - Sujets: speed, backtracking - Source: McGavin: even at 100M nodes/s, the 5-hint tree is 4.9×10³² years (groups.io msg 11201) — https://groups.io/g/eternity2/message/11201 - Source: Razvan's epitaph for the 2025 speed thread: 'we will not make a dent' (groups.io msg 11657) — https://groups.io/g/eternity2/message/11657 --- Tout solveur Eternity II a un budget fixe d'effort humain et de temps machine, et il dépense ce budget à l'un de deux endroits. Il peut le dépenser en **vitesse** - parcourir l'arbre de recherche aussi vite que le matériel le permet, essayer des milliards de placements par seconde - ou en **jugement** - être plus fin sur *quels* placements essayer, pour parcourir un arbre plus petit et meilleur. Cette page est le plaidoyer pour les premiers : ce qu'aller vite achète vraiment, ce qu'il n'achète pas, et comment en parler sans se leurrer. C'est aussi le foyer conceptuel d'un résultat précis : un [backtracker Rust portable qui égale le C optimisé à la main de McGavin sur les plateaux difficiles](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) - le moteur le plus rapide de l'histoire de la communauté - et tourne à environ 44 % de sa vitesse sur les faciles. Cette page-là est le journal d'ingénierie ; celle-ci est ce que le journal *signifie*. ## Trois choses qu'on appelle « rapide » La plus grande source de confusion en vingt ans de discours sur la vitesse est que « rapide » nomme trois quantités sans rapport. Les garder distinctes, c'est déjà gagner l'essentiel de la bataille. > **Les trois axes, et pourquoi ils ne se convertissent pas** > > **1 · Placements par seconde (alias pièces/s, nœuds/s).** À quelle vitesse la recherche *avance*. C'est un nombre moteur-*et-plateau* : le C de McGavin fait ~287 M sur un plateau facile mais ~105 M sur un difficile ; le [moteur JIT présenté ici](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) fait ~122 M sur le facile et ~110 M sur le difficile - égalant le C là précisément où le puzzle est difficile. Plus grand veut dire plus rapide, mais toujours *sur le même plateau*. **2 · Arêtes appariées sur 480.** À quel point un plateau est *bon*. C'est là que vivent les [records](/fr/research/records/) - le plafond est 470. Cela n'a rien à voir avec l'axe 1 : un moteur lent peut trouver un meilleur plateau qu'un rapide, et le fait couramment. **3 · Placements agrégés par seconde.** Un nombre de *grappe* - beaucoup de machines additionnées. Le fameux « ~300 M/s » de la communauté qu'on attache parfois à un seul moteur est en fait la [grappe du Eternity 2 Syndicate](/fr/research/build/faster/distributed-solving/) : ~20 machines additionnées, pas un cœur. Un grand nombre sur l'axe 1 ne dit rien de l'axe 2, et l'axe 3 n'est pas du tout une vitesse de moteur. Toute affirmation rigoureuse de vitesse dit sur quel axe elle porte. Pour l'histoire précise et sourcée de la façon dont la communauté a fixé sa définition d'un « nœud » - pièces *posées*, à la manière des échecs, et pourquoi même cela flatte les ordres de remplissage par ligne - voyez la section sur la discipline de mesure du [registre d'ingénierie des solveurs](/fr/research/build/faster/solver-engineering/). Cette page prend ce vocabulaire pour acquis et demande à quoi sert la vitesse. ## Ce qu'achète la vitesse Des choses réelles, et il vaut la peine d'être concret, car le plaidoyer *contre* la vitesse ne porte qu'une fois qu'on respecte le plaidoyer *pour*. - **L'énumération vérifiée.** Un moteur rapide et déterministe peut parcourir un arbre de référence jusqu'au dernier nœud et le *compter*, transformant la théorie en fait vérifié. Les [benchmarks](/fr/research/build/benchmarks/) de la communauté - protocoles de recensement, le 10×10 finalement tombé après ~180 années-cœur - sont des victoires de débit. On ne vérifie pas ce qu'on ne peut pas finir. - **Le déterminisme comme somme de contrôle.** Deux moteurs rapides qui parcourent le même arbre doivent annoncer le même nombre de nœuds. Cette égalité est la façon dont portages, réécritures et matériel neuf prouvent qu'ils parcourent le même arbre avant que leur vitesse ne signifie quoi que ce soit - c'est la colonne vertébrale de l'[échelle d'optimisation du moteur JIT](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/), où chaque échelon s'arrête au nombre de nœuds identique. - **Plus de tentatives par seconde sous une heuristique.** La vitesse est un multiplicateur du jugement : une bonne boucle de réparation qui tourne deux fois plus vite a deux fois plus de chances d'un meilleur plateau dans le même temps d'horloge. La vitesse ne *remplace* pas le jugement, mais elle amplifie celui qu'on a déjà. ## Ce que la vitesse ne peut pas acheter Le mur. Et personne n'a été plus clair là-dessus que celui qui a construit le moteur le plus rapide. Sur son meilleur chemin de placement à cinq indices - déjà un arbre bien plus petit que le puzzle brut - McGavin a calculé que même à cent millions de nœuds par seconde, la recherche prendrait environ **4,9 × 10³² ans**, et qu'y jeter des milliards de cœurs laisse quand même « des ordres de grandeur au-delà de l'âge de l'Univers » ([msg 11201](https://groups.io/g/eternity2/message/11201)). Quand le fil sur la vitesse de 2025 s'est éteint, Razvan en a écrit l'épitaphe : quelle que soit notre vitesse de vérification, « nous n'y ferons pas une brèche » dans l'espace ([msg 11657](https://groups.io/g/eternity2/message/11657)). L'arithmétique est implacable et c'est la [leçon centrale](/fr/research/why/prune-vs-speed/) du site : une accélération à facteur constant, si durement gagnée soit-elle, se *multiplie contre* un nombre si grand qu'aucun facteur constant ne compte. Doubler la vitesse d'une recherche qui prendrait 10³² ans donne une recherche qui prend 5 × 10³¹ ans. Rétrécir l'*arbre* est le seul levier doté d'exposants. ## L'expérience contrôlée C'est exactement pourquoi le [résultat du backtracker JIT](/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) est présenté comme une expérience de vitesse et rien d'autre. Il répond à une question nette et bornée - *du Rust portable et sûr peut-il atteindre le débit d'un C optimisé à la main ?* - et la réponse dépend du plateau : sur les plateaux difficiles et profonds comme le vrai puzzle, il **égale** le C en parcourant l'arbre identique ; sur les plateaux faciles et peu ramifiés, le C est environ 2,3× plus rapide. Cela tranche une question ouverte plus petite que la communauté avait laissée en suspens : l'avantage fameux de ~4× du moteur de McGavin sur les solveurs « typiques » relevait-il de l'**art de la génération de code** ou simplement d'un **matériel plus récent** ? En gardant le matériel fixe et en atteignant sa vitesse *sur les plateaux difficiles* depuis du code portable, on montre que c'était l'artisanat - le même artisanat, reproductible dans un langage sûr, consigné échelon par échelon. (Cela montre aussi où l'artisanat paie le plus : sur les plateaux faciles, où le travail par nœud est quasi gratuit, sa génération de code plus serrée gagne encore.) Et il s'arrête ensuite, sans détour, là où tout moteur rapide s'arrête : pointé sur le vrai puzzle, il plafonne dans les hauts 300 sur 480, parce qu'un backtracker strict est un superbe arpenteur d'arbre et un piètre solveur. Les records appartiennent aux moteurs qui dépensent leur budget dans l'*autre* sens - dans le [jugement destruction-réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/) et dans [ce qu'une recherche a le droit d'apprendre](/fr/research/lab/experiments/raphael-anjou/learning/) - et ils y arrivent à une fraction de la vitesse. Voilà tout le compromis. La vitesse est réelle, apprenable et mérite d'être maîtrisée ; le moteur JIT prouve qu'on peut la maîtriser dans un langage sûr. Mais sur Eternity II, la voie rapide et la voie gagnante ne sont pas la même voie. C'est pourquoi la question d'ingénierie intéressante n'est jamais seulement « à quelle vitesse » - c'est « rapide *à quoi*, et est-ce là l'obstacle ? » Une note sur ce qui est livré aujourd'hui : les exécutions derrière ces chiffres étaient exploratoires, tout plateau lié depuis ces pages se vérifie dans la visionneuse, et aucune reproduction empaquetée en une seule commande n'existe encore. ## À lire aussi - [Le backtracker JIT : du Rust portable à égalité avec du C optimisé sur les plateaux difficiles](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/jit-backtracker/) — Un backtracker Rust en profondeur d'abord, sûr et portable, spécialisé à l'exécution en émettant puis compilant du Rust propre à chaque puzzle, porté de 43 à 123 millions de nœuds de recherche par seconde sur un cœur. Mesuré équitablement face au C de Peter McGavin sur la même machine : à égalité sur les plateaux difficiles et profonds comme le vrai Eternity II, et à environ 44 % de sa vitesse sur les faciles. Chaque échelon parcourt l'arbre identique ; tout le gain vient du code, pas de l'algorithme. - [Le backtracker C de McGavin : l'histoire du débit, reconstruit ici](https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/backtracker/) — Le backtracker C de Peter McGavin, le plus rapide de la communauté : une recette d'optimisation de 2007 capitalisée pendant deux décennies via code généré, tables de correspondance et astuces de compteur, puis compilée sur mon M1 et pointée vers le vrai puzzle à 256 pièces, où en mono-cœur elle dépasse 200 des 256 pièces à ~109M placements/s. - [Ingénierie de solveur : l'artisanat sous l'algorithme](https://eternity2.dev/fr/research/build/faster/solver-engineering/) — Tous les solveurs record exécutent le même backtracking en profondeur d'abord. Ce qui les distingue, c'est la couche en dessous : tables de correspondance, hachages parfaits, structs taillées pour le cache, code généré, archéologie du compilateur. C'est cet artisanat qui décide si un nœud coûte 26 cycles ou 2 600. Vingt ans de registre d'ingénierie de la communauté, technique par technique, et ce que tout cela a rapporté. - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. --- # L'étude sur les indices > Donner à un backtracker cinq pièces correctes gratuitement, dans la géométrie même des indices du puzzle. Il s'avère que cela n'aide pas, et selon l'ordre de remplissage cela peut nuire gravement, car une pièce épinglée est une contrainte dure qu'un ordre de remplissage fixe doit satisfaire à son arrivée. Une famille d'ordres de remplissage, exécutée sur les mêmes plateaux indicés, un seul cœur, mesurée contre l'absence totale d'indices. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/ - Mise à jour: 2026-07-21 - Sujets: backtracking, search-space, structure - Reproduire: `just experiments hint-study` - Source: Générateur exécutable + résultats versionnés + scripts (le répertoire d'appui de cette étude) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/hint-study --- Il existe une réponse folklorique à la question de savoir comment rendre Eternity II plus facile : donner au solveur quelques pièces correctes. La question naturelle qui suit est *combien*, et la [discussion communautaire sur la géométrie des indices](/fr/research/why/hint-geometry/) l'a déjà affinée en *où*. Cette étude pose une question plus élémentaire, que ces deux-là enjambent : sur nos propres plateaux générés, les indices aident-ils *tout court* ? Pour un backtracker chronologique, la réponse est **non**. Amorcez-le avec les cinq pièces officielles des indices, à leurs positions réelles sur le plateau, puis mesurez-le contre le même plateau exactement sans aucun indice : il fait moins bien sur chaque ordre de remplissage testé, sans exception. Sur un balayage compact ligne par ligne, les cinq pièces correctes ne coûtent que dix à vingt arêtes appariées ; sur l'ordre qu'un débutant choisirait en premier, « rejoindre les indices et les relier entre eux », elles en coûtent environ trois cent quarante-cinq, transformant l'un des meilleurs ordres sans indices en le pire de tous. La raison est simple une fois qu'on la voit : pour un solveur qui remplit les cases dans un ordre fixe, une pièce épinglée n'est pas une information gratuite mais une **contrainte dure qu'il doit satisfaire à l'instant où il l'atteint**, et parfois il ne le peut pas. ## Le voir : cinq indices, quatre ordres Chaque plateau ci-dessous se remplit selon un ordre différent, en boucle. Rien n'est en train d'être *résolu* ; c'est seulement l'ordre dans lequel la recherche visiterait les cases, rendu visible. La case lumineuse est celle qui vient d'être placée, et la traînée derrière elle est le **front d'onde** récent, de sorte qu'on voit combien de bord ouvert chaque ordre garde en avançant. Ce bord ouvert, la frontière, est ce qu'un backtracker paie : son branchement croît avec la frontière, et une petite frontière est aussi ce qui laisse à la recherche la marge de contourner un épinglage hostile. > **[Interactive: HintPathFill]** Rendered on the canonical page (link above); not shown in this markdown export. Un balayage ligne par ligne garde une seule frontière mince et la fait rouler le long du plateau, si bien qu'en rencontrant une pièce épinglée il peut ajuster l'unique ligne qu'il est en train de construire. Les ordres qui cherchent les indices font l'inverse. Spiraler vers l'intérieur ou l'extérieur traîne un anneau entier comme frontière, et tracer les indices éparpille son front d'onde à travers le plateau dès le tout premier coup, s'engageant partout avant de pouvoir savoir si les engagements sont cohérents. Le balayage compact survit aux cinq indices ; les ordres qui les cherchent en sont défaits. ## Ce que l'étude mesure Deux comparaisons appariées, exécutées sur les mêmes plateaux générés : - **Les indices aident-ils, et quel ordre leur survit ?** Fixer les indices (cinq, dans la forme des cinq indices d'Eternity II lui-même) et ne faire varier que l'ordre de remplissage, mesuré contre le plateau identique sans indices. C'est la colonne vertébrale de l'étude : elle montre que les indices n'aident jamais, et que l'ampleur du dommage est fixée par l'ordre de remplissage et sa frontière ouverte. - **Le nombre.** Ajouter *plus* d'indices aide-t-il ? Un peu, mais la façon naïve de le mesurer est *confondue*. Un bloc d'indices groupés engrange gratuitement un tas d'arêtes correctes du seul fait d'être épinglé ; ce « plancher » gratuit flatte les dispositions groupées au score brut sans rien dire de la question de savoir si le plateau est devenu plus facile à *terminer*. La [page de méthode](/fr/research/lab/experiments/raphael-anjou/hint-study/method/) définit le plancher et les métriques qui y sont immunisées (taux de résolution et score gagné) qui voient au travers. Tout ici est construit et mesuré de zéro : notre propre générateur paramétrique de plateaux, notre propre famille de backtrackers, notre propre scoreur canonique, et un solveur à faisceau comme contraste non backtracker. Aucun plateau, puzzle ou moteur communautaire n'est utilisé ; seule la *forme* de l'arrangement à cinq indices est empruntée à la discussion de la liste, comme géométrie à tester. ## Comment lire les chiffres Chaque plateau est re-scoré par un unique scoreur canonique d'arêtes appariées qui ne compte jamais une couture face au bord (grise), la même convention que le [benchmark](/fr/research/lab/experiments/single-core-benchmark/) et [l'étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/). Le maximum est 480. Chacune des quinze graines est une instance générée véritablement distincte, et non simplement une graine de solveur différente, de sorte que la dispersion entre graines est une vraie variance d'instance à instance et est rapportée comme telle. Aucun score auto-déclaré n'est pris pour argent comptant. Les comparaisons sont développées sur la [page des résultats](/fr/research/lab/experiments/raphael-anjou/hint-study/findings/) ; comment les plateaux sont générés, pourquoi la recette de couleurs reste fidèle à toutes les tailles, et ce que signifie chaque métrique figurent sur la [page de méthode](/fr/research/lab/experiments/raphael-anjou/hint-study/method/). ## Pages de cette section - [Comment l'étude sur les indices est construite](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/method/) — L'appareillage derrière l'étude sur les indices : un générateur paramétrique de plateaux fidèle à la recette de couleurs d'Eternity II à toutes les tailles, la famille de backtrackers à ordre de remplissage, l'unique scoreur canonique, et le morceau d'arithmétique qui garde l'axe du nombre significatif, le plancher des coutures épinglées. - [Ce que l'étude sur les indices a montré](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/findings/) — Les résultats, développés : sur ces plateaux les cinq indices en forme d'indices officiels n'aident jamais un backtracker, ils vont d'un coût modéré à une catastrophe, et l'ordre de remplissage décide de l'ampleur des dégâts ; les scores sont bimodaux, pas un gradient lisse ; et la question du nombre d'indices est confondue par un plancher gratuit de coutures épinglées. ## À lire aussi - [Les expériences de Raphaël Anjou](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/) — Un carnet d'expériences de recherche sur Eternity II, organisé autour des moteurs partagés qui les font tourner, des pipelines de combinaison qui courent après le score, de quatre études qui décortiquent un paradigme de recherche une décision à la fois, et de résolutions exactes de fin de partie. Chacune expose son idée, son meilleur plateau et les questions qu'elle laisse ouvertes. La meilleure atteint 463 sur 480. - [L'étude DFS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. - [L'emplacement des indices l'emporte sur leur nombre](https://eternity2.dev/fr/research/why/hint-geometry/) — Sur un casse-tête 16×16 construit à l'image d'Eternity II, dix-huit indices dispersés sur le plateau le résolvent en quelques minutes, là où les entasser en rangées contiguës en réclame une centaine rien que pour ramener la recherche à des dizaines de milliards de placements. C'est la position, non le nombre, qui fait levier, et elle pointe droit vers la fin de partie. --- # Ce que l'étude sur les indices a montré > Les résultats, développés : sur ces plateaux les cinq indices en forme d'indices officiels n'aident jamais un backtracker, ils vont d'un coût modéré à une catastrophe, et l'ordre de remplissage décide de l'ampleur des dégâts ; les scores sont bimodaux, pas un gradient lisse ; et la question du nombre d'indices est confondue par un plancher gratuit de coutures épinglées. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/findings/ - Mise à jour: 2026-07-21 - Sujets: backtracking, structure, search-space - Source: Résultats par exécution versionnés (results.jsonl) et le script d'analyse — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/hint-study --- L'étude fixe cinq indices dans la forme des cinq indices d'Eternity II lui-même, exécute huit ordres de remplissage sur les plateaux identiques, et pose une question simple : que valent ces cinq indices ? Chaque nombre ci-dessous porte sur quinze instances générées distinctes, un seul cœur, huit secondes par exécution, re-scoré sur 480 par un unique scoreur canonique. La comparaison est appariée, chaque ordre de remplissage voit les mêmes plateaux, et la dispersion par instance est montrée plutôt que moyennée, car il s'avère qu'elle compte plus que n'importe quelle médiane. ## Les indices n'aident pas, et l'ordre de remplissage décide de combien ils nuisent Commençons par la distribution. Chaque point est un plateau ; le trait est la médiane. > **[Interactive: HintStudyCharts]** Rendered on the canonical page (link above); not shown in this markdown export. Deux choses sont visibles d'un coup. D'abord, les scores sont **bimodaux** : sur la plupart des ordres, un plateau soit grimpe dans les 360, soit cale à deux chiffres, avec peu d'entre-deux. Une médiane tracée à travers cela résume un fossé, pas un centre, et c'est exactement pourquoi les points sont montrés. Ensuite, les ordres se séparent nettement : les trois balayages compacts (ligne par ligne, son miroir de bas en haut, le peigne de Verhaard) se tiennent haut sur la plupart des plateaux ; les ordres fragmentants restent bas de bout en bout. Mais la séparation compact-contre-fragmentant n'est pas le vrai résultat, car elle invite la mauvaise question, « quel ordre *utilise* le mieux les indices ? ». La question qui compte est de savoir si les indices aident *tout court*. Le deuxième graphique y répond, et la réponse est non. Il montre le **changement apparié** qu'apporte l'ajout des cinq indices : le score de chaque ordre sur un plateau moins son score sur le *même plateau sans indices*. Chaque barre est à zéro ou en dessous. Les cinq indices en forme d'indices officiels n'aident pas un seul ordre de remplissage. Sur les balayages compacts ils ne coûtent que dix à vingt points. Sur la spirale sortante ils en coûtent environ quatre-vingt-dix. Et sur les deux ordres qui cherchent les indices ils sont ruineux : l'ordre `trace-hints`, qui dessine un squelette entre les indices avant de remplir, perd environ trois cent vingt-cinq, et le flot `connect-hints-first` perd à peu près **trois cent quarante-cinq**, faisant passer un ordre qui score parmi les *meilleurs* des huit sans indices au *pire* avec eux. Plus un ordre poursuit délibérément les indices, plus ils lui coûtent. Donner au solveur cinq pièces correctes, dans la géométrie même des indices du puzzle, a rendu chacune de ses versions pire. ## Pourquoi un indice correct fait mal Une pièce épinglée n'est pas une information gratuite pour un backtracker chronologique ; c'est une **contrainte dure que l'ordre de remplissage fixe doit satisfaire à son arrivée**. Quand un balayage compact descend jusqu'à une case intérieure épinglée, la pièce est déjà là, et la ligne qu'il vient de construire doit s'apparier aux faces de cette pièce. La plupart du temps il le peut, à petit prix : le balayage contourne la contrainte et perd quelques dizaines de points. Mais sur certains plateaux la pièce épinglée contredit ce à quoi la frontière s'est engagée, et il n'y a pas de réparation locale : la recherche heurte un mur qu'elle ne peut franchir et s'agite en dessous. C'est le mode calé, et ce sont les indices qui le créent. Sur l'ordre ligne par ligne, les plateaux qui s'effondrent à deux chiffres sont précisément ceux où un épinglage en forme d'indice tombe là où le balayage ne peut pas l'honorer ; le même plateau sans épinglages grimpe dans les 360 et 370. Cela recadre le résultat sur l'ordre de remplissage. L'ordre compte toujours (un balayage compact survit aux contraintes des indices avec une cicatrice de dix à vingt points tandis que `connect-hints-first` en est détruit), mais ce que l'ordre achète n'est pas « bien utiliser les indices ». C'est **leur survivre**. La frontière en est la raison : un ordre qui garde une unique frontière serrée a la marge de contourner un épinglage défavorable ; un ordre qui s'est déjà fragmenté en cinq taches ouvertes s'est engagé partout à la fois et ne le peut pas. Cette relation à la frontière, à travers les huit ordres, est d'une netteté frappante, et elle vaut d'être montrée précisément parce que la frontière peut se calculer depuis la géométrie d'un ordre sans aucun solveur, puis se confronter aux scores mesurés : > **[Interactive: FrontierPhaseChart]** Rendered on the canonical page (link above); not shown in this markdown export. La frontière ouverte moyenne qu'un ordre maintient prédit de près son score médian à travers ces huit ordres. C'est une relation descriptive forte, pas une loi prouvée sur huit points, et elle cesse de trancher le classement parmi les ordres fragmentants à droite (la spirale entrante maintient une frontière plus grande que la sortante et score pourtant plus haut). Mais la direction est exactement ce que le mécanisme prédit : le coût de branchement est multiplicatif en la frontière, un ordre qui garde la frontière petite garde donc la marge d'absorber un épinglage hostile. Pour le contraste, le solveur à faisceau, qui n'est pas un backtracker chronologique et ne paie pas le coût de frontière de la même façon, atteint une médiane dans les 450 sur ces mêmes plateaux indicés. Les indices et les plateaux sont loin d'être insolubles. C'est spécifiquement le backtracker *chronologique à ordre fixe* qui ne parvient pas à transformer cinq pièces correctes en progrès. ## Le nombre : un seuil, pas un gradient, et un plancher qui le cache La même question un cran plus loin : ajouter *plus* d'indices aide-t-il ? La réponse n'est pas un « plus, c'est mieux » lisse, et le nombre brut cache quelle part est réelle. Le graphique du bas ci-dessus scinde le score de chaque disposition en deux parts. Le **plancher** est l'ensemble des coutures que les épinglages complètent gratuitement, parce que leurs deux extrémités sont épinglées à la vraie solution ; la part **gagnée** est ce que la recherche a réellement trouvé. Un bloc groupé plein engrange un plancher élevé (cinq blocs 4×4 épinglent un quart des coutures du plateau avant que la recherche ne fasse un seul pas), tandis qu'un treillis épars, dont les indices ne se touchent jamais, n'engrange rien. Une comparaison au score brut offre donc aux dispositions groupées cent points d'avance qui ne disent rien de la progression de la recherche. Lisez la colonne « gagnée » à travers les treillis épars, dont le plancher est nul si bien que la part gagnée *est* le score, et un seuil apparaît. Un épars clairsemé, quatre à seize indices, ne gagne presque rien (dans les vingt) : les épinglages ne sont que des contraintes éparpillées sur lesquelles le balayage ne cesse de trébucher, exactement l'effet des cinq indices. Mais continuez d'en ajouter et le tableau bascule. Vingt-cinq indices épars gagnent 127, et trente-six, un treillis de six par ligne, **résolvent le plateau entièrement sur la plupart des instances**. Sous le seuil, les indices épars ne font que gêner ; au-dessus, il y en a enfin assez pour découper le plateau en morceaux suffisamment petits pour que le balayage les termine. Ce n'est pas un gradient d'aide, mais un mur que le nombre doit franchir. Les blocs groupés montrent l'image en miroir. Leur score brut est surtout du *plancher* : cinq blocs 4×4 (quatre-vingts indices, un quart du plateau) résolvent bien chaque instance, mais ils ont épinglé tant de plateau qu'ils l'ont à moitié résolu à la main. Retirez le plancher et les dispositions groupées en deçà de cet extrême ne gagnent que deux chiffres, portées par les coutures gratuites. La vraie histoire du nombre n'est donc ni « plus d'indices aident » ni « plus d'indices nuisent », mais : il faut *beaucoup* d'indices corrects, épars ou groupés, pour faire bouger un backtracker chronologique, et tant que ce niveau n'est pas atteint, les épinglages supplémentaires ont autant de chances de faire trébucher la recherche que de l'accélérer. La [page de méthode](/fr/research/lab/experiments/raphael-anjou/hint-study/method/) développe l'arithmétique du plancher en entier. ## Épars contre contigu : nous obtenons l'inverse La [rédaction communautaire sur la géométrie des indices](/fr/research/why/hint-geometry/) formule une version plus tranchante de l'affirmation sur le placement : dix-huit indices *épars* sur un treillis résolvent en minutes un puzzle 16×16 de type E2, tandis que dix-huit empilés en lignes du haut *contiguës* n'aident guère, et qu'il faut quatre-vingts indices contigus ou plus pour égaler les dix-huit épars. Ce résultat a été mesuré sur un puzzle précis avec un moteur précis. Nous avons posé ses deux dispositions exactes, le treillis épars des lignes {1,3,5} et le bloc de dix-huit cases en haut, sur nos propres plateaux générés et nos propres solveurs pour voir si la direction tient. > **[Interactive: HintGeoComparison]** Rendered on the canonical page (link above); not shown in this markdown export. Elle ne tient pas. Sur nos plateaux, les dix-huit **contigus** scorent *plus haut* que les dix-huit épars pour sept des huit ordres de remplissage, et de loin : un balayage ligne par ligne atteint une médiane de 377 avec le bloc contigu et seulement 138 avec le treillis épars. Cela ressemble à une contradiction frontale, et il vaut la peine d'être précis sur pourquoi ce n'en est pas tout à fait une. Les deux études mesurent des choses différentes. Le résultat communautaire porte sur le *temps jusqu'à une solution complète* : les indices épars atteignent la fin de partie profonde où un backtracker passe presque tout son temps, ils élaguent donc la partie coûteuse, tandis qu'un bloc contigu en haut n'élague que l'ouverture bon marché. Notre nombre est un *score d'arêtes appariées à budget court*, et à huit secondes aucun de ces backtrackers stricts n'atteint la fin de partie. Ce qu'un bloc contigu ancré en haut achète, immédiatement, c'est une grande région correcte contre laquelle le balayage ligne par ligne peut construire, le score grimpe donc vite même si la partie dure du plateau reste intacte. Les indices épars, au contraire, fragmentent le remplissage précoce exactement comme le faisait la forme à cinq indices. Les deux résultats sont donc cohérents dès qu'on sépare « résout tout le plateau à terme » de « score bien dans les huit premières secondes » : le placement épars aide le premier et nuit au second. La section suivante rend cette séparation visible. ## Le résoudre : là où l'épars finit par gagner À 16×16 rien ne se résout en huit secondes, le score est donc toujours un instantané d'une recherche encore dans son ouverture. Pour voir l'effet de *fin de partie* rapporté par la communauté, il faut un plateau qui se résout entièrement. Un 8×8 construit selon la même recette de couleurs le fait, en bien moins d'une seconde, et sur lui nous pouvons mesurer la quantité qui compte réellement : le nombre de nœuds de recherche qu'un backtracker ligne par ligne demande pour atteindre une solution complète. Moins de nœuds signifie que les indices ont fait un vrai travail d'élagage. Ci-dessous, un treillis épars et un bloc contigu apparié, à nombres d'indices croissants. > **[Interactive: SolveSpeedChart]** Rendered on the canonical page (link above); not shown in this markdown export. C'est toute l'histoire en un graphique, et elle s'aligne enfin avec l'affirmation communautaire. À quatre indices, le treillis épars est *pire* qu'inutile, ne résolvant que deux plateaux sur trente, le même effet des indices clairsemés qui font trébucher la recherche que sur chaque autre axe, tandis que le bloc contigu apparié les résout presque tous. Mais franchissez un seuil vers seize indices et les lignes s'échangent brutalement : un treillis épars de seize indices se résout en environ quatre mille nœuds, tandis que le bloc contigu apparié broie encore près de deux millions, un rapport de cinq cents à nombre d'indices égal. Poussez plus loin et les deux dispositions deviennent faciles (à trente-six indices un quart du plateau est épinglé et l'une comme l'autre se résout en quelques centaines de nœuds), l'avantage de l'épars est donc une fenêtre, la plus large là où le nombre suffit à atteindre la recherche profonde sans que le plateau soit à moitié résolu à la main. Dans cette fenêtre, les indices épars atteignent la part de la recherche avec laquelle un backtracker se débat réellement et la court-circuitent, exactement comme Joe et Peter McGavin l'ont décrit ; un bloc contigu n'élague jamais que l'ouverture facile. La comparaison de scores à 16×16 n'a semblé les contredire que parce qu'à budget court la recherche ne vit jamais assez longtemps pour atteindre la région où le placement épars paie. ## Ce que cela dit et ne dit pas C'est un résultat sur les **backtrackers stricts, chronologiques, en profondeur d'abord**, sur des plateaux 16×16 générés selon la recette de couleurs d'Eternity II, à budget court (huit secondes). Chacun de ces mots de cadrage mérite sa place. *Chronologique* : le résultat porte spécifiquement sur les solveurs qui remplissent les cases dans un ordre fixe et doivent satisfaire une pièce épinglée en l'atteignant, un solveur à faisceau, qui ne le fait pas, atteint les 450 sur les mêmes plateaux. *Généré* : les plateaux partagent la recette de couleurs d'E2 et la *forme* de ses cinq indices, mais ils ne sont pas le puzzle officiel, et l'étude n'y transfère aucun nombre. *Budget court* : aucun de ces backtrackers stricts ne résout en huit secondes, ceci mesure donc jusqu'où chacun parvient, pas une course vers 480 ; la survie de l'effet « les indices nuisent » à des budgets bien plus longs n'est pas testée ici. Dans ce cadre, la leçon est solide et, pensons-nous, contre-intuitive : pour un backtracker chronologique, cinq pièces correctes placées dans la géométrie même des indices du puzzle ne sont pas un cadeau mais une contrainte, et peuvent coûter bien plus qu'elles ne donnent. Ce qui décide des dégâts, ce ne sont pas les indices mais l'ordre de remplissage qui doit vivre avec eux, et l'ordre paie un indice comme il paie tout le reste, dans la taille de la frontière qu'il garde ouverte. C'est une lecture de plus de [pourquoi le puzzle résiste](/fr/research/why/hint-geometry/) : même une information correcte n'aide qu'un solveur construit pour la recevoir. ## À lire aussi - [L'étude sur les indices](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/) — Donner à un backtracker cinq pièces correctes gratuitement, dans la géométrie même des indices du puzzle. Il s'avère que cela n'aide pas, et selon l'ordre de remplissage cela peut nuire gravement, car une pièce épinglée est une contrainte dure qu'un ordre de remplissage fixe doit satisfaire à son arrivée. Une famille d'ordres de remplissage, exécutée sur les mêmes plateaux indicés, un seul cœur, mesurée contre l'absence totale d'indices. - [Comment l'étude sur les indices est construite](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/method/) — L'appareillage derrière l'étude sur les indices : un générateur paramétrique de plateaux fidèle à la recette de couleurs d'Eternity II à toutes les tailles, la famille de backtrackers à ordre de remplissage, l'unique scoreur canonique, et le morceau d'arithmétique qui garde l'axe du nombre significatif, le plancher des coutures épinglées. - [L'emplacement des indices l'emporte sur leur nombre](https://eternity2.dev/fr/research/why/hint-geometry/) — Sur un casse-tête 16×16 construit à l'image d'Eternity II, dix-huit indices dispersés sur le plateau le résolvent en quelques minutes, là où les entasser en rangées contiguës en réclame une centaine rien que pour ramener la recherche à des dizaines de milliards de placements. C'est la position, non le nombre, qui fait levier, et elle pointe droit vers la fin de partie. - [L'étude DFS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. --- # Comment l'étude sur les indices est construite > L'appareillage derrière l'étude sur les indices : un générateur paramétrique de plateaux fidèle à la recette de couleurs d'Eternity II à toutes les tailles, la famille de backtrackers à ordre de remplissage, l'unique scoreur canonique, et le morceau d'arithmétique qui garde l'axe du nombre significatif, le plancher des coutures épinglées. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/method/ - Mise à jour: 2026-07-21 - Sujets: backtracking, structure, search-space - Source: Le générateur paramétrique et le moteur à ordres de remplissage (le répertoire d'appui de cette étude) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/hint-study --- Cette page est l'appareillage derrière [l'étude sur les indices](/fr/research/lab/experiments/raphael-anjou/hint-study/) : comment les plateaux sont générés, pourquoi ils restent fidèles à Eternity II à toutes les tailles, la famille d'ordres de remplissage, et la pièce qui compte le plus pour lire correctement les résultats, l'arithmétique du *plancher des coutures épinglées*, qui est ce qui sépare un effet réel d'un artefact de mesure sur l'axe du nombre. ## Les plateaux : un générateur fidèle, paramétrique en taille Chaque instance est générée de zéro, ensemencée et déterministe : le même triplet `(size, colours, seed)` produit le même plateau sur n'importe quelle machine. Un plateau généré est un plateau *résolu*, la pièce $i$ occupe la case $i$ à la rotation zéro, dont les identifiants de pièces sont ensuite réétiquetés par une permutation ensemencée, de sorte qu'un indice pour la case `pos` épingle la vraie pièce (réétiquetée), et qu'un solveur ne peut pas simplement parcourir le placement identité. La recette de couleurs reflète exactement la structure du puzzle officiel. Sur un plateau $n\times n$ il y a $$ E(n) \;=\; 2\,n\,(n-1) $$ coutures intérieures (les arêtes appariées ; $E(16) = 480$). Elles se répartissent en une **bande de cadre**, les coutures joignant deux pièces de bord le long du pourtour, et l'intérieur profond. Les cinq *couleurs de bord* sont confinées à la bande de cadre et n'apparaissent jamais à l'intérieur ; les *couleurs intérieures* apparaissent à la fois dans l'intérieur profond et sur la face tournée vers l'intérieur des pièces de bord. C'est le fait structurel définissant un vrai plateau Eternity II, et le générateur le reproduit et est testé contre lui. ### Pourquoi le recensement est automatiquement équilibré (une affirmation à énoncer avec soin) Il est tentant, et les premières rédactions l'ont fait, de présenter le recensement de couleurs *pair* d'Eternity II comme un cadeau spécialement réglé : chaque couleur apparaît un nombre pair de fois, si bien que les appariements $\sum_c N_c / 2$ d'une solution parfaite tombent avec un jeu nul. La parité paire est réelle, mais elle n'est **pas** un exploit de réglage. Elle est forcée. Une couleur peinte sur $k$ coutures intérieures apparaît sur exactement $2k$ faces de pièces, une de chaque côté de chaque couture. Donc pour toute couleur $c$, $$ N_c \;=\; 2\,k_c \quad\text{est pair, pour n'importe quel coloriage de coutures.} $$ La parité à jeu nul est donc automatique pour *tout* plateau construit en coloriant des coutures ; elle ne dit rien de spécial sur Eternity II. Les propriétés qui portent véritablement la charge, et que le générateur doit réussir, sont au nombre de trois : les couleurs de bord confinées à la bande de cadre, les effectifs par couleur maintenus **équilibrés** (afin qu'aucune couleur ne soit assez rare pour sur-contraindre), et chaque pièce **distincte à rotation près** (afin qu'un indice épinglé nomme une pièce unique). La rédaction de l'étude est précise sur ce point là où le cadrage antérieur ne l'était pas. ### Mettre la recette à l'échelle sans changer la difficulté Le générateur et le solveur sont tous deux paramétriques en taille, le plateau peut être $8\times8$ ou $12\times12$ aussi aisément que $16\times16$, ce qui ouvre une suite naturelle : l'effet du placement se *renforce*-t-il quand le plateau grandit ? Répondre proprement exige une recette de couleurs qui ne change pas la *difficulté* du puzzle quand la taille change. Garder simplement les *effectifs* de couleurs fixes en faisant croître $n$ rendrait le puzzle structurellement *plus facile* aux grands $n$ : avec plus de coutures et la même palette, chaque couleur se répète plus souvent, la case moyenne accepte donc plus de voisins et la contrainte se relâche. Cela confondrait taille et difficulté. La recette maintient au contraire la **multiplicité par couleur** à peu près constante. En écrivant $F(n)$ pour le nombre de coutures de la bande de cadre et $E(n) - F(n)$ pour l'intérieur, le nombre de couleurs de bord et intérieures est choisi comme $$ b(n) \;=\; \operatorname{round}\!\Big(\tfrac{F(n)}{12}\Big), \qquad i(n) \;=\; \operatorname{round}\!\Big(\tfrac{E(n) - F(n)}{24}\Big), $$ en visant les multiplicités qu'Eternity II utilise lui-même à $n=16$ (bord $\approx 12$, intérieur $\approx 24$). À $n=16$ cela restitue exactement la recette officielle, cinq couleurs de bord et dix-sept intérieures. Réussir cela sur les petits plateaux a demandé une correction du générateur. La palette d'Eternity II est *à dominante intérieure*, cinq couleurs de bord contre dix-sept intérieures, mais le générateur par défaut plafonne le nombre de couleurs de bord à cinq et prend tout le reste comme intérieur, ce qui sur un petit plateau inverse le rapport : à $8\times8$ la recette veut huit couleurs, et le plafond les répartirait en cinq de bord pour une intérieure, une mer intérieure quasi uniforme qui ne se comporte en rien comme E2. Le générateur accepte désormais un nombre explicite de couleurs de bord, et la recette maintient l'intérieur à environ trois fois le bord à chaque taille ($8\times8 \to$ deux de bord, six intérieures ; $16\times16 \to$ cinq et dix-sept, inchangé). Avec cela, les petits plateaux sont fidèles *et* pleinement solubles, ce sur quoi repose la comparaison de vitesse de résolution de la [page des résultats](/fr/research/lab/experiments/raphael-anjou/hint-study/findings/). Les résultats principaux sur les ordres et le nombre sont tous à $16\times16$ ; le plateau $8\times8$ n'est utilisé que là où une résolution complète est nécessaire. ## Les géométries d'indices Chaque disposition est une fonction pure de la taille du plateau, si bien que la même géométrie peut être dessinée, mesurée et mise à l'échelle de façon cohérente. La galerie ci-dessous les rend toutes à partir de l'unique primitive de plateau partagée. > **[Interactive: HintLayoutGallery]** Rendered on the canonical page (link above); not shown in this markdown export. ## Le plancher des coutures épinglées : garder l'axe du nombre significatif Voici la subtilité qui a remodelé l'étude. Demandez « plus d'indices aident-ils ? » et le geste évident est de comparer les scores finaux à différents nombres d'indices. Mais un indice fait deux choses différentes à la fois, et le score les confond : 1. il **retire une pièce** de la recherche (la partie utile, il élague l'arbre) ; 2. il **peut compléter une couture gratuitement**, si une case voisine est aussi épinglée. Le second effet est un pur cadeau comptable. Définissons le **plancher des coutures épinglées** d'une disposition comme le nombre de coutures intérieures dont les *deux* extrémités sont épinglées : $$ \text{plancher} \;=\; \#\{\, \text{coutures intérieures } (u,v) : u \text{ et } v \text{ toutes deux indicées} \,\}. $$ Parce que les épinglages sont des pièces de la vraie solution, chacune de ces coutures est garantie correcte avant même que le solveur ne tourne. Un bloc groupé plein $k\times k$ en apporte $2k(k-1)$ ; cinq blocs $k{=}4$ engrangent $5 \cdot 24 = 120$ coutures correctes, un **quart des 480**, gratuitement. Un treillis épars, dont les indices ne se touchent jamais, a un plancher de **zéro**. Une comparaison au score brut **flatte** donc systématiquement les dispositions groupées : elles partent avec plus de cent points d'avance de pure comptabilité, indépendamment de la question de savoir si le plateau est devenu plus facile à *terminer*. C'est la même famille d'erreur que compter les coutures du pourtour dans un plateau partiel, un plancher qui gonfle le nombre sans refléter de progrès. Le commutateur de la galerie ci-dessus dessine ces coutures engrangées pour rendre le score gratuit visible. L'étude ne classe donc pas les dispositions au score brut sur l'axe du nombre. Elle utilise deux métriques immunisées contre le plancher : - le **taux de résolution**, la fraction des instances qu'un ordre complète réellement jusqu'à 480 ; - la **profondeur atteinte**, jusqu'où la recherche est allée au-delà des cases épinglées, sur 256. Toutes deux mesurent si la recherche a fait *un progrès que les épinglages ne lui ont pas offert*. Sur l'axe des ordres, où chaque disposition comparée partage les *mêmes* indices et donc le même plancher, le score brut est directement comparable et est utilisé. ## Mesurer contre l'absence d'indices, apparié par instance La question « que valent les indices ? » n'a de réponse que relativement au fait de *ne pas* les avoir. L'axe des ordres est donc exécuté deux fois sur chaque plateau : une fois avec les cinq indices en forme d'indices officiels, une fois sans aucun (`baseline_00`), et l'effet rapporté est la **différence appariée**, le score avec indices moins le score sans indices sur le *même* plateau généré. Apparier par instance retire la variance de difficulté d'un plateau à l'autre, qui sur ces plateaux bimodaux est assez grande pour noyer l'effet si les deux conditions étaient comparées sur des graines différentes. Une différence appariée négative signifie que les indices ont rendu cet ordre de remplissage pire qu'il ne l'était avec un intérieur vierge, ce que rapportent les résultats. Toutes les comparaisons utilisent l'ensemble commun de graines menées à terme, de sorte que chaque ordre et chaque disposition sont agrégés sur les instances identiques. ## Les ordres de remplissage, et pourquoi la frontière est le levier Le moteur est le [backtracker DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/) frère de cette étude, exécuté en strict (pas de ruptures, pas de propagation) afin que **l'ordre de remplissage soit la seule chose qui change**. Les ordres testés sont ligne par ligne, son miroir de bas en haut, la spirale entrante, la spirale sortante, bord d'abord, le peigne de Verhaard, un contrôle lignes-des-indices d'abord, et l'ordre propre à l'étude qui cherche les indices, `connect-hints-first`. Pourquoi l'ordre compte-t-il autant ? Le coût d'un backtracker est gouverné par la **frontière ouverte** : l'ensemble des cases déjà remplies encore adjacentes à une case vide. Quand la case suivante est placée contre une frontière de taille $f$, le nombre de plateaux partiels que la recherche peut avoir à considérer croît multiplicativement en $f$, le branchement est exponentiel en la frontière, pas en le plateau. Un unique balayage compact maintient $f$ à environ une ligne ($\approx n$) ; un ordre qui ouvre des taches autour de $k$ indices éparpillés mène $k$ frontières de front, et $$ \text{travail} \;\sim\; \prod_{j} b^{\,f_j} \;=\; b^{\sum_j f_j}, $$ de sorte que fragmenter le remplissage en régions déconnectées multiplie le coût, il ne l'additionne pas. C'est exactement pourquoi `connect-hints-first`, l'ordre qui *cherche* les indices, est le pire performeur : atteindre les indices tôt vaut bien moins que garder la frontière petite, et relier des ancres éparpillées fait l'exact contraire de la garder petite. ## Comment lire les chiffres Chaque plateau est re-scoré par un unique scoreur canonique d'arêtes appariées qui ne compte jamais une couture face au bord (grise). Le maximum est $E(n)$ ($480$ à $16\times16$). Chacune des quinze graines est une instance générée distincte, la dispersion entre graines est donc une véritable variance d'instance. Le débit, là où il est rapporté, est en nœuds de recherche par seconde et n'est jamais comparé entre ordres différents, car un nœud sous un ordre n'est pas la même unité de travail que sous un autre. Tout l'appareillage, générateur, dispositions, résultats par exécution et script de grille, réside dans le [répertoire d'appui](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/hint-study) de l'étude, et `just experiments hint-study` relance le tout. ## À lire aussi - [L'étude sur les indices](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/) — Donner à un backtracker cinq pièces correctes gratuitement, dans la géométrie même des indices du puzzle. Il s'avère que cela n'aide pas, et selon l'ordre de remplissage cela peut nuire gravement, car une pièce épinglée est une contrainte dure qu'un ordre de remplissage fixe doit satisfaire à son arrivée. Une famille d'ordres de remplissage, exécutée sur les mêmes plateaux indicés, un seul cœur, mesurée contre l'absence totale d'indices. - [Ce que l'étude sur les indices a montré](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/findings/) — Les résultats, développés : sur ces plateaux les cinq indices en forme d'indices officiels n'aident jamais un backtracker, ils vont d'un coût modéré à une catastrophe, et l'ordre de remplissage décide de l'ampleur des dégâts ; les scores sont bimodaux, pas un gradient lisse ; et la question du nombre d'indices est confondue par un plancher gratuit de coutures épinglées. - [L'emplacement des indices l'emporte sur leur nombre](https://eternity2.dev/fr/research/why/hint-geometry/) — Sur un casse-tête 16×16 construit à l'image d'Eternity II, dix-huit indices dispersés sur le plateau le résolvent en quelques minutes, là où les entasser en rangées contiguës en réclame une centaine rien que pour ramener la recherche à des dizaines de milliards de placements. C'est la position, non le nombre, qui fait levier, et elle pointe droit vers la fin de partie. --- # Le backtracker JIT : du Rust portable à égalité avec du C optimisé sur les plateaux difficiles > Un backtracker Rust en profondeur d'abord, sûr et portable, spécialisé à l'exécution en émettant puis compilant du Rust propre à chaque puzzle, porté de 43 à 123 millions de nœuds de recherche par seconde sur un cœur. Mesuré équitablement face au C de Peter McGavin sur la même machine : à égalité sur les plateaux difficiles et profonds comme le vrai Eternity II, et à environ 44 % de sa vitesse sur les faciles. Chaque échelon parcourt l'arbre identique ; tout le gain vient du code, pas de l'algorithme. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/jit-backtracker/ - Mise à jour: 2026-07-20 - Sujets: speed, backtracking - Reproduire: `cargo run --release -p dfs-codegen --bin run_dfs_codegen_jit -- --puzzle P.json --chain2 --opt native` - Source: Peter McGavin's genbody71.zip — the C reference this engine chases (groups.io msg 11749) — https://groups.io/g/eternity2/message/11749 - Source: rust-lang/rust#80630 — LLVM cannot lower loop+match to a computed goto (why the function-chain design exists) — https://github.com/rust-lang/rust/issues/80630 - Source: The eternity2 repository on GitHub — https://github.com/raphael-anjou/eternity2 --- > **Ce qu'est cette expérience, et ce qu'elle n'est pas** > > C'est une expérience de **vitesse**, pas de résolution. Elle pose une seule question : un backtracker Rust *sûr et portable* peut-il atteindre le débit du moteur le plus rapide de la communauté - le [C optimisé à la main de Peter McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) - sans quitter Rust ni descendre à l'assembleur ? La réponse dépend du plateau : sur les plateaux **difficiles et profonds comme le vrai Eternity II, il égale son C** ; sur les plateaux faciles et peu ramifiés, son C est environ **2,3× plus rapide**. Il ne dit rien des *scores* : parcourir l'arbre vite et trouver un plateau à haut score sont [deux axes entièrement distincts](/fr/research/lab/experiments/raphael-anjou/going-fast/). Le meilleur que ce moteur atteint sur le vrai puzzle est dans les hauts 300 sur 480, exactement là où un backtracker strict doit s'arrêter - les plateaux record viennent des métaheuristiques, pas d'une marche plus rapide. Tout moteur Eternity II rapide est, en dessous, le même backtracker en profondeur d'abord : remplir les cases dans un ordre fixe, essayer chaque pièce qui convient, descendre, remonter à la première impasse. La [page de McGavin](/fr/research/lab/experiments/peter-mcgavin/backtracker/) raconte l'histoire du débit du moteur C qui détient depuis des années la couronne de vitesse mono-cœur de la communauté. Cette page en est l'autre versant : jusqu'où du *Rust portable* peut s'en approcher, et où tombe la ligne rigoureuse. Le résultat dépend du plateau, et c'est là qu'est l'intérêt. Mesuré sur mon Apple M1, sur un cœur, les deux moteurs compilés sans affichage avec génération de code native et exécutés dos à dos : | Plateau | C de McGavin (sans affichage) | Ce moteur | Résultat | | --- | --- | --- | --- | | Facile (71.puz de Joe, 18 indices) | ~287 M/s | ~122 M/s | McGavin **~2,3×** | | **Difficile (16×16 profond, comme le vrai E2)** | **~102–105 M/s** | **~104–111 M/s** | **~égalité** | Sur les plateaux qui ressemblent vraiment à Eternity II - profonds, densément contraints, où la recherche passe son temps à revenir en arrière - un moteur Rust sûr et portable **égale du C optimisé à la main**. Sur les plateaux faciles et peu ramifiés, où il n'y a presque rien à faire par nœud, le C en ligne droite de McGavin est plus de deux fois plus rapide. Les deux nombres sont réels ; l'ingénierie ci-dessous est ce qui a hissé Rust jusqu'à l'égalité sur les plateaux difficiles. Tout ce qui suit vient de la **génération de code et de la disposition des données**, pas d'une recherche plus fine : chaque échelon parcourt l'arbre *identique* et, sur un plateau soluble de test, s'arrête au *nombre de nœuds identique*. Cet invariant est la colonne vertébrale de toute l'expérience, alors autant l'énoncer d'abord. > **Mesurez la référence à pleine vitesse, ou vous vous tromperez vous-même** > > Une version antérieure de ce travail annonçait que nous *battions* McGavin nettement. C'était faux, et la raison est instructive. Le moteur de McGavin est livré avec un affichage terminal en direct (`#define INTERACTIVE`) : un état qu'il redessine sans cesse. Cet affichage lui coûte environ **2,7× de son débit** - sa vitesse sans affichage est de ~287 M sur le plateau facile, mais avec l'affichage il affiche ~106 M. La première comparaison opposait notre moteur sans affichage à son binaire *bridé* et produisait une victoire fantôme. Reconstruit sans affichage (`-mcpu=native`), le vrai tableau est celui ci-dessus : il gagne le plateau facile largement, et nous égalisons sur les difficiles. La leçon est générale - construisez toujours la référence telle qu'elle tourne à pleine vitesse avant de faire confiance à un ratio. ## La règle du jeu : le même arbre, à chaque échelon Un backtracker en profondeur d'abord est déterministe. Étant donné un plateau et un ordre de remplissage fixe, il visite exactement une seule suite de nœuds, sur n'importe quelle machine, dans n'importe quel langage. Il existe donc un test implacable pour savoir si une « optimisation » n'est bien qu'une accélération et non une modification silencieuse de la recherche : **le nombre de nœuds ne doit pas bouger.** Tout au long de ce travail, l'oracle a été un 16×16 soluble à 60 indices. Chaque version du moteur le résout à 480 et annonce **251 815 nœuds** - le même nombre, au chiffre près, de la référence la plus lente au build fusionné le plus rapide. Tout changement qui déplaçait ce nombre était un bug déguisé et a été annulé. C'est cette seule discipline qui permet de lire l'échelle de vitesse ci-dessous comme une comparaison à conditions égales, et non comme une collection de programmes au comportement différent. > **Ici la correction est un invariant de base, pas une étape** > > Le moteur vérifie les quatre arêtes de chaque placement contre chaque voisin déjà fixé (pièce posée ou bordure du cadre), et il interdit à une arête de bordure/grise de faire face à l'intérieur. Ce ne sont pas des optimisations « ajoutées plus tard » - c'est la définition d'un placement Eternity II légal, présente dans chaque version de cette page. L'échelle ne fait varier *que* la vitesse d'une recherche fixe et correcte. ## L'idée centrale : générer le programme, ne pas interpréter le puzzle Un backtracker générique paie, à chaque nœud, des questions dont la réponse ne change jamais pendant une exécution : *sur quelle case suis-je ? où sont ses voisins ? quel vivier de candidats lire ?* Une boucle pilotée par tables les cherche dans des tableaux, à chaque nœud, indéfiniment. Le C de McGavin y répond **une fois, à la compilation**, en générant un programme spécialisé pour un puzzle : `genbody -DG` écrit un second fichier C avec un bloc en ligne droite par case, les adresses des voisins gravées en constantes, et des chaînes de `goto` reliant les blocs. Cette spécialisation est la source de sa vitesse - même algorithme, exécuté au ras du métal. Ce moteur fait la même chose en Rust, à l'exécution : 1. `emit_program(&instance)` écrit un **programme Rust autonome et spécialisé pour le puzzle** - pièces, viviers de candidats, indices et ordre de remplissage tous gravés en données `const`, sans crate externe. 2. L'enveloppe le compile avec `rustc -O` (environ 0,15 s pour le build simple, ~1,7 s pour le fusionné). 3. Le binaire généré exécute la recherche et imprime son résultat. C'est le flux `genbody -DG → compile → exécute` de McGavin, en Rust, appelé comme une bibliothèque. Rien d'exotique - juste sortir les faits fixes du puzzle hors de la boucle chaude pour les confier au compilateur. Tout ce qui suit consiste à extraire des facteurs constants du code généré, et chaque extraction est un petit changement autonome qu'un diff illustre au mieux. ## L'échelle, un changement à la fois Les diffs ci-dessous sont **simplifiés pour la lecture** : le vrai moteur émet sa boucle interne en Rust généré (des constantes comme la position d'une case et ses voisins sont gravées par case, et la source fait quelques centaines de lignes par puzzle). Chaque diff montre l'idée du changement, pas le texte généré littéral - lancez le moteur avec `--emit-src out.rs` pour voir le vrai code d'un plateau donné. ### 1 · Empaqueter chaque candidat dans un mot La première boucle générée chassait encore un pointeur : lire un index `u32`, le suivre dans un tableau `oriented[]` pour le `(id, rotation, arêtes)` de la pièce, *puis* tester si la pièce était déjà utilisée. Trois chargements dépendants pour considérer un candidat. ```diff - let idx = pool[i]; // load an index … - let (pid, rot, edges) = oriented[idx as usize]; // … chase it into a second array … - if !used[pid] { /* consider */ } // … then test usage + let cand = pool[i]; // one contiguous load: pid<<48 | rot<<40 | edges<<8 + let pid = (cand >> 48) as usize; + if free[pid] != 0 { let edges = (cand >> 8) as u32; /* consider */ } ``` Chaque candidat devient un unique `u64` empaqueté, stocké directement dans son vivier `(up, left)`. La boucle chaude fait **un** chargement, extrait l'id de la pièce, et teste l'usage *avant* de dépaqueter les arêtes - le motif « vérifier `tileFree` d'abord » de McGavin. **+12 %**, et cela met en place la représentation empaquetée dont dépend tout le reste du travail. ### 2 · Stocker les cases du plateau en un `u32`, pas quatre octets Le plateau stockait les quatre arêtes de chaque case en `[u8; 4]`. Lire l'arête d'un voisin pour la comparer demandait quatre chargements d'octets séparés. McGavin garde les arêtes de chaque tuile posée en **un seul `u32`** et les pousse vers les voisins par décalages. ```diff - let cell: [[u8; 4]; N]; // four byte loads to read one neighbour - let up_edge = cell[up_pos][2]; // …and index arithmetic each time + let cell: [u32; N]; // one u32 per cell, URDL packed, empty = 0xFFFF_FFFF + let up_edge = (cell[up_pos] >> 8) as u8; // one load + one shift ``` Ce fut le plus grand levier de disposition des données : **34 → 57 M nœuds/s, +67 %**. Nombre de nœuds inchangé. Bien représenter la structure de données la plus chaude (le plateau) a compté davantage que toute micro-optimisation venue ensuite. ### 3 · Émettre une fonction par case - le pivot Voici le geste qui a rendu « égaler McGavin » plausible. La taxe restante était la boucle pilotée par tables elle-même : `free_order[level]`, `cursor[level]`, `score_at[level]` - des chargements de tableaux indexés à *chaque nœud*, pour des valeurs que McGavin a en constantes de compilation. La façon évidente de les graver - un unique gros `loop { match level { …256 branches… } }` - ne marche pas : `rustc` met plus d'une minute à compiler une seule fonction énorme, et [LLVM ne sait pas abaisser un `loop`/`match` en goto calculé](https://github.com/rust-lang/rust/issues/80630) de toute façon, donc il ne reproduirait même pas la structure de `goto` de McGavin. La façon qui *marche* est d'émettre **une petite fonction `#[inline(never)]` par case** : ```diff - // one generic loop, indexing arrays by depth on every node - loop { - let pos = free_order[level]; - let (up_pos, left_pos) = neigh[level]; - // …scan, place, advance level, or back out… - } + // one function per cell; its position and neighbours are baked constants + fn cell_37(st: &mut St, left_arg: u8) -> bool { + const POS: usize = 138; const UP: usize = 122; // this cell's facts, as constants + for cand in POOL_UL[/* up*COLORS+left */] { // its exact candidate pool + // place … + if cell_38(st, right_edge) { return true; } // advance = call the next cell + // unplace … + } + false // exhausted = plain return (backtrack) + } ``` Avancer, c'est appeler la fonction de la case suivante ; revenir en arrière, c'est un simple `return`. Environ 256 *petites* fonctions se compilent en deux secondes (une chaîne de 200 fonctions compile en ~1 s ; la fonction géante unique prenait >60 s). C'est le code en ligne droite par case de McGavin, exprimé en une chaîne de fonctions minuscules que Rust acceptera réellement de compiler. **58 → 92 M nœuds/s, +56 %** - le plus grand levier de l'échelle. Nombre de nœuds inchangé. ### 4 · Cesser de recalculer ce qu'on a déjà chargé Deux changements plus modestes, même thème : ne jamais relire en mémoire ce qu'on a déjà dans un registre. Le **voisin de gauche** d'une case est, 94 % du temps (240 des 256 cases, toutes sauf les débuts de ligne), exactement la pièce que la case *appelante* vient de poser. L'appelant passe donc sa propre arête droite en argument, et la case dérive sa contrainte de gauche sans aucune lecture du plateau : ```diff - let left_edge = (cell[LEFT] >> 24) as u8; // re-read the neighbour we just placed + fn cell_38(st: &mut St, left_arg: u8) -> bool { // caller handed us its right edge + let left = left_arg; // …no board read ``` Et le **gain de correspondance** - le nombre d'arêtes nouvellement appariées qu'ajoute un placement - relisait ses quatre voisins. Or les arêtes du haut et de gauche étaient *déjà chargées* pour choisir le vivier de candidats, et dans l'ordre par ligne ces voisins sont toujours posés (ou une arête de cadre, sans gain). Le gain haut/gauche devient donc deux additions `bool → u32` sans branche sur des valeurs déjà en main ; seuls des voisins bas/droite réellement fixés coûtent une lecture : ```diff - let gain = matched(up) + matched(left) + matched(down) + matched(right); // 4 reads + let gain = u32::from(e_up == up) + u32::from(e_left == left) // 0 reads: cached + + need_down_read + need_right_read; // only if pinned ``` Ensemble : **92 → 106 M nœuds/s** - sur le plateau difficile, cela met à niveau avec le C sans affichage de McGavin (~102–105 M là-bas). Nombre de nœuds inchangé. ### 5 · Un tableau d'octets pour l'ensemble des pièces utilisées Le moteur suivait les pièces posées avec un masque de bits `u64` : décalage, masque, et, test. McGavin utilise un `unsigned char tileFree[256]` plat ; son test est un chargement d'octet et une comparaison à zéro. ```diff - if used[pid >> 6] & (1u64 << (pid & 63)) == 0 { /* free */ } // shift, mask, and, test + if free_pc[pid] != 0 { /* free */ } // one byte load + compare ``` **106 → 108 M.** Nombre de nœuds inchangé. ### 6 · Fusionner des cases pour amortir l'appel - le coup gagnant Le dernier obstacle entre la chaîne de fonctions et le `goto` de McGavin était l'appel lui-même : un `goto` vers la case précédente est un saut nu ; un `return` de fonction restaure d'abord les registres sauvegardés par l'appelé. Alors **fusionnons plusieurs cases en une fonction** - imbriquons le balayage de la deuxième case *dans* la boucle de placement de la première, la troisième dans la deuxième, et ainsi de suite, pour n'avoir qu'un `call` par *groupe* de cases posées au lieu d'un par case : ```diff - fn cell_37(st){ for c in pool { place; if cell_38(st, r) {return true} unplace } } - fn cell_38(st){ for c in pool { place; if cell_39(st, r) {return true} unplace } } + fn cells_37_38_39(st){ // three cells, one function, one call in/out + for c37 in pool37 { place37; + for c38 in pool38 { place38; + for c39 in pool39 { place39; + if next_group(st, r) {return true} + unplace39 } + unplace38 } + unplace37 } ``` La fusion échange moins d'appels contre plus de pression sur les registres, il y a donc un optimum, et il est peu marqué. En balayant la taille du groupe sur `bench-hard`, trois essais chacun, dos à dos : | groupe | 1 | 2 | 4 | 6 | 8 | | --- | --- | --- | --- | --- | --- | | nœuds/s | ~102 M | ~107 M | **~110 M** | ~108 M | ~108 M | La fusion bat nettement l'absence de fusion (groupe 1), mais au-delà du groupe 2 les écarts sont dans le bruit d'une exécution à l'autre : le pic erre entre les groupes 4 et 6 selon le plateau et l'humeur de l'allocateur de registres de LLVM, et ne dépasse jamais quelques pour cent. Le défaut de `--chain2` est le groupe 6 ; le groupe 4 a devancé sur ce plateau précis. Ce qui compte, c'est le saut depuis le groupe 1, pas le vainqueur exact. Le nombre de nœuds est préservé à travers l'imbrication dans tous les cas. ## L'échelle d'un coup d'œil Trois points d'ancrage sont revérifiés aujourd'hui sur les plateaux `bench-*.json` commités ; les étapes entre eux sont les écarts relevés en cours de développement (chacun un commit autonome), qui dérivent de quelques pour cent selon l'état de la machine - lisez donc les lignes du milieu comme la *forme* de la montée, pas des constantes de laboratoire. | Échelon | Moteur | Changement | statut | | --- | --- | --- | --- | | **naive-clean** | récursif | DFS Rust portable simple, la référence rigoureuse | **~44 M, vérifié** | | **JIT piloté par tables** | codegen | programme généré, boucle interne par tables | **~61 M, vérifié** | | cases plateau en u32 | codegen | un chargement + décalage par voisin | +~65 % (journal) | | chaîne de fonctions | codegen | une fonction par case | +~55 % (journal) ★ | | haut/gauche en cache + octets | codegen | cesser de relire les voisins posés | +~15 % (journal) | | **fusion (groupe 4–6)** | codegen | **un appel pour plusieurs cases** | **~108–110 M difficile / ~122 M facile, vérifié** | | *C de McGavin (sans affichage)* | C | *même machine, pour référence* | *~102 M difficile / ~287 M facile* | Deux moteurs partagent ce tableau : `naive-clean` est un backtracker récursif à part (lançable avec `run_dfs --algo naive-clean`), et tout depuis « JIT piloté par tables » est le chemin codegen dont parle cette page (`run_dfs_codegen_jit`). Le résumé rigoureuse est un **gain de ~2,5× de la référence naive-clean au champion fusionné sur le plateau difficile** (~44 M → ~110 M) et **~2,8× sur le facile** (~44 M → ~122 M) - atterrissant, sur le difficile, à niveau avec le C sans affichage de McGavin. Trois méta-leçons en découlent, la part transférable : 1. **La représentation prime sur les micro-opérations.** Les deux plus grands gains isolés - cases u32 (+67 %) et chaîne de fonctions (+56 %) - portaient tous deux sur la *forme* des données et du code, pas sur le rognage d'instructions. Aucun réglage de branche n'en a approché. 2. **Réutiliser ce qu'on a déjà calculé.** Le gain en cache et la gauche-en-argument étaient de purs gains « cesse de le recharger ». 3. **La structure prime sur les cycles.** La fusion s'est attaquée à la *structure d'appel*, pas à un cycle isolé - et c'est ce qui a hissé Rust à niveau avec du C optimisé à la main sur les plateaux difficiles. ## Reproduisez-le Le moteur et deux plateaux de référence commités vivent dans le dépôt public sous `research/experiments/dfs-study/engine/crates/dfs-codegen` (`bench/bench-easy.json`, `bench/bench-hard.json`, et un `bench/README.md` avec la recette complète). Les trois points d'ancrage de l'échelle - la référence naive-clean, le plancher codegen et le champion fusionné - sont chacun lançables directement, pour que quiconque puisse les rejouer sur sa propre machine, dos à dos. Depuis `research/experiments/dfs-study/engine` : ```bash # naive-clean : la référence rigoureuse (backtracker récursif simple à part) ~44 M cargo run --release -p dfs-run --bin run_dfs -- \ --puzzle crates/dfs-codegen/bench/bench-hard.json --algo naive-clean --seed 1 --budget-s 10 # plancher JIT piloté par tables : le chemin codegen sans chaîne/fusion ~61 M cargo run --release -p dfs-codegen --bin run_dfs_codegen_jit -- \ --puzzle crates/dfs-codegen/bench/bench-hard.json --budget-s 15 --opt native # champion fusionné (groupe = 6) : le moteur dont parle cette page ~108–110 M difficile, ~122 M facile cargo run --release -p dfs-codegen --bin run_dfs_codegen_jit -- \ --puzzle crates/dfs-codegen/bench/bench-hard.json --budget-s 15 --chain2 --opt native # n'importe quelle largeur de fusion, pour balayer les groupes vous-même cargo run --release -p dfs-codegen --bin run_dfs_codegen_jit -- \ --puzzle crates/dfs-codegen/bench/bench-hard.json --budget-s 15 --group 4 --opt native ``` Pointez `--puzzle` sur `bench-easy.json` et chaque configuration imprime `score=480` au **même nombre de nœuds** (3 577 121 570) - l'égalité qui prouve que l'échelle est une échelle de vitesse et rien d'autre. Sur le `bench-hard.json` non terminant, elles impriment le même score partiel à des `nps` différents. (Donnez-lui un vrai budget : un budget très court mesure la mise en route du compilateur, pas le débit. Le plateau facile demande ≥30 s pour se résoudre.) Les trois micro-étapes intermédiaires du tableau ci-dessus - candidats empaquetés, gain en cache, ensemble utilisé en octets - ne sont pas des drapeaux séparés ; elles sont la suite de commits dans `bench/README.md`, reproductible avec `git checkout`. Pour reproduire équitablement la comparaison avec McGavin, construisez **son** moteur sans affichage - commentez `#define INTERACTIVE` près du haut de `genbody.c` pour que l'affichage en direct ne le bride pas - puis lisez le vrai débit : ```bash # McGavin, sans affichage + natif : émettre le C spécialisé, puis lier et exécuter gcc -o genbody genbody.c -lm -Ofast -mcpu=native -DG # émet body.c pour ce puzzle ./genbody PUZZLE.puz HINTS.hnt gcc -o solve genbody.c -lm -Ofast -mcpu=native # lie body.c, lance la recherche ./solve PUZZLE.puz HINTS.hnt # lisez la ligne « Rate: » (= placements / temps écoulé) sur un plateau difficile, ou # le résumé final « tiles/second » sur un plateau soluble — c'est sa vraie vitesse ``` Avec l'affichage laissé actif, le même binaire affiche environ un tiers de cela - c'est exactement le piège qui a produit le faux « nous le battons ». > **D'abord : comptons-nous seulement la même chose ?** > > Une comparaison de vitesse n'a aucun sens tant que les deux moteurs ne comptent pas les mêmes événements ; avant de faire confiance à un ratio, nous avons lu la source de McGavin. Son compteur (`ntp`, la fameuse astuce de débordement 16 bits) s'incrémente **une fois par pièce posée sur le plateau** - après que le candidat a passé la table de correspondance des couleurs et le contrôle d'usage, à l'instant où il est placé (`genbody.c`, le `ntp++` juste après `square[x][y].tile = t`). Notre `st.nodes` fait exactement la même chose : il s'incrémente après qu'un candidat a passé les contrôles d'arêtes et d'usage, au moment où la pièce est posée. Aucun ne compte les candidats qui échouent à ces contrôles ; les deux comptent les placements qui seront ensuite annulés. Donc les « tuiles posées par seconde » de McGavin et nos « nœuds de recherche par seconde » sont **la même mesure** - des placements effectifs, pas des tentatives. (La seule asymétrie : il compte la poignée de placements d'indices forcés et nous les extrayons - ≤18 sur un compte de milliards, soit rien.) Le nombre dont il faut se méfier est le « M/s » d'un *troisième* moteur : c'est là que « placements tentés » et « placements effectués » peuvent différer d'un ordre de grandeur, ce qui est la mise en garde de longue date de la communauté sur [ce qu'est un « nœud »](/fr/research/build/faster/solver-engineering/). > **Mesurer rigoureusement, ou ne pas mesurer** > > Le débit absolu en nœuds/s dérive avec la charge et la température de la machine et - comme le montre la correction plus haut - avec la façon dont le moteur *de référence* est construit. **Seuls les ratios pris dans le même état, dos à dos, sans affichage, machine par ailleurs au repos, sont fiables.** Chaque comparaison de cette page a été prise sans rien d'autre en cours, les deux moteurs compilés sans affichage avec génération de code native et exécutés à quelques secondes d'écart. Le vieux folklore « McGavin est 5× plus rapide » était aussi un mirage, dans l'autre sens : il comparait son exécution sur un puzzle facile à la nôtre sur un difficile. Faites correspondre le plateau, faites correspondre le build, mesurez dos à dos - sinon le nombre ne signifie rien. ## L'écart sur plateau facile est un levier réel et ouvert Pourquoi le C de McGavin gagne-t-il le plateau facile de 2,3× tout en n'égalisant que sur les difficiles ? Parce que sur un plateau peu ramifié il n'y a presque rien à faire par nœud - choisir la ou les deux candidates, poser, avancer - et son code en ligne droite, où la liste de candidats de chaque case est réduite à une recherche par hachage parfait minimal, le fait avec le moins d'instructions possible. Notre travail par nœud (indexer le vivier, calculer le gain, vérifier le bord) est peu coûteux mais pas *nul*, et quand l'arbre est peu profond et large, ce surcoût se voit. Sur un plateau difficile, les mêmes nœuds sont dominés par le retour arrière et les défauts de cache, où les deux moteurs convergent. Refermer l'écart facile signifierait adopter sa génération de liste de candidats plus serrée - une étape suivante concrète, pas un mur. C'est consigné ici comme ouvert plutôt que masqué. ## Ce que vaut la vitesse Pointé sur le vrai Eternity II à 256 pièces - six cœurs, quinze minutes, l'indice central obligatoire fixé - ce moteur parcourt l'arbre à des dizaines de millions de nœuds par seconde et par cœur, et plafonne, d'une graine à l'autre, dans les hauts 300 sur 480. Ce n'est pas une déception ; c'est [tout le propos de la leçon centrale du site](/fr/research/why/prune-vs-speed/). Un backtracker strict est un superbe arpenteur d'arbre et un piètre solveur : l'espace de recherche est si vaste qu'aucune vitesse atteignable n'y fait une brèche, ce qui est précisément pourquoi les records viennent des [heuristiques et de la réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/), pas du débit brut. Le résultat ici est donc délibérément étroit et, je crois, mérite d'être dit franchement : un moteur Rust *sûr et portable* peut **égaler du C optimisé à la main sur les plateaux difficiles et profonds qui ressemblent au vrai puzzle**, en parcourant le même arbre sur le même matériel - tandis que le C gagne encore de ~2,3× sur les faciles. Et même à égalité, il ne sait pas résoudre Eternity II, parce que la vitesse n'a jamais été l'obstacle. L'argument plus long sur ce compromis - pourquoi certains algorithmes dépensent leur budget en vitesse et d'autres en jugement - a sa propre page : [aller vite](/fr/research/lab/experiments/raphael-anjou/going-fast/). ## À lire aussi - [Le backtracker C de McGavin : l'histoire du débit, reconstruit ici](https://eternity2.dev/fr/research/lab/experiments/peter-mcgavin/backtracker/) — Le backtracker C de Peter McGavin, le plus rapide de la communauté : une recette d'optimisation de 2007 capitalisée pendant deux décennies via code généré, tables de correspondance et astuces de compteur, puis compilée sur mon M1 et pointée vers le vrai puzzle à 256 pièces, où en mono-cœur elle dépasse 200 des 256 pièces à ~109M placements/s. - [Aller vite : quand un solveur dépense son budget en vitesse](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/going-fast/) — Certains moteurs Eternity II mettent tout leur effort à parcourir l'arbre de recherche le plus vite possible ; d'autres le mettent dans le jugement sur où chercher. Voici le plaidoyer pour les premiers - ce qu'achète le débit brut, les trois choses différentes qu'on appelle « rapide », et pourquoi le moteur le plus rapide jamais construit ne sait toujours pas résoudre le puzzle. - [Ingénierie de solveur : l'artisanat sous l'algorithme](https://eternity2.dev/fr/research/build/faster/solver-engineering/) — Tous les solveurs record exécutent le même backtracking en profondeur d'abord. Ce qui les distingue, c'est la couche en dessous : tables de correspondance, hachages parfaits, structs taillées pour le cache, code généré, archéologie du compilateur. C'est cet artisanat qui décide si un nœud coûte 26 cycles ou 2 600. Vingt ans de registre d'ingénierie de la communauté, technique par technique, et ce que tout cela a rapporté. - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. --- # Apprendre à partir des grilles fortes > Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/ - Mise à jour: 2026-07-16 - Sujets: learning, construction --- L'essentiel de ce carnet cherche Eternity II à partir de zéro : un beam construit une grille depuis une grille vide, un backtracker creuse et rebrousse chemin, une boucle de réparation polit une grille complète coup par coup. Chacun ne raisonne qu'à partir des règles du puzzle et de la grille qu'il a sous les yeux. Cette étude fait exception, et c'est bien une étude plutôt qu'un ensemble décousu de runs parce que ses cinq expériences posent une même question sous des angles différents : **que peut apprendre une recherche des grilles que les gens ont déjà trouvées, et jusqu'où cela la porte-t-il ?** La matière première est un corpus de grilles fortes, tout arrangement que la communauté et ce projet ont poussé au-delà de 400 sur 480. Le geste, dans chacune des expériences ici, consiste à lire ce corpus pour en tirer une structure (où se placent les pièces, quelles pièces se touchent, quels motifs locaux reviennent, quels accords sont des pièges) et à réinjecter cette structure dans une recherche comme un biais. On est plus proche de l'apprentissage par imitation que de la conception d'algorithmes de recherche, et l'idée mérite son propre espace parce que la même poignée de concepts revient sans cesse, chacun un peu plus affûté que le précédent. Le corpus lui-même est [publié](/fr/research/build/dataset/) : 7 658 grilles distinctes scorant de 400 à 469, diffusées sous CC0, avec le contrôle de diversité qui empêche un signal appris de se contenter de ré-encoder une seule grille. La présentation agnostique de chaque technique vit dans la section théorique [apprendre à partir des grilles fortes](/fr/research/build/learning/) ; les pages ici en sont le versant laboratoire, les runs qui mettent chaque technique à l'épreuve de la vraie grille 16×16, avec leurs scores et les questions qu'ils ont laissées ouvertes. ## Les cinq expériences, du signal le plus simple au plus subtil L'étude se lit comme une séquence. Chaque expérience donne un tour de vis de plus que la précédente, et les pages sont ordonnées pour être lues dans cet ordre. | # | Expérience | Le signal appris | Atteint (sur 480) | |---|---|---|---| | 1 | [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/) | où chaque pièce tend à se placer, un simple comptage de positions | 460 | | 2 | [KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/) | trois signaux (position, adjacence, patch 2×2) qui votent ensemble | 460 | | 3 | [LODESTONE](/fr/research/lab/experiments/raphael-anjou/learning/lodestone/) | quelles pièces répondent à une demande de couleur rare, une faible boussole | 451 | | 4 | [PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) | les mauvaises habitudes partagées qui plafonnent les grilles, en minant le piège et non la structure | 463 | | 5 | [REPLAY](/fr/research/lab/experiments/raphael-anjou/learning/replay/) | l'unique coup qu'une seule grille record a joué et que notre recherche ne savait pas jouer | 460 | **[PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/)** est la forme la plus simple que l'idée puisse prendre, un comptage : sur les grilles fortes, à quelle fréquence chaque pièce se place-t-elle dans chaque case ? Utilisé comme départage lors de la construction, il bâtit une grille compétitive à partir de rien et atteint 460. **[KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/)** additionne les signaux plutôt que de se fier à un seul, laissant un comptage de position, un comptage d'adjacence et une qualité de patch 2×2 apprise voter sur chaque placement, ce qui mène une construction jusqu'à une famille de coins qu'aucune recherche antérieure n'avait forcée. **[LODESTONE](/fr/research/lab/experiments/raphael-anjou/learning/lodestone/)** prend le chemin inverse, vers un unique signal délibérément faible (un poids de demande rare par pièce) et, ce faisant, découvre le fil du rasoir qui traverse toute l'étude : dès qu'un signal appris cesse d'être un départage pour devenir l'objectif, la recherche s'effondre. **[PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/)** est le tournant subtil. Toutes les expériences qui la précèdent font confiance à l'accord entre grilles fortes ; celle-ci demande quels accords sont des *pièges*, des placements que toute grille adopte mais qu'aucune grille de tête ne conserve, et oriente une recherche de réparation pour les attaquer. Elle a produit la meilleure grille de ce projet, 463. **[REPLAY](/fr/research/lab/experiments/raphael-anjou/learning/replay/)** apprend d'une seule grille plutôt que d'une statistique : reconstruire exactement un record de la communauté, et tout ce qu'il faut ajouter à votre recherche pour qu'elle emprunte ce chemin est précisément l'ingrédient qui lui manquait. Ici, c'était le double break, le coup qui a fait passer l'échelle stricte de 458 à 460. ## Le mur unique que les cinq atteignent Le fil conducteur est ce qui fait de ceci une étude et non un sac de tours, et il donne à réfléchir. Chaque signal ici n'est sûr qu'en tant que biais léger : faites-lui trop confiance et la recherche se disloque (LODESTONE tombe de 451 à 380 à mesure que son poids monte ; la liste de pièges de PALIMPSEST aide comme guide et nuit comme interdit). Et même parfaitement exploité, aucun de ces signaux ne relève le plafond. Ils atteignent le sommet de la portée propre d'une recherche, vite et de façon fiable, puis s'arrêtent, parce que le corpus dont ils apprennent est fait de grilles qui butent toutes sur le même [mur de rigidité](/fr/research/why/rigidity-wall/). Apprendre à partir des grilles fortes est le chemin le plus rapide *vers* le plateau et, à lui seul, aucun chemin *au-delà*. Ce mode d'échec est le sujet de la [synthèse sur l'effondrement](/fr/research/build/learning/when-learning-collapses/) de la section théorique, et c'est la note sur laquelle toute l'étude se résout. C'est l'une des trois études du [carnet d'expériences](/fr/research/lab/experiments/raphael-anjou/). Ses sœurs, l'[étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/) et l'[étude de réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/), démontent un unique paradigme de recherche décision par décision ; celle-ci tient le paradigme lâche et fait varier ce que la recherche a le droit de *savoir*. ## Pages de cette section - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - [LODESTONE](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/lodestone/) — Une boussole ténue pour une recherche partie de zéro : l'inciter à engager les pièces rares tôt, là où elles sont nécessaires. Elle ne relève pas le plafond ; elle fait que la recherche atteint de façon fiable le sommet de sa propre plage. - [PALIMPSEST](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Lire chaque plateau fort pour repérer les habitudes qui, en silence, plafonnent un plateau, puis les briser. Cette expérience a produit le meilleur plateau du projet : 463 sur 480. - [REPLAY](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/replay/) — Reconstruire à l'identique les plateaux stricts à 460 de la communauté, et découvrir au passage le coup que les solveurs ordinaires ne savent pas jouer : payer deux désaccords sur une même case. ## À lire aussi - [Apprendre des grilles fortes](https://eternity2.dev/fr/research/build/learning/) — La plupart des attaques contre Eternity II cherchent à partir de zéro. Une famille distincte fait l'inverse : elle fouille le corpus des grilles déjà trouvées pour en extraire de la structure, puis réinjecte cette structure dans la recherche. Priors de position, ordonnancement appris des coups, fouille d'anti-motifs, décodage de records, et le mode de défaillance où un signal appris s'effondre. - [Le jeu de données](https://eternity2.dev/fr/research/build/dataset/) — Un jeu de données public sous licence CC0 pour Eternity II, en deux volets : quatorze instances de référence à résoudre, et un corpus de 7 658 plateaux forts distincts dont on peut s'inspirer. Chaque score est recalculé à partir du plateau lui-même, et le corpus est vérifié comme réellement varié, plutôt que mille copies d'un même plateau. - [Les expériences de Raphaël Anjou](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/) — Un carnet d'expériences de recherche sur Eternity II, organisé autour des moteurs partagés qui les font tourner, des pipelines de combinaison qui courent après le score, de quatre études qui décortiquent un paradigme de recherche une décision à la fois, et de résolutions exactes de fin de partie. Chacune expose son idée, son meilleur plateau et les questions qu'elle laisse ouvertes. La meilleure atteint 463 sur 480. - [L'étude DFS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. - [L'étude de la réparation](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/) — La jumelle de l'étude DFS, pour l'autre manière d'attaquer Eternity II : détruire une partie d'un plateau, la reconstruire, garder le changement s'il aide. Une question, posée avec soin. Que rapporte chaque décision de cette boucle : quelle région détruire, comment la reconstruire, quand garder un mouvement, quand redémarrer, et de quel plateau partir ? - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. --- # KEYRING > Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/ - Mise à jour: 2026-07-21 - Sujets: construction, learning - Reproduire: `just research-record-boards` - Source: La recherche en faisceau comme construction best-first à largeur bornée (page conceptuelle de ce projet) — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx --- [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/) se fiait à un seul signal appris, un décompte de positions, pour départager ses égalités. KEYRING est l'étape suivante de l'[étude](/fr/research/lab/experiments/raphael-anjou/learning/) : et si un seul signal ne suffisait pas ? Lorsqu'on construit un plateau une pièce à la fois, le point difficile consiste à décider quelle pièce placer ensuite quand plusieurs conviendraient, et une règle empirique unique, même apprise, tend à conduire la recherche vers les mêmes impasses à chaque fois. KEYRING porte trois intuitions apprises différentes en même temps, un trousseau, et les laisse voter, ce qui empêche la recherche de trop se fier à un signal en particulier. ## Fonctionnement À partir de la bibliothèque de plateaux forts, KEYRING apprend trois choses. Premièrement, où chaque pièce aime se placer : à quelle fréquence une pièce apparaît à chaque position dans les bons plateaux. Deuxièmement, quelles pièces aiment être voisines : à quelle fréquence deux pièces finissent en contact. Troisièmement, quels petits carrés 2×2 apparaissent dans les bons plateaux plutôt que dans les mauvais. Il remplit ensuite le plateau par une recherche en faisceau, en gardant de nombreux plateaux partiels vivants à la fois. Lorsqu'il doit choisir la pièce suivante, il note chaque option d'après le nombre d'arêtes qu'elle apparie, ajusté par les trois signaux appris conjointement. Une petite dose d'aléa empêche les nombreuses tentatives parallèles de s'effondrer sur un même chemin. > **[Figure]** Interactif : le vote de placement à trois signaux — interactive: KeyringDiagram. Rendered on the canonical page (link above); not shown in this markdown export. ## Le plateau > **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat KEYRING a atteint 460 sur 480, et l'a fait dans une disposition de coins où aucun plateau n'était parvenu à ce niveau auparavant : ce n'est donc pas une nouvelle route vers un plateau connu, mais une région véritablement inédite. Sur des runs répétés, il a décroché un plateau fort bien plus souvent que la version à signal unique, plus simple, dont il est issu. Ce n'est pas le meilleur score du projet (c'est 463), mais trouver un plateau élevé dans une famille inédite compte : les plateaux forts sont réputés isolés les uns des autres, si bien que chaque nouvelle famille constitue son propre point d'appui. ## Méthode Les trois signaux, rendus précis, puis la manière dont ils orientent le faisceau. Le plus fort des trois est le **prior de carré 2×2**. Sur le corpus, on sépare les plateaux en *hauts* (score ≥ 460) et *bas* (< 460), et pour chaque carré 2×2 $q$ (quatre pièces avec leurs rotations) on le note par un rapport de log-odds lissé à la Laplace : $$ \text{score}(q) = \log\big(\text{count}_\text{high}(q) + \alpha\big) - \log\big(\text{count}_\text{low}(q) + \alpha\big), \quad \alpha = 0{,}5 $$ Un carré qui apparaît dans les plateaux forts et non dans les faibles obtient un score positif ; un carré piège à consensus obtient un score négatif. (Dans le run qui a trouvé le 460, le corpus se répartissait en 23 plateaux hauts contre 1255 bas.) Les deux autres signaux sont des décomptes plus simples : une fréquence de **pièce-en-position** et une fréquence d'**adjacence de paires de pièces**, chacune comptabilisée sur le même ensemble de plateaux forts. La construction est une **recherche en faisceau** : on garde $W$ plateaux partiels vivants, et à chaque étape on étend chaque faisceau en notant chaque placement candidat comme son gain en arêtes appariées plus une somme pondérée des trois priors, puis on conserve les $W$ meilleurs. Un peu d'aléa injecté empêche les $W$ faisceaux de s'effondrer sur un seul chemin, ce qui a permis à KEYRING d'atteindre une *nouvelle* famille de coins plutôt que de redériver un plateau connu. Les carrés se compactent dans une clé `u64` (pièce ≤ 8 bits, rotation 2 bits, ×4 cellules = 40 bits), de sorte que la consultation du prior est un accès de hachage. Comme pour [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/), la construction en faisceau atteint seule la zone haute des 450 ; le plateau 460 retenu prend cette construction et ajoute par-dessus une queue de raffinement local, la même séparation construire-puis-raffiner qu'emploient les pipelines de record. Les trois signaux sont ce qui porte la *construction* dans une famille inédite ; les dernières arêtes relèvent du raffinement. Une limite qu'il vaut la peine d'énoncer : les priors sont appris d'un corpus lui-même sous-optimal, et encodent donc autant le plafond de la communauté que sa sagesse : cette même double arête que [PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) transforme en atout en séparant le bon consensus des pièges. ## Reproduire `just research-record-boards` vérifie octet par octet le score du plateau 460 retenu à partir de sa chaîne Bucas stockée. La recherche est stochastique (recherche en faisceau avec aléa injecté), si bien qu'un nouveau run ne reproduira pas le même plateau ; le plateau est l'artefact de référence. Le moteur est le producteur en faisceau partagé ; le changement décrit par cette page tient aux trois signaux de classement appris. Ces signaux sont extraits d'un corpus de plateaux forts, de sorte que le run n'est pas reproduit de zéro ici. ## Questions ouvertes Graduer le signal de carré par degré, plutôt que de traiter les carrés comme simplement bons ou mauvais, aiderait-il davantage ? Les poids des trois signaux pourraient-ils évoluer à mesure que le plateau se remplit, en se fiant davantage à la structure en fin de construction ? Et cette nouvelle famille peut-elle être poussée au-delà de 460 avec un raffinement plus long ? ## À lire aussi - [Ordonnancement des coups appris](https://eternity2.dev/fr/research/build/learning/learned-value-ordering/) — Quand plusieurs pièces conviennent, laquelle poser ensuite ? Plutôt qu'une seule règle empirique, on transporte plusieurs signaux appris des bons plateaux et on les fait voter. Le vote empêche la recherche de trop se fier à une intuition unique et de foncer vers la même impasse. - [Apprendre à partir des grilles fortes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - [Motifs interdits](https://eternity2.dev/fr/research/why/forbidden-patterns/) — Presque tout petit assemblage de pièces que l'on pourrait construire est impossible. Pour un carré 2×2, 99,72 % des façons de placer quatre pièces ne pourront jamais s'accorder. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. --- # LODESTONE > Une boussole ténue pour une recherche partie de zéro : l'inciter à engager les pièces rares tôt, là où elles sont nécessaires. Elle ne relève pas le plafond ; elle fait que la recherche atteint de façon fiable le sommet de sa propre plage. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/lodestone/ - Mise à jour: 2026-07-21 - Sujets: construction, search-space, learning - Reproduire: `just research-record-boards` - Source: Géographie des couleurs rares (ce projet) : où se situent les demandes (N,O) rares — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/why/rare-color-geography.mdx --- [KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/) ajoutait des signaux ; LODESTONE, la troisième expérience de l' [étude](/fr/research/lab/experiments/raphael-anjou/learning/), se réduit à un unique signal délibérément ténu, et ce faisant met au jour la lame de rasoir sur laquelle chaque signal appris tient ici en équilibre. Les bonnes grilles s'accordent discrètement sur un point : à mesure que le score monte, elles satisfont de plus en plus un ensemble particulier de demandes rares, ces emplacements où seules une ou deux pièces de tout le jeu peuvent servir les couleurs nord et ouest d'une case. LODESTONE se demande si le fait de renseigner une recherche partie de zéro sur ces demandes l'aide à engager les bonnes pièces rares avant qu'elles ne soient volées. ## Fonctionnement À partir du corpus des bonnes grilles, LODESTONE construit un prior : pour chaque pièce, la fréquence à laquelle elle finit par servir l'une de ces demandes rares nord-ouest dans une bonne grille, pondérée fortement à la hausse pour les plus rares, de sorte qu'une pièce qui est le seul serveur possible reçoit le plus gros bonus. La recherche par faisceau classe alors ses placements candidats selon le score d'arêtes appariées habituel, augmenté d'un petit multiple de ce prior ; ainsi, parmi des coups par ailleurs équivalents, elle préfère placer les pièces que les bonnes grilles ont appris à dépenser tôt. Le détail crucial, c'est la taille de ce multiple. Le prior doit être un pur départage, pas une composante de l'objectif : il tranche entre des coups qui s'apparient également, rien de plus. > **[Figure]** Interactif : carte d'attraction des couleurs rares — interactive: LodestoneRarityLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat À un poids infime, le prior apporte un gain faible mais constant : sur cinq graines, le score médian parti de zéro passe de 449 à 451, et, plus utile encore, la dispersion se resserre, d'un éparpillement 446-451 à une plage fiable 450-451. Il fait atterrir le constructeur au sommet de sa plage au lieu de le laisser trébucher par moments. Montez le poids ne serait-ce qu'un peu et tout s'effondre (422, puis 380), car courir après les demandes rares du corpus se paie alors directement au détriment de l'appariement de l'arête qui est devant vous. Cet échec est lui-même le résultat : la rareté est un vrai signal pour savoir *quelle* pièce préférer, mais un signal faible, et sûr uniquement en tant que départage. LODESTONE reste modeste sur son ampleur : il améliore la qualité et la régularité de la construction de quelques arêtes, et ne touche pas au plafond de bassin qui arrête toute méthode près du sommet. ## Méthode Le signal d'abord, puis la manière délibérément minuscule dont il est employé. **La mesure.** Une *demande rare* est une case dont les couleurs nord et ouest ne peuvent être servies que par une ou deux pièces de tout le jeu. Sur l'ensemble du corpus, le nombre de demandes rares satisfaites dans au moins la moitié des grilles croît *de façon monotone* avec le score, à peu près 1 → 2 → 3 → 10 à mesure que les grilles grimpent vers 458+. Les bonnes grilles ne placent pas seulement les pièces rares par hasard ; elles satisfont de plus en plus les *mêmes* demandes rares. C'est une structure réelle, corrélée au score, qu'aucun constructeur antérieur n'avait intégrée. **Le prior.** Pour chaque pièce, on pondère la fréquence à laquelle elle sert l'une de ces demandes rares nord-ouest dans une bonne grille, avec un fort renforcement pour les plus rares (une pièce qui est le *seul* serveur possible reçoit le plus gros poids). Le faisceau classe les candidats selon le gain d'arêtes appariées habituel, augmenté d'un petit multiple de ce poids. **Le réglage est toute l'histoire.** Le multiple doit être un pur *départage* : il décide entre des coups qui s'apparient également et rien d'autre. À un poids infime : score médian parti de zéro 449 → 451 sur cinq graines, et la dispersion se resserre de 446-451 à une plage fiable 450-451. Poussez le poids et tout s'effondre (422, puis 380), car courir après les demandes rares se paie alors directement au détriment de l'appariement de l'arête qui est devant vous. L'effondrement *est* le résultat : la rareté dit *quelle* pièce préférer, mais faiblement, sûre seulement en tant que départage. ## Reproduire Graine fixée ; l'artefact reproductible ici est l'*effet* du départage (une dispersion plus resserrée et une médiane +2 sur cinq graines), et non une grille unique. Le moteur est le producteur par faisceau partagé ; le changement que décrit cette page est un ténu départage pièce-rare-tôt. Ce poids de départage est dérivé du jeu de pièces et d'un corpus, si bien que le run n'est pas ici reproduit depuis zéro. ## Questions ouvertes Pourrait-on rendre le prior conscient de la position sans qu'il devienne une composante de l'objectif, fort uniquement dans les régions où les demandes rares se concentrent réellement ? Le combiner aux trois signaux de KEYRING ajoute-t-il un quatrième vote utile, ou seulement davantage de bruit ? Et le gain de régularité vaut-il plus que le gain de médiane, sachant qu'une recherche plus resserrée est plus facile à échafauder en échelle ? ## À lire aussi - [Priors de corpus](https://eternity2.dev/fr/research/build/learning/corpus-priors/) — La façon la plus simple d'apprendre des bons plateaux : compter où chaque pièce tend à se placer, ou à quelle fréquence elle satisfait une demande rare, et se servir de ce décompte comme d'un léger départage en construction. Ce doit rester un départage ; dès qu'il entre dans l'objectif, il fait s'effondrer la recherche. - [Quand l'apprentissage s'effondre](https://eternity2.dev/fr/research/build/learning/when-learning-collapses/) — La moitié désenchantée de l'apprentissage à partir des grilles fortes. Un signal appris atteint fiablement le sommet de la plage propre à une recherche, puis s'arrête. Faites-lui trop confiance et la recherche s'effondre ; même utilisé parfaitement il ne relève pas le plafond, car le plafond n'est pas une chose que le corpus connaît. - [Apprendre à partir des grilles fortes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. --- # PALIMPSEST > Lire chaque plateau fort pour repérer les habitudes qui, en silence, plafonnent un plateau, puis les briser. Cette expérience a produit le meilleur plateau du projet : 463 sur 480. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/ - Mise à jour: 2026-07-21 - Sujets: local-search, learning - Reproduire: `just research-record-boards` - Source: Ropke & Pisinger 2006, recherche adaptative à grand voisinage (le cadre destruction-réparation que ceci oriente) — https://doi.org/10.1287/trsc.1050.0135 --- Jusqu'ici, chaque expérience de l'[étude](/fr/research/lab/experiments/raphael-anjou/learning/) a fait confiance à l'accord entre plateaux forts : là où les bons plateaux concordent, on les suit. PALIMPSEST est le moment où cette confiance est examinée, et elle a produit le meilleur plateau du projet. Quand de nombreuses recherches indépendantes atteignent toutes un plateau élevé mais imparfait, elles tendent à s'accorder sur beaucoup de placements. Une partie de cet accord est une structure authentique, une autre partie est une mauvaise habitude partagée : un choix local qui paraît bon et maintient chaque recherche bloquée juste en deçà du sommet. L'idée de cette expérience est de lire l'ensemble du corpus de plateaux forts, de séparer l'accord utile du piège, et d'attaquer les pièges. ## Comment ça marche On prend chaque plateau que quiconque a trouvé et qui obtient un score raisonnable, et pour chaque paire de positions voisines on compte combien de fois une paire de pièces donnée s'y trouve, pondérée par la qualité du plateau. Deux motifs se dégagent. Certaines adjacences reviennent encore et encore dans les tout meilleurs plateaux : ce sont des structures sûres, réelles. D'autres apparaissent presque partout mais jamais dans les meilleurs plateaux : ce sont les pièges, les choix qui semblent justes et plafonnent le score. Les pièges se regroupent dans des régions particulières du plateau plutôt que de se répartir uniformément. Savoir où ils sont transforme le corpus en une carte : quels placements suivre, et lesquels démonter puis reconstruire. Regrouper les plateaux selon l'agencement de leurs coins oriente alors la recherche vers la famille la plus prometteuse à attaquer. > **[Figure]** Interactif : la carte des pièges, famille de coins par famille de coins — interactive: PalimpsestDiagram. Rendered on the canonical page (link above); not shown in this markdown export. ## Le plateau > **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat Utilisée comme carte pour orienter la recherche, cette approche a atteint 463 des 480 arêtes appariées, le meilleur plateau que ce projet ait produit. À titre de comparaison, le meilleur plateau de la communauté sur ce puzzle est 470, et une solution complète en compte 480. Une réserve mérite d'être dite : tenter d'utiliser directement la liste des pièges, en forçant la recherche à éviter les placements piégés, n'a pas fonctionné en soi et tendait à dégrader les plateaux. La valeur résidait dans la lecture du corpus pour choisir où concentrer l'effort, non dans le codage en dur de ses conclusions dans la recherche. ## Méthode Pour le lecteur qui veut la procédure exacte. Elle se déroule en deux passes. **1. Fouille de consensus pondérée par le score et séparée par bassin.** Sur un corpus de plateaux dont le score va de 400 à 480, pour chaque paire de cellules adjacentes $(i, j, \text{dir})$ et chaque paire de pièces qui s'y trouve un jour, on calcule deux fréquences plutôt qu'une : $$ \begin{aligned} p_\text{high}(\text{pair}) &= \frac{\#\{\text{boards with the pair, score} \ge 460\}}{\#\{\text{boards with score} \ge 460\}} \\[4pt] p_\text{all}(\text{pair}) &= \frac{\#\{\text{boards with the pair}\}}{\#\{\text{all boards}\}} \end{aligned} $$ ainsi qu'un *plafond* : le score maximal de tout plateau contenant cette paire. C'est le plafond, et non $p_\text{high}$, qui sépare les deux catégories. Le **bon consensus** correspond à un $p_\text{all}$ élevé assorti d'un plafond qui atteint la famille de tête, les plateaux au niveau du meilleur du projet (463) ou à un point de celui-ci : des motifs que les plateaux les plus forts conservent, donc une structure fiable. Les **pièges de consensus** correspondent à un $p_\text{all}$ élevé assorti d'un plafond qui cale quelques points plus bas, aucun plateau portant la paire ne franchissant le seuil des 460-et-quelques : le mauvais choix consenti qui verrouille toute une famille sous le record. La coupure se situe entre « atteint le sommet » et « cale juste en dessous » ; sur ce petit corpus (un plafond à 463, des plateaux groupés du haut des 450 au bas des 460) elle est fixée à la main plutôt que balayée, et $p_\text{high}$ (score $\ge$ 460) est rapporté à côté mais n'est pas le discriminant. La vue à fréquence unique (la persistance seule) ne peut pas les distinguer ; la séparation par plafond est toute l'astuce. **2. ALNS de destruction des pièges.** On prend un plateau à 461 (il se situe *à l'intérieur* du bassin des pièges par construction), on localise les ~50 paires- pièges les mieux classées qu'il contient, et on trouve le coin : la position dont le retrait brise le plus de paires-pièges tout en préservant les paires de bon consensus. Puis on perturbe ces cellules-pièges, on les échange contre des pièces non piégées, introduisant 4 à 8 discordances délibérées, et on renvoie le plateau à la [recherche adaptative à grand voisinage](/fr/research/build/local-search/local-search-alns/). L'opérateur de destruction de la pire bande d'ALNS déchire de préférence exactement ces régions intentionnellement brisées et les reconstruit. Exécution : 30 minutes × 6 graines. La complexité est banale : la passe de fouille est linéaire dans la taille du corpus, et le coût réel est la recherche ALNS qu'elle oriente. La contribution tient à l'*endroit* où elle dirige cette recherche, non à une nouvelle recherche. ## Reproduire Le vérificateur `just research-record-boards` recalcule le score en arêtes appariées du plateau à 463 versionné à partir de ses arêtes Bucas brutes et vérifie qu'il égale l'annonce, si bien que le plateau est reproductible et vérifiable octet par octet dans le visualiseur. La recherche qui l'*a trouvé* est une exécution stochastique du moteur ALNS partagé (30 min × 6 graines), orientée par la carte des pièges décrite ci-dessus. Elle ne reproduira pas le même plateau, raison pour laquelle l'artefact de référence est le plateau, non une nouvelle exécution. L'orientation est lue à partir d'un corpus de plateaux forts, si bien que l'exécution n'est pas reproduite ici depuis zéro. ## Questions ouvertes Pourquoi la reconstruction des régions piégées tend-elle à retomber sur le même plateau de tête déjà connu plutôt que sur un plateau réellement nouveau ? Une carte distincte par famille de coins révélerait-elle une structure que la carte combinée masque ? Et une pénalité douce pour les placements piégés aiderait-elle là où une interdiction stricte a nui ? ## À lire aussi - [Fouille d'anti-motifs](https://eternity2.dev/fr/research/build/learning/anti-pattern-mining/) — L'idée subtile derrière l'apprentissage à partir des grilles fortes : tout accord entre elles n'est pas bon à prendre. Certains placements partagés sont de vraies structures ; d'autres sont un piège commun qui plafonne chaque recherche juste sous le sommet. Distinguer les deux, puis attaquer le piège. - [Apprendre à partir des grilles fortes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. --- # PRIOR > Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/ - Mise à jour: 2026-07-21 - Sujets: construction, learning - Reproduire: `just research-record-boards` - Source: Recherche en faisceau (page de concept de ce projet) : construction meilleur-d'abord à largeur bornée — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx --- PRIOR ouvre l'[étude sur l'apprentissage à partir des bons plateaux](/fr/research/lab/experiments/raphael-anjou/learning/) avec la forme la plus simple que l'idée puisse prendre : un comptage. La plupart des bons plateaux de ce site sont trouvés en partant d'un plateau déjà correct puis en l'améliorant. PRIOR pose une question plus difficile : peut-on construire un plateau compétitif à partir d'une grille vide, sans aucun plateau où s'ancrer ? L'astuce consiste à laisser la foule des bons plateaux passés guider discrètement la construction sans en copier aucun en particulier, et cette guidance n'est rien de plus qu'un décompte des positions où les pièces ont tendance à se placer. ## Fonctionnement À partir de la bibliothèque des plateaux au bon score, PRIOR apprend une seule chose toute simple : pour chaque position du plateau, la fréquence à laquelle chaque pièce y apparaît. Cela donne une préférence douce, un prior, sur ce qui a tendance à aller où. Il construit ensuite par recherche en faisceau, en gardant simultanément en vie de nombreux plateaux partiels qu'il étend case par case. Quand deux options raccordent le même nombre d'arêtes, le prior tranche l'égalité en faveur de la pièce la plus typique des bons plateaux à cet endroit. Une règle de diversité empêche les nombreuses tentatives parallèles de converger vers le même chemin. Aucun plateau n'est copié à l'unité ; la guidance est statistique. > **[Figure]** Interactif : la carte de chaleur du prior positionnel — interactive: PriorDiagram. Rendered on the canonical page (link above); not shown in this markdown export. ## Le plateau > **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat En partant de zéro, PRIOR atteint le milieu des 450, et avec un prior plus tranché construit à partir des tout meilleurs plateaux uniquement, il monte plus haut. Suivi d'un raffinement local, il atteint 460, le plateau montré ici. Le fait qu'une construction à partir de rien se rapproche autant des records, c'est là tout le propos : la structure des bons plateaux est en partie apprenable, et il n'est pas nécessaire d'en partir pour y arriver. Ce n'est pas le meilleur score du projet (463), et le gain final s'appuie ici sur une étape de raffinement, ce que l'étiquette du plateau signale. Mais en tant que résultat sur table rase, c'est le plus solide du projet, et c'est la base sur laquelle les constructeurs multi-signaux ultérieurs ont grandi. ## Méthode Le prior est délibérément la chose la plus simple qui puisse marcher : un comptage. Sur chaque plateau du corpus dont le score dépasse un seuil (440 pour le prior de base), on cumule une matrice $256 \times 256$ $M[p][c]$, le nombre de bons plateaux qui placent la pièce $p$ dans la case $c$. Normalisée par case, c'est la préférence utilisée pour départager les égalités. Trois affinements, chacun une variante du même décompte : - **Sensible à la rotation.** On scinde chaque pièce selon ses quatre rotations : un tenseur $1024 \times 256$ ($256 \times 4$ lignes). Le prior préfère désormais non seulement la bonne pièce mais la bonne orientation, 262 144 entrées contre les 65 536 de base. - **Par famille de coins.** Les bons plateaux se répartissent en familles selon leurs quatre pièces de coin. Construire un prior *distinct* à partir des seuls plateaux d'une famille donne un signal que la matrice mise en commun gomme par moyennage ; c'est ce qui a permis à la construction à partir de zéro d'atteindre un 460 inédit plutôt que le bassin commun encombré. - **Seuil plus tranché.** Reconstruire le prior à partir des tout meilleurs plateaux uniquement (une coupure plus haute) relève le plafond de la construction, au prix d'un signal plus mince et plus bruité. La construction est une [recherche en faisceau](/fr/research/build/construct/beam-search/) : on garde $W$ plateaux partiels, on les étend case par case, et quand des candidats sont à égalité sur les arêtes raccordées, on laisse $M$ trancher ; une règle de diversité maintient les $W$ faisceaux à l'écart les uns des autres. Le 460 obtenu ici mène une construction en faisceau à partir de zéro jusqu'au milieu des 450, puis un court raffinement local jusqu'à 460. **La nouveauté a été vérifiée, pas supposée.** Le plateau obtenu est comparé à chaque plateau du palier 460 déjà connu, par permutation des coins et distance de Hamming sur (pièce, position) ; une correspondance ne compte comme un nouveau bassin que lorsque la famille de coins diffère ou que la distance de Hamming est grande. Le plateau de PRIOR a passé ce test : c'est un bassin réellement distinct, pas une redécouverte. ## Reproduire `just research-record-boards` vérifie exactement le score du plateau 460 validé, arête par arête, à partir de sa chaîne Bucas stockée, de sorte que le résultat est vérifiable même si la recherche qui l'a trouvé n'est pas déterministe (son gain final utilise un raffinement stochastique). Le plateau est l'artefact de référence. La recherche qui l'a produit est le producteur en faisceau partagé, avec la seule modification que décrit cette page : le prior positionnel appris qui départage ses égalités. Ce prior est une matrice extraite d'un large corpus de bons plateaux, raison pour laquelle l'exécution n'est pas reproduite ici à partir de zéro. ## Questions ouvertes Jusqu'où le prior peut-il se resserrer avant de surapprendre ? Construit à partir d'une poignée de plateaux de tête seulement, le signal est fort mais mince. Un prior distinct par famille de plateaux pourrait-il capturer une structure que le prior combiné gomme par moyennage ? Et quelle part de l'écart final tient à la construction plutôt qu'au raffinement qui la suit ? ## À lire aussi - [Priors de corpus](https://eternity2.dev/fr/research/build/learning/corpus-priors/) — La façon la plus simple d'apprendre des bons plateaux : compter où chaque pièce tend à se placer, ou à quelle fréquence elle satisfait une demande rare, et se servir de ce décompte comme d'un léger départage en construction. Ce doit rester un départage ; dès qu'il entre dans l'objectif, il fait s'effondrer la recherche. - [Apprendre à partir des grilles fortes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - [GAUNTLET](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/gauntlet/) — Lancer la même recherche en faisceau selon neuf ordres de parcours différents, pour qu'elle atterrisse dans des régions distinctes au lieu de toujours converger vers la même. L'ordre en zigzag a trouvé un plateau 458 inédit. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [PALIMPSEST](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Lire chaque plateau fort pour repérer les habitudes qui, en silence, plafonnent un plateau, puis les briser. Cette expérience a produit le meilleur plateau du projet : 463 sur 480. --- # REPLAY > Reconstruire à l'identique les plateaux stricts à 460 de la communauté, et découvrir au passage le coup que les solveurs ordinaires ne savent pas jouer : payer deux désaccords sur une même case. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/replay/ - Mise à jour: 2026-07-21 - Sujets: backtracking, learning - Source: Plateaux stricts à 460 de la communauté (chronologie des records) : les témoins que REPLAY reconstruit — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/records.mdx --- REPLAY clôt l'[étude](/fr/research/lab/experiments/raphael-anjou/learning/) sur une forme d'apprentissage différente. Chaque expérience qui l'a précédée extrayait une *statistique* de l'ensemble du corpus ; REPLAY apprend d'un *seul* plateau, et il apprend la chose qu'une statistique ne peut pas montrer : le coup exact qu'un record a joué et que notre recherche ne savait pas faire. Les plateaux publics entièrement indicés servant d'étalon à ce projet atteignent 460 (le record communautaire est depuis passé à 464), mais la propre recherche à ruptures autorisées de ce projet plafonnait à 457 ou 458, quoi qu'il arrive. REPLAY s'est donné pour but de reproduire ces plateaux 460 à l'identique, pièce par pièce, afin d'apprendre ce qu'ils faisaient que notre recherche ne savait pas faire. La réponse s'est révélée être un unique coup resté inaperçu. ## Fonctionnement Une recherche à ruptures autorisées ne laisse normalement une case porter qu'un seul désaccord au moment où on la place. REPLAY assouplit cette règle pour en admettre deux sur certaines cases, et réordonne le classement des placements candidats de sorte que les coups réellement joués par un bon plateau connu passent devant ceux qui semblent moins coûteux. Avec ces deux changements, elle peut suivre le chemin même qu'a emprunté le plateau témoin. Rejoués ainsi, les plateaux 460 de la communauté se reconstruisent à l'identique, chaque pièce à sa place, et le score se vérifie. La reproduction est la preuve que l'ingrédient manquant était bien réel. > **[Figure]** Interactif : les cases à double rupture — interactive: DoubleBreakDiagram. Rendered on the canonical page (link above); not shown in this markdown export. > **[Figure]** Interactif : rejouer l'ordonnancement des ruptures — interactive: DoubleBreakLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat Les deux plateaux stricts à 460 de la communauté se rejouent exactement jusqu'à 460. La découverte : chacun contient quatre ou cinq cases qui paient deux désaccords à la fois. Une recherche qui n'autorise qu'un seul désaccord par case ne peut littéralement pas atteindre ces plateaux, et c'est précisément pour cela que les runs antérieurs du projet saturaient à 457-458. Autoriser la double rupture hisse l'échelle stricte jusqu'à 460. C'est une explication nette d'un plateau de longue date, et une mise en garde : une règle d'apparence raisonnable (une rupture par case) barrait en silence l'accès aux plateaux mêmes que nous poursuivions. ## Méthode Le rejeu est une recherche en profondeur d'abord menée dans un mode délibérément contraint. - **Ordonnancement prior-sur-coût.** Un DFS ordinaire tolérant aux ruptures classe les placements candidats par coût de désaccord immédiat, le moins cher d'abord. REPLAY inverse la priorité en *prior-sur-coût* : les candidats réellement utilisés par le plateau témoin passent devant ceux qui semblent moins coûteux, si bien que la recherche est attirée le long du bon chemin connu au lieu de s'en écarter. C'est le drapeau `--prior-over-cost` piloté par l'ordonnancement propre au plateau témoin. - **Queue exacte.** Les 14 dernières cases sont résolues exactement (`--exact-tail 14`) plutôt qu'heuristiquement, si bien que la finale que les runs ordinaires bâclent se referme de façon déterministe. - **Le relâchement qui a compté.** Le budget de désaccords par case passe de un à deux. C'est ce seul changement qui rend les plateaux témoins accessibles. Menés sur un cadre 460 fixe, 8 threads, une cadence de redémarrage de 5 secondes et un budget par run, les deux témoins stricts à 460 de la communauté se reconstruisent pièce par pièce et le score se vérifie : la reproduction *est* la preuve que l'ingrédient manquant était la double rupture. **Le constat.** Chaque témoin contient quatre ou cinq cases qui paient deux désaccords à la fois. Une recherche plafonnée à une rupture par case ne peut pas représenter ces plateaux, et c'est exactement pour cela que les runs antérieurs du projet, tolérants aux ruptures, saturaient à 457-458. C'est un résultat de complétude de recherche déguisé en tentative de record : le mur était dans le jeu de coups, non dans le calcul. ## Reproduire Celle-ci est initialisée par graine et plus proche du déterminisme que les constructeurs stochastiques : le rejeu DFS à partir d'un cadre fixe et d'un ordonnancement de témoin reconstruit les plateaux 460 de façon fiable. Les cibles qu'il reconstitue sont les [records](/fr/research/records/) stricts à 460 propres à la communauté, si bien que les plateaux eux-mêmes figurent dans la chronologie des records ; ce que cette expérience ajoute, c'est le rejeu qui les reconstruit. Le rejeu réclame deux entrées au-delà du puzzle, un cadre de bordure et le plateau témoin de la communauté qu'il reconstitue ; un répertoire d'appui exécutable livrant les deux est prévu. ## Questions ouvertes Autoriser deux ruptures par case ouvre-t-il une voie vers 461 et au-delà, ou seulement vers les 460 connus ? Existe-t-il des plateaux nécessitant une triple rupture ? Et peut-on prédire les cases à double rupture à partir d'un plateau partiel plutôt que de les découvrir par rejeu ? ## À lire aussi - [Décoder les records](https://eternity2.dev/fr/research/build/learning/decoding-records/) — La façon la plus littérale d'apprendre d'une grille forte : la reconstruire à l'identique, pièce par pièce, jusqu'à ce que votre recherche sache la reproduire. Ce que la reconstruction vous force à ajouter est l'ingrédient qui manquait à votre recherche, et la reproduction en est la preuve. - [Apprendre à partir des grilles fortes](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/) — Une étude en cinq expériences d'une seule idée : plutôt que de chercher Eternity II à partir de zéro, exploiter la structure du corpus de grilles fortes déjà trouvées et la réinjecter dans une recherche. Un a priori de position, un vote de coup appris, une boussole de demande rare, un mineur d'anti-motifs et un décodage de record, du signal le plus simple au plus subtil, et le mur unique que les cinq atteignent. - [LADDER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lancer des centaines de courtes recherches bon marché sur le plateau, ne garder que les départs les plus profonds, et faire monter les survivants à travers des tours de plus en plus longs. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Apprentissage des no-goods : se souvenir de ses échecs](https://eternity2.dev/fr/research/build/reduce/nogood-learning/) — Un sous-arbre voué à l'échec est un théorème : cet état partiel ne pourra jamais s'étendre. Mémorisez-le et n'y revenez plus jamais. La communauté a essayé les deux variantes : tables de transposition à la manière des échecs sur la frontière de recherche, et contraintes extraites du puzzle lui-même. Le bilan complet de ce que la mémoire achète à l'échelle d'E2, et les petits plateaux où elle paie vraiment. - [PALIMPSEST](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Lire chaque plateau fort pour repérer les habitudes qui, en silence, plafonnent un plateau, puis les briser. Cette expérience a produit le meilleur plateau du projet : 463 sur 480. --- # Un élagage correct par comptage des couleurs pour la recherche tolérante aux ruptures > Suivre, couleur par couleur, l'offre de demi-arêtes face à la demande du front dans un DFS à budget de ruptures, et élaguer dès que le déficit ou sa parité dépasse les ruptures restantes. Correct par construction ; le gain se compose avec la profondeur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/ledger/ - Mise à jour: 2026-07-22 - Sujets: backtracking, search-space, structure - Reproduire: `just research-ledger-prune` - Source: Le topic de reproduction ledger-prune : code, plan et résultats committés — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/ledger-prune --- La recherche de hauts scores sur Eternity II tourne avec une tolérance aux ruptures : le DFS peut poser une pièce discordante tant que le nombre total de ruptures facturées reste dans un budget. Dans ce cadre, presque aucun élagage classique n'est correct, car le budget est une ressource globale ; une branche qui semble localement morte peut être sauvée en dépensant une rupture tout à fait ailleurs. Je me suis demandé si un test de comptage purement global pouvait élaguer malgré tout, sans jamais couper une complétion qui tient dans le budget. C'est possible : zéro déclenchement erroné sur tous les rejeux, et des réductions de nœuds qui se composent avec la profondeur, même si leur ampleur dépend du moteur. ## Fonctionnement À chaque nœud, la recherche tient un registre, couleur par couleur : l'offre de demi-arêtes que proposent encore les pièces inutilisées (les quatre côtés de chacune), et la demande du front (côtés exposés des cases posées face aux cases vides, plus le bord gris que le cadre doit encore). Deux conditions nécessaires en découlent pour toute complétion qui respecte le budget de ruptures restant r : - **Déficit.** Le manque total, sommé sur les couleurs comme max(0, demande moins offre), ne peut jamais dépasser r. C'est la forme consciente du budget de l'échec « plus de couleur c » qu'un DFS nu ne découvre que case par case. - **Parité.** Le nombre de couleurs dont l'écart offre moins demande est impair ne peut jamais dépasser 2r, plus une place par jonction d'indice non facturée. Un placement parfaitement apparié déplace chaque balance de couleur d'une quantité paire ; la parité ne bouge donc qu'à une rupture facturée (qui bascule exactement deux couleurs) ou à une jonction d'indice non facturée (au plus une). Si l'une des deux conditions échoue, aucune complétion dans le budget n'existe sous le nœud et tout le sous-arbre est sauté. Les deux se prouvent par le même argument d'invariance, ce qui rend l'élagage correct et non heuristique : il n'a jamais besoin de deviner où les ruptures seront dépensées. ## Ce qui a été mesuré Trois sondes, toutes committées dans le topic de reproduction. **La porte de correction.** Rejouer la queue parfaite connue d'un tableau à marge nulle ; la vraie queue n'ayant besoin d'aucune rupture, tout déclenchement est un bug. Huit tableaux générés, 257 profondeurs chacun : zéro déclenchement. La version d'origine de cette étude, dans mon moteur de chasse aux records, a passé la même porte sur quatre tableaux à haut score (251 cases jugées chacun), zéro déclenchement aussi. **La grille A/B.** Épuiser deux fois un suffixe fixé d'un tableau généré résolu, élagage coupé puis actif, en comptant toutes les complétions dans le budget. Les deux bras doivent trouver les mêmes complétions ; ce fut le cas dans les 144 paires non censurées. Les 96 cellules de la grille (suffixes de 20 à 32 cases, budgets 1 à 3, 8 graines) montrent un ratio de nœuds au-dessus de 1 : minimum 1,48x, médianes de 1,8x à 4,1x. La parité est partout le déclencheur dominant. **Les lignes de certificat.** Les trois tableaux 464 communautaires (retrouvés via les URL committées de [l'étude design-recipe](/fr/research/why/design-recipe/) ; le palmarès communautaire vit sur la [page des records](/fr/research/records/)) ont été retournés de 180 degrés et leurs queues épuisées à budgets sans marge, le protocole de l'étude d'origine. Les tableaux s'identifient par leur empreinte de ruptures de suffixe ; l'un lit (2, 5, 6, 7) contre le (2, 5, 6, 8) d'origine, trois profondeurs exactes et une décalée d'une seule rupture par différence de convention de facturation. Ce tableau est le tableau 1 de l'étude d'origine. ## Le résultat | Affirmation (mesure d'origine) | Mesuré ici | Statut | |---|---|---| | Zéro déclenchement erroné en rejouant les vraies queues à marge nulle | 0 déclenchement sur 8 tableaux x 257 profondeurs | reproduit | | L'élagage ne change jamais la réponse | complétions identiques dans les 144 paires A/B non censurées | reproduit | | Ratio de nœuds au-dessus de 1 à petits budgets | les 96 paires de la grille au-dessus de 1 (min 1,48x) | reproduit | | Le ratio se compose avec la profondeur (1,5x, 140x, 995x, 4 330x) | 1,7x, 19,4x, 45,3x ; ligne la plus profonde censurée | forme reproduite, ampleur liée au moteur | | Nul à grand budget (~0,1 pour cent de déclenchements) | la sonde est restée dans le régime actif (76 à 82 pour cent) | non testé ici | Sur le tableau 464 identifié, à budgets identiques à l'origine (r = 5 et r = 6 sur les lignes profondes), l'épuisement a trouvé exactement une complétion à chaque profondeur non censurée, la forme de certificat que l'origine rapporte, et le ratio se compose : > **[Figure]** Lignes de certificat sur le tableau 464 (retourné 180°, budgets sans marge) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. Un multiplicateur qui grandit avec la profondeur est la signature d'une réduction du facteur de branchement, la seule espèce d'accélération qui survit au passage à l'échelle (l'argument est déroulé dans [l'élagage bat la vitesse](/fr/research/why/prune-vs-speed/)). ## Portée et limites La correction est le titre, et elle est indépendante du moteur ; les ampleurs ne le sont pas. Le moteur d'origine jugeait le registre par candidat, sur une mise à jour incrémentale, dans une recherche à godets limitée à une discordance par case, et mesurait 140x à 4 330x sur les mêmes lignes. Ce portage juge une fois par nœud sur un registre recalculé de zéro, facture les ruptures par arête sans plafond par case, et atteint 45,3x avant que le plafond de 300 secondes ne censure la ligne la plus profonde. Porter le registre incrémental par candidat est l'étape suivante nommée ; d'ici là, le chiffre de 4 330x est attribué au moteur d'origine, pas confirmé par celui-ci. Deux choses de plus ne suivent pas. Ce n'est pas une revendication de score : LEDGER élague un DFS à budget de ruptures existant (la famille de moteurs derrière des recherches comme [celle de Joshua Blackwood](/fr/research/lab/experiments/joshua-blackwood/solver/)) ; il ne trouve rien tout seul. Et il ne paie que dans le régime petit budget et suffixe profond : l'origine mesurait environ 0,1 pour cent de déclenchements sous un budget généreux à l'échelle du tableau, où la tenue du registre est une perte sèche. Ma sonde hors régime n'a même pas pu atteindre ce régime silencieux sur un suffixe court (un budget épuisable s'assèche près des feuilles, là où vivent la plupart des nœuds) ; ce nul reste donc non testé ici. ## À lire aussi - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [Arguments de parité](https://eternity2.dev/fr/research/build/analysis/parity-arguments/) — Comptez n'importe quoi sur un plateau à appariement d'arêtes deux fois, une fois de chaque côté, et les totaux doivent coïncider, livrant des preuves d'impossibilité au prix d'un seul passage. L'histoire du 479 en montre à la fois la puissance et le piège : un argument de parité limpide, vrai pour tout coup intérieur, mis en défaut par les soixante arêtes de bordure que personne ne comptabilise. - [Conçu pour être insoluble : la recette](https://eternity2.dev/fr/research/why/design-recipe/) — Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. - [Le solveur de Blackwood, décodé et exécuté ici](https://eternity2.dev/fr/research/lab/experiments/joshua-blackwood/solver/) — Le backtracker record de Joshua Blackwood, décodé grâce aux notes de Jef Bucas (un échéancier de quotas de couleurs et une tolérance aux mismatchs en fin de partie, réglés presque optimalement), puis construit et exécuté sur mon M1 : tel que publié, il file jusqu'à 248 des 256 pièces en ignorant les indices ; épinglez les cinq indices officiels et le même moteur cale autour de 45. --- # Meet in the middle > Des expériences exactes de fin de partie qui se rejoignent au milieu : énumérer une région depuis deux extrémités et raccorder sur la couture, pour trouver la vraie meilleure complétion avec une preuve plutôt que la meilleure conjecture d'une heuristique. Elles mesurent exactement une petite région au lieu de courir après le score du plateau entier. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/ - Mise à jour: 2026-07-22 --- La recherche heuristique conjecture ; elle ne sait jamais qu'elle tient la meilleure fin possible. Les expériences réunies ici prennent le parti inverse pour une petite région : l'énumérer depuis deux extrémités, raccorder les moitiés partout où les couleurs de leur couture concordent et où leurs ensembles de pièces ne se recouvrent pas, et repartir avec la meilleure complétion *exacte*, assortie de la preuve que rien ne fait mieux. C'est le classique échange [meet-in-the-middle](/fr/research/build/exact/meet-in-the-middle/) de temps contre espace, pointé sur la fin de partie du puzzle. Ce ne sont pas des tentatives sur le score. Elles répondent à une autre question que les [pipelines de combinaison](/fr/research/lab/experiments/raphael-anjou/pipelines/) et les [études](/fr/research/lab/experiments/raphael-anjou/) de recherche : non pas *jusqu'où une heuristique peut grimper*, mais *quelle est la vraie meilleure fin de cette région, et à partir de quand les méthodes exactes cessent d'être abordables*. Une réponse exacte sur une petite région vaut ici davantage qu'un nouveau presque-succès sur le plateau entier. La première et pour l'instant seule expérience de cette classe est [BANDSAW](/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/). Elle a résolu exactement une bande de rangées sur un banc d'essai 10×10, prouvé à partir d'où le budget de mésappariements cesse d'être abordable, et laissé en sous-produit un plateau à 437 sans cadre (compté en arêtes appariées), la seule page de ce carnet à la rigueur prouvée. La section porte le nom de la technique plutôt que celui de l'unique page, parce que d'autres idées exactes de fin de partie ont vocation à la rejoindre à mesure qu'elles arrivent. ## Pages de cette section - [BANDSAW](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Résoudre exactement une bande de rangées en se rejoignant au milieu, pour trouver la vraie meilleure fin et mesurer jusqu'où décider une fin de partie. ## À lire aussi - [BANDSAW](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Résoudre exactement une bande de rangées en se rejoignant au milieu, pour trouver la vraie meilleure fin et mesurer jusqu'où décider une fin de partie. --- # BANDSAW > Résoudre exactement une bande de rangées en se rejoignant au milieu, pour trouver la vraie meilleure fin et mesurer jusqu'où décider une fin de partie. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/ - Mise à jour: 2026-07-21 - Sujets: exact-methods - Source: Rencontre au milieu (la page conceptuelle de ce projet) : la technique des deux moitiés et de la jointure — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/exact/meet-in-the-middle.mdx --- La recherche heuristique devine ; elle ne sait jamais qu'elle tient la meilleure fin possible. BANDSAW mène l'expérience inverse : pour une bande de rangées près du bas, il calcule la meilleure complétion exacte, avec la preuve que rien ne marque davantage. Le but n'est pas la vitesse mais la certitude, et cette certitude sert aussi de règle pour mesurer la difficulté réelle de la fin de partie. ## Fonctionnement On coupe la bande en une moitié haute et une moitié basse. On énumère toutes les façons de remplir la moitié haute jusqu'à un petit budget de désaccords, indexées par deux éléments : les pièces employées et la rangée de couleurs laissée pendante à la couture. On énumère la moitié basse de la même manière, mais seulement à partir des pièces que la moitié haute n'a pas utilisées. Puis on joint les deux moitiés partout où leurs couleurs de couture concordent et où leurs jeux de pièces ne se recouvrent pas. Cette jointure au milieu trouve la meilleure complétion exacte sans parcourir tout l'arbre. Des tables de bornes inférieures exactes, calculées en remontant colonne par colonne, lui permettent d'élaguer les branches qui ne peuvent déjà plus battre le budget, et il relève le budget pas à pas jusqu'à ce qu'une passe ne trouve plus rien de nouveau, ce qui prouve le meilleur score pour cette bande. > **[Figure]** Interactif : l'arbre de fin de partie par rencontre au milieu — interactive: MeetInMiddleDiagram. Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat Sur un banc d'essai 10×10, BANDSAW règle la fin de partie de façon exacte et fixe le budget là où l'exactitude cesse d'être abordable : l'arbre de recherche croît d'environ un facteur vingt par désaccord supplémentaire, des deux côtés, si bien que la rencontre au milieu cesse d'être rentable à la taille pleine du plateau. Ce résultat négatif est la partie utile : il indique précisément où les méthodes exactes s'épuisent et où les heuristiques doivent prendre le relais. Les pièces exactes qui ont survécu - les tables de bornes inférieures de suffixe et le branch-and-bound élagué - sont devenues des instruments réutilisables. Un plateau sans cadre marquant 437 est sorti de la même mécanique. ## Méthode La jointure est l'idée ; l'élagage est ce qui la rend abordable. - **Rencontre au milieu.** On coupe la bande en une moitié haute et une moitié basse. On énumère chaque remplissage de la moitié haute jusqu'à un budget de désaccords, indexé par (jeu de pièces utilisé, rangée de couleurs de couture). On énumère la moitié basse de la même façon, en ne puisant que dans les pièces laissées par la moitié haute. On joint les deux moitiés partout où leurs couleurs de couture concordent *et* où leurs jeux de pièces sont disjoints. Cette jointure trouve la meilleure complétion exacte sans jamais parcourir l'arbre entier : le classique compromis temps-contre-espace de la [rencontre au milieu](/fr/research/build/exact/meet-in-the-middle/). - **Bornes inférieures de suffixe.** Remonter colonne par colonne construit des tables de bornes inférieures exactes, si bien qu'un partiel qui ne peut déjà plus battre le budget courant est élagué avant d'être prolongé. - **Cliquet de budget.** On relève le budget de désaccords d'un cran à la fois et on résout à nouveau ; quand une passe ne trouve rien de meilleur, le meilleur précédent est *prouvé* optimal pour cette bande. Cette preuve est la raison pour laquelle cette page est étiquetée **proven**, et non mesurée : le résultat est un certificat, pas un échantillon. Le plafond mesuré : chaque moitié croît d'environ un facteur 20 par unité de budget supplémentaire, si bien qu'à la taille pleine du plateau 16×16 la table de la moitié haute ne tient plus ; c'est la mémoire, pas le temps, qui est le mur. Ce résultat négatif est le livrable : il fixe précisément où les méthodes exactes s'épuisent et où les heuristiques doivent prendre le relais. Le plateau 437 sans cadre est tombé de la même mécanique. ## Reproduire Déterministe (`kind: exact`) : la résolution par rencontre au milieu et sa preuve d'optimalité se reproduisent à l'octet près pour une bande donnée, et le plateau 437 est vérifiable dans le visualiseur. L'énumérateur MITM et les tables de bornes de suffixe sont versionnés avec le code de recherche. ## Questions ouvertes Les tables de bornes inférieures peuvent-elles passer à l'échelle de la fin de partie 16×16 complète, ou l'espace d'états de la couture croît-il trop ? À quelle taille de bande la mémoire, plutôt que le temps, devient-elle la limite ? Et les rares cas où la jointure du milieu se déclenche effectivement peuvent-ils être repérés à l'avance et terminés de façon exacte ? ## À lire aussi - [STAGED](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construire tout le plateau depuis zéro, sans cadre pré-posé, par étapes, en laissant la bordure émerger en dernier des pièces restantes. - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [Rendez-vous au milieu](https://eternity2.dev/fr/research/build/exact/meet-in-the-middle/) — Énumérer deux moitiés d'un problème et les recoller sur une interface partagée, en échangeant de la mémoire contre un exposant divisé par deux. L'astuce classique de Horowitz–Sahni, ce qu'elle donne sur des bandes du plateau, et ce que l'expérience BANDSAW de ce projet a mesuré, y compris la méthode unilatérale qui l'a battue. --- # Pipelines de combinaison > Sept expériences de recherche nommées qui visent le score, chacune un pipeline plutôt qu'un algorithme unique : elle construit un plateau avec un moteur, puis le relève ou l'achève avec un autre. À leurs côtés, deux constats décortiquent la machinerie sur laquelle les pipelines s'appuient. Chaque page consigne son idée, son plateau et les questions qu'elle laisse ouvertes. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/ - Mise à jour: 2026-07-22 --- Ce groupe rassemble sept expériences de pipeline avec score et deux constats. Un *pipeline* construit un plateau avec un moteur, puis le relève ou l'achève avec un autre ; l'intérêt tient autant à la *combinaison*, à la répartition du travail entre construction, réparation et finition exacte, qu'à l'une ou l'autre des étapes. Les deux constats, l'étude de largeur de faisceau et le cadre fluide, n'ont pas de score propre : ils décortiquent la machinerie sur laquelle cette famille s'appuie, le producteur en faisceau pour l'un, la bordure gelée de CLOISTER pour l'autre. Les cartes ci-dessous distinguent les deux genres. Ce chaînage de moteurs est aussi ce qui sépare ce groupe des quatre études qui décortiquent chacune un paradigme unique : l' [étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/), l' [étude de réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/), l'[apprentissage sur plateaux forts](/fr/research/lab/experiments/raphael-anjou/learning/) et l'[étude des indices](/fr/research/lab/experiments/raphael-anjou/hint-study/). Elles partagent les [moteurs](/fr/research/lab/experiments/raphael-anjou/engines/) ; ce qui diffère, c'est la façon dont chacune les compose et les pilote : ce qu'elle amorce, ce qu'elle interdit, ce qu'elle démolit et reconstruit. La section méthode de chaque page en parcourt les étapes dans l'ordre. Plusieurs des constructeurs partant de zéro s'appuient sur le producteur en faisceau, et deux sur la boucle de réparation ALNS, des moteurs qui n'ont pas encore leur propre fiche ici (voir la [page des moteurs](/fr/research/lab/experiments/raphael-anjou/engines/)) ; lorsqu'un pipeline le fait, sa page le dit clairement plutôt que de renvoyer vers une page qui n'existe pas encore. Elles sont classées par ce qu'elles ont appris, non par leur score. Un pipeline qui a terminé plus bas mais a expliqué pourquoi vaut davantage ici qu'un pipeline qui a grappillé un point sans savoir dire comment. ## Pages de cette section - [GAUNTLET](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/gauntlet/) — Lancer la même recherche en faisceau selon neuf ordres de parcours différents, pour qu'elle atterrisse dans des régions distinctes au lieu de toujours converger vers la même. L'ordre en zigzag a trouvé un plateau 458 inédit. - [CLOISTER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fixer une bordure parfaite, puis explorer l'intérieur en traitant les arêtes de la bordure comme des contraintes dures dès la toute première case. - [CAS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cas/) — Poser d'abord une bordure parfaite, puis résoudre le plateau vers l'intérieur, anneau par anneau, chaque anneau comme un problème d'affectation sur les pièces restantes. - [MIDDEN](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/midden/) — Décider à l'avance non pas quand un plateau peut casser, mais où : confiner chaque désaccord à une forme de cellules choisie, et chercher la meilleure forme. - [Le cadre fluide](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/) — Une bordure parfaite de 60 pièces n'est pas un objet rigide. Chaque cadre entièrement apparié admet exactement 45 échanges libres à coût de bordure nul ; un tiers des cadres parfaits ne peuvent même pas démarrer l'intérieur, et un seul échange libre ranime chacun d'eux. - [LADDER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lancer des centaines de courtes recherches bon marché sur le plateau, ne garder que les départs les plus profonds, et faire monter les survivants à travers des tours de plus en plus longs. - [Rendre un producteur beam 10x meilleur : la réponse est la largeur](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/beam-width/) — Une revue vérifiée plus des mesures appariées : aucune astuce par nœud ne bat la largeur brute du faisceau à temps de calcul égal. Les deux seuls additifs qui survivent sont la randomisation des clés de troncature exactement à égalité (gratuite) et le rééchantillonnage SMC des survivants (petit mais significatif). - [MOSAIC](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/mosaic/) — Découper le plateau en petits blocs, résoudre chacun jusqu'à l'optimum prouvé, puis les recoller en payant les coutures au lieu de les interdire. En partant de zéro, sans record à recopier, la méthode atteint 448. - [STAGED](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construire tout le plateau depuis zéro, sans cadre pré-posé, par étapes, en laissant la bordure émerger en dernier des pièces restantes. --- # Rendre un producteur beam 10x meilleur : la réponse est la largeur > Une revue vérifiée plus des mesures appariées : aucune astuce par nœud ne bat la largeur brute du faisceau à temps de calcul égal. Les deux seuls additifs qui survivent sont la randomisation des clés de troncature exactement à égalité (gratuite) et le rééchantillonnage SMC des survivants (petit mais significatif). - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/beam-width/ - Mise à jour: 2026-07-22 - Sujets: construction, speed, search-space - Reproduire: `just research-beam-width-smc` - Source: Zhang, Complete Anytime Beam Search (AAAI-98) — https://cdn.aaai.org/AAAI/1998/AAAI98-060.pdf - Source: Passage à l'échelle de l'inférence par filtre particulaire (2025) — https://arxiv.org/html/2502.01618v3 - Source: Pilotage par Monte-Carlo séquentiel — https://arxiv.org/pdf/2306.03081 --- Je cherchais le levier qui rendrait un constructeur à large faisceau dix fois meilleur par unité de calcul : un score par nœud plus malin, un oracle de complétabilité, une règle de dominance, n'importe quoi. Après une revue de la littérature et une campagne de mesures A/B appariées, la réponse est décevante et utile à la fois : le levier, c'est la largeur brute. Tout ce qui est astucieux perd face à un faisceau simplement plus large à temps égal, avec exactement deux exceptions bon marché, toutes deux des changements de la règle de survie, pas du score des nœuds. ## Ce qui a été mesuré Le banc d'essai est une échelle d'instances N×N plantées et résolubles, construites avec le générateur du kit du projet : plateaux cadrés avec l'équilibre de couleurs réel, un optimum connu de 2N(N−1) arêtes intérieures appariées, et 5 cases de la solution épinglées comme indices, à l'image des indices officiels. Un beam par couches remplit le plateau en ordre ligne par ligne, et trois règles de survie s'affrontent à largeur et temps fixés : troncature top-k déterministe (plain), top-k avec départage aléatoire des clés exactement à égalité, et rééchantillonnage SMC, où les survivants sont tirés proportionnellement à un softmax de leur score, façon filtre particulaire. Chaque plateau fini est re-noté par le scoreur canonique qui exclut le pourtour ; aucun auto-rapport du solveur n'est cru sur parole. Deux disciplines comptent ici. D'abord, toutes les comparaisons sont appariées : les deux bras voient la même instance et la même graine, et les statistiques sont un t apparié et un Wilcoxon sur les deltas par graine. Ensuite, la taille des barreaux est plafonnée à N=12, car à N=14 la distribution des scores est fortement bimodale et la variance de graine écrase la variance de mécanisme ; une comparaison à quelques graines y est du bruit. L'effet de la dureté des instances sur les scores mesurés est un sujet en soi ; voir [la dureté d'une instance](/fr/research/why/how-hard-is-this-instance/). ## Le résultat La largeur est le levier dominant, et de loin. Sur le banc plus dur de l'étude d'origine, le score moyen sur l'optimum monte de façon monotone de 0,210 à la largeur 32 jusqu'à 0,346 (largeur 128), 0,527 (largeur 512) et 0,743 (largeur 2048) à budget fixe de 3 secondes. Les alternatives coûteuses perdent à temps égal dans cette même étude : un oracle de complétabilité par couplage de Hall atteint 0,441 à largeur 64 là où un faisceau plain, avec les mêmes 10 secondes, atteint 0,815 à largeur 8192, et une fusion par dominance de type diagramme de décision fait chuter le score de 0,679 à 0,657. Leur coût par nœud croît avec la taille du plateau exactement là où la profondeur est la plus rare : le temps qu'ils brûlent achète moins que la largeur qu'il aurait pu payer. La reproduction versionnée confirme chaque signe sur le banc du kit : > **[Figure]** Attendu (banc source) vs mesuré (banc du kit) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. Les deux additifs de la règle de survie sont significatifs chacun de leur côté. Randomiser les clés de troncature exactement à égalité ne coûte rien et gagne +2,06 arêtes à largeur 128. Le rééchantillonnage SMC gagne +1,75 arête à N=10 (t = 3,30) et +1,92 à N=12 (t = 5,41), avec des comptes de nœuds identiques dans les deux bras : le gain n'est pas du calcul en plus, mais un autre choix de partiels survivants. Un front rééchantillonné reste divers et vit plus profond avant de mourir, là où un front top-k déterministe peut s'étouffer tôt sur des survivants quasi identiques. La température a dû être balayée : T = 1,0 est catastrophique (17 à 29 arêtes perdues, chaque graine perd), et le gain vit sur un plateau autour de T dans [0,1, 0,2]. Le meilleur plateau de la campagne, un plateau SMC à N=12 qui marque [237 sur 264](https://eternity2.dev/viewer?puzzle=smc_n12_c22_s34&puzzle_size=12&board_edges=adcaacpdafjcacofafqcadmfaeldabmeaetbacpeabmcaadbcmeaplimjunloswuquismgtulmngmmmmtqhmpwwqmjrwdabjejbaipwjnqopwjsqiiojtskinqusmsoqhmgswukmrtuubadtblbawkolomjksplmolipknulunwnoopngrgokhvrughhdaegbpdaorlpjtwrltntisutukjswstkpvisgltvvtklhwsteafwdlbaltqlwvjhnivouspijumstrnuiwigtwvikkwwsjvkfaejbsbaqjgsjrqjvltrpgqlmmignthmitvtvpntwrhqvkhreabkbgcagpogqhpptvshqwjviwvwhuiovgrunnnghhjnhrohbafrcheajrqhpqkrshiqupnhvkopirhkrklrnutijoouovrofaevekcaqvnkkniviggnnuopqjuuhgqjvlggtsrloqhsrvpmeafvcmfanujqklquglkloitlgvkinsnvgqjsrlpkhomsprqofabrfeaakdaewdadifadgdafweadscaehcacpfacmdafrcadbaac&hints=67.0-62.1-7.2-19.0-112.0), se vérifie arête par arête dans le viewer. ## Ce qui ne suit pas C'est un résultat sur des instances d'échelle, pas sur le 16×16 canonique. Que le gain SMC se transfère à un vrai producteur 16×16, et à la qualité du vivier qu'il alimente en aval, reste explicitement ouvert ; aucun de ces chiffres n'est une revendication de record, d'aucune sorte (l'état des scores qui comptent vit sur la [page des records](/fr/research/records/)). Trois réserves mesurées bornent encore le résultat. Les instances du kit sont nettement plus faciles que le banc source (ratios de score de 0,82 à 0,88 contre 0,21 à 0,74), ce qui comprime la marge au-dessus du beam plain : le gain SMC atterrit ici vers +1 % relatif contre +6 % là-bas, même signe, significativité plus forte. Le coût par nœud de ce portage est plus élevé que celui du moteur source, donc la loi de largeur est rapportée à saturation (plafond de 12 secondes, chaque passe se termine) plutôt que dans le cadre à temps égal de la source ; les A/B de règle de survie n'en souffrent pas, puisque les deux bras développent par construction les mêmes nœuds à largeur fixée. Et le résultat sur les égalités n'autorise qu'une chose : randomiser les clés *exactement* à égalité. Élargir la fenêtre de tolérance du score est un autre geste, désastreux sur le vrai producteur 16×16 dans l'étude source (450 tombe à 290 à tolérance 2). Randomisez les égalités ; n'élargissez jamais la fenêtre. ## À lire aussi - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [Benchmark mono-cœur](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/) — Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - [Cette instance est-elle NP-complète, et comment l'encoder ?](https://eternity2.dev/fr/research/why/how-hard-is-this-instance/) — L'appariement de bords est NP-complet en tant que famille, mais cela ne dit rien d'un plateau 16×16 fixé : une instance isolée est une constante, pas un problème. Ce qui est vrai, c'est la dureté au pire cas de la famille et la dureté empirique de cette instance, et comment écrire le puzzle pour un solveur SAT, de couverture exacte ou de PLNE, avec de petits croquis détaillés. Une mesure sur plateaux plantés chiffre le choix de la formulation : une falaise de résolubilité qu'un paradigme de recherche heurte et qu'un autre franchit, et qui bouge avec le nombre de couleurs. - [LADDER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lancer des centaines de courtes recherches bon marché sur le plateau, ne garder que les départs les plus profonds, et faire monter les survivants à travers des tours de plus en plus longs. --- # CAS > Poser d'abord une bordure parfaite, puis résoudre le plateau vers l'intérieur, anneau par anneau, chaque anneau comme un problème d'affectation sur les pièces restantes. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cas/ - Mise à jour: 2026-07-22 - Sujets: construction, local-search - Reproduire: `just research-cas-annular` - Source: Sujet de reproduction (ce projet) : plan archivé, crate de calcul et résultats par cadre derrière chaque nombre de cette page — https://github.com/raphael-anjou/eternity2/blob/main/research/topics/cas-annular/article.md --- CAS (concentric annular solving, résolution annulaire concentrique) construit le plateau comme pousse un oignon : on pose une bordure parfaite, puis on résout vers l'intérieur, anneau par anneau, jusqu'à ce que les quatre cases centrales ferment le plateau. La question posée : cet ordre de l'extérieur vers l'intérieur peut-il être un chemin vers les records ? La réponse est un non net doublé d'un oui utile : depuis n'importe quel cadre parfait, le pipeline plafonne dans une bande étroite de 429 à 437, et depuis ce même état de départ il bat une poursuite par destruction-réparation sur chacun des cadres, sans exception. ## Fonctionnement Le plateau 16×16 se décompose en 8 anneaux concentriques de 60, 52, 44, 36, 28, 20, 12 et 4 cases. CAS fixe d'abord l'anneau le plus externe comme cadre parfait 60/60 : les 60 cases de bordure remplies avec des pièces de bordure, chaque arête du pourtour grise, et les 60 adjacences internes à l'anneau appariées. Il résout ensuite chaque anneau interne à son tour comme un problème d'affectation sur les pièces encore libres, en maximisant les arêtes appariées contre l'anneau qui l'entoure plus celles internes à l'anneau lui-même. Une fois posé, un anneau est gelé ; la recherche n'y revient jamais. Les runs d'origine (volumes de recherche 74 à 79) résolvaient chaque anneau par MIP, 25 à 45 secondes par cadre. La reproduction archivée le remplace par un beam déterministe de largeur 1024 par anneau, qui retombe dans la même bande, et ajoute un bras de comparaison : épingler le même cadre, laisser l'intérieur vide, et confier cet état à une [recherche locale par destruction-réparation](/fr/research/build/local-search/local-search-alns/). ## Le résultat Vingt cadres parfaits énumérés, vingt scores entre 429 et 437 arêtes appariées sur 480 (moyenne 432,8). L'audit source, sur ses propres 20 cadres, se tenait entre 430 et 436 avec une moyenne de 432,4. La bande et la moyenne se reproduisent à un point près de chaque côté, et le cadre ne compte pas : chaque cadre 60/60 mène au même plateau. Le meilleur plateau de la reproduction score 437 ; il est vérifiable [arête par arête dans la visionneuse](/viewer/?puzzle=official_eternity2&puzzle_size=16&board_edges=abdaabjbaeqbadteaftdafgfacrfabpcafubabjfafhbafqfadofadhdaendaabedgdajiggqphitwhptgiwgkogrphkpjppumhjjvomhnlvqgtnouvghmwuniombafjdpcagnnpwlmnhuqlisouoqwshwmqppvwhjqpoqtjlvmqtkuvvulkwswuommsfaemcpcansvpiujsqrluonjrkpgnmonpvmjoqgqmtrkgmhmrunhhlktnwhqkmorheabocnfavhunjlthljmlhukjgsquntksjkqtqmokkigmmhgihruhtrgrqpqrrhkpbachfoeaurhotusrgolukuwopmmukrvmqrtropprgmspgsjwuvusgtqvqvntkokvcacoeteahustsgrulorgwuiogvvlvitvtvphpsuvskpphvrkuwovqlhwnkolkgikcadgencaspwnrilpriliiklqvwvkuiwqooiqijjrprsjrmorinjmhsknoiisiwgidafwcqeawinqliwillkilwolvwlwwmulijjmqwlrtqqwosnqjtrukmttiommgllofaelepbanqrpwoiqklwooupllsnhuhwklsuhhwusqngwnnsnrqunttlqmrgtlslreaesbgbaringigqiwwvgpmiwnnvjvijnuksivrtknkvrssskujoslijjgpnilulpeaeubteanpgtqgmpvgsgisjgvntorkmnsmwktrsmvmtrtplmoslgjuhsnkoulqjkeafqeibagtgimsutsphsjnmptmqnmrwmwpkrstoptpjtlsnptgwshhlgouqnjuoufafubmdagmtlujvmqovjmnloqoqnwmsokqhmoriqjkgrntkkwvwtlrwvqvproknvfackdsdatjisvvijvlwvlkplqjskshvjhrphijurgwvjkrvwwhtrwjhhpjijnthjcadtdcaaidacidadweadpcaesbacveabpdaeufadvcafvbactfabhcafrbachcabdaac&hints=135.0-210.1-34.1-221.2-45.1). > **[Figure]** Attendu vs mesuré (20 cadres CAS, 8 cadres de référence) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. La seconde moitié est le duel. Partie du même cadre épinglé avec un intérieur vide, la poursuite par recherche locale perd à chaque fois. Dans la mesure source (alns_only complet, 60 secondes par cadre), elle atteignait 385 à 398 et perdait les 8 comparaisons disponibles par 34 à 49 points. Le proxy plus léger de la reproduction fait mieux en absolu (411 à 419) et perd quand même chaque cadre, par 13 à 23 points. L'ampleur de l'écart n'est pas comparable entre les deux montages ; sa direction et sa constance sur chaque cadre le sont. ## Pourquoi ça s'arrête Le plateau n'est pas un problème de réglage, ni un trou dans l'objectif : les 480 arêtes sont toutes dans l'objectif de CAS. Le mécanisme est une pénurie de pièces. Les anneaux externes, résolus gloutonnement, verrouillent les pièces selon leur qualité vers l'extérieur, et aux anneaux 5 à 7 le pool restant ne contient tout simplement plus de pièces dont les profils de couleurs conviennent aux contraintes tournées vers l'intérieur. C'est la version à l'échelle des anneaux du [vol de pièces](/fr/research/why/piece-theft/) : une pièce rare dépensée tôt, des anneaux avant la case qui en avait besoin. Les volumes sources ont tenté les sauvetages évidents, et les deux confirment le diagnostic. Un hybride CAS-ALNS score 418, pire que CAS seul ; une passe de raffinement ALNS sur un plateau CAS terminé atteint 437 à 439, un gain de quelques points qui reste loin de ce que d'autres pipelines de ce carnet atteignent depuis zéro sur le même matériel. Pour situer la barre de la communauté, voir la [page des records](/fr/research/records/). ## Ce qui suit, et ce qui ne suit pas CAS est deux choses à la fois, et les deux moitiés font le résultat. Comme chemin vers les records, il est réfuté en tant qu'ordre glouton : l'ordre de l'extérieur vers l'intérieur affame sa propre fin de partie, depuis n'importe quel cadre. Comme outil de sous-problème, c'est la meilleure option que j'aie mesurée pour un état précis, un cadre parfait plus un intérieur vide. Les opérateurs de destruction-réparation attendent un plateau complet à muter ; face à un intérieur vide, ils doivent d'abord en construire un, mal, tandis que CAS est exactement l'outil constructif de cet état. Le bon algorithme dépend de l'état de départ ; la composition du pipeline compte autant que ses composants. [CLOISTER](/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) est l'expérience sœur qui garde le cadre épinglé mais abandonne l'ordre anneau par anneau. Trois réserves bornent la conclusion. La reproduction épingle les cinq pièces indices officielles ; les pages sources ne disent pas si les runs d'origine le faisaient. Les cinq indices sont tous à l'intérieur, le bras cadre n'est donc pas affecté, et l'épinglage ne peut que rendre la reproduction légèrement conservatrice, la direction sûre pour une affirmation de plateau. Le bras de référence est un proxy léger : seules la direction de l'écart et sa constance sur chaque cadre se transposent, pas sa taille. Et les nombres sont des propriétés du jeu de pièces officiel 16×16 : le mécanisme vit dans les anneaux 5 à 7, qu'un plateau 8×8 (4 anneaux) n'atteint jamais, si bien qu'un test sur petit plateau ne peut ni confirmer ni réfuter la conclusion. ## Reproduire `just research-cas-annular` relance l'ensemble depuis zéro : énumération des cadres par DFS de bordure avec graine, bras CAS à 20 cadres, bras de référence à 8 cadres, et régénération du fichier de résultats archivé avec scores par cadre, écarts et une URL de visionneuse pour chaque plateau. ## À lire aussi - [CLOISTER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fixer une bordure parfaite, puis explorer l'intérieur en traitant les arêtes de la bordure comme des contraintes dures dès la toute première case. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. --- # CLOISTER > Fixer une bordure parfaite, puis explorer l'intérieur en traitant les arêtes de la bordure comme des contraintes dures dès la toute première case. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/ - Mise à jour: 2026-07-21 - Sujets: local-search, backtracking - Source: Géographie de la bordure à couleurs rares (ce projet) : pourquoi le cadre est la coupe naturelle — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/why/rare-color-geography.mdx --- La bordure et l'intérieur sont d'ordinaire résolus ensemble, ce qui gaspille des efforts : l'intérieur ne cesse de proposer des pièces qui ne pourront jamais rejoindre la bordure par la suite. CLOISTER épingle d'abord un cadre parfait de 60 pièces, puis explore l'intérieur 14×14 en prenant les arêtes tournées vers l'intérieur du cadre comme de véritables contraintes dès la première case ; un intérieur condamné est ainsi rejeté immédiatement plutôt qu'à la fin. ## Fonctionnement On part d'une bordure complète et parfaitement appariée. La recherche intérieure est un remplissage en profondeur d'abord tolérant aux ruptures, mais les cases longeant l'arête interne du cadre doivent s'accorder avec le cadre, et cette exigence est active dès le premier placement, et non vérifiée seulement une fois l'intérieur achevé. Des finales exactes évaluent la dernière région, y compris la qualité de sa jonction avec le rebord. Parce que la bordure est fixée, la recherche recueille quelque chose qu'un intérieur reconstitué après coup ne peut pas obtenir : la poignée d'arêtes supplémentaires qui découle du fait que l'intérieur épouse réellement le rebord contre lequel il a été bâti, au lieu d'être greffé sur un rebord après coup. > **[Figure]** Interactif : comment le cadre ancre l'intérieur — interactive: BorderAnchorDiagram. Rendered on the canonical page (link above); not shown in this markdown export. Essayez en direct : fixez un cadre et regardez la recherche intérieure se dérouler face à lui dans votre navigateur. > **[Figure]** Interactif : résolvez l'intérieur autonome en direct — interactive: CloisterLiveLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat En tant que solveur d'intérieur autonome, CLOISTER atteint un score intérieur de 453 sans indices, en quelques minutes, et confirme un effet réel : un intérieur bâti contre son propre rebord s'y rattache avec quelques arêtes appariées de plus que le même intérieur, de qualité équivalente, rattaché après coup. Avec les cinq indices officiels forcés, il se stabilise dans le haut des 440 à le bas des 450. Il ne bat pas les meilleurs records, et il sature comme tout le reste à l'approche du mur. Mais il isole et mesure proprement le couplage bordure-intérieur que la recherche sur plateau entier estompe. ## Méthode La recherche est un DFS tolérant aux ruptures sur l'intérieur, mais le levier tient dans le cadrage et dans une campagne en deux phases menée sur *de nombreux* cadres. - **Le cadre comme contrainte dure.** Une bordure complète de 60 pièces est fixée, et les couleurs du cadre tournées vers l'intérieur deviennent des contraintes dures sur les cases du rebord dès le tout premier placement intérieur, et non un contrôle repoussé à la fin. Un intérieur condamné est élagué immédiatement. - **Finale exacte.** La région de finale est résolue exactement (une finale exacte de 14 cases), y compris sa jonction avec le rebord, de sorte que les dernières cases sont fermées de façon déterministe plutôt que par heuristique. - **Campagne en largeur sur les cadres.** Plutôt qu'une seule bordure, on balaie un répertoire de cadres candidats en deux phases : une sonde de compatibilité avec les indices, peu coûteuse (~6 secondes), écarte les cadres incapables d'accueillir les indices, puis une recette de finale de 30 secondes tourne sur chaque cadre survivant avec 8 graines. Le meilleur intérieur l'emporte. L'effet mesuré est faible mais réel, et il provient d'une seule chose : le couplage bordure-intérieur que la recherche sur plateau entier moyenne et efface, mais qu'une construction rebord d'abord peut exploiter tant qu'elle le peut encore. 453 sans indices ; du haut des 440 au bas des 450 avec les cinq indices forcés. ## Reproduire Graine fixée et quasi déterministe à cadre donné : la résolution DFS de l'intérieur à partir d'un cadre fixe reproduit son score de façon fiable, et le plateau enregistré est vérifiable arête par arête dans la visionneuse. La résolution requiert une entrée au-delà du puzzle, un cadre de bordure parfaite pré-résolu ; un répertoire de support exécutable, livrant ce cadre aux côtés du moteur, est prévu. Pour l'instant, l'exécution reste exploratoire : le plateau 453 se vérifie dans la visionneuse, mais aucune reproduction empaquetée en une seule commande n'est encore livrée. ## Questions ouvertes Quelle part du bonus de compatibilité au rebord peut-on récolter sans fixer d'abord la bordure ? Le balayage de nombreuses bordures, plutôt que d'une seule, trouve-t-il un intérieur qui se rattache mieux encore ? Et d'où vient exactement le plafond de la version à indices stricts ? ## À lire aussi - [STAGED](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construire tout le plateau depuis zéro, sans cadre pré-posé, par étapes, en laissant la bordure émerger en dernier des pièces restantes. - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. - [MIDDEN](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/midden/) — Décider à l'avance non pas quand un plateau peut casser, mais où : confiner chaque désaccord à une forme de cellules choisie, et chercher la meilleure forme. - [Rendez-vous au milieu](https://eternity2.dev/fr/research/build/exact/meet-in-the-middle/) — Énumérer deux moitiés d'un problème et les recoller sur une interface partagée, en échangeant de la mémoire contre un exposant divisé par deux. L'astuce classique de Horowitz–Sahni, ce qu'elle donne sur des bandes du plateau, et ce que l'expérience BANDSAW de ce projet a mesuré, y compris la méthode unilatérale qui l'a battue. - [Le cadre fluide](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/) — Une bordure parfaite de 60 pièces n'est pas un objet rigide. Chaque cadre entièrement apparié admet exactement 45 échanges libres à coût de bordure nul ; un tiers des cadres parfaits ne peuvent même pas démarrer l'intérieur, et un seul échange libre ranime chacun d'eux. --- # Le cadre fluide > Une bordure parfaite de 60 pièces n'est pas un objet rigide. Chaque cadre entièrement apparié admet exactement 45 échanges libres à coût de bordure nul ; un tiers des cadres parfaits ne peuvent même pas démarrer l'intérieur, et un seul échange libre ranime chacun d'eux. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/ - Mise à jour: 2026-07-22 - Sujets: structure, local-search - Reproduire: `just research-frame-manifold` - Source: Sujet de reproduction (ce projet) : plan, code de calcul et résultats derrière chaque nombre de cette page — https://github.com/raphael-anjou/eternity2/blob/main/research/topics/frame-manifold/article.md --- Les pipelines « bordure d'abord » comme [CLOISTER](/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) construisent une bordure de 60 pièces entièrement appariée, la gèlent, puis imposent ses 56 couleurs tournées vers l'intérieur comme contraintes dures à la recherche intérieure. Je voulais savoir si cet objet gelé est vraiment un seul objet, en partant d'un réflexe simple : quand l'intérieur cale contre le rebord, pourquoi revenir en arrière sur la bordure alors qu'on pourrait échanger une seule pièce du rebord ? Mesurée sur 500 cadres parfaits frais, la réponse est plus nette que la question. Une bordure parfaite est une variété connexe avec exactement 45 sorties libres ; un tiers des bordures parfaites ne peuvent même pas démarrer l'intérieur ; et un échange libre répare chaque cadre mort échantillonné, à coût de bordure nul. ## Ce qui a été mesuré D'abord les définitions. Un cadre place les 4 coins et les 56 pièces de bord sur les 60 cases de bordure du plateau officiel 16×16, le gris exactement vers l'extérieur. BB compte les adjacences bord-à-bord appariées le long de l'anneau, maximum 60 ; BB = 60 est un cadre parfait. Un échange légal permute deux pièces posées de la même classe (coin avec coin, pièce de bord avec pièce de bord) ; les rotations étant forcées par la règle du gris vers l'extérieur, un échange est déterminé par la paire de cases. Un échange est libre quand il laisse BB à 60. Le crate de calcul génère ses propres cadres BB = 60 du jeu officiel de 256 pièces (un placement en profondeur d'abord randomisé sur les 60 cases de bordure), puis mesure chaque affirmation directement : 1. chaque échange légal de même classe et son coût en BB, cumulé sur tous les cadres ; 2. des chaînes d'échanges libres, l'ensemble libre étant recalculé sur l'anneau courant à chaque pas, en suivant BB, le nombre de coups libres, et la dérive de l'anneau et du vecteur de couleurs intérieures ; 3. la remplissabilité de chaque case intérieure touchant le cadre : un cadre est mort quand une telle case ne peut être remplie par aucune des 196 pièces intérieures ; 4. une réparation gloutonne de chaque cadre mort par échanges libres uniquement. Passe principale : 500 cadres générés indépendamment, marche de longueur 100, réanimation tentée sur les 60 premiers cadres morts. La passe est déterministe ; relancer la commande archivée reproduit le fichier de résultats octet par octet. Le premier cadre généré se regarde dans la [visionneuse](/viewer/?puzzle=official_eternity2&puzzle_size=16&board_edges=abdaaepbacqeadpcabmdacrbacpcafvcafufabtfachbabhcacsbaepcadteaacddtcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaencnfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeabofhcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaababgcidaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabafhdofaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaafaelfoeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeaeseqbaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeabvbpcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabafuckfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaafadufqfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadadgfjbaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadaepbjfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeaetftdaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaeadwdhdaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadaendcaaocacrfacgfafqeafmfaewdafsdadidadgcadvbacjbabteabueaeibaeeaab). ## Le résultat **Exactement 45 coups libres, sur chaque cadre.** Les 500 cadres parfaits admettent exactement 45 échanges libres, jamais 44, jamais 46. Aucun échange n'augmente jamais BB (60 est le maximum), et les coups libres se composent : après 100 échanges libres enchaînés, BB vaut toujours 60 et 45 coups libres restent disponibles. Le compte ne s'épuise jamais. **Aucun n'est cosmétique.** Zéro des 45 échanges libres ne préserve la couleur intérieure des pièces touchées : chaque coup libre change le vecteur de contraintes que la bordure présente à l'intérieur. Une marche libre de 100 pas a visité 99 vecteurs de cibles de rebord distincts sur 101 possibles sans jamais quitter BB = 60. **Parfait n'est pas utilisable.** 180 des 500 cadres parfaits (36 pour cent) avaient au moins une case intérieure qu'aucune des 196 pièces intérieures ne pouvait remplir, et 46 (9,2 pour cent) étaient morts dès la toute première case qu'un solveur en ordre de balayage visite : la recherche intérieure meurt à la profondeur 0 malgré un score de bordure parfait. La réparation gloutonne par échanges libres seuls a ranimé 60 cadres morts sur 60, BB ne quittant jamais 60. Dans l'exemple travaillé de l'étude source, un seul échange libre a fait passer un DFS cadré de la profondeur 0 à la profondeur 153 sur 196. > **[Figure]** Attendu contre mesuré (passe principale, 500 cadres) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. Une passe de robustesse à graine indépendante (100 cadres frais, base de graine 7001) concorde : 45 échanges libres sur chaque cadre, aucun gain, 45 cadres morts sur 100 (histogramme 38 / 7), les 45 tous ranimés, et la marche tient de nouveau BB = 60 avec 45 coups libres du début à la fin. La chute tient donc à travers générateurs et graines : une bordure parfaite et une bordure utilisable sont deux propriétés différentes, et le cadre peut rester mobile pendant la recherche au lieu d'être défait par retour arrière. ## Ce qui n'en découle pas - Aucune affirmation n'est faite que marcher sur la variété ou ranimer des cadres morts améliore les scores de plateaux complets. L'A/B de l'étude source n'a produit aucun plateau cadré complet ; tout effet sur le score reste une question ouverte, et un producteur qui garde le cadre fluide pendant la recherche intérieure est un travail futur. Cette page publie la mécanique seule. - Le 45 est revendiqué comme une propriété du jeu de pièces officiel et répliqué ici sur des cadres issus d'un autre générateur. Le taux de cadres morts est une propriété de l'échantillonnage du générateur : 36,0 pour cent sur la passe principale, 45 pour cent sur la passe à graine indépendante ; l'énoncé défendable est un taux entre le milieu des 30 et le milieu des 40 pour cent, pas un 36 universel. - Le compte brut de paires de même classe est de 1546 par cadre ici contre environ 1458 dans la source, qui excluait de toute évidence une classe de paires sans effet. Les parts et les deux lignes porteuses (45 libres, 0 gain) concordent quoi qu'il en soit. - Les cadres sont ici sans indices, comme dans la mesure source ; la compatibilité des cadres avec les indices est un sujet distinct et ne fait pas partie de cette affirmation. ## À lire aussi - [CLOISTER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fixer une bordure parfaite, puis explorer l'intérieur en traitant les arêtes de la bordure comme des contraintes dures dès la toute première case. - [STAGED](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construire tout le plateau depuis zéro, sans cadre pré-posé, par étapes, en laissant la bordure émerger en dernier des pièces restantes. - [L'équilibre du bord](https://eternity2.dev/fr/research/why/border-balance/) — Un plateau résolu dissimule une loi comptable toute simple : chaque couleur que le bord tend vers l'intérieur, l'intérieur la lui rend aussitôt. La violer, c'est savoir sur-le-champ que le plateau est faux ; la respecter, en revanche, ne garantit rien. - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. --- # GAUNTLET > Lancer la même recherche en faisceau selon neuf ordres de parcours différents, pour qu'elle atterrisse dans des régions distinctes au lieu de toujours converger vers la même. L'ordre en zigzag a trouvé un plateau 458 inédit. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/gauntlet/ - Mise à jour: 2026-07-21 - Sujets: construction - Reproduire: `just research-record-boards` - Source: Recherche en faisceau (la page de concept de ce projet) : la construction dont on fait varier l'ordre de parcours — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx --- Une recherche en faisceau qui remplit toujours le plateau dans le même ordre a tendance à découvrir le même genre de plateau, quelle que soit la graine aléatoire. L'ordre dans lequel on visite les cases décide en sourdine de la région où l'on aboutit, et sur seize graines, un même ordre de parcours n'a produit qu'une seule famille de disposition des coins. GAUNTLET en fait un outil : lancer la recherche selon neuf ordres de parcours véritablement différents, et l'on échantillonne des régions véritablement différentes. ## Fonctionnement GAUNTLET dérive le faisceau constructif de PRIOR et lui confie un ordre de parcours interchangeable : ligne, ligne inversée, colonne, colonne inversée, zigzag, zigzag inversé, spirale entrante, spirale sortante et diagonale, neuf en tout. Comme l'ordre des cases modifie quels plateaux partiels survivent à chaque étape, chaque ordre explore une trajectoire différente au lieu de s'agglutiner sur une seule. Un balayage de 9 parcours × 4 graines a produit **18 signatures de disposition des coins distinctes**, contre une seule sur seize graines du faisceau à parcours unique dont il est issu. Chaque exécution complète produit un plateau entier ; les plus solides sont ensuite polis par un rehaussement ALNS de 30 minutes. Le constat est net : *l'ordre de parcours est un axe de diversité plus puissant que la graine aléatoire.* Voilà le levier, et c'est sur lui que s'appuient KEYRING et PRIOR par la suite. > **[Figure]** Interactif : le calendrier de l'ordre de construction — interactive: GauntletDiagram. Rendered on the canonical page (link above); not shown in this markdown export. Déroulez un parcours pour voir comment l'ordre de visite oriente le faisceau. > **[Figure]** Interactif : dérouler l'ordre de construction — interactive: GauntletStepThrough. Rendered on the canonical page (link above); not shown in this markdown export. Ou faites courir les neuf ordres les uns contre les autres, en direct, dans votre navigateur. > **[Figure]** Interactif : faire courir les stratégies de construction — interactive: GauntletLiveRace. Rendered on the canonical page (link above); not shown in this markdown export. ## Le plateau La recherche est stochastique, elle ne reproduira donc pas ce plateau exact, mais le plateau qu'elle a trouvé est figé, fourni ici, et vérifiable arête par arête. > **[Interactive: RecordBoard]** Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat L'ordre en zigzag à la graine 99, rehaussé, a atteint 458 sur 480 dans la disposition des coins cp=(3,0,1,2), le premier plateau égal ou supérieur à 458 jamais trouvé dans cette disposition au sein de notre base. Il se situe à au moins 246 cases sur 256 de tout ce que nous avions à ce niveau : un bassin véritablement nouveau, pas une autre route vers un bassin connu. La contribution de GAUNTLET est donc une portée plutôt qu'un record : il a ouvert une nouvelle région de plateaux solides. Un second tour (32 rehaussements supplémentaires) a plafonné à 457 sans aucun 461, ce qui indique que la nouvelle famille sature comme les autres, mais la famille elle-même était la prise. ## Méthode Le pipeline comporte trois étapes, et les paramètres sont l'essentiel. **Étape 1 : construction diversifiée.** On dérive le faisceau de PRIOR et on lui confie un ordre de parcours interchangeable sur les 256 cases : `row`, `row_rev`, `col`, `col_rev`, `zigzag`, `zigzag_rev`, `spiral_in`, `spiral_out`, `diagonal`, neuf ordres, croisés avec les graines `{1, 7, 42, 99}`. Tous partagent un même a priori (la matrice `high459`) à faible température de softmax (0,05), de sorte que le faisceau est guidé par l'a priori sans être déterministe. L'ordre modifie quels plateaux partiels survivent à chaque étape, si bien que chaque couple (parcours, graine) suit une trajectoire différente. **Étape 2 : rehaussement.** Chaque construction solide reçoit un rehaussement ALNS (opérateurs d'évasion d'a priori + destruction/réparation `basic_lkh`), 5 minutes par construction durant le balayage, plus longtemps pour les finalistes. **Étape 3 : regroupement.** On regroupe toutes les sorties par permutation des coins et on signale les signatures absentes de la base existante. C'est ainsi que le balayage 9×4 a fait émerger **18 familles de coins distinctes** là où seize graines d'un parcours unique n'en avaient fait émerger qu'une, la constatation mesurée selon laquelle *l'ordre de parcours est un axe de diversité plus puissant que la graine.* Le plateau gagnant, zigzag, graine 99, rehaussé, se trouve en cp = (3, 0, 1, 2), à une distance de Hamming ≥ 246/256 de tout ce qui était précédemment à ce niveau : un nouveau bassin selon le même test permutation des coins plus Hamming qu'emploie [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/). ## Reproduire `just research-record-boards` vérifie le score du plateau 458 retenu, exactement, à partir de sa chaîne Bucas stockée. Le balayage est stochastique (neuf parcours × quatre graines, puis une passe de polissage), il ne reproduira donc pas le même plateau ; le plateau est l'artefact de référence. Le moteur est le producteur en faisceau partagé, exécuté selon neuf ordres de remplissage ; il utilise le même a priori extrait du corpus que [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/), si bien que l'exécution n'est pas reproduite ici à partir de zéro. ## Questions ouvertes Cette nouvelle famille présente-t-elle la même structure locale rigide que les autres, ou une forme différente ? Et un raffinement plus long peut-il la hisser au-delà de 458, comme une famille fraîche a parfois plus de marge qu'une famille bien rodée ? ## À lire aussi - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [Rendre un producteur beam 10x meilleur : la réponse est la largeur](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/beam-width/) — Une revue vérifiée plus des mesures appariées : aucune astuce par nœud ne bat la largeur brute du faisceau à temps de calcul égal. Les deux seuls additifs qui survivent sont la randomisation des clés de troncature exactement à égalité (gratuite) et le rééchantillonnage SMC des survivants (petit mais significatif). --- # LADDER > Lancer des centaines de courtes recherches bon marché sur le plateau, ne garder que les départs les plus profonds, et faire monter les survivants à travers des tours de plus en plus longs. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/ladder/ - Mise à jour: 2026-07-21 - Sujets: local-search - Source: Halving successif / stratégies de redémarrage (la page concept sur les redémarrages de ce projet) — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/backtracking/restarts.mdx --- L'essentiel d'une longue recherche est gaspillé sur des départs condamnés dès le début. LADDER ne dépense presque rien pour découvrir quels débuts valent la peine d'être poursuivis. Il lance une avalanche de sondages très courts, garde les quelques-uns qui sont allés le plus loin, et ne paie qu'ensuite pour des exécutions plus longues, sur ceux-là seuls. C'est une sélection par tournoi appliquée aux départs de recherche. ## Comment ça marche Le premier tour, ce sont des centaines de sondages de cinq secondes partant de graines aléatoires différentes, chacun cherchant à poser une longue suite de cellules parfaitement raccordées. On garde les préfixes les plus profonds, et on écarte ceux qui sont de quasi-doublons les uns des autres pour que les survivants restent diversifiés. On promeut ces derniers vers un tour plus long doté de critères de qualité plus stricts, puis on promeut les meilleurs d'entre eux vers une exécution de pleine longueur. Chaque échelon consacre davantage de temps à des candidats moins nombreux et meilleurs, à la manière dont les tournois par halving successif allouent l'effort aux concurrents qui continuent de gagner. > **[Figure]** Interactif : la progression échelon par échelon — interactive: LadderDiagram. Rendered on the canonical page (link above); not shown in this markdown export. > **[Figure]** Interactif : lancer la recherche en échelle en direct — interactive: LadderLiveLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat LADDER a produit un plateau à 451 respectant les cinq indices officiels, sans aucune aide d'un quelconque record connu, la première fois que le projet s'est échappé de la bande de 444 à 450 dans laquelle la recherche non guidée n'arrêtait pas de retomber. Les finitions sont déterminées par leur préfixe : une fois un début suffisamment fort mis en banque, le reste suit. Une exécution plus longue a par la suite atteint 452, une arête de plus, même si 451 est le plateau retenu et reproductible ici. Il a aussi cartographié les limites : la réserve de débuts parfaits s'épuise, et au-delà d'un certain point les échelons convergent tous vers le même plafond. LADDER est donc un bon moyen de trouver le meilleur départ, non un moyen de franchir les murs structurels qui arrêtent toute méthode près du sommet. ## Méthode L'échelle est un tournoi récursif par halving successif sur les *départs* de recherche, notés par la profondeur de préfixe. - **Premier tour : avalanche.** Des centaines de sondages de 5 secondes partant de graines différentes, chacun posant une suite aussi longue que possible de cellules parfaitement raccordées. On classe par la profondeur de ce préfixe parfait ; on garde les plus profonds, et on écarte les quasi-doublons (des préfixes trop semblables à un survivant) pour que l'ensemble conservé reste diversifié. - **Cliquet.** Chaque tour suivant épingle le préfixe le plus profond mis en banque au tour précédent (un épinglage à profondeur 15 dans l'exécution enregistrée) et sonde *au-delà* de lui, poussant la frontière du préfixe parfait d'un cran de plus. La récursion s'arrête lorsqu'un tour gagne moins de quatre cellules de profondeur : la réserve de débuts plus profonds est à sec. - **Finition.** À partir des trois préfixes distincts les plus profonds, on lance de longs échelons exact-tail-14 (300 s × 8 graines chacun) pour convertir le début mis en banque en un plateau complet. Le constat est que *la finition est déterminée par le préfixe* : une fois un début parfait suffisamment profond mis en banque, la fin de partie suit. C'est pourquoi concentrer le calcul sur la découverte du meilleur départ, plutôt que de le répartir sur des exécutions complètes, a permis de s'échapper de la bande 444-450 dans laquelle la recherche non guidée n'arrêtait pas de retomber. Un tour de finition plus long a par la suite atteint 452 ; le plateau retenu et reproductible ici est le 451. ## Reproduire À graine fixée ; la structure sondage-et-promotion reproduit le *comportement* de façon fiable, même si le plateau exact dépend des graines. Le plateau 451 retenu est vérifiable dans la visionneuse. La montée n'a besoin d'aucun corpus, cadre ni témoin : elle part du puzzle seul, aussi un répertoire d'accompagnement exécutable est-il prévu pour elle aux côtés des autres expériences parties de zéro. Pour l'instant, l'exécution reste exploratoire : le plateau 451 se vérifie dans la visionneuse, mais aucune reproduction empaquetée en une seule commande n'est encore livrée. ## Questions ouvertes Quel est le vrai plafond de la sélection par préfixe d'abord si l'on donne davantage de calcul aux premiers échelons ? La règle de diversité pourrait-elle être plus fine sur les quasi-doublons à conserver ? Et combiner les préfixes les plus profonds de familles différentes bat-il la promotion au sein d'une seule ? ## À lire aussi - [REPLAY](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/replay/) — Reconstruire à l'identique les plateaux stricts à 460 de la communauté, et découvrir au passage le coup que les solveurs ordinaires ne savent pas jouer : payer deux désaccords sur une même case. - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - [Redémarrages et lois à queue lourde](https://eternity2.dev/fr/research/build/backtracking/restarts/) — Lancez deux fois le même backtracker sur le même casse-tête et les temps d'exécution diffèrent d'un facteur dix, cent, mille. La communauté l'a mesuré en 2007 ; la littérature CSP l'avait déjà nommé. Le remède (couper, rebattre, redémarrer) explique pourquoi chaque solveur record depuis est un portefeuille de redémarrages. - [Rendre un producteur beam 10x meilleur : la réponse est la largeur](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/beam-width/) — Une revue vérifiée plus des mesures appariées : aucune astuce par nœud ne bat la largeur brute du faisceau à temps de calcul égal. Les deux seuls additifs qui survivent sont la randomisation des clés de troncature exactement à égalité (gratuite) et le rééchantillonnage SMC des survivants (petit mais significatif). - [L'échelle de tailles](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/scaling-ladder/) — Un banc qui fait tourner n'importe quel solveur, tel quel, sur des plateaux plantés entièrement résolubles à N = 8, 10, 12, 14, chacun avec un plafond prouvé de 2N(N-1) : la taille d'effondrement d'une méthode se mesure avant de passer des semaines sur le vrai 16×16. --- # MIDDEN > Décider à l'avance non pas quand un plateau peut casser, mais où : confiner chaque désaccord à une forme de cellules choisie, et chercher la meilleure forme. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/midden/ - Mise à jour: 2026-07-21 - Sujets: local-search - Source: Vol de pièces (ce projet) : la vue spatiale de l'endroit où les plateaux échouent, ce que MIDDEN contrôle en amont — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/why/piece-theft.mdx --- La plupart des solveurs tolérant les cassures contrôlent quand un désaccord est permis : à certaines profondeurs, au-delà d'un certain remplissage. MIDDEN contrôle où, à la place. Il fixe un masque, un ensemble de cellules choisi, et impose que les désaccords ne puissent être payés qu'à l'intérieur ; partout ailleurs, l'accord doit être parfait. Puis il cherche sur la forme de ce masque. Les méthodes existantes disent quand encaisser des dégâts ; cette expérience demande où les dégâts doivent se loger. ## Fonctionnement Choisir un masque : deux ou trois lignes, deux ou trois colonnes, un treillis dispersé de cellules, ou un ensemble choisi par couleur. Lancer la recherche en forçant des accords parfaits hors du masque et en autorisant les désaccords uniquement à l'intérieur. Des formes de masque différentes conduisent la recherche dans des parties différentes de l'espace, si bien que le masque devient un bouton de réglage plutôt qu'une règle figée. Comparer les formes révèle quelle géométrie de dégâts autorisés permet à un plateau de faire croître une longue série parfaite avant de devoir dépenser un désaccord. > **[Figure]** Interactif : les masques de cassure par géométrie des dégâts — interactive: MaskShapeDiagram. Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat Un treillis dispersé de cellules à dégâts autorisés allonge nettement plus la plus longue série parfaite que le fait de concentrer les dégâts sur une ligne ou deux, poussant le mur parfait d'environ 150 cellules jusque dans les 170. Le mécanisme est clair ; ce qui reste ouvert, c'est l'économie de l'affaire : convertir une série parfaite plus longue en un score final plus élevé, une fois que la fin de partie doit absorber les dégâts différés. Le masque est donc un vrai levier, le complément spatial des contrôles de timing habituels, avec un effet mesuré sur la distance à laquelle un plateau reste parfait, mais pas encore une voie aboutie vers un record. ## Méthode Toutes les autres recherches tolérant les cassures régulent les dégâts par *quand* : une profondeur, une fraction de remplissage. MIDDEN régule par *où*. C'est le premier contrôle de dégâts par ensemble de cellules (OÙ) face aux régulations par profondeur (QUAND) de tous les autres. - **Le masque.** Un ensemble de cellules choisi (un masque de 256 bits) est passé via `--break-cells`. À l'intérieur du masque, les désaccords sont autorisés ; partout ailleurs, l'accord doit être parfait. La recherche est par ailleurs un DFS tolérant les cassures standard, à partir d'un cadre fixe. - **Le balayage.** La *forme* du masque devient la variable de conception : deux ou trois lignes, deux ou trois colonnes, un treillis dispersé, ou un ensemble choisi par couleur, balayés sur les formes et les densités, chacun à 300 s × 8 graines. Le résultat mesuré est une règle de conception à densité graduée : un **treillis dispersé** de cellules à dégâts autorisés allonge la plus longue série parfaite d'environ 153 cellules à 167-174 (**+21**), bien plus que le fait de concentrer les dégâts sur une ligne ou deux. Le mécanisme est clair ; l'économie qui reste ouverte, c'est la fin de partie : une série parfaite plus longue ne sert que si la queue peut absorber les dégâts différés, et le masque dispersé qui maximise le mur ne scelle pas à lui seul la fin de partie. L'étape suivante naturelle (composer un masque de corps dispersé avec une queue ouverte) est exactement ce que le balayage MIDDEN-v2 s'est proposé de tester. ## Reproduire Amorcé sur un cadre fixe ; l'effet d'allongement du mur se reproduit d'un masque à l'autre, même si le plateau exact dépend des graines, et le plateau 452 committé est vérifiable dans la visionneuse. Comme [CLOISTER](/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/), il lui faut un cadre de bordure pré-résolu (plus le masque de cellules de cassure, qui est un intrant littéral) ; un répertoire d'appui exécutable, livrant le cadre, est prévu. Pour l'instant, l'exécution reste exploratoire : le plateau 452 se vérifie dans la visionneuse, mais aucune reproduction empaquetée en une seule commande n'est encore livrée. ## Questions ouvertes Quelles formes de masque convertissent une série parfaite plus longue en arêtes réellement accordées à la fin, plutôt que de simplement différer les dégâts ? Peut-on combiner des masques spatiaux avec des contrôles de timing, de sorte qu'un plateau soit régulé à la fois sur où et sur quand il peut casser ? Et existe-t-il un masque qui reflète l'endroit où les meilleurs plateaux connus portent réellement leurs désaccords ? ## À lire aussi - [LADDER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/ladder/) — Lancer des centaines de courtes recherches bon marché sur le plateau, ne garder que les départs les plus profonds, et faire monter les survivants à travers des tours de plus en plus longs. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [CLOISTER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fixer une bordure parfaite, puis explorer l'intérieur en traitant les arêtes de la bordure comme des contraintes dures dès la toute première case. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. --- # MOSAIC > Découper le plateau en petits blocs, résoudre chacun jusqu'à l'optimum prouvé, puis les recoller en payant les coutures au lieu de les interdire. En partant de zéro, sans record à recopier, la méthode atteint 448. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/mosaic/ - Mise à jour: 2026-07-21 - Sujets: exact-methods - Source: RC2 MaxSAT (le solveur de blocs exact) : un algorithme MaxSAT pondéré guidé par les noyaux — https://doi.org/10.3233/SAT190116 --- Eternity II ne possède aucune structure locale exploitable à l'échelle globale, mais une petite fenêtre de cette structure, un bloc 4×4, se résout à l'optimum parfait en quelques secondes. MOSAIC est une expérience bâtie sur ce seul fait : si l'on sait résoudre un bloc exactement, peut-on composer seize blocs exacts en un plateau entier ? ## Fonctionnement Le plateau 16×16 est découpé en seize blocs 4×4, remplis un par un. Chaque bloc est confié à un solveur MaxSAT exact, qui trouve le meilleur placement possible des pièces qu'il contient. Toute l'astuce tient à la manière dont un bloc rejoint ses voisins déjà posés : ces arêtes partagées ne sont pas des exigences strictes mais des cibles *souples* que le bloc est récompensé d'atteindre. Un bloc ne peut donc jamais devenir impossible ; il paie simplement toute couture qu'il ne peut apparier, et se complète toujours. La seconde idée s'attaque directement au vol de pièces. Avant de remplir un bloc, MOSAIC met de côté les pièces globalement les plus rares, afin que les derniers blocs ne soient pas privés des pièces rares que leurs coutures réclameront. Régler la quantité à réserver est le seul véritable levier ; trop peu et le coin s'affame, trop et les premiers blocs en pâtissent. > **[Figure]** Interactif : la recherche d'assemblage des blocs — interactive: MosaicBlockLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat La primitive de fenêtre tient sa promesse : un bloc 4×4 se résout à son optimum de 24 arêtes en une trentaine de secondes, un 3×3 en onze, confirmant que le puzzle est bel et bien tractable à petite échelle. Composée sur l'ensemble du plateau, en partant de zéro et sans démarrage à chaud, MOSAIC atteint 448 sur 480. Le point de réservation optimal se situe autour de huit pour cent du réservoir. Le déficit est instructif : il se concentre presque entièrement dans les trois derniers blocs du coin inférieur droit, là où le réservoir finit par s'épuiser : le vol de pièces, de nouveau, désormais visible comme un unique point vif sur le plateau. L'exactitude à petite échelle se compose bien, mais l'ordre de composition dépense sa liberté tôt et la paie à la fin, la même forme que rencontre chaque méthode ici. ## Méthode L'exactitude est authentique, tout comme le retour arrière qui la recoud. - **Blocs exacts.** Chaque bloc 4×4 est encodé comme un problème *MaxSAT pondéré* et résolu par RC2, un solveur guidé par les noyaux, jusqu'à un remplissage prouvé optimal. Les arêtes partagées avec les voisins déjà posés sont des clauses *souples* (récompensées, non exigées), de sorte qu'un bloc ne peut jamais être infaisable : il paie toute couture qu'il ne peut apparier et se complète toujours. - **Retour arrière sur les solutions.** MOSAIC n'est pas un recollage en un seul coup. Chaque niveau de bloc conserve un *énumérateur* de solutions MaxSAT, meilleures d'abord, via RC2 augmenté de clauses de blocage qui écartent les remplissages déjà vus. Lorsqu'un bloc ultérieur est affamé ou qu'un niveau s'épuise, la recherche revient en arrière et tire la solution *suivante* du bloc précédent (libérant un jeu de pièces différent). C'est une recherche par retour arrière grossière sur 16 niveaux, où chaque nœud est un bloc entier optimal. - **Réservation de rareté.** Avant remplissage, MOSAIC met de côté les pièces globalement les plus rares, afin que les blocs finaux ne soient pas privés des pièces rares que leurs coutures réclament. Cette fraction de réservation est le seul véritable levier ; le point optimal mesuré est d'environ 8 % du réservoir. La primitive de fenêtre est réelle : un bloc 4×4 atteint son optimum de 24 arêtes en environ 30 s, un 3×3 en environ 11 s, le puzzle *est* tractable à petite échelle. Composée depuis zéro, elle atteint 448, le déficit résiduel se concentrant dans les trois derniers blocs du coin inférieur droit : le [vol de pièces](/fr/research/why/piece-theft/) rendu visible comme un unique point vif. ## Reproduire Déterministe : les résolutions de blocs MaxSAT et la composition par retour arrière sont exactes, d'où `kind: exact` ; le plateau à 448 se reproduit et se vérifie arête par arête dans le visualiseur. Le moteur de bloc fonctionne à partir du seul puzzle, sans corpus ni plateau de départ, sa seule dépendance externe étant un solveur MaxSAT ; un répertoire d'accompagnement exécutable est donc prévu aux côtés des autres expériences exactes. Pour l'instant, l'exécution reste exploratoire : le plateau 448 se vérifie dans le visualiseur, mais aucune reproduction empaquetée en une seule commande n'est encore livrée. ## Questions ouvertes Un ordre des blocs non ligne par ligne, en spirale vers l'intérieur ou résolvant d'abord le coin contraint, déplacerait-il l'épuisement hors du bloc le plus dur ? Les blocs pourraient-ils se chevaucher, de sorte que les coutures soient résolues deux fois puis réconciliées ? Et une primitive plus rapide (en Rust) rendrait-elle abordable une taille de bloc supérieure, avec sa garantie d'exactitude plus forte ? ## À lire aussi - [BANDSAW](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Résoudre exactement une bande de rangées en se rejoignant au milieu, pour trouver la vraie meilleure fin et mesurer jusqu'où décider une fin de partie. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Quel mur arrête quelle méthode](https://eternity2.dev/fr/research/why/walls-and-methods/) — La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - [Encodages SAT et CSP](https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/) — Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. --- # STAGED > Construire tout le plateau depuis zéro, sans cadre pré-posé, par étapes, en laissant la bordure émerger en dernier des pièces restantes. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/staged/ - Mise à jour: 2026-07-21 - Sujets: construction - Reproduire: `just research-record-boards` - Source: Recherche par faisceau (la page-concept du projet) : la primitive de construction par étapes — https://github.com/raphael-anjou/eternity2/blob/main/web/content/research/build/construct/beam-search.mdx --- Presque tous les solveurs commencent par verrouiller la bordure, parce que la bordure est la partie la plus contrainte et que l'épingler rétrécit la recherche. STAGED est une expérience qui refuse cette béquille. Il construit le plateau par étapes, du haut vers le bas, avec les 256 pièces libres, et ne s'engage jamais sur une bordure avant la toute fin, où la bordure tombe simplement de ce qui reste. La question à laquelle il répond : peut-on atteindre un plateau solide sans jamais s'ancrer à un cadre ? ## Comment ça marche La construction se déroule en quatre étapes. Les deux premières remplissent la moitié haute du plateau par une recherche simple et rapide, en mettant de côté les plateaux partiels qui survivent. Au passage de relais, une estimation admissible peu coûteuse écarte tout partiel qui ne peut manifestement pas être bien terminé, de sorte que les étapes suivantes ne travaillent que sur des départs prometteurs. La troisième étape fait croître la bande de rangées suivante à partir de ces survivants. La quatrième est un finisseur exact sur les rangées du bas qui minimise les non-concordances, et il choisit la bordure du bas en dernier, contre les pièces encore inutilisées. Le cadre n'est donc pas conçu d'emblée ; il émerge comme une conséquence de tout ce qui le surplombe. > **[Figure]** Interactif : la construction étape par étape — interactive: StageBuildDiagram. Rendered on the canonical page (link above); not shown in this markdown export. ## Le résultat STAGED atteint 436 sur 480 depuis zéro, avec une bordure émergente et les cinq indices officiels respectés, construit de bout en bout sans aucun cadre sur lequel s'appuyer. C'est bien en dessous des records, et cet écart est le constat même : il mesure ce que vaut l'ancrage habituel du cadre-d'abord, et il a montré que la mécanique sans cadre fonctionne à pleine échelle. Au passage, il a cerné l'anatomie des tout meilleurs plateaux : ce sont un bloc parfait couvrant l'essentiel du plateau, plus une fine bande de non-concordances concentrée sur quelques rangées du haut. C'est cette forme que les constructeurs ultérieurs cherchent à reproduire délibérément. ## Méthode Quatre étapes, chacune transmettant ses survivants à la suivante à travers un filtre admissible. 1. **Faisceaux de la moitié haute (étapes 1–2).** Remplir la moitié haute par une recherche simple et rapide, en mettant de côté les plateaux partiels qui survivent. Les 256 pièces sont libres, aucun cadre n'est épinglé. 2. **Passage de relais admissible.** À chaque frontière d'étape, une estimation *admissible* peu coûteuse (une borne supérieure optimiste sur la meilleure fin possible) écarte tout partiel qui, de manière prouvable, ne peut pas être bien terminé. Comme l'estimation ne sous-évalue jamais le score atteignable, l'élimination est sûre : elle ne retire que les partiels qui ne peuvent pas gagner. 3. **Croissance de bande (étape 3).** Prolonger les partiels survivants vers le bas, sur la bande de rangées suivante. 4. **Finisseur exact (étape 4).** Résoudre exactement les rangées du bas, en minimisant les non-concordances, et *choisir la bordure en dernier* parmi les pièces restantes. Le cadre n'est pas conçu d'emblée ; il tombe de tout ce qui le surplombe. Le résultat est 436 depuis zéro avec une bordure émergente, les cinq indices respectés, bien en dessous des records, et cet écart est la mesure : il chiffre ce que vaut l'ancrage habituel du cadre-d'abord. Le sous-produit a compté plus que le score : STAGED a cerné l'anatomie des meilleurs plateaux, un grand bloc parfait plus une fine bande de non-concordances sur quelques rangées du haut, la forme cible que les constructeurs ultérieurs visent délibérément. ## Reproduire Stochastique (les faisceaux de la moitié haute départagent les égalités de façon aléatoire), donc une nouvelle exécution ne reproduira pas le plateau exact ; le plateau 436 versionné est l'artefact de référence et est vérifiable dans le visualiseur. Le moteur est le producteur par faisceau partagé, exécuté par étapes pour que la bordure émerge en dernier plutôt que d'être fixée d'abord. Il ne nécessite ni corpus ni plateau de départ, aussi un répertoire de support exécutable pour l'ensemble du pipeline par étapes est-il prévu aux côtés des autres constructeurs depuis zéro. ## Questions ouvertes Un générateur qui dépenserait délibérément ses non-concordances sur les rangées du haut, pour garder le reste parfait, peut-il atteindre les 450 sans cadre ? Quelle part de l'écart de 436 aux records tient à l'ancrage de cadre manquant, par opposition à la fin de partie plus difficile ? Et une estimation apprise de la qualité de fin sélectionne-t-elle de meilleurs survivants que l'estimation admissible peu coûteuse ? ## À lire aussi - [CLOISTER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fixer une bordure parfaite, puis explorer l'intérieur en traitant les arêtes de la bordure comme des contraintes dures dès la toute première case. - [BANDSAW](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) — Résoudre exactement une bande de rangées en se rejoignant au milieu, pour trouver la vraie meilleure fin et mesurer jusqu'où décider une fin de partie. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. - [Le cadre fluide](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/fluid-frame/) — Une bordure parfaite de 60 pièces n'est pas un objet rigide. Chaque cadre entièrement apparié admet exactement 45 échanges libres à coût de bordure nul ; un tiers des cadres parfaits ne peuvent même pas démarrer l'intérieur, et un seul échange libre ranime chacun d'eux. --- # L'étude de la réparation > La jumelle de l'étude DFS, pour l'autre manière d'attaquer Eternity II : détruire une partie d'un plateau, la reconstruire, garder le changement s'il aide. Une question, posée avec soin. Que rapporte chaque décision de cette boucle : quelle région détruire, comment la reconstruire, quand garder un mouvement, quand redémarrer, et de quel plateau partir ? - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/ - Mise à jour: 2026-07-16 - Sujets: local-search, search-space, speed - Reproduire: `just experiments repair-study` - Source: Moteur exécutable + résultats commités + scripts (le répertoire de référence de cette étude) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study --- Il existe deux façons concrètes d'attaquer Eternity II. La première consiste à construire un plateau case par case et à revenir en arrière lorsqu'il échoue ; l'[étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/) la décortique. La seconde consiste à tenir un plateau entier et à le *réparer* : arracher une région, la reconstruire, garder le changement s'il a aidé, et recommencer. La réparation est l'ultime étape des chaînes construire-puis-affiner derrière les plateaux quasi-record de ce projet, et c'est la méthode vers laquelle la littérature se tourne dès qu'un plateau est trop bon pour qu'un déplacement d'une seule pièce l'améliore. Cette étude décortique la boucle de réparation comme sa jumelle a décortiqué le retour arrière : une décision à la fois, sur les mêmes dix variantes à coins épinglés, un cœur, soixante secondes par exécution. Le score maximal est de 480 arêtes appariées. La boucle elle-même est courte. Une itération, parcourue ci-dessous. > **[Figure]** Une itération de destruction-réparation, étape par étape — interactive: RepairLoopDiagram. Rendered on the canonical page (link above); not shown in this markdown export. Le but n'est pas de gagner. La plupart des variantes terminent entre 360 et 379, et celle qui fait le mieux (446) y parvient en partant d'un plateau solide obtenu par retour arrière plutôt que d'un plateau construit, ce qui constitue en soi la leçon centrale de l'étude. Réparer un simple plateau glouton sur un cœur pendant une minute est peu de chose à côté des chaînes qu'emploient les records ; ce que l'étude mesure, c'est *ce que vaut chaque décision de la boucle*, en changeant une chose à la fois et en mesurant le résultat avec le même scoreur canonique qu'utilisent l'étude DFS et le reste du site. ## La famille, et le classement Cinq familles, disposées de sorte que les voisines ne diffèrent que par une seule décision, toutes issues d'une même boucle d'ancrage épurée (départ glouton, destruction des cases dépareillées, recomplétion gloutonne, conservation du résultat sauf s'il perd du score, jamais de redémarrage). Le **plateau de départ** change le point où la boucle commence. L'**opérateur de destruction** change quelles cases chaque itération soulève. La **réparation** change la manière dont le trou est reconstruit. L'**acceptation** change le moment où un mouvement non améliorant est conservé. Le **redémarrage** change ce qui se passe une fois que la boucle s'enlise. > **[Interactive: RepairStudyLeaderboard]** Rendered on the canonical page (link above); not shown in this markdown export. ## Ce que l'étude a trouvé - **Partir d'un plateau solide obtenu par retour arrière remporte l'étude entière.** La variante qui consacre ses vingt premières secondes à exécuter le break-DFS de l'étude DFS, puis répare le plateau à un peu plus de 440 qui en résulte, termine la plus haute de toutes, avec une moyenne de 446 (meilleur résultat 449). La réparation n'ajoute qu'une poignée d'arêtes par-dessus ce plateau, mais le plateau dont elle part vaut cent points de plus qu'une construction gloutonne, et cela se répercute jusqu'au bout. C'est la division du travail construire-puis-affiner qu'emploient les records, reproduite de bout en bout sur un cœur en une minute. - **Parmi les variantes à départ glouton, la destruction aléatoire l'emporte et cibler les défauts se retourne contre soi.** Une destruction aveugle à la géométrie qui soulève douze cases *aléatoires* termine à une moyenne de 402 (meilleur résultat 409) et continue de s'améliorer tard dans l'exécution. Tout opérateur qui cible les cases dépareillées termine en dessous, et plus il se fixe précisément, plus il fait mal : l'ancre des cases dépareillées atterrit à 366, une destruction par composante connexe plus large à 350. Sur un plateau médiocre, il y a de l'amélioration disponible partout, si bien qu'explorer vaut mieux qu'attaquer là où ça fait déjà mal. Cela s'inverse sur un plateau quasi-record, où les quelques défauts restants sont la seule chose qu'il reste à corriger. - **Le plateau de départ fixe le plancher.** Une construction gloutonne démarre autour de 348 ; une construction aléatoire démarre près de 18, et bien que la boucle la fasse gagner un spectaculaire 308 points, elle termine tout de même en dessous de là où le départ glouton *commençait*. La construction est le levier, la réparation est le polissage. - **La règle d'acceptation est l'autre véritable levier.** Le recuit simulé, qui descend occasionnellement pour quitter un plateau, est la règle d'acceptation la plus forte avec une nette marge (moyenne 377, meilleur résultat 394), bien devant une montée de colline stricte (361). Le degré de tolérance accordé à un mouvement non améliorant vaut un écart de seize points sur la même boucle. - **Les raffinements astucieux ne rapportent rien ici.** Une destruction de bande entière est inerte (zéro amélioration sur neuf instances sur dix). Une recomplétion *exacte* bornée d'un petit trou ne bat pas une recomplétion gloutonne simple du même trou, un résultat négatif net : ses reconstructions localement parfaites coûtent assez d'itérations pour que davantage de reconstructions gloutonnes moins chères aillent tout aussi loin. Ni un coup de pied aléatoire ni un retour-au-meilleur en cas d'enlisement ne décollent le score de la référence sans redémarrage. Chacun de ces points a son propre traitement : la manière dont le moteur est construit et la signification de chaque statistique avancée sont sur la [page méthode](/fr/research/lab/experiments/raphael-anjou/repair-study/method/), et les comparaisons de destruction, réparation, acceptation, redémarrage et plateau de départ sont détaillées sur la [page des résultats](/fr/research/lab/experiments/raphael-anjou/repair-study/findings/). ## Comment lire les chiffres Chaque plateau est re-scoré par l'unique scoreur canonique, et le score auto-déclaré d'aucun moteur n'est cru. La boucle maintient son score de manière incrémentale à mesure qu'elle place et soulève des pièces, mais le nombre publié est toujours un re-score canonique frais du plateau produit. Le débit est reporté en itérations de réparation par seconde et n'est **jamais comparé d'une famille à l'autre**, car une itération qui exécute une recomplétion exacte n'est pas la même unité de travail qu'une itération qui exécute un remplissage glouton. L'axe à surveiller est le *plateau d'enlisement* : l'itération à laquelle le meilleur global s'est amélioré pour la dernière fois, face au nombre total d'itérations exécutées. Quand la première est de quelques milliers et le second de centaines de milliers, l'exécution a trouvé sa réponse tôt puis a rabâché le même bassin pour le reste de la minute. Cet écart est la forme mesurée d'une observation de longue date sur ce casse-tête : la destruction-réparation est une superbe exploratrice de bassin et ne s'échappe pour ainsi dire jamais du bassin où elle atterrit. Tout l'appareillage (le moteur, les dix variantes, les résultats par exécution commités et les scripts de la grille) réside sous le [répertoire de référence](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study) de l'étude, et `just experiments repair-study` reconstruit le moteur et réexécute toute la grille. Le plateau, le scoreur et la couche d'E/S proviennent d'une [bibliothèque partagée](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/common) qu'utilise aussi l'étude DFS, de sorte qu'un plateau réparé et un plateau obtenu par retour arrière sont scorés par exactement le même code. ## Pages de cette section - [Comment l'étude de la réparation est construite](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/method/) — Le moteur derrière l'étude sur la réparation : une unique boucle composable de destruction-réparation où une variante est un changement déclaré par rapport à un parent, l'IO et le scoreur partagés avec l'étude DFS, une carte des désaccords maintenue de façon incrémentale, et la définition de chaque statistique que l'étude fait ressortir. - [Ce que l'étude de la réparation a montré](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/findings/) — Les cinq comparaisons au cœur de l'étude sur la réparation, décortiquées : la destruction aléatoire aveugle l'emporte tandis que tout opérateur ciblant les conflits perd ; la construction fixe le plancher ; le recuit simulé est la règle d'acceptation la plus forte ; et les raffinements astucieux (recharge exacte, redémarrages) ne rapportent rien à ce budget. ## À lire aussi - [Les expériences de Raphaël Anjou](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/) — Un carnet d'expériences de recherche sur Eternity II, organisé autour des moteurs partagés qui les font tourner, des pipelines de combinaison qui courent après le score, de quatre études qui décortiquent un paradigme de recherche une décision à la fois, et de résolutions exactes de fin de partie. Chacune expose son idée, son meilleur plateau et les questions qu'elle laisse ouvertes. La meilleure atteint 463 sur 480. - [L'étude DFS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. --- # Ce que l'étude de la réparation a montré > Les cinq comparaisons au cœur de l'étude sur la réparation, décortiquées : la destruction aléatoire aveugle l'emporte tandis que tout opérateur ciblant les conflits perd ; la construction fixe le plancher ; le recuit simulé est la règle d'acceptation la plus forte ; et les raffinements astucieux (recharge exacte, redémarrages) ne rapportent rien à ce budget. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/findings/ - Mise à jour: 2026-07-16 - Sujets: local-search, search-space, speed - Source: Résultats par exécution versionnés (results.jsonl) et rapport par famille (report.md) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study/results --- Cinq comparaisons portent l'[étude sur la réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/). Chacune isole une décision en maintenant les quatre autres fixes sur une boucle de référence simple : départ glouton, destruction des cellules en défaut, recharge gloutonne, conservation du résultat sauf s'il perd du score, jamais de redémarrage. Tous les scores sont le nombre moyen d'arêtes concordantes sur les dix variantes à coins épinglés, mono-cœur, soixante secondes. Le débit d'itérations n'est jamais comparé d'une famille à l'autre. ## Le plateau de départ : le levier que la boucle ne peut remplacer Ne changez que le plateau depuis lequel la boucle démarre, et tout le reste de l'exécution en découle. Une construction gloutonne démarre autour de 348 et la boucle la porte à une moyenne de 366. Un plateau aléatoire démarre près de 18 et la boucle le porte de 308 points, énormes, jusqu'à une moyenne de 326. Ce gain plus important n'est pas la boucle qui fait mieux ; c'est la boucle qui fait mal le travail de la construction. Le départ aléatoire, après des millions d'itérations, termine encore en dessous de là où le départ glouton *commençait*. C'est le premier résultat de l'étude, et le plus solide : **la construction est le levier, la réparation est le polissage.** Une construction gloutonne « couleur la plus rare d'abord » (l'heuristique de Selby et Riordan selon laquelle une couleur rare doit être dépensée là où elle est forcée) démarre un peu plus haut encore et termine à une moyenne de 373, le meilleur des départs *gloutons*. La preuve la plus nette de ce point est de partir d'un plateau réellement fort plutôt que d'un plateau glouton. La dernière variante de plateau de départ confie à la boucle un plateau construit par le break-DFS de l'[étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/) : l'exécution passe ses vingt premières secondes à revenir en arrière jusqu'à un plateau autour de 440, puis le répare pendant les quarante restantes. Ce départ se situe cent points au-dessus d'une construction gloutonne, et il se propage directement jusqu'à l'arrivée. C'est la variante au plus haut score de toute l'étude, à une moyenne de 446 (meilleur 449), bien au-dessus des 402 de la boucle à destruction aléatoire, et elle tranche la question construire-puis-raffiner autour de laquelle tourne le reste de l'étude : la réparation *ajoute* bien quelques arêtes par-dessus un plateau fort obtenu par backtracking, mais seulement quelques-unes, et le plateau dont elle part décide presque tout. C'est exactement la division du travail qu'emploient les records, et cette étude la reproduit de bout en bout sur un cœur en une minute : un backtracker pour construire un bon plateau, puis une boucle de réparation pour en extraire les dernières arêtes. ## L'opérateur de destruction : attaquer les cassures peut se retourner contre soi Fixons maintenant le départ glouton et ne changeons que les cellules que chaque itération soulève. C'est l'axe qui porte le résultat le plus surprenant de l'étude. > **[Figure]** Les quatre opérateurs de destruction, sur un même plateau aux jointures rompues — interactive: DestroyOperatorDiagram. Rendered on the canonical page (link above); not shown in this markdown export. - **Une destruction aléatoire aveugle à la géométrie remporte la comparaison des opérateurs, à une moyenne de 402 (meilleur 409).** En soulevant douze cellules *aléatoires* au lieu des cellules rompues, elle continue d'échantillonner de nouvelles régions du plateau, accepte près des trois quarts de ses mouvements, et son meilleur score continue de s'améliorer tard dans l'exécution : sa dernière amélioration survient au-delà de trois millions d'itérations, là où toute variante pilotée par les conflits a gelé depuis longtemps. C'est la meilleure de toutes les variantes qui partent d'un plateau glouton (seul le départ ensemencé par le DFS, un tout autre levier, termine plus haut). - **Tout opérateur piloté par les conflits termine en dessous d'elle, et plus il se fixe sur les cassures, moins il réussit.** L'ancre « cellules en défaut », qui soulève jusqu'à une douzaine des cellules rompues, atteint en moyenne 366 et stagne tôt : elle arrache le même enchevêtrement groupé, le reconstruit gloutonnement dans presque la même disposition, et son meilleur score cesse de bouger en quelques milliers d'itérations. L'opérateur « composante plus halo », qui soulève tout un enchevêtrement connexe (un trou bien plus grand), fait pire encore, à 350, et son meilleur ne s'améliore plus après l'itération 211 : un trou de cette taille confie à la recharge gloutonne un sous-problème qu'elle ne sait pas améliorer, de sorte que presque rien n'est jamais conservé. - **Une destruction de bande entière est inerte.** Soulever les deux rangées comptant le plus de cassures laisse à la recharge gloutonne un sous-problème presque aussi difficile que le casse-tête lui-même ; sur neuf des dix instances, elle ne fait *aucune* amélioration sur toute la minute, de sorte que le score reporté est simplement son plateau de départ. Le schéma est net et mérite d'être énoncé clairement : sur ce départ glouton médiocre, plus un opérateur cible précisément les cassures existantes, moins il réussit, et la destruction aléatoire aveugle l'emporte. C'est l'inverse de l'intuition naturelle, et de ce qui fonctionne sur un plateau *proche du record*, où tout le plateau est proche de l'optimum et où le réglage de la communauté a jugé les opérateurs pilotés par les conflits et par composante les plus précieux, précisément parce que les quelques défauts restants sont la seule chose qu'il reste à corriger. Cette étude n'atteint jamais ce régime. Soixante secondes sur un plateau médiocre laissent une marge d'amélioration large partout, et là un opérateur qui rattaque sans cesse le même amas rompu, ou qui arrache un trou trop grand pour être bien reconstruit, perdent tous deux face à un opérateur qui se contente d'essayer sans relâche de nouvelles petites régions. Le constat n'est pas « la destruction pilotée par les conflits est mauvaise » mais « l'opérateur gagnant dépend de la qualité déjà atteinte par le plateau, et sur un plateau médiocre, explorer bat à la fois se fixer et sur-détruire ». ## Réparation : comment le trou est reconstruit Fixons la destruction et ne changeons que la recharge. Rompre les ex æquo exacts de score de la recharge gloutonne par une pièce ensemencée, plutôt que de façon déterministe, ajoute un peu d'exploration et aide légèrement, jusqu'à une moyenne de 365. La comparaison la plus tranchante est gloutonne contre recharge *exacte*, et elle doit être montée avec soin pour constituer un test propre à un seul axe : la recharge exacte ne paie que lorsque le trou est assez petit pour être exploré, aussi l'étude l'associe-t-elle à une petite destruction (au plus six cellules en défaut) et la compare-t-elle à la *même* petite destruction rechargée gloutonnement, de sorte que la seule chose qui change entre les deux est la recharge. Montée ainsi, la recharge exacte tourne à chaque itération plutôt que de retomber sur la gloutonne, reconstruisant chaque petit trou à son véritable optimum. Le résultat est un franc négatif. La recharge exacte (moyenne 360) ne bat **pas** la recharge gloutonne du même petit trou (moyenne 363) ; si tant est qu'elle soit une nuance en retrait. Deux choses l'expliquent. La recharge exacte accepte presque chaque itération, car une reconstruction localement optimale d'un trou de six cellules ne fait presque jamais baisser le score, si bien que la boucle dérive latéralement au lieu de grimper. Et elle paie cette optimalité locale à environ un tiers du nombre d'itérations, si bien que sur une minute fixe elle explore moins le plateau. Sur ce casse-tête, à ce budget, une reconstruction localement parfaite d'une région minuscule ne vaut pas ce qu'elle coûte : les reconstructions moins chères et légèrement moins bonnes de la recharge gloutonne, exécutées plus souvent, vont tout aussi loin. C'est la même question « le débit de nœuds n'est pas le score » que soulèvent les moteurs heuristiques de l'étude DFS, et ici la réponse penche du côté d'itérations plus nombreuses et moins chères, ce qui mérite d'être consigné précisément parce que l'on suppose si souvent le contraire. ## Acceptation : à quel point on autorise un mouvement non améliorant, cela compte Fixons la boucle et ne changeons que le moment où un candidat non améliorant est conservé. Des cinq axes, c'est celui qui déplace le plus le score après l'opérateur de destruction. - **Une montée de colline stricte, qui ne conserve que les améliorations strictes, est la plus faible, à une moyenne de 361.** Refuser tout mouvement latéral la verrouille dans le premier bassin qu'elle trouve ; son taux d'acceptation est essentiellement nul. - **Autoriser les mouvements égaux ou meilleurs (l'ancre) fait mieux, à 366.** Les mouvements latéraux lui permettent de dériver à travers les plateaux à score égal qui dominent ce paysage. - **Une règle de recuit simulé avec refroidissement est l'acceptation la plus forte, avec une marge nette, à 377 (meilleur 394), parmi les meilleures des variantes à départ glouton.** Autoriser occasionnellement des mouvements *aggravants* au début, puis refroidir, lui permet de quitter un plateau où la simple dérive latérale est piégée, et son meilleur score continue de s'améliorer jusqu'aux environs de l'itération vingt mille au lieu de geler dans les premiers milliers. Une règle d'acceptation tardive, qui compare au score de quelques dizaines d'itérations plus tôt, se place entre les deux à 369. Ainsi la règle d'acceptation est ici un vrai levier, non un détail : du strict au recuit, c'est un écart de seize points sur la même boucle (361 à 377). Cela mérite d'être énoncé face à une observation connue du propre réglage ALNS de la communauté : sur une large plage de températures de recuit, les scores finaux étaient essentiellement identiques. Les deux ne sont pas en contradiction. Ce réglage avait été fait sur des plateaux proches du record, où le paysage est une mer de plateaux à score égal et où toute température accepte presque tout ; le plateau de départ médiocre de cette étude conserve une vraie structure en descente à exploiter, de sorte que le fait que la règle veuille bien descendre pour échapper à un plateau importe réellement. Quelle règle d'acceptation l'emporte, comme quel opérateur de destruction l'emporte, dépend de la qualité déjà atteinte par le plateau. ## Redémarrage : aucune perturbation ne fait bouger l'aiguille Fixons la boucle et ne changeons que ce qui se passe une fois qu'elle stagne. Ne rien faire laisse l'exécution ratisser le même bassin pour le reste de la minute. Un *coup* aléatoire, qui déplace et recharge aléatoirement une vingtaine de cellules quand le meilleur n'a pas bougé depuis un moment, et un *retour au meilleur plateau atteint*, qui rattaque le titulaire, sont les deux perturbations testées. Toutes deux se situent à un point près de l'ancre sans redémarrage (365 et 365, contre 366 pour l'ancre). C'est un net résultat nul : greffer un détecteur de stagnation et une perturbation sur la boucle glouton-défaut ne l'aide pas, car la perturbation soit jette la structure qui rendait le plateau bon (le coup), soit revient à un plateau sur lequel le même opérateur a déjà stagné (le retour). Ni l'une ni l'autre ne transforme la boucle en évadeuse de bassin ; sur ce casse-tête, s'échapper d'un bassin exige un mouvement différent de perturber-et-réparer, ce qu'expliquent précisément le [mur de rigidité](/fr/research/why/rigidity-wall/) et la [structure des σ-cycles](/fr/research/why/sigma-cycles/). ## Le fil conducteur Deux thèmes traversent les cinq comparaisons. Le premier est que **les deux décisions qui déplacent le score sont l'opérateur de destruction et la règle d'acceptation**, et toutes deux le déplacent dans la même direction contre-intuitive : les choix gagnants sont ceux qui gardent la boucle en *exploration* plutôt qu'en *exploitation*. La destruction aléatoire bat tout opérateur qui cible les cassures ; le recuit, qui descend pour quitter un plateau, bat toute règle qui ne bouge que latéralement ou vers le haut. Raffiner la recharge et greffer un redémarrage, les deux décisions qui tentent d'être plus astucieuses au sujet d'une région où la boucle est déjà bloquée, ne rapportent rien. Le second est pourquoi explorer gagne ici tandis que se fixer gagne sur un plateau proche du record : **la boucle de réparation est une exploratrice de bassin, non une évadeuse de bassin.** Sur un plateau médiocre il y a une large structure en descente partout, de sorte que les mouvements qui en couvrent davantage l'emportent ; sur un plateau proche du record il n'en reste aucune, hormis un unique cycle imbriqué, de sorte que les mouvements qui le ciblent précisément l'emportent. Aucun des deux régimes ne permet à perturber-et-réparer de s'échapper d'un bassin une fois qu'elle y est. Voilà pourquoi les pipelines construire-puis-raffiner qui atteignent les meilleurs plateaux de ce projet divisent le travail comme ils le font : un producteur constructif fort pour choisir un bon bassin, et la réparation comme dernier kilomètre à l'intérieur, jamais sommée d'en sortir. ## À lire aussi - [L'étude de la réparation](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/) — La jumelle de l'étude DFS, pour l'autre manière d'attaquer Eternity II : détruire une partie d'un plateau, la reconstruire, garder le changement s'il aide. Une question, posée avec soin. Que rapporte chaque décision de cette boucle : quelle région détruire, comment la reconstruire, quand garder un mouvement, quand redémarrer, et de quel plateau partir ? - [Comment l'étude de la réparation est construite](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/method/) — Le moteur derrière l'étude sur la réparation : une unique boucle composable de destruction-réparation où une variante est un changement déclaré par rapport à un parent, l'IO et le scoreur partagés avec l'étude DFS, une carte des désaccords maintenue de façon incrémentale, et la définition de chaque statistique que l'étude fait ressortir. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. --- # Comment l'étude de la réparation est construite > Le moteur derrière l'étude sur la réparation : une unique boucle composable de destruction-réparation où une variante est un changement déclaré par rapport à un parent, l'IO et le scoreur partagés avec l'étude DFS, une carte des désaccords maintenue de façon incrémentale, et la définition de chaque statistique que l'étude fait ressortir. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/method/ - Mise à jour: 2026-07-16 - Sujets: local-search, speed - Source: L'espace de travail du moteur (repair-engine, repair-run) sur la bibliothèque partagée e2-core / e2-io — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study/engine --- Cette page décrit l'appareillage derrière l'[étude sur la réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/) : comment le moteur est construit, pourquoi une nouvelle variante est peu coûteuse à ajouter, et ce que signifie chaque nombre des résultats. Elle est le jumeau délibéré de la [page méthode de l'étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/method/), et elle repose sur la *même* bibliothèque partagée : le plateau, le jeu de pièces, l'unique scoreur canonique et le contrat d'IO proviennent tous d'un crate `e2-core` / `e2-io` commun qu'utilise aussi l'étude sur le backtracking. Un plateau réparé et un plateau issu du backtracking sont donc évalués par le code identique, ce qui permet aux nombres des deux études de se placer sur un même axe. ## Une variante est un changement déclaré par rapport à un parent Chaque algorithme de l'étude est la *même* boucle de destruction-réparation, paramétrée par cinq choix indépendants : - **plateau de départ** : le plateau à partir duquel la boucle commence (aléatoire, construction gloutonne, ou construction gloutonne priorisant la couleur la plus rare) ; - **opérateur de destruction** : quelles cellules chaque itération retire (aléatoires, les cellules en désaccord, la pire bande de lignes, ou une composante connexe de désaccords plus son halo) ; - **réparation** : comment le trou est comblé (glouton le plus contraint d'abord, le même avec départage bruité, ou un remplissage exact borné pour les petits trous) ; - **acceptation** : si un candidat remplace le plateau de travail (garder si ce n'est pas pire, améliorations strictes uniquement, recuit simulé, ou acceptation différée) ; - **redémarrage** : ce qui se produit lors d'un blocage (rien, une secousse aléatoire, ou un retour au meilleur plateau obtenu jusque-là). Une variante est un petit enregistrement nommant ces cinq choix, accompagné du **parent dont elle dérive et d'une description en une ligne de l'unique changement qu'elle ajoute**. Ajouter une variante revient à ajouter un enregistrement au registre, sans nouveau code de boucle sauf si l'idée constitue une stratégie véritablement nouvelle. La matrice « quoi s'empile sur quoi » de la page des résultats est générée à partir de ces descriptions, de sorte qu'elle ne peut pas diverger du code qui a réellement tourné. ## La carte des désaccords, maintenue de façon incrémentale Un backtracker construit un plateau à partir de rien ; une boucle de réparation détient toujours un plateau *complet* et le modifie. Les cellules qui valent la peine d'être attaquées sont celles qui touchent une arête cassée ; le moteur tient donc à jour, par cellule, un décompte vivant des arêtes intérieures cassées qui lui sont incidentes. Poser ou retirer une pièce ne met à jour que les arêtes autour de cette seule cellule, jamais tout le plateau, si bien qu'un opérateur de destruction guidé par les conflits peut demander « quelles cellules touchent un désaccord ? » sans réexaminer l'ensemble. Le score courant est tenu de la même manière : chaque placement l'ajuste en fonction de la poignée de coutures qui ont changé. Un rebalayage complet a lieu exactement une fois, lorsque le plateau de départ est construit ; à partir de là, la boucle est incrémentale. C'est ce qui rend possibles des centaines de milliers d'itérations en soixante secondes, et c'est la même discipline que la [page théorique sur l'ALNS](/fr/research/build/local-search/local-search-alns/) décrit comme maintenir la destruction à un coût proportionnel au trou, non au plateau. ## Le scoreur est l'unique source de vérité Le score auto-déclaré d'aucun moteur n'est digne de confiance. Le score incrémental de la boucle est un dispositif de performance ; le nombre *publié* est toujours un re-score canonique frais du plateau de sortie, à travers le même scoreur qu'utilisent le site et l'étude DFS (arêtes appariées, non bordurières, adjacences intérieures, comptées vers la droite et vers le bas par cellule). Un test vérifie que le score incrémental et le score canonique concordent après des milliers de poses-et-retraits aléatoires, afin que l'on puisse faire confiance au chemin rapide pour suivre la vérité plutôt que de s'en écarter. ## Les statistiques que l'étude fait ressortir Pour chaque exécution, le moteur enregistre - et les résultats transportent jusqu'à la page : - **score final** : les arêtes canoniquement appariées (sur 480) du meilleur plateau trouvé. - **gain** : le score final moins le score du plateau de départ. Cela isole la contribution propre de la boucle de réparation par rapport à la construction dont elle est partie : une variante qui démarre haut peut n'ajouter que peu et finir tout de même haut, et c'est le gain qui distingue les deux. - **le blocage (dernière itération record vs itérations totales)** : l'itération à laquelle le meilleur global s'est amélioré pour la dernière fois, comparée au nombre d'itérations que le budget a permis. C'est l'axe phare de l'étude : lorsque le premier est très en dessous du second, l'exécution a trouvé sa réponse tôt puis n'a plus rien bougé. - **taux d'acceptation** : la fraction d'itérations conservées par la règle d'acceptation. Un taux proche de zéro signifie que la boucle propose des changements qu'elle rejette presque toujours, souvent le signe qu'elle ré-attaque la même région. - **taille moyenne de destruction** : cellules retirées par itération, afin qu'un opérateur à grand trou ne soit pas comparé en silence à un opérateur à petit trou. - **itérations par seconde** : rapportées par variante et **jamais comparées entre familles**, car une itération exécutant un remplissage exact n'est pas la même unité de travail qu'une itération exécutant un remplissage glouton. - **redémarrages** : perturbations déclenchées, zéro pour une variante sans politique de redémarrage. La page trace aussi une **courbe de convergence** pour quelques variantes représentatives : le meilleur score obtenu jusque-là, échantillonné toutes les deux cents itérations, à mesure qu'une exécution typique progresse. C'est l'image la plus claire du blocage : la courbe monte fortement, puis s'aplatit tandis que le compteur d'itérations continue de grimper. ## Honnêteté sur la vitesse du moteur glouton Comme le moteur MRV de l'étude DFS, la boucle de réparation ici est écrite d'abord pour la clarté. Le remplissage glouton réexamine le réservoir de pièces restantes pour chaque cellule qu'il remplit, plutôt que de maintenir des listes de candidats de façon incrémentale ; ses itérations par seconde sont donc celles de ce moteur au code propre, non le meilleur qu'un noyau de réparation optimisé pourrait atteindre. Le classement par score n'en dépend pas, puisque le débit est un axe distinct jamais mêlé à la comparaison des scores, mais les cadences d'itération doivent être lues comme celles de ce moteur, non comme le plafond de la destruction-réparation. ## Ce que cette étude se garde délibérément d'affirmer Il s'agit d'une étude de la boucle de réparation *nue*, une décision à la fois, à un petit budget fixe. Ce n'est pas le pipeline record : les plateaux qui atteignent le milieu des 450 et au-delà combinent un producteur constructif puissant, des exécutions plus longues, et la réparation comme polissage final, et plusieurs des observations sur les opérateurs se liraient ici différemment sur un plateau proche du record que sur le départ glouton médiocre dont la boucle est issue. Là où un résultat dépend de la qualité du plateau de départ, la page des observations le précise. Le réglage propre de la communauté a par exemple trouvé que les opérateurs guidés par les conflits et par composantes sont précieux précisément sur des plateaux quasi optimaux, où les rares désaccords restants sont la seule chose qu'il reste à corriger - le régime que les courtes exécutions de cette étude n'atteignent jamais. ## Reproductibilité Le moteur, les dix variantes, les résultats par exécution versionnés et les scripts de grille vivent tous sous le [répertoire support](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/repair-study) de l'étude. `just experiments repair-study` reconstruit le moteur et relance toute la grille ; l'exécution est déterministe à une graine fixe, et l'agencement des coins est le seul axe de diversité. ## À lire aussi - [L'étude de la réparation](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/) — La jumelle de l'étude DFS, pour l'autre manière d'attaquer Eternity II : détruire une partie d'un plateau, la reconstruire, garder le changement s'il aide. Une question, posée avec soin. Que rapporte chaque décision de cette boucle : quelle région détruire, comment la reconstruire, quand garder un mouvement, quand redémarrer, et de quel plateau partir ? - [Ce que l'étude de la réparation a montré](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/repair-study/findings/) — Les cinq comparaisons au cœur de l'étude sur la réparation, décortiquées : la destruction aléatoire aveugle l'emporte tandis que tout opérateur ciblant les conflits perd ; la construction fixe le plancher ; le recuit simulé est la règle d'acceptation la plus forte ; et les raffinements astucieux (recharge exacte, redémarrages) ne rapportent rien à ce budget. - [Recherche locale et ALNS](https://eternity2.dev/fr/research/build/local-search/local-search-alns/) — Détruire une partie du plateau, la reconstruire en mieux, et laisser l'algorithme apprendre quelles démolitions rapportent. La recherche à grand voisinage adaptative est le meilleur outil de finition de ce projet, et la démonstration la plus nette du mur où la finition s'arrête. --- # L'échelle de tailles > Un banc qui fait tourner n'importe quel solveur, tel quel, sur des plateaux plantés entièrement résolubles à N = 8, 10, 12, 14, chacun avec un plafond prouvé de 2N(N-1) : la taille d'effondrement d'une méthode se mesure avant de passer des semaines sur le vrai 16×16. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/scaling-ladder/ - Mise à jour: 2026-07-22 - Sujets: structure, backtracking - Reproduire: `just research-scaling-ladder` - Source: Ansótegui et al., la transition de phase des puzzles d'appariement d'arêtes (contexte du seuil de difficulté) — https://doi.org/10.1007/978-3-540-85958-1_42 --- Le vrai 16×16 est un endroit coûteux pour découvrir qu'une méthode ne passe pas à l'échelle. L'échelle de tailles pose d'abord une question moins chère : elle fait tourner n'importe quel solveur, sans le modifier, sur des plateaux plantés entièrement résolubles à N = 8, 10, 12 et 14, chacun avec un plafond prouvé, et lit la taille à laquelle la méthode s'effondre. Les deux solveurs de référence livrés se séparent nettement et se dégradent de façon monotone en montant l'échelle : c'est précisément la lecture que le banc existe pour produire. ## Fonctionnement Chaque barreau est construit à rebours depuis une solution plantée, donc il est résoluble par construction, et sa cible de résolution complète vient gratuitement : une grille N×N compte exactement 2N(N-1) adjacences internes, le plateau planté les apparie toutes, et aucun plateau ne peut faire mieux. Les quatre barreaux portent des plafonds de 112, 180, 264 et 364. Aucun solveur externe n'est requis pour certifier quoi que ce soit ; avant tout solveur, le banc re-score le plateau planté à travers le même scoreur (bordure exclue) que les solveurs affronteront et vérifie qu'il atteint exactement le plafond. Cette assertion est active : un premier brouillon avait placé un petit plateau dans une grille de largeur 16, obtenu 28/60, et s'est fait prendre par elle. Cinq cases de la solution sont épinglées comme indices à la manière du puzzle officiel, chaque solveur reçoit un budget mural fixe de 12 secondes sur un seul cœur, et chaque plateau rendu est re-scoré indépendamment depuis ses arêtes ; l'auto-déclaration du solveur n'est jamais utilisée. Une ligne JSON par (solveur, N, graine) enregistre le score vérifié, le plafond, leur rapport, si la résolution est complète, le nombre de nœuds et un lien vers le plateau. Chaque plateau s'ouvre dans le [visualiseur](/viewer/) : voici un [barreau planté N=8](/viewer/?puzzle=ladder_n8_c22_s1&puzzle_size=8&board_edges=adcaabtdacrbafkcabofabmbaflbaadfcnfatrunrsgrkwisohuwmgvhlqjgdadqfmcaupimgnupikonujvkvrnjjoordadocheaikrhujikokujvvlknqpvopsqdaepehbarglhinwgulsnltnlpkmtspskeaepbidaljqiwvojstivnwhtmjpwstljeaetdhbaqmvhoqwmimrqhqgmpsuqlgtseadgbeaavbaewfabrfafgcafucactcacdaac) et le [meilleur partiel N=14](/viewer/?puzzle=ladder_n14_c22_s5&puzzle_size=14&board_edges=abdaaclbafncadkfabqdafibacufadhcafkdadhfacqdaewcacueaadcducalijunowikwsoqjkwihpjuvjhhnnvkqonhihqqqqiwmsqunumdaenctbajrptwrlrsisrkroipwtrjpjwnlopouvlhvnuqrtvsjgruttjeaftbpbapmnplkwmsiskothitsltjlosovvlvgpvnqhgtosqgkootrgkfaerbwbanslwwnkssghnhiggljmiotjjvmttpmgmhwgmsrvwokhrgpukeafpbiealpuikvwphluvgrslmurrjskutmgsgknmghlkvijhhgiiuhhgfabhescauupswvjuukjvsjikrrwjkokrglqonmollwlmjoiwinwohqjnbaeqcidapgvijirgjsuiisnswlnskhmlqlthottlloptiswownusjhrneaehdgfavtwgrjhtuuwjnkmunqnkmirqtmtitglmpqggwpoqaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaocaeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&hints=56.2-186.0-114.3-53.2-37.0) produit par cette exécution. Les deux solveurs livrés couvrent les deux familles que l'étude originale sépare : un retour arrière en profondeur d'abord qui ne place que des pièces parfaitement concordantes (le membre le plus simple de la famille propagative) et un remplisseur glouton ligne par ligne, sans aucun retour arrière. ## Le résultat Dans l'exécution originale à treize méthodes (13 méthodes × 11 instances × 3 graines = 429 tâches), l'échelle a séparé les familles de solveurs d'un barreau entier : la famille propagative, pilotée par les contraintes, a tenu un rapport parfait de 1.000 jusqu'à N=12 inclus (264 arêtes sur 264), les ordres « bordure d'abord » s'étaient déjà effondrés vers 0.15 à 0.22 à cette taille, et à N=14 toutes les méthodes sont tombées entre 0.055 et 0.157. La reproduction archivée rejoue le banc de bout en bout avec les deux solveurs de référence : > **[Figure]** Attendu vs mesuré (4 barreaux × 8 graines × 2 solveurs, budget mono-cœur de 12 s) — interactive figure. Rendered on the canonical page (link above); not shown in this markdown export. Toute la mécanique se reproduit : le plafond prouvé gratuit, la certification de chaque plateau planté à travers le scoreur même que les solveurs affrontent, le re-score indépendant de chaque plateau rendu, et la dégradation monotone du DFS, parfait à N=8 puis sans aucune résolution complète à N=14, tandis que le glouton ne résout jamais complètement nulle part. La dispersion entre graines est large sur les barreaux hauts (0.216 à 1.0 à N=12, 0.047 à 0.613 à N=14 pour le DFS) ; c'est pour cela que chaque barreau garde 8 graines. ## Ce qui n'en découle pas - **Réussir aux petits N ne prédit rien sur le 16×16.** Les méthodes parfaites à N=12 sont presque sans valeur un barreau plus haut ; le livrable est la courbe de dégradation, jamais un classement à une taille donnée. Pour l'état de l'instance réelle, voir [la page des records](/fr/research/records/). - **Des échelles issues de générateurs différents ne sont pas interchangeables.** La profondeur de l'effondrement dépend du profil d'instance. Les barreaux originaux reprenaient le profil de couleurs du vrai puzzle (22 couleurs intérieures, 5 couleurs rares confinées à l'anneau adjacent au cadre) et comptaient jusqu'à 10 à 11 pièces dupliquées à N=14 ; le générateur du kit ne produit aucun doublon et pas d'anneau de couleurs rares, et l'effondrement à N=14 y est visiblement moins profond (des partiels vers 0.6 contre un plancher de 0.157 dans la grille originale). Les formes de courbes se transfèrent ; les points de rupture exacts, non. - **Qu'un solveur de référence faible échoue sur un barreau ne réfute rien.** Les lignes parfaites jusqu'à N=12 appartiennent à des solveurs propagatifs précis pas encore portés dans le kit ; un solveur sous-dimensionné ne peut que rester en dessous. ## Reproduire `just research-scaling-ladder` reconstruit les quatre barreaux depuis le générateur à graines (un binaire par barreau, le moteur partagé fixant la taille du plateau à la compilation) et relance les deux solveurs au budget de 12 secondes, en écrivant une ligne JSONL par exécution plus un recensement des barreaux avec le lien visualiseur de chaque plateau planté. Cela reproduit la mécanique du banc et la forme des courbes ; une égalité case par case avec la table originale à treize méthodes exige le jeu d'instances original archivé et le portage du registre de solveurs, comme le précise le plan de reproduction. ## À lire aussi - [Benchmark mono-cœur](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/) — Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [Cette instance est-elle NP-complète, et comment l'encoder ?](https://eternity2.dev/fr/research/why/how-hard-is-this-instance/) — L'appariement de bords est NP-complet en tant que famille, mais cela ne dit rien d'un plateau 16×16 fixé : une instance isolée est une constante, pas un problème. Ce qui est vrai, c'est la dureté au pire cas de la famille et la dureté empirique de cette instance, et comment écrire le puzzle pour un solveur SAT, de couverture exacte ou de PLNE, avec de petits croquis détaillés. Une mesure sur plateaux plantés chiffre le choix de la formulation : une falaise de résolubilité qu'un paradigme de recherche heurte et qu'un autre franchit, et qui bouge avec le nombre de couleurs. - [Les benchmarks de la communauté](https://eternity2.dev/fr/research/build/benchmarks/) — Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. --- # Benchmark mono-cœur > Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/ - Mise à jour: 2026-07-13 - Sujets: speed, construction, backtracking - Reproduire: `just experiments single-core-benchmark` - Source: Moteur exécutable + résultats commités + scripts (le répertoire de support de cette expérience) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark --- Donnez à chaque solveur le même budget, un cœur et une minute : lequel l'emporte ? La réponse renverse l'intuition évidente. Plusieurs solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, ont chacun été exécutés une fois sur dix variantes à coins épinglés du casse-tête officiel, en mono-thread, 60 secondes par exécution. Chaque plateau a été re-noté par un unique scoreur canonique ; aucun score auto-déclaré par un moteur n'est digne de confiance. Le score maximal possible est 480. > **Chaque moteur ici est notre code** > > `blackwood_style` et `verhaard_style` sont **nos implémentations réécrites de zéro** des algorithmes publiés par Joshua Blackwood et Louis Verhaard, et non les programmes propres des auteurs. Le `eii` de Verhaard n'a jamais été diffusé que sous forme de binaire Win32 ; une ré-implémentation (dont les constantes ont été récupérées depuis `eii.exe`) est donc le seul moyen de l'exécuter. Le vrai C# de Blackwood, lui, *est* [public](https://github.com/jblackwood345/EternityII_Solver), mais il code en dur ses 256 pièces et son nombre de threads : il ne peut donc ni lire les variantes de cette grille ni être épinglé sur un seul cœur sans être modifié. Les scores présentés ici mesurent notre lecture de chaque algorithme, non l'ingénierie des auteurs, et ne doivent pas être cités comme « Blackwood obtient N ». Le classement ci-dessous montre les méthodes qui rivalisent au score. Une seconde famille, les préréglages CSP (un moteur d'arc-cohérence exécuté sous une douzaine de réglages d'ordonnancement), relève d'une catégorie différente : son meilleur préréglage atteint environ 183, moins de la moitié du score d'un prétendant, il ne mérite donc aucune ligne au classement. Ce balayage de préréglages est une étude à part entière, sur sa [propre page](/fr/research/lab/experiments/single-core-benchmark/csp-presets/). ## Ce qu'achète une minute d'un cœur Les deux backtrackers record dominent ce budget. Notre moteur de style Verhaard atteint une moyenne de **440,8** (meilleur 451) et notre moteur de style Blackwood **436,4** (meilleur 440), tous deux explorant de 20 à 40 millions de nœuds de recherche par seconde. Rien d'autre n'en approche : le DFS naïf se pose à **365,6**, et le meilleur préréglage CSP à environ **183**. L'écart entre ces deux groupes est le constat. Les quatre familles voient le même casse-tête et les mêmes 60 secondes, et elles terminent séparées de 250 points. Ce qui les distingue n'est pas la vitesse : les moteurs CSP sont trois ordres de grandeur plus lents par nœud que les backtrackers et battent tout de même le DFS naïf sur les variantes favorables, car chaque nœud est élagué plutôt que simplement visité. Le nombre de nœuds et le score ne sont pas le même axe. Ce que cette grille ne peut pas vous dire, c'est où se situe le plafond. Le meilleur plateau ici (451) reste à 13 points du record 5 indices de la communauté, 464, et la moyenne du meilleur moteur se situe à environ 24 points en dessous ; les records n'ont pas été établis en une minute, ils sont venus de fermes de calcul et de mois d'effort. On mesure ici l'efficacité par cœur à budget faible et fixe, rien de plus. > **[Figure]** Le classement : score moyen sur dix variantes de coins, mono-cœur, 60 s — interactive: BenchmarkLeaderboard. Rendered on the canonical page (link above); not shown in this markdown export. ## Lire le tableau Les deux backtrackers sont en tête de ce tableau et ils s'y maintiennent avec stabilité : le moteur de style Verhaard couvre 437 à 451 sur les dix variantes, le moteur de style Blackwood 431 à 440. La référence naïve est le plancher : un 365 rapide et bourré de déchets qui montre à quoi ressemble un simple décompte d'arêtes appariées sans aucune qualité de plateau. Les unités de débit diffèrent selon la famille et ne sont jamais comparées entre elles. Les backtrackers comptent les nœuds de recherche par seconde, les moteurs CSP de même mais entre 5 et 10 milliers, car chacun de leurs nœuds exécute une arc-cohérence complète. La famille CSP troque le débit contre l'élagage, ce qui explique qu'elle explore bien moins de nœuds tout en battant le DFS naïf sur les bonnes variantes. ## Ce que fait chaque prétendant - **Verhaard et Blackwood (backtrackers, rangs 1 et 2).** DFS à rupture contrôlée par la profondeur, à 20 à 40 millions de nœuds par seconde. Ils poussent jusqu'à 437 à 451 mais heurtent un mur : la fin de partie exige bien plus de calcul que ne le permettent 60 secondes. Blackwood a trouvé son 470 après environ un mois sur un seul PC, et l'a qualifié de « coup de chance » ([message 10194](https://groups.io/g/eternity2/message/10194)). - **DFS naïf (la référence).** Remplit tout le plateau en autorisant toutes les ruptures. En ordre ligne par ligne (`anjou-naive_rowmajor`) il atteint un décompte d'arêtes appariées élevé (365) mais un plateau de faible qualité, criblé de ruptures. Rapide, et sans valeur. Il siège sur le tableau comme un plancher : le nombre qu'une méthode doit franchir pour valoir quelque chose. (La sensibilité du DFS naïf à l'ordre de visite, et la raison pour laquelle la variante en spirale s'effondre à 78, figurent sur la [page des préréglages CSP](/fr/research/lab/experiments/single-core-benchmark/csp-presets/) aux côtés des autres ablations du même moteur.) ## Où se situent ces chiffres Cette grille plafonne chaque moteur à un cœur pendant 60 secondes, bien en deçà du calcul qui a produit les records ci-dessous. Elle mesure l'efficacité par cœur et la qualité heuristique, non le score maximal atteignable. Un moteur qui se classe bien ici atteint de bons plateaux à moindre coût ; les chiffres record exigent de nombreux cœurs multipliés par des heures. Chaque variante ici épingle les 5 indices officiels (plus 3 coins, soit 8 amorces au total), si bien que le plafond pertinent est le **record 5 indices de la communauté, 464**, et non le 470 tous indices (qui utilise plus que les 5 indices). C'est ce 464 que marque la ligne pointillée du classement. | référence | score | conditions | |:--|--:|:--| | Record communautaire 5 indices | 464 | Benjamin Riotte, juillet 2026 (mêmes 5 indices que ces variantes épinglent) | | Meilleur de cette grille (style Verhaard) | 451 | un cœur, 60 s (moyenne 440,8 sur 10 variantes) | | Style Blackwood dans cette grille | 440 | un cœur, 60 s (moyenne 436,4 sur 10 variantes) | | Plafond communautaire tous indices | 470 | Blackwood, ~1 mois sur un seul PC, utilise plus que 5 indices | ## Méthode et reproductibilité Chacune des dix variantes est le casse-tête officiel augmenté de trois cellules de coin épinglées (des dispositions distinctes des pièces de coin) : les dix partagent donc le jeu de 256 pièces et les 5 amorces d'indices mais diffèrent par trois contraintes de coin. Elles sont émises à la fois en JSON au schéma du site (pour les moteurs natifs) et en CSV (pour les moteurs autonomes) depuis un unique générateur, de sorte que chaque algorithme voit des instances identiques. Une exécution par casse-tête, graine fixe ; la disposition des coins est le seul axe de diversité. Chaque exécution émet une `.url` bucas, et le score est le décompte canonique d'arêtes appariées produit par le même scoreur, jamais l'auto-déclaration du moteur. Il n'y a eu aucun échec sur l'ensemble des 150 exécutions. Chaque moteur de la grille est notre propre code open source et s'exécute depuis ce dépôt, y compris les deux écrits à partir des algorithmes publiés par la communauté ; aucun solveur tiers n'est intégré ici. La grille les mesure tous ; le classement ci-dessus ne montre que les cinq qui rivalisent au score, et la [page des préréglages CSP](/fr/research/lab/experiments/single-core-benchmark/csp-presets/) montre le reste. L'espace de travail des crates, les dix variantes, les résultats commités par exécution et les scripts de la grille résident tous dans le [répertoire de support](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark) de l'expérience, et `just experiments single-core-benchmark` compile les moteurs et relance la grille entière. La famille native (le naïf et les préréglages CSP) est un unique binaire sélectionné par préréglage ; les deux backtrackers sont un binaire chacun, pilotés par un petit wrapper. Tous deux parlent le même contrat casse-tête-en-entrée, url-bucas-en-sortie, et chaque plateau est re-noté par l'unique scoreur canonique. ## Constats connexes Le profilage a placé 96,6 pour cent du temps de la famille CSP dans une seule boucle AC-3 lourdement pré-optimisée. Ce moteur est déjà à son plafond de performance ; les vitesses du benchmark sont ses vraies vitesses, non un écart d'implémentation. Par ailleurs, les constantes Blackwood de la communauté ne se transfèrent pas d'un étiquetage de couleurs à l'autre : ses couleurs privilégiées publiées ont obtenu 387 dans notre étiquetage contre 435 pour un ré-ajustement, un écart de 48 points que notre Blackwood comble en ré-ajustant seulement les ID de couleur relatifs à l'étiquetage tout en respectant chaque élément structurel de la spécification publiée. ## Travaux ouverts La grille exécute nos implémentations. Deux des trois moteurs record de la communauté peuvent en principe être exécutés directement, et c'est la prochaine mesure évidente : - **Le générateur en C de Peter McGavin.** Il en a posté le code source sur la liste en janvier 2026 sous le nom `genbody71.zip` ([message 11749](https://groups.io/g/eternity2/message/11749)). Il compile sur Apple silicon avec `clang` et sa passe de génération émet un `body.c` de 10 363 lignes spécialisé pour un seul casse-tête. C'est le moteur le plus rapide que la communauté ait mesuré, à 295 M de placements/s sur le CPU de Joe ([message 11750](https://groups.io/g/eternity2/message/11750)), et il est absent de cette grille. - **Le C# de Joshua Blackwood.** [Public et sous GPL-3.0](https://github.com/jblackwood345/EternityII_Solver) ; il compile sans modification sur .NET 8. Mais il code en dur ses 256 pièces dans `Util.cs`, fixe `number_virtual_cores = 64`, et ne prend aucun argument : l'épingler sur un seul cœur ou lui fournir les variantes de cette grille suppose de modifier son code source, moment où l'artefact n'est plus purement le sien. L'exécuter tel que publié, sur le casse-tête brut, est la forme fidèle de cette mesure. - **Le `eii` de Louis Verhaard** ne peut pas du tout être exécuté : le téléchargement depuis son propre site fournit `eii.exe` et aucun code source, raison pour laquelle notre moteur le reconstruit à partir du binaire. Aucun de ces moteurs n'est intégré à ce dépôt ; tous deux sont récupérés et exécutés localement au moment de la mesure. ## Pages de cette section - [Presets CSP, à la mesure](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/csp-presets/) — Un seul moteur de propagation de contraintes, exécuté sous une douzaine de presets d'ordonnancement et de propagateurs, sur les dix mêmes variantes à coins fixés que le classement. Une étude de ce qu'apporte chaque réglage, tenue à l'écart du classement principal parce que le meilleur preset atteint moins de la moitié du score d'un prétendant. ## À lire aussi - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. - [Recherche en faisceau](https://eternity2.dev/fr/research/build/construct/beam-search/) — Maintenir en vie les K plaquettes partielles les plus prometteuses à la fois et les faire croître case par case. La recherche en faisceau est le moteur des constructeurs ex nihilo de ce projet, et une illustration limpide des raisons pour lesquelles la largeur seule s'enlise dans les profondeurs de l'intérieur. --- # Presets CSP, à la mesure > Un seul moteur de propagation de contraintes, exécuté sous une douzaine de presets d'ordonnancement et de propagateurs, sur les dix mêmes variantes à coins fixés que le classement. Une étude de ce qu'apporte chaque réglage, tenue à l'écart du classement principal parce que le meilleur preset atteint moins de la moitié du score d'un prétendant. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/csp-presets/ - Mise à jour: 2026-07-15 - Sujets: backtracking, search-space - Reproduire: `just experiments single-core-benchmark` - Source: Moteur exécutable + résultats versionnés + scripts (le répertoire support de cette expérience) — https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark --- Le classement du [benchmark mono-cœur](/fr/research/lab/experiments/single-core-benchmark/) montre les méthodes qui rivalisent sur le score. Cette page montre le reste : une douzaine de presets d'un seul moteur de satisfaction de contraintes, plus le DFS naïf dans son ordre de visite le plus faible. Ce ne sont pas une douzaine de solveurs. C'est un unique cœur d'arc-cohérence coiffé de têtes différentes, tenu pour que le coût exact de chaque technique classique se lise sur un nombre plutôt que se discute. > **[Figure]** Presets CSP : score moyen sur dix variantes à coins, mono-cœur, 60 s — interactive: BenchmarkLeaderboard. Rendered on the canonical page (link above); not shown in this markdown export. ## Ce qu'apporte chaque réglage Les presets font varier deux choses : l'ordre dans lequel le moteur affecte les cellules, et l'intensité de la propagation avant qu'il ne s'engage. À puzzle et budget fixés, l'écart de score entre deux presets est la valeur de ce seul réglage. - **L'ordonnancement par valeur la moins contraignante aide.** `anjou-gacolor_ac3_lcv` atteint une moyenne de 114 contre 76 pour le simple `anjou-gacolor_ac3` : choisir la valeur qui élimine le moins de voisins vaut ici environ 38 points. - **Certains réglages sont inertes à cette profondeur.** Trois presets (`anjou-gacolor_ac3`, `anjou-gacolor_ac3_ns1`, `anjou-verhaard_preferred`) ont produit des plateaux identiques au bit près sur ce puzzle. NS-1 et l'ordonnancement préféré n'ajoutent rien en 60 secondes : le moteur ne descend jamais assez profond pour qu'ils mordent. - **L'ordonnancement bord d'abord est le preset le plus fort.** `anjou-border_first_lcv` et `anjou-rare_color_first` dominent la campagne à environ 183, en fixant le cadre sur-contraint avant l'intérieur libre. Cela reste moins de la moitié du score d'un prétendant. ## Pourquoi aucun d'eux ne rivalise Chaque preset est bimodal. Sur une disposition de coins favorable, la recherche par arc-cohérence atteint 340 à 349 ; sur une disposition hostile, elle s'effondre à environ 55, piégée dans un mauvais bassin dont elle ne peut sortir en 60 secondes. La moyenne reste basse parce que les mauvais coins la tirent vers le bas, et aucun réglage d'ordonnancement ne corrige le problème du bassin. Voilà la vraie histoire de cette famille : la propagation rend chaque nœud bien élagué mais coûteux, si bien que la recherche est forte là où l'instance est clémente et impuissante là où elle ne l'est pas. Les moteurs constructifs du classement n'entrent jamais dans ce piège, et c'est pourquoi un preset à 183 se trouve sur une page différente des prétendants du classement, qui plafonnent à 451. ## Le DFS naïf est ici aussi, pour une seule raison La recherche en profondeur naïve, toutes ruptures autorisées, n'est pas un preset CSP, mais son ordre de visite relève de la même leçon. En ordre ligne par ligne (`anjou-naive_rowmajor`, présent au classement comme référence) il atteint 365 ; le même DFS en ordre de visite en spirale (`anjou-naive_spiral`) s'effondre à une moyenne de 78. Le seul choix de l'ordre de visite coûte à la recherche naïve près de 290 points, la même sensibilité à l'ordonnancement que montrent les presets CSP, à plus grande échelle. ## Méthode et reproductibilité Ces presets ont tourné dans la même grille que le classement : dix variantes du puzzle officiel, chacune avec trois cellules de coin fixées, mono-cœur, 60 secondes, graine fixe, une exécution par variante. Chaque plateau est re-scoré par l'unique scoreur canonique à arêtes appariées, jamais par l'auto-déclaration du moteur. Le moteur, les dix variantes, les résultats versionnés par exécution et les scripts vivent sous le [répertoire support](https://github.com/raphael-anjou/eternity2/tree/main/research/experiments/single-core-benchmark) de l'expérience, et `just experiments single-core-benchmark` rejoue la grille entière, prétendants et presets ensemble. ## À lire aussi - [Benchmark mono-cœur](https://eternity2.dev/fr/research/lab/experiments/single-core-benchmark/) — Quinze solveurs, les nôtres et nos implémentations des deux backtrackers record de la communauté, chacun exécuté une fois sur dix variantes à coins épinglés du casse-tête officiel, un seul cœur, 60 secondes par exécution. Le constat : le nombre de nœuds n'est pas le score. - [La cohérence d'arc, à partir d'AC-3](https://eternity2.dev/fr/research/build/reduce/arc-consistency/) — Le forward checking regarde un coup à l'avance ; la cohérence d'arc oblige la liste de candidats de chaque case à se défendre contre celle de chaque voisine, jusqu'à un point fixe. AC-3 de Mackworth, les raffinements optimaux qui ont suivi, ce que toute cette famille a réellement mesuré sur ce casse-tête, et où elle devient incorrecte. - [Ordres de remplissage](https://eternity2.dev/fr/research/build/backtracking/fill-order/) — L'ordre dans lequel un algorithme de retour arrière visite les 256 cases est son unique liberté : il ne coûte rien à l'exécution et fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur. Vingt ans de science communautaire, des guerres fixe-contre-dynamique aux courses de stratégies, jusqu'au carré magique 10×16 et à la recherche en peigne de Verhaard, répondent tous à la même question : quel chemin à travers le plateau est le moins coûteux ? --- # Problèmes ouverts > La frontière ouverte d'Eternity II réunie au même endroit : chaque angle qui vaut encore une tentative, le mur qu'il attaque, ce qui a déjà été essayé et où cela s'est arrêté, et s'il s'agit d'une cible abordable pour un débutant ou d'un objectif difficile et bien cartographié. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/open-problems/ - Mise à jour: 2026-07-21 - Source: Archive de la liste de diffusion eternity2 (groups.io) : où les cibles ouvertes sont annoncées et discutées — https://groups.io/g/eternity2 --- Voici le tableau des angles ouverts : une ligne par direction qui mérite encore une tentative. Chaque entrée pose la question en une ligne, nomme le mur qu'elle attaque (issu de [pourquoi c'est difficile](/fr/research/why/)), renvoie à ce qui a déjà été essayé et à l'endroit où cela s'est arrêté (dans la [carte murs-méthodes](/fr/research/why/walls-and-methods/) et les [impasses](/fr/research/build/dead-ends/)), et indique son abordabilité. Les étiquettes disent ce qu'elles disent : **abordable pour un débutant** désigne une cible qu'on peut prendre sans dix ans de contexte ; **difficile, bien cartographié** désigne une cible que beaucoup de tentatives solides ont balisée sans qu'aucune ne l'ait franchie ; **sans prise en charge** désigne un angle sur lequel personne ne travaille activement, ce qui est distinct d'un angle qui a été attaqué puis a tenu. Pour l'état de l'art, le score vit sur la page [records](/fr/research/records/) ; cette page ne montre que ce qui reste ouvert. ## L'écart de 470 à 480 > **Une méthode peut-elle franchir le plafond de 470 jusqu'à un 480 complet ?** > > La piste canonique. Le meilleur plateau ne respectant que l'indice de départ obligatoire est à 470/480 depuis que la communauté l'a atteint, et un 480 conçu est acquis : l'éditeur a construit le puzzle à partir d'une solution, donc un plateau parfait existe et seul son emplacement reste ouvert. **Mur.** [Rigidité](/fr/research/why/rigidity-wall/) : les plateaux records sont des îles localement figées, et les dix arêtes manquantes se trouvent de l'autre côté de [tous les murs structurels à la fois](/fr/research/why/walls-and-methods/). **Essayé, et où cela s'est arrêté.** Toute méthode de la [carte murs-méthodes](/fr/research/why/walls-and-methods/) finit contre la rigidité ; les constructions depuis zéro et depuis le corpus plafonnent entre 458 et 463, et aucune ne franchit le plafond. La force de calcul brute ne le comble pas non plus, ce qui est consigné sous [jeter plus de calcul contre le mur](/fr/research/build/dead-ends/). **Étiquette.** Difficile, bien cartographié. C'est le sommet du puzzle entier : on sait beaucoup de choses sur pourquoi il résiste, ce qui est précisément la raison pour laquelle un franchissement inédit ferait la une. ## La cible stricte à cinq indices, de 464 à 465 > **Un plateau honorant les cinq indices officiels peut-il dépasser 464 ?** > > La ligne stricte à cinq indices est suivie séparément de la ligne ouverte à 470, car [l'essentiel des progrès sur le record ouvert s'est fait sans les indices](/fr/research/build/clue-puzzles/). Le meilleur plateau respectant les cinq placements est à 464. **Mur.** [Rigidité](/fr/research/why/rigidity-wall/) de nouveau, plus les placements d'indices qui rétrécissent la région atteignable : moins de plateaux satisfont les cinq, donc la botte de foin est plus petite, mais l'aiguille aussi. **Essayé, et où cela s'est arrêté.** Le 464 est la marque courante de la ligne stricte sur la page [puzzles à indices](/fr/research/build/clue-puzzles/) ; les constructions strictes et re-compressions du projet atteignent la classe des 460 sans la dépasser, comme le montre la [carte murs-méthodes](/fr/research/why/walls-and-methods/). **Étiquette.** Difficile, bien cartographié, mais un pas plus court que l'écart de 470 à 480 : 464 à 465, c'est une seule arête, sur une ligne où la région atteignable est plus resserrée et donc plus facile à raisonner que le record ouvert. ## Le 10x10 sans indice set_2 de Brendan Owen > **Résoudre set_2, le 10x10 sans indice jamais résolu.** > > Brendan Owen a publié une paire de 10x10 générés sans indice avec leurs statistiques. L'un (set_1) est tombé ; l'autre (set_2) n'a jamais été résolu et reste le prochain échelon convenu par la communauté sous le 16x16 complet. **Mur.** La même difficulté d'appariement d'arêtes que le puzzle complet, à une taille qu'une seule machine peut réellement terminer. Set_1 a demandé une recherche vaste mais bornée, donc set_2 est une cible d'ingénierie de recherche, pas une cible structurelle. **Essayé, et où cela s'est arrêté.** L'histoire complète est sur la page [benchmarks](/fr/research/build/benchmarks/#les-1010-de-brendan--lun-est-tombé-lautre-tient-encore) : set_1 a été résolu, les statistiques de set_2 sont connues, et il [tient toujours](/fr/research/build/benchmarks/#les-1010-de-brendan--lun-est-tombé-lautre-tient-encore). **Étiquette.** Abordable pour un débutant. C'est la seule cible ouverte dimensionnée pour une machine personnelle et un backtracker bien réglé plutôt qu'une grappe de calcul, donc la première vraie tentative recommandée. ## Franchir un bassin de rigidité > **Existe-t-il un chemin local d'un bassin record à un autre ?** > > Chaque plateau record se trouve dans un bassin que des preuves MIP montrent localement optimal jusqu'à un halo de plusieurs cellules. La question ouverte est de savoir si une suite de petits coups légaux atteint un autre bassin. **Mur.** [Rigidité](/fr/research/why/rigidity-wall/) sous sa forme la plus tranchée, et [pourquoi le saut de bassin paraît impossible](/fr/research/why/sigma-cycles/) : le pas d'un grand plateau vers un meilleur est un unique échange géant et indivisible, sans gradient à suivre. **Essayé, et où cela s'est arrêté.** Le théorème de rigidité consigne des preuves MIP d'optimalité de halo sur plusieurs bassins, et la recherche d'une courte chaîne d'évasion entre bassins a échoué pour une raison structurelle exposée sur [pourquoi le saut de bassin paraît impossible](/fr/research/why/sigma-cycles/). L'entrée [recombiner deux bons plateaux](/fr/research/build/dead-ends/) est le même mur vu du côté du croisement. **Étiquette.** Difficile, bien cartographié. Un seul coup de franchissement, ou une preuve qu'aucun n'existe, changerait la façon dont on juge toute méthode de recherche locale. ## Le mur mémoire du meet-in-the-middle > **Les deux moitiés d'une recherche par meet-in-the-middle peuvent-elles se rejoindre à taille réelle ?** > > Faire se rejoindre deux recherches partielles au milieu est complet en principe, mais le nombre de plateaux partiels à stocker croît d'environ un facteur vingt par erreur d'appariement supplémentaire tolérée, si bien que les moitiés cessent de se rejoindre bien avant le 16x16 complet. **Mur.** Le coût de l'exactitude mesuré directement : l'approche [meet-in-the-middle](/fr/research/build/exact/meet-in-the-middle/) est exacte, mais sa mémoire dépasse ce que toute machine peut contenir. **Essayé, et où cela s'est arrêté.** BANDSAW a résolu une bande de fin de partie à l'optimalité prouvée et, ce faisant, a mesuré la croissance d'environ un facteur vingt par erreur des deux côtés, donc se rejoindre au milieu cesse de payer à taille réelle ; ce résultat est la [ligne BANDSAW](/fr/research/why/walls-and-methods/) de la carte. Une meilleure représentation, ou une rencontre avec perte qui reste saine, est le levier ouvert. **Étiquette.** Difficile, bien cartographié. Le mur est ici quantifié, donc le progrès est mesurable : tout encodage qui abaisse le facteur de croissance par erreur est un gain réel, même sans résolution complète. ## Un axe de diversité au-delà du parallel tempering > **Existe-t-il un mécanisme de recherche qui trouve de nouveaux bassins de façon fiable, au-delà du parallel tempering ?** > > Presque toute méthode redécouvre la même poignée de bassins. Dans un balayage complet des méthodes, seul le parallel tempering a produit de façon fiable de nouveaux bassins, et même lui plafonne vite. **Mur.** [Rigidité](/fr/research/why/rigidity-wall/) vue comme un goulot de diversité : la contrainte n'est pas le score qu'une méthode atteint mais le nombre de bassins distincts qu'elle sait trouver, et l'arsenal standard en trouve trop peu. **Essayé, et où cela s'est arrêté.** L'étude de diversité est écrite sur la [carte murs-méthodes](/fr/research/why/walls-and-methods/) : la recherche locale adaptative, le placement en serpent et le haut de la distribution d'un générateur entraîné retombent tous dans les bassins connus, et seul le parallel tempering s'en échappe de façon fiable. [Générer des plateaux avec un transformeur](/fr/research/build/dead-ends/) est l'une des tentatives de diversité qui n'ont pas tenu. **Étiquette.** Sans prise en charge, et ouvert. Contrairement aux cibles cartographiées ci-dessus, celle-ci n'a pas de liste d'attaques balisée à battre : un mécanisme de diversité vraiment neuf est une idée que personne n'a encore plantée, ce qui en fait l'entrée la plus spéculative et la moins contrainte par les travaux antérieurs. ## La rigidité locale est-elle une conséquence de l'effondrement de distinction de la loi d'aire ? > **Les plateaux records gèlent-ils parce que les partiels distincts s'effondrent, ou est-ce une coïncidence d'échelle ?** > > Les plus petits mouvements qui séparent les meilleurs plateaux connus et l'échelle à laquelle les plateaux partiels réellement distincts s'effondrent sont tous deux un patch de quelques centaines de cases. La question ouverte est de savoir si c'est un lien causal, la rigidité découlant de la loi d'aire, ou deux faits indépendants partageant par hasard une échelle de longueur. **Mur.** [Rigidité](/fr/research/why/rigidity-wall/) et [la loi d'aire](/fr/research/why/entropy-area-law/). La rigidité est établie de manière indépendante, par des preuves MIP d'optimalité de halo et un halo SAT versé ; la loi d'aire est une estimation de distinction. Réduire l'une à l'autre les relierait, mais rien sur le site ne le dérive. **Essayé, et où cela s'est arrêté.** La [page de la loi d'aire](/fr/research/why/entropy-area-law/) observe l'échelle partagée et renvoie à [pourquoi le saut de bassin semble impossible](/fr/research/why/sigma-cycles/) ; elle ne prétend pas que la rigidité est causée par l'effondrement. Le résultat de rigidité est exact et région par région, et tient seul sans invoquer la loi d'aire. Aucune page n'affirme le pont causal, ce qui est justement pourquoi il figure ici comme question. **Étiquette.** Difficile, bien cartographié. Les deux extrémités sont parmi les murs les plus étudiés de la section ; la part ouverte est l'arête entre eux, et la trancher dans un sens ou l'autre reformulerait la lecture des deux murs. ## Le pic de difficulté produit-il le profil de branchement d'aucun coup forcé ? > **Le facteur de branchement élevé est-il imposé par la position au pic à une solution ?** > > Chaque case intérieure conserve 73 à 137 pièces légales, et le puzzle se situe à la transition de phase d'environ une solution attendue. Les deux sont regroupés sous « rien de local à élaguer », mais aucune dérivation ne lie le décompte de branchement à la position à environ 17 couleurs intérieures. **Mur.** [Aucun coup forcé](/fr/research/why/no-forced-moves/) et [le pic de difficulté](/fr/research/why/phase-transition/). Le décompte de branchement est un compte de candidats par case sur le jeu de pièces ; le pic est un énoncé sur le nombre de solutions à 17 couleurs. Un puzzle pourrait en principe avoir l'un sans l'autre. **Essayé, et où cela s'est arrêté.** [Élagage contre vitesse](/fr/research/why/prune-vs-speed/) et la [carte mur-méthode](/fr/research/why/walls-and-methods/) regroupent les deux murs sous le même thème, qu'il n'y a rien de local à élaguer, ce qui est une union thématique et non une affirmation causale. Aucune page ne dérive le profil de branchement du décompte de couleurs. **Étiquette.** Difficile, bien cartographié. Les deux murs sont chacun mesurés exactement ; la pièce manquante est la dérivation qui les relie, laquelle transformerait un thème partagé en mécanisme. ## La géométrie des sigma-cycles plafonne-t-elle la recherche constructive, pas seulement la réparation locale ? > **Le mur des sigma-cycles est-il la raison pour laquelle les producteurs beam et DFS saturent aussi, ou seulement la recherche locale ?** > > Le mouvement entre deux plateaux records est un cycle indivisible de nombreuses cases, et chaque préfixe propre score moins ; cela montre pourquoi la réparation locale ne peut franchir entre bassins. La question ouverte est de savoir si la même géométrie plafonne les producteurs DFS et beam constructifs, qui saturent entre 458 et 463 pour des raisons calculées seulement entre plateaux finis, pas dans l'arbre de recherche. **Mur.** [Sigma-cycles](/fr/research/why/sigma-cycles/) et [rigidité](/fr/research/why/rigidity-wall/), vus sur l'axe de diversité. Le résultat des sigma-cycles est un énoncé exact sur chaque paire de planches embarquées, mais il est calculé entre plateaux records finis, pas sur l'arbre de recherche constructif qui les produit. **Essayé, et où cela s'est arrêté.** La [carte mur-méthode](/fr/research/why/walls-and-methods/) documente que les producteurs à partir de zéro et beam saturent comme les autres, et l'enquête de diversité a trouvé que l'arsenal standard redécouvre sans cesse les mêmes bassins. Étendre le mécanisme des sigma-cycles pour expliquer ce plafond constructif, plutôt que seulement celui de la réparation locale, n'est pas prouvé et n'est affirmé nulle part sur le site. **Étiquette.** Difficile, bien cartographié, et proche de la question de diversité ci-dessus : une preuve que la même géométrie de cycle régit la saturation constructive unifierait deux plafonds observés indépendamment. ## D'où viennent ces problèmes, et où en écrire un Chaque affirmation ci-dessus s'appuie sur une page déjà présente sur ce wiki : les murs dans [pourquoi c'est difficile](/fr/research/why/), les tentatives arrêtées dans la [carte murs-méthodes](/fr/research/why/walls-and-methods/) et les [impasses](/fr/research/build/dead-ends/), les cibles de référence sur la page [benchmarks](/fr/research/build/benchmarks/). Si vous en prenez une et qu'elle bouge, [le carnet est ouvert](/fr/research/contribute/) et il y a une place pour le compte rendu. ## À lire aussi - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Quel mur arrête quelle méthode](https://eternity2.dev/fr/research/why/walls-and-methods/) — La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Les benchmarks de la communauté](https://eternity2.dev/fr/research/build/benchmarks/) — Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. - [Rendez-vous au milieu](https://eternity2.dev/fr/research/build/exact/meet-in-the-middle/) — Énumérer deux moitiés d'un problème et les recoller sur une interface partagée, en échangeant de la mémoire contre un exposant divisé par deux. L'astuce classique de Horowitz–Sahni, ce qu'elle donne sur des bandes du plateau, et ce que l'expérience BANDSAW de ce projet a mesuré, y compris la méthode unilatérale qui l'a battue. - [Contribuez vos recherches](https://eternity2.dev/fr/research/contribute/) — Ce wiki est le foyer de recherche de la communauté, et il y a de la place pour votre travail. Trois façons de le faire publier, du message sur la liste de diffusion à la pull request, plus le petit jeu de règles maison qui garde chaque page digne de confiance. --- # Articles > La littérature académique sur Eternity II et les casse-têtes à raccordement d'arêtes, tirée des notes de recherche du projet et de la liste de lectures de la communauté, classée selon l'utilité réelle de chaque article lorsqu'on cherche à écrire un solveur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/papers/ - Mise à jour: 2026-07-15 - Sujets: exact-methods, search-space --- En résumé : les résultats de complexité expliquent pourquoi le problème est difficile, les articles SAT/CSP montrent pourquoi les solveurs génériques butent sur un mur, et ce sont les articles sur la propagation de contraintes et les grands voisinages dont les idées se retrouvent dans les solveurs les plus performants. > **[Interactive: PapersView]** Rendered on the canonical page (link above); not shown in this markdown export. --- # Le who's who de la recherche sur E2 > Deux décennies de recherche sur Eternity II ont été menées par des personnes identifiées, sur une liste de diffusion. Cette page en est la galerie : qui elles sont, ce que chacune a apporté, et où le lire dans leurs propres mots. Un remerciement autant qu'un index. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/people/ - Mise à jour: 2026-07-02 - Source: Brendan Owen établit le partage 17+5 comme le puzzle le plus difficile possible (message groups.io 1947) — https://groups.io/g/eternity2/message/1947 - Source: Le récit à la première personne de Louis Verhaard sur le 467 : « c'est mon programme qui a fait le travail » (message groups.io 6891) — https://groups.io/g/eternity2/message/6891 - Source: Peter McGavin résout le benchmark 10×10 de Brendan Owen (message groups.io 9686) — https://groups.io/g/eternity2/message/9686 - Source: Le 470 de Joshua Blackwood, le record en vigueur (message groups.io 10117) — https://groups.io/g/eternity2/message/10117 - Source: Al Hopfer énonce l'équilibre de bordure NS-1 (message groups.io 10754) — https://groups.io/g/eternity2/message/10754 - Source: Brendan Owen revient sur la liste après quatorze ans (message groups.io 11500) — https://groups.io/g/eternity2/message/11500 --- Les [pages d'histoire](/fr/research/community/hunt/) racontent l'aventure de la communauté dans l'ordre chronologique ; cette page la raconte par personne. Presque tout ce que ce wiki sait (chaque record, chaque théorie, chaque outil et chaque [impasse documentée](/fr/research/build/dead-ends/)) remonte à quelqu'un qui l'a publié sur la [liste de diffusion eternity2](https://groups.io/g/eternity2), le plus souvent gratuitement, souvent pendant des années. Voyez cette galerie comme un index et un remerciement à la fois. Les noms apparaissent tels que chacun signait ses messages publics ; chaque affirmation renvoie à un message. Beaucoup des personnes ci-dessous ont leur propre page de contributeur : un nom en **gras avec un lien** l'ouvre, rassemblant leur profil, leurs messages sourcés et toutes les pages qu'elles ont écrites ici. [Raphaël Anjou](/fr/research/people/raphael-anjou/), qui maintient le wiki et mène les expériences du labo, a la sienne lui aussi, un chercheur parmi les autres. Les noms sans lien sont documentés directement ici, sur cette page. ## Les fondateurs et les analystes du lancement (2000–2007) ### [Brendan Owen](/fr/research/people/brendan-owen/) Le fondateur. Owen a créé le groupe eternity_two en octobre 2000, soit six ans et demi avant que le puzzle n'existe ([msg 384](https://groups.io/g/eternity2/message/384)), et lui a donné son ton scientifique : dans les deux jours suivant l'annonce de janvier 2007, il avait dérivé la formule du nombre attendu de solutions qui fait de la difficulté un paramètre de conception ([msg 38](https://groups.io/g/eternity2/message/38)), et le week-end du lancement il a numérisé les vraies pièces et publié la première estimation du nombre de solutions ([msg 987](https://groups.io/g/eternity2/message/987)). Ses résultats phares : la preuve qu'un partage de couleurs 17+5 est le 16×16 le plus difficile possible ([msg 1947](https://groups.io/g/eternity2/message/1947)), le modèle exact de l'arbre de recherche que l'on appelle désormais [théorie complexe](/fr/research/why/complex-theory/) ([msg 5197](https://groups.io/g/eternity2/message/5197), [msg 5209](https://groups.io/g/eternity2/message/5209)), les [puzzles de référence](/fr/research/build/benchmarks/) 9×9/10×10 sur lesquels la communauté s'affronte encore, et la preuve en forme close de la profondeur de pic 256 × (1 − 1/e) ([msg 8125](https://groups.io/g/eternity2/message/8125)). Après un adieu à la clôture du concours ([msg 8429](https://groups.io/g/eternity2/message/8429)), il est revenu en 2025, affinant son propre modèle ([msg 11500](https://groups.io/g/eternity2/message/11500), [msg 11546](https://groups.io/g/eternity2/message/11546)). ### [Günter Stertenbrink](/fr/research/people/gunter-stertenbrink/) Un vétéran d'Eternity I et le premier à provoquer les estimations du groupe : en 2001, il demandait, des années avant les faits, comment on concevrait un puzzle doté d'un prix colossal et n'ayant qu'environ 1 % de chances d'être résolu en dix ans ([msg 15](https://groups.io/g/eternity2/message/15)), et il a accueilli les annonces de presse de 2005 par « So we can conclude, the end of the universe is in several years. » ([msg 34](https://groups.io/g/eternity2/message/34)). Pendant deux décennies, il a vérifié les chiffres de la liste, des conversions en couverture exacte de 2007 jusqu'au registre matériel « nœuds par watt » des années 2010. ### [Dave Clark](/fr/research/people/dave-clark/) Auteur du solveur distribué ESolve pour Eternity I, il a rejoint le groupe en 2001 ([msg 21](https://groups.io/g/eternity2/message/21)) et a bâti eternity2.net, le projet BOINC qui était le visage public de la communauté en 2007 ([msg 756](https://groups.io/g/eternity2/message/756)). Il l'a arrêté avec une comptabilité complète : 1,6 TFlops, plus de 10^19 opérations, aucune solution ([msg 3511](https://groups.io/g/eternity2/message/3511)). Il a ouvert le code de son solveur ([msg 3716](https://groups.io/g/eternity2/message/3716)) et a laissé aux archives leur meilleure source primaire sur la création du puzzle : son entretien téléphonique avec Monckton décrivant comment la solution a été générée puis mise sous scellés ([msg 4177](https://groups.io/g/eternity2/message/4177)). ### Txibilis Angel de Vicente, qui signait Txibilis, a construit la suite standard de plateaux de référence de type E2 ([msg 1886](https://groups.io/g/eternity2/message/1886)) et était le meilleur concepteur manuel d'[ordres de remplissage](/fr/research/build/backtracking/fill-order/) de la communauté. Son duel avec l'optimiseur automatisé de doc_s_smith a fait chuter les compteurs de nœuds de la recherche exhaustive de plusieurs ordres de grandeur ([msg 2928](https://groups.io/g/eternity2/message/2928)). La culture du benchmark qui a plus tard validé la théorie complexe commence avec lui. ### doc_s_smith En plein duel, la liste a découvert qui était doc_s_smith : Dietmar Wolz, le découvreur de la plupart des solutions connues d'Eternity I ([msg 2972](https://groups.io/g/eternity2/message/2972)). Son optimiseur de stratégie automatisé a établi des records de benchmark en 2007 ([msg 2896](https://groups.io/g/eternity2/message/2896)) ; de retour en 2010, il a publié une boîte à outils Java qui a transformé la liste en atelier d'algorithmes ([msg 7755](https://groups.io/g/eternity2/message/7755)) et a donné à l'après-concours son objectif de travail : « beat 468 matching edges » ([msg 7803](https://groups.io/g/eternity2/message/7803)). ### kubzpa Auteur du premier article sérieux sur le comptage des solutions, situant E2 autour de 15 millions de solutions ([msg 3497](https://groups.io/g/eternity2/message/3497)), et du résultat d'impossibilité le plus net de l'époque : l'argument de parité montrant qu'aucun plateau ne peut marquer exactement 479 par ses coutures intérieures ([msg 1640](https://groups.io/g/eternity2/message/1640)). Il a tenu dix-sept mois, jusqu'à ce que Verhaard signale l'unique faille ([msg 6317](https://groups.io/g/eternity2/message/6317)) : retourner une pièce de bordure dont les deux arêtes de bord extérieures partagent une couleur, et le plateau se lit comme un 479 tandis que ces arêtes de rebord non comptées restent intactes. C'est une subtilité de la bordure non comptée, non une brèche dans le calcul de parité intérieure, qui tient toujours, comme Verhaard l'a lui-même noté : 479 « cannot be achieved in another way » ([msg 6319](https://groups.io/g/eternity2/message/6319)). ### mjqxxxx Michael Quist était l'arbitre mathématique de la liste. Il a publié le premier cadre de comptage entièrement rigoureux pour les puzzles de type E2 ([msg 1221](https://groups.io/g/eternity2/message/1221)), a affiné la théorie de l'équilibre de bordure ([msg 2098](https://groups.io/g/eternity2/message/2098)), et ses relectures ont débusqué les défauts qui ont rendu solides les résultats des autres. Kubzpa a amendé son article sur le comptage des solutions après que sa relecture eut repéré une simulation Monte-Carlo erronée ([msg 3589](https://groups.io/g/eternity2/message/3589)). ## Les années du prix (2007–2010) ### [Louis Verhaard](/fr/research/people/louis-verhaard/) La seule personne que le puzzle ait jamais payée. Son solveur eii, rendu public « because I am stuck » ([msg 5940](https://groups.io/g/eternity2/message/5940)), a trouvé le 467 qui a remporté le prix de vérification de 10 000 $, inscrit sous le nom de sa femme, Anna Karlsson, comme il l'a lui-même confirmé : « Anna is my wife… it was my program that did the job » ([msg 6349](https://groups.io/g/eternity2/message/6349), [msg 6891](https://groups.io/g/eternity2/message/6891), [msg 7451](https://groups.io/g/eternity2/message/7451)). Ses méthodes sont devenues canoniques : les ordres de remplissage en peigne (comb-search) ([msg 6112](https://groups.io/g/eternity2/message/6112)) et le glissement d'arêtes contrôlé par la profondeur ([msg 7321](https://groups.io/g/eternity2/message/7321)). Il fut aussi le défenseur le plus acharné de la théorie complexe : « the finest work that has ever been published about E2 » ([msg 7810](https://groups.io/g/eternity2/message/7810)), et son 467 a tenu douze ans. ### Yannick Kirschhoffer Auteur de l'Eternity II Editor, l'éditeur et interface de solveur Java multiplateforme publié en février 2008 ([msg 4544](https://groups.io/g/eternity2/message/4544)) qui est devenu l'outil de plateau standard de la communauté pendant des années. Il proposait encore son aide sur le code lorsque celui-ci a refait surface en 2012 ([msg 9064](https://groups.io/g/eternity2/message/9064)). ### Fred Signant Eternity Blogger, Fred a construit E2Lab dans une salve de publications quasi quotidiennes à l'automne 2009 ([msg 7148](https://groups.io/g/eternity2/message/7148)), un éditeur/solveur dont le retrait délibéré de son propre « bouton magique », « to respect the game rules », en dit long sur l'éthique de la liste ([msg 7150](https://groups.io/g/eternity2/message/7150)). Son blog a hébergé les tableaux de la communauté durant les années de l'après-concours. ### [Al Hopfer](/fr/research/people/al-hopfer/) Un habitué depuis 2008 et le théoricien de la bordure de la communauté. Sa « doctrine de l'équilibre » pour la génération de puzzles apparaît en 2009 ([msg 6842](https://groups.io/g/eternity2/message/6842), [msg 6844](https://groups.io/g/eternity2/message/6844)) ; en 2022, il a énoncé la condition exacte que ce wiki appelle l'[équilibre de bordure NS-1](/fr/research/why/border-balance/) ([msg 10754](https://groups.io/g/eternity2/message/10754), [msg 10757](https://groups.io/g/eternity2/message/10757)), et l'a étayée par un partiel de 222 pièces à bordure complétée, entièrement documenté ([msg 10862](https://groups.io/g/eternity2/message/10862)). ## La longue décennie (2010–2019) ### [Peter McGavin](/fr/research/people/peter-mcgavin/) Le pilier de l'époque, et sans doute le chercheur le plus déterminant du puzzle après Owen. Son travail a [sa propre page](/fr/research/lab/experiments/peter-mcgavin/backtracker/). Il a calculé le nombre canonique d'environ 14 702 solutions attendues ([msg 8924](https://groups.io/g/eternity2/message/8924)), a transcrit la théorie complexe en LaTeX ([msg 9188](https://groups.io/g/eternity2/message/9188)) puis, plus tard, en code C exact ([msg 11197](https://groups.io/g/eternity2/message/11197)), que ce site porte. En 2017, il a résolu le 10×10 sans indice d'Owen en environ 180 années-cœur, dans les barres d'erreur de la théorie, sa plus forte validation à ce jour ([msg 9686](https://groups.io/g/eternity2/message/9686), [msg 9688](https://groups.io/g/eternity2/message/9688)), et en 2020 il a détenu le record lui-même : « New record score of 469! Only 11 breaks! » ([msg 10045](https://groups.io/g/eternity2/message/10045)). ### Tony Wauters L'université en personne. Il a publié l'article hyper-heuristique de son équipe, évalué par les pairs (461/480 en une heure), et est resté pour répondre aux questions ([msg 9017](https://groups.io/g/eternity2/message/9017), [msg 9023](https://groups.io/g/eternity2/message/9023)), et son équipe a enchaîné avec les travaux MILP et Max-Clique de 2017 ([msg 9683](https://groups.io/g/eternity2/message/9683)). ### Michael Field Un vétéran des solveurs les plus rapides des premières années, devenu le réaliste matériel du groupe : son architecture de backtracker sur FPGA projetait environ 5 G placements par seconde et par puce ([msg 9226](https://groups.io/g/eternity2/message/9226)), et ses analyses de capacité des voies GPU et FPGA ont dit à la liste ce que le silicium pouvait et ne pouvait pas acheter ([msg 9003](https://groups.io/g/eternity2/message/9003)). ### Arnaud Carré Arrivé en 2009, il a redéfini le standard de vitesse en 2014 avec un solveur mono-cœur à 114,5 millions de récursions par seconde, offert comme référence de comparaison ([msg 9233](https://groups.io/g/eternity2/message/9233)), et est revenu en 2018 pour les courses de benchmark. ### Adam Miles Le flanc GPU. Arrivé en 2017, il est passé des astuces de bits sur CPU à un solveur de calcul DirectX 12 tournant sur une Xbox One X ([msg 9811](https://groups.io/g/eternity2/message/9811)) et a re-vérifié exhaustivement sur GPU le jeu 9×9 numéro 1 d'Owen : les mêmes 2 solutions que le recensement CPU de 2014, en 25,4 heures ([msg 9822](https://groups.io/g/eternity2/message/9822)). ### JSA Le vérificateur de la communauté et, plus tard, son sauveur. En 2009, il a reproduit le 467 avec le solveur public de Verhaard, environ 82 jours sur un seul PC, consignant précisément à quel point l'air se raréfie au-dessus de 466 ([msg 6687](https://groups.io/g/eternity2/message/6687)). Lorsque Yahoo a annoncé qu'il effacerait les archives en 2019, JSA a payé les frais de transfert vers groups.io, proposant « I can pay for the first 5 years » ([msg 2](https://groups.io/g/eternity2/message/2)), et il rédige encore les messages de bienvenue du groupe ([msg 11771](https://groups.io/g/eternity2/message/11771)). ### Ole Knudsen Kronjuvel (Kron) était là depuis les toutes premières années, a revendiqué a posteriori un partiel de 231 pièces d'octobre 2007 ([msg 7563](https://groups.io/g/eternity2/message/7563)), et, en tant que propriétaire du groupe, a créé le nouveau domicile groups.io lors de la migration de 2019. Le message de bienvenue de 2026 s'ouvre par un hommage à lui ; il a disparu de la liste depuis 2023 ([msg 11771](https://groups.io/g/eternity2/message/11771)). ## La vague de records et l'ère moderne (2019–2026) ### [Joshua Blackwood](/fr/research/people/joshua-blackwood/) L'inconnu qui a mis fin au gel de douze ans. Inconnu de la liste, il a annoncé un 468 sur Reddit en août 2020 ([msg 10032](https://groups.io/g/eternity2/message/10032)), a ouvert le code de son solveur quelques jours plus tard ([msg 10037](https://groups.io/g/eternity2/message/10037)) accompagné de rares résultats négatifs (SAT, GPU et caches 2×2 tous mesurés puis écartés, [msg 10056](https://groups.io/g/eternity2/message/10056)), et en mars 2021 il a publié le 470 qui tient toujours ([msg 10117](https://groups.io/g/eternity2/message/10117)), trouvé avec le code public exact ([msg 10161](https://groups.io/g/eternity2/message/10161)). Son algorithme est [décodé sur ce wiki](/fr/research/lab/experiments/joshua-blackwood/solver/). ### [Jef Bucas](/fr/research/people/jef-bucas/) L'infrastructure de l'ère moderne. Il a donné l'alerte qui a déclenché la migration des archives ([msg 9920](https://groups.io/g/eternity2/message/9920)), a construit le visualiseur de plateaux [e2.bucas.name](https://e2.bucas.name) qui est devenu le livre des records de la communauté ([msg 9955](https://groups.io/g/eternity2/message/9955)), a réécrit le solveur de Blackwood en C sous le nom de libblackwood, doublant grosso modo sa vitesse et alimentant la vague de 469 de novembre 2020 ([msg 10065](https://groups.io/g/eternity2/message/10065), [msg 10078](https://groups.io/g/eternity2/message/10078), [msg 10067](https://groups.io/g/eternity2/message/10067)), et a égalé le 470 en 2024 ([msg 11401](https://groups.io/g/eternity2/message/11401)), en créditant toujours Blackwood. Son étude de paramètres wrapper_blackwood est republiée [sur ce wiki](/fr/research/lab/experiments/joshua-blackwood/solver/) avec sa permission ([msg 11905](https://groups.io/g/eternity2/message/11905)). ### Carlos Fernandez Le chirurgien de plateaux. Il a produit un 469 par un simple échange d'une pièce du plateau record de McGavin ([msg 10074](https://groups.io/g/eternity2/message/10074)), une variante 470 à bordure réarrangée ([msg 11403](https://groups.io/g/eternity2/message/11403)), des résolutions de quadrant 14×14 en quatre minutes ([msg 10802](https://groups.io/g/eternity2/message/10802)), et des barreaux élevés de l'échelle des cinq indices ([msg 11068](https://groups.io/g/eternity2/message/11068)). ### Bruno Gauthier Un vétéran de la vitesse de l'époque 2014, dont le solveur en Forth tournait à 80–90 millions de nœuds par seconde ([msg 9265](https://groups.io/g/eternity2/message/9265)), il a détenu le record le plus strict des annales pendant plus de trois ans : 460/480 avec les cinq pièces indices à leurs positions officielles, à partir de 2023 ([msg 11074](https://groups.io/g/eternity2/message/11074)) jusqu'au 464 de Benjamin Riotte en juillet 2026. ### Benjamin Riotte Détenteur du record strict des cinq indices. En juillet 2026, il a fait passer le meilleur plateau respectant les cinq placements d'indices du 460 de longue date de Gauthier à **464/480** (16 arêtes brisées), avec son propre DFS Blackwood modifié ([groups.io](https://groups.io/g/eternity2/message/11919)). Igor Pejic a atteint la même plage 463–464 indépendamment dans le même fil. Ce fut le premier mouvement sur la ligne strictement canonique en plus de trois ans. ### [Marijn Heule](/fr/research/people/marijn-heule/) Le point de contact du monde SAT. Dans le fil SAT au long cours, un collaborateur de Marijn Heule a rapporté que l'équipe de Heule avait réimplémenté et amélioré l'encodage à l'origine des résultats de benchmark SAT de 2008 ([msg 10969](https://groups.io/g/eternity2/message/10969)), l'état de l'art du flanc des méthodes exactes, qui débattait encore d'encodages CNF de 4 Go le tout dernier jour des archives ([msg 11822](https://groups.io/g/eternity2/message/11822)). ### [Raphaël Anjou](/fr/research/people/raphael-anjou/) Maintient ce wiki et mène les expériences cataloguées dans [le labo](/fr/research/lab/) ; ses comptes rendus se rassemblent sur sa [page de contributeur](/fr/research/people/raphael-anjou/), un chercheur parmi les autres. ### [William Millilaw](/fr/research/people/william-millilaw/) A mené une campagne de solveur dense de deux semaines en 2026, consignée pour l'essentiel comme des réfutations de méthodes qui ne percent pas le puzzle. Deux de ses résultats affinent le plafond : un test de gel par réplique, et un test de résidu SAT en halo montrant que les plateaux records sont des optima locaux stricts. Nous avons reproduit le second sur les plateaux publics, et il atterrit sur le [mur de rigidité](/fr/research/why/rigidity-wall/) aux côtés des preuves de programmation en nombres entiers ([reproduction](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/rigidity-sat-halo)). ### onesmallstep A fondé le serveur Discord de la communauté en novembre 2021 et l'a maintenu en vie durant les années creuses (rapporté sur le Discord de la communauté, novembre 2021 ; pas de lien de message public). Solveur dévoué à part entière (meilleur score auto-déclaré autour de 466–467), il est aussi la raison pour laquelle le wiki a un temps colporté par erreur un « 470 de 2025 » : un *relais* de record pris pour une *revendication* de record, corrigé ici à partir des archives Discord elles-mêmes. ### Reinout Annaert Le chasseur méthodique de l'ère Discord : un meilleur score auto-déclaré de 469, la sous-culture des séries linéaires (partiels consécutifs de 229 et 230 pièces), et l'homme qui a tranché la question de l'origine des placements d'indices : « They directly come from Tomy's Hint Puzzles » (rapporté sur le Discord de la communauté, décembre 2024 ; pas de lien de message public). Sur la liste de diffusion, il confirme conserver des figures de solutions marquant au-dessus de 467/480 ([msg 11549](https://groups.io/g/eternity2/message/11549)). Ses suggestions ont aussi façonné la feuille de route du terrain de jeu de ce site. ## Et bien d'autres encore Aucune galerie de cette taille n'est complète. Parmi les nombreuses personnes qui y ont leur place : Alan O'Donnell, qui avait le premier solveur fonctionnel quelques semaines après l'annonce ([msg 64](https://groups.io/g/eternity2/message/64)) ; Max, le partenaire d'entraînement de Verhaard dans la course au 467, dont le meilleur score fut 465 ([msg 6348](https://groups.io/g/eternity2/message/6348)) ; istarinz, qui a franchi les 558 millions de placements par seconde en 2008 et est devenu l'autorité du groupe en matière de vérification par recherche exhaustive ([msg 6212](https://groups.io/g/eternity2/message/6212)) ; antminder, dont l'hybride affectation-réparation atteignait en moyenne un 462 par jour en 2008 ([msg 5589](https://groups.io/g/eternity2/message/5589)) ; Pierre Schaus, dont l'article de programmation par contraintes a fourni cet opérateur de réparation ([msg 5601](https://groups.io/g/eternity2/message/5601)) ; capiman26061973, fondateur de l'échelle des cinq indices ([msg 11037](https://groups.io/g/eternity2/message/11037)) et du programme de minage des combinaisons invalides ([msg 7768](https://groups.io/g/eternity2/message/7768)) ; David Barr, auteur de solveurs GPU et navigateur open source pendant une décennie ([msg 9367](https://groups.io/g/eternity2/message/9367), [msg 11121](https://groups.io/g/eternity2/message/11121)) ; Henk van der Griendt, qui a déniché l'annonce du prix que tous les autres avaient manquée ([msg 6337](https://groups.io/g/eternity2/message/6337)) ; et juraj.pivovarov, la conscience du prototypage rapide de la communauté ([msg 9411](https://groups.io/g/eternity2/message/9411)). ## Corrections bienvenues Cette page sera toujours incomplète, et elle peut être erronée par endroits : un résultat mal attribué, un nom manquant, une orthographe préférée. Si l'un de ces points vous concerne, vous ou votre travail, dites-le sur la [liste de diffusion](https://groups.io/g/eternity2) ou via la [page de contribution](/fr/research/contribute/) : les corrections arrivent avec les mêmes règles de sourçage que tout le reste ici, et le crédit est tout l'objet de cette page. ## À lire aussi - [La traque, une histoire (partie I : 2000-2009)](https://eternity2.dev/fr/research/community/hunt/) — L'histoire de la communauté, d'une liste de diffusion fondée sept ans avant que le casse-tête n'existe jusqu'au prix d'examen de 10 000 $ remporté sous un nom d'emprunt, chaque événement rattaché à son message d'origine. Partie I d'une chronique en cours. - [La traque, une histoire, partie II : 2009-2026](https://eternity2.dev/fr/research/community/hunt-part-2/) — Dix-sept ans après le prix : le concours s'éteint avec sa solution enfermée dans un coffre, 467 tient une décennie, l'archive survit à la fermeture de Yahoo à quelques jours près, puis un inconnu venu de Reddit réécrit le livre des records. Chaque événement est rattaché à son message d'origine. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Records et solveurs > Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/records/ - Mise à jour: 2026-07-22 - Source: Archive de la liste de diffusion eternity2 (groups.io) : les annonces de records ; compte gratuit requis pour la lecture — https://groups.io/g/eternity2 - Source: Wikipédia : le casse-tête Eternity II (le prix de 2 M$, l'échéance de 2010 et le 467 de Verhaard) — https://en.wikipedia.org/wiki/Eternity_II_puzzle - Source: Le récit de Louis Verhaard sur son propre solveur à 467 — https://www.shortestpath.se/eii/eii_details.html - Source: e2.bucas.name (Jef Bucas) : le visualiseur de plateaux de la communauté ; chaque plateau lié peut y être re-scoré — https://e2.bucas.name --- Cette page suit le score : qui détenait le meilleur plateau à chaque étape, et comment il l'a obtenu. Pour le récit autour des chiffres, les points de bascule qui ont fait avancer le casse-tête, voyez l'[histoire en un coup d'œil](/fr/research/history/) ; les méthodes les plus fortes vivent dans la liste de diffusion et sur Discord, pas dans les revues scientifiques. > **[Interactive: RecordsView]** Rendered on the canonical page (link above); not shown in this markdown export. ## Lignée du carnet : comment les chiffres propres au projet ont été atteints Cette section concerne le carnet du projet, pas l'échelle des records communautaires. Rien ici n'est un record communautaire : chaque marque des tableaux ci-dessus (470 en régime « pièce de départ seule », 464 avec les cinq indices) reste au-dessus de chaque ligne ci-dessous. Ces lignes existent pour que les chiffres propres au projet restent traçables, chacune avec sa convention de score explicitée. Les méthodes sont documentées dans [le labo](/fr/research/lab/). | Date | Plateau | Score | Convention de score | Comment | | --- | --- | --- | --- | --- | | 2026-07-13 | Plateau du producteur, brut | 457/480 | Les cinq indices à leurs cases officielles ; arêtes appariées sur 480 | Un producteur en faisceau suivant un ordre de remplissage en peigne ; c'est le plateau brut, avant toute réparation. | | 2026-07-13 | Même plateau, après réparation | 461/480 | Les cinq indices à leurs cases officielles ; arêtes appariées sur 480 | Une passe de destruction-réparation a porté le 457 brut à 459, puis 460, puis 461. La boucle elle-même est étudiée dans [l'étude de réparation](/fr/research/lab/experiments/raphael-anjou/repair-study/). | | 2026-07 | PALIMPSEST | 463/480 | Pièce de départ seule ; arêtes appariées sur 480 | Un prior de placement extrait du corpus de plateaux communautaires, plus une destruction-réparation ciblée. Décrit dans [PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/). | Les deux conventions ne se comparent pas : un score « pièce de départ seule » et un score à cinq indices ne visent pas la même cible, d'où la convention nommée sur chaque ligne. Sous la convention à cinq indices, le meilleur du projet est 461 face au 464 communautaire ; en régime « pièce de départ seule », son meilleur est 463 face au 470 communautaire. ## À lire aussi - [Histoire : les grandes étapes](https://eternity2.dev/fr/research/history/) — L'histoire d'Eternity II en un coup d'œil, de la liste de diffusion fondée en 2000 au record de 470 qui tient toujours. Une chronologie parcourable des tournants, chacun renvoyant à l'histoire complète en deux parties et au message où il s'est produit. - [Expériences](https://eternity2.dev/fr/research/lab/experiments/) — Les expériences de recherche nommées du laboratoire, une section par chercheur. Chacune est un run réel contre Eternity II avec son idée, son meilleur plateau et les questions qu'elle a laissées ouvertes. Le carnet de Raphaël Anjou est ici en entier ; le carnet reste ouvert à tous les autres. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. --- # Nombres de référence > Dénombrements exacts du nombre de façons valides de remplir un petit bloc à une position donnée du plateau officiel d'Eternity II, sous des règles de plus en plus contraintes : des nombres sûrs pour vérifier le code d'appariement des bords et de contraintes de votre solveur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/reference/ - Mise à jour: 2026-07-11 - Sujets: backtracking - Reproduire: `just research-subgrid` - Source: Dénombrements de sous-grilles publiés par sylvogel (message groups.io 11879) — https://groups.io/g/eternity2/message/11879 - Source: Générateur Rust reproductible de ce projet + résultats versionnés (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/subgrid-placement-counts --- Combien de façons distinctes, respectant l'appariement des bords, existe-t-il de remplir un petit bloc du plateau officiel ? Ces dénombrements sont la vérité de terrain sur laquelle éprouver un solveur : si votre code d'appariement des bords et de contraintes est en désaccord avec les nombres ci-dessous sur un coin 2×2, le bug est dans votre code, pas dans la table. Les chiffres en romain sont calculés à partir du jeu de pièces officiel par le générateur Rust reproductible de ce projet (lien plus bas), de sorte que quiconque peut les recalculer. La poignée de chiffres en italique correspond à des dénombrements trop grands pour être énumérés exactement en quelques secondes (de dizaines de milliards à dizaines de milliers de milliards de remplissages) ; ce sont **les valeurs publiées par sylvogel**, reproduites ici par souci d'exhaustivité et créditées dans les sources. Tout le reste est recalculé ici à partir de zéro. > **[Interactive: ReferenceTableView]** Rendered on the canonical page (link above); not shown in this markdown export. ## À lire aussi - [Faits et chiffres établis](https://eternity2.dev/fr/research/build/known-facts/) — Les chiffres que tout chercheur sur Eternity II finit par redémontrer, rassemblés au même endroit avec leur provenance : la définition du puzzle, le placement des indices, les conventions de score, le tableau des records, la taille de l'espace de recherche et les comptages structurels. - [Les benchmarks de la communauté](https://eternity2.dev/fr/research/build/benchmarks/) — Comment une communauté à qui il était interdit de partager les pièces s'est malgré tout dotée d'une culture de test partagée : protocoles de vérification par comptages dérivés, les suites Txibilis et débutants, duels au nombre de nœuds, énumérations complètes, et le seul benchmark qui reste ouvert aujourd'hui. --- # Pourquoi c'est difficile > Eternity II n'est pas difficile par accident. Le casse-tête a été conçu pour résister à l'ingéniosité, et les murs structurels mesurables (rigidité, entropie, motifs interdits) expliquent pourquoi aucune recherche, si ingénieuse soit-elle, n'a atteint la fin. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/ - Mise à jour: 2026-07-21 --- Eternity II n'est pas difficile par accident. Voici la science derrière le fait qu'aucune recherche, si ingénieuse soit-elle, n'ait atteint la fin : la conception du casse-tête, et les murs structurels qui apparaissent dès qu'on se met à mesurer. > **[Interactive: ScoringPrimer]** Rendered on the canonical page (link above); not shown in this markdown export. ## Par où commencer - **[Quel mur arrête quelle méthode](/fr/research/why/walls-and-methods/)** aligne chaque méthode face au mur qu'elle attaque et au score où ce mur l'a arrêtée. La carte d'une page, et l'endroit pour s'orienter d'abord. - **[Le mur de rigidité](/fr/research/why/rigidity-wall/)** est le mur contre lequel presque toute méthode finit : les records sont des îles localement figées, sans gradient vers un meilleur plateau. - **[Le pic de difficulté](/fr/research/why/phase-transition/)** explique pourquoi les nombres de pièces et de couleurs se situent exactement là où la recherche est au pire. - **[Aucun coup forcé](/fr/research/why/no-forced-moves/)** est le mur qu'on ressent en premier : chaque case intérieure garde des dizaines de pièces légales, si bien que la recherche ne se resserre jamais d'elle-même. Si vous êtes venu vous demander si le plateau est [NP-complet, et comment l'encoder](/fr/research/why/how-hard-is-this-instance/), commencez par là : l'appariement de bords est NP-complet en tant que famille, mais une instance 16×16 fixée est une constante, pas un problème. ## Conçu pour résister à l'ingéniosité Eternity I est tombé en 2000 parce qu'Alex Selby et Oliver Riordan ont découvert que le casse-tête possédait bien plus de solutions que son concepteur ne le croyait, et qu'ils ont dirigé leur recherche vers les régions les plus « denses en solutions ». Pour Eternity II, l'éditeur a recruté les vainqueurs : Selby et Riordan ont participé à la conception et aux tests de résistance du nouveau casse-tête afin qu'aucun raccourci statistique de ce genre ne subsiste. Les empreintes visibles de cette validation : une unique solution conçue intégrée à des décomptes de couleurs équilibrés, aucune pièce à symétrie de rotation, aucune pièce en double, et des paramètres de nombre de pièces et de nombre de couleurs situés au pic empirique de difficulté (confirmé plus tard par Ansótegui et al.). Le casse-tête n'est pas difficile par accident. Il a été réglé pour l'être. Un détail qui ressemble à un choix de conception sans en être un : la bordure utilise son propre ensemble de cinq motifs, distinct de celui de l'intérieur. Cette séparation est automatique, non délibérée. Comme le rebord extérieur est gris uni, chaque pièce de bordure a son arête grise fixée vers l'extérieur, si bien que ses arêtes colorées ne rencontrent jamais que d'autres arêtes de bordure (latéralement) ou l'intérieur (vers le centre), et les deux réservoirs ne se touchent jamais. Les motifs de bordure pourraient être n'importe quelles cinq couleurs, voire un simple réétiquetage de celles de l'intérieur, sans rien changer au casse-tête. Ils paraissent « rares » uniquement parce qu'il y a moins d'arêtes de bordure à colorer, et non parce que les concepteurs auraient cantonné une ressource rare au cadre pour déjouer les solveurs. (Merci à Vasily V. sur la liste groups.io pour la correction.) ## Les murs structurels Au-delà du récit de conception, le casse-tête possède une structure mesurable qui explique l'écart entre le meilleur plateau connu (470/480) et une solution complète, publiée ci-dessous avec le calcul exact qui sous-tend chaque mur. Une manière utile de tenir tout cela ensemble consiste à lire [un plateau complet comme un mot de code](/fr/research/why/permutation-code-wall/) : ses 480 jointures intérieures sont des contrôles de type parité, le score vaut 480 moins le nombre de contrôles en échec, et la règle « chaque pièce une seule fois » devient un code de permutation superposé aux contrôles de couleur. La lentille renomme le score plutôt qu'elle n'ajoute un nombre, mais elle met les deux contraintes dures dans un même cadre, et le dénombrement qui la sous-tend se reproduit exactement. Dans la même clé algébrique, les [invariants de flux](/fr/research/why/flux-invariants/) pondèrent chaque couleur d'arête et lisent chaque pièce comme un vecteur signé : les coutures intérieures s'annulent, le plateau entier somme à zéro, et un quart de tour multiplie le vecteur par l'unité imaginaire, si bien que la loi est de rang complexe plein 22 sur l'ensemble officiel et que chacun de ses bits est invisible au comptage de couleurs. Certains de ces murs sont le même énoncé vu à des échelles différentes. Le [vol de pièce](/fr/research/why/piece-theft/), où une pièce rare dépensée tôt affame une case bien plus loin, est le visage à l'échelle de la case de la [loi d'aire](/fr/research/why/entropy-area-law/) : les deux sont la règle « chaque pièce une seule fois », la règle discrète qui porte la difficulté, l'une ressentie comme une seule case morte et l'autre mesurée comme l'effondrement des plateaux réellement distincts au-delà d'un patch de quelques centaines de cases. À l'échelle d'un remplissage entier, le même couplage produit [une région difficile qu'on ne peut pas concevoir autrement](/fr/research/why/irreducible-hard-region/) : remplissez le plateau dans n'importe quel ordre fixe et la difficulté se rassemble dans la bande que vous terminez en dernier, si bien qu'une décomposition déplace la difficulté au lieu de la supprimer. Les [motifs interdits](/fr/research/why/forbidden-patterns/) se placent à côté, sur un autre axe : ils comptent exactement à quelle vitesse les petits patchs épuisent leurs arrangements légaux sous le seul appariement des couleurs, tandis que l'effondrement de la loi d'aire est la surcouche distincte « une seule fois » posée sur des patchs valides en couleur. Les deux sont des décomptes exacts de rareté cohérents, pas le même axe, et les pages les gardent séparés à dessein. Savoir si les liens causals plus profonds tiennent, si la rigidité est elle-même une conséquence de l'effondrement de distinction dont elle partage l'échelle, de l'ordre de la centaine de cases, et si la géométrie des sigma-cycles est ce qui plafonne la recherche constructive, sont des questions ouvertes du tableau des [problèmes ouverts](/fr/research/open-problems/), pas des affirmations faites ici. ## Pages de cette section - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [Un jeu de pièces extrême sur chaque axe mesuré](https://eternity2.dev/fr/research/why/why-e2-is-hard/) — Mesurez les 256 pièces officielles sans aucun solveur en vue et chaque porte structurelle est fermée : aucune pièce symétrique par rotation, 5 paires jumelles sur 32 640 appariements, un plafond de 307 sur 480 si rien ne tourne, des budgets de couleurs qui s'apparient à exactement 480 sans aucun jeu, et une palette 17+5 posée au point d'une-solution-attendue. - [Quel mur arrête quelle méthode](https://eternity2.dev/fr/research/why/walls-and-methods/) — La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - [Cette instance est-elle NP-complète, et comment l'encoder ?](https://eternity2.dev/fr/research/why/how-hard-is-this-instance/) — L'appariement de bords est NP-complet en tant que famille, mais cela ne dit rien d'un plateau 16×16 fixé : une instance isolée est une constante, pas un problème. Ce qui est vrai, c'est la dureté au pire cas de la famille et la dureté empirique de cette instance, et comment écrire le puzzle pour un solveur SAT, de couverture exacte ou de PLNE, avec de petits croquis détaillés. Une mesure sur plateaux plantés chiffre le choix de la formulation : une falaise de résolubilité qu'un paradigme de recherche heurte et qu'un autre franchit, et qui bouge avec le nombre de couleurs. - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. - [Pourquoi 479 est impossible](https://eternity2.dev/fr/research/why/parity-defect-floor/) — Un argument de comptage sur le jeu de pièces officiel interdit un score d'exactement 479/480 : les demi-arêtes de chaque couleur viennent en nombre pair, et un unique raccord cassé laisserait deux comptes impairs. Le plancher sous le parfait est 478, et au plus 76 quasi-solutions à un coup peuvent entourer une solution. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Le mur des 470 : une frontière de phase, pas une limite d'ingénierie](https://eternity2.dev/fr/research/why/the-470-wall/) — Le plateau communautaire dans les hauts 460 se lit comme une frontière de phase entropique de l'instance, pas comme une limite du génie logiciel : le calcul exact sur le jeu officiel donne une densité de contraintes proche de 0,0094, un paysage recuit qui s'effondre au-delà de 470 et ne franchit 1 qu'à 480, et un nombre attendu de 10 à 20 solutions parfaites quasi orthogonales entre elles. Les nombres côté instance sont exacts ; le tableau du fossé de recouvrement en 16x16 est une conjecture assumée. - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [Motifs interdits](https://eternity2.dev/fr/research/why/forbidden-patterns/) — Presque tout petit assemblage de pièces que l'on pourrait construire est impossible. Pour un carré 2×2, 99,72 % des façons de placer quatre pièces ne pourront jamais s'accorder. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [Pureté de l'anneau : le bord est un sous-puzzle clos, sans aucun jeu](https://eternity2.dev/fr/research/why/ring-purity/) — Cinq des 22 couleurs ne touchent jamais les 196 pièces intérieures. La liste des pièces force toute solution valide à dépenser les 120 demi-arêtes de cadre sur l'anneau du bord : un sous-puzzle autonome à jeu exactement nul (120 = 120), un circuit eulérien sur cinq sommets, relié à l'intérieur par seulement 56 arêtes tournées vers le centre. - [Invariants de flux : une loi de rotation que l'ensemble officiel respecte exactement](https://eternity2.dev/fr/research/why/flux-invariants/) — Pondérez chaque couleur d'arête et lisez chaque pièce comme un vecteur signé, est moins ouest sur un axe, sud moins nord sur l'autre. Sommé sur une région quelconque, les coutures intérieures s'annulent et seule la bordure survit, si bien que le plateau totalise zéro. Un quart de tour pivote le vecteur d'un angle droit, ce qui fait de la loi une algèbre dans les entiers de Gauss. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - [Le casse-tête n'a pas de fonction de hauteur](https://eternity2.dev/fr/research/why/no-height-function/) — Empruntez l'astuce du physicien qui rend les défauts cristallins solubles et tentez de transformer un joint dépareillé en dislocation dotée d'une charge conservée. Cela échoue de trois façons : une hauteur scalaire est aveugle aux ruptures, l'ensemble des ruptures forme des chaînes ouvertes et non des boucles fermées, et le courant orienté par couleur n'est pas conservé. Seul un bit de parité non signé survit. - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - [La région difficile qu'on ne peut pas concevoir autrement](https://eternity2.dev/fr/research/why/irreducible-hard-region/) — Remplissez un plateau dans un ordre fixe et les trois quarts du haut se posent librement, tandis que la difficulté s'entasse dans la bande que vous terminez en dernier. Sur quarante plateaux générés, tout le reste tombe dans la moitié basse à chaque fois ; mélangez l'ordre de remplissage et il se disperse, donc la région difficile est fabriquée par le balayage, pas cachée dans le plateau. - [L'immédiateté des contraintes : chaque ordre de remplissage paie les mêmes 480](https://eternity2.dev/fr/research/why/constraint-immediacy/) — Sommez, pour n'importe quel ordre de visite du plateau 16x16, le nombre de voisins déjà posés que chaque case affronte à l'instant où elle est remplie : le total vaut exactement 480, quel que soit l'ordre. Un ordre de remplissage ne peut pas ajouter de restriction ; il choisit seulement quand chaque restriction s'applique. Ce qui sépare les ordres, c'est l'immédiateté, la distance entre une décision et sa réfutation, et seuls les extrêmes de ce classement appartiennent au puzzle plutôt qu'au moteur. - [Le plateau comme mot de code](https://eternity2.dev/fr/research/why/permutation-code-wall/) — Lisez un plateau complet comme un mot de code dont les 480 jointures intérieures sont des contrôles de type parité, et le score d'arêtes appariées devient 480 moins le nombre de contrôles en échec. C'est une lentille nette reposant sur une seule identité porteuse, et il vaut la peine d'être précis sur ce que la vue par codes correcteurs apporte et sur ce qu'elle ne fait que renommer. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [L'emplacement des indices l'emporte sur leur nombre](https://eternity2.dev/fr/research/why/hint-geometry/) — Sur un casse-tête 16×16 construit à l'image d'Eternity II, dix-huit indices dispersés sur le plateau le résolvent en quelques minutes, là où les entasser en rangées contiguës en réclame une centaine rien que pour ramener la recherche à des dizaines de milliards de placements. C'est la position, non le nombre, qui fait levier, et elle pointe droit vers la fin de partie. - [Relier les indices tôt n'aide pas, cela nuit](https://eternity2.dev/fr/research/why/clue-corridors/) — Relier les paires d'indices par des couloirs de pièces posés tôt donne l'impression d'ajouter des contraintes. Le comptage dit le contraire : un couloir de largeur 1 entre les deux indices les plus proches admet environ deux millions de milliards de remplissages distincts, donc il n'exclut presque rien tout en dépensant des pièces dont la fin de partie aura besoin. Dans un A/B contrôlé, chaque bras couloir a perdu face à son propre témoin à chaque taille de plateau. - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. - [Le cadre n'est pas le bassin : une bordure différente n'ouvre pas un plateau plus haut](https://eternity2.dev/fr/research/why/frame-is-not-the-basin/) — L'anneau de bordure est la partie la plus contrainte du casse-tête ; une bordure forte différente devrait donc fixer un intérieur haut différent. Il n'en est rien. De nombreuses bordures entièrement appariées et distinctes, chacune complétée par un même producteur d'intérieur fixe, donnent des sommets quasi maximalement différents les uns des autres mais uniformément bas, aucun près de la zone record. La bordure diversifie le plateau sans en prédire le plafond. - [L'équilibre du bord](https://eternity2.dev/fr/research/why/border-balance/) — Un plateau résolu dissimule une loi comptable toute simple : chaque couleur que le bord tend vers l'intérieur, l'intérieur la lui rend aussitôt. La violer, c'est savoir sur-le-champ que le plateau est faux ; la respecter, en revanche, ne garantit rien. - [Conçu pour être insoluble : la recette](https://eternity2.dev/fr/research/why/design-recipe/) — Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. - [La moisson de théorèmes : treize lois de structure](https://eternity2.dev/fr/research/why/theorem-sweep/) — Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. --- # L'équilibre du bord > Un plateau résolu dissimule une loi comptable toute simple : chaque couleur que le bord tend vers l'intérieur, l'intérieur la lui rend aussitôt. La violer, c'est savoir sur-le-champ que le plateau est faux ; la respecter, en revanche, ne garantit rien. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/border-balance/ - Mise à jour: 2026-07-22 - Sujets: search-space, structure - Reproduire: `just research-border-mismatch-share` - Source: Équilibre des types d'arêtes du bord observé lors de l'été de lancement (angwin_uk, août 2007) — https://groups.io/g/eternity2/message/2073 - Source: La condition de bord plus forte de mjqxxxx : effectifs pairs, répartis à parts égales entre arêtes gauche et droite (août 2007) — https://groups.io/g/eternity2/message/2098 - Source: Observation de Brendan Owen sur l'appariement des effectifs d'arêtes dans les jeux plantés (juin 2007) — https://groups.io/g/eternity2/message/422 - Source: Énoncé de Hopfer (2022) de la condition d'égalité des multiensembles (groups.io msg 10754) — https://groups.io/g/eternity2/message/10754 - Source: Reformulation nette de Hopfer : même mélange d'images internes sur les 56 pièces de bord (msg 10757) — https://groups.io/g/eternity2/message/10757 --- Ne considérez que la couture entre l'anneau extérieur de pièces de bord et le premier anneau de pièces intérieures. Chaque arête qui traverse cette couture présente une couleur, comptée une fois côté bord et une fois côté intérieur. Dans toute solution complète, les deux décomptes sont identiques : le multiensemble des couleurs que le bord présente vers l'intérieur égale exactement le multiensemble que l'intérieur présente vers l'extérieur. Appelons **déficit** ce déséquilibre, $\Delta$ : la moitié du désaccord total entre les deux décomptes. Un plateau achevé et correct a $\Delta = 0$. Les quatre solutions complètes connues, sur quatre jeux de pièces différents, la satisfont toutes exactement. Ainsi $\Delta > 0$ est un certificat qu'un plateau ne pourra jamais être complété : une condition nécessaire, réelle et peu coûteuse. ## La loi, en une ligne À travers la couture bord↔intérieur, les couleurs que le bord montre vers l'intérieur et les couleurs que l'intérieur montre vers l'extérieur forment le même multiensemble. En notant $A[c]$ et $B[c]$ les deux décomptes par couleur : $$ \Delta \;=\; \tfrac{1}{2} \sum_{c} \bigl|\, A[c] - B[c] \,\bigr| \;=\; 0 . $$ ## Le voir sur un vrai plateau Un plateau 8×8 résolu part à l'équilibre ($\Delta = 0$). Retirez une pièce de bord et observez quelles couleurs se déséquilibrent, et le déficit grimper. Essayez ensuite le bouton d'échange, et observez le piège. > **[Figure]** Interactif : le déficit d'équilibre du bord NS-1 — interactive: Ns1Lab. Rendered on the canonical page (link above); not shown in this markdown export. ## Le piège, et pourquoi il compte Échanger deux pièces de bord laisse $\Delta$ à 0. L'échange déplace des couleurs le long de la couture sans modifier l'un ou l'autre décompte ; l'invariant y est donc aveugle. Pire, sur une quasi-solution, la plupart des erreurs restantes ne se trouvent pas du tout sur la couture du bord. Elles siègent d'intérieur à intérieur, là où NS-1 ne regarde jamais. Sur les neuf plateaux de la classe 469 du corpus, parmi les 99 arêtes non appariées qui subsistent, 86,9 % siègent d'intérieur à intérieur et pas une seule n'est de bord à bord ; seuls les 13,1 % restants tombent sur la couture qu'inspecte NS-1. L'invariant est aveugle à la grande majorité de ce qui reste faux. C'est là toute la texture d'Eternity II en miniature. Une vérification aussi propre soit-elle ne dit jamais que « assurément cassé », jamais « assurément correct ». Le puzzle résiste à tout certificat de progrès à bon marché. ## Est-ce utile, alors ? Oui, comme élagueur de fin de recherche. Une fois que le solveur a refermé l'anneau de bord, imposer $\Delta = 0$ rejette une part utile des impasses profondes au prix d'un seul passage sur les 56 arêtes de la couture (l'ampleur exacte de cette part est mise en file pour mesure, pas encore un banc figé). C'est nécessaire-mais-lâche : cela écarte les mauvais états à peu de frais et laisse intacte la partie difficile, l'intérieur. ## À lire aussi - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. - [Motifs interdits](https://eternity2.dev/fr/research/why/forbidden-patterns/) — Presque tout petit assemblage de pièces que l'on pourrait construire est impossible. Pour un carré 2×2, 99,72 % des façons de placer quatre pièces ne pourront jamais s'accorder. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. --- # Relier les indices tôt n'aide pas, cela nuit > Relier les paires d'indices par des couloirs de pièces posés tôt donne l'impression d'ajouter des contraintes. Le comptage dit le contraire : un couloir de largeur 1 entre les deux indices les plus proches admet environ deux millions de milliards de remplissages distincts, donc il n'exclut presque rien tout en dépensant des pièces dont la fin de partie aura besoin. Dans un A/B contrôlé, chaque bras couloir a perdu face à son propre témoin à chaque taille de plateau. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/clue-corridors/ - Mise à jour: 2026-07-22 - Sujets: structure, search-space - Reproduire: `cd research/topics/clue-corridors/compute && cargo run --release --bin corridors > ../results/corridor_counts.json` - Source: Placements officiels des indices (cases 34, 45, 135, 210, 221 ; données d'instance sur e2.bucas.name) — https://e2.bucas.name/ --- Les cinq indices sont les seules cases du puzzle officiel dont le contenu est connu avec certitude. Regardez le plateau une minute et une idée s'impose d'elle-même : les relier. Poser une courte chaîne de pièces d'un indice à l'autre, faire de chaque chaîne une épine dorsale fixe, et espérer que ces épines contraignent tout ce qui suit. L'idée m'a plu au point de la mesurer, et la mesure est un négatif net, deux fois plutôt qu'une. Un comptage exact montre qu'un couloir d'indice à indice admet environ deux millions de milliards de remplissages distincts, donc s'y engager ne contraint presque rien ; et dans un A/B contrôlé, chaque bras qui posait ses couloirs tôt a fini derrière le même solveur sans couloirs, à chaque taille de plateau testée. ## Cinq îlots, et les ponts entre eux Les indices occupent les cases 34, 45, 135, 210 et 221, soit (x, y) = (2, 2), (13, 2), (7, 8), (2, 13) et (13, 13) : quatre en retrait de deux cases par rapport aux coins, un juste à gauche du centre. Leurs distances de Manhattan deux à deux vont de 10 à 22. Aucune paire d'indices n'est proche de l'adjacence : le pont le plus court entre deux d'entre eux est une chaîne de dix placements. Ce que vaut un placement de chaîne dépend du nombre de côtés qu'il doit apparier. Avec $n = 196$ pièces intérieures et $C = 22$ couleurs intérieures déclarées, une case qui doit s'accorder avec $k$ voisins déjà posés a en espérance $b_k = 4n / C^k$ candidats légaux : $b_1 \approx 35{,}6$, $b_2 \approx 1{,}62$, $b_3 \approx 0{,}074$. Un placement n'élague, en espérance, que lorsque $b_k$ passe sous 1, ce qui exige $k \ge 3$ côtés appariés. Un couloir de largeur 1 est bâti entièrement de placements à $k = 1$ : chaque nouvelle pièce ne touche que la précédente et hérite d'environ 36 candidats légaux à chaque pas. ## Ce que vaut un couloir : deux millions de milliards de remplissages La table de branchement est un modèle uniforme, alors le vérificateur compte aussi exactement sur le vrai jeu de pièces. Le vrai jeu est plutôt plus permissif : le nombre de couples (pièce, rotation) présentant une couleur intérieure donnée sur un côté donné vaut en moyenne 46,1 (de 43 à 49), contre 35,6 pour le modèle. Construisez la matrice de transfert $T[a][b]$ qui compte les pièces intérieures montrant la couleur $a$ d'un côté et la couleur $b$ du côté opposé, élevez-la à la longueur du couloir, et ses puissances donnent des comptages exacts de chemins. Pour le couloir de longueur 10 entre la paire d'indices la plus proche, les deux couleurs d'extrémité étant fixées par les indices, ce comptage vaut $2{,}59\times10^{15}$ chemins (moyenne sur les paires de couleurs). Un chemin peut réutiliser une pièce ; la correction de distinction en champ moyen $\prod_{j=0}^{9}(1 - j/196) = 0{,}792$ laisse $2{,}05\times10^{15}$ remplissages à pièces toutes distinctes. Mon premier passage sur ce comptage, avec un modèle de pièces un peu plus serré, donnait $1{,}9\times10^{15}$ ; le vérificateur archivé s'établit à $2{,}05\times10^{15}$, et la conclusion ne bouge pas entre les deux. Un engagement satisfiable de deux millions de milliards de façons n'est pas une contrainte au sens utile du terme. Le poser exclut une fraction infinitésimale de l'espace de recherche, tout en retirant dix pièces du pot à $k = 1$, précisément là où l'arithmétique dit que la recherche ne récupère rien. Reliez deux ou trois paires d'indices et la facture monte à 10 à 20 pièces dépensées avant qu'une seule case réellement contrainte n'ait été remplie. ## L'A/B : chaque bras couloir a perdu Le comptage dit que le couloir n'apporte rien ; il faut une expérience pour montrer qu'il coûte. La série d'origine de l'étude comparait trois bras qui ne diffèrent que par la phase couloir : un témoin (indices épinglés, puis un remplissage glouton à contact maximal avec redémarrages), un bras couloir de largeur 1, et un bras ruban de largeur 2, chacun posant ses routes d'indice à indice avant le même remplissage. Elle a tourné sur des instances à l'échelle avec une géométrie d'indices fidèle, aux tailles N = 8 à 16, avec 12 graines appariées par cellule et 20 secondes par exécution monocœur. | Plateau | Moyenne témoin | Couloir largeur 1 | Ruban largeur 2 | |---:|---:|---:|---:| | 8×8 | 92,50 | -4,67 | -3,00 | | 10×10 | 144,17 | -9,58 | -5,50 | | 12×12 | 209,83 | -13,58 | -6,75 | | 14×14 | 285,67 | -12,00 | -7,83 | | 16×16 | 377,17 | -17,67 | -8,08 | Les scores sont des arêtes appariées, et chaque delta oppose un bras à son propre témoin sur graines appariées. Chaque bras couloir a perdu face à son témoin à chaque taille, avec un Wilcoxon apparié $|z| \ge 2{,}80$. Le dommage croît avec les plateaux, et donc avec les couloirs : une perte moyenne de 4,7 arêtes à N = 8 devient 17,7 à N = 16, où les deux distributions de scores se séparent franchement (la pire graine du témoin a marqué 373 ; la meilleure du bras couloir, 365). Et élargir le couloir en ruban de 2 cases, ce qui permet à son second rang d'arriver à 2 contacts au lieu de 1, divise à peu près le dommage par deux à chaque taille. C'est exactement la dépendance en largeur que le comptage prédit, et c'est ce qui relie le mécanisme à la mesure. ## Ce que cela ferme, et ce que cela laisse ouvert Le négatif est précis : poser tôt des couloirs d'indice à indice de largeur 1 (ou 2) nuit, et plus de couloir nuit davantage. La même arithmétique qui les condamne désigne aussi l'endroit où la contrainte est réelle : les cases posées avec 2 contacts ou plus, puisque seul $k \ge 3$ élague franchement et que $k = 2$ s'en approche. Faire croître des régions compactes ancrées sur les indices, où la plupart des cases arrivent avec plusieurs contacts, est un geste différent, que cette expérience ne touche pas. Le résultat rejoint aussi ce que les études d'indices trouvent avec constance. Sur un puzzle 16×16 apparenté, [la position des indices l'emporte sur leur nombre](/fr/research/why/hint-geometry/) parce que la valeur d'un indice tient à ce qu'il atteigne la partie du plateau où la recherche peine ; et dans [l'étude d'indices du labo](/fr/research/lab/experiments/raphael-anjou/hint-study/), les cinq indices officiels seuls n'ont jamais aidé un backtracker chronologique sur les plateaux testés. Un couloir est la façon extrême de mal dépenser ce cadeau : il encaisse les cinq cases fixes immédiatement, dans la région la moins chère de la recherche, et le paie sur le pot de pièces. Comme les négatifs du [balayage de théorèmes](/fr/research/why/theorem-sweep/), celui-ci vient avec son prix : pour que relier les indices paie, il faudrait que ses cases arrivent avec trois contacts, et un chemin de largeur 1 n'y parvient jamais. > **Note** > > Le versant comptage se reproduit exactement : le vérificateur du répertoire du sujet recalcule la géométrie des indices, la table de branchement, l'offre de couleurs et les comptages de couloirs par matrice de transfert depuis le jeu de pièces officiel en une seconde environ, et sa sortie est archivée dans results/corridor_counts.json. Le tableau A/B est la mesure d'origine de l'étude : la re-exécution empaquetée des trois bras est spécifiée dans le plan de reproduction du sujet et ses tableaux ne sont pas encore archivés ; lisez donc ces deltas comme le relevé d'une série, la confirmation par une série fraîche restant à venir. ## À lire aussi - [L'emplacement des indices l'emporte sur leur nombre](https://eternity2.dev/fr/research/why/hint-geometry/) — Sur un casse-tête 16×16 construit à l'image d'Eternity II, dix-huit indices dispersés sur le plateau le résolvent en quelques minutes, là où les entasser en rangées contiguës en réclame une centaine rien que pour ramener la recherche à des dizaines de milliards de placements. C'est la position, non le nombre, qui fait levier, et elle pointe droit vers la fin de partie. - [L'étude sur les indices](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/hint-study/) — Donner à un backtracker cinq pièces correctes gratuitement, dans la géométrie même des indices du puzzle. Il s'avère que cela n'aide pas, et selon l'ordre de remplissage cela peut nuire gravement, car une pièce épinglée est une contrainte dure qu'un ordre de remplissage fixe doit satisfaire à son arrivée. Une famille d'ordres de remplissage, exécutée sur les mêmes plateaux indicés, un seul cœur, mesurée contre l'absence totale d'indices. - [La moisson de théorèmes : treize lois de structure](https://eternity2.dev/fr/research/why/theorem-sweep/) — Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. --- # La théorie complexe : compter l'arbre de recherche avant de le parcourir > La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/complex-theory/ - Mise à jour: 2026-07-02 - Sujets: structure, backtracking - Source: La forme close du pic de profondeur de Brendan Owen, 256·(1−1/e) (groups.io msg 8125, 2010) — https://groups.io/g/eternity2/message/8125 - Source: La résolution 10×10 de Peter McGavin validant la théorie complexe (groups.io msg 9686, 2017) — https://groups.io/g/eternity2/message/9686 - Source: Les estimations du nombre de solutions de Brendan Owen (groups.io message 5209) — https://groups.io/g/eternity2/message/5209 - Source: L'implémentation de référence et la table de profondeurs de Peter McGavin (groups.io message 11197) — https://groups.io/g/eternity2/message/11197 - Source: La tabulation « Backtracker estimates » de Brendan Owen pour les puzzles à indices et E2 (groups.io Databases) — https://groups.io/g/eternity2/databases - Source: La validation estimé-contre-réel de Brendan Owen, « NxM puzzles using Eternity II subset pieces » (groups.io Files, dossier Brendan) — https://groups.io/g/eternity2/files/Brendan/NxM_actual_theory.pdf - Source: L'étude heuristique-contre-nombre-de-nœuds de Brendan Owen, « Heuristics: 20×2 rectangle » (groups.io Files, dossier Brendan) — https://groups.io/g/eternity2/files/Brendan/heuristics.pdf - Source: La mesure profondeur-contre-temps du backtracker par Joe, échantillon de 1 milliard d'itérations (groups.io msg 11725, 2026) — https://groups.io/g/eternity2/message/11725 --- > **À qui l'on doit cette idée** > > La théorie complexe est due à Brendan Owen, l'un des vérificateurs du puzzle ; Peter McGavin l'a [implémentée en C](https://groups.io/g/eternity2/message/11197) en arithmétique à précision arbitraire et a publié les chiffres. Nous la reprenons ici parce qu'un membre de la communauté (Dan Karlsson) a justement fait remarquer qu'elle manquait, et parce qu'elle sous-tend presque toutes les bonnes décisions qu'on peut prendre pour un solveur, à commencer par le choix de l'ordre de recherche. ## L'idée Prenez un ordre de balayage et parcourez-le case par case. À chaque nouvelle case, une pièce inutilisée tirée au hasard s'accorde à ses voisines déjà posées avec une certaine probabilité : un produit de chances d'accord de couleur par arête. Multipliez cela par le nombre de pièces restantes et vous obtenez le nombre attendu de façons d'étendre le plateau d'une case de plus. Enchaînez ce calcul sur les 256 cases et vous disposez d'une estimation en forme close de la largeur de l'arbre de recherche à chaque profondeur et, à la dernière case, du nombre de solutions complètes du puzzle. C'est une moyenne, non un décompte exact : le modèle suppose que les 22 couleurs d'arête sont tirées indépendamment, ce qui est faux (quatre arêtes sont soudées à une même pièce rigide). Mais calibré sur de petits puzzles dont le nombre réel est connu, il tombe à un facteur deux près. C'est amplement suffisant pour en discerner la forme. ## Les chiffres phares | Indices posés | Solutions attendues | | ------------------------------------ | ------------------- | | Un indice (la pièce centrale seule) | ≈ 14 702 | | Les cinq indices officiels | ≈ 1 | Avec la seule pièce centrale imposée, le puzzle compte de l'ordre de quinze mille solutions ; ajoutez les quatre autres indices et le nombre attendu chute à environ $4\times10^{-8}$ : de manière écrasante, exactement une. C'est la raison formelle pour laquelle le puzzle à 5 indices possède une unique solution conçue. ## Les mêmes chiffres, confrontés à la réalité Brendan a tabulé l'estimation non seulement pour E2 mais aussi pour les quatre *puzzles à indices* plus petits, et c'est là qu'elle gagne sa crédibilité. Ces puzzles à indices sont assez petits pour que leurs arbres aient été explorés exhaustivement, si bien que l'estimation se place juste à côté du nombre réel. Elle tombe à un facteur deux près, la calibration que cette page ne cesse de promettre. La table consigne aussi le meilleur ordre de remplissage connu pour chaque puzzle, et ils ne sont pas tous identiques : l'ordre est un choix que la forme de l'espace de recherche récompense ou pénalise, non une propriété du puzzle. > **[Interactive: ClueEstimatesTable]** Rendered on the canonical page (link above); not shown in this markdown export. Les puzzles à indices fournissent quatre points de mesure ; Brendan a vérifié le modèle bien plus largement. Son étude **« NxM puzzles using Eternity II subset pieces »** trace les nœuds-par-solution estimés contre le nombre *réel* pour de l'ordre d'une centaine de plateaux plus petits construits à partir des pièces mêmes d'E2, et sur un axe log-log le nuage épouse la diagonale sur onze ordres de grandeur, de dix nœuds à $10^{11}$. Voilà le vrai fondement de la confiance qu'on peut accorder à l'estimation sur un plateau trop grand pour jamais être exploré : elle a eu raison partout où elle *pouvait* être vérifiée. Une étude compagnon montre même qu'un score statique tout bête (la somme, au carré, des comptes d'accords d'arête par case) prédit le nombre total de nœuds d'un rectangle avec un $R^2$ d'environ 0,84, preuve de plus que le coût de la recherche est inscrit dans la structure du plateau avant même qu'on ait posé une pièce. ## L'entonnoir Tracez la largeur attendue à chaque profondeur et trois régimes apparaissent. Leur forme est ce que la communauté appelle l'entonnoir d'E2. Lancez le balayage ci-dessous et observez le compteur : il grimpe astronomiquement, puis bouge à peine pendant une centaine de cases à travers le plateau, cette reptation plate au sein d'une bande astronomiquement large, c'est le mur, avant que les soixante dernières pièces ne le fassent redescendre en entonnoir. > **[Figure]** interactive: ComplexFunnelAnimated. Rendered on the canonical page (link above); not shown in this markdown export. ## À vous d'essayer : l'ordre décide de l'entonnoir La même estimation, exécutée en direct pour différents ordres de balayage. Le pic du plateau (le point le plus large que la recherche doit franchir) est décidé par le seul ordre, avant qu'un seul nœud ne soit posé. > **[Figure]** Interactif : l'entonnoir de l'espace de recherche — interactive: ComplexFunnelLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Trois régimes - **Croissance (profondeur 1–50).** Les solutions se multiplient géométriquement, de un à environ $10^{27}$. Chaque placement est pour ainsi dire gratuit ; rien ne vous contraint encore. - **Plateau (profondeur 50–200).** L'arbre est à sa largeur maximale, environ $10^{45}$ façons d'étendre, tandis que le nombre de solutions ne bouge presque pas. C'est là que les backtrackers passent l'essentiel de leur temps : un échantillon empirique ([groups.io msg 11725](https://groups.io/g/eternity2/message/11725), un calcul de 1 milliard d'itérations) a mesuré 99 % du temps du backtracker à une profondeur $>132$ et 70 % à une profondeur $>150$, c'est-à-dire au fond de l'arbre plutôt qu'au début. - **Effondrement (profondeur 200–256).** La largeur retombe de $10^{45}$ à environ $10^{4}$. Les ~60 dernières pièces sont fortement contraintes : chacune posée élimine des ordres de grandeur de branches. La fin de partie est localement facile ; le difficile, c'est d'y parvenir. ## Pourquoi cela change votre façon de chercher Si l'essentiel du travail se situe dans le plateau, l'objectif n'est pas la vitesse brute. C'est de traverser le plateau jusqu'à l'entrée de l'entonnoir (vers la profondeur 200), après quoi la recherche s'enchaîne de manière déterministe. Et comme la théorie complexe note un ordre de balayage avant de l'exécuter, on peut comparer des ordres par la hauteur du pic de leur plateau plutôt que par tâtonnement. C'est la version rigoureuse d'une règle que ce site énonce partout : l'ordre de remplissage est un choix de premier plan, et le balayage de McGavin, du coin inférieur gauche et de gauche à droite, a été retenu parce que la théorie complexe le disait bon. ## Des tuiles plus grandes La même idée fonctionne si l'on place des tuiles 2×2 ou 3×3 au lieu de pièces isolées : un bloc entier de cases est engagé d'un coup, ses arêtes internes étant déjà accordées. Le [terrain de jeu des chemins de recherche](/playground/paths/) vous permet de le faire pour de vrai : choisissez une forme de bloc (1×1, 2×1, 2×2, 3×3, …) et estampez des blocs sur la grille pour construire un chemin par blocs. Lancez la course et un solveur de macro-pièces dédié engage un sous-assemblage valide entier par bloc au lieu d'une pièce à la fois, si bien que la recherche progresse région par région. L'estimation du pic de plateau, en regard, note toujours l'ordre de cases qu'impliquent vos blocs, prédisant le coût avant que vous n'exécutiez le moindre nœud. ## Ce qu'elle ne peut pas voir La théorie complexe est une estimation au premier moment ; elle est donc aveugle à une chose : la question de savoir si les nombreux plateaux partiels comptés sont réellement distincts. Les [résultats d'entropie et de loi d'aire](/fr/research/why/entropy-area-law/) montrent que la distinction s'effondre à mesure que l'aire remplie grandit, un effet du second ordre que le modèle à arêtes indépendantes ne peut capter. Servez-vous donc de la théorie complexe pour choisir des ordres et lire la forme de l'arbre, jamais comme un décompte exact ni comme une borne. ## Provenance et validation La trace écrite de la théorie court à travers la liste de diffusion. Brendan Owen a publié le modèle achevé en avril 2008 ([msg 5197](https://groups.io/g/eternity2/message/5197), [5209](https://groups.io/g/eternity2/message/5209)), et a plus tard démontré une élégante forme close : pour un ordre de balayage, le pic du nombre de nœuds se situe à la profondeur $256\,(1 - 1/e) \approx 161.8$ ([msg 8125](https://groups.io/g/eternity2/message/8125)) ; l'entonnoir ci-dessus y culmine empiriquement. Peter McGavin a mis la théorie en forme ([msg 9188](https://groups.io/g/eternity2/message/9188)), a publié le chiffre de 14 702 solutions attendues dès 2011 ([msg 8924](https://groups.io/g/eternity2/message/8924)), et a livré en 2017 sa validation la plus forte : la résolution du benchmark 10×10 sans indice de Brendan en explorant les premières rangées classées par théorie complexe, soit environ 180 années-cœur, tombant dans les prédictions de la théorie ([msg 9686](https://groups.io/g/eternity2/message/9686), [9688](https://groups.io/g/eternity2/message/9688)). Son implémentation C de référence de 2024 ([msg 11197](https://groups.io/g/eternity2/message/11197)) est ce que l'estimateur en direct de cette page porte, ligne pour ligne. ## À lire aussi - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [Cette instance est-elle NP-complète, et comment l'encoder ?](https://eternity2.dev/fr/research/why/how-hard-is-this-instance/) — L'appariement de bords est NP-complet en tant que famille, mais cela ne dit rien d'un plateau 16×16 fixé : une instance isolée est une constante, pas un problème. Ce qui est vrai, c'est la dureté au pire cas de la famille et la dureté empirique de cette instance, et comment écrire le puzzle pour un solveur SAT, de couverture exacte ou de PLNE, avec de petits croquis détaillés. Une mesure sur plateaux plantés chiffre le choix de la formulation : une falaise de résolubilité qu'un paradigme de recherche heurte et qu'un autre franchit, et qui bouge avec le nombre de couleurs. --- # L'immédiateté des contraintes : chaque ordre de remplissage paie les mêmes 480 > Sommez, pour n'importe quel ordre de visite du plateau 16x16, le nombre de voisins déjà posés que chaque case affronte à l'instant où elle est remplie : le total vaut exactement 480, quel que soit l'ordre. Un ordre de remplissage ne peut pas ajouter de restriction ; il choisit seulement quand chaque restriction s'applique. Ce qui sépare les ordres, c'est l'immédiateté, la distance entre une décision et sa réfutation, et seuls les extrêmes de ce classement appartiennent au puzzle plutôt qu'au moteur. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/constraint-immediacy/ - Mise à jour: 2026-07-22 - Sujets: backtracking, search-space - Reproduire: `cd research/topics/constraint-immediacy/compute && cargo run --release -- repro-korder ../results` - Source: Le kit de reproduction derrière cette page : vérificateur des comptes de contraintes, solveur simple à deux bras, résultats archivés (research/topics/constraint-immediacy) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/constraint-immediacy --- Une intuition récurrente au sujet des backtrackers d'Eternity II tient en une phrase : si la recherche visitait d'abord les cinq cases indices, en suivant un chemin qui les relie tôt, les indices « restreindraient le puzzle plus vite » et l'arbre de recherche rétrécirait. L'intuition sonne juste, et la comptabilité dit le contraire. Aucun ordre de remplissage ne restreint le puzzle plus qu'un autre. Ce qu'un ordre contrôle réellement, c'est *quand* chaque restriction s'applique, et cette question de calendrier a une réponse nette : les restrictions payées tard sont les plus chères. ## Une somme qu'aucun ordre ne peut changer Fixez un ordre de visite complet des 256 cases. Quand la case $i$ est remplie, notez $k_i$ le nombre de ses voisines déjà posées : le nombre de contraintes d'arête que la nouvelle pièce doit satisfaire à cet instant. Chaque jointure intérieure du plateau est vérifiée exactement une fois, par celle de ses deux extrémités posée en second. La somme des $k_i$ vaut donc le nombre de jointures intérieures, soit sur le plateau 16x16 $2 \times 16 \times 15 = 480$, les mêmes 480 jointures que compte le [plancher de parité](/fr/research/why/parity-defect-floor/). Le total est invariant par chemin : $$\sum_i k_i = 480 \quad \text{pour tout ordre de visite.}$$ Le kit de reproduction vérifie cela exactement pour cinq ordres de visite sur le plateau officiel. Les cinq somment à 480 ; seule change la façon dont le total se distribue : | ordre | k=0 | k=1 | k=2 | k=3 | k=4 | somme | |---|---|---|---|---|---|---| | hint-link | 1 | 75 | 137 | 41 | 2 | 480 | | outer-spiral | 1 | 58 | 170 | 26 | 1 | 480 | | row-major | 1 | 30 | 225 | 0 | 0 | 480 | | boustrophédon | 1 | 30 | 225 | 0 | 0 | 480 | | border-first | 1 | 58 | 170 | 26 | 1 | 480 | Ces cinq valeurs sont les mesures d'origine du moteur de l'étude source ; la reproduction empaquetée couvre l'invariant et les deux solveurs simples ci-dessous, pas ce tableau. L'ordre ligne par ligne (row-major) est presque uniforme : passées la première ligne et la première colonne, chaque case affronte exactement deux contraintes. L'ordre hint-link (un chemin qui enchaîne tôt les cinq cases indices par des corridors de liaison) paie ses 41 cases à trois contraintes et ses 2 cases à quatre en posant d'abord 75 cases vérifiées contre une seule voisine. La loi de conservation en fait un échange, jamais un gain : une case ne peut affronter trois ou quatre voisines posées que parce que d'autres cases ont été posées presque sans vérification avant elle. ## L'immédiateté : le moment où la facture tombe Si le volume total de contraintes est fixé, qu'est-ce qui distingue les ordres en pratique ? Le coût d'un placement erroné est la taille du sous-arbre que la recherche explore avant que la réfutation n'apparaisse. Un ordre fait de longues portions sous-contraintes (des suites de cases vérifiées contre une seule voisine, avec des dizaines de candidats chacune) suivies de fermetures sur-contraintes (des cases vérifiées contre trois ou quatre) échoue *en dernier* : les erreurs commises à bas prix dans le corridor ne sont détectées qu'à la fermeture, un sous-arbre entier plus tard. Un ordre qui maintient la distance entre une décision et sa réfutation près de zéro échoue *tout de suite*, et tout le bénéfice est là. C'est le principe d'immédiateté des contraintes : restreindre tôt est le bon choix exactement quand la restriction teste chaque décision sur-le-champ. L'ordre bord-d'abord (border-first) engage en premier le sous-ensemble le plus contraint (les 60 pièces de bord, qui n'admettent qu'une seule orientation sur le pourtour), si bien que ses restrictions s'appliquent à l'instant où elles naissent. Le chemin hint-link est le cas opposé, une précocité géométrique sans immédiateté : les indices sont atteints tôt, mais le long de corridors dont les placements restent presque sans test jusqu'à ce que le plateau se referme autour d'eux. ## Ce que le moteur a mesuré Le principe a été extrait de runs à ordre fixe du moteur de recherche du projet, la même famille qu'examine [l'étude DFS](/fr/research/lab/experiments/raphael-anjou/dfs-study/). Ici et plus bas, les scores sont des arêtes intérieures appariées sur 480 selon le scoreur canonique qui exclut le pourtour ; aucun de ces nombres n'est une revendication de record, et les tables de records vivent sur [/research/records](/fr/research/records/). | ordre | arêtes appariées (moteur) | |---|---| | hint-link | 51 | | outer-spiral | 204 | | couture à deux fronts | 3 à 5 sous row-major | | row-major | 433 | | border-first | 445 | Un seul principe couvre toute la table : hint-link et la spirale échouent en dernier et s'effondrent ; row-major est uniforme et solide ; border-first ajoute un test immédiat sur les pièces les plus contraintes et finit en tête. ## La contre-épreuve au solveur simple Un classement mesuré sur un seul moteur peut être une propriété de ce moteur. Pour séparer les deux, la reproduction a relancé les cinq ordres sur un solveur volontairement simple, deux bras à 60 s par ordre et par bras sur le plateau officiel, un seul cœur sur Apple Silicon : une passe gloutonne au meilleur ajustement qui remplit tout le plateau en tolérant les défauts, et une recherche en profondeur à ajustement parfait avec retour arrière chronologique, notée sur son plus profond préfixe cohérent (16 à 47 milliards de nœuds par ordre, le budget a donc été réellement dépensé). Le fichier de résultats archive un lien visionneuse pour chaque plateau final. | ordre | glouton | score DFS | profondeur DFS | |---|---|---|---| | hint-link | 316 | 44 | 60/256 | | outer-spiral | 366 | 28 | 35/256 | | row-major | 343 | 344 | 194/256 | | boustrophédon | 359 | 342 | 193/256 | | border-first | 358 | 28 | 35/256 | Ce qui survit au changement de moteur, ce sont les extrêmes. Hint-link est de loin le pire ordre à ajustement parfait, et son score DFS de 44 atterrit près du 51 du moteur. Row-major et le boustrophédon forment le milieu de tableau solide dans les deux bras. Et sur le plateau officiel, le bras glouton garde border-first devant row-major, 358 contre 343, la même direction que le 445 contre 433 du moteur. Ce qui ne survit pas, c'est tout le reste. Sous le DFS simple, la spirale ne s'effondre plus dans une classe à part (elle fait jeu égal avec border-first, ce qui est cohérent avec le fait que les deux ordres partagent ici un profil de contraintes identique et les 60 mêmes premières cases), et border-first lui-même bute sur un mur de fermeture du pourtour à la profondeur 35 sur 256 au lieu de mener. Sur quatre plateaux 16x16 générés avec cadre, l'avantage glouton s'inverse purement et simplement : row-major gagne le bras glouton sur 4 graines sur 4 et le bras en profondeur sur 3 sur 4, le score DFS de border-first oscillant de 28 à 366 selon la graine. L'énoncé rigoureux de cette page est donc à deux faces : l'invariant et les extrêmes appartiennent au puzzle ; le milieu fin de tout classement d'ordres de remplissage appartient au moteur qui l'a produit. ## Où reste le levier La loi de conservation borne ce que la géométrie seule peut faire. Un profil uniforme à deux contraintes est le meilleur calendrier qu'un ordre de visite puisse atteindre, puisque les cases affrontant trois ou quatre voisines posées n'existent qu'en aval de cases posées presque sans vérification. Row-major atteint déjà ce profil, et les vingt ans d'ingénierie communautaire des ordres de remplissage recensés sur la [page des ordres de remplissage](/fr/research/build/backtracking/fill-order/) sont des raffinements à l'intérieur de ce cadre. Toute liaison précoce supplémentaire doit être informationnelle plutôt que géométrique : propager ce que la réserve de pièces restante peut encore servir (le mode d'échec que rend visible le [vol de pièce](/fr/research/why/piece-theft/)), des a priori de placement, des réserves de candidats restreintes, des portes d'élagage calculées. L'invariance elle-même est un petit énoncé exact dans l'esprit du [balayage de théorèmes](/fr/research/why/theorem-sweep/) : peu profond, mais il ferme une porte proprement. Personne ne rétrécira cette recherche en déroutant le chemin à travers le plateau ; les 480 vérifications sont dues en totalité, sur tout chemin, et seul leur calendrier vous appartient. ## À lire aussi - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [La moisson de théorèmes : treize lois de structure](https://eternity2.dev/fr/research/why/theorem-sweep/) — Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. - [Ordres de remplissage](https://eternity2.dev/fr/research/build/backtracking/fill-order/) — L'ordre dans lequel un algorithme de retour arrière visite les 256 cases est son unique liberté : il ne coûte rien à l'exécution et fait varier la taille de l'arbre de recherche de plusieurs ordres de grandeur. Vingt ans de science communautaire, des guerres fixe-contre-dynamique aux courses de stratégies, jusqu'au carré magique 10×16 et à la recherche en peigne de Verhaard, répondent tous à la même question : quel chemin à travers le plateau est le moins coûteux ? - [L'étude DFS](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/dfs-study/) — Une seule question, posée avec soin : parmi les backtrackers en profondeur d'abord pour Eternity II, qu'apporte réellement chaque ordre de remplissage, chaque heuristique et le mécanisme de rupture ? Une famille de backtrackers écrits de zéro, séparés chacun par un seul changement, exécutés sur les mêmes dix variantes à coins fixés, sur un seul cœur, pendant soixante secondes. --- # Conçu pour être insoluble : la recette > Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/design-recipe/ - Mise à jour: 2026-07-02 - Sujets: structure - Source: guenter stertenbrink pose le problème de conception : un casse-tête ayant ~1 % de chances de tomber en dix ans (msg 15, février 2001) — https://groups.io/g/eternity2/message/15 - Source: Brendan Owen, Concevoir le casse-tête le plus difficile : la recette complète et la dérivation du 17,14 (msg 1947, août 2007) — https://groups.io/g/eternity2/message/1947 - Source: Brendan Owen, Estimations du casse-tête le plus difficile : le tableau des paramètres les plus durs pour chaque taille de plateau (msg 2164) — https://groups.io/g/eternity2/message/2164 - Source: Brendan Owen, Fréquences des pièces : la distribution plate qui a tué la méthode d'Eternity I (msg 1667) — https://groups.io/g/eternity2/message/1667 - Source: Brendan Owen citant The Times : Selby et Riordan ont écrit le générateur pour Monckton (msg 3373) — https://groups.io/g/eternity2/message/3373 - Source: Le récit par Dave Clark d'un appel téléphonique avec Christopher Monckton sur la façon dont le casse-tête a été généré (msg 4177) — https://groups.io/g/eternity2/message/4177 - Source: Le recensement de l'espace de conception des pièces : 256 pièces sur environ 21 000 possibles, formes symétriques évitées (msgs 8014–8034 ; recensement au msg 8025) — https://groups.io/g/eternity2/message/8025 - Source: Brendan Owen sur la solution des concepteurs enfermée dans un coffre (msg 8823) — https://groups.io/g/eternity2/message/8823 --- Eternity II n'est pas un casse-tête qui se trouve être difficile. C'est le produit d'une recette : une courte liste de règles de conception qui, appliquées ensemble, produisent le casse-tête à raccords de bords le plus difficile qu'un nombre donné de pièces puisse former, tout en garantissant l'existence d'une solution. Le plus remarquable, c'est que la recette n'a pas été divulguée ni publiée par les concepteurs. La communauté l'a reconstituée, ingrédient par ingrédient, en quelques semaines après le lancement, pour l'essentiel dans un unique message d'août 2007 signé Brendan Owen et intitulé, fort à propos, « Concevoir le casse-tête le plus difficile » ([msg 1947](https://groups.io/g/eternity2/message/1947)). Cette page parcourt cette recette : ce qu'est chaque règle, ce qu'elle coûte à quiconque tente de résoudre le casse-tête, et d'où provient chaque affirmation. La mesure de l'ingrédient le plus tranchant (le nombre de couleurs situé exactement sur le pic de difficulté) fait l'objet de [sa propre page](/fr/research/why/phase-transition/) ; ici, elle prend simplement place parmi les autres. ## Le problème a précédé le casse-tête Le problème de conception a été énoncé sur la liste de diffusion six ans avant que quiconque ait à le résoudre. En février 2001, alors qu'Eternity I était à peine refroidi et qu'Eternity II n'était encore qu'une rumeur, guenter stertenbrink a demandé au groupe comment on concevrait un casse-tête assorti d'un prix de 5 M£ de sorte qu'il n'ait qu'environ 1 % de probabilité d'être résolu en dix ans ([msg 15](https://groups.io/g/eternity2/message/15)). Les réponses ont évoqué la mise à l'échelle d'une difficulté de type Eternity I, voire la dissimulation de problèmes cryptographiques dans les bords. C'est exactement le fil du rasoir sur lequel un casse-tête à prix doit avancer. Rendez-le trop facile et le prix est perdu ; c'est ce qui est arrivé à Eternity I, tombé en 2000 parce qu'il avait infiniment plus de solutions que son concepteur ne le croyait. Rendez-le littéralement impossible et le concours est une escroquerie. La cible, c'est un casse-tête dont on peut prouver qu'il possède une solution, positionné de telle sorte qu'aucune quantité réaliste de calcul ne la trouve dans la fenêtre du concours. Les concepteurs d'Eternity II avaient vu mourir Eternity I, et la recette qui suit se lit comme une réponse point par point. ## La recette, ingrédient par ingrédient ### Garder une forme compacte La première règle de la dérivation d'Owen : utiliser un plateau compact, le carré 16×16, plutôt qu'une forme allongée ou irrégulière ([msg 1947](https://groups.io/g/eternity2/message/1947)). Une forme compacte maximise la part des jointures intérieures, là où l'incertitude est la plus forte, et ne laisse ni bras étroits ni couloirs qu'un solveur pourrait épuiser à bon compte et utiliser comme point d'ancrage. Owen a ensuite vérifié la conséquence par l'expérience : sur des conceptions 16×16 comparables à palettes déséquilibrées, il existe toujours une région moins coûteuse à paver en premier (pour un partage 2/19, démarrer au milieu revient plus de cent fois moins cher qu'un balayage par lignes), mais sur les paramètres réels d'E2, aucune région de ce genre n'existe. La conception ne présente, selon ses propres mots, « aucune zone faible par où commencer le pavage » ([msg 5263](https://groups.io/g/eternity2/message/5263), comparaison de conceptions [msg 5243](https://groups.io/g/eternity2/message/5243)). ### Aucune pièce symétrique, aucun doublon Chacune des 256 pièces est unique, et aucune n'est symétrique par rotation ([msg 1947](https://groups.io/g/eternity2/message/1947)). En 2010, la communauté a dénombré l'espace de conception pour mesurer à quel point ce choix est délibéré : avec 5 motifs de cadre et 17 motifs intérieurs, il existe environ 21 000 conceptions de pièces possibles, y compris des formes comme *aaaa* et *abab* qui se répètent sous rotation. Le jeu réel les évite toutes, ostensiblement ([msgs 8014–8034](https://groups.io/g/eternity2/message/8014)). La conséquence, c'est l'absence de cadeaux. Une paire dupliquée permettrait de réécrire n'importe quelle solution en échangeant les deux pièces, doublant gratuitement le nombre de solutions ; une pièce à symétrie de rotation regrouperait des orientations et rétrécirait l'espace de décision. Refuser les deux maintient le nombre de solutions attendu exactement là où les concepteurs le voulaient et ne laisse au solveur strictement aucune symétrie à exploiter : chaque placement est une décision pleine et indépendante parmi 4 orientations de pièces distinctes. Il y a une seconde raison, plus discrète, d'interdire les pièces symétriques, et Owen l'a mesurée. Une pièce symétrique n'est pas seulement structurellement redondante, elle est aussi plus facile à *placer*, parce qu'elle s'insère dans davantage de contextes. Il a construit un jeu de 289 pièces (les 17 formes à symétrie de 90 degrés, les 136 formes à symétrie de 180 degrés, et 136 pièces asymétriques aléatoires), pavé un petit rectangle de toutes les façons possibles, et compté la fréquence d'apparition de chaque pièce sur l'ensemble des 759 millions de solutions. Les pièces asymétriques apparaissaient **2,08 fois** plus souvent que les pièces à symétrie de 180 degrés et **4,14 fois** plus souvent que celles à symétrie de 90 degrés ([msg 2076](https://groups.io/g/eternity2/message/2076)). Les pièces symétriques sont donc les *plus difficiles à paver*, et un casse-tête qui les aurait incluses aurait remis au solveur précisément la prise offerte par une pavabilité inégale - celle-là même que les [fréquences de couleurs plates](#rendre-chaque-fréquence-plate) sont censées supprimer. Les bannir maintient chaque pièce à peu près aussi difficile à placer, sans aucune pièce facile à garder pour la fin. ### Deux palettes, strictement séparées Les 22 couleurs se répartissent en 17 couleurs intérieures et 5 qui n'apparaissent que sur les raccords entre pièces de bordure, jamais à l'intérieur ([msg 1947](https://groups.io/g/eternity2/message/1947)). Cela transforme le cadre en un sous-casse-tête à part entière, dont la difficulté peut être réglée indépendamment de l'intérieur, de sorte qu'aucune des deux parties n'offre un point d'entrée facile : le même exercice d'équilibre que la forme compacte, appliqué à la palette. Les cinq couleurs réservées au cadre sont aussi les rares, mises en quarantaine sur le pourtour : les pièces de bord étant moins nombreuses que celles de l'intérieur, et les cases de bord ne prenant qu'une seule orientation, la recette d'Owen nivelle les deux groupes pour que leurs pièces restent à peu près aussi faciles à poser, plutôt que de laisser le cadre comme un point d'entrée mou et inégal ([msg 1947](https://groups.io/g/eternity2/message/1947)). Cette signature visible fait l'objet de [sa propre page](/fr/research/why/rare-color-geography/). ### Rendre chaque fréquence plate Lorsque Owen a numérisé son jeu le jour du lancement, il a trouvé la distribution des couleurs de bords « aussi plate que possible » : 24 arêtes pour chacune des 5 couleurs de raccord de bordure, 48 à 50 pour chacune des 17 couleurs intérieures ([msg 1054](https://groups.io/g/eternity2/message/1054)). C'est cet ingrédient unique qui a tué la stratégie d'Eternity I. Eternity I a été cassé en grande partie par l'ordonnancement selon la difficulté des pièces : les pavabilités de ses pièces variaient énormément, de sorte que les solveurs pouvaient garder les pièces les plus faciles pour la fin et laisser les statistiques les mener à bon port. Deux semaines après le lancement, Owen a montré que la distribution plate d'E2 rend cette approche inutile : quand chaque couleur est également fréquente, chaque pièce est à peu près également pavable, et aucune heuristique d'ordonnancement ne prend prise ([msg 1667](https://groups.io/g/eternity2/message/1667)). Comme l'a formulé en réponse doc_s_smith, l'une des personnes ayant réellement résolu Eternity I, la sélection de la position la plus contrainte est devenue « notre seul autre espoir » ([msg 1722](https://groups.io/g/eternity2/message/1722)). ### Viser exactement une solution Le dernier ingrédient fixe les décomptes de couleurs eux-mêmes. Owen a raisonné à rebours à partir de l'exigence « environ une solution attendue » : en imposant que le nombre attendu de pavages intérieurs soit égal à 1 et en résolvant pour le nombre de couleurs intérieures, on obtient $$I = (196! \cdot 4^{196})^{1/392} \approx 17.14$$ Arrondissez à 17, ajoutez les 5 couleurs de bordure réglées séparément, et vous avez la palette exacte d'Eternity II ([msg 1947](https://groups.io/g/eternity2/message/1947)). Owen a étayé la dérivation par des simulations, défendu le 17+5 contre la conception voisine 16+8 issue de la même famille à une solution attendue - car elle équilibre mieux la pavabilité des pièces de bordure et intérieures et ne laisse aucune entrée facile par le cadre ([msg 2426](https://groups.io/g/eternity2/message/2426)) -puis complété par un tableau des paramètres les plus durs pour chaque taille de plateau, une recette générale dont E2 est la ligne 16×16 ([msg 2164](https://groups.io/g/eternity2/message/2164)). Une solution attendue n'est pas un caprice esthétique arbitraire. C'est le réglage où les solutions sont aussi rares qu'elles peuvent l'être tout en existant encore : le sommet de la transition de phase, le point où l'on peut prouver que la recherche est à son pire. Cette mesure, et les analyses publiées qui ont plus tard confirmé le nombre d'Owen, se trouvent sur la [page du pic de difficulté](/fr/research/why/phase-transition/). Le revers prouve que le curseur est réel : une conception 16×16 délibérément *relâchée* discutée sur la liste compte environ 10^42 solutions attendues, quoiqu'Owen ait prévenu que même celle-là n'a rien d'une promenade de santé ([msg 4968](https://groups.io/g/eternity2/message/4968)). ## Qui l'a réellement conçu Christopher Monckton a inventé la franchise Eternity et mis le prix en jeu, mais son idée originale pour la suite était un casse-tête tridimensionnel de 1001 pièces. Owen l'a rapporté en notant que « la conception réelle est d'Alex et Oliver » ([msg 2697](https://groups.io/g/eternity2/message/2697)). Alex Selby et Oliver Riordan sont les deux mathématiciens qui ont remporté Eternity I en découvrant qu'il avait bien plus de solutions que prévu ; Monckton a engagé ceux qui l'avaient battu. Le groupe l'a soupçonné des semaines avant le lancement ([msg 716](https://groups.io/g/eternity2/message/716)), l'a vu confirmé dans un dépliant officiel Tomy (l'inventeur a rencontré les vainqueurs d'E1 lors d'une émission télévisée du matin et leur a demandé de travailler au développement d'E2 ; [msg 901](https://groups.io/g/eternity2/message/901)), et l'a enfin recoupé avec un article du Times : Selby et Riordan ont conçu le programme générateur du casse-tête ([msg 3373](https://groups.io/g/eternity2/message/3373)). Cette provenance explique la précision de la recette. La seule équipe au monde ayant une expérience de première main de la façon dont un casse-tête à prix échoue statistiquement a été payée pour s'assurer que ce mode de défaillance avait disparu. Chaque ingrédient ci-dessus (platitude, absence de doublons, palettes équilibrées, une solution attendue) ferme une porte que Selby et Riordan avaient eux-mêmes franchie en 2000. ## Comment les pièces ont été générées : un récit de seconde main Le seul récit détaillé du processus de génération présent dans l'archive est de seconde main et doit être lu comme tel. Dave Clark, fondateur du projet distribué eternity2.net, a rapporté une longue conversation téléphonique qu'il a eue avec Monckton le 26 juillet 2007 : le casse-tête a été généré à partir de l'entropie saisie au clavier par les juges du concours (quelque 200 entrées), régénéré jusqu'à satisfaction des juges, puis imprimé une seule fois et mis en coffre. Monckton lui a décrit le générateur de nombres aléatoires comme utilisant « des résidus gaussiens de puissances de nombres premiers convenablement choisis », ce que Clark a interprété comme l'implémentation propre à Selby et Riordan ([msg 4177](https://groups.io/g/eternity2/message/4177)). Le fil a brièvement envisagé l'idée d'attaquer un générateur cryptographiquement faible ; une réponse a souligné que si la construction était de type Blum-Blum-Shub, elle serait prouvablement difficile ([msg 4180](https://groups.io/g/eternity2/message/4180)). Rien n'est sorti de cette piste, mais le récit demeure la meilleure source quasi primaire de l'archive sur l'origine réelle des 256 pièces. ## La police d'assurance Un casse-tête conçu pour ne jamais être résolu doit tout de même prouver qu'il *peut* l'être. Le matériel de lancement de Tomy indiquait que personne, ni l'inventeur ni les concepteurs, ne connaît la solution : le générateur l'a imprimée « entre des pages de texte aléatoire pendant que toutes les parties étaient hors de la pièce », et la sortie a été scellée devant témoins ([msg 901](https://groups.io/g/eternity2/message/901)). Une fois le concours clos sans vainqueur, Owen a livré la formule encore citée aujourd'hui : « Je suis certain qu'Alex et Oliver ont créé une solution lorsque Chris les a payés pour générer un casse-tête pratiquement impossible », et qu'elle repose cachée au milieu de rames de texte imprimé enfermées dans un coffre, comme assurance contre toute contestation en justice de la bonne foi du concours ([msg 8823](https://groups.io/g/eternity2/message/8823)). Ce coffre est l'ingrédient final de la recette. La solution conçue est ce qui permet au casse-tête de se poser à une solution attendue plutôt qu'à zéro : existence garantie par construction, découverte tarifée au-delà de la portée de tout concurrent. ## Ce que la recette signifie si vous attaquez le casse-tête aujourd'hui Chaque raccourci générique que vous pourriez être tenté de saisir a été anticipé et facturé il y a près de vingt ans. L'ordonnancement selon la fréquence des pièces est mort avec la distribution plate. Les astuces de symétrie et de doublons n'ont rien à quoi s'accrocher. Il n'y a aucune région molle à paver en premier, aucun déséquilibre de palette à faire levier, et le nombre de couleurs se tient au réglage exact où la recherche est au pire. Le plafond brut de la communauté n'a bougé que deux fois en vingt ans (467 en 2008, 470 en 2021) et s'y maintient depuis (la piste à indices stricts, elle, a continué d'avancer indépendamment ; voir [/research/records](/fr/research/records/)) ; ce palier est le relevé empirique d'une conception qui a fonctionné précisément comme prévu. Cela ne rend pas le casse-tête impossible : une solution existe de façon certifiée, imprimée et mise sous clé. Cela signifie que l'écart restant n'est pas un problème de réglage. Ce qui le comblera devra être une idée que les concepteurs n'ont pas pu anticiper. C'est là, au fond, la raison d'être de ce wiki. ## À lire aussi - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. - [La traque, une histoire (partie I : 2000-2009)](https://eternity2.dev/fr/research/community/hunt/) — L'histoire de la communauté, d'une liste de diffusion fondée sept ans avant que le casse-tête n'existe jusqu'au prix d'examen de 10 000 $ remporté sous un nom d'emprunt, chaque événement rattaché à son message d'origine. Partie I d'une chronique en cours. --- # L'entropie et la loi d'aire > Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/entropy-area-law/ - Mise à jour: 2026-07-22 - Sujets: structure - Reproduire: `just research-entropy-area-law` - Source: Le lemme de sous-additivité de Fekete, le théorème qui garantit l'existence même de la limite d'entropie h∞ — https://en.wikipedia.org/wiki/Subadditivity#Subadditive_sequences - Source: L'entropie de Shannon d'une source, les quantités h(n) mesurées ici — https://doi.org/10.1002/j.1538-7305.1948.tb01338.x --- CartesianGrid, Line, LineChart, ResponsiveContainer, Tooltip, XAxis, YAxis, } from "recharts"; Oublions un instant la règle qui impose d'utiliser chaque pièce une seule fois et traitons les 196 pièces intérieures comme des tuiles réutilisables. En dénombrant les blocs entièrement compatibles, on constate qu'ils croissent exponentiellement avec la taille : les façons localement valides de paver ne manquent pas. La grammaire d'appariement est riche, et non restrictive. Cette richesse se mesure exactement. Pour une bande de largeur $n$, le taux de croissance par cellule est une densité d'entropie $h(n)$, et la suite décroît vers la vraie valeur bidimensionnelle à mesure que la bande s'élargit. ## L'entropie de la grammaire, largeur par largeur > **[Figure]** interactive: EntropyChart. Rendered on the canonical page (link above); not shown in this markdown export. ## Puis la loi d'aire frappe Rétablissons maintenant la règle qui impose d'utiliser chaque pièce une seule fois, et demandons-nous à quelle fréquence un bloc $n \times n$ compatible en couleurs emploie effectivement des pièces distinctes. Nous le comptons exactement, dans le dépôt : pour chaque taille de bloc intérieur nous comptons $A(n)$, les remplissages compatibles en couleurs quand les pièces peuvent se répéter, et $B(n)$, ceux qui emploient des pièces distinctes, puis prenons $\rho(n) = B(n)/A(n)$. Elle s'effondre, et elle s'effondre selon l'aire, non selon le périmètre : $$ \rho(n) \;\approx\; \exp(-\alpha\, n^2), \qquad \alpha \approx 0.044. $$ L'exposant est ajusté par moindres carrés sur la plage comptée exactement : $A$ et $B$ sont calculés ici pour $n$ jusqu'à $3$ (et $A$ jusqu'à $4$), avec $B(2) = 4\,059\,952$ concordant avec la table de référence sub-grille du dépôt. L'exposant par bloc croît encore sur cette petite plage (0,029 à $n=2$, 0,048 à $n=3$), si bien que 0,044 est une estimation basse de la valeur pour les grands blocs. À $n=4$, le comptage réutilisable $A(4)$ atteint déjà $6{,}3\times10^{16}$, au-delà de l'énumération distincte exacte en temps raisonnable ; la courbe au-delà de $n=3$ est donc une extrapolation de l'ajustement. Une décroissance en loi d'aire est brutale, car l'aire croît de façon quadratique. Par extrapolation, la proportion de blocs réalisables passe sous le seuil du millième aux alentours de 155 cellules. (Une étude hors site antérieure rapportait un $\alpha \approx 0.085$ plus raide et un seuil vers 80 cellules ; les comptages exacts du dépôt sur $n \le 3$ donnent les valeurs plus douces présentées ici, l'exposant par bloc croissant restant compatible avec la valeur hors site atteinte pour de plus grands blocs.) > **[Figure]** interactive: RhoChart. Rendered on the canonical page (link above); not shown in this markdown export. ## Voir l'écart se creuser La même idée appliquée aux pièces réelles, dénombrées exactement. Faites varier la taille du bloc et observez combien de blocs compatibles en couleurs survivent à la règle d'usage unique des pièces. > **[Figure]** Interactif : effondrement de la distinction et décroissance de rho — interactive: EntropyScarcityLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pourquoi c'est important Un effondrement de l'ordre de la centaine de cellules est à l'échelle des plus petits mouvements qui séparent les meilleurs blocs connus. La grammaire d'appariement reste riche, puis la règle de distinction l'effondre sur l'aire. Le mur ne se dresse donc pas là où le problème paraît difficile, dans l'appariement des couleurs ; il se dresse dans la règle discrète selon laquelle chaque pièce ne sert qu'une fois, dont le coût croît avec l'aire, sur un plateau juste assez grand pour qu'elle morde. Voir [pourquoi le basin-hopping est impossible](/fr/research/why/sigma-cycles/). ## Le théorème, en bref L'entropie par largeur possède une limite bien définie. Accoler côte à côte une bande de largeur $n_1$ et une bande de largeur $n_2$ n'ajoute qu'une contrainte de couture, si bien que les valeurs propres vérifient $$ \lambda_{n_1+n_2} \;\le\; \lambda_{n_1}\,\lambda_{n_2}. $$ En passant au logarithme, $\log \lambda_n$ devient sous-additif, et le lemme de Fekete donne la limite comme un infimum, ce qui explique précisément pourquoi la courbe ci-dessus décroît : $$ h_\infty \;=\; \lim_{n\to\infty}\frac{\log_{10}\lambda_n}{n} \;=\; \inf_n \frac{\log_{10}\lambda_n}{n}. $$ La borne supérieure est le taux purement horizontal : ignorer les contraintes verticales ne fait qu'ajouter des blocs, donc $$ 0 \;<\; h_\infty \;\le\; \log_{10}\lambda_H \;=\; 1.6645, $$ avec $\lambda_H = 46.18$ le rayon spectral de la matrice de compatibilité des couleurs à l'horizontale. La positivité tient parce que la grammaire admet exponentiellement de nombreuses chaînes, si bien que la densité est strictement comprise entre zéro et 1,6645, mesurée aux environs de 0,67. Ce que le théorème démontre, c'est qu'une limite positive existe et qu'elle est majorée par $\log_{10}(46.18) = 1.6645$. Sa valeur précise aux environs de 0,67 provient d'un balayage hors ligne. L'exposant de loi d'aire $\alpha \approx 0.044$ est ajusté ici à partir des comptages de blocs exacts du dépôt sur $n \le 3$ ; son extrapolation aux plus grands blocs (et le seuil des ~155 cellules) dépasse la plage comptée exactement. Le théorème ne fixe pas ces valeurs. ## À lire aussi - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [Motifs interdits](https://eternity2.dev/fr/research/why/forbidden-patterns/) — Presque tout petit assemblage de pièces que l'on pourrait construire est impossible. Pour un carré 2×2, 99,72 % des façons de placer quatre pièces ne pourront jamais s'accorder. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Compter les solutions : mesurer ce qu'on ne peut pas trouver](https://eternity2.dev/fr/research/build/analysis/solution-counting/) — Personne n'a jamais vu une solution complète d'Eternity II, et pourtant la communauté sait, à un facteur deux près, combien il en existe. Cette page raconte l'histoire et le métier de ce nombre : recensements exacts sur petits plateaux, la formule d'espérance et sa convergence sur 14 702 en vingt ans, et les estimations par recherche élaguée auxquelles on n'a fait confiance que lorsque quatre exécutions indépendantes concordaient. --- # Invariants de flux : une loi de rotation que l'ensemble officiel respecte exactement > Pondérez chaque couleur d'arête et lisez chaque pièce comme un vecteur signé, est moins ouest sur un axe, sud moins nord sur l'autre. Sommé sur une région quelconque, les coutures intérieures s'annulent et seule la bordure survit, si bien que le plateau totalise zéro. Un quart de tour pivote le vecteur d'un angle droit, ce qui fait de la loi une algèbre dans les entiers de Gauss. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/flux-invariants/ - Mise à jour: 2026-07-22 - Sujets: structure - Source: Invariants de flux : topic de reproduction avec l'article, le vérificateur versionné et le JSON de résultats (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/flux-invariants - Source: Conway et Lagarias, Tiling with polyominoes and combinatorial group theory : les invariants de mot de bord que cette loi adapte à l'appariement d'arêtes (JCTA 1990) — https://doi.org/10.1016/0097-3165(90)90057-4 - Source: Brendan Owen numérise l'ensemble de pièces : l'histogramme de couleurs que cette loi confronte (groups.io msg 1054, juillet 2007) — https://groups.io/g/eternity2/message/1054 - Source: Brendan Owen, Design the hardest puzzle : la séparation délibérée des palettes bordure et intérieur (groups.io msg 1947, août 2007) — https://groups.io/g/eternity2/message/1947 --- Les scores de cette page suivent la convention d'appariement d'arêtes : le score d'un plateau est le nombre, sur les 480 jointures intérieures, dont les deux demi-arêtes montrent la même couleur. Une solution complète vaut 480. Les invariants ci-dessous ne concernent pas le score d'un plateau ; ils concernent les rotations de pièces qu'un plateau-480 valide a le droit d'employer, et ils tiennent pour toute solution valide, quel que soit son score. ## L'idée en une ligne Donnez à chacune des 22 couleurs d'arête un poids numérique, la couleur de bordure grise recevant le poids zéro. Lisez une pièce posée comme un vecteur à deux dimensions : son poids côté est moins son poids côté ouest sur l'axe horizontal, son poids sud moins son poids nord sur l'axe vertical. Sommez maintenant ce vecteur sur un bloc de pièces posées. Chaque couture intérieure du bloc est partagée par deux pièces, et elle entre dans la somme une fois avec un signe plus depuis une pièce et une fois avec un signe moins depuis sa voisine, la même couleur sur les deux faces, si bien que les deux s'annulent. Rien ne survit à la somme, sauf la bordure extérieure du bloc. Sur le plateau entier cette bordure extérieure est le rebord gris, de poids zéro, donc le total est exactement le vecteur nul. C'est une loi de conservation, la cousine discrète d'un théorème de la divergence : le flux sortant de toute région égale le flux traversant sa frontière, et pour le plateau entier la frontière ne porte aucun flux. ## Pourquoi un quart de tour fait entrer les nombres complexes Le vecteur n'est pas insensible à la rotation. Tournez une pièce de quatre-vingt-dix degrés dans le sens horaire et sa couleur nord passe à l'est, l'est au sud, le sud à l'ouest, l'ouest au nord. Suivez ce que cela fait au vecteur et les axes horizontal et vertical s'échangent avec un signe : le nouveau vecteur est l'ancien tourné d'un angle droit. Dans le plan, un quart de tour est une multiplication par l'unité imaginaire. Donc si vous écrivez le vecteur comme un nombre complexe, un quart de tour de la pièce le multiplie par $i$, et les quatre rotations qu'une pièce carrée peut prendre correspondent aux quatre puissances $1, i, -1, -i$. Ce seul fait est ce qui élève une identité de comptabilité en algèbre. La loi de conservation, écrite couleur par couleur, dit qu'une certaine somme d'entiers de Gauss, un terme par pièce, chacun multiplié par une puissance de $i$ fixée par la rotation choisie de cette pièce, doit valoir zéro. C'est une contrainte non pas sur l'emplacement des pièces mais sur les rotations que l'ensemble entier peut adopter. ## La famille complète, et ce qui est nouveau Le groupe de rotation d'un carré a quatre caractères, et la loi de flux n'en est qu'un. Décomposer la pièce selon les quatre donne le treillis complet des invariants linéaires, intrinsèques à la pièce, de l'appariement d'arêtes : rien de linéaire ne lui échappe. Les quatre membres sont un simple recensement de couleurs (insensible à la rotation, le décompte total de chaque couleur sur la pièce), la loi de flux gaussienne que l'on vient de décrire, son conjugué complexe (la même information), et un quatrième membre, à valeurs entières, qui couple le choix par chaque pièce de la paire d'arêtes opposées qui se retrouve horizontale à la couleur d'échiquier de sa case. Ce dernier est l'écho, côté appariement d'arêtes, de l'obstruction de bicoloration que Conway et Lagarias ont utilisée pour le pavage par polyominos, la méthode du mot de bord dont toute cette famille est adaptée. Le recensement n'a rien de neuf : ce n'est que du comptage de couleurs. La valeur de la loi de flux, c'est qu'elle, elle en apporte. Sur l'ensemble officiel son ombre insensible à la rotation, la version obtenue en oubliant le $i$ et en fusionnant plus et moins, est identiquement nulle pour les 22 couleurs, parce que tout décompte de couleur sur le plateau est pair. Autrement dit, le comptage de couleurs sait déjà tout ce que l'ombre pourrait lui dire, et il n'en sait rien de plus. Chaque contrainte que la loi de flux impose au-delà de cette ombre est une information réellement nouvelle qu'un recensement ne peut pas voir. ## L'algèbre linéaire sur l'instance réelle Alignez les 22 couleurs en lignes et les 256 pièces en colonnes, et les coefficients de flux par pièce forment une matrice. Son rang mesure à quel point la loi contraint réellement le casse-tête. Recalculés sur l'ensemble officiel de 256 pièces, les nombres sortent ainsi.
22
rang complexe, plein (22 sur 22 couleurs)
40
contraintes réelles indépendantes
21
contraintes de parité indépendantes (mod 2)
Un rang complexe plein de 22 signifie que la loi lie les 22 couleurs à la fois, sans qu'aucune couleur ne s'échappe comme variable libre. Scinder les équations complexes en leurs parties réelle et imaginaire donne 40 contraintes réelles indépendantes sur l'assignation des rotations. Et réduire tout le système modulo 2, où la rotation d'une pièce se ramène à un unique bit de parité (un quart de tour et un trois-quarts de tour deviennent identiques modulo 2), laisse 21 contraintes de parité indépendantes, le système augmenté restant lui aussi de rang 21, donc cohérent plutôt que contradictoire. Ce système mod 2 à lui seul retire un facteur d'environ deux millions de l'espace des parités de rotation. Les faits d'instance que la loi confronte se reproduisent eux aussi exactement, chiffre pour chiffre face à l'ensemble de pièces numérisé par Brendan Owen : 196 pièces intérieures, 56 pièces de bord, 4 coins ; la couleur de bordure grise sur 64 demi-arêtes ; cinq couleurs de cadre qui ne touchent que des pièces de bord, 24 demi-arêtes chacune ; les couleurs intérieures restantes se répartissant en cinq à 48 et douze à 50 ; et tout décompte de couleur pair, ce qui est exactement ce qu'exige un appariement d'arêtes parfait. Les cinq indices officiels sont toutes des pièces intérieures. Rien de tout cela ne dépend d'une confiance dans une numérotation de couleurs : le vérificateur dérive l'ensemble des couleurs de cadre des données (les couleurs qui n'apparaissent jamais sur une pièce intérieure), si bien qu'un renumérotage entre le kit de départ et la liste source ne peut pas le tromper. ## D'une loi à une vérification de fin de partie Une loi de conservation qui doit tenir pour le plateau entier contraint aussi tout plateau partiel, parce que les pièces encore à poser doivent porter exactement le flux qui manque aux pièces posées. Au cours d'une recherche qui remplit la grille pièce par pièce, le flux dû par les pièces restantes est fixé dès l'instant où l'ensemble posé est fixé. Si aucune assignation de rotations aux pièces restantes ne peut fournir ce flux dû, le plateau partiel est mort, et l'on peut s'arrêter sans explorer son sous-arbre. Réduit modulo 2 cela devient un petit système linéaire sur les parités de rotation des pièces restantes, décidé par élimination de Gauss, et c'est un certificat de fin de partie fiable. Fiable veut dire qu'il ne rejette jamais un plateau réellement complétable : la loi est une condition nécessaire, donc un partiel réel passe toujours. Ce qu'il peut faire, c'est attraper une erreur. Testé sur un réservoir de plateaux 8 sur 8 résolus et encadrés, avec des rotations implantées, en injectant une unique rotation illégale dans le préfixe posé, le contrôle n'a pas rejeté une seule fois un partiel valide sur 3 600 essais, et sa probabilité d'attraper l'erreur injectée croissait avec la fraction de remplissage. | Fraction de remplissage | Partiels valides rejetés | Erreur de rotation unique attrapée | |---|---|---| | 0,50 | 0 sur 900 | 0,6 % | | 0,75 | 0 sur 900 | 14,1 % | | 0,90 | 0 sur 900 | 88,3 % | | 0,95 | 0 sur 900 | 94,6 % | Le contenu reproduit ici est le mécanisme et la forme de cette courbe, pas les pourcentages exacts. La source rapporte une courbe plus raide (13 %, 50 %, 100 % aux remplissages 0,50, 0,75, 0,90) sur une famille implantée différente ; le run ci-dessus utilise un plateau 8 sur 8 à 13 couleurs avec une pièce injectée choisie uniformément et un réservoir de 30 plateaux, 30 ordres chacun (900 par remplissage), si bien que les taux de détection absolus se situent plus bas. Ce qui tient exactement, et c'est là le point, c'est que le certificat est fiable et que sa probabilité de détection grimpe de façon monotone vers le plein à mesure que le plateau se remplit. C'est précisément le comportement utile pour une recherche : le contrôle s'affûte exactement là où la queue de branchement de l'arbre est la plus coûteuse, vers la fin, et chaque prise est orthogonale à l'élagage par couleur et par décompte, donc elle s'ajoute par-dessus au lieu de les dupliquer. ## Ce que c'est et ce que ce n'est pas La loi de flux est une obstruction. Elle peut certifier un plateau partiel mort ; elle ne peut jamais en certifier un complétable. C'est le rôle correct et voulu pour un invariant à l'intérieur d'une recherche par séparation et élagage, et il est partagé par tous les résultats de cette famille. Deux réserves de plus, dites franchement. La loi contraint les rotations que l'ensemble de pièces peut employer, pas la case où chaque pièce se pose ; seul le membre d'échiquier se couple à la position, et seulement par la parité de la case, si bien qu'aucun membre n'épingle une pièce à un emplacement. Et l'extension non linéaire naturelle, un produit de mot de bord non abélien à la manière de la construction originale de Conway et Lagarias, ne survit pas en deux dimensions : une case intérieure a quatre arêtes partagées mais seulement deux voisines adjacentes à elle dans tout ordre de lecture linéaire, si bien qu'au moins deux de ses arêtes ne pourront jamais s'annuler, et la construction retombe sur la loi de flux linéaire. Tout invariant strictement plus fort que ceux-ci doit être non linéaire et se situe hors de la famille des groupes de pavage. ## Où cela se place Voici le compte-rendu détaillé d'une loi de la [revue des théorèmes](/fr/research/why/theorem-sweep/), l'arc qui a demandé ce qui pouvait être prouvé sur l'instance plutôt que quel score pouvait être atteint. Elle se place à côté de la [pureté de l'anneau](/fr/research/why/ring-purity/), l'autre loi exacte que la bordure respecte, et elle est le complément algébrique de la [lentille du code de permutation](/fr/research/why/permutation-code-wall/), qui lit le plateau entier comme un mot de code : la loi de flux est un ensemble de contrôles de parité que les rotations doivent satisfaire, la même monnaie que celle dans laquelle cette lentille est écrite. La [page de théorie complexe](/fr/research/why/complex-theory/) compte la largeur de la recherche ; cette page y ajoute une façon peu coûteuse et fiable d'élaguer sa fin de partie. Chaque nombre ci-dessus est recalculé par le vérificateur versionné dans le topic de reproduction lié sous les sources : un unique programme Rust déterministe qui charge l'instance officielle, dérive les couleurs de cadre des données, calcule les trois rangs, vérifie l'ombre d'orthogonalité au recensement et exécute le balayage de fin de partie graine par graine, en émettant un unique fichier JSON (versionné sous `results/flux_invariants.json`) qui contient chaque chiffre cité ici. Les faits d'instance et les rangs se reproduisent octet pour octet ; le certificat rapporte sa propre courbe de prises, fiable à chaque remplissage. ## À lire aussi - [La moisson de théorèmes : treize lois de structure](https://eternity2.dev/fr/research/why/theorem-sweep/) — Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. - [Pureté de l'anneau : le bord est un sous-puzzle clos, sans aucun jeu](https://eternity2.dev/fr/research/why/ring-purity/) — Cinq des 22 couleurs ne touchent jamais les 196 pièces intérieures. La liste des pièces force toute solution valide à dépenser les 120 demi-arêtes de cadre sur l'anneau du bord : un sous-puzzle autonome à jeu exactement nul (120 = 120), un circuit eulérien sur cinq sommets, relié à l'intérieur par seulement 56 arêtes tournées vers le centre. - [Le plateau comme mot de code](https://eternity2.dev/fr/research/why/permutation-code-wall/) — Lisez un plateau complet comme un mot de code dont les 480 jointures intérieures sont des contrôles de type parité, et le score d'arêtes appariées devient 480 moins le nombre de contrôles en échec. C'est une lentille nette reposant sur une seule identité porteuse, et il vaut la peine d'être précis sur ce que la vue par codes correcteurs apporte et sur ce qu'elle ne fait que renommer. - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. --- # Motifs interdits > Presque tout petit assemblage de pièces que l'on pourrait construire est impossible. Pour un carré 2×2, 99,72 % des façons de placer quatre pièces ne pourront jamais s'accorder. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/forbidden-patterns/ - Mise à jour: 2026-07-01 - Sujets: structure, search-space - Reproduire: `just research-forbidden-patterns` - Source: Motifs interdits : article, code source et résultats (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/forbidden-patterns --- Eternity II compte 256 tuiles carrées, chacune portant une couleur sur ses quatre côtés. 196 d'entre elles sont des pièces intérieures, celles dépourvues de bord gris, donc les seules à pouvoir se retrouver à l'intérieur du plateau. Prenez-en quelques-unes, disposez-les dans une petite forme et faites-les pivoter à votre guise. La plupart du temps, les couleurs ne s'aligneront tout simplement pas, quoi que vous fassiez. Plus la forme est grande, plus la situation empire. Deux pièces côte à côte échouent à s'accorder dans environ 39 % des cas. Ajoutez-en une troisième en L et vous êtes bloqué dans 83 % des cas. Fermez un carré 2×2 et 99,72 % de tous les placements sont morts-nés : seul environ 1 sur 358 fonctionne. ## L'un s'accorde, l'autre non
> **[Figure]** interactive: BoardSvg. Rendered on the canonical page (link above); not shown in this markdown export. > **[Figure]** interactive: BoardSvg. Rendered on the canonical page (link above); not shown in this markdown export.
## À vous de jouer : tirez quatre pièces > **[Figure]** Interactif : peignez un assemblage et regardez-le s'interdire lui-même — interactive: ForbiddenPatchLab. Rendered on the canonical page (link above); not shown in this markdown export. ## D'où vient ce 99,72 % Une estimation grossière explique pourquoi ce nombre est si élevé. Deux pièces adjacentes partagent une arête. Chaque pièce intérieure porte des couleurs issues de la palette intérieure de 17 couleurs, si bien qu'une paire aléatoire de demi-arêtes s'accorde avec une probabilité d'environ $$ \Pr[\text{one edge matches}] \;\approx\; \frac{1}{17} \;\approx\; 6\%. $$ Un carré 2×2 comporte quatre arêtes internes à satisfaire simultanément. Les rotations offrent quatre chances à chaque pièce, mais les quatre arêtes sont couplées, si bien qu'une estimation d'indépendance faite au dos d'une enveloppe situe la probabilité que les quatre s'accordent à très grossièrement $$ \Pr[\text{2}\times\text{2 feasible}] \;\sim\; 1 - \left(1 - \tfrac{1}{17}\right)^{\!c} \ \text{per rotation budget} \;\Rightarrow\; \lesssim 1\%, $$ ce qui est déjà en dessous de un pour cent. Le décompte exhaustif exact aboutit à 0,28 % de configurations réalisables, soit 99,72 % d'interdites $(\,0.28\% = \tfrac{3{,}993{,}696}{1{,}431{,}033{,}240}\,)$. L'estimation est grossière parce que les arêtes ne sont pas indépendantes et les couleurs ne sont pas uniformes, mais elle donne le bon ordre de grandeur et montre pourquoi fermer un carré est bien plus difficile que placer une simple paire. ## Les décomptes exacts Tous les placements à pièces distinctes de chaque forme, vérifiés exhaustivement, sans échantillonnage. | Forme | Placements | Interdits | % interdits | | ---------------- | -------------: | ------------: | ----------: | | Deux côte à côte | 38,220 | 14,890 | 38.96% | | Deux empilées | 38,220 | 14,890 | 38.96% | | L de trois | 7,414,680 | 6,173,828 | 83.26% | | Carré 2×2 | 1,431,033,240 | 1,427,039,544 | 99.72% | Calculé exactement à partir du jeu officiel ; l'exécution se reproduit à l'identique à chaque fois (une vingtaine de secondes). [L'article, le code source et les résultats sont sur GitHub](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/forbidden-patterns). ## Interdit avant même d'avoir choisi une pièce La rareté commence un niveau en dessous des pièces entières, au niveau des couleurs. Une cellule intérieure présente deux des 17 couleurs intérieures à n'importe quel coin donné, les deux arêtes qui s'y rejoignent, ce qui fait $17 \times 17 = 289$ paires de couleurs ordonnées possibles. Elles n'existent pas toutes. Dès 2008, la communauté a remarqué que **20 de ces 289 paires sont des absences** : aucune pièce intérieure, dans quelque rotation que ce soit, ne présente cette paire particulière de couleurs sur des arêtes adjacentes ([msg 5027](https://groups.io/g/eternity2/message/5027)). Ainsi, un plateau partiel qui force une cellule à répondre par l'une de ces 20 paires de coin est mort sur-le-champ, avant même qu'une seule pièce ne soit essayée, et un solveur rapide peut le rejeter par une simple consultation de table. C'est la même leçon que le décompte 2×2, poussée jusqu'à la plus petite unité qui puisse être impossible : les contraintes mordent si tôt que des catégories entières d'exigence locale n'ont tout bonnement aucune réponse légale. ## Pourquoi c'est important Un plateau terminé et correct ne comporte aucun assemblage interdit : par définition, tout s'accorde. Compter les assemblages interdits d'un plateau indique donc à peu près à quelle distance il se trouve d'une véritable solution, même lorsque deux plateaux ont le même nombre d'arêtes accordées. Les plateaux faibles regorgent de carrés interdits ; les meilleurs plateaux jamais trouvés n'en gardent qu'une petite vingtaine. Cela montre aussi, sous un autre angle, pourquoi le puzzle résiste aux corrections locales astucieuses. Quand 99,72 % des petits carrés sont impossibles, les pièces qui s'accordent réellement sont rares et spécifiques. Il n'y a presque aucune marge pour réagencer les choses sans casser quelque chose. Les bons agencements sont rares et rigides. ## Un second axe de progression Compter les carrés interdits transforme l'idée en un signal exploitable. Prenez un vrai plateau record : le nombre de fenêtres 2×2 interdites décroît à mesure que le score d'arêtes accordées augmente. Deux plateaux au même score d'arêtes peuvent malgré tout différer ici : celui qui compte le moins de carrés interdits est structurellement plus proche d'une solution, et c'est pourquoi certains solveurs suivent le nombre d'assemblages interdits comme critère de départage. > **[Figure]** Interactif : comptez les placements réalisables face aux interdits — interactive: ForbiddenCountLab. Rendered on the canonical page (link above); not shown in this markdown export. ## À lire aussi - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. - [La cohérence d'arc, à partir d'AC-3](https://eternity2.dev/fr/research/build/reduce/arc-consistency/) — Le forward checking regarde un coup à l'avance ; la cohérence d'arc oblige la liste de candidats de chaque case à se défendre contre celle de chaque voisine, jusqu'à un point fixe. AC-3 de Mackworth, les raffinements optimaux qui ont suivi, ce que toute cette famille a réellement mesuré sur ce casse-tête, et où elle devient incorrecte. --- # Le cadre n'est pas le bassin : une bordure différente n'ouvre pas un plateau plus haut > L'anneau de bordure est la partie la plus contrainte du casse-tête ; une bordure forte différente devrait donc fixer un intérieur haut différent. Il n'en est rien. De nombreuses bordures entièrement appariées et distinctes, chacune complétée par un même producteur d'intérieur fixe, donnent des sommets quasi maximalement différents les uns des autres mais uniformément bas, aucun près de la zone record. La bordure diversifie le plateau sans en prédire le plafond. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/frame-is-not-the-basin/ - Mise à jour: 2026-07-22 - Sujets: structure, search-space - Reproduire: `just research-frame-is-not-the-basin` - Source: Le cadre n'est pas le bassin : topic de reproduction avec l'article, le producteur versionné et les deux fichiers JSON de résultats (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/frame-is-not-the-basin --- Il existe un raccourci tentant pour Eternity II. L'anneau de bordure est la partie la plus contrainte du plateau : soixante cases sur cinq couleurs d'anneau seulement, remplies par les quatre coins et les cinquante-six pièces de bord (la [page pureté de l'anneau](/fr/research/why/ring-purity/) montre pourquoi ces cinq couleurs ne quittent jamais le rebord). Si une bordure entièrement appariée fixe le sommet du plateau, alors une bordure *différente* devrait fixer un intérieur haut *différent*, et construire plusieurs bordures fortes distinctes ouvrirait plusieurs bassins hauts distincts. La diversification par la bordure serait un levier pour les scores. Cette page est la mesure qui referme cette porte. Générer de nombreuses bordures entièrement appariées et structurellement distinctes, puis compléter chacune avec le même producteur d'intérieur fixe, donne des sommets quasi maximalement différents les uns des autres et pourtant tous logés dans la même bande basse, loin de la zone record. La bordure est un fort *diversifiant* du plateau obtenu et un *sélecteur* de qualité inutile. L'identité du cadre ne prédit pas le plafond de l'intérieur.
28
bordures entièrement appariées distinctes, deux bases de graines
~190 / 196
cases intérieures qui diffèrent entre deux sommets quelconques
441
meilleur plateau, strict 5/5, encore à 14 de 455
Chaque score de cette page relève de la convention stricte à cinq indices (les cinq indices officiels respectés, adjacences non grises appariées sur 480) ; les cinq indices se trouvent sur des cases intérieures, aucun sur l'anneau, si bien que chaque complétion ici est un plateau strict 5/5 légal et que la bordure est libre de toute contrainte d'indice. Pour situer ces nombres par rapport aux records communautaires et de carnet, voir la [page des records](/fr/research/records/). ## Le cadre est un objet lâche La raison de douter du raccourci est structurelle. L'anneau de bordure est un problème d'appariement de bords cyclique et autonome sur cinq couleurs à approvisionnement équilibré, si bien que les bordures entièrement appariées sont astronomiquement abondantes : le cadre seul admet, on le sait depuis longtemps, plus de $10^{15}$ arrangements. En produire des versions structurellement distinctes est trivial, et elles se couplent à l'intérieur par un unique canal à faible information : soixante couleurs tournées vers l'intérieur, un mot-frontière que l'intérieur doit satisfaire, sur un intérieur de 196 cases et 22 couleurs. Ce canal est bien trop mince pour déterminer l'intérieur. L'espoir qu'une bordure différente fixe un intérieur haut différent repose donc sur une information que le cadre ne porte pas. L'expérience transforme cet argument structurel en test direct. ## Ce qui a été mesuré Sur l'ensemble officiel de 256 pièces, les cinq indices officiels épinglés : 1. générer N bordures entièrement appariées structurellement distinctes à partir de zéro (un placement en profondeur d'abord randomisé sur les soixante cases de bordure, gris vers l'extérieur, chaque adjacence d'anneau appariée, dédupliqué par égalité exacte de l'anneau) ; 2. figer chaque bordure et remplir ses 196 cases intérieures avec **un** seul producteur fixe à budget fixe : un faisceau tolérant aux ruptures qui remplit l'intérieur ligne par ligne, notant chaque candidat par arêtes appariées moins non appariées contre ses voisins déjà placés (bordure figée comprise) et élaguant à une largeur fixe avec une départage graine ; 3. rapporter la bande de score plateau complet, la distance de Hamming par tuiles entre les meilleures complétions, et si une bordure atteint la zone record. Deux questions, et deux seulement : **les sommets sont-ils distincts ?** et **les sommets sont-ils hauts ?** ### L'exécution principale Seize bordures entièrement appariées structurellement distinctes, faisceau d'intérieur de largeur 128, trois graines par bordure, meilleure conservée : | Grandeur | Résultat | | --- | --- | | Bordures entièrement appariées distinctes générées | 16 (sur 17 tentatives en profondeur d'abord) | | Bande de score des sommets (min / médiane / max) | 434 / 437 / 440 | | Une bordure atteint la zone record (>= 455) | non | | Écart du meilleur sommet par bordure à 455 | 15 | | Hamming par tuiles intérieures (sur 196 cases) | 188 à 191, moyenne 190,4 (120 paires) | | Meilleur plateau, strict 5/5, bordure toujours appariée | oui et oui (440, 40 ruptures) | Les deux lignes porteuses sont la troisième et l'avant-dernière. **Aucune bordure n'atteint la zone record** : la meilleure des seize marque 440, encore à 15 de 455 et à une vingtaine du haut strict 5/5 du carnet. Et les complétions sont **quasi maximalement distinctes** : entre deux quelconques, 188 à 191 des 196 cases intérieures diffèrent. Les bordures diversifient le plateau presque entièrement et n'en sélectionnent aucunement la qualité ; chacune des seize se loge dans une fenêtre de six points, 434 à 440. Le meilleur plateau de l'exécution, complétion strict 5/5 légale d'une bordure entièrement appariée, est visualisable depuis le fichier de résultats versionné du topic de reproduction. ### La passe de robustesse Le point étant précisément que l'identité du cadre n'importe pas, le résultat doit montrer qu'il n'est pas un accident d'une seule base de graines. Une seconde passe indépendante (douze bordures, une base de graines différente) concorde : bande 434 à 441 (médiane 438), meilleur 441 encore à 14 de 455, Hamming par tuiles intérieures 187 à 191 (moyenne 190,3), et le meilleur plateau à nouveau une complétion strict 5/5 d'une bordure entièrement appariée. Deux bases de graines indépendantes, 28 bordures distinctes en tout, et aucune ne franchit 445, encore moins la zone record. ## Pourquoi un intérieur plus fort ne fait que l'affûter Une passe de carnet antérieure a mené ce même test avec un intérieur plus faible, à ajustement dur, qui calait dans les 250 et n'approchait jamais la zone record. Cette reproduction y substitue délibérément un producteur d'intérieur *plus fort*, le faisceau tolérant aux ruptures ci-dessus, qui remplit toujours les 196 cases. Sa bande absolue est donc plus haute, la mi-430 plutôt que les 250. Cela n'adoucit pas le constat ; cela l'affûte. Même avec un solveur d'intérieur bien meilleur, aucune bordure distincte n'atteint la zone record, et les bordures restent quasi maximalement distinctes. Un intérieur plus fort ne peut rendre la bordure informative, car la bordure est une coque en aval, à faible entropie, suspendue à l'intérieur, et non la chose qui le fixe. La bande est une propriété du solveur d'intérieur ; le constat négatif est une propriété du couplage cadre-intérieur, et il est indépendant du producteur. ## Ce que cela referme, et ce que cela ne referme pas Le résultat est un énoncé de rigidité sur la bordure. Il referme la diversification par la bordure comme voie vers de meilleurs scores : une bordure entièrement appariée différente donne un plateau différent, mais pas un plateau plus haut, si bien qu'il n'y a aucun gradient à gravir en parcourant l'espace des bordures. Là où vit réellement l'information des hauts scores, c'est l'intérieur des rangées du haut, et c'est exactement la région que le [mur de rigidité](/fr/research/why/rigidity-wall/) décrit comme une île figée. Le cadre ne fixe pas le sommet ; le sommet se fixe lui-même, et la bordure y est suspendue. La comptabilité de couture qui couple les deux, l'équilibre exact des couleurs à travers l'interface bordure-intérieur, fait l'objet de la [page équilibre de la bordure](/fr/research/why/border-balance/). C'est un constat négatif à configuration unique, borné franchement. Il est établi purement à partir de bordures générées de zéro et complétées par un seul producteur fixe, la forme de robustesse que l'étude d'origine réclamait. Il ne tente pas le contrôle plus difficile consistant à figer la bordure propre d'un plateau record et à la compléter, ce qui exigerait un plateau qui ne fait pas partie du kit de départ public ; le constat tient sans lui. Et la bande absolue est celle du solveur d'intérieur, non une affirmation sur un chiffre exact : ce qui porte, c'est l'écart à la zone record, et il se reproduit avec de la marge. Chaque nombre ci-dessus est recalculé par le producteur versionné du topic de reproduction lié dans les sources : un programme Rust qui charge l'instance officielle, génère ses propres bordures entièrement appariées, fige chacune et complète l'intérieur avec le seul faisceau fixe tolérant aux ruptures, et émet deux fichiers JSON (l'exécution principale et la passe à graine indépendante) contenant chaque chiffre cité ici. ## À lire aussi - [Pureté de l'anneau : le bord est un sous-puzzle clos, sans aucun jeu](https://eternity2.dev/fr/research/why/ring-purity/) — Cinq des 22 couleurs ne touchent jamais les 196 pièces intérieures. La liste des pièces force toute solution valide à dépenser les 120 demi-arêtes de cadre sur l'anneau du bord : un sous-puzzle autonome à jeu exactement nul (120 = 120), un circuit eulérien sur cinq sommets, relié à l'intérieur par seulement 56 arêtes tournées vers le centre. - [L'équilibre du bord](https://eternity2.dev/fr/research/why/border-balance/) — Un plateau résolu dissimule une loi comptable toute simple : chaque couleur que le bord tend vers l'intérieur, l'intérieur la lui rend aussitôt. La violer, c'est savoir sur-le-champ que le plateau est faux ; la respecter, en revanche, ne garantit rien. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # L'emplacement des indices l'emporte sur leur nombre > Sur un casse-tête 16×16 construit à l'image d'Eternity II, dix-huit indices dispersés sur le plateau le résolvent en quelques minutes, là où les entasser en rangées contiguës en réclame une centaine rien que pour ramener la recherche à des dizaines de milliards de placements. C'est la position, non le nombre, qui fait levier, et elle pointe droit vers la fin de partie. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/hint-geometry/ - Mise à jour: 2026-07-10 - Sujets: structure, search-space, backtracking - Reproduire: `just experiments hint-study-solve` - Source: L'étude de densité d'indices de Joe et la résolution à 18 indices de Peter McGavin (fil groups.io « A method to prune E2 search space by 17-30%+ », msg 11725) — https://groups.io/g/eternity2/message/11725 - Source: Peter McGavin : 18 indices dispersés résolvent le casse-tête 16×16 façon E2 en moins de 15 minutes (groups.io msg 11746) — https://groups.io/g/eternity2/message/11746 - Source: Peter McGavin : le backtracker optimisé remonte au message de Mike de 2007 (groups.io msg 3098) — https://groups.io/g/eternity2/message/3098 --- Donnez gratuitement à un solveur quelques pièces correctes et le casse-tête devient plus facile. La question évidente est de savoir combien il en faut. La meilleure question, il s'avère, est de savoir *où* les placer. Sur un casse-tête 16×16 construit avec la recette de couleurs exacte d'Eternity II, dix-huit indices posés aux bons endroits le résolvent en quelques minutes ; les entasser au contraire dans des rangées contiguës, une mesure en a réclamé une centaine (soixante de bordure plus quarante intérieurs) rien que pour ramener la recherche à des dizaines de milliards de placements. Pour établir nous-mêmes le seuil de bascule, nous avons rejoué le même affrontement sur un plateau assez petit pour être résolu jusqu'au bout : égaler un réseau dispersé de seize indices a demandé **cinq rangées contiguës, quarante indices**, environ deux fois et demie le nombre, tranché par la seule géométrie. ## Deux façons de dépenser les mêmes dix-huit indices > **[Interactive: HintGeometryDiagram]** Rendered on the canonical page (link above); not shown in this markdown export. Le plateau de gauche est la disposition réelle qu'a employée Peter McGavin : dix-huit indices sur un réseau régulier, une colonne sur trois, sur quelques rangées éparses. Son backtracker à balayage de rangées, sans fioritures, a résolu le casse-tête 16×16 façon E2 de Joe (cinq couleurs de bordure, dix-sept couleurs intérieures, la même distribution que le casse-tête officiel) en moins de quinze minutes sur un seul cœur, en parcourant un arbre de recherche de 41 160 067 167 placements. Entassez au contraire les dix-huit indices dans les premières rangées, à la manière dont un balayage de haut en bas les accumule naturellement, et ils n'achètent presque rien : la partie difficile du plateau reste entièrement ouverte. Joe l'avait abordé par l'autre bout, en amorçant des rangées contiguës entières à partir d'une solution connue, et il lui en fallait bien davantage pour ramener la recherche à une taille maniable : une centaine d'indices (soixante de bordure plus quarante rangées intérieures) laissait encore un arbre d'environ 47 milliards de placements ([msg 11725](https://groups.io/g/eternity2/message/11725)). Ni l'un ni l'autre de ces chiffres n'établit le seuil avec précision, car un plateau 16×16 ne se termine jamais en quelques secondes et le décompte brut est brouillé par les correspondances gratuites qu'un bloc plein vous offre. Nous avons donc réduit le casse-tête à une taille qui, elle, se termine, un 8×8 construit selon la même recette de couleurs, et mesuré la vraie grandeur : le nombre de nœuds jusqu'à une résolution complète, sur trente instances graines par disposition. Là, un réseau dispersé de seize indices résout chaque instance en quelques milliers de nœuds de recherche. Les rangées contiguës doivent grimper à cinq rangées pleines, quarante indices, avant de résoudre chaque instance dans le même budget de nœuds. À nombre *égal*, seize indices dispersés l'emportent sur seize entassés en deux rangées de plus de deux ordres de grandeur en nœuds de recherche, et le bloc échoue à en résoudre six sur trente. Le réseau atteint la fin de partie ; le bloc ne l'atteint jamais avant de presque l'ensevelir.
18
indices dispersés, résolu en minutes
2,5×
d'indices en plus, en rangées contiguës, pour égaler un réseau dispersé (mesuré jusqu'à la résolution)
99%
du temps de recherche passé au-delà de la profondeur 132
70%
du temps de recherche passé au-delà de la profondeur 150
## Pourquoi la position gagne : les indices doivent atteindre la fin de partie Les deux nombres de droite expliquent ceux de gauche. Joe a instrumenté son backtracker sur plus d'un milliard d'itérations et constaté que le travail n'est pas du tout réparti sur le plateau : 99 % s'effectue après la profondeur 132 sur 256, et 70 % après la profondeur 150. Presque toute la douleur est dans la seconde moitié du remplissage, et l'essentiel au-delà des trois cinquièmes. Un bloc d'indices contigus en haut est dépensé exactement là où la recherche n'allait jamais peiner. Il raccourcit un début facile et laisse intacte la queue coûteuse. Les indices dispersés font l'inverse : parsemés à travers le plateau, jusque dans la région que la recherche atteint en dernier, ils devancent les choix qui, sinon, exploseraient loin dans l'arbre. C'est le même fait que les plateaux records portent à leur surface. Un plateau quasi parfait concentre tous ses dégâts dans la bande de rangées sur laquelle la recherche s'est terminée, parce que [ce sont les rangées remplies en dernier qui vous font payer le casse-tête](/fr/research/why/mismatch-geometry/). Les indices n'aident que dans la mesure où ils atteignent cette bande avant la recherche. Cela cadre aussi avec [le fait que l'intérieur ne donne aucun coup forcé](/fr/research/why/no-forced-moves/) : chaque cellule intérieure acceptant encore des dizaines de voisines, la valeur d'un indice ne tient pas à une propagation locale mais à une contrainte globale, qui élague des sous-arbres entiers que la recherche aurait sinon dû parcourir. Un indice loin de la région difficile n'élague que des sous-arbres qui étaient de toute façon bon marché. ## Ce que cela dit et ne dit pas C'est un résultat sur un casse-tête 16×16 construit selon la recette de couleurs d'Eternity II, et non sur le casse-tête officiel, dont les cinq indices fixes constituent un cadeau différent, bien plus modeste, à des endroits différents. Ce qui se transpose, c'est la forme de la leçon, et c'est la même que celle que l'argument [élagage contre vitesse](/fr/research/why/prune-vs-speed/) formule par l'autre bout : ce qui compte, c'est de changer l'endroit où la recherche dépense son effort, et l'effort réside dans la fin de partie. Une poignée d'indices visant cette fin de partie vaut une multitude d'indices visant n'importe où ailleurs. > **Note** > > Les décomptes, l'arbre de 41 milliards de nœuds et les statistiques de profondeur sont les mesures de Joe et de Peter McGavin, rapportées sur la liste groups.io eternity2 en janvier 2026 ; la disposition dispersée montrée est décodée du plateau publié par Peter (msg 11746). Le backtracker optimisé qu'a employé Peter remonte au message de Mike de 2007 (msg 3098). Ce sont des résultats communautaires sur un casse-tête façon E2 particulier, consignés ici avec attribution plutôt que redérivés. Le seuil des cinq rangées est notre propre mesure, sur nos propres plateaux 8×8 générés et notre backtracker : le plus petit nombre de rangées contiguës dont le taux de résolution et le nombre médian de nœuds jusqu'à la solution égalent tous deux un réseau dispersé de seize indices, sur trente instances graines par disposition. Reproduisez-le avec `just experiments hint-study-solve`. ## À lire aussi - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. --- # Cette instance est-elle NP-complète, et comment l'encoder ? > L'appariement de bords est NP-complet en tant que famille, mais cela ne dit rien d'un plateau 16×16 fixé : une instance isolée est une constante, pas un problème. Ce qui est vrai, c'est la dureté au pire cas de la famille et la dureté empirique de cette instance, et comment écrire le puzzle pour un solveur SAT, de couverture exacte ou de PLNE, avec de petits croquis détaillés. Une mesure sur plateaux plantés chiffre le choix de la formulation : une falaise de résolubilité qu'un paradigme de recherche heurte et qu'un autre franchit, et qui bouge avec le nombre de couleurs. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/how-hard-is-this-instance/ - Mise à jour: 2026-07-22 - Sujets: exact-methods - Source: Demaine & Demaine 2007, « Jigsaw Puzzles, Edge Matching, and Polyomino Packing: Connections and Complexity » (Graphs and Combinatorics 23) : l'appariement de bords est NP-complet — https://doi.org/10.1007/s00373-007-0713-4 - Source: Ansótegui, Béjar, Fernàndez & Mateu, How Hard is a Commercial Puzzle: the Eternity II Challenge (CCIA 2008) — https://repositori.udl.cat/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/download - Source: Knuth, The Art of Computer Programming, Volume 4B : Algorithme X et Algorithme C (couverture exacte avec couleurs) — https://www-cs-faculty.stanford.edu/~knuth/taocp.html - Source: Puzzle Eternity II (Wikipédia) — https://en.wikipedia.org/wiki/Eternity_II_puzzle --- Cette page répond à une question qui ressurgit sans cesse sur les Stack Exchange de mathématiques et d'informatique, et qui domine la liste des différends sur la page de discussion Wikipédia du puzzle : l'appariement de bords est NP-complet en général, alors cela nous apprend-il quelque chose sur *ce* plateau 16×16 fixé, et concrètement, comment confierait-on Eternity II à un solveur ? Les réponses brèves sont : non, pas directement, voici trois encodages, et une mesure en fin de page montre à quel point le choix entre eux peut compter. ## D'abord, l'erreur de catégorie La NP-complétude est une propriété d'un *problème*, ce qui, en théorie de la complexité, désigne une famille infinie d'instances indexée par un paramètre de taille $n$. Les « puzzles d'appariement de bords » forment une telle famille : étant donné $n$, un ensemble de tuiles carrées et un alphabet de couleurs, décider si les tuiles pavent un cadre $n \times n$ avec tous les bords adjacents qui concordent. Ce problème de décision est NP-complet ([Demaine & Demaine 2007](https://doi.org/10.1007/s00373-007-0713-4)), ce qui signifie à la fois qu'une solution proposée est vérifiable en temps polynomial et que tout problème de NP s'y réduit. Un plateau fixé unique n'est pas une famille. L'instance Eternity II a une réponse bien définie, « oui, elle est résoluble » (les concepteurs l'ont construite à partir d'une solution) ou, dans la forme de compétition à 5 indices, « oui, avec exactement cet agencement ». Cette réponse tient en un seul bit. Un seul bit est une constante, et « cette constante est-elle NP-complète ? » n'est pas une question bien formée : il existe un algorithme en temps constant qui affiche la réponse (`return true`), la réponse y est simplement inscrite en dur. Demander si une instance isolée est NP-complète relève de la même erreur de catégorie que demander si le nombre 17 est de temps polynomial. La famille est donc dure et l'instance est une constante. Qu'y a-t-il, alors, de réellement vrai et utile à dire sur la difficulté du plateau posé sur votre bureau ? ## Ce qui est réellement vrai Deux énoncés distincts, tenus séparés : - **Dureté au pire cas de la famille.** Parce que le problème général est NP-complet, on ne connaît aucun algorithme qui batte le temps exponentiel dans le pire cas lorsque $n$ croît, et en trouver un prouverait $\mathrm{P}=\mathrm{NP}$. Cela borne ce que tout solveur d'appariement de bords générique peut promettre. Cela ne dit rien de la manière dont se comporte une entrée *spécifique*. - **Dureté empirique de cette instance.** Une dureté que l'on peut mesurer. Le plateau 16×16 compte de l'ordre de $1{,}115\times10^{557}$ agencements distincts de pièces et de rotations, et le puzzle semble n'admettre que très peu de solutions (la forme à 5 indices est conçue pour n'en avoir essentiellement qu'une ; voir la [théorie de la complexité](/fr/research/why/complex-theory/) pour l'estimation du nombre attendu). Une recherche par retour sur trace faufile donc un espace astronomiquement vaste vers un ensemble de solutions quasi vide, et passe ainsi presque tout son temps à explorer des impasses. Voilà pourquoi le puzzle est dur *en pratique*, et c'est une affirmation sur ce plateau, non sur la famille. Le théorème du pire cas et la difficulté empirique pointent ici dans la même direction, mais ce sont des énoncés de nature différente et un seul des deux est un théorème. Une famille peut être NP-complète alors qu'une instance donnée est triviale (beaucoup le sont), et une instance peut être brutalement difficile à résoudre en pratique même au sein d'une famille polynomiale. Ansótegui et al. ont plaidé exactement ce cas empirique pour Eternity II, en en tirant des jeux de tests pour solveurs et en mesurant la difficulté directement plutôt qu'en invoquant le théorème général ([CCIA 2008](https://repositori.udl.cat/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/download)). > **La version en une ligne** > > « Eternity II est-il NP-complet ? » Non : une instance n'a pas de classe de complexité. « Le problème d'appariement de bords est-il NP-complet ? » Oui. « Cette instance est-elle difficile à résoudre ? » Empiriquement oui, parce que l'espace de recherche est large de ~$10^{557}$ et que l'ensemble des solutions est quasi vide, si bien que la recherche se noie dans les impasses. ## L'encodage : la mise en place Le reste est pratique : comment écrire le plateau pour qu'un solveur puisse le mâcher ? Les trois encodages ci-dessous partagent le même squelette. Numérotons les cases $c = 1 \dots 256$, les pièces $p = 1 \dots 256$, et les rotations $r \in \{0, 1, 2, 3\}$. Un *placement* est un triplet $(c, p, r)$ : la pièce $p$ déposée dans la case $c$ tournée de $r$ quarts de tour. Chaque encodage doit exprimer trois choses : 1. chaque case reçoit exactement un placement, 2. chaque pièce est utilisée exactement une fois, 3. partout où deux cases se touchent, les couleurs du bord partagé concordent. Les encodages ne diffèrent que par la façon dont ils expriment la contrainte 3, l'appariement des couleurs, et cette différence est toute l'affaire. Les croquis ci-dessous utilisent un plateau 2×2 ou 3×3 pour que l'on puisse voir toutes les clauses ; le 16×16 a la même forme à plus grande échelle. ## SAT / FNC Introduisons une variable booléenne $x_{c,p,r}$, vraie lorsque la pièce $p$ se trouve à la case $c$ dans la rotation $r$. Sur le plateau complet, cela fait $256 \times 256 \times 4 \approx 262{,}000$ variables avant la moindre contrainte. Ensuite : - **Exactement un placement par case.** Pour chaque case $c$, une clause « au moins un » sur tous ses placements, $\bigvee_{p,r} x_{c,p,r}$, plus des clauses « au plus un » interdisant toute paire, $\lnot x_{c,p,r} \lor \lnot x_{c,p',r'}$ pour des placements distincts. - **Exactement une case par pièce.** L'image miroir : pour chaque pièce $p$, une clause « au moins un » sur les cases qu'elle pourrait occuper, plus des clauses « au plus un » pour qu'elle ne soit placée qu'une fois. - **Appariement de bords.** Pour chaque adjacence intérieure et chaque placement dont le bord exposé montre la couleur $k$, interdire tout placement de la case voisine dont le bord en vis-à-vis n'est pas $k$ : une clause binaire $\lnot x_{c,p,r} \lor \lnot x_{c',p',r'}$ pour chaque paire en conflit. Un croquis 2×2 rend la troisième famille concrète. Les cases $A$ (en haut à gauche) et $B$ (en haut à droite) partagent un bord vertical ; le bord est de $A$ doit être égal au bord ouest de $B$. Pour chaque placement $(A,p,r)$ montrant la couleur est $k$, et chaque placement $(B,p',r')$ dont la couleur ouest n'est pas $k$, ajouter $\lnot x_{A,p,r} \lor \lnot x_{B,p',r'}$. Faire de même pour $A$/$C$ verticalement et pour les deux autres adjacences intérieures. Voilà tout ce qu'est la contrainte 3 : un grand tas de clauses binaires « ces deux placements ne peuvent pas être vrais tous les deux ». Le hic, c'est que le tas est énorme. Les clauses de conflit dominent, les encodages « au plus un » ajoutent leur propre explosion (l'approche naïve par paires est quadratique ; les encodages en échelle ou par commandant l'échangent contre des variables auxiliaires), et le résultat est une formule à des millions de clauses dont la structure ne donne presque rien à apprendre à la recherche guidée par les conflits. Cela a été tenté dès 2008 et les solveurs SAT complets s'enlisent sur le plateau complet ; Blackwood, parmi d'autres, a rapporté que SAT n'aidait pas. L'encodage est propre, le solveur n'est pas le goulot d'étranglement, c'est l'*instance* qui l'est. Voir [Encodages SAT et CSP](/fr/research/build/exact/sat-csp-encodings/) pour l'historique des jeux de tests et les cas où les verdicts SAT gagnent encore leur place comme preuves d'impossibilité sur de petites régions. ## Couverture exacte et liens dansants La vue par couverture exacte est plus soignée, et elle cache un piège qui fait trébucher presque tous ceux qui se tournent vers les liens dansants de Knuth. Posons 512 *items* : un par case (« la case $c$ est remplie ») et un par pièce (« la pièce $p$ est utilisée »). Chaque *option* est un placement $(c,p,r)$, et elle couvre exactement deux items : la case $c$ et la pièce $p$. Un ensemble d'options couvrant chaque item exactement une fois est un plateau où chaque case est remplie et chaque pièce utilisée une fois. C'est une instance de couverture exacte propre, et l'**Algorithme X** de Knuth avec liens dansants résout la couverture exacte à merveille. Voici le piège. Les contraintes 1 et 2 sont des conditions de couverture unique, ce qui est exactement ce qu'exprime la couverture exacte. Mais la contrainte 3, l'appariement des couleurs, n'est pas du tout une condition de couverture unique : un bord partagé n'est pas « utilisé une fois », il se voit « attribuer une couleur sur laquelle les deux voisins s'accordent ». L'Algorithme X ordinaire n'a aucun moyen de dire cela. On l'encode, on le lance, et on obtient des plateaux aux bords discordants, ou bien l'on tente de greffer des items supplémentaires et la sémantique de couverture unique nous résiste. Cette confusion précise a sa propre question sur le CS Stack Exchange. La solution est l'extension de Knuth lui-même, l'**Algorithme C**, pour XCC, la couverture exacte avec couleurs (TAOCP Volume 4B). À côté des items *primaires* (couverts exactement une fois), on ajoute des items *secondaires* qui peuvent être couverts un nombre quelconque de fois, *pourvu que toutes les options couvrant un item secondaire donné lui attribuent la même couleur*. On donne à chaque bord intérieur de la grille un item secondaire. Un placement qui expose la couleur $k$ sur un bord partagé attribue la couleur $k$ à l'item secondaire de ce bord. Deux placements ne peuvent alors coexister de part et d'autre du bord que s'ils le colorent de façon identique, ce qui est précisément la contrainte d'appariement de bords, désormais exprimée nativement. Un croquis 3×3 : 9 items de case et 9 items de pièce (primaires), plus 12 items de bord intérieur (secondaires, un par jonction horizontale ou verticale). Les placements de la case centrale touchent chacun quatre items de bord secondaires et doivent s'accorder en couleur avec les quatre voisins ; les placements d'une case de coin en touchent deux. L'Algorithme C faufile tout cela sans jamais produire de plateau discordant. Le point que les étudiants manquent : **la couverture exacte par DLX pour Eternity II requiert l'Algorithme C, pas l'Algorithme X.** La page [couverture exacte et liens dansants](/fr/research/build/exact/exact-cover-dlx/) déroule la construction XCC complète et montre où le DLX brille véritablement (petits plateaux, dénombrement exhaustif des solutions) par opposition aux cas où il s'enlise sur le 16×16. ## PLNE et clique maximale, brièvement Deux cadrages de plus, utiles surtout comme aiguillages : - **Programmation linéaire en nombres entiers.** Réutiliser les variables SAT comme entiers 0/1 $x_{c,p,r}$. Les contraintes 1 et 2 deviennent des égalités $\sum_{p,r} x_{c,p,r} = 1$ par case et $\sum_{c,r} x_{c,p,r} = 1$ par pièce. L'appariement de bords devient, pour chaque bord intérieur et chaque couleur $k$, une condition de liaison reliant les placements de couleur $k$ des deux voisins (une forme propre : une nouvelle variable binaire de couleur de bord $y_{e,k}$ avec $\sum_k y_{e,k} = 1$, les placements de chaque côté impliquant le $y$ correspondant). C'est une PLNE de faisabilité, sans objectif, et la relaxation linéaire est faible, si bien que la séparation-évaluation se comporte à peu près comme la recherche SAT. Voir [Relaxations linéaires](/fr/research/build/exact/lp-relaxations/). - **Clique maximale.** Construire un graphe dont les sommets sont les placements légaux et dont les arêtes joignent deux placements mutuellement compatibles (cases différentes, pièces différentes, et accord sur tout bord partagé). Un plateau complet est une clique de taille 256. C'est élégant sur le papier, mais le graphe est immense et les solveurs de clique ne s'en sortent pas mieux ; cela vaut d'être connu comme réduction, non comme attaque pratique. ## Combien pèse la formulation ? Une falaise mesurée Les sections précédentes se terminent sur une note décourageante : l'encodage est propre, l'instance est le mur. Cette affirmation méritait un chiffre, et le chiffrer l'a affinée dans une direction inattendue. Le banc d'essai est une famille de plateaux *plantés* : des instances cadrées, aux couleurs équilibrées, construites à partir d'une solution connue, avec cinq cases de la solution épinglées comme indices, notées selon la convention des bords appariés hors pourtour (une résolution complète à la taille $N$ vaut exactement $2N(N-1)$ bords appariés : 264 en 12×12, 480 en 16×16). Les plateaux plantés ne sont pas l'Eternity II canonique ; ils admettent vraisemblablement de très nombreuses solutions là où le vrai puzzle est conçu pour n'en avoir essentiellement qu'une. Ce qu'ils offrent, c'est une échelle d'instances résolubles par construction que deux paradigmes de recherche différents peuvent attaquer côte à côte. Sur ce banc, à 22 couleurs, une recherche en profondeur à redémarrages qui ne place que des correspondances exactes résout entièrement quatre graines 10×10 sur cinq (la plus rapide en 4 ms) et deux graines 11×11 sur cinq, puis zéro sur cinq en 12×12 et zéro à toutes les tailles au-dessus. L'échec n'est pas une affaire de budget. L'instance 12×12 de graine 1 marque 127 sur 264 après 20 secondes, après 45 secondes et après 120 secondes, tandis que le nombre de nœuds visités passe de 22 millions à 132 millions ; une instance 14×14 rampe de 236 à 240 sur 364 sur la même extension sextuple du budget. La recherche ne converge pas lentement ; elle est clouée. Confiez les instances identiques à CP-SAT avec un modèle structuré (une variable entière par case parcourant les identifiants de pièces sous une contrainte AllDifferent, des indices pièce-et-rotation canalisés par des tables Element vers des variables de couleur par côté, le tout posé en question de décision) et le mur se déplace. Quatre des cinq instances 12×12 tombent en 31,7 à 88,1 secondes (la cinquième dépasse le délai de 300 secondes), et l'une des deux instances 13×13 essayées tombe en 74 secondes, chaque plateau retourné étant revérifié indépendamment : distinction des pièces, conformité aux indices, décompte des bords recalculé. Ce sont des résolutions complètes vérifiées de plateaux qu'aucune graine de la DFS ne touche, quel que soit le budget. La falaise appartient au paradigme de recherche, pas aux plateaux. Le tour original de cette mesure tournait sur un générateur autorisant 26 couleurs intérieures, un réglage que le banc empaqueté ne peut pas produire (son générateur plafonne les couleurs intérieures à 22, le compte du vrai puzzle). À 26 couleurs, le contraste était plus net encore : CP-SAT a résolu entièrement 25 instances sur 25 aux tailles 10 à 14 avec des temps médians de 0,10 à 0,84 seconde, une demi-seconde en 13×13, et a terminé un 16×16 planté en 15 secondes environ, pendant que la falaise de la DFS se tenait un barreau plus haut, en 13×13. Ce même tour a aussi mesuré l'écart de formulation en isolation : sur une instance 12×12, un MIP générique sur binaires de placement avec lignes de somme à un, passé par la séparation-évaluation de HiGHS, a rendu 11 bords appariés sur 264 après 300 secondes ; CP-SAT a rendu les 264 sur la même instance en 0,42 seconde. Même problème, même machine, environ trois ordres de grandeur, et toute la différence tient à la façon d'écrire les contraintes. Mettre les deux réglages côte à côte fait apparaître un second résultat : la falaise bouge avec le nombre de couleurs, pour les deux paradigmes à la fois. À 26 couleurs, la DFS meurt en 13×13 et CP-SAT traverse un 16×16 planté en quelques secondes. À 22 couleurs, la DFS meurt un barreau plus tôt, en 12×12, et CP-SAT lui-même ralentit d'environ vingt fois à la médiane entre 11×11 et 12×12 puis commence à dépasser ses délais à partir de 12×12 : les sondes 14×14 et 16×16 butent toutes deux sur un plafond de 120 secondes. (Les grands barreaux étaient des sondes à graine unique, et les temps CP-SAT à 22 couleurs portent une part d'inflation due à un volet DFS partageant la machine, qui n'explique en rien l'écart avec les médianes sous la seconde à 26 couleurs.) Plus de couleurs, c'est un plateau plus contraint et une recherche plus facile pour tout le monde ; moins de couleurs tire les deux paradigmes vers le bas ensemble, si bien que des mesures prises à 26 couleurs avantagent tous les solveurs de la course. Le 16×16 planté sur lequel la sonde a échoué mérite d'être vu, montré ici comme sa solution construite : [16×16 planté, 480/480](https://eternity2.dev/viewer?puzzle=gen_16x16_c22_s1&puzzle_size=16&board_edges=aebaabgeabvbacvbadvcacrdadlcadodadidaeqdafneadgfacwdafscachfaabcbjcagmujvhpmvuohvtpurnttlrsnouvriphuqowpnluogqllwpqqsvgphkgvbackcgdauwsgpluwoqmlpjoqtikjsnnivvvnhmrvwhpmuuuhlutuqqkugguqgnhgcabndgdassrguihsmqkiokhqkjnknokjvkrormikpptmuroptrirkomruumohjsubaejdlearsulhqmskvpqhqkvnwpqknuwrlqnikrltjlkosnjiglsmoogmnjoslqneaclerdauhjrmiihpklikwlkprmwunprqnwnrgnnlgjgnvmglknvowskjkowqwpkcafwdjfajjgjiqqjlptqlnipmslnpowswjjonoljjttomsrtnwtssrowosmrpmisfafmfhdagvkhqjsvtinjitsilwntwjrwjvrjlkovtsvkrhqstquhojhqmkqjitrkfaftdufakstusuisnmvuslsmnrmlrsvrrhnsoomhvtloqvntutvvhkltqukkrmtufaemfhfatwhhirhwvtrrsjptmtujvtgtnvstmohvliionwhivqqwlomqkgpotljgeaflfqeahgqqhmngrprmpqhpuugqgiquslqihqrliimqhkjiqwwkmspwpqisjkjqfaekembaqipmnioirkwihvkkgntvqhhnqnshrwgnmvlwjgwvwqkgpwmqiliwjulleadububapssuohjswmuhkowmtnpohrtnspgrgnrplnvnwgpnkvvgmhlvihwhlnshdadnbkeasgtkjjigumvjwwwmpjgwtpojgujprvtuvruvptorvmmtlsomwigssopidafoegcatppgiltpvpwlwohpgiuoolhijroltigrujgiotljmkjtorkkgiirppmifabpcbaapeabtbaewcabhcacueacheaeocaegfacgcaflbacjfabkbafieabmdaebaad). > **Un témoin, compté dix fois** > > Le tour à 26 couleurs a aussi essayé dix familles heuristiques sur la falaise, d'un remplisseur naïf ligne par ligne à la propagation AC-3 et à l'élagage par déficit de Hall : six ont résolu entièrement le 12×12 et aucune n'a résolu le 13×13. Dix solveurs d'accord ressemblaient à dix preuves que les instances étaient le mur. C'en était une seule. Les dix s'engagent chronologiquement et gloutonnement sur une information locale, donc ils échouent ensemble pour la raison partagée, et le premier solveur d'un paradigme réellement différent a renversé la conclusion en une demi-seconde. L'accord de N solveurs de la même famille est un témoin à N voix. ## Où cela vous laisse Si vous êtes venu demander si la théorie de la NP-complétude rend cette instance prouvablement difficile, la réponse est qu'elle ne le fait pas, et ne le peut pas : les classes de complexité décrivent des familles, et ce plateau est une entrée fixée avec une réponse fixée. Le problème général d'appariement de bords est NP-complet, ce qui plafonne ce que tout solveur peut promettre lorsque $n$ croît, mais la difficulté que vous ressentez réellement est empirique : un espace large de $10^{557}$ au-dessus d'un ensemble de solutions quasi vide. Chaque encodage ci-dessus capture fidèlement le puzzle, et sur le 16×16 complet aucun ne le rend facile ; mais la falaise des plateaux plantés montre que le choix du formalisme n'a rien de neutre en deçà de cette échelle, où le même plateau peut être hors d'atteinte pour un paradigme et une résolution d'une minute pour un autre. Une fois le plateau encodé, le levier qui subsiste est la [cohérence d'arc](/fr/research/build/reduce/arc-consistency/) et un ordre de recherche avisé, ce dont s'empare la suite de cette section. ## À lire aussi - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. - [Encodages SAT et CSP](https://eternity2.dev/fr/research/build/exact/sat-csp-encodings/) — Écrire le puzzle sous forme de clauses et le confier à un solveur industriel : le geste évident, tenté dès 2008. Pourquoi les solveurs complets s'enlisent sur le plateau complet, et où leurs verdicts gardent toute leur valeur comme preuves d'impossibilité. - [Couverture exacte et liens dansants](https://eternity2.dev/fr/research/build/exact/exact-cover-dlx/) — Eternity II se formule proprement comme un problème de couverture exacte, et l'algorithme X de Knuth muni des liens dansants en est la machine classique. Là où il brille vraiment (petits plateaux, dénombrement exhaustif) et les deux raisons pour lesquelles il ne vient pas à bout du 16×16 : un arbre de recherche jamais réduit, et aucun crédit partiel. - [La cohérence d'arc, à partir d'AC-3](https://eternity2.dev/fr/research/build/reduce/arc-consistency/) — Le forward checking regarde un coup à l'avance ; la cohérence d'arc oblige la liste de candidats de chaque case à se défendre contre celle de chaque voisine, jusqu'à un point fixe. AC-3 de Mackworth, les raffinements optimaux qui ont suivi, ce que toute cette famille a réellement mesuré sur ce casse-tête, et où elle devient incorrecte. --- # La région difficile qu'on ne peut pas concevoir autrement > Remplissez un plateau dans un ordre fixe et les trois quarts du haut se posent librement, tandis que la difficulté s'entasse dans la bande que vous terminez en dernier. Sur quarante plateaux générés, tout le reste tombe dans la moitié basse à chaque fois ; mélangez l'ordre de remplissage et il se disperse, donc la région difficile est fabriquée par le balayage, pas cachée dans le plateau. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/irreducible-hard-region/ - Mise à jour: 2026-07-22 - Sujets: structure, search-space - Reproduire: `just research-irreducible-hard-region` --- Deux choses sont vraies de presque toute tentative de casser Eternity II en découpant le plateau en morceaux remplis tour à tour. Le premier morceau rempli se pose facilement. Le dernier, non. Que les morceaux soient des lignes, des bandes, des bandeaux, des blocs ou des anneaux concentriques, la difficulté ne s'étale pas sur eux ; elle se rassemble dans la région que la recherche atteint en dernier, et s'y dresse comme un mur. Cette page teste la version la plus nette de cette affirmation et la trouve vérifiée nettement, avec une nuance que la mesure rend évidente : la région difficile n'est pas un patch fixe du plateau attendant qu'on le trouve. Elle est fabriquée par l'ordre dans lequel vous remplissez, et elle atterrit là où cet ordre se termine. ## L'affirmation, et ses trois volets La conjecture complète, dans le carnet du projet, comporte trois volets. D'abord, **la difficulté se localise** : remplissez de façon séquentielle et le reste, les cases que la recherche ne parvient pas à poser, se concentre dans la dernière région. Ensuite, **cette région est trop grande pour être résolue exactement** : elle dépasse la fenêtre d'environ 112 cases où une complétion exacte revient encore en un temps raisonnable. Enfin, **elle est trop globalement couplée pour être achevée par une heuristique** : comme chaque pièce sert une seule fois, dépenser une pièce rare tôt dans la partie facile affame la partie difficile plus tard, si bien qu'aucune réparation locale n'atteint un nouveau plateau élevé. Seul le premier volet est un fait net qu'on lit directement sur un plateau. Les deux autres sont des plafonds liés à un solveur exact particulier et à la rareté propre à l'ensemble officiel de 22 couleurs, et le carnet lui-même les qualifie d'empiriques plutôt que de démontrés. Cette page reproduit donc le premier volet, la localisation, et porte les deux autres comme conjecture. La seule lecture qu'elle ajoute au carnet est que la localisation se comprend mieux comme une propriété de l'ordre de balayage que du plateau, ce que le contrôle ci-dessous rend inévitable. ## L'instrument, et pourquoi il est loyal La mesure part de zéro sur des plateaux encadrés, équilibrés en couleur et **à solution plantée**, construits par le générateur ensemencé du kit de départ : une solution parfaite existe forcément, donc tout blocage revient à la recherche et non à une instance insoluble. Pour chaque graine du générateur, le vérificateur construit un plateau 16x16 sans indices épinglés, puis lance sur lui deux fois la même recherche en profondeur à appariement exact avec redémarrages, une fois en ordre de cases row-major et une fois dans un ordre de cases aléatoire ensemencé, et lit deux nombres sur le partiel le plus profond que chaque bras atteint : - la **fraction de front**, la ligne remplie la plus profonde divisée par le côté du plateau, qui dit jusqu'où la partie facile est allée ; et - la **fraction de reste dans la moitié basse**, parmi les cases encore vides, la part qui se situe dans les lignes 8 à 15, qui dit où la difficulté a atterri. Les deux nombres sont définis pour n'importe quel ordre de remplissage, ce qui est précisément ce qui permet au bras aléatoire d'être un contrôle équitable face au bras row-major. Les scores sont ici donnés selon la convention des arêtes appariées (jointures intérieures seulement ; une solution 16x16 complète vaut 480), même si cette page ne revendique aucun record ; les statistiques de front et de reste relèvent de la géométrie des cases, pas du score d'arêtes. Pour situer les plateaux du projet face aux meilleurs de la communauté, voir la [page des records](/fr/research/records/). ## Ce que fait le balayage Exécuté sur Apple Silicon, un seul cœur, quarante plateaux fois deux bras en environ trois minutes au budget par défaut de 1,5 million de nœuds. La source du carnet est une synthèse de nombreuses expériences de décomposition plutôt qu'une seule mesure, si bien qu'elle n'engage aucun tableau de chiffres par graine pour un plateau du kit ; les nombres ci-dessous sont la forme que la conjecture prédit, et l'accord porte sur cette forme et son signe. Balayage de localisation, quarante plateaux 16x16 générés et encadrés, 22 couleurs, partis de zéro : | Quantité | Forme prédite par la conjecture | Mesuré, row-major | Mesuré, contrôle aléatoire | | --- | --- | ---: | ---: | | Plateaux entièrement résolus | aucun attendu (ce n'est pas un solveur) | 0 / 40 | 0 / 40 | | Fraction de front médiane sur les plateaux calés | les dix lignes et plus du haut se remplissent librement (au-dessus de 0,6) | 0,75 (12 lignes sur 16) | 0,0 (aucune ligne ne se remplit entièrement) | | Plage de la fraction de front | élevée | 0,6875 à 0,75 | sans objet | | Fraction de reste moyenne dans la moitié basse | proche de 1,0 (la région difficile est la dernière bande) | 1,000 | 0,503 | | Plateaux dont tout le reste est dans la moitié basse | tous | 40 / 40 | 0 / 40 | La recherche row-major atteint un front médian des trois quarts du plateau, douze lignes complètes sur seize, avant de ne plus pouvoir poser un appariement parfait. Cela correspond à l'image du carnet où les dix lignes et plus du haut se remplissent quasi librement. Et sur chacun des quarante plateaux, tout le reste se situe dans la moitié basse : la fraction de reste moyenne dans la moitié basse vaut exactement 1,000. ## Le contrôle, c'est tout l'enjeu Prenez les mêmes quarante plateaux et remplissez chacun dans un ordre de cases uniformément aléatoire au lieu de row-major. Il n'y a plus de dernière région, et le reste se disperse. La fraction de reste moyenne dans la moitié basse vaut 0,503, indiscernable d'un partage égal, et pas un seul des quarante plateaux ne concentre son reste en bas. La région difficile n'est donc pas quelque part sur le plateau à découvrir. Le même plateau a toute sa difficulté en bas sous un balayage row-major et n'en concentre nulle part sous un ordre aléatoire. La difficulté est réelle, mais elle est placée par la décomposition. C'est l'image en miroir de ce que montrent directement les plateaux records : leurs [quelques défauts s'entassent dans une bande](/fr/research/why/mismatch-geometry/) dont la position est fixée par la direction dans laquelle la recherche a rempli le plateau. Ici, on peut voir cette bande se créer et se déplacer en ne changeant rien d'autre que l'ordre de remplissage. ## Le blocage est un mur, pas un démarrage lent Une dernière vérification sépare un mur d'une recherche qui a simplement manqué de nœuds. Réexécutez huit des plateaux à quatre millions de nœuds, soit environ 2,7 fois le budget du balayage, et comparez le front aux mêmes graines de la série principale. | Quantité | Balayage à 1,5 million de nœuds | Réexécution à 4 millions de nœuds | | --- | ---: | ---: | | Fraction de front, graines 1 à 8 | 0,6875 à 0,75 | 0,6875 à 0,75 | | Fraction de reste moyenne dans la moitié basse | 1,000 | 1,000 | Le front ne monte pas avec le budget. Quatre des huit plateaux montent d'une ligne, un descend d'une ligne, et trois ne bougent pas du tout, le tout dans une seule ligne de gigue, et le reste demeure entièrement dans la bande basse. La recherche n'est pas lente ; elle est arrêtée, et elle est arrêtée à la dernière région qu'elle tente de remplir. C'est l'échec insensible au budget que la conjecture prédit, reproduit directement. ## Ce que cela règle et ne règle pas Cela reproduit uniquement le volet localisation de la conjecture. Les deux volets restants sont énoncés comme conjecture et ne sont pas mesurés ici, délibérément. Le volet **trop grande pour être résolue exactement** est propre à la machine et au solveur : la fenêtre exacte d'environ 112 cases est une propriété d'une recherche à arêtes strictes particulière, et un solveur exact plus puissant la déplacerait. Notre région difficile est constituée des quatre à cinq lignes du bas, environ 64 à 80 cases, ce qui se situe en réalité en dessous de la fenêtre d'environ 112 cases ; c'est plus petit que les environ 96 à 128 cases que décrit la conjecture, parce que ces plateaux générés se remplissent plus profondément que les décompositions de l'ensemble officiel que le carnet a synthétisées. Savoir si une région difficile dépasse un jour la fenêtre sur l'ensemble officiel est l'affirmation distincte et non mesurée. Le volet **trop globalement couplée** est un plafond empirique lié à la rareté de l'ensemble officiel, le couplage qui permet à une pièce rare dépensée en haut d' [affamer une case bien plus bas](/fr/research/why/piece-theft/). Nos plateaux proviennent du générateur encadré du kit, à solution plantée et admettant plausiblement de nombreuses solutions, là où le vrai casse-tête est réputé n'en admettre essentiellement qu'une. La localisation vaut pour tout plateau soluble sous un remplissage séquentiel, car le reste doit bien vivre quelque part et un balayage row-major le met en bas, si bien que la famille générée est un test adéquat de la localisation ; ce n'est pas un test de l'affirmation de couplage, qui exigerait l'ensemble officiel. Cet écart de famille d'instances explique pourquoi cette reproduction est qualitative plutôt qu'exacte : il n'y a pas de tableau source à reproduire au bit près, seulement un signe et une bande, et les deux se reproduisent. La leçon plus large tombe là où tombent les autres murs structurels. Une décomposition ne supprime pas la difficulté ; elle la déplace. C'est la même forme que le [mur de rigidité](/fr/research/why/rigidity-wall/), où un record est une île localement figée, et c'est pourquoi la [carte des méthodes](/fr/research/why/walls-and-methods/) montre chaque famille de décomposition s'arrêtant contre un mur à un endroit différent du plateau plutôt que d'en échapper à un. ## À lire aussi - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Quel mur arrête quelle méthode](https://eternity2.dev/fr/research/why/walls-and-methods/) — La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Où vivent les désaccords > Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/mismatch-geometry/ - Mise à jour: 2026-07-22 - Sujets: structure - Source: Annonce du record 469 de Peter McGavin : le plateau dont cette page analyse les onze arêtes non appariées (groups.io msg 10045, septembre 2020) — https://groups.io/g/eternity2/message/10045 --- Notez un plateau record arête par arête et un fait frappant apparaît : les désaccords ne sont pas dispersés. Le 469 de McGavin place la totalité de ses onze arêtes non appariées dans les cinq premières rangées (rangées 0 à 4) ; les rangées 5 à 15 sont localement parfaites. Le plateau est, de fait, une dalle impeccable de 11 rangées avec tous les dégâts balayés contre une seule arête. Notez maintenant de la même manière les meilleurs plateaux construits de zéro de ce projet. Les dégâts se retrouvent là encore dans une bande de cinq rangées, mais en bas. Les désaccords de KEYRING et de GAUNTLET siègent dans les rangées 11 à 15, les rangées 0 à 10 restant parfaites. C'est la même image retournée de haut en bas. ## Le voir sur les vrais plateaux Choisissez un plateau. La bande ombrée indique où tombent réellement ses désaccords, calculée en direct avec la règle de notation propre au moteur : les plateaux de la communauté en haut, ceux de ce projet en bas. > **[Figure]** Interactif : où les désaccords sont contraints de vivre — interactive: MismatchGeometryLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Prendre du recul : la bande est une loi du corpus Deux plateaux pourraient n'être qu'une anecdote. Agrégeons donc. Prenez tous les plateaux à haut score que ce projet a jamais archivés, soit 1 964 plateaux à 455 arêtes appariées ou mieux (convention des arêtes appariées ; la [page des records](/fr/research/records/) replace ces chiffres internes dans leur contexte), et marquez chaque jointure selon sa fréquence d'échec. La même image réapparaît sous forme de loi de fréquence. Les jointures qui relient les rangées 11 à 14 à leurs voisines cassent dans environ 38 à 49 % de tous les plateaux. La jointure la plus fragile de tout le plateau se trouve en rangée 12, colonne 2, brisée dans 49,4 % des cas ; les quatre suivantes (47,5 %, 47,3 %, 46,3 %, 46,0 %) appartiennent elles aussi à la rangée 12, et les vingt jointures les plus souvent brisées se situent toutes dans les rangées 11 à 13. Ce sont des décomptes exacts sur le corpus archivé, pas des échantillons. Une mise en garde, qui est en réalité le constat lui-même : chacun de ces 1 964 plateaux est sorti du pipeline propre à ce projet, qui remplit de haut en bas. La carte de chaleur n'est pas une propriété du puzzle ; c'est la signature du pipeline, écrite 1 964 fois. Un remplissage descendant dépense son budget de conflits en chemin, l'ensemble de contraintes devient trop tendu autour de la rangée 12, et cette couture craque dans la moitié des exécutions. Un solveur avec un autre ordre de remplissage déplacerait la couture, ce que montrent précisément les plateaux de la communauté dans la figure ci-dessus. ## Pourquoi cela bascule : l'ordre de balayage Le basculement n'est pas une coïncidence ; c'est l'empreinte de la manière dont chaque plateau a été construit. Une recherche qui remplit le plateau du bas vers le haut dépense tôt ses placements parfaits, en bas, et se voit contrainte d'absorber tous les conflits accumulés dans les dernières rangées qu'elle atteint : le haut. Une recherche qui remplit du haut vers le bas fait exactement l'inverse et entasse les dégâts en bas. Les désaccords finissent toujours agglutinés contre l'arête sur laquelle le solveur a terminé. Même puzzle, même type de plateau, ordre de construction opposé. Une nuance que le récit à deux solveurs dissimule : la bascule se joue par exécution, pas par outil. Au sein même de la production de ce projet coexistent deux familles de plateaux quasi record à géométrie inversée. Dans l'une (meilleur plateau à 458 arêtes appariées, un ancien meilleur score interne ; voir la [page des records](/fr/research/records/) pour le contexte), tous les désaccords intérieurs occupent les cinq dernières rangées de l'intérieur et les neuf premières rangées intérieures sont parfaites. Dans l'autre (meilleur à 457), les vingt désaccords intérieurs occupent tous les rangées 1 à 4, les rangées 5 à 14 restant parfaites. Les meilleurs plateaux des deux familles ne partagent que 7 placements sur 256 (2,7 %) : ce sont des plateaux presque disjoints, pas deux arrangements d'un même cadre. Et les deux sont localement figés ; la programmation en nombres entiers exacte, appliquée à chaque amas de dégâts jusqu'à une trentaine de cellules, n'améliore ni l'un ni l'autre d'une seule arête. Ce sont des familles que nous avons échantillonnées, quelques plateaux chacune : la partition elle-même est une observation, pas un recensement. Mais elle adoucit le récit : l'ordre de balayage est la force dominante, et pourtant ce qui fixe réellement la bande, c'est la trajectoire de l'exécution individuelle, le bassin dans lequel elle est tombée. Même pipeline, bandes opposées. ## La même bande, sous un objectif différent Le motif n'est pas un artefact de notre façon de noter. Certains solveurs optimisent tout autre chose : non pas les arêtes appariées sur un plateau complet, mais le plus grand nombre de pièces plaçables sans aucun conflit, quitte à laisser des trous plutôt que des désaccords. Poursuivez cet objectif et les trous atterrissent au même endroit. Le plateau « Only seven holes » de Louis Verhaard place 249 des 256 pièces sans conflit, et les sept trous siègent tous dans les rangées 1 à 4, la bande du haut encore une fois. Laurent Zamofing, atteignant un plafond similaire en 2026 en recombinant les plateaux record de la communauté, a relevé la même chose : « le résidu non résolu tombe toujours dans cette bande du haut » ([msg 11901](https://groups.io/g/eternity2/message/11901)). Deux objectifs qui ne partagent rien d'autre que le puzzle, et les dégâts résiduels se rassemblent contre la même arête. C'est l'ordre de construction, et non la règle de notation, qui décide où se loge la difficulté. (Davantage sur cette variante sur la [page des variantes](/fr/research/build/variants/).) ## La forme des dégâts Les dégâts ont une forme constante, pas seulement un lieu constant. Sur chaque plateau quasi record que nous avons profilé, le graphe des arêtes en désaccord est une forêt : il ne referme jamais de boucle. Et à mesure que les plateaux s'améliorent, les dégâts se fragmentent. Les plateaux intermédiaires, entre 444 et 447 (arêtes appariées), portent 24 à 26 désaccords répartis en cinq à dix amas, le plus grand couvrant 13 à 15 cellules. Trois plateaux à 458, trouvés indépendamment, partagent une empreinte identique : 17 désaccords en deux amas seulement, le plus grand de 25 cellules ; très probablement un même bassin trouvé trois fois. Un plateau à 459 se scinde en quatre petits amas, le plus grand de 10 cellules à peine. Les meilleurs plateaux portent un résidu plus petit et plus dispersé. Cela suggère une conjecture, et rien de plus : l'amélioration procéderait en fragmentant les dégâts jusqu'à ce que chaque fragment soit assez petit pour être réparé localement. La concentration elle-même se mesure. Comprimez la densité de désaccords par cellule avec une transformée de Fourier bidimensionnelle en ne gardant que 1 % des coefficients : des dégâts bien concentrés se reconstruisent avec une faible erreur, des dégâts dispersés non. Sur cette échelle, un plateau à 457 en particulier est plus concentré (erreur de reconstruction 0,145) que les trois plateaux à 458 (0,236 chacun, identiques : le même bassin, encore) et fait quasiment jeu égal avec le 459 (0,148), tandis que les plateaux intermédiaires se situent entre 0,32 et 0,34. Le corpus est petit (une dizaine de plateaux), mais deux mesures structurelles indépendantes confirment le classement, et cela suggère une hypothèse à garder en tête : la qualité structurelle serait un axe en partie orthogonal au score brut. Un 457 peut être plus proche de la forme d'un record qu'un 458. ## Rien ne tombe sur la bordure Répartissez les 480 jointures d'un plateau en trois classes : 60 jointures bordure-bordure le long de l'anneau, 56 jointures où l'anneau rencontre l'intérieur, et 364 jointures intérieur-intérieur. Comparez le 469 de McGavin avec un plateau de ce projet monté à 444 arêtes appariées sur une bordure équivalente : la décomposition raconte deux fois la même histoire. Tous deux réalisent un 60 sur 60 parfait sur l'anneau et 55 sur 56 sur la couture. La totalité de l'écart de 25 arêtes est intérieur-intérieur, 354 sur 364 contre 329 sur 364. (Deux plateaux seulement : lisez ceci comme une illustration de la décomposition, pas comme une loi du corpus.) Les cinq couleurs réservées au cadre forment un cycle autonome que toute recherche compétente sature ; les dix-sept couleurs intérieures sont là où mord la rareté. Une sonde plus tranchante suggère que la bordure ne porte même pas l'information. Gelez uniquement la bordure du meilleur plateau de ce projet et laissez un remplissage glouton compléter l'intérieur : il n'atteint que 204 à 209 arêtes appariées, la même plage qu'une bordure valide aléatoire (202 à 214). Gelez plutôt les rangées du haut et le remplissage grimpe régulièrement : 209 sans rien geler, 258 avec quatre rangées, 334 avec huit, 364 avec dix, 406 avec douze, 424 avec treize, et le score complet avec les seize. Une seule politique de complétion gloutonne a été utilisée ; traitez donc cela comme une sonde, pas comme une loi. Mais sous ce remplissage, l'identité d'un grand plateau vit dans le squelette intérieur de sa douzaine de premières rangées, pas dans son cadre. ## La bande des dégâts est la bande de la liberté La bande du bas n'est pas seulement là où les plateaux de ce projet cassent ; c'est là où ils divergent entre eux. Sur 421 plateaux complets à 455 arêtes appariées ou mieux (tous issus, là encore, d'une même famille de pipeline), comptez combien d'arrangements distincts chaque rangée présente à travers le corpus. Les rangées 0 à 11 affichent chacune 39 à 63 arrangements distincts, soit environ 9 à 15 % de plateaux uniques dans cette rangée. Les rangées 12 à 15 bondissent à 131 ou 132 chacune, environ 31 % : trois fois plus de diversité. Les rangées où vivent les désaccords sont aussi celles où les plateaux quasi record diffèrent le plus les uns des autres. Zoomez sur quatre plateaux distincts atteignant tous 459 arêtes appariées et la même partition apparaît cellule par cellule. Seules 3 des 256 cellules sont identiques sur les quatre (les deux coins supérieurs plus une cellule de l'anneau de bordure) ; 212 cellules basculent entre exactement deux placements ; et les 24 cellules qui diffèrent sur les quatre plateaux se logent entièrement dans les rangées 13 à 15 (neuf, dix et cinq cellules ; aucune dans les rangées 0 à 12). Dans les quatre plateaux de score égal que nous avons comparés, toute la variation véritable vit dans la bande des dégâts. Un contraste mérite une phrase : le réarrangement qui sépare l'un de ces plateaux du 469 de McGavin s'étend sur tout l'intérieur de façon à peu près uniforme, quatre à neuf cellules dans chaque rangée de 1 à 14. Passer d'un plateau à un autre de même score est un remaniement de la bande du bas ; passer à un plateau réellement meilleur exige de reconstruire partout (la [page des cycles sigma](/fr/research/why/sigma-cycles/) rend cela précis). Le mécanisme derrière la diversité est le même que derrière les dégâts : les dernières rangées remplies absorbent à la fois les conflits accumulés et la liberté accumulée. Tout ce qui est en amont est squelette ; la bande du bas est là où les complétions distinctes à haut score bifurquent. ## Ce que cela nous apprend C'est la forme visible de deux faits plus profonds. D'abord, les grands plateaux sont réellement quasi complets : l'écart jusqu'à 480 est concentré, non diffus, ce qui explique pourquoi la programmation en nombres entiers les trouve localement figés partout, sauf dans cette unique bande (le mur de rigidité). Ensuite, cela dit que la fin de partie est toute la partie : les rangées que vous remplissez en dernier sont celles où le puzzle vous fait payer, si bien que l'ordre dans lequel vous cherchez décide où atterrit la difficulté. C'est la même leçon que la course de chemins de l'espace de jeu vous fait ressentir, ici inscrite dans la structure de chaque plateau record. Deux sondes rendent ces deux faits concrets. La première : un ancien meilleur plateau de ce projet à 459 arêtes appariées montre le motif sous sa forme la plus pure. Ses 21 désaccords siègent tous dans les rangées 12 à 15, les 192 cellules des rangées 0 à 11 sont parfaites, et les défauts forment une unique région connexe sur les quatre dernières rangées. Le remède évident consiste à épingler les douze rangées parfaites et à ne rechercher que le bas. Cette recherche meurt en quelques millisecondes, vers la profondeur 211 : étant donné ces engagements du haut, 459 est l'optimum. (Un seul plateau, une seule configuration de recherche ; l'épuisement, lui, est exact.) La région parfaite n'est pas une réserve en attente. Elle est dépensée : chaque degré de liberté en amont a été consommé pour la rendre parfaite, ce qui explique pourquoi la bande résiduelle ne peut pas être réparée sur place, et pourquoi améliorer ce plateau a fini par exiger des mouvements de destruction-réparation traversant tout le plateau. La seconde sonde est le test miroir sur le 469 de McGavin, dont les dégâts se cachent en haut. Épinglez ses 14 rangées du haut et laissez une recherche de destruction-réparation recompléter le bas : elle reconstruit le 469 entier. Épinglez ses 14 rangées du bas et recomplétez le haut : elle n'atteint que 462, sans seuil net en chemin (443, 453, 454, 462 à mesure que le bloc épinglé passe de onze à quatorze rangées). Et épingler quinze rangées du bas fait pire (460) que quatorze, car geler davantage le plateau supprime le jeu dont la recherche avait besoin pour absorber le haut difficile. C'était une sonde rapide à configuration unique (une graine, soixante secondes de réparation par point) : tenez les chiffres exacts avec prudence ; la direction de l'asymétrie, elle, avait été prédite avant l'exécution et confirmée par elle. La lecture : la bande où vivent les désaccords est exactement la partie du plateau qui le définit, et le reste s'en déduit. Pour cette famille de plateaux, l'écart au-dessus de 469 se lit comme un problème des cinq rangées du haut (une interprétation, pas un théorème). La bande que votre recherche garde pour la fin n'est pas seulement là où vous payez ; c'est là que se fait le travail irremplaçable. > **Note** > > Les décomptes par rangée et la bande surlignée sont calculés dans votre navigateur à partir des vraies arêtes du plateau (la même règle de notation que celle du moteur), et non placés à la main. Le constat sous-jacent et l'explication par l'ordre de balayage sont consignés dans le carnet de laboratoire du projet. ## À lire aussi - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [STAGED](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/staged/) — Construire tout le plateau depuis zéro, sans cadre pré-posé, par étapes, en laissant la bordure émerger en dernier des pièces restantes. - [Quel mur arrête quelle méthode](https://eternity2.dev/fr/research/why/walls-and-methods/) — La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Aucun coup forcé > La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/no-forced-moves/ - Mise à jour: 2026-07-01 - Sujets: structure, search-space - Reproduire: `just research-no-forced-moves` - Source: Aucun coup forcé : article, source et résultats (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/no-forced-moves --- Bar, BarChart, CartesianGrid, ResponsiveContainer, Tooltip, XAxis, YAxis, } from "recharts"; Chacune des 196 pièces intérieures compte entre 73 et 137 autres pièces qui peuvent légitimement se placer à sa droite (en dénombrant les partenaires de droite, comme le fait le graphique ci-dessus). La pièce typique dispose de plus d'une centaine d'options. Pas une seule pièce n'est jamais contrainte à un unique choix. C'est le revers des motifs interdits. Là, presque toutes les combinaisons de pièces sont impossibles. On pourrait croire que toutes ces règles finiraient par acculer les pièces à une position unique. Il n'en est rien : les contraintes excluent des combinaisons sans jamais acculer une pièce individuelle, si bien qu'un solveur ne se voit jamais offrir de coup gratuit et forcé sur lequel bâtir.
{data.forcedPieces}
pièces contraintes à une seule option
{data.minPartners}–{data.maxPartners}
partenaires par pièce (du min au max)
{data.meanPartners}
partenaires en moyenne
## Combien de voisines chaque pièce autorise Les 196 pièces intérieures, réparties selon le nombre de voisines de droite que chacune accepte. La distribution tout entière se tient bien loin de un. > **[Interactive: PartnerHistogram]** Rendered on the canonical page (link above); not shown in this markdown export. ## À l'œuvre sur un vrai casse-tête Le moteur remplit quelques cases ; puis on dénombre, en direct, combien de pièces conviennent légitimement à la suivante. Le compte ne tombe presque jamais à un. > **[Figure]** Interactif : nombre de candidats, case après case — interactive: ForcedMovesLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pourquoi c'est important Placez ce constat aux côtés des motifs interdits et la véritable forme de la difficulté se dessine. Localement, le casse-tête paraît lâche : n'importe quelle pièce s'accommode d'une foule d'autres, si bien qu'il n'y a rien à propager ni aucune chaîne de coups forcés à exploiter. Globalement, presque toutes les combinaisons sont illégales. La dureté loge dans cet écart : beaucoup de liberté locale, presque aucune cohérence globale. Un solveur doit enchaîner une longue suite de choix d'apparence libre qui ne se révèlent erronés que bien plus tard. ## À lire aussi - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [La cohérence d'arc, à partir d'AC-3](https://eternity2.dev/fr/research/build/reduce/arc-consistency/) — Le forward checking regarde un coup à l'avance ; la cohérence d'arc oblige la liste de candidats de chaque case à se défendre contre celle de chaque voisine, jusqu'à un point fixe. AC-3 de Mackworth, les raffinements optimaux qui ont suivi, ce que toute cette famille a réellement mesuré sur ce casse-tête, et où elle devient incorrecte. --- # Le casse-tête n'a pas de fonction de hauteur > Empruntez l'astuce du physicien qui rend les défauts cristallins solubles et tentez de transformer un joint dépareillé en dislocation dotée d'une charge conservée. Cela échoue de trois façons : une hauteur scalaire est aveugle aux ruptures, l'ensemble des ruptures forme des chaînes ouvertes et non des boucles fermées, et le courant orienté par couleur n'est pas conservé. Seul un bit de parité non signé survit. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/no-height-function/ - Mise à jour: 2026-07-23 - Sujets: structure, search-space - Source: Vérificateur sans fonction de hauteur : article, code source Rust et tableau de résultats par plateau (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/no-height-function --- Il existe une idée empruntée qui, si elle tenait, changerait la façon d'attaquer ce casse-tête. Dans la physique statistique des cristaux, un pavage porte une **fonction de hauteur** : un nombre vivant sur les faces et qui monte ou descend d'une quantité fixe à travers chaque arête. Quand le pavage est parfait, la hauteur est univaluée. Un défaut est un point où parcourir une petite boucle en additionnant les pas ne vous ramène pas au point de départ ; le reste est une charge conservée (les physiciens l'appellent un **vecteur de Burgers**), et les défauts ne peuvent être créés ou détruits que par paires qui s'annulent. C'est ce dernier fait qui est le trésor. C'est lui qui autorise le **mouvement de ver** : une réécriture étalée sur le réseau mais simple dans l'espace des hauteurs, qui fait glisser deux défauts l'un vers l'autre jusqu'à ce qu'ils s'annulent. Notez un plateau complet d'Eternity II en comptant ses joints internes appariés sur 480 (la convention des arêtes appariées utilisée dans tout ce wiki ; la [page des records](/fr/research/records/) replace dans son contexte les nombres qui suivent). Un joint dépareillé est une **rupture**. Si les ruptures étaient des dislocations dotées d'une charge orientée conservée, il existerait un mouvement non local et fondé qui abaisse le nombre de ruptures en faisant marcher une paire d'entre elles l'une vers l'autre pour les annihiler, exactement le genre de mouvement que la recherche par simple échange ne peut voir. Cette page consigne pourquoi cet espoir ne survit pas au contact d'un vrai plateau. L'échec n'est pas affaire de goût. Ce sont deux faits concrets mesurables sur n'importe quel plateau, plus un troisième qui n'a besoin d'aucun plateau, et le vérificateur du sujet de reproduction mesure les deux premiers sur les plateaux records consignés de ce projet. ## La hauteur scalaire est aveugle dès le départ Prenons d'abord la version la plus naïve : placez un seul nombre sur chaque case et lisez le « pas » à travers un joint comme la différence des deux nombres de cases. Parcourez les quatre cases autour d'un coin intérieur de la grille et additionnez les quatre pas. Le nombre de chaque case entre dans la boucle une fois avec un plus et une fois avec un moins, donc la somme est **zéro**, toujours, pour toute affectation de nombres et quelles que soient les ruptures. Une rupture vit sur un joint ; elle ne change jamais la somme de boucle d'aucun coin. Une hauteur scalaire par case ne peut donc pas détecter une rupture du tout. Ce n'est pas qu'elle les détecte mal ; elle y est structurellement sourde. Cette partie est une identité en une ligne, elle est donc énoncée ici plutôt que mesurée. ## L'ensemble des ruptures est fait de chaînes ouvertes, pas de boucles fermées La correction du physicien consiste à cesser d'utiliser les valeurs des cases et à placer plutôt le pas sur un joint **exactement quand ce joint est rompu**. Alors la somme de boucle autour d'un coin de la grille compte les joints rompus touchant ce coin, pris modulo deux. La hauteur n'est univaluée que si chaque coin touche un nombre pair de ruptures, c'est-à-dire seulement si les ruptures forment des boucles fermées sur la grille des coins. Ce n'est pas le cas. Sur chaque plateau mesuré, des dizaines de coins touchent un nombre **impair** de ruptures. Dans l'image cristalline, ces coins impairs sont des **cœurs** de dislocation, les bouts libres de chaînes de ruptures ouvertes. Une hauteur ne peut pas se refermer autour d'un bout libre, elle ne peut donc pas exister globalement. Le décompte de ces cœurs est le premier nombre rapporté par le vérificateur, et il reste grand même sur les meilleurs plateaux : | Plateau (ce projet) | Arêtes appariées | Ruptures | Cœurs de degré impair | Couleurs à courant déséquilibré | | --- | ---: | ---: | ---: | ---: | | meilleur en arêtes appariées, 463 | 463 | 17 | 22 | 10 | | un plateau 460 | 460 | 20 | 22 | 9 | | un plateau 458 | 458 | 22 | 34 | 15 | | un plateau 460 antérieur | 460 | 20 | 26 | 12 | Les quatre sont des scores en arêtes appariées, revérifiés par le vérificateur avant que la topologie ne soit mesurée ; un plateau dont la valeur revérifiée diverge de celle consignée est refusé d'emblée, de sorte que les nombres ci-dessus décrivent toujours un plateau de qualité connue et vérifiée. Le meilleur d'entre eux ne se tient qu'à 17 ruptures d'une hypothétique solution et porte encore 22 cœurs à chaînes ouvertes. L'obstruction ne s'adoucit pas à mesure qu'un plateau approche d'une solution, et c'est là tout le propos : il n'existe aucun plateau près du sommet où les boucles se referment tranquillement. ## Le courant orienté n'est pas conservé Une dernière échappatoire mérite d'être écartée. Peut-être que résoudre les ruptures couleur par couleur sauve une charge conservée. Pour une seule couleur, orientez chaque joint à demi rompu (un joint dont exactement un côté montre cette couleur, ce qui est nécessairement une rupture) comme une flèche pointant de la case porteuse de la couleur vers sa voisine non appariée, et additionnez les flèches en un vecteur par couleur sur tout le plateau. Un courant réellement conservé sommerait à **zéro**. Ce n'est pas le cas. Sur chaque plateau, plusieurs couleurs ont un total non nul, listé dans la dernière colonne ci-dessus : entre 9 et 15 des 22 couleurs portent un courant déséquilibré, selon le plateau. La raison est structurelle, et elle explique pourquoi aucune ingéniosité n'y remédie. Sur une solution réelle, chaque arête colorée est appariée à une arête de la même couleur, il n'y a donc pas de joint à demi rompu et le courant de chaque couleur est trivialement nul. Un joint à demi rompu est précisément une demi-arête **non appariée**, une demi-arête dont le partenaire manque, de sorte que sa flèche n'a rien contre quoi s'annuler. La somme déséquilibrée n'est pas une erreur de comptabilité ; c'est la signature du partenaire manquant. À titre d'orientation seulement, une exécution antérieure et indépendante du carnet a mesuré les mêmes décomptes de cœurs sur trois plateaux différents (un plateau 451, un 463 et un 458) et a obtenu **28, 22 et 32** cœurs impairs ; les quatre plateaux présentés ici se situent à **22, 22, 34 et 26**, exactement dans le même régime, le plateau 463 correspondant à 22 des deux côtés. Les couleurs et signes précis qui ressortent déséquilibrés sont des étiquettes liées à la façon dont un plateau particulier a été numéroté et n'ont aucun sens propre ; seul le décompte des couleurs déséquilibrées, et le fait qu'il ne soit jamais nul, est le contenu reproduit. Ce sont les propres plateaux de ce projet, bien en dessous des meilleurs de la communauté, 470 sous la convention de l'indice central et 464 avec les cinq indices posés (là encore, la [page des records](/fr/research/records/) conserve ce contexte) ; ils sont utilisés ici parce que l'obstruction doit être vérifiée sur un vrai plateau à haut score de l'instance officielle, non sur un petit plateau généré où elle serait soit vide soit hors instance. ## Ce qui survit est un unique bit Réunissez les trois échecs. Une hauteur scalaire est sourde aux ruptures ; l'ensemble des ruptures est fait de chaînes ouvertes aux dizaines de bouts libres ; le courant orienté par couleur ne s'équilibre pas. Toute route vers une hauteur à vecteur de Burgers est fermée. Ce qui reste est bien plus faible qu'une hauteur : le seul invariant conservé de l'ensemble des ruptures est une **parité par couleur non signée**, un bit par couleur (un élément d'un espace de dimension 22 sur le corps à deux éléments). Un bit enregistre si le décompte de joints à demi rompus d'une couleur est pair ou impair ; il n'a ni direction ni magnitude. Un bit n'est la holonomie d'aucune fonction de hauteur, et aucun mouvement de ver ne peut se construire dessus. Voilà le résultat négatif, et il vaut la peine d'être énoncé clairement car l'idée qu'il tue est réellement séduisante : l'image des dimères et défauts est fermée du côté des ruptures, et avec elle le rêve d'un mouvement non local net qui fait marcher les défauts jusqu'à l'annihilation. L'intuition physique qu'il laisse debout est plus prometteuse et vit ailleurs : la bonne sortie d'un plateau localement figé (voir le [mur de rigidité](/fr/research/why/rigidity-wall/)) est un **mouvement d'amas corrélé**, plusieurs tuiles tournées ensemble, plutôt qu'une édition d'un seul site. Ce récit compagnon est un résultat distinct et n'est pas mesuré ici. Cela épouse aussi la forme du casse-tête telle qu'on la voit sur les plateaux eux-mêmes. Les ruptures ne se dispersent pas ; elles [s'entassent dans une seule bande](/fr/research/why/mismatch-geometry/) et le graphe des arêtes dépareillées est toujours une forêt, ne fermant jamais de boucle, ce qui est le même fait de chaîne ouverte que cette page démontre impossible à refermer. Le bit de parité survivant est un cousin de la loi de comptage derrière [pourquoi 479 est impossible](/fr/research/why/parity-defect-floor/) : les deux sont ce que l'on obtient quand un invariant orienté s'effondre en un invariant non signé sur le corps à deux éléments. La direction est exactement ce que cette instance refuse de vous donner. ## Vérifiez par vous-même Le vérificateur charge chaque plateau consigné via l'analyseur de plateau du kit de démarrage, le renote avec la règle canonique (et refuse tout plateau dont la valeur renotée diverge de son score consigné), puis fait une passe linéaire pour compter les cœurs de degré impair et les courants par couleur déséquilibrés. Il est déterministe, n'utilise aucun aléa, s'exécute en bien moins d'une seconde sur un seul cœur, et sa sortie est stable au bit près d'une exécution à l'autre. L'[article, le code source Rust et le tableau de résultats sont sur GitHub](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/no-height-function), et le bloc de reproduction de cette page pointe vers le même sujet. Deux réserves de portée, que la trouvaille énonce clairement à son propre sujet : ceci est une reproduction **qualitative**. Les décomptes exacts de cœurs et les sommes de courant sont des fonctions du plateau précis, ils se lisent donc comme « dans le même régime que », jamais comme une correspondance au bit près avec un tableau antérieur ; et l'obstruction de la hauteur scalaire de la première section est une identité démontrée, affirmée plutôt que recalculée. ## À lire aussi - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - [Pourquoi 479 est impossible](https://eternity2.dev/fr/research/why/parity-defect-floor/) — Un argument de comptage sur le jeu de pièces officiel interdit un score d'exactement 479/480 : les demi-arêtes de chaque couleur viennent en nombre pair, et un unique raccord cassé laisserait deux comptes impairs. Le plancher sous le parfait est 478, et au plus 76 quasi-solutions à un coup peuvent entourer une solution. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Pourquoi 479 est impossible > Un argument de comptage sur le jeu de pièces officiel interdit un score d'exactement 479/480 : les demi-arêtes de chaque couleur viennent en nombre pair, et un unique raccord cassé laisserait deux comptes impairs. Le plancher sous le parfait est 478, et au plus 76 quasi-solutions à un coup peuvent entourer une solution. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/parity-defect-floor/ - Mise à jour: 2026-07-22 - Sujets: structure, search-space - Source: David Eddy ouvre le fil Parity : le nombre d'arêtes de chaque type est pair, et la conséquence sur la dernière pièce (msg 332, juin 2007) — https://groups.io/g/eternity2/message/332 - Source: L'exemple détaillé de Christophe Weibel d'une dernière pièce qui ne correspond pas à son trou (msg 335) — https://groups.io/g/eternity2/message/335 - Source: Le verdict de Brendan Owen sur la parité dans E2 : correcte par construction, utile seulement vers la fin d'une recherche (msg 346) — https://groups.io/g/eternity2/message/346 - Source: Plancher de défaut par parité : article, source du vérificateur et résultats du recensement (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/parity-defect-floor --- Classez les plateaux complets par score, en comptant les raccords internes appariés sur 480 (la convention arêtes-appariées utilisée partout dans ce wiki), et l'échelle semble continue : barreau après barreau, chacun occupé par un plateau que quelqu'un a construit. Elle a exactement un trou. Aucun placement complet légal des 256 pièces ne marque 479. C'est un théorème sur le jeu de pièces publié, démontrable par simple comptage, et cette page déroule l'argument entier : la parité qui l'impose, le plancher de défaut de 2 qui en découle, et le recensement qui borne le nombre de quasi-solutions à un coup autour de toute solution. C'est aussi une entrée de [la moisson de théorèmes](/fr/research/why/theorem-sweep/), le tour d'horizon de ce qui se démontre à partir du sac avant toute recherche. ## Compter les demi-arêtes 256 tuiles à quatre bords portent 1024 demi-arêtes. Le gris du cadre en occupe 64, exactement le nombre d'emplacements tournés vers l'extérieur sur le pourtour (16 par côté). Les 960 restantes portent les 22 couleurs, et le recensement est remarquablement pair : | Groupe de couleurs | Demi-arêtes | | --------------------------------------- | ----------: | | Bord gris du cadre | 64 | | Cinq couleurs de jonction du cadre (1 à 5) | 24 chacune | | Cinq couleurs intérieures (6 à 10) | 48 chacune | | Douze couleurs intérieures (11 à 22) | 50 chacune | Chaque compte coloré est pair. Le total coloré, 960, vaut exactement deux fois le nombre de raccords internes ($2 \times 16 \times 15 = 480$) : dans un placement complet à cadre légal, où les 64 demi-arêtes grises regardent vers l'extérieur, les demi-arêtes colorées remplissent exactement les 960 places des raccords internes, sans reste. Rien de tout cela ne dépend de la position des pièces. Ce sont des propriétés du sac. Un raccourci plaisant se cache ici : la parité aurait pu être prédite sans examiner une seule pièce. Les concepteurs garantissent qu'une solution existe, et un plateau résolu apparie chaque demi-arête colorée avec une partenaire de même couleur, donc le compte de chaque couleur vaut deux fois son nombre de raccords, pair par définition. Le recensement ne fait que confirmer sur le jeu réel ce que la solvabilité promettait déjà. ## L'argument, en quatre lignes Fixez un placement complet à cadre légal (chaque bord tourné vers l'extérieur est gris) et fixez une couleur $c$. Chacun des 480 raccords internes montre deux demi-arêtes. Certains raccords montrent $c$ des deux côtés, d'autres d'un seul. En comptant les demi-arêtes de $c$ : $$h(c) = 2 \cdot \#\{\text{raccords montrant } c \text{ deux fois}\} + \#\{\text{raccords montrant } c \text{ une fois}\}.$$ Puisque $h(c)$ est pair, le nombre de raccords montrant $c$ exactement une fois est pair aussi. Cela vaut pour toutes les couleurs à la fois, dans tout placement complet, résolu ou cassé. Supposons maintenant un placement à 479. Il a exactement un raccord cassé, et un raccord cassé montre deux couleurs différentes, disons $a$ et $b$ (si les deux côtés s'accordaient, ce serait un appariement ; le gris est exclu, puisque ses 64 demi-arêtes regardent vers l'extérieur). Tout autre raccord est apparié et montre sa couleur deux fois. Donc exactement un raccord montre $a$ exactement une fois. Un est impair. Cela contredit la parité de $h(a)$, et le placement ne peut pas exister. ## Le plancher sous le parfait est 478 Notons le défaut d'un plateau comme $480$ moins son score. La parité interdit le défaut 1 et n'interdit rien d'autre : au défaut 2, les comptes impairs peuvent s'absorber par paires, et l'argument se tait. Tout placement complet légal est donc soit une solution, soit rate au moins deux raccords. Un dernier fait recensé ferme l'échappatoire restante : aucune tuile d'Eternity II n'est fixée par une rotation (0 sur 256), donc un plateau ne peut pas marquer 480 en différant d'une solution seulement par une tuile tournée sur place. Score 480 veut dire solution. Tout le reste veut dire 478 ou moins. Pour les classements d'aujourd'hui, le barreau manquant est académique : les meilleurs plateaux complets de la communauté sont à 470 sous la convention indice-central-seul et à 464 avec les cinq indices posés ([la page des records](/fr/research/records/) tient l'échelle complète). Mais il change ce que « presque résolu » peut jamais vouloir dire. Il n'y a pas de 479 par où passer en route vers 480. Le dernier pas de l'ascension va de 478 à 480, deux raccords d'un coup, et toute méthode qui améliore les plateaux un raccord à la fois est structurellement incapable de le franchir. ## La coquille des 478 est clairsemée Une solution existe ; le casse-tête a été construit à partir d'elle. Qu'est-ce qui se trouve juste à côté, à 478 ? Un plateau à un coup d'une solution doit venir d'un coup qui casse exactement deux raccords, et seules deux sortes de coups uniques peuvent le faire. Les deux se comptent dans le sac : - **Échanges de jumelles.** Deux tuiles intérieures qui s'accordent, dans certaines orientations, sur trois de leurs quatre bords. Placées de sorte que les bords communs s'alignent, les échanger ne dérange qu'un bord de chacune : deux raccords. Le jeu contient exactement **50** telles paires quasi-jumelles. - **Rotations sur place.** Une tuile dont les couleurs répétées permettent à un demi-tour ou à un quart de tour de garder deux de ses quatre couleurs de bord en position, si bien que la tourner là où elle est casse exactement les deux autres raccords. Le jeu contient **23** tuiles à demi-tour et **3** tuiles à quart de tour de ce type. En les additionnant, toute solution a au plus $50 + 23 + 3 = 76$ voisins de défaut 2 atteignables par un seul échange ou une seule rotation. C'est une borne supérieure tirée du sac : qu'une paire de jumelles donnée s'aligne vraiment dans une solution précise dépend de cette solution, si bien que le compte réalisé pour la solution des concepteurs reste ouvert. Le plafond tient malgré tout. Autour du sommet de l'échelle, les quasi-solutions sont clairsemées, quelques dizaines de plateaux au plus, alors que les barreaux plus bas sont peuplés astronomiquement. C'est la même rareté que [les motifs interdits](/fr/research/why/forbidden-patterns/) montrent à l'échelle 2×2, lue au sommet. ## Le cadre paie sa facture d'avance Le recensement a une seconde histoire à raconter. Les couleurs 1 à 5 n'apparaissent sur aucune tuile intérieure ; leurs $5 \times 24 = 120$ demi-arêtes vivent entièrement sur les bords latéraux des 60 tuiles du pourtour. L'anneau du pourtour a exactement 60 raccords, donc dans toute solution les cinq couleurs de jonction du cadre les saturent exactement, 12 raccords par couleur, sans aucun jeu. Et comme l'orientation d'une tuile du pourtour est forcée (gris vers l'extérieur), chacune des 56 tuiles de bord montre une couleur fixe vers l'intérieur où qu'elle atterrisse. Sommé sur le sac, l'intérieur reçoit un vecteur de demande fixe sur les couleurs 6 à 22, à savoir (4, 5, 3, 3, 1, 1, 2, 3, 4, 6, 4, 2, 3, 6, 4, 3, 2), 56 bords tournés vers l'intérieur en tout. Quel que soit le cadre construit, la facture de frontière de l'intérieur reste ces mêmes 17 nombres, connus avant toute recherche. ## Ce que la communauté a vu en juin 2007 La parité a été repérée avant même la sortie du casse-tête. En juin 2007, David Eddy ouvre un fil de la liste de diffusion intitulé Parity avec l'observation que « le nombre d'arêtes de chaque type est pair », et en tire la conséquence sur la dernière pièce : si la pièce finale a quatre bords différents, le trou final doit montrer les mêmes quatre couleurs dans un certain ordre, ce qu'il évalue à une chance sur 6 de correspondre ([msg 332](https://groups.io/g/eternity2/message/332)). Christophe Weibel fournit l'exemple détaillé montrant que la dernière pièce peut réellement ne pas correspondre à son trou ([msg 335](https://groups.io/g/eternity2/message/335)), et Brendan Owen, qui avait étudié la conception, clôt le fil avec le verdict pratique : la parité est correcte pour E2 par construction, et dans une recherche elle n'aide jamais que tout près de la fin ([msg 346](https://groups.io/g/eternity2/message/346)). Tout cela est vrai, et le fil s'est arrêté là. Poussée un pas plus loin, la même observation contient le théorème ci-dessus : la parité fait plus que rendre la dernière pièce aléatoire, elle supprime le barreau 479 purement et simplement, fixe le plancher de défaut à 2, et plafonne à 76 la coquille à un coup autour de chaque solution. ## Vérifiez-le vous-même Chaque nombre de cette page se réduit à un recensement en une passe du jeu officiel : les comptes de demi-arêtes et leur parité, l'identité d'ajustement exact 960, le zéro tuile symétrique par rotation, la partition 4/56/196 en coins/bords/intérieur, les générateurs de défaut 2 en 50/23/3, la saturation du cadre et le vecteur de demande vers l'intérieur. Le vérificateur recalcule chaque valeur à côté de sa valeur attendue et émet un drapeau de réussite par affirmation ; les 16 vérifications passent et la sortie est identique à l'octet près d'une exécution à l'autre. [L'article, la source du vérificateur et les résultats sont sur GitHub](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/parity-defect-floor), et le bloc de reproduction de cette page pointe vers le même sujet. Une réserve de périmètre : l'argument de parité couvre les placements complets des 256 pièces avec un cadre gris légal. Les plateaux partiels, et ceux qui violent la règle du cadre, sont hors de sa portée. ## À lire aussi - [La moisson de théorèmes : treize lois de structure](https://eternity2.dev/fr/research/why/theorem-sweep/) — Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. - [Motifs interdits](https://eternity2.dev/fr/research/why/forbidden-patterns/) — Presque tout petit assemblage de pièces que l'on pourrait construire est impossible. Pour un carré 2×2, 99,72 % des façons de placer quatre pièces ne pourront jamais s'accorder. - [Conçu pour être insoluble : la recette](https://eternity2.dev/fr/research/why/design-recipe/) — Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. --- # Le plateau comme mot de code > Lisez un plateau complet comme un mot de code dont les 480 jointures intérieures sont des contrôles de type parité, et le score d'arêtes appariées devient 480 moins le nombre de contrôles en échec. C'est une lentille nette reposant sur une seule identité porteuse, et il vaut la peine d'être précis sur ce que la vue par codes correcteurs apporte et sur ce qu'elle ne fait que renommer. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/permutation-code-wall/ - Mise à jour: 2026-07-22 - Sujets: structure - Reproduire: `cd research/topics/permutation-code-wall/compute && cargo run --release > ../results/permutation_code_wall.json` - Source: Le jeu de pièces d'Eternity II et le visualiseur interactif de plateau (bucas.name) — https://e2.bucas.name/ - Source: La lentille plateau-comme-mot-de-code : article, code du vérificateur et résultats JSON (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/permutation-code-wall --- Il existe une manière de regarder un plateau achevé qui emprunte tout son vocabulaire aux codes correcteurs d'erreurs, et elle est réellement éclairante dès qu'on sait exactement ce qu'elle affirme. Étalez la grille 16 sur 16, traitez chaque tuile comme un symbole, et traitez chaque endroit où deux tuiles voisines se rencontrent comme un *contrôle* qui réussit (les deux arêtes en regard sont de la même couleur) ou échoue. Il y a 480 de ces jointures intérieures. La liste des contrôles qui échouent est un *syndrome*, et une solution complète est le seul plateau dont le syndrome est vide. Notez un plateau selon la [convention d'arêtes appariées](/fr/research/records/) employée partout dans ce wiki (comptez les jointures intérieures qui s'apparient, sur 480), et l'arithmétique vient d'elle-même : le score vaut 480 moins le nombre de contrôles en échec. Cette seule ligne, score égale 480 moins le poids du syndrome, est tout le moteur de la lentille par codes. Tout le reste de ce qu'elle dit du casse-tête (distance minimale, décodeurs, ensembles bloquants) est bâti dessus. Il vaut donc la peine de bien cerner ce qu'est réellement cette identité, et de séparer la part de ce tableau qui est un fait réel et dénombrable sur le jeu officiel de la part qui n'est qu'un changement d'habit. ## Ce que la lentille renomme, et ce qu'elle mesure Le partage franc, énoncé clairement parce que c'est là tout l'enjeu. L'identité elle-même renomme plutôt qu'elle ne révèle. Le « poids du syndrome » est le décompte des arêtes intérieures non appariées ; le scoreur appelle déjà ce décompte *ruptures* et le définit déjà comme le score maximal moins le score atteint. Donc « score égale 480 moins le poids du syndrome » n'est pas une découverte sur Eternity II. C'est la définition du score écrite en langage de codes. Ce n'est pas un reproche : un bon renommage peut rendre une structure lisible. Cela signifie simplement que l'identité vous offre un point de vue, pas un nombre. Sous le vocabulaire, en revanche, se trouvent trois faits qui sont de vraies propriétés du design publié à 256 pièces, chacun exactement dénombrable, chacun vérifiable face à l'instance officielle : - **480 contrôles.** Une grille 16 sur 16 possède exactement 480 jointures intérieures. C'est $2WH - W - H$ avec $W = H = 16$, c'est la longueur de la liste d'adjacences du scoreur lui-même, et c'est le score maximal du kit. Trois chemins indépendants vers le même 480. - **Un code de permutation.** Les 256 tuiles sont toutes distinctes à rotation près, si bien qu'un plateau légal emploie chacune des 256 pièces exactement une fois. En langage de codes, le mot de code n'est pas une chaîne libre de symboles ; c'est une permutation, et cette contrainte est bien plus forte que les seuls contrôles de jointure. - **Un code de bordure.** Exactement cinq couleurs (étiquetées 1 à 5) n'apparaissent que sur le cadre, jamais sur une tuile intérieure, et la couleur de cadre grise repose sur zéro demi-arête intérieure. Le rebord est un petit code séparé empilé sur les jointures. Voilà ce qui donne à la lentille quelque chose de concret sur quoi s'appuyer. Le [théorème de parité](/fr/research/why/parity-defect-floor/), lu dans ce langage, est un énoncé selon lequel ce code n'a pas de syndrome de poids un : on ne peut pas faire échouer exactement un contrôle sur un plateau complet légal, si bien que 479 est un barreau vide et que le plancher de défaut est 2. La [loi d'aire](/fr/research/why/entropy-area-law/) et le [vol de pièce](/fr/research/why/piece-theft/) sont, dans ce langage, des énoncés sur le code de permutation : c'est la règle « chaque pièce une seule fois », et non l'appariement des couleurs, qui porte la difficulté. ## L'identité, vérifiée bit à bit Comme l'identité est porteuse, la reproduction la confirme directement au travers du scoreur canonique du kit, le même scoreur excluant le rebord que le site et chaque moteur utilisent, si bien qu'un contrôle en échec ici signifie la même chose qu'une rupture partout ailleurs sur ce wiki. Le contrôle part d'une vraie solution : un plateau 16 sur 16 généré et résolu qui marque 480 sur 480 avec un syndrome vide. Il injecte ensuite un nombre exactement connu de contrôles rompus en corrompant une demi-arête en regard à la fois vers une couleur qu'aucune pièce ne porte, n'acceptant une corruption que lorsqu'elle fait baisser le score d'exactement un. Ce garde-fou pas à pas est ce qui fait du compte injecté une quantité connue plutôt qu'inférée : $k$ ruptures signifie exactement $k$ contrôles en échec, chacun vérifié à part. Il relit ensuite le score, le nombre de ruptures et un recomptage indépendant du syndrome, et confirme que les trois concordent. Exécuté sur cinq plateaux résolus et huit nombres de ruptures (quarante lignes en tout, sur la convention d'arêtes appariées, sur 480), chaque ligne obéit à l'identité : | Ruptures injectées $k$ | Score | Ruptures | Recomptage indépendant du syndrome | 480 moins $k$ | | ---------------------: | ----: | -------: | ---------------------------------: | ------------: | | 0 | 480 | 0 | 0 | 480 | | 1 | 479 | 1 | 1 | 479 | | 2 | 478 | 2 | 2 | 478 | | 5 | 475 | 5 | 5 | 475 | | 10 | 470 | 10 | 10 | 470 | | 29 | 451 | 29 | 29 | 451 | | 60 | 420 | 60 | 60 | 420 | | 120 | 360 | 120 | 120 | 360 | Chaque ligne satisfait score égale 480 moins $k$, ruptures égale $k$, et le recomptage indépendant du syndrome égale $k$, sur les cinq graines. L'exécution est déterministe et se termine en moins d'une seconde sur puce Apple Silicon ; le JSON de résultats archivé est stable octet pour octet à la réexécution. La ligne à $k$ égale 29 est là exprès : elle affiche le score 451, qui est exactement le couple score-et-ruptures que porte le plateau champion à bande inférieure conçu de zéro par le papier (29 ruptures, 451 arêtes appariées). L'identité 480 moins 29 égale 451 tient face au couple score-et-ruptures que le papier rapporte pour ce plateau champion. (Ce 451 est un chiffre de carnet obtenu de zéro, bien en dessous des meilleurs plateaux complets de la communauté, à 470 et 464, sur la [page des records](/fr/research/records/) ; l'enjeu ici est seulement que l'arithmétique de codes tombe dessus.) ## Les faits structurels, sur l'instance officielle | Fait | Attendu | Mesuré | | --- | --- | --- | | Nombre de contrôles | 480 | 480 de trois façons : formule $2WH - W - H$, liste d'adjacences énumérée, score maximal du kit | | Code de permutation | 256 tuiles, chacune une fois | 256 pièces, toutes distinctes à rotation près | | Code de bordure, couleurs de cadre | cinq, confinées au rebord | 5 couleurs de cadre (1 à 5), 17 couleurs intérieures | | Code de bordure, gris | rebord extérieur seul | 0 demi-arête grise sur une pièce intérieure quelconque | Les quatre sont recalculés à partir des données de l'instance plutôt que supposés, et les quatre concordent. ## Ce que la vue par codes correcteurs apporte et n'apporte pas Ce qu'elle apporte, c'est un modèle mental net et un endroit où loger les deux contraintes dures. Les contrôles de jointure forment à eux seuls un code faible : localement, un plateau presque parfait a quantité de motifs de couleurs à faible désaccord à proximité, d'où le fait que les [désaccords se regroupent](/fr/research/why/mismatch-geometry/) en une seule bande plutôt qu'ils ne s'étalent. La force réside dans le code de permutation superposé par-dessus, l'exigence que les symboles soient un vrai réarrangement de la totalité des 256 pièces. Nommer cette couche, et la séparer des contrôles de couleur, est une manière utile de dire où se situe la difficulté : non pas dans l'appariement des couleurs, mais dans leur appariement alors que chaque pièce est dépensée exactement une fois. Ce qu'elle n'apporte pas, c'est un nombre nouveau. L'identité centrale est la propre définition du score dans un autre alphabet, et le vocabulaire des décodeurs et de la distance minimale décrit le même paysage que les pages [rigidité](/fr/research/why/rigidity-wall/) et [loi d'aire](/fr/research/why/entropy-area-law/) mesurent directement, sans ajouter de mesure à elle. L'affirmation plus forte qu'une lecture par codes voudrait faire, à savoir que la distance minimale du code de permutation est ce qui fixe en place un plateau record précis, est une mesure propre à un plateau qui vit sur un unique plateau champion privé que le kit public ne fournit pas, si bien qu'elle n'est ici ni confirmée ni infirmée. Ce qui se reproduit exactement, c'est l'échafaudage : 480 contrôles, un code de permutation à 256 pièces, un code de bordure à cinq couleurs, et l'unique identité qui soutient tout le tableau. ## À lire aussi - [Pourquoi 479 est impossible](https://eternity2.dev/fr/research/why/parity-defect-floor/) — Un argument de comptage sur le jeu de pièces officiel interdit un score d'exactement 479/480 : les demi-arêtes de chaque couleur viennent en nombre pair, et un unique raccord cassé laisserait deux comptes impairs. Le plancher sous le parfait est 478, et au plus 76 quasi-solutions à un coup peuvent entourer une solution. - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [Le vol de pièce, là où meurent les solveurs](https://eternity2.dev/fr/research/why/piece-theft/) — Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Calibré sur le pic de difficulté > Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/phase-transition/ - Mise à jour: 2026-07-02 - Sujets: structure - Reproduire: `just research-phase-transition` - Source: Brendan Owen, Concevoir le casse-tête le plus difficile : la dérivation 17+5 (liste de diffusion eternity2, août 2007) — https://groups.io/g/eternity2/message/1947 - Source: Ansótegui, Béjar, Fernández & Mateu, On the hardness of solving edge matching puzzles as SAT or CSP problems (Constraints, Springer 2013) — https://link.springer.com/article/10.1007/s10601-012-9128-9 - Source: Ansótegui, Béjar, Fernández & Mateu, How Hard is a Commercial Puzzle: the Eternity II Challenge — https://repositori.udl.cat/server/api/core/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/content --- Les problèmes de recherche difficiles possèdent un bouton de réglage de la difficulté. Desserrez-le et les solutions se multiplient : une recherche en trouve une presque aussitôt. Serrez-le et il n'en existe plus, ce qui est souvent facile à prouver. Entre les deux se trouve une bande étroite où les solutions sont rares mais bien réelles, et c'est là que la recherche explose. On parle de transition de phase, comme l'eau qui gèle. Pour les casse-tête à appariement de bords, ce bouton est le nombre de couleurs. Trop peu et les pièces s'emboîtent d'innombrables façons ; trop et elles ne s'ajustent presque plus. L' [analyse publiée](https://link.springer.com/article/10.1007/s10601-012-9128-9) situe le pic autour de 17 couleurs intérieures, le réglage pour lequel un casse-tête de cette taille possède environ une seule solution. Eternity II en utilise 17. La communauté disposait de ce chiffre quelques semaines après le lancement : en août 2007, Brendan Owen a dérivé $I = (196! \cdot 4^{196})^{1/392} \approx 17.14$ couleurs intérieures à partir du critère « environ une solution attendue », exactement les paramètres publiés, des années avant les analyses académiques ([Concevoir le casse-tête le plus difficile, msg 1947](https://groups.io/g/eternity2/message/1947)). Nous l'avons mesuré ici. Le critère d'Owen n'a jamais été énoncé que pour le plateau complet ; nous l'avons donc passé à une seconde taille pour voir s'il tient. La même formule prédit $(36! \cdot 4^{36})^{1/72} \approx 7.56$ couleurs intérieures pour un plateau 8x8, et un 8x8 est assez petit pour qu'un backtracker ordinaire résolve réellement des instances aléatoires : sa courbe de difficulté se balaie directement. En mesurant l'effort du solveur en fonction du nombre de couleurs intérieures sur des plateaux 8x8 générés (le générateur et le DFS du site), la bande dure, là où la recherche cesse de trouver une solution dans le budget imparti, tombe exactement où le critère à la taille 8 le prédit. Le balayage 16x16 complet forme l'autre moitié du tableau : un backtracker ordinaire ne le termine à aucun nombre de couleurs, et la profondeur qu'il atteint décroît régulièrement à mesure que les couleurs augmentent, si bien que le vrai plateau se situe au-delà du point où la courbe est déjà devenue verticale. L'[expérience hardness-peak](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/hardness-peak) contient le code, les deux balayages et le critère recalculé dans le dépôt (il reproduit le 17,14 d'Owen à la taille 16). ## Le mur de la difficulté > **[Figure]** Interactif : le pic de difficulté selon le nombre de couleurs — interactive: PhaseTransitionLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Ou mesurez-le vous-même Le graphique ci-dessus est précalculé. Celui-ci ne l'est pas : le moteur résout en direct des casse-tête inédits, un par nombre de couleurs, et trace le pic à partir de véritables exécutions dans votre navigateur. > **[Figure]** Interactif : résoudre en direct de part et d'autre du pic de difficulté — interactive: PhaseTransitionLiveLab. Rendered on the canonical page (link above); not shown in this markdown export. ## La transition, mesurée sur de vraies pièces L'argument fondé sur le nombre de couleurs indique *où* se trouve le pic. En mars 2008, Brendan Owen est allé observer une transition de phase directement, sur les pièces réelles. Il a pris un mince rectangle intérieur de 2 par L et l'a pavé avec des ensembles aléatoires de pièces intérieures d'E2 - quatre cents ensembles aléatoires pour chaque longueur - en notant combien pouvaient être complétés sans aucun désaccord ([msg 4909](https://groups.io/g/eternity2/message/4909)). > **[Interactive: RectangleTransitionChart]** Rendered on the canonical page (link above); not shown in this markdown export. La forme obtenue est la transition de phase en miniature. Une bande de 2 par 1 ou 2 par 2 est si courte que des pièces aléatoires s'y ajustent souvent : 58 % de cas résolubles à la longueur 1. Puis tout s'effondre. De la longueur 4 à la longueur 15, pas un seul ensemble aléatoire sur quatre cents ne pave le rectangle, quelle que soit la longueur : les solutions sont si rares qu'elles n'existent pratiquement pas. Et elles reviennent ensuite. À la longueur 16, un ensemble sur quatre cents fonctionne ; à 19, on atteint 8,5 % ; à 21, 57 % ; et à 22, près de neuf sur dix. La région où les solutions sont extrêmement rares sans être encore impossibles est précisément la bande difficile, et ici ce n'est ni un récit ni un modèle : c'est un décompte. C'est aussi pourquoi un intérieur large de 14 cases est si redoutable : il se situe dans la partie raide de cette montée, là où une solution existe mais où presque aucun arrangement aléatoire n'en est une. ## La répartition, lue directement sur les pièces Trier les couleurs de l'ensemble officiel selon l'endroit où elles apparaissent révèle clairement l'intention de conception.
5 couleurs réservées au cadre
{data.frameOnlyColors.map((c) => (
> **[Interactive: MotifSwatch]** Rendered on the canonical page (link above); not shown in this markdown export. '{colorToLetter(c)}'
))}
Elles n'apparaissent que sur les pièces de bord et de coin, jamais à l'intérieur. Ce sont les couleurs rares, cantonnées au pourtour.
17 couleurs intérieures
{data.interiorColors.map((c) => (
> **[Interactive: MotifSwatch]** Rendered on the canonical page (link above); not shown in this markdown export. '{colorToLetter(c)}'
))}
La palette de l'intérieur du plateau, là où se joue la quasi-totalité des appariements.
## L'ensemble en chiffres | | Nombre | | ---------------------- | -----: | | Pièces de coin | 4 | | Pièces de bord | 56 | | Pièces intérieures | 196 | | Couleurs intérieures | 17 | | Couleurs du cadre | 5 | ## Pourquoi c'est important C'est le signe le plus net qu'Eternity II a été rendu difficile délibérément. La taille du plateau, le nombre de pièces et la répartition des couleurs visent tous la même cible : un casse-tête à environ une seule solution, placé à l'endroit le plus défavorable qui soit pour n'importe quelle recherche. La difficulté a été choisie, comme un bon examen n'est ni trivial ni impossible. Comment savons-nous que ce pic est réel et non un simple récit ? Deux voies se rejoignent ici. L'analyse publiée le [dérive](https://repositori.udl.cat/server/api/core/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/content) : pour les casse-tête à appariement de bords avec cadre, le nombre de couleurs pour lequel on attendrait environ une solution tombe près de 17, et c'est le réglage le plus difficile à explorer. Et vous pouvez en observer une part vous-même dans la démonstration ci-dessus : construisez de vrais casse-tête, comptez le travail effectué, et voyez-le exploser lorsque les couleurs se font rares. La conséquence est concrète. Elle signifie que l'écart jusqu'à une solution n'est pas un problème de réglage que l'on peut réduire à force d'une machine plus rapide ; le casse-tête a été placé là où la recherche est la pire, volontairement, de sorte que le vaincre exige une idée réellement meilleure, et non simplement plus d'efforts. Voyez la difficulté mesurée en direct sur la [page Algorithmes](/algorithms/). ## À lire aussi - [Conçu pour être insoluble : la recette](https://eternity2.dev/fr/research/why/design-recipe/) — Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. --- # Le vol de pièce, là où meurent les solveurs > Un solveur remplit quelques rangées sans effort, puis se heurte à un mur au milieu du plateau. Voici le mécanisme : une pièce rare dépensée au mauvais endroit, plusieurs rangées plus tôt. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/piece-theft/ - Mise à jour: 2026-07-01 - Sujets: structure, search-space - Reproduire: `just research-piece-theft` - Source: Régin 1994, « A Filtering Algorithm for Constraints of Difference in CSPs » (AAAI-94) : l'argument all-different/ensemble de Hall que le décompte de demandes rares de cette page motive — https://cdn.aaai.org/AAAI/1994/AAAI94-055.pdf --- Bar, BarChart, CartesianGrid, ResponsiveContainer, Tooltip, XAxis, YAxis, } from "recharts"; Remplissez le plateau du coin haut-gauche vers le coin bas-droite, et chaque nouvelle case connaît déjà deux de ses couleurs : la couleur nord vient de la pièce du dessus, la couleur ouest de la pièce à gauche. La case réclame une pièce inutilisée capable d'afficher exactement cette paire. Ces demandes sont rares, avec seulement trois pièces possibles en moyenne, et 47 d'entre elles n'en ont qu'une seule. Ainsi, un plateau qui paraît en bonne santé, avec la plupart des pièces encore dans la boîte, peut déjà être condamné. Quelque part plus haut sur le plateau, l'unique pièce qui aurait pu servir une case à venir a été employée à autre chose. Lorsque le solveur atteint enfin cette case, il n'a plus rien à poser. ## Comment une case meurt > **[Interactive: PieceTheftDiagram]** Rendered on the canonical page (link above); not shown in this markdown export. ## Combien de pièces peuvent satisfaire une demande
{data.uniqueServerDemands}
demandes satisfaites par une seule pièce
{data.meanServers}
pièces par demande, en moyenne
{data.occurringDemands}
demandes distinctes rencontrées
> **[Figure]** interactive: ServersChart. Rendered on the canonical page (link above); not shown in this markdown export. ## Affamez une case vous-même Le moteur remplit un plateau jusqu'à une case n'ayant qu'un seul fournisseur légal ; volez cette pièce et regardez la case mourir alors que la boîte est encore pleine. > **[Figure]** Interactif : là où les solveurs meurent du vol de pièce — interactive: PieceTheftLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pourquoi c'est important Un correctif tentant serait une vérification globale : les pièces restantes couvrent-elles encore les cases restantes ? Cela n'aide en rien. Globalement, l'offre est suffisante ; l'échec tient à une seule pièce rare mal affectée, non à une pénurie. Un contrôle global en avant ne voit donc rien d'anormal, jusqu'au moment où la case se révèle sans fournisseur, ce qui explique pourquoi un contrôle global naïf passe à côté. Mettez cela en regard de l'[absence de coups forcés](/fr/research/why/no-forced-moves/) et le piège est complet. Chaque pièce dispose de dizaines d'emplacements possibles, si bien que le solveur ne sait jamais où une pièce rare doit être réservée, alors même que chaque pièce rare a exactement une demande pour laquelle elle doit être préservée. Liberté de poser, aucune indication sur ce qu'il faut garder. ## À lire aussi - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [All-different, le filtre par matching de Régin](https://eternity2.dev/fr/research/build/reduce/alldiff-regin/) — Aucune pièce ne peut servir deux fois : une seule contrainte all-different globale sur 256 cases. Jean-Charles Régin a montré en 1994 comment un matching biparti la filtre complètement en temps polynomial ; sa variante par couleur est le propagateur le plus puissant jamais mesuré sur l'edge matching, avec une réserve nette sur les recherches tolérantes aux erreurs. - [PRIOR](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/prior/) — Construire un plateau à partir de rien, en départageant les égalités selon la position habituelle des pièces dans les bons plateaux déjà connus. Il atteint un score élevé sans aucun plateau de départ à copier. --- # Pourquoi un ordinateur plus rapide ne change rien > L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/prune-vs-speed/ - Mise à jour: 2026-07-01 - Sujets: speed, search-space, backtracking - Reproduire: `just research-prune-vs-speed` - Source: Article, source et résultats sur GitHub (research/topics/prune-vs-speed) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/prune-vs-speed - Source: Peter McGavin : l'élagage par détection précoce d'impasse est en général trop coûteux pour en valoir la peine (groups.io msg 11848) — https://groups.io/g/eternity2/message/11848 - Source: @95A31 : toute une batterie de tests de faisabilité s'est révélée inutile sur une recherche 8×8 (groups.io msg 11856) — https://groups.io/g/eternity2/message/11856 --- Voyez la recherche comme un arbre. Depuis le plateau vide, vous choisissez une pièce pour la première case ; de là une pièce pour la deuxième ; et ainsi de suite, sur 256 cases de profondeur. Le nombre de feuilles tout en bas est le facteur de branchement élevé à la puissance de la profondeur, un nombre astronomiquement grand. Pour prouver qu'une région n'a pas de solution, une recherche doit parcourir cet arbre. Il y a alors deux façons de faire moins de travail. Vous pouvez aller plus **vite** : un meilleur moteur, plus de cœurs, des boucles internes optimisées à la main. Ou vous pouvez rendre l'arbre plus **petit**, en élaguant les branches qui ne peuvent mener à aucune solution, de sorte que le facteur de branchement effectif diminue. Cela paraît similaire. Ce n'est même pas comparable. ## Constant contre exponentiel Une accélération est un diviseur constant. Rendez la machine 1000× plus rapide et vous attendez 1000× moins, que l'arbre fasse dix niveaux de profondeur ou dix mille. Elle vous achète un multiple fixe, un point c'est tout. Un élagage, lui, se compose. Rognez ne serait-ce que quelques pour cent sur le facteur de branchement et vous économisez cette fraction à chaque niveau. Sur 256 niveaux, les économies se multiplient entre elles : faire passer le facteur de branchement de $b$ à $b'$ divise le travail par $(b/b')^{256}$. Une coupe de 5 %, appliquée jusqu'au bout, vaut $(1/0.95)^{256} \approx 5\times10^{5}$, soit l'équivalent d'une accélération de cinq cent mille fois, à partir d'une seule idée structurelle peu coûteuse. Cela bat presque toute accélération qu'une machine réelle peut offrir. ## Sentez l'écart Mettez une accélération brute en balance avec un petit élagage par niveau et regardez l'élagage l'emporter de plusieurs ordres de grandeur. > **[Figure]** Interactif : puissance de l'élagage contre vitesse brute — interactive: PruneVsSpeedLab. Rendered on the canonical page (link above); not shown in this markdown export. ## En quoi c'est exactement la malédiction d'E2 Si l'élagage est le levier qui compte, les casse-têtes difficiles sont ceux qu'on ne peut pas élaguer. Eternity II a été réglé pour être précisément cela. Quatre de ses murs disent, au fond, la même chose : il n'y a rien de local à élaguer. - **[Aucun coup forcé](/fr/research/why/no-forced-moves/)** : chaque case intérieure a encore 73 à 137 voisins légaux, si bien que la propagation ne réduit presque jamais une case à un seul choix. Le facteur de branchement reste obstinément élevé. - **[Au sommet de la difficulté](/fr/research/why/phase-transition/)** : les décomptes de pièces et de couleurs se situent là où l'on attend environ une solution, ne laissant aucune région dense en solutions vers laquelle diriger un raccourci statistique, l'astuce qui a fait tomber Eternity I. - **[La loi d'aire](/fr/research/why/entropy-area-law/)** : le nombre de plateaux partiels véritablement distincts s'effondre à mesure que l'aire remplie grandit, mais aucun signal de score local ne peut voir cet effondrement global, si bien qu'on ne peut pas élaguer vers lui à bon compte. - **[La rigidité](/fr/research/why/rigidity-wall/)** : même à partir d'un plateau record, le passage à un meilleur est énorme et indivisible, sans gradient à suivre ni rien à proximité à élaguer. ## Ce que cela signifie pour tout le reste ici C'est la grille de lecture de toute la section recherche. Un moteur bien plus rapide rend la même recherche moins coûteuse, pas plus petite, et ne fait pas bouger le record. Chaque expérience qui a vraiment fait bouger les choses a plutôt changé la forme de la recherche : un ordre de parcours différent, un a priori appris sur l'emplacement des pièces, une région confinée pour les défauts d'appariement. Et chaque impasse est, au fond, un élagage que la structure globale du casse-tête refuse d'honorer. La vitesse donne d'abord un sentiment de productivité ; ce n'est presque jamais là que se cache l'écart avec 480. ## La communauté a abouti là aussi, à la dure Le versant contre-intuitif, c'est que même un élagage *légal* est souvent perdant. Un test qui détecte un plateau partiel condamné et rebrousse chemin tôt semble être un gain gratuit, mais si le test coûte plus cher que le sous-arbre qu'il économise, un simple backtracker qui fonce tout droit est plus rapide. Peter McGavin a exposé sans détour le consensus établi sur la liste groups.io : les méthodes qui tentent de détecter un placement partiel condamné et de rebrousser chemin tôt « sont en général considérées comme trop coûteuses pour en valoir la peine ». Un nouveau venu faisant tourner un solveur à diagramme de décision, @95A31, l'a ensuite confirmé de zéro : après avoir construit toute une batterie de tests de faisabilité, il a rapporté que « tous les tests de faisabilité que j'ai implémentés se sont révélés inutiles », une recherche 8×8 complète peinant encore à traverser 953 milliards de nœuds en 17 heures. La leçon n'est pas que l'élagage est mauvais, c'est qu'un élagage ne paie que s'il est *moins coûteux que la recherche qu'il supprime*, et sur ce casse-tête presque rien de local ne franchit ce seuil. > **Note** > > Les nombres de l'arbre dans la démo sont illustratifs : un facteur de branchement et une profondeur choisis pour être proches d'E2 et lisibles, non la mesure d'un solveur précis. La courbe de difficulté et les décomptes de nœuds, en revanche, sont de vraies mesures de moteur sur de petits casse-têtes, déterministes et reproductibles avec `just research-prune-vs-speed`. Le principe lui-même, diviseur constant contre diviseur exponentiel, est exact. ## À lire aussi - [Quel mur arrête quelle méthode](https://eternity2.dev/fr/research/why/walls-and-methods/) — La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - [La théorie complexe : compter l'arbre de recherche avant de le parcourir](https://eternity2.dev/fr/research/why/complex-theory/) — La théorie complexe de Brendan Owen estime la largeur de l'arbre de recherche à chaque profondeur, et jusqu'au nombre total de solutions. Beaucoup, dans la communauté, la tiennent pour la chose la plus importante à comprendre sur Eternity II. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [La cohérence d'arc, à partir d'AC-3](https://eternity2.dev/fr/research/build/reduce/arc-consistency/) — Le forward checking regarde un coup à l'avance ; la cohérence d'arc oblige la liste de candidats de chaque case à se défendre contre celle de chaque voisine, jusqu'à un point fixe. AC-3 de Mackworth, les raffinements optimaux qui ont suivi, ce que toute cette famille a réellement mesuré sur ce casse-tête, et où elle devient incorrecte. --- # Les couleurs rares vivent sur le cadre > Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/rare-color-geography/ - Mise à jour: 2026-07-01 - Sujets: structure - Reproduire: `just research-rare-color-geography` - Source: Brendan Owen dérive le design 17+5 couleurs comme le puzzle le plus difficile possible (message groups.io 1947) — https://groups.io/g/eternity2/message/1947 --- Bar, BarChart, CartesianGrid, Legend, ResponsiveContainer, Tooltip, XAxis, YAxis, } from "recharts"; Les 22 couleurs ne jouent pas des rôles équivalents. Triez-les selon l'emplacement de leurs arêtes et elles se scindent en deux classes nettes : cinq couleurs rares cantonnées à la bordure, et dix-sept couleurs communes qui font presque tout leur travail à l'intérieur du plateau. ## Où les couleurs rares sont autorisées Choisissez l'une des cinq couleurs rares et observez le plateau : ses 24 arêtes s'allument tout autour de l'anneau du cadre, et l'intérieur 14×14 reste entièrement vierge. Passez à une couleur commune et c'est l'intérieur qui se remplit à la place. Ce centre vide, pour chaque couleur rare, constitue tout le résultat. > **[Figure]** interactive: RareColorRing. Rendered on the canonical page (link above); not shown in this markdown export. ## Les cinq couleurs rares > **[Interactive: RareSwatches]** Rendered on the canonical page (link above); not shown in this markdown export.
{data.edgesPerRareColor}
arêtes chacune
{data.rareEdgesTotal}
arêtes rares, toutes sur le cadre
0
arêtes rares à l'intérieur
## Cadre contre intérieur, couleur par couleur > **[Figure]** interactive: FrameInteriorChart. Rendered on the canonical page (link above); not shown in this markdown export. > **[Figure]** Interactif : la géographie des couleurs rares sur la bordure — interactive: RareColorLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Pourquoi c'est important La séparation elle-même est structurelle, ce n'est pas une astuce défensive. Comme le liseré extérieur est uniformément gris, chaque pièce de bordure garde son arête grise tournée vers l'extérieur, si bien que ses arêtes colorées ne rencontrent jamais que d'autres arêtes de bordure ou l'intérieur : les couleurs de bordure et d'intérieur vivent dans des réservoirs séparés, quoi qu'il arrive. Les cinq couleurs de bordure paraissent « rares » simplement parce qu'il y a bien moins d'arêtes de bordure à colorer, et on pourrait les réétiqueter avec n'importe quelles cinq valeurs (y compris en réutilisant celles de l'intérieur) sans rien changer au puzzle. (Voir la [note de conception sur le pourquoi](/fr/research/why/#conçu-pour-résister-à-lingéniosité), avec nos remerciements à Vasily V. sur la liste groups.io pour la correction.) Ce qui est réel, et ce qui compte pour la résolution, c'est la conséquence : l'intérieur 14×14 est laissé à dix-sept couleurs communes sans aucun signal rare, fortement contraignant, nulle part en son sein, ce qui explique en grande partie pourquoi la recherche à l'intérieur a si peu de prise. La bordure, où le réservoir de couleurs est petit et les correspondances serrées, est en conséquence la partie que tout plateau solide réalise pour ainsi dire parfaitement. Les décomptes de couleurs d'Eternity II ont été équilibrés pour supprimer les points d'appui statistiques qui avaient coulé Eternity I ; cette géographie, c'est là que l'on en ressent le résultat. Voir [pourquoi l'intérieur n'offre aucun coup forcé](/fr/research/why/no-forced-moves/). ## À lire aussi - [Conçu pour être insoluble : la recette](https://eternity2.dev/fr/research/why/design-recipe/) — Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. - [Motifs interdits](https://eternity2.dev/fr/research/why/forbidden-patterns/) — Presque tout petit assemblage de pièces que l'on pourrait construire est impossible. Pour un carré 2×2, 99,72 % des façons de placer quatre pièces ne pourront jamais s'accorder. - [L'équilibre du bord](https://eternity2.dev/fr/research/why/border-balance/) — Un plateau résolu dissimule une loi comptable toute simple : chaque couleur que le bord tend vers l'intérieur, l'intérieur la lui rend aussitôt. La violer, c'est savoir sur-le-champ que le plateau est faux ; la respecter, en revanche, ne garantit rien. - [CLOISTER](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) — Fixer une bordure parfaite, puis explorer l'intérieur en traitant les arêtes de la bordure comme des contraintes dures dès la toute première case. --- # Le mur de rigidité > Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/rigidity-wall/ - Mise à jour: 2026-07-22 - Sujets: structure, local-search, exact-methods - Source: Théorème de rigidité locale (article du projet, 2026-05-16) : ≥13 preuves PLNE d'optimalité de halo sur 3 à 4 bassins, jusqu'au halo-4 — https://github.com/raphael-anjou/eternity2/tree/main/research - Source: Land & Doig 1960, séparation et évaluation, la méthode exacte derrière chaque résolution de région — https://doi.org/10.2307/1910129 - Source: benj39100 : le recuit sur GPU appliqué au plateau strict à 5 indices bute sur le même cœur figé ; le meilleur score croît avec la distance au sortant (message groups.io 11902) — https://groups.io/g/eternity2/message/11902 - Source: Tests indépendants de résidu SAT sur halo et de gel des répliques de William Millilaw, reproduits ici sur cinq plateaux publics (chaque résolution terminée UNSAT, jusqu'à un halo de rayon 4 au sens de Chebyshev) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/rigidity-sat-halo - Source: kissat, le solveur SAT derrière les preuves UNSAT sur anneaux de bordure et intérieur complet — https://github.com/arminbiere/kissat - Source: Google OR-Tools CP-SAT, le solveur certifiant derrière les mouvements de grappe et les re-résolutions de fenêtres — https://developers.google.com/optimization - Source: Diaconis & Sturmfels 1998, bases de Markov : le cadre d'algèbre des mouvements derrière la théorie du rayon de connectivité — https://doi.org/10.1214/aos/1030563990 - Source: Graver 1975, connectivité des fibres bornées : le même cercle d'idées — https://doi.org/10.1007/BF01584976 - Source: Wolff 1989, la classe de mouvements de grappe corrélés issue de la physique statistique qui a inspiré le recensement des permutations — https://doi.org/10.1103/PhysRevLett.62.361 --- Voici l'intuition par laquelle presque tout le monde commence : s'approcher, puis nettoyer les derniers désaccords. Échanger deux ou trois pièces, en faire pivoter quelques-unes, et le score va sûrement grimper jusqu'à 480. Ce n'est pas le cas. Sur chaque plateau de tête que nous avons testé, les derniers désaccords sont verrouillés. Déplacez quoi que ce soit dans le voisinage et le score reste identique ou baisse. Les bons plateaux ne sont pas des quasi-solutions attendant un polissage ; ce sont des points isolés qui n'ont nulle part de meilleur où aller à côté. ## Regardez la région grandir > **[Interactive: RigidityHalo]** Rendered on the canonical page (link above); not shown in this markdown export. ## Essayez de faire mieux vous-même Un vrai petit plateau parfait. Échangez n'importe quelles deux pièces, ou laissez le moteur essayer tous les échanges. Rien ne le bat ; c'est la rigidité, en direct. > **[Figure]** Interactif : échangez des pièces et regardez le score refuser de monter — interactive: RigidityLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Commencer par les plus petits mouvements Avant même de convoquer un solveur, les vérifications les moins chères se font par force brute : essayer chaque petit mouvement existant, et compter. Voici une version de poche, qui tient dans la tête. Le plateau 469 de la communauté et un plateau 466 connu ne diffèrent que sur exactement quatre cellules : les quatre mêmes pièces, décalées d'une position le long d'une bande de la rangée du bas. Énumérez les 6 144 agencements de ces quatre pièces dans ces quatre cellules (24 permutations fois 256 combinaisons de rotations) : le maximum est 469, atteint uniquement par l'agencement du sortant lui-même. Le plateau 466 est l'un des 6 143 agencements moins bons. Deux bons plateaux peuvent n'être qu'à quatre cellules l'un de l'autre sans aucun chemin entre eux, ni au-dessus d'eux, à travers ces cellules. Passez à l'échelle. Sur l'un de nos plateaux à 459 (convention stricte à cinq indices ; nos chiffres restent en dessous des meilleurs de la communauté, voir [la page des records](/fr/research/records/) pour le contexte), chaque rotation non triviale de chaque pièce a été testée : 768 rotations, zéro amélioration ; chaque vraie rotation fait strictement baisser le score. Les 32 640 échanges de paires de pièces : zéro amélioration. Les combinaisons échange-plus-rotation : 47 164 d'entre elles, tirées d'un échantillon de 5 000 paires sur les 522 240 possibles, zéro encore ; celle-ci est un large échantillon, pas une énumération complète. Il existe aussi une raison analytique pour laquelle une rotation ne peut même jamais être neutre : une rotation de 180 degrés laisse le compte local de concordances inchangé dans tous les voisinages possibles seulement si les couleurs haut et bas de la pièce coïncident, ainsi que ses couleurs gauche et droite, et zéro des 256 pièces possède cette symétrie (aucune n'est non plus totalement symétrique par rotation). Aucune rotation n'est jamais gratuite. La même sonde bon marché, passée sur onze de nos hauts plateaux, scores 454 à 459, donne 8 448 tests de rotation simple et pas une seule amélioration. Sur un plateau à 457 (convention des arêtes concordantes), l'énumération a été poussée à tout mouvement touchant jusqu'à cinq pièces : 1 024 basculements de rotation simple, 6 720 rotations de paires adjacentes, 20 240 transpositions non adjacentes, 32 796 3-cycles sur les 38 cellules adjacentes aux désaccords, 982 200 4-cycles et 28 480 440 5-cycles. Environ 29,5 millions de mouvements, zéro amélioration, plus deux balayages par séparation et évaluation (une recherche de permutation sur 38 cellules et un halo de rayon 1 sur 82 cellules) qui n'ont rien trouvé non plus. Ce même plateau à 457 a été atteint 11 fois de manière indépendante par une recherche à redémarrages chauds, identique à l'octet près à chaque fois : la recherche n'orbite pas autour d'un bon plateau, elle s'effondre sur un point exact et y reste. Même les mouvements conçus pour paraître gratuits échouent. Certaines paires de pièces partagent trois de leurs quatre couleurs d'arêtes ; les échanger semble presque neutre. Sur le 469 de la communauté, les 114 échanges simples de ce type ont tous été essayés : exactement un conserve le score de 469 (et produit le seul plateau jumeau connu), 2 donnent 468 et 111 donnent 467. Les 6 441 doubles échanges : aucun n'atteint 470, le meilleur donne 468. Sur 6 555 perturbations construites précisément pour être presque neutres en score, l'ensemble de niveau 469 contient exactement deux plateaux. Les chiffres s'expliquent d'eux-mêmes. À un score de 459, une cellule contribue en moyenne environ 3,6 arêtes concordantes, alors qu'une pièce aléatoire déposée dans un voisinage fixé n'en espère qu'environ 0,18 (à peu près quatre arêtes fois une chance sur 22 couleurs) ; un échange aléatoire s'attend donc à perdre environ 6,8 arêtes. Une borne probabiliste grossière plafonne la probabilité d'un échange améliorant vers 5 pour cent ; la fréquence mesurée est inférieure à $3\times10^{-5}$. Chaque placement d'un plateau de tête est co-adapté à ses voisins bien au-delà de ce que le hasard seul prédirait. Une note de portée : chaque recensement ici est exhaustif dans sa classe de mouvements mais porte sur un seul plateau (les recensements de rotations et d'échanges sur un 459, l'énumération à cinq pièces sur un 457, le recensement des quasi-jumelles sur le 469) ; ce sont les preuves exactes ci-dessous qui les généralisent. ## Comment le sait-on Le résultat ne repose pas sur le fait d'essayer un grand nombre d'échanges puis d'abandonner. Il provient d'une question exacte posée à un solveur de programmation en nombres entiers : prendre une région du plateau, libérer chaque pièce qui s'y trouve, et trouver l'unique meilleure façon de la remplir à nouveau. Le solveur explore tout cet espace local de manière exacte, non par échantillonnage. La réponse revient toujours la même : le meilleur agencement est celui qui est déjà là. Nous l'avons démontré région après région, plateau après plateau, et jusqu'à un rayon de quatre cellules ; la plus grande région fermée par un certificat compte 79 cellules, près d'un tiers du plateau. À chaque fois, aucune amélioration n'existe. Une prudence apprise en chemin : une re-résolution exacte à froid d'une grande région peut sous-performer en silence. Sommé de reconstruire de zéro les trois dernières rangées d'un plateau solide (48 cellules), le solveur n'a même pas retrouvé la propre queue du plateau dans le temps imparti, atteignant 68 arêtes concordantes contre les 72 du sortant après 201 s (une seule exécution). Sur les grandes fenêtres, « rien trouvé de mieux » peut n'être qu'une difficulté du solveur, pas une preuve. Un verdict de rigidité n'est retenu ici que lorsque le solveur part du sortant, de sorte que tout mieux est strictement plus facile à trouver, et qu'il certifie malgré tout un écart nul. ## Méthode : la preuve PLNE La question exacte, énoncée précisément. Autour de chaque cellule défectueuse, on prend la région *halo-$r$* : toute cellule à moins de $r$ pas. On libère toutes les pièces qu'elle contient, on garde le reste du plateau fixé comme frontière, et on résout un programme en nombres entiers pour le meilleur remplissage légal. Des variables binaires $x_{c,p,\theta} \in \{0,1\}$ placent la pièce $p$ à la rotation $\theta$ dans la cellule $c$ ; des contraintes d'une-pièce-par-cellule et d'une-cellule-par-pièce en font un problème d'affectation ; l'objectif maximise les arêtes concordantes, en comptant la frontière fixée. Une région de 64 cellules représente environ 18 700 variables binaires. La séparation et évaluation trouve alors soit un remplissage strictement meilleur, soit prouve, à l'aide d'une borne duale, qu'il n'en existe aucun. La définition qui vaut d'être retenue : un plateau est *localement rigide au rayon $r$* si, pour chaque composante connexe de ses cellules adjacentes aux désaccords, libérer toutes les cellules à distance au plus $r$ de celle-ci et résoudre exactement n'apporte aucune amélioration. Elle n'en trouve jamais. Les preuves, région par région. Ces exécutions PLNE proviennent du carnet de recherche du projet (l'article du 2026-05-16 cité dans les sources) ; le tableau ci-dessous n'est pas encore rejoué par la chaîne de résultats validés de ce site, de sorte que ses temps de solveur et ses bornes duales ne sont pas vérifiables de façon indépendante depuis ce dépôt, à la différence du résultat SAT sur halo plus bas. La même note de provenance couvre chaque recensement, énumération et escalade SAT ajoutés à cette page ; la reproduction SAT au rayon 4 est le seul résultat committé dans ce dépôt : | Région | Plateau | Cellules | Temps solveur | Résultat | |---|---|---:|---:|---| | halo-2, par composante (×8) | 3 bassins (469, 459, 458) | 2–34 | quelques secondes chacune | tous Δ = +0, **prouvé** | | halo-1 conjoint | McGavin 469 | 37 | 895 s | Δ = +0, **prouvé** | | halo-1 conjoint | Local 459 | 59 | 1800 s | Δ = +0, **prouvé** | | halo-1 conjoint | trois 458 distincts | 57, 62, 64 | 180 s chacun | Δ = +0, **prouvé** | | halo-1 par composante | un second 459, disjoint | 52 + 4 | ~60 s | Δ = +0, **prouvé** | | 3 rangées du haut (une bande, pas un halo) | McGavin 469 | 48 | 70 s | Δ = +0, **prouvé** | | halo-3, par composante | McGavin 469 | 42 + 47 | 929 s | Δ = +0, **prouvé** | | halo-3, grappe la plus dense | un 458 | 79 + 19 | 1200 s + 0,2 s | Δ = +0, **prouvé** | | halo-4, composante 0 | McGavin 469 | 57 | 1200 s | Δ = +0, **prouvé** | Sur au moins six plateaux distincts et plus de vingt régions, la réponse est invariante : le plateau sortant est localement PLNE-optimal, jusqu'au halo-4 pour le 469 de McGavin. Deux lignes méritent un mot. La ligne des trois rangées du haut est une bande géométrique complète, pas un halo : elle libère des cellules propres à côté des cellules brisées, et exclut donc en plus les mouvements qui échangeraient des pièces entre cellules brisées et propres à l'intérieur de la bande. Et la région de 79 cellules, la plus grande jamais fermée ici, se trouve sur un 458 plutôt que sur le 469 parce que la résolubilité suivait la *densité de défauts*, pas la taille brute de la région : les régions denses en défauts se ferment, les plus grandes mais clairsemées expirent. L'unique région laissée avec un écart, les quatre rangées supérieures, 64 cellules, donne encore un résultat *rigoureux* : une borne duale de 123 contre les 116 du sortant, de sorte que même le cas non fermé ne peut dépasser le mur que de peu (cela implique une borne de ≤ 476 à l'échelle du plateau). Toutes les résolutions n'ont pas abouti, et le registre garde aussi celles-là. La résolution conjointe halo-2 de 54 cellules sur le 469 est restée bloquée sur sa relaxation racine pendant 55 minutes avant d'être arrêtée ; la bande des 5 rangées du haut (80 cellules) a expiré ; sur les trois 458, les deux grandes composantes halo-2 ont atteint une limite de 120 s en rapportant +0 *sans* certificat, ce qui compte comme « aucune amélioration trouvée », pas comme prouvé. Une ligne inachevée de plus élargit le constat à une autre convention de score : un plateau à 460 joué *sans* la contrainte des indices a reçu une résolution conjointe halo-1 (42 cellules libres, liberté totale des pièces) et une exécution de 900 secondes n'a rien trouvé de mieux tout en laissant un écart dual de 9,5 pour cent ouvert ; cette ligne aussi est « rien trouvé dans le budget », pas « prouvé optimal ». Un seul plateau, une seule exécution. Ce n'est pas non plus un plateau malchanceux isolé. Un second plateau à 459, trouvé par un chemin de construction complètement différent, ne coïncide avec le premier que sur 3 des 256 cellules, essentiellement les cellules des indices ; les deux plateaux sont structurellement disjoints, et le second est *lui aussi* prouvé rigide au halo-1 (deux composantes, 52 et 4 cellules, +0 prouvé en une minute environ). Au halo-2, sa petite composante (7 cellules) a été prouvée +0 en 18 s ; sa grande composante (67 cellules) est restée indécise après environ 13 minutes et demeure ouverte. La conjecture que cela soutient, énoncée comme telle : l'ensemble de niveau 459 est une union disjointe de nombreux points rigides, et le dépasser exige un réagencement à l'échelle du plateau ou un autre départ, jamais une retouche locale. Le badge indique *prouvé* plutôt que *conjecturé* pour les régions effectivement fermées ; l'énoncé général sur *tous* les plateaux reste une conjecture, étayée par chaque région testée à ce jour. ## Aucun échange astucieux n'existe non plus La PLNE libère une région et la remplit depuis l'ensemble complet des pièces. Il existe une classe de mouvements complémentaire qu'elle ne couvre pas : choisir $k$ cellules et essayer toutes les façons de permuter et re-pivoter les pièces *qui s'y trouvent déjà*, le reste du plateau gelé. Une algèbre de mouvements différente, et la même réponse. Sur un de nos plateaux à 452 (convention stricte à cinq indices, 2026-07) : $k=1$, exhaustif sur les 251 cellules libres, zéro mouvement améliorant. $k=2$, exhaustif sur les 31 375 paires hors indices, zéro. $k=3$ à $6$, environ 29 000 grappes échantillonnées (près des défauts, sur tout le plateau, connexes et non connexes), zéro ; ce palier est un large échantillon, pas une énumération. Pour $k=7$ et $8$, l'échantillonnage a été promu en véritable énumération : chaque sous-ensemble connexe de 7 et 8 cellules parmi les cellules touchant un défaut, sur deux plateaux indépendants, 849 sous-ensembles en tout (231 sur le 452, 618 sur un 451 structurellement étranger qui en diffère sur 249 des 256 cellules), tous résolus jusqu'au bout, zéro améliorant, zéro dépassement de délai ; plus les 7 845 sous-ensembles connexes de 7 cellules à un pas d'une arête en défaut, zéro encore. Environ 60 000 mouvements de grappe évalués, et le meilleur delta trouvé où que ce soit est exactement zéro. Ce zéro n'est pas un détecteur cassé. En témoin positif, un sabotage délibéré de deux pièces (452 ramené à 447) a été réparé par la même machinerie en un seul mouvement de 4 cellules, retour direct à 452. Et la recherche locale gloutonne sur cette classe de mouvements, lancée depuis trois plateaux d'origines indépendantes (le 452, un jumeau de même score n'en différant que sur 2 cellules, et le 451 étranger), a touché un point fixe immédiat dans les 20 exécutions ensemencées : minimum, médiane et maximum identiques, zéro évasion. Le détail qui pique : le 452 lui-même est *né* de cette classe de mouvements. Une co-rotation de deux pièces a soulevé un 451 rigide sous tout mouvement de pièce unique. Un authentique mouvement corrélé à deux corps a existé ; une fois pris, plus aucun mouvement corrélé de taille jusqu'à 8 ne subsiste près des défauts. Le rayon de rigidité grandit à mesure que le plateau s'améliore. Changer la géométrie de l'ensemble libéré n'aide pas davantage. Libérez des bandes de rangées contiguës plutôt que des taches : 54 bandes d'une rangée sur 54, à travers les bandes de défauts des deux plateaux (largeurs 8 à 14, jusqu'à 15 cellules libérées), certifient exactement le score du plateau en moins d'une seconde chacune, et 18 bandes de deux rangées sur 18, hors de la pire bande, certifient la rigidité jusqu'à 26 cellules. Dans la bande de défauts la plus dense de chaque plateau, les bandes plus larges (16 à 26 cellules) deviennent difficiles à *certifier* : après escalade à 300 s et 3 graines, 6 sur 10 restent ouvertes avec des écarts de borne de 2 à 6 arêtes. Mais sur les 30 exécutions d'escalade, le solveur n'a jamais trouvé le moindre agencement meilleur que celui du plateau. C'est un écart de certification, pas l'indice d'une amélioration, et les bandes ouvertes sont consignées comme ouvertes, pas comme prouvées. Les fenêtres rectangulaires racontent la même histoire. Sur le 452, dont les 28 arêtes brisées se répartissent en 22 concentrées dans la bande du bas et 6 éparses, chaque fenêtre de jusqu'à 18 cellules autour de chaque grappe de défauts (quatre fenêtres, 9 à 18 cellules) se re-résout à un optimum certifié exactement à la valeur du plateau. Chaque défaut est forcé par des pièces engagées *ailleurs* ; aucune fenêtre qui se contente de contenir le défaut ne peut le réparer. Même laisser les pièces s'échanger à travers la frontière bon/mauvais ne bouge rien. Sur un de nos plateaux à 459 (strict à cinq indices), les deux rangées du bas (32 cellules) certifient l'optimalité en 49 s. Une fenêtre de 46 cellules, et des fenêtres de 52 et 72 cellules qui libèrent en plus 6 à 10 cellules donneuses *dans la région parfaite*, pour que des pièces puissent circuler entre parties propres et brisées, renvoient toutes le plateau identique : zéro cellule déplacée, pas même un remaniement latéral à score égal (150 à 180 s chacune, graine unique, si bien que ces fenêtres plus grandes comptent comme « aucune amélioration et aucun mouvement trouvés », pas comme des certificats). Le même opérateur appliqué à un plateau plus faible à 455 le soulève de 2 jusqu'à 457 : il améliore donc bel et bien les plateaux qui ne sont pas encore à leur point fixe ; le 459, lui, y est déjà. Dans chaque fenêtre, la relaxation linéaire croit qu'environ 17 concordances de plus sont disponibles ; la contrainte chaque-pièce-une-seule-fois les interdit toutes. La contrainte qui mord, c'est quelles pièces le reste du plateau laisse en réserve, jamais la taille de la fenêtre. La difficulté est la distinction globale, pas la concordance locale. ## Rigide une rangée entière à la fois Halos et fenêtres sont des taches. Essayez une géométrie qui traverse le plateau : libérez une rangée entière de 16 cellules, restreignez-la aux pièces non utilisées ailleurs sur le plateau, et énumérez les remplissages alternatifs par programmation dynamique. Sur un plateau à 460 (désaccords tous dans les rangées 11 à 14) et sur le 469 de la communauté (désaccords dans les rangées 0 à 4), le remplissage actuel de chaque rangée est le meilleur disponible, et plusieurs rangées n'admettent *aucune alternative légale* : la chaîne posée est l'unique façon de faire passer cette rangée à travers le reste du plateau. Les chiffres. Sur le 460 : les rangées 1 à 10 sont parfaites et n'admettent qu'une seule chaîne chacune, celle qui est posée ; les rangées 12 et 14 ont zéro chaîne alternative ; la rangée 13 a 176 alternatives, toutes moins bonnes, la meilleure perdant 10 arêtes. Sur le 469 : la rangée 3 a zéro alternative ; les rangées 2 et 4 ont leurs meilleures alternatives à 20 arêtes de moins ; les rangées 5 à 14 sont parfaites, l'originale figurant parmi jusqu'à environ 17 857 chaînes légales sans qu'aucune fasse mieux. En libérant deux rangées conjointement (32 cellules, jointure interne libre) : les paires (11,12), (12,13) et (13,14) sur le 460 donnent 0 à 4 chaînes alternatives au total, toutes moins bonnes (12 à 16 arêtes de moins) ou infaisables. Trois rangées conjointement (48 cellules) : les rangées (11,12,13) et (12,13,14) donnent zéro chaîne alternative. Ces rangées ne sont pas seulement optimales ; elles sont souvent *forcées*. Unicité, pas simplement optimalité. Portée : l'énumération est une programmation dynamique à faisceau (largeur 100 000 pour une rangée, 5 000 à 50 000 pour deux et trois rangées), exhaustive en pratique mais non certifiée comme le sont les lignes PLNE ; disons faisceau-exhaustive. Deux plateaux. Un pendant exact sur des bandes : videz entièrement les 2 rangées du bas (32 cellules) d'un plateau à 460 et laissez une recherche exacte par contraintes énumérer chaque remplissage légal à partir des pièces libérées. Il existe exactement 32 remplissages alternatifs, tous à 460 ou moins. Videz les 4 rangées du bas (64 cellules) : la seule complétion que la recherche exacte atteint est le plateau original lui-même. Un seul plateau, ces deux tailles de bandes seulement ; mais sur chaque bande qu'on a pu fermer exactement, le score actuel est le vrai plafond. ## Où vivent les derniers désaccords, et pourquoi ils sont coincés Sur un de nos plateaux à 458, l'anatomie de l'échec est remarquablement concentrée. L'anneau de bordure est parfait (60 sur 60), les neuf rangées intérieures du haut sont parfaites, et les 22 désaccords (4 bordure-intérieur, 18 intérieur-intérieur) vivent tous dans les cinq rangées du bas, regroupés en 10 minuscules grappes disjointes de 2,8 cellules en moyenne, la plus grande n'en comptant que 5. Chaque grappe semble réparable trivialement. Les résolutions exactes disent le contraire : re-remplissages par grappe, delta zéro ; élargissements halo-1 et halo-2 jusqu'à 16 cellules, delta zéro ; et l'union des 28 cellules touchant un défaut, résolue conjointement à l'optimalité prouvée en 1,74 s, delta zéro. C'est le mécanisme de tout le mur en miniature : la région des défauts est à son optimum exact *étant donné les pièces qu'on lui a laissées*. Le haut parfait du plateau a consommé un ensemble de pièces précis, et c'est cet engagement qui plafonne le bas. Réparer les derniers désaccords exigerait de désengager des pièces de la région déjà parfaite, un grand mouvement inter-régions, pas une réparation locale. (Une relaxation linéaire lit un plafond de 478 pour cette bordure ; c'est un plafond de relaxation pour cette bordure particulière, pas une affirmation sur le véritable optimum.) Un seul plateau, mais le motif, des défauts tassés en quelques minuscules grappes que les re-remplissages exacts ne peuvent réparer, est exactement ce que le tableau des halos ci-dessus retrouve sur les autres bassins. ## Pourquoi personne ne peut certifier le mur par le haut Deux faits coexistent sur le plateau à 452 (strict à cinq indices), et leur tension est l'état de l'art actuel. Fait A : aucun mouvement local d'aucune sorte testée ne le bat, et quatre cadres indépendants concordent (mouvements de grappe, re-résolutions de fenêtres, un certificat exact à écart nul attestant que le lot de pièces posé sur ses cellules touchant un défaut est placé optimalement, et une sonde thermodynamique qui, ou bien gèle sur le sortant, ou bien fond vers l'aléatoire, sans échappée douce entre les deux). Fait B : toute tentative de borner une *grande* région par le haut échoue ; les bornes sont lâches et ne convergent pas. Sur la queue de trois rangées du plateau, 8 graines à 20 minutes chacune ont toutes rendu exactement le sortant, aucune n'a jamais rien trouvé de mieux, tandis que la borne supérieure du solveur *montait* de 79 (à 300 s) à 89 (à 1200 s), s'éloignant des 72 du sortant au lieu de s'en approcher. Une borne de programmation linéaire sur l'intérieur lit 478,5 sur 480 : vide de sens. Il y a un récit d'avertissement là-dedans. Une première lecture de l'exécution à 300 s donnait « un écart de 7, de la marge vers un score plus haut ». La chasse à 8 graines a montré que l'écart était l'artefact d'une relaxation non convergente, pas l'indice d'un meilleur plateau atteignable. La raison pour laquelle les bornes restent lâches : la rareté qui rend ce puzzle difficile est du second ordre, une affaire de *paires* de couleurs conjointement rares, et les relaxations de concordance du premier ordre, sur lesquelles sont bâties les bornes LP et de propagation, ne peuvent pas la voir, quel que soit leur temps de calcul. Ainsi la rigidité locale (prouvée) et l'écart global ouvert ne se contredisent pas. Le sortant est un optimum local profond, *et* un meilleur agencement déconnecté peut exister qu'aucun mouvement local n'atteint ; aujourd'hui aucune borne ne l'exclut et aucune recherche ne le trouve. Fermer l'une ou l'autre direction d'un seul écart de grande région serait une première : un meilleur remplissage serait un nouveau meilleur plateau, et une borne ramenée jusqu'au sortant serait le premier plafond de score local prouvé. La borne duale des quatre rangées du haut (123 contre 116) est ce qui ressemble le plus à un progrès par le haut, et elle reste lâche de 7 arêtes. Portée : le fait A est prouvé sur un plateau à travers plusieurs lentilles ; le fait B porte une dispersion à 8 graines sur son exécution décisive. ## Impossible même de recombiner les bons plateaux La rigidité survit même quand l'ensemble des mouvements est « emprunter à chaque bon plateau jamais trouvé ». Construisez une optimisation où chaque cellule peut prendre la pièce et la rotation que *n'importe lequel* de 25 à 30 plateaux distincts à haut score y place, avec chaque-pièce-une-seule-fois imposé, et libérez le plateau entier, les 256 cellules. L'optimum est exactement le meilleur plateau déjà présent dans le corpus, jamais un mélange qui le batte : 457 avec les cinq indices épinglés (convention stricte ; corpus de 25 plateaux, résolu en 24 s), et 459 sans imposer les indices (convention des arêtes concordantes). Les versions par région à rayons croissants, 77, 127, 191 et 252 cellules libres, sont toutes à delta zéro en quelques secondes à environ 30 s. Ces optima sont des certificats, par corpus ; le corpus date de 2026-05, quand nos meilleurs étaient 457 strict et 459 en arêtes concordantes, tous deux sous les chiffres de la communauté hier comme aujourd'hui ([page des records](/fr/research/records/)). Le corpus n'est pas à court de choix. Chacune des 256 cellules a au moins 2 options distinctes à travers les plateaux, et une pièce typique apparaît à 6 à 19 positions différentes dans le corpus. La diversité est riche ; l'unicité des pièces la fragmente. Les plateaux issus de familles d'agencements de coins différentes ne peuvent pas du tout se mélanger, et ajouter le 469 de la communauté au corpus fait que l'optimiseur choisit simplement ce plateau en bloc, à 469, plutôt que de le mélanger à quoi que ce soit. La lecture : l'écart au-dessus des meilleurs plateaux connus est un écart de *découverte*, pas de recombinaison. L'amélioration ne se cache dans aucune combinaison de ce qui est déjà connu ; elle exige des plateaux hors du corpus connu tout entier. ## Pourquoi c'est important Cela recadre tout l'écart jusqu'à 480. La distance entre le meilleur plateau connu et une solution n'est pas un amas de petites corrections en attente d'être trouvées. Si c'était le cas, ce type de recherche locale les aurait trouvées. L'obstacle, c'est que les bons plateaux siègent au fond de leurs propres petites vallées, et que les parois de ces vallées sont exactes, non approximatives. Cela dit aussi ce qui ne marchera pas. Le polissage, l'ascension de colline et la plupart des heuristiques de réparation locale tentent de remonter la pente depuis un point figé. Il n'y a pas de pente à remonter. Atteindre une solution exige un mouvement qui réagence une grande région d'un seul coup, ou un point de départ entièrement différent, non un meilleur polissage. Les preuves conjointes au halo-1 rendent cela quantitatif : tout opérateur de destruction-réparation dont la portée est au plus le halo, des fenêtres jusqu'à environ 30 cellules autour des défauts, est mathématiquement épuisé sur ces plateaux. Le gel n'est pas « notre heuristique est faible » ; cette classe d'opérateurs entière est terminée. Même le plus grand mouvement unique que nous sachions faire ne s'échappe pas. Sur notre plateau à 461 (strict à cinq indices ; pour situer ce chiffre face aux records de la communauté, voir [la page des records](/fr/research/records/)), les mouvements de cycles entiers indécomposables décrits sur la [page des sigma-cycles](/fr/research/why/sigma-cycles/) ont été appliqués *atomiquement*, chacun suivi d'une re-résolution de fenêtre locale pour réparer les cellules dérangées. Environ 4 000 mouvements de ce type : zéro évasion, et la sortie non locale la moins chère perd encore au moins un point (meilleur résultat 460, deux cellules de différence). Cela n'exclut que la variante à nettoyage local ; une re-résolution compensatrice globale n'a pas été testée. Mais un grand mouvement ne suffit pas si son nettoyage est local. Une chose de plus que la rigidité ne signifie *pas* : difficile à reconstruire. Épinglez les quatorze premières rangées du 469 de la communauté et laissez une recherche de réparation reconstruire le reste : 3 graines sur 4 reviennent à 469 (la quatrième reste coincée à 454). Faites de même avec les préfixes de nos propres plateaux records : aucune graine ne dépasse jamais 460. Une petite sonde (4 graines, réparations de 30 secondes par plateau), mais la forme est nette. Le mur ne mesure pas la difficulté de reconstruire un plateau ; il dit *à quelle vallée appartient le squelette du plateau*. Un préfixe admet une excellente complétion ou n'en admet pas, et aucune chance de graine ne change laquelle. ### La fin de partie se décide tôt Épinglez les $N$ rangées supérieures du 469 de la communauté et laissez la recherche locale compléter le reste. Le score de complétion n'est pas graduel en $N$ ; c'est une falaise avec des leurres : $N=1$ donne 400, $N=2$ donne 382, $N=4$ donne 401, $N=8$ donne 418, $N=12$ donne 450, $N=13$ donne 455, et $N=14$ donne 469, une reconstruction *exacte*, zéro cellule de différence, $N=15$ pareil. À 13 rangées épinglées, il existe une complétion alternative des trois dernières rangées, avec les mêmes pièces autrement, qui ne marque que 455 et constitue elle-même un piège : la concordance locale des couleurs admet plusieurs complétions et la recherche ne sait pas laquelle se prolonge. Réussir 87 pour cent d'un record n'est pas « presque y être ». Ce sont des exécutions de complétion uniques par point, sur des budgets de l'ordre de la minute, sans dispersion de graines ; lisez le seuil, pas les scores individuels. Deux notes complètent le tableau. Le balayage prouve que la machinerie de complétion est capable *d'atteindre* 469 ; le mur consiste à trouver les quelque 224 premières pièces de la structure, pas dans une faiblesse de l'étape de polissage. Et l'influence ne circule pas dans l'autre sens : une rangée du haut seule, une parmi au moins $5\times10^{8}$ rangées du haut légales, ne détermine presque rien. Quatre préréglages d'opérateurs de notre famille de recherche locale, poussés depuis une rangée du haut épinglée, calent tous entre 378 et 400 ; les autres familles de recherche ne sont pas testées, ce négatif est donc circonscrit à notre chercheur. Pendant ce temps, 363 de nos plateaux à 455 et plus n'ont utilisé que 47 rangées du haut distinctes : les bons plateaux se regroupent en haut bien avant que le bas ne soit décidé. ## Quelqu'un a heurté le même mur du côté du recuit La preuve PLNE aborde le mur de façon analytique. En juin 2026, un autre chercheur s'y est heurté de plein fouet, empiriquement. En travaillant le plateau strict à cinq indices avec un solveur de recuit simulé sur GPU (4096 répliques parallèles), benj39100 a rapporté deux choses qui se lisent comme une reformulation de cette page. Premièrement, le meilleur score qu'une exécution pouvait atteindre *augmentait avec la distance au meilleur plateau courant* : pour grimper de 429 vers 432, les perturbations gagnantes devaient migrer régulièrement plus loin, parce qu'au voisinage du sortant il n'y avait aucun mouvement améliorant à trouver. Deuxièmement, à travers tous leurs meilleurs plateaux, les mêmes quelque quarante-deux arêtes brisées formaient un « noyau dur » figé que la recherche locale ne touchait jamais, si bien qu'ils ont dû ajouter un terme explicite qui *récompensait* le fait d'ouvrir ce noyau de force. Un sortant localement figé sans gradient à proximité, et un petit ensemble verrouillé de défauts que rien de local ne déplace : voilà le mur de rigidité, vu depuis une méthode complètement différente. ## Et encore, depuis un solveur SAT Un troisième chercheur est parvenu à la même conclusion avec un troisième outil. William Millilaw, travaillant le plafond de façon indépendante, a mené deux tests. Le premier était un test de gel : perturber la racine d'un plateau de tête, ré-optimiser, et voir quelles cellules reviennent. Sur ses meilleurs plateaux, 93 à 100 pour cent des cellules revenaient exactement à leur place, un noyau figé que la recherche ne pouvait déplacer. Le second était une question de décision pour un solveur SAT. Libérer les cellules autour des désaccords, exiger que chaque arête libérée concorde, et demander si un quelconque agencement de ces pièces la satisfait. Son solveur a répondu UNSAT. Nous avons [reproduit ce test SAT](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/rigidity-sat-halo) sur cinq plateaux publics, avec notre propre encodeur et un témoin positif pour nous assurer qu'une région concordante revient satisfiable. Sur les quatre plateaux records de la communauté, du 467 de Verhaard au 470 de Blackwood, et le 464 de Riotte (le record strict à cinq indices), chaque résolution qui aboutit est UNSAT jusqu'à un halo de rayon 4 au sens de Chebyshev (cette reproduction mesure la région libérée par rayon de Chebyshev, alors que les échelles SAT du carnet plus bas comptent des pas de Manhattan ; les deux échelles de halo ne sont donc pas la même métrique) : aucun réagencement local des propres pièces d'un plateau record ne referme un seul désaccord, même lorsque la région libérée dépasse la centaine de cellules. Les instances de rayon 4 sont assez grandes pour que quelques-unes n'aboutissent pas dans le temps imparti au solveur ; celles-ci sont enregistrées comme dépassements de délai et laissées ouvertes, non comptées comme prouvées, de sorte que le tableau validé énonce exactement ce qui a été décidé. La programmation en nombres entiers optimise et borne ; le recuit se cogne au mur à la main ; SAT décide et renvoie une réfutation. Trois méthodes, une seule réponse. Un quatrième outil est d'accord. Un optimiseur MaxSAT, une variante de SAT qui renvoie à la fois le meilleur remplissage et une preuve de son optimalité, a été pointé sur des sous-régions d'un de nos plateaux à 454 plus ancien : épingler tout ce qui est hors d'une région, libérer la région, demander le meilleur remplissage prouvable. Chaque fenêtre $k\times k$ jusqu'à 5×5 a été prouvée optimale dans son budget de 60 s (les fenêtres 6×6 ont dépassé le budget et sont consignées comme non fermées, pas comme prouvées), et la zone de défauts entière du plateau, 45 cellules contenant ses 26 désaccords intérieurs, a été prouvée optimale en 83 s : ces 26 désaccords sont le mieux que cette région puisse faire étant donné le reste du plateau. Ce 454 avait lui-même été atteint à l'octet près depuis 4 graines aléatoires différentes, le même effondrement sur un point unique que le 457 du recensement plus haut : les exécutions indépendantes n'atteignent pas seulement le même score, elles atteignent exactement le même plateau. Poussez la question SAT plus loin et la réponse devient plus spectaculaire. Prenez un de nos plateaux à 459 (cinq indices imposés), libérez chaque cellule à distance au plus 10 de ses désaccords, 218 des 256 cellules libres et seulement 38 épinglées, et demandez si *une quelconque* complétion atteint un 480 complet. UNSAT, en 0,31 s. L'échelle en chemin : les halos 0 à 5 tous UNSAT en moins de 2 s chacun ; le halo 7, 173 libres et 83 épinglées, UNSAT en 0,17 s. Les 38 cellules encore épinglées au halo 10 sont essentiellement les deux rangées du haut plus 3 des 5 indices. Les deux rangées supérieures de ce plateau sont donc, à elles seules, prouvées incompatibles avec toute solution parfaite : tout 480 doit différer de ce plateau quelque part dans ces 38 cellules. La rigidité est portée par un mince squelette en haut du plateau, pas par les voisinages des défauts. Au rayon 15, seulement 4 cellules épinglées, le solveur a expiré à 600 s ; ce cas est ouvert. Un plateau précis ; on ignore si d'autres plateaux à 459 partagent la même rigidité du haut épinglé. Ses travaux antérieurs sur le serpent et la recherche locale ont chiffré le pourquoi. Le plus grand pavé qu'un quelconque de ses opérateurs de réparation pouvait réécrire en un mouvement faisait environ 48 cellules, alors que deux des bons plateaux connus, tous deux proches du plafond, diffèrent sur environ 225 cellules. Un mouvement qui ne peut toucher que 48 cellules ne peut franchir un écart de 225 cellules, si bien qu'aucune suite de tels mouvements n'atteint un bassin différent. Il a cherché une chaîne de petits mouvements améliorants qui permettrait de percer un tunnel vers la sortie et n'en a trouvé aucune : zéro amélioration sur vingt-huit millions de combinaisons de quatre et cinq mouvements au plateau. C'est le même mur, énoncé comme un budget. La réparation locale réécrit trop peu à la fois pour quitter la vallée, ce qui explique pourquoi s'en échapper exige un mouvement qui réagence une grande région d'un seul coup, exactement comme le conclut la section de preuve ci-dessus. ## Le mur va jusqu'à 480 Tout ce qui précède demande si un réagencement local peut refermer un désaccord. Il y a une question bien plus grande : en ne gardant que l'anneau de bordure d'un plateau, *un quelconque* agencement des 196 pièces restantes atteint-il un 480 parfait ? Sur notre plateau à 459 (convention des arêtes concordantes, indices canoniques), la réponse est une preuve de non, à toutes les échelles. Libérer les 32 cellules en désaccord : UNSAT en 0,09 s (14 000 variables, 81 000 clauses). Libérer tout ce qui est à 5 pas d'un désaccord, 140 cellules, plus de la moitié du plateau : UNSAT en 1,56 s. Libérer *l'intérieur entier*, les 191 cellules intérieures hors indices, en ne gardant que l'anneau de bordure de 60 pièces : UNSAT en 1,37 s (160 000 variables, 5,4 millions de clauses). Les barreaux intermédiaires, halo-1 à 70 cellules (0,33 s), halo-2 à 93 cellules (0,89 s), halo-3 à 109 cellules (0,80 s), sont tous UNSAT aussi. Le solveur est kissat, cité dans les sources. Et ce n'est pas la malchance d'un seul plateau. Neuf configurations d'anneaux de bordure distinctes ont été testées, couvrant quatre agencements de coins différents : la bordure du 469 de la communauté, nos bordures records 459 et 458, un plateau à 435 issu de la propagation de croyances, et cinq bordures partielles énumérées systématiquement. Chacune, sans exception, est UNSAT pour 480, en moins de 2 secondes à chaque fois. Fait le plus notable, la bordure du 469 de la communauté, à 11 désaccords de la perfection, ne peut prouvablement héberger aucun intérieur à 480 : UNSAT en moins de 0,01 s. L'encodeur a été validé aller-retour sur de petits puzzles solubles, où des résolutions fraîches se décodent en plateaux parfaits vérifiés et où épingler une bordure correcte rend SAT, la même discipline de témoin positif que la reproduction plus haut ; les verdicts UNSAT sont réels, pas des artefacts. Le bord ouvert de ce résultat en est le meilleur résumé. Seules neuf configurations de bordure existent dans notre corpus, et une bordure compatible avec un 480 existe à coup sûr : le puzzle a été construit à partir d'une solution. Elle n'est simplement aucune des bordures qu'une recherche de classe record ait jamais produites. Polir près d'un record n'est pas seulement lent ; sous la propre bordure de ce record, atteindre 480 est prouvé impossible. Une solution exige une autre bordure. ## Pourquoi le mur existe La page jusqu'ici prouve le mur ; voici ce qui se rapproche le plus d'une raison. Modélisez l'ensemble des plateaux à score fixé comme un graphe dont les arêtes sont des mouvements touchant au plus $k$ cellules, et demandez le plus petit $k$ qui le connecte : le rayon de connectivité. Sur de petites instances d'appariement d'arêtes où chaque plateau peut être énuméré exactement, deux lois émergent. Premièrement, le rayon est petit sur l'essentiel du spectre des scores et saute au plateau entier exactement au score maximal : sur une instance à 6 cellules, $k$ vaut 2 à 4 cellules aux scores intérieurs et 6, le plateau entier, au maximum ; sur une instance à 9 cellules, le rapport $k/N$ se situe autour de 0,22 à 0,44 à l'intérieur et 0,78 au sommet. Deuxièmement, la rigidité s'allume avec la richesse des couleurs : en balayant la palette sur les instances à 9 cellules, le support moyen du mouvement minimal monte de 1,4 à 7,6 cellules quand les couleurs passent de 2 à 8, et la fraction d'instances dont les solutions parfaites exigent un mouvement plein-plateau pour s'interconnecter monte de 0 à 70 pour cent. À l'échelle jouet, il y a un théorème, prouvé par un argument de forçage et vérifié par énumération exhaustive : si le jeu de couleurs est assez riche pour que chaque couleur d'arête exposée n'admette au plus qu'une tuile légale pendant un remplissage, alors deux solutions parfaites distinctes ne partagent *aucune cellule*, si bien que tout mouvement entre elles doit toucher chaque cellule. À une richesse de couleurs comparable à celle du vrai puzzle, chaque instance testée était rigide exactement en ce sens : zéro cellule partagée entre toute paire de solutions parfaites. Pour Eternity II lui-même, c'est une conjecture, et nous l'étiquetons comme telle. Avec 22 couleurs intérieures, chacune réutilisée environ 24 à 50 fois sur 480 adjacences intérieures, le vrai puzzle siège profondément dans le régime rigide, si bien que des plateaux quasi parfaits distincts devraient être quasi orthogonaux (ce qui correspond à la différence de 225 cellules observée plus haut entre bons plateaux) et qu'aucun mouvement de taille bornée ne devrait relier des optima distincts. La condition « au plus une tuile » n'est pas strictement vraie sur E2, donc l'affirmation défendable est « une grande fraction du plateau », pas « prouvablement les 256 cellules ». Le corollaire est la partie satisfaisante : la recherche locale gèle *précisément aux hauts scores* parce que c'est là que le graphe des mouvements se déconnecte. L'intérieur de la gamme des scores se parcourt facilement, d'où le fait qu'atteindre les 450 et 460 soit routinier ; le sommet est un ensemble de points isolés, d'où le fait que le polissage y meure. Une théorie, les deux moitiés de l'histoire de cette page. (Les mathématiques sont le cercle d'idées des bases de Markov et de Graver en statistique algébrique ; voir les sources. Les seuls mouvements de sommet bon marché que la théorie autoriserait sont des symétries globales, et ce jeu de pièces n'en a essentiellement aucune.) > **La pièce suivante du tableau** > > Si vous ne pouvez pas améliorer un plateau localement, peut-être pouvez-vous sauter d'un bon plateau à un autre. Cela échoue aussi, pour une raison connexe : [voyez pourquoi le saut de bassin est impossible](/fr/research/why/sigma-cycles/). *Les preuves utilisent la programmation en nombres entiers sur des régions de chaque plateau ; elles tournent plusieurs minutes par région sur un solveur, et ne sont donc pas reproduites en direct ici. Les plateaux eux-mêmes sont fournis et vérifiables dans la visionneuse.* ## À lire aussi - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - [Quel mur arrête quelle méthode](https://eternity2.dev/fr/research/why/walls-and-methods/) — La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [PALIMPSEST](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) — Lire chaque plateau fort pour repérer les habitudes qui, en silence, plafonnent un plateau, puis les briser. Cette expérience a produit le meilleur plateau du projet : 463 sur 480. - [MIDDEN](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/pipelines/midden/) — Décider à l'avance non pas quand un plateau peut casser, mais où : confiner chaque désaccord à une forme de cellules choisie, et chercher la meilleure forme. - [Relaxations LP et PLNE : une demi-pièce partout](https://eternity2.dev/fr/research/build/exact/lp-relaxations/) — Écrivez Eternity II comme un programme en nombres entiers, abandonnez l'intégralité, et un solveur linéaire atteint une erreur nulle en quelques secondes, 30 % d'une pièce et 20 % d'une autre partageant un même coin. Dix-huit ans de campagnes communautaires ont mesuré où s'arrête le confort fractionnaire : un plateau à 420–440 arêtes dès que les pièces doivent être entières, un mur PLNE dès le 8×8, et un record académique de 461 en une heure. Ce qu'enseigne la route de l'optimiseur, et là où le LP reste utile. --- # Pureté de l'anneau : le bord est un sous-puzzle clos, sans aucun jeu > Cinq des 22 couleurs ne touchent jamais les 196 pièces intérieures. La liste des pièces force toute solution valide à dépenser les 120 demi-arêtes de cadre sur l'anneau du bord : un sous-puzzle autonome à jeu exactement nul (120 = 120), un circuit eulérien sur cinq sommets, relié à l'intérieur par seulement 56 arêtes tournées vers le centre. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/ring-purity/ - Mise à jour: 2026-07-22 - Sujets: structure - Source: Pureté de l'anneau : le sujet de reproduction avec l'article, le vérificateur versionné et le JSON de résultats (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/ring-purity - Source: Brendan Owen numérise le jeu de pièces : 24 demi-arêtes pour chacune des 5 couleurs de jonction du bord, 48 ou 50 pour chaque couleur intérieure (groups.io msg 1054, juillet 2007) — https://groups.io/g/eternity2/message/1054 - Source: Brendan Owen, Design the hardest puzzle : la séparation délibérée de la palette en 17+5 (groups.io msg 1947, août 2007) — https://groups.io/g/eternity2/message/1947 --- Cinq des 22 couleurs d'arêtes n'apparaissent sur aucune des 196 pièces intérieures. Dans la numérotation standard, ce sont les couleurs 1 à 5 : les couleurs de cadre. Chacune occupe exactement 24 demi-arêtes, toutes portées par les 60 pièces de bord, soit une réserve totale de 120. La pureté de l'anneau, c'est l'énoncé suivant : les données des pièces ne laissent aucun choix à cette réserve. Toute solution valide dépense l'intégralité des 120 demi-arêtes sur les 120 emplacements de l'anneau du bord tournés vers l'anneau lui-même, sans aucun jeu. Le bord est un sous-puzzle autonome, et son seul contact avec l'intérieur passe par 56 arêtes tournées vers le centre.
120 = 120
demande de l'anneau contre réserve de cadre, jeu nul
5 × 24
couleurs de cadre × demi-arêtes chacune
56
arêtes reliant l'anneau à l'intérieur
## Trois faits sur la liste des pièces La preuve repose sur trois propriétés vérifiables en parcourant une seule fois les 256 pièces. Aucune recherche, aucun échantillonnage. Premièrement, les couleurs de cadre n'apparaissent que sur les pièces de bord. Le vérificateur ne fait pas confiance aux étiquettes : il dérive l'ensemble des couleurs de cadre depuis les données, comme les couleurs à zéro occurrence sur les pièces intérieures, et en trouve exactement cinq. Deuxièmement, chacune des 56 pièces d'arête porte exactement deux emplacements de couleur de cadre et un emplacement hors cadre parmi ses trois emplacements non nuls, et l'emplacement hors cadre se trouve à l'opposé de l'emplacement gris. C'est le cas 56 fois sur 56. Troisièmement, les deux emplacements non nuls de chaque pièce de coin sont de couleur de cadre, et les deux emplacements gris sont adjacents. C'est le cas 4 fois sur 4. Pour mémoire, le reste de la palette est aussi plat que la partie cadre : parmi les 17 couleurs intérieures, 5 apparaissent 48 fois et 12 apparaissent 50 fois. Brendan Owen a mesuré exactement ces effectifs la semaine où il a numérisé son jeu ([msg 1054](https://groups.io/g/eternity2/message/1054)), et la séparation stricte des deux palettes était une décision de conception ([msg 1947](https://groups.io/g/eternity2/message/1947)) ; la [page sur la recette de conception](/fr/research/why/design-recipe/) raconte cette histoire. ## L'argument de forçage Une pièce d'arête se pose sur le pourtour avec son emplacement gris tourné vers l'extérieur ; l'emplacement opposé au gris regarde donc l'intérieur. Son voisin de ce côté est une pièce intérieure, qui, par le premier fait, n'a aucune couleur de cadre à offrir. L'emplacement tourné vers l'intérieur ne peut donc pas porter une couleur de cadre. Par le deuxième fait, la pièce d'arête possède exactement un emplacement hors cadre, et il se trouve précisément à l'opposé du gris, c'est-à-dire à la position intérieure. Les deux emplacements de cadre sont donc forcés sur les deux positions tournées vers l'anneau, le long du pourtour. Les coins, par le troisième fait, apportent leurs deux emplacements non nuls à l'anneau. Comptons. Demande : $56 \times 2 + 4 \times 2 = 120$ emplacements tournés vers l'anneau. Réserve : $5 \times 24 = 120$ demi-arêtes de cadre. Les deux nombres coïncident exactement. Chaque demi-arête de cadre est consommée sur l'anneau, aucune ne reste, et aucune couleur hors cadre n'apparaît jamais sur une jonction de l'anneau. C'est le sens de « sans aucun jeu » : le budget des couleurs de cadre est dépensé jusqu'à la dernière demi-arête. ## L'anneau est un circuit eulérien Cette saturation admet une lecture nette en théorie des graphes. Prenez un multigraphe à 5 sommets, un par couleur de cadre, avec une arête par pièce de bord, joignant ses deux couleurs tournées vers l'anneau. Un arrangement valide de l'anneau du bord est exactement un circuit eulérien de ce multigraphe : parcourir l'anneau, c'est lire un circuit fermé qui utilise chaque arête-pièce une fois, et réciproquement. Sur l'instance réelle, le multigraphe compte 60 arêtes, tous ses degrés valent 24, et il est connexe : un circuit eulérien existe donc, comme il le doit, puisqu'une solution complète existe. Parmi les 60 arêtes, 14 sont des boucles (des pièces montrant la même couleur de cadre sur leurs deux emplacements d'anneau), et les arêtes couvrent les 15 paires de couleurs possibles, les 10 paires non ordonnées plus les 5 boucles. ## Ce que vaut la loi Deux mesures de force accompagnent le théorème, une exacte et une échantillonnée. L'exacte est le branchement du premier pas. Fixez une pièce de bord posée ; la pièce suivante le long de l'anneau doit s'accorder à la couleur de cadre exposée. Parmi les pièces de bord, seules celles incidentes à cette couleur conviennent : selon la couleur, 20, 21, 21, 22 ou 22 d'entre elles, moyenne 21,2, contre 59 candidates pour un ordre sans contrainte. L'accord de couleur divise à lui seul le premier facteur de branchement par 2,78. L'échantillonnée est une estimation par échantillonnage préférentiel séquentiel sur 1000 constructions gloutonnes ensemencées de l'anneau. Le log10 moyen de la probabilité d'un chemin achevé vaut -27,30 (écart-type 0,64) pour la graine 1 et -27,39 (écart-type 0,62) pour la graine 2, contre une référence uniforme de $\log_{10}(1/59!) = -80,14$. Autrement dit : la loi d'accord des couleurs concentre la masse de probabilité d'environ 53 ordres de grandeur par rapport à un ordre uniforme des pièces de bord, tout en laissant une rareté résiduelle proche de $10^{-27}$. Une marche gloutonne purement guidée par les couleurs n'achève donc presque jamais un anneau : 8,7 % de complétions pour la graine 1, 9,3 % (graine 2, exécutée pour vérifier la cohérence ; le JSON archivé couvre la graine 1) pour la graine 2, la mesure d'origine donnant 9,4 %. Les 87 constructions achevées de la graine 1 se sont toutes refermées en circuit, extrémités concordantes, ce qui est la structure eulérienne visible dans l'échantillon. ## Ce qui reste ouvert Le décompte exact des circuits eulériens non orientés du multigraphe réel de l'anneau est ouvert. Un raccourci à orientation unique via le théorème BEST a été tenté pendant l'étude d'origine, démasqué comme sous-décompte par un test de contrôle sur K5, puis retiré ; aucun décompte de circuits n'est revendiqué nulle part. La mesure de complétion gloutonne ignore par ailleurs l'alternance géométrique coins/arêtes de l'anneau physique : elle mesure la loi d'accord des couleurs isolément, pas la contrainte complète de l'anneau. ## Où cela se place, et comment le vérifier Le théorème découpe le puzzle le long du pourtour. Côté intérieur, les 56 pièces d'arête montrent chacune une couleur de la palette intérieure à 17 couleurs, et ces 56 arêtes constituent toute l'interface du bord avec les 196 pièces intérieures ; la comptabilité à travers cette couture est le sujet de la [page sur l'équilibre du bord](/fr/research/why/border-balance/). Le visage visible de la même séparation, les cinq couleurs rares cantonnées au pourtour, se trouve sur la [page de géographie des couleurs rares](/fr/research/why/rare-color-geography/). Et cette page est le récit détaillé d'une des lois du [balayage des théorèmes](/fr/research/why/theorem-sweep/), aux côtés du reste de la structure exacte de l'instance. Chaque nombre ci-dessus est recalculé par le vérificateur versionné du sujet de reproduction indiqué dans les sources : un programme Rust unique qui charge l'instance officielle, dérive les couleurs de cadre depuis les données, vérifie exhaustivement chaque clause du théorème, construit le multigraphe de l'anneau, exécute les deux mesures Monte-Carlo ensemencées et produit un fichier JSON (versionné sous `results/ring_purity.json`) contenant tous les chiffres cités ici. Les clauses déterministes se reproduisent à l'octet près ; les mesures échantillonnées concordent, à l'erreur d'échantillonnage près, sur des graines indépendantes. ## À lire aussi - [La moisson de théorèmes : treize lois de structure](https://eternity2.dev/fr/research/why/theorem-sweep/) — Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. - [L'équilibre du bord](https://eternity2.dev/fr/research/why/border-balance/) — Un plateau résolu dissimule une loi comptable toute simple : chaque couleur que le bord tend vers l'intérieur, l'intérieur la lui rend aussitôt. La violer, c'est savoir sur-le-champ que le plateau est faux ; la respecter, en revanche, ne garantit rien. - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. - [Conçu pour être insoluble : la recette](https://eternity2.dev/fr/research/why/design-recipe/) — Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. --- # Pourquoi le basin-hopping semble impossible > Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/sigma-cycles/ - Mise à jour: 2026-07-22 - Sujets: structure, local-search - Reproduire: `just research-sigma-cycles` - Source: Annonce du record 469 de Peter McGavin : l'un des plateaux contre lesquels les cycles sont calculés (groups.io msg 10045, septembre 2020) — https://groups.io/g/eternity2/message/10045 - Source: J. Houdayer, A cluster Monte Carlo algorithm for 2-dimensional spin glasses (arXiv) : l'original, en physique, du mouvement de transplantation de boucles entières — https://arxiv.org/abs/cond-mat/0101116 - Source: Théorème de Jordan pour le groupe symétrique : l'outil de théorie des groupes derrière le calcul d'absence de structure cachée — https://en.wikipedia.org/wiki/Jordan%27s_theorem_(symmetric_group) --- Deux plateaux de haut niveau paraissent totalement différents, et pourtant ils sont liés : on peut transformer l'un en l'autre en prélevant un ensemble de pièces et en déplaçant chacune vers l'emplacement qu'occupait la suivante, tout le long d'une boucle. Les mathématiciens appellent cette boucle un cycle. Parcourez la boucle entière et vous arrivez à l'autre plateau. Voici le hic. Entre les meilleurs plateaux, cette boucle est énorme. Passer d'un plateau à 464 de Riotte à celui à 469 de McGavin, c'est une boucle imbriquée allant jusqu'à 189 cellules, accompagnée de quelques plus courtes, déplaçant presque toutes les pièces du plateau. Une habitude de ce paysage mérite d'être nommée avant les schémas : la distance en score ne dit rien de la distance en configuration. Dans une paire mesurée, deux plateaux séparés de deux points de score différaient sur 88 % de leurs positions ; dans une autre, deux plateaux séparés d'un point différaient sur 72 cellules. (Deux paires, des exemples illustratifs et non des statistiques de population ; la preuve à l'échelle de la population, c'est le balayage ci-dessous.) « Marcher d'un 456 vers un 457 voisin » n'est pas un plan sensé quand le plateau « voisin » peut se trouver à presque tout un plateau de distance. Sauf mention contraire, chaque score de cette page compte les arêtes appariées sur 480 du puzzle canonique ; quand l'un de nos propres plateaux apparaît, nous précisons si ses cinq pièces-indices sont en place. ## Une seule boucle, tout ou rien > **[Interactive: SigmaCycleDiagram]** Rendered on the canonical page (link above); not shown in this markdown export. ## Essayez sur un vrai petit puzzle Ce n'est pas un schéma : le moteur en direct trouve deux solutions réelles, calcule les cycles effectifs entre elles, et note chaque étape que vous franchissez. > **[Figure]** Interactif : appliquer une partie du cycle de permutation — interactive: SigmaCycleLab. Rendered on the canonical page (link above); not shown in this markdown export. ## Comment nous le savons Nous l'avons fait tourner sur chaque plateau que nous fournissons. Pour chaque paire ordonnée de plateaux partageant un même jeu de pièces, nous calculons les cycles exacts, puis essayons chaque mouvement partiel : n'appliquer qu'un préfixe de boucle et re-noter. Cela fait **246 paires**, **1 154 grandes boucles** et **54 238 applications partielles** au total. Aucune n'a atteint le score du plateau dont elle partait. Chaque mouvement partiel a perdu du terrain ; au mieux un préfixe s'est arrêté à un seul point sous son départ, et le pire a chuté de 224 points. C'est ce qui en fait un mur. Pour passer d'un bon plateau vers un meilleur, il faudrait s'engager à déplacer une boucle entière d'un coup, jusqu'à 195 cellules, sans aucune étape améliorante en chemin pour vous y guider. Toute recherche qui procède par étapes est aveugle à un mouvement de ce genre. Les préfixes ne ferment que la moitié de la porte ; les boucles complètes ferment l'autre. L'un de nos plateaux à 458, décomposé contre le 469 de McGavin, donne 11 boucles (tailles 80, 42, 42, 40, 25, 10, 4, 4, 3, 2, 2). Appliquer une boucle seule fait chuter le score de 5 à 170 points ; même les boucles de 2 cellules perdent 6 à 7 arêtes chacune. Seule la permutation complète, toutes boucles ensemble, atteint 469. Une seconde paire raconte la même histoire avec plus de détail : entre l'un de nos plateaux à 460 et le 469, la permutation se scinde en 15 cycles (longueurs jusqu'à 52), tout cycle isolé coûte 4 à 143 arêtes appariées, chaque combinaison testée des petits cycles finit 10 à 29 arêtes plus bas, et seul le mouvement complet des 253 pièces récupère le gain de 9 points. La proximité en score n'adoucit rien : contre des plateaux à un, deux et trois points au-dessus de ce 460, le meilleur mouvement à un seul cycle véritablement non trivial coûte encore 4 arêtes. Ce sont des calculs exacts et déterministes, mais sur une poignée de paires de notre propre collection ; lisez-les comme « sur chaque paire testée », pas comme un théorème. La version la plus tranchante : même quand nous connaissons un meilleur plateau à une boucle de distance, les étapes ne peuvent pas couvrir cette distance. L'un de nos plateaux à 459 diffère d'un 460 trouvé un jour de seulement 39 cellules, réparties en trois boucles de 21, 14 et 4 cellules. Chaque boucle appliquée seule fait chuter le score de 9 à 11 points, la boucle de 4 cellules comprise ; les paires de boucles atterrissent entre 442 et 454 ; seules les trois ensemble donnent le 460. La recherche par destruction-réparation lancée depuis le meilleur partiel à deux boucles (un 451) est remontée au mieux à 459, jamais au 460 pourtant connu, sur 15 configurations (5 graines, 3 jeux d'opérateurs, 30 secondes chacune). Une seule paire source-cible, et ce 460 était une trouvaille unique ; mais l'indivisibilité mord à 4 cellules exactement comme elle mord à 154. ## Fabriquer nos propres boucles Tout ce qui précède compare des paires de plateaux connues. Nous avons aussi attaqué par l'autre côté : construire les boucles nous-mêmes. Prenez un plateau fort, choisissez un anneau de cellules, faites tourner chaque pièce d'un cran le long de l'anneau comme un seul mouvement indivisible, puis donnez au plateau la réparation locale la plus forte que nous ayons pu bâtir (re-tourner chaque pièce touchée, puis re-permuter exhaustivement le pire amas cassé, jusqu'à 6 cellules). Nous avons lancé environ 4 000 boucles construites de ce genre sur deux plateaux : notre meilleur plateau bâti de zéro, à 461 arêtes appariées avec les cinq pièces-indices en place, et un 456 issu du même pipeline. Ce sont nos propres meilleurs, bien en dessous de ceux de la communauté ; voyez [la page des records](/fr/research/records/) pour les situer. Sur 8 graines et plus et trois familles de construction de boucles, le nombre de mouvements ayant atteint un plateau *différent* au score de départ ou mieux : exactement zéro. Chaque fois que la réparation remontait au score de départ, elle avait silencieusement défait la boucle et reconstruit le plateau d'entrée à l'identique. Le mécanisme est la même arithmétique de frontière qui traverse toute cette page : une boucle construite présente de nouvelles couleurs le long de tout son pourtour, la perte avant réparation vaut à peu près la taille du pourtour, et une réparation locale ne peut regagner ces arêtes qu'en inversant la boucle. S'échapper exigerait des pièces affluant de tout le plateau, précisément le mouvement tout-ou-rien que l'analyse des cycles réclame. Le mouvement non local le moins cher trouvé coûte exactement une arête : échangez deux pièces éloignées aux couleurs quasi identiques et vous obtenez un plateau véritablement différent à 460, à deux cellules du 461. L'affirmation « zéro évasion » vaut pour cet opérateur et cette force de réparation (fenêtres locales jusqu'à 6 cellules), pas pour toute réparation concevable. ## Les cycles, mesurés Les plateaux se répartissent en deux familles qui utilisent les mêmes pièces (le visualiseur les stocke sous deux alphabets de couleurs), et nous testons chaque paire à l'intérieur de chacune : - Les plateaux-records vers le 469 de McGavin se résolvent en une boucle géante allant jusqu'à 189 cellules, accompagnée de quelques plus courtes, déplaçant environ 250 des 256 cellules. - La plus grande boucle d'une paire va de 6 à 195 cellules, médiane 119 ; deux paires se réduisent à une boucle unique, tout ou rien. - **Chaque préfixe propre de chaque grande boucle donne un score strictement moins bon que son plateau de départ, sur les 54 238 testés, sans une seule exception.** Trois paires choisies à la main le suggéraient ; la population complète le confirme sur les plateaux que nous fournissons, même s'il n'est toujours pas prouvé que cela vaille pour tout plateau concevable. Une propriété mesurée de plus compte pour qui conçoit des opérateurs : les grandes boucles sont éparpillées, pas régionales. En décomposant l'un de nos plateaux à 458 contre le 469, chaque boucle de 25 cellules ou plus couvre les lignes 1 à 14 et les colonnes 1 à 14, autrement dit tout l'intérieur, et une petite boucle de 4 cellules est exactement les quatre coins. (Une seule paire de plateaux, mais cela concorde avec le mécanisme des coins plus bas.) Un opérateur régional (détruire une fenêtre, réparer une fenêtre) ne peut donc jamais contenir une boucle ; pire, chaque cellule d'une boucle a besoin d'une *pièce différente*, pas d'un réarrangement des pièces déjà dans la région. ## Pourquoi tout mouvement partiel doit perdre : la loi de la frontière Le recensement dit que les mouvements partiels perdent toujours ; voici la raison géométrique, et elle est quantitative. Les cellules d'une boucle étant éparpillées sur le plateau, tout sous-ensemble partiel possède une longue frontière face aux cellules intactes. Chaque arête de frontière appose une pièce déplacée contre un voisin auquel elle n'a jamais été appariée dans aucun des deux plateaux d'arrivée, et presque chacune de ces arêtes casse. La perte de score d'un mouvement partiel vaut, à bonne approximation, la taille de sa frontière. Mesuré sur la boucle de 154 cellules entre l'un de nos plateaux à 459 et le 469 : la frontière minimale sur toutes les applications partielles contiguës est d'environ 190 arêtes de grille, atteinte vers la mi-parcours (autour de 113 cellules appliquées) ; le ratio frontière-par-cellule va de 1,07 à 4,0 selon la taille du sous-ensemble. Ces chiffres de boucle géante viennent de ce seul cycle ; des boucles plus petites à score égal, mesurées sur deux paires de plateaux indépendantes, donnent 2,0 à 3,5 arêtes de frontière par cellule. La réparation locale après un mouvement partiel regagne typiquement de l'ordre de 30 à 50 arêtes. Une capacité de réparation de 30 à 50 face à un trou d'environ 190 arêtes : cette inégalité, c'est le mur. La loi est aussi serrée, partout où nous avons regardé. Sur plus de 200 applications partielles couvrant 5 boucles, la perte réalisée colle à la frontière à 2 arêtes près pour les sous-ensembles jusqu'à 50 cellules ; entre 92 % et 100 % des arêtes de frontière cassent réellement. Le meilleur résultat jamais observé perd 3 arêtes, sur un mouvement d'une seule cellule à frontière 4. Le sous-ensemble le plus mince de tout le corpus (ratio frontière-taille 0,67, un sous-ensemble de 45 cellules d'une boucle de 190 cellules entre deux plateaux au même score) perd exactement sa frontière : moins 30 prédit, moins 30 mesuré. Aucun sous-ensemble à gain positif n'existe dans le corpus. C'est un seul corpus interne de 7 plateaux ; la bonne formulation est « sur chaque paire mesurée », pas « prouvé pour tout plateau ». Ruser sur le sous-ensemble n'échappe pas non plus à la loi. Au lieu de blocs contigus, nous avons fait croître gloutonnement le sous-ensemble qui minimise la frontière, puis laissé la recherche par destruction-réparation nettoyer derrière. Les sous-ensembles gloutons à frontière minimale de la boucle de 154 cellules atteignent bien 35 à 45 % de frontière en moins que les contigus ; aux tailles 10, 20 et 40, les frontières font 24, 38 et 64 arêtes et les pertes réalisées 22, 38 et 63, soit pour l'essentiel 100 % de la frontière. La réparation depuis ces plateaux abîmés plafonne à 448, 441 et 430 respectivement, tous bien sous le départ à 459, sur 12 combinaisons de graines et d'opérateurs à 30 secondes chacune ; une exécution de 5 minutes sur le meilleur cas stagne encore à 446-448. (Une boucle, une méthode gloutonne de construction du sous-ensemble.) La partie instructive : un mouvement partiel n'a pas laissé le plateau à mi-chemin entre deux bons plateaux ; il l'a fait tomber dans une troisième vallée, plus basse, dont le propre plafond se trouve sous le point de départ. Le plateau de score était déterminé par la vallée, pas par le budget. ## Le paysage que relient les boucles Que relient donc les boucles ? Mesuré sur nos propres collections de plateaux, le paysage à score égal est binaire : quasi-jumeaux ou quasi-étrangers, rien entre les deux. Parmi sept de nos plateaux qui font tous 459, six forment une seule famille, différant deux à deux de seulement 34 à 44 cellules sur 256 avec des boucles de 9 à 25 cellules ; le septième est une île, différant de la famille de 251 à 253 cellules avec des boucles jusqu'à 190 cellules. Aucune paire ne se trouve à distance intermédiaire, et une raison algébrique fait attendre exactement cette forme : les boucles se composent en conservant les pièces, donc ajouter une petite boucle à une boucle géante donne une autre boucle géante ; rien n'interpole entre une paire proche et une paire lointaine. (Un corpus de 7 plateaux produits par notre propre pipeline, biaisé vers la famille que notre recherche trouve ; le compte de la famille est une borne inférieure et le nombre d'îles inconnu.) À l'échelle de la population, l'image de l'île tient. En groupant les 135 plateaux uniques à 455 ou mieux que notre recherche ait jamais produits, en reliant deux plateaux qui diffèrent de moins de 100 cellules, on obtient 47 composantes : 18 singletons, une plus grande famille de 22 membres (une famille à 458), et le 469 de McGavin comme composante dont le plus proche voisin du corpus se trouve à 247 cellules. C'est environ dix fois le plus grand opérateur de destruction que notre recherche de réparation utilise (64 cellules). (Un instantané d'un corpus biaisé par la recherche.) Il existe aussi un candidat structurel au fait que les plateaux du sommet diffèrent presque partout : ils s'engagent sur des arrangements différents des quatre pièces de coin. Les trois plateaux du sommet examinés (le 469, un 459 et un 458) utilisent trois permutations différentes des quatre coins ; le 469 et le 459 partagent exactement une position de pièce sur 256, l'indice central obligatoire, tandis que le 459 et le 458 en partagent 29. Déplacer une pièce de coin vers un autre coin force le ré-appariement de tout l'anneau de bord de 60 cellules, qui conditionne à son tour l'intérieur : un mouvement à l'échelle du plateau par construction. Avec 4! = 24 arrangements de coins possibles, le paysage pourrait se scinder en jusqu'à 24 classes incompatibles par le bord ; ce dernier pas est une conjecture tirée de trois plateaux, pas une mesure. Avec [le mur de rigidité](/fr/research/why/rigidity-wall/), l'indivisibilité des boucles et leur éparpillement, cela fait une quatrième ligne indépendante pointant vers une même conclusion : seuls des mouvements à l'échelle du plateau relient les plateaux de classe record. ## Y a-t-il une structure cachée dans les boucles ? Question de suite naturelle : les permutations entre plateaux du sommet obéissent-elles à une algèbre, une loi de groupe exploitable pour prédire ou construire de nouveaux plateaux du sommet ? Nous avons calculé la réponse exactement, et c'est non. Prenez les permutations reliant six plateaux du sommet (trois 458, un 459, un 460 et le 469) et regardez le groupe qu'elles engendrent dans le groupe symétrique sur 256 pièces. La seule structure présente est forcée et sans intérêt : les pièces de coin vont sur des coins, les pièces de bord sur des bords, l'intérieur sur l'intérieur. Cela est un théorème pour tout plateau légal, puisqu'une pièce à k côtés gris ne peut occuper qu'une cellule à k faces tournées vers l'extérieur. À l'intérieur de ces trois classes (196 intérieures, 56 de bord, 4 de coin), le groupe engendré est le groupe symétrique complet à une seule relation de parité près (la parité intérieure égale la parité des coins ; la parité des bords est libre), un objet d'ordre environ 4,3 × 10441. Deux paires de plateaux engendrent déjà tout cela, exactement comme se comportent des permutations *aléatoires*. Et le groupe n'a aucun rapport avec le score : appliquez l'un de ces ré-étiquetages à tout plateau autre que sa cible unique et le score s'effondre (le 469 tombe à 119, un 458 à 44, un 459 à 50). (Calcul exact avec preuves via le théorème de Jordan, sur les six plateaux analysés ; la contrainte de type de pièce seule vaut pour tous les plateaux ; le résultat ne dépend pas du choix de base et ne change pas si l'on exclut le plateau communautaire.) Trois conséquences méritent d'être écrites noir sur blanc. Les statistiques de longueur de cycle ci-dessus ne sont que la structure de cycle générique d'un immense groupe symétrique. Les arguments de comptage par symétrie ne peuvent pas prédire combien de plateaux du sommet existent. Et il n'y a aucun raccourci algébrique pour recombiner de bons plateaux : la rareté des plateaux du sommet est un phénomène de score et de géométrie, pas de symétrie. L'expérience de recombinaison directe est d'accord. Nous avons croisé des plateaux : 56 hybrides à lignes entrelacées issus de 18 parents à 458 ou mieux, chacun avec 5 minutes de réparation. Les seuls hybrides à bien scorer (quatre, à 461) étaient une illusion : leurs familles parentes partageaient tant de placements que l'entrelacement reproduisait un plateau déjà dans notre collection ; ces parents étaient déjà reliés par exactement les petites boucles que décrit cette page, et la réparation n'a rien apporté (zéro conflit avant la première itération). Chaque hybride issu de parents véritablement étrangers a fini entre 371 et 436, et la réparation n'a pas pu les récupérer. Avec ce schéma de croisement et ce court budget de réparation, le croisement soit rebrasse des plateaux reliés par boucles, soit vole en éclats. ## Le seul petit mouvement gratuit : l'échange de jumelles Une famille de petits mouvements préservant le score existe bel et bien, et elle confirme la règle au lieu de la casser. Deux pièces quasi jumelles, identiques sur trois de leurs quatre couleurs d'arête, peuvent échanger leurs places ; l'échange change *quelles* arêtes cassent, pas nécessairement combien. Appliqué au 469 de McGavin (les pièces de tuples de couleurs 13-16-14-16 et 13-16-14-18, qui diffèrent d'une seule arête, posées à deux positions de la même ligne), un tel échange produit un plateau véritablement différent qui score aussi 469 ; les deux plateaux diffèrent d'exactement 2 cellules. Celui-là est déterministe et vérifié sur les deux plateaux. Le jeu de pièces canonique contient 5 paires jumelles et 114 paires quasi jumelles, donc ces mouvements existent en quantité, mais ce sont des trocs, pas des gains : sur nos propres plateaux, échanger deux pièces dont les quatre couleurs coïncident comme multiensemble mais pas en ordre cyclique coûte toujours 4 arêtes (aucune rotation ne les réaligne), et le meilleur échange quasi jumeau trouvé coûte 1. Un ensemble de niveau de score est clos par échanges de jumelles, ce qui le rend épais dans cette seule direction triviale ; tout petit mouvement non trivial perd. Qu'un échange de jumelles quelque part gagne un point reste ouvert ; aucun de ceux que nous avons essayés ne l'a fait. ## Tout ce que nous avons lancé contre le mur Les résultats ci-dessus suggèrent des contre-attaques évidentes, et nous les avons essayées. Chaque entrée ci-dessous est l'échec d'une configuration, cadré comme tel ; aucune n'est une réfutation universelle. **La chaleur.** Une chaîne de Metropolis assez chaude pour accepter presque tout mouvement n'escalade pas le mur ; elle tombe de la montagne. Des chaînes à échanges de paires aléatoires parties de l'un de nos plateaux à 459, 100 000 itérations à chacune de six températures (T de 2 à 50), s'effondrent à des scores de 20 à 25 en quelques milliers de pas et ne revisitent jamais 450 ou mieux (la seule visite à cette hauteur est l'état de départ), malgré des taux d'acceptation de 85 à 99 %. Une chaîne dont les mouvements sont des boucles entières fait mieux en un sens étroit : elle navigue indéfiniment entre plateaux au même score, planant à 459 et y visitant plusieurs plateaux distincts, mais le maximum jamais vu est 459 (exécutions courtes : 500 itérations, 2 configurations). Un seul plateau de départ, et la seule famille des chaînes chauffées simples ; des variantes plus fines comme le tempering parallèle à mouvements de boucles ne sont pas testées ici, donc pas réfutées. Le mécanisme : les plateaux du sommet sont une aiguille de mesure nulle dans l'espace des configurations, et un marcheur aléatoire perd l'aiguille instantanément ; les mouvements de boucle préservent le score en entier et le perdent en partie, donc la chaîne peut errer sur un ensemble de niveau sans jamais construire une ascension. **Les transplantations de boucles entières.** Transplanter le jeu complet de boucles d'un meilleur plateau « oracle » est un vrai opérateur ; c'est la version puzzle du mouvement de cluster de la physique des verres de spin (le Monte Carlo à clusters de Houdayer, en sources). Il a même marché une fois, à plus basse altitude : appliquer le jeu complet de boucles d'un oracle à 456 sur un plateau à 447, suivi d'une phase de redémarrage à haute température, a sauté de 447 à 457 par-dessus une unique barrière de 76 cellules, d'un coup. Depuis un plateau du sommet, jamais aucun gain : depuis un 457 contre deux oracles à 456 distincts, chacune des 4 à 6 boucles par paire a un delta strictement négatif, et l'application complète fait tomber le plateau à 453-456. Une seule instance de succès et deux paires d'oracles en échec, donc le cadre est « sur les paires essayées » ; notablement, l'opérateur n'a jamais été testé avec un oracle *meilleur* que le plateau de départ, faute d'en avoir eu un. Le mécanisme : une transplantation n'aide que si la bonne région de l'oracle recouvre la zone de désaccord du plateau courant ; entre vallées distinctes du sommet, les bonnes régions ne s'alignent pas, et chaque boucle importe plus d'erreurs qu'elle n'en corrige. **Dire à la réparation où est la boucle.** Nous avons donné à la recherche par destruction-réparation les cellules exactes qu'occupe une boucle : détruire précisément celles-là, laisser la réparation les remplir. Aucun effet. Sur un plateau partiellement construit (score 442, plus grande boucle de 71 cellules contre une référence à 459), l'opérateur de destruction ciblant la boucle se déclenche 9 à 13 fois par exécution et est toujours accepté, et pourtant les scores finaux font 448 avec ou sans lui (exécutions de 120 secondes ; un plateau, une graine, un budget). La partie instructive : la contrainte ne vit pas dans les cellules de la boucle mais dans l'anneau d'arêtes intactes qui les entoure, qui force la réparation à réinstaller les pièces mêmes qu'elle vient de retirer. Il faudrait les *pièces* de l'autre plateau, pas seulement son ensemble de cellules. **L'adoption forcée.** Enfin nous avons tenté la téléportation : épingler 61 cellules d'un plateau du sommet aux paires de pièces caractéristiques de la vallée du record (elles se concentrent dans les lignes du bas, là où ce plateau est le plus rigide), puis laisser la réparation reconstruire tout le reste. L'épinglage ravage le plateau, jusqu'à 254 sur 480, et une demi-heure de réparation par tentative remonte au mieux à 374 sur 6 graines (meilleurs par graine de 363 à 374) : très loin du départ à 461, sans parler du record. Un plateau de départ, une taille d'ensemble d'épingles, aucun balayage du nombre d'épingles. C'est encore la loi de la frontière : forcer un sous-ensemble de la structure de destination sans la boucle entière est un mouvement partiel de boucle sous un autre nom. ## Pourquoi c'est important Conjuguée avec [le mur de rigidité](/fr/research/why/rigidity-wall/), cette observation ferme d'un coup les deux voies de sortie évidentes. On ne peut pas s'extraire localement d'un bon plateau, et on ne peut pas non plus sauter vers un voisin, car le meilleur plateau le plus proche se trouve à un unique mouvement indivisible de nombreuses cellules, sans étape améliorante pour vous y conduire. Ces cycles atteignent le 469 de McGavin et le 470 de Blackwood ; lire le même mur à travers les deux alphabets raconte une seule histoire. C'est une explication plausible de la raison pour laquelle le record de 470 tient depuis 2021 : les mouvements qui le battraient semblent trop vastes pour qu'une recherche pas à pas puisse les trouver. Les ajouts ci-dessus affinent ce tableau sans le changer. Le mur ne cache pas de symétrie exploitable : les boucles sont des mélanges génériques, preuve à l'appui. La proximité en score ne l'adoucit pas : même à un point de distance, le meilleur mouvement à un seul cycle non trivial perd. Les distances sont hors d'échelle pour nos outils : le plateau le plus proche du 469 que nous ayons jamais produit se trouve à 247 cellules, environ dix fois le plus grand opérateur de destruction que manie notre recherche de réparation. Et le seul mouvement gratuit, l'échange de jumelles, change quelles arêtes cassent mais n'a jamais été vu en changer le nombre dans le bon sens. *Le résultat est calculé exactement par `just research-sigma-cycles` et versionné dans le [sujet sigma-cycles](https://github.com/raphael-anjou/eternity2/tree/main/research/topics/sigma-cycles), qui lit les plateaux fournis, les regroupe par jeu de pièces partagé, et note chaque préfixe propre de chaque grand cycle dans chaque paire ordonnée. Le laboratoire interactif ci-dessus exécute le même mécanisme en direct sur de petits puzzles fraîchement générés ; l'animation est une schématisation du mécanisme, non un cycle en particulier. Le balayage des préfixes sur toute la population est la partie couverte par ce pipeline reproductible ; les mesures de la loi de la frontière, le groupement du paysage, le calcul de groupe, les boucles construites et les expériences négatives ci-dessus sont des expériences de carnet distinctes sur nos collections internes de plateaux, chacune rapportée avec son propre cadre dans le texte et pas encore branchée au pipeline automatisé.* ## À lire aussi - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Où vivent les désaccords](https://eternity2.dev/fr/research/why/mismatch-geometry/) — Un plateau quasi parfait ne répartit pas uniformément ses rares erreurs. Il les concentre dans une seule bande de cinq rangées et laisse tout le reste impeccable. Quelle bande ? Cela dépend de la direction dans laquelle la recherche a rempli le plateau, et l'on voit le reflet sur les vrais plateaux record. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. - [KEYRING](https://eternity2.dev/fr/research/lab/experiments/raphael-anjou/learning/keyring/) — Construire un plateau de zéro en classant chaque pièce suivante selon trois signaux appris de plateaux forts passés. A atteint 460 dans une famille de plateaux qu'aucune recherche antérieure n'avait percée. --- # Le mur des 470 : une frontière de phase, pas une limite d'ingénierie > Le plateau communautaire dans les hauts 460 se lit comme une frontière de phase entropique de l'instance, pas comme une limite du génie logiciel : le calcul exact sur le jeu officiel donne une densité de contraintes proche de 0,0094, un paysage recuit qui s'effondre au-delà de 470 et ne franchit 1 qu'à 480, et un nombre attendu de 10 à 20 solutions parfaites quasi orthogonales entre elles. Les nombres côté instance sont exacts ; le tableau du fossé de recouvrement en 16x16 est une conjecture assumée. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/the-470-wall/ - Mise à jour: 2026-07-22 - Sujets: structure - Reproduire: `cd research/topics/the-470-wall/compute && cargo run --release --bin the_470_wall > ../results/landscape.json` - Source: Achlioptas & Coja-Oghlan, Algorithmic barriers from phase transitions (FOCS 2008) : le regroupement des solutions et là où les algorithmes locaux calent dans les CSP aléatoires — https://arxiv.org/abs/0803.2122 - Source: Gamarnik, The overlap gap property: a topological barrier to optimizing over random structures (PNAS 2021) — https://www.pnas.org/doi/10.1073/pnas.2108492118 --- Les meilleurs plateaux publics se regroupent depuis des années dans les hauts 460, et le plafond se tient à 470 sur 480 (l'historique des records vit sur la [page des records](/fr/research/records/)). La question posée ici est de savoir si ces dix derniers points sont un problème d'ingénierie, quelque chose qu'un meilleur backtracker ou une heuristique plus fine finira par arracher, ou une propriété de l'instance elle-même. Traiter le jeu de pièces officiel comme un membre d'un ensemble aléatoire à solution plantée donne une réponse quantitative, et cette réponse désigne l'instance : la réserve de plateaux qu'une recherche peut effectivement atteindre s'effondre exactement là où la communauté s'est arrêtée. L'argument comporte deux couches au statut très différent, et je les garde séparées d'un bout à l'autre. Les nombres calculés sur le vrai jeu de pièces sont exacts, et l'étape de calcul derrière cette page les reproduit bit à bit. Le tableau structurel qui les interprète en 16×16 est une conjecture, appuyée par l'énumération exhaustive de petites instances réglées sur le même paramètre, et elle est étiquetée comme telle plus bas. ## Le sac, mesuré exactement Les 256 pièces se répartissent en 4 coins, 56 pièces de bord et 196 pièces intérieures. En écartant les 64 demi-arêtes grises du pourtour, il reste 960 demi-arêtes colorées, qui s'apparient en les 480 adjacences internes d'un plateau rempli. La comptabilité est serrée : $960 = 2 \times 480$, sans aucun jeu nulle part. Les scores de cette page comptent les adjacences internes appariées sur 480, la même convention d'arêtes appariées que le plafond communautaire ; rien ici ne porte sur la piste stricte à cinq indices. L'économie des couleurs se scinde ensuite en deux sous-systèmes qui ne se parlent jamais. L'anneau du cadre, le cycle des 60 joints entre pièces de bord, n'utilise que les couleurs 1 à 5, chacune présente sur exactement 24 demi-arêtes ; la probabilité que deux demi-arêtes de cadre tirées uniformément s'accordent vaut $p_f = 5 \cdot (24/120)^2 = 0{,}200$. Le sous-système intérieur couvre les 420 autres joints sur les couleurs 6 à 22 (cinq couleurs à 48 demi-arêtes, douze à 50), ce qui donne $p_i \approx 0{,}0588$, presque exactement $1/17$. Ces deux probabilités portent toute l'analyse. Une vérification exacte de plus mérite d'être notée : le vrai sac ne contient aucune pièce qui se répète par rotation. Face à un nul aléatoire apparié, cela semble être la seule empreinte statistiquement significative de la passe de conception ; le côté nul de cette comparaison demande encore son propre générateur, seul le côté jeu réel (exactement zéro) est vérifié ici. ## Un seul nombre situe le régime Le paramètre qui positionne Eternity II dans son ensemble est la densité de contraintes : le nombre attendu de pièces qui conviennent à une case intérieure totalement contrainte, dont les quatre voisines sont déjà posées. Avec 196 pièces intérieures, 4 rotations chacune et une probabilité de collision par arête de 0,0589 pour une arête de pièce intérieure aléatoire, $$\mu = 196 \cdot 4 \cdot 0{,}0589^4 \approx 0{,}0094.$$ Un trou entièrement entouré admet environ un candidat sur cent. C'est très en dessous de un, ce qui place l'instance en plein régime rigide des ensembles de satisfaction de contraintes à solution plantée : le régime où la théorie dit que l'ensemble des solutions se réduit à des points isolés et bien séparés, et où les algorithmes locaux calent prouvablement avant de les atteindre ([Achlioptas & Coja-Oghlan 2008](https://arxiv.org/abs/0803.2122), [Gamarnik 2021](https://www.pnas.org/doi/10.1073/pnas.2108492118)). Le nombre lui-même est une fonction exacte des vrais comptes de couleurs ; ce que le régime implique à cette taille relève de la couche conjecturale, reprise plus bas. ## Le paysage de score recuit La pièce maîtresse côté instance est un comptage au premier moment : combien de configurations de plateau *non corrélées* à la solution plantée atteignent un score donné ? Le compte de base des placements respectant les classes (coins aux coins, bords sur le pourtour, intérieures à l'intérieur, rotations libres pour les pièces intérieures) vaut $W_{\text{geom}} = 4! \cdot 56! \cdot 196! \cdot 4^{196} \approx 10^{559{,}9}$. Le score d'une telle configuration aléatoire est la somme de 60 indicatrices de Bernoulli($0{,}200$) pour le cadre et de 420 indicatrices de Bernoulli($0{,}0588$) pour l'intérieur, et une convolution exacte en espace logarithmique de ces 480 variables donne le paysage complet. Une configuration uniformément aléatoire marque $36{,}7 \pm 5{,}7$. | score | configurations non corrélées à ce score (log10) | | ----: | ----------------------------------------------: | | 37 | 558,8 | | 200 | 462,8 | | 400 | 186,6 | | 460 | 59,6 | | 470 | 33,1 | | 480 | +1,28 | Deux choses ressortent. D'abord, la réserve de plateaux non corrélés à haut score reste astronomique remarquablement haut : environ $10^{60}$ configurations au score 460 et encore environ $10^{33}$ à 470. Ensuite, le compte franchit 1 pratiquement à 480 même : le nombre attendu de placements parfaits non corrélés au plateau planté vaut $10^{1{,}28} \approx 19$. Le modèle de travail que cela chiffre est un ensemble de solutions de l'ordre de 10 à 20 plateaux parfaits, quasi orthogonaux entre eux et orthogonaux au planté, au sommet d'une courbe d'entropie qui dépasse tout juste zéro. ## Exact en dessous, conjecture au-dessus Tout ce qui précède cette ligne est un calcul exact sur le jeu officiel : les comptes de classes, l'économie des 960 demi-arêtes, les deux probabilités de collision, $\mu$, $W_{\text{geom}}$ et chaque ligne du tableau du paysage. La commande de reproduction de cette page régénère tout cela depuis le moteur partagé en moins d'une seconde, dans `results/landscape.json` du dossier du sujet. Ce que le paysage ne dit pas, c'est comment ces rares hauts scores sont *disposés* : la masse entropique se connecte-t-elle aux plateaux parfaits, ou un fossé vide les sépare-t-il ? À cette question je ne peux répondre exactement que sur de petites instances. L'énumération exhaustive de plateaux plantés $n \times n$ pour $n$ jusqu'à 7, avec le nombre de couleurs réglé pour apparier la densité de contraintes, montre une tendance nette : à $\mu$ lâche, l'histogramme de recouvrement avec le planté de l'ensemble des solutions est continu, et quand $\mu$ descend vers le 0,009 d'E2 il devient bimodal puis s'effondre. Au point apparié ($n = 5$, 11 couleurs, $\mu = 0{,}009$), l'énumération trouve la solution plantée, un amas juste à côté d'elle, une grande famille à recouvrement zéro, et une bande totalement vide entre les deux. > **Là où commence la conjecture** > > Les énoncés en 16×16 (un ensemble de 10 à 20 plateaux parfaits quasi orthogonaux, un fossé de recouvrement vide en dessous, et le mur des 470 comme bord visible de ce fossé) sont des extrapolations de la tendance des petites instances le long du paramètre de densité de contraintes. C'est une conjecture, pas une mesure : aucun calcul faisable ne les vérifie directement à taille réelle. Le tableau du paysage et chaque nombre côté instance de cette page sont exacts ; la structure du fossé en 16×16 est la partie à tenir pour un modèle de travail. ## Lire le mur Rapprochez la couche exacte et la couche conjecturale, et le plateau communautaire cesse de ressembler à un déficit d'outillage. Une heuristique qui grimpe le paysage de score puise dans la bande entropique, et cette bande est profonde : avec $10^{33}$ configurations non corrélées encore disponibles à 470, atteindre les hauts 460 est bon marché en un sens précis, et le génie des solveurs moissonne cette bande depuis des années. Au-delà, la réserve s'amincit d'une trentaine d'ordres de grandeur sur dix points de score, et si l'extrapolation du fossé de recouvrement tient, il n'y a rien entre les deux pour grimper : les dix points manquants sont la largeur d'une région vide qui sépare les derniers plateaux entropiques d'une poignée de plateaux parfaits isolés. C'est la propriété du fossé de recouvrement dans son rôle de manuel, une barrière topologique qu'une recherche locale et stable ne peut pas franchir, quelle que soit la qualité de l'implémentation. Cette lecture s'accorde avec ce que nous mesurons ailleurs sur le wiki : le [mur de rigidité](/fr/research/why/rigidity-wall/) trouve les plateaux records figés en optima locaux isolés sans gradient vers l'extérieur, exactement la sensation que devrait donner le bord inférieur d'un fossé vu d'en bas. Elle précise aussi ce que « progresser » devrait vouloir dire. Plus de vitesse et un meilleur ordre achètent des points entropiques, et ceux-ci s'épuisent vers 470 d'après le tableau ci-dessus ; ce qui franchira le fossé devra injecter de la corrélation avec une vraie solution parfaite plutôt que grimper la fonction de score. Les énoncés sur l'instance qui tiennent au niveau de la preuve, par opposition au modèle de travail de cette page, sont rassemblés dans le [balayage des théorèmes](/fr/research/why/theorem-sweep/). ## À lire aussi - [La moisson de théorèmes : treize lois de structure](https://eternity2.dev/fr/research/why/theorem-sweep/) — Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Conçu pour être insoluble : la recette](https://eternity2.dev/fr/research/why/design-recipe/) — Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. --- # La moisson de théorèmes : treize lois de structure > Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/theorem-sweep/ - Mise à jour: 2026-07-22 - Sujets: structure - Source: Conway et Lagarias, Tiling with polyominoes and combinatorial group theory : l'ancêtre des arguments par invariants de bord pour les problèmes de pavage (JCTA 1990) — https://doi.org/10.1016/0097-3165(90)90057-4 - Source: Le théorème BEST, qui compte les circuits eulériens d'un graphe orienté : le bon outil (et un piège documenté) pour compter les arrangements de bordure — https://en.wikipedia.org/wiki/BEST_theorem - Source: Chemins et circuits eulériens : la théorie classique à laquelle l'anneau de bordure se réduit — https://en.wikipedia.org/wiki/Eulerian_path - Source: Johnson, Papadimitriou et Yannakakis, How easy is local search? : le cadre PLS derrière le résultat de complétude de la recherche locale (JCSS 1988) — https://doi.org/10.1016/0022-0000(88)90046-3 - Source: Ben-Sasson et Wigderson, Short Proofs Are Narrow : la machinerie de largeur de résolution derrière la borne inférieure d'épuisement (JACM 2001) — https://doi.org/10.1145/375827.375835 - Source: Krzakala, Montanari, Ricci-Tersenghi, Semerjian et Zdeborova, Gibbs states and the set of solutions of random CSPs : le tableau de la phase condensée sur lequel s'appuie l'analyse du paysage des scores (PNAS 2007) — https://doi.org/10.1073/pnas.0703685104 - Source: Gamarnik, The overlap gap property : le concept de barrière qui correspond à la bande de recouvrement vide mesurée (PNAS 2021) — https://doi.org/10.1073/pnas.2108492118 --- Pendant un moment de ce projet, j'ai posé les solveurs pour poser une autre question : non pas « quel score puis-je atteindre » mais « que puis-je démontrer ». Le plan était une moisson. Emmener le casse-tête dans chaque branche des mathématiques qui a plausiblement quelque chose à en dire (flots et coupes, combinatoire extrémale, physique statistique, algèbre, théorie des CSP, automates, complexité des preuves, complexité de la recherche locale) et pousser chaque branche jusqu'à ce qu'elle livre un théorème ou explique précisément pourquoi elle ne le peut pas. La moisson a produit treize familles de résultats. Cette page est la carte : quelques phrases par famille, avec des liens vers les articles complets quand ils existent. Trois familles ont aujourd'hui leur page dédiée ; les autres recevront la leur au fur et à mesure que leurs reproductions arrivent dans le dépôt. Une remarque de saveur avant la liste. Certains de ces résultats sont des lois que le jeu de pièces respecte, d'autres des théorèmes d'impossibilité sur l'échelle des scores, d'autres encore des négatifs propres : la preuve qu'un outil standard d'un autre domaine, correctement appliqué, ne certifie rien ici. Les négatifs sont énoncés avec le même soin que les positifs. Savoir qu'une porte est verrouillée, et pourquoi, c'est ce qui permet d'arrêter d'en payer le loyer. ## Les lois que le jeu de pièces respecte **La pureté de l'anneau.** Les cinq couleurs qui n'apparaissent que sur les pièces de bordure sont plus rares qu'il n'y paraît : leurs $5\times24=120$ demi-arêtes saturent exactement les 120 emplacements tournés vers l'anneau des 60 pièces de bordure, sans aucun jeu. Dans toute solution, chaque pièce de bord est forcée de pointer son unique couleur non-cadre vers l'intérieur, et tout le problème de la bordure se réduit à trouver un circuit eulérien dans un multigraphe à 5 sommets et 60 arêtes. Article complet : [la pureté de l'anneau](/fr/research/why/ring-purity/). **Le comptage de l'anneau du cadre.** Cette famille chiffre ce que la loi de l'anneau rapporte. Le raccord des couleurs à lui seul ramène le premier placement de bordure de 59 candidats à environ 21, et un anneau construit légalement au hasard reste vers $10^{-27}$ sur l'échelle des probabilités : 53 ordres de grandeur mieux qu'un ordre uniforme ($10^{-80}$), et toujours astronomiquement loin de la certitude. Le cadre présente aussi une facture fixe à l'intérieur : chaque couleur de cadre ferme exactement 12 joints de l'anneau, et les 56 arêtes tournées vers l'intérieur portent une demande de couleurs, déterminée par le seul jeu de pièces, que toute solution doit reproduire. Un article dédié suivra. **Les invariants de flux.** Donnez à chaque couleur un poids numérique et à chaque pièce le vecteur de ses différences de poids est-ouest et sud-nord ; sommé sur n'importe quelle région, cela se télescope en un flux de bord, et un quart de tour agit sur le vecteur comme la multiplication par $i$. La décomposition selon les quatre caractères du groupe des rotations donne le treillis complet des invariants linéaires intrinsèques aux pièces : un recensement des couleurs, une loi de flux à valeurs dans les entiers de Gauss, de rang plein 22 sur le vrai jeu de pièces, et une parité en damier qui couple la rotation d'une pièce à sa case. La loi de flux sert aussi de certificat incrémental valide qui attrape les erreurs de placement en fin de partie. Un article suivra. **Un jeu de pièces quasi aléatoire.** Chaque statistique d'ordre deux auditée (fréquences des paires de couleurs, matrices d'adjacence, spectre du graphe de transition induit) est indiscernable d'un témoin aléatoire aux mêmes comptes de couleurs ; le seul signal délibéré est l'absence connue de pièces dupliquées par rotation. Côté génération, les preuves soutiennent des comptes de couleurs imposés exactement sur un coloriage par ailleurs uniforme et cohérent avec le raccord, et un théorème boucle la boucle : reconstruire la disposition cachée à partir du sac de pièces est exactement aussi dur que résoudre le casse-tête. Un article suivra. ## Là où l'échelle des scores se ferme **Le plancher de parité : 479 est impossible.** Dans tout placement légal, les apparitions d'une couleur d'un seul côté d'un joint vont par paires. Un unique raccord manqué laisserait deux couleurs impaires, donc aucun plateau ne marque 479 : l'échelle saute de 478 à 480. Le défaut minimal non nul est 2, réalisé en échangeant des pièces quasi jumelles, et autour de toute solution il existe au plus 76 plateaux à un coup de ce défaut : les presque-réussites sont prouvablement rares, et non abondantes. Article complet : [le plancher de parité des défauts](/fr/research/why/parity-defect-floor/). **Le paysage recuit et le mur des 470.** Traitez les plateaux non corrélés à la solution d'origine comme un ensemble aléatoire et comptez-les par score : le compte est astronomique jusqu'à environ 465 à 470 puis s'effondre au-delà. Le plateau communautaire vieux de vingt ans se lit alors comme une frontière de phase, pas comme un échec d'ingénierie. La même analyse évalue l'instance à environ 10 à 20 plateaux parfaits mutuellement quasi orthogonaux, des aiguilles isolées entourées d'une bande de recouvrement vide ; c'est exact sur les petites instances plantées et une conjecture énoncée telle quelle à pleine taille. Le meilleur plateau communautaire est à 470 sur la piste ouverte et 464 sur la piste stricte à cinq indices ; les conventions et le tableau complet vivent sur [la page des records](/fr/research/records/). Article complet : [le mur des 470](/fr/research/why/the-470-wall/). **La loi d'aire entropique.** Le casse-tête a deux règles : les bords doivent se raccorder, et chaque pièce ne sert qu'une fois. Le budget entropique mesuré montre que la première règle est généreuse et que la seconde porte pour l'essentiel toute la difficulté, l'unicité des pièces effondrant le compte des blocs légaux à une échelle mesurable. Cette famille a déjà sa page : [l'entropie et la loi d'aire](/fr/research/why/entropy-area-law/). ## Les machineries qui ne peuvent prouvablement pas le comprimer **La largeur du CSP.** La grille nue de 16 par 16 a une largeur arborescente d'exactement 16, ce qui semble exploitable jusqu'à ce que la contrainte globale de différence sur les 256 cases entre en scène et rende vide tout argument de tractabilité par la largeur. Le tableau de la propagation concorde : la cohérence d'arc ordinaire réduit 48 des 196 domaines intérieurs, la cohérence globale par couplage en réduit 191. La contrainte qui fait mal est celle qu'aucune décomposition ne peut couper. Un article suivra. **Les relaxations convexes.** Le lift SDP standard et une relaxation LP correctement dérivée, construits exactement sur de petites sous-instances plantées aux optima connus, ne certifient que le plafond trivial et manquent des obstructions qu'un comptage élémentaire résout immédiatement. À l'échelle de cette instance, la convexité ne rapporte rien. Un article suivra. **Les certificats algébriques.** Dans le Nullstellensatz à degré borné sur GF(2), tout ce que la propagation par comptage d'un bon solveur fait déjà possède un certificat de degré 2, et rien d'autre n'est bon marché : réfuter un défaut de réutilisation de pièce dans une fenêtre $K\times K$ exige un degré qui croît avec l'aire, donc aucun certificat algébrique global n'existe à l'échelle du plateau. L'alternative par réseaux de tenseurs meurt d'un calcul de rang : le tenseur par case a une dimension de lien effective proche de 289, sans trou spectral contre lequel tronquer. Un article suivra. **Aucune compression sans perte du front.** Un programme dynamique exact sur les fronts de balayage ne comprime que si deux ensembles distincts de pièces utilisées peuvent fusionner sans risque, et un argument à la Myhill-Nerode montre qu'ils ne le peuvent jamais, quel que soit l'ordre de balayage ; mesuré sur la vraie instance, le front exact de la première rangée est multiplié par environ 8,9 à chaque colonne. Les découpes en meet-in-the-middle échouent pour une raison complémentaire : les deux moitiés puisent dans le même stock fini de pièces, donc l'optimum à deux voies est dégénéré et aucune signature d'interface valide n'existe en deçà de l'égalité littérale. Un article suivra. ## Le plancher de complexité **La recherche locale est PLS-complète.** Pour la famille naturelle d'instances de raccord de bords qui contient ce casse-tête, le paysage d'amélioration est PLS-complet (démontré pour une palette généralisée, le raffinement à palette bornée étant énoncé comme conjecture), et décider si un plateau meilleur donné est atteignable par les seuls coups améliorants est PSPACE-complet. Un plateau de plusieurs années est le comportement attendu d'un tel paysage, pas la signature d'un solveur mal réglé. Un article suivra. **La complexité des preuves d'épuisement.** Chaque sous-arbre « aucune complétion n'existe ici » qu'un backtracker referme est une réfutation par résolution arborescente, et son coût est borné inférieurement par la largeur de résolution, gouvernée par la coupe autour de la région ouverte. La contrainte d'unicité des pièces n'apporte aucune difficulté de type pigeonnier que la résolution étendue pourrait attaquer, car le raccord des bords raréfie le graphe de compatibilité pièces-cases jusqu'à une quasi-permutation. La conséquence est nette : l'apprentissage de clauses et de meilleurs encodages rapportent des facteurs polynomiaux, et aucune méthode de la famille résolution n'épuise super-polynomialement plus vite que ce que nous faisons déjà tourner. Un article suivra. ## Ce que la moisson change Le but n'a jamais été de baisser les attentes. Un plateau parfait existe par construction, et rien dans ces treize familles ne touche à ce fait. Ce que la moisson fait, c'est remplacer le folklore par des énoncés chiffrés : le mur a un mécanisme, le plateau de scores a une classe de complexité, et chaque raccourci manquant a une preuve d'impossibilité au lieu d'une vague réputation. Chaque route encore ouverte vient désormais avec la facture qu'elle devra payer, et c'est un bien meilleur point de départ pour la prochaine tentative qu'une carte vierge. ## À lire aussi - [Pureté de l'anneau : le bord est un sous-puzzle clos, sans aucun jeu](https://eternity2.dev/fr/research/why/ring-purity/) — Cinq des 22 couleurs ne touchent jamais les 196 pièces intérieures. La liste des pièces force toute solution valide à dépenser les 120 demi-arêtes de cadre sur l'anneau du bord : un sous-puzzle autonome à jeu exactement nul (120 = 120), un circuit eulérien sur cinq sommets, relié à l'intérieur par seulement 56 arêtes tournées vers le centre. - [Pourquoi 479 est impossible](https://eternity2.dev/fr/research/why/parity-defect-floor/) — Un argument de comptage sur le jeu de pièces officiel interdit un score d'exactement 479/480 : les demi-arêtes de chaque couleur viennent en nombre pair, et un unique raccord cassé laisserait deux comptes impairs. Le plancher sous le parfait est 478, et au plus 76 quasi-solutions à un coup peuvent entourer une solution. - [Le mur des 470 : une frontière de phase, pas une limite d'ingénierie](https://eternity2.dev/fr/research/why/the-470-wall/) — Le plateau communautaire dans les hauts 460 se lit comme une frontière de phase entropique de l'instance, pas comme une limite du génie logiciel : le calcul exact sur le jeu officiel donne une densité de contraintes proche de 0,0094, un paysage recuit qui s'effondre au-delà de 470 et ne franchit 1 qu'à 480, et un nombre attendu de 10 à 20 solutions parfaites quasi orthogonales entre elles. Les nombres côté instance sont exacts ; le tableau du fossé de recouvrement en 16x16 est une conjecture assumée. - [L'entropie et la loi d'aire](https://eternity2.dev/fr/research/why/entropy-area-law/) — Eternity II a deux règles : les bords doivent coïncider, et chaque pièce ne sert qu'une fois. La première est généreuse. Toute la difficulté tient dans la seconde. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Cette instance est-elle NP-complète, et comment l'encoder ?](https://eternity2.dev/fr/research/why/how-hard-is-this-instance/) — L'appariement de bords est NP-complet en tant que famille, mais cela ne dit rien d'un plateau 16×16 fixé : une instance isolée est une constante, pas un problème. Ce qui est vrai, c'est la dureté au pire cas de la famille et la dureté empirique de cette instance, et comment écrire le puzzle pour un solveur SAT, de couverture exacte ou de PLNE, avec de petits croquis détaillés. Une mesure sur plateaux plantés chiffre le choix de la formulation : une falaise de résolubilité qu'un paradigme de recherche heurte et qu'un autre franchit, et qui bouge avec le nombre de couleurs. - [Records et solveurs](https://eternity2.dev/fr/research/records/) — Eternity II n'a jamais été résolu, mais près de deux décennies d'efforts collectifs ont porté le meilleur plateau à 470/480. Qui détient quoi, comment ils y sont parvenus, et pourquoi certains plateaux « 480 » annoncés ne correspondent pas au vrai casse-tête. --- # Quel mur arrête quelle méthode > La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/walls-and-methods/ - Mise à jour: 2026-07-21 - Sujets: structure - Source: Ansótegui, Béjar, Fernández & Mateu, How Hard is a Commercial Puzzle: the Eternity II Challenge — https://repositori.udl.cat/server/api/core/bitstreams/0b6533fe-54e5-4070-85fe-80f7d35837d8/content --- C'est l'outil pour choisir son créneau. Si vous voulez décider où investir vos efforts, lisez les colonnes de haut en bas : choisissez le mur qui vous intéresse le plus, et le tableau vous remet chaque méthode qui l'a attaqué et le score exact où elle s'est arrêtée. Pour un panorama plus large par famille de méthodes, voyez la [carte de toutes les approches connues](/fr/research/build/approaches-map/) ; pour les angles encore ouverts, le tableau des [problèmes ouverts](/fr/research/open-problems/) ; et pour les approches qui, de manière prouvée, ne font pas bouger le score, les [impasses](/fr/research/build/dead-ends/). Chaque case de la carte ci-dessous repose sur les travaux publiés de ce projet. Les quatre murs eux-mêmes sont corroborés par la littérature publiée ; les résultats d'expériences sont le travail propre de ce projet, chacun documenté sur sa propre page ; ils ne sont pas présentés comme vérifiés de l'extérieur. ## Sur quoi repose chaque mur Tous les murs ne sont pas de même nature de preuve. Certains sont des calculs exacts et déterministes versés dans ce dépôt ; l'un est répliqué de l'extérieur par plusieurs méthodes indépendantes ; plusieurs sont des mesures réelles prises sur l'unique planche Eternity II et son jeu de records. C'est une base légitime, mais le lecteur mérite de savoir laquelle est laquelle avant de s'appuyer sur une ligne. Le tableau ci-dessous ramène chaque affirmation structurelle de cette section à la forme la plus forte que ses preuves soutiennent réellement, au niveau de cette preuve, à la présence d'une réplication externe, et à la seule réserve à garder en tête. > **Les quatre niveaux** > > - **Prouvé, externe.** Un théorème ou un calcul exact qu'un tiers a énoncé ou répliqué, et la page cite ce tiers. - **Prouvé, interne.** Un calcul exact et déterministe réalisé ici, code et résultat versés sous `research/topics/` et reproductibles depuis la commande de la page. - **Mesuré, instance unique.** Une mesure réelle, prise sur l'unique planche Eternity II (ou une planche de type E2), sans réplication. Vraie, et non un défaut en soi, mais c'est un seul point de donnée. - **Conjecture.** La page elle-même présente l'affirmation comme non prouvée en général. Un mur n'est pas déclassé pour avoir été mesuré sur une instance unique. Il ne l'est que là où un niveau inférieur est présenté comme supérieur, et aucun ici ne l'est. | Mur / affirmation | Forme la plus forte soutenue | Niveau | Réplication externe | La seule réserve | | --- | --- | --- | --- | --- | | [Pic de difficulté](/fr/research/why/phase-transition/) | 17,14 couleurs intérieures découlent du critère d'une solution attendue ; 17 est proche du pic de difficulté de recherche pour l'assemblage de bords encadré | Prouvé, externe | Oui : la dérivation de Owen en 1947 ; Ansótegui, Béjar, Fernández & Mateu confirment le pic | « Une solution attendue » est une moyenne au premier moment supposant des couleurs de bord indépendantes ; elle situe le pic, elle ne compte pas les solutions | | [Théorie complexe / l'entonnoir](/fr/research/why/complex-theory/) | Un estimateur au premier moment de la largeur d'arbre et du nombre de solutions, juste à un facteur deux près partout où on a pu le vérifier | Conjecture (badge de la page), sur réplication externe | Oui : le modèle de Owen ; le portage C de McGavin et sa résolution 10×10, dans la prédiction | C'est une moyenne, aveugle au caractère réellement distinct des partiels comptés ; un outil pour classer les ordres de balayage, jamais un compte exact ni une borne | | [Aucun coup forcé](/fr/research/why/no-forced-moves/) | Un décompte exhaustif exact sur le jeu intérieur officiel : aucune pièce intérieure n'est jamais forcée à un seul partenaire droit (73 à 137 partenaires chacune) | Prouvé, interne | Aucune réplication externe ; le décompte est propre au projet, versé et reproductible | Il compte la compatibilité par paires sur le jeu complet, pas les candidats dans une planche partielle vivante ; une propriété des pièces, pas une preuve que la recherche ne se resserre jamais | | [Motifs interdits](/fr/research/why/forbidden-patterns/) | Décomptes exhaustifs exacts : 38,96 % des paires, 83,26 % des L-triominos, 99,72 % des carrés 2×2 sont infaisables sur des pièces intérieures distinctes | Prouvé, interne | Les décomptes 2×2 sont le résultat exact versé du projet ; les 20 paires-coins vides sont une observation communautaire citée de 2008 | La lecture « le décompte de patchs interdits suit la distance à une solution » est un signal heuristique, pas une distance monotone prouvée | | [Loi d'aire de l'entropie](/fr/research/why/entropy-area-law/) | Les décomptes de blocs A(n)/B(n) sont désormais exacts en dépôt jusqu'à n=3 (B(2)=4 059 952 recoupe la table de sous-grilles), donnant un exposant en dépôt α≈0,044 ; la limite d'entropie près de 0,67 et le point d'effondrement sont des extrapolations | Prouvé, interne (les décomptes de blocs) + mesuré (l'ajustement) | Partiel : le lemme de Fekete et l'entropie de Shannon sont les théorèmes externes qui rendent la limite bien définie ; l'ajustement de α et l'échelle d'effondrement sont propres au projet | Le théorème garantit qu'une limite positive existe ; il n'en fixe pas la valeur. L'exposant est ajusté sur n≤3 et sa valeur par bloc croît encore, donc le point d'effondrement des grands patchs est une extrapolation au-delà des largeurs comptées | | [Rigidité](/fr/research/why/rigidity-wall/) | Sur les planches records publiques, aucun réarrangement des pièces propres d'une planche dans un halo jusqu'à quatre cases ne clôt un décalage (SAT : UNSAT), désormais versé | Prouvé, interne pour le halo SAT ; la table MIP plus profonde est prouvée pour les régions closes mais portée depuis un article hors site | Oui, le mur le mieux répliqué : les tests de gel et de résidu SAT de Millilaw reproduits ici avec un contrôle positif ; le noyau gelé du recuit GPU de benj39100 l'atteint par une troisième méthode | La preuve versée du site est le halo SAT au rayon 4 sur cinq planches (quelques instances au rayon 4 dépassent le temps, notées ouvertes). La table MIP et la borne planche entière ≤476 proviennent de l'article hors site, et l'énoncé « toutes planches » est une conjecture | | [Sigma-cycles](/fr/research/why/sigma-cycles/) | Sur **chaque** paire ordonnée de même jeu de pièces des planches embarquées (246 paires, 1 154 grandes boucles), **chaque** préfixe propre de chaque grande boucle score strictement moins que son départ, sur les 54 238 applications partielles | Prouvé, interne (un énoncé de population sur le jeu embarqué) | Aucune réplication externe ; calculé ici contre le 469 de McGavin et les planches records et de projet embarquées | Le décompte est exact sur les planches livrées ; la propriété « tout sous-cycle est pire » n'est toujours pas prouvée pour toute planche possible. Une forte observation de population, pas un théorème général | | [Géométrie des décalages](/fr/research/why/mismatch-geometry/) | Sur les planches records et de projet, les décalages résiduels se groupent dans une bande de rangées qui bascule avec le sens de construction ; un objectif de comptage de trous y dépose les restes | Mesuré, instance unique | Partiel : le basculement selon le sens est la lecture du projet ; la planche à sept trous de Verhaard et le résidu en bande haute de Zamofing sont cités comme observations de même sens, désormais vérifiables dans l'archive étendue | Un motif sur une poignée de planches avec une histoire mécaniste, pas une preuve | | [Vol de pièce](/fr/research/why/piece-theft/) | Un décompte exact des demandes (nord, ouest) sur le jeu intérieur : la plupart ont un à trois fournisseurs, et un nombre précis en a exactement un | Prouvé, interne (les décomptes) ; mesuré (le mécanisme « où meurent les solveurs ») | Aucune réplication externe ; Régin 1994 est cité comme la théorie all-different qui nomme le mécanisme | Les décomptes de fournisseurs rares sont exacts ; « c'est là que meurent les vrais solveurs » est un mécanisme illustré sur l'instance, pas un taux d'échec mesuré sur les solveurs | | [Géométrie des indices](/fr/research/why/hint-geometry/) | Sur un puzzle 16×16 de type E2, des indices dispersés le résolvent en minutes là où des rangées contiguës empilées échouent, car le travail vit dans la seconde moitié du remplissage | Mesuré, instance unique (une planche de type E2, pas le puzzle officiel) | Oui, proprement attribué : la résolution à 18 indices de McGavin et son arbre de 41 milliards de nœuds ; les statistiques de profondeur de Joe | Pas le puzzle officiel, dont les cinq indices fixes diffèrent. Les chiffres de profondeur sont l'échantillon d'un seul backtracker | | [Équilibre du bord / NS-1](/fr/research/why/border-balance/) | Une condition nécessaire exacte ; les quatre solutions complètes connues la vérifient ; un déficit positif certifie l'infaisabilité. La part intérieur-intérieur des erreurs restantes est désormais exacte : **86,9 %** sur les neuf planches embarquées de classe 469, aucune bord-bord | Prouvé, externe (la condition), prouvé, interne (la répartition des erreurs) | Oui pour la condition, citée aux énoncés communautaires 2007–2022 ; la répartition des erreurs est le recompte versé du projet | La condition est nécessaire, jamais suffisante : un déficit nul ne prouve rien, et l'invariant est aveugle à la majorité intérieur-intérieur des erreurs restantes. Le rendement d'élagage est une mesure sur instance unique, pas encore un banc versé | | [Géographie des couleurs rares](/fr/research/why/rare-color-geography/) | Un décompte exact sur le jeu officiel : les cinq couleurs de bord n'apparaissent jamais sur un bord intérieur | Prouvé, interne | Aucune réplication externe du décompte ; l'intention de conception 17+5 est citée à Owen | Correctement présenté comme structurel (bordure grise, pools de couleurs séparés), pas une ruse de rareté ; l'étiquette « rare » est un artefact du moindre nombre de bords de bordure | | [Recette de conception](/fr/research/why/design-recipe/) | La communauté a reconstruit une recette cohérente de puzzle le plus dur, ingrédient par ingrédient, chacun sourcé à un message de l'année de lancement | Conjecture (badge de la page), chaque ingrédient sourcé de l'extérieur | Oui, densément : les dérivations et mesures de Owen, le recensement de l'espace de conception, la chaîne de provenance jusqu'à Selby et Riordan | Une reconstruction de l'intention de conception, pas un énoncé que les concepteurs ont publié ; la page la badge conjecturée | | [Cadre de complexité](/fr/research/why/how-hard-is-this-instance/) | L'assemblage de bords est NP-complet comme famille ; une planche fixe unique est une constante, pas un problème ; la difficulté d'E2 est empirique sur un espace ~10^557 | Prouvé, externe | Oui : Demaine & Demaine 2007 pour la NP-complétude ; Ansótegui et al. pour le cas empirique | La distinction de catégorie porte le raisonnement : la NP-complétude plafonne ce que les solveurs généraux peuvent promettre, elle ne dit rien de cette planche | | [Élagage contre vitesse](/fr/research/why/prune-vs-speed/) | L'argument de composition est de l'arithmétique exacte ; sur E2, un élagage légal coûte souvent plus que le sous-arbre qu'il retire | Prouvé (l'arithmétique), mesuré (le verdict « l'élagage ne paie pas ») | Partiel : le principe est autonome ; le verdict communautaire est cité à McGavin et 95A31, désormais vérifiables dans l'archive étendue | Les chiffres de l'arbre de démonstration sont illustratifs, pas une mesure d'un vrai solveur, et la page le dit | Trois évolutions depuis le premier tracé de cette carte méritent d'être soulignées, car elles font monter des affirmations d'un niveau. Les sigma-cycles étaient une observation sur trois paires ; c'est désormais un énoncé exact sur chaque paire de même jeu de pièces des planches embarquées, 54 238 applications partielles sans une exception. La répartition des erreurs de bord est désormais un recompte exact (86,9 % intérieur-intérieur) plutôt qu'un chiffre hors site. Et les décomptes de blocs de la loi d'aire sont désormais calculés en dépôt et se reproduisent depuis la commande de la page, l'exposant étant ajusté sur la plage comptée exactement. Enfin, les quatre citations communautaires qui se situaient au-delà de l'instantané d'archive valident désormais l'export étendu, si bien que les passages de corroboration de la rigidité, de la géométrie des décalages et de l'élagage contre vitesse reposent sur des sources qu'un lecteur peut vérifier. La lecture d'ensemble : seule la rigidité porte trois méthodes indépendantes (SAT, MIP, recuit) aboutissant à un même verdict. Les autres murs sont des calculs exacts propres au projet ou des mesures sur instance unique, sur l'unique planche qui compte. Lisez « corroboré par la littérature » comme signifiant que la transition de phase et le gradient manquant ont été reproduits ailleurs, pas chaque mur. ## Les quatre murs, en une ligne chacun Chacun d'eux est une version d'un même énoncé : il n'y a rien de local à élaguer. - **[Aucun coup forcé](/fr/research/why/no-forced-moves/)**. Chaque case intérieure conserve 73 à 137 pièces légales, si bien que le facteur de branchement ne s'effondre jamais. - **[Le pic de difficulté](/fr/research/why/phase-transition/)**. Avec ≈17 couleurs intérieures, le puzzle se situe à la transition de phase : environ une solution attendue, le pire endroit où chercher. - **[La loi d'aire](/fr/research/why/entropy-area-law/)**. Les plateaux partiels réellement distincts s'effondrent à mesure que l'aire remplie grandit, mais aucun score local ne peut percevoir ce fait global. - **[La rigidité](/fr/research/why/rigidity-wall/)**. Les records sont localement figés ; le pas vers un meilleur plateau est un unique échange géant et indivisible, sans gradient à suivre. ## La carte Les colonnes sont les murs ; les lignes, les méthodes, meilleur score en tête. Une marque pleine (●) signifie que la méthode travaille fondamentalement contre ce mur. Le plafond communautaire sur ce puzzle est 470 ; la solution complète est 480. | Méthode | Meilleur | [Coups forcés](/fr/research/why/no-forced-moves/) | [Pic de difficulté](/fr/research/why/phase-transition/) | [Loi d'aire](/fr/research/why/entropy-area-law/) | [Rigidité](/fr/research/why/rigidity-wall/) | Nouveau bassin | | --- | --- | :-: | :-: | :-: | :-: | --- | | [PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/) · depuis le corpus | 463/480 | | | | ● | non | | [PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/) · from scratch | 460/480 | | ● | | ● | non | | [KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/) · from scratch | 460/480 | | | | ● | nouvelle famille | | [REPLAY](/fr/research/lab/experiments/raphael-anjou/learning/replay/) · décoder et rejouer | 460/480 | | | | ● | non | | [GAUNTLET](/fr/research/lab/experiments/raphael-anjou/pipelines/gauntlet/) · from scratch | 458/480 | | | | ● | nouvelle famille | | [CLOISTER](/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/) · ancrer et contraindre | 453/480 | | | ● | ● | non | | [MIDDEN](/fr/research/lab/experiments/raphael-anjou/pipelines/midden/) · ancrer et contraindre | 452/480 | | | ● | ● | non | | [LADDER](/fr/research/lab/experiments/raphael-anjou/pipelines/ladder/) · concentrer l'effort | 451/480 | ● | ● | | | nouvelle famille | | [LODESTONE](/fr/research/lab/experiments/raphael-anjou/learning/lodestone/) · from scratch | 451/480 | ● | | | | non | | [MOSAIC](/fr/research/lab/experiments/raphael-anjou/pipelines/mosaic/) · résoudre un fragment exactement | 448/480 | ● | ● | | | non | | [BANDSAW](/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/) · résoudre un fragment exactement | 437/480 | ● | ● | | | non | | [STAGED](/fr/research/lab/experiments/raphael-anjou/pipelines/staged/) · from scratch | 436/480 | ● | | ● | | non | ### Comment la lire Presque toutes les méthodes finissent contre la rigidité, le mur qui dit que les grands plateaux sont des îlots isolés. Les méthodes construites from scratch ou à partir du corpus (PRIOR, KEYRING, PALIMPSEST, GAUNTLET) tentent d'atteindre un nouvel îlot en pilotant la construction par un signal appris ; elles plafonnent à 458–463 et deux d'entre elles atteignent bien des familles réellement nouvelles, mais aucune ne passe jusqu'au plafond. Les méthodes de concentration et exactes (LADDER, BANDSAW) attaquent plutôt la recherche elle-même (le facteur de branchement élevé et le pic infouillable) et le paient en fin de partie. Les méthodes d'ancrage (CLOISTER, MIDDEN) localisent les dégâts mais butent sur le mur de la loi d'aire à l'intérieur. Aucun mur pris isolément ne raconte toute l'histoire, et aucune méthode ne franchit les quatre. ## Où chacune a calé, et pourquoi Le plafond n'est jamais arbitraire. Pour chaque méthode, son propre compte rendu consigne la raison exacte pour laquelle le score a cessé de grimper, citée ici en une ligne. - **[PALIMPSEST](/fr/research/lab/experiments/raphael-anjou/learning/palimpsest/)** (463/480). A atteint 463, le meilleur du projet, en lisant le corpus pour repérer quels choix partagés sont des pièges et en pilotant un balayage de 15 bassins pour les contourner. Forcer directement la recherche à éviter les pièges dégradait les plateaux : la valeur résidait dans le lieu où chercher, pas dans une règle stricte. - **[PRIOR](/fr/research/lab/experiments/raphael-anjou/learning/prior/)** (460/480). Plafonne à 460 : le prior de position appris amène rapidement une construction from scratch dans la classe des 460, mais le signal du corpus ne suffit pas à elle seule pour en sortir. - **[KEYRING](/fr/research/lab/experiments/raphael-anjou/learning/keyring/)** (460/480). Trois signaux appris votant ensemble (position, adjacence, patch 2×2) ont atteint 460 dans un agencement de coins qu'aucun plateau n'avait percé auparavant, une nouvelle famille, mais le signal de patch est marginal et le polissage plafonne toujours à 460. - **[REPLAY](/fr/research/lab/experiments/raphael-anjou/learning/replay/)** (460/480). Rejoue exactement les plateaux stricts-460 de la communauté et révèle le coup que la recherche ordinaire manque : 4 à 5 cases qui encaissent deux inadéquations d'un coup, inatteignables pour une recherche qui n'en autorise qu'une au plus. - **[GAUNTLET](/fr/research/lab/experiments/raphael-anjou/pipelines/gauntlet/)** (458/480). Lancer le beam dans neuf directions de balayage a ouvert une toute nouvelle famille à 458 (l'ordre de balayage est un axe de diversité plus fort que la graine aléatoire), mais une seconde passe a plafonné à 457 sans aucun 461 : la nouvelle famille sature comme les autres. - **[CLOISTER](/fr/research/lab/experiments/raphael-anjou/pipelines/cloister/)** (453/480). En tant que solveur intérieur autonome, il confirme un réel bonus de compatibilité avec le pourtour, mais ce bonus ne peut pas se greffer après coup (la même rigidité que le plateau complet), si bien qu'il se fixe dans le bas des 450. - **[MIDDEN](/fr/research/lab/experiments/raphael-anjou/pipelines/midden/)** (452/480). Choisir où (et non quand) le plateau peut se rompre allonge la série parfaite de 153 à 167–174 cases, mais la géométrie dispersée échoue toujours en fin de partie : rien n'absorbe les derniers dégâts. - **[LADDER](/fr/research/lab/experiments/raphael-anjou/pipelines/ladder/)** (451/480). Inonde de sondes bon marché et promeut la plus profonde, atteignant un plateau strict-451 sans record à copier, la première évasion hors de la bande universelle 444–450, mais le stock d'ouvertures parfaites s'épuise et les échelons convergent tous vers un même plafond. - **[LODESTONE](/fr/research/lab/experiments/raphael-anjou/learning/lodestone/)** (451/480). Un prior de demande-rare utilisé uniquement comme départage relève la médiane from scratch de deux points (449→451) et resserre la variance, mais tout poids plus élevé l'effondre : la rareté est un signal réel mais faible, et il ne touche jamais au plafond du bassin. - **[MOSAIC](/fr/research/lab/experiments/raphael-anjou/pipelines/mosaic/)** (448/480). Compose des solutions exactes de blocs 4×4 avec des coutures souples, atteignant 448 from scratch, mais le déficit se concentre presque entièrement dans les trois derniers blocs de coin, où le vivier de pièces s'amenuise : le même vol de pièces, désormais réduit à un seul point vif. - **[BANDSAW](/fr/research/lab/experiments/raphael-anjou/meet-in-the-middle/bandsaw/)** (437/480). Résout une bande de fin de partie jusqu'à l'optimalité prouvée, et ce faisant mesure le mur de l'exactitude : l'arbre de recherche croît d'environ un facteur vingt par inadéquation supplémentaire autorisée, des deux côtés, si bien que se rejoindre au milieu cesse d'être rentable à pleine taille. - **[STAGED](/fr/research/lab/experiments/raphael-anjou/pipelines/staged/)** (436/480). Construit le plateau entier sans cadre préétabli et avec une bordure émergente, atteignant 436, bien en deçà des records. C'est cet écart qui constitue le résultat : il mesure exactement ce que vaut l'ancrage cadre-d'abord habituel. ## La forme de l'écart Parcourez la table de haut en bas et la leçon de tout le projet saute aux yeux : les méthodes qui font bouger le score changent la forme de la recherche - un ordre de balayage, un prior appris, une région confinée -, jamais sa vitesse brute. Et chacune d'elles cale contre un mur qui est global, pas local. Les dix arêtes de 470 à 480 ne relèvent pas d'un problème de finition ; elles se trouvent de l'autre côté des quatre murs à la fois. Une campagne distincte menée en 2026 par William Millilaw a abouti à la même conclusion par le versant de la diversité. En balayant toute la liste des méthodes, il a constaté que presque tout (recherche locale adaptative from scratch, placement en serpentin, le sommet de la distribution d'un générateur entraîné) redécouvre sans cesse la même poignée de bassins, et que seul le parallel tempering produisait de façon fiable des bassins réellement nouveaux, des plateaux très éloignés de l'ensemble connu. Même celui-là plafonne vite. Sa lecture est celle que cette table ne cesse de formuler : le goulot d'étranglement n'est pas le score qu'une méthode atteint mais le nombre de bassins distincts qu'elle sait trouver, et aucune méthode de l'arsenal standard n'en trouve assez. > **Note** > > Chaque ligne de saturation est distillée du carnet de laboratoire du projet (une entrée par expérience). Les quatre murs sont corroborés par la littérature publiée : la transition de phase à 17 couleurs par Ansótegui, Béjar, Fernández & Mateu, « How Hard is a Commercial Puzzle: the Eternity II Challenge » ; le gradient manquant et les bassins profonds par la littérature de recherche locale sur Eternity II. ## À lire aussi - [Pourquoi un ordinateur plus rapide ne change rien](https://eternity2.dev/fr/research/why/prune-vs-speed/) — L'idée la plus importante de la recherche combinatoire difficile : réduire l'espace que l'on explore l'emporte, d'une marge exponentielle, sur le fait de l'explorer plus vite. Eternity II est conçu pour qu'on ne puisse presque pas le réduire. - [Le mur de rigidité](https://eternity2.dev/fr/research/why/rigidity-wall/) — Chaque plateau record dont nous disposons est figé sur place. Impossible de progresser par petites retouches d'un excellent plateau vers un plateau parfait, et nous pouvons le démontrer. - [Expériences](https://eternity2.dev/fr/research/lab/experiments/) — Les expériences de recherche nommées du laboratoire, une section par chercheur. Chacune est un run réel contre Eternity II avec son idée, son meilleur plateau et les questions qu'elle a laissées ouvertes. Le carnet de Raphaël Anjou est ici en entier ; le carnet reste ouvert à tous les autres. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [Une carte de toutes les approches connues](https://eternity2.dev/fr/research/build/approaches-map/) — La synthèse que la communauté réclame sans jamais la trouver : chaque famille d'attaque tentée sur Eternity II, ce que chacune a réellement atteint, où elle bute, et un lien vers la page de fond. Une même idée directrice les traverse toutes. - [Impasses](https://eternity2.dev/fr/research/build/dead-ends/) — Des approches que nous avons essayées, séduisantes en apparence, mais qui ne font pas bouger les lignes sur Eternity II, consignées avec nos constats pour que vous investissiez votre temps ailleurs. - [Problèmes ouverts](https://eternity2.dev/fr/research/open-problems/) — La frontière ouverte d'Eternity II réunie au même endroit : chaque angle qui vaut encore une tentative, le mur qu'il attaque, ce qui a déjà été essayé et où cela s'est arrêté, et s'il s'agit d'une cible abordable pour un débutant ou d'un objectif difficile et bien cartographié. --- # Un jeu de pièces extrême sur chaque axe mesuré > Mesurez les 256 pièces officielles sans aucun solveur en vue et chaque porte structurelle est fermée : aucune pièce symétrique par rotation, 5 paires jumelles sur 32 640 appariements, un plafond de 307 sur 480 si rien ne tourne, des budgets de couleurs qui s'apparient à exactement 480 sans aucun jeu, et une palette 17+5 posée au point d'une-solution-attendue. - Page canonique (avec figures et démos interactives): https://eternity2.dev/fr/research/why/why-e2-is-hard/ - Mise à jour: 2026-07-22 - Sujets: structure - Reproduire: `cd research/topics/adversarial-piece-set/compute && cargo run --release > ../results/invariants.json` - Source: Le jeu de pièces adverse : article, code source et résultats (GitHub) — https://github.com/raphael-anjou/eternity2/tree/main/research/topics/adversarial-piece-set - Source: Brendan Owen, Design the hardest puzzle : la recette et la dérivation du 17,14 (msg 1947, août 2007) — https://groups.io/g/eternity2/message/1947 - Source: Le recensement de l'espace des pièces possibles : les formes symétriques existent dans cet espace et le jeu réel les évite toutes (msg 8025, septembre 2010) — https://groups.io/g/eternity2/message/8025 - Source: Les pages Eternity de Selby et Riordan, le site des concepteurs eux-mêmes — https://www.archduke.org/eternity/ --- Posez les solveurs et mesurez l'objet lui-même. Le jeu officiel compte 256 pièces carrées, quatre bords colorés chacune. Si ces pièces avaient été tirées sans soin, un peu de mou structurel survivrait quelque part : une pièce répétée, une pièce symétrique, une couleur en surplus, un biais d'orientation qui ne coûte rien, une clique de pièces qui se préfèrent entre elles. C'est de ce mou-là que les solveurs se nourrissent. Cette page vérifie chacune de ces portes directement sur le jeu de pièces seul, et chacune est fermée, exactement, pas approximativement. Cinq des six mesures ci-dessous sont versionnées comme un seul sujet reproductible. Chacune se recalcule depuis l'instance publiée en moins d'une seconde, et le binaire vérifie lui-même ses valeurs attendues : reproduire les nombres et les contrôler sont un seul et même geste. ## Les cinq mesures versionnées | Axe | Mesure | L'extrême où il se trouve | | --- | --- | --- | | Symétrie de rotation | 256 pièces sur 256 ont leurs quatre rotations distinctes | 1 024 pièces-rotations, rien à quotienter | | Jumelles | 251 multiensembles de couleurs distincts ; 5 paires jumelles et 114 quasi-jumelles sur 32 640 appariements | aucun doublon, coïncidence au niveau de 0,4 % | | Plafond à orientation fixe | au plus 307 joints sur 480 peuvent s'apparier si aucune pièce ne tourne | la rotation est structurellement nécessaire | | Budget de couleurs | les 22 couleurs ont toutes un nombre pair de côtés ; la capacité d'appariement somme à 480 | exactement suffisant, aucun jeu | | Palette scindée | 17 couleurs intérieures, 5 couleurs de joints de bordure | 17 est le réglage d'une-solution-attendue | ### Aucune symétrie de rotation nulle part Une pièce identique à elle-même après un quart ou un demi-tour réduirait les orientations et rétrécirait l'espace de décision, et la réduction standard, chercher une forme canonique par orbite, empocherait la remise. Mesuré : chacune des 256 pièces a une orbite de rotation complète de taille 4, le puzzle possède donc réellement 1 024 pièces-rotations distinctes et la recherche par formes canoniques ne gagne strictement rien. Le recensement communautaire de l'espace de conception montre que c'est un choix, pas un accident : avec cette palette, l'espace des pièces possibles contient des formes qui se répètent sous rotation, et le jeu réel les évite toutes ([msg 8025](https://groups.io/g/eternity2/message/8025)). La [recette de conception](/fr/research/why/design-recipe/) porte le versant intentionnel de cette histoire, y compris la mesure de Brendan Owen montrant que des pièces symétriques se placeraient assez inégalement pour rendre au solveur le signal d'ordonnancement par difficulté que les concepteurs retiraient. ### Cinq jumelles sur 32 640 appariements Oubliez l'ordre des bords et demandez quelles pièces portent le même budget de quatre couleurs. Les 256 pièces produisent 251 multiensembles distincts : exactement 5 paires coïncident, les pièces (2,3), (5,14), (7,51), (109,110) et (171,181) dans la numérotation de recherche, et dans chaque paire les couleurs partagées occupent un ordre cyclique différent, si bien qu'aucune pièce ne se répète, même à rotation près. En relâchant la question vers les quasi-jumelles, les paires partageant 3 de leurs 4 bords à même position dans l'orientation stockée, on ajoute 114 paires en 79 groupes. Rapportée aux 32 640 paires non ordonnées que le jeu offre, même cette coïncidence relâchée reste une fraction de pour cent. La porte ainsi fermée est le doublement gratuit : une vraie paire de doublons permettrait de réécrire toute solution en échangeant les deux pièces, et il n'y en a aucune. ### La rotation est structurellement nécessaire Figez chaque pièce dans son orientation publiée et demandez combien des 480 joints pourraient s'apparier. Couleur par couleur, les joints horizontaux utilisent au plus la plus petite des offres tournées vers l'est et vers l'ouest, et les joints verticaux la plus petite des offres nord et sud. La somme plafonne à **307 sur 480**. C'est une borne de comptage, pas un résultat de recherche : aucun arrangement de pièces non tournées, où que ce soit sur le plateau, ne peut la dépasser. Un pipeline qui fixe les orientations tôt concède donc au moins 173 joints avant même de chercher, et 307 se situe très en dessous de tous les hauts plateaux de la [page des records](/fr/research/records/). Les deux nombres comptent ici les bords appariés entre pièces adjacentes, pourtour extérieur exclu, la convention en usage sur tout ce site. ### Un budget de couleurs sans aucun jeu Comptez les côtés de pièces par couleur. Chacune des 22 couleurs non grises a un total pair, et les capacités d'appariement, la moitié du nombre de côtés par couleur, somment à exactement 480, le nombre géométrique de joints du plateau. L'offre est exactement suffisante pour un plateau parfait : aucune couleur ne manque, ce qui certifierait l'impossibilité de la solution construite, et aucune couleur n'est en excès, ce qui laisserait du jeu à dépenser aux plateaux partiels. Aucun jeu signifie aussi aucun levier. Aucun argument de comptage sur la seule offre de couleurs ne peut élaguer quoi que ce soit, la difficulté loge donc entièrement dans quelles pièces portent quelles couleurs, pas dans la quantité de chaque couleur. Ce que le raisonnement d'offre produit de plus aiguisé est l'invariant d'[équilibre de bordure](/fr/research/why/border-balance/), et cette condition est nécessaire, jamais suffisante. ### La palette scindée, et ce qui a été réglé Les 22 couleurs se divisent en 17 couleurs intérieures et 5 qui n'apparaissent que sur les joints entre pièces de bordure. La séparation elle-même est automatique : avec un pourtour gris massif, les bords colorés d'une pièce de bordure ne rencontrent jamais que d'autres bords de bordure ou l'intérieur, les deux réservoirs ne se mélangent donc jamais, comme l'explique la page de [géographie des couleurs rares](/fr/research/why/rare-color-geography/). Ce qui a été choisi, ce sont les comptes. La dérivation d'Owen l'année du lancement retrouve 17,14 couleurs intérieures à partir de l'exigence d'environ une solution attendue ([msg 1947](https://groups.io/g/eternity2/message/1947)), le plus rare qu'une solution puisse être tout en existant encore, et la page du [pic de difficulté](/fr/research/why/phase-transition/) mesure que c'est le pire endroit possible pour une recherche. La recette reconstruite complète, ingrédient par ingrédient, se trouve sur la page de la [recette de conception](/fr/research/why/design-recipe/). ## Le sixième axe, décrit sans ses chiffres Une mesure de plus appartient à la thèse mais ne fait pas encore partie du sujet versionné. Construisez le graphe dont les nœuds sont les 256 pièces, pondéré par le nombre d'adjacences par rotation que chaque paire supporte, et lisez son spectre. Le graphe se sépare proprement en exactement deux blocs, les 60 pièces de cadre et les 196 pièces intérieures, et au-delà de cette coupure il ne montre aucune structure de communauté à aucune échelle : pas de cliques de pièces mutuellement compatibles, pas de sous-puzzle bon marché à découper et résoudre d'abord. Le regroupement est à échelle unique, et la seule frontière de grappe visible est la ligne cadre-intérieur que tout solveur connaît déjà. Les chiffres spectraux derrière cette description sont différés jusqu'à ce que leur calcul soit versionné aux côtés des cinq autres ; lisez donc cet axe comme une description pour l'instant, et les cinq précédents comme exacts. ## Ce que ces extrêmes interdisent Chaque axe ferme une porte standard. - **Réduction par symétrie.** Rien à quotienter : les 1 024 pièces-rotations sont toutes distinctes. - **Astuces de doublons.** Aucun doublement gratuit des solutions : 5 quasi-coïncidences sur 32 640 appariements, aucune n'étant un vrai doublon. - **Raccourcis d'orientation.** Fixer les rotations tôt concède 173 joints sur 480 par un argument de comptage, avant toute recherche. - **Arguments d'offre.** Des budgets pairs et exactement suffisants : compter les couleurs n'élague rien. - **Sous-communautés bon marché.** Rien de plus tendre que la coupure cadre-intérieur pour commencer. Cette page est le pendant métrologique de deux voisines. La [recette de conception](/fr/research/why/design-recipe/) reconstruit, depuis les archives de l'année du lancement, pourquoi le jeu a été bâti ainsi ; le [balayage de théorèmes](/fr/research/why/theorem-sweep/) rassemble les lois prouvées sur le même objet. Et les extrêmes d'ici sont le rez-de-chaussée des murs de la section : [aucun coup forcé](/fr/research/why/no-forced-moves/) est la même platitude ressentie cellule par cellule pendant une construction, et les [cycles sigma](/fr/research/why/sigma-cycles/) sont ce que l'absence de petits échanges devient entre hauts plateaux finis. Pour savoir quelle méthode meurt contre quel mur, la [carte murs et méthodes](/fr/research/why/walls-and-methods/) sert d'index. ## Reproduction et conventions Le répertoire du sujet contient un binaire Rust autonome qui charge l'instance officielle embarquée (256 pièces, sans indices) et recalcule chaque nombre ci-dessus : le recensement des orbites de rotation, les comptes de jumelles et quasi-jumelles, le plafond d'appariement à orientation fixe, et la parité et capacité d'appariement par couleur. L'exécution est déterministe, s'achève en bien moins d'une seconde, imprime un unique document JSON, et sort avec un code non nul si une valeur attendue échoue ; le fichier de résultats versionné est identique octet pour octet d'une exécution à l'autre. Les identifiants de pièces de la liste des jumelles suivent la numérotation de recherche du jeu. Les deux nombres de type score de cette page, 307 et 480, comptent les bords appariés entre pièces adjacentes pourtour extérieur exclu, la même convention que la page des [records](/fr/research/records/) ; rien ici ne note un plateau candidat, et rien sur cette page n'est une revendication de record. ## À lire aussi - [Conçu pour être insoluble : la recette](https://eternity2.dev/fr/research/why/design-recipe/) — Eternity II applique une recette pour obtenir le casse-tête à raccords de bords le plus difficile possible : forme compacte, aucune pièce symétrique ni dupliquée, palettes cloisonnées, fréquences plates, une seule solution attendue. La communauté a rétro-conçu chaque ingrédient dès l'année du lancement. - [La moisson de théorèmes : treize lois de structure](https://eternity2.dev/fr/research/why/theorem-sweep/) — Un seul arc de recherche, treize familles de théorèmes structurels : pureté de l'anneau, le plancher de parité à 479, le mur des 470 comme frontière de phase, les invariants de flux, la loi d'aire entropique, et les résultats d'impossibilité qui chiffrent chaque raccourci classique. Cette page est la carte. - [Quel mur arrête quelle méthode](https://eternity2.dev/fr/research/why/walls-and-methods/) — La section recherche a deux versants : les murs structurels qui rendent Eternity II difficile, et les algorithmes conçus pour les franchir. Cette page fait le pont : chaque méthode confrontée au mur qu'elle attaque réellement, et le score auquel ce mur l'a arrêtée. - [Calibré sur le pic de difficulté](https://eternity2.dev/fr/research/why/phase-transition/) — Eternity II utilise 22 couleurs, réparties entre 17 couleurs intérieures et 5 réservées au cadre, et ce chiffre d'environ 17 se situe près du point où ce type de casse-tête est le plus difficile à résoudre (la transition est une bande, pas un entier unique). - [Les couleurs rares vivent sur le cadre](https://eternity2.dev/fr/research/why/rare-color-geography/) — Cinq des 22 couleurs d'Eternity II n'apparaissent que le long de l'anneau de bordure, chacune sur exactement 24 arêtes, jamais une seule fois à l'intérieur. Une séparation structurelle qui façonne la manière dont chaque solveur traite le cadre. - [Aucun coup forcé](https://eternity2.dev/fr/research/why/no-forced-moves/) — La manière habituelle de résoudre un casse-tête logique consiste à repérer un emplacement où une seule pièce convient, à la poser, puis à recommencer. Ce levier n'existe pas ici : chaque pièce intérieure admet entre 73 et 137 voisines possibles, et aucune n'est jamais contrainte à une seule option. - [Pourquoi le basin-hopping semble impossible](https://eternity2.dev/fr/research/why/sigma-cycles/) — Si l'on ne peut pas améliorer un excellent plateau en le peaufinant, peut-être peut-on sauter vers un autre excellent plateau. Sur chaque paire de records testée, c'est impossible, et la raison structurelle mérite qu'on la voie.