Geole a écritCependant la création a été faite sans mettre l'option --assume-clean Donc les données ont été préservées.

Humpf ! C'est tout le contraire. Et je viens de réaliser seulement maintenant que --assume-clean n'avait pas été utilisé.
Alors que la conclusion m'avait amené à penser le contraire (J'ai vue "--assume-clean", mais zappé "sans mettre" )

par ailleurs je note au message #5

jayme a écrit j'ai les messages suivants

mdadm: /dev/sdb1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Tue Jun  9 19:39:26 2015
mdadm: partition table exists on /dev/sdb1 but will be lost or
       meaningless after creating array
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Tue Jun  9 19:39:26 2015
mdadm: partition table exists on /dev/sdc1 but will be lost or
       meaningless after creating array
Continue creating array? o
Continue creating array? (y/n) y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

/dev/sdd n'apparait pas, je n'en tiens pas compte j'essaie de monter /dev/md0 avec

Après avoir fait quelques essais pour tenter de reconstituer une situation comparable. Je conclu que si sdd n'est pas apparu à ce moment, c'est qu'il n'a pas été reconnu comme faisant parti précédemment d'une grappe raid (J'ai obtenu le même résultat en effaçant un des disques)

Avec tout ça les chances de récupération s'amenuisent...

Par ailleurs, dans l'analyse des résultats de testdisk Il y a bien des traces nombreuses d'un système de fichier ext4 de 4To. Mais toutes localisent le début du système de fichier à des positions différentes et dans une fenêtre situé à environ 2To du début du volume raid.
Je pense qu'il va falloir tenter d'autres combinaisons d'assemblage...