Bonjour,
J'ai trouvé quine, la réponse attendue, mais quand j'exécute le programme sur un interpréteur, il ne s'arrête pas, il doit y avoir une erreur quelque part...

Edit:
En fait, je n'était pas assez patient, il marche parfaitement. Si tu l'as trouvé toi même, félicitation!

Juste avant ton premier crochet, tu as un ><, est ce vraiment utile?
Edit: J'ai compris pourquoi...
Je suis en train d'essayer d'écrire mon propre quine, et pour l'instant, j'ai fait la fonction qui me permet de recopier les données sous la forme +++>...
Je pense que l'on peut faire gagner pas mal de taille en améliorant la compression de données (même si le code sera alors un peu plus long....)

Edit2:
Il me semble que l'on peut faire une légère amélioration en remplaçant:

<<<+++++++[->+++<]>[->++>+++<<]>+>-

par

<<+++++++++[->+++++>+++++++<<]>-->-

C'est la même taille, mais comme il y a plus de + et moins de [], ça compresse pas mal dans la partie données...

Edit3:
Dans la plupart des interpréteurs brainfuck, il me semble que la mémoire est cyclique, tu dois donc pouvoir éviter les >>>> du début, et les .... du code...
Sinon, si tu y tient absolument, tu peux supprimer le >< avant le premier crochet, retirer un . du .... et afficher un > avant d'afficher les + (au lieu d'après)

Après quelque recherche, le plus compressé que j'ai pu trouvé est celui là (392 caractères):

->++>+++>+>+>+++>>>>>>>>>>>>>>>>>>>>+>+>++>+++>++>>+++>+>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>+>+>>+++>>+++>>>>>+++>+>>>>>>>>>++>+++>+++>+>>+++>>>+++>+>++>+++>>>+>+>
++>+++>+>+>>+++>>>>>>>+>+>>>+>+>++>+++>+++>+>>+++>>>+++>+>++>+++>++>>+>+>++>+++>
+>+>>+++>>>>>+++>+>>>>>++>+++>+++>+>>+++>>>+++>+>+++>+>>+++>>+++>>++[[>>+[>]++>+
+[<]<-]>+[>]<+<+++[<]<+]>+[>]++++>++[[<++++++++++++++++>-]<+++++++++.<]→

Le code est assez malin: chaque signe est codé par 2 valeurs. Il met un - au début pour permettre d'avoir des valeurs 0 dans le code. (Il détecte ce signe avec une instruction du genre: +[-code>+]. il fait d'abord une première étape où il met d'un côté des ++++>, en créant pour chaque + enlevé deux colonnes de + (qui encode le +) et rajoute à la fin des valeurs pour coder le >. D'autre part, il recopie la colonne en ajoutant 2 +. Ensuite, il parcours tout ce qu'il à créé en une seule fois (car le codage est le même pour tout les affichages et qu'il a rentré ses valeurs à l'envers) et affiche tout. Le codage est du type 16x + y, ou x et y sont les deux valeurs qui encodent (qui sont rentrées dans la partie donnée sous la forme x-2 y-11 pour qu'elles prennent le moins de place possible)
Ca me parait assez dur à améliorer, peut être avec un codage similaire à 3 données...)
La flèche à la fin est nécessaire. Elle est comptée comme un commentaire, et est affichée à cause de du -> au début (qui décodé tout à la fin donne quelque chose un peu aléatoire...) C'est pas exactement cette flèche, c'est celle qui correspond parfois au code ascii 18 (Mais elle ne veut pas s'afficher sur p2t)

est-ce volontaire d'avoir ecrit "cyrptogramme" au lieu de "cryptogramme..." ?

Bonne réponse de caduk donc, la réponse était bien "quine" puisque c'est le nom d'un programme qui, une fois exécuté, renvoie son propre code source.
C'était donc un quine, en Brainfuck.

Voilà pour la réponse courte.
La version mi-longue est détaillée sur mon blog ici : http://brainfuckhowto.blogspot.fr/2017/ … ion-5.html

La version longue : tout langage Turing complet (TC) admet un quine.
Démonstration :
- on appelle un programme une "fonction calculable"
- universality theorem: pour tout langage TC, il existe une fonction calculable "universelle" qui, prenant en entrée une fonction calculable, retourne le résultat de celle-ci. En bon français c'est un interpreteur.
Le but n'étant pas de se farcir les dizaines de pages de cette demo là, on va considérer ce résultat pour acquis.
- théorème smn : idem la demo est longue mais le principe simple. Pour toute fonction calculable, avec des entrées, il existe une fonction calculable qui fait pareil, avec une des entrées étant fixée. En français : si je code une fonction avec des paramètres, je peux coder une fonction avec des paramètres fixés à l'avance. Dit comme ça, ça ne casse pas des briques.

Théorème du point fixe : pour toute fonction T calculable prenant en entrée une fonction calculable (un bout de code qui transforme un algorithme en un autre) il existe un point fixe, c'est à dire une entrée E telle que T(E) fait pareil que E.
Soit une fonction calculable F, prenant une fonction calculable en entrée ;  soit S(F,F) le programme qui exécute F avec pour entrée la fonction F elle-même (théorème smn). Enfin, soit T une transformation. T(S(F,F)) est donc le résultat de la transformation de S(F,F).
D'après le premier théorème il existe un programme M qui, prenant en entrée F, retourne T(S(F,F))
Considérons S(M,M). T(S(M,M)) vaut M(M), qui est par définition S(M,M). Cette fonction est donc un point fixe de T.

Partant de là, soit T un programme qui affiche le code source de son paramètre F, il existe un programme Q tel que T(Q) et Q font pareil (point fixe). Donc Q affiche son propre code source: c'est un quine

Une vision simplifiée. En langue naturelle, si je dis à quelqu'un : dis deux fois dis deux fois, il va me répéter "dis deux fois" 2 fois, c'est donc un quine en français.

De la même manière, on peut construire un quine en informatique, y compris en BF. Les détails de la construction du quine proprement dit sont expliqués dans le lien ci dessus.

On pourra aussi lire Quel est le titre de ce livre? et Ça y est je suis fou, de Raymond Smullyan; ainsi que cette excellente page http://www.madore.org/~david/computers/quine.html