Salut Jordan.
Je vois que tu as manœuvré avec autant d'ingéniosité que de ténacité. Je suis resté, quant à moi, en situation de porte-à-faux : d'avoir à conjecturer en mode purement théorique, sans pouvoir conduire de tests expérimentaux faute de disposer d'un installateur de Windows sur un medium quelconque. Ce qui m'étonne, dans ce fourbi, c'est autant l'incapacité de «BootCamp» à régler a priori la question des partitions d'accueil de Windows, que les limites de l'installateur de Windows à reconnaître les partitions qui lui sont réservées d'avance.
--------------------
D'après ton tout dernier message, tu as choisi de virtualiser Windows via le logiciel de virtualisation : «Vmware Fusion» - solution on ne peut plus satisfaisante pour qui n'entend pas jouer à des jeux réclamant de grosses ressources (auquel cas la solution d'une installation réelle sur le disque reste incontournable). Tu as ainsi trouvé une solution en changeant les termes du problème (à l'instar d'Alexandre tranchant le «Nœud Gordien» au lieu de s'évertuer à vouloir de le dénouer) 
.
--------------------
J'en induis que tu as abandonné la perspective d'installer Windows sur ton disque, option qui m'avait impliqué par la bande dans sa problématique à cause des questions de partitionnement qu'elle soulève et qui m'intéressent. Tu me permettras sans doute quelques bavardages dominicaux sur ce dernier thème destiné à rester ici en friche...
Dans tes messages d'hier, une avancée qui me paraît importante est le fait que Windows requière 2 partitions à la suite (et pas une seule) : une partition principale pour les fichiers de l'OS et une partition secondaire pour les fichiers de démarrage du Système (probablement un émulateur de BIOS). La préconisation de ton pote allait dans ce sens : laisser en espace libre (ne relevant pas a priori d'une partition dans la table GPT) tous les blocs du disque en-dessous de la «Recovery HD» (/dev/disk0s3), pour permettre à l'installateur de Windows de créer dessus les 2 partitions : OS / BIOS à sa guise. Soit. Mais alors : pourquoi l'installateur n'a-t-il pas fait son travail comme attendu ? Il semble, en effet, d'après les liens à des clichés du message #33 avoir de lui-même multiplié des micro-partitions sans pouvoir ensuite les reconnaître logiquement dans une table de partition MBR cohérente. D'où ton procédé, consistant à préparer à l'avance 2 partitions d'accueil : une /dev/disk0s4 (125 Go) pour l'OS et une /dev/disk0s4 (1 Go) pour le BIOS. Avec le problème récurrent : comment faire pour que l'installateur les honore quant tu démarres sur lui ?
La démarche que tu avais envisagé , une fois tes 2 partitions créées :
m'a donné du fil (cogitatif) à retordre - avouons-le.
D'abord, parce qu'elle est logiquement impossible, en vertu du "paradoxe de Frege" que le mathématicien Bertrand Russell a mis en évidence avant de créer sa «Théorie des Ensembles». Frege était un logicien qui avait proposé en premier une formalisation jouant sur 2 types d'entités : les ensembles (objets contenants) et les éléments (objets contenus), sans s'apercevoir que sa théorie permettait en dernière instance de poser un ensemble comme s'appartenant à lui-même, càd. comme objet inclus de son propre ensemble - ce qui induit en cascade des effets de contradiction. C'est en interdisant ce paradoxe, et en imposant à un ensemble de ne pouvoir être l'élément que d'un ensemble d'ordre supérieur et pas de lui-même, que Russell a construit une formalisation en arborescence, càd. non-réflexive. Ce n'est pas (à mon avis) qu'une formalisation ne puisse être réflexive (et même, ne doive pas l'être --> c'est la requête ontologique de la philosophie : pouvoir s'arrêter à un Ensemble absolument Premier qui soit le fondement de lui-même = l'«Être», au lieu d'admettre à l'infini qu'aucun Ensemble n'est absolument Premier, puisque a priori posable comme objet seulement en tant qu'élément inclus dans un Ensemble supérieur E+1 - ce qui impose à la pensée de ne jamais pouvoir s'arrêter, contrairement au principe d'Aristote «Anankè sthénaî» : "il est nécessaire de s'arrêter" <à un Principe absolument Premier - quand on pense>) - c'est qu'une telle formalisation réflexive n'est pas opératoire mais seulement spéculative. Aucun ordinateur n'est possible sur la base d'une formalisation réflexive - il faut nécessairement une formalisation arborescente, càd. russellienne, pour ce faire.
Quand tu demandais à gdisk de définir une partition (élément) non dans une Table de Partition (Ensemble), mais comme une Table de Partition - tu demandais à un élément d'être son propre Ensemble de référence (pars totalis), ce qui me semble relever du "paradoxe de Frege" : un "partitionnement réflexif". C'est impossible en logique informatique, strictement russellienne, càd. arborescente et c'est à cette logique opératoire qu'obéit le logiciel gdisk : une Table de Partition est un ensemble formel incluant des éléments (partitions) ; ce n'est pas une partition (élément) se référant à elle-même comme étant une Table (Ensemble). Bref, une Table de Partition se projetant sur l'espace entier d'un disque, c'est toujours l'espace-disque entier qui est concerné, les partitions élémentaires équivalant à des sous-secteurs de cet espace d'ensemble. Donc gdisk ne pouvait pas faire ce que tu demandais.
--------------------
Il m'était venu par ailleurs d'autres idées (conjecturelles). Apparemment, pour que des partitions créées à l'avance dans la table GPT soient "vues" comme entités par l'installateur de Windows, il faut qu'elles contiennent des systèmes de fichiers non-Apple (pas jhfs+ donc, mais par exemple ms-dos). Mais, dès que des partitions sont créées dans la table GPT avec un format non-Apple, la Table secondaire "protective MBR" qui double la GPT se trouve convertie, à partir du format (ms-dos par exemple) en une "hybrid MBR" qui est "foireuse", parce qu'aucun travail de mise en correspondance des partitions GPT (ms-dos) comme entrées formelles de cette table "hybrid MBR" n'a été effectué pour autant (c'est un table créée "à partir du format" qui n'est pas congruente formellement dans ses entrées de partitions avec la GPT). Or cette "hybrid MBR" foireuse est tout de suite détectée comme invalide par l'installateur de Windows opérant sur un EFI-based computer, à cause de sa non-congruence avec la table GPT. D'où des messages du style : "table MBR trouvée au lieu de GPT requise".
L'idée qui m'était venue était donc de reformater les 2 partitions dédiées à Windows (/dev/disk0s4 & /dev/disk0s5) soit en ms-dos, soit directement en ntfs (pourquoi pas ?), ce qui évidemment impacte la "protective MBR" par défaut et la convertit en une "hybrid MBR" invalide. Rien de plus simple alors que de demander à gdisk de supprimer cette "hybrid MBR" invalide (par exemple en demandant la recréation d'une "protective MBR" - dont, je le rappelle, la spécificité est de n'avoir qu'une entrée de partition équivalant à la totalité de l'espace-disque jusqu'à une limite de 2 To). Ensuite, de demander la recréation formelle d'une "hybrid MBR" valide, car générée en corrélation de définitions des partitions avec le partitionnement GPT pris pour "template" = patron (il aurait suffi de demander à ce que les partitions GPT : 1 = ESP, 4 = WINDOWS et 5 = WINDOWS 2 soient intégrées comme entrées à la table "hybrid MBR" en qualité de partitions n°1, 2 et 3 - trois entrées étant un maximum).
Il aurait été intéressant de vérifier, alors, les 2 partitions étant "vues" comme entités (format ms-dos ou ntfs) et la table de partition MBR étant a priori reconnaissable car valide, quel aurait été le comportement de l'installateur de Windows. Aurait-il sans moufter accepté d'installer les fichiers-Système sur la partition ntfs de l'OS et les fichiers de boot sur la partition-BIOS ? Ou bien y aurait-il eu encore d'autres avanies (et framboises...) ? 
--------------------
