Nous essaierons au travers de cette interview de retracer un peu l’évolution de sa carrière, carrière assez dense comme vous pourrez le constater. Les contraintes de disponibilité de monsieur Tsuruta nous ont poussés à essayer de réduire au maximum le nombre de questions, ce qui explique le fait qu’une large partie de son travail ne sera pas – ou peu – abordée ici.

Cette interview a été conduite en juin/juillet 2012 par courriel.

1 / Tout d’abord M. Tsuruta, merci d’avoir accepté de répondre à cette interview.

D’après les informations qui figurent sur votre site internet, votre premier travail dans l’industrie du jeu vidéo concerne le jeu Swimmer de Tehkan. Pouvez-vous nous en dire plus sur ce que vous faisiez avant d’entrer dans cette société ? Quel a été votre parcours scolaire / universitaire ? Est-ce que vous vous intéressiez déjà aux jeux vidéo avant d’en faire votre métier ?

J’étais étudiant de la section Art de l’université Nihon, dans laquelle je prenais des cours d’animation. Durant la seconde année de mes études, je suis entré à Tehkan en tant que travailleur à temps partiel, et j’ai participé au développement de Swimmer.

Lors de l’entretien, on m’a demandé de dessiner quelque chose qui serait emporté par le courant d’une rivière, et qui semblerait douloureux en cas de collision.

J’ai commencé à m’intéresser aux jeux vidéo et l’animation à partir du moment où j’ai posé candidature pour ce petit job.

2 / Dans une interview, Ishizuka Michishito a déclaré : « Plus de la moitié des personnes qui étaient recrutées dans les équipes de développement de Tecmo étaient originaires de Universal / UPL. Cela représentait un peu moins de 20 personnes (rires). On disait même « Si t’es pas originaire de Universal, tu ne feras jamais carrière ici ! » pour plaisanter (rires)« . À cette époque, comment était l’ambiance au sein de Tehkan ? Et comment étaient les salaires des développeurs comparés à ceux d’aujourd’hui ?

À l’époque, on procédait à la vente des PCB utilisées dans les bornes qui étaient commercialisées pour les exploitants arcade. Le prix unitaire d’une PCB variait de 100 000 à 200 000 mille yens, avec une durée de développement comprise entre 3 et 6 mois environ. Cela nécessitait une équipe principale de développement composée de plusieurs personnes.
Les marges bénéficiaires étaient grandes, et c’était l’époque où le marché de l’arcade était en développement constant. Je pense donc que les bénéfices de la société demeuraient très importants.

Même en cas d’échec d’un projet, il était possible de redresser suffisamment la situation par la suite en créant un nouveau jeu. Et c’est peut-être pour toutes ces raisons que le développement des jeux se déroulait dans une atmosphère de liberté.

Quant aux salaires, je pense qu’ils ne différaient pas vraiment de ceux des autres secteurs d’activité économique. Et c’était encore le temps où le concept d’emploi à vie était très présent dans les mentalités japonaises.

3 / Vous étiez designer graphique pour Swimmer. Combien de personnes ont développé ce jeu et d’où en vient l’idée ?

Une personne pour le hardware, une pour la programmation, une pour l’aspect sonore, une pour la direction et les graphismes, auxquelles s’ajoutent, si je ne me trompe pas, 3 personnes à temps partiel pour les graphismes. Comme c’était mon premier travail, il y avait beaucoup de choses liées au développement que je ne comprenais pas très bien.

À l’époque, pour la conception graphique, on coloriait les croquis originaux sur une feuille quadrillée, on transformait le résultat en données numériques, puis on gravait tout cela sur une EPROM, que l’on disposait ensuite sur une PCB. On pouvait ensuite observer pour la première fois le rendu via un écran cathodique. À l’heure actuelle, ce type de marche à suivre faite de procédés détournés serait totalement impensable, mais elle était indispensable durant ces années.

Il n’était d’ailleurs pas seulement question de savoir si les dessins étaient bien réalisés, il fallait aussi s’occuper du rendu et de leur affichage, et cela nécessitait plusieurs tests particulièrement fastidieux. Mais lorsque pour la première fois j’ai vu nager le personnage que j’avais dessiné, j’ai trouvé cela très amusant.

