Discussion :

[Sve@r]

tandis que avec le premier programme ca prendrait plusieurs heures, voir jours...

Oui c'est vrai que j'ai lancé un 900x900 il y a probablement 40mn et il n'est toujours pas généré. Hé oui, la complexité augmente proportionnellement au carré de la taille...

Si je fais ca on verra directement par ou il faut passer pour résoudre le labyrinthe : il y aura 1 seule solution mais qui ne passera pas aléatoirement par tous les minis-labyrinthes, cela reviendrait a résoudre plusieurs mini_labyrinthes a la suite.

Oui, effectivement.

Mon but est d'obtenir des labyrinthes de toutes tailles pour pouvoir faires différents types d'études (que j'ai deja commencé a implémenter dans le programme) quant à l'efficacité des différents algorithmes.

Pourquoi faire? Le problème est déjà résolu: en entrant dans le labyrinthe je pose ma main gauche(*) contre un mur puis je ne la décolle plus du mur et j'avance en longeant donc le mur gauche. Je suis forcé d'arriver à la sortie à un moment ou un autre.
(*) ça marche aussi avec la droite

Je me dis que je pourrais, à la place d'inserer des labyrinthes pour faire la jonction, realiser cette methode en attribuant aux labyrinthes différents indices.

Pas évident car l'algo permet de créer des chemins mais n'évite pas les culs de sac. Faudra donc gérer si le labyrinthe permet de sortir sur un autre ou pas.
Exemple

Comme tu vois, en arrivant dans un cul de sac le type repart chercher dans une autre direction. Mais si la case avec une croix est un labyrinthe, cela signifie que c'est un labyrinthe "cul de sac" donc avec l'entrée et la sortie sur le même côté. Ca va pas être évident...

en y repensant même cette méthode ne garantit pas l'unicité

Ah si. Puisque ça garantit l'unicité pour les cases, ça garantit l'unicité pour les labyrinthes. Mais ça ne garantit pas que tu passeras par les 9 (cf mon exemple où on peut shunter les deux du haut)