4 / Guzzler (Tehkan, 1983) est votre premier jeu en tant que game designer, et vous l’avez développé en même temps que Swimmer. Comment se fait-il que vous ayez occupé ces fonctions aussi rapidement ? Qu’est-ce qui est difficile dans le design d’un jeu ?

Au moment où mon travail sur Swimmer était sur le point de s’achever, la société était à la recherche de nouveaux projets de conception de jeux, et j’en ai proposé plusieurs. L’un d’entre eux allait devenir Guzzler. Ce sont ces offres de projets qui m’ont permis de reconduire mon contrat chez Tekhan après mon travail sur Swimmer. Mais cette fois en tant que designer.

Le point particulièrement délicat dans la conception de jeux d’arcade réside dans les visions antinomiques du jeu que possèdent d’un côté le joueur, et de l’autre l’exploitant : le joueur désire s’amuser le plus longtemps possible, mais l’exploitant veut gagner de l’argent, donc limiter le temps de jeu pour pousser le joueur à remettre une pièce dans la borne.

Il faut donc faire en sorte que le joueur conserve l’envie de s’amuser en dépit de la faible longueur des parties, et cela est extrêmement délicat.

5 / Il semblerait que pas moins de 6 personnes composent le staff de Bomb Jack (Tehkan, 1984). Qui a lancé l’idée de ce jeu ? Est-ce que vous avez des souvenirs ou des anecdotes à nous raconter au sujet de son développement ?

J’étais à l’origine du design de Bomb Jack, mais le jeu comportait des problèmes de gameplay, et c’est Ueda Kazutoshi, à l’époque responsable de la section développement, qui a apporté de nombreuses corrections pour arriver au jeu que l’on connaît aujourd’hui.

Il m’a beaucoup influencé dans ma façon de concevoir les jeux, et je me référencie souvent à sa phrase « Le jeu est une question d’équilibre » pour mon travail.

6 / La prochaine question concerne un point qui m’intéresse énormément : en 1986, Tehkan est devenu Tecmo, Ueda Kazutoshi et Ishizuka Michishito ont quitté cette société pour aider à fonder, respectivement, Atlus et Westone (Escape). Pour quelles raisons ? Qu’avez-vous ressenti en apprenant que vos camarades développeurs quittaient Tekhan / Tecmo ?

Si l’on s’attarde un peu sur le développement de Tehkan, il semblerait qu’au tout début ont été recrutés des gens dotés d’une grande expérience issus d’une autre société (NDT : Universal / UPL) afin de constituer les différentes sections.

Je pense que les fondateurs de Tecmo, quant à eux, désiraient tôt ou tard mettre en place une entreprise dont les ressources humaines seraient constituées de nouveaux diplômés universitaires. Les premiers employés de Tekhan ont dû se sentir lésés par ces décisions, et à cela s’ajoutait le fait que le marché de l’arcade était en plein essor, ce qui fait que plusieurs d’entre eux ont dû décider de démissionner pour aller fonder leur propre société.

Le fait que des personnes avec lesquelles j’avais conçu des jeux démissionnent a été un choc pour moi. En particulier dans le cas où l’on entre alors en concurrence avec eux, peut-être par manque de communication, pour une personne qui ne connaît pas le mot « démission », c’est un évènement qui paraît si soudain ! Mais j’avais entendu dire que c’était un milieu professionnel dans lequel les talents allaient et venaient de façon brusque, et lorsque la réalité m’apparut sous les yeux, j’en prenais de plus en plus conscience.

7 / Parlons un peu de Solomon’s Key (Tecmo, 1986). C’est un jeu très populaire en Europe. J’ai personnellement d’abord connu ce jeu via sa version Famicom, et non arcade. Je pense qu’il en va de même pour la majorité des Français. Mais qu’en était-il du Japon ?

Le développement du jeu concernait d’abord la version arcade, mais durant ce dernier, on a débuté celui de la version Famicom, et les deux jeux ont été mis en vente presque simultanément.

Les chiffres de vente des PCB et des jeux Famicom diffèrent énormément, et, pour cette raison, je pense qu’au Japon les personnes qui connaissent la version Famicom mais pas la version arcade sont nombreuses. Néanmoins, Tehkan était avant tout une société qui avait débuté dans l’arcade, et donc les fans de la version arcade étaient également nombreux. Il m’est même arrivé de participer à des rencontres avec eux.

Peu de temps après la mise en vente de Solomon’s Key, un(e) professeur(e) – d’école primaire si je me souviens bien – est venu(e) nous poser des questions afin de pouvoir finir le jeu. Il / Elle avait l’intention de montrer la fin du jeu à ses élèves le dernier jour de l’année scolaire pour leur faire plaisir. Mais il y avait un stage en particulier qui lui posait problème, et il / elle voulait qu’on lui donne la solution. Je suis content du fait que nous ayons pu lui montrer.

8 / Quelle fut l’idée à l’origine de Solomon’s Key ? C’est un jeu qui combine des éléments d’action et de réflexion (sous forme de puzzle), mais est-ce qu’à l’origine c‘était déjà le cas ? Est-ce que vous l’avez conçu seul ?

A cette époque, Lode Runner remportait un franc succès. Dans ce jeu, la principale action possible consiste à faire disparaître des blocs. Et je me suis dit que l’action inverse serait peut-être amusante. C’est donc cette idée qui fut à l’origine de Solomon’s Key.

Je me suis d’abord orienté vers la réalisation d’un jeu d’action. Mais comme le fait de faire apparaître et disparaître des blocs est proche d’un puzzle, Ueda Kazutoshi a demandé à l’une de nos connaissances de travailler sur cet aspect du jeu pour les stages plus orientés réflexion, ce qui fait que, finalement, Solomon’s Key est devenu un mélange d’action et de puzzle.

Comme vous le laissiez supposer dans votre question, au commencement, j’étais vraiment seul à travailler sur ce projet. Lors du développement de la version arcade, Ueda Kazutoshi s’est allié à moi, et le travail a pris une orientation axée sur des éléments de puzzle. Ensuite, Ueda a quitté Tehkan, le développement de la version Famicom a débuté, et j’ai dû alors concevoir des niveaux avec toute une équipe. Le projet est donc passé par plusieurs phases.

9 / Solomon’s Key est votre premier titre sur Famicom. Quelles étaient les différences notoires en matière de développement entre la Famicom et l’arcade ? Le novice que je suis a plutôt tendance à penser qu’il est plus simple de développer sur la console de Nintendo. Qu’en pensez-vous ?

Il y en avait plusieurs : les fonctionnalités de la console demeuraient assez floues, ses capacités techniques étaient inférieures à celles des machines arcade, etc. Par exemple, et c’est un simple ordre d’idées, une palette de 15 couleurs possibles sur un jeu arcade correspondait à 3 couleurs sur la version Famicom, et nous devions donc redoubler d’efforts pour pallier à ces insuffisances techniques. Je pense que sur ce point, le développement d’un jeu Famicom était plus complexe que celui d’un jeu arcade.

Néanmoins, comme le système de jeu en lui-même était déjà restreint dans la version arcade, je pense que l’adaptation sur la console de Nintendo demeurait assez fidèle à l’originale.

10 / Par la suite, vous avez développé des jeux sur de nombreuses plateformes. Après la commercialisation de la Playstation et de la Saturn, les jeux en 3D ont connu un véritable essor. En tant que développeur, comment avez-vous vécu cette transition ? Etait-ce difficile sur le plan technique ?

Les modes de conception et les technologies utilisés pour le développement des jeux en 3D diffèrent de ceux des jeux en 2D. Dans le cas des jeux 3D auxquels j’ai participé, mon travail se portait davantage sur le design ludique que les aspects technologiques, et c’est pourquoi je pense qu’à l’époque je n’ai pas souvent eu l’occasion d’être en contact direct avec ce type de technologie.

A l’inverse, j’ai l’impression qu’à l’heure actuelle les opportunités d’utiliser ces technologies 3D ou OpenGL se sont accrues depuis que je développe des applications pour iPhone.

11 / Quand êtes-vous devenu freelance et pourquoi avez-vous quitté Tecmo ?

J’ai quitté Tecmo en 1988 après le développement du premier épisode de Captain Tsubasa (Famicom, Tecmo, Avril 1988). J’ai pris cette décision car je me suis marié avec ma petite amie que je fréquentais depuis l’Université. Ses parents étaient gestionnaires d’un studio photo et je suis devenu un de leurs employés. Mais je n’ai pas pour autant arrêté de développer des jeux, puisque j’ai continué à la faire en tant que freelance.

12 / Concrètement, comment se déroule une journée de travail d’un développeur freelance ? Par exemple, quand vous avez travaillé sur Monster Kingdom Jewel Summoner (PSP, Gaia, Février 2006) pour Gaia, je doute fort que vous soyez resté tout le temps à la maison sans vous déplacer chez ce développeur n’est-ce pas ?

Pour commencer, des rencontres avec l’équipe de mon client ont lieu, et durant celles-ci, on vérifie la marche à suivre, le contenu de la demande, le planning, le cadre dans lequel le travail doit être effectué, et on fixe l’ensemble de tous ces points.
Ensuite, arrivé à un certain stade – stade qui autorise toutefois des modifications en cas de problèmes -, on montre au client l’avancée de son travail, et si cela convient à tout le monde, on se met à nouveau d’accord pour la finalisation.
De façon générale, mon travail sur le développement intrinsèque se déroule chez moi, et les rencontres ont lieu principalement dans l’entreprise du client.

Dans le cas de Monster Kingdom Jewel Summoner, j’ai dû me rendre à l’entreprise du client pour effectuer les réglages finaux de la difficulté du jeu.

13 / Vous avez développé un jeu du nom de Astro Zill pour iPhone, iPod Touch et iPad. Pourriez-vous nous le présenter ?

C’est un jeu dans lequel il faut coller des boules de même couleur les unes aux autres pour les faire disparaître. Un peu à la manière de Solomon’s Key, il faut faire disparaître, apparaître, déplacer des boules, et ordonner des couleurs. Les autres jeux d’ordonnancement à base de couleurs ne contiennent pas de personnage principal, mais c’est le cas dans Astro Zill, et cet aspect est directement issu de Solomon’s Key.

En fait, Ueda Kazutoshi m’avait offert un jeu de réflexion du nom de Ten Billion Barrel, et c’est ce jeu qui est à la base des mécanismes de Astro Zill.

Dans Astro Shift, un jeu pour iPhone récemment mis en vente, j’ai poussé encore plus loin les ressemblances avec les mécaniques de jeu de Ten Billion Barrel.

14 / Que pensez-vous de l’industrie vidéoludique actuelle ?

Il semblerait que le marché soit d’abord parti de l’arcade, pour évoluer vers les consoles, et ensuite se concentrer sur les jeux basés sur les réseaux sociaux. Et si l’on observe les évolutions sur le plan de la durée de jeu (NDT : comprendre par là : durée d’une ou plusieurs parties en continu), je considère que l’on a effectué une révolution complète : on est parti de plusieurs minutes pour évoluer vers plusieurs heures, et revenir ensuite de nouveau vers plusieurs minutes.

15 / Existe-t-il des personnes qui vous ont influencé ou que vous respectez ?

Bien-sûr, la première personne à laquelle je pense est Ueda Kazutoshi. Et ensuite vient Douglas E. Smith, le créateur de Lode Runner.

16 / C’est une question difficile, mais, pour vous, qu’est-ce qu’un jeu ?

Dans un jeu, il y a d’une façon ou d’une autre des conditions de réussite, et pour que le joueur les satisfasse, il faut qu’il emploie des ressources, comme, par exemple, du temps et ses capacités. C’est du moins ce que je pensais.

Récemment, j’en suis venu à me demander s’il ne s’agissait pas plutôt de « conditions de bien-être », au lieu de celles énoncées précédemment. Je pense que l’on joue pour obtenir des joies plus grandes que celles que le quotidien nous permet d’acquérir.

En ce sens, je pense donc que le jeu est un objet doté de mécanismes faisant ressentir du bonheur. Le jeu est conçu pour permettre d’acquérir ce bonheur, mais il appartient au joueur d’aller le chercher. Et c’est en opérant des choix divers qu’il peut se procurer cette satisfaction.

17 / Ainsi s’achève cette interview. Merci beaucoup M. Tsuruta. Un dernier mot ?

Je suis très heureux d’avoir été interviewé au sujet des jeux auxquels j’ai participé durant un peu moins d’un quart de siècle.

L’origine de mes jeux se trouve bien entendu dans les jeux d’arcade auxquels je jouais lorsque j’étais lycéen puis étudiant. Et je pensais faire des jeux originaux sur iPhone en m’appuyant sur ces bases.

On peut dire que je vise le style des jeux d’arcade de cette époque quand je travaille sur Astro Zill ou Astro Shift. Et je serais très heureux si, après la lecture de cette interview, des personnes pouvaient s’intéresser à mes jeux et y jouer.

Liste des travaux de Tsuruta Michitaka (^) :
 
- Swimmer, 1982, Tehkan, arcade : designer graphique.

- Guzzler, 1983, Tehkan, arcade : designer.

- Bomb Jack, 1984, Tehkan, arcade : designer.

- Solomon’s Key, 1986, Tecmo, arcade et Famicom : designer, chara designer, map designer.

- Tsuppari Ôzumo, 1987, Tecmo, Famicom : chara designer

- Captain Tsubasa, 1988, Tecmo, Famicom : designer des mécanismes des matchs et de l’architecture narrative.

- Necros no Yôsai, 1990, ASK Kôdansha, PC Engine : designer du système narratif, du système de combats, rédacteur du story board.

- Captain Tsubasa 2, 1990, Tecmo, Famicom : story board, système d’augmentation de la difficulté en cours de jeu, données scénaristiques pour le haut niveau de jeu, mécanismes d’apparition des cinématiques en cours de jeu, etc.

- Pitman, 1990, ASK Kôdansha, Gameboy : Mécaniques du jeu, Chara designer.

- F1 Boy, 1990, ASK Kôdansha, Gameboy : Designer.

- Hyaku no Sekai no Monogatari, 1991, ASK Kôdansha : Concepteur des décors des scènes cinématiques et des séquences de combat.

- Solomon’s Key 2, 1992, Tecmo, Famicom : Designer, Responsable général.

- Captain Tsubasa 3, 1992, Tecmo, Famicom : Responsable général de la section projet, Conseiller pour le système de narration.

- Captain Tsubasa, 1994, Tecmo, Mega-CD : Elaboration du système de narration, des données scénaristiques pour le haut niveau de jeu, des mécanismes d’opérations mathématiques, et des outils de transformation des données.

- Zico Soccer, 1994, Electronic Arts Victor, Super Famicom : Projet général, concepteur des données pour la difficulté.

- Dokapon Gaiden, 1995, Asmik, Super Famicom : Projet, concepteur des données pour la mise en scène des combats.

- Dungeon Creator, 1996, Electronic Arts Victor, Playstation : Projet.

- Dark Half , 1996, Enix, Super Famicom : Concepteur des phases parlées par les personnages.

- Imadoki no Vampire, 1996, Atlus, Playstation : Projet, concepteur des données pour la difficulté.

- Willy Wombat, 1997, Hudson, Saturn : Concepteur de la carte du jeu.

- Sotsugyô M, 1997, Hearty Robin, Playstation : Rédacteur du cahier des spécifications.

- Monster Tactics, 2000, Nintendo, Gameboy Color : Designer, concepteur de la carte, projet général, concepteur de la difficulté, administrateur.

- Palm Ball, 2001, Does, Palm : Rédacteur du cahier des spécifications, correction des données.

- Puzzle Pom, 2003, Gigaflops Giga Appli, iPhone 503 504 : Tout, sauf les données musicales.

- Jidôshaô, 2003-2005, Square Enix, Web : Projet, rédacteur du cahier de spécifications, datawork.

- Deep Labyrinth, 2004 ( ?), Interactive Brains, Vodafone V-appli : Aide à l’élaboration du projet et au système d’entrée des données.

- Light Stream, 2005, Interactive Brains, EZ-appli (BREWR), au W21T : Aide à l’élaboration du projet, spécifications pour l’écran, scénario, conception d’une partie des tracés de circuits.

- Monster Kingdom Jewel Summoner, 2006, Gaia, PSP : Système de combat (concepteur des spécifications, de l’aperçu, et des données pour la difficulté, en dehors de celle des boss), système de progression.

- Astro Zill, 2009~, turu3net (Tsuruta Michitaka), iPhone – iPod touch – iPad : Projet, Programmation, Graphismes.

- Astro Shift, 2012, turu3net (Tsuruta Michitaka), iPhone – iPod touch – iPad : Projet, Programmation, Graphismes.

Une petite vidéo sur le premier épisode de la mythique saga, dans sa réédition au format cartouche au Japon (via un émulateur). Un challenge qui consiste à finir le jeu sans utiliser d’armes
secondaires. Rien de très passionnant au final, mais une occasion pour moi de me lancer dans un shibari play (jap. : 縛りプレイ). Vous l’aurez compris, il s’agit de finir un jeu en s’imposant
des contraintes, shibari venant du verbe shibaru « attacher, lier, nouer, ligoter ». Amateurs / trices de bondage et de S.M., bon visionnage !

Une dernière chose : très récemment, les gugusses de The Legacy Music Hour ont réalisé une interview de Yamashita Kinuyo, interview selon laquelle Terashima Satoe serait l’autre compositrice des
musiques du jeu. Vous pouvez lire tout cela ici :

http://legacymusichour.blogspot.com/2011/07/legacy-music-hour-episode-36-kinuyo.html

Avant d’entrer dans le vif du sujet, de courtes présentations s’imposent : je suis un enculé qui porte des tongs, et je publie de temps à autres des vidéos sur Dailymotion. Ces dernières sont
principalement axées sur des anecdotes en rapport avec la conception du jeu dont il est question.

Pour ma première participation à Nesblog, voici une petite vidéo qui concerne Doki Doki Panic. Ou, plus exactement, son contexte de parution. Ne vous attendez donc pas à un vidéotest ou
quelquechose qui s’en approcherait.

Je voudrais revenir sur un point qui n’est pas suffisamment mis en évidence dans ce petit montage commenté  : le jeu vidéo est une industrie comme les autres, à savoir qu’elle est
étroitement liée à des facteurs économiques sur lesquels elle n’a aucune emprise. La sortie de Doki Doki Panic s’explique uniquement par les formidables quantités de liquidités qu’a dégagées la
bulle immobilière japonaise (1985-91), bulle sans laquelle le Japon n’aurait pas connu le boom des expositions pharaoniques de la période considérée. Et, bien-sûr, cette logique fonctionne dans
l’autre sens : l’éclatement de la bulle a eu un impact majeur sur l’industrie japonaise du jeu vidéo, condamnant à la faillite de nombreux éditeurs / développeurs qui avaient cru bon investir
dans ces fonds spéculatifs. Le cas le plus connu étant sans doute celui de Hal Laboratory, qui déclara la faillite en 1992 après avoir expérimenté des investissements immobiliers. La société ne
dut sa survie qu’à l’intervention de Nintendo, sous l’égide de son boss Yamauchi Hiroshi qui nomma Iwata Satoru à la tête de Hal Laboratory.

Ce long détour pour tenter d’énoncer cette banalité : le jeu vidéo, en tant qu’industrie, ne fonctionne pas en autarcie. Et l’arrivée de nouvelles machines et de nouveaux jeux toujours plus
coûteux n’est donc pas un processus inéluctable. C’est Nouriel Roubini qui me l’a dit. Si si.

Allez, trêve de conneries, bon visionnage à tous !

Une vidéo un peu longue, j’en ai bien conscience, mais cela est dû au passage relatif aux parcours professionnels de trois des concepteurs du jeu. Je ne pouvais pas faire l’impasse sur cela tant ça me semblait important.

A la toute fin, une interview de Uematsu Nobuo, dans laquelle il explique que le report de la sortie de Final Fantasy IV fut en grande partie lié à l’excellent travail de Koshiro Yûzô sur Actraiser.

Avec la participation exceptionnelle de 6coups6mouches, pour lequel le décès de Pierre Bérégovoy n’a aucun secret.

Un grand merci à toi 6coups !

En vous souhaitant à tous et toutes de bonnes fêtes !

Il s’agit cette fois d’un jeu tournant sur la 16 bits de Nintendo et qui m’a beaucoup marqué : un savant mélange d’action et de gestion, avec pour toiles de fond le rapport homme-divin et la

lutte du Bien contre le Mal.

Une vidéo un peu longue, j’en ai bien conscience, mais cela est dû au passage relatif aux parcours professionnels de trois des concepteurs du jeu. Je ne pouvais pas faire l’impasse sur cela tant

ça me semblait important.

A la toute fin, une interview de Uematsu Nobuo, dans laquelle il explique que le report de la sortie de Final Fantasy IV fut en grande partie lié à l’excellent travail de Koshiro Yûzô sur

Actraiser.

Avec la participation exceptionnelle de 6coups6mouches, pour lequel le décès de Pierre Bérégovoy n’a aucun secret.

Un grand merci à toi 6coups !

En vous souhaitant à tous et toutes de bonnes fêtes !